c++ interface

[shayelk]

Hi,
I'm looking for a way to create two way communication between my LabVIEW VI and a user program writhen in C++ or Matlab.
The idea is that the user program will be able to lunch the VI, which will run in the background, and then send commands and recieve output as it wishes (the VI is a control algorithm for a quad copter and the user program is a navigation algorithm. So the user might send input such as "go to (X,Y,Z)" or "take off and hover" and ask for output such as "where is the quad copter?" "is the quad copter airborne?").
I think what I'm looking for is baically something like LabVIEW notifiers that can be used between C++/Matlab and LabVIEW (i.e there would be a notifier with the next designated coordinate updated by the user, and a notifier with the current position updated by the VI).
Any ideas what I should be looking at?


Thank you for your help!

[Yamaeda]

Wouldn't it be easier to export your LV functions as a DLL and call them directly from the C program?

/Y

[shayelk]

@Yamaeda wrote:

Wouldn't it be easier to export your LV functions as a DLL and call them directly from the C program?

/Y

---

Not if I understand what you're suggesting correctly- as much as I know, if I do as you suggested, the C program will call the VI with certain parameters, the VI will run and than end, returning the output.

I want the VI to run continuously while constantly getting new parameters from the C program and sending up-to-date output. (as I said- the VI is a control algorithm. it has to run continuously in order for the quad to stay airborne, even if no new input is available) 

[Yamaeda · Accepted solution]

Ok, if you want both programs to run unrelated but have the ability to send information i'd look into TCP or UDP, once set up it's a nifty way to send commands and language independant.

/Y

[natasftw]

I'm guessing you're looking at the LVH quadcopter controls.

Why not just build your UI in LabVIEW instead of c++?  It's already pretty much done for you.  Why is there a need to complicate the communication?

[shayelk]

---

@natasftw wrote:

I'm guessing you're looking at the LVH quadcopter controls.

---

I'm not familiar with LVH, I'm building the control algorithm from scratch because it's a bit different from most of the algorithms I saw (flying indoor using IR cameras as positioning input, rather then outdoor using GPS, accelerometers and gyros).

---

natasftw wrote:

Why not just build your UI in LabVIEW instead of c++?  It's already pretty much done for you.  Why is there a need to complicate the communication?

---

Because the users of this control algorithm will be people doing research on navigation and guidance, who don't necessarily know LabVIEW. My goal is to allow each researcher to write his or her navigation and guidance code in a language to their preference without being bothered with control

[nathand · Accepted solution]

Is it acceptable for your LabVIEW VI to run as a separate process? It sounds like it is. If so, you can include as a subVI a functional global variable that holds the latest data. Then, build a separate set of LabVIEW VIs that use VI Server to get access to that functional global, and package those into a DLL that you call from the C++ program. This gives you essentially shared memory (in the form of a functional global variable) between the LabVIEW and C++ applications, with the threading safety that LabVIEW provides.

[shayelk]

---

@nathand wrote:

Is it acceptable for your LabVIEW VI to run as a separate process? It sounds like it is. If so, you can include as a subVI a functional global variable that holds the latest data. Then, build a separate set of LabVIEW VIs that use VI Server to get access to that functional global, and package those into a DLL that you call from the C++ program. This gives you essentially shared memory (in the form of a functional global variable) between the LabVIEW and C++ applications, with the threading safety that LabVIEW provides.

---

That sounds great! I have a lot to learn before I can actually implement it but I'll certainly look into it. thank you!