I'm writing an application that will use ZMQ to communicate with another (C++) application being developed by another engineer. We are both using the Dealer setup for two-way communication, and the system is working fine when the application is run within the labview development environment.
However, ultimately the application will also publish a web page via LabVIEW's web services (http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/build_web_service/) so the application will be the 'startup vi' for an application which will be published to the web server.
Firstly, when starting the web service in debugging mode (http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/ws_debugging/), I found the system would hang such that the 'ZMQ read with timeout' would block parallel code execution - that is, I have a producer-consumer structure, and the producer ZMQ read would prevent the consumer loop from running. I was able to solve this by explicitly placing the ZMQ read in a 'timed loop' structure and specifying which processor it should run on. I also needed to do the same for the 'ZMQ destroy context' that would stop the producer loop (as per lazy pirate), otherwise it would not destroy the context because the parallel 'read' prevented it from executing.
With those problems solved, the application worked fine deployed to the debug server, and our applications could communicate.
However, the system has been very unstable, crashing the whole laptop. The exact cause has yet to be determined. I tried publishing the web page in non-debug mode (right-click->Application Web Server->Publish, rather than right-click->Start) but now ZMQ create context fails with the error:
"Call Library Function Node in zeromq.lvlib:zmq_context.lvclass:zmq_ctx_create.vi:5610001"
I'm at a loss here. I believe ZMQ error messages should have descriptions included in the installation, but they aren't. I managed to find a list of error codes, but 5610001 is not on it.
Using Labview 2015 SP1 on Windows 10 64-bit.
Any help appreciated, I (or my colleague!) would really prefer not have to abandon ZMQ at this point!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi there,
I've never tested ZMQ as part of a WebService in LabVIEW before, so I don't know if there are different symantics with per-DLL memory that could be coming into play. There are a couple of surprising things indicative of issues that I have not seen before
Blocking "any thread" calls (requiring explicit placement on another CPU)
Unknown error number 5610001
Instability of entire system
Can you create a minimal web server application that has this behaviour that I can use for testing? (Please export to LV2012)
I am concerned that the error you see if spawned by the Call Library Node and not from zmq_errno.vi. Any anticipated error should be produced inside this helper VI and not from the Library Node itself. Generally the Library Node only creates errors on seg faults or similar, which would possibly be a difference between running in Debug and Runtime environments.
The blocking behaviour you saw makes me think that Web Services are default restricted to a single thread, so maybe there are other things that are different about the execution model as well.
I've attached a debug build of the DLL which will create %TEMP%\lvzmq-err.log. Please replace the DLL, run the application once and send me the log file.
Hi Martiijin,
Thanks a lot for your help and quick response. Unfortunately the application and the machine it's on are used for an experiment at a national lab, and the ZMQ component is not 100% necessary (at least at the current time), so we're running without it and i'm a bit limited on the times at which I can do debugging. I do apologise for this.
For the moment though, other issues aside, the error being generated during publishing seems to come from the create context, and I've posted a screencap of the relevant portion of code, which is very standard. I would imagine the minimum steps necessary to reproduce would just be: an empty vi that creates a context, closes it, and writes any errors to file. Set this as the startup vi of a web resource. Web publish the result via Application Web Service->Publish, and you should see an error in your file from the context creation. Could you try this and see what happens?
Wrt the other issues:
- The idea that web services are restricted to a single thread sounds plausible... The computer it's running on is a fairly terrible AMD E1-6010 APU with just 2 cores, if that makes any difference. (probably not).
- As for errors - just to check; do you need to feed all zmq nodes' error out into the zmq_errno.vi to get a translation? So far all my errors have been non-descriptive 'labview doesn't recognise this error number'. Somewhere or other I found a list of error codes and their meanings, and i've been using that. Of course, this error number isn't in it.
- I have copied over the new ZMQ dll, and i'll try it the next chance I get, but this may not be for a few days I'm afraid.
Cheers,
Marcus
Last edit: m 2016-05-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh, on the subject of the instability of the system, it's looking like this may be (at least partly) unrelated to ZMQ. I've disabled the ZMQ sections of code for now, and the laptop still occasionally reboots itself without warning.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK I managed to take the system down and try your new dll. When I run the application in debug mode the lvzmq_err.log is created, but is empty (and no errors, in debug mode). But when I publish the system, the file isn't even created (and 5610001 error).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Marcus,
Sorry for the delay, I have been travelling a lot recently. There are a couple of things that catch my attention as odd here. Firstly the 5610001 error, which comes from LabVIEW and not ZMQ. This is clear firstly because that's not an error code I programmed in, and secondly because the error comes from the CLN directly and not from zmq_errno.vi. The only way that can happen is if it's an internal LabVIEW error.
Double checking the code, I was mistaken about the log file. There should be two files generated by the debug build: %TEMP%\lvzmq.log and %TEMP%\lvzmq-err.log. The first file contains debug messages from the LabVIEW interface, and the second contains error messages from libZMQ. If the second file was created but empty, then that's a good sign as it means libZMQ encountered no errors. But the file I need is actually %TEMP%\lvzmq.log, and it definitely should not be empty. Can you check it exists?
I am concerned that the file isn't even created when not run in debug mode. Again, I suspect something strange about running the VI as a web service. I should have time to run some tests on this today or tomorrow and get back to you. Can you send me a screenshot of the 5610001 error?
Cheers,
Martijn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Martijin.
I'm afraid I can't see any lvzmq.log; no files even vaguely hinting at lvzmq are generated from the web published application. From the applications in development environment, i get a lvzmq-err.log, but as i say, it's empty.
I've been testing whether this is actually just part of a wider problem with built applications and haven't been able to even build the testrepreq.vi in the source files directory.
Initially I just opened the file, went to tools->Create Built Application from vi, and followed through. This gave me an error that turned out to be due to it expecting lvzmq64.dll in the data support folder, but that wasn't automatically included. When I create the data folder and copied the dll in there, i got a complaint about "failed to load dynamic library because of missing external sybols or dependencies, or because of an invalid file format. (error 13).
Is this indicating I need to be including ZMQ into my projects and builds somehow?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is odd; the two log files should definitely be created by the debug build. But while I look into that, yes, you absolutely have to manually include the DLLs into the built application. This is because of a flaw in how LabVIEW handles cross-platform libraries, which is a known problem. The solution I've gone with means that you have to include the relevant DLLs in the Data directory when you distribute. You need both lvzmq64.dll and libzmq64.dll otherwise you will get dependency errors. It would be a good idea to include all 4 DLLs because the runtime environment might be different from what you anticipate, leading to corrupt DLL calls.
Unfortunately DLL resolution issues are complicated, and distributing with the application is the best way to go. Installing into the system directory is another option but I think that is less desirable because of potential version conflicts ("DLL hell").
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Getting a screenshot of the application is actually a little tricky - the front panel of the application gets stripped out when it gets published, since interface is by the labview web application server. I have tried to set up the front panel for remote access but haven't succeeded. Still, it'd just be a standard error out control indicating:
error code: 7
Call Library Function Node in zeromq.lvlib:zmq_context.lvclass:zmq_ctx_create.vi:5610001->read caen.vi->read caen.vi.ProxyCaller
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ok with all dlls in the data directory i've been presented with a dialogue for the various vi's being called - starting with zmq_version.vi. I've pointed labview at it, but it tells me "VI version is too early (10.0) to convert to the current Labview version (15.0f2)"
The file is obviously compatible since i can open it, but simply opening and re-saving the source file so it has version 15 returns the same error regardless.
Last edit: m 2016-06-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK this makes some more sense now. The error code is 7. The number 5610001 is an internal VI reference that states which node failed - this is probably only useful to NI who have internal debugging tools. If you explain error on code 7, you see it's "File Not Found", which since it comes from the CLN means the DLL was not found.
The point about including the DLLs isn't in the FAQ so I'll add it.
To quickly update all the files, go to the install directory (LABVIEW\vi.lib\addons\zeromq) and open the project library (zeromq,lvlib) to load them all into memory. It should automatically recompile the VIs, and you should be able to do File>Save All (not Save As).
This perplexes me though - did you install using VIPM? Because VIPM should automatically have upgraded the VIs to your installed version of LabVIEW.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Aha, progress!
I installed by VIPM, IIRC I saved the vip file from the downloads page and transferred it to the system using scp, then installed with VIPM. The system is on a private controlled network with no direct internet access, so it was a little awkward.. but i think that's how i did it.
I resaved everything, but now I'm getting:
"Hex (0x626) cannot open a file with separated compiled code in the LV runtime engine.
An error occurred loading zmq_version.vi Load error code 59. The source files' compiled code has been separated, and this version of Labview does not have access to separated compiled code."
Last edit: m 2016-06-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah yes, those national lab networks. Have you checked the LabVIEW runtime versions match? I can't say I know enough about how LabVIEW internals work to give you a good explanation of what that error message means.
It looks like SOME of the VIs are set to have separate code from compiled version. You can change this in the VI settings (Ctrl+I) for each one. Looking through the VIs, the ones that appear to be affected are all the zmq_recv, zmq_send, and zmq_poll VIs. I'm not sure why only these ones, it wasn't intentional. Disabling this "separation" for those VIs is the best fix I can come up with right now.
Edit: If you want to remove the code separation parameter, it affects more VIs than I originally thought
Last edit: Martijn Jasperse 2016-06-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Martijin,
I removed, redownloaded an reinstalled from vipm the zmq library again, just to make sure i hadn't accidentally done something strange (although I can't think what). I have a feeling the version number is different, but without changinging anything else, the zmqrepreq test application now, once built, actually made it past opening a context without errors. It did still get stuck at opening a connection - so I swapped in the debug dll again, and... well, the error vanished, and the tests all succeeded. :)
So I've now managed to build an application with ZMQ, but I'm still somewhat stuck on achieving this with web pulishing. As i understand it, when the web resource is published, labview creates a zip file of all it's dependencies, uploads it to the application web server, which then unzips it and starts it going. I'm currently at a loss as to where I can step into this procedure and specify some support dlls that need to get bundled along into a suitable 'data' directory. It does however seem like a much more generic labview problem at this point, so i should be able to get support from NI or the labview forums on how to achieve that. We'll see what happens then - hopefully that'll be it!
Last edit: m 2016-06-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, well it's not what i'd call a solution, but a workaround. I still don't know how to include a suitably located support directory in a web published application, but if you specify the dll by name only (i.e. modify the zmq_libpath.vi), and labview can't find it, it'll search some standard locations for it - locations in the path environmental variable, system32, the vi search path specified in the .ini file associated with the .exe (not relevant) and the vi search path specified in the tools->options menu (not sure if relevant for built/published). I tried all of these, but i tried them all before finding they only worked when specifying by name, so i don't currently know which one(s) did the trick. I'll update later if narrow it down or find a better solution, but for now, ZMQ is replying over web. :)
Thanks for your support Martijin, and your work on building ZMQ for LabVIEW to begin with.
Last edit: m 2016-06-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey, glad you found a solution! There are some other things that could be tried. I can modify a script I created a while back that will modify all CLN calls to use direct library names instead of zmq_libpath.vi. This means LabVIEW will resolve the path itself before deployment and the dependency handler should determine the necessary DLLs. There are annoying technical reasons why this is not the default solution, but you can modify the VIs with the script after they are installed by VIPM.
For interest, the solution when building a straight EXE is include the DLLs in the project and then modify the Build Specifications to "Always Include" the DLLs ("Source Files" options) and then tell LabVIEW to put those DLLs in the Support Directory ("Source File settings"). The example application has the correct settings. You are correct in pointing out this information is nowhere in the FAQ.
Also, the most recent version of LabVIEW I have access to is 2012, which has a different form of the web interface (https://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/build_web_service/) than 2013 and newer. Again, because it is configured through a "Build Specification", the above solution works. But I guess it doesn't apply to the newer style server.
Glad you're finding the library useful! As a FOSS project I don't have much time to work on it, but I try to support it where possible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Attached is a script that recodes all the CLNs to use a hardcoded lib path that should fix path resolution issues in built applications. Run this and it will modify all the installed package VIs for future use. Then try redeploying the application and checking if it helps. In the unlikely event it messes something up, uninstall and reinstall with VIPM to revert the changes.
But if you're fine with the current fix then great!
hi,
Thanks for the script. Right now as the system is up and functional I'd prefer not to take it down, but I've saved a copy and will give it a try later just to see if it does indeed solve the problem.
Thanks also for the tip on including the dlls into builds; that sounds pretty straightforward. I had looked for a method of that kind, adding the dlls to the project and making them always included, but as you've noticed LV2015 doesn't seem to offer standalone builds for web services. If i get any replies from NI on how it should be done, i'll copy them in here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have happily found this thread while trying to build a Labview 2018 exe that I need to run in a W10 64-bits. I've included the .dlls in the built in project (following the FAQ method) but I fail when trying to execute the application in this OS . The application has been built in a W10 64bits system. When I include only the lvzmq64.dll and libzmq64.dll I get error code 7 from zmq_ctx_create.vi. If I add lvzmq32.dll and libzmq32.dll I get error code 13. When I run the exe in a W10 32 bits machine, the application seems to work without error... I am very puzzled and, of course at the end I need to run this in a W10 64 bits VM ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm writing an application that will use ZMQ to communicate with another (C++) application being developed by another engineer. We are both using the Dealer setup for two-way communication, and the system is working fine when the application is run within the labview development environment.
However, ultimately the application will also publish a web page via LabVIEW's web services (http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/build_web_service/) so the application will be the 'startup vi' for an application which will be published to the web server.
Firstly, when starting the web service in debugging mode (http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/ws_debugging/), I found the system would hang such that the 'ZMQ read with timeout' would block parallel code execution - that is, I have a producer-consumer structure, and the producer ZMQ read would prevent the consumer loop from running. I was able to solve this by explicitly placing the ZMQ read in a 'timed loop' structure and specifying which processor it should run on. I also needed to do the same for the 'ZMQ destroy context' that would stop the producer loop (as per lazy pirate), otherwise it would not destroy the context because the parallel 'read' prevented it from executing.
With those problems solved, the application worked fine deployed to the debug server, and our applications could communicate.
However, the system has been very unstable, crashing the whole laptop. The exact cause has yet to be determined. I tried publishing the web page in non-debug mode (right-click->Application Web Server->Publish, rather than right-click->Start) but now ZMQ create context fails with the error:
"Call Library Function Node in zeromq.lvlib:zmq_context.lvclass:zmq_ctx_create.vi:5610001"
I'm at a loss here. I believe ZMQ error messages should have descriptions included in the installation, but they aren't. I managed to find a list of error codes, but 5610001 is not on it.
Using Labview 2015 SP1 on Windows 10 64-bit.
Any help appreciated, I (or my colleague!) would really prefer not have to abandon ZMQ at this point!
Not much to specify in terms of coding considering the error is occurring at the create context node.
Hi there,
I've never tested ZMQ as part of a WebService in LabVIEW before, so I don't know if there are different symantics with per-DLL memory that could be coming into play. There are a couple of surprising things indicative of issues that I have not seen before
Can you create a minimal web server application that has this behaviour that I can use for testing? (Please export to LV2012)
I am concerned that the error you see if spawned by the Call Library Node and not from zmq_errno.vi. Any anticipated error should be produced inside this helper VI and not from the Library Node itself. Generally the Library Node only creates errors on seg faults or similar, which would possibly be a difference between running in Debug and Runtime environments.
The blocking behaviour you saw makes me think that Web Services are default restricted to a single thread, so maybe there are other things that are different about the execution model as well.
I've attached a debug build of the DLL which will create %TEMP%\lvzmq-err.log. Please replace the DLL, run the application once and send me the log file.
Cheers,
Martijn
Last edit: Martijn Jasperse 2016-05-27
Hi Martiijin,
Thanks a lot for your help and quick response. Unfortunately the application and the machine it's on are used for an experiment at a national lab, and the ZMQ component is not 100% necessary (at least at the current time), so we're running without it and i'm a bit limited on the times at which I can do debugging. I do apologise for this.
For the moment though, other issues aside, the error being generated during publishing seems to come from the create context, and I've posted a screencap of the relevant portion of code, which is very standard. I would imagine the minimum steps necessary to reproduce would just be: an empty vi that creates a context, closes it, and writes any errors to file. Set this as the startup vi of a web resource. Web publish the result via Application Web Service->Publish, and you should see an error in your file from the context creation. Could you try this and see what happens?
Wrt the other issues:
- The idea that web services are restricted to a single thread sounds plausible... The computer it's running on is a fairly terrible AMD E1-6010 APU with just 2 cores, if that makes any difference. (probably not).
- As for errors - just to check; do you need to feed all zmq nodes' error out into the zmq_errno.vi to get a translation? So far all my errors have been non-descriptive 'labview doesn't recognise this error number'. Somewhere or other I found a list of error codes and their meanings, and i've been using that. Of course, this error number isn't in it.
- I have copied over the new ZMQ dll, and i'll try it the next chance I get, but this may not be for a few days I'm afraid.
Cheers,
Marcus
Last edit: m 2016-05-27
Oh, on the subject of the instability of the system, it's looking like this may be (at least partly) unrelated to ZMQ. I've disabled the ZMQ sections of code for now, and the laptop still occasionally reboots itself without warning.
OK I managed to take the system down and try your new dll. When I run the application in debug mode the lvzmq_err.log is created, but is empty (and no errors, in debug mode). But when I publish the system, the file isn't even created (and 5610001 error).
Bump. Need this fixed or we'll have to abandon ZMQ and go to normal TCP sockets. Anyone?
Hi Marcus,
Sorry for the delay, I have been travelling a lot recently. There are a couple of things that catch my attention as odd here. Firstly the 5610001 error, which comes from LabVIEW and not ZMQ. This is clear firstly because that's not an error code I programmed in, and secondly because the error comes from the CLN directly and not from zmq_errno.vi. The only way that can happen is if it's an internal LabVIEW error.
Double checking the code, I was mistaken about the log file. There should be two files generated by the debug build: %TEMP%\lvzmq.log and %TEMP%\lvzmq-err.log. The first file contains debug messages from the LabVIEW interface, and the second contains error messages from libZMQ. If the second file was created but empty, then that's a good sign as it means libZMQ encountered no errors. But the file I need is actually %TEMP%\lvzmq.log, and it definitely should not be empty. Can you check it exists?
I am concerned that the file isn't even created when not run in debug mode. Again, I suspect something strange about running the VI as a web service. I should have time to run some tests on this today or tomorrow and get back to you. Can you send me a screenshot of the 5610001 error?
Cheers,
Martijn
Hi Martijin.
I'm afraid I can't see any lvzmq.log; no files even vaguely hinting at lvzmq are generated from the web published application. From the applications in development environment, i get a lvzmq-err.log, but as i say, it's empty.
I've been testing whether this is actually just part of a wider problem with built applications and haven't been able to even build the testrepreq.vi in the source files directory.
Initially I just opened the file, went to tools->Create Built Application from vi, and followed through. This gave me an error that turned out to be due to it expecting lvzmq64.dll in the data support folder, but that wasn't automatically included. When I create the data folder and copied the dll in there, i got a complaint about "failed to load dynamic library because of missing external sybols or dependencies, or because of an invalid file format. (error 13).
Is this indicating I need to be including ZMQ into my projects and builds somehow?
That is odd; the two log files should definitely be created by the debug build. But while I look into that, yes, you absolutely have to manually include the DLLs into the built application. This is because of a flaw in how LabVIEW handles cross-platform libraries, which is a known problem. The solution I've gone with means that you have to include the relevant DLLs in the Data directory when you distribute. You need both lvzmq64.dll and libzmq64.dll otherwise you will get dependency errors. It would be a good idea to include all 4 DLLs because the runtime environment might be different from what you anticipate, leading to corrupt DLL calls.
Unfortunately DLL resolution issues are complicated, and distributing with the application is the best way to go. Installing into the system directory is another option but I think that is less desirable because of potential version conflicts ("DLL hell").
Getting a screenshot of the application is actually a little tricky - the front panel of the application gets stripped out when it gets published, since interface is by the labview web application server. I have tried to set up the front panel for remote access but haven't succeeded. Still, it'd just be a standard error out control indicating:
error code: 7
Call Library Function Node in zeromq.lvlib:zmq_context.lvclass:zmq_ctx_create.vi:5610001->read caen.vi->read caen.vi.ProxyCaller
OK, I'll try sticking all the dlls in and see if we get anywhere. I hadn't seen that posted in the FAQ, did I miss it?
Fingers crossed!
ok with all dlls in the data directory i've been presented with a dialogue for the various vi's being called - starting with zmq_version.vi. I've pointed labview at it, but it tells me "VI version is too early (10.0) to convert to the current Labview version (15.0f2)"
The file is obviously compatible since i can open it, but simply opening and re-saving the source file so it has version 15 returns the same error regardless.
Last edit: m 2016-06-07
OK this makes some more sense now. The error code is 7. The number 5610001 is an internal VI reference that states which node failed - this is probably only useful to NI who have internal debugging tools. If you explain error on code 7, you see it's "File Not Found", which since it comes from the CLN means the DLL was not found.
The point about including the DLLs isn't in the FAQ so I'll add it.
To quickly update all the files, go to the install directory (LABVIEW\vi.lib\addons\zeromq) and open the project library (zeromq,lvlib) to load them all into memory. It should automatically recompile the VIs, and you should be able to do File>Save All (not Save As).
This perplexes me though - did you install using VIPM? Because VIPM should automatically have upgraded the VIs to your installed version of LabVIEW.
Aha, progress!
I installed by VIPM, IIRC I saved the vip file from the downloads page and transferred it to the system using scp, then installed with VIPM. The system is on a private controlled network with no direct internet access, so it was a little awkward.. but i think that's how i did it.
I resaved everything, but now I'm getting:
"Hex (0x626) cannot open a file with separated compiled code in the LV runtime engine.
An error occurred loading zmq_version.vi Load error code 59. The source files' compiled code has been separated, and this version of Labview does not have access to separated compiled code."
Last edit: m 2016-06-07
Ah yes, those national lab networks. Have you checked the LabVIEW runtime versions match? I can't say I know enough about how LabVIEW internals work to give you a good explanation of what that error message means.
It looks like SOME of the VIs are set to have separate code from compiled version. You can change this in the VI settings (Ctrl+I) for each one. Looking through the VIs, the ones that appear to be affected are all the zmq_recv, zmq_send, and zmq_poll VIs. I'm not sure why only these ones, it wasn't intentional. Disabling this "separation" for those VIs is the best fix I can come up with right now.
Edit: If you want to remove the code separation parameter, it affects more VIs than I originally thought
Last edit: Martijn Jasperse 2016-06-07
Hi Martijin,
I removed, redownloaded an reinstalled from vipm the zmq library again, just to make sure i hadn't accidentally done something strange (although I can't think what). I have a feeling the version number is different, but without changinging anything else, the zmqrepreq test application now, once built, actually made it past opening a context without errors. It did still get stuck at opening a connection - so I swapped in the debug dll again, and... well, the error vanished, and the tests all succeeded. :)
So I've now managed to build an application with ZMQ, but I'm still somewhat stuck on achieving this with web pulishing. As i understand it, when the web resource is published, labview creates a zip file of all it's dependencies, uploads it to the application web server, which then unzips it and starts it going. I'm currently at a loss as to where I can step into this procedure and specify some support dlls that need to get bundled along into a suitable 'data' directory. It does however seem like a much more generic labview problem at this point, so i should be able to get support from NI or the labview forums on how to achieve that. We'll see what happens then - hopefully that'll be it!
Last edit: m 2016-06-08
OK, well it's not what i'd call a solution, but a workaround. I still don't know how to include a suitably located support directory in a web published application, but if you specify the dll by name only (i.e. modify the zmq_libpath.vi), and labview can't find it, it'll search some standard locations for it - locations in the path environmental variable, system32, the vi search path specified in the .ini file associated with the .exe (not relevant) and the vi search path specified in the tools->options menu (not sure if relevant for built/published). I tried all of these, but i tried them all before finding they only worked when specifying by name, so i don't currently know which one(s) did the trick. I'll update later if narrow it down or find a better solution, but for now, ZMQ is replying over web. :)
Thanks for your support Martijin, and your work on building ZMQ for LabVIEW to begin with.
Last edit: m 2016-06-08
Hey, glad you found a solution! There are some other things that could be tried. I can modify a script I created a while back that will modify all CLN calls to use direct library names instead of zmq_libpath.vi. This means LabVIEW will resolve the path itself before deployment and the dependency handler should determine the necessary DLLs. There are annoying technical reasons why this is not the default solution, but you can modify the VIs with the script after they are installed by VIPM.
For interest, the solution when building a straight EXE is include the DLLs in the project and then modify the Build Specifications to "Always Include" the DLLs ("Source Files" options) and then tell LabVIEW to put those DLLs in the Support Directory ("Source File settings"). The example application has the correct settings. You are correct in pointing out this information is nowhere in the FAQ.
Also, the most recent version of LabVIEW I have access to is 2012, which has a different form of the web interface (https://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/build_web_service/) than 2013 and newer. Again, because it is configured through a "Build Specification", the above solution works. But I guess it doesn't apply to the newer style server.
Glad you're finding the library useful! As a FOSS project I don't have much time to work on it, but I try to support it where possible.
Attached is a script that recodes all the CLNs to use a hardcoded lib path that should fix path resolution issues in built applications. Run this and it will modify all the installed package VIs for future use. Then try redeploying the application and checking if it helps. In the unlikely event it messes something up, uninstall and reinstall with VIPM to revert the changes.
But if you're fine with the current fix then great!
hi,
Thanks for the script. Right now as the system is up and functional I'd prefer not to take it down, but I've saved a copy and will give it a try later just to see if it does indeed solve the problem.
Thanks also for the tip on including the dlls into builds; that sounds pretty straightforward. I had looked for a method of that kind, adding the dlls to the project and making them always included, but as you've noticed LV2015 doesn't seem to offer standalone builds for web services. If i get any replies from NI on how it should be done, i'll copy them in here.
No worries; if it's working for you then no reason to change it. Hope it continues to work well for you!
Hello Martijin,
I have happily found this thread while trying to build a Labview 2018 exe that I need to run in a W10 64-bits. I've included the .dlls in the built in project (following the FAQ method) but I fail when trying to execute the application in this OS . The application has been built in a W10 64bits system. When I include only the lvzmq64.dll and libzmq64.dll I get error code 7 from zmq_ctx_create.vi. If I add lvzmq32.dll and libzmq32.dll I get error code 13. When I run the exe in a W10 32 bits machine, the application seems to work without error... I am very puzzled and, of course at the end I need to run this in a W10 64 bits VM ...