форум асутп
 На главную                       Здесь может быть Ваша реклама, подробнее...


 Наверх  |  Перейти к теме  |  Поиск  |  Вход  |  Дерево    
 Quality(OPC) in IEC 1131
Автор: Sergey Gazimagomedov 
Дата:   08.10.04 17:47

Hello, All!

Есть вопрос по использованию информации о качестве сигнала в OPC нотации.
Кто как интерпретирует эту информацию в алгоритмах на языках МЭК 1131 и в С++?

Интересует реакция на основное изменение (Good, Bad, Uncertain) и на другие флаги как реагируете?

With best regards, Sergey Gazimagomedov.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Quality(OPC) in IEC 1131
Автор: Shchekin Sergei I. 
Дата:   08.10.04 18:16

> -----Original Message-----
> From: Sergey Gazimagomedov [mailto:gsa@xxxxxx.xxxxxxx.xx]
> Sent: Friday, October 08, 2004 5:47 PM

> Есть вопрос по использованию информации о качестве сигнала в
> OPC нотации. Кто как интерпретирует эту информацию в
> алгоритмах на языках МЭК 1131 и в С++?

Уважаемый Сергей!
OPC обычно используется средствами человеко-машинного интерфейса (HMI), SCADA-системами и т.п. А на языках МЭК 1131 обычно программируются КОНТРОЛЛЕРЫ, непосредственно управляющие технологическим оборудованием. В этом случае контроллер НЕ ПОЛУЧАЕТ ниоткуда данные по OPC.

Контроллерам более свойственна диагностика исправности измерительного канала. Обычно проверяется исправность аналогового входного модуля (встроенными в ОС средствами диагностики), а также, например, вхождение сигнала в стандартный диапазон 4..20 мА. В случае обнаружения неисправности измерительного канала действия зависят от того, что это за канал, используется ли этот сигнал в регулировании или защите, есть ли дублирующие каналы, возможно ли косвенное вычисление сигнала (по значениям других сигналов) и т.д.

Так что "абстрактного" ответа здесь не может быть. Действия могут варьироваться от перевода регулятора в ручной режим до аварийного останова процесса. А реализация кода на МЭК 1131 или Си, я думаю, должна иметь один и тот же практический смысл.



С уважением,
Сергей Щекин
TRICONEX
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Quality(OPC) in IEC 1131
Автор: Sergey Gazimagomedov 
Дата:   08.10.04 18:55

>> Есть вопрос по использованию информации о качестве сигнала в
 >> OPC нотации. Кто как интерпретирует эту информацию в  алгоритмах на
 >> языках МЭК 1131 и в С++?

 SSI> Уважаемый Сергей!
 SSI> OPC обычно используется средствами человеко-машинного интерфейса
 SSI> (HMI), SCADA-системами и т.п. А на языках МЭК 1131 обычно
 SSI> программируются КОНТРОЛЛЕРЫ, непосредственно управляющие
 SSI> технологическим оборудованием. В этом случае контроллер НЕ ПОЛУЧАЕТ
 SSI> ниоткуда данные по OPC.

Обычно так, но сейчас большинство контроллеров имеют OPC сервер. Какую информацию вы туда (в OPC quality) записываете? т.е. в контроллере это качество создается. Понятно, что это отдано на усмотрение производителя.
Так нам и интересно, как вы это реализуете. Есть ли у вас вообще качество канала, если есть, что туда пишете.

 SSI> Контроллерам более свойственна диагностика исправности
 SSI> измерительного канала. Обычно проверяется исправность аналогового
 SSI> входного модуля (встроенными в ОС средствами диагностики), а также,
 SSI> например, вхождение сигнала в стандартный диапазон 4..20 мА. В
 SSI> случае обнаружения неисправности измерительного канала действия
 SSI> зависят от того, что это за канал, используется ли этот сигнал в
 SSI> регулировании или защите, есть ли дублирующие каналы, возможно ли
 SSI> косвенное вычисление сигнала (по значениям других сигналов) и т.д.

 SSI> Так что "абстрактного" ответа здесь не может быть. Действия могут
 SSI> варьироваться от перевода регулятора в ручной режим до аварийного
 SSI> останова процесса. А реализация кода на МЭК 1131 или Си, я думаю,
 SSI> должна иметь один и тот же практический смысл.

:) Абстрактный ответ я давно в OPC спецификации прочитал. Мне интересен именно конкретный.
Пример - зашкал. Кроме действий по технологии, вы этот факт в quality отражаете, чтобы системы верхнего уровня могли этой инфой воспользоваться?

With best regards, Sergey Gazimagomedov.
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Quality(OPC) in IEC 1131
Автор: Vladimir Konnov 
Дата:   09.10.04 23:30

Sergey Gazimagomedov писал(а):

> >> Есть вопрос по использованию информации о качестве сигнала в
>  >> OPC нотации. Кто как интерпретирует эту информацию в  алгоритмах на
>  >> языках МЭК 1131 и в С++?

>
> Обычно так, но сейчас большинство контроллеров имеют OPC сервер. Какую
> информацию вы туда (в OPC quality) записываете? т.е. в контроллере это
качество
> создается. Понятно, что это отдано на усмотрение производителя.
> Так нам и интересно, как вы это реализуете. Есть ли у вас вообще
качество
> канала, если есть, что туда пишете.
>

Ваш вопрос вызвал у меня нескрываемое любопытство. Поясните пожалуйста,
как Вы связываете между собой контекст МЭК 1131 и контекст OPC? OPC-сервер
всегда работает под виндами и предоставляет свои информационные каналы в
SCADA, например. Все известные мне OPC-сервера сами общаются с
контроллерами и сами выставляют качество. Не встречался с возможностью
манипулировать качеством. Из Ваших слов я понял, что в контроллере можно
управлять качеством, которое формирует OPC-сервер на компьютере клиента?

С уважением, Владимир Коннов.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Quality(OPC) in IEC 1131
Автор: Shchekin Sergei I. 
Дата:   11.10.04 11:17

