Search the Community

Yer, I like to ask all the big questions... The question was raised here (among other things, but I want to focus on installation directory only) and elsewhere on whether OpenG would be better suited in vi.lib as per the NI requirements for developing third-party APIs etc... Why is OpenG installed to user.lib? That's simple, it's a historical thing. Now due to changes, notably NI opening up vi.lib, things have changed. It also turns out user.lib is so 8.0's (ha! get it?) and vi.lib is now the preferred and more professional approach for installation of third-party APIs. I tested this in LabVIEW 2009. It seems LabVIEW handles the transition quite well, so I think this is doable. You can test it yourself by doing the following: Create a Test.vi Link Test.vi to (any) reuse VI in user.lib Save and close Test.vi Move the user.lib reuse VI to the same level in vi.lib (do not edit any folder or file names) Open Test.vi and watch LabVIEW link to the moved reuse VI I have even played with changing folder names and LabVIEW is able to link to the correct VI. So we could even review if we wanted to change _OpenG.lib to _OpenG or OpenG as per the NI recommendations for Company Name. So what would a change like this mean? I envisage the following for OpenG Developers and End Users: On opening a project with OpenG, the OpenG VIs will be missing, LabVIEW will conduct a search and automatically find the new VIs in vi.lib quickly and with no user interaction All OpenG packages will have external dependencies upgraded to be the latest OpenG packages (so all linkages are correct for that package) This update of OpenG Libraries will be atomic i.e. available to the public all at the same time (as per 4.x release) Thoughts?

I am very pleased to announce the release of the OpenG String Library 4.1.0.12 package as the features were driven by the LAVA community. This package will be available for download through VIPM in a few days. Thanks to Ed Dickens for helping to review changes. And thank you to everyone who participated in the online discussions. Changelog: [MOD] 3303663 - Format Variant Into String__ogtk.vi doesn't handle Timestamp [MOD] 3292424 - Update Trim Whitespace with Fast Trim [FIX] 3275381 - "Slice String__ogtk.vi" has Input or RHS of Connector Pane [FIX] 1958939 - "Scan Variant from String" missing description [MOD] 3275249 - Update OpenG Comment [FIX] 3386135 - OpenG Comment not Merge VI in palette [MOD] 1914597 - Format Variant Into String missing DAQ, DAQmx, and VISA type [MOD] 921506 - "Format Variant Into String" should accept RefNums [NEW] 3419755 - Create new String To Character Array VI Below are some of the changes in detail. New, Faster Trim Whitespace Code This was the first community review that integrated Shaun R's Fast Trim code which was further optimized by Darin K. The VI is ~7x faster than the native implementation! New String To Character Array VI Wouter proposed this new VI which splits a string into an array where each element is a character. The code was optimised by Fab and Darin K. Slice String Connector Pane Fixed The connector pane for Slice String no longer has an input on the right hand side. The original VI was deprecated. I64, U64, VISA, DAQ, Timestamp Support Added to Format Variant to String and Scan Variant From String One of the more requested features is that the Timestamp datatype is now supported in these VIs. ISO 8601 was proposed by Phillip as the default timestamp format however, you can specify any %T type formatting. Thanks to Mellroth with helping out with the format code. Once you have installed the new package, download this snippet to test for yourself: Kind regards Jonathon Green OpenG Manager

This thread was manually moved from OpenG to LAVA.

Hello, I managed to install VI Packet Manager in Ubuntu Oneiric and downloaded many libraries. The problem is I cannot see those libraries in my LabVIEW 2011. I saw Packet Builder is only available for Windows. The VIPM downloaded the ogp files and some other files under its cache folder but I have no idea how to access them in LabVIEW. This sounds extremely trivial and may be that is why I was not able to find the solution after searching for couple of hours. If there is no packet builder in Linux then why do we have VIPM? How do we use the downloaded libraries? Thanks, Şenol

Jason Willis, aka WireWarrior on the LAVA forums, is a CLD from Little Rock, Arkansas, USA and very keen to start helping. On behalf of the OpenG Team I would like to welcome Jason on board and look forward to his contributions! In fact, he will be chairing the Variant Config Update - haven't seen it? - check it out here! Kind Regards Jonathon Green OpenG Manager Wanna be an OpenG Developer too? PM me.

