Polling hardware without holding back QSM

[johndoe773]

Hello NI community,

I have an issue with polling hardware for ready state. I have no clue on how to do this when the system is using QSM (Queued state machine). I have devised a way to do so and attached it to the post but I still wonder:

- Is this the correct way?

- Is there a better way?

- How does anybody else try to do this?

There is a link with the following post

https://forums.ni.com/t5/LabVIEW/Maxon-motor-profile-positon-mode-immediate-setting/m-p/3589964

The goal is to work with QSM. The hardware needs to be polled to check if it is ready with the previous command. When the previous command is excecuted and the hardware is ready, the trigger should be set for the next command to the hardware.

Any advice?

[Wolleee]

Is there a reason you  need a second loop for polling? You have your user interface available in your main producer loop to send the main consumer loop, "message handler loop", commands if need be.  You can enqueue them in the front if they must be handled immediately.  So what you can do is trash the polling loop and enqueue your polling state in the message handler loop when you need to continue polling.   

Also you can replace the delay express vi with a wait and wire directly to the poll finished indicator instead of using a property node. You can also do away with the quit variable and wire a true constant directly from your exit case.

[billko]

---

@Wolleee wrote:

Is there a reason you  need a second loop for polling? You have your user interface available in your main producer loop to send the main consumer loop, "message handler loop", commands if need be.  You can enqueue them in the front if they must be handled immediately.  So what you can do is trash the polling loop and enqueue your polling state in the message handler loop when you need to continue polling.   

Also you can replace the delay express vi with a wait and wire directly to the poll finished indicator instead of using a property node. You can also do away with the quit variable and wire a true constant directly from your exit case.

---

Doesn't the polling loop exist so that it can poll at the same time the Main Consumer Loop is doing stuff?  If you move the polling into the Main Consumer loop, it can be polling OR doing something else.

[Wolleee]

---

---

Doesn't the polling loop exist so that it can poll at the same time the Main Consumer Loop is doing stuff?  If you move the polling into the Main Consumer loop, it can be polling OR doing something else.

---

Billko,

i did read that in the post title that an external polling loop was desired, but it didnt sound like it was necessary based on the information given.  It sounded like the polling could be a state in the QSM because there was no mention of doing a parallel task.  If that is incorrect then yes, the external polling loop is required. 

[johndoe773]

I might have not explained fully, indeed.

What I have is a QSM loop with a consumer that can activate a hardware (motor) move. Once the hardware is moving then the consumer loop will be busy with performing precise timed measurements. I can not afford the main consumer loop to be held back by polling or polling delays. That is where in my mind a third loop came into the equation. The third loop can then poll the hardware for the ready state. When the trigger is there for the hardware ready state, a trigger can be given to the main consumer loop that the move is finished and a next move can be performed. The next move in its turn is again measuring and polling for the hardware.

However the example that I made is messy and somewhat unstable. I searched furiously on the forum to find how this should be tackled, but I was unsuccessful.

[BrandonC1]

I've been looking into your VI, could you tell me where the polling delay is coming from?

[johndoe773]

I am sorry I did not reply to you sooner. I have not been on the forum for some time and missed your question.

The polling delay would be due to the code and hardware latency. I included a fast sketch in paint of this delay origins. The issue is as  well that you are never sure how long the delay will be. The time is linked to where you are located in the polling code.

I "solved" it by making my measurement data not time-based but sample based. The graph looks like cr#p but the process is no longer time based. All the processes are now in one producer consumer loop.

It somewhat works, but it is far from ideal (I guess that's labview for ya!). I am still interested in a good fix for this if anyone knows a way.

[BowenM]

I'd mentioned in a post awhile ago that I've been using an interrupt type QSM - you can see an example I posted here. It is a slight modification to the consumer loop that allows it to just go about its business doing whatever it needs to (polling hardware, updating plots, etc), but will still respond to GUI events.  These events can change the state (switch from polling to waiting for example) without much overhead.

It isn't ideal for all situations, but any time I need a loop in the background polling hardware, reading data, etc it is my go-to architecture.

[JÞB]

Look into my tag Cloud for Grandma

A timer state can help.

I'll post an example tommorow.