LabVIEW 2013 Favorite features and improvements

[shoneill]

6.1 - Average (RT Below Average)

7.0 - Far Above Average (RT Above Average)

7.1 - Far Above Average <<< almost identical to 7.0 except for work in the modules

8.0 - Far Below Average

8.2 - Below Average (RT Far Below Average) <<< RT impacted by lingering 8.0 project issues

8.5 - Below Average but better than 8.2

8.6 - Average

2009 - Average

2010 - Below Average but better than 8.2

2011 - Above Average <<< Many people called this the new 7.0 and it had extremely fast adoption rate

2012 - Above Average

2013 - Above Average (keep in mind that I've been actively developing in 2013 for months longer, in alpha and beta, than most of you, so I feel I have enough time under my belt to evaluate this one)

 

Well we recently ported a Version 8.5 project to 2012 SP1 and had very little trouble.  A couple of toolkits were no longer automatically installed (Internet toolkit for example) but these problems were quickly fixed.  The inability to have a time critical VI in a Timed loop caused errors, but again was quickly remedied.  All in all the code worked as it should with the exception of a Waveform chart bug which (If I'm informed correctly) will be patched soon.

 

So whether 2012SP1 turns out to be a worthwhile change over 8.5 (I think it will) time will tell.  The ability to port relatively painlessly between versions is a testament to the work NI has done in this area.  Kudos for that. (wrong forum   )

 

One thing which will keep us going for a while are undocumented bug workarounds in our code (from 8.5) which are essentially no longer required in 2012..... I foresee some future Rubes.

[hooovahh]

My own rankings, based on both my own perceptions as I work in these versions, on the CARs I was fixing for each version, and the amount of complaints I heard from customers on the forums. 

You obviously are in a better position to rate LabVIEW versions for stability over the years.  Your intimate knowledge of low level development, and CARs is invaluable.  And as years pass my memory of why I feel a way about a version becomes less clear.

 

Also I never meant to go off topic, really I just wanted to say that I hope 2013 is the most rock solid version yet, but if it isn't my fall back would be 2011, simply because for me I've used it on more projects then 2012, which we only started using on real projects since SP1 about 6 months ago.

[gregstoll]

A gentle reminder: sending in reports when the NI Error Reporting dialog pops up helps us make future versions of LabVIEW more stable!

[todd]

A gentle reminder: sending in reports when the NI Error Reporting dialog pops up helps us make future versions of LabVIEW more stable!

 

You should have several from me from last night .

2012 kept crashing, then hanging. Forcing recompile on each Actor Core.vi, saving all, mass-compiling (for good measure), and restarting LV eventually got it working again. I think the troubles began when I changed some reference controls in a STD that is part of the private data in one of the actors. (I can submit this project to NI, if that's useful. Maybe if I get a repro, first.)

[gregstoll]

You should have several from me from last night .

2012 kept crashing, then hanging. Forcing recompile on each Actor Core.vi, saving all, mass-compiling (for good measure), and restarting LV eventually got it working again. I think the troubles began when I changed some reference controls in a STD that is part of the private data in one of the actors. (I can submit this project to NI, if that's useful. Maybe if I get a repro, first.)

I can take a quick look at the reports - send me a message with one of the report IDs and I'll pull it up.

[hooovahh]

And what about MyRIO? I know this is a new features of LabVIEW thread but why is a FPGA and dual core arm running linux real-time, with built in WiFi, and USB host for $500 not getting lots of attention (price was mentioned by NI but not confirmed yet)

I talked to someone at NI today and they were able to get some slightly more official information (while still being unofficial).  Not naming any names, but the word from this individual was that student pricing would be $250, universities was $500, and non-academic pricing would be available for $1,000.

 

To be clear nothing official but I can't wait to get my hands on one of these.

[mje]

Ditto. Its really hard for anything NI offers on the FPGA level to compete with our ASIC. Which means we tend to re-purpose and hack a lot of our old boards when prototyping next generation or new products. MyRIO may be cost effective enough to consider using, I really want to do more than just dabble in LabVIEW RT/FPGA.

[hooovahh]

Ditto. Its really hard for anything NI offers on the FPGA level to compete with our ASIC. Which means we tend to re-purpose and hack a lot of our old boards when prototyping next generation or new products. MyRIO may be cost effective enough to consider using, I really want to do more than just dabble in LabVIEW RT/FPGA.

I get more excited about the possibilities.  This can basically become a headless device that performs a task using AIO, DIO, SPI, UART, Vision, Wifi, Bluetooth, and USB.  I have so many applications where someone will ask for a program that does X and just runs without needing a PC.

 

A simple one recently was someone wanted to send a CAN command and have a waveform be generated based on the message.  So send a CAN message and a Sine wave is generated at X frequency and Y amplitude.  This is quite easy with LabVIEW and a cDAQ CAN module, and analog output module, but needs a laptop.  With this I could do it without a PC.  I could even add control (pots switches) and a LCD output.  What about a headless resolver simulator that simulates a position, or speed?  Or a remote logging application where you can do a FTP data dump over Wifi?  With the new version of Multisim/Ultiboard you can simulate a circuit then push it down to an FPGA and it will best approximate the simulated circuit, we could put this on a MyRIO and take our simulation into the real world without a PC.  Talk about rapid prototype!

 

If an Arduino, and a Raspberry Pi had a baby, it would have nothing on a MyRIO. (okay maybe not exactly true but still)

[JLMommy]

If an Arduino, and a Raspberry Pi had a baby, it would have nothing on a MyRIO. (okay maybe not exactly true but still)

 

 That's just an awesome analogy...we have a Raspberry Pi at home but I'm much more excited for a myRIO!

[hooovahh]

 That's just an awesome analogy...we have a Raspberry Pi at home but I'm much more excited for a myRIO!

Yeah I guess there are some things a Raspberry Pi does that I would have a hard time getting a MyRIO to do (1080 HDMI output is one) but then again I can't have the Raspberry Pi update a timed processing loop running at 40MHz+ (talking about the FPGA)

[Phillip Brooks]

Would Pi and Arduino have a baby named Galileo?

 

http://www.anandtech.com/show/7387/intel-announces-galileo-quark-based-arduino-compatible-developer-board

[Steen Schmidt]

Both LabVIEW 2012 and 2013 has crashed numerous times on me. 2012 In fact much more than 2010...

 

In 2012 we tracked it down to when compiler optimizations were set at above 7, combined with using inlining and recursion together (I have a demo-project illustrating this). A CAR has been filed. There is still a warning dialog popping up almost every time I quit LV 2012.

 

At first I thought the above wasn't present in 2013, as I can easily leave compiler optimizations on 10 (as I prefer it). But then I started experiencing crashes with 2013 as well, although not so severely as with 2012. I think it still has something to do with inlining, but much less of a problem than 2012. I haven't filed a CAR on 2013 yet.

 

/Steen

[shoneill]

Ooh, Warnings with inlining.  I think I should write a song about it.

 

It's driving me nuts.  Also problems with deployed code on a  RT not matching the code in the IDE when editing and runn ing code from the IDE is a nightmare....

 

Roll on LV 2020.  Maybe we'll have a really stable version by then.

[hooovahh]

Ooh, Warnings with inlining.  I think I should write a song about it.

Curious what issues you've seen.  I'd say we inline 80% or so of our reuse library and haven't seen issues in 2011, 2012, or 2013 as a result.  What issues should we look for?

[shoneill]

I'm not 100% sure it's related to inlining but here goes:

 

recently (Actually it seems to be happening a lot since we installed the "November 2012" patch for RT (which is supposed to fix glitch issues with FIFOs)) we started seeing what can only be described as "weird sh1t" happening with our code.

 

When debugging RT code in the IDE and running the top-level VI from the IDE (plus automatic deploy and so on) we would see VIs which are running on the RT not being reserved (or marked as executing) when viewed on the host.  With time I realised this was simply a mismatch between the deployed code and the IDE source code which led to all kinds of performance debugging nightmares.  Debugging nightmares in general in fact.  Setting probes where you KNOW it has been executed but not showing any values (listed as "not executed") is perhaps the most harmless version of what I was seeing.  Hard crashes of the entire LV system was less harmless.

 

I got some keys from NI which should have fixed the problem but actually led to all deploys failing and the VIs complaining when trying this were nearly all inlined - hence my irritated glance in that direction.  I deleted the keys but am left with a system where I'm never quite sure which version of my software is actually running on the RT.  I've spent days trying to debug something and tearing my hair out only to have the software (unchanged nominally) working fine when I re-connect the next day.  My sanity is intact though, that was actually in doubt for some time.  Another work colleague has started seeing the exact same behaviour.

 

I got more keys to fix the behaviour but I haven't tried them all out yet.

 

Shane

[shoneill]

Just to follow up a little.

 

I've had success with adding the entry

RTCloseVIsOnDocMod=True

to the ni-rt.ini on the root directory of the RT system exhibiting the problem.  This seems to get around the problem of the RT and host getting confused because of changed VIs not being deployed properly.  Your mileage may vary.