И снова про SFC: раздумья о правильном подходе.

[dorofeevms]

Уважаемые коллеги.
Вопрос из области лучших практик, философско-технического плана.
На ST, FBD , С и тд давно программирую. SFC начал использовать сравнительно недавно.
Пока на SFC реализуется простой автомат, я бы даже сказал - с (почти) любым уровнем сложности, вопросов много не возникает.
Но тут попала мне задача, вроде бы простая на первый взгляд, однако требующая достаточно большого "интерактива" с оператором, HMI "в полный рост".

Не суть важно, на чем ее реализовать необходимо, я , исключительно для целей отладки "в натуре" взял имеющийся под рукой PLC73, суть в следующем:
- SFC, прекрасно подходит для решения задачи, в том числе с подзадачами и "вспомогательными" процессами,
если алгоритм предусматривает достаточно много шагов, и каждый шаг может генерировать несколько сообщений, а некоторые ветки задачи требуют ввода,
КАК логичнее/красивее реализовать ЦЕНТРАЛИЗОВАННЫЙ вывод на экран ?

Поясняю: когда использую state machine, например в С, или даже ST, то перед вызовом SM я один раз считываю входы и проверяю ошибки, в каждом состоянии я решаю некие логические задачи, в соответствии с алгоритмом устанавливаю выходы (как правило - переменные, выходы - централизованно в конце) , И ПОСЛЕ ОТРАБОТКИ СОСТОЯНИЯ один раз обновляю дисплей. То есть в некоемом (любом) состоянии при появлении сообщения для
оператора я складываю его в буфер и вывожу все (ошибки, сообщения и тд) в одном месте в конце. Очень удобно: форматируется все в одном месте, в зависимости от типа - ошибка, инфо и тд - выводится префикс и тд...

И вот тут-то я и задумался: в "конце цепочки" SFC нельзя реализовать - алгоритм может крутиться, например, на шаге автонастройки, или цепочки задания рецепта (а там много ввода и проверок), и, с точки зрения SFC все это -
ОДИН шаг.
Вызывать В КАЖДОМ шаге "последним оператором" (действием) нечто вроде UpdateDisplay (MSG_TYPE, MSG_TEXT......) - можно, но, почему-то в душе я пока не привык к этой идее.
Подумал, добавить выходное действие к шагу, но, учитывая, что может быть SFC внутри SFC (сам пока не делал, но на форуме такая тема есть и мне она понятна!!!) этот вариант ТОЖЕ НЕ очень подходит, ибо пока алгоритм работает внутри одного шага - он также может генерировать сообщения и обрабатывать ввод, а выходное действие выполнится только после перехода к следующему шагу.....

С благодарностью послушаю мнения экспертов и бывалых!

Михаил

[1exan]

Уважаемые коллеги.
Вопрос из области лучших практик, философско-технического плана.
На ST, FBD , С и тд давно программирую. SFC начал использовать сравнительно недавно.
Пока на SFC реализуется простой автомат, я бы даже сказал - с (почти) любым уровнем сложности, вопросов много не возникает.
Но тут попала мне задача, вроде бы простая на первый взгляд, однако требующая достаточно большого "интерактива" с оператором, HMI "в полный рост".

Не суть важно, на чем ее реализовать необходимо, я , исключительно для целей отладки "в натуре" взял имеющийся под рукой PLC73, суть в следующем:
- SFC, прекрасно подходит для решения задачи, в том числе с подзадачами и "вспомогательными" процессами,
если алгоритм предусматривает достаточно много шагов, и каждый шаг может генерировать несколько сообщений, а некоторые ветки задачи требуют ввода,
КАК логичнее/красивее реализовать ЦЕНТРАЛИЗОВАННЫЙ вывод на экран ?

Поясняю: когда использую state machine, например в С, или даже ST, то перед вызовом SM я один раз считываю входы и проверяю ошибки, в каждом состоянии я решаю некие логические задачи, в соответствии с алгоритмом устанавливаю выходы (как правило - переменные, выходы - централизованно в конце) , И ПОСЛЕ ОТРАБОТКИ СОСТОЯНИЯ один раз обновляю дисплей. То есть в некоемом (любом) состоянии при появлении сообщения для
оператора я складываю его в буфер и вывожу все (ошибки, сообщения и тд) в одном месте в конце. Очень удобно: форматируется все в одном месте, в зависимости от типа - ошибка, инфо и тд - выводится префикс и тд...

И вот тут-то я и задумался: в "конце цепочки" SFC нельзя реализовать - алгоритм может крутиться, например, на шаге автонастройки, или цепочки задания рецепта (а там много ввода и проверок), и, с точки зрения SFC все это -
ОДИН шаг.
Вызывать В КАЖДОМ шаге "последним оператором" (действием) нечто вроде UpdateDisplay (MSG_TYPE, MSG_TEXT......) - можно, но, почему-то в душе я пока не привык к этой идее.
Подумал, добавить выходное действие к шагу, но, учитывая, что может быть SFC внутри SFC (сам пока не делал, но на форуме такая тема есть и мне она понятна!!!) этот вариант ТОЖЕ НЕ очень подходит, ибо пока алгоритм работает внутри одного шага - он также может генерировать сообщения и обрабатывать ввод, а выходное действие выполнится только после перехода к следующему шагу.....

