drjdpowell

So’s Joe’s design, now that I look at it. Though your one seems more like his “flattened variant”; how are you going to do the nesting?

Thoughts: If I were approaching this problem, I would create a LabVIEW datatype that matched the recursive structure of JSON. Using LVOOP, I would have the following classes: Parent: "JSON Value”: the parent of three other classes (no data items) Child 1: “JSON Scaler”: holds a “scaler” —> string, number, true, false, null (in string form; no need to convert yet) Child 2: “JSON Array”: array of JSON Values Child 3: “JSON Object”: set name/JSON Value pairs (could be a Variant Attribute lookup table or some such) If I’m not missing something, this structure one-to-one matches the JSON format, and JSON Value could have methods to convert to or from JSON text format. Plus methods to add, set, delete, or query its Values. Like Shaun, I would have the user specify the LabVIEW type they want explicitly and never deal in Variants. — James

Cameras showed up in MAX no problem, but both MAX names would, if selected, lead to images from only one of the cameras. It’s was driver issue, at a lower level than MAX.

I think I’ve seen it with NI-IMAQdx. It’s only with some USB cameras, such as webcams. And it is only when using identical models; one can use multiple cameras of different models, because they go into the Registry under their model names.

It’s adapting to the type of the control it’s connected to, which I did not know it could do.

Had that problem. I believe it is because the Windows software was never made to work with multiple cameras at once. Each identical camera is listed in the Windows Registry under identical names. I believe you can modify the registry, but that is not a satisfactory solution.

Actually, I’ve seen this same effect with an Xcontrol of mine. The same effect occurs if you set the control to “synchronous” and hit the terminal. Note, though that you aren’t directly firing events here; you’re triggering a property, and whatever code behind the scenes is firing “Data Changed” events into the Xcontrol. And the associated data isn’t packaged with the event, it’s provided via the “Data In” input terminal. It isn’t clear that the problem is in the event system itself.

From personal experience, whenever there is a problem somehow involving Xcontrols, my suspicion falls first on the Xcontrol.

You can use User Events "many-to-one” too. Create an Event, register for it yourself, then pass the Event to other processes so they can send you messages.

Can you provide a reference? I’ve only seen mention of that problem when the two events are in different event queues in the same event structure, such as a statically-registered event and a dynamically-registered one.

Hi jg, Really like the tool, except, in addition to renaming, it also moves all the control labels: left centered for controls; right centered for indicators. I know this is a style preferred by many (but not me) and I wondered if this could be turned off? Or better yet, make it a separate tool. — James

Random thoughts on User Events versus Queues: — The event registration refnum is a queue, and it is more instructive to compare this queue to regular Queues rather than compare User Events to Queues. They have different extra features, but in basics they are the same; they serve up the enqueued items to one receiver in order. And one should not have more than one receiver per queue. — The event structure itself can receive from multiple queues. In particular, the statically registered events are in a separate queue from any event reg. refnum attached dynamically. The order that items are served up from different queues is determined by timestamp. This means that near simultaneous events placed in different queues cannot be relied upon to be received in order. However, items from the same queue will always be in order, which means one can use a User Event to reliably carry messages to a process. — A User Event can be thought of as an array of queues; firing the Event is the same as enqueuing to all the queues, and the Event Registration Node serves to add its queue to the array. When created, of course, the User Event is an empty array. Random random thoughts: — a “name” is a reference, the same as a refnum. — “subpaneling” is a silly term

From me. I find them a bit difficult. Just a bit.

The timers output unsigned U32 numbers, and the subtraction will produce the same U32. This cannot be less than zero so that code never executes. Which is not a problem since the subtraction will already handle the rollover satisfactorily; for example: 1 − 4294967295 = 2. Understanding unsigned numbers and rollover is tricky; I usually have to experiment to remind myself how it works every time I have to do it. — James

Welcome to the weird and wonderful frustrating world of Xcontrols. Presumably they don’t bother to update the display when the FP is closed, but I would have thought that some event should be triggered when you open the FP so you could set the display state. But I couldn’t get your control to work.

I’m guessing this refers to a very limited list of events that could meaningfully belong to either VI, like “This VI>>Key down”, rather than the vast majority of events, like on controls, that only one VI can register for.

SDietrich, please see the updated package in the Code Repository. I have not tested it with an actual extension, so please report any problems. Thanks.

You only need to use one; they all wrap the C interface. SQLite itself is public domain, and such a valuable addition to LabVIEW that I feel there really needs to be a package that is free and unrestricted. Shaun provides a high-level LabVIEW API for interacting with the database (with VIs like “Select”, “Create Table” and the like) which may be of interest (though personally I think it’s better to work with straight SQL). SAPHIR’s… well, it’s a company and you pay for it so perhaps you get better tech support. — James BTW, you don’t need a database to do the other parts of my original suggestion. It just makes it easier.

