Тормозит передача по modbus на индикатор (решено)

[Shuric]

Вывожу циферку одновременно на экран контроллера и по модбас на индикатор ОВЕН SMI2. На индикаторе цифра обновляется секунд на 10-15 позже, чем на экране. Залез посмотреть в SMLogix - и действительно, на входе кубика с переменной число уже несколько раз поменялось, а на выходе появляется секунд 15 спустя.

Всего на модбасе 8 устройств. Из двух читается по 40 слов групповым запросом, в 6 пишется по одному слову. Скорость 19200.
Период для всех переменных 500 мс.
Что за фигня? Искать проблемы в проводах или..?

[СВМ]

Сообщение от Shuric

Вывожу циферку одновременно на экран контроллера и по модбас на индикатор ОВЕН SMI2. На индикаторе цифра обновляется секунд на 10-15 позже, чем на экране. Залез посмотреть в SMLogix - и действительно, на входе кубика с переменной число уже несколько раз поменялось, а на выходе появляется секунд 15 спустя.

Всего на модбасе 8 устройств. Из двух читается по 40 слов групповым запросом, в 6 пишется по одному слову. Скорость 19200.
Период для всех переменных 500 мс.
Что за фигня? Искать проблемы в проводах или..?

1 Увеличьте скорость до 115200 бод
2 Увеличьте период до 3 секунд

[Shuric]

Сообщение от СВМ

2 Увеличьте период до 3 секунд

а период почему увеличивать ?

[ailcat]

Сообщение от Shuric

а период почему увеличивать ?

Из-за низкой скорости обмена ваши устройства не успевают вычитываться с задаваемой периодичностью. В итоге из запросов накапливается очередь на их вычитку - потому что следующий запрос будет выполнен только после того, как ответит предыдущий слейв (или не ответит и истечет таймаут, что еще медленнее). И даже может быть, что очередь быстро переполняется и запросы на запись в СМИ2 вообще теряются.
Увеличение скорости и, главное, увеличение периода опросов - позволяют иметь короткую очередь (в идеале - только из выполняющегося в данный момент запроса к слейву), и тем самым обеспечить почти мгновенную реакцию индикатора.

UPD:
Если задержка индикации СМИ2 критичнее частоты опроса датчиков - настройте слейвы на обращение "по запросу", и дергайте их поочередно: Slave1-индикатор-Slave2-индикатор-Slave3-индикатор-... и т.д. При этом частота запросов станет пофигу (хоть 1 мс) - индикатор будет обновлять очень часто, и задержку вы практически не увидите...

[Shuric]

Как-то у меня в голове не склеивается.
Пусть 1 и 2 - устройства, с которых читаем (причём, как я написал, читаем немного), 3-8 - пишем (вообще по одной переменной). Период везде одинаковый и, по логике, контроллер ставит запросы в очередь как-то в том же порядке 1-2-3-4-5-6-7-8-1-2-3-4....Пусть период опроса слишком короткий - начинает копиться очередь.... а потом запросы начинают отбрасываться... ну и пускай отбрасываются. я просто получаю ответы на более старые запросы, но в том же порядке - 1-2-3-...
Зато опрос идёт без перерыва..

Да и вроде передача 40 слов одним групповым запросом даже на скорости 19200 должно занимать совсем небольшое время. Другое дело - если тормозит контроллер, С которого считываем данные - но тогда изменение периода опроса не поможет.

Тогда, наверное, имеет смысл поставить разный период опроса - для устройств 1 и 2 (контроллеры) - побольше, а 3-8 (индикаторы) - на порядок меньше?

Видимо, придётся какой-нибудь сниффер в руки и смотреть, что на шине делается...
Могу отписаться, если удастся это сделать.

[ailcat]

Отпишитесь, конечно.

Я с этим столкнулся, когда распределенную сеть мучал - в итоге перешел к системе К-1-К-2-К-3-...-К-n (где К - критичный слейв, 1...n - менее критичные).
Увеличение периода опросов, сокращение тайм-аутов, увеличение сокрости и т.п. работают только до тех пор, пока все слейвы отвечают сразу и быстро. Стоит одному "замешкаться" (перестать отвечать, сдохнуть, ловить помеху во время передачи) - и всё, запросы начинают копиться как снежный ком; при этом критичный сможет "втиснуться" лишь если попадет в очень узкое окно, когда в очереди уже появится свободное место, но ни у кого из некритичных еще не истечет интервал. А схема с опросом "через один" гарантирует запрос даже если дергать очередной слейв каждый тик...

[СВМ]

Сообщение от Shuric

Могу отписаться, если удастся это сделать.

Отпишитесь, пожалуйста.

[Arsie]

Сообщение от Shuric

Пусть период опроса слишком короткий - начинает копиться очередь.... а потом запросы начинают отбрасываться...

Не отбрасываются. У вас обычная ситуация несбалансированного трафика. Причины расписаны Иликэтом с СВМ-ом верно, способы решения тоже верные.

Тайм-аут подберите правильный, базовый 100 мсек для передачи пары значений непомерно велик.