choosing a set point in an embedded fieldpoint FP2010 program

[euromata]

I have created an event based (sequence structure) program that controls a simple machine. I want the machine to be standalone, i.e.controlled by the FP2010 only and  not necessary to have the PC connected. Therefore I intend to embed the program and enable the vi to run on start-up. I have some push buttons connected to the FP module as digital inputs, in order  to control the machine on and machine off.

I would like to have the option of changing a pressure setpoint in the machine  i.e. an analogue voltage output from the FP module.

What method can I use to communicate to the FP 2010 when it is running an embedded program?

my concern is that if I can communicate with the FP module to change a setpoint and I loose the network connection, then will the fieldpoint program hang and stop my machine?.

I would appreciate any suggestions/comments

Thank you

[tst]

If you have analog input modules, you can connect a potentiometer to the FP, so you don't have to worry about communication.

If you still want communication, you can use TCP, which is very reliable if your network is OK. Search the example finder (Help>>Find Examples) for "TCP" and you will find several examples showing how to transfer data to and from a FP. You can also search the site for "TCP tutrials" for some more detailed explanations. Alternatively, you can use the RT Communication Wizard (Tools menu), which also uses TCP, but does the job for you.

In any case, the code should be written in such a way that if there is no communication, something happens (the machine stops, the setpoint goes back to a default, the setpoint remains at its last value, etc.). In any case, the communication loop should be seperate from the rest of your code, and that way the FP will not hang.

To learn more about LabVIEW, I suggest you try searching this site and google for LabVIEW tutorials. Here and here are a couple you can start with. You can also contact your local NI office and join one of their courses.
In addition, I suggest you read the LabVIEW style guide and the LabVIEW user manual (Help>>Search the LabVIEW Bookshelf).

[bob_miller]

I second the concept of a TCP connection running in an independent loop. I have implemented just
this in a cFP2020-controlled water plant. Obviously I don't want it to hang if someone kills the TCP
connection by unplugging a cable.

The TCP connection code should be able to listen for a connection, communicate when connected,
and detect (via timeout and/or sanity checks on the data transferred) when the connection is broken
and go back to listen mode and start over. This loop can communicate values to and from the rest of
your program via global vis and such. It is also best if your controls are "events" (in the conceptual
sense), that is, instead of an analog control which the connection constantly polls, use the control with
a button which says "load this value".  Instead of a static on/off switch, use two buttons, "on" and "off".
In short, make every command communication possible without the RT host having to poll the state
of the client's controls; the client sends commands (and values) to the host only when there is something
to change. That way, the host interprets no connection as "steady as she goes", which I think is what
you want. Of course, you could branch to an alarm state if you detect a broken TCP connection. I dont.
Like you, I want the RT box to just keep running -- and I have a "monitor" vi running on the cFP whose
only job is to make sure the mission-critical vi is alive and well, and kill and restart it if it isn't.

My current TCP connection loops, built off of the NI-supplied examples, support multiple TCP
clients, any of which can come and go at will. One client runs on an ethernet-connected PC in the
plant; another can be connected (via the PC) via dial-up modem. It all works very reliably -- I have
dialed in from the beach at Ocracoke, NC, checked some values, changed some settings, left a message
for the operator on duty -- all via the LabVIEW applications -- hung up, and gone back to worrying
about which SPF to use. The embedded code has been running for about six months now without
problems.

If I can figure out how to post a pair of stripped-down VIs with the RT host and the client code I will, but
the NI TCP communication examples are actually a great place to start -- that's what I did.

Bob

[Khalid]

Hi Bob and Tst,

I am just curious... none of you mentioned the built-in watchdog feature of FieldPoint.  Do you not use it?  Or use it only as a last resort to take the outputs to a safe state? 

Thanks,

-Khalid

[tst]

Yes.

I view the watchdog as something which is only supposed to kick in if something has gone wrong with the program. As long as the program is running correctly (even if there is no communication), I would prefer handling everything myself. Luckily, handling communication like Bob described is fairly easy.

[euromata]

Thanks tst

using another input channel on the module is not an option, thanks for the input

I will investigate the use of the TCP vi's, and thanks for the tips

Thanks Bob your techniques for the water plant program are exactly what I need to implement, plenty of food for thought there

Time to get stuck into some programming

[bob_miller]

---

@Khalid wrote:

I am just curious... none of you mentioned the built-in watchdog feature of FieldPoint.  Do you not use it?  Or use it only as a last resort to take the outputs to a safe state? 

---

When I originally architected the program, I considered using the watchdog feature for this and chose not to. The reason was simple: I wanted it to be
OK to power off (or crash) the PC, unplug the network, etc. This implies no "mission critical" communication occurs over the Ethernet; there really
should be nothing for the embedded watchdog to do if the connection fails.

The idea for the monitor VI came from the NI example "Redundant data logger", though the uses for the monitor have changed substantially from that
example's original purpose - its code's origin is now almost completely unrecognizable.  It is possible that the embedded watchdog could have been
employed instead, but I simply didn't pursue it further.

[Aside: I do not use the PC to host the front panel for the cFP-embedded RT VI; the PC runs its own client VI which communicates to the embedded VI
via the TCP connection we are discussing, reflecting everything to its own front panel. This allows me to put lots of compute and memory-intensive
code on the PC (such as trend plots, database management and report generation) without cluttering or loading down the fieldpoint code.]

Actually, I am working on installing a remote fieldpoint node on the other side of a rs-485 bus and plan to employ the watchdog embedded in the
remote FP1001 node to put all equipment there in "safe" mode if the local node or the link goes down. No embedded VI can run on this "dumb"
unit, so the embedded watchdog is a needed feature there. Whether the embedded watchdog is ever employed at the local end of the bus is doubtful; I'm
not sure it can be configured to "watch" COM4. It is probably more straightforward to add any additional needed "watchdogging" to the monitor VI
and/or make the main mission-critical VI do the right thing if communication to the remote node goes south. I may well employ the "watchdog VIs"
(something else entirely) for this.

Bob

P.S. I really will try to post some example code, but I am not posting from my LabVIEW development system so I can't get there from here at the moment.

[Aaron_G]

Euromata,

Instead of the TCP VIs, you can use the PublishData.vi, located in NI Measurements>>FieldPoint>>FieldPoint RT palette. The PublishData.vi allows you to Publish a Read Only or Read/Write item. This item shows up as an additional channel under the [c]FP-2xxx module when the embedded program is running.

This simplifies your programming as you can create a channel called SetPoint as a Read/Write item. In your embedded code, you use the PublishData.vi (high level) or Read Publish Data.vi (low level), to read the current setpoint. This setpoint is cached locally and can be pre-initalized as part of your program. It will always be available to be read (embedded), and a client can connect, change it and disconnect without any programming required in your embedded program to handle the client. The client can connect using either a FieldPoint Write VI or DataSocket VI with Logos URL. The DataPublish.vi (and underlying technology) assume that the FieldPoint unit is a server and there is no negative effect when a client is disconnected. The DataPublish.vi (high level) supports a Timeout value that can be set to 0 (always Read immediately) or be a non-zero value (waits for a change of the value). If you use a timeout, then a loss of communications would stall your program by the timeout time, but if you set it to 0, loss of communications will have no effect.

Regards,

Aaron