CODESYS V3.5. Настройка обмена с другими устройствами (Modbus, ОВЕН, OPC и др.)

[Денис Сухарев]

Добрый день.
Спасибо за подсказку, действительно дело было в формате сигнала. Изменил на (Float32 + time) и всё заработало.

Прибор СПК-107 внедряется в существующую систему опроса, где уже используется протокол Owen, по этому без вариантов.
СПК-107 должен сидеть на шине в роли шпиона (Spy), активный опрос реализуется в качестве запасного варианта.

Теперь возникла новая проблема, с подключением прибора СПК-107 в сеть Lan.
При подключении к роутеру RT-GE-5 прибор не определяется и не пингуется.
При этом роутер показывает активный линк порта и даже какой то объём обмена пакетами, но в таблице маршрутизации прибор не появляется. Не помогла даже жёсткая привязка МАК адреса к IP 192.168.0.10.
Опробованы и режим DHCP и статика с учётом подсети LAN роутера (шлюз 192.168.0.1).
При прямом подключении к компьютеру патчкордом crossover связь появляется, но не сразу после подключения кабеля, а после отключения и повторного включения соединения в системе на компьютере.
Прибор планируется подключить к облаку OwenCloud.
С чем могут быть связаны данные проблемы?

[Евгений Кислов]

Добрый день.

а после отключения и повторного включения соединения в системе на компьютере.

Что именно вы под этим подразумеваете? Можете показать скриншотами?

Мы не наблюдали подобных проблем, но что касается роутеров - RT-GE-5 мы не использовали.

[Денис Сухарев]

Спасибо, разобрался.
Дело было в настройках роутера.
Вопрос закрыт.

[knoppix]

Добрый день, возникла такая проблема, есть 30 устройств опрашиваемых через преобразователь МКОН (ПЛК - (MODBUS TCP) - МКОН - (MODBUS RTU) - полевые устройства), опрос идет через библиотеку OwenCommunication Library 3.5.11.6. Пока все устройства в сети проблем никаких нет, все опрашивается, пишется и читается, объем данных небольшой (4 HR), таймаут выставлен на 500мс, настройки таймингов в МКОН пробовал или по-умолчанию (задержка между пакетами - 5мс, время ожидания ответа 300мс) или увеличивал на порядок до 50мс и 3000мс. Скорость опроса по линии RTU 9600, 1STOP, Четность.

Суть проблемы, как только в линии одну из устройств перестает отвечать, падает вся линия, блок OCL.TCP_Client не показывает никаких ошибок, блок OCL.MB_TcpRequest выдает SLAVE_DEVICE_FAILURE. При этом в сниффере МКОН видно как идет опрос линии. Если вернуть выпавшее устройство в строй, то после переинициализации OCL.TCP_Client (сброс и установка xEnable) ошибка пропадает и опрос снова идет корректно. В каком направлении искать ошибку?

[Евгений Кислов]

Добрый день.

Суть проблемы, как только в линии одну из устройств перестает отвечать, падает вся линия, блок OCL.TCP_Client не показывает никаких ошибок, блок OCL.MB_TcpRequest выдает SLAVE_DEVICE_FAILURE. При этом в сниффере МКОН видно как идет опрос линии. Если вернуть выпавшее устройство в строй, то после переинициализации OCL.TCP_Client (сброс и установка xEnable) ошибка пропадает и опрос снова идет корректно. В каком направлении искать ошибку?

Выложите, пожалуйста, простейший проект с опросом двух слэйвов через МКОН, на котором я смогу воспроизвести проблему (чтобы при физическом отключении одного слэйва опрос второго прекращался).

[СергейНовосиб]

Добрый день!

Делаю опрос счетчика Энергомера СЕ301 R33 146JAZ. Проверял на двух счетчиках, один на столе, второй в действующем шкафу.
Взял пример опроса, загрузил в СПК1хх 3.5.14 и все работает. Данные читает.
Далее внедряю проверенные блоки проекта в существующий проект и получаю нестабильное чтение данных с чтением то нулевых значений то реальных, причем с интервалом от 3 до 7 циклов (цикл опроса пока 5сек, делал разные). Ошибок блок "OVP.Energomera_IEC" никаких не выдает. Из проекта удаляю ВСЁ и оставляю только опрос счетчика. Ситуация с опросом не изменилась. При этом почему то файл проекта практически не уменьшился.
Далее перенес все на CS 3.5.17. Здесь вообще блок "OVP.Energomera_IEC" выдает ошибку "Time_out" и данных нет.
Не могу понять в чем дело!

Версия библиотеки 3.5.14.9.

[Евгений Кислов]

Добрый день!

Делаю опрос счетчика Энергомера СЕ301 R33 146JAZ. Проверял на двух счетчиках, один на столе, второй в действующем шкафу.
Взял пример опроса, загрузил в СПК1хх 3.5.14 и все работает. Данные читает.
Далее внедряю проверенные блоки проекта в существующий проект и получаю нестабильное чтение данных с чтением то нулевых значений то реальных, причем с интервалом от 3 до 7 циклов (цикл опроса пока 5сек, делал разные). Ошибок блок "OVP.Energomera_IEC" никаких не выдает. Из проекта удаляю ВСЁ и оставляю только опрос счетчика. Ситуация с опросом не изменилась. При этом почему то файл проекта практически не уменьшился.
Далее перенес все на CS 3.5.17. Здесь вообще блок "OVP.Energomera_IEC" выдает ошибку "Time_out" и данных нет.
Не могу понять в чем дело!

