LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Generic File I/O Path Too Long RT Deploy

Solved!
Go to solution

So I've been fighting with this setup and having errors on deploying code to an embedded RT target.  I have a cDAQ-9132 running RT Linux and I've found that if my path is too long it will give strange errors.  Sometimes the error will be on opening the project giving "Generic File I/O" but the VI opens without error.  And sometimes I see "loaded with errors on the target and was closed" on the deploy.

 

The path to the reuse code in the user.lib is similar to the following:

 

C:\Program Files (x86)\National Instruments\LabVIEW 2015\user.lib\_xxxxxxx\Automotive Communication\CAN Drivers\Generic CAN Drivers\CAN Class\Public\Signal Conversion\Read Signals Polymorphics\Read Signals - Single Sample_xxxxxxx.vi

 

Which is 233 characters including slashes and colons which is under the Windows limitation of 260 (or 255).

 

Attached is an example of this.  Unzip the user.lib zip in the user.lib, and then open the RT Test Project.  In it is an RT target but opening just the RT Test VI.vi should show the Generic File I/O error and the VI appears missing on the BD.  If you then open the Read Signals - Single Sample_xxxxxxx.vi the VI loads without error and the top level VI can be ran without error now.

 

I have not seen it documented anywhere, but is there a file length limitation that is causing this issue?  Is there a document stating how deep into the user.lib reuse can be?  I realize my paths were getting a bit long but also noticed Windows length hadn't been surpassed yet.  And is it possible that if this limtiation exists, that we get a bit more helpful of an error?  Thanks.

 

Windows 7 x64, LabVIEW 2015 32-bit.

Download All
0 Kudos
Message 1 of 13
(3,686 Views)

The first thing I would do is make a copy of your target VI, and put it into C:\Test\X.vi, and adapt your code's path to match.

If that works, then maybe you have a path problem.

If that does NOT work, it's something else.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 2 of 13
(3,651 Views)

@CoastalMaineBird wrote:

The first thing I would do is make a copy of your target VI, and put it into C:\Test\X.vi, and adapt your code's path to match.

If that works, then maybe you have a path problem.

If that does NOT work, it's something else.


Oh that absolutely works.  In the test code I posted the VI in user.lib is named Read Signals - Single Sample_xxxxxxx.vi If I rename it Read Signals - Single_xxxxxxx.vi leaving the rest of the long path in the user.lib it works just fine.

 

I have about 6 VIs that have this error, and trimming the path just enough has everything working just fine.

0 Kudos
Message 3 of 13
(3,638 Views)

You mentioned RT Linux, but then mentioned the "Windows Length".

 

Perhaps Linux has a different limit ?

 

(I know nothing about Linux, in case that's not obvious).

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 4 of 13
(3,632 Views)

Thanks, I hadn't thought of that, but a quick google search states that ext4 (the file system used on this hardware) has a file length limitation much higher than Windows.  255 for a single file name, and 4096 for a full path with folders.  Even so I don't think the directory structure is duplicated on the RT.  I've generally seen it built into a single rtexe.

 

http://unix.stackexchange.com/questions/32795/what-is-the-maximum-allowed-filename-and-folder-size-w...

 

I say bug or limitation, with how the code is being deployed.  It is likely caching it in a directory deeper than the user.lib so that Windows limitation is hit sooner than it would normally be.

0 Kudos
Message 5 of 13
(3,626 Views)

When I build an RT exe, the code gets put into a folder on my hard disk with a complete duplicate of the RT path on my Windows disk.

 

IOW, if I specify the destination path as C:\My Project\ My Folder\My File.rtexe, it shows up on my Windows disk as:

C:\Users\Steve\Projects\Blah\C\My Project\My Folder\My File.rtexe

 

i.e. the path is much longer than expected.

 

Maybe that enters into it ?

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

Message 6 of 13
(3,618 Views)

I haven't even got to the building of the EXE part, this is just running a VI, which I assume makes an EXE in some hidden place on disk in a similar way to application builder, which I never specify.  But even so the Generic File I/O error happens on opening the project, not even opening the VI, or building of the EXE.

0 Kudos
Message 7 of 13
(3,614 Views)

Loads OK for me here.

I'm running Win 7 x64 and LV2015-32  on a Mac VM.

 

 

Screen Shot 2016-10-03 at 3.29.30 PM.png

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

Message 8 of 13
(3,601 Views)

Well that's my exact environment, maybe it is just something on my end.  If any blue guys have any suggestions I'd be glad to try them.  At the moment I've just moved on with trimming some file paths.

0 Kudos
Message 9 of 13
(3,597 Views)

Oh boy...well I made the change to where the code could be opened and ran, by shortening the file names and folders.  Then I went to make an EXE and it failed with Generic File I/O.  So I enabled build logging to look at what is happening when it fails and it shows the following:

 

Spoiler
SourceItem[161]
sourcePath:C:\Program Files (x86)\National Instruments\LabVIEW 2015\user.lib\_xxxxxxx\Automotive Communication\CAN Drivers\Generic CAN Drivers\CAN Class\Public\Signal Conversion\Read Signals Poly\Read Signals - Single Sample_xxxxxxx.vi

destPath:C:\Users\hoover.brian\AppData\Local\Temp\tNIAB\home\lvuser\natinst\bin\startup.rtexe\1abvi3w\user.lib\_xxxxxxx\Automotive Communication\CAN Drivers\Generic CAN Drivers\CAN Class\Public\Signal Conversion\Read Signals Poly\Read Signals - Single Sample_xxxxxxx.vi

The temp path mentioned is 260 characters.  So I have continued frustrations with Windows, NI, and myself.  Windows for the limitation, NI for making it worst with a deep temp path (but it is where it is), and myself for making such a nested structure.

 

NI is there a way to set this temp path to something like C:\temp?  Or do I need to go trim some more and then hope my user name doesn't get longer?

0 Kudos
Message 10 of 13
(3,569 Views)