[Вопрос] Корректность данных получаемых функцией getPriorityTagDuration()

[Сергей Борисов]

В процессе разработки динамического приложения появилась необходимость получать все статусы оборудования с учётом приоритетности за текущий день/смену в режиме реального времени. Используя метод getPriorityTagDuration() WINNUM JavaScript SDK получаю данные, которые не соответствуют данным в отчетах. 

Например, в приложенном скриншоте №1 с данными полученные функцией getPriorityTagDuration() видны частые появления тега статуса "Станок выключен", хотя в приложенном скриншоте №2 видно, что в отчёте по работе оборудования за текущий день, статуса "Станок выключен" нет. Также не совпадают временные метки старта и окончания действия тегов, например, тег "М0 останов", см. скриншот №3.

В чём может быть причина таких расхождений? Или расчёт длительности тегов, выполняемый в функции getPriorityTagDuration() отличается от методов расчётов для стандартных отчётов? Или требуется какая-то настройка платформы для получения корректных данных?

Hello World!:

- Сообщений не найдено.

[Lamantur]

Добрый день! Выскажу предположение. Если я правильно понял, то на последних двух скриншотах показаны отчеты для двух разных приложений, в одном из них есть М0 в приоритетности, в другом нет. Нужно проверить, а какое приложение указано в запросе.
getPriorityTagDuration(appid, pid, startTime, endTime, [callBackFunc]) - Параметр appid - идентификатор приложения
Возможно вы указали идентификатор самого динамического приложения или редактора, а для него теги не настраивали.
Приоритетность тегов устанавливается в настройках для каждого приложения.

Hello World!:

- Сообщений не найдено.

[Сергей Борисов]

День добрый!

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

   
   Всё верно! Я специально привёл пример из разных стандартных отчётов, так как из-за наличия ручных причин простоев, не видно включено оборудования или нет.
   
   • Скриншот №2 - отчёт с основными статусами работы оборудования, который открывается со страницы оборудования на вкладке "День".
     
   • Скриншот №3 - отчёт статусов работы оборудования с учётом тегов приоритетности, который открывается на странице отчётов > "Работа оборудования"
     
   
   

2. Нужно проверить, а какое приложение указано в запросе.

   
   Идентификатор приложения в функции указан такой же как и в отчётах, где были сделаны скриншоты, а также указаны верные значения даты начала и окончания!
   
   
3. Вопрос был в правильности расчётов функции getPriorityTagDuration() JavaScript WINNUM SDK. Полученные данные из функции не соответствуют ни одному из стандартных отчётов. Может метод getLastTagDataCalculation() Java класса, к которому выполняется запрос, считает и отдаёт неверные данные?
   

Hello World!:

- Сообщений не найдено.

[Lamantur]

Я бы для начала проверил теги. Например - приходят ли сигналы в тот промежуток времени, когда функция выдает "Станок выключен".
Обычно результаты функции совпадают с отчетом по приоритетности - данные, с которыми они работают одинаковые. Может у вас стоит слишком большой таймаут в настройках отчета (вкладка таймаут и потеря связи, по умолчанию 60 000 мс = 60 секунд)? Я не вижу всего вашего результата, поэтому сложно оценить. Но на первый взгляд такое ощущение, что тег NC_OFF сбивает время для остальных тегов, что как раз может быть вызвано слишком большим таймаутом на потерю связи. При слишком маленьком таймауте - наоборот появляются черные полосы в отчете.

Hello World!:

- Сообщений не найдено.

[Сергей Соловьев]

Я бы для начала проверил теги. Например - приходят ли сигналы в тот промежуток времени, когда функция выдает "Станок выключен".
Обычно результаты функции совпадают с отчетом по приоритетности - данные, с которыми они работают одинаковые. Может у вас стоит слишком большой таймаут в настройках отчета (вкладка таймаут и потеря связи, по умолчанию 60 000 мс = 60 секунд)? Я не вижу всего вашего результата, поэтому сложно оценить. Но на первый взгляд такое ощущение, что тег NC_OFF сбивает время для остальных тегов, что как раз может быть вызвано слишком большим таймаутом на потерю связи. При слишком маленьком таймауте - наоборот появляются черные полосы в отчете.

