Chris Bolin

A quick update (a year later...) The LabVIEW Tools Network (where OpenG is listed on ni.com) now has ratings. If you've used OpenG and like (or don't like!) it, you can rate it there... http://sine.ni.com/nips/cds/view/p/lang/en/nid/209027 See you at NIWeek

But in all seriousness, I completely understand how this affects users. It's good to note that this would happen in the basic, standard use case of just opening a opening a config file, writing a value, and closing, all with the public Config file functions in the palette. You've narrowed down the root problem in Save Config (a non-palette VI), but users would see this bug in Close Config (a palette VI).

So moving from MacOS to Linux fixed the issue?

A LAVA repost 14 minutes after submitting an idea? I couldn't ask for more

Hmm, definitely. We hadn't encountered this before. By design "Gold" status applied both to the product and to the provider's ability to provide accountably (again, this could be an additional cost), so the user only has to go to a single source. Has anyone ever provided paid support for OpenG? I'd be interested to hear about the experience.

I completely agree. We simply wanted the possibility for legal accountability (even at an extra cost), as this is necessary for certain applications and industries. We wanted 3rd party products (especially the top tier) to have the possibility of being used in the same strict environments as LabVIEW.

This is a great discussion. Please don't think we don't want OpenG to be a Gold product - personally I think it's one of the best examples of a LabVIEW product available. We are just working to codify how this all fits together. Here's the line of reasoning ... Two things are usually necessary when a customer using any product needs help: Response Accountability The response helps them resolve their current issue. But if the provider doesn't respond or the issue isn't resolved, there needs to be some accountability for the product. I have no doubt whatsoever of OpenG's quality and the community's ability to support it. But where does the accountability lie? As with any open source software, it lies with the user, not the provider. But after reading the above discussion, I am now thinking maybe open-source (code) add-ons could be "Gold" because users can support themselves...

Thanks, Ton - that's exactly what I'm looking for! (This comes with no guarantee that it will be available in the future, but at least we can investigate)

Did you use LabVIEW Scripting before it was legal (pre-8.6) or *somehow* have access to private properties and methods? If so, I'm interested in your help. I'd love to know if you used properties and methods that weren't part of the official scripting release. Don't worry, I don't even have to see your source. I just want you to run a tool on your scripting VIs that looks for private properties and methods, and tell me what you find. Any takers? You can PM me or email me (via Lava). Thanks all!

Hey Michael - Any chance we update this post to point to the download for 8.6 and 2009, and mention Scripting is included by default in 2010?

It's not monolithic! The OpenG package is simply empty, with dependencies on all of the constituent packages. This way, it's very easy to get OpenG for the first time (something that was somewhat awkward before). But you as an OpenG user will not form dependencies on the OpenG package, just the children.

I realized that I should have posted this on LAVA months ago... During NIWeek 2010 we launched the new LabVIEW Tools Network, and one of the first products we were able to include was OpenG. Why is this relevant? Well, ideally it will get OpenG out in front of more LabVIEW users and maybe even help the project. Have a great weekend!

Paul and Daqlu - AQ mentioned that the Endevo/Symbio tool is the recommended UML tool for LV. That doesn't mean, however, that others haven't created UML tools as well. Some LabVIEW users at AddQ released a free LabVIEW OO framework called G#, and they actually built a plug-in for StarUML. It supports both code generation and reverse engineering of G# classes. They've done this primarily as an open source effort, and might be willing to look at general LV class support for StarUML (or let someone else take that up, in the open source spirit )

Great question! We are still fleshing that out, but my initial thoughts are to certify all the palette VIs together, and look at OpenG builder separately.

For those of you that are curious, I want OpenG to be a "Compatible with LabVIEW" product (ni.com/compatiblewithlabview). Part of the compatibility requirements are customer references, and after speaking with the OpenG founder, we decided the best way to get those references was from directly from the user base (enter: LAVA). As a Compatible with LabVIEW product, OpenG should be exposed to wider audience, which is good for OpenG and LabVIEW - and by extension, you and me