Leaderboard

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

UDP does not guarantee ordering, non-duplication or even delivery of "chunks", so you would need to make sure each write contains enough information to completely identify which part of which file it is. That way you could reassemble them on the other side. Even then you may not get them all, so probably want a way to ask for some part of the file to be resent. These are things that TCP would take care of for you. Do you really need to use UDP?

Do you have any detailed information about what "optimizing data update"s actually does?

Thanks to Ram Kudukoli (of NI R&D) for sharing this with us at the recent CLA Summit: If Façade is not executing fast enough to keep up with data updates, it causes the updates to queue up. The updates will happen even after the VI stops running. To reduce data updates: - Open the Xcontrol .xctl file in a text editor like Notepad. - Add the bolded line shown below: <Property Name="NI.Lib.Version" Type="Str">1.0.0.0</Property> <Property Name="NI.XClass.Flags" Type="Int">0</Property> <Property Name="NI.XCtl.OptimizeDataUpdate" Type="Bool">true</Property> <Property Name="NI.XItem.DeclaredLeakProof" Type="Bool">false</Property> - Save the .xctl file.

Well like with any other DLL too, using the Windows API LoadLibrary() and GetProcAddress(). The bad thing about this is that it will make your SQLite library more Windows specific and less portable. My personal choice for this would be to create an extra C file that adds the necessary C functions and then either add it to the SQLite source, compiling my own LabVIEW friendly SQLite shared library, or in order to be able to reuse prebuilt SQLite libraries, create a separate DLL that contains these helper functions. Yes this requires you to use a C compiler for every platform you want to support your library on, but if you start to support more than one platform (and Windows 64 Bit is a different platform already) the maintenance effort of creating those helper shared libraries for each platform and maintaining the platform specific loading of those helper functions is quickly getting a real hassle in comparison to simply creating the helper library directly in C. And your LabVIEW VI library stays all tidy and clean, no matter what LabVIEW platform you want to support. BTW: I was just checking out Fossil from the same author. Looks like an interesting light weight DVCS application based entirely on an embedded SQLLite manager for its datastorage. Advantages: Integrated Issue Tracker and wiki, support for binary files although obviously without merging of branches, simple HTTP based network protocol with SSL support both for syncing but also interfacing with it from a different tool (like a LabVIEW plugin). And all that in a single executable that barely is larger than the SQLite database kernel itself. The disadvantage, if you can call it that, is the rather simple web based user interface to all this functionality.

What you're seeing is the same behavior that all LV controls have. It is why some controls have "Synchronous Display" as an option. The synch display option forces LV to wait until the UI is updated for every write to the indicator. Normal operation will update the UI on a much slower schedule -- so you see big jumps when writing to a Numeric control inside a loop, for example. If you update your XControl using the Value property instead of using the FPTerminal, I'm 90% certain that you'll get the synchronous display behavior.

Here’s what I decided with the Timestamps. LabVIEW Timestamps saved as 128-bit BLOB or 8-byte DBL, or ISO8601 Timestring with “T” and “Z”. The “Get Column Timestring” property recognizes all these formats as well as the standard SQLite text format (sans “T” or “Z”). Shown is a “Test Timestamps" VI that records Timestamps in five ways, the three bindings and two autotimestamping Triggers (using strftime() to get the full ISO8601, and date time()): SQLite LabVIEW.zip

Name: Array Point to RowCol Submitter: LAVA 1.0 Content Submitted: 03 Jul 2009 Category: General LabVIEW Version: 8.0 Version: 1.0.0 License Type: GNU Public Potentially make this available on the VI Package Network?: Undecided Copyright © 2006, dsaunders All rights reserved. Author: dsaunders --see readme file for contact information Description: Converts a pixel coordinate to an array index. Returns an array of indices with a length equal to the number of array dimensions. Also returns if the point is within the content rectangle (not on the caption, scrollbars, etc.) Works on any N-dimensional array regardless of visibility of caption, label, index display, or scrollbars. Designed to be used on mouse events that provide the mouse coordinates. Limitations: Property nodes do not indicate the array border width, nor if the user has chosen to display an element gap. These inputs are thus provided on the VI. Version History: 1.0.0: Initial release of the code. Click here to download this file