Методы ModLogic для разработки модуля

Стартовая страница Форумы Разработка и интеграция Методы ModLogic для разработки модуля

Просмотр 15 сообщений - с 1 по 15 (из 15 всего)
  • Автор
    Сообщения
  • #4816
    Romiros
    Участник

    Михаил, добрый день. Вы говорили что создавать произвольные архивы лучше через модуль.
    Посмотрел реализацию ModTest и ExportDB.
    Я так понимаю в данный момент используя методы доступные в ModLogic можно получать только текущие данные входных каналов (OnCurDataProcessed) или архивные, поступающие от драйвера (OnArcDataProcessed).
    OnCurDataCalculated использовать по-моему не вариант (каждые 100 мс) большая нагрузка на сервер.
    Собственно вопрос:
    — Как получить текущие и архивные данные всех каналов (входные и дорасчетные) нормальным способом ?
    Я придумал только два идиотских способа:
    1. По таймеру в модуле (далее вычисление ближайшего времени записи и т.д.).
    2. Добавить в ModLogic и MainLogic соответственно события при записи текущего, минутного и часового срезов. Но это опять изменение исходников, хотя было бы удобно. Приходит событие что срез изменился и нужно его перезапросить.
    Может я просто что-то неправильно понимаю в архитектуре?

    #4819
    Mikhail
    Модератор

    Добрый день!
    Интерфейс ServerData предоставляет метод GetSnapshot, который позволяет получить архивы из кода серверного модуля.

    Если можно, опишите Вашу задачу в целом, а то не совсем ясно, что посоветовать.

    #4820
    Romiros
    Участник

    Спасибо. Я его и использую, сразу просто не заметил или его раньше не было. Очень удобно стало. У меня вопрос по какому событию правильно запустить выполнение алгоритма?
    OnCurDataProcessed не подходит.
    Мне нужно по мере поступления данных в таблицы часовых срезов суммировать их за сутки. Еще конечно было бы не плохо получить секундный настраиваемый архив. Допустим раз в 5 секунд записывается срез.

    #4822
    Mikhail
    Модератор

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

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

    #4823
    Romiros
    Участник

    Спасибо, буду пробовать

    #4841
    Romiros
    Участник

    Добрый день, Михаил. Наверное можно в этой же теме продолжить.
    Использую метод ProcArcData(SrezTableLight.Srez snapshot)
    Пишет одинаковые данные и в минутную и часовую таблицы если время среза равно началу часа (11:00 например). Я так понял вычисляется ближайшее время записи.
    Так и должно быть?
    Просто при передачи часовых архивов будет перезаписываться и первая минута часа и соответственно наоборот при передачи минутных архивов.

    #4845
    Mikhail
    Модератор

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

    #4846
    Romiros
    Участник

    По мне как-то не логично 🙂
    Допустим с 00:00 до 01:00 я пишу каждую минуту в минутный срез значения. В часовом срезе на я должен получить среднее из них за час, а получу значение как минутного среза на 01:00. Получается искажение информации. Или не так?
    Я так понимаю для записи готовых минутных и часовых архивов нужно идти не этим путем, а через драйвер scada-коммуникатора?
    Или использовать ServerComm SendArchive?
    А передача данных из модуля для чего-то другого?

    • Ответ изменён 8 лет, 7 месяцев назад пользователем Romiros.
    #4848
    Mikhail
    Модератор

    Если можно, опишите свою задачу с точки зрения общей идеи.

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

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

    #4849
    Romiros
    Участник

    Действительно лучше опишу ситуацию.
    Возьмем один параметр.
    1. Поступает он в скаду по OPC. Скада производит усреднение и архивирование.
    2. Есть часовые архивы этого параметра лежат в БД MSSQL Server.
    3. У скады доступа к прибору нет, то-есть данные получаем от систем сбора данных (текущие — OPC, архивные — SQL ).
    4. Что я хочу сделать:
    1. После того как в БД SQL появляются архивные данные (могут появиться и через несколько дней, каналы связи не надежные по-сравнению с системой сбора текущих значений) я хочу эти часовые значения записать в часовые срезы скада и присвоить им статус архивный ( т.е. для пользователя это будет означать, что данные уже «коммерчески» правильные, получены из прибора)
    2. Поскольку ProcArcData позволяет формировать срезы за любую дату, можно перенести в скада информацию за предыдущие годы. Для нас это очень удобно.
    3. Через модуль записывать события из БД SQL, тут вроде проблем быть не должно.

    Т.е. по сути мне нужен импорт из MS SQL.
    Проблема в том, что как только я эти часовые архивы начну писать в таблицы срезов, я буду искажать информацию минутных срезов (а при записи минутных часовые — еще страшнее).

    Вот и хочу спросить каким путем пойти? 🙂

    #4853
    Mikhail
    Модератор

    Похожая ситуация при выкачивании архивов из приборов учёта, например, теплосчётчиков. Мы в цикле получаем текущие (итоговые) данные и записываем их в скаду, как обычно. При этом прибор сохраняет в своей памяти часовые и суточные архивы, которые можно выкачать из него. Учёт потребления должен строится на тех архивных данных, которые выкачаны из прибора. Поэтому были созданы отдельные входные каналы для часовых данных и отдельные каналы для суточных. Минус в том, что получается много доп. каналов, но плюс в том, что информация не теряется.

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

    #4855
    Romiros
    Участник

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

    #4859
    Mikhail
    Модератор

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

    редактирование по принципу как это сделано в скада-сервер, только автоматически?

    Эта фраза мне не совсем понятна.

    #4861
    Romiros
    Участник

    Да может быть с отдельными каналами будет лучшим вариантом, если брать не все параметры а только расход (можно сказать что так специально задумано для сравнения 🙂 ).
    По поводу редактирования я имел ввиду то как реализовано редактирование в скада-сервере. Открывается таблица нужного среза вносятся изменения и таблица обновляется.
    Но я тупанул, так можно открыть только существующую таблицу срезов, а не создать новую.

    #4863
    Mikhail
    Модератор

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

Просмотр 15 сообщений - с 1 по 15 (из 15 всего)
  • Для ответа в этой теме необходимо авторизоваться.