Tips to remember when using Queued State machine

[johnsold]

VeeJay,

I do not understand exactly what you have connected when you asked this:

---

When I use shift registers and monitor values with probe in producer, the values remain the same until the device changes it.

In consumer SM, when I deQ , there are 0s in between i.e. what I enQ is not deQing the same values

---

Do you have a timeout on the Dequeue? Do you have any cases with output tunnels set to Use Default if Unwired?

Why do you want to maintain values without a shift register?

Lynn

[VeeJay]

---

@johnsold wrote:

VeeJay,

I do not understand exactly what you have connected when you asked this:

---

When I use shift registers and monitor values with probe in producer, the values remain the same until the device changes it.

In consumer SM, when I deQ , there are 0s in between i.e. what I enQ is not deQing the same values

---

Do you have a timeout on the Dequeue? Do you have any cases with output tunnels set to Use Default if Unwired?

Why do you want to maintain values without a shift register?

Lynn

---

Hi Lynn,

Here is what I am observing. When my device sends values, for eg. speed =2.5mph, I send that to the shift register cluster along with other values like (START, STOP, TEST END, SPEED, ANGLE) . I enQ the cluster from the shift register to the Q in 1st loop.

When I deQ, what I see is a bunch a zeros in between. I do not have any cases with output tunnels set to Use Default if unwired. I pass the wire through in other cases; speed values are changed in CASE 163 and Angle values are changed in CASE 164 etc.

When I put a probe tool to see values in loop 1 , the values remain as it it unless changed. When I deQ in SM loop  (3rd loop), START boolean keeps changing from TRUE to FALSE at loop rate. Keeps starting and stopping. Basically all values in cluster don't remain the same unless the device changes them.

I will have to try combinations of timeouts and time delays etc. It is causing too much problems in my application.

Quick question regarding Q's. Timeout = TRUE when a deQ cannot deQ a value or when a value is not available to deQ? Because in my program, I enQ and deQ every iteration, hence there is a value ALL the time.

Thanks!

V

[VeeJay]

Hi tob,

Thank you! But, I guess my question could have been clearer. I understand the use for shift registers. My question is with regards to Q's.

When we run Q name and error wire through a while loop, you say it is better to use shift registers than tunnels. I agree. Do I use shift registers for Q name and error in both enQ and deQ loop?

V

[johnsold]

VeeJay,

"When I deQ, what I see is a bunch a zeros in between. I do not have any cases with output tunnels set to Use Default if unwired. I pass the wire through in other cases; speed values are changed in CASE 163 and Angle values are changed in CASE 164 etc."

Without going back through the entire thread I may be asking something you already answered.   The other way zeros could get into the queue is if the serial reads are not getting the correct data.  I have no way of checking that of course since I do not have your hardware.  In the TDML_split_control_and_data.vi the Speed and Angle outputs are 0 if the default case is called.

Also, because of the shift register in the upper loop, the Speed and Angle data is enqueued one iteration later than when it is received.  Then that data gets enqueued to the bottom loop one itreation after it is received.  The feedback going the tohre way does not appear to be delayed. Is this an issue? Can the remote device get confused by getting delayed feedback?  It gets SOMETHING ~ every 10 ms but it may not be the right something.

Lynn

[VeeJay]

---

@johnsold wrote:

VeeJay,

Without going back through the entire thread I may be asking something you already answered.   The other way zeros could get into the queue is if the serial reads are not getting the correct data.  I have no way of checking that of course since I do not have your hardware.  In the TDML_split_control_and_data.vi the Speed and Angle outputs are 0 if the default case is called.

THat is the exact reason why I have the Speed and Angle indicators inside case 163 and 164 respectively, so that I dont get the defaults sent when other cases are being executed. Is that not what happens? If case 163 is executed and a data value of 2.5 is extracted, won't the indicator hold the 2.5 value until case 163 is executed again? I assumed this, hence I don't get why 0's were being sent in place of 2.5's for eg.

Also, because of the shift register in the upper loop, the Speed and Angle data is enqueued one iteration later than when it is received.  Then that data gets enqueued to the bottom loop one itreation after it is received.  The feedback going the tohre way does not appear to be delayed. Is this an issue? Can the remote device get confused by getting delayed feedback?  It gets SOMETHING ~ every 10 ms but it may not be the right something.

I will check for incorrect feedback today. The best way for me to do that is just not respond with the correct feedback B's and D's. But, I don't think Delay will cause the device to get confused. I think it is built on delayed feedback acceptance, but not error feedback. i will do this experiment and let you know.

Lynn

---

[johnsold]

VeeJay,

I ran the TDML... subVI by itself (of course without a remote device) and it appears to set the Angle and Speed indicators to default (0) values when the default (no action) case runs.  Try it yourself.  If this is not the intended action, perhaps you can set some value which can never occur to the indicators in the default case and "filter" those out in the other loop. Or add a Valid boolean which is set True only when data is received from the remote device.

Lynn

[VeeJay]

Thanks Lynn! Would you think using shift registers would maintain the speed and angle at intended values until a new change comes from the device vis'-a-vis' through case 163 and 164 respectively? I thought that since I had the indicators inside the cases, a value received will be held until it is changed.

V

[johnsold]

VeeJay,

Yes, you should be able to do it with shift registers.

The subVI needs to generate some kind of output for each inidicator wired to the calling VI every time it is called.  It has no way of remembering the results of the previous call unless you program it to do so. Since you already have a shift register in the upper loop carrying that cluster, just pass it through the subVI and change the data where appropriate.

Lynn

[VeeJay]

Thanks Lynn! I understand now. Maybe if they were controls, then they would maintain the value through each iteration and I would feed values to the speed/angle control in case 163/164 through property nodes. which I wouldn't want to do. Hence, I will use shift registers.

As I think about this problem more, please refer to the attached image. Would you think the second method would be more ideal? Also, as you suggested, I am no longer having the control code event case, rather, I have brought it up in the upper loop sending ACK immediately to VISA WRITE. I will however send the entire cluster as you have suggested coz that makes total sense.

V

[johnsold]

VeeJay,

I think the second method make sense.  If you no longer have the control code event case, is the communications between loops 1 and 2 now just one way (the stop notification)?

Lynn