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

[petr2off]

Добрый день. Малененчко тут бился с Modbus TCP в связке контроллер Modb - OPC сервер. Почти победил, но остались странные периодические отваливания связи, с периодом 40 секунд. В проекте менять ничего нельзя, стойка управления водородкой в комплекте продается, но посмотреть проект можно. Посмотрел и увидел, что на все требуемые Modbus регистры имеют 2 интерфейса - Modbus TCP и Modbus RTU. Который Modbus TCP он живой, в смысле настроенный, и используется. А вот Modbus RTU пустой висит. Раньше через него связь с панелью делалась, но потом панель перевели на связь по TCP. Т.е. это мусор, который в спешке не убрали.
Вопрос - он может "гадить" периодически на связь по Modbus TCP ?

[Ryzhij]

Я так понимаю, что для Modbus-RTU ПЛК настроен как слэйв, и для Modbus-TCP как сервер?
В этом случае влияния не будет.
Нет запросов - нет действий.
Исключениеим будет наличие в программе обработки Heart-бита для выявления отсутствия связи.

[petr2off]

оба слейвы.

[petr2off]

Вообще по схеме получается, что к одному slave (ОВЕН) стучатся 2 master - Weintek и OPC. Они не могут мешать друг другу ?

[Никита]

Теоретически не должны. На практике - зависит от этого овна.
Аналогичную ситуацию с моксой я уже описывал - MB3480 сервером (слейвом), Insat OPC + Weintek клиентами (мастерами). Работает. Но не во всех режимах, при определенных настройках моксы начинается конфликт. С овном возможна подобная история.
Нет возможности обкатать эту схему на столе в составе контроллера, панели и OPC-сервера?
Был когда-то интересный прецедент, овеновский преобразователь 485-Ethernet отказывался нормально работать в поле. При этом и в сервисе овена и на стенде у асушников с ним никаких проблем не было.
Кстати, сам OPC-сервер тоже из овна?

[petr2off]

Нет, OPC сервер другого производителя. К сожалению я не могу туда влазить. Водородка - это комплексное изделие, типа на гарантии. Тут она еще и крякнула. Внутренний 485 канал упал. К тому же ее запустили, и теперь никто не позволит останавливать работающее оборудование. (Работающее в локальном режиме).

[Никита]

Я не про влезть в работающее, а про собрать стенд из ЗИПа и опробовать.

[petr2off]

Нет ЗИПа, к сожалению. Единственное что добился - они обещали сделать проект, когда Weintek встанет в рассечку. Т.е. с ОВНОм он будет общаться как MASTER Modbus RTU, а с OPC как SLAVE Modbus TCP. Мне кажется такой вариант поустойчивей будет.

[Никита]

Вот на том самом проекте мы от такого варианта как раз отказались - там панель и АРМ работают (надеюсь, до сих пор) параллельно и независимо. А включение панели в рассечку ставит все остальное в зависимость от работоспособности самой панели. Причем в вашем случае - не только аппаратной, но и любого программного глюка.
Схема с двумя клиентами по TCP принципиально работоспособна. Тут надо бы как раз овеновский контроллер в таком режиме погонять и посмотреть. Или вообще на поставщика это свалить, раз история гарантийная. А панель-ретранслятор - это уже костыль.

[petr2off]

По разному гонял. Сократил поток сбойных пакетов до 1 в 20 секунд. Удручает что ничего с о стороны ОВНА сделать не могу. Нет там никаких настроек в slave Modbus TCP. А на верху у меня мокса 205 стоит, которая ни как не программируется.

[Никита]

Так и я про то. Это не настройки, это вопрос прошивки и применяемых микросхем. Поэтому и интересно сначала убедиться в возможности Овна вообще нормально работать в тепличных условиях

[petr2off]

Когда я оставляю на моксе 1 канал - работает нормально.

[Никита]

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

[petr2off]

Там все просто, раньше панелька через 485 подключалась, но там и так все не шустро шевелится, они решили ее на TCP переключить.
Причем сделали это в первый раз, именно на этой установке. Сейчас кстати, когда запустили установку - сбоить стало намного интенсивней.

[Никита]

Что-то есть подозрение, что перевод Овена с 485 на Ethernet шустроты не добавит. Мак-адрес Овеновского контроллера не подскажете, ради интереса? Хотя бы первую половину. Есть догадка что там изначально Ethernet из 485 сделан...
Сколько вообще параметров передается?

[petr2off]

Да вообще мизер, 7 вещественных и 6 целых 16-разрядных регистров. Правда тут посовещались и решили, что вещественных должно быть 10.

Отправлено спустя 1 минуту 24 секунды:
Мак адрес сейчас не скажу, это надо цеплятся нотебуком к нему. Сейчас электрики могут и не пустить, они зверем на все это бл...ство смотрят.

