Конфигуратор vs modbus.lib

[Sergey666]

Самое непредсказуемое в разных Modbus Slave - это таймауты. Обработка в Slave в идеале должна делаться именно так, как Вы описали. В этом случае Slave не теряли бы ни одного запроса и могли бы вовремя ответить. Но реально так не получается, приходится экспериментальным путём подбирать в Master таймауты, многократно превосходящие стандартные.

Тайм-аут должен быть один - на ожидание ответа , стандартно 1000мс . "Торможение" на модбас шине происходит когда 1 или несколько слэйвов не отвечают и мастер вынужден выдерживать тайм-аут , непрерывно вычитывая буфер порта(для очистки мусора и совести).
Считаю что обмен должен быть организован по принципу непрерывно-независимого-асинхронного потока , как писал выше товарищ Егор , это нормально и надежно .

[Валенок]

По теме.
Пока 1...2 переменных 1..2 слейва - устраивает конфигуратор.
Когда увеличивается кол-во переменных/слейвов или перенеся код обнаруживаешь какие-то станные зависимости от прошивок/таржетов или нужно более гибкое управление - переходишь на modbus.lib
Перейдя на modbus.lib через некоторое время уходишь на просто syslibcom.lib, т.к. modbus.lib простой и надежный - но можно и улучшить
А перейдя на биб-ки и привыкнув к возможностям почему-то не хочется юзать конфигуратор (конфигуратор-слейв - нареканий невызывает) даже с 1..2 переменных с 1..2 слейвами

То что описал Егор - нормально. Другого варианта для спецификации модбас и последовательного порта просто нет.

Таймаут вообще странное понятие.
Лично я учитываю время от момента отправки последнего байта запроса до момента прихода первого байта пакета-отклика (может и мусор). Почти всегда 3-10мс. Отдельные девайсы - 50мс. Дольше ждать смысла нет - ответа не будет.

[capzap]

чего сразу syslibcom, если не хочется терять связь с конфигуратором, то и unm не плоха

[Sashokxxx]

http://owen.ru/forum/showthread.php?...848#post175848 Но это может быть неактуально для СПК.

В библиотеке SysCom которая подсоединяется при добавлении modbus.lib через дескриптор открывается все, но настроить порт, ровно как и получить данные о настройках порта - не получилось. SetSettings and GetSettings не понятно как работают, открыл и настроил через OwenLib читал через UniRead. Все работает.

[Валенок]

чего сразу syslibcom, если не хочется терять связь с конфигуратором, то и unm не плоха

Портирование 63<->110

[Yegor]

Я таймаут считаю с момента завершения отправки запроса до схождения контрольной суммы ответа. Точнее, это частный случай слежения за автоматом. Тот же таймер следит и за отправкой запроса. Короче, вот псевдокод с некоторыми упрощениями:

