- В этой теме 23 ответа, 3 участника, последнее обновление 7 лет назад сделано
.
-
Сообщения
-
Добрый день, есть ли возможность записать данные из драйвера во вчерашнюю базу или в базу месячной или более давности. Например в определенный день, определенного месяца записать значение ?
Добрый день!
Драйвер может передавать текущие данные, архивные и события. Текущие данные не содержат метки времени. Архивные данные и события записываются на ту дату, которая для них установлена в коде драйвера. В общем-то на любую в пределах срока хранения данных сервером.Михаил, а можно сразу вопрос вдогонку?
Правильно ли я понимаю: при записи данных в прошлое, если такой временной срез не существовал вообще, то он нормально создается. А вот если он существовал, то запишутся только те каналы, которые существовали?
По крайней мере на практике у меня получается так.Ну я вопрос задал куда копать ? SetCurData это текущие данные, а какие команды для архивных и где в коде посмотреть примеры с установкой даты для записи?
Хм, остается вопрос, как новый файл будет подключаться к общим данным, например для просмотра графика ?
Как обычно
TagSrez srez = new TagSrez(1);
srez.DateTime = DateTime.Today-100;
Ну и т.д. И у вас в архивах будет файл с данными на 100 дней назад.Если вы с этим разобрались, можете накидать простенький код для понимания ?
Собственно есть вопросы при реализации из драйверов счетчика. Не знаю, насколько оно реализуемо.
Есть драйвер, где я определенным номером команды выполню опрос месячных срезов мощности. Соответственно Январь, Февраль, Март и т.д.
Требуется. При отсутствии базы ее создать и записать с нынешнего дня все прошлые месяцы, при повторном запуске записать только не достающие месяцы в базу.
При этом желательно не создавать каналы в текущих базах. Это возможно ?С теми возможностями, которые есть сейчас в скаде думаю нет.
1. Есть только таблицы минутных и часовых срезов, куда писать значение за месяц? Т.е. такую таблицу нужно сгенерировать, допустим модулем(до этого пока не добрался).
2. Перезагружаемый метод передачи архивов в коммуникатор или сервер не позволяет разделять какие срезы передавать (минутные или часовые). Т.е. не создавая доп каналов Вы будете искажать информацию (я уже столкнулся, выглядит очень некрасиво на графиках, когда в последнюю минуту часа приходит средний расход за час). Тут мне кажется нужно расширить метод ProcArcData и AddArcSrez, чтобы можно было четко указать что и куда мы пишем (но это мое видение, могу ошибаться).
3. Если вы будете передавать данные за далекое прошлое, т.е. когда данный канал еще не существовал в архивных срезах, но сами срезы уже были, то он просто не запишется.
Как можно сделать Вам с учетом вышесказанного:
По-любому создать доп каналы (дорасчетный с формулой по типу DayBeg(), только отслеживать конец месяца) и писать допустим в последний час месяца, а остальные обнулять.
Просто даже если сгенерировать свою месячную таблицу, отобразить данные получится только пользовательским web страницами.Короче все упирается в исходники. Либо их править самим, либо можно скинуться Михаилу на разработку :).
Уже нескольким людям нужны дополнительные срезы. Сформулируем общую задачу, собираем народ, сделаем коммерческое предложение, от которого невозможно отказаться 😀.
Просто хотелось, чтобы дневные, месячные, годовые срезы были нативными и с ними можно было работать из скада.Да уж, пошел в Новые идеи писать 🙂
Я уже предлагал Михаилу сделать голосовалку по тем или иным моментам, с определением конечной цены за модуль (например 500р). Народ начинает оплачивать стоимость модуля и когда наберется сумма на разработку то начинать его делать. Все оплатившие до разработки автоматом получают ключ…Ладно, пока буду писать в каналы и попусту тратить место баз…
1. да, нужно сгенерировать новую БД при первоначальном обращении командой к драйверу, если такой БД еще не было.
2. Это должен быть совершенно иной срез данных (так как база новая или существующая но созданная нами) — насколько понимаю сама RapidSCADA не умеет работать в нынешнем состоянии с другими БД, даже если я их создам из драйвера средствами же самой RapidSCADA (печально, механизмы вроде есть…)
3. Дорасчетные каналы на катят, так как данные по месячным срезам уже все подсчитаны в самом счетчике, их надо просто вытащить, дергать их постоянно в каналы по месяцам ну это расточительство. Один счетчик бы фиг с ним, а сотня уже жесть…Я тоже за нативность в рамках всей SCADA системы, и эти механизмы в последующем должны быть в составе ядра и бесплатны. Иначе просто не будет развития системы.
Пусть и для первоначальной разработке придется заплатить, но для одного человека, если это не оплачивается заказчиком, это проблема. А скинуться толпой уже вариант.
Речь конечно идет не о специализированных модулях, а именно о тех модулях или доработках, которые улучшат систему в целом.Я создавал в директории архивов новые папки Sec(секундный) и Day(Дневной), но это правка исходников и очень большая, перекомпилируется считай вся скада. Короче не вариант.
С дорасчетными да это лишнее, это я уже по инерции свои задачи приплел.
Вобщем пока в прошлое нормально можно писать только события. Это я реализовал.
Полностью согласен. Подождем ответа Михаила, он там вплотную новыми схемами занят судя по гитхабу.Может действительно в складчину потянем.
Так я и не хочу переделывать исходники, а то потом черт ногу сломит, я и так с драйверами уже больше года ковыряюсь, так как не программист…
Одно дело опросить сам прибор, и совсем другое красиво это всунуть в scada, но вот не хватает способов сделать это красиво. Либо перегрузка лишним существующих баз, либо невозможность потом самой scada это посмотреть.Еще предлагал как-то реализовать механизм настраиваемого WEB окна через команды управления, типа в Канале управления вместо № команды писать #myWindow1&read=true а Web откроет окно с настройками myWindow.txt (или xml) где можно было бы задавать поля для вывода, указывать номера сигналов для чтения из прибора, кнопки считать, записать (если установлено значение read=true то считать при открытии окна). Оттуда же сделать экспорт в exel, например вызывая плагин отчетов…
Было бы классное решение привязывать все настраиваемые параметры приборов вообще без привязки к БД, так как они не нужны…
- Вы должны авторизироваться для ответа в этой теме.