zeromq - simple fast lightweight communication - does it fill a gap in NIs offering?

[Darin]

I'll try to dig something up showing throughput sloshing data back and forth between python, java and LV.

 

It was very enticing, especially since my natural curiosity takes me into the depths of various protocols and file formats.  Of my many spelunking expeditions AMQP was one of the best.

[M_P]

I had great fun digging into the depths of the fancy schmancy messaging protocol I was designing, until I discovered that it already existed, was called ZeroMQ, and was implemented better than mine was.  That was simultaneously sad and exciting.

 

I'd love to see a comparison between the different languages (ideally with the code to reproduce) - I'm trying to work up some recommendations for customers choosing what messaging architecture to use for a large mostly LV system.

[Bob Edwards]

Good to know that NI have been looking at 0MQ et al. Given the useful features M_P describes above and the apparent popularity it seemed a pity that Martijn Jasperse's labview-zmq was languishing. I think he'd enjoy a little fresh input - he's not much time to spare from his day job.

 

Things I like about it for my purpose: well documented api, serverless solution for master - multiple slave, messages not streams, any data you like, fault tolerance, small memory requirement, simple installation of final apps - just two dlls, Ascii based Identities when using the Router socket (for naming slaves)

 

I'd second that 0MQ would make a good open source labview library, especially if alternative (better) binding techniques are possible as the labview language developer. (e.g. event support / development system recovery after 0mq error) Keep the library simple to keep it flexible, with plenty of examples to illustrate the extras 0MQ brings and fire the imagination. Examples make or break adoption I think, especially as 0MQ docs are on the whole good, but lengthy.

[viSci]

Just poking this thread to see if anyone is still working on AMQP or 0MQ...

[Bob Edwards]

Yes, I'm having another go,

 

I've come back to 0mq after a break away from it. The Labview-zmq package is worth another look, the author has revised the interface quite a bit and I suspect this is more stable than it was - less likely to crash the labview development system. Can be found at http://labview-zmq.sourceforge.net/

 

One of the changes made is the use of labview objects which the author claims has simplified the wrapper between labview and 0mq.

Edited March 3, 2014 by Bob Edwards

[M_P]

I'm in need of some use cases/requirements for actual LV applications that need 0MQ, AMQP, or similar middleware so I can justify spending additional time on this.  I'm working on messaging/data distribution architectures in my spare time, but spare time has been increasingly difficult to come by.  

 

If any of you fine folks have requirements/use cases/application details that you can share with me, I'd appreciate it if you can send them my way.  

 

Specifically, what is the value you see in these libraries that is not met by existing LabVIEW libraries/capabilities?  

What kind of data distribution are you doing with them (and does it fit into some combination of tags, commands, and streams)?  Are your data types static or could they change arbitrarily?

Do you have a brokered approach, and if so what drove the requirement for a broker?  (Centralized logging and alarming, abstraction point between control nodes and HMI nodes, etc)

What directionality is the data flow?  One-way producer->consumer, mesh broadcast, two-way command handshake, etc

 

If posting publicly is no bueno, matthew.pollock@ni.com

[odoylerules]

I'm in need of some use cases/requirements for actual LV applications that need 0MQ, AMQP, or similar middleware so I can justify spending additional time on this.  I'm working on messaging/data distribution architectures in my spare time, but spare time has been increasingly difficult to come by.  

 

If any of you fine folks have requirements/use cases/application details that you can share with me, I'd appreciate it if you can send them my way.  

 

Specifically, what is the value you see in these libraries that is not met by existing LabVIEW libraries/capabilities?  

What kind of data distribution are you doing with them (and does it fit into some combination of tags, commands, and streams)?  Are your data types static or could they change arbitrarily?

Do you have a brokered approach, and if so what drove the requirement for a broker?  (Centralized logging and alarming, abstraction point between control nodes and HMI nodes, etc)

What directionality is the data flow?  One-way producer->consumer, mesh broadcast, two-way command handshake, etc

 

If posting publicly is no bueno, matthew.pollock@ni.com

 

 

