УкраїнськаEnglishmRussian
Вхід/Новий
У темі немає нових постів

Как организована передача сообщений (алармов, предупреждений и т.п.) с PLC в скаду OpenSCADA?


Автор Повідомлення
Повідомлення створено: 02. 12. 2015 [13:25]
rockshox
Сергей Краев
Автор теми
Зареєстрован(а) с: 02.12.2015
Повідомлення: 4
Роман, скажите, как реализовали обмен сообщениями от PLC и скады? Ведь цикл контроллера 10-20мс, а скада под виндой явно медленнее опрашивает PLC.....Если работали со Step7, то есть функции SFB35 (alarm_8p, передача 8 сообщений в скаду ) и SFB37 (AR_SEND, передача архива сообщений), а у Вас как это реализовано? Вы набиваете в PLC в какой-то блок DB все сообщения, а скада с помощью функций libnodave читает их, так что-ли?
Повідомлення створено: 02. 12. 2015 [13:57]
roman
Roman Savochenko
Moderator
Contributor
Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
"rockshox" wrote:

Роман, скажите, как реализовали обмен сообщениями от PLC и скады? Ведь цикл контроллера 10-20мс, а скада под виндой явно медленнее опрашивает PLC.....Если работали со Step7, то есть функции SFB35 (alarm_8p, передача 8 сообщений в скаду ) и SFB37 (AR_SEND, передача архива сообщений), а у Вас как это реализовано? Вы набиваете в PLC в какой-то блок DB все сообщения, а скада с помощью функций libnodave читает их, так что-ли?

Да, я Вам говорил, всё через DB или Вы в документации что-то другое видели?

P.S. Не пишите сюда вопросы персонально на меня иначе я не буду отвечать, поскольку это фактически персональные консультации!

Learn, learn and learn better than work, work and work.
Повідомлення створено: 02. 12. 2015 [21:51]
rockshox
Сергей Краев
Автор теми
Зареєстрован(а) с: 02.12.2015
Повідомлення: 4
То что через DB сообщения появляются "наверху" это понятно из документации, я имел ввиду как организовано взаимодействие "запись -чтение"? Как Вы уходите от конфликтной ситуации? Скада и контроллер, как я понимаю, работают в асинхронном режиме, т.е. контроллер пихает появившиеся события в DB-блок (размер которого, очевидно, ограничен), а скада из этого блока их забирает. Но, допустим, в блок контроллер накидал события/сообщения и взвёл некий флаг в 1 (данные можно забирать), скада читает этот флаг и "увидев" 1 начинает считывать сообщения из блока и в какой-то момент пропадает связь между контроллером и скадой (свич отвалился, компьютер перегружается на котором вертится скада и т.п.). Как Вы обрабатываете эту ситуацию? Ведь к тому моменту, когда появится связь, контроллер накидает в блок (исходя из того что он ограничен по размеру - то он закольцован) кучу новых событий (которые перезатрут старые но ещё не прочитанные скадой) и откуда Ваша скада "знает" с какой позиции в блоке читать?
Повідомлення створено: 02. 12. 2015 [22:00]
roman
Roman Savochenko
Moderator
Contributor
Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
"rockshox" wrote:

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

Никак, потому как у меня нет таких задач и необходимости держать нарушения и сообщения на стороне ПЛК фирмы Siemens в принципе.

Learn, learn and learn better than work, work and work.
Повідомлення створено: 02. 12. 2015 [22:06]
rockshox
Сергей Краев
Автор теми
Зареєстрован(а) с: 02.12.2015
Повідомлення: 4
"roman" wrote:

Никак, потому как у меня нет таких задач и необходимости держать нарушения и сообщения на стороне ПЛК в принципе.
Всё ясно, хотя я ожидал другого ответа. Удачи!
Повідомлення створено: 03. 12. 2015 [08:13]
roman
Roman Savochenko
Moderator
Contributor
Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
"rockshox" wrote:

"roman" wrote:

Никак, потому как у меня нет таких задач и необходимости держать нарушения и сообщения на стороне ПЛК в принципе.
Всё ясно, хотя я ожидал другого ответа. Удачи!

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

В тоже время на ПЛК, основанных на OpenSCADA, можно и часто прозрачно держатся архивы нарушений, сообщений и значений со шлюзованием их на АРМ.

Learn, learn and learn better than work, work and work.
Повідомлення створено: 03. 12. 2015 [18:00]
rockshox
Сергей Краев
Автор теми
Зареєстрован(а) с: 02.12.2015
Повідомлення: 4
"roman" wrote:

как-будто у Вас ПЛК это исключительно Сименс и на нём свет клином сошёлся
Да, исключительно Siemens, поскольку на металлургическом заводе, на котором я работаю, автоматизация полностью на "плечах" у PLC Siemens, и ничего не могу с этим поделать:)
"roman" wrote:

это самые закрытые ПЛК
Ну у меня нет оснований Вам в этом не доверять, поэтому с этим с Вами соглашусь. А по поводу того закрытые они или не закрытые ПЛК - какая разница, важно лишь-то, что те решения, которые у сименса есть, работают безукоризненно, это факт! который подтвержается многолетней практикой их использования.
"roman" wrote:

В тоже время на ПЛК, основанных на OpenSCADA, можно и часто прозрачно держатся архивы нарушений, сообщений и значений со шлюзованием их на АРМ.
Что значит прозрачно держатся? Вы мне в позапрошлом ответе дали понять, что решения о сохранении сообщений (в ПЛК) при нештатных ситуация (потеря общения между ПЛК и OpenSCAD'ой) нет. Или я что-то упустил?
Повідомлення створено: 04. 12. 2015 [18:43]
fido_max
Maxim Kochetkov
Contributor
Зареєстрован(а) с: 28.10.2010
Повідомлення: 129
"rockshox" wrote:

Да, исключительно Siemens, поскольку на металлургическом заводе, на котором я работаю, автоматизация полностью на "плечах" у PLC Siemens, и ничего не могу с этим поделать:)

Сочувствую! :-)
"rockshox" wrote:

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

А закрытость встает боком тогда, когда оно вдруг начинает работать не так, как ты задумывал, а объяснить и понять это нет никакой возможности, т.к. что у него там внутри происходит - никому не известно. Или другой момент - нужно реализовать экзотическую фичу/подключить хитрое устройство, а в ответ слышишь: у нас поддержка таких устройств отсутствует, извините. Ни производитель помочь не может, ни ты сам реализовать не можешь.
"rockshox" wrote:

Что значит прозрачно держатся? Вы мне в позапрошлом ответе дали понять, что решения о сохранении сообщений (в ПЛК) при нештатных ситуация (потеря общения между ПЛК и OpenSCAD'ой) нет. Или я что-то упустил?

Это в случае если на ПЛК в качестве рантайма работает OpenSCADA.
Повідомлення створено: 14. 12. 2015 [13:16]
Specar
Александр Антуганов
Зареєстрован(а) с: 04.07.2014
Повідомлення: 20
скада под виндой

я что то пропустил ?

и в какой-то момент пропадает связь между контроллером и скадой


караул просто, вот у меня все плк сименс в кольце и БД с данными считывают панели управления сименс и винтек ну и опенскада конечно.

это самые закрытые ПЛК

а S1200 4 ревизии и S1500 вообще бида.

Ведь цикл контроллера 10-20мс


разве цикл не 150мс по умолчанию ?



0841