SFC внутри SFC

[drvlas]

Здравствуйте!

У меня часть программы пишется на SFC. Мне было бы удобно, чтобы один из шагов содержал в себе действие, написанное тоже на SFC. При этом данное действие (назовем это условно "пуск двигателя") имеет такую структуру, что выполняется за много циклов программы. То есть там свои задержки, свои события, которых ждем и так далее - полноценная многошаговая SFC програмка.

Возник вопрос:

Если известно точно, что действие "пуск двигателя" не выполняется за 1 цикл, то где его лучше разместить - как входное, выходное или связанное N-действие? По смыслу, когда "пуск двигателя" отработает, мне нужно ждать некоего сигнала готовности и переходить на следующий шаг "родительского" процесса.

Я прилепил картинку, не знаю, поможет ли. Здесь я для примера из Step2 огранизовал входное действие (тот самый "пуск двигателя), а в нем какая-то накрученная муть. Требуется, чтобы при активизации Step2 начинала работу эта муть - и работала себе по циклам процессора, пока не выполнит весь "пуск двигателя". А "папа" этого процесса, шаг Step2, как предполагается, следит за условием окончания (обозначил на рисунке "R") и при выполнении - передает активность шагу Step3.
Процесс же "пуск двигателя" стоит в ожидании. И в следующий раз при активности шага Step2 будет выполнено какое-то условие активизации "пуска двигателя" и действие начнет свою работу.

Я пробовал построить модель, но не хватает ума и усердия. Даже порождение альтернативной ветви вызывает у меня судороги С трудом нашел, как это сделать...
Думаю, а вдруг это все не правильно и так нельзя делать?

[drvlas]

Если известно точно, что действие "пуск двигателя" не выполняется за 1 цикл, то где его лучше разместить - как входное, выходное или связанное N-действие?

Извините за поспешный вопрос! Все же сделать модель оказалось не так сложно (прилагается).
Ответ на мой вопрос таков: Входное (думаю, что и выходное) действия выполняются 1 раз. Поэтому, если поместить в них действие, представляющее многошаговую (точнее - многоцикловую) программу, то она не сможет выполниться при однократной передаче маркера вызывающему шагу.
Нужно размещать многоцикловое SFC-действие в связанное действие (как в моем примере wBS), повторяющееся многократно, пока родительский шаг активен.

Уважаемые модераторы, тему можно чикануть полностью... У меня не получается удалить все.

[swerder]

вопрос исчерпан? так бы подсказал

[drvlas]

вопрос исчерпан? так бы подсказал

Йо, так подскажи! У меня тут сколько открытий в ходе моделирования...

Нет, правда, если поделитесь любой инфо по SFC, буду очень рад.

[swerder]

как делаю я:
главная управляющая sfc диаграмма максимально упрощена, вызывает "подпрограммы действий" написанные так же на sfc. вызов происходит при переходе по каким-то условиям в шаг вызова подпрограммы, в шаге (не входное, не выходное, связанное действие) переменная "программа_действия" принимает значение true. эта переменная является разрешением на выполнение "подпрограммы".
как только "подпрограмма" выполняет весь свой алгоритм, взводит свою переменную "все_сделано".
теперь возвращаемся к главной sfc. условием выхода из шага активации подпрограммы как раз является та самая переменная "все_сделано". деактивация подпрограммы у меня сделана в следующем шаге после активации (в принципе можно и в выходном действии шага активации) - "программа_действия" принимает значение false.
подпрограмма получив false обнуляет свою переменную "все_сделано" и переходит на шаг init, где ожидает следующего вызова.
упростив вышесказанное получаем:
имеем 2 sfc программы. одна вызывает другую. в шаге вызывающей устанавливается true на переменную разрешения работы вызываемой программы, выход из шага и, соответственно, обнуление переменной происходит по условию все_сделано = true.
вызываемая прога работает пока "можно_работать" = true. доработала до конца - все_сделано := true.

[Александр Приходько]

Если есть сложности с пониманием - а как оно работает, как взаимодействуют ФБ и программа, я очень советую на первых порах пользоваться средствами отладки.
Это не сложно! При этом вы ивидите как работает программа и как она взаимодействует с ФБ.

алгоритм отладки прост:
1) Пуск программа - на ПЛК или в эмуляции
2) Меню онлайн - диалог точек останова. Через данное меню вы в вашем проекте ставите точку, в которой программа контроллера приостановится и будет ждать пока вы ее не запустите или не будете выполнять ее по шагам.
3) После выбора точки останова ваш проект приостановится в том месте, где вы поставили точку останова.
4) Теперь по шагам нужно выполнять ваш проект. Можно проверить как работает весь алгоритм в целом: Онлайн - шаг поверхностный. Или можно проверить как работают и ФБ - онлайн шаг детальный.

Во втором случае вы будете перемещаться по программе от одного шага к другому, при этом отрабатывать алгоритм всех ваших ФБ.

В первом случае вы не заходите в сами ФБ, но они все равно выпоняются, вы лишь только видите результат его работы (например состояние выходов).

Не поленитесь. В свое время мне это очень помогло.

[drvlas]

Спасибо откликнувшимся!
В обратном порядке:

я очень советую на первых порах пользоваться средствами отладки.
...
Не поленитесь. В свое время мне это очень помогло.

Да, я так и сделал. Отладкой пользуюсь (я уже кое-как на ST шкарябаю проги), вопрос был только в создании грамотного примерчика на SFC. Ну, глаза боятся, руки делают...
А вообще, когда перестал бояться и сделал именно SFC в SFC - какая красота! И настолько все прозрачно, что действительно слаборазвитые средства автодокументирования в Кодесис уже не кажутся таким уж недостатком.
SFC forever!

И сделал я примерно то, что описал уважаемый swerder:

как делаю я:

Хочу поподробнее сравнить со своей реализацией (пока только в примере, в основной программе все еще только пишется), поэтому беру небольшой таймаут.

[drvlas]

Вот что я понял о вызове SFC программы "дочки" из SFC "папы".

1) Переход на дочерний процесс - в связанном действии "папы". Разовые (входное и выходное) действия не позволяют "дочке" выполнить многотактовую работу.
Как только "дочка" активизирована, маркер начинат там бегать своей жизнью.
ВАЖНО: И основной процесс тоже продолжает работать. Из этого вывод:

2) Нужно позаботиться, чтобы вызывающее действие продолжало выполняться до тех пор, пока "дочка" не отработает полностью.
Простейшая реализация (но не единственная при МЭК-шагах): сделать вызывающее действие типа N, но при этом тормознуть "папу" на данном шаге.
Я ввел общую переменную, которую можна назвать "Команда-отчет", пусть это будет
FE_Cmd
По-моему, уважаемый swerder работает с разными переменными, но это не принципиально.

3) Запуск дочернего процесса. Во входном действии "папы" даем команду:

FE_Cmd := CMD_GO;

Это не все. "Дочка" еще не активирована. Но весь дочерний модуль реализован в связанном действии данного шага "папы". Поэтому активизация шага "папы" тут же активизирует связанное действие - и "дочка" увидит, в том числе, и изменение переменной FE_Cmd.
По ней "дочка" соскакивает с шага ожидания, условие выхода:

FE_Cmd = CMD_GO

... и начинает работу.
Что у "папы" в это время происходит? А программа крутится. Значит, вызывающий шаг родительского процесса может стать неактивным! Вот почему, как и уважаемый swerder, я ставлю условием выхода из данного шага:

FE_Cmd = CMD_DONE

4) Когда дочерний процесс все отработал, то управление зацикливается на шаг ожидания, а в выходном действии последнего активного шага ставим:

FE_Cmd := CMD_DONE;

5) Еще одна интересная штучка. Коллега swerder пишет:

вызываемая прога работает пока "можно_работать" = true. доработала до конца - все_сделано := true.

У меня реализовано, что дочерний процесс может состоять из нескольких частей работы, то есть умеет приостанавливаться и запускаться из РАЗНЫХ шагов родительского процесса. То есть, "дочка" доработала до окончания первой части, передает сигнал CMD_DONE и тормозит. Родительский шаг по этому сообщению деактивируется, процесс пошел, а "дочка" заморозилась. На некотором шаге родительского процесса вновь активизируется "дочка". И вот здесь я использую то, что "дочка" активизируется не с шага ИНИТ, а именно с того шага, на котором ее остановили. Поэтому она продолжает свой долгий путь.
Так реализуется, по сути, параллельное существование основного и дочернего процессов, где окончание активности дочернего может быть не финалом, а лишь паузой.

Много слов... Картинок готовых нет. Если надо будет - будем рисовать

[swerder]

2) в простом sfc - вызов дочки связанным действием, сразу после шага условие окончания работы дочки. в МЭК-SFC переменная с классификатором S, по условию окончания работы дочки - переменная с классификатором R.
4) выходное действие отрабатывает только при наступлении активности следующего шага диаграммы, а когда она настанет уже зависит от ситуации.
5) а смысл? разрежьте эту дочку на несколько частей и вызывайте каждую часть тогда когда надо.
гораздо проще будет использовать дочки-SFC как законченный кусок алгоритма, а не склеенные части с замораживанием.

[drvlas]

5) а смысл? разрежьте эту дочку на несколько частей и вызывайте каждую часть тогда когда надо.
гораздо проще будет использовать дочки-SFC как законченный кусок алгоритма, а не склеенные части с замораживанием.

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

Но Вы подали интересную идею вот здесь:

2) в МЭК-SFC переменная с классификатором S, по условию окончания работы дочки - переменная с классификатором R.

Ага, говорю я! А почему Stored? А потому что снимать активность с дочернего процесса вовсе не обязательно. Ведь мы обмениваемся командой-отчетом, по которой дочерний процесс все равно будет стоять на одном шаге, пока "папа" не скажет Go-go-go!
Правильно. Дочерний процесс можно просто 1 раз запустить - и не снимать с него активности.
Но тогда, дорогой коллега, мы приходим вот к какой чудной организации:

Каждый процесс, требующий несколько шагов для работы, оформляется в SFC-программу. Вне зависимости от того, какой из них "папа", какой "дочки". А синхронизация их работы выполняется по переменным типа "команда-отчет". И все.

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

Как замечательно! Жаль, что это и так ясно тем, кто работает с SFC
Но новичку это просто откровение...

Еще раз спасибо swerder-у!