Странная работа FBD-блока Fronts? или ClrSrcreen? (нет проблемы)

[MadKid]

Здравствуйте, товарищи и коллеги.

Изучаю работу SMLogix, это для меня новая среда. И конкретно сейчас столкнулся с нюансом, который объяснить для себя не могу. В чём суть:
решаю элементарую формальную задачку. поверх текущего экрана (в данном случае это просто картинка на весь экран) нарисовать прямоугольник при касании экрана, потом этот прямоугольник убрать, когда убирают палец.
Поскольку у нас нет возможности при отрисовке чего-либо на экране запоминать старое содержимое экрана, и нет в картинках прозрачности, то нам необходимо при "убирании" динамического объекта чистить весь экран и перерисовывать фон. Вот с этим и возник вопрос.

Как следует из хелпов, блок очистки экрана работает по уровню управляющего сигнала: пока там 1, Трим непрерывно циклически чистит экран. В этом можно убедиться на практике, если в проекте тупо соединить выход "состояние" от экранной кнопки и вход enable у блока очистки. Держим палец на кнопке - экран залит, отпускаем - снова видим текущий экран.

Если же мы хотим производить отрисовку и очистку по фронту (однократно, в момент нажимании-отпускании), то тут начинается непонятное.

Если используем блок Fronts (см. картинку 1), то при отпускании кнопки мы не увидим текущий экран проекта. Мы будем наблюдать очищеный экран устройства.

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

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

в какие моменты в работающем проекте происходит перерисовка экрана? Можно ли как-то влиять на этот процесс?

В лоджиксе есть UI-выходы, но где их найти СМАрте и как ими пользоваться? Можно просто ссылку.

Какой из двух вариантов поведения проекта является глючным, а какой правильным с точки зрения идеологии сегнетикс? Что из этого мне лучше использовать в своих проектах в дальнейшем?

Если я перерисую вручную задник экрана (передёрну видимость), то перекроет ли он всё остальное, что было до этого поверх него (кнопки, текст и тд)?

Лоджикс 3.28, Trim5

[New]

Цитата

Сообщение от MadKid

Если используем блок Fronts (см. картинку 1), то при отпускании кнопки мы не увидим текущий экран проекта. Мы будем наблюдать очищеный экран устройства.

Всё правильно. При нажатии активируется PutRect, при отпускании ClrScr. В результате чистый экран.

Цитата

Сообщение от MadKid

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

А 1 на выходе AND у вас откуда берётся?

[MadKid]

Цитата

Сообщение от New

А 1 на выходе AND у вас откуда берётся?

оччень, знаете-ли уместный вопрос )) присмотрелся к своей "схеме", стыдно стало ... а ещё такую а простыню накатал действительно, единице там взяться неоткуда... и вообще, как выяснилось, всё предельно просто, а я начитался устаревших хелпов. Оказывается, блоки вывода прекрасно умеют сами себя стирать, и не надо ничего мудрить.

фух... ну надо же такую глупость ляпнуть, а )) Разобрались.

[Ilya J.]

А вы пока просто "играетесь" и это была конечная цель? Или она глобальнее?

[MadKid]

Цитата:

Сообщение от Ilya J.

А вы пока просто "играетесь" и это была конечная цель? Или она глобальнее?

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

Теперь я собираюсь развивать функционал, делать дополнительные меню, алгоритмы регулирования, ротации, оповещения и тд

И конечно же, красивую графику, дабы заказчик увидел "товар лицом".
С этой целью пытаюсь получше прочувствовать механизмы работы лоджикса (а точнее - проектов и графики в частности), чтобы понять свои возможности и ограничения. Надо выработать функциональную базу для построения развитого графического интерфейса. Чтобы в едином подходе все было построено, и в будущем можно было масштабировать и заимствовать.

Сейчас я выяснил: информация, что графические блоки не умеют себя стирать, всётки актуальна. Но по событиям на тачскрине (или где-то уровнем выше) происходит автоматическая перерисовка экрана... и при отпускании кнопки блок как бы "стирается". Вобщем, актуальными остались следующие вопросы:
1
как передавать в SMArt значения с UI-выходов, и что с ними можно там делать? В хелпах есть есть об этом упоминание, но ни конкретных инструкций, ни чего-то такого в интерфейсе я не нашёл
2
можно ли как-то из fbd-редактора активировать/деактивировать, переключать экраны? или как-то вызывать обновление экрана обходными путями?

[New]

Цитата

Сообщение от MadKid

2 можно ли как-то из fbd-редактора активировать/деактивировать, переключать экраны?

Можно. С помощью UI-переменных. Под изображением контроллера в SMArt-е есть конфигуратор переходов. Просто наведите на него курсор, всплывёт подсказка.

