LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What am I doing wrong with asynchronous call and forget?

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.

 

Screenshot 2024-03-26 192438.png

Any help is greatly appreciated.

 

 

0 Kudos
Message 1 of 34
(577 Views)

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

Call&ForgetSnippet.png

Check how small snippet in the attachment works for you.

 

0 Kudos
Message 2 of 34
(550 Views)

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?

0 Kudos
Message 3 of 34
(533 Views)

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

0 Kudos
Message 4 of 34
(529 Views)

@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.

0 Kudos
Message 5 of 34
(523 Views)

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:

Call&Forget.gif

Message 6 of 34
(521 Views)

@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.)

0 Kudos
Message 7 of 34
(508 Views)

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.

Untitled2.png

 

 

 

 

0 Kudos
Message 8 of 34
(472 Views)

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

0 Kudos
Message 9 of 34
(466 Views)

@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 10 of 34
(459 Views)