С благодарностью послушаю мнения экспертов и бывалых!

Михаил

Оформите автомат в виде отдельного ФБ и делайте в программе на любом языке предварительные действия, потом вызывайте ФБ на SFC, а после него - операторы с выводом, обработкой экраном и т.д.

[kondor3000]

На ST всё реализуется по шагам, через CASE, сколько надо шагов и подшагов, с любыми действиями, без заморочек c SFC.

[1exan]

На ST всё реализуется по шагам, через CASE, сколько надо шагов и подшагов, с любыми действиями, без заморочек c SFC.

Отлаживать алгоритм на SFC намного проще, чем тот-же СASE на ST

[dorofeevms]

Отлаживать алгоритм на SFC намного проще, чем тот-же СASE на ST
Вот именно. Поэтому я и стараюсь активно использовать SFC.
Я ж с чего вопрос начал: с того, что с CASE знаком (и бесконечные труды определенных людей под умными названиями, но малосодержательным контентом "Применение SWITCH технологий...." перечитал пачками).Как сделать все это с помощью CASE я хорошо представляю.
Но SFC отнюдь не зря придумали! Это ОЧЕНЬ выразительный инструмент абстракции и реализации.

Не совсем поднял идею "Оформите автомат в виде отдельного ФБ и делайте в программе на любом языке предварительные действия, потом вызывайте ФБ на SFC, а после него - операторы с выводом, обработкой экраном и т.д."
У меня именно "основной алгоритм-автомат" на SFC как раз и является самым "диалоговым" компонентом. Если я его оформлю в FB то в нем и придется вернуться к вопросу взаимодействия с дисплеем/кнопками.
Может неправильно понял Вашу мысль ? Или не донес свою

[1exan]

Вот именно. Поэтому я и стараюсь активно использовать SFC.
Я ж с чего вопрос начал: с того, что с CASE знаком (и бесконечные труды определенных людей под умными названиями, но малосодержательным контентом "Применение SWITCH технологий...." перечитал пачками).Как сделать все это с помощью CASE я хорошо представляю.
Но SFC отнюдь не зря придумали! Это ОЧЕНЬ выразительный инструмент абстракции и реализации.

Не совсем поднял идею "Оформите автомат в виде отдельного ФБ и делайте в программе на любом языке предварительные действия, потом вызывайте ФБ на SFC, а после него - операторы с выводом, обработкой экраном и т.д."
У меня именно "основной алгоритм-автомат" на SFC как раз и является самым "диалоговым" компонентом. Если я его оформлю в FB то в нем и придется вернуться к вопросу взаимодействия с дисплеем/кнопками.
Может неправильно понял Вашу мысль ? Или не донес свою

Наверное я не совсем понял задачу

[dorofeevms]

Ответственность на мне, я плохо объяснил.
Если интересно продолжить - я сейчас "очищу" все шаги в копии проекта, уберу несколько, чтобы на экрах входило, и пришлю, с комментариями.

[1exan]

Ответственность на мне, я плохо объяснил.
Если интересно продолжить - я сейчас "очищу" все шаги в копии проекта, уберу несколько, чтобы на экрах входило, и пришлю, с комментариями.

Да, давайте посмотрим

[dorofeevms]

Да, давайте посмотрим
Дико извиняюсь. Перед отпуском подвалило работы.
Сильно "кастрировал" алгоритм, убрал и часть ветвей и часть шагов. Но суть осталась.
Сейчас напишу , позже дополню вопросами, собираюсь в дорогу...79357

[dorofeevms]

Добавляю, ибо уже в дороге.
Начиная с шага CheckHadware, все шаги - waitrepair , step7-step12, подразумевают активный диалоговый режим. Некоторые шаги из череды step7-step12 имеют вложенные sfc алгоритмы.
Итак, выводить инф и получать данные с клавиатуры необходимо на многих разных шагах.
Если бы это был case(switch) вариант, то я после обработки состояния вызвал бы некий Updatedisplay (msg), где и оформил бы весь вывод.
Ну и теперь уже сам прихожу к выводу, что тут так не прокатит… придется в Каждом шаге, где необходим вывод, вызывать FB ,который будет отвечать за обновление интерфейса.
Есть, правда , еще один вариант, я им пользуюсь в С.
Можно запустить ПАРАЛЛЕЛЬНЫЙ всем веткам ПРОЦЕСС, от checkhardware до самого конца, котрый будет делать Единственную функцию -обновлять вывод на экран. Но будет делать он это ПРИ УСТАНОВЛЕННОМ ФЛАГЕ, скажем, needUpdate=true (придется делать глобальную переменную, либо, что лучше, вызывать «глобальную» функцию типа update(msg, true), которая и флаг установит и месседж запишет).
А вот флаг устанавливать в шагах основного алгоритма.
После обновления интерфейса параллельный процесс , разумеется, сразу сбрасывает флаг.