> -----Original Message-----
> From: Sergey Gazimagomedov [mailto:gsa@xxxxxx.xxxxxxx.xx]
> Sent: Friday, October 08, 2004 6:55 PM

> Обычно так, но сейчас большинство контроллеров имеют OPC
> сервер. Какую информацию вы туда (в OPC quality) записываете?
> т.е. в контроллере это качество создается. Понятно, что это
> отдано на усмотрение производителя. Так нам и интересно, как
> вы это реализуете. Есть ли у вас вообще качество канала, если
> есть, что туда пишете.

Именно КАЧЕСТВА сигнала мы не формируем.


> :) Абстрактный ответ я давно в OPC спецификации прочитал. Мне
> интересен именно конкретный. Пример - зашкал. Кроме действий
> по технологии, вы этот факт в quality отражаете, чтобы
> системы верхнего уровня могли этой инфой воспользоваться?

Мы формируем флаг неисправности измерительного канала (дискретная переменная). Этот флаг читается системой АРМ оператора так же, как любая другая переменная контроллера. На основании значения этой переменной формируется предупредительный сигнал и анимируется окошко отображения аналогового сигнала (цвет, мигание).


С уважением,
Сергей Щекин
TRICONEX
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Quality(OPC) in IEC 1131
Автор: Oleg Alekseyev 
Дата:   11.10.04 15:07

----- Original Message -----
From: "Shchekin Sergei I."

>> Обычно так, но сейчас большинство контроллеров имеют OPC
>> сервер. Какую информацию вы туда (в OPC quality) записываете?
>> т.е. в контроллере это качество создается. Понятно, что это
>> отдано на усмотрение производителя. Так нам и интересно, как
>> вы это реализуете. Есть ли у вас вообще качество канала, если
>> есть, что туда пишете.

> Именно КАЧЕСТВА сигнала мы не формируем.

Видимо потому, что Вы не имеете собственного OPC сервера и предлагаете
пользовать то, что есть у Матрикона.
Спросим у Матрикона:
The Matrikon OPC Server for Triconex provides high-speed read and write access to the Triconex Tricon and Trident. The server supports all available point types, full communication redundancy and fail-over.
...

Tested and Proven with most of the Major DCS vendors.

Ага, значит есть возможность работы в составе DCS.
Их есть у меня. Имеется комплекс гидрокрекинга состоящий из трёх
территориально удалённых секций. В составе DCS есть HIMA,
Yokogawa и Triconex. По ряду обстоятельств в настоящий момент
связать все секции в единый комплекс можно только по OPC.

>> :) Абстрактный ответ я давно в OPC спецификации прочитал. Мне
>> интересен именно конкретный. Пример - зашкал. Кроме действий
>> по технологии, вы этот факт в quality отражаете, чтобы
>> системы верхнего уровня могли этой инфой воспользоваться?

> Мы формируем флаг неисправности измерительного канала (дискретная переменная). > Этот флаг читается системой АРМ оператора так же, как любая другая переменная
> контроллера. На основании значения этой переменной формируется
> предупредительный сигнал и анимируется окошко отображения аналогового сигнала
> (цвет, мигание).

Как обработать в Triconex сигнал, полученый по OPC с учётом его OPC-качества?

Best regards.
Oleg.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Quality(OPC) in IEC 1131
Автор: Shchekin Sergei I. 
Дата:   11.10.04 15:43

> -----Original Message-----
> From: Oleg Alekseyev [mailto:oleg@xxxxxx.xxxxxxx.xx]
> Sent: Monday, October 11, 2004 3:08 PM


> Видимо потому, что Вы не имеете собственного OPC сервера и предлагаете
> пользовать то, что есть у Матрикона.

Олег, я Вас не понял: то, что Вы сказали - это упрек нам (TRICONEX) или комплимент в пользу "международного капиталистического разделения труда"? Хорошо или плохо то, что мы своим клиентам рекомендуем OPC-сервер самого известного и (по-моему) самого надежного разработчика OPC-серверов?


> Спросим у Матрикона:
> The Matrikon OPC Server for Triconex provides high-speed read
> and write access to the Triconex Tricon and Trident. The
> server supports all available point types, full communication
> redundancy and fail-over.
> ...
>
> Tested and Proven with most of the Major DCS vendors.
>
> Ага, значит есть возможность работы в составе DCS.
> Их есть у меня. Имеется комплекс гидрокрекинга состоящий из трёх
> территориально удалённых секций. В составе DCS есть HIMA,
> Yokogawa и Triconex. По ряду обстоятельств в настоящий момент
> связать все секции в единый комплекс можно только по OPC.

Ну, и в чем проблема? Matrikon правильно все пишет.


> Как обработать в Triconex сигнал, полученый по OPC с учётом
> его OPC-качества?

Олег, TRICON по OPC НИЧЕГО и НИ ОТ КОГО НЕ ПОЛУЧАЕТ. Поэтому и обработать информацию о качестве не может (ну нет ее там!!!). OPC-сервер работает во ВНЕШНИХ (по отношению к контроллеру) системах, причем это должны быть системы под Windows. А собственно TRICON не является (слава Богу!) PC-совместимой машиной под Windows (не дай Бог!).

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

С уважением,
Сергей Щекин
TRICONEX
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Quality(OPC) in IEC 1131
Автор: Oleg Alekseyev 
Дата:   11.10.04 16:55

----- Original Message -----
From: "Shchekin Sergei I."

> Видимо потому, что Вы не имеете собственного OPC сервера и предлагаете
> пользовать то, что есть у Матрикона.

SS> Олег, я Вас не понял: то, что Вы сказали - это упрек нам (TRICONEX) или комплимент в пользу "международного капиталистического разделения труда"? Хорошо или плохо то, что мы своим клиентам рекомендуем OPC-сервер самого известного и (по-моему) самого надежного разработчика OPC-серверов?

Это не упрёк и не комплемент. Просто это (OPC) не ваша головная боль .

SS> Так что, прошу меня извинить, но я не понял, что Вы имели в виду своим вопросом. Поясните, пожалуйста.

