To get continuous images in labview from a c++ program

[prady.siegen]

I am working on a project in which I am using a Texas Instrument Time of flight camera. I am connecting this camera to my PC by using a c++ code and grabbing an image by using C++ program which i execute by command prompt. I can get an image in the form of its pixel data with resolution 320 x 240 in a .txt format. I am callin that file and plotting those points to get an image on my Front panel. I need to show these frames continuously which are captured by C++ program on same pc with 30 fps speed.

Which path i should follow?

How can I use buffer of labview in my case?

Or If I go for TCP/IP connection and create Server and client and use shared memory of my PC?

Looking forward for your help.

Thank you. 

[nathand]

Who wrote the C++ command-line program? Do you have source code for it? Does it call a DLL provided by Texas Instruments? What is the interface to the camera, both software and hardware?

The best route forward depends on your options for getting access to the camera image. For example, if the camera connects over ethernet, you may be able to establish a connection to it directly through LabVIEW TCP functions, if the protocol is available. If TI provides a DLL for accessing the camera image, you can call that DLL directly from LabVIEW. There's probably no need for a separate C++ application since any form of inter-process shared memory becomes complicated.

[prady.siegen]

There was a sdk provided by the TI. I have used the existing libraries and written a c++ program myself to connect the camera to my Pc and capture frame. The camera is connected by USB.

I am planning to connect the output of the c++ program and use it as an input to labview which will be continuously updated. I dont know whether it will work properly,but I am trying to get a continuous frames to labvies so that it will be seen as a live streaming with minimal lag.

[rolfk · Accepted solution]

The most performant option would likely be to write a DLL in C(++) and integrate that through the Call Library Node into LabVIEW. The DLL runs inside the LabVIEW process and by being smart with the parameters passed from and to LabVIEW through your DLL you can avoid quite a few memory copies, and don't have to squeeze it through some interprocess communication link like TCP/IP.

Note that the Call Library Node only can call exported standard C functions in the DLL, but no C++ objects. That doesn't have to be a problem though. You can write everything in C++ if you like, and then add standard C wrapper functions to the library that call those methods with an explicit "this" object pointer as first parameter.

The wrapper function then simply de-references the "this" pointer and calls the method (or methods) necessary. In the Call Library Node you treat the "this" pointer as a pointer sized integer variable and provide a 64 bit integer on the LabVIEW diagram. This is necessary so you can eventually move to 64-bit LabVIEW and a 64-bit version of your DLL, should the need arise. When you define those wrapper functions as extern "C" the C++ compiler will not decorate them with its compiler specific name decorations and you can import them into the LabVIEW Call Library Node fairly easily.

You need to be pretty steadfast with C pointers and how to deal with them properly, to make the Call Library Node correct, but considering that you already wrote a program in C++ I would think that should be pretty manageable. It takes a little time to get to understand the intricacies of the Call Library Node in respect to how LabVIEW deals with its data, but it's much easier than the typical LabVIEW programmer having to learn a lot about the C datatypes and especially pointer types first, when starting to use the Call Library Node.

In LabVIEW you generally don't worry about allocating an array before being able to use it in any way. LabVIEW does all for you automatically. But in C (to a lesser extend in C++ if you use automatic variables like in the standard template library) you have to worry about every single memory space, even scalar variables have to be declared explicitly beforehand, before you can use them in any way. And the same applies when using the Call Library Node. This is the single most stumbling block for many LabVIEW programmers trying to use the Call Library Node. 

[MarcDub]

The only think I would add to rolfk's suggestions is to consider using user events to transfer data from the dll to your LabVIEW application.

There is an example here .

This is the best way, I think, to sustain a 30 Hz rate. The drawback is that you probably have to make sure that it is "Thread safe" and run it in "any thread" instead of that in "UI thread" (the UI thread is getting continuously interrupted by UI events which negatively impact your acquisition rate) in its own loop.

Good luck.