This is topic Определение некорректного значения FLOAT in forum Языки программирования в TRACE MODE 6 / Algorithm Programming Languages at Форум TRACE MODE: техническая поддержка.


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

Posted by Сергей К. (Участник № / Member № 3297) on :
 
При опросе вычислителя ИРГА-2 появляются значения вида 1.#QNAN.
Подобное значение возникает тогда когда появляются проблемы с датчиком у прибора (обрыв или еще что).

Как определить этот момент в программе? И можно ли это сделать?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
По какому протоколу Вы получаете данные от вычислителя?
Правильно - исключить передачу некорректных значений по интерфейсу.

Программно в проекте можно поймать этот факт недостоверности путем сравнения полученного значения с числом, заведомо превышающим допустимую верхнюю границу значений по этому параметру.
 
Posted by Сергей К. (Участник № / Member № 3297) on :
 
Протокол ModBus-RTU.
Исключить не получиться в силу того, что при ошибке датчика ИРГА выставляет определенное значение в hex-формате 0xFFFFFFFF.

Верхняя граница возможна.
Т.е. если для температуры верхнюю границу поставить в 1000°С то сравнение (предел < параметр) при некорректном значении выдаст TRUE? Правильно понял?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Описанная в предыдущем посте возможность программной фиксации была реализована на модели, в которой значение -1.#QNAN формировалось внутри программы за счет некорректной арифметической функции (корень квадратный из отрицательного числа).
В стандарте МЭК, на основе которого построены программы, значения "не число" (-1.#QNAN и им подобные) параметра FLOAT не определены. Поэтому реалаьно программа, на вход которой подано такое значение, на него не реагирует и его не обрабатывает (эквивалент - ВХОД_программы_равен 0). Если значение "0" реальному процессу не свойственно, можно в программе принять это в качестве сигнала о недостоверности.

Если Вы используете для считывания Modbus-переменных функции Rin_Float или Rout_Float,
то появление -1.#QNAN в этой ситуации объяснимо.
Мы промоделировали ситуацию, когда от источника передается 0xFFFFFFFF.
При получении такого кода от источника в канале FLOAT устанавливается признак аппаратной недостоверности. Это уже достаточная информация для индикации и принятия соответствующего решения.
 
Posted by Сергей К. (Участник № / Member № 3297) on :
 
Для опроса используется R_FIFO_QUEUE.
Потребуется-ли переделка на опрос с помощью Rin_Float или Rout_Float?
Или будет достаточно сделать обработку в канале (трансляцию) FLOAT которая при аппаратной недостоверности выполнит определённые действия?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Пршлите, пожалуйста, Ваш проект на hotline@adastra.ru.
 


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



Powered by Infopop Corporation
UBB.classic™ 6.7.2