Hi,
I'm trying to use the zmq_socket_monitor function in LabVIEW code and am experiencing problems. There is no wrapper provided in the ZeroMQ VI package, therefore I'm trying to mimic a call via "Call Library Function Node". Based on the zmq.h prototype and other wrappers I produced the following labview call:
int32_t zmq_socket_monitor(const uintptr_t sock_obj, const CStr endpoint, int32_t events);
however the call to the function always returns -1, error.
Hi,
I can see two problems with this approach: firstly the sock_obj is not actually a socket; it's a pointer to a data structure containing a socket. So if you were passing it directly to ZMQ you'd need to pass the socket member of the structure pointed to by sock_obj.
The second problem is more fundamental: if you create a CLN linked directly to libzmq and not lvzmq, then LabVIEW will load this in a separate instance to the one loaded by lvzmq - in which case passing pointers between them causes an access violation (or best case scenario a "not a socket" error).
My recommendation is to wrap the zmq_socket_monitor call in zmq_labview.c with a one-line wrapper function like the ones at the end of the file. Then call this wrapper function using the VI you created, which also enables you to use the package error handler (which is not possible for direct libzmq calls).
I've created a support ticket to include these functions in the library, but I won't have time for this for a few days. But the method I describe above should work.
Cheers,
Martijn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I did unbundle the sock_ref as from the sock_obj in other wrappings and the prototype is the same as in already wrapped calls.
About the second... I was unable to make a working copy of lvzmq32.dll, but I must admit I'm completely at a loss at compling, especially under windows. Basically what I did was, I followed the directions at http://zeromq.org/docs:source-git, windows section. Built for version 14 which I have installed:
>buildall
Building ..\vs2015\libzmq.sln
Platform=x86
Configuration=DynDebug
Configuration=DynRelease
Configuration=LtcgDebug
Configuration=LtcgRelease
Configuration=StaticDebug
Configuration=StaticRelease
Platform=x64
Configuration=DynDebug
Configuration=DynRelease
Configuration=LtcgDebug
Configuration=LtcgRelease
Configuration=StaticDebug
Configuration=StaticRelease
Building complete: ..\vs2015\libzmq.sln
Press any key to continue . . .
and produced the .lib files.
* the lib files were not located where the instructions say, but rather under:
Then I edited the makefile in the lib directory of the LabView distribution to use ARCH=32 and pointed the .lib file location to libzmq\bin\Win32\Release\dynamic. The make is successful and lvzmq32.dll is generated, however in LabVIEW I get "Library does not exist or can not be loaded" error.
If you see somethng funcdamentally wrong in what I did, please let me know, but if it's not obvious, I'll just have to wait for your official upgrade.
Thanks for the help and best regards,
Blaz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
There are actually two levels of wrapping, one in LabVIEW that provides thread safety by using the (sock_ref->sock_obj) trick to serialise the library calls (which you did implement in the screenshot). Then there is another layer at the C level (sock_obj -> socket) which protects the LabVIEW process in the event of an abort, hang, or linger. This dereferencing is done in the wrapper DLL and would require a MoveBlock call (or similar) to do in LabVIEW.
This may seems convoluted but the libzmq philosophy is to terminate the host process if something goes wrong, which is fine for a commandline utility but not when the host process is LabVIEW! I'll add a note to the FAQ to explain this further.
I can't immediately see anything wrong with your build process. Did you move the relevant DLLs to the labview-zmq folder in <vi.lib>/addons? Windows DLL resolution is not the best, and it's strongly preferable to put the DLLs in the same folder. If you built it successfully and got the "can not be loaded" error it is almost certainly a path resolution issue.
I should be able to patch in the call this weekend. I saw in the example a non-library call get_monitor_event() that also looks useful; are there any other necessary function calls?
Cheers,
Martijn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
As a follow-up, I implemented the socket_monitor and proxy calls in the repo, but had some problems with testing that reveal some further work needs to be done. Specifically, since zmq_proxy() occupies the calling thread, termination semantics are complicated, and in my initial tests my socket monitor wasn't receiving any messages. I'll look into it more when I have some time, otherwise feel free to play around with it yourself.
Cheers,
Martijn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks for the socket_monitor implementation. I'll complie the code and try it ASAP. Do you have any ETA on when will you publish a new version of the ZMQ VI package. The product I'm working on, woul have to have a versioned vi package included, and though I can continue developement with my own dll's I'd really prefer to use an official version.
Regards,
Blaz
Last edit: Blaz Kelbl 2016-08-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Sorry, I moved house yesterday and have a lot going on right now. I would prefer not to package and release until I have a working test VI, but if you need it I can do an alpha release this weekend.
Cheers,
Martijn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey,
I fully understand and appreciate that you don't want to release without propper testing. An alpha release would be great if not too much of a hassle - perhaps I could provide some feedback based on my application. So I'm looking forward to the alpha release.
Thank you very much for all the help and for being so responsive!
Blaz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi again, I believe the socket monitor is working now; I've just released v3.4.0, which includes the socket monitor and an example showing how to use it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As a follow up, the VIP is now available from the project page, and I've updated the FAQ with more information about internals, and some details about how the socket monitor works -- http://labview-zmq.sourceforge.net/?faq#monitor
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I completely forgot that the vi 0mq package isn't visible in the VIPM repository and was downloaded and installed manually from this site in the first place.
Sorry for the false alarm and best regards,
Blaz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did look into distributing via the LabVIEW Tools Network a few years ago, but I didn't have time to write all the required documentation. I think they loosened the requirements a while back so it's something I could look into again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
we discovered two problems with the latest lvzmq package:
1. the new typedef monitor_event.ctl isn'0t included in the lvlib file as the other typedefs are. While this problem doens't appear while you're in development mode, it pops out when you try to complie the code, including the "zeromq.lvlib", expecting all the dependencies to be included.
The execution priority property of the zmq_libpath.vi was changed to "subroutine". Again, the problems appear when you complie the application. The path of the library becomes:
application.exe/1abvi3w/.....
If the execution priority is changed to "Above normal" or less as was in the .102 the problem dissapears.
Best regards
Blaz Kelbl
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Blaz,
Thanks for the report, I appreciate it. Everything should be "normal" priority to prevent thread switching overhead, so I've corrected that, and put the missing CTL in the LVLIB. I'll put out a new package tomorrow.
Cheers,
Martijn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm trying to use the zmq_socket_monitor function in LabVIEW code and am experiencing problems. There is no wrapper provided in the ZeroMQ VI package, therefore I'm trying to mimic a call via "Call Library Function Node". Based on the zmq.h prototype and other wrappers I produced the following labview call:
int32_t zmq_socket_monitor(const uintptr_t sock_obj, const CStr endpoint, int32_t events);
however the call to the function always returns -1, error.
I'm trying to mimic the example code found at http://api.zeromq.org/4-2:zmq-socket-monitor , but I can't gt past the first zmq_socket_monitor call.
Any suggestion would be greatly appreciated.
edit: attached picture
Last edit: Blaz Kelbl 2016-08-02
Hi,
I can see two problems with this approach: firstly the sock_obj is not actually a socket; it's a pointer to a data structure containing a socket. So if you were passing it directly to ZMQ you'd need to pass the socket member of the structure pointed to by sock_obj.
The second problem is more fundamental: if you create a CLN linked directly to libzmq and not lvzmq, then LabVIEW will load this in a separate instance to the one loaded by lvzmq - in which case passing pointers between them causes an access violation (or best case scenario a "not a socket" error).
My recommendation is to wrap the zmq_socket_monitor call in zmq_labview.c with a one-line wrapper function like the ones at the end of the file. Then call this wrapper function using the VI you created, which also enables you to use the package error handler (which is not possible for direct libzmq calls).
I've created a support ticket to include these functions in the library, but I won't have time for this for a few days. But the method I describe above should work.
Cheers,
Martijn
Hi,
I did unbundle the sock_ref as from the sock_obj in other wrappings and the prototype is the same as in already wrapped calls.
About the second... I was unable to make a working copy of lvzmq32.dll, but I must admit I'm completely at a loss at compling, especially under windows. Basically what I did was, I followed the directions at http://zeromq.org/docs:source-git, windows section. Built for version 14 which I have installed:
Press any key to continue . . .
and produced the .lib files.
* the lib files were not located where the instructions say, but rather under:
Then I edited the makefile in the lib directory of the LabView distribution to use ARCH=32 and pointed the .lib file location to libzmq\bin\Win32\Release\dynamic. The make is successful and lvzmq32.dll is generated, however in LabVIEW I get "Library does not exist or can not be loaded" error.
If you see somethng funcdamentally wrong in what I did, please let me know, but if it's not obvious, I'll just have to wait for your official upgrade.
Thanks for the help and best regards,
Blaz
Hi,
There are actually two levels of wrapping, one in LabVIEW that provides thread safety by using the (sock_ref->sock_obj) trick to serialise the library calls (which you did implement in the screenshot). Then there is another layer at the C level (sock_obj -> socket) which protects the LabVIEW process in the event of an abort, hang, or linger. This dereferencing is done in the wrapper DLL and would require a MoveBlock call (or similar) to do in LabVIEW.
This may seems convoluted but the libzmq philosophy is to terminate the host process if something goes wrong, which is fine for a commandline utility but not when the host process is LabVIEW! I'll add a note to the FAQ to explain this further.
I can't immediately see anything wrong with your build process. Did you move the relevant DLLs to the labview-zmq folder in <vi.lib>/addons? Windows DLL resolution is not the best, and it's strongly preferable to put the DLLs in the same folder. If you built it successfully and got the "can not be loaded" error it is almost certainly a path resolution issue.
I should be able to patch in the call this weekend. I saw in the example a non-library call get_monitor_event() that also looks useful; are there any other necessary function calls?
Cheers,
Martijn
Oh, thanks, I see the dereferencing now:
sock_obj *s ---> s->sock
zmq_proxy comes to mind, though I was able to work around it following the "Simple request-reply broker example".
Thanks,
Blaz
Last edit: Blaz Kelbl 2016-08-04
Hi,
As a follow-up, I implemented the socket_monitor and proxy calls in the repo, but had some problems with testing that reveal some further work needs to be done. Specifically, since zmq_proxy() occupies the calling thread, termination semantics are complicated, and in my initial tests my socket monitor wasn't receiving any messages. I'll look into it more when I have some time, otherwise feel free to play around with it yourself.
Cheers,
Martijn
Hi,
thanks for the socket_monitor implementation. I'll complie the code and try it ASAP. Do you have any ETA on when will you publish a new version of the ZMQ VI package. The product I'm working on, woul have to have a versioned vi package included, and though I can continue developement with my own dll's I'd really prefer to use an official version.
Regards,
Blaz
Last edit: Blaz Kelbl 2016-08-09
Hi,
Sorry, I moved house yesterday and have a lot going on right now. I would prefer not to package and release until I have a working test VI, but if you need it I can do an alpha release this weekend.
Cheers,
Martijn
Hey,
I fully understand and appreciate that you don't want to release without propper testing. An alpha release would be great if not too much of a hassle - perhaps I could provide some feedback based on my application. So I'm looking forward to the alpha release.
Thank you very much for all the help and for being so responsive!
Blaz
Hi again, I believe the socket monitor is working now; I've just released v3.4.0, which includes the socket monitor and an example showing how to use it.
As a follow up, the VIP is now available from the project page, and I've updated the FAQ with more information about internals, and some details about how the socket monitor works -- http://labview-zmq.sourceforge.net/?faq#monitor
Hi,
I based my project code on your example in my project and works perfectly.
Thank you!
Hi Martijn,
do you perhaps know when the new vi package will be available via the VI package manager?
Best regards,
Blaz
Hi,
It was released in v3.4.0.104 on 18/08 so it should already be available.
Cheers,
Martijn
Hi,
I completely forgot that the vi 0mq package isn't visible in the VIPM repository and was downloaded and installed manually from this site in the first place.
Sorry for the false alarm and best regards,
Blaz
I did look into distributing via the LabVIEW Tools Network a few years ago, but I didn't have time to write all the required documentation. I think they loosened the requirements a while back so it's something I could look into again.
Hi,
we discovered two problems with the latest lvzmq package:
1. the new typedef monitor_event.ctl isn'0t included in the lvlib file as the other typedefs are. While this problem doens't appear while you're in development mode, it pops out when you try to complie the code, including the "zeromq.lvlib", expecting all the dependencies to be included.
application.exe/1abvi3w/.....
If the execution priority is changed to "Above normal" or less as was in the .102 the problem dissapears.
Best regards
Blaz Kelbl
Hi Blaz,
Thanks for the report, I appreciate it. Everything should be "normal" priority to prevent thread switching overhead, so I've corrected that, and put the missing CTL in the LVLIB. I'll put out a new package tomorrow.
Cheers,
Martijn