Войти Зарегистрироваться
Ваш регион:
Ваш город — Вашингтон
Угадали?
В корзине пусто!

Опыт применения RODOS-11

 

Философия.

Прекрасный летний денек. Вы гуляете на свежем воздухе и вдруг ощущаете, что на лоб упала капля. Действия? С криком «Кажется дождь начинается!!!» открываете зонтик или ищите ближайший навес? Нет? Конечно «нет». Вы ждете. Для вас существует некое мерило. Грань. До того, как «количество события» за эту грань перевалило вы ждете. И если на последней секунде (или капле) событие прекратилось – «а вот и не считается»)))))))) Все. Дождь покапал и прошел. Зонтик не открывался, убежище не искалось. Для каждого мерило свое. Кто-то считает количество капель. Кто-то их плотность или частоту. Кто-то отсчитывает время, в течение которого капли не прекращаются. Кто-то смотрит на окружающих, на их реакцию, многие ли открыли зонтики или засеменили по подворотням. И так далее. Если «количество события» соизмеримо с мерилом – вы начинаете «быть на грани». Достаете зонтик, но еще не спешите его раскрывать. Ищите глазами навес, но еще не бежите туда. Но как только «количество события» превысило ваше мерило – вы проводите черту. Дождь. И только тогда действуете!!!

Математика.

Ночь с субботы на воскресенье. На улице минус 25. Приходит оповещение, что температура одного из датчиков превысила верхнюю границу. Проходит 5 секунд. Оповещение, что все в норме, температура вернулась на допустимую грань. Еще 5 секунд. Оповещение о перегреве. Еще 5. Оповещение о норме. … И так до самого утра. Часов 5-6-7-8… Действия? Все верно!!! Покинуть теплую кроватку, срочно-обморочно взять такси и (в ночь с субботы на воскресенье) рвануть на работу спасать чего-нибудь. Что случилось? А ничего. Ни-че-го. Просто температура находится на грани. При одном измерении на четверть градуса превышает норму, при следующем – возвращается (становится равной норме, что есть «окончание сбоя»). И такой маятник с частотой в 5-6 секунд на протяжении нескольких часов. Дальнейшие действия? Опять верно. Вспомнить русский разговорный в отношении… некоторых личностей и обстоятельств)))

Соединяем философию с математикой.

Однократный выход показаний датчика за допустимую грань – не сбой и не повод бить во все колокола. Равно как и «маятник» на грани допустимой температуры. И то и другое – повод поразмышлять о причинах, повод что-то сделать, но совсем не повод будить СМСками среди ночи.

Суть в том, что событие (сбой или нормализация) должно «состояться» и только после этого мы от колебаний «нуууууууу да… или может и нет…» однозначно делаем вывод: да, нечто достойное записи в протокол (исходя из методики – заодно и оповещения) однозначно произошло.

В программе мерилом считается время, в течение которого «событие» (выход температуры за допустимую грань, не ответ датчика, не ответ порта и равно с ними – нормализация ситуации) наблюдалось НЕП-РЕ-РЫВ-НО. Например, отвалился датчик и в течении 10 минут так ни разу и не откликнулся. Или после перегрева температура нормализовалась и в течение 8 минут больше ни разу (!!!, ни на одном из датчиков!!!, даже на четверть градуса!!!) не вышла за пределы.

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

Как это сделать.

В INI-файле есть два параметра.

DSPEED. Это количество тиков (тысячных долей секунды), в течение которых программа ожидает ответа датчика. 1000 соответствует 1 секунде. Замечу, что даже если ответ от датчика поступил раньше – это никак не влияет на ситуацию. Программа отправляет запрос и вышеозначенное количество тиков не делает ничего. Просто стоит. По прошествии времени – забирает ответ.

DKOLVO. Это количество опросов, на протяжении которых «событие должно непрерывно наблюдаться». Замечу, что при старте программы самые первые 4 опроса «не в счет». Ведь мы сравниваем! А при старте программы мы еще не имеем ни одного параметра. Поэтому первый опрос первого датчика (температура), первый опрос второго датчика (температура), первый опрос третьего датчика (температура) и первый опрос третьего датчика (влажность) в зачет не идут. А дальше начинается цикл и все опросы «зачитываются».

