Below is a zip file; it includes a couple of examples.

SQLite LabVIEW.zip

LabVIEW 2011. SQLite dll for Windows (32-bit) included.

NOTE: more recent version now in the Code Repository.

An (incomplete) menu:

Here is the block diagram of Example2:

There are basically two use modes: (1) calling “Execute SQL” on a Connection to run SQL scripts (and optionally return 2D arrays of strings or variants from an SQL statement that returns results); and (2) “Preparing" a single SQL statement and executing it step-by-step explicitly. The advantage of the later is the ability to “Bind” parameters to the statement, and get the column data back in the desired datatype. The “Bind” and “Get Column” VIs are set as properties of the “SQL Statement” object, for convenience in working with large numbers of them.

This package closely follows the SQLite C/C++ interface and is intended to facilitate the execution of SQL scripts, rather than provide VIs that substitute for SQL statements. Thus there are no VIs for creating tables, triggers, etc. The SQLite website provides extensive documentation of SQL and the C/C++ interface.

The only differences from the C/C++ interface are:

1) “Reset” and “Finalize” do not return the error code from the previous “Step” (as this would be both unnecessary an confusing in LabVIEW)

2) The default busy timeout for waiting for a database file that is temporarily “busy” due to another connection is set at 5000 ms, rather than 0 ms.

3) I created a “First Step” VI that wraps “Step”, intended to be the first call on Step that actually execute the statement (further calls to Step increment through return result rows). I did this to allow future potential retry logic in “First Step”, and to have a clearer set of VI icons showing the difference between executing a statement and stepping through result rows.

As I said, it would be really nice to have an SQLite interface in OpenG. I’ve only just scratched the surface of what can be done with SQLite (see, for example, the “Full Text Search” and “R*tree” extensions).

— James

• It's located here: https://github.com/Open-G

I'm hoping this will encourage collaboration and modernization of the OpenG project. Pull requests are a thing with Git, so contributions can be encouraged and actually used instead of dying on the vine.

I am having a big problem in unpacking a zip file containing subfolders on PharLap.

Unpacking attached zip file results in error:

Open/Create/Replace File in ZLIB Read Compressed File__ogtk.vi->ZLIB Get File__ogtk.vi->ZLIB Extract All Files To Dir__ogtk.vi->Untitled 2.vi<APPEND>
C:\q\qqqqqq/IOExport.csv

It seems that the separator decoding does not work properly, so I have looked inside lvzip.llb\ZLIB Common Path to Specific Path__ogtk.vi:

Here I see no case for Pharlap (neither for modern windows), while I guess that it should convert common path "/" separator to PharLap's "\".

Is my guess correct?

I am using ZLIB version 1.2.3 and LabVIEW2017

q.zip

Am I supposed to update them manually before first using them? I didn't find any info about this problem.
Edit: Ok, when I try to update it LabVIEW says it's not 64-bit compatible... Any progress in this direction since 2010?

You can find these functions currently in the LAVA Code Repository.

The code is currently in 2010, but I can backsave to 2009.

Ton

CRC32

Total VIs:

3

Description:

I was suprised LabVIEW didn't had the CRC32. So I made it, http://en.wikipedia.org/wiki/Cyclic_redundancy_check, http://www.ietf.org/rfc/rfc1952.txt. It can take a array of U32, one element of U32 or a string. When needed I can create more CRC checks, CRC8, CRC16, etc... but CRC32 is the most used one I readed.

Note:

-

Blockdiagram:

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?
  

crc32.vi

crc32 (Element).vi

crc32 (String).vi

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

Thoughts? Critisism? Praise? Ideas to make it better? Good for OpenG?

1D to 2D array.llb

2D to 1D array.llb

Final Array Element.llb

Community,

This VI was in the Candidates folder for the String Package.

It has been sitting in there for a while therefore, I have just gone ahead and posted as is (so the license will be migrated on confirmation from the author etc...).

What are you thoughts on this VI?

• Would you like to see such a function in OpenG?
  
• Can you optimize the code?
  
