What am I doing wrong with asynchronous call and forget?

[madvillain97]

I have a simple state machine program, where the first state (0) is an event case handling Front Panel controls. One of the events handles the movement of a Motorised stage, and inside, there's a case structure to determine if the button pressed was for a simple + - step movement in x,y,z, or a "move to absolute position case". If it's the latter, I want to call a subVi that iteratively moves to that position and compensates for backlash (a simple while loop that checks if the position has been reached by reading the encoders).

However, each time I call the subVi, the state machine halts until the subVi finishes. I want to implement it in such a way that the subVi is called, and the state machine goes back to the Timeout event (state 0) where I read the encoders every 50ms. I thought calling it with asynchronous call and forget would be a way for it to run in parallel with the main VI, which is what I want to achieve, but apparently I'm missing something.

I would like to do this without implementing a QMH, as I will be calling the subvi in the background while I'm in a new state collecting data from a potentiostat.

 

Any help is greatly appreciated.

[Andrey_Dmitriev]

Interesting, my initial suggestion was that you occasionally starting two times in your state machine, but even that, then caller will finish execution:

Check how small snippet in the attachment works for you.

[wiebe@CARYA]

Is the VI you're starting reentrant?

If not, I assume a 2nd call will wait for the first one to finish before leaving the Start Asynchronous Call node.

EDIT: Apparently, Start Asynchronous Call node doesn't wait if the non-reentrant VI is running, but 'queues' the starts. Not sure if that explains your situation. Maybe post some code?

[madvillain97]

Thank you for your reply.

The Vi set as reentrant indeed. However, when I call the vi, execution stays in that event case instead of going back to timeout so that I can use the other FP controls.

My issue here is that I want to create a Vi to achieve slower speeds than provided by the controller (from 20 um/s to 2 um/s by just moving stepwise 95nm with a ms wait time delay in with a subvi). This indeed will need to be run in parallel to the state machine, but it seems to wait for the Vi to finish before moving to the next state.

Is my only alternative now to make a QMH?

Thanks for your time

Edit: I'll post my code ASAP

[Andrey_Dmitriev]

---

@madvillain97 wrote:

Thank you for your reply.

The Vi set as reentrant indeed. However, when I call the vi, execution stays in that event case instead of going back to timeout so that I can use the other FP controls.

---

Still unable to reproduce an issue regardless if SubVI is reentrant or not. In case of reenterant multiple copies can be invoked parallel, if not, then the only one, but caller still not blocked (also in case if both contains event structures). Please post your minimal code to reproduce, this sounds interesting.

[Andrey_Dmitriev]

---

wiebe@CARYA wrote:

Is the VI you're starting reentrant?

If not, I assume a 2nd call will wait for the first one to finish before leaving the Start Asynchronous Call node.

---

No:

[wiebe@CARYA]

---

@Andrey_Dmitriev wrote:

---

wiebe@CARYA wrote:

Is the VI you're starting reentrant?

If not, I assume a 2nd call will wait for the first one to finish before leaving the Start Asynchronous Call node.

---

No:

---

👍 (I did spot that myself, see my edit that I posted 30 sec. after the original post.)

[playerm1]

With talk of micro and nano-second timing, is this running on an RT-Target like a cRIO?  I can't think of an exact reason why that would account for the behavior you are seeing, but it would be an easy thing to rule out by trying to run the same code on a standard Windows box.

Any other non-standard settings in VI Properties >> Execution?

Weird settings for VI server for target (target >> properties) or environment (tools >> options)?

Maybe try opening the VI reference by path instead of by name to see if it does anything different.

[Andrey_Dmitriev]

---

wiebe@CARYA wrote:

---

@Andrey_Dmitriev wrote:

---

wiebe@CARYA wrote:

Is the VI you're starting reentrant?

If not, I assume a 2nd call will wait for the first one to finish before leaving the Start Asynchronous Call node.

---

No:

---

👍 (I did spot that myself, see my edit that I posted 30 sec. after the original post.)

---

Oh, sorry, I was busy with gif creation, didn't catch this, should refresh comments before posting

[crossrulz]

---

@playerm1 wrote:

Maybe try opening the VI reference by path instead of by name to see if it does anything different.

---

If using 2024Q1, you can wire the VI reference straight into the Open VI Reference instead of the name or path.  I am weirdly excited about this feature.