Tips to remember when using Queued State machine

[VeeJay]

Yes absolutely! Notification is the only communication between loop 1 and 2. Is there any other way to ensure STOP loops?

Now back to timeouts, I am still dealing with some issues here. ANy chance I can replace Notifier with some other (BETTER??) method to avoid dealing with Timeouts there as well and just focus on Q's. Thanks!

V

[VeeJay]

Actually, small error in the diagram. Loop 1 and Loop 3 labels should be changed.

[johnsold]

VeeJay,

Notifiers are one of the better ways to stop parallel loops.  You can also use queues, but a queue just for stopping is overkill.  If you were sending other commands to loop 1 via a queue it might be convenient to include the stop command.  With the structure you have, I would stay with the notifier.

When you develop a fix for the queue timeout issue, the exact same method will work with the Wait on Notification.

What are your current issues with timing?  There have been enough changes that I am not sure what you have and what does not work about it at this point.

Lynn

[VeeJay]

The ideal architecture for my application would be using the same Q between Loop1 and Loop3 for events as well. Basically my event structure handles User events whose consequence results in state change in Loop 3 State machine. But, it would involve adding the User event state in front of the Q and I am intimidated to increase complexity. I will hold that as an exercise once I have this working. For now, I will work with two Q's

The issues I am facing is one with respect to timeouts and Timing in loops. Would I be able to manage loop timing with timeouts on Q's? I guess most of this should be trial on my side becuase of the way my device works. All I would like to know at this point is w.r.t. Q timeout. Does the Q timeout because there is no element in the Q or does it timeout because it is unable to retrieve an element within the current iteration that it timesout?

Also would it be better to check for Q full before enQing or check for Q empty before deQing, Although I do not anticipate either because I am forcing elements to enQ and deQ all the time, vis'-a-vis' #elements in Q will always show zero.

V

[johnsold]

VeeJay,

I agree that adding complexity at this stage just to make the architecture more "ideal" is not appropriate.  If a change becomes necessary to get it working, then that could be considered.

In loop 1 the behavior is limited by the serial port speed.  I think I would let the serial reads determine the timing there.  That means that any Dequeue or Wait for Notifications should have short timeouts AND that you must check the timed out status of each to determine the validity of the data at their outputs.

In loop 3 I would use one of the queues to set the timing (10 ms timeout) and set all others to short timeouts.  Anothre option would be to set all to 10 ms.  Then the loop would wait 10 ms if data was not present in all queues and notifiers.  This has the disadvantage that the state machine code will not start executing until the timeouts have occurred.  If some states require a substantial amount of time to complete, the short timeouts are probably better.

If loop 2 is only handling the event case, I would ask whether it could run without timeouts.  Generally event loops only need to iterate when an event occurs.  This is different from the way you had your loops set up, so yu would need to look carefully at the queues and notifiers to see whether waiting indefintely causes problems elsewhere.

None of your queues have limited sizes (other than the 2^32 inherent limit), so there is no need to be checking.  During troubleshooting and debugging, checking the # elements in the queue can be useful to see if the dequeue loops are keeping up.  At the speeds you are running, It would take several weeks to fill one queue if you never dequeued anything.

Lynn

[VeeJay]

Hi Lynn,

Quick questions!!!

A timeout on the "Configure VISA" funtion would suffice? Or should I set timeout on VISA READ AND WRITE?

If I have set it large enough like 250ms or so, would I still have to set timeouts for DeQ and Notifiers? Maybe make them 50ms?

Why would deQ function timeout affect State machine code? I want the SM code to run at 10ms atleast, so setting deQ timeout 10ms should not timeout ya? Unless they are sequential that SM code runs for x ms after 10ms timeout on deQ. Is this how it works?

Also, wouldn't waiting indefinitely on an event structure cause the program to freeze? Isn't that why we program a timeout case?

I haven't really made use of the inherent property of latency by using Q's. All I did before Q's is use property nodes or local variables to wirelessly send command and data to state machine code. I thought that by using Q's, I could enQ as they come and deQ as I needed at a different rate, but looks like I deQ as soon as I enQ, hence # elements in Q =0 most of the time. I am not complaining 🙂 but I really thought by using Q's I wouldn't be losing information. My Q is effectively a 1 element Q. 🙂

V

V

[johnsold]

VeeJAy,

The timeout on Configure VISA is an integer and is in seconds (unlike most other timeouts which are in milliseconds). There is a property node which can set the VISA timeout with ms resolution.  You need to put one of those after the Configure to have a 250 ms timeout.

The Dequeue timeout affects the state machine by forcing the state to wait the timeout period if no data is in the queue.  If the code in the state then takes 8 ms for example, the total time for that iteration of the loop would be 18 ms.  They will be sequential if the data from the Dequeue is an input to the case structure.  If the Dequeue is inside some state and the data is processed within that state or passed via shift register to other states, then the timing is not sequential.  I have not seen your state machine, so I am not sure how you have it wired.

Waiting indefinitely on the event structure will keep that loop from running until an event occurs.  This is not bad. If the only thing that loop does is to wait on events, why should it spin on timeouts?  As long as one of the events is the Stop, this is not an issue.  However, doing it this way means you need to change your Stop notifier and possibly some of the queues so that not having something sent every 10 ms does not cause the rest of the program to freeze.

You will not lose data by using queues (unless you specifically choose the Lossy Enqueue, which you have not). The latency I was referring to is that caused by enqueuing data from a shift register in the top loop. The data is placed into the shift register on the previous iteration. This means that the data enqueued is 10 ms old.  The ideal situation is that on average the # elements in the queue is 0.  If the number continuously growing, eventually you will have a memory problem.  One case where a queue grows and shrinks is where 100 data points are collected at one time and put into the queue whle they are dequeued one point at a time.  In a case like that the dequeue loop need to run at least 100 times faster than the enqueue loop.

Lynn

[VeeJay]

My Case structure in Loop 3 depends on values received from Loop 1 Q. Hence, I believe the loop would run the way you have described.

I think I should deQ values in loop3 to a shift register and send the shift register values to the SM case so that it doesn't wait for "timeout" time. Would that be a better option? In all terms though, I am really not so concerned if my loop runs at 15ms instead of 10ms as long as it does not hang/freeze. The only place I will notice will be log files which I currently record every iteration.

I thought the default on timeout on "Configure VISA" was 10000 = 10sec. I will settle with a timeout there and a relatively much small timeout for deQ, enQ and Notifier in Loop1.

[johnsold]

VeeJay,

---

I think I should deQ values in loop3 to a shift register and send the shift register values to the SM case so that it doesn't wait for "timeout" time. Would that be a better option?

---

I do not see how this makes much difference.  Whether you connect the Dequeue output directly to the case structure or indierctly through a shift register you still have both delays. With the shift register method the delays would be in parallel so that the longer one would dominate but the data woudl get to the state machine one iteration later.

One of us (maybe both) is confused. Can you post your ideas for loop 3 with the state machine.  Even if it is a mostly empty case structure I can see how you intend to connect the shift registers and the dequeue functions.

Lynn

[VeeJay]

Hi Lynn,

I think I am overthinking it. But, just to clarify, I have attached 2 images showing the way elements are used for the State machine. Note: I have not yet included timeouts, that is something I am working on. Please let me know if this clarifies your question. I really appreciate your answers, as it is knocking out so many doubts from my head.

V

Edit: I just read what you had actually asked. I am working on getting you that vi. But, what I mean by deQ and shift registers is sending the deQd element to the shift register and using the value from the shift register front end into the case structure. I will be delayed by one iteration but my question was would that reduce the delay we were discussing about.