drjdpowell

Although there can only be one thing writing a specific transaction at a specific time, two or more processes can write to the same file (and same table, actually). They just end up writing one after the other.

Just because Actor Framework and DQMH are the two most popular LabVIEW frameworks, doesn't mean there is a binary choice between multiple User Events and the Command Pattern. Personally, I wouldn't recommend either of them for general use (unless you are a scripting wizard, perhaps). And a single message to multiple registered processes is not hard to do without User Events.

There is an example, found this way:

For comment, here is a beta version of the next SQLite Library release (1.11). It has a significant new feature of a "Parameter(s)" input to the "Execute SQL" functions. This can be a single parameter or a cluster of multiple parameters. Uses Variant functions and will be not as performance as a more explicit preparing and binding of a Statement object, but should be easier to code. drjdpowell_lib_sqlite_labview-1.11.0.86.vip

Sorry, I had missed this comment at the time. That is a good idea. https://bitbucket.org/drjdpowell/jsontext/issues/53/force-use-of-decimal-point-in-timestamps

I've seen that trick, but I use a single subpanel containing a "layout" subVI (a subVI containing nothing but a set of arrainged subpanels). Then a reentrant subVI containing nothing but an XY graph is placed in all the layouts subpanels. Limited in how many layouts you can have, but 4x4 is probably the most graphs you can reasonably have.

You can do this kind of stuff using regular plots and subpanels. Don't know if it is any better, but that's what I do.

I've considered a similar flatten-unflatten method, in the default case for clusters too large to handle with the other method, but I've never needed clusters that large and the flatten-unflatten method is ballpark an order of magnitude slower, I would guess.

Go with the second option. In general, the communication channel should be owned by the receiver.

An alternate design is to not use "Wait On Asynchronous Call" and instead pass in a Queue that you use to return the Object. That's the design I would use in any case (I've never used Wait On Asynchronous Call). Your Queue can be a queue of a parent class.

Unfortunately, "Get Dynamic Launch Shell" gets a reference to a VI that calls the "Actor.vi" Dynamic-Dispatch method that is overridden by all your actors; i.e. practically ALL your application code! It could have been anything breaking that rendered Get Dynamic Launch Shell" broken. So it is near impossible to tell what was wrong. If only that error message reported which subVI was the problem...

Thanks for the ideas. For clarification: I don't actually want multiple running instances of the EXE, rather, I need to find out why it is crashing silent. I am running multiple EXE instances to try and increase the amount of deg info (since I can try different configurations in each). So far, my only clue is that all running copies using the dll die within seconds of each other, which implies a common trigger event. Sadly, there is no obvious issues using dependency walker, and no network connections to the dll. Problem seen on multiple PCs, running single or multiple. Trying to rebuild app in LabVIEW 2019 as a test, but proving difficult (builds broken, and it is a very large app).

Note: because of BitBucket dropping support for Mercurial (and their intention to delete a Hg repos in May!?!), I have converted the Hg repo to a Git one, still on Bitbucket under the the LAVAg Team: https://bitbucket.org/lavag/labview-task-manager/commits/

Since I have just painfully converted many years of Hg repos to Git, I thought I'd make a quick note here. I used the procedure described here: https://helgeklein.com/blog/2015/06/converting-mercurial-repositories-to-git-on-windows/ Here is a screenshot of the Windows cmd window: After this one needs to push to the new git repo on Bitbucket (though you could use another service). I could not do this from the command line, but I could push after opening the repo in SourceTree (which I had previously set up to use the right private key to talk to Bitbucket). Personally, I stayed with Bitbucket, partly because I could transfer my Issue Tracker history. It involved Exporting the Issues (under Settings), and then Importing to the new git repo. It was quite painless, except for the tedium of converting many many repos.

Does NXG have shortcut menus on controls yet? Can't really tell from Google because NXG seems to follow a "let's rename everything" obscuration strategy. I see it seems to have subpanels now (renamed "panel containers" to prevent new users googling the past expert knowledge on how to best leverage subpanels). And are those menus modern ones with, say, icons and tip strips? That was something I was looking forward to with NXG: modern menus.

Hi, thanks. Crashes when running only one instance, and on multiple computers. I only ran 5 at once to increase the chance of the crash happening, as it is random and can not happen for many days. Was surprised that they all failed together (the "Application Error" messages in the Windows Event Log were within seconds of each other). This kind of rules out something in the simulated data like an NaN triggering a bug, as they are all independent. Thanks for they idea of running instances compiled under different LabVIEW versions, I may try that. I will also ask the DLL maker about file access.

Hello, I have a complex application which calls a proprietary dll from another company. Recently, we have been having repeated crashes (silent, no error dialog except "Application Errors" in the Windows Event Log). As a test, I ran 5 copies of the application (using AllowMultipleInstances=True in the EXE's ini file). All four copies calling the dll crashed within a couple of seconds of each other (crashes happen only on hours/days timescale) while a fifth, not calling that dll, did not. I am confused as to how all the 4 copies failed at the same time. The dll just does a calculation (complex, but does not access anything external), so I do not understand how all the copies could fail at the same time (they were running independently on simulated random data). Anyone have a similar experience? All copies are presumably running in the same LabVIEW runtime engine; could there be any relation to the Runtime Engine?

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.