Диагностика ошибок в ответе Modbus-slave.

[johnny0000]

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

цитата из Википедии
При ошибках второго типа подчинённое устройство отсылает сообщение об ошибке (если запрос адресован этому устройству; на широковещательные запросы ответ не отправляется). Признаком того, что ответ содержит сообщение об ошибке, является установленный старший бит номера функции. За номером функции, вместо обычных данных, следует код ошибки и, при необходимости, дополнительные данные об ошибке.

Есть какая-то возможность отслеживать такие ошибки в CoDeSys v2.3\ПЛК110-60 [М02]???

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

[EFrol]

Можно работать через сокеты - https://ftp.owen.ru/CoDeSys23/10_Soc...ckets_v1.0.pdf
Я юзаю - https://ftp.owen.ru/CoDeSys23/05_Lib...anuals/UNM.pdf
Это все есть здесь - https://owen.ru/product/codesys_v2/documentation

[johnny0000]

Можно работать через сокеты - https://ftp.owen.ru/CoDeSys23/10_Soc...ckets_v1.0.pdf
Я юзаю - https://ftp.owen.ru/CoDeSys23/05_Lib...anuals/UNM.pdf
Это все есть здесь - https://owen.ru/product/codesys_v2/documentation

Спасибо, EFrol, за предоставленную информацию.
А что с асинхронным режимом обмена, не пробовали, можно такое реализовать на ПЛК110-хх?

[EFrol]

В библиотека SysLibSockets.lib работает в блокирующем и неблокирующем режиме - это соответствует синхронному и асинхронному?
UNM - работает с буферами портов (RS232/RS485/Ethernet) - это значит, что она по определению асинхронна ?
Вот пример использования UNM для трансляции ModbusTCP в ModbusRTU и обратно - ModbusTCP <-> ModbusRTU

[johnny0000]

Блокирующий - он же синхронный режим, цикл ПЛК блокируется пока не состоится вся заданная цепочка обмена.
Неблокирующий - он же асинхронный, ПЛК только запускает обмен, все остальное на себя берет операционка, а ПЛК в каждом новом цикле просто проверяет результат обмена.
Я это так понимаю.
В любом случае спасибо, ознакомлюсь пока с документацией, и нужно пробовать.

[johnny0000]

Всем доброго утра!
Началась работа с железом (ПЛК110-60[M-02]), настраиваем\заводим сокеты через syslibsocket.com. Вопросы:
1) почему номер сокета может быть больше 36, вчера отсылал\принимал данные через сокет с номером 652???
2) как правильно задать неблокирующий режим через setopt, присваиваем "0" или "1"???
3) ну и... EmbOS/IP SEGGER, есть ли смысл опираться на работу сокетов этой операционки???????

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

1. это хендл сокета, от может быть любым
2. В примерах всё есть
3. У вас есть описание работы сокетов CoDeSyS, и примеры. ими и пользуйтесь.

[johnny0000]

1. это хендл сокета, от может быть любым
2. В примерах всё есть
3. У вас есть описание работы сокетов CoDeSyS, и примеры. ими и пользуйтесь.

Просто в документе про сокеты была фраза, мол смотрите описание ОС... с этого все и началось, кстати про EmbOS все таки почитал.
Безымянный.jpg

- То есть в случае каких-то проблем просто закрываем сокет, открываем заново, если дескриптор не "-1" пользуемся им и не паримся что там за число... больше 36...больше 6000)???


Кстати... вопрос про изучение EmbOS встал после того как я решил обкатать проект на WinNTv2.4, и как я понимаю там библиотека SysLibSocket работает по другому. Ну это так... отступление лирическое).

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

да, не паримся на число

[johnny0000]

да, не паримся на число

Понимаю вашу иронию, Владислав, звучит конечно не серьезно. Могу предположить что хендел сокета, является указателем на область памяти. Но не об этом... недавно просто видел пост о том, что мол сокет с номером "0" всегда соответствует сокету связанному с ПК на котором крутиться CoDeSys, правда или нет не знаю.
Но вопрос остался, как можно диагностировать канал связи ПЛК с ПК (с CoDeSysHMI.exe например), через программу ПЛК, что бы в случае разрыва например, как-то обрабатывать это событие (например притормозить какой-то механизм)???