I don't have a lot of details to share, but in the past i have specifically looked at the 0MQ labview driver for interfacing labview components with Nodejs.  Since both languages are currently supported, it provided an easy, turn key method for passing data without having to develop the communication protocol from scratch.  However, given the that labview implementation of ZeroMQ does not currently support VxWorks this was a dead end for me as i was really hoping to use NodeJS and the browser as the front end for my CRIO interfaces.  If the 0MQ library could be updated to support VxWorks i think that would fill a gap for interfacing NI hardware with other software options.  I had not yet looked at RabbitMQ as this was a quick side project.  

 

As a side note, i have been able to use low level TCP functions to facilitate nodejs to labview communication but as i mentioned it wasn't implemented as well as the ZeroMq library.

[Mellroth]

I know this is a really old thread, but I just saw Darins post about implementing ZMTP in LabVIEW.

On 11/27/2013 at 6:05 PM, Darin said:

 

Been there, done that.  I have G implementations of ZMTP (at least most bits I need) and AMQP (0.9.1 not the 1.0 trainwreck).  I tend to use AMQP most often since my code is more complete (and there was more adoption of it when I wrote it), but they are both great.  The brokerless nature of ZMQ can be great when you need it, turns out most times I was implementing a de facto broker and could have stuck to AMQP.

 

Unfortunately the specs are really laid out seductively in terms of classes and methods so I gummed up the works by using a bit too much LVOOP (not to mention busted my carpal tunnels).  Performance is ok, but as I de-LVOOP it is finding another gear.  I create worker pools consisting of simple  LV workers and similar C++, Java, or Python workers and see what share each worker does.  LV is behind, but getting up there with the big boys.  The LV9 to LV12 performance kick was also welcome here.

 

The AMQP implementation gave rise to one of my new mantras:  No LVOOP in a loop.

Was this a native LabVIEW implementation or did you use a wrapper around the ZMQ windows DLL? 

/J

[Darin]

11 hours ago, Mellroth said:

I know this is a really old thread, but I just saw Darins post about implementing ZMTP in LabVIEW.

Was this a native LabVIEW implementation or did you use a wrapper around the ZMQ windows DLL? 

/J

Holy blast from the past, but back in the day I did create a pure G implementation of a limited subset of ZMTP.  Basically I implemented what I needed for REQ/REP and PUB/SUB peers over TCP and some other low-hanging fruit.  A few MUSTs and several SHALLs in the RFC were ignored along the way to suit my needs (mostly self-educational).  It was strictly version 2.0, no dealing with v1.0 peers (plus it is now at least v4.0).  Looking back I will just say that I was not lazy, I was guarding against downgrade attacks....

These days I use 0MQ a lot, but mostly over inter-process connections which requires platform-specific bits so pure-G is out, and at that point I strongly suggest just wrapping libzmq (actually if pressed I would suggest wrapping it in all cases).   I do not say this about very many libraries, but this one has been a pleasure to work with across several platforms with many different language bindings.  In my use cases I have not run into any problems with my wrappers

[Mellroth]

On 12/2/2016 at 9:33 PM, Darin said:

Holy blast from the past, but back in the day I did create a pure G implementation of a limited subset of ZMTP.  Basically I implemented what I needed for REQ/REP and PUB/SUB peers over TCP and some other low-hanging fruit.  A few MUSTs and several SHALLs in the RFC were ignored along the way to suit my needs (mostly self-educational).  It was strictly version 2.0, no dealing with v1.0 peers (plus it is now at least v4.0).  Looking back I will just say that I was not lazy, I was guarding against downgrade attacks....

These days I use 0MQ a lot, but mostly over inter-process connections which requires platform-specific bits so pure-G is out, and at that point I strongly suggest just wrapping libzmq (actually if pressed I would suggest wrapping it in all cases).   I do not say this about very many libraries, but this one has been a pleasure to work with across several platforms with many different language bindings.  In my use cases I have not run into any problems with my wrappers

Thanks for the reply,

the thing for us is that the customer needs ZMQ (ZMTP) on a Pharlap-based cRIO (no inter-process stuff). We are essentially evaluating our options; either implement in pure G, or recompile for Pharlap and change the wrapper VIs to handle this.

Any chance you could share the G code?

/J

 

[Thomas_xyz]

On 5.12.2016 at 9:28 AM, Mellroth said:

Thanks for the reply,

the thing for us is that the customer needs ZMQ (ZMTP) on a Pharlap-based cRIO (no inter-process stuff). We are essentially evaluating our options; either implement in pure G, or recompile for Pharlap and change the wrapper VIs to handle this.