Я хотел обратить внимание уважаемого сообщества на факт отсутствия сквозной
обработки качества сигналов (в том числе и в формате OPC) в системах проектирования
основанных на МЭК стандарте. И хотел услышать, кто как решает эту проблему. Так понятно?

С уважением.
Олег Алексеев.

P.S. "Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий."
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Quality(OPC) in IEC 1131
Автор: Ilya Ablin 
Дата:   11.10.04 17:43

Добрый день!

> Я хотел обратить внимание уважаемого сообщества на факт
> отсутствия сквозной обработки качества сигналов (в том числе
> и в формате OPC) в системах проектирования основанных на МЭК
> стандарте. И хотел услышать, кто как решает эту проблему. Так понятно?

На мой взгляд, есть три основных подхода.

1. Качество (достоверность) передается наверх в отдельных сигналах (не
всегда дискретных, иногда перечислимых).
2. Качество формирует OPC-сервер, иногда с учетом признаков достоверности,
заложенных в частнофирменный протокол, либо в предопределенные переменные.
3. Качество передается за счет того, что система является единой
(вертикально-интегрированной), как, например, наша (MasterSCADA) при
использовании поддерживаемых ее для программирования контроллеров, или ряд
DCS (только не надо, ради бога, вспоминать старые дискуссии об отличиях
DCS).

С уважением,
Аблин Илья
Компания ИнСАТ
mailto:ablin@xxxxx.xx
http://www.insat.ru
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Quality(OPC) in IEC 1131
Автор: Oleg Alekseyev 
Дата:   11.10.04 18:14

Hi,Ilya.
----- Original Message -----
From: "Ilya Ablin" <ablin@xxxxx.xx>

>
> > Я хотел обратить внимание уважаемого сообщества на факт
> > отсутствия сквозной обработки качества сигналов (в том числе
> > и в формате OPC) в системах проектирования основанных на МЭК
> > стандарте. И хотел услышать, кто как решает эту проблему. Так понятно?
>
> На мой взгляд, есть три основных подхода.
>
> 1. Качество (достоверность) передается наверх в отдельных сигналах (не
> всегда дискретных, иногда перечислимых).

Интересует, как передать в контроллер информацию, что внешний по отношению
к контроллеру сигнал некондиционный, и какова будет (должна быть) его (контроллера) реакция?

> 2. Качество формирует OPC-сервер, иногда с учетом признаков достоверности,
> заложенных в частнофирменный протокол, либо в предопределенные переменные.

Если мне ни с кем не изменяет память, в мире есть такое чудо, как OPCbridge, передающий выходные сигналы с одного OPC сервера на другой. Что происходит при этом с качеством?
http://www.softwaretoolbox.com/store/item_pages/itempage_940.asp

> 3. Качество передается за счет того, что система является единой
> (вертикально-интегрированной), как, например, наша (MasterSCADA) при
> использовании поддерживаемых ее для программирования контроллеров, или ряд
> DCS (только не надо, ради бога, вспоминать старые дискуссии об отличиях
> DCS).

И какова реакция функционального блока, если на его вход приходит некондиционный сигнал?

Best regards.
Oleg.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Quality(OPC) in IEC 1131
Автор: Ilya Ablin 
Дата:   11.10.04 18:39

Добрый день!


> Интересует, как передать в контроллер информацию, что внешний
> по отношению к контроллеру сигнал некондиционный, и какова
> будет (должна быть) его (контроллера) реакция?

Откуда передать? Простейший способ - через переменную, реакция зависит от
проектировщика данной системы в соответствии со степенью фатальности данной
некондиционности. Например, некондиционность может быть учтена в
блокировках, переводящих систему в безопасное состояние.

> > 2. Качество формирует OPC-сервер, иногда с учетом признаков
> > достоверности, заложенных в частнофирменный протокол, либо
> в предопределенные переменные.
>
> Если мне ни с кем не изменяет память, в мире есть такое чудо,
> как OPCbridge, передающий выходные сигналы с одного OPC
> сервера на другой. Что происходит при этом с качеством?
> http://www.softwaretoolbox.com/store/item_pages/itempage_940.asp

Оно передается вместе с каждой переменной, так как является ее неотъемлимой
частью.

> И какова реакция функционального блока, если на его вход
> приходит некондиционный сигнал?

Решение принимает (и документирует) разработчик блока в соответствии со
значимостью сигнала для результата, а также с тем, какой именно признак
качества плох.

С уважением,
Аблин Илья
Компания ИнСАТ
mailto:ablin@xxxxx.xx
http://www.insat.ru
Адрес этого сообщения    Ответить на это сообщение
 
 Ответ: Re: Quality(OPC) in IEC 1131
Автор: Nikolay Naumov 
Дата:   12.10.04 06:12

Здравствуйте, Олег!

>>>Я хотел обратить внимание уважаемого сообщества на факт отсутствия сквозной
обработки качества сигналов (в том числе и в формате OPC) в системах проектирования
основанных на МЭК стандарте. И хотел услышать, кто как решает эту проблему. Так понятно?
..............

У меня в ISaGRAF  по каждому аналоговому параметру используются три переменных:
1.Вещесвенная.   Передача на  SCADA значения параметра.
2  Целая.              Передача на  SCADA набора битов, характеризующих качество.
3. Целая.              Получение от SCADA набора битов, управляющего обработкой параметра.

Это то что Вы хотели услышать?





 --
С уважением
Николай Наумов
Инженер-программист АСУТП
Уральский алюминиевый завод
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Quality(OPC) in IEC 1131
Автор: Oleg Alekseyev 
Дата:   12.10.04 10:33

Hi, Ilya.

----- Original Message -----
From: "Ilya Ablin"
>
> > Интересует, как передать в контроллер информацию, что внешний
> > по отношению к контроллеру сигнал некондиционный, и какова
> > будет (должна быть) его (контроллера) реакция?
>
> Откуда передать? Простейший способ - через переменную, реакция зависит от
> проектировщика данной системы в соответствии со степенью фатальности данной
> некондиционности. Например, некондиционность может быть учтена в
> блокировках, переводящих систему в безопасное состояние.