Версия библиотеки 3.5.14.9.

Добрый день.
Обеспечьте, пожалуйста, удаленный доступ к ПК, с которого можно будет подключиться к СПК (3.5.17), который опрашивает счетчик.
Все нужные данные присылайте на почту.

[Tacio]

Добрый день, возникла такая проблема, есть 30 устройств опрашиваемых через преобразователь МКОН (ПЛК - (MODBUS TCP) - МКОН - (MODBUS RTU) - полевые устройства), опрос идет через библиотеку OwenCommunication Library 3.5.11.6. Пока все устройства в сети проблем никаких нет, все опрашивается, пишется и читается, объем данных небольшой (4 HR), таймаут выставлен на 500мс, настройки таймингов в МКОН пробовал или по-умолчанию (задержка между пакетами - 5мс, время ожидания ответа 300мс) или увеличивал на порядок до 50мс и 3000мс. Скорость опроса по линии RTU 9600, 1STOP, Четность.

Суть проблемы, как только в линии одну из устройств перестает отвечать, падает вся линия, блок OCL.TCP_Client не показывает никаких ошибок, блок OCL.MB_TcpRequest выдает SLAVE_DEVICE_FAILURE. При этом в сниффере МКОН видно как идет опрос линии. Если вернуть выпавшее устройство в строй, то после переинициализации OCL.TCP_Client (сброс и установка xEnable) ошибка пропадает и опрос снова идет корректно. В каком направлении искать ошибку?

Почти подобная проблема. К ПЛК210 по Rs485 подключено 8 устройств (такие же ПЛК210). В настройках мастера response timeout установлен в 50мс, в настройках каждого слейва также указано 50мс. Для каждого слейва указано 2 канала: чтение регистров и запись регистров. Когда в сети нет ни одного слейва я ожидаю, что один цикл опроса всех слейвов займёт 8*50мс для запросов на чтение + 8*50 для запросов на запись. В сумме 800мс, пусть будет 1с. Однако, если вклиниться в линию и посмотреть реальный тайминг, то видно, что цикл занимает примерно 12с, а между отдельными запросами примерно 560мс.
Где в моих рассуждения или настройках ошибка? Для работы по Modbus использую стандартные средства Codesys.

[Евгений Кислов]

Почти подобная проблема. К ПЛК210 по Rs485 подключено 8 устройств (такие же ПЛК210). В настройках мастера response timeout установлен в 50мс, в настройках каждого слейва также указано 50мс. Для каждого слейва указано 2 канала: чтение регистров и запись регистров. Когда в сети нет ни одного слейва я ожидаю, что один цикл опроса всех слейвов займёт 8*50мс для запросов на чтение + 8*50 для запросов на запись. В сумме 800мс, пусть будет 1с. Однако, если вклиниться в линию и посмотреть реальный тайминг, то видно, что цикл занимает примерно 12с, а между отдельными запросами примерно 560мс.
Где в моих рассуждения или настройках ошибка? Для работы по Modbus использую стандартные средства Codesys.

Выложите, пожалуйста, простейший проект, на котором вы проверяете эту ситуацию.

[Tacio]

Почти подобная проблема. К ПЛК210 по Rs485 подключено 8 устройств (такие же ПЛК210). В настройках мастера response timeout установлен в 50мс, в настройках каждого слейва также указано 50мс. Для каждого слейва указано 2 канала: чтение регистров и запись регистров. Когда в сети нет ни одного слейва я ожидаю, что один цикл опроса всех слейвов займёт 8*50мс для запросов на чтение + 8*50 для запросов на запись. В сумме 800мс, пусть будет 1с. Однако, если вклиниться в линию и посмотреть реальный тайминг, то видно, что цикл занимает примерно 12с, а между отдельными запросами примерно 560мс.
Где в моих рассуждения или настройках ошибка? Для работы по Modbus использую стандартные средства Codesys.

После некоторых экспериментов получился следующий результат.
При использовании библиотеки OwenCommunications ситуация заметно лучше, однако:
1. Если таймаут ожидания ответа ставить менее 100мс, то начинает проскакивать ошибка TIME_OUT, хотя снифер показывает, что слэйв сразу ответил на запрос.
2. Между приёмом ответа от слейва и новым запросом есть пауза 60-80мс, хотя никаких искусственных пауз в коде нет.
При использовании стандартных компонентов, но не через дерево проекта, а используя, например, IoDrvModbus.ModbusRequest2:
1. При таймауте ожидания ответа 50мс никаких проблем не возникает, при этом по сниферу видно, что действительно пауза ожидания ответа 60-70мс
2. Между приёмом ответа от слейва и новым запросом есть пауза 18-30мс
Таким образом я остановился на использовании IoDrvModbus.ModbusRequest2.