Any chance you could share the G code?

/J

 

Hello Mellroth,

http://labview-zmq.sourceforge.net/

Take a look. I have not tried it yet. Tell us what you think about it ...

Edited January 10, 2017 by Thomas_xyz

[crandiba]

On 12/5/2016 at 9:28 AM, Mellroth said:

Thanks for the reply,

the thing for us is that the customer needs ZMQ (ZMTP) on a Pharlap-based cRIO (no inter-process stuff). We are essentially evaluating our options; either implement in pure G, or recompile for Pharlap and change the wrapper VIs to handle this.

Any chance you could share the G code?

/J

 

Hey Mellroth,
Again, sorry for the reply to an old post but we are looking at the exact same problem: ideally, looking for a native G implementation or AMQT or 0MQ. Sorry to bother but did you have any luck or which way did you end up going for at the end?
Thanks!

[MarkCG]

On 11/26/2013 at 2:47 PM, GoGators said:

Just came across this port.  Sys Eng at NI is interested in zeromq and rabbitmq.  We've been playing around with both and are considered making an open source library if it fits a need.  One of the SEs even built it for the cRIO-9068 platform for alliance day to talk about reuse on NI Linux RT.  Don't count us out yet

Turns out one of my coworkers is trying to compile zeromq for the cRIO-9068, but not having success. Anyone ideas or have the .so file available? We also have a cRIO-9038 which is a different processor architecture, maybe it will work there?

[smithd]

4 hours ago, MarkCG said:

Turns out one of my coworkers is trying to compile zeromq for the cRIO-9068, but not having success. Anyone ideas or have the .so file available? We also have a cRIO-9038 which is a different processor architecture, maybe it will work there?

Depends on how they are trying to compile it. Back in the 2013 time frame I got it working the way that was being recommended at the time, which was through the eclipse cross-compile tools. Unfortunately, when NI moved to the new community system all that got deleted (as far as I can tell).

The more recent recommendation I've seen is to just compile it on the target. I can confirm that works, at least a year or so ago. You just copy the whole source directory onto the cRIO and run the commands specified in the source (configure, make, make install probably). Before you can run those commands you need to have the build tools installed, which you can get by 'opkg install packagegroup-core-buildessential' (https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/Building-software-for-NI-Linux-RT/td-p/3372279/page/3). You may find that it says a library is missing, in which case you'll usually need to look in opkg for the -dev version of the library in question. For example, I compiled drivers for a USB device so I needed to find libusb-dev and then some libusb compatibility layer as well.

I doubt you'll find using the 9038 any easier, as its still the ni flavor of linux.

[Rolf Kalbermatter]

NI still provides Eclipse installations to cross compile shared libraries for their NI Linux RT based hardware targets.

http://www.ni.com/download/labview-real-time-module-2014/4846/en/

http://www.ni.com/download/labview-real-time-module-2017/6731/en/

Still need to test if it is mandatory to use both versions depending on the targeted LabVIEW version or if shared libraries created in the 2014 version will also work on LabVIEW versions 2017 and 2018.

And I agree, the difference between the Intel and ARM versions of the targets in terms of compiling C source code for just about any software that does not contain assembly code instructions is really the same.

Edited December 21, 2018 by Rolf Kalbermatter

[smithd]

2 hours ago, Rolf Kalbermatter said:

NI still provides Eclipse installations to cross compile shared libraries for their NI Linux RT based hardware targets.

http://www.ni.com/download/labview-real-time-module-2014/4846/en/

http://www.ni.com/download/labview-real-time-module-2017/6731/en/

Yeah they are still available, but I'm saying I've seen the NI guys on the linuxrt forum suggest target compilation. Can't find it now of course.

In actuality the compilation part isn't much different -- running vim over ssh on an arm crio is approximately as painful as using eclipse. The part that is more difficult is the configure step. ZeroMQ has a ton of optional settings (which event mode to use? select, poll, epoll, kqueue... security? they have an NaCl based encryption scheme...etc.). You can technically figure out each one, but copying to the target and running configure is a looooot easier.

Edited December 21, 2018 by smithd

[MarkCG]

