What is the best way to use my C++ code including an API in a LabVIEW VI?

[ttte]

I have a large C++ code to collect and analyze data. The code also include a small API that consists of around 50 functions for system setup, buffering, and access of the data received from a camera via a commercial board.

I am trying to add a control device to be activated with LabVIEW RT based on the data analysis from the C++ code. I was trying to use CIN or Call Library Functions but having lots of problem following the procedures in 'Using External Code in LabVIEW' manual. I am not even sure if this would be possible because my C++ code needs to include the API.

Could anyone tell me what the best way would be to use this C++ code in LabVIEW RT? Thanks.

[Ed007]

Need more detail about the test setup. You are saying you need to use LabVIEW RT to interface with your C++ code. Is there are reason you need real-time performance? Usually, if you perform acquisitions of large data sets followed by analysis of that data, you don't need real-time performance because you cannot achieve one anyways. It would be much better if you can get away with LabVIEW and your commercial board installed in the PC. Then, you would interface with your C++ code either by calling exportable library functions through a DLL that you create in C++, or through a CIN.
If you have to use the LabVIEW RT, then I would suggest that you implement your solution (code) completely in LabVIEW RT instead of importing C++. It would be much easier. In that case you need a hardware target, which is running a real-time OS,separate from your development PC. Then you have to check that the driver that comes with your card is supported in LabVIEW RT, and if it isn't, you have to make one to be able to use the card in LabVIEW RT. You see how it adds to the complexity of the system. Not to mention that you would need two PC's (one for development and GUI, and the other for the DAQ hardware and real-time processes).

[Ricardo_SR]

Hello,

It is definitely better if you could do all your code using LabVIEW instead of calling the c++ code. Now if you still want to do that, there are some things that you need to check. When building your dll you need to make sure that all the functions used don't depend on the windows, meaning that only a portion of the WIN32API is available in LabVIEW RT. The best way to create your dll is using LabWindows CVI. CVI’s compiler will check these restrictions.
The other thing you need to also check is the driver for your hardware to make sure that it is supported in LabVIEW RT. The most probable thing is that you will have to create your own driver.
If you don't want to do that, then the best solution is to use one of NI DAQ boards.
Hope this helps.


Ricardo S.
National Instruments

[ttte]

A little more details about the test setup...

There are physically and functionally two separate parts in the setup. The commercial board drives the camera for data acquisition only. I think it is so fast that I don't need to worry about additional RT capability and should be able to get away with LabVIEW. But the control part needs to respond fast enough not to have any delay or irregularity in control. The samples move on the conveyor belt and the control part should be able to hit them with air jets based on the data collected and analyzed upstream. Due to the precision required for hitting the samples with air jets, I was thinking to use LabVIEW RT.

I first tried with CIN but no luck yet. Based on your advice, I think I will try with DLLs. The C++ code includes the custom API for setup and use of the camera and the commercial board. It runs okay at least for the measurement part. All I need from LabVIEW is to control the air jets based on the results. Do you think I can make a single DLL from my C++ code for data acquisition? Thanks in advance...

[Ricardo_SR]

Hi Thomas,

So if you are thinking of creating the dll just for the jets I think that should work fine. Now there is some concept I want to clarify. Anything running in Real Time doesn't imply that will run fast, it really means that it will run deterministically. Meaning that if you want something to happen every ms, then it will happen. Definitely in our PXI systems you can go all the way to micro sec but keep in mind that RT is not fast but deterministic.
Hope this helps.

Ricardo S.
National Instruments

[ttte]

Thank you for clarifying the difference between LabVIEW and LabVIEW RT.

Based on your advice, the best approach seems to be using LabVIEW with DLLs. I am trying to test if I can use Call Library Functions.

Here are some follow-up questions. My C++ code works fine and already includes many API functions for the commercial board. The manual 'Using External Code in LabVIEW' shows how to configure a Call Library Function Node for an API function.

Q1. Does this mean I have to make 50 Call Library Function Nodes for 50 API functions in my case? That must be a lot of work... Or, I can use my entire C++ code to build a single DLL and configure a Call Library Function Node for the DLL?

Q2. If it requires too much work to use Call Library Function Nodes, wouldn't it be a better idea to try to do both daq and control with C++? I heard it may be possible to use the parallel port for 5V outputs and to control some valves. Any suggestions?

[Ed007]

Q1: You can call only one function with call library function node. This way you will end up with 50 nodes. Yes, this is a lot of work initially, but try to combine several function calls into a subVI. This is basically like creating a sort of a driver for your card. Depending on the functionality of your card, if you combine the function calls logically into subVI's, you will not have to call each individual function. You just call your VI and it handles all the included function calls for you. Basically, create a LaBVIEW driver for your card with only a few logical blocks (VI's) that with handle most of the card operations for you instead of calling individual functions every time.
And no, you cannot configure Call Library Function Node for the Dll. You configure it to call a single function from the DLL.

Q2: You can do that but think LabVIEW will save you a lot of time if you implement the entire project in LabVIEW. Also, LabVIEW will let you interface with your parallel port for digital input and output using Port IN.vi and Port Out.vi. There are examples in LabVIEW how to do this.

[ttte]

1) What do you think about an idea of using the existing C++ code and a LabVIEW VI at the same time? The outputs of the C++ code are just 10 numbers (say, 0 for OFF or 1 for ON). If I can put the results into fixed memory locations and run the C++ program and a VI at the same time, it may be possible to make the VI read the data as soon as they are available. One thing I worry is that I may lose control of timing in the air valve activation. Does this approach make sense?

2) So, I can not put the entire C++ code into a Call Library Function Node... And I can call only one function with a Call Library Function Node??? Hmmm... Can't we consider the entire C++ code as a BIG function that includes other functions inside? I know I need to give this option up but just trying to understand better.