NIM741 клиент MOBUS

NIM741 клиент MOBUS

Поиск  Правила  Войти
Форумы технической поддержки » Поддержка и обсуждение продукции » FASTWEL I/O
Страницы: 1 2 След.
RSS
NIM741 клиент MOBUS
 
#1
0
03.08.2018 09:29:30
Имеется СРМ712 с модулем NIM741. Настраиваю на нём клиента MODBUS c помощью библиотеки FastwelModbusRTUClientSerial.lib. Код настройки взял из примера fw_modbus_client_test.pro. Для непосредственного опроса сервера использую ModbusClient.
В задачи клиента входит только чтение с сервера трёх блоков данных (массив из трёх элементов MODBUS_ITEM_DESCRIPTOR).
Вопрос следующий. Каким образом можно понять, что связь с сервером прервалась? Анализируя поле status объекта MODBUS_ITEM_DESCRIPTOR в течение заданного промежутся времени? Однако, если искусственно оборвать физическое подключение между клиентом и сервером, то например статус первого элемента MODBUS_ITEM_DESCRIPTOR будет MBC_OPERATION_STATUS_PROCESSING, в время как у оставшихся двух он будет MBC_OPERATION_STATUS_OK. Как это можно интерпретировать? Тоже самое будет, если включить контроллер с уже оборванным физическим соединением, хотя в этом случае я жду, что поля всех MODBUS_ITEM_DESCRIPTOR будут иметь значение отличное от MBC_OPERATION_STATUS_OK.  
 
 
 
#2
0
03.08.2018 11:19:30
Цитата
Имеется СРМ712 с модулем NIM741. Настраиваю на нём клиента MODBUS c помощью библиотеки FastwelModbusRTUClientSerial.lib. Код настройки взял из примера fw_modbus_client_test.pro. Для непосредственного опроса сервера использую ModbusClient.
В задачи клиента входит только чтение с сервера трёх блоков данных (массив из трёх элементов MODBUS_ITEM_DESCRIPTOR).
Вопрос следующий. Каким образом можно понять, что связь с сервером прервалась? Анализируя поле status объекта MODBUS_ITEM_DESCRIPTOR в течение заданного промежутся времени? Однако, если искусственно оборвать физическое подключение между клиентом и сервером, то например статус первого элемента MODBUS_ITEM_DESCRIPTOR будет MBC_OPERATION_STATUS_PROCESSING, в время как у оставшихся двух он будет MBC_OPERATION_STATUS_OK. Как это можно интерпретировать? Тоже самое будет, если включить контроллер с уже оборванным физическим соединением, хотя в этом случае я жду, что поля всех MODBUS_ITEM_DESCRIPTOR будут иметь значение отличное от MBC_OPERATION_STATUS_OK.  

Добрый день,

Насколько я понимаю, Вы хотите иметь информацию о том, есть ли связь с конкретным подчиненным узлом (сервером)?
В функциональном блоке MODBUS_CLIENT_SERIAL есть выходной массив SlavesDiag (ARRAY [1..247]), где номер элемента массива соответствует адресу подчиненного узла. Данный массив как раз отображает состояние связи с каждым подчиненным узлом.



В коде примера fw_modbus_client_test.pro есть строчка условия:
IF ModbusClient.SlavesDiag[ModbusItemArray[0].RemoteAddr].iState = MB_SLAVE_CONNECTED THEN

Она как раз определяет есть ли связь с узлом под номером 0(MB_SLAVE_CONNECTED).
Описание возможных состояний подчиненного узла заданы в структуре MODBUS_REMOTE_NODE_STATE.
 
 
 
#3
0
24.09.2021 12:21:41
Не стану создавать новую тему. Есть несколько замечаний по работе с библиотекой FastwelModbusRTUClientSerial.lib версии от 10.08.2021. Исходные данные те же: СРМ712 с модулем NIM741.
1. В ФБ MODBUS_CLIENT_SERIAL в коде проверки результата обмена нет проверки на адрес узла источника ответа.
2. Там же: нет проверки на кол-во байт регистров в ответе. То есть, один раз запомнили требуемое кол-во регистров и далее предполагается, что ответ будет содержать это кол-во.
3. При получении ответа от сервера с другим адресом узла не трактовать это как ошибку, а игнорировать это сообщение и продолжать приём данных в рамка заданного таймаута с учётом уже прошедшего времени с начала приёма.

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

