fp read vs. fp network read; i/o point versus FP refnum...REPOST

[bob_miller]

I posted this in the LabVIEW forum inadvertantly; it probably belongs here:

I'll ask the second item first:

The online help for FP vis suggests that FP Create Tag and related vi's which
generate and/or employ FP refnum (a cluster of a server refnum and tag refnum)
are obsolete and the FP I/O Point  should be used instead.  Having discovered that
the FP Get Config vi now has a "get item list (long string)" function which generates
a string which matches an FP I/O Point, and that FP read will accept the string, I can
see my way toward rearranging my code to eliminate the use of FP refnums.

But do I really want to do this? Does the passing of a string (which must be parsed
and converted) to FP read versus a refnum add overhead which the latter didn't
require?  Is that overhead eliminated if I convert the string to an FP I/O Point prior
to entering my acquisition loop? The only way I knw to do this is to launder the
string through an FP read in initialization, a rather crufty approach). If the string is
not valid when passed to FP Read, what error do I get (this might be useful in an
embedded app to find LV items in my channel list not accessible via FP read)?

Now the first item:

Browsing through the Fieldpoint palette unearthed the "FP network read" vi. Hmmmmm.
This VI accepts a "URL" string which can include either fieldpoint paths  or LV published
items.  Does this work embedded on a cFP2020 for items published by the cFP2020? I'm
still looking for a wormhole to build an acquisition loop which can acquire both fieldpoint
and published items (published from the same fieldpoint)  whether it resides on a PC
connected to the fieldpoint or is embedded on the fieldpoint beside the publishing VI. Or
like FP read does this vi lose its ability to connect to published channels when it is
embedded on the cFP2020 (because it relies on the host-PC-resident FP server)?

How to build the URLs (which are hard paths versus tags) is tomorrow's problem...

A third question just popped into mind:

FP Get Configuration defaults to read the last .iak file saved in MAX when run on the
host and apparently to the ni-rt/system/fpbank.ini file when running embedded (this is
apparently the file MAX writes to the fieldpoint, not the .iak). But if I pass a hard path
to an .iak file to the Get Configuration vi, does it use this path when embedded (assuming
the path is valid because I manually copy the .iak there from the host)? And if I do so,
would FP Get Configuration return published channels in the list, even though FP Create
Tag and/or FP Read might not be able to resolve them in when embedded on the cFP2020?

Bob

[bob_miller]

Follow-up:

FP Read does indeed put out a nice recognizable error when passed an
invalid string. So  I should be able to trap on eror when it is passed a LV
item and branch to an alternate routine.

I tried embedding an .iak file with a LV item in it and pointing an embedded
FP get config at it, piping the channel list into FP read.  The LV item never made it
into the channel list, so I don't really know if FP get config read the .iak file I was
pointing to or went back and read the fpbank.ini file. I will have to do more
experimentation (e.g blowing away the fpbank.ini file)...

I realize the questions I have asked can generally be answered by experimentation,
but doing so necessarily involves shutting down my community water system. I would
therefore still appreciate some answers, even though it might appear I am just
being lazy

Bob

[e-Cash-Money]

Hello Bob,

Sorry it has taken me so long to reply, but there was a lot of stuff that you asked for that I needed to test out!

1) I don't think you have to launder the string through an initial FP Read in order to cast it into the FP I/O Point type.  I doubt you would see any performance increase if you did this.  I also think that the FP I/O Point constant is actually just a string with some extra name filtering, etc, so I don't think the type conversion is going to create that much overhead.  However, if you do notice a performance decrease, then you will have to launder the string through some FP function to cast it into the FP I/O Point type as you suggested.

2) I tested the FP Network Read on an embedded fieldpoint system and was succesfully able to read the LED value off of the same controller.

3) Based on your tests so far, it looks like the FP Get Config VI looks at the .ini file and not the hardcopy of the .iak file you copied onto the controller.  I would double-check to make sure that you have the correct file path for the embedded iak file.  If the file path is correct and FP Get Config doesn't return any of the different information that is in the iak file, I think it is safe to say that it will read from the ini file.