Просмотр полной версии : Протокол ОВЕН и ModBus на одной шине
Такой вопрос, возможно даже кто то пробовал это:
в одной физической сети (2 провода А и В) организовать 2 сети по протоколу ОВЕН и ModBus, опрашивать разными ОРС с разных преобразователей интерфейса, с разных портов.
Преследуемая цель, разделить устройства опроса (информационная часть) и устройства управления механизмами, для уменьшения времени реагирования устройств управления, т.к. в сети много устройств и опрос ОРС сервера вырос до 10 сек., тоесть отсылаешь команду открытия клапана и ждешь) Мастер в сети только скада.
Невозможно, у вас будут накладываться данные от чужих запросов и ответов.
Всегда будет происходить совпадение времени, от этого не избавиться.
ИМХО, я бы поступил проще, каналы управления с максимальным периодом опроса, например в цикле на двух устройствах, все остальные параметры с уменьшиным периодом опроса. Но правда позволяют ли это настроить ваши ОРС сервера.
Сергей0308
24.02.2017, 03:25
ИМХО, я бы поступил проще, каналы управления с максимальным периодом опроса, например в цикле на двух устройствах, все остальные параметры с уменьшиным периодом опроса. Но правда позволяют ли это настроить ваши ОРС сервера.
Ну и зачем постоянно писать "0" или "1" при дискретных сигналах?
Сергей0308 имеется ввиду те каналы, на которых управление читать максимально быстро. и там же запись.
Ведь ОРС пока не дочитал данные не будет выполнять запись, а там пачка сигналов читается в очереди.
ИМХО, я бы поступил проще, каналы управления с максимальным периодом опроса, например в цикле на двух устройствах, все остальные параметры с уменьшиным периодом опроса. Но правда позволяют ли это настроить ваши ОРС сервера.
OPC сервера ОВЕН
Efremov я к сожалению не особо с ним знаком, на компе в домене он криво у меня работает. Посмотрите в его настройках, можно ли там указывать время опроса для разных каналов. На группы там точно можно делить. в общем все вялотекущие сигналы опрашивайте реже. например постоянно опрашивайте важные и реже не важные из расчета времени так, чтобы было минимум совпадения времени. Тогда при подаче команды управления есть шанс, что она выполнится быстрее, если в это время не было опросов не важных параметров.
Хотя с протоколом Овен не помню, кажется он не поддерживает групповых запросов как Modbus.
Невозможно, у вас будут накладываться данные от чужих запросов и ответов.
Всегда будет происходить совпадение времени, от этого не избавиться.
тоесть будут совпадать частоты 2 х разных преобразователей интерфейса? но ведь разные протоколы передачи данных, даже можно сделать что бы адреса устройств не пересекались в 2 х разных сетях.
Efremov частоты и протоколы тут не важны, важно время и свобода линии. Вот например одна сторона сделала запрос прибору и ждет ответа, вторая сторона не знает, что линия сейчас будет занята и тоже посылает запрос, в это время первый прибор начинает отвечать и второй прибор начинает отвечать, в результате на линии мусор.
Я пробовал проводить эксперимент только я двумя SCADA системами опрашивал один прибор, расшарив COM порт на две линии TCP, там такая каша начинается.
а на каждый прибор ставить свой TCP шлюз с поддержкой нескольких сокетов это накладно. Если бы приборы были c TCP протоколом то это одно, а когда это линия RS485 то ничего хорошего не выйдет. Время опроса и ответа как бы вы не разносили всегда периодически совпадает.
А можно. Только средства нестандарные, т.е. сами реализуете мастеров с возможностью их синхронизации. Но с большой вероятностью для своей задачи выбрали не самую короткую дорогу.
10 сек - это, простите, очень до хрена - у вас там 5 тыщ датчиков ?
Поподробней
Все просто, датчиков всего 140 штук, все приборы формы ОВЕН, протокол фирма ОВЕН, ОРС фирма ОВЕН , опрос идет в порядке очереди, в ОРС есть отладочное окно в котором в котором все отображается, сам ОРС пишет что опрос всех параметров занимает порядка 13 000 ms, в ОРС время опроса выставлено 100 ms, все как бы складывается
Efremov а почему не перейти на Modbus RTU ? по крайней мере можно сократить время с 13с на меньшее
Т.е. для каждого датчика - отдельный модуль расширения, и все 140 модулей расширения это 2AC или 8AC ?
нет не для каждого, 17 приборов это ТРМ138, УКТ38, МВ110-8А, и в нагрузку пока 2шт МВ110-16Д и МУ110-16Р и их как раз планируется поставить еще больше 10 шт, поэтому и хочу отделить их.
И еще поясняю мастер в сети только скада контроллеров нет, все собирается через ОРС и в скаду.
Efremov а почему не перейти на Modbus RTU ? по крайней мере можно сократить время с 13с на меньшее
на эксперименты времени нет, производство работает круглосуточно и остановить нельзя, т.к. потом выход на параметры целые сутки, большие убытки, поиграться никак нельзя, если бы точно знать что с 13 сек получится сократить до 1 сек то это было бы хоть какое то обоснование останова производства, но вообще конечно для информационной части 13 сек это не кретично, всех устраивает, а вот для управления это совсем беда.
з.ы. на самом деле мастер в сети для приборов не SCADA, а как раз таки OPC сервера.
Разделять линии самое лучшее.
до 1 секунды там никак даже на Modbus.
з.ы. на самом деле мастер в сети для приборов не SCADA, а как раз таки OPC сервера.
Разделять линии самое лучшее.
до 1 секунды там никак даже на Modbus.
если честно проектировал 15 лет на ПТК КВИНТ, КРУГ, ТЕКОН из за того что проекты были полномасштабные никогда не пользовался ОРС, тоесть 1 раз и то давно принимали параметры из другой системы для расчета ТЭП, теперь понимаю что это очень долгая весчь. Всегда были требования что бы техпрограмма не превышала 100 ms, соответственно контроллер за цикл опрашивал более 200 датчиков.
а таймауты на ожидание ответа от каждого прибора ? ноль же не поставишь, так что в 1 сек сомнительно
а вообще вся эта идея с разделением DO и Di от Ai началась из за того, что приборы ТРМ138, УКТ38, МВ110-16Д, МУ110-16Р, МВ110-8А все объеденены в сеть через преобразователь интерфейса АС3-М, через OPC-сервер ОВЕН сигналы поднимаю в скаду SimpLight, получается следующая ситуация: всё работает штатно до того момента как прописываю в ОРС модуль вывода МУ110-16Р, после этого начинают с модуля МВ110-8А данные приходить с переодичностью 1 сек. есть, 5-7 сек. отсутствуют, удаляю с ОРС модуль вывода и с модуля МВ110-8А начинают данные приходить постоянно, из за этого на мониторе эти параметры то гаснут то появляются, при этом DO и DI остаются работать штатно, это только потом я начал смотреть на времена опроса и т.д., короче эту загадку я так и не разгадал...
У Вас точно нет конфликта адресов? Напомню, что МУ110-16Р занимает в сети 16 адресов подряд.
Ну и если не брать УКТ38, все приборы поддерживают МОДБАС. Переходите на него, он быстрее, в т.ч. за счет группового чтения и записи.
Также OPC от инсата имеет приоритет записи, т.е. при поступлении команды на запись он прерывает опрос, не дожидаясь перебора адресов.
У Вас точно нет конфликта адресов? Напомню, что МУ110-16Р занимает в сети 16 адресов подряд.
Ну и если не брать УКТ38, все приборы поддерживают МОДБАС. Переходите на него, он быстрее, в т.ч. за счет группового чтения и записи.
Также OPC от инсата имеет приоритет записи, т.е. при поступлении команды на запись он прерывает опрос, не дожидаясь перебора адресов.
сразу проверил адреса не наезжают ли друг на друга там все ОК, ОРС всего один, перейдти сразу на Модбас проблемно, выше писал, кстати все это происходит даже если физически из сети выткнуть МУ110-16Р, и прописывать его в ОРС
Кинуть вторую линию (или использовать 2-ю пару если есть в кабеле) и потихоньку пересаживать по прибору на Modbus
Интересно, с чем связан выбор SimpLight ? Просто если все с Modbus, можно было выбрать другую SCADA где Modbus работает через нативные драйвера самой SCADA без прослойки в виде OPC
перейдти сразу на Модбас проблемно
Так переходите по очереди, но прокладывая параллельную шину.
все это происходит даже если физически из сети выткнуть МУ110-16Р, и прописывать его в ОРСЧто происходит? Подробнее, пожалуйста.
Посмотрел, вроде у SimpLight есть поддержка Modbus в некоторых версиях и не так уж дорого, договоритесь с разработчиками перейти на версию с поддержкой Modbus без ОРС, будет гораздо лучше
При цене OPC Инсат на 500 тегов в 3900р - по сути дешевле одного прибора ОВЕН, говорить про его стоимость для завода с непрерывным производством - просто смешно.
у меня максимальная версия SIMP Light ENT unlim muiltiOPC+MODBUS (Симп лайт ЭНТ без ограничения кол-ва тегов), буду в понедельник прокладывать паралельную шину и потихоньку переходить на MODBUS откажусь от ОРС, скада куплена месяц назад, сеть работала уже давно на протоколе ОВЕН, поэтому некогда было глобально переделывать все, а нужно было запустить в работу скаду
Так переходите по очереди, но прокладывая параллельную шину.
Что происходит? Подробнее, пожалуйста.
вот это происходить :
""а вообще вся эта идея с разделением DO и Di от Ai началась из за того, что приборы ТРМ138, УКТ38, МВ110-16Д, МУ110-16Р, МВ110-8А все объеденены в сеть через преобразователь интерфейса АС3-М, через OPC-сервер ОВЕН сигналы поднимаю в скаду SimpLight, получается следующая ситуация: всё работает штатно до того момента как прописываю в ОРС модуль вывода МУ110-16Р, после этого начинают с модуля МВ110-8А данные приходить с переодичностью 1 сек. есть, 5-7 сек. отсутствуют, удаляю с ОРС модуль вывода и с модуля МВ110-8А начинают данные приходить постоянно, из за этого на мониторе эти параметры то гаснут то появляются, при этом DO и DI остаются работать штатно, это только потом я начал смотреть на времена опроса и т.д., короче эту загадку я так и не разгадал...""
от ОРС по возможности надо держаться подальше, если нет специфических условий. Через них работа всегда медленней, чем через нативные драйвера. В данном случае поддержка Modbus непосредственно через драйвер SCADA будет лучше.
А вы на столе пробовали сделать проверку через другой преобразователь ?
Есть еще момент, часть модулей в/в Овен с автоопределением протокола, может это может как-то влиять ?
Ведь у вас часть работает по Овен, а часть по Modbus, то есть в сеть сыпятся запросы по обоим протоколам, может какой-то модуль плющить начинает из-за этого ?
Кстати абсолютно этому не удивлюсь, есть прецинденты даже на одном протоколе, пока производитель не обновил прошивки приборов.
нет, сейчас все по протоколу Овен работает. Да на столе пробовал через 3 вида преобразователей, и действительно скорости разные, это меня удивило
Efremov модули DI, DO вы тоже по протоколу Овен подключали и у вас увеличивалось время опроса ?
Тут либо с адресами что-то либо может что-то с прошивками, из-за чего это происходило.
Efremov модули DI, DO вы тоже по протоколу Овен подключали и у вас увеличивалось время опроса ?
Тут либо с адресами что-то либо может что-то с прошивками, из-за чего это происходило.
DI и DO все по протоколу Овен, только разные преобразователи интерфейса, овеновские АС3, АС4, Мохa, Bolid, всех быстрее работал АС3
Powered by vBulletin® Version 4.2.3 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot