I want to use SFCs as actions in SFC-steps. This means I would have a top-level SFC and several sub-SFCs.
When the top-level SFC leaves a step with a sub-SFC, the sub-SFC stays in its last active step it is just not active. If the the top-level step is active again, the sub-SFC continues with the last step.
Now I want this sub-SFC to be resetted, i.e. to start in its init step again.
I have not seen any possibilty to achieve this goal. SFCReset and SFCInit variables seem to affect the top-level SFC only.
Any ideas? Thank you for your time in advance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think you need to rerun the sub-sfc from top-sfc so it have a chance to finish.
You have the possibility to set Entry/Exit action this will execute one scanrotation before/after.
/Torbjörn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your answer.
Sure, letting the sub-SFCs finish is an option.
However, the execution in the sub-SFCs might be aborted by, e.g., an emergency stop. In this case I would like to have the sub-SFCs resetted and the sub-SFCs should explicitly not finish.
If there is any command I could put in an Exit action, e.g. a local SFCReset, that would be great.
Or just an option to chose if sub-SFCs stay in last acitve step or are memoryless.
Best,
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And then I make sub-SFCs for almost all steps to flesh them out in detail.
I don´t want to make the top-level-SFC larger and I would like to not use ST on the sub level.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
would be a Macro rather than a sub SFC. That way the SFC runs like a single SFC unit, but is much better organised allowing you to _ in / out of Macro steps rather than using Sub SFC's that are only active, when the top level step is active.
In this way a macro is viewed like a sub level, but acts like a top level.
Apologies if I have misunderstood the problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also thought about macros, but I discarded them.
If I have parallel macros, I am in a step inside them somewhere. Thus, it is not garanteed that I can leave the whole parallel branch once the following transition becomes true ("Critical error detected" in my example).
If I have sub-SFCs, each of them is just a step in parallel. If the following transition is true, the sub-SFCs are all stopped immediately and the following step becomes active.
I found a possible solution for the sub-SFCs:
You can set SFCReset := true in the entry-action of the top-level SFC step and SFCReset := false in the normal action of the init step of the sub-SFC.
This works with on sub-SFC, but I am not sure about the side effects that can occur in a setting with several sub-SFCs. Also this is very cumbersome.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am having the same issue. Are your top-level SFC steps (the steps that have sub-SFCs) using IEC conforming actions or IEC-extending actions (step entry, step exit, step active)?
My top-level SFC steps are using the IEC conforming actions with the 'N' qualifier. Those actions are SFCs or sub-SFCs as you call them. In my sub SFCs I am using the IEC extending actions in all the steps.
The way my program works is a button is pressed that latches, when latched, the top-level SFC is called. I'm using a trigger (R_TRIG) with the latching variable. The pulse from this trigger I equate to SFCReset when I call the program:
PROGRAM_TO_CALL(SFCReset := Trigger.Q);
I have the SFCReset variable declared in my top-level SFC (i.e. not global).
The reason I explain my method to you is that I developed this code in Codesys 2.3, and it works. When I call the program with my latching button, the top-level SFC resets, as well as all the sub-SFCs. But in Codesys 3.5, it does not work. The top level SFC resets properly, but the sub-SFCs do not.
Wonder if you have any ideas after all this time? If you need any more info or if I need to explain what I did better then let me know.
Cheers,
Andrew.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Till now we still use the
"SFCReset := true in the entry-action of the top-level SFC step and SFCReset := false in the normal action of the init step of the sub-SFC"
It works quite good and works also for more SFC layers. If you make it a standard for yourself, using always the same action, then it gets also easier to use.
We are not using IEC-Actions at all, because we had some side effects with "normal" actions as IEC-Actions with qualifier R overrode the normal actions, even when it was not active.
Best,
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I may not properly understand the SFC flags, but why doesn't the "SFCReset := true" in the entry action of the top-level SFC step reset that top-level SFC? I thought if the SFCInit or SFCReset variables were set to TRUE then the SFC it corresponds to would go back to the Init step? Is there a rule that states that if the flag is made TRUE in a lower step then it just resets the actions in that corresponding step?
For my program, I ended up using macros, like what aellis_scatts brought up. It is suitable for our application, because if the sequence is interrupted anywhere then we always start the top-level SFC at the top again. However I can't rule out needing a solution like yours in the future so would be good to work out.
Cheers,
Andrew.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The trick is that you set SFCReset := true in the entry action of the step. So the next thing the PLC will do is to activate the step, which is then to reset this SFC and execute the first step there, which in turn sets SFCReset := false again.
As there are no other SFCs executed, only one will be reset.
We also thought about macros but we wanted to have more reuseability and the option to leave a top-level step directly, neglecting the state of the sub-SFC.
Since more people are interested in this topic, it might be another good time to plea to the Codesys developers
Zitat:
Dear Codesys developers,
Please add a enabled option into the SFCs. If the option is enabled in the parameters of the SFC then the last step of this SFC -that was active when the SFC was left- will be resumed when it is entered again. If the option is not enabled, the SFC should start with the initial step everytime it is entered.
This would be similar to the History pseudostate in the UML state machine, e.g.: http://www.uml-diagrams.org/state-machine-diagrams.html#shallow-history-pseudostate.
Best,
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
there was really a problem resetting SFC Actions.
This problem was addressed in
CDS-43049 SFC: SFCReset-Flag does not affect SFC in Actions
and in
CDS-45015 SFC: SFCReset-Flag only affects IEC-actions
The problem was fixed with V3.5 SP8, you have to upgrade the compiler version to 3.5.8.0 or higher
Regards,
Roman
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi.
i had the same problem, that setting SfcInit := true would not reset the Sub-SFC.
in my case, the reason was, that in my main PLC i did the following:
IF NOT emergencystop THEN
sfc ();
sfc.SfcInit:=false;
ELSE
sfc.SfcInit:=true;
END_IF
Now the problem was, that when the emergencystop was set to TRUE, the SfcInit also was set to TRUE, but the SFC was not called again and therefore would not notice that the SfcInit became true.
After setting the emergencystop back to false the SFC continued at the place it was stopped.
The solution was to permanently continue to call the SFC like this:
IF NOT emergencystop THEN
sfc.SfcInit:=false;
ELSE
sfc.SfcInit:=true;
END_IF
sfc ();
Now it worked.
Even though the SFC is permanently called, as soon as SfcInit is true, the SFC is resetted to its INIT Step and does not continue to work.
Maybe this is helping someone.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear all,
I want to use SFCs as actions in SFC-steps. This means I would have a top-level SFC and several sub-SFCs.
When the top-level SFC leaves a step with a sub-SFC, the sub-SFC stays in its last active step it is just not active. If the the top-level step is active again, the sub-SFC continues with the last step.
Now I want this sub-SFC to be resetted, i.e. to start in its init step again.
I have not seen any possibilty to achieve this goal. SFCReset and SFCInit variables seem to affect the top-level SFC only.
Any ideas? Thank you for your time in advance.
Hi!
I think you need to rerun the sub-sfc from top-sfc so it have a chance to finish.
You have the possibility to set Entry/Exit action this will execute one scanrotation before/after.
/Torbjörn
Hi,
Thank you for your answer.
Sure, letting the sub-SFCs finish is an option.
However, the execution in the sub-SFCs might be aborted by, e.g., an emergency stop. In this case I would like to have the sub-SFCs resetted and the sub-SFCs should explicitly not finish.
If there is any command I could put in an Exit action, e.g. a local SFCReset, that would be great.
Or just an option to chose if sub-SFCs stay in last acitve step or are memoryless.
Best,
Martin
What if you use parallell branch (sub) in top-level SFC, instead of sub-SFC actions.
Then the SFCReset will work.
We used parallell branches and one main action to not get non executeing code.
I am using parallel branches and sub-SFCs
I wanted to use sub-SFCs to organize the code.
My programm is more or less like:
Init Step
|
Check everything ok
|
===========================================
| | |
Normal Operation Safety Checks Error Checks
| | |
===========================================
|
Critical Error detected
|
_> Init Step
And then I make sub-SFCs for almost all steps to flesh them out in detail.
I don´t want to make the top-level-SFC larger and I would like to not use ST on the sub level.
If this is all about keeping the top level SFC tidy, could you not use Macro's to organise the SFC code.
So the area of code:
>Zitat:
| | |
Normal Operation Safety Checks Error Checks
| | |
===========================================
would be a Macro rather than a sub SFC. That way the SFC runs like a single SFC unit, but is much better organised allowing you to _ in / out of Macro steps rather than using Sub SFC's that are only active, when the top level step is active.
In this way a macro is viewed like a sub level, but acts like a top level.
Apologies if I have misunderstood the problem.
Thank you for your response
I also thought about macros, but I discarded them.
If I have parallel macros, I am in a step inside them somewhere. Thus, it is not garanteed that I can leave the whole parallel branch once the following transition becomes true ("Critical error detected" in my example).
If I have sub-SFCs, each of them is just a step in parallel. If the following transition is true, the sub-SFCs are all stopped immediately and the following step becomes active.
I found a possible solution for the sub-SFCs:
You can set SFCReset := true in the entry-action of the top-level SFC step and SFCReset := false in the normal action of the init step of the sub-SFC.
This works with on sub-SFC, but I am not sure about the side effects that can occur in a setting with several sub-SFCs. Also this is very cumbersome.
Hi MHU,
I am having the same issue. Are your top-level SFC steps (the steps that have sub-SFCs) using IEC conforming actions or IEC-extending actions (step entry, step exit, step active)?
My top-level SFC steps are using the IEC conforming actions with the 'N' qualifier. Those actions are SFCs or sub-SFCs as you call them. In my sub SFCs I am using the IEC extending actions in all the steps.
The way my program works is a button is pressed that latches, when latched, the top-level SFC is called. I'm using a trigger (R_TRIG) with the latching variable. The pulse from this trigger I equate to SFCReset when I call the program:
PROGRAM_TO_CALL(SFCReset := Trigger.Q);
I have the SFCReset variable declared in my top-level SFC (i.e. not global).
The reason I explain my method to you is that I developed this code in Codesys 2.3, and it works. When I call the program with my latching button, the top-level SFC resets, as well as all the sub-SFCs. But in Codesys 3.5, it does not work. The top level SFC resets properly, but the sub-SFCs do not.
Wonder if you have any ideas after all this time? If you need any more info or if I need to explain what I did better then let me know.
Cheers,
Andrew.
Hi Andrew,
Till now we still use the
"SFCReset := true in the entry-action of the top-level SFC step and SFCReset := false in the normal action of the init step of the sub-SFC"
It works quite good and works also for more SFC layers. If you make it a standard for yourself, using always the same action, then it gets also easier to use.
We are not using IEC-Actions at all, because we had some side effects with "normal" actions as IEC-Actions with qualifier R overrode the normal actions, even when it was not active.
Best,
Martin
Martin,
I may not properly understand the SFC flags, but why doesn't the "SFCReset := true" in the entry action of the top-level SFC step reset that top-level SFC? I thought if the SFCInit or SFCReset variables were set to TRUE then the SFC it corresponds to would go back to the Init step? Is there a rule that states that if the flag is made TRUE in a lower step then it just resets the actions in that corresponding step?
For my program, I ended up using macros, like what aellis_scatts brought up. It is suitable for our application, because if the sequence is interrupted anywhere then we always start the top-level SFC at the top again. However I can't rule out needing a solution like yours in the future so would be good to work out.
Cheers,
Andrew.
Hi Andrew,
The trick is that you set SFCReset := true in the entry action of the step. So the next thing the PLC will do is to activate the step, which is then to reset this SFC and execute the first step there, which in turn sets SFCReset := false again.
As there are no other SFCs executed, only one will be reset.
We also thought about macros but we wanted to have more reuseability and the option to leave a top-level step directly, neglecting the state of the sub-SFC.
Since more people are interested in this topic, it might be another good time to plea to the Codesys developers
Best,
Martin
Hi Martin,
I will try that. Obviously if it works for you it should work for me.
Yes the developers should consider that, a History option would be perfect for this. I imagine it would be useful for many applications.
Cheers,
Andrew
Hi Folks,
there was really a problem resetting SFC Actions.
This problem was addressed in
CDS-43049 SFC: SFCReset-Flag does not affect SFC in Actions
and in
CDS-45015 SFC: SFCReset-Flag only affects IEC-actions
The problem was fixed with V3.5 SP8, you have to upgrade the compiler version to 3.5.8.0 or higher
Regards,
Roman
Hi.
i had the same problem, that setting SfcInit := true would not reset the Sub-SFC.
in my case, the reason was, that in my main PLC i did the following:
IF NOT emergencystop THEN
sfc ();
sfc.SfcInit:=false;
ELSE
sfc.SfcInit:=true;
END_IF
Now the problem was, that when the emergencystop was set to TRUE, the SfcInit also was set to TRUE, but the SFC was not called again and therefore would not notice that the SfcInit became true.
After setting the emergencystop back to false the SFC continued at the place it was stopped.
The solution was to permanently continue to call the SFC like this:
IF NOT emergencystop THEN
sfc.SfcInit:=false;
ELSE
sfc.SfcInit:=true;
END_IF
sfc ();
Now it worked.
Even though the SFC is permanently called, as soon as SfcInit is true, the SFC is resetted to its INIT Step and does not continue to work.
Maybe this is helping someone.