Есть расходомер с выходом 4-20мА, считываемый аналоговым входным модулем 1756-IF16, вставленным в контроллер L72, входящий в систему FactoryTalk View SE, отдающую данные во внешний мир по OPC с помощью FT Gateway.
Есть аналоговый тег Ch0Data, показывающий ток втекающий в модуль.
Есть дискретный тег Ch0Fault, показывающий что в токовой петле есть обрыв/КЗ или модуль неисправен, проще говоря на Ch0Data уже можно не смотреть.
Мы хотим передать данные о расходе в вышестоящую систему (АСУП/MES). Если принять в качестве значения расхода величину Ch0Data, то при обрыве токовой петли Gateway выдает расход равным нулю, вводя в заблуждение OPC-клиента. Надо как-то показать, что показания датчика не равны нулю и не равны максимуму шкалы, они вообще ничему не равны, а просто недоступны.
В спецификации OPC DA описан именно такой механизм, уведомляющий клиентов о том, что значение неточно/недоступно/некорректно - флаги Quality. Можно ли в FactoryTalk Gateway создать OPC Item, у которого Value зависит от Ch0Data, а Quality зависит от Ch0Fault?
Немного не понял при чем тут сам OPC, реализуйте проверку Ch0Fault в ПЛК и взависимости от значения данной переменной, уже в СКАДА системе выводите определенные сообщения для пользователя.
Признак качества в теге OPC отражает не валидность физического значения, а качество ПЕРЕДАЧИ самого значения (качество связи) .
Можно с отличным качеством передать и полный бред.
Поэтому обрабатывайте тег Chanel_Fault и не парьтесь!
А если OPC признак качества тега станет "bad", то SCADA сама выведет вместо цифр значения тега прочерки, черепашек, обезъянок/собачек или другую какую зверушку.
mp3corp Есть моя система, FactoryTalk, в ней все хорошо, а том числе и сообщения при обрывах.
Есть общезаводская система учета, в которую нужно отсылать ключевые технологические параметры.
В случае обрыва сенсора, отправляются данные о том, что: Value=0 Quality=Good - то есть наглая ложь; Quality не должно быть Good, ведь я знаю что наступил Channel Fault!
Ryzhij62
Цитата:
Признак качества в теге OPC отражает не валидность физического значения, а качество ПЕРЕДАЧИ самого значения (качество связи) .
Я этого и добиваюсь. Обрыв езернета к контроллеру уже приводит к Bad Quality встроенными средствами FactoryTalk Gateway.
Я хочу, чтобы дополнительно к этому, обрыв между контроллером и сенсором тоже генерировал Bad Quality. Неужели это противоречит философии OPC?
Ну так обрыв кабеля Ethernet это и есть "падение" источника данных, поэтому и будет статус "Bad". Откуда OPC знать, что при значении переменной Ch0Fault==1, он должен выдавать не 0 и нечто иное? Как и говорил ранее, реализуйте все сами на верхнем уровне, если Fault то пусть пользователь видит то что... что Вы сами захотите то он и увидит)
Объясните мне, для чего все эти танцы с -1.#QNAN, если можно привязать любую анимацию на верхнем уровне при проверки переменной ...Fault?
Анимация одно, а в базу..., показ на тренде...
На как я понял у ТС будут приходить нули, т.е. на тренде будет совмещенная линия с осью абсцисс, в базу... ну обычно в журнал идут строковые сообщение о алармах, предупреждениях и т.д. Понятно что это дело того кто "ЭТО" делает, но я за простоту!
Объясните мне, для чего все эти танцы с -1.#QNAN, если можно привязать любую анимацию на верхнем уровне при проверки переменной ...Fault?
Над тем, что вы называете верхним уровнем, есть еще один уровень, самый верхний. Там принимаются решения сколько какого продукта изготовить и сколько кому зарплаты выдать. Это называется система управления производством и там нет никаких "анимаций", там есть архивы, статистика и отчеты. Вот туда нужно отправлять данные по OPC.
maxim писал(а):
Здравствуйте, пишите в Value например -1 или -8888, если есть ошибка канала.
Магические константы и изобретение велосипеда... По возможности хотелось бы все-таки использовать стандартные средства OPC для этой задачи. Это было бы более гибкое и поддерживаемое решение.
dv_ писал(а):
Или -1.#QNAN, если тег REAL - RSLinx Classic сам подставит BAD.
Хорошая идея, но в RSLinx Enterprise эту фичу убрали.
Emulate5000 > RSLinx Classic > OPC Test Client:
Кстати, формулировка причины не та, но уже что-то.
Emulate5000 > RSLinx Enterprise > FactoryTalk Live Data Test Client:
В принципе с этим тоже можно работать. По крайней мере, NAN - это лучше чем -8888.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Smart Solutions VDT GmbH | Friedrich-List-Allee 38, D-41844 Wegberg-Wildenrath, Germany Tel.: +49 2432 933 57 83 | e-Mail: office@vdt-solutions.de Все товарные знаки и торговые марки являются собственностью их владельцев.
При использовании материалов сайта ссылка на данный сайт обязательна. Открытие страницы: 0.128 секунды
FAQ
Поиск
Группы
Профиль
Войти и проверить личные сообщения
Вход