Отправлено спустя 1 час 13 минут 45 секунд:
кстати, когда водородка не работала - условия в общем то стендовые были. И в таких условиях, в общем то почти удалось достигнуть работоспособного состояния. А вот включился электролизер - и все Ж..ПА.

[petr2off]

Мысль в голову пришла. Контроллеры ОВЕН питаются 220в. А у водородки процесс выпрямления мощный. Т.е. генерация мощных помех, герц 300. А ИБПшники там стремные стоят, как и все элетрооборудование (в смысле BACK UPS). Т.е. все это запросто может переть по питанию. Сейчас осциллограф подготовлю, завтра посмотрю...

[Никита]

Может и просто по воздуху. Но похоже, что проблема все же не со структурой сети, а с конкретным овном.
Для начала - ревизия медных трасс, уравнивание потенциалов всего оборудования, связанного медью, потом вопросы к поставщику.

[petr2off]

От щкафа до электролизера метров 5 наверно будет. И стенка металлическая между ними. У электролизера ток, ампер 500. Но прямо возле него стоят РП ОВЕНОВские с ОВЕНовской же панелью - и ничего, работают...

[Jackson]

Вообще по схеме получается, что к одному slave (ОВЕН) стучатся 2 master - Weintek и OPC. Они не могут мешать друг другу ?

по TCP - нет.вообще на ModBUS-TCP понятий «мастер» и «слейв» нет - есть «сервер» и «клиент». Клиентов может быть несколько и серверов несколько и общаться они могут друг с другом как угодно - трафик управляется на уровне протокола.

В ОВНе единое адресное пространство для обоих физических интерфейсов, данные берутся из одной и той же области памяти, но эти процессы независимы. По крайней мере должны быть.я конечно встречал слабенькие контроллеры, где один процессор занимается абсолютно всем, и если из грузить запросами по всем интерфейсам, то контроллеру плохеет, но в том что я видел тормозили в первую очередь локальные кнопки и дисплеи, а интерфейсы и алгоритм работали без сбоя.

Вы это можете легко проверить: подключите на 485 порт любой мастер. Например ПК с МодБас-пулом и пусть раз в пару секунд шлёт запросы одного и того же регистра. Если проблема устранится - печаль, значит в ОВНе сделано так как пишут выше (как в анекдоте про дискету и многозадачность) и это жесть. Тогда я бы так и вылечил - подключить к Овну Вейнтек ещё и по 485 где слать пустые запросы раз в 2-5 секунд.

Мне же кажется что либо свич либо сервер забивается запросами и берет тайм-аут на обработку скопившейся очереди. Это лечится настройками клиентов: уменьшить максимальную длину посылок, увеличить интервал между посылками, оптимизировать посылки так чтобы получать данные за минимальное количество запросов (Weintek этого не делает сам - каждый контрол на экране шлёт свой собственный запрос). На одном проекте я этим серьезно занялся и в результате клиент получал данные от семи серверов максимум за две посылки, это заметно ускорило получение данных и обработку тайм-аутов (потеря связи с одним сервером не тормозит получение данных от остальных). В вейнтеке выставил для Ethernet-порта паузу между посылками 200 мсек, тайм-аут 1-1,5 сек, количество попыток связи - 2. Эти сервера опрашивает не только Weintek так что возможны задержки их работы. Попробуйте поиграть с этими вещами.

Отправлено спустя 9 минут 37 секунд:
Ещё некоторым серверам сносит крышу от запросов несуществующих регистров, например 03 функцией читаем 100 регистров, а регистр 50 не существует (в описании это должно быть сказано) - тогда нормальный сервер просто не ответит на этот запрос (проигнорирует как ошибочный), а ненормальный пойдёт искать этот несуществующий регистр и заблудится. Посмотрите какие летят запросы и все ли эти регистры в действительности доступны.

[petr2off]

По 485 там подключено штук 20 модулей ОВЕНА, точнее там внутренняя сетка получается из банды 110 и еще одной панельки. Внутри все работает. Почему у меня сомнения зародились, если отваливается панель по TCP/IP то OPC Резко хорошеет. Сбои практически исчезают.
Разделение мастер - слейв делается по принципу кто инициирует запрос. Запрос инициирует мастер, в данном случае Панель и OPC.
Если мы переходим к координатам Клиент - сервер, кто в данном случае сервер а кто клиент ?
Насчет настройки. TCP в ОВЕНе не настраивается ни как. Там можно только IP и маску задать и выбрать 2 варианта Master и Slave. Выбран Slave. Поэтому я бы не стал так категорично утверждать, что в Modbus TCP нет понятий мастер и слейв. Если выбран Master, то еще таймаут добавлется.
Со стороны OPC, я уменьшил размер Modbus пакета с 64 регистров до 32, помогло. Сбоев стало меньше.
В панель я лазить не могу, установка на гарантии.