Для небольшого количества опросов (именно опросов!!!) можно пользоваться простой формулой. Умножаем значения параметров друг на друга, переводим результат из миллисекунд в нечто нам более понятное (секунды или минуты-секунды)… и все)))

Пример.

DSPEED=500

DKOLVO=40

500х40=20000. Это в миллисекундах. Для перевода в секунды делим 20000 на 1000 и получаем 20 секунд. При таких параметрах, например, сначала датчик покажет превышение температуры относительно нормы и только через 20 секунд появится запись в протоколе (исходя из методики – может и оповещение на почту).

Можно считать обратно. Как набрать паузу в 10 минут? Например, мы производим опрос 1 раз в 2 секунды. Сколько должно быть опросов, чтобы набрать 10 минут? 10 минут = 600 секунд. Один опрос за 2 секунды. Значит нам надо 300 поросов.

DSPEED=2000

DKOLVO=300

Эту же паузу (10 минут) можно набрать иначе. Один опрос за 0,2 секунды. То есть в 10 раз чаще, чем в предыдущем примере. Значит, потребуется в 10 раз больше опросов. 3000. Т.к. 0,2х3000=600 (секунд, что есть 10 минут).

DSPEED=200

DKOLVO=3000

Если вы поставите реальный эксперимент с параметрами из двух последних примеров – однозначно получите РАЗНЫЕ паузы между наступлением события и его индикацией в протоколе.  Эти паузы будут сопоставимы с означенными 10-ю минутами, но никогда не будут одинаковы. Причем второй вариант (3000 опросов) всегда (!) даст большее время паузы. Почему? Ответ. Получить данные от датчика – эти слова стоит читать буквально. Получить. Отклик может быть для нас положителен или отрицателен – мы пока не знаем. За время DSPEED мы его только получаем. Для ответа «плохо-хорошо», своего рода для того, чтобы рефери в ринге открыл счет требуется анализ полученных данных. Рефери должен потратить мгновение, чтобы посмотреть в глаза пропустившему удар боксеру и принять решение – открывать счет или нет. Программа поступает так же. После получения данных прорабатывается блок команд по анализу текущей ситуации. И так происходит после каждого опроса. В наших примерах количество опросов отличается на порядок (в 10 раз). Если в первом случае на 300 повторений суммарно потребуется, например, 1 секунда (что называется, и ойкнуть не успеешь), то во втором (исходя из 10-кратного превосходства) – целых 10 (это уже даже не «мхатовская пауза», а ощутимо дольше).

Время исполнения блока анализа можно вычислить только экспериментально, т.к. это зависит во многом от компьютера, его возможностей, загрузки процессора и… и чего-нибудь еще)))

Один из реальных примеров. При количестве опросов равном 1000 к расчетным 5 минутам 33 секундам (скорость 333) получаем плюсом 10-15 секунд.

К данному описанию прикладываются три видеоролика.