Год назад в славном городе Брно собрались перед экраном монитора
киповец, инженер АСУ, програмист и системный интегратор пораскинуть
мозгами над реализацией программы управления блокировками.
Накидали на экран десяток функциональных блоков, обвязали их связями
и довольные собой стали попивать кофею. Киповец почесал затылок и
выдал вводную:
- А у меня концевик залип. - Накидали ещё десяток элементов.
- А у меня обрыв термопары. - Поставили мультиплексор на резерв.
- А вторую забрали метрологи. - Программа уже не умещается на двух экранах.
- А этот козёл опять на кнопку невовремя сел. - ДА ТАК НЕ БЫВАЕТ!

К чему это всё - если качество сигнала является неотъемлемым атрибутом
самого сигнала, зачем плодить сущности (переменные). Не логичнее было бы
учитывать качество во всех функциональных блоках? К примеру, имеем
блок "ЛОГИЧЕСКОЕ И".  При сквозном учитывании качества сигнала, атрибут
качества выходного сигнала тоже должен обсчитываться как "И" качества
входных.

> > > 2. Качество формирует OPC-сервер, иногда с учетом признаков
> > > достоверности, заложенных в частнофирменный протокол, либо
> > в предопределенные переменные.
> >
> > Если мне ни с кем не изменяет память, в мире есть такое чудо,
> > как OPCbridge, передающий выходные сигналы с одного OPC
> > сервера на другой. Что происходит при этом с качеством?
> > http://www.softwaretoolbox.com/store/item_pages/itempage_940.asp
>
> Оно передается вместе с каждой переменной, так как является ее неотъемлимой
> частью.

И что далее с этой неотъемлемой частью будет делать контроллер?

> > И какова реакция функционального блока, если на его вход
> > приходит некондиционный сигнал?
>
> Решение принимает (и документирует) разработчик блока в соответствии со
> значимостью сигнала для результата, а также с тем, какой именно признак
> качества плох.

В документации я этого не нашёл.

 С уважением,
Олег Алексеев.
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Ответ: Re: Quality(OPC) in IEC 1131
Автор: Oleg Alekseyev 
Дата:   12.10.04 10:54

----- Original Message -----
From: "Nikolay Naumov"


 Здравствуйте, Nikolay.
>
> >>>Я хотел обратить внимание уважаемого сообщества на факт отсутствия сквозной
> обработки качества сигналов (в том числе и в формате OPC) в системах проектирования
> основанных на МЭК стандарте. И хотел услышать, кто как решает эту проблему. Так понятно?
> ..............
>
> У меня в ISaGRAF  по каждому аналоговому параметру используются три переменных:
> 1.Вещесвенная.   Передача на  SCADA значения параметра.
> 2  Целая.              Передача на  SCADA набора битов, характеризующих качество.
> 3. Целая.              Получение от SCADA набора битов, управляющего обработкой параметра.
>
> Это то что Вы хотели услышать?
>
Меня интересует больше проблема как передать качество с контроллера на контроллер
и что потом с этим качеством делать.
По нашей просьбе разработчики Ш9327 загнали качество канала в само значение
сигнала по каналу. Так стало намного проще подключить Ш9327 к Yokogawa.

Oleg.
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Quality(OPC) in IEC 1131
Автор: Vladimir Konnov 
Дата:   12.10.04 11:34

Oleg Alekseyev писал(а):

> Интересует, как передать в контроллер информацию, что внешний по
отношению
> к контроллеру сигнал некондиционный, и какова будет (должна быть) его
> (контроллера) реакция?
>
> > 2. Качество формирует OPC-сервер, иногда с учетом признаков
достоверности,
> > заложенных в частнофирменный протокол, либо в предопределенные
переменные.
>
> Если мне ни с кем не изменяет память, в мире есть такое чудо, как
OPCbridge,
> передающий выходные сигналы с одного OPC сервера на другой. Что
происходит при
> этом с качеством?
> http://www.softwaretoolbox.com/store/item_pages/itempage_940.asp

>
> И какова реакция функционального блока, если на его вход приходит
некондиционный
> сигнал?

Олег, думаю, Вам надо понять спецификацию OPC. Посмотрел Вашу ссылку на
OPCbridge. Мне кажется, что он к Вашим вопросам не имеет отношения.
Почувствуйте отличия двух вариантов: 1)OPC-OPC и 2)OPC-PLC. В первом
случае, качество уже сформировано одним из участников
процесса-OPC-сервером, и логично предположить, что делать с ним уже ничего
не надо, надо только один к одному передать. Это случай OPCbridge. Во
втором, Его надо сформировать. И вот тут-то и проблема(правда, не имеющая
отношения к OPC). Спецификация OPC ничего не говорит о том, как будет
формироваться это качество. Предполагается, что разработчик OPC-сервера
сам позаботится об этом. Если Вы не разработчик, то это не Ваша забота. То
есть, разработчик, с точки зрения спецификации, не обязан предоставлять
пользователю возможность манипулировать качеством. И в контроллер,
передаются только сигналы с качеством GOOD. Предполагается, что PLC-это
конечная точка, которая уже ничего не преобразовывает при записи.

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

И последний, самый надёжный вариант- напишите свой OPC-сервер для Вашего
контроллера и у Вас всё будет под контролем. Готовые решения- это всегда
ширпотреб, расчитанный на удовлетворение большинства потребностей
большинства пользователей. Прогни мир под себя! Будь самим собой!

С уважением, Владимир Коннов.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Quality(OPC) in IEC 1131
Автор: Shchekin Sergei I. 
Дата:   12.10.04 12:09

> -----Original Message-----
> From: Oleg Alekseyev [mailto:oleg@xxxxxx.xxxxxxx.xx]
> Sent: Tuesday, October 12, 2004 10:33 AM


> К чему это всё - если качество сигнала является неотъемлемым атрибутом
> самого сигнала, зачем плодить сущности (переменные). Не
> логичнее было бы
> учитывать качество во всех функциональных блоках? К примеру, имеем
> блок "ЛОГИЧЕСКОЕ И".  При сквозном учитывании качества
> сигнала, атрибут
> качества выходного сигнала тоже должен обсчитываться как "И" качества
> входных.

