I'm trying to get labview-zmq to run on my cRIO-9068 (linux, ARM) but having issues. I was able to get the library / VI to work on Windows 10 in Labview 2017 but not on the cRIO. I'm using the labview-zmq-3.4.1.107.vip release.
Questions
1. Can the lvzmq32.so file be used for the ARM A9 processor? It looks like lvzmq.so was built on an Intel x86 machine. I'm assuming it can't be used for the ARM architecture.
2. I would like to compile a .so library so I can run a zeromq VI on my ARM-based cRIO
i. Is zmq_labview.c the only file I need to compile?
a. If so, the labview-zmq packages do not have all the .h headers needed to compile (I'm using Eclipse 2017 with C/C++ cross compiling toolchain). Would you be able to share all the .h files that must be included with zmq_labview.c for compilation?
Last edit: slai 2018-12-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I've never used the cRIO so I can't provide too much insight. As you suspect, the x86 binaries simply cannot be used on an ARM system, and you will need to cross-compile them for that target. I'm not aware of an official ARM build of ZeroMQ itself so the first step is to create a compatible binary of the library (see http://zeromq.org/build:arm).
You need to compile all the C files in the lib/ directory together, as well as link to libzmq itself, see the makefile for some details. You also need to link against the LabVIEW runtime (LVRT) for memory management reasons; there are some header files in the cintools/ LabVIEW directory that need including (extcode.h and friends).
It's also possible that there are different internal rules for the ARM target that LabVIEW uses internally as it's not explicitly listed in the documentation (http://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/how_labview_stores_data_in_memory/). This may cause it to crash even if it compiles, although a workaround can be implemented relatively easily once you can test it.
Cheers,
Martijn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So I was able to compile the binaries but could not get past the C code compilation. I adjusted the makefile to suit my environment but was still missing header files (mingw, memory, msvcrtver, sdkddkver, stdarg, stddef, stdlib, w32api, windef, windows). I was able to spoof or pull these .h files from MinGW but compilation errors that I couldn't debug resulted in me giving up.
Edit: I actually want to keep trying this path, but have a couple more questions
1. What does your build environment look like? For example, it looks like synch.h comes from a package called nachos? Is that correct?
2. How do you compile the code on linux? Very open-ended, but any details are welcome.
Last edit: slai 2018-12-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Update: I moved libzmq/ to the crio and compiled there (MUCH easier, see this forum). I am still seeing an error but it's a different one, so I'm pretty sure that is progress.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm, you really shouldn't need the windows headers to build for the cRIO since they're used for threading and process management on that platform. My build environment is MSVC16 community edition for Windows and GCC on a rather old Debian system for Linux. I think the <synch.h> include might be unnecessary because <pthread.h> is included later, should be safe to remove.</pthread.h></synch.h>
When you say you could compile binaries but not the C code, do you mean you compiled libzmq32.dll but not lvzmq32.dll? What error do you get now?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Basically I have compiled libzmq (by cloning the repo and compiling thru the means in my 12-21 comment) on the cRIO, but not lvzmq (dono if this is possible? or even how to do this). Issue is that the labview VI library functions are built with lvzmq functions provided in the download package (vi.lib/addons/zeromq) and not the libzmq api. This means that when I deploy the VI to the cRIO, I have to update the pre-built example VI's, which use lvzmq, and map those library functions to be libzmq compatible. Having said that, I have not gotten it to work yet.
I have used the python command line to check that I can create a context, socket, bind, and send a message and it works no problem (using the libzmq api). However, the lvzmq-to-libzmq mapping that the labview functions require is not straight forward. So I'm slogging through that now.
example: lvzmq_ctx_create (in lvzmq) = zmq_ctx_new (in libzmq)
The tricky part is that the VIs (lvzmq) may or may not have the same inputs and outputs as the mapped libzmq functions, and so the VIs provided in lvzmq may not be correct at all for running with libzmq.
I hope what I wrote makes sense.
Last edit: slai 2019-01-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do not use libzmq directly from LabVIEW, it will cause you huge problems. Libzmq is not designed to work with LabVIEW's intrinsically multithreaded runtime and even the simplest examples will cause LabVIEW to crash. This is the entire reason why I wrote LVZMQ in the first place - see various entries on the FAQ. LVZMQ provides the "glue" between LabVIEW and libzmq to prevent the system from crashing. It is so very much more complicated than just the API calls being slightly different.
I'm not sure why you can't compile LVZMQ? There's a makefile in the lib/ directory. Compile lvzmq32.so for your target system using the libzmq you have already compiled. Check the symbol definitions to ensure it doesn't try to pull in Windows headers. Use the latest code release as I removed some unused functionality yesterday.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've tried to make the makefile in lib/ before and this leads me back to the original issues I was having in my 12-18 post. will try to compile again and report back
Last edit: slai 2019-01-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok so I got lvzmq to work on the cRIO, and I compiled directly on the cRIO. I needed to:
1. copy over cintools to the cRIO
2. copy over the labview zeromq directory to the cRIO to /usr/local/natinst/labview/vi.lib/addons/
3. create a symlink from /usr/local/natinst/labview/liblvrt.so.17.0.0 to liblvrt.so
4. edited the linux build rules in the makefile to be this
edit line 592 of zeromq/lib/zmq_labview.c to be pthread_t thread;
re-pointed all the library function paths in the labview vi at /usr/local/natinst/labview/vi.lib/addons/zeromq/lvzmq32.so (the new library we compiled with the makefile)
and it works! Thanks so much for the pointers Martijn, really appreciate it
Last edit: slai 2019-01-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Installed zeromq using opkg install zeromqopkg install zeromq-staticdev
Copied cintools folder to /usr/local/natinst/labview
Copied zeromq directory to cRIO: usr/local/natinst/labview/vi.lib/addons/
Created symlink from /usr/local/natinst/labview/liblvrt.so.16.0.0 to liblvrt.so
modified makefile to this
# LINUX BUILD RULESelse # omg so much simpler!LABVIEW= /usr/local/natinst/labview
CFLAGS= -Wall -O3 -fpic -I $(LABVIEW)/cintools -I /usr/include
LDLIBS= -lzmq -llvrt
ifdef DEBUGCFLAGS+= -DDEBUG
endifall :lvzmq32.so# copy the product to the labview directory
@cp $< $(LABVIEW)/vi.lib/addons/zeromq
endif# Linux shared-library targetlvzmq32.so :$(SRC)$(CC) -shared -o $@ $^ $(CFLAGS)$(LDFLAGS)$(LDLIBS)
First time doing something like that so I might did some error there. Changed ../lvzmq32.so to lvzmq32.so because I was receiving errors at @cp $< $(LABVIEW)/vi.lib/addons/zeromq
6. Edited line in zeromq/lib/zmq_labview.c
7. and basically harcoded: /usr/local/natinst/labview/vi.lib/addons/zeromq/lvzmq32.so in zmq_libpath.vi
8. after that I run make in the /usr/local/natinst/labview/vi.lib/addons/zeromq/lib directory where I got some 2 warnings
So, does it mean that the compilation was OK?
I run the subscriber on cRIO, and it seems to work, but when I started publisher on another PC, I suddenly lost connection to my cRIO. Maybe it got restarted, I do not know. Sometimes I was able to connect to the cRIO again, sometimes there were some errors in the log which causes cRIO to restart.
cRIO-9030 with NI Linux Real-Time x64 4.1.15-rt17-4.0.0f0
LabVIEW 2016, Real Time Module 2016, NI RIO 16.0
Could you please have a look on the instruction above whether I did something wrong?
Do you have any idea what can cause the lost of the connection?
Thank you for help
Juraj
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Juraj,
It seems like your cRIO is running 64-bit LabVIEW, whereas previous attempts were on 32-bit LabVIEW. There are significant internal differences which can cause crashing due to incorrectly aligned memory, and would explain why it may have worked at first, but then crashed the system at some point. When I wrote the library, 64-bit only existed on Windows, and frustratingly NI are not particularly forthcoming on the relevant differences.
Try editing zmq_labview.c at line 63 to be #define LVALIGNMENT 8 and recompile. If that fixes the issue I will put a better fix into the library. Out of interest what were the compiler warnings you received?
Cheers,
Martijn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
admin@cRIO-9030:/usr/local/natinst/labview/vi.lib/addons/zeromq/lib# make
cc -shared -o lvzmq32.so zmq_labview.c -Wall -O3 -fpic -I /usr/local/natinst/labview/cintools -I /usr/include -L /usr/local/natinst/labview -lzmq -llvrt
zmq_labview.c: In function 'lvzmq_ctx_create_reserve':
zmq_labview.c:216:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
*pinstdata = bonzai_init(( void* )ninits );
^
zmq_labview.c: In function 'lvzmq_receiver_thread':
zmq_labview.c:575:11: warning: variable 'err' set but not used [-Wunused-but-set-variable]
int ret, err;
^
Those two warnings are the two I experienced before.
It looks that the compilations was ok, and I was able to run the subscriber on cRIO and publisher on the other PC in python. No lose of connection and the data were transferred. So great. thanks for your help and info
Juraj
Last edit: Juraj Talan 2019-08-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey there -
I'm trying to get labview-zmq to run on my cRIO-9068 (linux, ARM) but having issues. I was able to get the library / VI to work on Windows 10 in Labview 2017 but not on the cRIO. I'm using the labview-zmq-3.4.1.107.vip release.
Questions
1. Can the lvzmq32.so file be used for the ARM A9 processor? It looks like lvzmq.so was built on an Intel x86 machine. I'm assuming it can't be used for the ARM architecture.
2. I would like to compile a .so library so I can run a zeromq VI on my ARM-based cRIO
i. Is zmq_labview.c the only file I need to compile?
a. If so, the labview-zmq packages do not have all the .h headers needed to compile (I'm using Eclipse 2017 with C/C++ cross compiling toolchain). Would you be able to share all the .h files that must be included with zmq_labview.c for compilation?
Last edit: slai 2018-12-15
Hi,
I've never used the cRIO so I can't provide too much insight. As you suspect, the x86 binaries simply cannot be used on an ARM system, and you will need to cross-compile them for that target. I'm not aware of an official ARM build of ZeroMQ itself so the first step is to create a compatible binary of the library (see http://zeromq.org/build:arm).
You need to compile all the C files in the lib/ directory together, as well as link to libzmq itself, see the makefile for some details. You also need to link against the LabVIEW runtime (LVRT) for memory management reasons; there are some header files in the cintools/ LabVIEW directory that need including (extcode.h and friends).
It's also possible that there are different internal rules for the ARM target that LabVIEW uses internally as it's not explicitly listed in the documentation (http://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/how_labview_stores_data_in_memory/). This may cause it to crash even if it compiles, although a workaround can be implemented relatively easily once you can test it.
Cheers,
Martijn
Thank you for the quick response Martijn! I will give it a go and will report back with my findings.
So I was able to compile the binaries but could not get past the C code compilation. I adjusted the makefile to suit my environment but was still missing header files (mingw, memory, msvcrtver, sdkddkver, stdarg, stddef, stdlib, w32api, windef, windows). I was able to spoof or pull these .h files from MinGW but compilation errors that I couldn't debug resulted in me giving up.
Edit: I actually want to keep trying this path, but have a couple more questions
1. What does your build environment look like? For example, it looks like synch.h comes from a package called nachos? Is that correct?
2. How do you compile the code on linux? Very open-ended, but any details are welcome.
Last edit: slai 2018-12-19
Update: I moved libzmq/ to the crio and compiled there (MUCH easier, see this forum). I am still seeing an error but it's a different one, so I'm pretty sure that is progress.
Hmm, you really shouldn't need the windows headers to build for the cRIO since they're used for threading and process management on that platform. My build environment is MSVC16 community edition for Windows and GCC on a rather old Debian system for Linux. I think the <synch.h> include might be unnecessary because <pthread.h> is included later, should be safe to remove.</pthread.h></synch.h>
When you say you could compile binaries but not the C code, do you mean you compiled libzmq32.dll but not lvzmq32.dll? What error do you get now?
Basically I have compiled libzmq (by cloning the repo and compiling thru the means in my 12-21 comment) on the cRIO, but not lvzmq (dono if this is possible? or even how to do this). Issue is that the labview VI library functions are built with lvzmq functions provided in the download package (vi.lib/addons/zeromq) and not the libzmq api. This means that when I deploy the VI to the cRIO, I have to update the pre-built example VI's, which use lvzmq, and map those library functions to be libzmq compatible. Having said that, I have not gotten it to work yet.
I have used the python command line to check that I can create a context, socket, bind, and send a message and it works no problem (using the libzmq api). However, the lvzmq-to-libzmq mapping that the labview functions require is not straight forward. So I'm slogging through that now.
example: lvzmq_ctx_create (in lvzmq) = zmq_ctx_new (in libzmq)
The tricky part is that the VIs (lvzmq) may or may not have the same inputs and outputs as the mapped libzmq functions, and so the VIs provided in lvzmq may not be correct at all for running with libzmq.
I hope what I wrote makes sense.
Last edit: slai 2019-01-04
Do not use libzmq directly from LabVIEW, it will cause you huge problems. Libzmq is not designed to work with LabVIEW's intrinsically multithreaded runtime and even the simplest examples will cause LabVIEW to crash. This is the entire reason why I wrote LVZMQ in the first place - see various entries on the FAQ. LVZMQ provides the "glue" between LabVIEW and libzmq to prevent the system from crashing. It is so very much more complicated than just the API calls being slightly different.
I'm not sure why you can't compile LVZMQ? There's a makefile in the lib/ directory. Compile lvzmq32.so for your target system using the libzmq you have already compiled. Check the symbol definitions to ensure it doesn't try to pull in Windows headers. Use the latest code release as I removed some unused functionality yesterday.
Ah ok, this makes sense....
I've tried to make the makefile in lib/ before and this leads me back to the original issues I was having in my 12-18 post. will try to compile again and report back
Last edit: slai 2019-01-04
Ok so I got lvzmq to work on the cRIO, and I compiled directly on the cRIO. I needed to:
1. copy over cintools to the cRIO
2. copy over the labview zeromq directory to the cRIO to /usr/local/natinst/labview/vi.lib/addons/
3. create a symlink from /usr/local/natinst/labview/liblvrt.so.17.0.0 to liblvrt.so
4. edited the linux build rules in the makefile to be this
# omg so much simpler! LABVIEW = /usr/local/natinst/labview LDFLAGS = -L $(LABVIEW) CFLAGS = -Wall -O3 -fpic -I $(LABVIEW) -I /usr/local/natinst/LabVIEW-2010/cintools -I /usr/include LDLIBS = -lzmq -llvrt ifdef DEBUG CFLAGS += -DDEBUG endifpthread_t thread;and it works! Thanks so much for the pointers Martijn, really appreciate it
Last edit: slai 2019-01-04
Congrats on getting it to work! And thanks for posting the necessary steps in case anyone else wants to achieve this - it has been requested before.
Hi Guys,
I tried to follow your steps, but did not succeed.
opkg install packagegroup-core-buildessentialopkg install zeromqopkg install zeromq-staticdev/usr/local/natinst/labviewusr/local/natinst/labview/vi.lib/addons//usr/local/natinst/labview/liblvrt.so.16.0.0toliblvrt.soFirst time doing something like that so I might did some error there. Changed
../lvzmq32.sotolvzmq32.sobecause I was receiving errors at@cp $< $(LABVIEW)/vi.lib/addons/zeromq6. Edited line in
zeromq/lib/zmq_labview.c7. and basically harcoded:
/usr/local/natinst/labview/vi.lib/addons/zeromq/lvzmq32.soinzmq_libpath.vi8. after that I run
makein the/usr/local/natinst/labview/vi.lib/addons/zeromq/libdirectory where I got some 2 warningsSo, does it mean that the compilation was OK?
I run the subscriber on cRIO, and it seems to work, but when I started publisher on another PC, I suddenly lost connection to my cRIO. Maybe it got restarted, I do not know. Sometimes I was able to connect to the cRIO again, sometimes there were some errors in the log which causes cRIO to restart.
cRIO-9030 with NI Linux Real-Time x64 4.1.15-rt17-4.0.0f0
LabVIEW 2016, Real Time Module 2016, NI RIO 16.0
Could you please have a look on the instruction above whether I did something wrong?
Do you have any idea what can cause the lost of the connection?
Thank you for help
Juraj
Hi Juraj,
It seems like your cRIO is running 64-bit LabVIEW, whereas previous attempts were on 32-bit LabVIEW. There are significant internal differences which can cause crashing due to incorrectly aligned memory, and would explain why it may have worked at first, but then crashed the system at some point. When I wrote the library, 64-bit only existed on Windows, and frustratingly NI are not particularly forthcoming on the relevant differences.
Try editing zmq_labview.c at line 63 to be
#define LVALIGNMENT 8and recompile. If that fixes the issue I will put a better fix into the library. Out of interest what were the compiler warnings you received?Cheers,
Martijn
Hi Martijn,
I did what you proposed and the results are below
admin@cRIO-9030:/usr/local/natinst/labview/vi.lib/addons/zeromq/lib# make cc -shared -o lvzmq32.so zmq_labview.c -Wall -O3 -fpic -I /usr/local/natinst/labview/cintools -I /usr/include -L /usr/local/natinst/labview -lzmq -llvrt zmq_labview.c: In function 'lvzmq_ctx_create_reserve': zmq_labview.c:216:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] *pinstdata = bonzai_init(( void* )ninits ); ^ zmq_labview.c: In function 'lvzmq_receiver_thread': zmq_labview.c:575:11: warning: variable 'err' set but not used [-Wunused-but-set-variable] int ret, err; ^Those two warnings are the two I experienced before.
It looks that the compilations was ok, and I was able to run the subscriber on cRIO and publisher on the other PC in python. No lose of connection and the data were transferred. So great. thanks for your help and info
Juraj
Last edit: Juraj Talan 2019-08-21