Two-way command-line communication with Labview 2011 RT Application

[ch.pi3]

Hello everyone,

I have a 2011 LabVIEW Real-Time application that I want to deploy on a PXIe-8100 for data acquisition. The application is a state machine whose functions I'd like to control via command line (over ethernet) on a remote computer. Essentially, I'm wanting to implement a two-way communication with the RT application using command line. Ideally I'd like to write a SCPI dictionary on the RT application such that I can type in a user-defined command on my computer's command line, have it be sent to the RT application, have the RT application parse the command, do whatever I had commanded it to do, and finally send me back a response.

From the research I've done so far, it seems like using Telnet might be the most promising for this (I tried to get this to work, but had minimal success, however). Other options might include using the "Open Application Reference.vi" along with a property node.

If anyone has any insight as to how this might be best approached, I'd very much appreciate your advice.

[Blokk]

If you really want the command line option, I would try the development in the following way (but I think it would be just easier to host a Remote Front Panel on the real-time target, and you can access it just using a simple browser + silverlight  http://digital.ni.com/public.nsf/allkb/AB6C6841486E84EA862576C8005A0C26 😞

1. You need to create a TCP/IP Listener (or server) in a parallel while loop in your target VI. You could set some sane timeout value, and handle the error. In this way this TCP server is always waiting for a client to connect.
2. Create a project under Windows with a VI which can Open up a TCP/IP connection toward the server. This VI would only run once: first it would build up a connection, then send a pure string with some termination character which will be recognized on the RT server side. After this check if the VI running under the Runtime Engine, if so, close it.
3. Create en EXE out from your client VI which can be called from command line with string arguments. These arguments will be your "SCPI" commands to communicate with the RT target. Here is an example for such EXE: https://decibel.ni.com/content/docs/DOC-10281

You could even set up a second argument as the IP address of your RT target, so this single command line application could send commands to different RTs if you have multiple on your local network.

Of course, you need to create some internal communication for getting the parsed command into your main RT while loop with that State Machine. I imagine you could use a Queued State Machine for your main while loop, and when a command comes, you insert the required state in front of the Queue in your TCP/IP server loop (priority msg).

Try to make your project, and if you see problems just attach your VIs here so people can help you.

Edit: if you need to get a response, then place a TCP Read function in your Client VI which will wait for the response sent from the Server...Then you can print the result back to command line...

Edit2: also check these:

http://forums.ni.com/t5/LabVIEW/Write-to-STDOUT-from-Labview-EXE-Ran-from-Console/m-p/3297020/highli...

http://www.notatamelion.com/2016/05/05/aint-misbehavin-thanks-to-external-calls/

[Bob_Schor]

Do you know how the Queued Message Handler works?  There's a concept of a Message, a cluster having a "Msg" part (which can be a string "message" or an e-num "state") and a "Data" part, a variant in case (for a particular "message") some data needs to be passed.

I built both my Host and Remote programs around the Queued Message Handler.  I then set up a pair of Network Streams that I used to send Messages from Host to Remote, and from Remote to Host.

Think of a "Message" as a "Command".  Normally, the Host sends Commands to itself ("Initialize", "Create Data Files", "Start Recording"), and similarly the Remote also sends Commands to itself.  Now suppose the Host wants to send a "Start Recording" command to the Remote.  Instead of putting it in the Host's Message Queue, it sends it via a Network Stream to the Remote.  The Remote has a "Listen for Messages" loop running in parallel with everything else it is doing, and if a Message from the Host shows up, it is placed on the Remote's Message Queue.

So the Host (perhaps in response to a Button Press) wants to tell the Remote to "Start Recording".  It sends a "Start Recording" message (with optional parameters, if appropriate) to the Remote via the Network Stream.  The Remote gets it, puts it on its own Message Queue, which causes it to start processing the "Start Recording" Message.

That's how the Host tells the Remote what to do.  The Remote, in turn, can send results back to the Host by having a Remote-to-Host Network Stream for Messages.  Suppose the Remote starts recording (because the Host told it to do so), and suppose it is supposed to take in 1000 points and then stop.  When it stops, it can send a "Recording Done" Message to the Host through its Network Stream, and potentially even include (as the Data Parameter of the Message) the 1000 points.  The Host has its own "Listen for Messages from Remote", and when one occurs, it packages it up and puts it on its Message Queue, where it is processed.

Network Streams are (now) a fairly robust communication mechanism in LabVIEW, and reasonably fast (besides the two Message Streams, I was also using a Network Stream to send 16-24 channels of 1KHz sampled data from the Remote to the Host, where they were then streamed to disk).

Bob Schor