drjdpowell

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 coul

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