Tacio (Все сообщения пользователя)

Каким образом это можно сделать программным способом?

К сожалению на оба ящика писем не получил Возможно ли временно выложить куда-то на ftp://ftp.prosoft.ru/ ?

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

Ещё вопрос. В ФБ SERIAL_COMM_FB в условии

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

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

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

В итоге, хотелось бы, чтобы разработчики FASTWEL внесли данные проверки в код библиотеки, так как они там должны быть хотя бы в рамках протокола MODBUS RTU.

Имеется СРМ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.  

Имеется плата Fastwell CPC307 с ОС КПДА.10964-01 на борту.
В этой системе запускается программа, которая слушает мультикастовые пакеты. Однако эти пакеты до приложения не доходят. Tcpdump, запущенный в этот же момент на этой же системе, их тоже не видит. ifconfig утверждает, что мультикаст поддерживается.
Tcpdump, запущенный на соседней QNX системе (с другим железом), подключённой к этому же коммутатору, эти пакеты видит. Если запускаю данное приложение на другом железе с интеловским адаптером, то всё принимается успешно.

Драйвер взят из bsp-cpc307-qnx650sp1-140.
Запускается след. образом: io-pkt-v4 -dshim "devn-vortex.so speed=100,duplex=1" -pqnet host=cpc307,mount=/net

Как можно решить эту проблему?