Porter

I figured that it was worth posting about the it here with "Package Not Compatible" in the subject just in case someone encounters the problem when trying to install a package from the code repository. A quick search of the error message on the LAVA forms should bring them here.

I tried to install one of my packages using VI Package Manager 2013 and was surprised to see the error message "This package is not compatible with any LabVIEW version on this computer."

The package is supposed to be compatible with any LabVIEW version >= 8.6 and I have 2013 installed. After some Googling, I found this: http://digital.ni.com/public.nsf/allkb/9A84C532AB9268BD86257CEF00794E70

It turns out that I had compiled the package using VIPM 2014 and thus it is not compatible with VIPM 2013. I suppose that this makes sense but the error message shown in VI package manager is very misleading.

So in conclusion... Keep VIPM up to date otherwise you might get misleading error messages when trying to install new packages.

I will look into adding this feature. The reason why I made a static language list was because I link the language to its associated code page. I suppose that it would make more sense to store this information in a config file that the user can modify.

Thanks for the suggestion. I've changed the color to orange.

Added support for SGL and EXT types. Uploaded package to Code Repository: http://lavag.org/files/file/259-floating-point-almost-equal/

Saved to LV 8.6

I wrote Robust CSV for this purpose: http://lavag.org/files/file/239-robust-csv/

Just specify the delimiter as Tab.

The other day I encountered a situation where I wanted to test if two floating point values were equal. Of course, one of the first things that you are told about floating point values is that you should never test for exact equality. So I proceed to wire up:

Is X = Y +/- some acceptable tolerance?

And that worked perfectly for my use case. That is, I knew that the max. value was 1000 and the min value was 0 and the resolution (or increment) was 0.01. A tolerance of 0.001 was sufficient.

This got me thinking. Wouldn't it be nice to have some reusable VIs for testing if floating point values are almost equal? Unfortunately this meant taking a broader view of the problem and lead me to this interesting blog post:

http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/

I've attached VIs for the Absolute Epsilon comparison, Relative Epsilon comparison and the ULP comparison described in the blog post for double precision floating point values.

Perhaps this would be a nice addition to the somewhat barren OpenG Comparison Pallet?

Uploaded package to Code Repository: http://lavag.org/files/file/259-floating-point-almost-equal/

AlmostEqual_LV2013.zip

AlmostEqual_LV86.zip

I've thrown together a user manual. Its included in the Documentation folder of the latest version (V 0.3.3).

You can also grab a copy here: https://dl.dropboxusercontent.com/u/8640811/SET%20Toolkit%20-%20User%20Manual.pdf

Strings supported as of version 0.3.1:

Front Panel

- Custom Title

Some important things to note:

- The source posted is actually for LabVIEW 2013.

- Version 0.3 is an alpha release. Expect to encounter bugs.

- Make sure that you add "UseUnicode=True" to the LabVIEW.ini file and restart LabVIEW before running the program..

I've posted the (modified) read CSV along with write CSV VIs as a package in the Code Repository: http://lavag.org/files/file/239-robust-csv/

Thanks for the info Phillip.

It's unfortunate that I didn't find your post earlier. Your VI is about 8 times faster than mine. Converting to a byte array and replacing CR/LF with ASCII record separators and commas with ASCII unit separators is a very good idea. Using indexed for loops instead of while loops to build the array must also make a big difference.

I was also using trim white space on every cell which is actually not correct.

I modified your VI slightly to fit my application:

- removed file open and path input/output (I don't want that functionality)

- added support for field delimiters other than the comma. Tested with tab and semicolon.

- force all end of lines to LF before processing. This avoids causing a blank row from a CR+LF.

Would you like me to post the modified VI here?

After many frustrating experiences with patched together CSV parsers (admittedly of my own creation), I've finally broken down and developed a CSV file parser that follows the RFC-4180 format: http://tools.ietf.org/html/rfc4180

That is to take into account double quotes and commas inside double quotes and multiple-line entries. This is essential if you plan on storing user-input text data or storing numbers that may have a comma as a decimal point.

From what I can tell, this is the same format that Open Office, Libre Office and Microsoft Excel use for their CSV file export. Therefore, using this format, you can export from LabVIEW to CSV, open it in Excel, make changes, export from Excel to CSV then import it back to LabVIEW without everything being broken by a missing double quotation mark or an extra comma.

Attached is the VI to parse a CSV formatted string to a 2D array of strings for LV 2013, 2012 and 8.6. I've also attached an example CSV file (inside Test1.zip) exported from LibreOffice to demonstrate some of the tricky cases that most CSV parsers can't handle.

Please give it a try and let me know your thoughts.

Update: I've posted the finished library to the Code Repository Database & File IO catagory here http://lavag.org/files/file/239-robust-csv/

I was looking for a way to simply pass status messages from anywhere in my application to a log file and/or a status message box on my user interface without having to pass a queue reference or event reference everywhere. I wanted something like the good old printf() command that I could litter throughout my application. I also wanted something that didn't take much place on the block diagram. This is what I came up with.

This VI sends the message string along with a time stamp and the call-chain to listeners of the "stdout" event (only if the specified verbose level less than or equal to the globally set verbose level).

The message received by the stdout event handler is an instance of the "LV_Printf Msg" class. The data is available though property nodes or it can be flattened to a string through the dynamically dispatched "Receive Message" method. You can create a child of this class and override the "Receive Message" method to format the message differently.

Please try it out and let me know your thoughts.

Source & Example Usage - LabVIEW 2013: LV_Printf - 2013.zip

Source & Example Usage - LabVIEW 2011 (not tested): LV_Printf - 2011.zip