RSview 32 проблемы с сообщениями

[mall]

В АСУТП используются 2 машины как серверные и 7 как клиентские, т.е. серверы используют "RSlinx OPC server" обращаясь непосредственно к PLC (их много и разные), а клиентские через "RSlinx remote OPC server" обращаются уже к серверам. все по ethernet. Проблема в следующем: почему-то не все алармы дублируются на клиентских машинах. Некоторые да, а некоторые нет, закономерности по какому-то критерию я не нашел, может плохо искал... Есть у кого мысли по данному вопросу? Может кто-то сталкивался?

[Looker]

В АСУТП используются 2 машины как серверные и 7 как клиентские, т.е. серверы используют "RSlinx OPC server" обращаясь непосредственно к PLC (их много и разные)

RSView32 - древность, а при такой архитектуре стоит переходить на Factory Talk View SE, реальность перехода под cанкционным вопросом.

а клиентские через "RSlinx remote OPC server" обращаются уже к серверам.

Неудачная идея, причем обмен с тормозами (может в этом и беда). У Rockwell была рекомендация: не более трех RSLinx Classic для общения с контроллерами, если нужно больше стоит применить RSLinx Gateway (на серверах) - надежнее и быстрее.
С 32-го в FTView проекты переносятся, есть исключения, например: Native Trend.

[mall]

У Rockwell была рекомендация: не более трех RSLinx Classic для общения с контроллерами, если нужно больше стоит применить RSLinx Gateway (на серверах) - надежнее и быстрее.

Ну так оно сейчас так и работает. 2 geteway (на серверах) общаются с контроллерами, а на остальных стоит classic и обращаются они к серверам. На серверах тоже стоит RS view и там все норм, а вот клиенты почему-то недополучают алармы?! Алармы были реализованы не мной и очень давно. Опрос PLC работает примерно так: (написан кодом в vb script) сервер вычитывает msg на PLC и выставляет нужные уровни в аналоговых (memory) тэгах, где и прописаны алармы.

реальность перехода под cанкционным вопросом

вот именно, но там намного больше проблем... Железо старое ещё на XP, поэтому боремся с тем, что есть. К тому же, в системе порядка 30 PLC в том числе slc 500, а при переходе, по хорошему, надо переписывать все программы контроллеров!

[Looker]

Ну так оно сейчас так и работает. 2 classic (на серверах) общаются с контроллерами, а на остальных стоит gateway

Надо наоборот. Classic на клиентах и обращается к Gateway на серверах.

Опрос PLC работает примерно так: (написан кодом в vb script) сервер вычитывает msg на PLC и выставляет нужные уровни в аналоговых (memory) тэгах, где и прописаны алармы.

Дилетанты делали и это очень мягко про них.

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

Нет, но учитывая vb script и вычитывание из контроллера... Не берусь утверждать.
VB в 32-м и FTView - две громадные разницы и не переносится в FTView.

[mall]

Дилетанты делали и это очень мягко про них.

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

[Ryzhij]

как бы я сделал, чтобы аварийные сообщения накапливались в ПЛК до их вычитывания, то есть исключая возможность их потери.

Вообще-то обычно достаточно механизма обработки алармов типа "фиксация- подтверждение - сброс".
Что там у Вас намудрили, и почему, с Ваших слов, первый этап в ПЛК отсутствует, сие нам не ведомо.

[mall]

достаточно механизма обработки алармов типа "фиксация- подтверждение - сброс".

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

ну а по сути основного вопроса ни у кого нету мыслей, я полагаю?

[Ryzhij]

я имею ввиду когда (если) параметр выходит за пределы и возвращается обратно, в момент когда, по каким-то причинам серверы выключены или не в сети. именно для этого накопление и подтверждение считывания выполнено на уровне ПЛК.

Есть OPC-DA, OPC-A&E и есть OPC-HDA. Разные подходы к обработке данных.

[mall]

Есть OPC-DA, OPC-A&E и есть OPC-HDA. Разные подходы к обработке данных.

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

[Ryzhij]

Тогда начнём сначала.
Где, на каком уровне, у Вас генерируются алармы?
Где , в ПЛК (в их программе) или на АРМ-ах (в проектах RSView32) происходит сравнение сигнала с уставкой и после задержки формируется тревога?
Скажу сразу - кошерным является формирование признака тревоги в программе ПЛК. Там он фиксируется и сбрасывается уже с экранной кнопки на АРМ-е.
А как сделано у Вас?

[mall]

на каком уровне, у Вас генерируются алармы?

В ПЛК, там они формируются и выстраиваются в очередь.

[mall]

Сам принцип формирования алармов в программе ПЛК мне кажется логичным и правильным (по вышеупомянутым причинам), но есть нюансы:
- огород с кодом на VBscript (как это работает, прям досконально, до сих пор не понял, разбираться с чужим кодом весьма не приятно)
- непонятки с сообщениями на клиентах, они приходят выборочно
- последнее время в принципе начали появляться проблемы с алармами на серверах, иногда OPC затыкается и опрос просто прекращается в логе пишет OPC ERROR: bad quality, причем это происходит на обоих серверах. такое чувство, что что-то просто ложит всё OPC в сети на прочь, при этом данные на дисплеях отображаются и изменяются адекватно
- прочтение сообщения не равно подтверждению и не равно самому состоянию аларма, т.е. по сути 3 разные структуры (ну если что-то переделывать) так еще и вычитывать их нужно с 3х серверов по-отдельности
Есть вероятность, что просто приходит время сменить оборудование, ибо раньше все работало нормально. Возможно ошибки появились потому, что некоторое ПО стало конфликтовать: в одной системе находятся и W-XP и W-7, а соответственно и серверы RSLinx разных версий (2.51 и 4.11), но сразу когда "новые" АРМы поставили все работало нормально, конфликтов не было!

[mall]

иногда OPC затыкается и опрос просто прекращается

все что я смог найти в логах:

[+]

1677740066251.jpg

2.jpg

1.jpg