Добрый день!
getPriorityTagDuration работает корректно в приложении с тегами, сигналы которых приходят регулярно, эта функция соответствует отчету Время в состоянии. Вы можете сравнить эту функцию с отчетом, увидите те же самые цифры. Попробуйте создать приложение с одним станком, со стандартными тегами. Отчет и функция для этого приложения покажут корректные результаты. Но, если в списке приоритетности имеется тег, который связан с сигналом, значение которого не приходило в заданном интервале времени ( например, Причина простоя ), то функция и отчет перестает давать корректные результаты, так как используется старый механизм определения состояния, не учитывающий возможность отсутствия значений сигналов.
Функция getLastTagDataCalculation () также работает корректно, если значения сигналов приходят в заданном интервале времени. Но также, если значение сигнала тега не приходит, функция не может вычислить состояние тега.

Hello World!:

- Сообщений не найдено.

[Сергей Борисов]

Обычно результаты функции совпадают с отчетом по приоритетности - данные, с которыми они работают одинаковые.

Данные в отчётах "Время в состоянии" и в "Работа оборудования" ВСЕГДА не совпадают! Причём не только появляются статусы "Станок выключен", но и временные метки начала и окончания действия тегов тоже не совпадают в этих отчётах!

Может у вас стоит слишком большой таймаут в настройках отчета (вкладка таймаут и потеря связи, по умолчанию 60 000 мс = 60 секунд)?

В настройках основного приложения "Системные параметры > Сигналы и потеря связи" параметр Максимальный период ожидания сигнала = 60000

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

Создал новое приложение с одним станком. Данные в отчетах "Время в состоянии" и в "Работа оборудования" совпадают, но заметил несоответствия:

1. на странице оборудования с настройкой Исключить статус -Под нагрузкой- = true и в настройке "Приоритетность Тегов оборудования" убран тег NC_WIP - не совпадают данные двух графиков! На одном статус "Станок выключен=0%", а на временной шкале и в детальном окне видно, что станок был выключен! Также статус "Станок выключен" виден в отчете "Время в состоянии". См. скриншот №4 и скриншот №5;
   
2. на странице оборудования с настройкой Исключить статус -Под нагрузкой- = false и настройка "Приоритетность Тегов оборудования" установлено исходное значение - снова не совпадают данные двух графиков, но имеется отличие! На одном статус "Станок выключен=0%", на временной шкале ниже, уже не видно, что станок был выключен, а на временной шкале в детальном окне видно, что станок всё-таки был выключен!. См. скриншот №6.
   

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

У нас одно основное приложение, в котором настроены теги приоритетности, применяемые для разных стоек ЧПУ. Не все стойки ЧПУ одинаково могут отдавать сигналы, которые привязаны к тегам приоритетности, например, стойки HAAS не отдают сигналы связанные с ручками коррекции скоростей.
Сигналы, связанные с ручными причинами простоев - приходят всегда, так как для них запущен повторяющийся сигнал.

Может стоит изменить алгоритм расчёта JAVA метода getLastTagDataCalculation(), раз он не может правильно отрабатываться в подобных случаях?

---

У нас стоит задача получать OEE конкретного оборудования за текущий день в реальном времени. Хотелось бы получать итоговые значения для каждого тега, аналогичные табличным данным, отображаемые в "Отчет OEE". Возможно есть какая-то JavaScript функция в SDK для этого случая?

Hello World!:

- Сообщений не найдено.

[Сергей Соловьев]

Если правильно понял, вопрос на скринах в том, что график работы отличается от детального отчета о работе оборудования. Это объясняется тем, что интервалы менее 2 пикселей не отображаются браузером. В результате на графике работы малые интервалы не видны. Это также видно в отчете о работе оборудования. Малые интервалы могут не отображаться, поэтому и добавлен детальный отчет о работе, его ширина достаточна для того, чтобы отображать интервалы в несколько секунд. Эта проблема не относится к работе функций. График загрузки оборудования на странице мониторинга округляет значения, при этом состояние Станок выключен рассчитывается вычитанием из общего времени время остальных тегов. К тому же имеет механизм расчета, который дает небольшую погрешность, поэтому интервал при переводе в проценты дал 0. В отчетах и вкладке Смена этот механизм уже улучшен, но интервал слишком мал, и там тоже может дать вам 0 при округлении. Это также не имеет отношение к SDK.

