Transmitting Commands or Queries over TCP from PC TO cRIO RT Host

[KindlyAtlas]

---

@GerdW wrote:

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?

Mind to attach that VI?

---

GerdW,

In short, yes, the main VI architecture includes subVIs that serve as a TCP server and message parser, so it knows that [in a certain "Remote" mode] it should be open to and be able to read commands received over that line.

The TCP comm portions of the Server, Message Receive + Send Parsers are attached in the original post. [JPGs] I also attached similar portions of what used to be the client VI - the one we're trying to replace. (I don't put too much weight on the client VIs)

For context, I believe across most images, the case structure 'state's are set to "GET:VER" or "DO:CAL" -- some of the easier commands that just query the HW S/N, or initiate a self-calibrate, respectively.

-I'm sorry I can't attach actual / full VIs due to IP & security reasons, however if there is a referenced or missing portion that needs definition or clarification, let me know and I'll see if I can get that up as well.

[GerdW]

Hi Atlas,

---

@KindlyAtlas wrote:

The TCP comm portions of the Server, Message Receive + Send Parsers are attached in the original post. [JPGs] I also attached similar portions of what used to be the client VI - the one we're trying to replace. (I don't put too much weight on the client VIs)

For context, I believe across most images, the case structure 'state's are set to "GET:VER" or "DO:CAL" -- some of the easier commands that just query the HW S/N, or initiate a self-calibrate, respectively.

---

Sorry, I usually don't care about images of code…

Did you try to send the exact same byte stream/array using Putty (or whatever) to your cRIO as you do in this VI?

Did you log that TCP message string to a file for debugging purposes?

(That would be a first step for solving your problem of replacing that VI: log a "known working" message from your VI and compare with the message sent by Putty!)

You can even do the same on your cRIO: log the incoming message string, then compare them based on their source/sender…

[rolfk · Accepted solution]

You seem to use (partial) binary communication on those messages. LabVIEW's binary format is not weird at all but follows the normal computer standards very closely. What you consider weird is the fact that binary formats are highly customized formats by their nature, not human readable and therefore pretty much impossible to reproduce on a command line like putty.

That is not LabVIEW's fault but whoever decided to use binary data communication instead of an ASCII format. Any other programming software would not be different in this. If you want to use binary communication, you need to use an environment that can deal with binary data communication. Most programming languages can do that, even Python if you are careful. But a command line tool will test your patience to an extend that only a godly person could master, if you try to do binary data communication.

The better approach would be likely to extend your LabVIEW program to ALSO allow an ASCII based command interface. Then you can do command line interaction much more easily. How to build that into your application is however not something we could tell you without seeing the entire VIs in real instead of just some pictures.

[KindlyAtlas]

@GerdW wrote:

Did you try to send the exact same byte stream/array using Putty (or whatever) to your cRIO as you do in this VI?

---

Sorry to everyone about the image VIs, but these are the rules... 😒

A version of our older system does successfully use TCP comm from "Client" VI to "Tool" VI, and they appear to use ASCII strings to talk. I can likely get Wireshark on that and see exactly what the two are saying to each other. A previous test confirmed ASCII is part of these messages, but as Rolf noted, they're likely muddied with pre- and app- ended binary. (Due to whatever the reasons were for pushing that instead of full ASCII) This would definitely make interaction via generic CLI very difficult, if not involving an extension of the current structure or a custom tool.

I will attempt to mirror that communication, but I expect that things will eventually point back to Rolf's answer - at least with the current setup and requirements of our system(s).

Thanks for the thoughts.