drjdpowell

Experimenting some more. I don’t really like either of my switch designs, as they seem too flat to identify as controllable objects. So I’ve worked on a new one (second from the left, below). This seems “just enough” non-flatness to aid in identifying it as a switch.

Thanks. Is there anything you could suggest to improve things (new examples, for example)?

I don’t think you can meaningfully get a generic system, beyond a straight “front-panel manager” thing that has no concept of anything beyond front panels. You’ve already mentioned specific concepts like “launch” and “done” and assigned Panel Close to meaning some kind of “cleanup” is required. Any implementation of that, however done, will make your framework non-generic. I looked into the VIBox XControl that smithd linked to, and I could not use it because it has specific assumptions and implementations of “stoping” a VI. My own Front Panels that go in subpanels-that-look-like-tabs are a mix of Messenger-Library actors, on the one hand, and subVIs with no internal loop on the other, so no system that assumes Front Panels be “launched” or “done” can ever be generic enough for me to use. Now you COULD do a framework for "actors with one front panel each (not necessarily AF Actors)”.

Can the User even close a VI in a subpanel? What are you wanting an event for?

I like it, thanks.

Do you still have that code?

Nope. Painfully tedious manual steps. Trial and error learning all the weird LabVIEW minutiae. I aint doing this twice.

Here’s a similar set of checkboxes. All very clear, though my latest ones are resizable, which is an advantage if the system one is too small. Google icon one is nice but based on PNGs and not resizable. Trouble with Switches (with checkboxes).vi

I include a radio group with buttons in the package (calling it "Selection Buttons”). It also works well if you use icon decals instead of text. Can’t do the nice borders like in that package, unfortunately. That’s an example of something that (to me) should be a checkbox, since it is part of a form that must be submitted. Part of the reason I chose not to add the ‘X' is that it makes it more like a checkbox: check for true and nothing for false. But that requires the User to learn what the funny circles are, and what “white circle to the left” means.

I think is makes a difference if one has one, two, or many switches in view. Many switches both true and false lets one tell the two states apart, especially with radio buttons where only one is true. With a two-state radio button there can still be User confusion. And then there is having a lone switch. The more elaborate design I made is for a lone switch, while the simpler one is for groups. I also have relied on checkboxes in place of true switches. Though I read somewhere that a checkbox implies an option that don’t immediately take effect (such a as configuration or a form that has to be applied/submitted), while a switch suggests immediate control of something.

I’ve been trying to come up with my own consistent set of custom controls that has a more modern “flat” or “near-flat” style. Largely this was inspired by reading Google Material Design, and I’ve just added the results as a package in the CR: Flatline Controls. The latest thing I’ve been toying with are slider switches (here the Material Design guide on switches). But I’m having a hard time coming up with something that is flat and non-skeumorphic, but also clearly a switch. Attached is a VI (2011) with multiple switch types. The most 3D, old-school, looks like a real-world switch (on the left) seems best in terms of being obviously a switch. My most Google-like switch, on the right, is flat and simple, but not immediately obvious. My question is: what of the multiple LabVIEW switches do people actually use? Trouble with Switches.vi

Sorry, James, I missed your post till today. The primary concern I have is whether error code has a performance cost on all the cases where their is no error. I haven’t looked, but I don’t think this is the case. I modified the parsing code a while back to never break up the JSON string, but rather just index along it. This was for performance reasons, but it should mean that you have full access to the whole string at point of error. So I’d recommend reporting back more than just 10 characters, possibly including part of the string before the actual section that failed to parse.

View File Flatline Controls A set of custom controls, following the trend of a more flat UI design. Heavily influenced by Google’s Material Design, though constrained by what can be done with available tools and options in LabVIEW. Uses icons from Google Material Design. — Buttons based on the system booleans (with hover effects). Icons can be added as decals (such as from materialdesignicons.com) — Matched sets of controls for numeric/string/enum/etc., based on Silver controls, but swapping out all ‘chrome’ for simple boxes and lines. — flattened versions of switches/sliders/arrays/graphs etc. Now on the LabVIEW Tools Network JDP Science Tools group on NI.com. Submitter drjdpowell Submitted 06/13/2016 Category User Interface LabVIEW Version 2011 License Type BSD (Most common)

I didn’t notice the MAX install part, so that might be my problem. Thanks.

Here is my current RT version of the example project (to go with the newest version of Messenger Library). To run the actor manager on the RT, you'll need to add it to the project (its in <LabVIEW>/project/Messenger Library).Messenger Library RT Test 2015.zip

Sorry guys, I was on holiday when Stobber asked his question. Rolf has answered better than I could. I have only used polling to identify changes. I tend to have timestamped data with the timestamp as primary key, and getting MAX() of the primary key is very fast. One could also use triggers to increment some field whenever something of interest changes, and then poll that field.

That 15-30 sec figure, at 1.5 to 3 ms per line, seems an order of magnitude too slow to me.

I've just got the evaluation kit for an sbRIO with RT Linux. I ran the example with 'Instrument' on the sbRIO; I found that the OpenG zlib compression library did not deploy to RT Linux. So I had to disable zlib with the following Project Conditional Disable: ZLIB_Compression == OFF Otherwise I didn't make any modifications. But I (so far) have not been able to get my custom probes working on RT, so I'm investigating other RT-usable tools. -- James

OpenG was written before proper recursion existed in LabVIEW, and uses (slow) VI-Server calls to dive into clusters. MGI is more recent and uses proper recursive calls, so should be significantly faster. Personally, I use JSON for configuration files.

Why are you not just (plain-old synchronously) calling the subVI?

References are “owned” by the "VI hierarchy" that created them, and are automatically destroyed if that hierarchy goes idle. Asynchronously-called VIs run in their own independent hierarchy (even if you use the Run method instead of ACBR). In your example, the DVR was destroyed when the launched VI finished.

Why? Actors are tools. One configures a tool for a specific task. You know the task; the tool doesn’t. Why would the tool be responsible for configuring itself?

I use messages containing JSON for configuration, combined with a subVI for handling "Set Config” or "Get Config" messages that accepts config info as either a variant cluster or an array of control references. Once set up, adding new configuration info is trivial.

You could extend your Action Engine to have a “Register” action, which takes a User Event and saves it in an array internally, then posts to the Event whenever the config value changes. Then processes loops can register if they need to be informed when something has changed. Then you have a hybrid AE/messaging system.