LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Passing data from C to LabVIEW application

Solved!
Go to solution

Dear Community,

I am having C application for fast data acquisition (no LV api for that 😞 ) and analysis. I would like to continuously send analyzed data to LabVIEW for further plotting, saving, etc... Did anyone work with a similar approach?

Ideas which way to go:
1. Writing wrapper of Data acquisition card to LV - this one would be most flexible, but I can see the main drawbacks - time with writing the whole wrapper and with LabVIEW receiving too much data from the card (800MB/s).
2. Calling exe application with System Exec - I am not sure, how should I get all the data from there.
3. Communicating between the C and LabVIEW application via TCP/IP (as this older post shows https://forums.ni.com/t5/LabVIEW/How-to-Communicate-data-between-two-application-One-in-labview/td-p...). I don't know whether this could work reliably and if it's recommended - I appreciate any comment on that.

Any ideas or points for discussion are warmly welcomed.
Thanks 😉 




-Patrik
CLA || CTA
If it helps - Kudo it, if it answers - Mark As Solution
0 Kudos
Message 1 of 6
(321 Views)
Solution
Accepted by topic author Ajskrim

Well 1 and 3 definitely should work. Why do you think TCP/IP is not possible to make reliable? It requires a bit of programming, in fact more complicated on your C side than in LabVIEW, but it can absolutely be done. Just don't expect to be done in a day of work. And 800MB/s of raw data through TCP/IP would definitely be a challenge in any programming language even if you use a GigE interface.

 

I would agree that option 1 is the most intense in terms of work required. 800MB/s of data is not nothing but can be done if your hardware is not a resource starved old system from 10 years ago.  Defining a good API that uses double buffering and such techniques is important. You do want to call that API relatively infrequently to read a lot of data every time, rather than often and only reading small chunks of data.

 

My experience is that the very stringent requirements of doing absolutely perfect memory management at all times in C, helps to also make it as efficient as possible since you have to think about it anyhow already. LabVIEW makes it much easier to be lazy as you do not worry about memory allocations normally, but memory copies will drag your performance down very quickly. And at times it can be challenging to convince LabVIEW to NOT make a copy, as you do not have the low level control over memory as you have in C.

 

Doing the processing of that amount of data in LabVIEW is a challenge, but not really more than in C. The difference is that in C you have to worry about things like proper memory management all the time without ever getting a single pointer go invalid for any reason, while in LabVIEW you need to worry about not causing unnecessary memory copies as that drags down your performance. In C one single error drags down your program with a crash, in LabVIEW it will usually keep working until you lag so far behind that unprocessed buffers are getting overwritten or you run out of memory.

Rolf Kalbermatter
Averna BV
Message 2 of 6
(287 Views)

Hey 

 

I am mostly afraid about my capabilities to make it reliable/working correctly (especially on C side). 

 

Thank you for the hints, I'll move forward with TCP/IP communication between the apps then.

 

 

-Patrik
CLA || CTA
If it helps - Kudo it, if it answers - Mark As Solution
0 Kudos
Message 3 of 6
(225 Views)

Hi rolfk,

 

sorry to come back to closed topic. 

I would just have one follow-up question.

 

Do you think it's possible to just point LabVIEW to the data written by C application instead of sending (duplicating) them? 

How I'd imagine it -> Acquire on C level -> save into the buffer -> share the pointer to the data with LabVIEW -> LabVIEW access the same memory location and reads the data.

 

Maybe I'm off, but it would save time and memory, wouldn't it?

 

Thanks for help.

-Patrik
CLA || CTA
If it helps - Kudo it, if it answers - Mark As Solution
0 Kudos
Message 4 of 6
(145 Views)
Solution
Accepted by topic author Ajskrim

No, not without going pretty much rogue! LabVIEW is a managed environment, which means it has a well defined memory management model that is optimized for the LabVIEW dataflow paradigma. In order for this to work you either have to preallocate buffers in LabVIEW and pass them to the lower level library to write into or if the library prefers to return pointers of its own, you have to copy the data out of that pointer into a LabVIEW buffer.

 

The only exception to this rule is if the library was specifically written to be used with LabVIEW and is using itself the correct LabVIEW memory manager routines to properly deal with buffers.

 

LabVIEW needs to be able to take control of a data buffer as soon as that buffer leaves the C function. It can only do that with buffers allocated through its own memory manager functions. There are several fundamental difficulties in C programming about having a memory buffer not allocated and resized/deallocated by the same entity even if you understand the actual buffer layout! A call to malloc() in your library may deal with a very different memory heap than the according call to free() from the calling application due to differences in the version of the used C runtime library by both. The only way to guarantee that the same C runtime is used would be to require both the library and application to be compiled with the same C(++) compiler and same version! You can only guarantee that if you control the source code of both and even then it is bothersome to depend on that.

Rolf Kalbermatter
Averna BV
Message 5 of 6
(138 Views)

Hi 

 

-Patrik
CLA || CTA
If it helps - Kudo it, if it answers - Mark As Solution
0 Kudos
Message 6 of 6
(108 Views)