Expanding cFP-2020-embedded data logger/controller to access remote FP bank via RS-485

[bob_miller]

I currently have a nicely functioning home-built SCADA application running embedded
on a cFP-2020. The application was built from a starting point of the NI example
"Redundant Data Logger Example",  and still employs the "Get FP Configuration" vi,
the "FP Open" vi  and the ""Create FP Tags" vi to initialize the logger to find all channels
configured through MAX in the .iak file, and generate refnums to pass to the logger
and controller loops, which employ "FP Read" and FP Write" vi's to perform all I/O.  The
aforementioned example is still accessible on the NI site.

I now need to expand the application to be able to access channels which are implemented
at a remote FP node which is on the other side of the cFP-2020's RS-485 (COM4) port. I
have done a fair amount of searching of the NI site and have gleaned that MAX, FP read
and FP write by themselves don't support access to such remote FP banks (or at least
didn't -- most of the articles I've read are old and say "not supported yet"). References to
"Optomux vi's" crop up but I have uncovered no clear advice. I know it can be done; exactly
how is murky.

I can probably stumble around for an indeterminate period of time and arrive at a solution,
but I would greatly appreciate some concise advice to get me started. It would be very easy
at this point to arrive at a functional but tortuous method of accessing these channels the
employment of which would wreak havoc on the generally clean architecture of the existing
application. I do not pretend to be an expert on the low-level details of FP I/O, having been
content to stand on the shoulders of giants, so please be compassionate ;-)...

Bob

[bob_miller]

As usual, I've been continuing to try to solve my own problem after posting to this
forum...I'm an impatient bloke...

I have wandered into the "publish data" vi examples. These seem to suggest that I can
build an independent server vi running on my cFP2020 which makes data ( which I
access via whatever arcane means ) available to MAX and the .iak configuration file, and
from there to the standard FP I/O vis in my existing embedded SCADA application. This at least
solves my concern about trashing the architecture of that painstakingly built application.

Now what remains is how to adapt the server to access my remote channels, which are
two dual-channel modules (one AI and one DO) on a FP-TB-10 attached to a FP1000
hanging on the cFP2020's RS-485 port. I assume this is where programming with optomux
VI's comes in. Pointers to good existing examples are desperately solicited...;-)

Bob

[bob_miller]

Responding to my own post again...

A search of  the DZ for "optomux FP-TB-10" uncovered some examples

in LV6.1 for reading and writing a FP100x through a com port of a (c)FP20xx.

These vis were thoroughly broken when opened in LV7.1, but once repaired (with

VISA-enabled vi's) worked nicely as advertised.

Along the way I discovered that the RX wires of the cFP2020's interface are indeed

biased. The TX wires are not, but the bus is working OK (for now) with no additional

biasing. If this remains the case when I move the remote FP node 2000 feet away, I

will dispense with biasing to preserve the isolation of the interface.

I also found a "Publish LabVIEW Items (client/server)" vi pair in the examples. These

seem to present some problems. First, I'm not sure the server is fully functional, as it

contains no loop to calculate and publish the "read-only" item (tank level). The other

problem is more severe and is the current difficulty:

It appears from both the instructions on the client VI (and in the behavior when I actually

tried it anyway) that the "publish data" vis make the information published available to

MAX. I was able to find the new items, save the .iak file, and use FP read and FP write

to access the items in a client vi running on the "host PC". However, I really want to access these

items from a client vi also running embedded on the fp20xx. The published LabVIEW items

did not appear in the I/O browser control when the vi was running on the fieldpoint, even

though I was careful to save the augmented .iak file in MAX (both to the host and the fieldpoint) .

What gives? Am I trying to do something I simply can't do? Adding to my confusion is a

healthy dose of murkiness in what exactly th "publish" vi's are doing for me. Or perhaps the

problem relates to the defect in the server (it only runs for a moment) or how I launch the

client on the fieldpoint....

Bob

[Aaron_G]

Bob,

You can access items published using the Publish Data.vi from an embedded program by using the Publish Data.vi. The FieldPoint VIs (read/write) work differently on a host system (calling into the FP Server) than on an embedded system (directly accessing the inter-module communication bus).

The Publish Data.vi allows you to create Read Only (read/write to by embedded code, read only from MAX), or Read/Write items (read/write by embedded and MAX). The VI also allows you to either read or write the item. Thus if you were creating an item to facilitate exchange of data from a computer, you could write to it from the computer (using FP Write) and read it using Publish Data. Your program will need to call Publish Data.vi to create each item at the start of the program.

Once a Data Publish item is created, it will exist with it's last value until either a) controller is rebooted or b) Data Publish is called with the action set to destroy.

Regards,

Aaron

[bob_miller]

So does this mean I can't access items published from one embedded program from another embedded program by using FP read/write?
Or more fundamentally, there is no single access mechanism which I can employ in my embedded logger which from the outside looks
the same for read/write of a local channel  (e.g FP Read) versus a channel out on the rs-485 bus (optomux or ReadPublish Data)? Yet
there is such a mechanism (FP read) if my logger is running on the host PC? <Expletive deleted>

This is extremely unfortunate if true because it means I must rewrite the FP-read/write-based acquisiton loop in my logger to be
able to distinguish between items which are accessible by FP r/w  and those items which arent. Even worse, the logger currently
initializes and determines the configured channels available to it by reading the embedded .iak file. If the published channels are not
available there,  I must hard-code them; indeed, I will probably have to hard-code all channels -- my program's architecture comes
crashing down in flames. It will be more straightforward for me to embed the optomux I/O  routines directly into my acquisition loops
and dispense with publish data routines completely!! How I will identify and create tags for these remote items is a total mystery to me
at this moment, but its sure to be a bag on the side of the program.

I probably don't really appreciate what's going on under the hood of the publish data mechanism, but it seems obvious to make the
mechanism work for an embedded client as well as a remote one; after all, FP read and write "appear to" work that way for local
channels! Or perhaps a "FP R/WEverythingDammit" vi which employs the FP server (does this reside on the FP?)  to find stuff that
doesn't map to the intermodule bus.

Thanks Aaron. I'm not a happy wireworker at this moment, but I appreciate your clarification -- I won't abuse the messenger!

Bob

[Ryan_V[DE]]

Bob,

Aaron is correct. Perhaps you could implement your desired functionality by connecting the FP-1000 to the host PC, rather than the 2020. If this is not an option, you'll need to use the Optomux VIs on the 2020 embedded application. Unfortunately, this will mean restructuring your code. I hate to be the bearer of bad news... Good luck!

[bob_miller]

I posted a carefully crafted response which the NI website ate upon submission because
authentification failed. Thanks for your help; if I come up with an elegant solution I will
post it. In the meantime I will be playing with how to architect a mechanism which I hope will
not be as crufty as I fear.  It will probably involve an embedded vi to access and publish
the remote channels with a "side door" for other embedded applications. These will need to have a
wrapper built around their acquisition loops to branch to a side-door routine when passed
a channel which isn't implemented in the fpbank.ini file (what MAX writes to the fieldpoint
when it saves the .ini file on the PC and which embedded FP access dlls apparently read
instead of an .iak file when the calling vi is embedded).

Bob