The VI is implemented with QSM pattern. It polls the UI events like clicking
STOP, RECONFIG, and START. Please give your comments, suggestions and advices
Firstly congratulations on using the queued state machine, it's a really useful design pattern to know.
Also should should be congratulated on the logical and "clean" layout of the block diagram and for labelling wires and adding comments.
A few constructive points for your consideration;
1. There's an empty string in the enumeration (type def) used for holding the State. Was this intentional ?
2. Maybe consider using a Queued message handler with 2 loops (producer / consumer) when there are possibly long (time consuming) operations in a particular state such as writing data to a file. A consequence of a lengthy state operation could be failing to respond promptly to user action. Using 2 loops means that lengthy operations can be handled in the state machine whilst user events are still handled in the other loop. Have a look at some of the producer consumer / event handler design patterns on NI.com
Thank you for your time, comments, and suggestion.
That empty string is a type mistake. I have removed it.
I posted PC-QSM code for same project several days ago.
Then I thought to uesed relative simple QSM pattern to solve
the problem. Now after reading your suggestion I think that QSM
is not suitable for this project because some states take long
time to finish tasks. This will cause the slow reponse of VI to
the UI events.
I have attached the code in PC-QSM pattern. I will appreciate it
if you could take time to review it and give your advices.
Ok, I see you have re structured to give better performance especially during long running "states". I have a couple of suggestions that may be of use to you;
1. I find a really useful thing is to create my queue data type as a type def cluster containing an enumeration (or String although you need to watch for typo's) for the "state" and then a variant. Using a variant essentailly allows you to enque any supporting data type for your "State". The variant can then be de-coded in the relevant state case.
2. I also noticed that you destroy the queue reference when the top loop (event handler) stops, this will cause the dequeue vi to throw an error in the bottom loop as the queue is no longer valid, You then sniff the error wire status and if there's an error you then try to enque the Stop "State"......this will not work as the queue is no longer valid therefore the Stop state will not be queued. I would suggest placing the release queue vi in the stop case of the bottom loop, In it's current state the bottom loop will never exit.
I will try to dig out an example of how I've stopped parallel loops using queues.
Sorry for late response. I have removed all instrument related Sub VIs from PC-QSM-IETS-MOD 03 and
saved as PC-QSM-IETS-MOD-04. After running it I can not push stop botton to stop it. The other issue is
that VI is stuck in some places. I have to click start to make it continue. I guess that this could have something
to do with the cluster in the queue data. But I don't know why. Colud you give me the clues?
I also have modified QSM code same way as on the PC-QSM and put erorr in Analyze case intentionally.
after highlight executingI noticed that it finally stays in Initialize00 state forever. Could you help figure it out?
I have attached two codes with the post.
Sorry for so many questions.
Thank you for your help.
I am looking at the code now and will look at the issues described but some info from you would help, specifically what was your intention in having 2 initialise state (one is called Initialise00) ?
The Initialize00 greyes out some parameters that do not need to be changed while VI is running and also calculates the bias array.
The Initialize configures instruments. In orer to chage some parameters while the VI is running I reset their vaules then push reconfig
let VI run just the content of the Initialize not of both the Initialize and the Initialize00. So I separate the Iniatialize00 from the Initialize.
The State Machine & QSM are great tools to have in your repertoire.
I briefly looked at your code and would like to provide the following comments:
Based on the way you wrote your code, you could easily replace the queue with shift registers to carry the next state of the state machine.
From my point of view, the idea behind a QSM is that you can send a number of states to the queue (usually have an Action Engine to handle the queued state inputs) all at once and the QSM will go through each state in the order that was entered into the queue. It is great to build a sequence of actions.
If you are experimenting, you can try to modify your QSM to have all the states entered during the initialization state. However, you would need to create a QSM Handler, first.
Great job.. Keep learning and pushing that enveloppe. 🙂
Have a look at the attached example. I have added a state manager function (copied from an example I have previous seen created by Tomi Mailla at JKI) and have added some error handling state also. Please have a review, hopefully the code is clear and makes sense but if you have any questions, just ask !