LabVIEW
Some questions about memory control
Solved!
I have found some problem while using memory control, when I use VI reference to run the VI that creates the data memory and then when I use the same method to fetch the data from the memory, it shows an error that the data reference is invalid, how can I solve this problem.
Hi,
@Wlison wrote:
I have found some problem while using memory control, when I use VI reference to run the VI that creates the data memory and then when I use the same method to fetch the data from the memory, it shows an error that the data reference is invalid, how can I solve this problem.
The problem is created by your dynamic VI calls! When a VI stops (as can be seen for the DataGeneration VI) all it's references are closed (including the DVR) to allow removal of the VI from memory.
When you run the next VI (dynamically) it tries to access a DVR that is already cleared/killed…
Possible solutions:
- Don't call those subVIs dynamically, but by placing them in your main VI. So they are kept in memory as long as their calling VI stays in memory!
- Don't use globals to store DVR references. Use wires to send data from one VI to the next.
@Wlison wrote:
Do you encounter a similar problem with the dynamic call to the VI used in TestStand, especially since instruments using the LAN interface need to create and close the network connection every time.
Yes that is a common problem when trying to interface to LabVIEW test adapters. The solution is usually to store the information to initialize the object and use that to initialize the refnum object with each test step again. If that is to cumbersome since the initialization takes way to long you have to start up a service thread (a VI keeping running in a loop until it is told to stop) as pre sequence step, then send it a shutdown command at the end of your sequence.
@Wlison wrote:
Do you think this is an issue that needs to be improved? Or do you think it's a problem. This problem makes editing sequence files more difficult and harder to read!
It's a bit extra cumbersome but not that much of a problem in my eyes. Changing the refnum lifetime handling in LabVIEW is a complete no-go. To many things could potentially break because of such a chance.
I'm not even sure if TestStand has a separate parallel pre-load setting for a test step. It's about 10 years ago that I last worked significantly in TestStand.
As already mentioned it would work if it was a normal sub-vi. So, why, are you using the dynamic route? It's just messier and more code. What are you trying to achieve?
This is a good question, my current work is to develop a test sequence editor to be used in place of TestStand, the way to run the VI in the test execution engine is to call it dynamically, and so far I've had good results!
I discovered this problem during testing, and the best solution so far is to create a service thread as Rolf Kalbermatter mentioned above, and have the lifecycle of this service thread cover the entire sequence.
Then it makes sense. 🙂
Keep such data in the sequencer, then you can e.g. send and recieve data through events or a queue. You can wire relevant queues/events as inputs to the VI's you start dynamically or obtain them by name (which is less recommended).
