# Best practices for real-time LabVIEW ↔ Julia data exchange

**URL:** <https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319>\
**Category:** General Usage\
**Tags:** question, data, labview\
**Created:** [September 12, 2025, 11:47am UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319 "2025-09-12T11:47:40Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Frauke](https://avatars.discourse-cdn.com/v4/letter/f/b5e925/32.png) [@Frauke](https://discourse.julialang.org/u/Frauke)\
**Post date:** [September 12, 2025, 11:47am UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/1 "2025-09-12T11:47:40Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [September 12, 2025, 12:21pm UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/2 "2025-09-12T12:21:43Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [September 12, 2025, 12:27pm UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/3 "2025-09-12T12:27:37Z")

</div>

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;

> [@\[ANN\] LabVIEW0 - Calling Julia from LabVIEW using ZeroMQ](https://discourse.julialang.org/t/ann-labview0-calling-julia-from-labview-using-zeromq/75033):
>
> I’m happy to announce this package. The package is alreary registered. For documentation see on GitHub [https://github.com/Eben60/LabVIEW0.jl/blob/main/README.md](https://github.com/Eben60/LabVIEW0.jl/blob/main/README.md) and links therein (I still have to learn Documenter). A number of examples are provided, and documentation contains screenshots of LabVIEW VIs, so you don’t need LabVIEW installation to get the first impression. BTW, though LV is commercial (and not cheap), there is now a [Community Edition](https://www.ni.com/en-ie/shop/labview/select-edition/labview-community-edition.html), which is free for private use and specifically …

> 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).

> [@Integrate Julia scripts into NI Labview](https://discourse.julialang.org/t/integrate-julia-scripts-into-ni-labview/42281):
>
> Hello, how about everyone, my most sincere and cordial greetings to all who read this post. I am a fairly new user and amazed at how great it is to use Julia as an alternative to other languages. My question is a bit silly but I still have no where to start, I would like to generate DLLs of some functions that I generate later in Julia. I have generated these DLLs before in C # within visual studio but they are really deficient, I would like to know if I can generate them in Julia due to thei…

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.

---

<div class="post-metadata">

**Author:** ![Eben60](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/eben60/32/13475_2.png) [@Eben60](https://discourse.julialang.org/u/Eben60)\
**Post date:** [September 12, 2025, 12:38pm UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/4 "2025-09-12T12:38:01Z")

</div>

> [@Frauke](#):
>
> 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.

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

_Edit:_

> [@Frauke](#):
>
> continuous signal streams

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

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [September 12, 2025, 12:45pm UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/5 "2025-09-12T12:45:19Z")

</div>

> [@Palli](#):
>
> on standard hardware (no hard-realtime can)

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.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [September 12, 2025, 1:09pm UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/6 "2025-09-12T13:09:48Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Frauke](https://avatars.discourse-cdn.com/v4/letter/f/b5e925/32.png) [@Frauke](https://discourse.julialang.org/u/Frauke)\
**Post date:** [September 12, 2025, 1:17pm UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/7 "2025-09-12T13:17:50Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [September 12, 2025, 1:27pm UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/8 "2025-09-12T13:27:29Z")

</div>

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.

> **[Implementing/Calling C code in labview](https://forums.ni.com/t5/LabVIEW/Implementing-Calling-C-code-in-labview/td-p/4066769)**
>
> I use to program in C language in Microcontrollers. Sometimes we make C code, which if we check for all the values it can take and check c code output, it takes lots of time since MCU are generally low speed.   What I want to do is:  Write...

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).

> <https://stackoverflow.com/questions/17185249/extensive-comparison-between-simulink-and-labview>

> **[Reddit - The heart of the internet](https://www.reddit.com/r/AskEngineers/comments/35brt4/can_anyone_explain_the_difference_between_labview/)**

---

<div class="post-metadata">

**Author:** ![Frauke](https://avatars.discourse-cdn.com/v4/letter/f/b5e925/32.png) [@Frauke](https://discourse.julialang.org/u/Frauke)\
**Post date:** [September 12, 2025, 1:37pm UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/9 "2025-09-12T13:37:18Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [September 12, 2025, 1:50pm UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/10 "2025-09-12T13:50:37Z")

</div>

I’m not sure maybe you only need:

> **[GitHub - JaneliaSciComp/NIDAQ.jl: National Instruments Data Acquisition Interface](https://github.com/JaneliaSciComp/NIDAQ.jl)**
>
> National Instruments Data Acquisition Interface

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).

---

<div class="post-metadata">

**Author:** ![Frauke](https://avatars.discourse-cdn.com/v4/letter/f/b5e925/32.png) [@Frauke](https://discourse.julialang.org/u/Frauke)\
**Post date:** [September 12, 2025, 2:01pm UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/11 "2025-09-12T14:01:24Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Eben60](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/eben60/32/13475_2.png) [@Eben60](https://discourse.julialang.org/u/Eben60)\
**Post date:** [September 12, 2025, 7:02pm UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/12 "2025-09-12T19:02:33Z")

</div>

I’ve never used it, and know little about, but [LabWindows/CVI - Wikipedia](https://en.wikipedia.org/wiki/LabWindows/CVI) could also be of interest, in case you have access to it.

---

<div class="post-metadata">

**Author:** ![Jake](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jake/32/46007_2.png) [@Jake](https://discourse.julialang.org/u/Jake)\
**Post date:** [September 12, 2025, 7:24pm UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/13 "2025-09-12T19:24:51Z")

</div>

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](https://sigview.com/) 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](https://digilent.com/shop/products/data-acquisition-daq/raspberry-pi/) 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](https://github.com/JuliaInterop/Clang.jl). This is available [here](https://github.com/Spectrum-Tec/MccDaqHats.jl).

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.

---

<div class="post-metadata">

**Author:** ![Paulo\_Jabardo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/paulo_jabardo/32/3196_2.png) [@Paulo\_Jabardo](https://discourse.julialang.org/u/Paulo_Jabardo)\
**Post date:** [September 12, 2025, 8:33pm UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/14 "2025-09-12T20:33:22Z")

</div>

I use the [https://github.com/JaneliaSciComp/NIDAQ.jl](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

---

<div class="post-metadata">

**Author:** ![Frauke](https://avatars.discourse-cdn.com/v4/letter/f/b5e925/32.png) [@Frauke](https://discourse.julialang.org/u/Frauke)\
**Post date:** [September 15, 2025, 7:19am UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/15 "2025-09-15T07:19:31Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![Frauke](https://avatars.discourse-cdn.com/v4/letter/f/b5e925/32.png) [@Frauke](https://discourse.julialang.org/u/Frauke)\
**Post date:** [September 15, 2025, 7:21am UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/16 "2025-09-15T07:21:31Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Frauke](https://avatars.discourse-cdn.com/v4/letter/f/b5e925/32.png) [@Frauke](https://discourse.julialang.org/u/Frauke)\
**Post date:** [September 15, 2025, 8:08am UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/17 "2025-09-15T08:08:49Z")

</div>

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.)?

---

<div class="post-metadata">

**Author:** ![Paulo\_Jabardo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/paulo_jabardo/32/3196_2.png) [@Paulo\_Jabardo](https://discourse.julialang.org/u/Paulo_Jabardo)\
**Post date:** [September 15, 2025, 10:37am UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/18 "2025-09-15T10:37:00Z")

</div>

[NIDAQ.jl](https://github.com/JaneliaSciComp/NIDAQ.jl) is actually the basis over which LabView is built. So it is low level.

---

<div class="post-metadata">

**Author:** ![Eben60](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/eben60/32/13475_2.png) [@Eben60](https://discourse.julialang.org/u/Eben60)\
**Post date:** [September 15, 2025, 11:14am UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/19 "2025-09-15T11:14:01Z")

</div>

> [@Paulo\_Jabardo](#):
>
> over which LabView is built.

Could you explain what you mean?

---

<div class="post-metadata">

**Author:** ![Paulo\_Jabardo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/paulo_jabardo/32/3196_2.png) [@Paulo\_Jabardo](https://discourse.julialang.org/u/Paulo_Jabardo)\
**Post date:** [September 15, 2025, 11:20am UTC](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319/20 "2025-09-15T11:20:08Z")

</div>

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.

[Next page](https://discourse.julialang.org/t/best-practices-for-real-time-labview-julia-data-exchange/132319.md?page=2)