09-01-2015 11:46 AM
This post is now way longer that I intended, so an executive summary:
Attached lvproj file exhibits observed performance.
Thanks for your time - Chris (details below for the interested)
It now takes between 30 seconds up to a minute to have the project in a usable state, starting from LabVIEW being loaded. I observe, depending on the specific project and computer used or if the real-time system is present:
Our main project, used for testing, has just two targets (My Computer and RT Single-Board RIO) and 3 VIs (one in My Computer, one for the real-time and one for FPGA). It opens at around 40 seconds.
This time has become a noticeable issue for our team lately, as we are doing integration testing on different systems here. Sometimes (and we try to limit it), there are two or three developers waiting for this, as we are all needed to isolate some specific issues. And this might happen a couple times a day and it is starting to add up. I wanted to see if our experience is normal within the community and if LabVIEW 2015 changes the situation in any way. I will be checking into this with LabVIEW 2015 in the upcoming weeks, but it is far down on my to do list right now. I'd also appreciate any tips or tricks that might help us out.
I've attached a project with no VIs in it and just with an unconfigured real-time target (no IP address), that we are using. I observe:
It does not seem to matter if the sb-RIO is present or not. Is this expected performance and can someone with 2015 open this project and see if the performance differs from 2014.
Environment
09-01-2015 11:56 AM
A long shot, but do you use the Volume License Server for your licenses? I recently had a problem where LabVIEW was taking a long time to load because it was trying to query an old license server and the connection was timing out.
Perhaps you have a similar issue (some sort of connection timing out)? Do you have any other addons installed with your LabVIEW installation?
Also - SSDs are great and will make a huge impact on loading times!
09-01-2015 12:09 PM
Thanks for the reply.
No to your long shot, currently all local licensing. But worth a check....
SSD - true, but the attached project is only 438kb, and the xml it contains loads into notepad fast, so improvement from a SSD might not be too noticeable.
LabVIEW addons - not sure what might matter, I've attached a MAX software report from one system if there is something there to look for...
Thanks for your time - Chris
09-02-2015 03:59 PM
I tried the project you mentioned and I can see a delay as you mentioned, I tried this myself with a project created on my system (same software versions), and I started seeing a similar, but much shorter delay with the project I created. The problem only started to show once I added the FPGA target to the project.
Could you see how this project which should be identical to the one you have behaves in your system.
09-04-2015 12:53 PM
Ahh, thank you; I think you are to something here. I observed the same behaviour as you reported.
A quick diff of the lvproj file results in some significant differences. This should not have been a surprise to me, as the file size was reduced to the 12kb from 438kb.
First, I added the DevKit CLIP declaration to the sbRIO-9651 Socket item for this FPGA target (I do not believe that this step is needed or applicable to cRIO FPGA targets). Did not expect this to matter, but it did impact the performance. This is the cause of the delay in the project attached and accounts, but leaves:
More investigation needed on my part.
The delay observed to the lvproj from the CLIP data loading might unavoidable, but if no target is present (or IP address 0.0.0.0), I would expect this delay to go away. This is a defect (fixable or needs improvement), IMO, so what is the standard procedure for reporting observed defects to NI? (I "searched standard procedure for reporting observed LabVIEW defects to NI" on ni.com and got no useful hits)
Thanks for your help!
09-08-2015 03:21 PM
Hello,
For this kind of feedback the best place to do so would probably be in the following page:
http://digital.ni.com/applications/psc.nsf/default?OpenForm
in there you can send us your feedback, so that it is taken into consideration by our R&D team. Aside from this whenever we encounter odd behaviour like this we can report it internally with a corrective action request, to ensure that this is noted, and ideally corrected for future versions of the software.
Regards.