Уважаемый Олег, хочу обратить Ваше внимание на то, что понятие "качество" применительно к OPC-серверу имеет абсолютно однозначный смысл: это качество ИНФОРМАЦИОННОГО ОБМЕНА с контроллером или другим устройством, выраженное в атрибуте переменной OPC-сервера. Ни к измерительному каналу в контроллере, ни к логике контроллера это качество никакого отношения не имеет. Вы абсолютно правы в том смысле, что действительно есть проблема анализа ДОСТОВЕРНОСТИ измерений в контроллере. Но это отдельная песня, НИКАК не связанная с OPC.

С уважением,
Сергей Щекин
TRICONEX
Адрес этого сообщения    Ответить на это сообщение
 
 Re[2]: Quality(OPC) in IEC 1131
Автор: Alexander Burmistrov 
Дата:   12.10.04 12:22

Hello Shchekin,

SSI> хочу обратить Ваше внимание на то, что
SSI> понятие "качество" применительно к OPC-серверу имеет абсолютно
SSI> однозначный смысл: это качество ИНФОРМАЦИОННОГО ОБМЕНА с
SSI> контроллером или другим устройством

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

С уважением,
Александр Бурмистров.
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Quality(OPC) in IEC 1131
Автор: Oleg Alekseyev 
Дата:   12.10.04 12:32

Hi, Vladimir.

----- Original Message -----
From: "Vladimir Konnov"

> Почувствуйте отличия двух вариантов: 1)OPC-OPC и 2)OPC-PLC. В первом
> случае, качество уже сформировано одним из участников
> процесса-OPC-сервером, и логично предположить, что делать с ним уже ничего
> не надо, надо только один к одному передать.

Почувствуйте отличие третьего варианта  PLC-OPC-нЕчто-OPC-PLC от первых двух.
К примеру, я имею два территориально разнесённых контроллера, имею OPC сервера
для этих контроллеров и имею линию связи, по которой могу передавать данные
только в формате OPC. Как мне сообщить второму контроллеру, что в первом
контроллере входной сигнал некондиционный?

>  Предполагается, что разработчик OPC-сервера
> сам позаботится об этом. Если Вы не разработчик, то это не Ваша забота. То
> есть, разработчик, с точки зрения спецификации, не обязан предоставлять
> пользователю возможность манипулировать качеством. И в контроллер,
> передаются только сигналы с качеством GOOD. Предполагается, что PLC-это
> конечная точка, которая уже ничего не преобразовывает при записи.

На мой взгляд, неправильно ПРЕДПОЛАГАЕТСЯ.

> И последний, самый надёжный вариант- напишите свой OPC-сервер для Вашего
> контроллера и у Вас всё будет под контролем. Готовые решения- это всегда
> ширпотреб, расчитанный на удовлетворение большинства потребностей
> большинства пользователей. Прогни мир под себя! Будь самим собой!

Анекдот:
- Милый. Я ходила к доктору. Он сказал мне, что у нас опять не получилось
зачать наследника.
- О Боже! Опять эти нелепые телодвижения!

"...Опять эти нелепые телодвижения..." c C++ ;-)

С уважением
Олег Алексеев.
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Quality(OPC) in IEC 1131
Автор: Oleg Alekseyev 
Дата:   12.10.04 12:43

----- Original Message -----
From: "Shchekin Sergei I."

> К чему это всё - если качество сигнала является неотъемлемым атрибутом
> самого сигнала, зачем плодить сущности (переменные). Не
> логичнее было бы
> учитывать качество во всех функциональных блоках? К примеру, имеем
> блок "ЛОГИЧЕСКОЕ И".  При сквозном учитывании качества
> сигнала, атрибут
> качества выходного сигнала тоже должен обсчитываться как "И" качества
> входных.

SS> Уважаемый Олег, хочу обратить Ваше внимание на то, что понятие "качество" применительно к OPC-серверу имеет абсолютно однозначный смысл: это качество ИНФОРМАЦИОННОГО ОБМЕНА с контроллером или другим устройством, выраженное в атрибуте переменной OPC-сервера. Ни к измерительному каналу в контроллере, ни к логике контроллера это качество никакого отношения не имеет.

Согласен. Качество OPC в контексте следует рассматривать только как пример реализации категории "ДОСТОВЕРНОСТЬ".

SS> Вы абсолютно правы в том смысле, что действительно есть проблема анализа ДОСТОВЕРНОСТИ измерений в контроллере. Но это отдельная песня, НИКАК не связанная с OPC.

И это, на мой взгляд, одно из самых узких мест систем разработки, основанных на МЭК-стандарте. ;-)

С уважением,
Олег Алексеев.
Адрес этого сообщения    Ответить на это сообщение
 
 Re[2]: Quality(OPC) in IEC 1131
Автор: Alexander Burmistrov 
Дата:   12.10.04 12:41

Hello Oleg,

OA> Почувствуйте отличие третьего варианта  PLC-OPC-нЕчто-OPC-PLC от первых двух.
OA> К примеру, я имею два территориально разнесённых контроллера, имею OPC сервера
OA> для этих контроллеров и имею линию связи, по которой могу передавать данные
OA> только в формате OPC. Как мне сообщить второму контроллеру, что в первом
OA> контроллере входной сигнал некондиционный?

Тут важно, чтобы связка OPC-сервер-PLC умела отрабатывать эту
ситуацию. Чего наверняка будет только там, где разработчики специально
над этим работали, и наделили свой OPC-сервер и свой контроллер такими
возможностями. Иначе - все бессмысленно.

С уважением,
Александр Бурмистров.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Quality(OPC) in IEC 1131
Автор: Shchekin Sergei I. 
Дата:   12.10.04 13:29

> -----Original Message-----
> From: Oleg Alekseyev [mailto:oleg@xxxxxx.xxxxxxx.xx]
> Sent: Tuesday, October 12, 2004 12:44 PM

