First, thank you for a well written and continuously maintained package. H5 has made many aspects of our data analysis much smoother, and using H5 would not have been feasible without this package. I'm running into a weird issue when appending data to a file where appending data takes >1 second, when it normally takes around 0.1 seconds. I've tracked it down to a long time delay from the H5Dprepare_append VI, and this will happen when the file size is relatively small. I've tested this with the append...
I am not clear about the license files to include with an open source LabVIEW project using h5labview. I am assuming that the HDF5 license file is needed (https://ncar.github.io/VaporDocumentationWebsite/licenses/hdf5License.html), but what about the h5labview toolkit itself?
For any future developers, here are the steps that allowed me to release a compiled executable which is currently working on both windows 10 and windows 11 machines without Labview installed: Add a virtual folder to your labview project. Here we will add the necessary .dll files as detailed below Navigate to the h5labview directory in windows explorer, for example: C:\Program Files\National Instruments\LabVIEW 2020\vi.lib\addons\h5labview2 Search the folder for '.dll'. Add the following 6 .dll files...
For any future developers, here are the steps that allowed me to release a compiled executable which is currently working on both windows 10 and windows 11 machines without Labview installed: Add a virtual folder to your labview project. Here we will add the necessary .dll files as detailed below Navigate to the h5labview directory in windows explorer, for example: C:\Program Files\National Instruments\LabVIEW 2020\vi.lib\addons\h5labview2 Search the folder for '.dll'. Add the following 6 .dll files...
For any future developers, here are the steps that allowed me to release a compiled executable which is currently working on both windows 10 and windows 11 machines without Labview installed: Add a virtual folder to your labview project. Here we will add the necessary .dll files as detailed below Navigate to the h5labview directory in windows explorer, for example: C:\Program Files\National Instruments\LabVIEW 2020\vi.lib\addons\h5labview2 Search the folder for '.dll'. Add the following 6 .dll files...
For any future developers, here are the steps that allowed me to release a compiled executable which is currently working on both windows 10 and windows 11 machines without Labview installed: Add a virtual folder to your labview project. Here we will add the necessary .dll files as detailed below Navigate to the h5labview directory in windows explorer, for example: C:\Program Files\National Instruments\LabVIEW 2020\vi.lib\addons\h5labview2 Search the folder for '.dll'. Add the following 6 .dll files...
Thank you for this discussion! I was able to get my executable working in no time!
Does anyone know if its possible to read an ENUM attribute from an HDF5 file using the H5labview toolbox? If so could you share a snippet? I'm interested in mapping the values to the names in the ENUM.
Does anyone know if its possible to read an ENUM attribute from an HDF5 file using the H5labview toolbox? If so could you share a snippet?
How can I programmatically change the column names in a dataset. For a cluster I can only change the labels in the LabVIEW development environment and not during runtime. Is there a LabVIEW example for this?
Rebuilt DLLs with waveform fix, bump VIPB to v2.15.1
waveform: Fixed null-termination in timeval_to_str
test: Added test case for default fill value
Added H5Pset_fill_value for defining default dataset value
Updated H5Sselect_simple to enforce correct array dimensions
Thanks for the report. The bug was fixed in commit [720f2a] and is included in release v2.15.0
H5Dread_var - filespace datatype incorrect
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
Actually - I dont seem to be able to raise a ticket, the button is greyed out on that page... Thanks Paul
Hi Martijn, Will raise a ticket in a sec. No, we didnt fork, but ended up not using/needing that function anyways. 2010 seems surpsingly old, even for universities... We went 8.6 --> 2012 -->2017 --> and now 2021... I think a shift of repository to one of the online git platforms would be sensible for sure (we run with git on bitbucket, but I have grabbed stuff from github and gitlab before. I did manage to clone the mercurial repo but it took a while to remember how (I actually would have preferred...
Hi Martijn, Thanks for the response - we did indeed end up using the reading as a 1D and then reshaping in the end and found that worked well. Thanks!
This fix seems to be working fine. Thanks for the quick response!
You are correct. I had made sure I had all the DLLs I could find in vi.lib/addons/h5labview2/lib/win64 included in the data folder but this did not work for me, so I believe I may have dragged everything from that folder into my data folder and this worked. I thought therefore that the only two new files I had added were those two. Looking closer at my project, I realized that the hdf5.dll I was including was the one in LabVIEW/resource, which was a different version (2016) than the one included...
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...
OK, I think I just answered my own question: it seems that not only does one need to include all DLLs in the vi.lib/addons/h5labview2/lib/winXX folder, but also the .ext and .lib files. At least that fixes the error I was encountering.
As previously reported regarding 2.14 - when the binaries were supposedly included with the package, obviating the need to install the actual HDF5 library from the HDF5 website, I am still unable to release an exe using the library. The build works fine (and needless to say, the app works fine when in development mode), with the two HDF5-related DLLs neatly copied in the data folder of the released app, but when running the code, as soon as h5labview2 code is called, the exe returns an error 7 (generic...
Bump VIPB to v2.15.0, updated CHANGES
H5LVread: drop requirement for matching dimensionality on slice readout
H5Dread_var: Fixed file_space data type
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,...
test: Adding early waveform read/write tests
test: Added unit testing for H5Dappend, including empty append
H5Dappend: Fixed constness on C library call
test: Mark test as failed if error is raised
H5Dappend: Fixed handling of unlimited dimension
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...
Added NULL pointer checking to H5LVget_variant_dims
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, First of all I need to say we love your toolkit and we use it all the time. So during one of our projects we encountered a hard crash of LabVIEW and we could only investigate this by checking the DMP file LabVIEW creates when a crash happens. The DMP file brought us to the H5LVget_variant_dims function, and after isolating the stuff we were doing, we found out that trying to append an empty array is causing the issue, see the image attached. the thing is, we only see this crash on Intel based...
Hi, First of all I need to say we love your toolkit and we use it all the time. So during one of our projects we encountered a hard crash of LabVIEW and we could only investigate this by checking the DMP file LabVIEW creates when a crash happens. The DMP file brought us to the H5LVget_variant_dims function, and after isolating the stuff we were doing, we found out that trying to append an empty array is causing the issue, see the image attached. the thing is, we only see this crash on Intel based...
Hi, First of all I need to say we love your toolkit and we use it all the time. So during one of our projects we encountered a hard crash of LabVIEW and we could only investigate this by checking the DMP file LabVIEW creates when a crash happens. The DMP file brought us to the H5LVget_variant_dims function, and after isolating the stuff we were doing, we found out that trying to append an empty array is causing the issue, see the image attached. the thing is, we only see this crash on Intel based...
Hi, First of all I need to say we love your toolkit and we use it all the time. So during one of our projects we encountered a hard crash of LabVIEW and we could only investigate this by checking the DMP file LabVIEW creates when a crash happens. The DMP file brought us to the H5LVget_variant_dims function, and after isolating the stuff we were doing, we found out that trying to append an empty array is causing the issue, see the image attached. the thing is, we only see this crash on Intel based...
We want to use hdf5 to store (possibly quite large) multi-dimension data sets. We're acquiring waveforms from an oscilloscope and changing a configurable number of variables (or dimensions) per waveform. For example, we might be acquiring these waveforms having our detector at points along a line in space, or points on a plane or points in 3D etc and we're hoping to store the data in a data set with the same number of dimensions. The storing bit works fine, we have tested with multi-dimension arrays...
Hiya, thanks for your last reply on version info changes. We're looking to actively use this toolkit now in a project and it would be good to know how things like bugs we may come across can be handled... As a for instance, I have found a bug in the H5Dread_var.vi - the filespace input on the front panel/connector pane is currently an i32 integer, but file spaces are 64 bit. Attempting to wire a filespace to read only part of a dataset results in an error because of this. This is a simple bug that...
Updated CHANGES for releases from 2.13.1 to 2.14.3
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
Hi, we're looking into using the hdf5 format for an application. I was just wondering what had changed in the latest version of this toolkit - the changes.txt file only shows the changes up to ver 2.13.0 but the package is at 2.14 now. What's different between 2.13 and 2.14? Thanks!
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...
I'm using this to convert a .tdms-file to .mat. In the .mat-file I want to store the channel names as an array of strings. When doing this i get this error: matlab_write.vi:4890002<err> Arrays of strings unsupported</err> Accoring to the "Variant I/O" on this page: https://h5labview.sourceforge.io/?examples it looks like the string array is possible. I tried this conversion (string array to variant) but with no luck. Is StringArray possible with .mat-files?
I am trying to install the h5 library, but I am getting the following error. Main Package Name: Hierarchical Data Format (HDF5) v2.13.1.143 Package Name with Error: Hierarchical Data Format (HDF5) v2.13.1.143 Error Message: VIPM could not install the package h5labview2-2.13.1.143 . Error Code: 7 Error Source: PostInstall.vi<err> Could not load HDF5. Ensure HDF5 v1.8.13 or newer installed. ===============</err> I am tried it for LabVIEW 2019 32 and 64 bit. In both I am getting the same error. How...
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
I have written a program for the analysis of Scanning Transmission X-ray Microscope (STXM) data which is pretty popular with users and is distributed in the form of a LabVIEW executable. I would like to add the ability to read HDF5 files to it. However, I can't seem to get a simple executable to work. When I try to make an executable out of the simple-write.vi example and run it, it dies with error 7 :Call Library Function Node in H5F.lvlib:H5Fopen.vi:6750001->simple-write.vi, even when I put the...
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
Hi there. I have been using the h5labview extension for storing a total of approximately 4000 unique data sets (separated into approx 36 groups, each containing approx 38 subgroups and, within each subgroup, 3 files). The process seems to run smoothly for a large number of readings but will eventually, at a random time, encounter the following access violation error which seems to be attributed to opening external files (please see attached image). I have definitely identified that it is the part...
Noted. Thanks.
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
Version 2.13.1.143 Unless I am mistaken, using a slash character in a dataset name results in an error 60032: Error 60032 occurred at H5Equery.vi Possible reason(s): Error in H5Dcreate2: unable to create dataset - H5D__create_named: unable to create and link to dataset - H5L_link_object: unable to create new link to object - H5L_create_real: can't insert link - H5G_traverse: internal path traversal failed - H5G_traverse_real: component not found. Does this sound realistic? Removing the '/' character...
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...
I haven’t had time to look at it these days. I have had a series of crisis. I would like to get back to it though so thanks for the nudge. I am glad that you are interested in a MacOS version. I am not sure how to build a framework from a dylib but I will look into it. It should not be that hard…. ? Recompiling the tabview shim was as far as I got. But https://stackoverflow.com/questions/7562793/how-do-i-create-a-working-framework-with-dylib-files-in-xcode-4/7563064 may have some help. I use fink...
Hi Scott- did you get anywhere with this? I'm keen to build h5labview for MacOS too, and have just come back to this since first looking at it last July...! I'm utterly clueless on building "real" (non-LabVIEW) software, however I note your commands were building a .dylib- but the library path constant in the VIs is looking for a .framework. And inspecting the Windows makefile, I see it Includes the LabVIEW cintools. -but beyond that, I have no idea what I'm doing... Any guidance much appreciated!...
Just curious whether anyone has managed to release executables that actually run properly with the new version.
Hi Martijn, Thank you for fixing it this quick.
Bump VIPB to v2.14.3
Fixed bool detection in H5LVquery_type by permitting H5T_ENUM class in validation
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
For our project we save some hdf5 attributes, and to make this more generic we create key value pairs where the value is a variant. So writing the key value pairs to the HDF5 file works fine and I also get to see the correct datatypes when I open the HDF5 file in the HDF5 viewer, but when I try to read an attribute which has data type boolean, I get an error. When I dig deeper in the code I see that an error occurs in the Query Type vi, which calls the H5LVget_type method in the library. this dll...
For our project we save some hdf5 attributes, and to make this more generic we create key value pairs where the value is a variant. So writing the key value pairs to the HDF5 file works fine and I also get to see the correct datatypes when I open the HDF5 file in the HDF5 viewer, but when I try to read an attribute which has data type boolean, I get an error. When I dig deeper in the code I see that an error occurs in the Query Type vi, which calls the H5LVget_type method in the library. this dll...
For our project we save some hdf5 attributes, and to make this more generic we create key value pairs where the value is a variant. So writing the key value pairs to the HDF5 file works fine and I also get to see the correct datatypes when I open the HDF5 file in the HDF5 viewer, but when I try to read an attribute which has data type boolean, I get an error. I looks like this is a bug in the library. I've created a test vi to run in the test suite to show where it errors. This vi is also added to...
In running on MacOS it seems to not be a big issue. I have installed the HDF5.10 (using the package manger "Fink") and in running the gcc compile for linux with appropriate flags, I can build the dylib. % gcc -c -fPIC -I /opt/sw/opt/hdf5.v1.10/include/ -I /Applications/National\ Instruments/LabVIEW\ 2020\ 64-bit/cintools h5labview.c -o h5labview.o % gcc -dynamiclib -undefined suppress -flat_namespace h5labview.o -o h5labview.dylib Is it simple to link the call library functions to this new dylib?...
Martjin, Thanks for the follow-up, I really appreciate it as well as the additional comments of what to think about as well. Late yesterday after reading up more on the examples and experimenting a bit, i was able to get things saving information in a format I wanted. Not sure I ended up following all your suggestiong above though. 1. I think have created in essence 3 data sets, not sure if this is the same as the "grouping" approach you suggested 2. One dataset is strictly for images. In order to...
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...
I'm new the the h5labview library and am working on creating a data storage method where I am collecting images and other data in a streaming fashion. Ideally I would like to save each bit of data as a row in the hdf5 file i.e. Timestamp, X, Y, Z, I, J, K, image Where the majority of the data is just either a float or int, and then the image data attached to each data write / index if think of it as an array. I have review the save image example and can follow that such as I can save single images...
Removed H5LVget_space due to issues with LabVIEW memory alignment
Added H5Sunlimited.ctl to clarify unlimited dimensionality
Updated documentation of maxdims relating to unlimited dimension
Updated VIPB for v2.14.2
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
Thanks again for the reply, I took us a little while to get into this, but we finally got it working. Changing the LVALIGNMENT in the h5labview.h file did the trick. After building the new .so file we got all the tests working. I've added the so file to this post for others that run into the same problem.
Hi Martijn, I see, it does look like something obscure is happening there. I checked and H5Sget_dims.vi has no problems, so it could be wrapped directly. Thanks again! Best, Francisco
Hi Martijn, Thanks for the explanation! I actually think the representations are clear as they are. I see that wiring a -1 (I32 or I64) to a U64 input will always automatically convert it appropriately. Perhaps an explicit mention in the context help of H5Dcreate_simple that -1 should be I32 or I64 would help guys like me in the future. I was having some trouble with another piece of code, because the max_dim input was mistakenly a DBL and -1 (DBL) converts to 0 (U64). 🤦♂️ Best, Francisco
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....
Hi, When trying to obtain the dimensions of a dataset with H5Squery, the dims array output is erratic. I attach an example where I create different datasets and then I read their dimensions. I believe this related to some 32/64 bit issue. If I split the dimensions into higher and lower 32 bit number, the right value is available. I tried playing with how H5LVget_space is called in H5Squery: uint32_t H5LVget_space(const int32_t loc_id, const CStr obj, const CStr attr, Array1DUint64_t **hndl); I tried...
Hi, I'm creating extendable datasets. I understand that leaving unwired the max_dims input in H5DCreate_simple makes the first dimension extendable. This is fine and working for me at the moment But: if I wanted any other dimension extended, how do a I pass a negative number if the datatype is U64? Thanks, Francisco ps: I'm using version 2.13.1.143, but I check recent versions and it's the same.
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/,...
Thank you for your reply, this has given me some more insights on how to do this. So after a rollercoaster ride of trying to build the HDF5 library and modifying the make file to build your library on Linux, I have finally made some progress, but i'm also running into a few issues. I've added the build HDF5 library, the h5labview.so file and the makefile to this post, so if you want to use them, they are probably ready for all the NI RT Linux devices that have an x64 processor When I tried to run...
Thank you for your reply, this has given me some more insights on how to do this. So after a rollercoaster ride of trying to build the HDF5 library and modifying the make file to build your library on Linux, I have finally made some progress, but i'm also running into a few issues. I've added the build HDF5 library, the h5labview.so file and the makefile to this post, so if you want to use them, they are probably ready for all the NI RT Linux devices that have an x64 processor When I tried to run...
Thank you for your reply, this has given me some more insights on how to do this. So after a rollercoaster ride of trying to build the HDF5 library and modifying the make file to build your library on Linux, I have finally made some progress, but i'm also running in a few issues. I've added the build HDF5 library, the h5labview.so file and the makefile to this post, so if you want to use them, they are probably ready for all the NI RT Linux devices that have an x64 processor When I tried to run the...
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/...
Hello Martijn, We are creating an application for a PXI running NI RT Linux with LV 2020 installed. I'm not really familiar with building so files for linux, but I looked up how to build, so i prepped my NI RT device with the build tools (make, gcc, etc) and copied the contents of the lib directory to the device. I tried to build using gcc -c -fPIC h5labview.c -o h5labview.o but it gives me the error h5labview.h:19:10: fatal error: hdf5.h: No such file or directory #include <hdf5.h> ^~~~~~~~ compilation...
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 Martijn, I think I found the reason for this problem: it's me! :) I dropped a vi that calls H5close() directly on a location in my code that has nothing to do with hdf5 and forgot it there. This bypasses the h5labview-dll and seems to leave it in a corrupted state long before using hdf5-functions intentionally. After removing this vi, it worked fine. Sorry for all that noise and thank you... Christian