Copyrighrt (c) 2014-2020 UPVI, LLC

Live HDF5 Version 1.2.0 in Beta

Published: Wednesday, 16 September 2020

After a very long hiatus, a new version (1.2.0.91) of Live HDF5 is available and in beta. In terms of functionality, the new version is primarily bug fixes. However, it has also been upgraded to include with HDF5 version 1.12.0. The new version is still released in LabVIEW 2015 VIs so that it should remain compatible with every currently supported version of LabVIEW. It has been primarily tested under the 32-bit LabVIEW 2020.

This beta version is only available from the UPVI website. After it has been more thoroughly vetted, I will upload a release version to the NI Tools Network. Please report any problems with the beta in the Forum.

Click here to be directed to the download page for version 1.2.0.91. Install using the VI Package Manager. Double-clicking clicking the file should work.

Changes since Version 1.1.1.86

  • Upgraded to HDF5 version 1.12.0*
  • Ported VIs to match
  • Added H5Fstart_swmr_write
  • Upgraded to MSVCRT 142 (Required by HDF5 upgrade)
  • Fixed several bugs that caused access violations when writing and especially reading string attributes.
  • Made the "Type" input on LVH5Tcreate_*_type required to help avoid such bugs in the future

*Notes on the upgrade to HDF5 1.12.0

The upgrade to version 1.12 of HDF5 caused a few major changes to Live HDF5. Most of the changes should be transparent to upgrading uses, but are worth pointing out.

  1. The HDF group no longer distributes a 32-bit version of the Windows DLL. Therefore, the versions of HDF5 included with Live HDF5 1.2 are built in-house by UPVI so that a 32-bit version of the DLL may be generated. They are built directly from the HDF5 tarballs.
  2. Between version 1.10 and 1.12 of HDF5, the underlying datatype of all of the HDF5 identifiers (hid_t) changed from 32-bit to 64-bit integers. This necessitated changing the way in which the identifiers are stored in LabVIEW (they are now implemented as LabVIEW classes) and also required changing the call parameters of essentially every VI in the library. While I believe that this conversion is complete, if you are getting unexpected errors about invalid identifiers, a likely culprit an improper return type (32-bit rather than 64-bit integer) on an External Library Node return type.
  3. Because the ABI changed again, the GetH5FileDriver.vi is currently broken.