1. Обязательно представиться на русском языке кириллицей (заполнить поле "Имя").
  2. Фиктивные имена мы не приветствуем. Ивановых и Пупкиных здесь уже достаточно.
  3. Не писать свой вопрос в первую попавшуюся тему - вместо этого создать новую тему.
  4. За поиск, предложение и обсуждение пиратского ПО и средств взлома - бан без предупреждения.
  5. Рекламу и частные объявления "куплю/продам/есть халтура" мы не размещаем ни на каких условиях.
  6. Перед тем как что-то написать - читать здесь и здесь, а студентам - обязательно здесь.
  7. Не надо писать в ЛС администраторам свои технические вопросы. Администраторы форума отлично знают как работает форум, а не все-все контроллеры, о которых тут пишут.

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

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

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

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

Сообщение Никита »

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
эксперт
эксперт
Сообщения: 1602
Зарегистрирован: 06 янв 2016, 19:45
Имя: Петров В.Л.
Страна: Россия
город/регион: Красноярск
Благодарил (а): 69 раз
Поблагодарили: 185 раз

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

Сообщение petr2off »

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

Jackson
администратор
администратор
Сообщения: 17468
Зарегистрирован: 17 июн 2008, 16:01
Имя: Евгений свет Брониславович
Страна: Россия
город/регион: Санкт-Петербург
Благодарил (а): 746 раз
Поблагодарили: 1277 раз

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

Сообщение Jackson »

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

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

Автор темы
petr2off
эксперт
эксперт
Сообщения: 1602
Зарегистрирован: 06 янв 2016, 19:45
Имя: Петров В.Л.
Страна: Россия
город/регион: Красноярск
Благодарил (а): 69 раз
Поблагодарили: 185 раз

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

Сообщение petr2off »

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

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

Jackson
администратор
администратор
Сообщения: 17468
Зарегистрирован: 17 июн 2008, 16:01
Имя: Евгений свет Брониславович
Страна: Россия
город/регион: Санкт-Петербург
Благодарил (а): 746 раз
Поблагодарили: 1277 раз

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

Сообщение Jackson »

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

Автор темы
petr2off
эксперт
эксперт
Сообщения: 1602
Зарегистрирован: 06 янв 2016, 19:45
Имя: Петров В.Л.
Страна: Россия
город/регион: Красноярск
Благодарил (а): 69 раз
Поблагодарили: 185 раз

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

Сообщение petr2off »

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

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