thank you Rolf and SmithD, this helps. I think he is making some progress now by compiling on the cRIO although it's not working yet. I've informed him of this thread and will update if we can get it working!

[MarkCG]

update to this thread: we got it working on the cRIO 9068. See this thread https://sourceforge.net/p/labview-zmq/discussion/general/thread/87780372ed/ for details. Thanks to everyone here and Martijn Jasperse for all your help. 

[Rolf Kalbermatter]

the last step in the description on the sourceforge post could be made simpler: 

Instead of changing the library path in all Call Library nodes to <some long path>/lvzmq32.so and having to maintain two versions of the VIs because of the different library name ending, you should replace the .so with .*. LabVIEW will then replace the .* with whatever file ending is standard for the current platfom (.so on Linux, .dll on Windows, .framework on Mac)

[smithd]

1 hour ago, Rolf Kalbermatter said:

the last step in the description on the sourceforge post could be made simpler: 

Instead of changing the library path in all Call Library nodes to <some long path>/lvzmq32.so and having to maintain two versions of the VIs because of the different library name ending, you should replace the .so with .*. LabVIEW will then replace the .* with whatever file ending is standard for the current platfom (.so on Linux, .dll on Windows, .framework on Mac)

as I recall Martijn had some issues with the combo of VIPM mass compiling + *s in the CLFN path. I filed a CAR for him at the time but I doubt its resolved, and his workaround was (again, as far as I remember) that when you install the package it runs a script which adjusts the path based on the platform. The middle ground is what I think most people end up doing, which is to create a VI with some conditional disable code to determine the path.

 

2 hours ago, MarkCG said:

update to this thread: we got it working on the cRIO 9068. See this thread https://sourceforge.net/p/labview-zmq/discussion/general/thread/87780372ed/ for details. Thanks to everyone here and Martijn Jasperse for all your help. 

As I was reading this I remembered something else..far, far too late ...NI provides a zeromq build as part of the core package list.

Package: zeromq
Version: 4.1.6-r0.16
Depends: libc6 (>= 2.24), libgcc1 (>= 6.3.0), libsodium18 (>= 1.0.11), libstdc++6 (>= 6.3.0)
Section: base
Architecture: cortexa9-vfpv3
Maintainer: NI Linux Real-Time Maintainers <nilrt@ni.com>
MD5Sum: ea3774e76c28b7c5b07318b4502fec9e
Size: 147468
Filename: zeromq_4.1.6-r0.16_cortexa9-vfpv3.ipk
Source: zeromq_4.1.6.bb
Description: zeromq version 4.1.6-r0
 ZeroMQ looks like an embeddable networking library but acts like a
 concurrency framework
OE: zeromq
HomePage: http://www.zeromq.org
License: LGPLv3+
Priority: optional

Package: zeromq-staticdev
Version: 4.1.6-r0.16
Depends: zeromq-dev (= 4.1.6-r0.16)
Section: devel
Architecture: cortexa9-vfpv3
Maintainer: NI Linux Real-Time Maintainers <nilrt@ni.com>
MD5Sum: 686b2b13e3908313aa35da8b46955ddc
Size: 3765648
Filename: zeromq-staticdev_4.1.6-r0.16_cortexa9-vfpv3.ipk
Source: zeromq_4.1.6.bb
Description: zeromq version 4.1.6-r0 - Development files (Static Libraries)
 ZeroMQ looks like an embeddable networking library but acts like a
 concurrency framework  This package contains static libraries for
 software development.
OE: zeromq
HomePage: http://www.zeromq.org
License: LGPLv3+
Priority: optional

All you should have to do is opkg update, opkg install zeromq, and opkg install zeromq-staticdev. Its available at least as far back as 2017.

Note: you will still need to compile the wrapper library

[Rolf Kalbermatter]

14 hours ago, smithd said:

as I recall Martijn had some issues with the combo of VIPM mass compiling + *s in the CLFN path. I filed a CAR for him at the time but I doubt its resolved, and his workaround was (again, as far as I remember) that when you install the package it runs a script which adjusts the path based on the platform. The middle ground is what I think most people end up doing, which is to create a VI with some conditional disable code to determine the path.

