LabVIEW
Passing data from C to LabVIEW application
Solved!
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.
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.
