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

[johnny0000]

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

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

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

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

[johnny0000]

Добрый день, capzap.
Да, ПЛК выступает в роли мастера сети, настройка сети через Ресурсы->Конфигурация ПЛК, добавлен модуль Modbus (master).
В документации про LastError говорится следующее:
66080
На сколько я понимаю эта переменная говорит нам о том что связь состоялась или нет в целом (что кабель цел/что помех нет/что у ПЛК хватило сил провести опрос и т.д.).
Меня же интересует тот случай, когда состоялся обмен мастер - слейв и слейв устройство в своем ответе на запрос указывает не запрошенные данные, а ошибку которая у него произошла. Эта процедура описана в стандарте. Датчик который я завожу в проект поддерживает эту процедуру, но обработать я ее нормально пока не могу.

[Cs-Cs]

Меня же интересует тот случай, когда состоялся обмен мастер - слейв и слейв устройство в своем ответе на запрос указывает не запрошенные данные, а ошибку которая у него произошла. Эта процедура описана в стандарте. Датчик который я завожу в проект поддерживает эту процедуру, но обработать я ее нормально пока не могу.
Неа! Обработка таких ошибок штатно в этой среде НЕ поддерживается.
Если нужна настолько глубокая диагностика - то придётся писать обмен самому, используя библиотеку OWEN Modbus.

[johnny0000]

Спасибо за ответ, Cs-Cs.
Обмен с датчиками происходит по Modbus TCP, соответственно для нужной мне (детальной) диагностики, придется работать с так называемыми "сокетами". Я правильно понимаю?
И еще вопрос в догонку, к знающим специалистам, возможно опрашивать по Modbus TCP в асинхронном режиме? Есть такие функции для ПЛК110-хх??

[EFrol]

Можно работать через сокеты - https://ftp.owen.ru/CoDeSys23/10_Sockets/CDSv2.3_Sockets_v1.0.pdf
Я юзаю - https://ftp.owen.ru/CoDeSys23/05_Library/01_Manuals/UNM.pdf
Это все есть здесь - https://owen.ru/product/codesys_v2/documentation

[johnny0000]

Можно работать через сокеты - https://ftp.owen.ru/CoDeSys23/10_Sockets/CDSv2.3_Sockets_v1.0.pdf
Я юзаю - https://ftp.owen.ru/CoDeSys23/05_Library/01_Manuals/UNM.pdf
Это все есть здесь - https://owen.ru/product/codesys_v2/documentation

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

[EFrol]

В библиотека SysLibSockets.lib работает в блокирующем и неблокирующем режиме - это соответствует синхронному и асинхронному?
UNM - работает с буферами портов (RS232/RS485/Ethernet) - это значит, что она по определению асинхронна ?
Вот пример использования UNM для трансляции ModbusTCP в ModbusRTU и обратно - ModbusTCP <-> ModbusRTU (https://owen.ru/forum/showthread.php?t=36702&page=4&highlight=%EC%E0%F0%F8%F0%F3%F2%ED%EE%E9+%F0%E5%F2 %F0%E0%ED%F1%EB%FF%F6%E8%E8)

[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 все таки почитал.
67303

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


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

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

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

[johnny0000]

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

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

[johnny0000]

По вопросу темы, задача решена. Полноценная диагностика слейв (ModbusTCP) устройств решена путем поднятия сокетов. На ПЛК крутится 4-е сокета, скорость опроса достаточная.
Так же, кому интересно, по вопросу контроля связи ПЛК<->ПК, открыл другую тему:
https://owen.ru/forum/showthread.php?t=37803