Transmitting Commands to Deployed VI via ANY Software

[KindlyAtlas]

Hi All,

I've been digging through NI KBs and forums for awhile now and I feel like I just have to reach out for ideas/help.

I'm working on a LabVIEW project (somewhat inherited) that operates independently on a cRIO device. For normal operations, the system is standalone-- it has a physical display, buttons, and I/O. However, we would like to add the ability to remotely control the system, as you would control a power supply or DMM over USB/COM -- just not over Serial.

A TCP Send/Receive structure is already set up in the project, including the various commands expected and what to respond when received. This was originally intended to communicate with an external VI on a connected PC, but now we'd like to remove that VI being a requirement. Ideally, a user could just pull up, say, PuTTY, open a connection to the cRIO, and send the same commands (and receive the same responses) the external VI would normally do.

I've found that this conversion may not be that simple. First, no real solid connection can be established with PuTTY, and then (say via Raw) commands just go nowhere with "Software caused connection abort". Then, nearly all support related to TCP connections appears to be about connecting a device to be controlled by LV. [I need the exact opposite]. I've seen a couple of custom Putty or SSH libraries pop up, but they appear to do the same thing - or they require a license, and I'd like to make sure that is the only route I can take to accomplish this. Many roads regarding this topic lead to Archived SSH, RAW, and TELNET Tools, but again, I'm trying to query the VI using these tools, not use these tools within the VI to query something else.

I'm mainly looking for help to:

• A way to intercept / issue the same commands on a PC via direct Ethernet and generic tools (PuTTY, etc.)
• An alternative that can format these commands for something that is able to do the same
• Generally maintain the structure that is there, avoiding complete reconstruction of master and sub VIs

This is part of a large lvproj so I can't include everything, but I've attached images of these VIs:

1. TCP Server
2. Send Message Parser (set to simple Get Version command)
3. Receive Message Parser (set to simple Get Version command)
4. TCPIP Loop DataRx from older VI <-> VI tool
5. TCPIP Loop DataTx from older VI <-> VI tool

Note: I can't necessarily comment on the "Whys" of everything in the VIs-- similar to the reasons why these have to be images.

Thank you for any help or ideas,

Kevin

[KindlyAtlas]

Partially bumping this topic, but by spilling some ideas that could hopefully spark someone else:

• Does anyone have an example of querying / commanding information from a VI (on another machine) via TCP and/or using PuTTY? 
• Since it is easy to SSH into the RT Linux shell, is it possible for the VI to read/write information to the shell, or a file in the shell filesystem, and a remote client can access that? Possibly live with some sort of port forwarding setup?
• This is all very similar to the operation/needs of a 'remote front panel', except a web-based application cannot be easily accessed via simple command interface. <The goal being that others can use the target/tool in their setup, however they want - like a remotely controlled PSU>

[KindlyAtlas]

I'm expanding this topic to: ANY advised methods of communicating with a deployed VI via Command Line Interface / non-NI software.

The archived "Telnet, SSH, etc." article [linked in original post] states that all of those utilities (generally, under the Internet Toolkit) were pulled by NI in 2014. However, the workarounds in that article appear to address only 'How to get LabVIEW to query / connect to another client machine', NOT the other way around.

So this topic really boils down to the above and following question. Does the pulling of that toolset mean that I can no longer communicate with an active VI (on a remote or otherwise connected) target without using NI utilities (another VI, MAX, etc.) or Remote Front Panel? I can't Serial, SSH, TCP, [any other general CLI] INTO a cRIO's primary VI to query variables or send commands? (As set up on / limited by the cRIO VI)

This would mean that though I can create a self-sufficient VI that can access "tools" via universal Comm protocols, I cannot make an LV-based tool that can be accessed in the same manner.

[GerdW]

Hi Atlas,

---

@KindlyAtlas wrote:

I'm expanding this topic to: ANY advised methods of communicating with a deployed VI via Command Line Interface / non-NI software.

---

You can use any kind of network communication (TCP, UDP) to communicate with that RTExe running on your cRIO!

I do this all the time with my cRIO applications: having a host computer sending UDP messages to the cRIO and reading the UDP responses of the cRIO. And yes: you need to implement that in your VIs…

[KindlyAtlas]

---

@GerdW wrote:

...having a host computer sending UDP messages to the cRIO and reading the UDP responses of the cRIO. 

---

What are you using on the host computer to send those UDP messages?

[GerdW]

Hi Atlas,

---

@KindlyAtlas wrote:

---

@GerdW wrote:

...having a host computer sending UDP messages to the cRIO and reading the UDP responses of the cRIO. 

---

What are you using on the host computer to send those UDP messages?

---

Most often its also LabVIEW, but that doesn't matter: you can send TCP/UDP messages to your cRIO using any tool you like!

[KindlyAtlas]

---

@GerdW wrote: Most often its also LabVIEW, but that doesn't matter: you can send TCP/UDP messages to your cRIO using any tool you like!

That's been the primary problem. The system was initially set up with 2 VIs (on separate machines) behaving as you're describing. But we'd like to remove one of those machines being a requirement.

In theory, I can just use any TCP tool (e.g. PuTTY; open to better alternatives) to send messages instead- but it's like talking to a wall. No connection, no responses. Almost as if LV is formatting messages in a way that general tools don't account for, and the TCP Tool gets spooked.

[GerdW]

Hi Atlas,

---

@KindlyAtlas wrote:

---

But we'd like to remove one of those machines being a requirement.

In theory, I can just use any TCP tool (e.g. PuTTY; open to better alternatives) to send messages instead- but it's like talking to a wall. No connection, no responses. Almost as if LV is formatting messages in a way that general tools don't account for, and the TCP Tool gets spooked.

---

You need to replace that one VI by a software/tool which outputs the same messages and is able to parse the responses in the same way as your VI does!

And no, LabVIEW does NOT "format messages in a weird way"…

[KindlyAtlas]

---

@GerdW wrote:

And no, LabVIEW does NOT "format messages in a weird way"…

---

So if LV doesn't "weirdly" format messages, shouldn't PuTTY be able to accomplish said task? (I'm guessing using a 'Raw' TCP connection)

Can you recommend an alternate tool that does this?

[GerdW]

Hi Atlas,

which kind of message do you want to send to your (cRIO) VI?

Does that VI know about these messages, i.e. did you implement your own TCP/UDP/whatever routines to handle the network communication?

Back to square 1:

---

@KindlyAtlas wrote:

A TCP Send/Receive structure is already set up in the project, including the various commands expected and what to respond when received. This was originally intended to communicate with an external VI on a connected PC, but now we'd like to remove that VI being a requirement.

Ideally, a user could just pull up, say, PuTTY, open a connection to the cRIO, and send the same commands (and receive the same responses) the external VI would normally do.

---

You need to send the very same messages as has been implemented in that special VI.

Mind to attach that VI?