Два и больше баков с ДУТ. Контролируем сливы

Ну перекрывать бак он не собирается вроде.
Есть альтернатива конечно подключить fm4200 к can-шине(renault и iveco). Но опыта подключения нет никакого. Если у кого есть ссылка на документацию как это делается буду благодарен.

Прошу прощения за офтоп, но все же буду благодарен за информацию о подключении CAN-шины к fm4200

2хLLS + Dalcon - ознакомлюсь.Спасибо!

Добавлено спустя   5 минут  41 секунду:
Dalcon только с LLS работает?

Новаком GNS-TRACK поддерживает до 8 датчиков типа ДУТ или LLS, дальше на сервер и обрабатывайте, как захочется.

Уточните, 2 ДУТа используются в двух баках или в одном?

Если нетрудно, прикрепите также скриншот со списком датчиков. где видны типы датчиков и параметры

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

такая схема может подойти если выводить общий объем из двух баков, если же два ДУТ утстановлены в один бак тогда есть смысл вывести среднее значение. т.е. ([ДУТ1]+[ДУТ2])/const2

ДУТы стоят в одном баке. При тарировке вводились по 50% каждого значения на датчик, чтобы в сумме они давали 100% (как сделать суммирование и дальнейшее деление на 2 не смог разобраться)
Как вставить изображение?

Добавлено спустя   8 минут  4 секунды:
При всём этом я не понимаю, почему так абсурдно в 1отчёте показывает... Почему то же Макс.уровень верно отображает, а нач. и конечный, видимо суммированные ДУТ1, ДУТ2 и ДУТ1+2
"Нач. уровень    1398 л
Конеч. уровень    1319 л
Макс. уровень топлива    699 л"

Не имеет значения что в пакетах значения датчиков приходят в виде fuel_omnicom1(2). Должно работать и с произвольными? Параметры, которые стоят у Вас, по сути могут же использовать данные одного и того же датчика, или я ошибаюсь?
Про параметры сам не догадался бы... Получается можно прописывать любую логическую часть в ячейке "параметр", а переменные это будет Название датчика. Так?

все верно, формула, описанная мною и ArsNova выше должна работать, позже есть в планах добавить в FAQ случаи с двумя ДУТами и примеры настройки...

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

здравствуйте,

Уточните ,пожалуйста, какой именно продукт используется.

Общее описание - "расход по ДУТ" это простой перепад уровня топлива - НУ - КУ. Если в статистике - от начала до конца интервала, если в поездках - для каждой поездки отдельно и сумма за весь интервал расходов. С моточасами - то же, что и со статистикой. Т.е. - если у вас расход ниже, чем по вашему мнению должен быть, смотрите, где не посчиталась заправка или конечный уровень был выше начального. Если заправка больше - смотрите, где начало и конец заправки, определите, где ложные значения и т.д.

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

2. Групировка датчиков с одинаковым именем. - см. первый абзац

3. Валидатор ДУТ2 - уточните ,пожалуйста, тип валидации.

Также значительно ускорить анализ поможет предоставление данных на support@gurtam.com с упоминанием ссылки на данную тему. Мы сможем проверить ситуацию комплексно и предоставить вам рекомендации по ее решению.

