drjdpowell

33 minutes ago, smithd said:

but it looked like the VIMs just wrapped the variant functionality

Eventually I want to expand the use of VIM features, but getting rid of the variant-to-data boilerplate is a good start.

29 minutes ago, smithd said:

I didn't dive too deep, but it looked like the VIMs just wrapped the variant functionality, so it probably wouldn't be too much of a challenge to remove the vims and just use one layer lower -- unless I missed something important.

Actually, you can just back save the entire package and use the VIMs unchanged as regular Variant-output VIs.   The only issue that forced me to use 2017 to build the package was that the VIMs wouldn’t appear on the pallets if I built in 2015.

3 hours ago, Tim_S said:

I'm back on LabVIEW 2015, so can't test it... what kind of performance does this have versus the JSON API?

Sorry for the jump to 2017, but the new VIM functionality was just too tempting.   I need to repeat a performance comparison, but here was my earlier tests.  Depends on the use case, but roughly an order of magnitude for the typical cluster to/from JSON use.

Might be something to do with the new VIMs.  I couldn’t build the package without excluding examples that used VIMs.  Did you use VIPM 2017?

And, does anyone else have this problem?

I've just added the (almost-out-of-beta) 0.8 version of JSONtext to the CR.  I have used it in real-world projects but not exercised every feature.

1 hour ago, Paracarro said:

as the 1st thing to do, it executes a "reinitialize all to default"

That's never been true, as far as I know.  The reason to use shift registers is that a local variable will involve a data copy, while a shift register does not.

On July 25, 2017 at 2:58 PM, Tim_S said:

Did you try to get ODBC working with PostgreSQL? Having some out of the box issues with that and see you posted a communication package you were working on in the other thread.

I didn’t try ODBC, as I was using pq, a dll that takes to Postgres more directly.  I would think that ODBC to Postgres would work, though.

1 hour ago, ensegre said:

I actually observed this most, while developing an Xcontrol built around a picture indicator.

That queueing behavior is a know issue with XControls, which are running even when the VI is stopped, so it may have nothing to do with the picture per se. 

I asked a similar question a year ago.   I decided on PostgreSQL, though my project that needs it was put on hold.

14 hours ago, Tim_S said:

Starting off... Currently using files for local test record storage, but also use SQL Server to aggregate data.

I’m using JSON for test record storage.  That can be stored locally, but can also be easily loaded into a JSON-aware database (including SQLite, Postgres and MySQL).  Then one can query against particular items in the JSON.  I’ve done this with the JSON_tree function of SQLite and it worked quite well.   

On June 27, 2017 at 10:05 PM, monzue said:

Looking at the orleans framework actually brought me to ask this question, because I couldn't tell if that framework supported a Messaging queue, or if there was any way to determine the number of messages in the queue.

I had a brief look at Orleans last night.   Very interesting, but it brings up a warning.  Most “actor” programming out there has been developed to handle distributed software-only applications on large numbers of interchangeable servers.  Think 20,000 Halo5 players and 2 or 3 Microsoft server farms.  We, in LabVIEW, are more likely to be dealing with a small number of not-at-all-interchangeable pieces of physical hardware.  We don’t have the option of handling an error by restarting to finish the job on a different server.  So the features of Orleans “virtual actors” sounds very interesting, but not necessarily that applicable to hardware-controlling applications.  I would still look at Akka if I were not doing LabVIEW.

You need to upgrade to the latest 2017 version of VIPM, as that's what I used to build the package.

Latest 1.4.4 version adds a set of "Quick Timer" probes.   These probes are intended to support rapid identification of slow points in code.  They are very simple probes that chart the time since the previous call of any other Quick Timer probe.  The time uses the High-Resolution Timer, and the probes are simple enough to execute in roughly 10 microseconds, so one should be able to usefully time sections of code that execute as fast as about 50 uS.  Use is very quick, too, as one just adds probes along a chain of actions.  Each probe charts the time from the previous upstream probe.  Currently there are probes for Strings, Objects, Variants, I32s and the Error Cluster, and you can mix the types.  Below I'm using the Object version to time SQLite actions, but I could have put some of the probes on the error wire instead.

Not really an “inspiration”, but I do try to study Akka, and it does have similar concepts to Messenger Library, and seems one of the most popular “Actor” frameworks, so if there is a C# version of Akka then that seems a good route.

1 hour ago, Taylorh140 said:

My personal favorite:The Prevent Screen Saver which is attached. (I don't remember where I got it from) It uses the same call that the windows media center does, to prevent the system from sleeping. Its also nice that when the application closes the screen can lock again which I find better. Also it doesn't require admin.

I use the tool from here, which is probably similar.

I use Hg, with TortoiseHg client, and Bitbucket to host the central repos.  

The 1.7 version just added include two significant improvements:

— “Segmented Control”, which is an improved “Selection Buttons” with divider bars and better spacing to get a clean look (thanks to Christina Rodgers from NI).  Previous version had one-pixel gaps.

— Improved buttons (motivated by the techniques discover with the Segmented Control) that maintain a rounded-rectangle boarder in their hover and ON states (the previous version lost its rounded-rectangle shape in those states).  This gives a much better look on hover.   Also allows the ON state to have its colour changed (also possible with the Segmented Control).  

It can be a bit confusing learning how to colour these controls.   One has to click on the outside boarder to colour the OFF state, and inside the boarder to colour the ON state.  Coloring inside the boarder will colour the ON state even when the control is OFF, due to weirdness of the system button’s treatment of colour.

SQLite's DATE() function works on text formats, including the text format this library can write, but not the Blob format (which is the LabVIEW binary timestamp).

You can easily search by time by calling 

SELECT COUNT(*) FROM Results WHERE LVTime>=? and LVTime<?

and binding the two end times.  Bind the end times with the same format that LVTime uses.

Hi Max,

The actual bug, I think, was that “Step.vi” was ignoring errors outside of 1..99.  It has a case structure that only passes those codes to the error-handling subVI (written, originally, because 100 and 101 are not errors).  I have changed it so that the extended error codes are now passed (see version 1.7.3 just added to the LAVA CR).  I tested it by making a foreign key error and it now works.

At some point, when everyone has ridiculously high-res screens, we won’t need antialiasing anymore.

FYI, here is a talk I recently gave on creating some of the controls in Flatline.

Nice work.   Though the problem with using vector-graphic icons in LabVIEW is the lack of antialiasing, especially for small icon sizes.  A PNG icon, if kept at original size, looks better. 

I've run it on an sbRIO (NI Linux).  You have to install SQLite first using opkg.

Note, the latest version, 1.7.2 just posted, includes a “Load Extended Math Functions” method, which loads an SQLite extension dll that adds a large set of math functions to the very limited set in standard SQLite.  The functions are:

Math: acos, asin, atan, atn2, atan2, acosh, asinh, atanh, difference,
degrees, radians, cos, sin, tan, cot, cosh, sinh, tanh, coth, exp,
log, log10, power, sign, sqrt, square, ceil, floor, pi.

String: replicate, charindex, leftstr, rightstr, ltrim, rtrim, trim,
replace, reverse, proper, padl, padr, padc, strfilter.

Aggregate: stdev, variance, mode, median, lower_quartile,
upper_quartile.

Tested on Windows with LabVIEW 32-bit.  Should work with 64-bit as I include the dll compiled with both witnesses, but I have not tested.  See the provided example.