Activity for Martijn Jasperse
-
Martijn Jasperse posted a comment on ticket #28
Thanks for the report. The bug was fixed in commit [720f2a] and is included in release v2.15.0
-
I had another go at updating the permissions - hopefully you can create a ticket now, although I will look towards migrating to github at some point soon. Feel free to shoot me an email to arrange a chat; m-dot-jasperse-at-gmail-dot-com. My timezone is AEST which can be awkward depending on where you are, but we can probably find something that works. Cheers, Martijn
-
Hi, It should not be necessary to include the EXT and LIB files - those are build artifacts and are not used by LabVIEW. However when you say "the two HDF5-related DLLs" that is not correct; you require ALL the distributed DLLs for the target architecture. They are required to be separate files per their licensing conditions, which is why there are several of them. Unfortunately Windows itself does not provide any diagnostic information when failing to load a DLL - it just reports "failed" and does...
-
Hi Paul, Sorry again for missing this - thanks for the descriptive scenario; it's not something I had considered myself previously. The dimensionality restriction was originally applied for sanity-checking in the C library because there was a lot of complexity on the LV side for higher-dimensional arrays. The implementation means you can always perform a read as either a "flat" 1D array (irrespective of the stored dimensionality), or as an array of equal dimension to the stored array. So for this...
-
Hi Paul, Very sorry I never noticed your forum posts; I had just changed jobs in May and I guess I completely lost track of my inbox. Thanks for reporting that issue with the datatype. Probably my preference would be to raise a ticket in SF, although it's a bit clunky. Did you end up forking in-house? Would be very happy to upstream any fixes or improvements you made, although in the past there have been issues due to my ancient LV2010 edition and my preference to continue to support older LV editions,...
-
Thanks for the kind words about this project, always nice to hear that my work has been useful to someone! It's been a long time since I worked on this project - is that call to H5LVget_variant_dims() part of one of the library VIs or is it part of your code? Edit: Sorry, I missed that you mentioned it's H5Dappend.vi. I think probably it makes sense to try to detect this scenario and skip the dataset operations since that just wasted CPU cycles LabVIEW represents "empty" arrays in several possible...
-
Thanks for the kind words about this project, always nice to hear that my work has been useful to someone! It's been a long time since I worked on this project - is that call to H5LVget_variant_dims() part of one of the library VIs or is it part of your code? LabVIEW represents "empty" arrays in several possible ways - one of which is to pass around a NULL pointer as a placeholder. So sometimes code breaks on empty arrays because it expected a valid pointer and got NULL, which is a hard-fault condition....
-
Hi, Apologies for the late reply as I was on vacation. I guess I forgot to update the CHANGES file, so I've gone back and updated it now. There is an updated version in both the repo and attached to this post. The primary change was updating from HDF5 v1.8.X to v1.10.X and exposing some of the new functionality that was made available in that version. Additional bug fixes are listed are listed in the file. Cheers, Martijn
-
I think it should be possible, it's just not implemented yet. The problem is not the writing arrays of strings to H5 on the LabVIEW side, but rather the unclear specification for the MAT file definition of a string array. A string array is an "array of variable length arrays" and I think MATLAB uses a fairly complicated way to describe such nested structures - but I don't have MATLAB so I never looked into it. The MATLAB handling code was originally contributed by community members. One ugly solution...
-
Hi - sure I would love contributions! Particularly in C since that's easier to merge. I'm not using SF much any more but I presume you can fork and open a merge request. Sorry for not responding to this sooner, I think my notifications were getting blocked.
-
Hi, Sorry I didn't get around to looking at this more, I have been swamped with work the past few months. I haven't worked with any options since DRAFT was added, as there is additional complexity there. My understanding of ZMQ paradigms probably counts as "classic" now, since those are the network structures that led me to wrap the library in the first place. The paradigms can be a bit confusing, particularly as the example implementations tend to use blocking calls. Hope you were able to work something...
-
Hi, The actual license details are in LICENSE.txt. The ZeroMQ library is licensed under LGPL and my contributions are 3-clause BSD. Both licenses are sufficiently permissive for commercial distribution, and IMatix has a special exemption clause. I think GPL.txt is only there for historical reasons; I can't remember when ZeroMQ swapped to a dual-licensing model but it was quite a while ago. Cheers, Martijn
-
Hi, The DLLs need to be in a subdirectory called "data" relative to the application EXE. I believe this is standard practice with LabVIEW compiled applications, although for various compatibility reasons LabVIEW doesn't correctly locate the DLLs automatically during the build process and you have to copy them manually. Since the code looks for this "data" directory, you're getting file-not-found in the CLN. Make sure to copy all the DLL dependencies as well to avoid load errors. Cheers, Martijn
-
Hi, ZMQ functions have to be exposed via the wrapper DLL to ensure that they are invoked via the same library instance, and avoid segfaults. I prefer using wrapper functions to ensure pointer validation and error handling are done correctly. It's easy enough to add wrapper functions to zmq_labview.c if you let me know which functions you think should be exposed. Cheers, Martijn
-
Hi, For particular sockets like ROUTER/DEALER, the routing_id is the first part of a multipart message. This is how a ROUTER server can ensure that a response gets delivered to the correct client when it managing multiple connections simultaneously. This is called the message "envelope" and is described here: https://zguide.zeromq.org/docs/chapter3/#The-Simple-Reply-Envelope, in particular figures 28 and 29. The idea is that you receive a multipart message which starts with the identity blob, process...
-
Well that's a memory access bug for sure, probably memory alignment related. Can you identify whether the crash happens on a read or a write operation? Are you using arrays of clusters? If so, what is your cluster structure? Can you produce a simple example that reproduces the issue? Cheers, Martijn
-
Yes that is correct. Using "/" in a name is unsupported because that is the internal path delimiter for HDF5. Creating a dataset called "A/B" is indistinguishable from a dataset called "B" in a group "A". I doubt HDF5 will let you do this and I think the behaviour might be undefined if you try to force it. Cheers, Martijn
-
Hi guys, Sorry I didn't see this earlier. I've never actually developed on MacOS so I really doubt I can provide much insight as to the steps required - particularly as regards different library packing formats. Happy to merge any makefiles or otherwise if you have some success though. One thing I'll mention is that according to this LAVA post, LabVIEW can directly load dylibs since 2011, although that support was pretty unclear back when I was writing this library. You should just be able to modify...
-
Hi Bas, Thanks for reporting this issue! The problem was in identification of the ENUM type and yes there is a simple fix for it. I've just uploaded v2.14.3 with the correction. Cheers, Martijn
-
I finally got around to booting up my old LabVIEW computer to build the package. I uploaded v3.6.2 with the proxy change. Cheers, Martijn
-
Hi, Based on my experience with HDF5 I would recommend that what you actually want is to use a group, where each image you stream is a new dataset in that group with associated measurement metadata, instead of trying to construct a compound object with the idea of it being one dataset. There are a number of reasons for this 1. It is less sensitive to data corruption. If the file is corrupted somehow you can recover uncorrupted datasets. Using one dataset all the data will be lost. 2. It is more space...
-
You can find the error code values and descriptions in zmq-errors.txt. The error value shown means EFSM: Operation cannot be accomplished in current state This is common when using strict socket types - particularly REQ and REP, which must alternate between send and receive operations. REP cannot simply receive, it must reply. EFSM typically indicates that a different socket type is applicable to your intended design pattern. ROUTER is a simple replacement, but perhaps PUB/SUB is more applicable...
-
Hi Patrick, Thanks for posting your results, it sometimes comes up when users want to package the DLLs but have to manually select them. The difficulty is that the 32-bit and 64-bit dependencies have the same filenames, so it's not trivial to just include all the DLLs. Maybe LabVIEW is smart enough to pick the ones appropriate for the target you're compiling for? Interesting there is such a difference between putting the DLLs as members of the class versus members of the library. Cheers, Martijn
-
Hi Sandhya, When using the DEALER/ROUTER paradigms, you need to use multi-part messages. I recommend using the multi-part VIs instead of using the "more" option manually. The attached example shows the simple version where there is only one attached REP socket. Cheers, Martijn
-
Very glad to hear you were able to get it working! Thanks for providing the compiled SO, I'm sure your experience getting it to work will be very helpful for anyone else trying to get this running on NI RT. Cheers, Martijn
-
I changed the behaviour of H5Squery in v2.14.2 which should fix the original issue. Cheers, Martijn
-
Just as an addendum, I finally got around to making a new build (v2.14.2), in which I added H5Sunlimited.ctl to clarify the value of the "unlimited" dimension and prevent strange behaviour related to type casting. I am surprised that converting the DBL to U64 did that! Cheers, Martijn
-
Hi Francisco, I can't reproduce this behaviour on my system, so I suspect the problem is with the pointer offsets around the NumericArrayResize in the library, which is quite poorly documented by NI and is complicated to use correctly (also there are variations between different versions of LabVIEW). Can you try using H5Sget_dims.vi? If that works I think I will make H5Squery a wrapper around this instead to avoid the "undocumented pointer magic". Cheers, Martijn
-
Hi Francisco, This relates to how HDF works internally in that it represents dimensions as unsigned. You can wire in H5S_UNLIMITED for any dimension by converting -1 to a U64 using the Numeric > Conversion palette (it will come out as U64_MAX which is a very large number). I thought about representing max_dims as signed, but that breaks convention with HDF5, so I decided against it at the time. But perhaps using signed I64 would be clearer - LabVIEW can't handle array sizes with lengths >32-bit anyway....
-
Almost certainly it's due to memory alignment. There are differences "under the hood" between LabVIEW on different operating systems which matter for efficient data IO as is used in this library. To avoid such problems requires costly/slow datatype conversions getting data in/out of the library, but on the other hand it can cause a lot of crashes in getting it right. The relevant documentation is here: https://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/how_labview_stores_data_in_memory/,...
-
Hello Bas, You need to install "libhdf". Any standard distro package manager should provide it precompiled or ported (you will likely need the "devel" version if your distro uses that terminology) and I included it precompiled for Windows. It's a bit difficult for Linux because of dependencies and admittedly I have no idea how it is handled on NI RT Linux - I've never developed for such a system myself. You can always try compiling it from source if there are no binaries available: https://www.hdfgroup.org/downloads/hdf5/...
-
Hi Francisco, Yeah that will work ok - you can use the "NAN" comparison node to verify if a DVR is valid if you want to ask permission instead of forgiveness :) I updated zmq_proxy.vi to do this - you can grab it straight from the repo. If that works I'll do a package rebuild later. Cheers, Martijn
-
Hi, Sorry I must have missed the notification on this one. I presume all that is required is a working GCC setup but I don't use OSX so I'm not sure what that involves on that system. The LabVIEW part is called "cintools" in your install directory which needs to be linked against the h5labview library. You should be able to find some information from NI about setting up a build environment relevant to you (check the documentation for Code Interface Node). It's possible that LabVIEW for Mac has some...
-
Oh, yes. H5close should never be used directly :) It is a last resort to force library cleanup in the case of memory leaks, but it should not be required in normal use. Every HDF call will fail until the library is explicitly reinitialised, which again should not be done directly.
-
Hi, That seems very strange - it should work. Are you able to run variant-io.vi in the examples folder? You could try specifying the object name as ".", which may help. Otherwise I can make a debug build to generate a log file. Cheers, Martijn
-
The two main version numbers are the LabVIEW package (v3.5.1.109) and the ZeroMQ library contained inside the package (v4.0.4). In terms of protocol-compatibility the library version is more relevant, and in terms of using it in LabVIEW the package version is more relevant. The protocol is implemented in C in ZeroMQ, and the LabVIEW package just provides access to the functionality within.
-
Should be fixed in 2.14.1.147
-
That's a large cluster you have! You are correct, I will make the change.
-
Sorry, MacOS is not a supported platform for this project. I'm not a Mac developer so I can't generate the library files necessary to make it work on Mac.
-
Thanks for pointing that out! The dependency check is now both broken and unnecessary. I've generated a new build, hopefully that works better.
-
Here's a build to try. I think it might need some tweaking - I'm not sure it makes sense having the DLLs in the parent directory for LVLIBP but in the "data" directory for embedded. This build also provides encryption support (PLAIN or CURVE) Regarding the DLLs, to be sure of the dependencies, you should take all the DLLs in the lib/win32 or lib/win64 directory as appropriate. Moving to the official binary builds means following their naming convention. Also, the MSVC runtimes were causing sufficiently...
-
Hi Joseph, Is your installation of LabVIEW 32-bit or 64-bit? The error arises if there is an inconsistency between the architecture of LabVIEW, HDF, and their dependencies (including runtime libraries). This is unfortunately a somewhat common issue so in the latest package (v2.14) I've included all the first-order dependencies. It would be good to know if that helps with the issue you describe. Cheers, Martijn
-
I started writing h5labview back in 2011 as part of a lab control and monitoring system for my PhD work. It was never intended to be the end-all solution to data storage, but provided a useful subset of the full HDF5 functionality. As HDF5 has matured, its functionality has expanded and some of that was supported in h5labview. However, I haven't been an active LabVIEW user since 2016 and no longer have interest in developing it further. However I may still do maintenance updates for some issues....
-
Thanks for the suggestion; I have put this implementation into the library.
-
The portability issues was fixed in 1.10.x, so it's not an issue and hid_t should be I64 everywhere - if it isn't it will produce errors like this. I need to remove references to 1.8.x so people know to use 1.10.x
-
It's pretty likely to be the MSVC runtime DLLs - if you don't have the same version of the runtime then it's likely it will fail to load and give error 13. Most PCs end up having a huge number of parallel MSVC versions installed by different apps - which is probably why it succeeds on most machines, but not on a blank VM. Most likely you need msvcr100.dll, which you can get here: https://www.microsoft.com/en-us/download/details.aspx?id=8328
-
Hi Niels, Thanks for the suggestion to change the libpath VI, I have rolled it into the next update. I'm changing the project to use the official DLL builds, but this produces a naming problem because the 32 and 64 bit DLLs have the same filenames. For now I have put them in different subdirectories, but when compiling would it be preferable to just have the applicable DLLs in the parent directory as you suggest above? Cheers, Martijn
-
Thanks for pointing out this bug - you are correct, this particular function call is inconsistent. I think there is a wider issue regarding hid_t portability between the 32-bit and the 64-bit builds, but that will likely need to be checked separately.
-
Ok there are a few issues here. Firstly, don't use HDF5-1.12 - it's extremely new and not well-supported yet. HDF5-1.10 is considered stable so install that instead. Any advice about DLL workarounds only applies to specific versions of HDF5 - if you have DLL hell then likely it is related to the specific version of HDF5 you have installed. You might even want to install the specific version of HDF5 linked to from the project homepage, because I can't make guarantees that it will just work with any...
-
Thanks for letting me know it works. The API documentation suggests it should be possible to set the HWMs after bind/connect, but from my experience it is best to do beforehand and ensure that the changes take effect immediately.
-
The SNDHWM and RCVHWM are different - make sure to set the RCVHWM on the receiver. I also recommend setting any socket options before bind or connect to ensure they propagate correctly. I suspect the timed loop on the receiver will make it worse because 1kHz is very slow. An extremely short delay in the sender is a better approach - the earlier example you had used a delay of 1us which is very quick, but sufficient to do the job.
-
My guess is that without the delay, the messages queue up faster than they are removed, so the number of messages is exceeding the high-water mark (HWM) and some messages are silently dropped. By default this is 1000 messages but you can increase it with the setsockopt VI. It would be worth considering whether this is a realistic sceanrio though - do you really expect to have several thousand messages in the queue at once? I would suggest that's evidence of needing to change your protocol as opposed...
-
Are you using h5labview? Or are you using CLNs directly as per the other thread? h5labview currently uses v1.10.1 so I don't follow the comment about v1.8.18. I doubt it has anything to do with the OS itself, but more likely the DLL installation on that computer - DLL hell is called that for a reason. Potentially the "installer choking" is an indication you have a problem here. Do you have a minimal example of code that crashes (exported to 2010)?
-
It depends on several details; I would not expect the file size to change after each flush. The main reason for this is that HDF5 preallocates space when you have chunked datasets with variable dimensions in order to save time on costly IO operations rebuilding the file when you expand the dataset. The outcome is that the file size will increase, but not after each write - or even after each chunk. HDF is flexible but not minimal - i.e. it may take up more disk space than strictly necessary for the...
-
Yes, this is referred to as the "high water mark" in the documentation. You should be able to use zmq_setsockopt to set ZMQ_RCVHWM and/or ZMQ_SNDHWM to 1. This must be done on the socket after creation but before connect/bind. Looks like there's a new option called ZMQ_CONFLATE but it seems that interacts badly with multipart messages so it's probably not preferable.
-
My rough understanding is that compiling for the RTOS corresponds to VxWorks so that means 64-bit aligned and therefore the presently-used value is incorrect. Again, my expectation is that the 32-bit RTOS would be 4-byte aligned and the 64-bit RTOS would be 8-byte aligned. I believe the code has been used successfully on 32-bit RTOS, which appears to contradict this, but I have encountered many situations where the documentation is incomplete or missing a corner case. Regarding thread safety, you...
-
Thanks for your input, sorry I've been swamped with work lately. I suspected there would need to be a modification to the alignment for 64-bit RTOS; I thought I had put one in already but evidently not. I expect LVALIGNMENT should be 8 so it should just be a case of modifying the preprocessor check around zmq_labview.c:56 to check SIZE_MAX to determine the native pointer size - or similar. Basically the alignment should be native - except on WIN32, where it's unaligned. Debugging all that caused...
-
Thanks for your input, sorry I've been swamped with work lately. I suspected there would need to be a modification to the alignment for 64-bit RTOS; I thought I had put one in already but evidently not. I expect LVALIGNMENT should be 8 so it should just be a case of modifying the preprocessor check around zmq_labview.c:56 to check SIZE_MAX to determine the native pointer size - or similar. Basically the alignment should be native - except on WIN32, where it's unaligned. Debugging all that caused...
-
Hi Mark, To (over)simplify, ZMQ handles all that in the background. It is a bit hard to get your head around if you're used to TCP because most of it comes from the framework of many-to-many network topology, so I'd recommend reading the "guide" for details. To summarize the main differences as I see them Connect/disconnect is handled in the background; this is hidden from the application (although "socket_monitor" exists if you need to know about it) Bind and Listen return immediately, even if no...
-
It'd be great if you could provide some more detailed instructions on compiling for real-time x64, which is a platform I've never worked with myself! I'm not especially keen on putting conditional disables in the zmq_libpath.vi because of a large number of inconsistencies with how that's treated by the mass-compile process under different versions of LabVIEW. I had used conditional disables originally and had to switch away from doing that because of several user-reported issues and I've prefer not...
-
Hmm, it's not clear if it is possible to be honest, because of the following statement: The library ships with HDF5 version 1.8.13. You may upgrade this to later versions by replacing the files hdf5.dll and hdf5_hl.dll in the vi.lib/UPVI/lvhdf5 directory. Of course, such an upgrade is not guaranteed to function, but it probably will. How LabVIEW handles multiple copies of the same DLLs but with different versions is not clear. I have never tried to have them installed at the same time, but I think...
-
This sounds very challenging! You'll have to write your own version of "unpickle" to interpret the data. Unfortunately "The data format used by pickle is Python-specific [...] however it means that non-Python programs may not be able to reconstruct pickled Python objects." I think it would be more realistic to rewrite your python app to use a more portable serialisation convention for data on the wire. I expect that attempting to unpickle the binary data will be a rabbit-hole of complexity, even...
-
That doesn't surprise me at all. A custom DLL that handles exactly your use-case and nothing else will always be faster than a general purpose library - especially in LabVIEW. The overhead comes from type-processing and converting, which is done on a per-call level. This permits "adapt to type" behaviour at the expense of speed. So if it's too slow then use a different method, which you already have. This is a free project after all.
-
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...
-
Thanks for the update! Glad to know it's not an issue with the library itself, even if it's counter-intuitive how some of the socket types relate to eachother. Good luck with developing your application.
-
To confirm, the exact same code worked on LV2015? Are both the old and new LV versions 64-bit? How many parts are involved in each message? Does LabVIEW hard crash or just never return from the CLN call? What value of timeout did you use? There should be no problem using different contexts, it just adds overhead but helps overcome some thread-safety issues. Have you tried the same pattern with the DEALER and REQ in different VIs? What happens when you press the STOP button?
-
The warnings indicate that the version of libzmq you have installed was not built with the draft APIs enabled. Remember, the RADIO/DISH pattern is not included in the standard release yet, which is why ZMQ_BUILD_DRAFT_API is required. The compiler complaining about implicit declarations means they were not built in the version you have installed (probably the openSUSE default). Try downloading a compatible binary release from http://zeromq.org/intro:get-the-software (with DRAFT APIs) I don't see...
-
No you cannot use the DLL under Linux. You have to build your own SO and you need some familiarity with the make process for that. Evidently you do not have the zmq devel headers installed on your build system. I am cannot test x64 Linux myself and NI have released very little information on this platform's internals so I do not know if it will work. I suggest reading up on building shared libraries.
-
Shared Objects are not like DLLs; the Linux way is to recompile on your host system as per your host dependencies. I think it is unlikely this will work by just using the binary built on my system but you can try regardless.
-
I've tested building on Linux and with a few minor fixes (now in the repo) it seems to work fine. Previous users have also reported it working on cRIO so it should be fine. If you encounter any specific issues please lodge a bug report.
-
Updaing the library shouldn't break anything significant- I had to add a terminal to the zmq_send VI which means you'll have to relink any VIs that call that one directly, but this is a quick process. There have been no major changes since the last release. The library has previously been debugged and used for LabVIEW Linux, although it has been some time since that was last tested. I have not tested it with the IPC protocol but I don't forsee any problems. I think there is scope to get that working...
-
Hi, glad to hear the library has been useful to you! My understanding is that RADIO and DISH types are presently still in DRAFT status, although they are included in the most recent stable release so I don't see why they couldn't be used. Didn't seem like a lot of work, so I went ahead and did it. I bumped the library to 4.3.1-stable with drafts enabled so support is there, and added the required extra functionality since messages must be marked with a group (annoyingly the doco doesn't exist so...
-
Hi, what link functionality do you require? Internal or external links? The library is basically in maintanence mode, but I don't think simple links would take a lot of effort to implement
-
Ah my mistake, you also need the new libzmq32.dll or it will fail to load (attached) which is presumably the cause of the error 42.
-
Hmm, there's some "magic" internals involved in lvzmq_get_monitor_event() that I'll need to check on. I'm guessing this is LV2017-32bit? I've attached a debug build which will generate a log file in %TEMP%/lvzmq.log. Please run your example and send the log file. Also, have you tried executing the socket_monitor.vi example - does that work or crash?
-
Further updated in r264 because of complexities in how TERM is handled. We can't use Reap? in the TERM call because that closes a socket that is being held in a blocking state. So now lvzmq_poll() closes the sockets if ETERM is received.
-
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.
-
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...
-
Recv with event is broken
-
Updated in r263. The problem was that the context termination didn't finish because the socket wasn't closed, and the socket close was waiting for the context termination to finish. Solved by using Reap? option. Keeping the socket_close external to the loop but not making it dependent on the error out causes a potential disaster condition where the close occurs during a send_multipart call.
-
Mutex locking on pointers
-
DVR paradigm performs this function reliably, ceased using MUTEX locks in the C code in r243 and removed in r262
-
Provide socket_monitor
-
Initially implemented in r237, fixed in r244, rewritten in r257 to be compatible with libzmq4.
-
I ran into some trouble compiling against the previous official libzmq build because of issues with MSVC, but the new build (v4.2.5) works just fine. Tests and examples appear to work properly. It's up on the repo if anyone wants to test it, will package a release soon. Cheers, Martijn
-
Hi, Can you confirm whether your host OS and LV are both 32-bit? Back in the day it was only 32-bit on Linux but that might not be true any more. Try running zmq_libpath.vi and check that the path name it generates is correct. Try opening the C DLL call in zmq_ctx_create and setting the path instead of specifying it on the diagram; LV provides some better error-checking when you do this but is less portable because of known packaging bugs. Cheers.
-
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...
-
Hi, Apparently I missed your post. Race conditions can cause crashes because it violates a precondition of the underlying zeromq library. ZMQ is not thread-safe and LabVIEW is inherently multithreaded. That's why it's important not to split context or socket wires wherever possible. My library includes a system for tracking which objects are in use and attempts to clean them up - when the project is closed that's when this system fires and cleans everything up. Basically once an assertion failure...
-
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...
-
Hi Carlo, Some progress has been made in implementing this, but it is not at the point of being stable due to complexities within LabVIEW's internal memory manager. H5T_VLEN is not a recommended structure though, and it may be more useful/portable to write that cluster as a group.
-
Hmm, it looks like B3D explicitly does not support HDF5 v1.10.x at the moment (https://git.embl.de/balazs/B3D). I'm in the middle of migrating h5labview over to 1.10 and I'd rather not fork it. Not sure why 1.10 is unsupported; could be they just haven't looked into it yet. In principle filters should be compatible I think? Could be worth contacting them about if you're keen on that filter in particular.
-
Hey, Glad you figured it out; evidently it wasn't the same test you did in Python? According to the API docs (http://api.zeromq.org/4-2:zmq-setsockopt) the property only exists on ZMQ_REQ, ZMQ_REP, ZMQ_ROUTER, ZMQ_DEALER sockets... but I'm pretty sure it's used by other types too (e.g. ZMQ_PUB) Cheers
-
1.10 is a major change to how HDF5 works internally and will enable a large number of new features - such as SWMR, virtual datasets, better filters, and performance improvements (see https://support.hdfgroup.org/HDF5/docNewFeatures/). IMO these things will benefit the research community at large because we often use (very) large datasets over long recording times. Importantly v1.10.X-enabled files cannot be read by v1.8.X so at some point the migration is necessary even if new features are not used...
-
Ok that was a lot more work than I expected since the repo was halfway through being converted to the 1.10-branch - this is a lot of work because they changed hid_t, among lots of other compatibility issues. For now I'm going to do an update based on v1.8.20, which was the last official build for both 32 and 64-bit Windows. The repo (set e1d0d86a5b01) has the requested change. Please test it to confirm it is stable. I looked into H5Pset_fapl_direct, and the reason it doesn't appear is because H5_HAVE_DIRECT...
-
Hi Adam, Sorry I didn't get back on this sooner. I will look at doing it today. Cheers, Martijn
-
Hi Greg, No worries, this should be easy - I'll change it to only generate a default FAPL if none is specified. I'm considering if CLOSE_STRONG should be set even if a FAPL is provided because it's so much harder to keep track of open handles in LV, and since they're persistent across a LV session it leads to memory leaks. Do you have a feeling on that? Regarding the second point; the HDF5 functions are only exposed via h5labiew.dll if they are specified in the DEF file. I just need to regenerate...
-
Hi Adam, Currently GZIP is available through H5Pset_deflate.vi. I'll add custom filters to the requested features list. There are some serious issues related to pathing and custom filters that are not yet resolved in the developer mailing list, so IMO it's not necessarily ready for prime-time yet. But GZIP and SZIP are built into the DLL and always available. Cheers, Martijn
-
PS check out the variant-io.vi file in the examples/ directory to see it in action, if you haven't already. There's also variant_read.vi and variant_write.vi in the tests/ directory which show it works on more complicated compound types.
-
Hi Luke, There should be no issue reading out a variant dataset at runtime since gradually changing datatypes is exactly why I wrote the read/write variant VIs. If it doesn't work that's a bug in the library, although NI does not document the internal variant interface so it's possible the implementation details change with some new version of LabVIEW and it stops working; but the code itself is stable and tested up to LV2016. Looking at your implementation though, the 60056 error is because you...
-
Thanks for the comment and link to ealier discussion, this seems like a good approach as well!
1 >