Два сообщающихся бака можно заводить и таким образом. Оперируя здесь и далее виртуальным баком.Заводите датчик в котором параметр по одному баку плюсуется с параметром другого (имеет вид в графе параметр датчика fuel1+fuel2), соответственно значения в таблице тарировки также плюсуются (как и порции топлива соответствующие этим значениям) В итоге, в таблице тарировки, максимальное значение (если заводите по 485 протоколу(4095+4095=8190), а соответствующее ему конечные объемы (объем бака1+объем бака2). Таким же образом заводятся ставятся 2 ДУТа в один бак, там где это оправдано (длинный, невысокий бак) На Porter, Sprinter..... из наших ГАЗонNEXT
            Такое заведение ДУТов в систему на мой взгляд на уровне подсчета проще для логики системы.

Кстати, как раз это и оправдано(описанный мною способ заведения), когда система баков  лишена возможно отключения перетекания из бака в бак. И тарировать приходиться дабл порциями в левый - в правый, а за время залива второй порции происходит не учитываемый по объему переток. Пуляешь равные порции в баки и тупо ждешь когда все успокоиться. У тебя в любом случае будет общий объем залитый в 2 бака соответствующий сумме конечных максимумов с 2 -х ДУТов, а каждая остановка в тарировании, будет означать проработку порционного тела таблицы каждого из баков. И ничего подгонять не надо

Опечатка, не всегда можно оттарировать раздельно.

Мтз старый прекрасно тарируется одновременно два бака, там есть тубка дренажная выходин в район горловины заливной правда диматер у нее около 10 млм.. но лейку никто не отменял...
Дальше порциями по 5 литров в левый, потом в лейку
опять 5 литров в горловину 5 в лейку.
И помоему на 30 литре начинает работать большая перепускная.

А вот про крен, ТЗ может вернутся в горизонтальное положение спустя пробег по полю, или при обработки местности с уклонами и т.д.

.

Можно и так , но на мой взгляд я делаю проще. И на точности измерений это не отражается

Равные порции это там где баки примерно одинаковы по объему. Если баки разные оцениваешь каждый. Прикидываешь за какое количество заливок, с поправкой на геометрию (см выше) можно оттарировать бак, так чтобы получилась красивая кривая бака отображающая правильно его геометрию второй бак тарируешь тем же количеством заливок. Естественно по объему порции в этом случае будут не равными(смотришь по интенсивности перетока.Смысл во всем этом очень простой. Одинаковое количество заливок в оба бака гарантирует примерно равный уровень при тарировании. Это нужно чтобы четко фиксануть точку графика тарировки каждого из баков. И Не надо долго ждать стабилизации уровней, если нельзя устранить переток.
              Метод сложения показаний с ДУТов в одно показание и сложение соответствующих ему объемов тем и хорош.Что тебе в общем то все равно сколько перелилось из бака в бак пока ты заливал порцию в другой бак........
          Господа в конце концов у каждого свои тараканы. Я просто делюсь своим опытом

э

Какая геометрия какая оценка баков???
Должно получится на бак больше 10 порций,
Их может быть и 30  и 50 от настроения

Залил 10 посмотрел н-код с ДУТА 1 и ДУТА 2
залил 20 посмотрел
залил дальше 35 потому что промазал тоже записал что на 35 литрах у тебя показания такие -то и все.

Дальше программа сама сгладит от 10 до 20 и дальше сгладит до 35
и так дальше под горловину!!!!

Как скажете так и будет..... Ибо " в начале было слово".Да, кстати, я вам ничего не пытаюсь продать. Чем писать кипятком, просто попробуйте

Понимаешь, костность восприятия порой бывает запредельная и в мои задачи не входит ее размягчить. Специально для вас повторюсь.
          Я в самом начале написал, что заводиться 1 виртуальный бак и все движения по ДУТам торчащим в своих баках производятся в этих рамках, поэтому литраж баков важен лишь на этапе оценки количества-объема порций в каждый бак, в рамках дабл-заливок, напрямую завязанный на то, чтобы минимизировать перетекание в процессе тарирования. Это главное. Здесь конечно стоит отметить, что скорость прямого, от первого ко второму баку, может быть и как правило, не равна обратному перетоку. Сложение данных с ДУТов равное в таблице сумме залитых в каждый бак порций, как раз призвано компенсировать этот процесс . Ибо ежли где-то убудет , значит во втором прибудет. Важно еще раз повторюсь четко зафиксировать точку стабилизации когда перетока нет ни прямого 1-2, ни обратного 2-1. Обычно тарирую в шахматном порядке : если первая дабл порция идет1-2 баки, то следующая 2-1 так немного быстрее. Пробуй и будет тебе счастье

Доброго времени суток. Возникла такая проблема: клиент хочет чтоб по каждому баку  отдельно был отчёт по расходу топлива на всех баках стоят ДУТ, возможно ли это сделать в отчёте или можно увидеть только  по графикам?

SupportViatec  добрый день

создаете датчик в объекте для каждого ДУТ и не используете галку "Группировать датчики уровня топлива с одинаковым именем" в настройках топлива http://docs.wialon.com/ru/hosting/cms/units/fuel
В отчет будет расход по каждому датчику (имя в скобках).

SupportViatec  статистика не умеет делить по датчикам

http://docs.wialon.com/ru/hosting/user/ … v_otchetax
В статистике нет возможности выводить отдельную строку для каждого датчика. Даже если они не группируются, в строках типа «Средний расход…», «Потрачено …», «Отклонение расхода …» и т.п. можно получить только одну строку на каждый тип топливного датчика (ДУТ/ДИРТ/ДАРТ/ДМРТ). Поэтому «Потрачено …» будут в статистике представлять из себя сумму по датчикам данного типа, а «Средний расход…» будет средним арифметическим между этими датчиками.

Есть 2-х баковое транспортно средство ( баки соединены).C именами сенсоров [Diesel. Big tank] и [Diesel. Small tank]
Для удобства анализа топлива в свойствах транспортного средства создали виртуальный датчик с параметрами:

Name: Total fuel in tanks
Sensor type: Fuel Level Sensor
Parameter: [Diesel. Big tank]+[Diesel. Small tank]

После этого при получении отчетов по "слив" и "заправка"  данные от датчиков суммируются:
[Diesel. Big tank]+[Diesel. Small tank] +[Total fuel in tanks].

В итоге  реальные данные по сливу и заправке не совпадает с данными из отчетов.
Конечно если делать детализацию например заправки , то все отчетливо понятно для нас. А вот клиента такие отчеты совсем не устраивают.
Пока что я просто изменил Sensor type в свойствах виртуального датчика  для получения корректной информации.Но тогда при графическом анализе работы ДУ1 и ДУ2 относительно пробега я перестал наблюдать "кривую"  [Total fuel in tanks]

И вот собственно вопрос:
Можно ли оставив тип сенсора виртуального датчика (Sensor type: Fuel Level Sensor)  , продолжив наблюдать  кривую от этого датчика на графике , при этом исключить суммирование при получении отчетов  [Diesel. Big tank]+[Diesel. Small tank] +[Total fuel in tanks].А оствить только значение от [Diesel. Big tank]+[Diesel. Small tank] ? Может быть это можно сделать например в свойствах отчета или еще использовать  какие-нибудь варианты?
Буду очень благодарен за информацию.

Спасибо Вам за ответ.  Одно из условий клиента он хочет контролировать баки по отдельности.
Условия описанные вами выше соблюдены:
Два датчика созданы (которые получают реальные значения от ДУТ)
Датчик Total fuel in tanks с параметрами [Diesel. Big tank]+[Diesel. Small tank] то-же создан.
А вот как раз отчеты оперируют датчиками  [Diesel. Big tank],[Diesel. Small tank]и[Total fuel in tanks] и суммирует все данные от этих 3-х датчиков, например при заправке. Как исключить датчик [Total fuel in tanks]  из отчетов для получения реальных данных о заправке используя данные только от датчиков  [Diesel. Big tank],[Diesel. Small tank]  ?Сейчас все заправки отображаются в два раза больше от реального значения.
Или как исключить  [Diesel. Big tank],[Diesel. Small tank] из отчетов оставив при этом оставить только значение   [Total fuel in tanks] .?
Со сливами такая-же ситуация.

Если оно решают поставленную Вам задачу - значит оно верное.

По моему в этой схеме достаточно было-бы одного ДУТа в баке, того что длиннее. Из минусов, больший перекос из-за не-центра, но в целом...

Необходимо провести тарировки обоих датчиков сразу. Понадобится 2 шт. УНУ и 2 компьютера.
Далее заливаем в систему тарировочная таблицы для обоих датчиков и создаём ещё один, виртуальный, дифференцированный датчик.

Не факт, что надо 2 УНУ и т.д., можно просто переключаться.
А как это сделать, наверное, можно посмотреть у Оммникома в инструкциях, там, по-моему, это все есть.

Я не про Омникомм конкретно, я об алгоритме тарировки бака в такой ситуации. Не встречал, чтобы у кого-то
еще было об этом написано, хотя читал, конечно, далеко не все. но все-таки вдруг поможет человеку.

Ага и минимум два монтажника))

