Вопрос по MODBUS RTU

Цитата:

---

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

По описанному случаю: Рекомендация такова:
Если вы опрашиваете ряд регистров на 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 поддерживает, но это же для тестов. Я к тому, что не всегда в реальном устройстве есть что считывать разными функциями. К сожалению у меня под руками сейчас нету реального устройства, которое не отличалась "резвостью" ответа. Причем это было устройство не сделаное "на коленях", а известного производителя и не имело возможности настройки разного рода таймаутов. Хотя может быть и все было бы с ним нормально.
С устройством, которое я сейчас нашел под рукой пока все нормально. Ура, как говорится! :)