Create a continuous data stream from C++, and read it in LabView

Question

Hello all.
I'm working on a project which involves connecting to a motion tracker and reading position and orientation data from it in realtime. The code to get the data is in c++, so I decided that the best way to do this would be to create a c++ DLL file which contains all the necessary functions to first connect to the device and read the data from it, and use the Call Library Function node to feed this data into Labview. 
I'm having trouble though, since ideally I would like a continuous stream of data from the c++ code into Labview, and I'm not sure how to achieve this. Putting the call library function node in a while loop seems like an obvious solution, but if I do it this way I would have to reconnect to the device every time I get the data, which is quite a bit too slow. 
So my question is, if I created c++ function which created a data stream, could I read this into Labview without having to continually call a function? I'd prefer to only have to call a function once, and then read the data stream until a stop command is given.
I'm using Labview 2010, version 10.0.
Apologies if the question is poorly phrased, many thanks for your help.
Dave
Solved!
Go to Solution.

Answer 1

dr8086 wrote:
This method sounds like an excellent suggestion, but I do have a few questions where I dont think I've understood fully.
From what I understand the basic premise is to use one call library function node to access a DLL which creates an instance of the device object, and passes a pointer too it into labview. Then a seperate call library function node would pass this pointer to another DLL which could access the device object, update it and read the data. This part could be in a while loop and carry on reading the data until a stop command is given.
That's it. I'm including some skeleton code as an example. I'm also including the code because I don't know how much you have experience with multi threading, so I'm showing how you'd have to use critical sections to guard the interactions between threads so that they don't lead to issues.
// exported function to access the devices
extern "C" __declspec(dllexport) int __stdcall init(uintptr_t *ptrOut)
*ptrOut= (uintptr_t)new CDevice();
return 0;
extern "C" __declspec(dllexport) int __stdcall get_data(uintptr_t ptr, double vals[], int size)
return ((CDevice*)ptr)->get_data(vals, size);
extern "C" __declspec(dllexport) int __stdcall close(uintptr_t ptr, double last_vals[], int size)
int r= ((CDevice*)ptr)->close();
((CDevice*)ptr)->get_data(last_vals, size);
delete (CDevice*)ptr;
return r;
// h file
// Represents a device
class CDevice
public:
virtual ~CDevice();
int init();
int get_data(double vals[], int size);
int close();
// only called by new thread
int ThreadProc();
private:
CRITICAL_SECTION rBufferSafe; // Needed for thread saftey
vhtTrackerEmulator *tracker;
HANDLE hThread;
double buffer[500];
int buffer_used;
bool done; // this HAS to be protected by critical section since 2 threads access it. Use a get/set method with critical sections inside
//cpp file
DWORD WINAPI DeviceProc(LPVOID lpParam)
((CDevice*)lpParam)->ThreadProc(); // Call the function to do the work
return 0;
CDevice::~CDevice()
DeleteCriticalSection(&rBufferSafe);
int CDevice::init()
tracker = new vhtTrackerEmulator();
InitializeCriticalSection(&rBufferSafe);
buffer_used= 0;
done= false;
hThread = CreateThread(NULL, 0, DeviceProc, this, 0, NULL); // this thread will now be saving data to an internal buffer
return 0;
int CDevice::get_data(double vals[], int size)
EnterCriticalSection(&rBufferSafe);
if (vals) // provides a way to get the current used buffer size
memcpy(vals, buffer, min(size, buffer_used));
int len= min(size, buffer_used);
buffer_used= 0; // Whatever wasn't read is erased
} else // just return the buffer size
int len= buffer_used;
LeaveCriticalSection(&rBufferSafe);
return len;
int CDevice::close()
done= true;
WaitForSingleObject(hThread, INFINITE); // handle timeouts etc.
delete tracker;
tracker= NULL;
return 0;
int CDevice::ThreadProc()
while (!bdone)
tracker->update();
EnterCriticalSection(&rBufferSafe);
if (buffer_used<500)
buffer[buffer_used++]= tracker->getRawData(0);
LeaveCriticalSection(&rBufferSafe);
Sleep(100);
return 0;
dr8086 wrote:
My main concern is that the object may go out of memory or be deallocated, since it wouldnt be held in any namespace or anything.
Since you create the object with new, the object won't expire until either the dll is unloaded or the process (LabVIEW) closes. So the object will stay valid between dll calls provided LabVIEW didn't unload the dll (which it does if the VIs are closed). When that happens, I'm not exactly sure what happens to live objects (i.e. if you forgot to call close), I imagine the system reclaims the memory but the device might still be open.
What I do to make sure that everything gets closed when the dll unloads before I could call close and delete the object is to everytime I create a new object in the dll I add it to a list, when the dll unloads, if the object is still on the list I delete it.
dr8086 wrote:
I also have a more general programming question about the purpose of the buffer. Would the buffer basically be a big table of position values, which are stored until they can be read into the rest of the VI? 
Yes, see the example code.
However, depending on the frequency with which you need to collect data from the device you might not need this buffer at all. I.e. if you collect a sample about every 100ms then you could remove all threading and buffer related functions and instead read the data from the read function itself like this:
double CDevice::get_data()
tracker->update();
return tracker->getRawData(0);
 Because you'd only need a buffer and a seperate thread if you collect data at a high frequency and you cannot lose any data.
Matt