Leaderboard

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!

Note: This file has now been moved to the LAVA CR. You can download the latest here. Continue support discussions about it here. I did several cosmetic improvements on the new icon editor that ship with LabVIEW 2009. Feel free to try it if you like it. PJM

In did this a long time ago like this (only for windows). Make a system call to "Dir nothing.txt" this will give you this result: H:\>dir nothing.txt Volume in drive H is Data Volume Serial Number is [color="#ff0000"]64BA-5E87[/color] Directory of H:\File Not FoundH:\> Then just parse the string //Mikael

I'm not an expert, but I don't think so. You need the requirements traceability tool to be developed using an accredited ISO process, otherwise you can't proove that it works properly, which means that you can't proove that the traceability artifacts produced by it for your project are accurate.

The new icon editor in LV2009 is written entirely in G and the VIs are shipped without password protection. There are many amendments and additions that the community might want to add. NI would like to collect that feedback and fold any innovations into the next version of the icon editor. The author and maintainer of the icon editor has created a new community on NI.com specifically for the icon editor. Any feedback you have about the editor should be posted there. http://decibel.ni.com/content/groups/enhanced-icon-editor-2009

Thanks to everyone that showed up and chowed down at the LAVA / OpenG NI-Week 2009 BBQ. I hope all y'all had as a good a time as I did See you next year! cheers, Chris

It seems to me you are keeping all the data the states will work on in this shift register. This is in most cases not a very good idea as it ties the entire state machine implementation very strongly to the data of all states, even though most states will only work on some specific data on this. There is also a possible performance problem if your state data cluster gets more and more huge over time. I have only a very limited state data cluster in my state machines and it is limited to containing data that is important for most of the states and directly important to the state machine itself. The rest of my application data is stored in various functional variables (uninitialized shift registers with different methods). (And yes I know it is a lot like doing LVOOP without the formal framework of LVOOP and I should be looking into using LVOOP, but have not yet found the drive and time to do so.) The various VIs do pull whatever data they need from those functional variables when they need it and where they need it and put the data back in there when needed. This keeps the state machine implementation very much decoupled of the application data itself and allows for much easier addition and modifications later on. The state machine itself will not document what data it uses but I feel this to be information that is not exactly part of the state machine design itself. It should be defined on a much higher level (anyone saying application design specification?) The individual data should not really be important to the different states in most cases but what you want to know is what state transitions your state machine involves when, where and how. Rolf Kalbermatter

At the (fantastically awesome) LAVA/OpenG BBQ, someone (apologies to whoever it was, I forget who - sometimes I think I'm the Dory character from Finding Nemo) asked about getting more recent projects in the GSW. Stephen Mercer / Aristos Queue had provided modified versions of the VIs to do this in 8.6. I added a config token for this in LV2009, so you no longer need the modified VIs. It's MaxGSWRecentProjects=10 (or whatever other number you want. We never display more than 10 recent files, though). - Christina, aka "Miss Eyes on VIs," LabVIEW R&D