YetAnotherForum
Добро пожаловать, Гость Активные темы | Вход | Регистрация

NIM741 клиент MOBUS
Tacio Offline
#1 Оставлено : 3 августа 2018 г. 12:29:30(UTC)

Новый пользователь

Сообщений: 6
Город:: Зеленоград

Имеется СРМ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.
FIO_Support Offline
#2 Оставлено : 3 августа 2018 г. 14:19:30(UTC)

Техническая поддержка

Сообщений: 7
Город:: Moscow

Tacio написал:
Имеется СРМ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.

Tacio Offline
#3 Оставлено : 24 сентября 2021 г. 15:21:41(UTC)

Новый пользователь

Сообщений: 6
Город:: Зеленоград

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

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

В итоге, хотелось бы, чтобы разработчики FASTWEL внесли данные проверки в код библиотеки, так как они там должны быть хотя бы в рамках протокола MODBUS RTU.
Tacio Offline
#4 Оставлено : 25 сентября 2021 г. 15:54:48(UTC)

Новый пользователь

Сообщений: 6
Город:: Зеленоград

Ещё вопрос. В ФБ SERIAL_COMM_FB в условии
Код:
ELSIF state = MBCS_RECEIVING THEN

приём продолжается даже если пользовательский буфер уже заполнен до тех пор пока не дождёмся конца интервала тишины. В этом есть какой-то смысл?
FIO_Support Offline
#5 Оставлено : 28 сентября 2021 г. 10:39:39(UTC)

Техническая поддержка

Сообщений: 7
Город:: Moscow

Tacio написал:

Не стану создавать новую тему. Есть несколько замечаний по работе с библиотекой 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 бит/с и выше это действительно не имеет смысла, т.к. пауза до следующего запроса появится сама по себе за счет периода циклической задачи.
Tacio Offline
#6 Оставлено : 30 сентября 2021 г. 11:44:39(UTC)

Новый пользователь

Сообщений: 6
Город:: Зеленоград

А можно ли в таком случае попросить у вас исходники библиотеки FastwelModbusServer?
FIO_Support Offline
#7 Оставлено : 30 сентября 2021 г. 15:49:26(UTC)

Техническая поддержка

Сообщений: 7
Город:: Moscow

Tacio написал:
А можно ли в таком случае попросить у вас исходники библиотеки FastwelModbusServer?

Ответ будет по электронной почте на gmail
Tacio Offline
#8 Оставлено : 30 сентября 2021 г. 16:31:03(UTC)

Новый пользователь

Сообщений: 6
Город:: Зеленоград

К сожалению на оба ящика писем не получил :( Возможно ли временно выложить куда-то на ftp://ftp.prosoft.ru/ ?
FIO_Support Offline
#9 Оставлено : 30 сентября 2021 г. 18:46:16(UTC)

Техническая поддержка

Сообщений: 7
Город:: Moscow

+ Еще попытка отправки на gmail. Видимо, дело в расширении - почта блокирует.
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.