Jump to content

Porter

Members
  • Posts

    227
  • Joined

  • Last visited

  • Days Won

    26

Everything posted by Porter

  1. Version 0.4.0.1 has a LV2013 and LV2012 package available for download. If you are running LV2013 or higher, please use the LV2013 package. I haven't had time to thoroughly test the LV2012 package.
  2. I'm currently adding support for 1D string array controls and constants. I will look into moving to LV 2012 after that.
  3. 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.
  4. 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.
  5. 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.
  6. Thanks for the suggestion. I've changed the color to orange.
  7. Added support for SGL and EXT types. Uploaded package to Code Repository: http://lavag.org/files/file/259-floating-point-almost-equal/
  8. Version V1.0.2

    593 downloads

    This package contains VIs for testing equality of floating point numbers within a specified tolerance. Absolute Epsilon comparison, Relative Epsilon comparison and the ULP comparison have been implemented as described in this blog post by Bruce Dawson: http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/ Note that the ULP comparison has not been implemented for extended precision floating point type. Installation and instructions: Install VIP package using VI Package Manager 2014. Examples: "<LabVIEW>\examples\LAVA\AlmostEqual\AlmostEqual_Example 1.vi" Demonstrates the usage of all three AlmostEqual functions. "<LabVIEW>\examples\LAVA\AlmostEqual\AlmostEqual_Example 2.vi" Demonstrates a case where exactly equal fails to produce the expected result. Development version available on GitHub: https://github.com/rfporter/FP-Equal
  9. View File Floating Point Almost Equal This package contains VIs for testing equality of floating point numbers within a specified tolerance. Absolute Epsilon comparison, Relative Epsilon comparison and the ULP comparison have been implemented as described in this blog post by Bruce Dawson: http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/ Note that the ULP comparison has not been implemented for extended precision floating point type. Installation and instructions: Install VIP package using VI Package Manager 2014. Examples: "<LabVIEW>\examples\LAVA\AlmostEqual\AlmostEqual_Example 1.vi" Demonstrates the usage of all three AlmostEqual functions. "<LabVIEW>\examples\LAVA\AlmostEqual\AlmostEqual_Example 2.vi" Demonstrates a case where exactly equal fails to produce the expected result. Development version available on GitHub: https://github.com/rfporter/FP-Equal Submitter Porter Submitted 12/19/2014 Category General LabVIEW Version
  10. I wrote Robust CSV for this purpose: http://lavag.org/files/file/239-robust-csv/ Just specify the delimiter as Tab.
  11. Thanks for the info. MGI's solution looks somewhat like the relative epsilon solution proposed in Bruce Dawson's blog post however they use a fixed maximum relative difference of 1%. Perhaps in some cases that would be too high. Altenbach's version looks identical to the AlmostEqual2sComplement() function described in another article by Bruce Dawson: http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm Notice at the top of that article he states that you should not be using that method of comparison as it has a couple of major flaws. For example, comparing 2 and -2 will always return true. I have added the relative epsilon comparison to the package for completeness. This way, you can try all 3 methods if you are interested. Most of the time I really only need the absolute epsilon comparison because I know beforehand what range of values I'm comparing.
  12. 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
  13. 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
  14. Strings supported as of version 0.3.1: Front Panel - Custom Title Front Panel Decoration Text - All Block Diagram String Constants (Not located within a structure) - Extracted if Label Visible - Labeled String Constants within Labeled Clusters will be extracted. - Block Diagram Array Strings currently not supported. All front pane Controls - Visible Captions - Tip Strips Boolean Controls - Visible Boolean Text Ring Controls - Item Strings String Controls - Default Value Run-Time Menus - Item Name if Item Tag doesn't start with APP
  15. 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.. - To start the program, run the "Launcher.vi" located in the "SET Language Editor" folder.
  16. Version V 0.4.0

    1,488 downloads

    The SET Localization Toolkit provides more convenient edit-time language switching support for LabVIEW 2013 projects. UI text is extracted from an existing project and stored in a localization file. Additional languages can be added then applied to the project using the apply language wizard. The idea is to be able to quickly apply a language to a project before distribution. Applying the language at edit-time allows you to fix up the UI in the target language. Change fonts and re-size controls so that it looks right before compiling it. Features: - No modification of project's source code required. No additional dependencies. - Support for switching code pages. - Ability to define shared resources. - Resources referenced via UID. Changing labels of control does not break linkage. - Resources can be exported to CSV file for external translation. - Resources stored as UTF-16LE text. - Ability to translate RTM files. Requirements: - Unicode support enabled in the LabVIEW.ini file Installation: - Download the ".vip" file and install using VI Package Manager 2014 - Make sure that "UseUnicode=True" is set in the "labview.ini" file Usage: - From within any LabVIEW window, select "Tools->LAVA->SET Project Editor" GitHub: https://github.com/rfporter/SET-Toolkit
  17. View File SET Localization Toolkit The SET Localization Toolkit provides more convenient edit-time language switching support for LabVIEW 2013 projects. UI text is extracted from an existing project and stored in a localization file. Additional languages can be added then applied to the project using the apply language wizard. The idea is to be able to quickly apply a language to a project before distribution. Applying the language at edit-time allows you to fix up the UI in the target language. Change fonts and re-size controls so that it looks right before compiling it. Features: - No modification of project's source code required. No additional dependencies. - Support for switching code pages. - Ability to define shared resources. - Resources referenced via UID. Changing labels of control does not break linkage. - Resources can be exported to CSV file for external translation. - Resources stored as UTF-16LE text. - Ability to translate RTM files. Requirements: - Unicode support enabled in the LabVIEW.ini file Installation: - Download the ".vip" file and install using VI Package Manager 2014 - Make sure that "UseUnicode=True" is set in the "labview.ini" file Usage: - From within any LabVIEW window, select "Tools->LAVA->SET Project Editor" GitHub: https://github.com/rfporter/SET-Toolkit Submitter Porter Submitted 09/21/2014 Category *Uncertified* LabVIEW Version License Type
  18. 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/
  19. Version V1.2.0

    1,474 downloads

    This package contains VIs for reading and writing to CSV files that follow the CSV format outlined in RFC-4180 (see http://tools.ietf.org/html/rfc4180). Using this package, you can properly import CSV files that were exported from spreadsheet programs such as Microsoft Excel, Open Office or LibreOffice Calc as well as export CSV files that will be compatible with any program capable of interpreting CSV files. This implementation of the CSV format is capable of handling escaped fields such as those containing commas (or other field delimiters), multiple lines, and double quotes. Notes: - Starting from V1.1.0, library files are located in "<LabVIEW>\vi.lib\LAVA\Robust CSV" and example is located in "<LabVIEW>\examples\LAVA\Robust CSV". Development version available on GitHub: https://github.com/rfporter/Robust-CSV
  20. View File Robust CSV This package contains VIs for reading and writing to CSV files that follow the CSV format outlined in RFC-4180 (see http://tools.ietf.org/html/rfc4180). Using this package, you can properly import CSV files that were exported from spreadsheet programs such as Microsoft Excel, Open Office or LibreOffice Calc as well as export CSV files that will be compatible with any program capable of interpreting CSV files. This implementation of the CSV format is capable of handling escaped fields such as those containing commas (or other field delimiters), multiple lines, and double quotes. Notes: - Starting from V1.1.0, library files are located in "<LabVIEW>\vi.lib\LAVA\Robust CSV" and example is located in "<LabVIEW>\examples\LAVA\Robust CSV". Development version available on GitHub: https://github.com/rfporter/Robust-CSV Submitter Porter Submitted 02/21/2014 Category Database & File IO License Type BSD (Most common)  
  21. 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?
  22. 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/
  23. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.