И снова про 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]

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

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

[dorofeevms]

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


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