Config Action Engine Fails (always worked before?)

[NIquist]

I have used an Action Engine to write and read config files in many apps.  Now for some reason my config refnum is bad when I switch to a new action.  The refnum goes bad after traversing the shift register.  I probe it and the number looks fine but the Not A Config Data Refnum.vi reports that it's bad and when I try to write to the opened file I get Error #1.  I even tried old code that is running fine in old test systems but it fails now in my dev system.  The VI is not re-entrant.  I'm stumped.  

I created a simplified version that illustrates the issue (attached).  Any ideas what might have gone wrong???

Win7 64-bit

LabVIEW 2013 32-bit Professional Development

EDIT:  My config file is C:\ConfigTester.ini

[Hooovahh]

Can you demonstrate the problem?  I don't see any reason that the reference would turn bad.  If your code is some how closing that reference you may get a problem but it looks like your code has no way of closing it at all, with is a different problem.

The VI re-entrent-ness looks good on that VI.

[Bob_Schor]

I ran this in LabVIEW 2014 (I can also try 2013 if you want).  I put E:\ConfigTst.ini in the Config Path box, and it ran fine, creating the .ini file with nothing in it.  Running it again also worked, with no indicators lit.  (I use E: as my "scratch" drive).

Is this the expected behavior?

Bob Schor

[Bob_Schor]

I just check with 2013, also seems to work without activating Front Panel indicators.

BS

[NIquist]

Thanks for the reply. 

The code I posted is just a stripped down version of my normal conguration data action engine.  My real code hase a "quit" state that closes the ref.

You can create an ini file yourself by specifying a filename (e.g: C:\configtest.ini) and then selecting 'open' and run it.  You'll see that the not a config data refnum (open) indicator stays off showing the the ini file is valid right after it's opened (it's checked in the open case).  Then, select 'check' and run it again.  You'll see the not a config data refnum (check) indicator turns on showing that the refnum is now invalid even though it should have retained its state through the shift register which is not initialized outside the loop.  Further, if you then select 'write' you should get an error #1 which seems to say that the filename or path is invalid but there's nothing invalid about C:\ConfigTester.ini (AFAIK).  

The ini file you specify IS created.  I made sure it wasn't read-only or anything.  The config VIs simply won't write to it when used in an Action Engine.  If I string all the functions wired straight through (no AE) they work fine with no errors.  

[NIquist]

---

@Bob_Schor wrote:

I ran this in LabVIEW 2014 (I can also try 2013 if you want).  I put E:\ConfigTst.ini in the Config Path box, and it ran fine, creating the .ini file with nothing in it.  Running it again also worked, with no indicators lit.  (I use E: as my "scratch" drive).

Is this the expected behavior?

Bob Schor

---

Hi Bob,

Did you run in this order:  open > check > write ???  If so what it should do is create a new INI file (the top LED stays OFF), check the file (the bottom LED should still stay off), and then after the write you should have new entries in your E:\ConfigTst.ini file.  That is what it should do but doesn't do for me but I can't fathom what my PC might be doing differently that could cause this behavior.

Thanks for taking time to try it for me!

[crossrulz · Accepted solution]

---

@NIquist wrote:

Then, select 'check' and run it again.

---

Well, that is one issue.  If you are just running the AE, then the reference will sort of be closed due to the AE and all of its callers (which are none here) have stopped running.  Therefore, the reference goes invalid.  Make another VI that calls the AE and performs these tests sequencially and see what happens.

[VItan]

I believe that the problem is the top level VI owning the queue reference went idle, causing LabVIEW to release the queue, causing the reference to become invalid.

If you look inside of those LVConfig VI's, it actually uses a queue to store the file info, and typecasts the queue's reference to the config file refnum.

If you run your AE manually and open, it works fine.  However, then it goes idle and the all VI's with the queue reference are now idle, so LabVIEW releases it.  However, your refnum still exists, but when you ask to check elements in the queue (which you are doing with the LVConfig check VI), it returns the error that the queue ref is invalid.

I am able to run the AE in a top level caller that does not go idle and have no problem.

Edit: Similar issue was discussed about a month ago here.

[AKA_TG]

AS others have said

One thing about AE's is that they are just VI's

So if the caller goes idle LabVIEW will close all resources in the AE, including any references.

This also happens when you run the AE by itself without a caller, although certain references can stay open from one execution to the next.The thing is LabVIEW always removes references from memory once it establishes they are no longer needed. Its something to be aware of when stuff like this happens.

[NIquist]

 DERP!  

Uhg, I so often use AEs to manually step through actions to test functionality I totally forgot that in this case the refnum wouldn't persist without a MAIN VI running.  I strung the functions together as subVIs in a MAIN.vi and it worked as expected.  Thanks crossrulz and Vitan.     Kudos for all...