Jim Kring

There isn't a spec for this, currently. But, I think that they are ordered by order of insertion. There has been talk of refactoring the current implementation, at some point, with variant attributes, since they are more performant.

Hi Dustin. Thanks for reporting this. I think I get what you're saying. Could you attach a small example VI that demonstrates the problem?

It would be nice if the template could include a typedef for the main cluster on the shift register, I normally end up creating one.

Hi Neil,

That's a good idea. One reason we didn't do that, initially, is that we wanted the JKI SM template (that you drop from the palettes) to be free of any dependencies . We're considering creating some templates that will integrate into the project templates wizard that will be a little more elaborate. Including a typedef (or maybe an LVClass?) for the main cluster might make great sense.

Anyone here try using an lvclass instead of a cluster?

That's great feedback, Eric.  These are definitely some useful features in Top Level applications.  I have a template with some similar features

If you have any more ideas or input, let us know! Thanks.

[cross-posted to NI forums]

Hi LAVA'ers,

Over at JKI, we've soft-launched a new idea exchange for the JKI State Machine:

http://ideas.jki.net/forum/31756-jki-state-machine/

I've seeded this with a couple ideas we've heard mentioned before.  If you're interested in providing your feedback on ways to make the JKI State Machine Better, we'd love to hear it!

In addition to feature ideas, we're also interested in knowing what types of design patterns and application examples you'd like to see.

Regards,

-Jim

Hi Todd, Brian,

I've been using it almost exclusively on all code in our reuse library and several projects from versions 2011, 2012, and 2013.  I've had no issues yet.  I've also inlined just about all I can in the reuse library as well without incident.

I jumped into the middle of two projects and converted them to subversion (I miss Hg!) and "separate". No discernible issues.

This is great to hear! Thanks for sharing your results.

-Jim

I'm curious whether people are using the "separating compiled code from source" feature in LabVIEW 2013 with success.  Are people still experiencing any issues? Do we trust this feature yet?

Hey Guys,

I just want to mention that JKI is committed to making sure that VI Tester works well in LabVIEW. We can't live without it at JKI and it's going to continue to be improved.  We've been really busy lately, so that's why there hasn't been a new version pushed out.

We see the LV UTF as addressing a totally different market need than VI Tester.  As I see it: UTF is great for people who want to show 100% test coverage through its static analysis tools -- NI created it to address the needs of people developing for regulated industries.  VI Tester is great for people who want to do better and faster software engineering in LabVIEW -- JKI created it to help test object-oriented (and other) LabVIEW applications using the industry-standard xunit architecture.