Вопросы об улучшениях и исправлениях ошибок, например, по поводу getLastTagDataCalculation и getPriorityTagDuration корректнее задать на support.winnum.io, потому что они там отслеживаются и ставятся в планы. Но, насколько я знаю, эти изменения уже планируются. Если узнаю об изменении, напишу в этой теме.

Для вычисления состояния за текущий день ( если все же getPriorityTagDuration не дает для вас верных результатов и пока она не улучшена) можно использовать getTagIntervalCalculation, функция возвращает все интервалы, их начало и окончание, и просуммировать все интервалы для каждого тега.

Альтернативно можно использовать результат расчета робота малых интервалов, который записывает результат расчета раз в три минуты в блокчейн, однако надо иметь ввиду, что робот малых интервалов рассчитывает с некоторой погрешностью из за стыков времени, поэтому в отчетах пока не применяется. Для вашей задачи, возможно, это подойдет, попробуйте. Если точность устроит, метод значительно ускорит ваше приложение. Сигнал записывается в оборудование в формате [App ID].[Tag ID].i.[тип расчета].[тип значения].[номер смены]. Номер смены необязательно. Пример ascii сигнала: 17.145.i.SCHED_PRIO.HOUR, где 17 - номер oid приложения, 145 - номер oid тега, i - обозначает малые интервалы,  SCHED_PRIO - расчет с учетом приоритетности, HOUR - получить часы . Можно запрашивать сразу несколько тегов, через |, например, '17.145.i.SCHED_PRIO.HOUR|17.146.i.SCHED_PRIO.HOUR|17.147.i.SCHED_PRIO.HOUR'. Пример запроса:
   

Код:

baseSdkUtils.service.WNConnectorHelper.getSignal(
        'AB50B7B8-2BCC-4566-B7E7-1F2ECDAB82ED', //идентификатор изделия
        '17.145.i.SCHED_PRIO.HOUR', // идентификатор сигнала
        false, //по дате
        false,  // сортировка
        '2024-04-26 00:00:00', // начальная дата
        '2024-04-26 23:59:59',  // конечная дата
        '', // количество
        function(data){
          console.log( data );
    });

И, конечно, робот приложения должен быть создан и запущен в Администрировании.

Результаты расчета по обоим методам лучше сравнивать с отчетом Загрузка оборудования из раздела Отчеты, Отчеты (календарь). Со страницей мониторинга за день не сравнивайте, там другой механизм, без учета приоритетности.

Hello World!:

- Сообщений не найдено.

[Сергей Соловьев]

Кстати, вместо getLastTagDataCalculation вы можете использовать getLastTagValue, это новая функция, которая есть в SDK, но еще не попала в документацию. Вычисляет последнее состояние тега и значения сигналов.

Hello World!:

- Сообщений не найдено.

[Lamantur]

Кстати, вместо getLastTagDataCalculation  вы можете использовать getLastTagValue, это новая функция, которая есть в SDK, но еще не попала в документацию. Вычисляет последнее состояние тега и значения сигналов.

Сергей, а какие тогда в ней аргументы? И в вызове у нее так же WNApplicationTagHelper?

Hello World!:

- Сообщений не найдено.

[Сергей Соловьев]

Кстати, вместо getLastTagDataCalculation  вы можете использовать getLastTagValue, это новая функция, которая есть в SDK, но еще не попала в документацию. Вычисляет последнее состояние тега и значения сигналов.

Сергей, а какие тогда в ней аргументы? И в вызове у нее так же WNApplicationTagHelper?

baseSdkUtils.service.WNApplicationTagHelper.getLastTagValue(appid, pid, tid, endTime, timeout_mills, [callBackFunc])
Пример есть в теме https://community.winnum.io/showthread.php?tid=15
Вообще, список функций можно увидеть в консоли: console.log( baseSdkUtils); там же будут видны аргументы

Hello World!:

- Сообщений не найдено.