Здравствуйте! На данный момент режим Наладка никак не фиксируется (+время). В тех местах в отчете, где мы видим время не работы отличное от 0 и нет никаких флагов в DeviceErrorDurations, мы принимаем за время действия режима Наладка. Так же мы имитировали с другими НС, кое где не хватает минут, которые мы таже принимаем за время действия режима Наладка (например 07.08: время НС 26 = 235 минут / 60 = 3,917, а StopWorkTime = 3,97, следовательно 0.05 = 4 минуты приходится на переключение в режим Наладка).
Просьба учесть и реализовать учет действия и фиксацию времени для режима Наладка otchet1.pdf (451 KB)
Вход и выход в режим “Наладка” у ТСРВ-024М+ не фиксируется в архивных записях, он отмечается в отдельном журнале режимов.
Этот журнал у нас считывается только если опрашивается архив событий, так как у нас нет возможности выбрать для опроса отдельные архивы, специфичные для ТСРВ-024М+.
Считайте архив событий, и у вас появятся события входа в различные режимы.
Вы не совсем правы, Антон. У ТСРВ024М+ есть 4 поля в архиве для каждой системы Тпрn1…Тпрn4, в которых записываются времена действия, которые приходятся на определенные флаги НС. Конкретно для Режимов Наладка идет Тпрn4 [n=1…3]. Мы писали здесь http://forum.lers.ru/viewtopic.php?f=8&t=2127 и http://forum.lers.ru/viewtopic.php?f=8&t=2658#p16398
Отдельного флага для Наладки нет - это правда! но время действия фиксируется.
Я помню, что вы говорили о R15 и переработке всей системы хранения, тоесть вы пока не можете получить эти поля и работать с ними (помимо того что в ТСРВ024М+, они еще имеют интеграторы).
Если вы про параметр “Время простоя ТС при выходе из режима “Работа””, то он специфичен конкретно для ТСРВ-024М+.
Он не должен фиксироваться, согласно новым правилам учёта. Для него не предусмотрено кода нештатной ситуации. К тому же он сохраняется нарастающим итогом. В данный момент у нас нет возможности его сохранить в штатном режиме.
В версии R15 мы переработаем систему хранения, что позволит сохранять и рассчитывать потребление для любого параметра.
Если вам необходимо получить значения раньше, мы можем предложить временное решение. Мы создадим ячейки для этих времён. Вы сможете завести ещё одну техническую точку учёта и привязать время наработки к ним. Потребление будет рассчитано, и вы сможете использовать его при формировании отчёта.
Здравствуйте! Давайте закроем пока эти темы до R15, не будем ничего добавлять. Мы вчера придумали как временно избежать отсутствия этих параметров в отчетах. Для нас актуально сейчас полностью отключить опрос “Архива событий” по всем ТСРВ024М+, подготовка отчетов с Архивом ошибок. Спасибо.
Здравствуйте, Антон! Я где то тут на форуме краем глаза видел, что вы иначе решили задачу с полями нарастающего итога, не создавая отдельного хранилища, а иначе. Расскажите подробнее?
С точки зрения пользователя ничего не изменится. Мы собирались реализовать универсальное хранилище для всех считанных данных. Однако эффективность этого решения оказалась очень низкой. Поэтому было принято решение дополнить существующую систему хранения новыми параметрами наработки. А универсальную систему реализовать чуть позже и использовать её только для некоторых специфичных параметров.
Спрашиваю потому, что стоит понять каким образом переделывать отчетные ведомости потом и 2ой вопрос меня больше волнует связан с API, подниму его на неделе.