This is topic Асинхронный обмен с OPC in forum Работа в MS Windows (ODBC/DDE/OPC/NET) / Working under MS Windows at Форум TRACE MODE: техническая поддержка.


To visit this topic, use this URL:
http://forum.adastra.ru/ultimatebb.php/ubb/get_topic/f/13/t/000097.html

Posted by Konstantin (Участник № / Member № 833) on :
 
Здравствуйте!
Подскажите пожалуйста какие настройки необходимы для обмена с OPC-сервером в режиме "по подписке".
Я создал в ТМ автопостроением канал типа OPC, задал ему режим ADVISE и, установив период пересчета базы каналов 1сек., стал ждать данных от этого канала, который на нижнем уровне меняется с частотой 0.5 секунд.
Результат наблюдал в СПАД и ОТ : значения обновляются гораздо реже, чем в реальности.
Т.о. режим ADVISE не отработал. Подскажите что я не так сделал и что можно попробовать еще.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Что значит "реже, чем в реальности" - конкретнее можно?
Что является источником данных для данного канала?
 
Posted by Konstantin (Участник № / Member № 833) on :
 
Источником данных является контроллер, который обменивается данными с OPC-сервером на высокой скорости (порядка 5-10мс). В МРВ создан автопостроением соответствующий канал. Период пересчета МРВ составляет 1сек.
Значение сигналов контроллера изменяются с частотой менее 0.5сек, а в СПАДе значения фиксируются 1 раз в секунду, т.е. на частоте пересчета канала МРВ, хотя режим ADVISE подразумевает фиксацию значений по факту изменения на сервере.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Все верно - значение канала не может меняться быстрее, чем пересчитывается база узла. Поэтому значение в архив и попадает не чаще, чем раз в 1 секунду, потому как сам канал пересчитывается с таким периодом. Хотите увеличить скорость обработки каналов в базе - увеличивайте скорость пересчета самого узла!
 
Posted by Konstantin (Участник № / Member № 833) on :
 
Тогда поясните пожалуйста как работает обьявленный режим "по подписке" (ведь так говориться о режиме ADVISE в HELP к ТМ 5.12).
В спецмфикации OPC говориться, что передачу данных в этом режиме инициирует сервер, значит соответственно настроенный канал МРВ должен его принять!
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Принять, то он его принимает - во вход, но вот в Реальное значение оно попадает только в момент пересчета канала, который возникает в рамках общего цикла пересчета всей базы каналов! Система же не асинхронна, чтобы каждый канал в базе пересчитывать тогда, когда ей захочется в разнобой, все каналы пересчитываются согласно своим установленным периодам относительно общего цикла пересчета узла, или астрономических временных уставок.
 
Posted by Konstantin (Участник № / Member № 833) on :
 
Т.о. Вы утверждаете, что режим по подписке в ТМ не реализован!!! Потому как в спецификации OPC этот режим описан как независящий от цикла пересчета базы каналов! Группа каналов, работающая в режиме "по подписке" ДОЛЖНА изменять свои реальные значения с временем изменения их на сервереOPC.
Скажите тогда, с какой целью введены четыре режима OPC каналов (SYNC/CASH; SYNC/DEVICE; ASYNC/DEVICE; ADVISE) и в чем их принципиальная разница?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Я такого не говорил! Обмен же работает в этом режиме! И в стандарте ОРС НИГДЕ не сказано, что этот режим описан как независящий от цикла пересчета - он, во-первых ограничен внутренним циклом обновления параметров самого ОРС-сервера, а во-вторых, он ограничивается циклом обработки данных клиента. И если Вы не обеспечиваете последний параметр на соответсвующем уровне циклу ОРС-сервера, то и данные меняться будут в соответсвии заданной Вами динамике - 1 секунда!
SYNC/CASH - синхронная выборка значений из кэша ОРС-сервера, без обращения непосредственно сервером к устройству. В этом режиме ОРС-сервер сам с определенным периодом должен обновлять этот кэш.
SYNC/DEVICE - при обращении к ОРС-серверу он генерирует запрос к девайсу и пока тот не выдаст ответ, ОРС-клиент транзакцию не завершает.
ASYNC/DEVICE - что-то вроде кэша, просто обмен с устройством по его родному протоколу асинхронен. При этом ОРС-клиент не дожидаясь конца текущей транзакции может инициировать следующую.
ADVISE - подписка ОРС-склиента на конкретные тэги ОРС-сервера, и если их значение меняется, то ОРС-сервер сам уведомляет об этом клиента.
 
Posted by Konstantin (Участник № / Member № 833) on :
 
Но тогда режим ADVISE ничем для пользователя не отличается от остальных, кроме как меньшей загрузой сети!?
Разве это предполагается по подписке? Нельзя хотя бы считывать очередь,из изменений значений (с метками времени), которые произошли между пересчетами?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Естественно - он для этого и был создан, чтобы без толку не гонять данные, которые не меняются.
Считывание очереди - это уже вектор данных, и спецификация эта называется HDA (Historical Data Access), однако данная спецификация в ОРС-интерфейсе ТМ5 не поддерживается.
А что мешает увеличить скорость пересчета самого МРВ? Вы кажется не совсем то делаете - для того, чтобы Мастер получал данные без потерь от Клиента его цикл как минимум должен соответсвовать циклу Клиента. А еще лучше, если он будет работать быстрее клиента. Вполне логичное правило, и справедливо оно не только для ТМ, а для любых цифровых систем вообще. [Улыбка / Smile]
 
Posted by Konstantin (Участник № / Member № 833) on :
 
Дело в том, что необходимо отлавливать переключения дискретных сигналов с точностью 10мс. А если в ТМ ставить такую частоту пересчета- процессор загружается на все 100%. Подскажите, как можно решить такую проблему?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
10мс под MS Windows - реально, но для ОС это предел, потому как в ней нельзя цикл таймера менее 10мс выставить, поэтому и загрузка ЦПУ такая большая. Эту задачу не в ПК надо решать, а в контроллере с более быстрым тактом сохранять в локальном архиве значения сигналов, а затем блоками их в МРВ поднимать. Однако на данный момент решить это можно будет только в 6-й версии ТМ, потому как в 5-ке МикроМРВ для контроллера, который умеет хранить локальные архивы специализирован на коммутируемый обмен: МикроМРВ Модем+. Другое решение - реализовать алгоритм в контроллере самим и через пользовательский драйвер подключить его к МРВ.
 


Новости АСУ ТП / News | SCADA / HMI | Обучение / Trainings | Свяжитесь с нами / Contact Us



Powered by Infopop Corporation
UBB.classic™ 6.7.2