drjdpowell

BTW, you should probably explore the "Advanced" subpallet of JSONtext, in particular "Difference.vi" and "Flatten JSON Object to JSONpath Array", as they are useful for this kind of stuff.

That would be a perfectly good choice. You could also use an array of paths like '$[n].Enabled' and call Set Item in a loop. Aside: Note that you could also use a JSON Object rather than an array to hold your list of targets. Like this: { "My Inst X":{"Enabled":true,"Hello":-2,"Hi":6}, "My Inst Y":{"Enabled":true,"Hello":-2,"Hi":6}, "My Inst Z":{"Enabled":true,"Hello":-2,"Hi":6}, "My Other Instrument":{"Enabled":true,"Something Else":true} } I mention this as I have noticed that LabVIEW programmers often get stuck in a mental model of JSON Objects and Arrays mapping onto LabVIEW Clusters and Arrays. In particular note that JSON Objects are not fixed type and number or elements at edit time (unlike Clusters), and JSON Arrays are not restricted to all elements having the same type (like LabVIEW Arrays). I also made the last instrument in my example one with a differences in its config structure. By using JSON, you can still let your User change common settings (like "Enable") even with instruments that cannot be represented as the same LabVIEW Cluster. This is an example of "Duck Typing", which can be difficult to do in LabVIEW otherwise.

You should be using $[*] or $[0] to indicate Array elements; $.[*] indicates all items in a JSON Object and $.[0] is the Object item named "0". Look at the detailed Help page for JSON Path notation in JSONtext.

Two suggestions: 1) Consider using JSON as your config-data format, rather than clusters. Using JSONtext to manipulate JSON will be faster than using OpenG tools to manipulate clusters. 2) Programmatically get an array of references to all your config-window controls and register a single Event case for Value Change of any one of them. Then use their (hidden) labels to encode what config item they set. For example, your control with the caption "Baud Rate" could have the hidden label "$.Serial Settings.Baud Rate" which is the JSONpath to set in your config JSON (or config clusters).

Tried it on LabVIEW 2021sp1, and it seems to have at least fixed the problem with a broken VI requiring manual recompile. No working VI with apparently broken wires yet, either. Possibly I should just up the base version of this package to 2021.

Thanks. I see there is also this one that may be the problem I'm having: 1513139 Malleable VIs Are Sometimes Erroneously Broken When Operating on Cluster Data Value References

Put a new 0.5 version on VIPM.io Remember, this is still beta code.

@AQ, I've incorporated most of your improvements, and made some changes myself. Question, though. These VIMs seem plagued by (in LabVIEW 2020) strange recompile bugs: broken wires that are usually fixed by doing a manual force recompile on the VI. Though often this still leaves some broken wires in a runable VI?!? See image. What do you think causes this and is there a way I can avoid it?

Did you add "file:" to the front to make a URI path. And what do you mean by "does not work"? What are you expecting shared-cache mode to do exactly? Shared Cache has nothing to do with multiple computers accessing a db (and yes, that is something you would be better off using Postgres).

I have never tried shard cache mode. Are you sure you actually need it? If so, try using a URI path to set it following this: https://www.sqlite.org/c3ref/open.html#urifilenameexamples

On the off chance anyone does use this, I have a beta with improvements: https://forums.ni.com/t5/JDP-Science-Tools/Beta-of-Cyth-SQLite-Logger-1-7-2/m-p/4208206 Biggest improvement might be a highlighting mode, as an alternative to the usual filtering, so entries matching the pattern show up in blue:

My point about Network Streams is not that they aren't a useful set of features for some uses cases, but that building something different, with contrary features, on top of them usually makes no sense. For example, the package hooovahh has posted does (if I read it right) use pinging to check messages are being received, and will close the Network Streams if it doesn't receive a response in about 1 second. This destroys the buffers of any waiting messages and means there is no QoS delivery at all, making all that stuff useless overhead. Not that it matters, because it is also a Request-Reply system where there can only be one active Request, and thus there is nothing to buffer. This makes the "explicit buffer sizing" and "flush method" features entirely meaningless. Network Streams are bringing nothing to teh party here but overhead.

LabVIEW.exe has a public moveblock method that you can call. I find it is better to call it directly than inside those subvis enserge shows.