> SS> Вы абсолютно правы в том смысле, что действительно есть проблема
> SS> анализа ДОСТОВЕРНОСТИ измерений в контроллере. Но это отдельная
> SS> песня, НИКАК не связанная с OPC.
>
> И это, на мой взгляд, одно из самых узких мест систем
> разработки, основанных на МЭК-стандарте. ;-)

Олег, мы вернулись к тому, с чего началось обсуждения этой темы (прочитайте, пожалуйста, вопрос С.Газимагомедова от 8.10.2004 и мой ответ в тот же день). Проблема [достоверности] ЕСТЬ, но она имеет абсолютно одинаковый практический смысл ВНЕ зависимости от языка программирования (Си или МЭК 1131).

С уважением,
Сергей Щекин
TRICONEX
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[2]: Quality(OPC) in IEC 1131
Автор: Valentin Anoprenko 
Дата:   12.10.04 15:46

Здравствуйте.

> SSI> хочу обратить Ваше внимание на то, что
> SSI> понятие "качество" применительно к OPC-серверу имеет абсолютно
> SSI> однозначный смысл: это качество ИНФОРМАЦИОННОГО ОБМЕНА с
> SSI> контроллером или другим устройством
>
> Смею предположить, что это не вся возможная область применения
> качества тегов OPC. Ничто не мешает использовать их и для того,
> чтобы сигнализировать об ошибочных ситуациях в процессе внутренней
> обработки информации контроллером.

И не только. Я, например, заложил в качество тегов признак
недостоверности соответствующего параметра (обрыв цепи датчика,
например).

---
С уважением,
Валентин Анопренко
НПФ "Система-Сервис"
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Quality(OPC) in IEC 1131
Автор: vladimirkonnov 
Дата:   13.10.04 12:07

Прошу прощения, что задержался с репликой. iprog
интерфейс к форуму
совсем у меня перестал работать и я не
сразу заметил.:(

"Shchekin Sergei I." wrote:

> Уважаемый Олег, хочу обратить Ваше внимание на
то, что
понятие "качество" применительно к OPC-серверу
имеет абсолютно
однозначный смысл: это качество ИНФОРМАЦИОННОГО
ОБМЕНА с контроллером
или другим устройством, выраженное в атрибуте
переменной OPC-сервера.
Ни к измерительному каналу в контроллере, ни
к логике контроллера это
качество никакого отношения не имеет.

Ничего подобного! Где Вы это прочитали? Вы
спецификацию смотрели
OPCDA2.0? На качество сигнала может оказать влияние
не только
коммуниникации, но и что угодно, в том числе
и логика контроллера.
Это что же, по Вашему, получается, если связь
есть, то качество
хорошее?!

Цитирую OPCDA2.0:
"
Substatus for BAD Quality:
...
Sensor Failure A sensor failure had been detected (the
'Limits'
field can provide additional diagnostic information in some
situations.)
...

Substatus for UNCERTAIN Quality:
...
Sensor Not Accurate
Either the value has `pegged' at one of the sensor limits (in
which
case the limit field should be set to 1 or 2) or the sensor is
otherwise known to be out of calibration via some form of internal
diagnostics (in which case the limit field should be 0).

Engineering Units Exceeded
The returned value is outside the limits defined for this parameter.
Note that in this case (per the Fieldbus Specification) the
`Limits'
field indicates which limit has been exceeded but does NOT
necessarily imply that the value cannot move farther out of range.

Sub-Normal
The value is derived from multiple sources and has less than the
required number of Good sources.
...
"

С уважением, Владимир Коннов.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re: Quality(OPC) in IEC 1131
Автор: Shchekin Sergei I. 
Дата:   13.10.04 13:21

> -----Original Message-----
> From: vladimirkonnov [mailto:konnov@xxxxx.xxx.xx]
> Sent: Wednesday, October 13, 2004 12:07 PM

> Ни к измерительному каналу в контроллере, ни
> к логике контроллера это
> качество никакого отношения не имеет.
>
> Ничего подобного! Где Вы это прочитали? Вы
> спецификацию смотрели
> OPCDA2.0?

Честно признаюсь: спецификацию OPCDA2.0 в оригинале не смотрел... :-( Изучал другие материалы (статьи и книги).


> Это что же, по Вашему, получается, если связь
> есть, то качество
> хорошее?!

Мы обычно в тех случаях, когда отказ или потеря точности датчика может иметь серьезные последствия, формируем ОТДЕЛЬНЫЕ переменные СОСТОЯНИЯ сигнала, которые читаются из контроллера OPC-сервером, как и  само ЗНАЧЕНИЕ переменной (сигнала). Причем бывает и так, что на одну переменную-значение приходится БОЛЕЕ ОДНОЙ переменной состояния. Кроме того, мы часто используем резервированные схемы измерения, когда на одну переменную "работают" несколько датчиков. Например, для измерения температуры в камере сгорания газовой турбины могут стоять 2 "запараллеленные" термопары, т.е. 1 сигнал. А могут и 3 отдельных термопары. Или даже 12 термопар. Я их обрабатываю по определенному алгоритму и вывожу ОДНО значение, которое может зависеть и от числа работоспособных термопар, и от мест их установки, и еще от других причин. Это как пример того, что, к сожалению, универсальный механизм формирования качества годится только для простых случаев и "однородных" систем измерения (1 датчик - 1 переменная).

Поэтому в практическом смысле (т.е. в соответствии с моим опытом) - да, достаточно качества связи, поскольку это имеет свое ПРАКТИЧЕСКОЕ и СТРОГОЕ значение. А остальные ситуации изменения КАЧЕСТВА ИЗМЕРЕНИЯ мы обрабатываем по-разному в каждом случае.

Кроме того, уж больно разные возможности диагностики СВОЕГО железа имеют разные контроллеры. Причем даже разные контроллеры ОДНОЙ фирмы и разные МОДУЛИ для одного контроллера. Так что про универсальность такого показателя качества можно забыть. А стандарт, по-моему, должен быть универсальным. Это мое личное мнение.


С уважением,
Сергей Щекин
TRICONEX
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Ответ: Re: Quality(OPC) in IEC 1131
Автор: Vladimir Konnov 
Дата:   14.10.04 10:38

Приветствую, Алексей!

Oleg Alekseyev писал(а):

> Меня интересует больше проблема как передать качество с контроллера на
> контроллер
> и что потом с этим качеством делать.

А нужно-ли Вам это "качество"? Может и проблема отпадёт. Или Вы
интересуетесь, что из этого можно получить теоретически?

> По нашей просьбе разработчики Ш9327 загнали качество канала в само
значение
> сигнала по каналу. Так стало намного проще подключить Ш9327 к Yokogawa.

:) Ну так, в этом случае, качество абсолютно прозрачно передаётся через
Бридж и уровень OPC-OPC, и само OPC, уже к нему не имеет никакого
отношения. Я бы даже сказал, что такая концепция работы с качеством
противоречит OPC. Где значение- это значение, а качество этого значения-
это качество, и передаётся по независимому каналу.

Мне кажется, что качество сигнала предназначено скорее для верхнего
уровня, где существует много альтернатив принятия решений и развитые
средства обработки. В отличие от контроллера. Железный контроллер должен
железно работать. А качество, напоминает мне нечёткую логику, где число
возможных состояний больше двух.

Вам стоит отталкиваться от Вашей задачи. Ну зачем может понадобиться в
контроллере сигнал, пришедший из другого контроллера и имеющий качество,
отличное от GOOD? Такую обработку лучше поручить верхнему уровню.

С уважением, Владимир Коннов.

PS :) а, вот, по поводу написания своего OPC- сервера, Вы напрасно
сиронизировали. Сейчас бы сами управляли всем процессом. Кстати, очень
интересно, если Yokogawa загоняет качество сигнала в его значение, то как
с этим сигналом работает Yokogaw-овский OPC-сервер? Он что фильтрует это
качество, а по OPC выдаёт уже чистое значение?
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Ответ: Re: Quality(OPC) in IEC 1131
Автор: Oleg Alekseyev 
Дата:   14.10.04 12:15

