• ОБЯЗАТЕЛЬНО заполнить свой профиль НА РУССКОМ ЯЗЫКЕ КИРИЛЛИЦЕЙ.
  • НЕ НУЖНО писать свой вопрос в первую попавшуюся тему, а вместо этого создать НОВУЮ тему.
  • Дублирование сообщений приравнивается к спаму.
  • Рекламу мы не размещаем ни на каких условиях.

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

Ответить
Аватара пользователя

Никита
почётный участник форума
почётный участник форума
Сообщения: 3145
Зарегистрирован: 20 янв 2010, 22:23
Имя: Никита
Откуда: Мурманск
Благодарил (а): 12 раз
Поблагодарили: 74 раза

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

Сообщение Никита » 04 окт 2018, 17:55

TEB писал(а):
04 окт 2018, 14:09
Никита писал(а):
04 окт 2018, 11:05
Если все данные с оборудования собираются по одной шине, пусть даже на 115200, то даже десятимегабитный свитч это должен нормально пропустить
Это смотря как читать. Если читать каждый регистр или бит отдельной посылкой то может и 100 МБит не хватить.
Да как угодно. Частоту опроса чаще чем пять раз в секунду смысла делать вообще нет, а разумное - раз в секунду, все равно живой оператор быстрее не отреагирует.
20 модулей х 32канала (условно) = 640 пакетов туда и столько же обратно. Адрес-функция-данные-CRC, ну пусть даже по 6 слов или 12 байт на телеграмму. Округленно 8кБ в обе стороны. С двух мастеров - 16кБ. 1280 пакетов, при объемах буферов дешевых коммутаторов от 128кБ и скорости на порт 14тыс пакетов/с в режиме 10Мбит/с вообще ни о чем.
Очень грубо, считая что при спуске с прикладного на физический уровень на каждом уровне пакет удваивает объем, это 16*2^6= 2^10=1МБ. Утрирую, конечно очень сильно, но попробую так учесть и все собственные нужды, от ARP до NetBIOS.
Так что либо сеть засрагружена чем-то еще, включая вирусы или попытки винды обновиться и лицензироваться (что не лучше), или оконечные устройства не готовы схавать такой трафик. А из оконечных наиболее загружен как раз Овен)
Опыт - это когда на смену вопросам: "Что? Где? Когда? Как? Почему?" приходит единственный вопрос: "Нахрена? "

Аватара пользователя

Автор темы
petr2off
частый гость
частый гость
Сообщения: 440
Зарегистрирован: 06 янв 2016, 19:45
Имя: Петров В.Л.
Благодарил (а): 6 раз
Поблагодарили: 15 раз

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

Сообщение petr2off » 05 окт 2018, 15:39

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

Аватара пользователя

Jackson
администратор
администратор
Сообщения: 10077
Зарегистрирован: 17 июн 2008, 15:01
Имя: Евгений свет Брониславович
Благодарил (а): 137 раз
Поблагодарили: 164 раза
Контактная информация:

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

Сообщение Jackson » 05 окт 2018, 18:15

Если
petr2off писал(а):
05 окт 2018, 15:39
В новом, через стандартный ОВЕНОВский MODBUS TCP SLAVE, как и c OPC.
, то как объяснить то, что
petr2off писал(а):
05 окт 2018, 15:39
2 - С OPC перестала работать вообще
?

Это не ОВЕНовская настройка, а общая настройка TCP-IP. Это адрес шлюза, через который панелька выходила бы на ОВЕН, если бы оба эти узла находились в разных подсетях. А если они в одной подсети (в IP-адресе отличаются только цифры после третьей точки) то шлюз не используется вовсе даже если настроен - настройки шлюза игнорируются.
petr2off писал(а):
05 окт 2018, 15:39
С понедельника буду пробовать переводить OPC на MOdbus RTU
Куда Вы торопитесь? :) Рекомендую посмотреть фактический IP-адрес ОВНа, раз он почему-то работал через несуществующий шлюз а теперь работает напрямую, и проверить по какому адресу OPC ищет ОВЕН, при несоответствии - изменить.
По вопросам работы Форума можно обратиться по этим контактам.

Аватара пользователя

Автор темы
petr2off
частый гость
частый гость
Сообщения: 440
Зарегистрирован: 06 янв 2016, 19:45
Имя: Петров В.Л.
Благодарил (а): 6 раз
Поблагодарили: 15 раз

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

Сообщение petr2off » 05 окт 2018, 20:13

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

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

Аватара пользователя

Jackson
администратор
администратор
Сообщения: 10077
Зарегистрирован: 17 июн 2008, 15:01
Имя: Евгений свет Брониславович
Благодарил (а): 137 раз
Поблагодарили: 164 раза
Контактная информация:

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

Сообщение Jackson » 05 окт 2018, 22:06

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

Аватара пользователя

Автор темы
petr2off
частый гость
частый гость
Сообщения: 440
Зарегистрирован: 06 янв 2016, 19:45
Имя: Петров В.Л.
Благодарил (а): 6 раз
Поблагодарили: 15 раз

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

Сообщение petr2off » 06 окт 2018, 11:09

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

Ответить

Вернуться в «ОВЕН»