Challenging the Explanation of why to use Helper Loop

[breiter56]

Hello world. In an attempt to improve my understanding as I begin leaping into the DQMH world, I'm challenging the explanation of the unresponsive behavior explained at : https://youtu.be/F8DiZrDcres?t=1544https://www.youtube.com/watch?v=F8DiZrDcres&t=1439s 26:38

"The Queue is full of pending "Acquire" messages". It appears that the Queue isn't full of a bunch of acquire messages. For every message enqueued, there is one dequeued at the same rate. What I see is that another "Acquire" message is enqueued after the "Stop" message. The MHL loop "Stops" for one iteration and then dequeues the one remaining "Acquire" message then the self enqueuing "Acquire" begins again.  

Is my explanation/understanding technically correct?

[Olivier-JOURDAN · Accepted solution]

Hello @breiter56 

First of all, I hope you'll continue to dive into DQMH and love it 😅

I'd say you are right in your interpretation. Congrats on your attentive listening.

That being said, this is not invalidating the use of the helper loop because:

1. you'll still need to flush the MHL queue to stop the acquisition, and it's not a good thing
2. you can't be sure of the periodicity of the call of acquisition if other messages are enqueued in the MHL
3. if the acquisition takes time to execute, the module can respond to other requests slower than expected

I hope this helps you better understand the interest of helper loops in a DQMH module.

[breiter56]

Thank you Mr. Jourdan, 

I am continuing to take the dive and am loving it.

- Jared

[Olivier-JOURDAN]

---

@breiter56 wrote:

I am continuing to take the dive and am loving it.

---

👍😃

[drjdpowell · Accepted solution]

---

@Olivier-JOURDAN wrote:

That being said, this is not invalidating the use of the helper loop because:

1. you'll still need to flush the MHL queue to stop the acquisition, and it's not a good thing
2. you can't be sure of the periodicity of the call of acquisition if other messages are enqueued in the MHL
3. if the acquisition takes time to execute, the module can respond to other requests slower than expected.

---

Side note, but it is only actually (3) that strongly suggests a helper loop.  Number (1) is easily solved with a simple state Boolean to record if we are acquiring or not. And (2) can be achieved several ways.

[breiter56]

Thanks again, 

I believe my intuition lead me to the solution for (1) - See attachment. To be honest, I had to "code and fix" to get there, but I am feeling pretty proud, after a year of  getting into LabVIEW....

The motivation behind my questioning is to avoid un-scripted code as much as reasonable. I'm still very early development of a serial comms - stepper motor/drive module. I expect to add events often, that almost all cases will be command arguments to the drive that must interrupt the "Read Encoder Position - "EP"" and then the MHL can go right back to reading EP until the application stops. 

There is a segue here to the next part of my plan and (New discussion post?) to "minimize redundant code in the module" vs "un-scripted code in the API tester". I'm not sure of the trade-offs for choosing (A) to make events for many (20?) drive-commands, or (B) a couple events and vary the commands in a couple event arguments (Write serial, and Write->wait->read serial) 

- Jared