1

Учет моточасов при попеременной отправке параметров

Тема: Учет моточасов при попеременной отправке параметров

Второй день ломаю голову. Имеется устройство, отдающее по частотному каналу в терминал ГалилеоСкай   температуру и бортовое напряжение. Передача ведется следующим образом: 1 минуту передаются данные о температуре (частота 100-1100Гц), затем 1 минуту передаются данные о напряжении (частота 1100-1330Гц). Таким образом датчики видно попеременно, но построению графиков это не мешает...
Клиент попросил реализовать счетчик моточасов. Я реализовал датчик зажигания (по изменению напряжения), но загвоздка - в моменты, когда приходит значение температуры (данные о напряжении, соответственно, отсутствуют), датчик зажигания меняет значение на ВЫКЛ... Нужно каким-то образом сохранить последнее валидное значение. Пробовал делать через валидаторы, но ,к сожалению, не получичлось...

2

Учет моточасов при попеременной отправке параметров

(07/06/2018 14:23:23 отредактировано boonch85)

Re: Учет моточасов при попеременной отправке параметров

x-radio пишет:

Прощения просим за некропост. Тему новую создать права не позволяют...

Второй день ломаю голову. Имеется устройство, отдающее по частотному каналу в терминал ГалилеоСкай   температуру и бортовое напряжение. Передача ведется следующим образом: 1 минуту передаются данные о температуре (частота 100-1100Гц), затем 1 минуту передаются данные о напряжении (частота 1100-1330Гц). Таким образом датчики видно попеременно, но построению графиков это не мешает...
Клиент попросил реализовать счетчик моточасов. Я реализовал датчик зажигания (по изменению напряжения), но загвоздка - в моменты, когда приходит значение температуры (данные о напряжении, соответственно, отсутствуют), датчик зажигания меняет значение на ВЫКЛ... Нужно каким-то образом сохранить последнее валидное значение. Пробовал делать через валидаторы, но ,к сожалению, не получичлось...

В программе мониторинга (по крайней мере в Fort Monitor) это можно попробовать решить функцией "отбрасываемые значения", выставляем нижний диапазон: мин. -1000000; макс. 1100, и верхний диапазон: мин. 1330; макс. 1000000. Все данные вне этого диапазона будут считаться не валидными. Если конечно под словом "валидатор" вы не имели в виду то же самое)

3

Учет моточасов при попеременной отправке параметров

Re: Учет моточасов при попеременной отправке параметров

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

4

Учет моточасов при попеременной отправке параметров

Re: Учет моточасов при попеременной отправке параметров

Здравствуйте!

Спасибо, что прислали детализированный запрос на support@gurtam.com -- я уже отправил вам ответное письмо.

Продублирую ответ тут:

x-radio пишет:

Нужно каким-то образом сохранить последнее валидное значение. Пробовал делать через валидаторы, но ,к сожалению, не получичлось...

В общем случае сохранить последнее валидное значение датчика невозможно, так как датчики не накапливают и не сохраняют значения, а только изменяют входные параметры из сообщений с помощью формул, валидации и таблицы расчёта.

Однако в датчиках вы можете обращаться к значению параметра из предыдущего сообщения. Это сможет помочь в вашей ситуации, только если сообщение с известным зажиганием прерывается не более чем на 1 сообщение с неизвестным зажиганием.

x-radio пишет:

Клиент попросил реализовать счетчик моточасов.

Попробуйте использовать значения других параметров для определения статуса зажигания. Например, изменение значение параметра "pwr_ext" или активацию параметров "acc_trigger" или "out17". Для подсчёта общего времени работы двигателя вы можете использовать счётчик моточасов, настроенный на датчик зажигания, с ввключённой опцией "Авто".

@ Oleg Zharkovsky
Customer Service / Quality Control and Training
"Timely is the best. But still better late than never."
5

Учет моточасов при попеременной отправке параметров

Re: Учет моточасов при попеременной отправке параметров

