Добавить текущие значения в расчетные точки учета. [6679]

Продолжение темы: Расчетная точка не имеет текущих значений

Не понравился я форуму :-): Поэтому описание во втором сообщении.

Продолжение темы: Расчетная точка не имеет текущих значений
В расчетных точках явно не хватает текущих значений параметров. Мне они понадобились для отображения в мнемосхемах.
Отсутствие текущих по причине разного времени прихода значений слишком поспешное, на мой взгляд, решение. Не стоит запрещать, то, что будет полезно в реализации проектов на ЛЭРС Учет. Ваше ограничение сейчас выглядит странно, когда в расчетной точке нет текущих, даже если источники данных для этой точки находятся в одном приборе.

Ниже фраза из предыдущей темы.

Перечисленные Антоном ограничения, на мой взгляд, можно обойти добавив в расчетную точку учета новый параметр - период, который должны укладываться значения, чтобы над ними можно было производить операции. Т.е. если все исходные данные в расчетной точке учета укладываются в этот период, то можно производить операции над ними, если выходят за пределы, то нет.
ЛЭРС Учет используется для визуализации процессов учета и секундная задержка не является значимой, для некоторых систем и 10, 60 и даже 300 секунд расхождения допустимы.
Предлагаемый период должен быть настраиваемый, и тот кому потребуются текущие в расчетных точках решит вопрос “динамики объектов” самостоятельно, настроив этот параметр, т.к. лучше Вас знает про “динамику своего объекта”.

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

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

У текущих значений невозможно установить точное соответствие. Представьте что по первой точке учёта считаны данные на начало и на конец периода, а у второй - на середину.
Т.е. у первой точке учёта с пятиминутным интервалом есть данные на
09:00:00 и на 09:05:00

У второй есть только значения на 09:02:30

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

Теоретически, проще было бы рассчитывать данные с какой-то скважностью, выбирая ближайшие к очередной дате показания из каждой точки. Но вряд ли это то, что вам надо.

Не нужно устанавливать соответствие, пока вы не определили параметры по которым устанавливаете. :-):
У меня есть заказчик, которому нужно видеть картину по нескольким стокам. Стоки в описываемом месте - это очень очень медленно меняющийся процесс. И Заказчика устроит, если он будет получать общую картину по стокам +/- 7,5 мин, т.е. с периодом 15 мин. Это же не коммерческие данные, цифры на основе которых считают деньги в архивах. И если пользователь, прекрасно понимая свой процесс, говорит, что для принятия оперативных решений ему нужна такая картинка, то почему Вы против? Тем более, что сделать это мы сможем и будем вынуждены, но уже извне воздействуя на ЛЭРС, а это криво, не правильно, не красиво и главное не стабильно при длительной работе (Вы же регулярно меняете ЛЭРС). И в конечном итоге, внешние программные “костыли” ложатся черным пятном на светлую картину ЛЭРС Учета :-):

Теперь про Ваш пример. У меня в голове простой алгоритм. Если период - 5 мин., то:

  1. получив данные по 1 -ой точке в 09:00:00, проверяем наличие данных назад по второй точке на глубину периода. Их в примере нет. Ничего не делаем
  2. получив данные по второй точке в 09:02:30. Аналогично изучаем прочие источники, на 5 мин. назад. Обнаруживаем данные за 09:00:00
  3. рассчитываем текущее значение для расчетной точке, используя данные за 09:00:00 и 09:02:30. Метку времени присваиваем 09:00:00.
  4. и т.д.

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

В принципе, алгоритм более-менее выкристаллизовался. Поставим в план реализацию предварительно на R26.

Расчёт текущих данных в расчётных точек будет доступен в версии R25. Чтобы он работал, текущие по всем исходным точкам учёта должны быть получены в пределах пяти минут.