Номера ком портов в ваших УНУ не меняются???
Или на компьютерах по 1 юсб ))

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

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

В итоге у нас получится 3 виртуальных бака.
схема во вложении.

Далее заводим 3 цифровых датчика, (важно цыфровых чтобы они не втягивались в отчеты, и можно было их анализировать по отдельности)

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

Например значение N кода 223 соответсует 100 литрам
223 = 100
224 = 100
Тогда линия графика после 223 будет горизонтальной

Дальше заводим Бак 2 -- часть длинного дута от пересенчения до верхней точки.
Данные литров уже делим на 2

И заводим Бак 3 -- короткий дут.

Создаем 1 виртуальный дут.
[Бак1]+[Бак2]+[Бак3]

И все должно работать.

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

Линия пересечения короткого и средины длинного дут будет сдвинута и в центральной части бака может начатся хаос.

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

єх если бы на тех тракорах была прямоугольная форма, а судя по фото это какой нибудь new holland)))

Факты перетекания между баками и т.д. не всегда удобно отслеживать в терминале.

В программах к ДУТ значения с большей дискреностью и видно когда топливо уже устаканилось.

DIESEL очень подробно расписали и, я уверен, окончательно запутали коллегу. Не стоит усложнять, я считаю. Мой способ работает.

+1
Что называется "спросил водички попить"

