C++ communication between Labview and one application

[MrHappyAsthma]

---

@gautierdufourcq wrote:

Thank you very much. It is a good starting point for me. I understand that I need to implement something in C++ and in Labview.

In fact, I am going to be precise. I call a dll in a software. Thanks to the previous posts, I can call the dll and managing the VI in this software because I have the frontpanel.

But I need the measures, so I want Labview gives me a scalar.

Is it true that Labview is my server ? And that C++ is the client ?

---

Well you can really do either one.  A server just accepts clients.  Which one is which is an architectural design preference.

I like the idea of making LabVIEW be the server still because LabVIEW handles the parallel things much simpler than multithreading in C++ code.  (LabVIEW requires no additional code where as adding threads and synchronization to C++ is a bit of a hassle in comparison.  Since it takes some effort.)

Note:  You may not need paralleism, but you could depending on if you need to queue multiple client calls for any reason.  Or if you want to recieve TCP strings simultaneously as the other DLL code.

Much like the code I showed above

You could still have LabVIEW running a TCP Listen server in a while loop.  (Slight modification of the code above).  Then C++ connects as a client and sends a command informing LabVIEW to send back the measurement scalar.  For instance, C++ sends the text "measurement".  Then LabVIEW uses TCP Read and sees "measurement" so it knows to reply with the data.  (This would be seen in the request indicator in the picture example).

Next, you can send the measurement back as a string using TCP Write. (This would be sent using the response control in the picture example.)

Is this clear?

[gautierdufourcq]

It is clear because you understood what I want, thank you. I am going to use the whule of the VI to send permanently the scalar. But I do not understqnd the error with these VI's.

Moreover, let's assume I want to send 8, i read one byte. If I send 14, I want 2 bytes. But if I read two bytes and that I send 7, I have 77. Do you see the error ?

[GregFreeman]

We are doing this now. Just set up a server like you would any other way in LabVIEW (or a client, if you want the c++ side to be the server). We are then flattening to JSON to transfer data between the applications. It's much lighter weight than XML and is human readable which is a bit nicer than flatten to binary string. Although, I do like the latter when communicating between LabVIEW applications because you have access to the flatten and unflatten from string primitives on both ends. I can't remember here if endianness is a problem, so it's something you may have to test.

[GregFreeman]

---

@gautierdufourcq wrote:

It is clear because you understood what I want, thank you. I am going to use the whule of the VI to send permanently the scalar. But I do not understqnd the error with these VI's.

Moreover, let's assume I want to send 8, i read one byte. If I send 14, I want 2 bytes. But if I read two bytes and that I send 7, I have 77. Do you see the error ?

---

Your problem is you need a fixed length header, telling you how many bytes to read in the following string. Do something like the following. Typecast your string length and concatenate to the front of the string. You now know there will always be a 4 byte header on the front of your string. So, you read those 4 bytes, type cast back to an I32 which tells you your length, then use that length to read the rest of your string. Also, you have a misnomer. Your server is actually your client, and the client is actually a server. Don't forget to put a loop around the server as well so it keeps reading data and doesnt' just read once and stop. Also, close the server connection.

[nathand]

At the risk of adding confusion, if you intend to continue calling the main VI as a DLL, there's no reason to get into TCP connections to exchange data with the calling program. Instead, you could add a few more functions to the same DLL to facilitate data transfer. One such approach would be to add a functional global variable that stores some data. You would call it periodically inside the VI to update the data it stores, and also export it so it could be called through the DLL interface to retrieve that data.

[Dennis_Knutson]

I like the idea of adding to the confusion. Make sure the ActiveX server is enabled and use the get and set control methods. No changes to the VI.

[gautierdufourcq]

Actually, the VI is a big while loop because of acquisition. The loop never stops so I cannot access to any value inside. But if I do not understand the ideau of a global variable, correct me. What I like with the idea of the TCP, it is that I can establish a socket where I can easily access to the value I want in C++ and when I want in C++. I plan to create a function independant from the VI, with multithreading, not in C++, but in a software, to read in the socket when I want.

[Dennis_Knutson]

The big while loop is there because the code was designed for a different purpose. You can easily write a VI for a single acquisition and returns the data immediately. You keep ignoring this simple solution.

[gautierdufourcq]

I am not enough strong to recode the VI, there are too much variable. That is why I am so embarassing. Anyway, in the VI, there would be internal variables (like machine states). But, calling after calling, the values should not be reinitialized. Is it possible to do that since i use C++. Here is one problem. The TCP is much more interesting, isn't it ?

[gautierdufourcq]

You have just given me an idea. I am going to try to establish a TCP protocol VI client and server. I will build a dll for the client and will implant it in C++ for avoiding to implement librairies for sockets. The acquisition VI will be the server.  But, if I call the system of TCP on a remote computer, do I need to install something else than Labview run-time ?