• It may be better suited in e.g. Comparison Package?
  
• Should it be rejected?
  

Kind regards

Jonathon Green

OpenG Developer

Is a GUID.vi

TEST - Is a GUID.vi

Code is in LabVIEW 2009

Numeric to binary string and binary string to numeric

Total VIs:

2

Description:

Conversion of numeric to binary string, and binary string back to numeric

Note:

Could be a good wrapper in my opinion.

Blockdiagram:

Binary string to numeric:

Numeric to binary string (from: https://decibel.ni.com/content/docs/DOC-5782)

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?
  

Time Stamp = "00000000ÍAm#ß~p0000000000"

I'd much prefer they be formatted like:

Time Stamp = "2013-02-13T16:17:39.873Z"

I realize this may run into some localization issues, but I'm fine with defaulting to the ISO 8601 format (or, you could change the "float number format" terminal to a generic "format string" input, and have float/time format strings line-delimited).  The code to do so already exists in "Format Variant Into String", it checks if a waveform is a datestamp type before writing.  This just needs to be ported over to the "Write key (variant)" VI (and correspondingly, to the read VI as well). 

There are a few outstanding issues with the Variant Configuration as well as some feature requests so I thought it would be a good idea to start a summary thread to track them as well as to review all of these at the same time (in case of interactions etc...).

Note: What will be implemented and when is not the point of this thread - that will be decided at a later date by the OpenG Team.

If you know of an issue (link to an existing thread LAVA or OpenG), want to report something or have a new idea please post in this thread.

For anything new, please create (or I will create a) new thread so that it can be discussed in detail.

Please do not discuss these items in this thread - use that item's own thread.

• The point of this thread is to bookmark and manage these items for review
  
• I will keep this original post as up to date as possible
  
• An item with an ID link is a link to an OpenG Tracker
  
• Any item with a description link is a link to an existing thread (LAVA or OpenG)
  

I am pretty excited to see work done on this OpenG Library as this is my favourite OpenG API.

Kind Regards

Jonathon Green

OpenG Manager

Current Items for Review:

ID: 3411108 - Recursive OpenG VIs should use native recursion (if performance benefit)

ID: 3409853 - Reentrancy bug in Write Key (Variant) VI?

ID: 1501747 - Unnamed cluster elements cause problems

ID: 1156973 - Fixed size arrays & Read/Write Panel to INI

ID: 3004519 - Use custom decimal sign for floats

ID: 849694 - Units in INI-files?

ID: 848288 - Missing Key output

ID: 3004517 - Writing to Panel deprecated issues (LabVIEW 2009)

Bug: Read Key(Variant)__ogtk.vi: VI looses variant name

Throw error on duplicate data

Cannot load an array of classes using variantconfig

Some detail on the code change is in this discussion.

This review has the following options:

• Do not add a 'Maintain Phase' input
  
• Add a 'Maintain Phase' input, defaults to 'False' (means that we don't need to deprecate the old code)
  
• Add a 'Maintain Phase' input, defaults to 'True' (means that we need to deprecate the old code)
  

Please add your vote (it's public voting), if you have input for this discussion please add it!

Notice that this VI uses my Global Stop VI found here.

Thoughts? Critisism? Praise? Ideas to make it better? Good for OpenG?

Long Wait.vi

This is my revised version.

Differences:

# elements, current array filter, mine implementation array filter

10000 - 30 ms - 0 ms

100000 - 2154 ms - 5 ms

1000000 - after 7 minuts it was still running - 56 ms

The code:

wgtk_filterArray.vi

The only difference is that I do not remove duplicates from the "items to filter". Further in this implementation the "filtered items indices" are returned sorted. Also the code could (theoratically) be even faster by first sorting the "items to filter" and then use a binary search instead of the labview linear search.

-edit- small improvement, the second loop iterator for indexing the "filtered items indices" array wasn't necessary. Because it can be calculated by substracting the loop iterator by the iterator for the other array.

wgtk_filterArray.vi

There are two main parts to this library. First, I included templates for Action Engines for using Queues, Notifiers, and Events. These AEs are pretty simple, but have become a criitcal part of some of my architectures over the years. They are controled using a type def enum.

The otehr main part is an Functional Global Variable for stopping an application. I called it a Stop Global. The key features with this FGV is a Set and a Reset mechanism and the use of an Event in order to tell an event structure to exit. I didn't like the idea of using a timeout event in order to poll the global. And yes, the event is controled with an AE that was created by one of the templates.

I zipped up the code and left an example of how to use the Stop Global. Everything should be saved in 2011. If you need me to save back to 2009, let me know.

Thoughts? Critisism? Praise? Ideas to make them better? Good for OpenG?

I'll post more of my library for submisison a little down the road.

Messaging.zip

Stop Global Example.vi

Messaging Library Descriptions.txt

I'm publishing this topic for introduce myself, I'm new in this forum and obviously I love LabVIEW!

If someone need some helps or some "advice" I'm glad to answer if I will be able to do it.

Thank you everybody, have a nice day.

Davide.

Modified Wait Until Next ms Multiple__ogtk.vi

— James

http://wiki.openg.org/Arithmetic_Mean_(Functional_Spec)

From the old fora's

I believe there wasn't made any decision yet... was there?

Read this post for start of review.

I’d like to suggest these three VIs (or similar) as possible LVOOP-object additions to the OpenG Toolkit:

“Get Class Name” is a modification of “Get Name of Class of Object” posted by AQ. Here it just returns the basic class name (which I use often in custom probes and the like).

"Get Default Object” is inspired by this discussion and uses AQ’s zero-iteration loop method. This is a very simple VI, but using it instead of the raw code is much clearer to the reader.

“Same or child class” just uses “Preserve Runtime Class” as a tester. Again, the advantage here is code readability (or it will be, as soon as someone comes up with a good icon for it).

Thoughts?

— James

OpenG Suggestions.zip

Is there a way of getting access to these? I was thinking that they had been linked over to the LAVA forums but I couldn't find it.

Thanks

Jason

I'm a LabVIEW coder of about three years. I've never had the opportunity to take the CLAD or CLD exam, but I'm approximately between the two in skill level, based on what I've seen from the practice tests, etc.

I'd really like to get involved in open source LabVIEW work, but don't really have too much opportunity at my new job. I'd really like to strengthen my LabVIEW chops and this seems like as good an avenue as any.

Can I contribute to OpenG, or some other open-source LabVIEW project? If so, how can I get started?

Please forgive me if this has all been answered already elsewhere.

Cheers,

Randy

IP Validation

Total VIs:

strpos.vi, strrpos.vi, substr_count.vi, valid_ipv6.vi, test,vi, unittest.vi, ip2long.vi, long2ip.vi, valid_ipv4.vi

Description:

I saw in the svn of OpenG that there was a candidate for IP validation. But however I think I have a better one. One for IPv4 and one for IPv6, credits for the IPv6 algo goes to http://crisp.tweakbl...d-caveats).html

Note:

-

Blockdiagram:

-

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?
  

-edit- ups I forgot to set the unittests data I inputed in the control as default value... well you can now enter them by hand.

$unitTests = array(    '2001:0db8:0000:0000:0000:0000:1428:57ab'    => true,    '2001:0DB8:0000:0000:0000:0000:1428:57AB'    => true,    '2001:00db8:0000:0000:0000:0000:1428:57ab'    => false,    '2001:0db8:xxxx:0000:0000:0000:1428:57ab'    => false,    '2001:db8::1428:57ab'    => true,    '2001:db8::1428::57ab'    => false,    '2001:dx0::1234'    => false,    '2001:db0::12345'    => false,    ''            => false,    ':'            => false,    '::'            => true,    ':::'            => false,    '::::'            => false,    '::1'            => true,    ':::1'            => false,    '::1.2.3.4'        => true,    '::256.0.0.1'        => false,    '::01.02.03.04'        => false,    'a:b:c::1.2.3.4'    => true,    'a:b:c:d::1.2.3.4'    => true,    'a:b:c:d:e::1.2.3.4'    => true,    'a:b:c:d:e:f:1.2.3.4'    => true,    'a:b:c:d:e:f:1.256.3.4'    => false,    'a:b:c:d:e:f::1.2.3.4'    => false,    'a:b:c:d:e:f:0:1:2'    => false,    'a:b:c:d:e:f:0:1'    => true,    'a::b:c:d:e:f:0:1'    => false,    'a::c:d:e:f:0:1'    => true,    'a::e:f:0:1'        => true,    'a::e:f:0:1'        => true,    'a::f:0:1'        => true,    'a::0:1'        => true,    'a::1'            => true,    'a::'            => true,    '::0:1:a:b:c:d:e:f'    => false,    '::0:a:b:c:d:e:f'    => false,    '::a:b:c:d:e:f'        => true,    '::b:c:d:e:f'        => true,    '::c:d:e:f'        => true,    '::e:f'        => true,    '::e:f'            => true,    '::f'            => true,    '0:1:a:b:c:d:e:f::'    => false,    '0:a:b:c:d:e:f::'    => false,    'a:b:c:d:e:f::'        => true,    'b:c:d:e:f::'        => true,    'c:d:e:f::'        => true,    'd:e:f::'        => true,    'e:f::'            => true,    'f::'            => true,    'a:b:::e:f'        => false,    '::a:'            => false,    '::a::'            => false,    ':a::b'            => false,    'a::b:'            => false,    '::a:b::c'        => false,    'abcde::f'        => false,    '10.0.0.1'        => false,    ':10.0.0.1'        => false,    '0:0:0:255.255.255.255'    => false,    '1fff::a88:85a3::172.31.128.1' => false,    'a:b:c:d:e:f:0::1'    => false,    'a:b:c:d:e:f:0::'    => false,    'a:b:c:d:e:f::0'    => true,    'a:b:c:d:e:f::'        => true,    'total gibberish'    => false);

ValidateIP.zip

Hamming Weight and Hamming Distance

Total VIs:

2

Description:

One VI calculates the hamming weight, the other the hamming distance,

Note:

-

Blockdiagram:

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

SliceString

Total VIs:

2

Description:

The slice string should in my opinion by revised. Currently it is not doing as the name implies it thus. Because it only fetches the subset of a string, which can already be done by the "string subset" function in LabVIEW, the only thing it really does is calculating the length. Because one gives 2 indices, i:j, then length is j-i.

My two VI's are different. They accept a array of indices and then slice them on those places and index the results in a array of strings. Further the other VI accepts a numeric input and then slices the string after each repetition. The end VI should be polymorfic. (The slice string by reptition is in fact the same as the StringToChar function.

Note:

-

Blockdiagram:

Slice string by indices

Slice string by repitition

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?
  

ps. the snippts are in 2011, the VI's in 2009

SliceStringByIndices.vi

SliceStringByRepetition.vi

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

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?
  

String shuffle

Total VIs:

1

Description:

This VI shuffles a string.

Note:

-

Blockdiagram:

Code:

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

Based on Jim's suggestion in my post Select Random Array Indices, I submit this VI: 'Random Int Number - Within range'.

The existing OpenG Random Number VI would presumably be renamed and added to a polymorphic VI.

I chose I32 data types for compatibility with array indexing functions. The default values of one and zero allow this to be used with 'Not Equal to Zero?' to simulate a coin toss.

Discuss.

Random Int Number - Within Range__ogtk.vi

UPDATE:

I was going to provide a link to the existing OpenG 'Random Number' documentation. A Google search found that Jim already submitted something similar to the old OpenG forums, see here. Jim mentions that the high and low are negatively biased and solves this by adding one to the high value and then rounding down.

I think his is better. Rather than duplicate Jim's post and test code, is there a way we can import the discussion from the OpenG board to the LAVA board?

Community,

This VI was in the Candidates folder for the String Package.

It has been sitting in there for a while therefore, I have just gone ahead and posted as is (so the license will be migrated on confirmation from the author etc...).

What are you thoughts on this VI?

• Would you like to see such a function in OpenG?
  
• Can you optimize the code?
  
• It may be better suited in e.g. Comparison Package?
  
• Should it be rejected?
  

Kind regards

Jonathon Green

OpenG Developer

Is an MD5.vi

TEST - Is an MD5.vi

Code is in LabVIEW 2009

Community,

This is the integration of ShaunR's Fast Trim to OpenG's Trim Whitespace function.

Please review the code and submit all comments below.

On testing PC the new Trim Whitespace VI is >3x faster than the native version and ~5x faster than current OpenG version.

Aside from the algorithm change the VI is now a subroutine (like natvie version).

The new interface supports an additional argument Remove non-printable characters (False), see BD for further comments.

Kind regards

Jonathon Green

OpenG Developer

Trim Whitespace (String) 1.vi

TEST - Trim Whitespace (Performance).vi

TEST - Trim Whitespace 1.vi

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?
  

Here is some code I wrote to get the conversation started.

It may not be beautiful code, but I was just trying to create the functionality described in the cross thread (did I get it right?)

I will turn this into an OpenG review if it gets enough interest.

Attached is a String Implementation

Chunking.vi

Example - Chunking.vi

Code is in LabVIEW 2009

I have problems with using VI Package manager at work and also still run LabVIEW 8.6.1, so I don't know if a recent OpenG function similar to this exists.

Select Random Array Indices.vi

IsOdd

Total VIs:

7

Description:

Checks if a number is odd (true) or even (false)

Note:

-

Blockdiagram:

Code:

Numeric IsOdd.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?
  

String equal length

Total VIs:

2

Description:

There are 2 VIs for checking the length of 2 or more strings, after fetching the length it compares the length and returns true if the length of the strings are equal.

Note:

Maybe there is need to trim whitespaces before fetching the length but this should be a optional feature in my opinion.

Blockdiagram:

2 string inputs:

Array string input:

Code:

String Equal Length.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?
  

Temperature conversion

Total VIs:

31

Description:

This VI converts a temperature to one of the existing temperature scalings. One could use the convert unit VI from the pallet. But firstly expression nodes prevent VI's from being inlined also it does not support all temperature scalings.

Note:

Blockdiagram:

-

Code:

Conversion temperature.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?
  

String IsEmpty

Total VIs:

2

Description:

These VIs check if a string is empty and are alternatives to the existing one. I often find myself checking if 2 strings or more are empty to have a fast exit out of one of my string functions.

Note:

-

Blockdiagram:

Code:

StrIsEmpty.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 am trialing a new model of review for OpenG VIs.

I want to enlist the help of the entire LAVA community.

If the VI under review is one that you use in your projects, interests you, or you just have a moment free whilst hanging out on LAVA (I mean, where else would you rather be, right?), then please check it out and leave your feedback.

The aim is - to steal a line from Christina - to get more eyes on the VIs

I am hoping this will lessen the load on individual reviewers whilst increasing the quality of the changes (or proposed changes).

This model is based on the assumption that there are a lot of Community folk who would like to contribute to OpenG but don't have the time to commit on a regular basis.

The reviews posted may be in the form of specs or actual VIs etc...

Feel free to leave your feedback in the form of comments, documents, code (changes, tests) or whatever makes sense!

You can get started by checking out the newly proposed Trim Whitespace VI code.

The LabVIEW community appreciates your time.

Kind regards

Jonathon Green

OpenG Developer

PS - Of course, if you are interested in contributing more to OpenG, please PM me!

This is an exciting release, since a majority of the work was spent trying to make it easier for OpenG Developers to make improvements to (and release new) packages, in the future.

Great work, Jon!

The author has confirmed this is ok.

I have no problem with this.

You can track this new feature here: ID: 3292424

I'd replace it with someting like:

/* This_is_a_free_text_comment_label-Double-click_this_text_and_start_typing_to_replace_it */

Note the spaces before and after the underscore delimited text.