Modbus.lib портиться команда при таймауте

[Ovtia]

Здравствуйте! Помогите, пожалуйста, разобраться в проблеме.
ПЛК150-220.У.М
Версия таргета: 2.12
Использую библиотеку Modbus.lib для организации Modbus мастера на порту RS-485. Набросал программу на основе примеров с форума. Столкнулся с такой непонятной проблемой: если устройство не успело ответить до таймаута, то следующая Modbus-посылка от мастера будет испорчена: вместо команды от мастера будет выслана часть ответа слейв устройства с прикрепленной к ней чек суммой.
И даже не важно какой ФБ будет вызываться дальше, например: таймаут вышел на блоке MB_RD_HOLD_REGS, а следующим в программе будет запускаться блок MB_WR_REGS, все равно его посылка будет представлять часть предыдущего ответа.
Прикладываю тестовую программу, скриншот программы, скриншот Serial Port Monitor когда проблема возникает и когда нет (если увеличить размер таймаута). В высланной программе проблема проявляется, но вырезано все лишнее и используется только один MB блок.
И еще вопрос, нужно ли делать блоку Enable := FALSE после выполнения? Его наличие или отсутствие никак не влияет на проблему.

[Ovtia]

50ms

Это не опечатка, это сделано, чтобы сымитировать таймаут на короткой линии на тестовом стенде. В реальности в сети будет 4 ПЛК-слейвов и 1 ПР, расстояние м/у каждым метров по сто, читаться с каждого пара десятков регистров и писаться по несколько. В то же время очень важно иметь минимальный таймаут, т.к. часть оборудования может быть выключена. Хотя на объекте я его конечно подниму. Скорее всего на объекте и 15 мс будет мало и тогда я получу ту же проблему? Может быть я как-то неправильно использую Modbus.lib?

нет

Спасибо понял.

[kondor3000]

Это не опечатка, это сделано, чтобы сымитировать таймаут на короткой линии на тестовом стенде. В реальности в сети будет 4 ПЛК-слейвов и 1 ПР, расстояние м/у каждым метров по сто, читаться с каждого пара десятков регистров и писаться по несколько. В то же время очень важно иметь минимальный таймаут, т.к. часть оборудования может быть выключена. Хотя на объекте я его конечно подниму. Скорее всего на объекте и 15 мс будет мало и тогда я получу ту же проблему? Может быть я как-то неправильно использую Modbus.lib?

Вы думаете от 100 метров или 5 метров что-то зависит? Во всех примерах стоит 50 мс, и всё работает даже с тысячами переменных. Тут всё от программиста зависит.

Вот вы пишите 4 ПЛК слейвы и 1 ПР. ПР мастером будет? И какой ПР вы хотите мастером сделать?

[Ovtia]

Вы думаете от 100 метров или 5 метров что-то зависит? Во всех примерах стоит 50 мс, и всё работает даже с тысячами переменных. Тут всё от программиста зависит.

Вот вы пишите 4 ПЛК слейвы и 1 ПР. ПР мастером будет? И какой ПР вы хотите мастером сделать?

Нет, мастером будет именно ПЛК150, на шине еще 4 ПЛК150 и ПР - они слейвы. Их у меня физически нет для тестирования modbus обмена использую МВА8. Здесь я просто демонстрирую проблему с библиотекой Modbus.lib. Я не понимаю, или я упускаю какое-то действие (например очистки буфера), либо с библиотекой какая-то проблема. Неужели это нормально, если ответ пришел вне периода тайм аута, то следующий вызов этого ФБ в библиотеке будет некорректным. Все показано на скриншотах. Дело не в неправильно подобранном периоде тайм аута. Он намеренно выставлен низким, дело в том как обмен рушится, если один из ответов пришел поздно. Если это так и работает, то я просил бы поделиться опытом, как с этим работать, если это зависит только от программиста.

[Ovtia]

если задача стоит в том чтобы со слейвов прочитать пачкой примерно одинаковый набор данных, то лучше создать фиксированный набор байт, повторяющий пакет запроса модбас и слать его в установленное время в порт, а потом разбирать пришедшие данные без всяких библиотек

Возможно, но это сложнее. Хотелось бы воспользоваться библиотекой - проще сделать, проще модифицировать. Неужели никто не сталкивался с такой проблемой, ведь насколько я сужу по форуму, ее достаточно широко исползуют.

[Ovtia]

Начнём с того, что для вашей задачи вообще не нужны библиотеки, освойте сначала конфигурацию. Для ускорения обмена, сгруппируйте подряд регистры.
Разнесите чтение и запись в отдельные UMD (универсал модбас девайс), чтение сделайте циклически, а запись по изменению. Время опроса 10 мс вместо 100.
Ещё для ускорения обмена почитайте пост # 396 petera https://owen.ru/forum/showthread.php?t=22915&page=180
а по поводу опроса МВА8 почитайте тут и мой пост тоже https://owen.ru/forum/showthread.php?t=35094

