drjdpowell

I did a Circular Buffer using VIMs, so I'm pretty sure one can get the same basic functionality, though i suspect there is advanced Xnode stuff that VIMs can't do.

Terminology is an aid to communication among multiple people, so I'll stick with how I have seen "SEQ" generally used, unless I see multiple people use it differently. There are lots of terms that are not exactly literal; your "watchdogs" aren't actually canines, for example, but I understood the software concept you actually meant.

Oh, sorry, I misread it. Your timing out on an Enqueue of a full Queue, while I have always built "watchdogs" using timeout on Dequeuing from an empty Queue.. In your case you do need to set a single element so as to define "full".

I had a look at your watchdog example. I note that, in my mind, "SEQ" stands for a pattern of using of a one-element Queue like a DVR, rather than any use of a Queue with only one element. I changed your example to use a Queue of 10 elements, and it ran fine, so the single-element nature is not a meaningful characteristic. Even in cases where I use Queues that have to have one element, such as my "Future Tokens" in "Messenger Library", I don't think of them as "SEQs", even though they are literally single-element queues.

Ah, you guys are talking about use of SEQs now, after DVRs were available. I'm thinking about before DVRs existed, where SEQs were often used to get DVR-like functionality. Most of that use of SEQs will have been replaced by DVRs now.

It is my, perhaps mistaken, belief that SEQs were quite often used to fill the gap before DVRs were invented. I'm sure I saw several examples in other people's APIs, and I used them mostly that way. I've used the "back pressure" of a queue, too, but then it's an N-element queue, were N might be set at one, but doesn't have to be, unlike the DVR-like use case where it must be single-element.

All the Tools Network libraries are supposed to have help documentation of some kind. At some point, they insisted I do it.

I don't use DQMH myself, but some suggestions: Re #1 and using the timeout: you don't need to use a fixed timeout; you can write some small subVI that calculates the time remaining till the next scheduled read. For example, if teh last Read was at 98700 ms, the next read should happen at 98800 ms. If it is now 98712 ms, then the subVI can output a 88 ms timeout. If a message is handled, and the time is now 98798 ms, then the subVI will calculate a timeout of 2 ms. You would code in logic of what to do if it is after the scheduled time (either do anyway, or skip). Re #2: you could have the higher-level Module A send a message to C containing the User Event of B's Broadcast. Then C can listen to B, without directly referencing it. B and C would need to agree on the datatype of the User Event, but would not otherwise be coupled. A is doing the coupling, but without handling all the messages.

I eventually "fixed" this by Find-Replacing all three VIMs used in the above large VI with themselves (thus starting the VIMs "from fresh"). There appears to be some kind of state that can be corrupted, that isn't fixed by clearing compiled code cache.

Having problems building my EXE. Generates this error sometimes (when it doesn't just silently crash): Does someone know what the long-meaningless-named VI might be (a vim instance, I'm guessing). Any help appreciated. -- James

There is a page on Path notation too:

Did you look at the detailed help on teh JSONtext VIs? They should all contain links to further documentation pages (or you can go to Help>>JDP Science>>JSONtext...). The "<JSON> tags" page explains:

Just a comment, but I have noticed that people very often deal with JSON by looking for the "monster cluster" that completely converts the JSON into a monolithic LabVIEW structure. I suggest people think a bit more modularly in terms of "subJSON". The first question I would ask you if I were working with you on your actual project is why do you need (at this code level, at least) to convert your variables from their perfectly reasonable JSON format to an array of clusters?

You've solved your problem, but this is the solution I just did:

I've put 0.4 on VIPM.io.

Working on the next JSONtext functionality, which is features to improve support of JSON Config Files. See https://forums.ni.com/t5/JDP-Science-Tools/BETA-version-of-JSONtext-1-6/td-p/4146235

I reported that in 2018: CAR 605085. I don't think they are planning on fixing it. Must use C strings under the hood.

You could ignore the error, with NaN as default pressure and temperature. Or you could read flow first, and only get pressure/temperature if flow isn't "<unset>".

BTW, one other use case I've had is "Multiple applications read/write to common config file", which requires careful thinking about preventing one App from overriding changes made by another App.

I think you just need an extra string for each item to hold end-of-line comments, plus a "no item" data type to allow full-line comments. See how teh NI INI Library does it.

There are actually multiple different use cases of config files, and multiple ways to implement those uses cases. My most common use case is "Computer writes config; Human reads and may modify; Computer reads config". The way I do this is mostly: Read config file into Application data structures. Later, convert Application data structures into config file. Comments don't exist in the Application data structures, so comments get dropped. Another (used, by the NI/OpenG INI libraries, and I'm guessing your TOML stuff) is: Read config file into intermediate structure Query structure to set Application data structures Update intermediate structure with changed values from Application data convert intermediate structure back to a config file Here, the intermediate structure can remember the comments in the initial file and thus preserve them. But, IMO, this is also less clean and more complex than the first method, as you have an additional thing to carry around, and the potential to forget to do that "update" part. Currently, with the latest version of JSONtext (now available!), I haven't really developed this second, comment-preserving method. I am more thinking of another, less common but important, use case: "Human writes (possibly from a template); Computer reads", where the computer never writes (this is @bjustice use case, I think). Here, the human writes comments (or the Template can be extensively commented). But I do intend to support keeping comments. It will probably involve applying changes from the new JSON into the original config-file JSON, preserving comments (and other formatting). But that is for the future. Note added later: the config-file JSON with Comments is now available in JSONtext 1.6.5. See https://forums.ni.com/t5/JDP-Science-Tools/BETA-version-of-JSONtext-1-6/m-p/4146235#M39

Note: that package also has RFC3339-compliant Datetime format VIs, if you haven't already done Timestamps.

Messenger Library uses the same watchdog mechanism, although I just trigger normal shutdown via an "Autoshutdown" message ; I don't call STOP. I would have thought 500 ms is too short a time to wait before such a harsh method.

A "queue" is a first-in-first-out mechanism. Don't be confused by specific implementations; the LabVIEW Event system is just as much a queue** as the LabVIEW "Queue". **Specifically, the "event registration refnum" is an event queue.

As thols says, the best practice is to NOT share things between loops, but if you do, I'd suggest a DVR.