Hi, Vladimir.

----- Original Message -----
From: "Vladimir Konnov"
>
> Приветствую, Алексей!
>
> Oleg Alekseyev писал(а):
^^^^^^^^^

> > Меня интересует больше проблема как передать качество с контроллера на
> > контроллер
> > и что потом с этим качеством делать.
>
> А нужно-ли Вам это "качество"? Может и проблема отпадёт. Или Вы
> интересуетесь, что из этого можно получить теоретически?

Меня интересует, как это реализовать практически в реальном проекте
с минимальными затратами и понятно даже электрику Пупкину.

> Я бы даже сказал, что такая концепция работы с качеством
> противоречит OPC. Где значение- это значение, а качество этого значения-
> это качество, и передаётся по независимому каналу.
> Мне кажется, что качество сигнала предназначено скорее для верхнего
> уровня, где существует много альтернатив принятия решений и развитые
> средства обработки.

Выбирая арбуз на рынке Вы интересуетесь не только его весом-ценой, но и его
качеством, поскольку это его ОСНОВНОЙ атрибут, определяющий потребительские
свойства. Уподоблю ваш организм контроллеру, а врача, анализирующего Ваши
испражнения c альтернативами принятия решений и развитыми средствами
обработки - системе верхнего уровня. Кому ВАЖНЕЕ знать о качестве продукта?
Или это совковый пережиток - не интересоваться сроком годности продукта?
 ;-)
 Кроме МастерСкады я не припомню, где в логике принятия решений
можно обрабатывать качество. Да и в МастерСкаде это только
декларируется, но не описано детально.

> В отличие от контроллера. Железный контроллер должен железно работать.

Это вы железу скажите. Всё что может сломаться обязательно сломается.
Можно говорить только о вероятности исправности железа - скорее
работает, чем поломалось. Опять нечёткая логика. ;-)

> А качество, напоминает мне нечёткую логику, где число
> возможных состояний больше двух.

И в чём проблема работы с нечёткой логикой? Имеем отсечной клапан с друмя
концевиками. Каков набор его состояний?
1. Открыт. По видимиму.
2. Закрыт. По видимому.
3. Открывается. Нечётко.
4. Закрывается. Нечётко.
5. Заклинил в промежуточном положении. Нечётко.
6. ХЕЗ - это когда сработали оба концевика. Однозначно!
Вы обрабатываете все его состояния, или только первых два?

> Вам стоит отталкиваться от Вашей задачи. Ну зачем может понадобиться в
> контроллере сигнал, пришедший из другого контроллера и имеющий качество,
> отличное от GOOD? Такую обработку лучше поручить верхнему уровню.

У меня есть контролируемый параметр с двумя датчиками. Один датчик
заведен в Triconex, другой в Yokogawa. Triconex реализует блокировки,
Yokogawa управляет процессом. Если Triconex обнаружил неисправность
своего датчика, он должен пользовать значение, полученное в Yokogawa,
и наоборот. Как с минимальными затратами на реализацию логики сообщить
контроллеру, что используемый им сигнал с другого контроллера достоверен?
И если недостоверен, как автоматизировать процесс принятия дальнейшего
решения?

> PS :) а, вот, по поводу написания своего OPC- сервера, Вы напрасно
> сиронизировали. Сейчас бы сами управляли всем процессом.

Да пописываем мы серверы, куда от этого денешься. НО НЕ OPC!

>  Кстати, очень
> интересно, если Yokogawa загоняет качество сигнала в его значение, то как
> с этим сигналом работает Yokogaw-овский OPC-сервер? Он что фильтрует это
> качество, а по OPC выдаёт уже чистое значение?

У Yokogawa во внуртеннем представлении качество входных сигналов имеет
более десятка состояний. OPC сервер предоставляет пользователю самому сопоставить соответствие внутреннего представления с качеством в формате OPC. А вот как учитывается в программировании логики - не знаю.

Best regards.
Oleg.
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Ответ: Re: Quality(OPC) in IEC 1131
Автор: Oleg Alekseyev 
Дата:   14.10.04 13:07

----- Original Message -----
From: "Shchekin Sergei I."

> ...Если Triconex обнаружил неисправность
> своего датчика, он должен пользовать значение, полученное в Yokogawa,

