ПЛК73 MODBUS MASTER удерживает линию после передачи

[shemanin]

Здравствуйте, уважаемые коллеги.

При работе ПЛК73 в режиме мастера, с помощью библиотеки Modbus.lib ПЛК удерживает шину после передачи сообщения. Время удержания зависит от скорости.
Возникают ситуации, когда подчиненный отвечает раньше чем ПЛК отпустит шину, это происходит, например с датчики Пьезоэлектрик, и датчиком температуры и влажности Autonics THD.

На осциллограммах изображено:
1. Подчиненный ответил после отпускания шины, время удержания шины мастером выделено;
2. Подчиненный ответил в момент отпускания шины, возможно сообщение будет принято;
3. Подчиненный ответил раньше момента отпускания шины, сообщение будет утеряно.

Как можно убрать эти моменты удержания? Ковырял библиотеку Modbus.lib, ничего не нашел. Снифил в слейв режиме ПЛК через конфигуратор. Эти удержания тоже присутствуют.

[Филоненко Владислав]

Если slave отвечает раньше чем мастер отпустит шину (а это даже меньше 1 мс), это значит, что slave реализован не по стандарту ModBus RTU и не дожидаясь стандартной паузы в 3,5 символа (но не менее 1 мс) начинает передавать.
К сожалению, тут ничего сделать нельзя.

[Вольд]

Здравствуйте, уважаемые коллеги.

При работе ПЛК73 в режиме мастера, с помощью библиотеки Modbus.lib ПЛК удерживает шину после передачи сообщения. Время удержания зависит от скорости.
Возникают ситуации, когда подчиненный отвечает раньше чем ПЛК отпустит шину, это происходит, например с датчики Пьезоэлектрик, и датчиком температуры и влажности Autonics THD.

На осциллограммах изображено:
1. Подчиненный ответил после отпускания шины, время удержания шины мастером выделено;
2. Подчиненный ответил в момент отпускания шины, возможно сообщение будет принято;
3. Подчиненный ответил раньше момента отпускания шины, сообщение будет утеряно.

Как можно убрать эти моменты удержания? Ковырял библиотеку Modbus.lib, ничего не нашел. Снифил в слейв режиме ПЛК через конфигуратор. Эти удержания тоже присутствуют.
Slave после приема пакета от Master должен сразу захватить шину и выдержать паузу перед тем как начать передачу пакета отклика. Пауза должна быть не менее той, что указана в стандарте протокола. То что Master после передачи пакета сразу не отпускает шину - это правильно.
Вывод: Master работает правильно, а ваш Slave - не правильно.

[rwg]

Slave после приема пакета от Master должен сразу захватить шину и выдержать паузу перед тем как начать передачу пакета отклика. Пауза должна быть не менее той, что указана в стандарте протокола. То что Master после передачи пакета сразу не отпускает шину - это правильно. Вывод: Master работает правильно, а ваш Slave - не правильно.
Нигде не написано, что Master удерживать шину. Если бы Мастер не удерживал шину всё могло бы заработать даже при таких таймаутах. Так что виноваты оба. Про то, что "Slave после приема пакета от Master должен сразу захватить шину" - скорей всего опечатка. А минимальный таймаут от конца запроса до начала ответа, к моему огромному сожалению, 1,75 мсек. Что было вполне оправдано 50 лет назад но никак не оправдано сейчас. Если убрать это ограничение, протокол мог бы стать намного шустрее.

[Yegor]

Нигде не написано, что Master удерживать шину.MODBUS over Serial Line (http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf)
2.5.1.1 <...> In RTU mode, message frames are separated by a silent interval of at least 3.5 character times. In the following sections, this timeinterval is called t3,5.

[rwg]

MODBUS over Serial Line 2.5.1.1. (http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf)

Это про время переключения с передачи на приём, про немой интервал, когда все отключены, шина свободна, её удерживает только растяжка из резисторов по питанию. В это время мастер может остаться активным, если у него тормозной драйвер. А где про то, что он должен оставаться в активном состоянии и удерживать шину?

[Вольд]

Нигде не написано, что Master удерживать шину. Если бы Мастер не удерживал шину всё могло бы заработать даже при таких таймаутах. Так что виноваты оба. Про то, что "Slave после приема пакета от Master должен сразу захватить шину" - скорей всего опечатка. А минимальный таймаут от конца запроса до начала ответа, к моему огромному сожалению, 1,75 мсек. Что было вполне оправдано 50 лет назад но никак не оправдано сейчас. Если убрать это ограничение, протокол мог бы стать намного шустрее.
Ты никогда не делал сетевой драйвер для последовательного порта.

[spectrum48k]

Ты никогда не делал сетевой драйвер для последовательного порта.

предлагаю не бряцать опытом, а технически обосновать

[Филоненко Владислав]

Технически, между моментом окончания передачи и переключением линии всегда есть пауза, т.к. процессору есть ещё чем заняться.
Грамотная поддержка режима 485 в процессорах встречается редко, приходится различными программными путями её эмулировать. Вот и пауза.
Более того, даже если убрать задержку, ПЛК всё равно не будет реагировать на ответ, т.к. он не по стандарту и считается битым.

[Bleak]

В версии прошивки 15 мастер вообще не отпускает линию. Придется делать промежуточный "тормоз" между повелителем и рабом. Раб Vacon20 не имеет настройки "задержка времени ответа".

[Филоненко Владислав]

В версии прошивки 15 мастер вообще не отпускает линию. Придется делать промежуточный "тормоз" между повелителем и рабом. Раб Vacon20 не имеет настройки "задержка времени ответа".
На сколько задержку? ПЛК по стандарту держит до 4 символов линию в передаче (и это соответствует стандарту).
А если slave сразу начинает передавать - это неправильно.

[Вольд]

В версии прошивки 15 мастер вообще не отпускает линию.

Сказки рассказывать не надо. ;) Как же тогда Master принимает от Slave ?


Раб Vacon20 не имеет настройки "задержка времени ответа".

Зачем нужна настройка задержки времени ответа если на то есть стандарт ?

[slonegd]

Наткнулся на проблему удержания линии. Разрабатываю собственное устройство с управлением по модбасу. Паузу 3,5 держу. ПЛК держит шину немного больше 3,5 слов. Не беда, я увеличил время паузы и эта проблема решена, хотя не ясно чего ПЛК вообще его держит. С СПК например такого не наблюдается.
Появилась вторая проблема. Бывает пропадает байт в середине пакета (и на СПК тоже). В терминале на компе байт есть, в буфере функционального блока нет. Решилось добавлением небольших пауз между словами. Неужели так сложно забрать байт из регистра микроконтроллера сразу, как он пришёл?
Ну и на последок, последний байт пакета никогда не появляется в буфере функционального блока библиотеки модбас, но всегда появляется первым байтом следующего запроса. То есть железо приняло этот байт, но не кинуло в буфер. Тут мне что ли надо шину держать или паузу какую выставлять?
При этом работа с модулями МВ безукоризнена. Может кто-нибудь подскажет как они этого добились?