Search the Community

Hello, I’ve been working with SQLite for a logging application and I thought I might offer my SQLite LabVIEW wrapper for possible inclusion in OpenG. There are at least two other implementations out there, both with licensing restrictions, but it would be nice to have this in OpenG as I think SQLite is a major addition to the capabilities of LabVIEW. 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

Having been using the Open G Zip Tools on both Windows and VxWorks targets for a long time I just ran into the issue of compatibility with Linux RT... I'm sure I can find an alternative on Linux RT, but the otpimal solution of course would be to have the existing toolkit also support Linux RT Has anyone compiled and modified the kit already for Linux (or set up a nice replacement)? Are there any plans to add such support in the official version? MTO

Hi all, I've got a customer that wants to zip/unzip files on their cRIO-9035, so I had them playing with the OpenG Zip tools to see if it would fit their needs. Although they've found that they can zip files on their cRIO just fine, they find that they get disconnected from their RT target and the shell shows the following error message: LabVIEW caught a fatal signal 15.0 - Recieved SIGSEGV Reason: address not mapped to object Attempt to reference address: 0x0x10000000 stdin: is not a tty The zip file they're testing with includes two simple .txt files with short strings in them ("booya" and "booya2"). This file unzips just fine on the host PC with the "ZLIB Extract All Files To Dir" VI, but when copied over to the cRIO and unzipped via the same VI, it only unzips the first text file and the resulting file doesn't have any text in it. I've attached a copy of the project and the zip file I used to reproduce this behavior using a cRIO-9033 that I had on hand. (The only thing I can't provide is the cRIO >_<) Could anybody tell me what I'm doing wrong? Any suggestions as to what other workarounds I could take to zip/unzip files on a LinuxRT target would also be very much appreciated! Regards, Tamon Unzip on cRIO-9033.zip

