This is topic Принудительная перерисовка графики in forum Общие вопросы / Common questions at Форум TRACE MODE: техническая поддержка.


To visit this topic, use this URL:
http://forum.adastra.ru/ultimatebb.php/ubb/get_topic/f/45/t/000399.html

Posted by WinCap (Участник № / Member № 6077) on :
 
В Справочной Системе для канала вызова шаблона экрана указано два способа принудительной перерисовки графики: послать 6,7 в атрибут (0,R) и установить флаг (0x10000 ForceUpdate) атрибуту (52,FS).

Ответьте, пожалуйста:
1. Эти два метода (R и FS) равнозначны?
2. Если экран видим, с каким периодом у него происходит перерисовка графики? И как на это повлияет установка принудительной перерисовки?
3. Разрешается ли устанавливать принудительную перерисовку экрана на каждом цикле системы?
 
Posted by АдАстра. Техподдержка (Участник № / Member № 4) on :
 
Уточните для каких целей требуется принудительная перерисовка графики? Вы проводите исследования графической части системы? Перерисовка графики на каждом цикле не имеет смысла, например если делать через 7-ку в R только данные из буфера тренда будут стираться и тренд реального времени ничего не покажет. Данная функция в большей степени отладочная, прикладного значения при нормальной работе не имеет, будет расходовать только больше ресурсов ПК. Рекомендуем ForceUpdate не использовать. Если перерисовка очень требуется, используйте R.

При штатной работе перерисовка графики определяется периодом вызова канала CALL.SCREEN, причем обновление данных по аргументам происходит асинхронно - по мере изменения атрибутов каналов, привязанных к аргументам.
 
Posted by WinCap (Участник № / Member № 6077) on :
 
Конечно, я исследую графическую часть системы. Мне же больше заняться нечем...

1. Если вывести на Экран значение Генератора “Пила”, то отчетливо видно, что некоторые значения “пропускаются”. Если Генератор и Экран имеют один период пересчета, то почему это происходит?

2. Чем все-таки отличается установка ForceUpdate и отправка 6 в атрибут (0,R)?

3. Если все каналы проекта имеют один цикл пересчета, значит, за сто циклов графика будет обновлена сто раз, по одному разу на цикл. Что, в таком случае, изменит установка ForceUpdate?

4. Что это за размытая формулировка “Рекомендуем ForceUpdate не использовать”? В настоящее время нами используется флаг ForceUpdate для исправления “некорректной” работы графической части системы, поэтому можно поконкретнее?
Как это работает, что при этом происходит и какие могут быть последствия? Как правильно этот флаг использовать?

[ 07.06.2022, 09:40: Сообщение отредактировал / Message edited by АдАстра. Техподдержка ]
 
Posted by АдАстра. Техподдержка (Участник № / Member № 4) on :
 
Рекомендуем использовать штатные механизмы, заложенные в SCADA. TRACE MODE обладает внушительным функционалом для отладки проекта и ПНР. Часть отладочных функций мы не рекомендуем использовать в штатной работе проекта 24/7. В том числе и описанную функцию. Рекомендуем в случае острой необходимости использовать перерисовку экрана через 0,R канала вызова Экрана. Неисполнение рекомендаций может привести к излишним тратам ресурсов системы и даже сбоям в работе проекта.
Как уже было описано выше, поток графики асинхронный. Если говорить о трендах, по умолчанию
используется интерполяция. Если установить курсор через функцию ГЭ "К метке времени", то данное значение, если оно реально было, будет показано.
Как уже было описано выше, обновление графики штатно происходит по мере изменения атрибутов каналов, привязанных к аргументам.
Необходимо разобраться в причинах “некорректной” работы графической части системы. Необходимо прислать на электронную почту техподдержки актуальный проект, где данная проблема наблюдается, папку узла проекта после запуска, описание как данный эффект воспроизвести и как он наблюдается оператором (лучше приложить скрин или видео, где это наглядно видно).
 
Posted by WinCap (Участник № / Member № 6077) on :
 
1. Если вывести на Экран в простой ГЭ Текст значение, например Генератора “Пила”, то отчетливо видно, что некоторые значения “пропускаются”. Если Генератор и Экран имеют один период пересчета, то почему это происходит?

2. Чем все-таки отличается установка ForceUpdate и отправка 6 в атрибут (0,R)? Как эти функции работают, что при этом происходит и какие могут быть сложности? Как правильно эти функции использовать? И чем такое принудительное обновление отличается от стандартного обновления графики, происходящего на каждом цикле системы?

3. Если все каналы проекта имеют один цикл пересчета, значит, за сто циклов графика будет обновлена сто раз, по одному разу на цикл. Что, в таком случае, изменит установка ForceUpdate или отправка 6 в атрибут (0,R)?