[Jackson]

Почему у меня сомнения зародились, если отваливается панель по TCP/IP то OPC Резко хорошеет. Сбои практически исчезают.

Тогда на время отбросьте эти модули с 485-го и посмотрите что будет с TCP/IP.

Запрос инициирует мастер, в данном случае Панель и OPC.
Если мы переходим к координатам Клиент - сервер, кто в данном случае сервер а кто клиент ?

Сервер - тот кто имеет данные, клиент - тот кому эти данные нужны. Любое устройство может работать как клиентом так и сервером одновременно. В Вашей системе - ПЛК это сервер, панель - это клиент. Если кто-то захочет тянуть данные с панели, то панель для него будет уже сервером.

Отправлено спустя 14 минут 37 секунд:

Насчет настройки. TCP в ОВЕНе не настраивается ни как.

Сервер и не надо настраивать - это надо в панели настроить чтобы она не слишком плотно и часто долбила ПЛК запросами. На Вейнтеке рефреш окна чаще чем раз в секунду всё равно маловозможен

В панель я лазить не могу, установка на гарантии.

Жаль. Тогда ничего не остаётся кроме как плотно разбираться с 485-м интерфейсом. Проверить подключение, правильность опроса (чтобы дырок не было), провода, резисторы, сопли в монтаже.... Похоже что действительно таймаут на 485-м подвешивает ModBUS-TCP, и тогда это жесткий косяк разработчиков. Любопытно сравнить стоимость этого ОВНа с аналогичным симатиком или омроном, где таких проблем нет.

Поэтому я бы не стал так категорично утверждать, что в Modbus TCP нет понятий мастер и слейв

Есть спецификация протокола. Я бы с ней не спорил. :)

Отправлено спустя 3 минуты 54 секунды:
Вообще, если это действительно косяк - это мощно. Примерив такое на свои задачи, я понимаю что у меня электростанция будет останавливаться всякий раз, когда порвется связь со СКАДА, если такое произойдет. Но такого к счастью не происходит ни в бюджетных ни в топовых контроллерах.

[Никита]

Мне же кажется что либо свич либо сервер забивается запросами и берет тайм-аут на обработку скопившейся очереди. Это лечится настройками клиентов

Если все данные с оборудования собираются по одной шине, пусть даже на 115200, то даже десятимегабитный свитч это должен нормально пропустить. Оптимизация - да, надо заняться.
Кстати, каждый запрос на панели отдельной посылкой - это проверенная информация? Т.е. я не зря заставлял студента на том проекте вычитывать дискреты с Овенов одной посылкой и потом ее расшифровывать в память?
Проблема может быть и на четвертом уровне. Если Овен не умеет держать два TCP-сокета, то каждый раз при запросе от нового клиента TCP-соединение рвется и устанавливается по-новой с новым клиентом, с выделением в контроллере буферов и структур для нового клиента, то это и правда мрак. Похоже все-таки придется мониторить трафик контроллера... Хотя для начала надо бы просто сокеты поглядеть на машине с OPC-сервером

[Jackson]

Кстати, каждый запрос на панели отдельной посылкой - это проверенная информация?

[+] ответ

Конкретно на моей панели и в моём проекте - да. Как проверить. Расставить на экране кучу контролов, завязанных на одно и то же устройство напрямую (адрес один, например регистры разные, а лучше не регистры а битовые - чтоб не 03 функцией читать а 01), и отключите это устройство физически - при открытии этого экрана у меня каждый элемент рисуется только после того как отработают настройки таймаута и кол-ва посылок, и так по каждому элементу. В какой-то момент вейнтек решает что связи нет совсем, рисует их все со значком "нет связи". Но каждый раз при открытии этого окна всё повторяется. Если на экране сотня контролов (а у меня их и больше кое-где) - кому такая панель в итоге нужна когда быстрее сходить и посмотреть пешком?

Т.е. я не зря заставлял студента на том проекте вычитывать дискреты с Овенов одной посылкой и потом ее расшифровывать в память?

Мне пришлось так делать во всём проекте. Больше того - сконфигурировать адресные пространства в устройствах так, чтобы нужные данные укладывались в одну посылку, для каждого рабочего окна отдельная конфигурация (во всех 7 устройствах). И отдельно обрабатывать таймауты связи чтобы отвалившиеся устройства не мешали опрашивать остальные. Только тогда картинка стала приемлемая. Там ещё панелька висит на самом агрегате и все эти задержки сразу в глаза бросаются. Стояла б она за углом или в другом помещении - никто бы и внимания не обратил.

Отправлено спустя 2 часа 48 минут 42 секунды:

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

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

[petr2off]

Там 10 параметров OPС сервер опрашивает, панелька та все опрашивает, потому как она еще и архив ведет.