From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Error 1 Configuration VIs while Passing Refnum through Shift Register on Mac
Solved!
All,
I am using LabVIEW 2013 SP1 with Mac OS X (Mavericks). I have a simple shift register VI that initializes a .ini file, reads/writes, and closes. I've done this plenty times on windows with no problem. I wrote a quick VI on Mac and I get Error 1. I can't figure out what the problem is. I am attaching my VI. Can somebody shed light on this issue please?
Check this.
In your VI, There is no Shift Registers for Cases. I think you missed to add State Machine for Case Selector.
Munna232,
The goal there isn't be be a state machine. That VI is meant to be an Action Engine. As long as the Initialize is done before any Read or Write, it should work fine.
Also watch for anybody accidentally closing the file on you. That is one of the dangers of use Action Engines.
Thanks guys.
This action engine creates a .INI file if there is none found. And if you try to close it, it still gives ERR 1. It somehow seems that if you pass the refnum through shift register it gives this ERR. If you wire them all in a sequence, it works OK. Any thing to try ?
When I have this VI as a part of the top level VI, this problem doesnt happen. It almost seems like when I run it standalone, the file refnum is released -- weird but that's what is going on.
@winterishere8 wrote:
When I have this VI as a part of the top level VI, this problem doesnt happen. It almost seems like when I run it standalone, the file refnum is released -- weird but that's what is going on.
I have seen that on Windows as well. The AE only really works well if there is a calling VI to keep it memory. I thought you were having issues with it with a calling VI. What you describe here makes sense.
@crossrulz wrote:
@winterishere8 wrote:
When I have this VI as a part of the top level VI, this problem doesnt happen. It almost seems like when I run it standalone, the file refnum is released -- weird but that's what is going on.
I have seen that on Windows as well. The AE only really works well if there is a calling VI to keep it memory. I thought you were having issues with it with a calling VI. What you describe here makes sense.
Keeping the AE in memory is not enough! The Top Level VI in whose hierarchy the Open Config case is executed needs to stay active (eg. not going idle) for as long as you want the open configuration to stay valid. The underlying object where the configuration information is stored in is a queue and that is a refnum like any other refnum in LabVIEW. And all real refnums in LabVIEW (except optionally the VISA ones) will be closed as soon as the top level VI in whose hierarchy the refnum was created/opened goes idle (stops executing).
@rolfk wrote:
Keeping the AE in memory is not enough! The Top Level VI in whose hierarchy the Open Config case is executed needs to stay active (eg. not going idle) for as long as you want the open configuration to stay valid. The underlying object where the configuration information is stored in is a queue and that is a refnum like any other refnum in LabVIEW. And all real refnums in LabVIEW (except optionally the VISA ones) will be closed as soon as the top level VI in whose hierarchy the refnum was created/opened goes idle (stops executing).
Actually even with VISA, "User Data" is lost when the caller goes idle although, VISA will automatically re-open a session identical to the previous session for that alias. Just "User data" isn't preserved in the session history. Ditto for DAQmx, last session information is externally stored and retrieved (The lookup is by string- so you can coerce a string to VISA Alias or DAQmx I/O container.) the "Session histoy sticks around as long as the VI is in memory. A trick I learned with an init all vi call in a TestStand sequence Pre-UUT loop and a model that unloaded the modules when complete. (I recall I just opened the VI FP "Hidden" as a work around)
Most NI-Drivers (NI-DMM, NI-Scope etc...) also have this external since really they all use "VISA" down deep (an oversimplification but a good rule of thumb)
THE EXCEPTION: Software defined instruments. These act like file refnums and become invalid when the top level vi goes idle. Its the FPGA refnum that dies the sudden death on the "Legacy" drivers. I have not played with "RFmx" and wouldn't mind learning what happens in there.
And just too really turn it all on its head, There is an LabVIEW Configuration option to "Automatically Close VISA Sessions." Check that box and the external VISA storage is tossed under the bus so all those sessions you stored on a USR go invalid as soon as the Top Level goes idle
Some days that can really bug you
