Два протокола на одном Modbus регистре

[Никита]

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

Это смотря как читать. Если читать каждый регистр или бит отдельной посылкой то может и 100 МБит не хватить.

Да как угодно. Частоту опроса чаще чем пять раз в секунду смысла делать вообще нет, а разумное - раз в секунду, все равно живой оператор быстрее не отреагирует.
20 модулей х 32канала (условно) = 640 пакетов туда и столько же обратно. Адрес-функция-данные-CRC, ну пусть даже по 6 слов или 12 байт на телеграмму. Округленно 8кБ в обе стороны. С двух мастеров - 16кБ. 1280 пакетов, при объемах буферов дешевых коммутаторов от 128кБ и скорости на порт 14тыс пакетов/с в режиме 10Мбит/с вообще ни о чем.
Очень грубо, считая что при спуске с прикладного на физический уровень на каждом уровне пакет удваивает объем, это 16*2^6= 2^10=1МБ. Утрирую, конечно очень сильно, но попробую так учесть и все собственные нужды, от ARP до NetBIOS.
Так что либо сеть засрагружена чем-то еще, включая вирусы или попытки винды обновиться и лицензироваться (что не лучше), или оконечные устройства не готовы схавать такой трафик. А из оконечных наиболее загружен как раз Овен)

[petr2off]

Поставщик "Водородки" прислал обновленный софт. Изменения касались работы с панелью. В старом ПО ОВЕН взаимодействовал с панелью через специальный GATEWAY, предназначенный для работы с панелью. Эта такая ОВЕНОВская настройка на MODBUS TCP. В новом, через стандартный ОВЕНОВский MODBUS TCP SLAVE, как и c OPC.
Результат: 1- Сама панель стала работать хорошо. Перестала отваливаться, при рестарте - самостоятельно устанавливает соединение с ОВЕНОМ. 2 - С OPC перестала работать вообще.
С понедельника буду пробовать переводить OPC на MOdbus RTU.

[Jackson]

Если

В новом, через стандартный ОВЕНОВский MODBUS TCP SLAVE, как и c OPC.

, то как объяснить то, что

2 - С OPC перестала работать вообще

?

Это не ОВЕНовская настройка, а общая настройка TCP-IP. Это адрес шлюза, через который панелька выходила бы на ОВЕН, если бы оба эти узла находились в разных подсетях. А если они в одной подсети (в IP-адресе отличаются только цифры после третьей точки) то шлюз не используется вовсе даже если настроен - настройки шлюза игнорируются.

С понедельника буду пробовать переводить OPC на MOdbus RTU

Куда Вы торопитесь? :) Рекомендую посмотреть фактический IP-адрес ОВНа, раз он почему-то работал через несуществующий шлюз а теперь работает напрямую, и проверить по какому адресу OPC ищет ОВЕН, при несоответствии - изменить.

[petr2off]

Это не настройка TCP IP. TCP IP в ОВЕНЕ не настраивается, этот драйвер написанный для связи с панелью, в нем создавались ТЭГИ, которые панель читала. Сейчас ТЭГИ для панели и ТЭГИ для OPC - создаются одинаково, как ТЭГИ MODBAS TCP slave. А объясняется просто, теперь, в панели контролируется разрыв соединения с контроллером, и по обнаружении этого факта, соннест поднимается снова.
И OPC теперь не может пробиться ОВЕНУ. IP адрес у ОВЕНА один, и он не менялся.

Отправлено спустя 11 минут 15 секунд:
Гэтвеем его парни из цеха ТАИ назвали. Я повторил не подумавши. А фактически этj Драйвер CODESYS для связи с панелью Weintek.
Из преимуществ - панель сразу видет все ТЭГИ ОВЕНА. Но склонен отваливатся, и сам не поднимается. Поэтому панель нужно было запускать после того, как поднимется контролер.

[Jackson]

Странные вещи говорите. Всё это реализуется стандартными средствами любого нормального OPC, и в панели тоже. И драйвер никакой не нужен. Вот отсюда и пляски с бубном - нестандартное решение стандартной задачи. Если б Вы сразу сказали что так всё сделано - людям не пришлось бы голову ломать над тем, о чём догадаться они никак не могли.
Тут Вам и не помогут - только разработчик знает как работает его решение.

[petr2off]

Драйвер нужен в любом случае. Просто это либо стандартный Modbus TCP Slave, по нему контроллер вяжется с OPC. А вот с панелькой можно связаться либо посредством того же Modbus TCP Slave, либо драйвером CODESYS для Weintek. Все они вполне стандартные. Сейчас все установлено единообразно, и панель и OPC связываются с контроллером через Modbus TCP Slave. Куда уж стандартней. Только вместе на работают, и какой разработчик Панели, контроллера или OPC знает, как это работает - непонятно.
Собственно говоря - я не хочу решать эту задачу, потому как это не я разрабатывал софт для "водородки". А вот за интеграцию с АСУ ТП , я отвечаю. Потому и склоняюсь к такому решению. Если 2 mastera Modbus (вы уж извините, я пользуюсь такой терминологией, потому как она и в контроллере, и в панели и в OPC используется) не могут работать. То для меня проще по 485 это привести на блочный щит, чем разбираться в глюках панели и ОВЕНА. К OPC у меня претензий нет, Вибробит и контроль ИБП она обслуживает без проблем.