state machine with polling loop

[jyang72211]

A few questions.

1. For notification, if I don't want to wait for notificaiton, I just set the time out to 0, right?

2. If we do 1, couldn't we do the same thing with a dequeue as well?  Why use notification instead of a queue?  

3. To use notification to stop long task in my state machine (the long task is probalby in a subvi), I have to pass the notification referene into the subvi, right?  

4. What did you mean by pure finite state machine?

5. What is Ben's article?  

Thanks!

[Mark_Yedinak]

---

@jyang72211 wrote:

A few questions.

1. For notification, if I don't want to wait for notification, I just set the time out to 0, right?

2. If we do 1, couldn't we do the same thing with a dequeue as well?  Why use notification instead of a queue?  

3. To use notification to stop long task in my state machine (the long task is probably in a subvi), I have to pass the notification reference into the subvi, right?  

4. What did you mean by pure finite state machine?

5. What is Ben's article?  

Thanks!

---

1. Yes, you can use a timeout of 0. This also allows the LabVIEW scheduler to check if other tasks need to run which helps to prevent starving the CPU.

2. The benefit of using a notifier is that it supports multiple listeners. Unless you use queue preview you cannot do this with queues. Therefore notifiers provide a broadcast capability.

3. Yes and no. You can pass the reference. Or you can use a predefined name for your application notifier and obtain the notifier reference using that. This name can essentially be a constant value in your application and therefore would not require you to wire anything to subVIs. You could wrap the check of the notifier in a subVI that you call when necessary in your subVIs.

4. A finite state machine is a state machine that every state and state transition is defined. A queued state machine breaks this since states can be injected at any time during the execution.

5. I will have to find the link to Ben's post. I should bookmark this for myself.

[JohnCS]

---

@jyang72211 wrote:

Using clear timing source to stop a timed loop from a parallel loop?  I didn't know that you can do this.  That's a pretty good idea.  I don't really use timed loop.  Do you have to create a time source to use it?  What is the advantage in creating a time source?  

---

A timing source is not necessary to run a timed loop. In that case, one of the built in timers of the O/S is used.  In the example that I posted earlier, I created a timing source and wired it to the timed loop's source terminal. The 1 kHz timing source is paced by the your system's O/S millisecond clock but other sources are possible. These are hardware dependent.

The timing source is named in this case, that way you can connect to it from other locations in the app without wiring it directly if necessary. Naming a queue or notifier works the same way. Without the timing source, you need to wire the timing loop's structure name to use the timed loop support VIs. A single timing source can be used to synchronize multiple time loops.

Using a Wait or Wait until next ms inside a while loop does not always act as expected.  In many instances, programmers add the timer in the while loop with the expectation that the the total time of the loop will be the time for the activity plus the wait. If there is no data dependency between the timer and the other activities in the loop, the timer will act in parallel with the other activities. If the elapsed time for the activity is smaller than the wait time, I expect to see the total time equal the requested wait time. The timed loop increases the determinism of the looped process. It gets better if you use hardware for the timing source.

Using a timed loop allows you to monitor the performance of the loop on the fly. The left data node of a timed loop exposes quite a bit of information about how well the loop is performing. Useful for troubleshooting.  The right node allows you to make programmatic changes to the loop's parameters between iterations. For example you might want to increase the period of the loop if you find it runs late. Using the sequenced timed loop allows one to create a repeatable series of activities whose timing parameters can be programatically changed  based on the previous sequence.

To kill the loop, I cleared the timing source in the stop event in the UI loop. The timed loop will immediately stop waiting and complete one more iteration before stopping since its timing source is gone. This way I won't have to wait for the loop to time out before stopping. In the while loop-wait pattern, you have to wait. The timed loop's left data node will return Wakeup Reason is Timing Source Error.  I could use this as a stop cue  and start whatever cleanup that the loop needs as an exit activity before actually stopping. (ie. closing valves, turning power off, one last file write, etc). 

JohnCS

[jyang72211]

Thanks for the answer.  They are great.  For your answer 1, you said that timeout of 0 for a dequeue or wait for notificaion will allows the LabVIEW scheduler to check if other tasks need to run to prevent starving the CPU. What do you mean by that?  I don't see the connection.  

[jyang72211]

Thanks!  Lots of food for thought.  What did you mean by "

Without the timing source, you need to wire the timing loop's structure name to use the timed loop support VIs. A single timing source can be used to synchronize multiple time loops"?  Can you elaborate?  

[JohnCS]

---

@jyang72211 wrote:

Thanks!  Lots of food for thought.  What did you mean by "

Without the timing source, you need to wire the timing loop's structure name to use the timed loop support VIs. A single timing source can be used to synchronize multiple time loops"?  Can you elaborate?  

---

The timed loop and timed loop VIs use names as references. The timed loop VIs need a name to tell them which loop to act on. There are two possible inputs to the timed loop via the Configure Input Node which will accept a name. You only need to use one. There are cases where you may want to use both.

1. The timed loop can be given a Structure Name which you then wire to  the timed loop VIs located elsewhere.
2. Left unwired, LabVIEW will assign the structure a name.  You can use that name instead.
3. The timed loop can be given the (timing) Source Name that you create with the Create Timing Source VI. Now the loop will refer to that named source. Now you only have to give the VIs the name.
4. You can create a software timing source whose output is a timing source name.
5. You can synchronize with the NI Scan Engine.

When you want to synchronize multiple timed loops, the Structure Name for each loop in the cycle is necessary.  For more synchronization info, check out Synchronizing Timed Structures in LabVIEW Help.  Lots of info there. Also search examples for 'timed-loop.'  Good examples of synchronization there.

In a multi processor computer, another good timed loop feature allows you to direct handling of that loop to a specific processor.

JohnCS

[Mark_Yedinak]

---

@jyang72211 wrote:

Thanks!  Lots of food for thought.  What did you mean by "

Without the timing source, you need to wire the timing loop's structure name to use the timed loop support VIs. A single timing source can be used to synchronize multiple time loops"?  Can you elaborate?  

---

If you write a while or for loop with no VI that will allow the scheduler to check if other nodes are available to run you will starve the CPU and more than likely have a very difficult time executing any other part of your program. The traditional answer to solve this is to use the Wait VI. To allow for maximum performance you should use a timeout of 0. The Wait VI, along with the notifier and queue VIs will internally allow the scheduler to see if other tasks are ready. If they are, it will allow a context switch to occur. Most any VI that has a timeout on it will force a check of the scheduler. SImple operations like numeric or string VIs do not.