NaN/PathRefnum? function producing useless answers for Path, Refnum

[camerond]

I have found similar threads to this, but not quite the same, AFAICT.

I'm trying simply to see if an INI file exists, so I created the following snippet:

I also created a small file, put it in my C:\ directory, which I have attached here.

When I run the LV program with C:\test.ini, my indicators come out as NaN/Path?: False, NaN/Refnum?: True

which I tried to interpret as (1) a valid path (file exists) and (2) a nonexisting refnum (although the refnum came from an LV-supplied subVI).

I then changed the control (file to find) to C:\test.in (lopped off final "i") and the two indicators gave me the same results. That blew away my first interpretation, and I can't come up with anything else which makes sense.

So, for paths and refnums, what is going on here, if anything?

I did see that the second test threw an error from the "Open Config Data" subVI, so I can use that for my test, but I'd like to know if the NaN... function is actually good for anything but numbers. If not, IMHO LV should change its designation on the palette.

Cameron

[1984]

As far as I am concerned your interpretation is not correct. That VI simply determines if the data you drive to input is NaN or so.

So if you drive an empty path constant or a non existent path, then it still will give you FALSE.

But lets say you divide a number with zero and drive that to the input gives you TRUE, since the result of the division is not a number.

Not sure if my explanation it makes sense. The "not a path" and the "not a refnum" constants can be used as an output if an error occured. I am not aware of any other use of them.

Use the "Check if file or folder exist" to check the path.

[dan_u]

The NaN/Path will only indicate if it's a path. C:\test.ini and C:\test.in are both valid paths. It doesn't check for a file at that location. You'd have to use "File/Directory Info" or some other function to see if a file is actually at that path.

<Not a Path> is a special switch of a LV path control. It may be set by a function, for instance when trying to open a file which does not exist.

[camerond]

Yes, 1984, I said my interpretation was obviously wrong. "[In a second test] the two indicators gave me the same results. That blew away my first interpretation."

I just want to find out what is actually going on. The path was supposedly a valid one, but the refnum invalid. I don't care about the number function, I know it works.

Is the LV subVI yielding invalid refnums? I can use them in a program and they work, but sticking up an indicator on the FP just gives me an empty white dog-eared square, which tells me nothing.

I know there are other ways to get around this (I mentioned one, you mentioned one), but I want to understand what is happening, so I can use it or not as conditions warrant.

Cameron

[AKA_TG]

I agree camerond.

On LV2010 the function clearly signals an invalid reference when it fact it is fine.

Why is the function claiming to provide info on the refnum when it obviously is not correct?

I guess Ill read the help file really really hard!

Maybe I missed something too.

[AKA_TG]

btw it does work correctly if you are using LV file I/O functions

Just not for the ini functions.

 Further looking reeveal that ini function uses a queue and typast this to a refnum.

Ini functions do not give you an actual reference number This is encapsulated away.

In fact ini functionality is actually in queues and very little file IO is done.

wow who nkew!

[altenbach]

---

camerond wrote:

I'm trying simply to see if an INI file exists, so I created the following snippet:

---

The right way would be to use this function... Check if File or Folder Exists VI. No need to create your own. 

[0utlaw]

Hi CameronD,

After taking a look at the VIs in question (they're unlocked and the low-level functions are located in NI_LVConfig.lvlib, I'd suggest digging into them a bit if you want to know how they work), it appears that the refnum type used is actually a datalog file refnum as detailed here:

LabVIEW Help: Types of Refnum Controls

http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/types_of_refnum_controls/

This appears to be a bitpacked cluster rather than an actual reference to a location in memory- the file itself is in fact read and closed in Open Config Data.vi

Because of this, it looks as though a separate function (Not A Config Data Refnum.vi) was provided in the config file palette. 

Also- have you attempted using the Check if File or Folder Exists VI?  As others have mentioned, the NAN/Path/Refnum primitive will return False if the path is a potential valid location on this computer.

I agree that the fact that the NAN/Path/Refnum doesn't "break" when a datalog reference is provided is unintuitive.

Regards,

[nathand · Accepted solution]

You're running into a confusing quirk of LabVIEW refnums. For checking if a configuration file refnum is valid, you should use "Not a Config Data Refnum.vi" from the Configuration File VIs palette. The "NaN/Path/Refnum?" function works only for refnum types that are built into LabVIEW, such as queues, TCP sockets, and file references. The configuration file VIs are built in LabVIEW, rather than built into LabVIEW, and the refnums they use aren't "real" refnums so far as LabVIEW is concerned, they're just data wrapped up as a datalog reference (a trick for creating unique pseudo-refnum types). You'll see several other palettes that likewise include their own functions to check whether a refnum is valid, such as the semaphore and rendezvous palettes.

[camerond]

Thanks, Nathand,

That clears it up a lot (and then digging down into the layers below the "Open Config Data" VI brings back the opacity). That's just one of the things which has confused me about the Config File VIs subpalette, but the explanation and the fact that you have to use a special "Not a Config Data Refnum.vi" with these instead of the normal "NaN/Path/Refnum?" (I never saw it until you pointed it out) answers several of the other questions, too. Like I said at first, in this case I just wanted to see if the file was there, so there are alternatives. But when I need to do more than what the prepackaged VIs do (which I expect I will), then it's just a matter of digging down in with my hip boots on. (Yuck.) But it's all fun, or I wouldn't be doing it in the first place.

Cameron