LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Unzip files within labview

Got that problem worked out. I didn't have the proxy setup right on the VPM connection settings so I wasn't getting any of the openG libraries.

 

New bigger problem:

 

LVzip is currently not compatible with LabVIEW 2009. The problem has been reported to OpenG http://forums.openg.org/index.php?showtopic=1071&st=0&gopid=2947&#entry2947

 

LabVIEW not being able to zip on crio natively is really frustrating. I will be tranfering data larges file from a distributed system. Being able to zip the files would have saved me like 250 mb per day and over 7.5 gigs of transfer monthly.

---------------------------------
[will work for kudos]
0 Kudos
Message 51 of 91
(2,529 Views)

I'm going to take a look at this either tonight or tomorrow and will try to get a new package pushed out as soon as possible.

 

Rolf Kalbermatter

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
Message 52 of 91
(2,527 Views)

A new version (2.5.1) of the OpenG Zip Tools has been released and published on the VI Package Network for download using VIPM.  This adds support for LabVIEW 2009.


Special thanks to Rolf for fixing the issues! 

0 Kudos
Message 53 of 91
(2,490 Views)

Problems:

 

I installed the new version of the package. I then created a test vi that just zipped up the files in a directory on the crio. When I tried to run/deploy the vi, here was the report

 

Initializing...
Calculating dependencies...
Checking items for conflicts. This operation could take a while...
Preparing items for download. This operation could take a while...
Deploying NI_FileType.lvlib
Deploying Belle Glade 2009.lvproj
Deploying BelleGlade(successfully deployed target settings)
Deploying MACBIN Resource Header__ogtk.ctl (3.35 K)
Deploying DialogType.ctl (2.10 K)
Deploying Compare Two Paths__ogtk.vi (12.54 K)
Deploying Search 1D Array (Path)__ogtk.vi (15.58 K)
Deploying whitespace.ctl (2.09 K)
Deploying Build Error Cluster__ogtk.vi (8.12 K)
Deploying MACBIN Resource File Info Core__ogtk.viMACBIN Resource File Info Core__ogtk.vi loaded with errors on the target and was closed.
LabVIEW:  Failed to load shared library lvzlib.*:LVPath_UtilFileInfo:C on RT target device.
Deploying BelleGlade Container
Deployment completed with errors

 

 

Was it something I did? Help

---------------------------------
[will work for kudos]
0 Kudos
Message 54 of 91
(2,443 Views)

rex1030 wrote:

Problems:

 

I installed the new version of the package. I then created a test vi that just zipped up the files in a directory on the crio. When I tried to run/deploy the vi, here was the report

 

Initializing...
Calculating dependencies...
Checking items for conflicts. This operation could take a while...
Preparing items for download. This operation could take a while...
Deploying NI_FileType.lvlib
Deploying Belle Glade 2009.lvproj
Deploying BelleGlade(successfully deployed target settings)
Deploying MACBIN Resource Header__ogtk.ctl (3.35 K)
Deploying DialogType.ctl (2.10 K)
Deploying Compare Two Paths__ogtk.vi (12.54 K)
Deploying Search 1D Array (Path)__ogtk.vi (15.58 K)
Deploying whitespace.ctl (2.09 K)
Deploying Build Error Cluster__ogtk.vi (8.12 K)
Deploying MACBIN Resource File Info Core__ogtk.viMACBIN Resource File Info Core__ogtk.vi loaded with errors on the target and was closed.
LabVIEW:  Failed to load shared library lvzlib.*:LVPath_UtilFileInfo:C on RT target device.
Deploying BelleGlade Container
Deployment completed with errors

 

 

Was it something I did? Help


That is a tough one and I have no cRIO to do any tests here. Probably another symbol clash between the shared library and the VxWorks kernel, so VxWorks simply fails the loading of the library. Or LabVIEW 2009 uses a different version of VxWorks.

8.2 used VxWorks 6.1, 8.5 and 8.6 use VxWorks 6.3. We had no way to determine if VxWorks 6.3 would be alright for LabVIEW 2009 and didn't want to wait with the release as we considered VxWorks operation a lot less important thannormal LabVIEW 2009 operation.

 

Rolf Kalbermatter

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 55 of 91
(2,428 Views)

You can download NI RIO 3.2.1 whenever you would like, no matter which version of labview you have: http://joule.ni.com/nidu/cds/view/p/id/1386/lang/en

 

Its actually a pretty important update because the newer crio-9014 controllers use a new hard drive controller that has a major bug with any version of NI RIO before 3.2.1 . The bug was that whenever you opened and closed a file it would declare a small chunk of drive space to be corrupted. Open and closing repeatedly would inevitably shrink your 'usable' drive space to nothing. 

 

So if you have a crio device, download the new NI RIO 3.2.1 and see if you are getting the same problems.

---------------------------------
[will work for kudos]
0 Kudos
Message 56 of 91
(2,410 Views)

rex1030 wrote:

You can download NI RIO 3.2.1 whenever you would like, no matter which version of labview you have: http://joule.ni.com/nidu/cds/view/p/id/1386/lang/en

 

Its actually a pretty important update because the newer crio-9014 controllers use a new hard drive controller that has a major bug with any version of NI RIO before 3.2.1 . The bug was that whenever you opened and closed a file it would declare a small chunk of drive space to be corrupted. Open and closing repeatedly would inevitably shrink your 'usable' drive space to nothing. 

 

So if you have a crio device, download the new NI RIO 3.2.1 and see if you are getting the same problems.


First Idon't have a cRIO device available at the moment.

 

Second it is not a question of NI-RIO. The VxWorks version used on those controllers varies depending on the LabVIEW version you use. While when developing a cRIO application in LabVIEW 8.2 there was a 6.1 version of VxWorks installed on the controller, for LabVIEW 8.5 and 8.6 this is VxWorks 6.3. The shared libraries need to be compiled with the according VxWorks toolchain version in order for those libraries to be loadable.

 

And I do not yet know the VxWorks version used when targeting cRIO devices in LabVIEW 2009. There is a good chance that they switched to a more recent VxWorks version. the latest one is 6.7 realeased in February of this year but I would guess that that was just a tiny bit to late to make it for LabVIEW 2009. So it might be 6.5 or 6.6 and that would mean I need to recompile the lvzip shared library with the according toolchain in order to be loadable in a LabVIEW 2009 target. I hope to get word about what version that needs to be and where I can download the GCC variant of that toolchain. But there still is a chance that somehow somewhere I have a new symbol clash between lvzip and the VxWorks kernel as used by LabVIEW 2009. VxWorks seems not able to handle shared library symbols on a module base but always seems to keep them in a global table for the entire system.

 

Rolf Kalbermatter

Message Edited by rolfk on 09-11-2009 05:33 PM
Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
Message 57 of 91
(2,398 Views)
Any app engineers care to tell us which version of VxWorks LabVIEW 2009 is using? If I have to open a service request I will. Seems like such a waste though.
---------------------------------
[will work for kudos]
0 Kudos
Message 58 of 91
(2,380 Views)

I'm not sure if you've been down this road, but...

 

The LabVIEW 2009 Real-Time Module Readme says that it's using VxWorks 6.3.

 

Thanks, 

Message 59 of 91
(2,374 Views)

As Jim mentioned, the operating system didn't change from 8.6 to 2009.

 

Another good reference to look at is:

What Operating System is my Real-Time Controller Running and Why?

Message 60 of 91
(2,371 Views)