Всем спасибо) разобрался!

Видимо ты один весь в работе, и пообщаться некогда.
Зато человек все понял и принял правильное решение, хотя это было сложно и решения его мы пока не знаем.

Уже подсказали.

А мой комментарий касается отдельных интеграторов, советы которых были написаны...
Издевки никакой нет. Это констатация в отношении уровня квалификации отдельных сотрудников. Простейшая регулярная ситуация вызывает поток фантазий... увы.

И да, я обычно в работе. Если есть 10 свободных минут, то такие темы их скрашивают.

SanderAMC  хороший совет. Но, топикстартер говорил о двух установленных ДУТах.

рекомендую попробовать формулу:
(f1*f1/(f1+1)+f2)/(1+f1/(f1+1))
все конечно зависит от математики внутри терминала, и датчика, который вы используете.
чтобы избежать деления 0/0 для частотного датчика добавления 1 Гц не страшно, для цифры, если идет выдача в литрах, то можно прибавить любое положительной сколь угодно малое число (различаемое программой). конечный вид формулы будет меняться в зависимости от того, какие показания идут в коротком датчике f1 при показаниях ниже отметки (ноль, или не ноль).
если уровень малый, то будет f2/1, при уровне выше нижней точки f1, будет (f1+f2)/2

Xt то велосипед изобрели однако. Начать надо было с описания какой датчик и какой прибор - кто-то уже писал - через конфигуратор от трекера и тарировать одновременно оба датчика, где отображены значения обоих датчиков. Оттарировали и все. Какие то виртуальные баки изобретать, по секциям делить и т.д. Если в конфигураторе нет данных, то поставить отправку по 3 сек - дольше, но тоже точно

Подскажите кто как борется с проблемой?
Думали снимать и чистить патрубки, которые соединяют баки.
На сложную технику тарировка до 6-8 часов.
Как например Фергусон

Миэлта либо галя 5
Дуты Эскорт, омником

Джон Диры 7 серии, 9, 8
Челенджеры 685

C МТЗ понятно, тарируем отдельно снятые.

А верхний соединитель заглушит нельзя?
просто с такими баками не имел дело что снизу и сверху соединяется, а на технике с двумя баками где не обязательно съем мы просто глушим соединительные трубки и тарируем баки по отдельности.
А на счет шлака в соединительном трубке  оно и так все вылиться когда будете снимать.

Делали одновременную тарировку в таких случаях.
Дольше по времени немного, но зато без колхоза )