Вопрос по MODBUS RTU

При тестировании ПЛК 100 возникла не понятная ситуация. Тестировал MODBUS RTU. Программа простейшая, заключалась в чтении слов (переменные AD0, AD2, AD3, AD4) из устройства по адресам 0, 2, 3, 4 и запись слова прочитанного по адресу 3 в устройство по адресу 1 (AD1:=AD3). После подачи питания на ПЛК все идет «как надо». Т.е. я меняю в эмуляторе устройства (программа Modbus Slave) переменную по адресу 3, после чего соответственно меняется переменная по адресу 1. Для удобства у меня по адресу 0 находится значение 1, по адресу 2 значение 3, по адресу 3 значение 4, по адресу 4 значение 5. Соответственно по адресу 1 у меня значение 4. Через некоторое время у меня в устройство записывается значение которое находится по адресу 4, т.е. переменная AD4. Есть ли этому какое-то объяснение? Думал это происходит после подключения Online из CoDeSys V2.3, но потом выяснилось, что это происходит без CoDeSys. При просмотре данных по обмену, изменяется только 06 функция, т.к. записывает уже значение 5, а не 4. Как смещаются данные в контроллере можно посмотреть в файле. Получается следующее: AD0 не изменяется, в AD1 записывается AD4, в AD2 считывается 4, в AD3 – 5, в AD4 значение по адресу 0.

Увеличьте таймаут ожидания ответа в мастере на ПЛК. ПК тормозит и не успевает ответить за установленное время ожидания ответа.
Более подробно см. http://www.owen.ru/forum/showthread.php?t=942

Я изменял Framing Time на 30, 100, 500 но это ни на что не послияло. Если устанавливаю 1000 нарушается обмен вообще (Last Error 81) и данные скачут как попало. Скажите пожалуйста, интерфейс ждет это время, а потом начинает собирать байты в буфер, или как? Не могли бы вы в кратце рассказать алгоритм приема по RS485. Спасибо.

Мастер посылает запрос и в течении заданного времени ожидания считывает байты, пришедшие в ответ. Из них собирается пачка, к-я анализируется на адрес и CRC и если всё нормально, то обрабатывается уже логически, в соотв. с кодом команды.

С ПК могут быть 2 проблемы:
1. Т.к. Windows не система реального времени, то к примеру свопирование может вызвать задержку ответа.
2. Драйвер Com-порта в Windows/программа ModBus slave не может обеспечить полное соответствие требованиям ModBus RTU, а именно передачу байт в посылке с интервалами не более 1,5 символа. ПЛК в соответствии со стандартом считает такие посылки бракованными и отбрасывает.

Больше 1 сек таймаут ожидания действительно не выставить.
ПК более стабильно работает в режиме ASCII

А сколько стоит значение Max timeout? У меня с ним раньше проблемы были, сейчас ставлю 150 и все устройства нормально работают.

В том то и дело, устройства, а не ПК.
На полуавтоматических преобразователях 232<->485 есть реальная проблема, ПК не успевает переключить направление передачи на преобразователе за время формирования ответа прибором и приходится искуственно вводить задержку на ответ, чтобы комп успел.
При работе с модулями и ПЛК таких проблем нет.

Преобразователь у меня ваш USB/RS485. Сейчас подключил реальное устройство (не комп),пока все нормально. С этим я смотрю поосторожней нужно. Но почему тогда не очищать буфер приемный перед посылкой следующего запроса? Я опрашивал один раз в секунду.

Буфер очищает сам мастер, считывая байты из него непрерывно на макс. скорости.
Преобразователь не причём, я привел пример для демонстрации проблем с реальным временем в Виндовс.
В http://www.owen.ru/forum/showthread.php?t=942 описано как можно бороться со сдвигом данных без увеличения таймаута.

Уточните пожалуйста такую вещь. Последовательность опроса (регистров, устройств...) идет в той последовательности в которой описана в PLC Configuration?

Порядок опроса не фиксированный, а зависит от выставленных для каждой переменной периодов опроса и числа ошибок обмена с переменной.
Мастер старается поддержать (если это позволяет пропускная способность линии связи) заданный темп опроса переменных.
При невозможности этого приоритет получают переменные с меньшим периодом опроса и переменные с типом управления по смене значения/команде, но мастер гарантирует что опросит (пусть и медленнее) все переменные.

Цитата:

---

Сообщение от Филоненко Владислав

По описанному случаю: Рекомендация такова:
Если вы опрашиваете ряд регистров на 1 устройстве, то чтобы избежать "сдвига данных" желательно либо чередовать команды (например 0x03 и 0х04), либо чередовать опросы устройств. В этом случае при задержке ответа мастер по неверному адресу/команде может идентифицировать такую ситуацию и данные не попадут в соседнюю ячейку.

---

Тогда как все это сделать, если мы в принципе не можем ничего указать мастеру, что и когда делать?

Если опрос переменных выставить с одинаковой частотой, то достаточно чередовать команды чтения 0x03 и 0x04.

Цитата:

---

Сообщение от Филоненко Владислав

Мастер посылает запрос и в течении заданного времени ожидания считывает байты, пришедшие в ответ. Из них собирается пачка, к-я анализируется на адрес и CRC и если всё нормально, то обрабатывается уже логически, в соотв. с кодом команды.

С ПК могут быть 2 проблемы:
1. Т.к. Windows не система реального времени, то к примеру свопирование может вызвать задержку ответа.
2. Драйвер Com-порта в Windows/программа ModBus slave не может обеспечить полное соответствие требованиям ModBus RTU, а именно передачу байт в посылке с интервалами не более 1,5 символа. ПЛК в соответствии со стандартом считает такие посылки бракованными и отбрасывает.

Больше 1 сек таймаут ожидания действительно не выставить.
ПК более стабильно работает в режиме ASCII

---

И как с этим бороться, у меня при опросе все время выдает 51 ошибку, пробовола увеличивать и уменьшать таймаут ошибка остается.

Цитата:

---

Сообщение от Филоненко Владислав

Если опрос переменных выставить с одинаковой частотой, то достаточно чередовать команды чтения 0x03 и 0x04.

---

Может это и не плохо, когда есть что читать разными функциями.:(

1. А почему нет? ModBusSlave не поддерживает?
2. Как я понял, на реальном объекте проблемы нет?

Конечно ModBusSlave поддерживает, но это же для тестов. Я к тому, что не всегда в реальном устройстве есть что считывать разными функциями. К сожалению у меня под руками сейчас нету реального устройства, которое не отличалась "резвостью" ответа. Причем это было устройство не сделаное "на коленях", а известного производителя и не имело возможности настройки разного рода таймаутов. Хотя может быть и все было бы с ним нормально.
С устройством, которое я сейчас нашел под рукой пока все нормально. Ура, как говорится! :)