Всем доброе утро!
Нахожусь в раздумьях по поводу того, как правильно распределить управление системами на объекте. В данный момент занимаюсь разработкой ПО верхнего уровня и пусконаладкой систем и вот хочу спросить совета.
Есть объект, управляется несколькими ПЛК. У каждого ПЛК есть RS232 и Ethernet. По месту к каждому ПЛК по RS232 подключается ЖК-панель Weintek. Кроме этого каждый ПЛК подключен к сети Ethernet и данные с него считывает АРМ диспетчера со скада-системой. Со считыванием и отображением даннных проблем никаких нет. А вот с заданием уставок и изменением режимов работы системы есть небольшая проблема, и для решения этой проблемы есть несколько вариантов - никак не могу остановится на каком-либо из них. Проблема следующего рода - задаю уставку из скады - данные записываются в контроллер. В контроллере в ячейке памяти, зарезервированной под работу по интерфейсу сохраняется значение переменной. Кроме того, переменная "висит" в скаде. Теперь подхожу к ЖК-панели и задаю эту уставку в ней. Уставка переписывается в контроллере, но затем происходит следующее - с скады опять приходит старая уставка и данные переписываются в память заного. Т.е. одновременно управлять контроллером двумя мастерами не получается. Есть несколько вариантов решения проблемы:
1. Завести в контроллере переменную - "выбор мастера" и переключать разные входы. Но тогда в контроллере для каждой уставки придется отвести по два входа с интерфейса.
2. В скаде придумать кнопку, которая будет отключать работу с интерфейсом переменных, отслающих данные по интерфейсу контроллерам. Будет что-то типа кнопки "включить местное управление".
3. Ограничить функционал ЖК-панелей и оставить им только визуализацию, без возможности вмешиваться в управление системами.
Возможно есть еще варианты - в общем нужен "свежий взгляд". Всем заранее спасибо за советы.

А зачем SCADA все время пишет переменную в контроллер? Это программная особенность такая? Сделайте запись в контроллер по нажатию кнопки "Применить" например и получится схема "кто последний - тот и папа".

Записывайте данные из разных источников в одну ячейку. Получите управление и актуальные значения во всех местах. В чем проблема-то?

А Вы думаете он в разные пишет?

Такая проблема возникает всегда когда протокол циклически пишет все переменные какие есть в программе (так делает Modbus например), в этом смысле протоколы на основе "телеграмм" намного удобнее.

Это же только с аналоговыми значениями проблема? С битовыми ведь всё просто.
Для аналоговых в любом случае придётся размножить переменные в ПЛК - как минимум разделить рабочее значение и значения, хранящееся в HMI и SCADA. Ну и переписывать их друг в друга по некоему алгоритму.
Например, если ваш контроллер позволяет определить конец текущего цикла программы - всё несколько проще. Смотрите что изменилось на конец цикла - и если одно значение не равно двум другим - пишете новое значение в два других.

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

2 Max2114
вообще странно как-то...
По моему опыту Скада не переписывает постоянно значения, а только по изменению... (даже без кнопки Применить, а встроенными средствами).
Изменил оператор уставку, нажал энтер - значение обновилось. И считывается, чтобы показать актуальное.
Поменял кто-то это значение из другого места (с пульта, по расписанию и т.п.) - измененное значение отразилось в скаде.
С чего оно опять-то меняться будет?
Как правильно написал Сергей Долганов - "кто последний - тот и папа".

В Дезиге есть система управления по приоритетам... можно попробовать ее самому реализовать,
но, имхо, сложно это. И, скоре всего, не нужно.

Из первого сообщения.
1. Теоретически возможно, практически - очень сложно и неудобно в итоге.
2. Возможно. Но тогда наддо на скаду добавлять индикатор "Местное управление",
чтобы оператор понимал, почему его система не слушается.
3. Не есть гуд. По смыслу местного управления.


Имхо, дело не в протоколе, а в кривых руках или лени программиста. Циклом можно опрашивать входы. но не выходы же

Автор, какие протоколы то? А то погрязнем в вариантах.

