RomainP

On 8/31/2022 at 10:02 AM, Rolf Kalbermatter said:

I can't right now work on that. But I have plans to do that in the coming months. The story behind it is that I did a little more than just to make it 64-bits.

- The file IO operations where all rewritten to be part of the library itself rather than relying on LabVIEW file IO. While LabVIEW 8.0 and newer supports reading and writing files that are bigger than 2GB, it still has the awful habit to use internally old OS file IOs that are naturally limited to only supporting characters in file names that are part of your current local and they also normally are limited to 260 character long path names. If your drive is formatted in FAT32, that is all the drive can do for you anyhow, but except for USB thumb drives, you would be hard pressured to find any FAT formatted drives anymore. So having these limitations in the library feels very bad.

These two things are specially a problem on Windows. Mac is slightly less problematic and Linux has long ago pretty much solved it all internally in the kernel and surrounding system libraries.

- Modern ZIP files support things like symbolic links and I wanted a way to support them. For Linux and Mac that is a piece of cake. For Windows I may for now not be able to seamlessly support that as creating symlinks under Windows is a privileged action, so the user has to either be elevated or you have to set an obscure Developer flag in Windows that allows all users to create symlinks.

So in summary there was a lot of work to be done, most of it actually for Windows. Most of that is done but testing all that is a very frustrating job. And the non-Windows targets will then also take some more time for additional testing and making things that were modified for Windows compile again properly.

So yes, it's still on my to-do list and I'm planning to work on it again, but right now I have another project that requires my attention.

Because of the significant changes in the underlying shared library and internal organization of the VIs it will be almost certainly version 5.0. The official library API (those nice VIs with a green gift box in them) should remain compatible but if you want to make use of the new path name feature to fully support long path names with full character support, you may have to change to the new API, with the library specific path type, although if you use high level library functions, internal long path names will be ok, you just won't be able to access them with the normal LabVIEW file functions if they contain non local ANSI characters or are to long! It's the best I could come up with without the ability to actually changing the LabVIEW source code itself to add that feature into the internal Path Manager in LabVIEW. 😀

The according File Utilities Manager functions in the library will also be available for the user in a separate palette.

OK, thank you. Please keep us informed.

On 3/22/2022 at 9:40 AM, Rolf Kalbermatter said:

However, be aware that the github code as is is an experiment in construction. Lots of things don't work right yet and there are many bugs in the underlaying shared library that simply won't do the right thing yet. I'm slowly working on it but it is a side project and sometimes I just don't feel like debugging C code very much.

An official release of OpenG Zip with support of LabVIEW 64 bit would be great. Currently this library is the last one preventing our team from switching to LV 64 bit.
 

The Beta of LabVIEW Community Edition is now available at http://ni.com/beta

MPSSE SPI done !  https://lavag.org/files/file/291-mpsse-spi/

Hello Benoit.

Thank you for your library ! But I have done few modifications to be able to use it :

I2C Device Read.vi :

- cluster "options" changed ("Acknowledge bit" renamed "Not Acknowledge bit", "Not Acknowledge bit" and "Reserved bit" inverted)

- conversion from and to string for "Data" deleted => Be able to receive also bytes with a value of 0.

MPSSE I2C.zip