This OpenG Review is now closed. This review relates to this thread here regarding support for the Timestamp datatype in the Format to String VI (among others). With the release of OpenG LabVIEW Data Library 4.1.0.16 it is now possible to parse Waveform and Refnum datatypes correctly (read about the original ideas here) e.g: Waveform (Timestamp) Refnum (VI Server) Therefore this review deals with how to modify the Format to String VI and subsequently its complementary VI Scan Variant From String to support Timestamps. Currently the Format To String VI is in the process of being modified to support: U64 and I64 DAQ Refnums Waveforms (example only - to be discussed here in review) Ideally we would like the same functionality mirrored in Scan Variant From String where possible: However the issue is that is seems that a Timestamp which has been formatted to a string can only be scanned back using the format specifier %T and must have been formatted using the Format to String and not the Format Date/Time primitive. But the Format Data/Time primitive is a more readable string and might be preferred i.e. to format a Timestamp to a string with no intention of converting it back. Therefore the main question is: How would you prefer to see this integrated? What formats should be supported? Should multiple formats be supported so the user can choose which, acknowledging some will not be able to be converted back? To aid this discussion attached is a code stub (if it helps) to get you started if you want to post code. Kind Regards Jonathon Green OpenG Manager

This package will be available for download through VIPM in a few days and covers some new VIs donated by JKI. [NEW] 3426051 - Add new 'Filter Error Codes" API New Palette New Filter Error Codes VIs that support Scalar and Array Error Code inputs New smaller Clear Errors VI (compared to NI) with additional Merge Upstream Error functionality Kind regards Jonathon Green OpenG Manager I would also like to thank Ed Dickens for reviewing this package for release.

This package will be available for download through VIPM in a few days and covers some new VIs. [MOD] 3419758 - Create new Random Number Within Range - I32 VI [NEW] 3422921 - Add Timestamp Constant Kind regards Jonathon Green OpenG Manager I would also like to thank Ed Dickens for reviewing this package for release.

This OpenG Review is closed. See Summary Post here. Please start a new thread to discuss new changes to this VI. VI Name: Supress error Total VIs: 2 Description: This VI has a integer (array), error code, as input and when the error code matches the error code on the error wire it supresses the error. Note: - Blockdiagram: Scalar: Array: Code: Supress Error.zip What are you thoughts on this VI? Would you like to see such a function in OpenG? Can you optimize the code? In which package should it be included? Should it be rejected?

This package will be available for download through VIPM in a few days and contains a small mod to the 4.1.0.8 release: [MOD] 3421698 - Message Digest Polymorphic VI should show instance icons

This package will be available for download through VIPM in a few days and adds the error constant to the palette for use on the BD. [FIX] 3410309 - Add Error Constant to Palette Kind regards Jonathon Green OpenG Manager

This package will be available for download through VIPM in a few days and incorporates a new MD5 Hash? VI and changes to existing MD5 Message Digest. [FIX] 3410441 - Add 'MD5 Hash' candidate to package [FIX] 3410442 - Add Hexadecimal String output to MD5 Digest These are the new/updated VIs: Kind regards Jonathon Green OpenG Manager

This package will be available for download through VIPM in a few days and covers a bug fix. [FIX] 3390029 - 'Delete elements from 2D array.vi' outputs incorrect result This is the output from buggy code: This is the output from the fixed code: Kind regards Jonathon Green OpenG Manager

This OpenG Review is now closed. See Summary Post here. Please start a new thread to discuss new changes to this VI. Please PM me if there are any issues with this thread. VI Name: String to char array Total VIs: 1 Description: This VI creates a array of characters of a string. It splits a string every character. Note: Maybe there should be added another input with which you can tell that the string needs to be splitted every 2/3/4... chars instead of every char. This can easily be done by using the counter in the for loop together with modular arithmetic and a case structure. Blockdiagram: Code: String to Char Array.zip What are you thoughts on this VI? Would you like to see such a function in OpenG? Can you optimize the code? In which package should it be included? Should it be rejected?

