Solution
This behavior is expected in LabVIEW because of how reference lifetimes are managed in memory.
Understanding Reference Lifetime vs. Static Data
If you store a static data type (such as a cluster, array, numeric, or string) in an uninitialized shift register, LabVIEW retains that data in memory as long as the calling application remains loaded in memory. If you stop the top-level VI and run it again, the uninitialized shift register still contains the last written values.
However, references (such as VI references, queue references, user events, or file refnums) are not the actual data; they are temporary pointer addresses pointing to memory blocks allocated by the LabVIEW execution engine.References are bound to the lifetime of the top-level VI that initially executed and created them. When that top-level caller VI finishes running or is stopped, LabVIEW automatically disposes of those memory blocks and invalidates the pointers.
While the uninitialized shift register in your FGV successfully stores the address value of the reference, the memory block it pointed to no longer exists. The next time you run your application and read the reference from the FGV, you are reading a pointer to a released memory location, which results in Error 1026.
To ensure references remain valid when using FGVs, implement one of the following design approaches:
-
Keep the Creator VI Running
Do not stop or abort the VI that initially called the Open VI Reference function (or created the queue, file, etc.) until you are completely finished using the reference. Keep it active in the background, or keep the top-level application running continuously.
-
Initialize References at the Top-Level VI
Create the reference at your application's top-level VI (the main execution loop) and store it in the FGV during the application's initialization phase. Because the top-level VI runs throughout the duration of your application, the reference remains valid across all subVIs until the application is closed.