SS> Простите, не понял. Это Ваше ЛИЧНОЕ мнение? Или мнение Triconex? Или мнение Yokogawa?
SS> Я, возможно, не в том Triconex работаю, но еще не разу не встречал такой ПАЗ, где в БЛОКИРОВКАХ участвует сигнал, который внешняя (по отношению к TRICON) система "сует" туда (в TRICON) по OPC.
SS> Здесь СТОЛЬКО нарушений, и ТАКИХ... Одновременно нарушены и ПБ-09-540-03, и IEC 61508, и много чего еще.
SS> Для получения КРИТИЧЕСКИХ (связанных с безопасностью) данных из другого контроллера (тоже TRICON) у Triconex есть свой коммуникационный протокол (Peer-to-Peer). И никаких OPC сюда близко нельзя подпускать!

Успокойтесь, по OPC Triconex c Yokogawa мы не связываем. Хотелось бы связать
две Yokogawa.
"Всё смешалось в доме Облонских" ;-)

С уважением,
Олег Алексеев.
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Ответ: Re: Quality(OPC) in IEC 1131
Автор: Vladimir Konnov 
Дата:   14.10.04 13:15

Oleg Alekseyev писал(а):

> Hi, Vladimir.

...

> Best regards.
> Oleg.

Извините что побеспокоил.

Владимир Коннов.
PS И ходють и ходють.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Ответ: Re: Quality(OPC) in IEC 1131
Автор: Shchekin Sergei I. 
Дата:   14.10.04 12:53

> -----Original Message-----
> From: Oleg Alekseyev [mailto:oleg@xxxxxx.xxxxxxx.xx]
> Sent: Thursday, October 14, 2004 12:16 PM


> ...Если Triconex обнаружил неисправность
> своего датчика, он должен пользовать значение, полученное в Yokogawa,

Простите, не понял. Это Ваше ЛИЧНОЕ мнение? Или мнение Triconex? Или мнение Yokogawa?
Я, возможно, не в том Triconex работаю, но еще не разу не встречал такой ПАЗ, где в БЛОКИРОВКАХ участвует сигнал, который внешняя (по отношению к TRICON) система "сует" туда (в TRICON) по OPC.
Здесь СТОЛЬКО нарушений, и ТАКИХ... Одновременно нарушены и ПБ-09-540-03, и IEC 61508, и много чего еще.

Для получения КРИТИЧЕСКИХ (связанных с безопасностью) данных из другого контроллера (тоже TRICON) у Triconex есть свой коммуникационный протокол (Peer-to-Peer). И никаких OPC сюда близко нельзя подпускать!

С уважением,
Сергей Щекин
TRICONEX
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Ответ: Re: Quality(OPC) in IEC 1131
Автор: Vladimir Konnov 
Дата:   14.10.04 14:27

Shchekin Sergei I. писал(а):

>
> > Успокойтесь, по OPC Triconex c Yokogawa мы не связываем.
>
> Спасибо, что успокоили. :-)))

Сергей, речь, похоже, идёт о связи двух Yokogaw по OPC.:)

С уважением, Владимир Коннов.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Ответ: Re: Quality(OPC) in IEC 1131
Автор: Shchekin Sergei I. 
Дата:   14.10.04 13:24

> -----Original Message-----
> From: Oleg Alekseyev [mailto:oleg@xxxxxx.xxxxxxx.xx]
> Sent: Thursday, October 14, 2004 1:08 PM


> Успокойтесь, по OPC Triconex c Yokogawa мы не связываем.

Спасибо, что успокоили. :-))) А я уж чуть было ни кинулся искать предприятия, где Вы могли такую "гениальную" идею на практике применить. Людей, знаете ли, жалко. Жертвы могли быть. ;-)))

С уважением,
Сергей Щекин
TRICONEX
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Ответ: Re: Quality(OPC) in IEC 1131
Автор: Мария Савина 
Дата:   19.06.23 11:38

Добрый день!

Вопрос по теме формирования качества OPC тега, подскажите, пожалуйста, каким образом ОРС сервер определяет качество ОРС тега в каждый момент? Есть какой-то четкий алгоритм, описанный в спецификации ОРС, или каждый разработчик ОРС-сервера по своему делает?

Вот перечень возможных вариантов качества, интересует при каких условиях присваивается то или иное значение качества тега.

https://simplight.ru/kachestvo-ops-tegov/?ysclid=lhvqbwunv2303268519
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Quality(OPC) in IEC 1131
Автор: Алексей Угрюмов 
Дата:   19.06.23 12:00

Здравствуйте,


полная таблица

https://honeywellprocess.my.site.com/opcsupport/s/article/What-are-the-OPC-Quality-Codes

я всегда ставил 192, если ок, 0 если не ок.

То есть вопрос не понятен: ставьте флаг в соответствии с описанием. Есть значение достоверное - 192 ( ну понятно, что можно 193, 194, 195, но у вас границы в сервере анализируются?). Клиент будет смотреть по маске 0хС0 на "good".
остальное всё по сути "не good", а дальше детали. Если сможете детализировать, в чём причина "не good" - ну ок, тогда клиент может выдать сообщение, что типа связи нет, или там поломка датчика. Но это не так существенно, это детали. Суть в том, что если по маске 0хС0 не 0, то значение достоверное, если 0 - не достоверное. Так будет его воспринимать клиент.
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Quality(OPC) in IEC 1131
Автор: Мария Савина 
Дата:   19.06.23 12:35

Я не разработчик, мы используем ОРС сервер SCADA Infinity (Integrity), пытаемся разобраться по каким условиям плохое качество принимает те или иные значения, какое значение качества будет при проблемах с каналом связи и т.п.
Адрес этого сообщения    Ответить на это сообщение
 Список форумов    


 Список форумов  |  Нужен логин? Регистрируйтесь здесь 
 Логин пользователя
 Имя пользователя:
 Пароль:
 Помнить пароль:
   
 Забыли ваш пароль?
Введите имя пользователя или e-mail, и новый пароль будет послан на email, указанный в вашем профиле.

Рейтинг@Mail.ru