Аппаратное обеспечение Modbus RTU в полевых условиях с неправильной задержкой ответа

У нас есть оборудование, которое обменивается данными на различных скоростях передачи через RS-485 / Modbus RTU (от 1200, 9600 до 115200).

В прошивке, работающей на нашем устройстве, есть небольшая ошибка, в которой задержка ответа Modbus RTU была исправлена ​​и рассчитана на основе работы на скорости 115200 бод. Проблема оставалась незамеченной до недавнего времени, когда один из наших клиентов начал использовать скорость передачи данных 1200 бод. Похоже, задержки ответа 115200 было достаточно для всего, вплоть до 9600.

Однако при скорости передачи 1200 бод первый байт ответного пакета пропускается (я предполагаю, что из-за времени, которое требуется для переключения с отправки на прием на скорости 1200 бод). Если запрашивается большой пакет, все в порядке (поскольку время, необходимое устройству для объединения пакета, компенсирует отсутствие задержки), хотя большинство пакетов повреждены.

К сожалению, обновление прошивки на этих устройствах уже в полевых условиях для использования правильной / более продолжительной задержки ответа не является вариантом. Есть ли у кого-нибудь идеи относительно того, как мы можем получить полные пакеты на скорости 1200 бод? (с неправильной задержкой ответа, из-за которой в настоящее время пропущен 1 байт)

Единственная идея, которую я мог придумать, - это запрашивать чрезмерное количество регистров у программного обеспечения с каждым запросом, чтобы увеличить задержку.


serial-port rs485 modbus
person Belgin Fish    schedule 26.06.2020    source источник
comment
Предположительно ваше оборудование в поле - это ведомые устройства? В спецификации Modbus ничего не говорится о минимальной задержке ответа . Вы имеете в виду задержку в 3,5 символа между допустимыми кадрами сообщения RTU?   -  person sawdust    schedule 27.06.2020

Ответы (1)


arrow_upward
1
arrow_downward

Если я правильно понимаю ваш вопрос, у меня однажды была такая же проблема.

Меня вызвали для устранения очень ненадежной связи Modbus, которая довольно часто выходила из строя, но в течение коротких периодов времени она работала нормально.

После проверки всех других очевидных параметров я подключил свой прицел и увидел следующее: Scope Capture Modbus collision

Как выяснилось, возникла проблема с прошивкой на ведомом устройстве: он запускал свой ответ Modbus сразу после получения стопового бита запроса. Таким образом, часть ответа была передана до того, как мастер успел освободить автобус (желтая стрелка на картинке).

В то время нас не устраивала перспектива обновления прошивки на мази, поэтому мы сначала изучили другие варианты. Лучшее, что мы придумали, - это настройка мастера (ПЛК от Schneider Electric), которая позволяла настраивать время, в течение которого шина была подтверждена мастером после ее стопового бита.

Вот как это было определено в руководстве / а>:

Руководство по ПЛК

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

Как-то связанное с вашим вопросом, я однажды измерил время, необходимое для освобождения шины, используя аппаратное управление направлением по сравнению с программным решением. Вы можете увидеть некоторые подробности здесь. Если обновление прошивки вам не подходит, я думаю, что возиться с трансивером тоже не получится ... В конце этого question Я подключил схему для автоматического переключения линии управления направлением связи RS485. Это может быть (по общему признанию ужасным) решением, если ваш Мастер не может переключаться быстрее.

person Marcos G.    schedule 28.06.2020