- Software
- IQANdesign
-
Ideas
Finite State Machine Improvement Ideas
I love the Finite State Machine. Great to see such an excellent feature added to the program after being away from IQAN for 11 years.
That being said, here are two possible improvements for the Finite State Machine:
1. The addition of Delay on to the arrows.
Justification: I find myself adding alot of internal digital channels outside of the Finite State Machine that are looking for the machine to be in a specific state number so long before turning true. Adding this and possibly the Delay off would make the code in the Finite State Machine more readable and explainable.
2. The addition of being able to set a debug on a state in the Finite State Machine:
Justification: The states can zoom through things so quickly that the only way to trap a bug would be to set a trigger to hold the Finite State Machine in that state. The alternative is to add all the exterior channels that contribute to the logic in a measure group and then work on analyzing what happens.
Implementation: The ability to set a debug flag on that state. Then as that state is about to be exited because an exiting arrow has turned true, the state would be held. The debug flag wouldn't persist between power cycles of the evaluating master module and debug flags cannot be communicated when sending a project. I know that this could be a touchy subject for IQAN because nothing else in the program allows you to pause the execution of blocks in real time. But I would like to make the argument that Finite State Machines tend to be used for supervisory or sequencing logic of actions on machines and staying in one of these states as long as the underlying safety checks are being performed in conventional channel blocks, this wouldn't pose a risk to life or machine.
Customer support service by UserEcho
Hello John
The delay is actually something that you could do if you are using Qcode.
If you have a local parameter in the code that you count up each cycle and only set the result to true when it reaches a specific level you have a timer based of the cycle time.
Something like this.
-------------------------------
static int:=False //local parameter
static temp:=0 //local parameter
if flank(DIN-A) then int:=True //Trigger start of timer
if int then temp:=temp+1 //Timer
if temp>40 then
temp:=0
int:=False
Result:=True
endif
-------------------------------
As for the debugging because the state changes to fast.
You could use the step function in the simulator just go a single cycle forward to get a better view of what is happening.
Thomas,
Yes, I could do the timers via Qcode or IDCs with delay ons. But your competitor, Simulink, is offering timer functions within their state flow modules.
https://www.mathworks.com/help/stateflow/gs/temporal-logic.html
As for the debugging, I would like to catch the issue on the machine and not just within IQANsimulate.
Adding a "delay on" as we have on the IDC channels to the transitions might be something that can be useful.
As for catching issues in run time on machines.
You can set up measure groups with the channels that you are interested in looking at.
Then use IQANrun/go/design to record what is happening.
This way you can see what the values of each of the channels are.
You will not be able to see what is going on in the code this way but you can at least see the values and from that debug what is happening in your code.