since the naming of the initial state START within any ECC can cause confusion with the START management command it would be better to change this name to IDLE. (thanks to Lacramioara for this suggestion and to Awite for the question)
Idle is in my opinion clearly the wrong name, as it depicts the starting point of the state machine and not an IDLE state, as the FB does not enter the IDLE state anytime no event occurs (=the FB is "idle"), which would lead to much more confusion than the same names in the management command (which a normal user usually never invokes directly) and an FB state with the same name.
I would suggest "entry point" or "Initial state" to clearly reflect the intend of the start state if a name change should be made
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We clearly got form several new users the feedback that start can be confusing.
I can also follow both of your argumentation lines. Very often in my FBs the initial state acts like an idle like state furthermore it further helps to show that it is not possible to add actions to the initial state.
However basic FBs are nearly always idle wating for an event to activate them. So this metaphore does not hold.
Hard to tell what would be the better option. To my understanding it would mainly affect this time the basic FB template or am I wrong here?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, but I cannot confirm this. In my 3 years of the IEC 61499 lab exercise nobody complained about the START state and I got a lot of complaints.
I gave this topic a lot of thoughts in the last 3 hours, and I have to strongly disagree that the argumentation to rename START to IDLE holds, but I can understand why there is confusion about this, due to the, im my honest opinion, bad BFB sample in the IEC 61499 standard which was taken as template for our BFB, but let me explain why.
First of all in my thinking the START state has a dedicated semantic meaning. It is the starting point of the ECC after the FB has been created or reset, and is exposing a working state of the FB itself as a necessary evil. Unfortunatly the template is also using it as a hub to reach the INIT state as well as an execution state, giving it a secondary role as a kind of IDLE state for the FB logic, which again unfortunatly intersects with the FB execution state of being IDLE.
Please note that I do not consider these states as equal, as one symbolizes an IDLE state in the intended FB logic, as the other one depicts the current execution state of the FB instance.
Please consult the IEC 614799 for the FB execution state machine, which defines the IDLE, RUNNING, STOPPED, and KILLED states
If we now introduce a dedicated IDLE state on the fact that the FB is idling, then we are unnecssarily expose an FB execution state to the ECC programmer.
Additionally we are encouraging bad design for the ECC, as most BFBs my students and myself are creating are not centered around a single IDLE state, and in most cases I would consider this bad design,
If all states can be accessed independently, and that would be the basic semantic message of a star-shaped ECC, then it should be better modeled as a SimpleFB.
Based on this I would suggest the following changes:
First, forbid incoming transistions to the START state
Second, change the template ECC so that the START state has an outgoing transition to the INIT state on INIT(+). From the INIT state an outgoing transition should go to a working state on REQ, Loop the wokring state in REQ. Again from the working state create an outpoing transition to a state called DEINIT on INIT(-), and last but not least an outgoing transition from DEINIT to INIT on INIT(+)
Third, if START is really to confusing, then change the name to ENTRY_POINT, or STARTING_POINT, as it semantically is exactly this and nothing else.
As to your question, yes I would also think that this would only affect the BFB template right now
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for all these comments they got me also thinking quite a lot.
First of all I don't think any more that start is such a bad name. In the end this is the state the FB will be after the start command (et least when coming from Idle). And yes Idle is in this case not better because of the management state machine (there are to many statemachines in 61499 ;-).
Regarding your last comment: According to the standard each state should have a name and I think we should keep it that way. However this comment triggered some other things I think would be intersting to consider, namly should we treat the start/initial state of the ECC special in the ECC editor? How about disabling that the initial state can be deleted or changed. This would reduce some elements of the UI mainly pull down menu items and properties. Furhtermore even if all is deleted there is always one state in the ECC editor. I could imagine that this could help startes to have some kind of anchor to start ECC development with when the accidentaly delete all states.
This brings me back to your first post. Should how should we name it or even should we allow to rename the initial state? So maybe in addition of not beeing able to delete it also to not allow it to change its name? Not sure about this.
I would not forbid incoming transitions on the start state. For several process it makes sense to go back to the original start state (espcially when the process is cyclic.
And this brings me back to how should a good ECC look for the default 4DIAC basic FB template? Should it have an INIT/INITO? should it be more generic? If it has INIT/INITO I agree that it should be different then now. But I would suggest that the INIT- goes via transition state to the start/initial state.
Looking forward to other opinions on this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding my last comment: I only gave some suggestions, if the state should be renamed/changed. If the state name will stay START I am perfectly fine with that.
Regarding your other suggestions. I never tried that, but if it is really possible to delete the START state, this should be changed immediatly! Also renaming should not be possible.
As I said in my second post, I think such cyclic FBs are corner-cases and can be easily created by adding an additional state after the START state. In my honest opinion, the START state should not be entered again, except via a reset of the FB, as that would strenghen the semantic message of the START state. I also think this would enforce a better design, e.g., that FBs are not able to be initialized multiple times unintentionally. But I admit that's a personal preference.
For the same reason I would prefer a dedicated deinitialized state, as the FB is probably in a different state, than a fresh reseted or created FB instance.
Probably a possible solution would be to provide more than one template for the usert to choose from, e.g. an empty template, an Init + working state template, and a working state template.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Given the discussion so far I developed a new basic fb template as you can see in the attached screenshot. If nobody objects I would add this template for the next release.
Furthermore I would also add an EmptyBasic FB template which contains only the START state and no interface elements.
I have some trouble with IDLE as idle implies for me somehow that the FB is not doing anything. Would Initial be better?
Should we change it in the Basic FB template?
but an FB does not do anything until an event occures therefore I still prefer idle
Idle is in my opinion clearly the wrong name, as it depicts the starting point of the state machine and not an IDLE state, as the FB does not enter the IDLE state anytime no event occurs (=the FB is "idle"), which would lead to much more confusion than the same names in the management command (which a normal user usually never invokes directly) and an FB state with the same name.
I would suggest "entry point" or "Initial state" to clearly reflect the intend of the start state if a name change should be made
We clearly got form several new users the feedback that start can be confusing.
I can also follow both of your argumentation lines. Very often in my FBs the initial state acts like an idle like state furthermore it further helps to show that it is not possible to add actions to the initial state.
However basic FBs are nearly always idle wating for an event to activate them. So this metaphore does not hold.
Hard to tell what would be the better option. To my understanding it would mainly affect this time the basic FB template or am I wrong here?
Ok, but I cannot confirm this. In my 3 years of the IEC 61499 lab exercise nobody complained about the START state and I got a lot of complaints.
I gave this topic a lot of thoughts in the last 3 hours, and I have to strongly disagree that the argumentation to rename START to IDLE holds, but I can understand why there is confusion about this, due to the, im my honest opinion, bad BFB sample in the IEC 61499 standard which was taken as template for our BFB, but let me explain why.
First of all in my thinking the START state has a dedicated semantic meaning. It is the starting point of the ECC after the FB has been created or reset, and is exposing a working state of the FB itself as a necessary evil. Unfortunatly the template is also using it as a hub to reach the INIT state as well as an execution state, giving it a secondary role as a kind of IDLE state for the FB logic, which again unfortunatly intersects with the FB execution state of being IDLE.
Please note that I do not consider these states as equal, as one symbolizes an IDLE state in the intended FB logic, as the other one depicts the current execution state of the FB instance.
Please consult the IEC 614799 for the FB execution state machine, which defines the IDLE, RUNNING, STOPPED, and KILLED states
If we now introduce a dedicated IDLE state on the fact that the FB is idling, then we are unnecssarily expose an FB execution state to the ECC programmer.
Additionally we are encouraging bad design for the ECC, as most BFBs my students and myself are creating are not centered around a single IDLE state, and in most cases I would consider this bad design,
If all states can be accessed independently, and that would be the basic semantic message of a star-shaped ECC, then it should be better modeled as a SimpleFB.
Based on this I would suggest the following changes:
First, forbid incoming transistions to the START state
Second, change the template ECC so that the START state has an outgoing transition to the INIT state on INIT(+). From the INIT state an outgoing transition should go to a working state on REQ, Loop the wokring state in REQ. Again from the working state create an outpoing transition to a state called DEINIT on INIT(-), and last but not least an outgoing transition from DEINIT to INIT on INIT(+)
Third, if START is really to confusing, then change the name to ENTRY_POINT, or STARTING_POINT, as it semantically is exactly this and nothing else.
As to your question, yes I would also think that this would only affect the BFB template right now
How about removing the name altogether, replacing it with a dedicated symbol, like a filled dot? Or just the double frame?
Thanks for all these comments they got me also thinking quite a lot.
First of all I don't think any more that start is such a bad name. In the end this is the state the FB will be after the start command (et least when coming from Idle). And yes Idle is in this case not better because of the management state machine (there are to many statemachines in 61499 ;-).
Regarding your last comment: According to the standard each state should have a name and I think we should keep it that way. However this comment triggered some other things I think would be intersting to consider, namly should we treat the start/initial state of the ECC special in the ECC editor? How about disabling that the initial state can be deleted or changed. This would reduce some elements of the UI mainly pull down menu items and properties. Furhtermore even if all is deleted there is always one state in the ECC editor. I could imagine that this could help startes to have some kind of anchor to start ECC development with when the accidentaly delete all states.
This brings me back to your first post. Should how should we name it or even should we allow to rename the initial state? So maybe in addition of not beeing able to delete it also to not allow it to change its name? Not sure about this.
I would not forbid incoming transitions on the start state. For several process it makes sense to go back to the original start state (espcially when the process is cyclic.
And this brings me back to how should a good ECC look for the default 4DIAC basic FB template? Should it have an INIT/INITO? should it be more generic? If it has INIT/INITO I agree that it should be different then now. But I would suggest that the INIT- goes via transition state to the start/initial state.
Looking forward to other opinions on this.
Regarding my last comment: I only gave some suggestions, if the state should be renamed/changed. If the state name will stay START I am perfectly fine with that.
Regarding your other suggestions. I never tried that, but if it is really possible to delete the START state, this should be changed immediatly! Also renaming should not be possible.
As I said in my second post, I think such cyclic FBs are corner-cases and can be easily created by adding an additional state after the START state. In my honest opinion, the START state should not be entered again, except via a reset of the FB, as that would strenghen the semantic message of the START state. I also think this would enforce a better design, e.g., that FBs are not able to be initialized multiple times unintentionally. But I admit that's a personal preference.
For the same reason I would prefer a dedicated deinitialized state, as the FB is probably in a different state, than a fresh reseted or created FB instance.
Probably a possible solution would be to provide more than one template for the usert to choose from, e.g. an empty template, an Init + working state template, and a working state template.
Currently you can delete all states and also select which of your states is the start/initial state.
As nobody objected to the idea that the intial state should not be delteable and changeable I created a seperate issue for it.
Given the discussion so far I developed a new basic fb template as you can see in the attached screenshot. If nobody objects I would add this template for the next release.
Furthermore I would also add an EmptyBasic FB template which contains only the START state and no interface elements.
I agree on both templates
I like them too. I think this will bring a great improvement in both understanding of the BFB as well as good ECC design
Thanks. I pushed the new templates in cset [fordiac-ide:ee1a18] and they will be available in 1.8 RC1. I close this issue for now.
Related
Commit: [ee1a18]