crelf

No, I just enjoy typing for the finger exercise it gives me I think it does. I'd recommend different resources if you're already a software architect that if you aren't.

Are you a software architect?

Topic closed - continue the discussion here.

Wow. ...and you friend is proud of that?

eh! Because LabVIEW isn't G Sounds good to me.

Shouldn't that make it el-vee-oop-eh? Aristos calls it el-voop, so I figured he defined it so I should follow suit.

When pronounced, el-voop-dee-vee-are doesn't take too long

Thou shalt not progam LabVIEW wilst the missus is watching TV.

I love my media center and media extender!

There are some that ship with TestStand (they're called "OI"s in TestStand, not "UI"s).

I'm hoping for the undocumented LabIEW.ini key...

I was just thining the same thing - something that either embedded them or floated them by default...

Using TestStand in your product doesn't mean that you can charge for a license fee and take a chunk of that yourself (depending on the price pain point you see in your customers' eyes ). Besides, the costs of designing, building, testing, releasing, maintaining, etc your own executive... that's a lot of dosh. As an aside, the TestStand depolyment license fee has dramatically reduced recently. That is totally true (I've done it a few times), but I figure it's also fun and satisfying to create the wheel Seriously though - my company is about test, and while it's great to create tools and libraries that we use internally, I find it more satisifying to create a system that tests something, not so much the tools I used to create it. I liken it to a power supply: you could buy a DC power supply for a few bucks of the shelf, or you could design, build, test, release, maintain, etc your own from discrete electronic components. Sure, building your own can be satisfying, but I'd rather use one that someone else made to create something bigger. I know I said I wouldn't say it, but TestStand can do that OK - seriously, now I'll leave you all alone. Unless you say something about TestStand's capabilities that I think is wrong, I'll try to ignore this thread the best I can

Irrespective of where you're going to share them (company website, NI's driver network, OpenG, LAVA, etc), you still need a license. Not just so you get credit, but also to protect yourself (if you don't have a license, then someone who uses your code can sue you if it'd found that doing so causes negative effects). I am also not a lawyer, but I use BSD when I'm releasing stuff to the public. It is less restrictive to others than GPL/LGPL. That said, there are a few discussions here on LAVA on licensing that you could use as a starting point, but nothing beats professional advice.

What's the problem? Doesn't install? Installs with errors? Installs, but running it doesn't work? ...

This is a really important attribute for the new errors class to work. *almost*?!?

Good stuff mate - congrats!

I don't know other OSes, but I think you'd need to call the command lines differently at least, and I figure they'd all return the information in different ways. Anyone with multiple OS experience care to comment?

Of course you were! I'm sooo getting my NI-Week days mixed up That was pretty damn good brisket - I sure remember that... Yep - I agree. I don't think that there's going to be a silver bullet, unless there's something funky under the hood that NI can use to make magic happen. I know it's going to be a difficult road, and we might be tempted to use the shove-everything-in-the-source-string method which, as I said in my presentation (as reminded by Aristos ) isn't necessarily a bad thing since it's already error data, but we're going to have to have multiple errors, and it's only through some magic in the new GEH that that's going to happen.

Thanks to Todd for this one: http://bit.ly/6ijVk

You don't need to create anything - that's why Mike's example returned "File Not Found". I'm not sure if that's safer or not, but I agree - I'd prefer to use the GetVolumneInformation function as well.

Something I'd thought about a while ago, and gb119 eloquently descrived on the LabVIEW Idea Exchange here, is the automatic conversion between the NEC and a new paradigm (ie: LVOOP Errors Class). One idea I'd had was something like the "Merge Signals" primative that is automatically inserted when you try to wire two signals into a graph: One of the real limitations of the "NEC in OO" paradigm that was presented is backward compatibility - this might alleviate some of that pain (automatically adding a onvert to and convert from on either side of a subVI with the NEC type - while including a wire between the conversion VIs to keep the existing errors data - sort of like wiring an existing cluster to the "input cluster" input of the "bundle by name" primative): I wish I had have been there! I'm glad you enjoyed it and it was thought-provoking - I think it's a very interesting topic and an opportunity for us to make a real difference in an area that we all know could be better

That's a good question - I suppose it would depend on what you were trying to prove to the regulatory body. If you're showing that you used SCC then you're probably ok, if you were using it for a configuration management traceability record the I'm not so sure... Real quick note: Requirements Gateway isn't a requirement management tool - it's a requirement traceability tool. I RG, and we use it here, but it doesn't manage your requirements, it traces them. Jeff will be uploading his NI-Week presentation soon which will explain that a little further, and how to include it into your process.

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.

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