Search the Community

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 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 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 bug fixes, performance updates, and new VIs. [FIX] 3386531 - Get Array Element Default Data does not support Timestamp [FIX] 3252254 - "Set Variant Name.vi" Kills Attributes [FIX] 3386530 - Create new Waveform and Refnum TD subtype VIs [FIX] 3386538 - Update Variant Constant to LabVIEW 2009 appearance [FIX] 3411109 - Recursive VIs should use native recursion (lvdata) [FIX] 3411324 - New VI: "Get Default Data from Variant" Waveform and Refnum Subtype Enums There are now new VIs and Enum Controls for determining the sub-type of Waveforms and Refnums datatypes. These VIs were designed by Jim Kring and solve the issue of parsing such datatypes as e.g. Timestamp (Waveform subtype) and VISA (Refnum Datatype). This will allow OpenG support such (sub) datatypes in e.g. Format To String.vi in the near future. Get Default Data from Variant This VI forms a thin wrapper around the Get Default Data from TD.vi complementing the Variant API nicely. You can New Variant Constant Image The Variant Constant image has been updated to be inline with the change made in a previous LabVIEW version both in the palette and on the block diagram.] There is no functional difference between the two constants. Here is a Test: Kind regards Jonathon Green OpenG Manager

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

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

There are some OpenG VIs, like the Variant Configuration File IO VIs, that use the legacy form of recursion (VI Server Call By Reference to self), which is (I believe) much less efficient than using the native recursion feature introduced in LabVIEW 2009. I would recommend changing all VIs that use legacy recursion to use native recursion, provided that a performance improvement would be gained. Here's a screenshot, showing what I mean:

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?

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.

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?

Copyright, trademarks - all this legal stuff gets tricky! Here is a documented experience from a LabVIEW development company that had to change their brand names due to a conflict. Licenses can get complicated too. Did you know that any application you create in LabVIEW requires a copyright notice regarding NI? Essentially I want to make it easier for users and to lessen confusion (if any) when using OpenG. So, I want to start by talking about the OpenG licenses. There has been some questions raised about how to license applications that make use of OpenG libraries (e.g. here). See here for an example of referencing OpenG in an application. I started to review the OpenG license and other licenses and see if we can do anything better or to make it easier for developers? Please join me in discussing this with any feedback, comments and improvements you may have. As it stands, we use the newBSD license aka the BSD-3-Clause license. Which is really good as is supported by the Open Source Initiative unlike the Original-BSD aka the BSD-4-Clause license. I have been looking at the Simplified-BSD aka the BSD-2-Clause license (which is also supported by the Open Source Initiative) and even Creative Common licenses. I think the newBSD is a good choice - what do you think? My next question is can the copyright in the license of the VI simply reference OpenG. By that I mean does each author have to appear in the license of each VI? This is by no means wishing to offend any authors, but this would simplify the copyright documentation. This would increase maintainability for the OpenG developer. And it would also standardise it. For example if there was a change to the license type in the future, you could not simply cut and paste a new one as each VI has different authors, so each license is different. We could still manage authors at the package level. And we could add authors to the VI Description. This would increase visibility because the LabVIEW Context Help would show that information. If a change as the above was ok, then referencing the use of OpenG in an application would be pretty simple too. If you add new VIs, remove VIs and authors change over the course of the project or releases, that copyright would not change - exactly the same as referencing National Instruments. This would increase maintainability for the End User. I am thinking that just referencing OpenG won't fly for the authors though (and fair enough) so I will also propose that the license is standardized to reference OpenG and we separate authors out into the VI Description under a Tag which would become searchable (more on that later) then I will create a tool that parses that information and outputs it to a text file and have an API where that file can be read in and the End User can then format the information in any way they wish to to include it in their license file. As an OpenG Developer this tool would help keep the new Package License Files up to date as well (this feature was introduced into VIPM 2010). I came up on this idea on my own, but Google has proved that someone else has thought of it, but no one has implemented it. The only other place I have seen Tags used is in Quick Drop (have I mentioned I love Quick Drop?) anyways we can analyse that implementation but I would like OpenG to define the standard for Tags in the VI Properties because I see this is also handy, not only for OpenG code but any re-use code used in an application, now or in the future, that an End User wants to reference in their application. Just run a tool (script) over the code and information is output to a file. As per moving the Authors to the VI Description, I also propose that the Name and Description is removed from the license as it is redundant information and means extra maintainability/work. I also propose that the license is moved to the BD to preserve FP space, and use a window of set size (to standardise it) and add the following notice (or similar) on the FP (bottom left hand corner). The current license would change from this... Get Data Name.vi Returns the name of the data wired on input. Please visit http://www.OpenG.org to learn about the Open Source LabVIEW software movement. NOTICE -- YOU MUST LEAVE THIS NOTICE IN PLACE. PER THE TERMS OF THE LICENSE BELOW, YOU MAY SUBLICENSE THIS SOFTWARE IN ANY WAY THAT DOES NOT CONFLICT WITH THIS LICENSE. ### BSD License (http://www.opensource.org/licenses/bsd-license.php) Begin ### Copyright (c) 2002, Jean-Pierre Drolet <drolet_jp@hotmail.com> Copyright (c) 2002-2006, Jim Kring <jim@jimkring.com> All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of SciWare, James Kring, Inc., nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ### BSD License End ###[/Code] ...to this: [CODE] Please visit http://www.OpenG.org to learn about the Open Source LabVIEW software movement. NOTICE -- YOU MUST LEAVE THIS NOTICE IN PLACE. PER THE TERMS OF THE LICENSE BELOW, YOU MAY SUBLICENSE THIS SOFTWARE IN ANY WAY THAT DOES NOT CONFLICT WITH THIS LICENSE. ### BSD License (http://www.opensource.org/licenses/bsd-license.php) Begin ### See VI Description for Author information All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of OpenG, nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ### BSD License End ###[/Code] [size=4][b]Thoughts?[/b][/size] [size=4]Cheers[/size] [size=4]-JG[/size]

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?

Crelf has proposed a minor update to the OpenG Comment in the OpenG String library.

This thread was manually moved from OpenG to LAVA.

This thread was manually moved from OpenG to LAVA.

This thread was manually moved from OpenG to LAVA.

This thread was manually moved from OpenG to LAVA.