There’s actually three LabVIEW interfaces to SQLite that you should look into: mine, Shaun’s, and one on the LabVIEW Tool Network by SAPHIR. I’m hoping to get mine into OpenG in the next few months.

Suggestion: Hide the graph's inbuilt scrollbar and use separate System Horizontal Scrollbar. Monitor the events from the Graph and Scrollbar and on any change redisplay the data. In fact, I would only display the visible data in the graph: that which is in view and decimated if too many points are in view (no more than a couple thousand points). By keeping the number of points written to the Graph low you’ll get very fast updates, and the user won’t notice that the Scrollbar isn't an inherent part of the Graph. This is an application of a technique described by mje for similar large-data issues with Listboxes. — James As an aside, I would use my new favorite tool, SQLite (here, or here), to actually hold and serve up the data. I believe one could even delegate the decimation to SQLite via an appropriate “GROUP BY” clause in the data “SELECT” statement. I’ve used mje’s technique and SQLite in an error and data logger that can handle large log databases very quickly (and very cleanly — complicated code like your decimation function becomes single-line SQL statements). The User cannot tell that the multicolumn listbox isn’t actually listing 30,000 log entries, even as they drag the scrollbar up and down.

If all one wants is “abort” functionality then that is easily addable to a JKI template. One has use a separate method of receiving the abort command (such as the notifier in Daklu’s example, or just a terminal to poll). I have in the past used something like this, with three extra cases added to the template: 1) “Check for Abort” which checks whatever you use as an abort signal and if true calls “Abort" 2) “Abort”, which if called takes the sequence queue (actually a string) and throws way all text up to the word “Jump_Here_On_Abort:” (throwing away everything if that word is not present). 3) “Jump_Here_On_Abort:”..“Jump_Here_On_Abort:~”, which doesn’t actually contain any code; it’s just a marker used by “Abort" Note that any statement placed after Jump_Here_On_Abort: will execute only if “Abort” is called. Then you write macros where you explicitly check for abort, at places in the sequence where you are sure it is OK to abort. For example: Macro: Ready equipment Check for Abort Macro: Step one Check for Abort Macro: Step two Check for Abort Macro: Step three Jump_Here_On_Abort: Macro: Execute this only on abort Macro: Equipment to Standby One can add a similar functionality to an all-subVI design by using a “Check for Abort" subVI that throws an error on abort, with Jump_Here_On_Abort: replaced by your error-handling code. — James

I may not understand the architecture in question. As I understand it, if you have a subVI Front Panel in a subpanel of the main VI, then clicks on that (sub)Front Panel trigger events in the subVI’s event structure. And Alex is going to communicate this to the main VI via a queue, with the main VI talking back via a User Event. Should all work fine.

Which events don’t work in subpanels?

You’re not going to get much argument Alex. I’m the one advocating QSMs, yet I’m strongly against the common single-queue designs where user input can interfere with an executing macro (in the JKI template, for example, the Event structure is only run in the “idle” case, which executes only when the internal sequencing queue is empty). I don’t even like macros potentially interfering with each other by enqueuing on the back.

I think I should restate how I use the JKI. Mostly I use it for something that either is a UI or incorporates the UI. I use the cases of the case structure not to replace subVIs in general, but instead: 1) code closely related to the UI (where with a case one can use terminals and locals, and one can find the property nodes from the front-panel control right-click menu). 2) high-level code that if in a subVI would be a method of the “clustersaurus” cluster/object and would mainly be called in a simple chain connected by the clustersaur. Calling these instead as a “macro” doesn’t really lose any clarity. At finer levels of abstraction I use subVIs (basically, once I’m writing methods on components of the clustersaur). I do not, thus, "break down each function into small pieces to improve reusability”, at least not with cases. Your complex, enqueue-at-back example strikes me as something that should really be handled at this level (as a single case or clustersaur method). Or simplified, such as by subsuming both C and D under B (so B enqueues in front either C or CD). I am not an advocate of very complex branching logic in the QSM. As I use cases as an alternate to (some) subVIs, I tend to use them like subVIs in that one subVI can “contain” another subVI call. By enqueuing on front, and not having external writers to the internal queue, I can mentally abstract “macros” as unified operations independent of other macros (example: “Macro: refresh main table” refreshes the main display table, it doesn’t depend on what I enqueue after it). Using a single queue for both internal sequencing and inter-loop communication is a major flaw, IMO. All “QSM”s should use two queues. — James