Very slow deployment with LabVIEW 2011 vs. 8.6 on cFP 2120

[syang]

we have similiar issues here...

we developed cRIO applications for controlling systems.

our rtexe is about 12~13MBs: in LV8.6 the load time is around 30sec; since upgrade to 2011, it increased to almost 4mins. (7~8 times or the original, matches your result, although you were using cFP)

we have been struggling with this issue for so long and eventually had to change our operational procedures -> basically telling operators to be more patient..

I do not see this as an "edge case", it happens to all lines of our LabVIEW 2011 based products. Totally agree with your comments.

[MarkCG]

Don't know what happened with 2011. I do think cFPs are intended to operate on an "always on" type of application, rebooted only to update software and the occasional yearly plant shutdown. I often deploy cFPs to the field in areas where power is subject to frequent power interruption due to bad weather so we have taken to building battery backup power supplies in our control cabinets.

[Timmar]

It's bad in 2010 as well

[GenTek]

This is both relief and a major dissapointment to hear.  I'm recently in the process of attempting to upgrade a process control system that we originally developed in LabVIEW 8.6.1.  The app included several nodes with cFP-2210 controllers running LabVIEW RT code.  A main PC hosts shared variables that bind to cFieldPoint IO.  We also use TCP connections to send 'commands' from host to cFP controller code modules.

After upgrading (per customer request) to LabVIEW 2012, the deployment process produces the same results - 'Waiting on RT Target to Respond', followed by broken TCP connections, etc.  I've been on the phone with more than one AE, and we've been approaching the issue as a Windows Firewall issue, but after disabling that altogether, no resolution.

At least I can now approach NI tech support with the info contained in this thread and hopefully get somewhere.

I agree - I've been working with LabVIEW RT now for several years (7.1 - present), and can honestly say that reliability has become gradually worse.  Migrating to more recent versions of LV (as recommended by NI) has brought more headaches than I care to discuss.  At some point, I'm going to become hesitant to recommend LV RT to my customers; and that's pretty frustrating as a long-time systems integrator specializing in LabVIEW control systems.

[MarkCG]

I don't think a CAR was ever generated for this issue. Nothing got fixed in 2012.  Supposedly cFP support stops in 2015 or something like that?  

[Timmar]

My observation, active support for cFP hasn't been seen since 2010, it appears to be in palative care waiting to pull the plug on it.

All I have got since then have been workarounds, not a bugfix in sight.   Network Published Shared Variables appear to be going the same way.  I have recieved new cFP's from NI With LV 8.5.1 installed on them.

It is a pity, I use a lot of cFP2200/2220's in a harsh (70 deg C) environment ,  At this point there is no cost effective/physicaly compatable replacement. The first usable cRIO is twice the price and 4 times the physical size.

[syang]

Just an exciting news to let all people on this post to know about LabVIEW 2013 vs 2011 boot time.

In my case I am seeing a 45% reduction in load time. 1:25 in 2013 vs 2:30 in 2011

[Timmar]

I am Celebrating (Skeptically)......

Have you seen any problems with the dev environment yet?

I am evaluating wheter or not to dive straight in or wait for the obligitory SP1 before using it.

[syang]

I do not have much information to share yet because I just started to evaluate for my company as well.

One hassle I have encountered was LV2013 had problem building RT code that had conditional disable structure. I worked around it by removing unsupported VIs from the conditional disable structures.

I have not seen significant increase in CPU/Mem usage on RT yet. This looks quite encouraging to me because we've been fighting hard for the huge increase in load time from 8.6 to 2011.

[Timmar]

Have sumbled into the conditional disable trap already myself on 2012

 was selecting a cRIO/PXI driver for Digital inputs.

The compiler didn't seem to care that it was disabled and tried to include it anyway,

So probably not a 2013 problem, just a carryover bug from the previous version.