(* Срабатывает, если автомат долго находится в одном состоянии *)
сторожевой_таймер(IN := состояние = _состояние, PT := T#100ms);
_состояние := состояние;

IF NOT сторожевой_таймер.IN THEN
    счётчик := 0; (* Чтобы в автомате не забывать это триста раз делать *)
END_IF

IF сторожевой_таймер.Q THEN (* Случился таймаут *)
    состояние := таймаут;
END_IF


CASE состояние OF


    начало:
        открыть_порт;
        настроить_порт;
        состояние := отправлять_запрос;
    
     отправлять_запрос:
        (* Сюда вставить ещё код формирования запроса *)
        (* Как правило, запрос отправляется целиком сразу *)
        счётчик := счётчик + в_порт(буфер, счётчик, размер_буфера - счётчик);
        IF счётчик = размер_буфера THEN
            состояние := ждать_ответ;
        END_IF
        
     ждать_ответ:
        (* Сначала читаем до того места, где указан или может быть вычислен размер ответа *)
        (* Не забываем, что ответ может приходить частями *)
        IF счётчик < до_маркера_размера THEN            
            счётчик := счётчик + из_порта(буфер, счётчик, до_маркера_размера - счётчик);
        ELSE (* Потом читаем остаток вычисленного размера *)
            счётчик := счётчик + из_порта(буфер, счётчик, размер_пакета - счётчик);
            IF счётчик = размер_пакета AND сходится_сумма THEN
                состояние := успех;
            END_IF
        END_IF
        
    успех:
        результат := из_буфера;
        состояние := отправлять_запрос;
        
    таймаут:
        состояние := отправлять_запрос;
        
END_CASE

По вкусу это оформляется функциональным блоком, открывание порта выносится за пределы, вызывающая сторона просто смотрит на "состояние" и по своему усмотрению активирует такие блоки один за другим.

[rwg]

Тайм-аут должен быть один - на ожидание ответа , стандартно 1000мс .

Это если ASCII Modbus. Если RTU и скорость 9600 и более, то 3,5 мсек. Но к сожалению многие производители Modbus Slave его не соблюдают и заставляют себя подолгу ждать . А ещё есть таймаут между концом приёма ответа и следующим запросом. Если не выждать паузу (по стандарту - те же 3,5 мсек, по факту - кто во что горазд), то Slave просто не услышит обращённый к нему запрос.

[Спорягин Кирилл]

Хочу добить тему организации опроса в одной задаче или в разных.
Опишу все еще раз, но по-другому.
Исходные данные следующие:
1. Количество модулей 10 шт. (все те же);
2. Время достаточное для опроса модуля по сети Modbus - 10 мс. Еще раз поясню, что за время я имею ввиду. Если я на N-ном цикле вызову, например, ФБ MB_RD_HOLD_REGS, то на цикле N+1, отстоящим от него на 10 мс (или более) выход Complete установится в true. Мои расчеты (см. выше) показывают, что 10 мс должно хватать (то же говорит и Валенок:"Почти всегда 3-10мс.").
3. Среднее время выполнения программы - 50 мс. Под этим временем понимается, то усредненное время, которое необходимо для выполнения всех операторов логики управления. Мне кажется, что для программы которая обрабатывает 10 модулей ввода/вывода, это вполне реальная величина.
4. Модули равнозначны по важности, поэтому - 5-й пункт.
5. Опрос модулей организован последовательно от 1 к 10-му. За опрос отвечают некие ФБ модулей. Так как ФБ модули используют общий ресурс - порт, то необходимо предусмотреть некий механизм, который определяет какой ФБ модуль сейчас занимает порт. Назовем условно этот механизм передачей маркера опроса.

Первый вариант. Все в одной задаче.
PROGRAM PLC_PRG
ФБМодуля1(); (* у кого маркер опроса тот исполняется *)
...
ФБМодуля10(); (* а так if not marker then exit; *)
ФБЛогики управления();

Второй вариант. Две разные задачи с разными циклами исполнения.
В это варианте изменен цикл вызова задачи управления. Он сделан равным 60 мс, т.е. с запасом от среднего времени выполнения - 50 мс.
PROGRAM Module_PRG (* циклическая интервал 10мс *)
ФБМодуля1(); (* у кого маркер опроса тот исполняется *)
...
ФБМодуля10(); (* а так if not marker then exit; *)

PROGRAM PLC_PRG (* циклическая интервал 60мс *)
ФБЛогики управления();

Теперь рассмотрим какое будет время реакции на событие в первом и во втором варианте.
Событием будем считать выход некоторого аналогового параметра за технологическую норму. Пусть данный технологический параметр привязан к первому модулю. Событие происходит удачно, как раз перед отправкой запроса в модуль.
За время реакции будем считать время от события до выдачи сигнала с 10-го модуля вывода на исполнительный механизм (ИМ).
Из прикрепленного рисунка хорошо видно, что время реакции в первом случае 450 мс, во втором 100 мс.
Что на мой взгляд существенно.

Другое дело, что если система небольшая, количество модулей 1-2, а время выполнения программы 5-10 мс, то все это безусловно теряет смысл.

[capzap]

Хочу добить тему организации опроса в одной задаче или в разных.
Опишу все еще раз, но по-другому.
Исходные данные следующие:
1. Количество модулей 10 шт. (все те же);
2. Время достаточное для опроса модуля по сети Modbus - 10 мс. Еще раз поясню, что за время я имею ввиду. Если я на N-ном цикле вызову, например, ФБ MB_RD_HOLD_REGS, то на цикле N+1, отстоящим от него на 10 мс (или более) выход Complete установится в true. Мои расчеты (см. выше) показывают, что 10 мс должно хватать (то же говорит и Валенок:"Почти всегда 3-10мс.").
3. Среднее время выполнения программы - 50 мс. Под этим временем понимается, то усредненное время, которое необходимо для выполнения всех операторов логики управления. Мне кажется, что для программы которая обрабатывает 10 модулей ввода/вывода, это вполне реальная величина.
4. Модули равнозначны по важности, поэтому - 5-й пункт.
5. Опрос модулей организован последовательно от 1 к 10-му. За опрос отвечают некие ФБ модулей. Так как ФБ модули используют общий ресурс - порт, то необходимо предусмотреть некий механизм, который определяет какой ФБ модуль сейчас занимает порт. Назовем условно этот механизм передачей маркера опроса.

Первый вариант. Все в одной задаче.
PROGRAM PLC_PRG
ФБМодуля1(); (* у кого маркер опроса тот исполняется *)
...
ФБМодуля10(); (* а так if not marker then exit; *)
ФБЛогики управления();

Второй вариант. Две разные задачи с разными циклами исполнения.
В это варианте изменен цикл вызова задачи управления. Он сделан равным 60 мс, т.е. с запасом от среднего времени выполнения - 50 мс.
PROGRAM Module_PRG (* циклическая интервал 10мс *)
ФБМодуля1(); (* у кого маркер опроса тот исполняется *)
...
ФБМодуля10(); (* а так if not marker then exit; *)

PROGRAM PLC_PRG (* циклическая интервал 60мс *)
ФБЛогики управления();

Теперь рассмотрим какое будет время реакции на событие в первом и во втором варианте.
Событием будем считать выход некоторого аналогового параметра за технологическую норму. Пусть данный технологический параметр привязан к первому модулю. Событие происходит удачно, как раз перед отправкой запроса в модуль.
За время реакции будем считать время от события до выдачи сигнала с 10-го модуля вывода на исполнительный механизм (ИМ).
Из прикрепленного рисунка хорошо видно, что время реакции в первом случае 450 мс, во втором 100 мс.
Что на мой взгляд существенно.

Другое дело, что если система небольшая, количество модулей 1-2, а время выполнения программы 5-10 мс, то все это безусловно теряет смысл.

так это у Вас теория или Вы на графиках привели среднеизмеренное время? Если всё в реале остановитесь на втором варианте

[Спорягин Кирилл]

Пока теория. Но собираюсь испробовать на практике. Только пока нет ни контроллера, ни модулей.