Jim Kring

Hello everyone! In terms of moving OpenG VIs into libraries (LVLIBs), it could have a lot of benefits. I wonder what the possible implications and down-sides are: - How can we get existing code to link to the new LVLIB'ed versions of the libraries? - Will it create any problems for users? Will it cause EXE builds to be larger? In terms of a work-around, adding "(OpenG)" as a suffix to VIs that have the same Palette Name as NI's sounds like it could also be a good idea. Again, I wonder what the possible implications and down-sides are: - Will seeing "(OpenG)" when the user hovers over it in the palettes cause confusion or look bad if none of the other OpenG VIs have "(OpenG)" in their name? Anyone see other considerations or have input on those I've mentioned? How would it appear in Quick Drop? Would the user be able to visibly distinguish between the OpenG Build Path and the built-in Build Path? For example, would (or could?) Quick Drop show "OpenG.lvlib:Build Path" or maybe "Build Path (OpenG.lvlib)" / "Build Path (OpenG)".

Empty path is actually not empty on Linux, it's "/" or the root directory. On Windows and Mac, if you list the contents of empty path, it lists all the drives on the computer. So, this isn't really an OpenG definition, as much as it is a LabVIEW definition. I hope that helps.

See Michael's cool announcement, here: VIPM 2013 for Intel-Based Macs

Great point. In fact, I'm going to be working to tweak our fully automated build to programmatically adjust the VI properties. It would be nice if I had an easier way to adjust the disable debug setting. Maybe VIPM's package builder should offer such a feature...

Yes, but (when a password protected diagram is opened while it is running) LabVIEW could (if the smarts were added) defer the enabling of debugging until after the VI stops running. Regarding use case frequency: - The number of times I've wanted to debug a password protected VI while it was running (and where I couldn't afford to stop and restart it) is zero. - The number of times I've wanted better performance of password protected VIs is all the time (why not, right?). Also, shouldn't users of password protected VIs be able to disable debugging (in order to benefit from the increase in performance) without knowing the password? Right now, they can't and that doesn't seem fair [update: I guess they could do this by resaving without block diagrams, but that doesn't seem very practical.]

True. Still, there's a usability opportunity, here. I'd argue that most users aren't concerned about a recompilation and would prefer to have LabVIEW automagically give them better performance when they password protect something. That's part of why we all love LabVIEW so much: it worries about (re)compilation and we don't

Darin: Thanks a bunch for the benchmarking and data. The results do speak loudly. This will make a big difference for our application, I think (~20% performance increase when running the code in the IDE).

I'm could probably test this, myself, but I'm pretty lazy busy. Is there any performance benefit of disabling the Allow Debugging VI property on a VI that is password protected? Meaning: does a password protected VI sort of have debugging disabled (and gain the associated performance improvements) while it's diagram is locked? Thanks for helping me avoid hard work find the answer

JKI is hiring! Come push the limits of LabVIEW and develop software for next-gen instruments, equipment, and devices: http://jki.net/careers

These are now available for download from VIPM.

This is one of my favorites He looks so super serial. (via the teampyrotech.org site) We love you, Justin

Great idea! This one should definitely be pushed through the system.

> This package will be available for download through VIPM in a few days. Go get it!

Hi All, I love all the new VIs and improvements showing up in OpenG. One thing I noticed about the new String to Character Array VI is that there are no comments in the code. While this VI is pretty straight-forward to understand, I think it's a great opportunity to highlight best practices for commenting code. And, while my own personal preferences for code commenting style might not be everyone's preference, I figured I'd share the level of documentation that I'd probably include: Happy Holidays! -Jim

I just checked and it's available in VIPM, now Great work, OpenG team!

Cool! Welcome to the OpenG Team, Jason

It looks like it's available in VIPM, now

It looks like it's available, now

It looks like it's available in VIPM now

This is very cool. How do you use it in practice? For example, how do you get the Class Private Data Hierarchy (Type)? Is there any way to obtain this from Object in?

Have you tried building your Code Capture Tool using VIPM's package builder? It excludes stuff in vi.lib and has the option to include or exclude individual OpenG packages.

I see the same thing -- that's interesting.

Native implementation, to me, means that it uses primitives other than a Call Library Function or Code Interface Node (unless it's to call to LabVIEW.exe and the code is guaranteed to work at Run Time in both desktop and real-time). I guess I don't really trust stuff that's inside password protected VIs and that's not in the palette. It could get removed or put into an LVLIB and scoped as private

Ton: Can you explain more about your use case? For example, the type of tool you are building, what you're using to build your tool (OpenG Builder, LabVIEW Application Builder), and why you need to exclude OpenG but include other vi.lib stuff?

The pitty is that in almost every instance where I use Clear All Errors, I use Merge Errors to merge in upstream errors. So, I think it's a really useful design pattern. My vote would be to make the Error In a required input.