Как организована передача сообщений (алармов, предупреждений и т.п.) с 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мс по умолчанию ?
|
|
|