Best practices for real-time LabVIEW ↔ Julia data exchange

General Usage
, ,
1

Hi everyone,

I am currently working on a project where I want to integrate LabVIEW with Julia. The basic idea is that LabVIEW acquires some signals from hardware, Julia processes the data (e.g., simple computations like scaling or filtering), and then LabVIEW receives the results back.

I am considering using TCP/IP Sockets or ZeroMQ since there are toolkits in LabVIEW for it.

Before I commit to building everything on one of these approaches, I wanted to ask the community:

  • Are there other practical ways to exchange data between LabVIEW and Julia, especially for real-time or near-real-time applications?
  • Any experiences with using shared memory, memory-mapped files, or other IPC mechanisms in this context?
  • Any advice on pitfalls or best practices for continuous signal streams between LabVIEW and Julia?

Thanks in advance for any suggestions! Frauke

3 Likes
2

Real-time can have a lot of different meanings. How hard are your real-time requirements?

If 99% of your messages are processed in 1ms, but 1% need 10ms, would that be a problem?

On the Julia side, do you need allocation-free code, or is it acceptable if the GC kicks in every now and then?

ZeroMQ is pretty good, according to my experience.

2 Likes
3

You want to call Julia from LabView right? I don’t know much about LabVIEW, if it can call C then it can call Julia in-process. That would be fastest (realtime isn’t about speed really, rather predictability). Shared memory though as fast. From one process to another with Julia, maybe still ok, i.e. with:

I think though LabVIEW0.jl would be ok for you, using ZeroMQ;

The latency of Julia call is about 1-2 ms. 1 MB data transfer (forth and back) in binary format “door to door” - from numeric array in LV back to numeric array in LV, inclusive all necessary data transformations in LV and Julia, takes about 20-25 ms on my notebook. At about 100MB transfer, LV may get out-of-memory (8 GB RAM installed).

Julia CAN do hard-realtime, but then we’re not talking idiomatic Julia code nor able to run on standard hardware (no hard-realtime can); I think you’re talking about soft-realtime, where memory allocations ok, and Julia should be then fine on standard hardware.

ZeroMQ CAN use TCP, or work only on same machine, seemingly better for you. I’m not sure what the package does, or allows all of its options? Maybe all are available to you or at least what you need.

2 Likes
4

This is exactly the use case of LabVIEW0.jl . Contact me if you get any issues.

Edit:

With LabVIEW0.jl, this won’t probably work out of the box.

3 Likes
5

Not exactly true. You can run hard real-time processes on Linux-RT on many (not all) Linux computers. But you might have to avoid graphic drivers; real-time works best without any display.

6

Yes, I meant on standard, or rather arbitrary hardware. You want known hardware and/or RTOS. Julia supports no RTOS, and they I believe also rely on known hardware, not too slow.

E.g. Raspberry Pi can be used for as lot of realtime yes. But say you need something requiring desktop class for speed, then install on slower standard computer, then Julia or RTOS or both would not save you.

7

Thank you! I will definitely look into that package. Working with ZeroMQ sounds most reasonable so far.

8

FYI: You CAN call C from LabVIEW and thus embed Julia in it (in-process). Embedding is not too hard. I’m unsure how demanding it is what you’re doing, like bandwidth, so then maybe that’s better for your continuous use case (not the edit above). Do you expect a lot of Julia code? See also new juliac. And e.g. Bumper.jl and more likely useful to you.

At first I though you were asking for SIMULINK (in MATLAB), I just mixed up and wasn’t answering for that, since I realized my error. What does LabVIEW give you that you can’t do just in Julia? I realize you may have something there already, thus better, not saying Julia alone for sure better, or with SIMULINK (that’s like harder to connect to for real time).

9

I am basically using LabVIEW to communicate with some NI DAQ hardware whereas my whole data analysis is written in Julia. It would be cool if I didn’t have to rewire my data processing in LabVIEW since it contains ODE solving and reconstruction algorithms which would be tough for me to reimplement in LabVIEW (I am really not a LabVIEW expert haha). So I really just need LabVIEW as my hardware arm and Julia as my brain if that makes sense. Therefore, it would be cool if they could talk with each other and exchange data, e.g. labVIEW sends a measured voltage to Julia, Julia computes something out of it and then sends it back to LabVIEW so LabVIEW can update the hardware control (e.g. change current in coils).

1 Like
10

I’m not sure maybe you only need:

since most your code is in Julia already, I thought some or lot in LabVIEW. I’m ignorant of it, it has a GUI, do you not want to do that in Julia (possible!) or do you not actually need one or very minimal?

It doesn’t matter much but do you use Windows? And need 32-bit LabVIEW or 32-bit for DAO? I recall some wanted 32-bit around for just that… 32-bit DLLs do not work with 64-bit (if I recall).

4 Likes
11

Well, that package looks interesting too! This way I can communicate with my NI hardware directly from Julia. Yes, of course the LabVIEW GUI would be nice but as you said, it’s possible building one in Julia as well.

I am using Windows and have 64-bit LabVIEW.

12

I’ve never used it, and know little about, but LabWindows/CVI - Wikipedia could also be of interest, in case you have access to it.

1 Like
13

I am not sure what data acquisition you are doing from Labview but there are another couple of alternatives that might be worth trying.

Sigview reportedly can acquire data from NI hardware and can call Julia natively. It is inexpensive with a free trial available.

Depending upon your data acquisition and processing requirements Digilent has some nice cost effective ADC hardware for the RPI. I have personal experience with the MCC 172. This hardware has drivers for C and Python. I have wrapped the C drivers for the 172 in Julia and control the hardware directly from Julia. I have a start for the other cards using Clang.jl. This is available here.

I have used both the RPI 4 and 5 (both are 8 Gig units) and am impressed with its processing capability, but not so much its graphics capability. The most responsive graphics I have tried is InspectDR, but currently that is limited to Julia 1.10.

3 Likes
14

I use the https://github.com/JaneliaSciComp/NIDAQ.jl package daily and it works very well. It is a little lower level but is a direct interface to the C library NIDAQmx.

Paulo

2 Likes
15

From my first impression Sigview seems exactly like the software I was looking for, so I will definitely look into that, thank you so much!

16

Thank you for sharing your experience with the NIDAQ.jl package. I will also set up a minimal working example with that package next to the Sigview solution to compare what works best for me in the end.

17

Hi Jake, I have one more question: Am I right in assuming that Sigview can only handle data acquisition in terms of analyzing and plotting measurement data recorded with some kind of DAQ hardware but not able to fully control the DAQ hardware in terms of sending signals out (e.g. to adjust currents through coils, etc.)?

18

NIDAQ.jl is actually the basis over which LabView is built. So it is low level.

19

Could you explain what you mean?

20

I should have been more precise in my language. The LabView language/environment when using National Instruments data acquisition boards calls NIDAQmx drivers. The NIDAQ.jl package is an interface to the NIDAQmx C drivers - It just Clanged it… Years ago that was the only option. Now, the more popular interface is the .NET version. It probably uses the C drivers but I don’t really know.

2 Likes