Целиком согласен с Lex и Долгановым.
Касательно потокола Modbus хранителем данных выступает ПЛК.
Мы всегда реализуем на ПЛК для одной ячейки памяти несколько (сколько необходимо) переменных по которым могут приходить данные.
Алгоритм следующий:
если текущее значение переменной не равно ее же предыдущему значению и переменная не равна значению в ячейке памяти - записываем в ячейку новое значение переменной.
И так по каждой перменной для данной ячейки.

Такми образом, кто бы ни выступал источником новых данных (панелька, СКАДА и т.д.) будет реализован механизм "Кто последний тот и прав". А все получатели получат эти самые последние данные.

Кривые руки программиста не при чем - такой эффект получается при использовании программных средств, без написания дополнительных макросов, реализующих "фишки" типа отключения передачи данных по интерфейсу.
Протокол ModbusTCP. И скада и панель пишут данные "циклически". Т.е. опрос и запись ведется постоянно. Кто последний тот и папа - не получится (хотя при большом желании можно "замутить" отключение записи со скады, но нежелательно так как получится "громоздко".


У меня как раз один из варинатов решения данной проблемы именно такой И скорее всего так и сделаю.

Так просто это сделать не получится - переменная по модбасу записывается всегда. Последний вариант, предложенный Chabol - самый оптимальный. Его и буду использовать.

Сама по себе ситуация немного странно вывернута: ну не могут быть у одних и тех же данных два разных источника. Это просто два разных источника и две разные информации I1 и I2. ПЛК лишь должен выступать судьей в выборе, то есть выполнить некоторую операцию над данными: f(I1, I2). Возможно потребуется дополнительная информация от источников, чтобы разрешить конфликт. Может это будет бит "сейчас папа - я"?
Эта же информация должна пойти крест накрест: от ПЛК к источнику 1 должна пойти инфа I2 с указанием, что "источник 2 является папой" и соответственно к источнику 2 должна пойти инфа I1 с битом "источник 1 - папа". Это для того, чтобы обновить источникам свои данные.

Если не секрет - что за ПО? Скада? Чтоб на те же грабли не наступать...

е-мае, да любая скада и любой ОПС-сервер при работе с модбасом будет себя вести точно так же. Это не "телеграммный" протокол. И эти "грабли" получаются в том случае, если "slave" - слуга двух господ. Панель Weintek ведет себя точно так же, как и скада. И другой контроллер тоже (в некоторых правда есть возможность выполнять запрос при условии, но при "обычном" подключении все будет аналогично). Если не верите - возьмите два ПК со скадой, контролер с двумя портами и протоколом модбас и попытайтесь перезаписать одну и ту же переменную. И увидите, что не правы.

Что-то вы, товарищи, не то мутите. И панель Вайнтек, и любой контроллер пишет переменные по Модбасу ТОЛЬКО ТОГДА, когда на это есть запрос. Например, на панели, закончил ввод, нажал на экранной клавиатуре Enter, и только тогда произойдет однократная запись по адресу переменной. Не понимаю, о чем речь идет... Аналогично и на текстовых панелях. Только кнопки уже будут аппаратные.

В контроллере предусмотрите дополнительную переменную, которая будет записывать задание на регулятор по команде. Теперь, меняя эту переменную и подовая команду на запись, будете менять задание со скады. Все остальное время задание со скады прилетать не будет.

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

А про телеграммы....
Modbus RTU это же не бродкаст, а запрос-ответ, поэтому можно задать (для разных команд) когда будет запрос - циклично или разово. ИМХО.

Только вот последним всегда окажется СКАДА. И опять перезапишет уставку такой, какая нужна именно ей.

Кнопка на скаде ближе к теме, но я бы сделал ее автоматической. Например по условию, что оператор с АРМа со СКАДОЙ ввел новое значение уставки включается подпрограмма, запускающая команду на перезапись переменной в контроллере. После прихода подтверждения о успешном выполнении команды она удаляется из регистров, но чтение этой переменной продолжается и сравнивается с уставкой. Если вдруг контроллер дал сбой и переменная слетела, то скада опять перезаписывает эту переменную.
Только вот стоит вопрос . как сделать так, чтобы СКАДА не восприняла изменение переменной с панели за сбой. Придется вводить некий флаг, который сообщает, что изменение произошло с панели и по нему скада понимает. что это не сбой.

Только вот я не знаю, возможно ли реализовать этот алгоритм, когда программа в контроллере , СКАДА или панели пишется не на языке программирования а при помощи конфигураторов. Это уже зависит от самого ПО.
Я не являюсь программистом таких систем, по этому не знаю всех тонкостей конфигурирования и программирование СКАДЫ, но если написали про ручную кнопку, то думаю и програмную по событию сделать не составит особого труда.




Во, нужно учиться араторскому мастерсту. то что расписал чуть ли не в в целой статье -оказывается умещается в паре предложений.

Вы не читаете внимательно! У меня ModbusTCP и ModbusRTU - т.е. панель пишет по ModbusRTU а скада по ModbusTCP. И вообще я проблему уже решил - завел две переменные для интрефейса со скады и для панели. Запись в ПЛК происходит при изменении одной из переменных, кто последний изменился ту и записывает. Сделе это посредствам ПЛК. Насчет того,пишет ли вайнтек данные постоянно или нет - вы сами то пробовал? Я пробовал и не раз, и знаю о чем говорю. Если кто не верит, могу для прикола сделать прогу с двумя пнаелями которые будут мастерами для одного контроллера по разным портам. Вам только так кажется, что данные в интрефейс приходят только тогда, когда вы туда что-то пошлете. При старте контроллера и скады/панели в интрефейс приходит 0. Когда нажимаешь кнопку и задаешь параметр, то в интерфейс посылается значение уставки, и в ячейке памяти контроллера просиходит запись (в той ячейке, в которой лежит переменная интерфейса). После этого пермененная так и "болтается" в интерфейсе. И если эта же ячейка используется другим мастером, по другому интерейсу, то он так же её переписывает, а так как с интерфейса скады опять приходят данные то происходит повторная перезапись. Если кто не верит - попробуйте.


Вариант, предложенный Chabool как раз работоспособный. Запись в память контроллера просиходит при ИЗМЕНЕНИИ поступающих данных из интерфейса из двух переменных. Которая последняя ИЗМЕНИЛАСЬ та уставка и записывается.

Как я понял, проблемы возникают именно из-за OPC сервера. Вы не можете из СКАДы изменить параметры переменной. По этому параметры опроса. статус (чтение/запись) и т.д. и т.п. у вас определяются при конфигурации и изменеию не подлежат. Т.е. возникают програмные ограничения. Отсюда и приходится вам работать с программой контроллера. Тоже выход. Делали АСУ ТП для одного из заводов. Так специально для более гибкой настройки системы ставили на верхнем уровне мощные контроллеры и уже через них работали со СКАДой. Но я выполнял только "железную" часть проекта в тесном сотрудничестве с монтажной и наладочной организацией. Теперь то я понимаю, зачем такая конфигурация ими была задана.
Хотя в первом посту вы предлагали использовать кнопу переключения на "ручное управление",т.е. у вас было видение. как заставить интерфейс не перезаписывать переменную.

Реализовывали не единожды связки с MasterSCADA и ОРС Lectus с Modbus RTU Слейвами.

ОРС отвечал за циклическую передачу комманды записи Слейву лишь до того момента пока Слейв ее не исполнит/воспримет (о чем он и сообщает в ответе показывая примененные данные). После этого никакой циклической записи переменной не велось, по крайней мере до тех пор пока ее снова не изменят и пока не отпадет необходимость в циклических посылках (пока Слейв не ответит, что получил запром на запись).

много букв. може уже есть ответ.
надо
в любом месте
считать и лишь потом записать если была команда "фас"

скада ничего не пишет если ничего тне отдает опс-серверу.

Блин, прошу прощения Шайтан попутал. Сегодня поэкспериментировал - никаких манипуляций не надо - "кто последний тот и папа" по умолчанию... пол года назад эксперимнетировал с панелью и контроллером в качетсве мастера - была проблема. Сегодня подключил панель и паралельно скаду - все отлично и без всяких там изворотов. Видимо +45 ударили в голову (в смылсе +45 градусов тепла)..