drjdpowell

Go get VIPM from JKI directly. I have not tested the library on Linux (other than Linux RT), but it should be able to work, if one has a copy of the sqlite3.so shared library installed in the right place. Does anyone else use this library on Linux?

First thing is SQLite has no timestamp data type. You are responsible for deciding what to use as a time representation. SQLite includes some functions that help you convert to a few possibilities, including Julian day, but I, in this library, choose to use the standard LabVIEW dbl-timestamp. The "get column as timestamp" function will attempt to convert to a time based on the actual datatype: Text: iso8601 Integer: Unix time seconds Float: LabVIEW dbl-timestamp Binary: LabVIEW full timestamp The first two match possibly forms supported by the time functions in SQLite, but the later two are LabVIEW ones. You are free to pick any format, and can easily write your own subVIs to convert. You can even make a child class of "SQL Statement" that adds "Bind Timestamp (Julian Day)" and "Get Column (Julian Day)" if you like.

Standard JSON specification for JSON objects is that they are a collection of named elements with order unimportant, so any JSON library should ignore order and match on names. Missing elements is a design choice, though, and I've gone with "use supplied default" rather than "throw error", for a number of reasons. But as LogMAN shows, there are ways to do checking yourself.

I have a project where Absorption Spectra are saved in an SQLite database. Data is stored in a custom format so as to take up a minimum of space. I have a child class of "Connection" that adds a lot of application-spec code, and a matching child of "SQL Statement. Here is the VI that does a Prepare: Here, multiple bits of information are passes into the child class, about the Timezone of the data and the offset time (times are stored as ms relative to an offset, to save space). The "SQL Statement with Scaled Data" child class has several additional Bind and Get Column vis, which have the scaling in then, allowing the calling code to easily work with different quantities (Absorption or Transmission, Local or UTC Timestamps): Here is the Bind Absorption method (the db actual contains a specially chosen 3-byte format that has to be converted to Absorption): So basically, this is extending the Connection and SQL Statement classes to be more capably for a specific application. Note that one does not have to do this, as one can use regular subVIs instead.

That input is to allow one to (optionally) make a LVOOP child class of SQL Statement. Normally one doesn't use this, but you can use a child class to add functionality. For example, I have used it to define new Bind and Get Column methods that store data in a more compressed format. But you probably can ignore it.

It depends on your architecture. If all your indicators are updated in a single place then you can easily defer updates, but if indicators are updated from many different places then update-on-change is more natural.

I would tend towards A.

I also use materialdesignicons, with a standard of either 54% opaque black, or 100% white, which is the google material design recommended values. The semi-transparant black looks grey, but blends slightly with any background colour, which looks nice. Sometimes I use blue to highlight a key control.

I have always done the second method, and just accepted the extra overhead of one extra message pass. Beware of premature optimization. It is generally rare for me to want to just forward a message like this without the forwarding actor needing to change or react to the message in some way. An alternate design is to accept that you don't have an actor-subactor relationship, but that your subactor should really be a helper loop of the actor. A dedicated helper loop can share references no problem. Your "actors sharing references" is a potentially suboptimal mix of "actors are highly independent but follow restrictive rules" and "helper loops have no restrictions but are completely coupled to their owner"

I have never noticed any memory issue, and I wouldn't expect memory as a potential issue with customized controls (the issue that can affect controls is an excessive redraw rate that shows up as a higher CPU load, not memory).

I don't think you can match the raw pull-from-file performance of something like TDMS (unfragmented, of course). SQLite advantages is its high capability, and if you aren't using those advantages then then it will not compare well.

Can you post an example?

First question is what is your table's Primary Key? I would assume it would be your Timestamp, but if not, the lookup of a small time range will require a full table scan, rather than a much quicker search. Have you put a probe on your prepared statement? The included custom probe runs "explain query plan" on the statement and displays the analysis. What does this probe show?

My app failed due to Queues created but not being closed under a specific condition. Memory use was trivial, and logged app memory did not increase, but at 55 days the app hit the hard limit of a million open Queues and stopped creating new Queues.

I have an app that uses a watchdog built into the motherboard. Failure to tickle the watchdog will trigger a full reboot, with the app automatically restarting and continuing without human intervention. In addition, failure to get data will also trigger restart as a recovery strategy. Still failed at 55 days due to an issue that prevented a Modbus Client to connect and actual get the data from the app. That issue would have been cleared up with an automatic reboot, but detection of that was not considered.