[ 07.06.2022, 09:41: Сообщение отредактировал / Message edited by АдАстра. Техподдержка ]
 
Posted by АдАстра. Техподдержка (Участник № / Member № 4) on :
 
1. Данная проблема устраняется системными настройками. Мы можем оказать помощь локализации и устранению проблемы. Для этого пришлите Ваш проект, в котором эта ситуация воспроизводится.

2. Принудительное обновление перерисовывает весь экран, штатная перерисовка обновляет только ГЭ согласно обновлению аргументов.
При записи команды стандартным образом через 0,R на следующем цикле штатно будут выполнены внутренние алгоритмы канала вызова шаблона экрана. При ForceUpdate результат не гарантирован, что-то может не обновиться.

3. Нет. В ответе на вопрос 2 указано, что перерисовываются только те ГЭ, у которых изменились значения привязанных аргументов экрана.
Принудительная перерисовка приведет к перерисовке всех ГЭ (включая статические ГЭ и динамические ГЭ, у которых значения привязанных аргументов экрана в текущем цикле пересчета не изменились), на что потребуется больше ресурсов, чем на перерисовку только тех ГЭ, у которых изменились значения привязанных аргументов экрана.

[ 08.06.2022, 10:34: Сообщение отредактировал / Message edited by АдАстра. Техподдержка ]
 
Posted by WinCap (Участник № / Member № 6077) on :
 
“штатная перерисовка обновляет только ГЭ согласно обновлению аргументов”
Теперь понятны причины “некорректной” работы графической части системы...

Для исправления случая, когда аргумент изменил своё значение, а ГЭ, привязанный к нему, не был обновлен штатно, используется принудительное обновление экрана. Понятно, что это вызывает дополнительную “графическую” нагрузку.
Может существует способ как-то “встряхнуть” аргумент, не меняя его значение, чтобы ГЭ, привязанный к нему, был обновлен штатно? Например, вызвать принудительную обработку привязанного к нему канала через установку (39, EXEC)?

[ 08.06.2022, 09:58: Сообщение отредактировал / Message edited by АдАстра. Техподдержка ]
 
Posted by АдАстра. Техподдержка (Участник № / Member № 4) on :
 
К сожалению, Ваши сообщения приходится редактировать согласно правилам форума.

"Некорректная" работа графической части (проблема с отображением значения в ГЭ Текст) разрабатываемого Вами проекта может быть решена системными настройками. Мы можем оказать помощь локализации и устранению проблемы. Для этого пришлите Ваш проект, в котором эта ситуация воспроизводится.

Описанная Вами методика решения проблемы увеличивает потребление ресурсов. Данный метод мы считаем сомнительным решением.
 
Posted by WinCap (Участник № / Member № 6077) on :
 
Речь идет не о ГЭ Текст, а о ГЭ Кнопка, которые, как Вам давно известно, “залипают” при двойном клике. Поскольку Вы эту проблему так и не решили, приходится решать её таким не оптимальным методом.

Из Ваших ответов следует, что наиболее приемлемым способом принудительно обновить экран является отправка 6 в атрибут (0,R). Спасибо за разъяснение.
 
Posted by АдАстра. Техподдержка (Участник № / Member № 4) on :
 
Проблема залипания ГЭ Кнопка при двойном клике нам не известна.
Если она у Вас стабильно воспроизводится, то пришлите проект с описанием как воспроизвести проблему (дополнительно видео воспроизведения проблемы приветствуется).

В этом же письме Вы можете прислать запрошенный нами пример с проблемой ГЭ Текст и генератором Пила (Сообщения от 07.06.2022)

Вы правы, рекомендуемый способ принудительного обновления графики экрана через отправку значения в атрибут (0,R) канала Call.Screen.

Но Вы не правы, что это оптимальное решение в Вашем случае. Принудительная перерисовка графики на каждом цикле пересчета приведет к увеличению потребления ресурсов ПК.
 
Posted by WinCap (Участник № / Member № 6077) on :
 
"Принудительная перерисовка графики ... приведет к увеличению потребления ресурсов ПК".
Но если ресурсов более чем достаточно это же не приведет к ещё каким-то проблемам?

[ 10.06.2022, 14:45: Сообщение отредактировал / Message edited by АдАстра. Техподдержка ]
 
Posted by АдАстра. Техподдержка (Участник № / Member № 4) on :
 
Наличие достаточных ресурсов не является поводом их нерационально использовать.
Если ресурсы использовать нерационально на решение мелких задач, то их может не хватить на решение приоритетных.
 


Новости АСУ ТП / News | SCADA / HMI | Обучение / Trainings | Свяжитесь с нами / Contact Us



Powered by Infopop Corporation
UBB.classic™ 6.7.2