LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

2012 and userlib size impact

We are noticing that the startup time and stability of LabVIEW 2012 is tied to the size of the userlib - i.e. how many VI's exist there.  We have a large userlib directory that worked fine in 2011. We have gone through and mass compiled all the files with 2012f3 and all compiles.  If I remove all these files from userlib, LabVIEW 2012 starts up fast and is stable.  If I copy back it takes a long time for LabVIEW to start and stability becomes an issue (a lot of image.cpp or primsupport.cpp crashes - even when labview is not doing anything - just at opening screen).  We can always recover by temporarily removing our userlib files, starting labview and then copying back after it starts up.

 

Anyone experiencing something like this?

 

John

0 Kudos
Message 1 of 8
(3,291 Views)

Hi John,

 

I was doing some reading on this issue, specifically the crashes you are finding. It sounds like image.cpp or primsupport.cpp crashes could be caused by mass compiling. The solution to that particular issue is to run a mass compile from the top level VI of your program, and note the files that generate the errors and try to mass compile those individually.

 

With the crashes, are there particular error numbers involved with it? It would be good to see what the error numbers are so I can look into this further.

 

Regards,

James W.
Applications Engineer
National Instruments
0 Kudos
Message 2 of 8
(3,269 Views)

James,

 

Thanks for the reply.  I have mass compiled our entire userlib and it has no errors.  I have also mass compiled the application and it too has no errors.

 

If I remove my userlib labview starts up quickly and runs without issue.  If I keep the userlib labview will sometimes not start and even if it starts it will just randomly crash (without a project loaded, just the opening screen sitting idle) with an image.cpp error.

 

I am going to have my machine re-imaged and try again.  I have loaded 2012 twice and it still has issues.


Any other thoughts?

0 Kudos
Message 3 of 8
(3,261 Views)

Do you have VIs in userlib with names identical to some in vi.lib?  I do not have any idea whether this could be the problem, but the concept jumped up in my mind when I read your description.

 

Lynn

0 Kudos
Message 4 of 8
(3,256 Views)

Not intentionally.  How can I do this comparison?

 

John

0 Kudos
Message 5 of 8
(3,246 Views)

I am not sure.  List Folder will list the files and folders in a folder.  You would then need to got through each folder in the list to get the files in those folders.  Then repeat the process for .llb files.  Somewhat messy but not particularly difficult.

 

After creating lists of files in each library, you could test for matches.

 

I am not sure whether this would catch every polymorphic instance VI.

 

Lynn

0 Kudos
Message 6 of 8
(3,239 Views)

The only thing is this is the same library we used for 2011 without issue.   Just seems to be 2012 related.

0 Kudos
Message 7 of 8
(3,236 Views)

I think some of the lower level (not on the palettes) VIs may have changed names between 2011 and 2012.

 

I have seen some subtle effects when backsaving from 2012 to earlier versions.  Try saving a VI with Mean.vi from 2012 to 2010 and opening it there.  It will display the search dialog looking for Mean (DBL).vi.  If you double click on Mean.vi in LV2012 it will open a panel called Mean (DBL).vi:1 (clone). There is also a complex version.  In LV2010 only the Mean.vi exists.

 

If some change such as this occurred on one or more of the VIs you use, you could end up with a name conflict which did not exist in earlier versions.

 

Lynn

0 Kudos
Message 8 of 8
(3,231 Views)