Оставим тему пропусков данных. Сегодня перебью параметры... В параметр adc13 c каждым сообщением приходит бортовое напряжение установки (реф). Я создал датчик [реф заведен], который корректно отлавливает состояние установки (заведен/заглушен) и выдает, соответственно вкл/выкл. Создал еще один датчик [моточасы реф],  тип - счетчик дифференциальный, формула - (time - #time)*[реф заведен]/const3600. При выводе сообщений в виде показаний датчиков в столбце [моточасы реф] в каждой строке получаю либо 0ч., либо 0,17ч (сообщения каждые 10 минут). На мой неопытный взгляд датчик с таким типом должен суммировать текущее значение с предыдущим. Разве не так??? В итоге нужен датчик, который пользователь увидит из мобильного приложения в разделе [датчики].

По поводу применения других параметров. Нужные мне параметры приходят по двум частотным каналам (adc12 и adc13), и никак не связаны с автоматически присылаемымы pwr_ext и прочими. То есть терминал, в данном случае, я использую просто как ретранслятор.

6

Учет моточасов при попеременной отправке параметров

Re: Учет моточасов при попеременной отправке параметров

x-radio, Ответили вам письменно. Дублируем здесь ответ:

> Я создал датчик [реф заведен], который*корректно*отлавливает состояние установки (заведен/заглушен) и выдает, соответственно вкл/выкл.

Да, он работает корректно.

> Создал еще один датчик [моточасы реф],  тип - счетчик дифференциальный, формула - (time - #time)*[реф заведен]/const3600. ,
> При выводе сообщений в виде показаний датчиков в столбце [моточасы реф] в каждой строке получаю либо 0ч., либо 0,17ч (сообщения каждые 10 минут).

Этой формулой вы считаете следующее:
1. Сколько времени прошло от предыдущего сообщения до текущего, в секундах.
2. Умножаете на статус рефа в текущем сообщении, т.е. на 0 или на 1.
3. Переводите время в часы.

При условии, что сообщения приходят каждые 10 минут, вы получаете:
А) 0 часов, если в текущем сообщении реф выключен.
Б) 0.17 часов, т.е. 1/6 часа = 10 минут, если в текущем сообщении реф включён.

По большому счёту, эта реализация датчика просто считает время между сообщениями.

> На мой неопытный взгляд датчик с*таким*типом должен суммировать текущее значение с предыдущим. Разве не так???

Нет. Этот датчик ничего не должен суммировать. Никакой датчик в принципе ничего не должен суммировать, если только вы не прописали это в его формуле.
Роль датчика: перевести значение параметра в человекопонятный вид для каждого конкретного сообщения.
Роль отчёта: провести вычисления на основании значения датчиков в каждом сообщении и учитывая тип датчиков, т.е. их логику.

Я неспроста отметил "тип датчика = логика". Устанавливая тип датчика, вы даёте системе понять, по каким принципам изменяются его значения и как она (система) должна с ними работать. Не наоборот!
Например:
1. Тип датчика "Счётчик -> Дифференциальный" означает, что его значение всегда увеличивается. Это может быть пробег с одометра машины (1000 км, 1001 км, 1002 км...), или счётчик расхода топлива (300л, 300.5л, 301л...), или счётчик абсолютных моточасов техники (70ч, 71ч, 72ч...).
2. Отчёт по датчику с типом "Счётчик -> Дифференциальный" считает приращение его значения за интервал времени. Было утром: 70ч. Стало вечером: 78 ч. Итог за день: 78 - 70 = 8 часов.
3. Чтобы правильно использовать этот тип датчика, вы должны подать на него значения, которые постоянно увеличиваются.

Для вашего датчика, с вашей формулой, нужен другой тип датчика: Счётчик -> Мгновенный.
Ведь вы считаете, сколько длился каждый из множества маленьких интервалов. В таком случае, используйте мгновенный счётчик, и система в отчёте посчитает их сумму: 0,17+0,17+0+0,17+0+... = N
Надеюсь, это объяснение поможет вам понять отличие датчика и отчёта. Теперь, переходим к главному.

> В итоге нужен датчик, который пользователь увидит из мобильного приложения в разделе [датчики].

Как мы уже выяснили:
- датчик считает по формуле своё значение в каждом конкретном сообщении
- датчик не считает и не накапливает сумму своих значений, т.к. это удел отчётов и счётчиков пробега/моточасов/трафика в настройках объекта
Дополнительно: датчик, который использует валидатор или предыдущее сообщение (#), не может быть использован ни для счётчика моточасов/пробега, ни в мобильном приложении

Для реализации обозначенной выше цели, у вас есть 2 варианта действий:

1. Считывать и передавать в систему текущее значение счётчика моточасов напрямую с рефа.
Такие решения существуют, всё упирается в возможности технической реализации.

2. Датчик работы рефа сделать ОСНОВНЫМ и, желательно, единственным датчиком зажигания.
Сейчас у вас в объекте 5 (!) датчиков зажигания. Это не так удобно, как если использовать 1 датчик зажигания, а остальные делать произвольными цифровыми датчиками.
Нюанс в том, что "Счётчик моточасов" на вкладке "Основное" зависит от того датчика зажигания, который создан первым. Как узнать, от какого это датчика зависит? Только экспортировав датчики объекта в WLP-файл и проверив их "id".
По итогу, у вас должен остаться только один датчик зажигания - "Реф заведён" - и счётчик моточасов будет работать по нему и отображаться в мобильном приложении.

7

Учет моточасов при попеременной отправке параметров

Re: Учет моточасов при попеременной отправке параметров

Плюсую! Спасибо! Очень доходчивою. Будем пробовать!