Wouter

There are several .dll availables for .NET. You can use them also in LabVIEW. http://www.google.nl/search?q=qr+code+generator+dll. Further when you google on "ISO/IEC 18004:2006" you may or may not find a .PDF file containing the ISO/IEC specification of QR code, enabling you to fully implement QR code in LabVIEW. However note that the .PDF is actually not the latest edition "ISO/IEC 18004:2006" but the previous "ISO/IEC 18004:2000".

I disagree! I like the concept. But I think it would be much more suitable for kids to learn like this then adults.

VI Name:

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

Further I was thinking about the following... do we need to add point-to-point means? For each one of them?

Weighted Mean (1D).vi

Quadratic Mean (1D).vi

Generalized Mean (1D).vi

Harmonic Mean (1D).vi

Geometric Mean (1D).vi

Midrange (1D).vi

Because Altenbach also wanted the VI to work for complex numbers... some reading material: http://faculty.sfasu...plexNumbers.PDF

Further... what about the geometric mean, harmonic mean, quadratic mean, weighted mean, truncated mean, midrange, http://en.wikipedia....i/Average#Types

http://forums.openg.org/index.php?showtopic=820

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

From the old fora's

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

Do you really need the voltage level? Or do you only need a indicator for the how much % of the battery level remains. If the latter you can just use the "GetSystemPowerStatus" function, it also returns the % level of the battery.

If not you can use PowerReadACValue; msdn.microsoft.com/en-us/library/windows/desktop/aa372734(v=VS.85).aspx

or PowerReadDCValue; msdn.microsoft.com/en-us/library/windows/desktop/aa372737(v=VS.85).aspx

for all power management functions you can look here: msdn.microsoft.com/en-us/library/windows/desktop/aa373163(v=VS.85).aspx

Thanks for your post, with a clear overview of the benefits.

Most of the stuff I readed @ http://zone.ni.com/devzone/cda/tut/p/id/3727 (sorry had to read first before asking ), it then made me more curious about the disadvantages... because how NI describes it, it is the best format available which I doubt.

Poly VI with CRC8, CRC16-CCITT (0x000, 0x1D0F, 0xFFFF), CRC-IBM, CRC32

Some reading material:

http://en.wikipedia.org/wiki/Cyclic_redundancy_check

http://www.pvlteam.com/doc/crc/algos.htm

http://www.miscel.dk/MiscEl/CRCcalculations.html

http://web.archive.org/web/20071221025748/http://www.joegeluso.com/software/articles/ccitt.htm

crc.zip

Other question... I don't really know anything about TDMS... But why save data in those files?

crc16-IBM

CRC-16-IBM x¹⁶ + x¹⁵ + x² + 1 (Bisync, Modbus, USB, ANSI X3.28, many others; also known as CRC-16 and CRC-16-ANSI)

crc16 IBM.vi

crc16 CCITT

crc16 CCITT (0xFFFF).vi

crc16 CCITT (0x1D0F).vi

crc16 CCITT (0x0000).vi

@Ton: you mean the hamming weight... http://en.wikipedia.org/wiki/Hamming_weight, and yes.

not the hamming distance ;-) http://en.wikipedia.org/wiki/Hamming_distance

@Ton, in the rfc1952 they even use unsigned long. So I would earlier change it to u64 then u8

Question what exactly needs to be done before the code gets reviewed for OpenG? I guess that the diagrams need some cleaning up. But anything else?

VI Name:

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

Euh ontopic ?

VI Name:

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

And the VI's

BinaryToNumeric.vi

NumericToBinary.vi

Okay, well here are the VI's then :-) (I could not edit the opening posts)

StrHammingDistance.vi

StrHammingWeight.vi

VI Name:

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?
  

VI Name:

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?
  

For this particulary example I disagree with you. Comment is good, but all the comments in this particular example are in my opinion not needed since the code is very straight forward.

When coding in C I wouldn't either comment code like "lenVariable = strlen(strVariable) // get the length of the string"

In my opinion only parts of code which are not that straightforward, certain parts of a algorithm, should be documented. When all the parts of the algorithm are straightforward, as in this case, the only thing that needs to be documented is what the algorithm exactly does, which is already done in this case.

_{Of course one could discuss about what the exact definition is of straightforward.}

I also just checked and can't seem to find it underneath LabVIEW 2011??