It seems to work fine for the OpenG ZIP library and other libraries I did in the past. So not exactly sure what the problem would be. Of course you need to make sure that the .so and .dll and .framework all end up in the same location relative to the VIs, the shared library name needs to be the same except a possible lib prefix on the Linux platform, and the calling convention needs to be cdecl on all platforms (where you have choice). Most new platforms only know one possible calling convention, so no choice there anyhow. Windows 64-bit for instance uses a new calling convention called fastcall, but that is the only one supported (and generally used outside kernel space).

Edited January 5, 2019 by Rolf Kalbermatter

[ShaunR]

On 1/5/2019 at 4:40 PM, Rolf Kalbermatter said:

It seems to work fine for the OpenG ZIP library and other libraries I did in the past.

Don't you use a modified OpenGPackage Manager for zlib rather than VIPM?

I'm not sure if it is the same issue but when VIPM compiles the *.* it "fixes" the file path to whatever bitness you compiled it in if it successfully finds the library. That means if you created the package with 64 bit LabVIEW and the file name is "something_*.*", then the path gets "fixed" to "something_64.dll". The result is that something_32.dll isn't searched for when installed and recompiled on a 32 bit platform and the Vis are broken.

[Rolf Kalbermatter]

15 hours ago, ShaunR said:

Don't you use a modified OpenGPackage Manager for zlib rather than VIPM?

I'm not sure if it is the same issue but when VIPM compiles the *.* it "fixes" the file path to whatever bitness you compiled it in if it successfully finds the library. That means if you created the package with 64 bit LabVIEW and the file name is "something_*.*", then the path gets "fixed" to "something_64.dll". The result is that something_32.dll isn't searched for when installed and recompiled on a 32 bit platform and the Vis are broken.

Well yes I do build my own .opg package with a version of the OpenG Package Builder. And this version does indeed not do many things and none that are required to support new post 8.0 features like lvlib, lvclass, etc. The only fixing that is done during the build process is renaming the VIs with a postfix then packing everything up into the opg package which is basically still the same as a vip.

If VIPM indeed does fixup the library names on package creation, which it may not even do intentionally but simply may be a side effect of the part where the entire hierarchy is first read into memory and then saved back to the VIs, then there is a serious problem. If the fixup only happens at masscompile time after installation there should be no problem at all.

The part in the OpenG Package Builder that does the postfix renaming uses in fact the same method to load and modify and then save the renamed hierarchy but I do execute it in pre 8.0 LabVIEW as the VIs are saved in the format of the LabVIEW version in which this step is performed. As all of the wildcard magic in the library name except the shared library ending itself is really only 2009 and higher gimmicks, it may be that the according function in later LabVIEW versions fixes up the library names on recompilation and then the built package indeed ends up with an undesired fixed library name. In that case VIPM should in fact restore the wildcard shared library names after renaming and recompolation before writing the VI hierarchy back to disk in order to keep the original names.

Also I obviously only use the shared library file ending wildcard and not the others for 32/64 bit library distinction. Instead I install both shared libraries to the target directory and then use a post install hook that renames the correct shared library for the current platform to the generic name without bitness indication and deletes the other one. That way the VIs can always use the same generic library name without need to distinguish between bitness there.

Edited January 7, 2019 by Rolf Kalbermatter

[ShaunR]

1 hour ago, Rolf Kalbermatter said:

where the entire hierarchy is first read into memory and then saved back to the VIs,

Yes. It is in the build process, not at install-by then it's too late (at install) and the recompile passes but the VIs are broken. By the way. this happens also with the TPLAT so it isn't a particular VIPM problem.

The work around is to delete the DLLs just before building (so that VIPM or TPLAT fail to find the files during the build) and press "ignore" when it searches. Luckily, that doesn't fail the build but I can see that at some point they might "fix" it so the build fails.

Edited January 7, 2019 by ShaunR

[Rolf Kalbermatter]

On 1/7/2019 at 12:50 PM, ShaunR said:

The work around is to delete the DLLs just before building (so that VIPM or TPLAT fail to find the files during the build) and press "ignore" when it searches. Luckily, that doesn't fail the build but I can see that at some point they might "fix" it so the build fails.

I think a better "workaround" is to use the paths from the hierarchy as read from disk to fixup the paths in the hierarchy list after loading and renaming the VIs, before writing it back with the Write VI Hierarchy method. Having to click away warnings sounds pretty unintuitive.