Вот и хотел обсудить подходы)

[1exan]

Если под выводом на экран подразумевается именно формирование экрана, имеющего для каждого из шагов SFC индивидуальный вид - я лично не вижу ничего плохого в том, чтобы делать это непосредственно внутри этого шага (или там вызывать ФБ экрана).
А как параллельный процесс будет получать информацию о том, какой именно экран (или что именно) нужно выводить сейчас?

[dorofeevms]

Чем больше думаю, тем больше соглашаюсь. Видимо , это самый простой вариант. С параллельным процессом можно так: желающий обновить что-либо шаг пишет в некую глоб структуру контент и выставляет флаг НужноОбновить=трю, а параллельный процесс отслеживает этот флаг, обновляет (причем использует активно справочники-константы), после обновления- сбрасывает флаг. Есть «+»: весь контент / константы и форматирование в одном месте. Но вообще-то, это больше ненужное усложнение. Так что если не будет иных идей - смиряюсь с этой точкой зрения. Прошу прощения, пишу с тел, дико неудобно…

[Валенок]

..выводить инф и получать данные с клавиатуры необходимо на многих разных шагах...
...Если бы это был case(switch) вариант, то я после обработки состояния вызвал бы некий Updatedisplay (msg), где и оформил бы весь вывод.
...Можно запустить ПАРАЛЛЕЛЬНЫЙ всем веткам ПРОЦЕСС, от checkhardware до самого конца, котрый ... -обновлять вывод на экран. Но будет делать он это ПРИ УСТАНОВЛЕННОМ ФЛАГЕ, скажем, needUpdate=true (придется делать глобальную переменную, либо, что лучше, вызывать «глобальную» функцию типа update(msg, true), которая и флаг установит и месседж запишет).
.. флаг устанавливать в шагах основного алгоритма. ...После обновления интерфейса параллельный процесс , разумеется, сразу сбрасывает флаг.

Updatedisplay, checkhardwar, needUpdate, глобальные переменные, вызвать, сбросы, набросы ... 8(



... SFC начал использовать сравнительно недавно.

...Ну и теперь уже сам прихожу к выводу, что тут так не прокатит…
Чо?

..Вот и хотел обсудить подходы)
Начни со справки в самой КДС


---
Но сам юзаю ST))

[dorofeevms]

Updatedisplay, checkhardwar, needUpdate, глобальные переменные, вызвать, сбросы, набросы ... 8(




Чо?

Начни со справки в самой КДС


---
Но сам юзаю ST))
«Ничо!»
Для начала начните по-русски писать.
Я не только справку КДС читал, но много чего еще другого.
Вместо того, чтобы какую-то чушь написать не содержательную, почитали бы о чем речь шла с самого начала.
(Слово «недавно», кстати, тоже может иметь разные оттенки смысла. Раз уж вы соизволили процитировать…)

[Валенок]

«Ничо!»
Для начала начните по-русски писать..
Да ваще пофиг.



..Вопрос из области лучших практик, философско-технического плана..
Долго обстругивал мусор. Нашел единственный двойной вопрос

..КАК логичнее/красивее реализовать ЦЕНТРАЛИЗОВАННЫЙ вывод на экран ?..
Логичнее - чтоб работало.
Красивее - чтоб побольше информации. И чтоб лес на заднем плане.

..С благодарностью послушаю мнения ..
А где благодарность то?



..Я не только справку КДС читал, но много чего еще другого..
Дык не первый кто сюда забегает и несёт какую-то философию "из области лучших практик" и без конкретики, выкладывает какие-то картиночки



..Вместо того, чтобы какую-то чушь написать не содержательную, почитали бы о чем речь шла с самого начала.
Вот эту "содержательную"


... На ST, FBD , С и тд давно программирую. SFC начал использовать сравнительно недавно
.. я бы даже сказал - с (почти) любым уровнем сложности, вопросов много не возникает.
Но тут попала мне задача, вроде бы простая на первый взгляд, однако требующая...
Не суть важно, ...я ... взял имеющийся под рукой PLC73, суть в следующем..
... И вот тут-то я и задумался ... но, почему-то в душе я пока не привык к этой идее.
Подумал, ... но, учитывая, что может быть ...
НЕ очень подходит, ибо пока алгоритм работает внутри одного шага - он также может...
?
Смахивает на начало какого-то романа.
В следующей главе появится Мефистофель и предложит мечущейся и терзаемой душе волшебный код. Но придется продать душу и подписатся кровью.



(Слово «недавно», кстати, тоже может иметь разные оттенки смысла. Раз уж вы соизволили процитировать…)
Это что-то из параллельного сознания?