В итоге, хотелось бы, чтобы разработчики FASTWEL внесли данные проверки в код библиотеки, так как они там должны быть хотя бы в рамках протокола MODBUS RTU.
 
 
 
#4
0
25.09.2021 12:54:48
Ещё вопрос. В ФБ SERIAL_COMM_FB в условии
Код
ELSIF state = MBCS_RECEIVING THEN

приём продолжается даже если пользовательский буфер уже заполнен до тех пор пока не дождёмся конца интервала тишины. В этом есть какой-то смысл?  
 
 
 
#5
0
28.09.2021 07:39:39
Цитата

Не стану создавать новую тему. Есть несколько замечаний по работе с библиотекой FastwelModbusRTUClientSerial.lib версии от 10.08.2021. Исходные данные те же: СРМ712 с модулем NIM741.
1. В ФБ MODBUS_CLIENT_SERIAL в коде проверки результата обмена нет проверки на адрес узла источника ответа.
2. Там же: нет проверки на кол-во байт регистров в ответе. То есть, один раз запомнили требуемое кол-во регистров и далее предполагается, что ответ будет содержать это кол-во.
3. При получении ответа от сервера с другим адресом узла не трактовать это как ошибку, а игнорировать это сообщение и продолжать приём данных в рамка заданного таймаута с учётом уже прошедшего времени с начала приёма.

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

В итоге, хотелось бы, чтобы разработчики FASTWEL внесли данные проверки в код библиотеки, так как они там должны быть хотя бы в рамках протокола MODBUS RTU.
Ещё вопрос. В ФБ SERIAL_COMM_FB в условии
Код
ELSIF state = MBCS_RECEIVING THEN

приём продолжается даже если пользовательский буфер уже заполнен до тех пор пока не дождёмся конца интервала тишины. В этом есть какой-то смысл?

Большое спасибо за детальный анализ исходного кода библиотеки FastwelModbusRTUClientSerial.lib, изначальный замысел которой состоял в том, чтобы быть полезным примером программирования FastwelSysLibCom.lib на Structured Text. Последний выпуск библиотеки состоялся в ноябре 2017 г. в пакете адаптации CoDeSys 2.3 для Fastwel I/O версии 2.71.23955 – была добавлена диагностика обмена с подчиненными узлами. В ближайшее время обновлений пакета адаптации CoDeSys 2.3 для Fastwel I/O не планируется, однако библиотека поставляется с открытым исходным кодом, поэтому Вы можете либо самостоятельно внести изменения, необходимые для работы двух мастеров (что Вы и сделали), либо извлечь код из библиотеки методом экспорта (все программные единицы и типы данных), импортировать в свой проект и доработать требуемым образом, чтобы не зависеть от FastwelModbusRTUClientSerial.lib.

Ожидание интервала тишины при state = MBCS_RECEIVING в случае заполненности буфера делается по причине того, что в стандарте "MODBUS over Serial Line. Specification and Implementation Guide V1.02, Clause 2.5.1.1" допускается передавать следующий запрос в линию не ранее истечения длительности передачи 3,5 символов. Однако практически при работе на скорости обмена 38400 бит/с и выше это действительно не имеет смысла, т.к. пауза до следующего запроса появится сама по себе за счет периода циклической задачи.
 
 
 
#6
0
30.09.2021 08:44:39
А можно ли в таком случае попросить у вас исходники библиотеки FastwelModbusServer?
 
 
 
#7
0
30.09.2021 12:49:26
Цитата
А можно ли в таком случае попросить у вас исходники библиотеки FastwelModbusServer?
Ответ будет по электронной почте на gmail
 
 
 
#8
0
30.09.2021 13:31:03
К сожалению на оба ящика писем не получил :( Возможно ли временно выложить куда-то на ftp://ftp.prosoft.ru/ ?
 
 
 
#9
0
30.09.2021 15:46:16
+ Еще попытка отправки на gmail. Видимо, дело в расширении - почта блокирует.
 
 
 
#10
0
15.02.2024 06:46:39
Доброго дня.
Где найти пример fw_modbus_client_test.pro??
 
 
 
Страницы: 1 2 След.
Читают тему
Российская электроника
для ответственных применений
Корзина
Задать вопрос