Ответы в темах
-
Записи
-
Доброго дня! Пытаюсь создать каналы для данных, получаемых со счетчика, но их почему-то нет, Администратор в драйвере видимо их не находит
https://yadi.sk/i/fKVv88tkFpl8GwЕсли нужна помощь, скидывайте исходники, тоже подключусь. Сейчас доберусь до работы и скину исходники в части создания каналов. Если мне память не изменяет, то каналы создаются во вьюв.
Как вариант можно при текущем запросе информации из архива запрашивать текущее время счетчика и в срез добавлять разницу во времени с сервером, чтобы контролировать разницу в показаниях часов, например в минутах.
Только вот сколько я не смотрел описаний как вытаскивать архивные данные (профили мощности) не могу разобраться …
В целом сложного нет ничего, если в устройстве сбиты часы, то так или иначе, каким бы способом архив не вытаскивался (например через оптопорт) он будет бесполезен. На Веге у меня введен дополнительный параметр, который показывает отставание архива, что показывает отклонение текущего времени от времени на сервере, где стоит скада.
Что на счет записи архива в скаду, то все не так уж и сложно:
1. Объявляем переменную в виде срезаTagSrez me23x;
2. Задаем размерность, пока просто все возможные параметрыme23x = new TagSrez(70);
3. Задаем в срез текущее время (в случае с архивом — это время записи, в зависимости от ситуации)me23x.DateTime = DateTime.Now;
4. Присваиваем значения в срез, например так `me23x.KPTags[0] = KPTags[0];
me23x.TagData[0].Stat = BaseValues.CnlStatuses.Defined;
me23x.TagData[0].Val = kanal1;`
5. Добавляем примечаниеme23x.Descr = "Дата обновления " + DateTime.Now;
6. Добавляем срез в базуAddArcSrez(me23x);Архивные данные я пока не загружаю, я пока сохраняю текущие данные в БД скады. Как вытаскивать профили мощности как раз таки разбираюсь, как записать их в БД проблем нет, на Веге это уже проходил. Логика была примерно такая:
1. Выбирается дата отправная, с которой будет производиться первоначальная загрузка, например 1 число текущего месяца. В драйвере где-то должна сохраняться дата (у конкретного экземпляра КП) последнего загруженного показания из прибора учета (архивного показания)
2. В час X производится загрузка показаний (у меркурия это архив 30+30), данные загружаются либо с даты последней загрузки, либо с отправной точки (если данные загружаются впервые)
3. После успешного обновления в параметрах где-то отображается дата последних записанных архивных данных и при следующем обновление данные вытаскиваются только с этого момента по настоящее времяКак-то так )
Начал со старыми исходниками пока ковыряться, данные в архив загружаются.
Пока с сигналами не совсем разобрался, когда драйвер для Веги писал, тоже на это натыкался, но думаю разберусь …
Не публикуются картинки, уже всяко их прикладывал
Есть предложение доделать его для возможности вытаскивать архивы, но хочется поработать со свежими исходниками, можете скинуть в личку, после доработки отправлю исходники обратно.
Доброго дня! При попытке создать входные каналы для данных, Администратор говорит, что в драйвере входных каналов не обнаружено. С чем это может быть связано?
Добрый день! DLL закинул в папку КП, но в Администраторе при попытке добавить КП в списке Меркурий не находит. Куда копать?
Спустя некоторое время возвращаемся в проект по сбору показаний с приборов учета.
И еще одно замечание участнику talbutdinov и именно по ВЕГА. Как раз наше решение базируется на оборудовании этого производителя.
Предлагаемый Вами алгоритм ничем не отличается от прямого доступа к базе сервера ВЕГА (что можно легко реализовать простым написанием View в MySQL — мы это делали на первом этапе) — смысл брать пакет один раз в час, если он пришел почти час назад.Хотелось бы отметить, что у каждого свое видение и подход, по этому замечание не принимается! ) Нам достаточно получать данные и лезть для этого в структуры базы данных, которая кстати со временем может измениться, нам не нет необходимости, когда есть описанный API. Да и открывать базу хотя бы на чтение для нас не совсем с точки зрения безопасности, так как сервисы стоят на разных машинах и общаются по интернету. Так что в нашем случае API — это оптимальный вариант.
А так я тоже рад, что мы не одни «ковыряемся» с LoRaWan и Вегой. С Вегой разговариваем на тему выпуска прошивки для СИ-13-485, чтобы была возможность отправления определенных команд в канал для опроса каких-либо устройств, чтобы не опрашивать их с сервера. По логике устройство отправляет пакет с адресом устройства в канал, устройства получившее его и имеющее этот адрес отправляет ответ обратно и этот пакет записывается на сервере, мы лишь опрашиваем сервер раз в период. Пока как-то так.
На днях должны доделать обработку событий и карты, постараемся все описать и выложить.
На счет однотипности устройств, у нас пока с этим беда, порядка 10 разных, приходится под каждый прописывать драйвер, а точнее логику чтения пакетов.
Вот есть часовая загрузка данных, которые отправляют данные о состоянии приборов учета, а точнее их показания. Если что-то идет не так, а именно если показания не изменяются или слишком большой разбег между часовыми показаниями или суточными (будет определяться по отдельной логике), то система выдает событие о том, что в показаниях имеются проблемы и стоит обратить внимание. Соответственно каждый раз будет всплывать в течении дня сообщение об ошибке при следующей проверке. У оператора открыто окно с событиями и по одному каналу 24 строки с одним и том же событием раз в час минимум, а если по 30 каналам будут события, по каждому 24, то будет «свалка» таких событий. Вот здесь будет лучше сделать так, чтобы если такое событие сегодня уже отображалось, то оно вновь не вылазило, так как в списке событий оно и так весит.
