There are several ways to get data from LabVIEW into DataTurbine, depending on your requirements.

1. Way back in 2002 I wrote LabVIEW code for streaming data on the NEES project. It was designed to be a library of subroutines that you'd add to your code, where streaming was best-effort and I tried hard to make it low-impact. For example, the code will handle network errors transparently, and you have to add a half-dozen routines to your DAQ program. Data is streamed in ASCII over TCP to DaqToRbnb, a Java program in our repository. Design slides for this DAQ code are here, protocol spec is here, and the code is available here (under trunk/labview/labview-daq). It's stable and works well - we're using it on the compact RIO as well.

The data on the web-based demo page is streamed from LabVIEW via this method.

2. The NEES code uses ASCII, and so is limited in rate. One faster option is to use the Capture program by sending UDP from Labview. This works up to tens of kilohertz and has less overhead than TCP. Code is here as of 10/2008.
3. LabVIEW has the DataSocket tools, which are very cool, but after discussions with NI we determined that we'd have to write our own non-trivial parser to convert the packets into DataTurbine datatypes, and at the moment the need just isn't there.
4. Protocol buffers are another interesting idea, but at the moment there's no extant LabVIEW code to create them. Since LV can invoke C via DLLs, it's do-able but would need some sort of project requirement.
5. There's the ActiveX bridge for windows, which I've not used.

The above are all for streaming numeric data. It's worth noting that the NEES Labview code also handles control of hardware such as motors, via a separate protocol/daemon, so we have some expertise in this area.