А по поводу библиотеки, примите за аксиому 50 мс и всё! Что касается ускорения обмена, группировка регистров и чтение циклически, запись по событию. Берёте пример, корректируете регистры и не парьте себе мозг!

Использую библиотеку именно по тому, что не устраивает обмен через конфигурацию: смотрел Serial Port Monitor'ом как работает через конфигурацию: отдельный запрос на каждый регистр - это категорически не устраивает, потому что любой из ПЛК-слейвов может быть отключен, и это не должно сильно влиять на систему в целом, если регистры запрашиваются по одному, то и таймаута ждать от каждого.
Спасибо, советами воспользуюсь, 50 мс не должно быть критично, если для каждого девайса я делаю одну групповую запись и один групповой запрос. Но хотелось бы все-таки услышать мнение по поводу поведения библиотеки modbus.lib.

[Ovtia]

И у меня не опечатка про "dp1MVA8". МВ8A - 50мс. Таймаут - индивидуальная настройка конкретного девайса. Некоторым 0*мс нормуль.
*У меня другое от этой либы трактование таймаута.

Я согласен. Но, учитывая специфику задачи, хотелось бы во-первых выставить таймауты как можно меньшие, а во-вторых таймаут ответа - величина случайная и легко может может изредка превышать даже установленные с большим запасом пределы, и тогда при использовании этой библиотеки мы получаем вот что. Или это я делаю что-то не так. Мне никто так и не может пояснить. А какое у вас трактование таймаута в этой библиотеке?

Либа позволит легко изменить цикличность "обнаруживающих" запросов.

Т.е. я в программе могу по обнаружению ошибки 255 MB блока уменьшить частоту опроса этим блоком? Да это удобно.

Она ведет себя хорошо и моет руки перед едой. Но как-то раз попросил её сходить за пивом. Отвратительно повела себя - пришла без водки.

Поведение программного компонента описана в документации к библиотеке modbus.lib и порождает ожидания своего поведения исходя из входных и выходных данных своих блоков. Увидеть поведение, описанное мной, программист не ожидает.

[Sergey666]

Я согласен. Но, учитывая специфику задачи, хотелось бы во-первых выставить таймауты как можно меньшие, а во-вторых таймаут ответа - величина случайная и легко может может изредка превышать даже установленные с большим запасом пределы, и тогда при использовании этой библиотеки мы получаем вот что. Или это я делаю что-то не так. Мне никто так и не может пояснить.

А что объяснять? Устройство "тормоз" отвечает не немедленно, а...когда сможет, а мастер "резкий" уже следующую команду шлет, вот хрень какая-то и получается на шине.

[Ovtia]

А что объяснять?

Что ожидаете то ?

Объяснить нормально ли такое поведение, как избежать этого, какие практические приемы позволяют избежать такого поведения. Пока я вижу, что ответ сводится к выставлению таймингов с запасом - это очевидный вариант, но неужели никто не копал глубже? Я ожидаю, что при отправке ФБ перезапишет свой буфер ввода-выводы на основе моих данных на своих входах и отправит его в порт, я не ожидаю, что ФБ возьмет кусок (по величине равный корректной команде) запоздалого ответа, рассчитает для него чек сумму и отправит в порт.

Прочитал РЭ на молоток. Согласно ему ожидаю забитые гвозди, но почему-то сильно болит палец. Видимо неправильный молоток.

Или неправильно пользуетесь молотком. Именно так мой вопрос и звучал. Например в РЭ на молоток не было написано, что первые удары по гвоздю нельзя производить с размаха, именно по этому палец и болит. А в общем виде РЭ на молоток правильно описывает процедуру использования, но забыли указать важный нюанс для новичка в забивании гвоздей.

Но либа - отличная, авторам - респект. Хотя я ее не юзаю, есть другие.

А какие еще есть? Не поделитесь вариантами?

[ferret_maybe]

Объяснить нормально ли такое поведение, как избежать этого, какие практические приемы позволяют избежать такого поведения. Пока я вижу, что ответ сводится к выставлению таймингов с запасом - это очевидный вариант, но неужели никто не копал глубже? Я ожидаю, что при отправке ФБ перезапишет свой буфер ввода-выводы на основе моих данных на своих входах и отправит его в порт, я не ожидаю, что ФБ возьмет кусок (по величине равный корректной команде) запоздалого ответа, рассчитает для него чек сумму и отправит в порт.

А чего вы ожидаете от асинхронного обмена в полудуплексном режиме?
Алгоритм простой:
Шаг 1. Открыл порт
Шаг 2. Послал команду запрос и ждешь ответа или конца времени разрешенной работы, если пришел ответ Шаг 3. Если не пришел и прошло время Шаг 4.
Шаг 3. Обработка вашего ответа
Шаг 4. Опрос нового устройства шаги 2 и 3 повторяем для нового (создаем шаги новые) или запуск таймера задержки опросов и шаг 2.

Цикл выполнения программы насколько меньше 5мс?