Hello to all. I have an application wich use; imaqdx (displays...), sliders, many controls and many indicators, and everything in a tab control of 3 pages and 2 subVI. I am trying to use "write and read panel to/from ini . vi". The first thing that my program does is to read panel from ini. Here there is the first problem because it gives the next error: "Error 91 "The data type of the variant is not compatible with the data type wired to the type input. Set control value" Here is my piece of code in image attached (boolean input in open.vi is True). I notticed that it gives me an error if the .ini file does not exist (but it should work even .ini file does not exist). Well, my next step was to create a .ini file before to use "read panel from INI.vi". So I use "write panel from INI.vi" and it works fine. It does not give me any error. and the ini file is the next: [medir.vi] Boca = "0,000000" Camara 1 Configuracion = "\00\00\00\1Dremote image 0000000013F9C704\00\00\00\0Anivissvc.*\00\00\00\13LV_ImageDTClassInfo\00\00\00\01\00\13)É\00\00\10\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\10\00¬\00\00\00\00\00\00\00\1D)\13\00\00\00\00\00\00\00\00\00<\04\00\00\00\00\00\00<\04\00\00\00\00\00\00\03\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00€\04\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00DÊù\13\00\00\00\00LÌj\0F<\1E\00\00ø\08\00\00\00\00\00\00\00\00\00\00\01\00\00\00\01\00\00\00\00\00\00\00\1D\00\00\00\00)\13\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00remote image 0000000013F9C704\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\0ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿúïêôÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿËž“Š„€z€}{zzwx|{wwxswyvttquvrtqpprqsrpvppsquqqusputquxusswwssttvwtwt}yqvuxuzvvuwtwvvtvrwrqpupgc\\XYZX\\XW[[UVVWUXTRTRURUQQSPNQNNOKKLKLJLJFEDEEBBC?B??=:>@CDHGHHIJGJEGDFEHJGFDBADDCCEDBCFILS^ao€–³Òñÿÿÿÿÿÿÿÿÿÿÿÿ\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00ÿÿÿÿÿÿÿÿÿÿÿÿÿÿìÛËÚ̾¶³³³¼³Àìÿãϸ¬ª£¤œ‘‘‹Ž‰Œ‡…€†~z~}x{||}z~xx}}v{syx{vwwwzyywxxxxwwuruwzyvwszvzt{z{yv{wy|{vyw{zzwy~y}xzz}y{|€†€‚€€‚ƒƒ†}‡ƒ…‡‡†‹ŠŒŒŽ‹‹•š’–”›žœ› ¡¢©©©±²µ¶º½ËÒåÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿýëä÷ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ Ž‹…†|ƒ}~xv~z{zu{wvvvuutvssqssusotqrwruxtrpqrrotusrvuwywrsuusyxvywxtvsvwuuwvwywquvvuvswtvqpplge^\\VYWYXWYXSWVUZUVQSUTSRTTUNONMKMMKKMJLLLJGEDC@CA?@@@??=CBDGGJLJIJGGIGHEFGFHHCBCBADCAADDIOWZiq„œ·Ôïÿÿÿÿÿÿÿÿÿÿÿÿ\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00ÿÿÿÿÿÿÿÿÿÿÿÿÿÿåÙ×âɺµ®¶¶³·ÍýÿßDz¨¤¢¥š–“‰ˆ‰…‚‚‚~~z}x}}~xxxwyy}xwzwzvywuvxyuxtvyxvvwtyqvpzv|zvzzy{xzzzxx{yxyzyzxw}{y~{}|~€{{|‚‚„ƒ‚…‡€{‚‚„‚‡Š‰‡‰Š‹ŠŒ‰ŒŽ‘Ž’••’“š™žš™›Ÿ¡§ž£ªª®²´»½ÂÉÚïÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿøàéÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿô»žŒˆƒ€~}~}||w{yzxuwwuxvrtvtvtrqpuotqppttvtxsstqqtrtpswtwwvsusuvwxxxxvxuxxvvtx{ux{uuvttxtsssspoja\\Z\\YYZXWYWSSWXWWUSRPTUQSRNQPQNOLNLLKJJIHFFHECA?A?><@?=?ADHFELIHHJIIGEHFGJJDEFBCBECEACDGJPX_fs‡¢»Úóÿÿÿÿÿÿÿÿÿÿÿÿ\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00ÿÿÿÿÿÿÿÿÿÿÿÿÿÿé×Ýã¾·®´´Âº»Ò Camara 2 = "0,000000" led_boca = "FALSE" Buena_boca = "0,000000" mala_boca = "0,000000" Espiga = "0,000000" led_espiga = "FALSE" buena_espiga = "0,000000" Bulbo = "0,000000" led_bulbo = "FALSE" buena_bulbo = "0,000000" Cuello = "0,000000" led_cuello = "FALSE" buena_cuello = "0,000000" mala_cuello = "0,000000" Cuerpo = "0,000000" led_cuerpo = "FALSE" buena_cuerpo = "0,000000" mala_cuerpo = "0,000000" Excentricidad = "0,000000" Buenas = "0,000000" Malas = "0,000000" led_excen = "FALSE" EXCENT = "0,000000" Camara 2 Configuracion = "\00\00\00\15Threshold Destination\00\00\00\0Anivissvc.*\00\00\00\13LV_ImageDTClassInfo\00\00\00\01\00\00\00Á\00\00\10\0000\00\00\03\00\00\00\00\00\00\00\\00\00\00\00\00\00\00Threshold Destination" Excentricidad.<size(s)> = "6" Excentricidad 0. = "<size(s)=0> " Excentricidad 1. = "<size(s)=0> " Excentricidad 2. = "<size(s)=30> 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000" Excentricidad 3. = "<size(s)=30> 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000" Excentricidad 4. = "<size(s)=30> 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000" Excentricidad 5. = "<size(s)=30> 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000 0,000000" Nivel de luminosidad = "157,666672" led_luminosidad = "TRUE" Distancia promedio = "46,131313" Bordes encontrados = "33" Camara2_grafica = "0,000000" Dist_Cuerpo_Cnfig = "0,000000" Dist_Boca_Cnfig = "0,000000" Dist_Espiga_Cnfig = "0,000000" Dist_Bulbo_Cnfig = "0,000000" Largo total = "0,000000" led_largoTotal = "FALSE" cuello_config_cluster.Left = "0" cuello_config_cluster.Top = "0" cuello_config_cluster.Right = "0" cuello_config_cluster.Bottom = "0" cuello_config_cluster.Rotation = "0,000000" top_cuello_prod = "0" botton_cuello_prod = "0" PLC_Valor_Cuello = "0" ampolla_ok_prod = "FALSE" num_disparo_cam1 = "0,000000" PLC_Valor_Espiga = "0" PLC_Valor_Cam2 = "0" lim_min_ambar_boca = "0,000000" lim_max_ambar_boca = "0,000000" Largo Total.<size(s)> = "1" Largo Total 0. = "<size(s)=0> " Tab Control = "Camara 2" Cluster.Numeric = "0,000000" Cluster.Numeric 2 = "0,000000" Cluster.Numeric 3 = "0,000000" Cluster.Numeric 4 = "0,000000" Cluster.Numeric 5 = "0,000000" I resume "camara 1 configuration" because the rare symbols are about x10 more. Well, next step is to read this .ini file and now it does not give me any error but it stacks in "read panel from ini.vi" (maybe it takes about minutes for reading .ini). How can I do to write and read panel to/from ini well? It is very important for my application. Maybe there is another library that I can use? Thanks a lot!

Hi. Im working on this prosjekt where I have a TCP communication between two computers (Server & Klient). I have managed to get communication between those two. (Sending and reciving one cluster.) But I want to send and recive more than one. I looked at det Topic "Passing Cluster and Datatype Through TCP" on how to use the OpenG, but I have a problem with "the Variant to Data". What am I doing wrong? Or is there another way to send more data? The Klient side: The Server side:

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:

After reading this LabVIEW Idea exchange request: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Provide-a-better-way-to-implement-a-polymorphic-VI/idi-p/920487 I was inspired to create VI macro(s) to attempt to address the problem mentioned in the request. Attached is my first attempt and I'm looking for feedback since I know people here have strong opinions. The benefit of this method is that a single vim (or 2 could replace a polymorphic VI with over 48 separate VIs....unless I'm missing something. I know that VI macros are not officially supported by NI, but that hasn't stopped us from using unsupported features before. Some people have probably already done something like this, but I couldn't find an example. To use the files, unzip them and copy them all to your \LabVIEW (version)\user.lib\macros\ directory. Create the directory if it does not exist. For example: C:\Program Files (x86)\National Instruments\LabVIEW 2014\user.lib\macros\ And as described in the wait-ms-with pass through post below, modify your LabVIEW.ini file to have the following ExternalNodesEnabled=True and Optionally XNodeWizardMode=True http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Wait-ms-with-error-pass-through/idc-p/3178218#M31820 Open the Example Changed.vi and review. Changed Example.zip

This thread was manually moved from OpenG to LAVA.

OpenG’s Trim Whitespace fails on a string of all whitespace, if set to trim the front only. It returns the last whitespace character.

My colleagues and I use the Fit VI to Largest Decoration function in OpenG all the time, and it (usually) works like a charm. I've got a fairly small Project, a simple State Machine that takes readings from a Vernier SensorDAQ device and plots it on a graph. I'm using a Queued State Machine pattern, so I begin by creating the State Machine Queue and enqueuing the Initialize State. The first thing I do inside Initialize is Fit VI to Largest Decoration, and it throws Error 1, pointing to the final FP.PanelBounds Property node that it is setting to resize the Window. I also watched this function run with Highlight Execution turned on, and sure enough, the Error line was OK until it got to that final Write to the Property node. My initial suspicion was the SensorDAQ function, even though it hadn't been called. So I took it out, but the error persisted. I also tried making the Fit VI to Largest Decoration the first VI to be run -- same error. Ohh, an idea. The VI in question was written by a colleague, who is not big on LabVIEW style. This morning, I rewrote the entire program, keeping only the Front Panel which has, among other things, a Graph on it. This problem is so weird that it almost has to be something "unconventional" -- I'm going to leave this post here, in case anyone has other insights, but I'm then going to replace the Front Panel and will report back, especially if it fixes the problem. Bob Schor

Hello, I have installed JKI VI Package Manager on my laptop running Windows 7, and everything is working fine. The problem is, we have a desktop computer in the lab which we are not allowed to connect to the internet because it contains sensitive patient information. However, I need to run the labVIEW program that I have successfully made work on my laptop (with the help of the VI Package Manager), on the desktop computer. I am not able to process this data on my laptop due to memory and speed problems. I installed everything that I needed on my laptop with the helpful instructions on this page: http://matio-labview.sourceforge.net/ Without the internet, I have managed to install on the offline desktop: 1. the VI Package Manager, 2. Matio, 3. a 2011 Run-time engine that the VI Package Manager told me I needed (I also needed it for my laptop), 4. The following required Library: http://sourceforge.net/projects/opengtoolkit/ To accomplish the above on the desktop, I followed the exact same steps that were used on my laptop, but since I am not on the internet with the desktop, the VI Package Manager cannot connect to tell me what other openG libraries I need to solve the 'dependencies' problems I am encountering. A list of all the Libraries listed on my laptop under the VI Package Manager is below. Is there a way that I can get all of these onto the desktop? Some way I can transfer and replace a folder(s), so that I can have these dependency problems sorted out? Thank you so much for your help!! Kind regards, Andrew

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]

Currently, saving a date/timestamp to a config file saves it like this: 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).

This OpenG Review is active. 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

This package will be available for download through VIPM in a few days. This release and covers a request for the LabPython package to be view-able under the new 4.x Top Level Menus, and to fix a dependency issue (related to this thread). This package was tested with Python 2.5 on both Windows 7 x86 and Windows XP x86. If any developers want to continue to work on the Labpython project or any other OpenG project just PM me. Kind regards Jonathon Green OpenG Manager

I was using the OpenG Periodic Trigger in an application and notice that my time base was drifting. After spending some time on it and rewritting to make it a little more readable I made a change to fix what seems to be a time leak to me. The change is made where it gets the new time after a trigger has occurred. If someone would take a look and give me feedback that would be great. Could this be an update to the OpenG Time library?Periodic Trigger.zip

It's that time of year again. What will the next installment of the LAVA/OpenG BBQ bring? One thing is for sure - door prize galore! Past prizes have included (just to name a few): home-made creations, gift-cards, tablets, books, Ipods, LabVIEW goodness, software and even a plane-ride. We accept anything - so feel free to be creative! By donating a prize you and your company will receive free advertising in this thread. But wait, it doesn't stop there! When your donation is drawn on the night, you may take center stage and embrace fame thrust upon on you by the loving crowd who are anxious to have their ticket drawn from Crelf's stunningly good-looking akubra. So what are you waiting for? Check out the cool prizes below (knowing there will be more added to this thread as NIWeek approaches). If you would like to donate (please do, we really appreciate the LAVA-love) feel free to add a prize below or PM me with the details and I'll do it. If you haven't already get your 2012 LAVA/OpenG BBQ tickets here!

Hello, I recently used TDMS files in a customer application and for that purpose I made VIs to write/read clusters containing parameters to/from TDMS file. These VIs are basically *copies* of the Read Variant Key.vi and Write Variant Key.vi from the OpenG Variant Configuration File palette so I thought it would be a good idea to add it to OpenG. Hopefully it could help someone. PS: haven't tested these VIs extensively (with all possible data types in LabVIEW) but they do work fine with big clusters containing 1D and 2D arrays. Read Property Key from TDMS File.vi Write Property Key to TDMS File.vi

I ran into an interesting issue with the Array of VData to VCluster when using XControl references as part of the VData. It looks like it puts it together correctly into a cluster, but when trying to type back to the XControl reference type it throws an error. You can convert it back to a normal control type, but when doing generic sets on controls in a cluster that method doesn't work very well. LV2011, Latest verison of the library. Screen shots here and code attached. I actually tried it with a couple different XControls and it didn't work. I wouldn't think that this behaviour is normal, but maybe there are some known restrictions when using XControl references? The references themselves seem a little weird because I did a source build on the project and it changed the type of controls in the "new" cluster constant when LabVIEW compiled it. They were just normal control references made from scratch in the source code and then in the build it changed them. They still said "Control" but when you clicked on them to view the ActiveX class they had Control and MRUFilePath selected. Weird. Anyway, I can probably manually cast these values, but the whole reason behind my method was I just had to add the control ref to a cluster in a class and input the refereces as a variant array and It would load them...no custom loading of the clusters. XControlRef.zip

This package will be available for download through VIPM in a few days and contains new VIs for working with LVOOP data created by drjdpowell. The API has been designed with optimization improvements available in 2012 in mind. The palette has been approved by asbo [NEW] 3484610 - New LVOOP Data Functions Kind regards Jonathon Green OpenG Manager

I would like to see OpenG version of the default 1,2 and 3 button dialogs offered by LabVIEW with an optional timeout. The purpose of such dialog is that it informs the user and allows him to take some action. If the user does not respond in time a default action would be taken. The timeout should default to '-1' meaning a timeout would never occure, the time-out would be configured in seconds, and the default button would show 'button-name[xxx]' with xxx in seconds until that action will be taken. Any thoughts? I'll try to come up with some protypes tomorrow. (perhaps an express VI) Ton

This OpenG Review is closed. See Summary Post here. Please start a new thread to discuss new changes to this VI. 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

I was researching the OpenG variantconfig issue 3005419 about decimal point localization and tried to view some of the files linked to the original discussion on the old OpenG forums. (http://forums.openg.org/index.php?showtopic=1117&pid=3034&st=0entry3034) The problem is whenever I try to access the VI that MADS linked or TonP's png image I get a file access not allowed because I am a guest. 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

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

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?