crelf

I've uploaded the presentation slides, audio and code in a new thread. I'm going to close this thread now - please continue the discussion in the new thread.

I presented at NI-Week 2009 on a couple of paradigms for extending the LabVIEW Error Handling Core (as inspired by all your posting here). Here are the resources from that presentation (I didn't screencapture the examples, but you should be able to see what I was talking about from the video and the code that's included): NIWeek Session Video Presentation Slides.pdf Presentation Code.zip It's a hot topic, and I know a lot of people have strong opinions on it, so let's discuss!

Anytime

I'm not sure whether I should be uber excited or scared, but I'll thank the mysterious Brian Powell of National Instruments for providing an LAVA/OpenG NI-Week 2009 BBQ mystery door prize. All I know about this prize is that it's an NI product prototype that didn't make it to market. "Do My Housework for LabVIEW Module"? "cRIO Espresso Module"? "Beer Extensions for Instrumentation (BXI)"? Who knows? I'll tell you who'll know: everyone at the BBQ tomorrow night!

"Code Coverage" is a a relative term and it doesn't really mean execution paths (that's cyclomatic complexity, which is very difficult to conceptualize with any programming language, and LabVIEW in particular). More info here (at arond the 15 minute mark). OK - the image is a little difficult to follow because it doesn't show that what we're actually counting here are diagrams - each of the executed pages is a diagram, and the main BD is counted a diagram, so that adds up to 3 diagrams executed. There are a total of 6 diagrams (the main BD, 2 cases in the first structure and 3 in the second), so that's a total of 3/6 = 50%. It is *not* tracing paths at the component level - it's tracing them at the diagram level. This all makes sense (it's the same method used by the VISTA Code Coverage Toolkit from oh so many years ago) - if the main BD wasn't counted, then the aggregate matrics for a whole project would be wrong. I just got the skinny from Eli Kerry (one of the benefits of being on the ground at NI-Week 09 ) and he gave me this - I think that the colour coding goes a long way in making it more clear: It's the green diagrams that are counted in this test case. ...and here's the coverage graphic for the 2nd test vector:

I'm so very happy to add another LAVA/OpenG NI-Week 2009 BBQ door prize, this time from our mega-admin Michael Aivaliotis: Project Management Tarot Deck for the G Programmer Designed by our very own Aristos Queue and first featured at the LAVA/OpenG NI-Week 2007 BBQ, this tarot deck is a laugh riot - it's the full 88 cards, each a different representation with a LabVIEW theme. Form the LabVIEW wiki entry:

Hear hear!

Well put. That's a good point. You don't *need* to know LVOOP to use these new features, but if you've been waiting to get into the LVOOP world, now's a great time to dip your toes in the water...

A big thanks to Nancy Hollenback from The G Team for offering up a couple of LAVA/OpenG NI-Week 2009 BBQ door prizes: Gift Certificates for amazon.com and Starbucks Nancy Hollenback, on of the few true LabVIEW gurus in industry, is offering up a combination of the two things behind every successful engineer: knowledge and caffine! What's better than curling up with a good novel and a decaf soy latte? I'll tell you: a great OO book and a long black These prizes are a $75 amazon.com gift certificate and a $50 Starbucks gift certificate - she also offered "a date with Nancy", but I'll take care of that thank you very much (not only does she know everything there is to know about LabVIEW, she's damn good lookin' too - what more could a guy want?!?)

Sounds like a good reason to be doing it. There are some good resources on the general software development models on NI's site, and Jeff Plotzke will be leading a presentation at NI-Week about this very topic that you might find interesting. Oh totally, but what I was getting at was that RG was developed using an audited quality process, so NI can stand behind it in saying that it won't miss any of those tags (or create any new ones that don't exist). It's not about the tagging within the custom software that I write (that's up to me), it's about that the tool finds and traces those tags. The requirements I deal with aren't necessarily covered in one area, and one area can often cover more than one requirement, so I don't think it's practical to have anything otherwise. That depends - were you being defensive? No, you didn't sound defensive at all.

I'm not trying to rain on anyone's parade here (I think it's a good tool and you've obviously put a lot of work into it), but since you asked... Did you develop it to a documented ISO audited and approved process? I need something that I know the vendor used an approved quality process, so I can be confident that the artifacts that it produces are complete and correct, and my customers can too. That's why I need to stick with Requirements Gateway for the time being - my customers can defend it because I can defend it because NI can defend it Also, we do a lot of TestStand work and RG can dive into that too...

You'll love it - but with power comes responsibility: remember to only use it when appropriate (am I starting to sound like a broken record yet?)

No worries - that's what we're all here for - to learn for each other

I never even thought of that!

Sounds like a subset of functionality of the old VI Player.

Right - when it's an emergency (hence the name) you need it in hardware, not software. I wouldn't call it "immediate stop", because that suggests it's the same as an emergency stop. Also, it gives the operator 2 options, so if there's an emergency, they need to think and make a decision on which button to press (SW or HW), and decision making is difficult and unreliable under emergency situations. Stick with having a HW stop, and monitor it with a digital input so your software can react appropriately.

I used to work at the same company as that guy - he knows about LabVIEW That's wild mate - nice job!

A big thanks to Mark Balla from Tecnova for offering up this LAVA/OpenG NI-Week 2009 BBQ door prize: 2 x iPod Shuffles 1 x Black and 1 x Silver Specifications: ● 4Gb (around 1k songs or so @ 128kbps) ● You get: iPod shuffle, Apple Earphones with Remote, iPod shuffle USB cable & Quick Start Guide ● Audio formats supported: AAC (16 to 320 Kbps), Protected AAC (from iTunes Store), MP3 (16 to 320 Kbps), MP3 VBR, Audible (formats 2, 3, and 4), Apple Lossless, AIFF, and WAV ● Dimensions: Height = 1.8" (45.2mm), Width = 0.7" (17.5mm), Depth = 0.3" (7.8mm) - that's pretty bloody tiny! ● Weight = 0.38oz (10.7g) From the Apple website:

Aw man - I was looking forward to seeing you there! Oh well - I'll have some brisket in your absence

Even if you're not in an industry that needs it, Requirements Gateway is a good tool for tracking requirements across your project. Requirements Gateway isn't a requirements management software package, but a requirements traceability package, and it helps us a lot (especially when you have a tech lead who isn't software savvy that can track requirements coverage - a very important metric in several places in the development cycle).

I do - especially when I have multiple targets. That said, I'm all for having the ability to define a VI to be run on a keyboard shortcut. I'd also like to see a button on the toolbar of every VI in the project that I can run the top level with (I'm not a huge keyboard shortcut guy).

We like to mix it up Seriously though, we've been trying different venues each year for a few years now, so I'll be on the look-out for a new place for next year - if you have any suggestions of places within walking distance of the ACC, please let me know and I'll check them out on the Thursday night (you're, of course, welcome to join me ).

Sure, I could use scripting, but I don't plan on releasing packages of every VI in vi.lib - that'd be a mess and very very difficult to control. It might be a good way to discover new hidden VIs, but it's not what I'm after when it comes to distributing (links to) them.

This is why we should come up with a packaging process where we can both expose hidden VIs and keep them future-proof. One way to expose them is to create wrapper merge VIs for each VI you want to expose (that only have the VI you want to expose on their diagrams), then create a package of them. This is, unfortunately, tedious work (I wonder if it would make sense to have virtual packages - packages that *refer* to VIs rather than containing them. Sort of goes against the whole idea of packages though. Just thinking out loud...) Hoovahh and I discussed this topic a couple of months ago - I'll ping him to add his 2 cents.

Yeah - that'd totally freak me out Keep an eye on him, but try not to make driect eye contact