I can't comment on time-frames, but please stay tuned and don't give up on us.  BTW, VIPM 2013 SP1 (one of the areas where we've been busy) was just released (do a check for updates)!  We couldn't have done that without VI Tester.

Any chance the updated array functions could be evaluated/included as well? The new Delete Array Elements functions for example can deliver a 100X speed increase compared to the existing ones.

Hey Mads, If you're interested in looking into this and making some specific recommendations, I'd be happy to consider them for inclusion.

Hi David,

I'll work with you to get this proposed fix through the process!

-Jim

I was just curious if there's been any movement on 64-bit support.

Hey Ryan.  Yes, that's right. The main OpenG Toolkit is just a simple way to install everything. There's actually nothing in the package itself -- it just declares dependencies on all the individual packages.

I think it could make sense for OpenG to start moving to 2010, at least, for active development.  This won't negatively impact people using older versions of OpenG, it just means that they won't be able to install newer versions of OpenG into older versions of LabVIEW.  I think the benefits of moving forward outweigh the benefits of staying on older versions of LabVIEW.

Also, it might make sense to change the version of OpenG Libraries to 2010 for those built in 2010 and then create a 2009 branch if any improvements need to also added to the 2009 branch.

Sweet! I'm glad this is working for everyone :-)

It was quite fun to dust off my developer hat too. And I got to use VIPM 2013 which made changing the pallet names of breeze--thanks for that, Michael Aivaliotis!

I was on a roll and fixed/released the new OpenG Time and Array libraries too, so this issue should be resolved for now.

Please let me know if there are any issues once you upgrade to the new versions.

Hey Everyone,

I've rebuilt the OpenG File library (v4.0.1.22) with a fix for this -- I've added the "(OpenG)" suffix to the Window Title and palette names.

vipm://oglib_file?repo_url=http://www.jkisoft.com/packages

Please take a look and let me know if this works well. If so, I'll make the fix for the OpenG Array and Time libraries, too.

It's not a bug. The palettes do not have anything other than names to use as lookup keys. When I designed the shorttcut palettes, I didn't extend this out because supporting multiple items of the same name leads to severe confusion when telling people to drop something from the palettes. Rather than build a bunch of infastructure to try to resolve multiple names, I figured it was better to encourage developers to name things uniquely. And at the time I did it (LV 7.0), libraries were on the horizon to solve any namespacing issues.

Makes sense to me

Speaking of libraries, I just confirmed with Stephen that, if you namespace an existing VI with a library, but leave the VI's location and name on disk unchanged, then existing code that links to that VI should automatically relink to the newly-namespaced VI without issue. We've used this trick at NI on several occasions when adding library namespacing to existing APIs...I see no reason why it wouldn't work for the OpenG libraries as well.

That's great! I didn't know about that (or learned about it so long ago I forgot about it)!  That eliminates one of the biggest technical hurdles around moving OpenG into LVLIBs. Now it just takes elbow grease

So again, the very low-budget solution to this issue would be to figure out the OpenG palette objects that share names with core LabVIEW functions (it looks like there are about 6 of them from the discussion above) and add an "(OpenG)" suffix to their window titles. The more elegant solution would probably be to add libraries to namespace the OpenG VIs.

Yeah, might do an incremental fix of adding the "(OpenG)" suffix, as a stopgap.

I discovered another reason, independent of Quick Drop, that these duplicate palette name issues should be fixed. When you right-click on a subVI, you don't get taken to the correct owning palette for identically named items. Right-clicking on an OpenG File VI should show the OpenG File palette, like this:

 

openggood.png

 

When doing this on the "Build Path" OpenG VI, it shows the File I/O palette instead:

 

opengbad.png

That's a great point, too! And, you just might have (arguably) found another LabVIEW bug ;p

Cheers,

Unfortunately, brackets in palette object names are treated special by Quick Drop, so suffixing with "[OpenG]" would not work. Any other delimeters (parentheses, braces, etc.) should work fine, though. I think I'd prefer if we kept brackets as a library name designation, so if you did suffix the OpenG object names, I'd prefer it be with parentheses.

Would you consider this a Quick Drop bug (that brackets in a VI Window Title would cause a failure of QD)? Might want to generate a Hash of the name and use it as the UID/reference for each item that appears in the list, rather than reference by name.

Would it create any problems (for Quick Drop) to use brackets in the VIs window title so that it looks a little more like what Quick Drop adds to LVLIB members?

For example:

"Build Path [OpenG]"

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?

Quick Drop will list multiple identically-named objects if they are namespaced differently. So one possible solution would be for OpenG to include all of their palette VIs in a library...this would cause both "Build Path" and "OpenG.lvlib:Build Path" to appear in Quick Drop as separate objects.

 

Assuming OpenG does not want to start including palette objects in libraries, I thought the renaming option was a simpler and more viable solution.

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)".

Perhaps my definition of "exists" is subtly different than the typical OpenG developer/user, but I had the expectation that an empty path input would return false.

I find that in most situations where I want to check if a path exists, I'm about to perform a file operation that also requires that path to be non-empty.

I don't think I'd ever use the "File Exists" primitive without also calling the "Empty Path/String?" primitive.

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

<OT>

On several occasions I have mentioned my desire for debug/release configurations like Visual Studio. This could control more than debugging, but also FP bounds so I easily can have off screen controls in the finished VI. At any rate, the current VI property dialog dance is a pain.

</OT>

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...