LabVIEW
Unzip files within labview
Brian K. wrote:Hi Rolf,
I was wondering if you had tested the new lvzlib.out file. For some reason when I run the a ZIP VI it causes the controller to hang. In particular at a Call Library Reference Node. Thanks.
I was hoping to get a CRIO system from a left over from a customer project sometimes soon but this seems to be delayed.
Maybe you can ask NI Netherlands to send me a loaner to test it 
As soon as I get to know more I will try to update this thread.
Rolf Kalbermatter
Brian K. wrote:Hi Rolf,
I think I am going to install VxWorks Bench and see what I can debug there. What is interesting that at no point is there a file made on disk. So it seems like either it is a file permissions, file path, or something else with file creation. After the ZLIB Open Zip Archive a zip reference is created, but when I use the "reference to file path VI" it gets Not a Path. I don't know if this is expected, but that is probably whereI'm going to start looking (i.e. the zipOpen2() function in lvzlib.out).
I was hoping an error would give me a clue, but I guess that would be too easy 🙂
You may be barking up the wrong tree. A ZIP or UNZIP refnum is not a real file refnum although I abusea datalog refnum for it. It's basically just a pointer to the underlaying data structure from the ZIP library that I typecast into a datalog refnum to make my own private LabVIEW refnum. So the LabVIEW refnum functions can not do anything with this (private) refnum.
Rolf Kalbermatter
Brian K. wrote:
Good call. What is actually happening is the zipOpen2() function at no point makes a file. I have yet to get VxWorks Bench installed, but hopefully that will happen this week. It also makes it tricky that at no point does an error occur. I give you an update later.
Well VxBench is no option for me since I don't have the license. I have to do with the Open Source variant of this. fopen() is one of the first operations that should be called in the zipOpen2 function and on most systems this should create the actual file too. I also just checked but it can't be that the vxWorks out file accidentially might try to call the win32 variant of the file operations (and I would guess such an error to make the out file unloadable since the external dependencies can't be resolved).
As soon as I get the cRIO I will try out some things on my own but it will likely have to be some fwrite() or something to a debug file I'm afraid 🙂
Rolf Kalbermatter
Brian K. wrote:Hi Rolf,
A little update. Part of the reason that the functions would not work is because in the VxWorks kernel there are stubs for functions with the same names as the functions in the .out. Thus everytime we would try to load the functions it would give a warning and prevent them from loading. Here is a list of the duplicate functions
Duplicate symbol:"uncompress" loading module lvzlib.out
Duplicate symbol:"inflateCopy" loading module lvzlib.out
The kernel seems to include the exact same library. Are you sure that are only stubs? Why would the kernel contain the entire zlib + zip library as stubs only?
It seems VxWorks has only one single global function table instead of one per dynamic module. This is VERY ugly. I'm surprised it does even work with a system like LabVIEW. Of course adding a prefix is a solution but will require changing all VIs on all platforms.
Rolf Kalbermatter
Hi Rolf,
So I talked it over with R&D to see why they only stub those functions instead adding them into the kernel. The reason has to deal with safemode on the controller. When we put it into safemode the controller loads the tiniest amount of OS from the non-volitile memory. zlib was added in because they need a way to uncompress files directly into memory, but nothing else. So in the kernel is literally a stripped down specialized version of zlib. There are currently no plans to change that functionality.
I did get it to zip on a VxWorks controller It turned out to be a bug in the ZLIB Compress Directory_ogtk.vi -> ZLIB Open Zip Archive.vi -> ZLIB Initialize File Functions__ogtk.vi The Call Library Function do not have all their parameters filled out for the function InitializeFileFuncs(). Leaving those off on other operating systems is fine because not defining them make it so the OS assumes NULLs. The problem is that on VxWorks it assigns blank parameters with 0xFF. I went ahead and put conditional disables in the code and put the corrected Call Library Function Node (to make sure that it does not effect other OSes).
So I guess to summarize:
1) Change all the conflicting function names to have lvzip_ prefixed. The source to that is attached. I also recompiled the DLL so that the Call Library Funtion does not get confused.
2) FTP lvzlib.out onto the controller in the ni-rt\system directory
3) Make the correction to InitializeFileFuncs() Call Library Function node, a few other house cleaning operations (conditional disables), and it works. I zipped the partially corrected (I only fixed Compress Directory.vi) library.
