Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
Страницы 1 … 16 17 18 19 20 … 23 Читать все
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Отправил шаблон отчета и информацию.
Единственно что шаблон нужно будет как я понимаю править под конкретный терминал.
По крайней мере будет образцом...
beifuss.alexei@gmail.com
yurimasterk
Изучил шаблон отчета.
По сути та-же самая таблица "Датчики счетчиков" просто вы отфильтровали те промежутки времени когда в RFID считывателе нет карты водителя, так как у Вас установлен перекрывающий клапан на раздачу и без карты он не откроется.
Т.е. ложные импульсы вы минимизировали на аппаратном уровне с помощью грубо говоря связки RFID-считывателя и перекрывающего клапана.
Здесь же тема(предложение) было создано для того, что-бы было возможно это сделать программно, так как некоторые клиенты приходят от конкурентов и просят перевести оборудование на wialon. НО! Начинаешь им говорить что-бы на Wialon это работало нужно докупить вот это, это и это. Им естественно это не нравиться, так как на предыдущем ПО у них все это работало и так без дополнительного оборудование.
Нужна возможность это сделать программно, а потом уже на конкретных примерах показать клиенту что для КОРРЕКТНОЙ работы нужно что-то докупить.
Отмечу что при подключении УСС к терминалу напрямую все равно будет проблема по точности показаний. Нужен контроль паразитных колебаний от УСС. У меня был случай с заправщиком когда импульсы шли просто и при движении и когда просто двигатель заводили...
Поэтому практически все решения, которые на сегодняшний день реализовываем на аппаратном уровне исключают дребезг.
yurimasterk
Изучил шаблон отчета.
По сути та-же самая таблица "Датчики счетчиков" просто вы отфильтровали те промежутки времени когда в RFID считывателе нет карты водителя, так как у Вас установлен перекрывающий клапан на раздачу и без карты он не откроется.
Т.е. ложные импульсы вы минимизировали на аппаратном уровне с помощью грубо говоря связки RFID-считывателя и перекрывающего клапана.
Здесь же тема(предложение) было создано для того, что-бы было возможно это сделать программно, так как некоторые клиенты приходят от конкурентов и просят перевести оборудование на wialon. НО! Начинаешь им говорить что-бы на Wialon это работало нужно докупить вот это, это и это. Им естественно это не нравиться, так как на предыдущем ПО у них все это работало и так без дополнительного оборудование.
Нужна возможность это сделать программно, а потом уже на конкретных примерах показать клиенту что для КОРРЕКТНОЙ работы нужно что-то докупить.
Есть счетчик жидкости ППО ДД-40-0.6 от ПриборКомплекта шел вместе с КАМАЗом. К сожалению в комплекте УСС не прилагался. Вообще пользуемся расходомерами от производителя из г. Ливны, думали, впендюрить их УСС, к сожалению не подходит по размеру. Подскажите, какие есть аналоги или другие способы по снятию данных с СЖ и последующей передачи в БК?
Ну 100% от дребезга я так думаю все равно не избавишься. Все-таки аналоговый сигнал есть аналоговый сигнал, а любой даже один ложный импульс отобразиться в отчете нулем что не есть гуд.
А так бы фильтр поставил на 0.0001 например, и не надо будет фильтровать.
И кстати по описанной выше фильтрации (отчет который Вы мне скинули).
Насколько я знаю на вашей установке есть тублер экстренной выдачи топлива без RFID карты и если его щелкнуть и выдать топливо то данная выдача не попадет в отчет в Wialon, так как в этих сообщений не будет значения RFID.
Я понимаю что на данный тумблер ставится пломба, но если данная строка не попадет в отчет не будет оперативно замечено что произошла выдача топлива без карты.
Клиент попросит вывести данную выдачу в отчет, но при снятии фильтрации по водителю в отчет попадут лишние нули и другие ложные значения по которым клиент начнет задавать каверзные вопросы.
Опять одно за другое цепляется.
если не подходит УСС, возможно счетчик выпущен до 2008 года, там нужно либо два шлица спиливать болгаркой, или менять шестеренки.
Либо как вариант ставить датчик До : http://exzotron.ru/datchik-oborotov-do-10-0/
Есть счетчик жидкости ППО ДД-40-0.6 от ПриборКомплекта шел вместе с КАМАЗом. К сожалению в комплекте УСС не прилагался. Вообще пользуемся расходомерами от производителя из г. Ливны, думали, впендюрить их УСС, к сожалению не подходит по размеру. Подскажите, какие есть аналоги или другие способы по снятию данных с СЖ и последующей передачи в БК?
yurimasterk а еще хотел спросить про один нюанс с вашим оборудованием.
Когда происходит выдача топлива и когда выдача закончилась закрывается клапан. Особенностью является то что после закрытия клапана через некоторое время (указанное в настройках оборудования) объем выдачи замораживается и все импульсы после этого на терминал и соответственно в Wialon не пересылается.
Ситуация. Если водитель бензовоза отключил клапан или каким-то образом исключил его из цепи, то все что он прольет через ППО никогда не попадет в Wialon, т.е. выдача прошла клапан "типа" закрылся водитель ждет указанное время в настройках оборудования что-бы объем выдачи зафиксировался и заморозился и продолжает лить сколько нужно топлива через ППО и значения УСС не попадут в Wialon.
Как это вовремя диагностировать и пресечь?
Прошу прощения не правильно проконсультировал.
с ДД40 не знаю как снять сигнал. по тем что продают вроде как импульсный выход есть..
ППО ДД-40-0.6
Ну 100% от дребезга я так думаю все равно не избавишься. Все-таки аналоговый сигнал есть аналоговый сигнал, а любой даже один ложный импульс отобразиться в отчете нулем что не есть гуд.
А так бы фильтр поставил на 0.0001 например, и не надо будет фильтровать.И кстати по описанной выше фильтрации (отчет который Вы мне скинули).
Насколько я знаю на вашей установке есть тублер экстренной выдачи топлива без RFID карты и если его щелкнуть и выдать топливо то данная выдача не попадет в отчет в Wialon, так как в этих сообщений не будет значения RFID.
Я понимаю что на данный тумблер ставится пломба, но если данная строка не попадет в отчет не будет оперативно замечено что произошла выдача топлива без карты.
Клиент попросит вывести данную выдачу в отчет, но при снятии фильтрации по водителю в отчет попадут лишние нули и другие ложные значения по которым клиент начнет задавать каверзные вопросы.
Опять одно за другое цепляется.
беда в том что ложные импульсы в этом случае проявляются даже в момент выдачи топлива.
То есть мы получаем погрешность от УСС не на механическом, а на электронном уровне. Это недопустимо.
В случае отключение тумблера, происходит просто отключение блокировки клавиатуры. В нашем варианте, пока не вставлена доступная карта, пользователю заблокирован доступ набора дозы на клавиатуре.
До тех пор пока не набрана доза, модуль по входу импульсы не пропускает.
Снятие тумблера, активирует клавиатуру для набора дозы.
То есть без карты можно произвести отгрузку, данные о расходе поступят через терминал о выданной дозе. Просто в данном случае не будет идентификации. При этом если карта все же вставлена, даже если она и не доступна. Она будет передаваться так же на сервер.
yurimasterk а еще хотел спросить про один нюанс с вашим оборудованием.
Когда происходит выдача топлива и когда выдача закончилась закрывается клапан. Особенностью является то что после закрытия клапана через некоторое время (указанное в настройках оборудования) объем выдачи замораживается и все импульсы после этого на терминал и соответственно в Wialon не пересылается.Ситуация. Если водитель бензовоза отключил клапан или каким-то образом исключил его из цепи, то все что он прольет через ППО никогда не попадет в Wialon, т.е. выдача прошла клапан "типа" закрылся водитель ждет указанное время в настройках оборудования что-бы объем выдачи зафиксировался и заморозился и продолжает лить сколько нужно топлива через ППО и значения УСС не попадут в Wialon.
Как это вовремя диагностировать и пресечь?
После закрытия клапана,включен режим выдачи, то есть даже после закрытия клапана оборудование продолжает сканировать импульсы по счетчику. То есть после закрытия клапана модуль пропускает импульсы от УСС, до тех пор пока не будет 30 секундной паузы. Либо будет нажата кнопка стоп.
Думаю для надежности , можно еще УСС дополнительно на второй счетный канал подключить, для контроля.
В случае отключение тумблера, происходит просто отключение блокировки клавиатуры. В нашем варианте, пока не вставлена доступная карта, пользователю заблокирован доступ набора дозы на клавиатуре.
До тех пор пока не набрана доза, модуль по входу импульсы не пропускает.Снятие тумблера, активирует клавиатуру для набора дозы.
То есть без карты можно произвести отгрузку, данные о расходе поступят через терминал о выданной дозе. Просто в данном случае не будет идентификации. При этом если карта все же вставлена, даже если она и не доступна. Она будет передаваться так же на сервер.
Я говорил про именно отчет в виалоне который вы мне скинули. Он отсеивает данную строку без карты из отчета.
Поэтому остается открытым вопрос по корректному отчету в виалоне для вашей разработки.
Думаю для надежности , можно еще УСС дополнительно на второй счетный канал подключить, для контроля.
Вот это логичное действие. Так мы хотя-бы не потерям данные сколько было выдано топлива при таком развитии событий.
Опять же мы стали обсуждать плюсы/минусы и работу вашей разработки во внештатной ситуации.
И отклонились от первоначальной темы, что в Wialon'e все таки нужен специализированный отчет для УСС или фильтра для его настройки в таблице датчики счетчиков.
Необходимо на аппаратном уровне исключить дребезг, что бы упростить логику создания отчета.
Опять же мы стали обсуждать плюсы/минусы и работу вашей разработки во внештатной ситуации.
И отклонились от первоначальной темы, что в Wialon'e все таки нужен специализированный отчет для УСС или фильтра для его настройки в таблице датчики счетчиков.
Ладно другой пример. Отсеяли мы дребезги на аппаратном уровне.
В трекерах типа ARUSNAVI насколько я помню, а так-же и на ADM трекер не сбрасывает показание в ноль после отправки точки на сервер а постоянно накапливает, т.е. в настройках датчика в объекте виалона нужно поставить тип счетчика не мгновенный а дифференциальный.
НО!
Трекер дойдя до какого-то значения сбросит счетчик в ноль.
Например дойдет он до значения 9999999999 к примеру, если применить что 200 импульсов это 1 литр то 9999999999/200=49999999,995 в таблицу с заправками вылезет значение МИНУС 49999999,995 литров.
Клиент спросит: ЧТО ЭТО? Уберите это!
А удалением сообщений или еще какими-нибудь методами это не уберешь. И данные огромные минусовые показания будут периодически вылезать когда трекер будет сбрасывать показания в ноль.
Отфильтровать с помощью нижней и верхней границы Х в настройках датчика не получится.
А теперь вопрос: Как это отфильтровать в Виалоне из результирующей таблицы?
Поэтому нужны фильтры программные.
Форумчане, добрый день.
Кто сталкивался с подобной задачей - прошу подсказать.
Необходимо оборудовать топливозаправщики (5 и 8 тонн) системой дозированной раздачи топлива (дизель).
Штатно на них установлены ППО-40 и ППО-25. Насколько я понимаю, что кроме терминала и усс необходимо поставить электромагнитный клапан и LED-модуль раздачи. Разграниченный доступ для персонала не нужен.
Поделитесь опытом!!!!
Какое оборудование использовали и возможные "подводные камни"?
А то вопрос серьезный и не хочется перед заказчиком "облажаться".
Заранее спасибо.
Прочитал всю ветку.
В основном все про ДУТ и УСС.
ДУТ ставить изначально не планировали.
УСС - тут все более-менее понятно. Будем использовать продукцию Промприбор.
Остается вопрос с LED-табло дозированной раздачи и клапан отсечки.
Какие выбрать и каких производителей?
Есть примеры использования всего перечня оборудования на одном топливозаправщике?
Какие "подводные камни"?
Думаю есть резон использовать тот терминал, который отправляет данные в нужном виде что бы как можно меньше мудрить с логикой отчета.
Ладно другой пример. Отсеяли мы дребезги на аппаратном уровне.
В трекерах типа ARUSNAVI насколько я помню, а так-же и на ADM трекер не сбрасывает показание в ноль после отправки точки на сервер а постоянно накапливает, т.е. в настройках датчика в объекте виалона нужно поставить тип счетчика не мгновенный а дифференциальный.
НО!
Трекер дойдя до какого-то значения сбросит счетчик в ноль.
Например дойдет он до значения 9999999999 к примеру, если применить что 200 импульсов это 1 литр то 9999999999/200=49999999,995 в таблицу с заправками вылезет значение МИНУС 49999999,995 литров.
Клиент спросит: ЧТО ЭТО? Уберите это!А удалением сообщений или еще какими-нибудь методами это не уберешь. И данные огромные минусовые показания будут периодически вылезать когда трекер будет сбрасывать показания в ноль.
Отфильтровать с помощью нижней и верхней границы Х в настройках датчика не получится.А теперь вопрос: Как это отфильтровать в Виалоне из результирующей таблицы?
Поэтому нужны фильтры программные.
yurimasterk Фильтр в таблице счетчиков по типу минимального и максимального значения не сильно усложнит логику.
По идее должно быть по типу условий:
Если значение в таблице "Датчики счетчиков" в поле "Счетчик" значение меньше нижней границы и больше верхней границы то не выводить эту строку в отчет.
Это позволит использовать разные типы терминалов и избавит от лишних заморочек с фильтрация "сброса" параметра счетчика, паразитных колебаний.
Даже по ДУТам есть параметры "Минимальный объем заправки, литров" и "Минимальный объем слива, литров", почему же не добавить ту же логику для выдачи топлива.
yurimasterk
Теперь вопрос к Вам.
У вас есть решение под названием "Универсальное устройство EFL для топливораздаточной колонки, бензовозов.
С ADM-710"
В данном решении используется терминал ADM и УСС.
В ADM счетчик типа дифференциальный (накапливаемый).
Именно у Вас (не у ваших партнеров) есть адекватный отчет именно в Wialon (без отбрасывании строк без водителя)?
Насколько я знаю для этого Вы используете ПО Fort Telecom где есть "Датчик расхода топлива (топливораздача)" в котором есть параметр "Минимальный фиксируемый размер слива и заправки". Это и есть то что я прошу у разработчиков GURTAM.
Если это уже есть у конкурирующего ПО и успешно используется (при том и Вами в том числе) то почему это в Wialon'е будет усложнение логики отчета (при том логики особо там много добавлять не надо)?
Алексей, в форте отчет программный созданный производителем под различные условия, на Wialon отчет конструируемый.
На форте отчет реализовывали согласно нашего технического задания. В любом случае производитель ПО, должен помочь в этом вопросе...
yurimasterk
Теперь вопрос к Вам.
У вас есть решение под названием "Универсальное устройство EFL для топливораздаточной колонки, бензовозов.
С ADM-710"
В данном решении используется терминал ADM и УСС.
В ADM счетчик типа дифференциальный (накапливаемый).Именно у Вас (не у ваших партнеров) есть адекватный отчет именно в Wialon (без отбрасывании строк без водителя)?
Насколько я знаю для этого Вы используете ПО Fort Telecom где есть "Датчик расхода топлива (топливораздача)" в котором есть параметр "Минимальный фиксируемый размер слива и заправки". Это и есть то что я прошу у разработчиков GURTAM.
Если это уже есть у конкурирующего ПО и успешно используется (при том и Вами в том числе) то почему это в Wialon'е будет усложнение логики отчета (при том логики особо там много добавлять не надо)?
Алексей, в форте отчет программный созданный производителем под различные условия, на Wialon отчет конструируемый.
В том то и дело, что конструируемый, но в этом конструкторе не хватает "кубика" что-бы его нормально доделать.
В любом случае производитель ПО, должен помочь в этом вопросе...
Но к сожалению даже после такого злостого выяснения плюсов и минусов данного решения, производитель ПО жестко игнорит данный вопрос(((
Мне не совсем ясна концепция "Сделать отчёт"
Мне кажется слишком прозрачно размыты критерии для отчёта.
Мне не совсем ясна концепция "Сделать отчёт"
Мне кажется слишком прозрачно размыты критерии для отчёта.
Немного не понял Вас. Не могли бы более развернуто объяснить Вашу мысль.
Страницы 1 … 16 17 18 19 20 … 23 Читать все
Чтобы отправить ответ, вы должны войти или зарегистрироваться
