This is topic Определение факта приема данных 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/000089.html

Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
 
Как точно определить факт приема данных из внешнего источника?

Требуется выполнить последовательность:
1. Запросить данные (в частности из БД по SQL)
2. Удостоверится, что данные пришли (даже если они не изменились)
3. Передать другому узлу ТМ
1'. Запросить данные из тех же полей, но с другим WHERE
2'. Удостовериться, что пришли
3'. Передать
и т.д.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
По пункту №2 рекомендую создать канал ПУСТОЙ_SQL-выполнить, только типа INPUT. И если после выполнения запроса этот канал остался равным нулю, значит запрос прошел успешно.
 
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
 
Это я догадался.
Ладно, с SQL я придумал.

При SELECT можно обнулять поле, по которому задается WHERE и после запроса по равенству этого поля заданному в запросе значению судить о приходе данных.

При UPDATE же: завести заранее в базе поле счетчика для каждой записи и увеличивать его при каждой транзакции, затем считывать и сверять с переданным.

Других способов не вижу.
 
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
 
В любом случае, для всех протоколов нужен признак обновления данных, независимо от изменения величин.

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

Я вижу это как вечнорастущий счетчик в каждом канале, естественно с обнулением при переполнении. Достаточно большой, чтобы даже медленные каналы, пересчитываемые через несколько циклов (а то и часов) могли определить его изменение - в идеале 32 разрядный - хватит на всё.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Лучше по флагу "Отработать" смотреть.
 


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



Powered by Infopop Corporation
UBB.classic™ 6.7.2