В первом видеоролике (https://www.youtube.com/watch?v=FVQiSXh5ngE) параметры:

DSPEED=333

DKOLVO=40

Расчетное время 333*40=13320 миллисекунд, т.е. 13,32 секунды. Примерно 12-13-14 секунд. Не забываем, что 12:23:45 – как выдумаете, это самое-самое начало 45-й секунды и до ее завершения, до наступления 46-секунды, еще практически целая секунда или это самый-самый конец 45-й секунды и до наступления 46-й осталось всего 0,001 ???????? вот потому и +/- 1 секунда в данном случае вещь вполне реальная.

Во втором видеоролике (https://www.youtube.com/watch?v=kbrST11ZQ5s):

DSPEED=500

DKOLVO=20

Расчетное время 500*20=10000 миллисекунд, т.е. примерно 10 секунд.

В видеороликах программа запускается БЕЗ подключенного к компьютеру устройства, т.е. ошибка (сбой) наступают сразу же (как помним – после первого цикла опроса датчиков). Ошибка заключается в отсутствии ответа от всех 4-х датчиков.

Протоколы продемонстрированных в видео примерах.

 

первый

второй

COM1

COM2

 

========================

no RODOS

========================

 

28.12.2016 20:32:45

Stop Work

 

28.12.2016 20:33:00   Email=ON

AHTUNG !!!   01111

COM1 = ON

T1 =    (10-30)

T2 =    (10-30)

T3 =    (10-30)

W3 =    (20-80)

 

28.12.2016 20:33:00

send Email

 

28.12.2016 20:33:10

Stop Work

Close Programm

 

COM1

COM2

 

========================

no RODOS

========================

 

28.12.2016 20:33:56

Stop Work

 

28.12.2016 20:34:08   Email=ON

AHTUNG !!!   01111

COM1 = ON

T1 =    (10-30)

T2 =    (10-30)

T3 =    (10-30)

W3 =    (20-80)

 

28.12.2016 20:34:08

send Email

 

28.12.2016 20:34:45

Stop Work

Close Programm

 

Между 20:32:45 и 20:33:00 – 15 секунд. Но в это время вошел и первый проход по датчикам, который, как мы помним, «не считается». При скорости 333 это заняло 333*4/1000=1,2 секунды. То есть у нас осталось 15-12=13,8 секунды. По расчетам было 13,32. Помня о возможной разнице в 1-2 секунды («начало секунды», «конец секунды»), расхождение всего в 0,5 – нормально.

Между 20:33:56 и 20:34:08 – 12 секунд. Но в это время вошел и первый проход по датчикам, который, как мы помним, «не считается». При скорости 500 это заняло 500*4/1000=2 секунды. То есть у нас осталось 12-2=10 секунд. По расчетам было столько же.

 

Смоделировать «видеоролики» (запуск программы при отсутствии устройства) можно самостоятельно.  В INI-файле есть параметр AVTOR. Присвойте ему значение любого существующего (!) COM-порта и запустите программу. Как видно из роликов, значение было AVTOR=COM1 (символы COM должны быть на латинице и заглавные).

Для возврата к прежнему состоянию оставьте значение параметра AVTOR пустым.

Обратите внимание на 2 вещи. Какое число написано в первой строчке зеленой панели? А пересчет от 0 до какого значения идет? Верно, это текущее значение параметра DKOLVO. Когда программа обнаруживает сбой – начинается пересчет от нуля до значения DKOLVO. Это и есть та самая «пауза», на протяжении которой программа ожидает – состоится ли событие. И только после того, как событие состоялось – идет индикация в логе. В приводимых видеозаписях одновременно пересчитываются 4 значения. Это верно, т.к. одновременно не отвечают все 4 датчика (три датчика не выдают ни одного из четырех параметров). Если, например, пойдет перегрев только одно датчика – и пересчет будет только в одной строке. Если выставить большое значение «паузы», нагреть датчик и дать ему остыть (вернуться в норму) пока пересчет не закончен (даже остановится на 999 из 1000) – сообщения о сбое в логе не будет.

Данная панель существовала и раньше (и она используется в работе программы), только она не визуализирована. Точнее – я об этом еще не рассказывал. Визуализировать ее можно в реальной работе двумя способами.

Первый. Присвойте параметру AVTOR любое значение, отличное от имени порта. Например, AVTOR=123. При старте программы панель сразу будет видна.

Второй. Оставьте параметр AVTOR пустым, но при работе программы воспользуйтесь единственным пунктом контекстного меню. Правая кнопка мыши в серый цвет. Скрыть лишнее – еще раз этот же пункт меню.

Если хочется «больше лога» – измените вертикальные размеры формы. Дубльклик в серый цвет автоматически приводит форму к стандартным размерам (на горизонталь дубльклик не действует).

У нас выставлена скорость 333, количество 1000, что соответствует 333 секундам «паузы». То есть 5 минут 33 секунды. Проверено, работает. Не тесты. Пара реальных ситуаций уже была.

На тестах пробовал – скорость меньше 200 делать не стоит. Датчик может не успеть ответить (точнее, ответит, ответит корректно, но не все символы могут успеть в потоке «долететь» или их может перекрыть следующий ответ от другого датчика) и как следствие – ошибочные показания.

По допфункционалу см. третий видеоролик (https://www.youtube.com/watch?v=gViobP4hyMA).

Ссылки на видеоролики:

https://www.youtube.com/watch?v=FVQiSXh5ngE

https://www.youtube.com/watch?v=kbrST11ZQ5s

https://www.youtube.com/watch?v=gViobP4hyMA

Описание:

http://www.olimp-z.ru/rodos-11

Кутить:

https://silines.ru/rodos-11