I have my own package called Messenger Library, which is an alternative to those other frameworks. Within that, my template of a message/event handler is called the DEV Template. There is a video on the DEV on the Wiki.

I have just posted a Beta version of Messenger Library 2.0: https://forums.ni.com/t5/JDP-Science-Tools/Messenger-Library-2-0-Beta-LabVIEW-2019/m-p/4199634#M49 This is in LabVIEW 2019

There are a lot of possible options for encoding Variants, all with a different set of advantages and disadvantages. Without a clear use case, it is difficult to see what the best choice would be.

The Type input just sees "array of clusters". Normally one just inputs an empty array; there is no code to look at individual elements of the array. Theoretically, this could be done, but that seems a very low-value use case so chances of me doing that are zero. Actually, it was a mistake of mine to implement the first part of your code; doing it again I would convert Variants in Clusters to 'null' and throw a "Variants not supported" error. This would keep my options open to introduce, without breaking changes, a better Variant support that includes encoding teh data type (along the lines of what Shaun describes). There is a number of possibilities, for example: { "config file:["c:\temp\config.ini",{"LVtype":"Path"}], "Room Temp":["21.4",{"LVtype":"DBL"}] } I am held back from that, partly because it would now be a breaking change, and partly because I have yet seen an example of someone using Variants and JSON that would not be far better implemented in just JSON.

I believe JKI JSON converts to Variants containing the basic JSON-matching types: String, Boolean, Number (DBL, I'm guessing). Then it also provides, if I remember, a special VI to convert that Variant into your cluster of actual specific data types. One of the reasons I don't like that is that it ties things to a monolithic LabVIEW type, the Cluster, that is not as flexible as JSON Object/Arrays. You show the same "LabVIEW tunnel vision" in your design of an array of "Group", "Name", "Value" clusters. That's a common way to handle the limits of LabVIEW. In JSON, the natural structure is this: { "Basic": { "config file":"c:\\test\\config.ini", "Operator:"Muller" }, "Extended": { "Room Temp":21.4, "Test No":0, "ping":null } } That isn't really doable with your LabVIEW Arrays and Clusters, even if I give you some extra Variant support. But you have tools to do stuff like this in JSONtext.

I would encourage you to try the "subJSON" described in the conversation LogMAN linked to. Basically, replace your "Value" variant with a string labelled "<JSON>Value", and convert your values to JSON (at all the places where you now have "Set Data Name__ogtk.vi"). Then, wherever you are converting your variants to strict type, instead convert the subJSON to that type. The problem with using Variants and JSONtext is that the JSON doesn't contain the specific type information needed to recover the data in the Variant.

I don't have the filtering syntax of JSONpath yet implemented in JSONtext. In fact, you surprised me by seeming to indicate that $..[?(@.folder=="User/Admin/UserA")] actually works, when it doesn't. At some point I may have teh time to implement that, but in the meantime consider filtering code in LabVIEW like this

That's right. And make sure you test your code as it changes to/from Summer Time, as that is where once a year bugs can happen.

I used to use Scan From String function, with %T codes: But I wouldn't say this was any stronger than your method. Now I use a reusable library for RFC3339 (subset of ISO-8601). This uses Scan From String mostly, but is robust against a variety of edge cases. Also handles things like the Local Time plus Offset format, which is nice in that it stores both Local Time and UTC time:

There I was thinking about a simple fix to your immediate problem, rather than the much bigger change of switching to UTC. Using DST=-1 is to use true Local Time, which is what your Users will find most intuitive. But one time a year your times will jump back one hour, which is a rather problematic behaviour. You could use Local Time never corrected for Summer Time; easier for you but confusing to Users. Aside: I suffer the programmer disadvantage of living in the Western European Timezone, which is the same as UTC for half the year, making it hard to notice errors in my UTC-Local conversion. I often have my computer set to a far away Timezone when I'm debugging time-related things.

But to answer you question, I would go with DST=-1. There will be one hour per year (Fall Back) where LabVIEW won't be able to know what the UTC time actually is (as there are two possibilities), but otherwise it would work. Note, though, that i never use that function that you are using.

I also strongly recommend using UTC usually (with conversion to Local Time for display). And using an existing, hopefully well tested, library to convert to/from ISO-8601 (my own functions are in https://www.vipm.io/package/jdp_science_lib_common_utilities/, though they are intended just for the RFC3339 internet standard and may not be as complete as Francois').