There's a VI in the lvdata package called Get Default Data from TD (that accepts a type descriptor input), but there's no equivalent (wrapper) for variant data input. I suggest that a Get Default Data from Variant VI be added to the library, for symmetry (and the fact that it would be useful -- I've needed such a function recently). Get Default Data from Variant.vi

I've been playing around with the variant configuration palette this week, and I think I found a bug in the Write Key (Variant) VI. The VI will insert escape characters into the section and key name strings to conform with INI file syntax. I've noticed, though, that if I use a file path as the name of a section that holds a cluster, it inserts multiple escape characters at each point, instead of just one. The image below explains it (hopefully). It looks like this bug only shows up when two conditions are met: 1. The section name contains escaped characters, like ‘\’. My section names are file paths to .lvclass files. 2. The variant key contains a cluster or an array of unknown type, causing the VI to be called reentrantly. Since the VI has to be called reentrantly, I haven't thought of a workaround yet. (Well, I guess I could restructure my file to stop putting paths into the section name, but I'd rather not have to.) I can think of two approaches to fix it, though. One is to add logic that counts the recursion in the VI and ensures that only the first instance executes the Encode subVI. Another is to encapsulate the multiply executing logic into a reentrant subVI, leaving out things like the Encode subVI so they're only called once from the main Write Key (Variant) VI.

This thread was manually moved from OpenG to LAVA.

This release includes addressing issues involving Invoke Nodes that have been depreciated and do not work in LabVIEW 2010+ Unfortunately the Release Notes are slightly out of date, here are all the fixes: [FIX] 3275377 - Memory Leak in "Current VIs Parents Ref.vi" [FIX] 3275359 - 'Set Control Value {Variant}' function returns error [FIX] 3386881 - Depreciate Get and Get All Control Values {Variant}

This release fixes a bug whereby OpenG LabVIEW Data Library was not included as a dependency.

Format Variant Into String__ogtk.vi doesn't handle timestamps, you get an "Unexpected Datatype" error, as the TDEnum reports it as a Waveform. I have put in place a fix that seems to work without issue, but I can't be sure that it doesn't falsely detect timestamps when processing other types of data. Is this something that can be integrated into the release? Up to this point I just have to remember to copy my version over the OpenG version. It would be nice to not forget and break my code every time I move to a new machine! -jed

ShaunR's LAVA CR Trim Whitespace VI (Fast Trim) is nominated to be integrated into the OpenG Strings package as it is 3x faster the standard Trim Whitespace. The author has confirmed this is ok. You can track this new feature here: ID: 3292424

Just a general though / question and I think this applies to both OpenG & LAVA CR's so I was not quite sure where to put this. I am working on a LAVA CR package and I intend to separate source & compile code and it had me thinking. What is the general take that people have on the separation of source & compile code issue for new tools or LAVA CR's that a LabVIEW 2010 or newer. I did see a comment, but cannot find it now, for NI that this will sometime in the future become the default setting rather than an option. As this setting can be do programming, I was also think that maybe this could be a feature request for the VIPM, similar to the mass compile on install setting. Dannyt

While upgrading the OpenG LabVIEW Data Tools to LabVIEW 2009, we noticed that the unit test for Remove Typedefs from Variant was't passing. Currently, the (buggy in LabVIEW 2009) code looks like this: The comment references a bug in LabVIEW 6.1 related to Variant to Flattened String. Basically, the old (LabVIEW 6.0) method we used was to call Variant to Flattened String and then to Flattened String To Variant as shown here: In 6.1, we changed the Flatten/Unflatten method with a call to Variant to Data and this did the trick (removed Type Defs from the variant). However, it appears that somewhere along the way, this stopped working (perhaps this "feature" was really a "bug" that got fixed by NI). Now, can anyone think of a reason that we wouldn't want to go back to using Variant to Flattened String and Flattened String To Variant? Can anyone think of a better way to remove typdefs from a variant?

This thread was manually moved from OpenG to LAVA.

This thread was manually moved from OpenG to LAVA.