Setting a Constant Execution Speed

[wesdeeg]

Good morning!

I've been having some small problems using a VI that calls to a mechanical stage through a VISA resource. This is one part of a larger experiment, and the experiment is very time sensitive, so we need all parts of the program to take the exact same amount of time. However, through testing I've found that the time it takes for this small VI to call the VISA and adjust one parameter shifts by a couple of milliseconds every time, ranging from around 7 to 30 milliseconds, which is far too large a range for my program. I was wondering if there was some way I could set the execution speed of the VI so that it is the exact same every time? Or remove this time entirely, but I don't know if that's possible considering it has to reference a VISA resource.

For reference, this is the VI that is being called as a subVI. When I run the main VI by itself the elapsed time is even larger, usually around 48 milliseconds but jumping up to 80 milliseconds sometimes. I've attached the full VI below.

 

Any help would be greatly appreciated!

Wesley Deeg

[Kyle97330]

First off, getting exact timing off of a standard consumer OS is impossible.  You can improve it but never guarantee it.  To guarantee it, you need a "Real-time" OS, which is an option for LabVIEW but a bit complicated and I won't go into it more just now.

Second, why are you using this method to call a VI dynamically?  The "set control value, run VI, read control value" method is very rarely the correct thing to do.  Usually you want to do a "call by reference" node from the VI reference wire.

Third, when you run this with "wait until done" as False, you have a potential race condition where you don't know if the VI finished or not when you read back the control value.  Why isn't this True?

[altenbach]

So you are running VIs over the network and these VIs do hardware interactions via VISA and are expecting reproducible timing? No way!

If the time can be long as long as it always takes the same time, you can place appropriate waits to slow everything down to a common execution time.

[crossrulz]

---

@Kyle97330 wrote:

Second, why are you using this method to call a VI dynamically?  The "set control value, run VI, read control value" method is very rarely the correct thing to do.  Usually you want to do a "call by reference" node from the VI reference wire.

Third, when you run this with "wait until done" as False, you have a potential race condition where you don't know if the VI finished or not when you read back the control value.  Why isn't this True?

---

I would use the Start Asynchronous Call to run the VI.  (Asynchronously Calling VIs).

I'm concerned about what is happening in the called VI.  It seems to me that it should be done in a Queued Message Handler or similar setup so that is constantly running and then use a Queue for sending commands to the running VI and another Queue, a Notifier, or User Event to get the data whenever it is updated or requested.

[wesdeeg]

The VI in question was part of the software package provided with the piece of equipment, so it's not something I've looked into adjusting as of yet. Thanks to some of you for confirming that the timing will never be the same, I'll try to adjust it into a form for queued message handling, it's what the clock for our data triggers run by so it should be a more ideal form.

By switching to a constantly running vi however, would the same time requirements of the system to contact the VISA resource and send a command still apply, taking those 7-30 milliseconds, or would that connection being open allow the taken for that command to be negligible in comparison to the current time the VI takes?

[wesdeeg]

I should clarify that final question, the issue more specifically is determining what the cause of this time delay is. Would that delay be from the formation of the VISA resource contact, which could then be solved by keeping it running, or is it likely the act of sending in the command? If it is the latter, I will need to adjust the setup in either case to have some form of wait delay to properly set the time as altenbach suggested, though I'm not sure if it's possible to have dynamic wait times (the overall program needs to run this VI before starting a set of 5000 averages that takes about a half a minute, and we then this averaging is looped 500+ times, so adding in a much longer delay on the order of seconds might make it unfeasible to run).

[altenbach]

Assuming that the measurement values change at a relatively constant rate, another option would be to exactly timestamp every measurement from the various devices, then use interpolation to bring them all on the same time spacing.

Still, I think that entire setup needs to be redesigned from scratch. Currently, you are basically herding cats.

[crossrulz]

The biggest improvement you can make is to eliminate the initialization and closing in your repeatedly called VI.  Initialize the port before all of your loops and close it after all of your loops.

[wesdeeg]

I've been troubleshooting the asynchronous call node with some other issues, but primarily for the asynchronous call node, for some reason it cannot actually call the VI on the other machine, it merely gives out an error in the Open VI reference, and is unable to execute on the machine it is programmed to run to. Is there some other intermediary step I am missing in this scenario? I've compared to the available LabVIEW examples for the Start Asynchronous Call node, and I can't see any place where this would've gone wrong. Do I need to adjust the VI that is being called so that it can be run asynchronously? 

 

I've included the VI from the other computer as well for reference, in case there's something wrong with that aspect. I recognize much of the code could likely be improved in a lot of ways, but with a lot of various problems to be fixed I don't have time to perfect every component.