[MadKid]

Да, нашёл.

В подсказке написано, что переход происходит по положительному фронту ui-переменной, к нему привязанной. Это вполне логично, я бы тоже так сделал.
Однако, это на практике не так. На самом деле переход происходит при условии переменная=1. Посмотрите на скриншоты. Пока тик=1, экраны быстро-быстро переключаются друг на друга. Когда тик=0, ничего не происходит.

И на главные вопросы я пока не могу найти ответ.
1 что сделать, чтобы после очистки экрана прорисовалась форма SMArt?
2 в какие моменты (или при каких условиях) обновляется экран SMArt?

За всем этим стоит желание делать комбинированный графический интерфейс: что-то мы прописываем в SMArt, а что-то в fbd.
Так можно создавать "композитные" элементы вывода в макросах (например число в рамке, табличка) и параметризовать графику, легко менять внешний вид и легенду.
Ну и в общем-то нет проблем, кроме одной: можно показать, но нельзя погасить...

[MadKid]

Собсно, всё придумал, задача решена.
Может кто воспользуется.

Задача: поверх экрана SMArt выводить и гасить fbd-элементы графики.

Решение.
Помещаем на экран "прозрачку" - картинку .png, любого размера, в любом месте, с полностью прозрачным изображением.
Из fbd меняем видимость этой картинки только для того, чтобы перерисовывался экран.
Собсно, ClrScreen в этом случае не нужен, вся fbd-графика, у которой выключен enable, сама стряхивается.

Документация не рекомендует нам рисовать фигуры непрерывно-циклично.
Тогда мы будем держать enable=0, и надо будет его передёргивать всякий раз,
как только на экране что-то меняется, чтобы и наша графика тоже отобразилась.
Не очень удобно, но можно.

ЗЫ можно и не прозрачку, а любую картинку, лишь бы на самый задний план, чтоб её никогда видно не было.

[New]

Цитата

Сообщение от MadKid

Однако, это на практике не так. На самом деле переход происходит при условии переменная=1. Посмотрите на скриншоты. Пока тик=1, экраны быстро-быстро переключаются друг на друга. Когда тик=0, ничего не происходит.

Неа. Для перехода необходимо чтобы совпали два сигнала: UI-переменная и активность окна. У вас переход происходит по фронту активности окна.

Цитата

Сообщение от MadKid

что сделать, чтобы после очистки экрана прорисовалась форма SMArt?

Создать в конфигураторе условие перехода на нужный экран после очистки. Кстати, не факт что очистка вообще нужна.

[MadKid]

Цитата

Сообщение от New

Неа. Для перехода необходимо чтобы совпали два сигнала: UI-переменная и активность окна. У вас переход происходит по фронту активности окна.

То есть переход, строго говоря, происходит по фронту комбинированного сигнала (экран_активен AND ui_переменная).

Эт саааавсем не то же самое, и как минимум доку надо подкорректить.
Ведь это важно: все переменные, по которым возможен выход из экрана, должны быть = 0 при входе в него.
Несмотря на то, что управление вроде как фронтом осуществляется.

[New]

Цитата

Сообщение от MadKid

Ведь это важно: все переменные, по которым возможен выход из экрана, должны быть = 0 при входе в него

А так оно чаще всего и бывает.

[MadKid]

Цитата

Сообщение от New

А так оно чаще всего и бывает.

Согласен с Вами в этом, потому как нормальный человек в своём проекте закодирует экраны по принципу "one-hot".

Однако, не хочу показаться занудой, но всё же. "Чаще всего" != "всегда".

Если вдруг у кого-то будет другой подход при создании проекта,
и он будет полагаться на определение "по фронту ui-переменной",
то у него могут возникнуть непонятки.
И такой момент: это особенно вероятно, если человек в этой области ещё свежий )),
что само по себе не добавляет ситуации ловкости.

Ведь фактически выход из экрана управляется уровнем ui-переменной.
Активность = !переменная (только на 1 цикл нарушается).
И сразу требования к схеме управления экранами становятся другие.

А так-то понятно всё.

[Arsie]

Цитата

Сообщение от MadKid

Собсно, всё придумал, задача решена.
Может кто воспользуется.

Это является баяном для нашего форума) Вашу придумку мы буквально устали рассказывать в каждой второй теме)

Но оно понятно, гораздо приятнее придумывать, чем читать


Добавлено через 1 минуту

Цитата

Сообщение от MadKid

Ведь это важно: все переменные, по которым возможен выход из экрана, должны быть = 0 при входе в него.
Несмотря на то, что управление вроде как фронтом осуществляется.

Управление уровнями. В справке ошибка, если фронт написан.