topic Re: Community Nugget Series: Application Development: Installment 2- The GUI and FP object encapsulation in LabVIEW

Community Nugget Series: Application Development: Installment 2- The GUI and FP object encapsulation

JÞB — Thu, 14 Apr 2011 16:29:51 GMT

Community Nugget Series: Application Development: Installment 1 can be found Here

Welcome back!

In Installment 1 of this nugget series I laid out a Model and and Architecture that I will use to develop an Automated Test System application. Today I will discuss some key considerations for the GUI or Corporate Communications Unit of the Test System Model:

All GUIs have some design targets. As a rule they should:

Be Responsive to user actions
Be Visually appealing
Group objects to present data in logical arrangement
Objects should have a clear and intuitive purpose
Provide amplifying instruction to the user
Provide users with system state information
Prevent irresponsible / illogical usage
Present a Familiar feel for similar application models (Leverage re-usable code components)

It would take months to fully delve into best practices and ideas for GUI construction. I recommend visiting the UI Interest Group Community pages for some excellent discussion on the HOWs of GUIs and many good ideas on the subject. Today, I want to focus on the ATS challenges to provide a responsive front panel while remaining informed by the rest of the system.

The ATS application Corporate Communications Unit is going to receive requests to take actions from a user and from other business units at times that cannot be pre-determined. From the Model Diagram we know it is not going to do much about theses requests other than to hand off most of the time consuming tasks to the Executive unit and wait for the next request. In our "Business model" this make sense. A customer walks in the door and asks the receptionist to "Test a Widget" for them. Bad practice would be for the Receptionist to go to the production floor, Test the widget, File a report, update the database and wait for the customer to review the data (if they are still there- I'd walk out!) A better practice would be for the Receptionist to let management know about the customer's request, show the customer test progress and see if there is anything else the customer needs while they are there.

A quick look through the LabVIEW VI templates shows a "Producer/Consumer Design Pattern (Events)" template that most closely matches our model of the data exchange betweenCorporate Communications and the Executive department

Time to look at the ATS implementation:

For development purpose I have added some decorations to set off FP boundaries and help ogranize BD Layout. The Top is a banner section that provides application information: (A coprorate Logo is hidden in the Pict Ring showing my CLD logo) and, not all functionality is shown or even available yet (We'll add some in a bit!) But the VI RUNS!

The BD looks like this in Rev A.

As you can see the BD does some initialization, Enters an event loop that enqueues notifications to the Executive and performs some clean-up after the user chooses to exit. Additionally, a second loop is spawned to synchronize the display of the Breakpoint array and the Table so when the Table scrolls up or down the Breakpoint array moves as well. (Note: This COULD be done in the event loop With an index value change test but scrollbars generate lots of index value changes, the user won't notice the 150mSec delay on the breakpoints following the data)

Most of the GUIs functions a encapsulated in sub-vi's that perform generic actions. Most developers have a library of "re-use" components that can be dropped as needed on a block diagram. Some "Come in handy" and some are "indispensable."

Let's take a look a three of these I use

To Be Continued.....

Re: Community Nugget Series: Application Development: Installment 2- The GUI and FP object encapsulation

JÞB — Thu, 14 Apr 2011 17:43:37 GMT

First Delay.vi:

Available Here : Just a common Wait with error handeling utility. But it points out that a LOT of example code exists on the NI website. Don't overlook the wheels that have already been invented! I use this vi FREQUENTLY. I know how it operates and I don't have to worry about coding any bugs re-writing the functionallity of the vi.

Next: The absolute first function I call on the BD of large projects. Close Modals FPs.vi. This has absolutely no function in the application! It fall into the catagory of utilities that aid development. Most larger applications contain some modal dialog vis and and, as I develope I find that I might have upwards of 50 LabVIEW windows open at any one time. If one of them is a dialog hitting RUN on any main.vi puts the modal FP on top of everything else in the app instance. It's happened often enough that I wrote this to prevent me from needing to Crash LabVIEW and loose changes I have reciently made.

Third: a nice Action Engine that was developed from example code found here

A re-use library is a must have- even if you need to download it from multiple sources.

Going back to our Corporate Communications GUI. From Our structure and model we can see that we need to move a lot of data around. Some if the data has impecations throughout the application, some is needed only in the GUI, and some is needed only in specific sections of the BD. Often getting this data from the GUI to where it is used or From where it is generated to the GUI shows up as Forum threads "How can I access my Control in a sub-vi?) This vi had many different examples of moving data around so it seems like a good place to talk about data scoping and how LabVIEW can transfer it.

If anyone hasn't read Ben's nugget on Action Engines Come back after you go though it here We will start with the FVG and AE and take a step beyond (But not all the waty to Nirvana.)

As a quick Review:

A FGV is a data storage unit: Breakpoint FGV.vi is an example of a FGV it sets or gets values on 1 USR taking no other action on the data.

An AE is a data storage unit that can act on the data its a FGV with States. App Kind AE.vi is an Action Engine

There is a subset of AE's, A special kind of AE, that operates specifically a referance to a resource maintained on its shift register. I call this type of AE a "Module" In encapsulates all the functions of the resource and provides an abstaction layer to the next level of code (that is, the callers only need to say what to do the module handles the how to do it)

The simplest way to pass data is on a wire- Source to Sink. This gives you access to a Value and values are useful- to computers! To pass them to a user we interperate values for human consumption as a property of a control or indicator object. We pass these values to controls and indicators through Termials, Local variables or Property nodes. Terminals and local variables can only point to objects on the front panel of the vi they are found on. They have the same "Scope" as the VI they belong to.

A VI Server referance to an object changes that! Put a VI server referance on a USR inside a module and you've got a pretty powerful tool.

Data Table.vi is one such tool Table Meth.ctl Lists the actions that I can take on the GUI data table and because it carries the referance to the actual GUI object with it, I can take any of these actions from any point in my project and the Data table will show the result of the action. In effect I have brought Data Table into the scope of every vi I drop Data Table.vi onto.

Using this VI I can report Operations Results directly to the user without duplicating the Data, The executive can populate "Steps" from a configuration file ADN the Accountant can generate reports from the exact same data. I also avoid race conditions since only one action can be taken at a time and if I loose any data or things "Look wonkey" I have 1 vi to look for to debug my large app.

Controls not otherwise encluded

JÞB — Thu, 14 Apr 2011 17:51:35 GMT

Ctls

Re: Controls not otherwise encluded

_Ian_ — Fri, 15 Apr 2011 14:56:07 GMT

Thanks Jeff!

I'm still (re)reading and digesting this.

In the meantime, Ray.R has kindly saved the files back down to V8.2 in the downconvert thread (or download the zip file directly here)

Re: Controls not otherwise encluded

Ben — Fri, 15 Apr 2011 16:20:12 GMT

Ah- hah!

This is the Nugget I have ben waiting for.

I will download and investigate closer this week-end but I think I see a GUI Controller.

Ben

Re: Digesting

JÞB — Fri, 15 Apr 2011 16:30:32 GMT

@_Ian_ wrote:

Thanks Jeff!

I'm still (re)reading and digesting this.

In the meantime, Ray.R has kindly saved the files back down to V8.2 in the downconvert thread (or download the zip file directly here)

Thanks Ray!

I have to admit the nugget did not format quite as intended. I had intended to launch on Monday 4-15 and was hoping to autosave as a first cut rough draft when I hit Post after collecting attachments (to zip from home this weekend). I wound up with 2 minutes to clear "notes to self" and add the TBC on post 1. A generic example project with a "Module" should hit this thread over the weekend to demonstrate the scope change you can obtain with the special case Action Engine I refer to as a Module.

Re: Community Nugget Series: Application Development: Installment 2- The GUI and FP object encapsulation

F._Schubert — Sun, 17 Apr 2011 10:17:26 GMT

I like this, so here is my share:

I've got a reuse package that deals with different access levels/user accounts. Depending on the user, Buttons are made visible/invisible.

Sorry, I can't share the code. There are some hardcoded master passwords inside.

Good reuse practices are a key to fast and reliable software developement. In addition to plenty of code found in this forum and the NI community pages, some great stuff can be found here:

As a side note: I always like an error case around the event structure. This way I go immediatly to the shut-down code and the error handler.

Felix

Re: Community Nugget Series: Application Development: Installment 2- The GUI and FP object encapsulation

JÞB — Mon, 18 Apr 2011 14:11:38 GMT

Felix,

Thanks for sharing! Your code is quite similar to the Example I'm going to post here.

Modular and re-usable code has tremendous advantages for both development and debugging! Keeping on fwith Felix's train of thought I'll present the following code excerpt from the ATS Project. In the Zip File you should find "User Data.vi" Looking at the VI Hierarchy

We see that this short snip of the ATS project contains 3 example modules that operate on different front panel objects.

Status.vi Drivers both the Test Status and Operator instructions. One place it is called in the project is from "Show Hide Controls.vi" Since we want to hide certain controls when a test is executing. Finally, User Data.vi maintains Log-in names, passwords and permits.

To remind us all the Main vi FP now looks like this:

Again I have some decorations for Layout assistance that will be removed later.

User data.vi Also needs a Config file to maintain user information. For demonstration the file path is a block diagram constant you may need to change to evaluate the code.

By using the VI server references to the GUI FP objects I have a scalable solution to expose the test status throughout the ATS project. Decisions on "What to show the user" can be made at the appropriate level by the best "Business unit" to make the code very readable. Maintainability is improved as well! Suppose requirements changed to require password encryption. We have 1 piece of code to modify.

Re: Controls not otherwise included

JÞB — Tue, 19 Apr 2011 16:37:58 GMT

@Ben wrote:

Ah- hah!

This is the Nugget I have Ben waiting for.

I will download and investigate closer this week-end but I think I see a GUI Controller.

Ben

Ben is correct (in a fashion) the concept of a GUI controller is fairly popular and simple to implement. Grab a cluster of references to every FP object wrap it in a sub-vi with a case for each action you want to take. (create a wrapper VI for each case and go to nirvana.)

If I remember correctly Ben explained HOW to implement this structure in this post .

I've used a slightly different approach by breaking out GUI elements by "Function." I took this approach for several reasons, KEY considerations were :

Can I create a base GUI that is readily adaptable for similar projects and maintains a "Feel" across applications?
How much of the functionality COULD be brought into a OO environment with minimal change?
How easy too maintain is this code?

The last Question really has more to do with who you work with than personal style. Each of these Modules could be a class, an X-control, or a AE holding a resource. Working with Software Engineers specializing in LabVIEW development you get a much different answer than when working with Test Engineers with a smattering of LabVIEW Skills. Maintenance and adaptation for new product is fairly easy for most engineers / techs that are casual LabVIEW programmers.

That Said: Here is the GUI-fully functional

Passwords are:

Log-in = ""
Jeff Bohrer = "P"
Admin = "Admin"
Jr. Tech = "Jr"
Sr. Tech = "Sr"
Engineer = "Eng"
Super User = "Super"

For Demo purposes a test execution marks time until Abort is pressed, delays 3 seconds, and generates a "Passed" execution.

Re: Controls not otherwise included

Ben — Wed, 20 Apr 2011 13:28:20 GMT

I was going to take a closer look but being at home with 2009, I can't open the most recent. Could someone post a 2009 version of the app zipped up?

Curious,

Ben

Re: Controls not otherwise included

MikeS81 — Wed, 20 Apr 2011 13:42:09 GMT

Hi Ben,

here it is.

Mike

Edit: Please copy the Demo\Files folder from the 2010 version.

Re: Controls not otherwise included

Ben — Mon, 25 Apr 2011 12:31:04 GMT

Sorry for the delay but I do want to squeeze this in before I head off again...

Jeff,

That example of a GUI controller is a bit more robust than I expected for an example (at first glance) but then after examining it, realized that litle bit of extra conplication is an excellent motivation for a GUi controller.

The Complication: Views change for various users.

Implementing all of the control settings for each level of access means that there could be as many version of "Show" as there are defined acces levels. To implmenet and then maintain this functionality would be challenging to implement and a nightmare to mainatin.

Note:

Not using a GUI controller for applications of this type sooner or latter gets you into a situation where your phone rings and the customer is saying "blha blah blah changes blah blah great blah blah BUT if yo udo this then this then it is..."

By using GUI controller GUI problems are either in the GUI controller (and its sub-VIs) or something that uses the GUI controller.

Now for some generall comments and questions since I'd like to hear what others think...

1) When dealing with multiple refs and property nodes I often (when there are tree or more depending on how the diagram reads) will use a sperate "Unbundle by Name" fore each property nodes to accomplish two ends.

a) Unbundle node "self-documents" which control is being actd on.

b) Make it easier to find the property node that without chasing a wire across the srceen.

Note: These are just my analy-retentative preferences and serve no purpose other than stated above.

From all of my reading multiple unbundles don't result in poor performance by the time LV unravles what you want and optimizes the code.

2) I avoid rebundling ref after using them. The ref is not changing (I like to learn about them if they do, type-cast as a U32 and see they say the same once teh code runs).

3) Now to your "Class" comment

You have used a code construct that is very similar to an Action Engine (it keeps it private data in the shift register and access to that private data is only possible through calls to the sub-VI) I have never read about, I believe I mentoned in passing in my Action Engine Nugget.

The code construct that I am refering to is the loop in the sub-VI may iterate more than once depending on the method invoked. Setting the permision method will invoke the "show" method after completing.

Q1) Should we still call this an Action Engine?

If not what scan we call it?

Q2) Have any of you implemented a similart critter? Yes I have. I had to implement on tht could potential execute about 15 states depending on the siutation.

If you did why did you choose that construct?

Comment:

You know... it you create wrappers for the calls to the GUI controller, put them all in a library, you can have something that resembles LVOOP by only creating wrappers for the calls that are allowed so that for example "Show" can never be called directly since there is no wrapper for it.

I am curious what others know and can say about any of the above or any suggestions from others on how they manage large GUIs.

Thanks again Jeff!

Ben

Re: Controls not otherwise included

JÞB — Mon, 25 Apr 2011 16:06:44 GMT

[Ben]The Complication: Views change for various users.

Implementing all of the control settings for each level of access means that there could be as many version of "Show" as there are defined acces levels. To implmenet and then maintain this functionality would be challenging to implement and a nightmare to mainatin.

Note:
Not using a GUI controller for applications of this type sooner or latter gets you into a situation where your phone rings and the customer is saying "blha blah blah changes blah blah great blah blah BUT if yo udo this then this then it is..." By using GUI controller GUI problems are either in the GUI controller (and its sub-VIs) or something that uses the GUI controller.

[Jeff] Working with Software Engineers specializing in LabVIEW development you get a much different answer than when working with Test Engineers!
OK that's the tounge in cheek answer.... but, it brings up some interesting points. Let me elaborate somewhat (this could require some duct tape.) "Components" of a system are defined by the system "Framework." There is a school of thought for Component based programming. "Components" in this context, encapsulate a set of related functions (or data). Taking Show Hide Controls.vi as an example. With this construct I encapsulated the set of objects the operator can select to change the state or state flow of the system. This is a highly selective list and we can say there is strong coupling between these objects. The Show method specifically denies USER access to these objects without permission by checking the state of the system and a list of user permissions. The Show method usage is then "Call whenever Testing? changes or Pemits changes. Were these events exposed in this example - no COULD they have been? YUP! and I'ld agree that would be more robust! I copped out and wrote a KISS component demoing the function with VI server Refs and no dynamic events. Suppose "Testing?" changes type to something more complex than a BOOL? Say "Status" <as string> and "In Test Dev Lab?" as bool, I have exacly 1 state to change. I can also add other methods that depend on the new "system state" In Test Dev Lab?". "Failing in Lab" might prompt a new method setting all remaining Breakpoints and displaying additional information for the dev team. By encapusatling just these special "State Flow" controls I can easilly debug how I got into a improper state for the system.

The Flip side- these objects obviously belong to a larger group "FP objects" If I have a requirement "allow user to move all objects" I need a parent component that reaches into this component with a method to disable all these objects, show them all and allow dragging. (and probably save the settings). My "move objects" method becomes more complex (but allows special handeling for this sub-class like, dissable the controls) and more difficult to debug as the method has "overrides."

Ben's GUI controller is not without merit- really only a change in scope of encapulation! The reliance on unbundle by name to aid identifying which object or group of objects is being acted has a simillar effect of increasing the coupling of related objects as the approach presented here.

[Ben] You have used a code construct that is very similar to an Action Engine (it keeps it private data in the shift register and access to that private data is only possible through calls to the sub-VI) I have never read about, I believe I mentoned in passing in my Action Engine Nugget.The code construct that I am refering to is the loop in the sub-VI may iterate more than once depending on the method invoked. Setting the permision method will invoke the "show" method after completing.

Q1) Should we still call this an Action Engine?
[Jeff] I believe this contstruct is an Action Engine- of a special case. Wrappers would present it as a "Pseudo Class" or it could be written very similar as a Class. The key differentiator from a "Classic" Action Engine is not that it can loop more than once but that it abstracts the actions to perform on the object(s) in the referance (Resource) within the system. I use the same construct for Hardware resources too! One benifit I find is the ease of finding them in either "Tree.vi" or in the Heirarchy view "This resource is here and it has these abilities" just shows in your face with Help on. The Icon style and VI documentation are a subset of the practice. Within my internal lexicon I simple call them "Modules."

Re: Controls not otherwise included

JÞB — Thu, 28 Apr 2011 18:25:13 GMT

Hmmm... the subject of "Modules" showed up in a thread here

the OP was having some dificulty maintaining a VISA session through an event loop where the resource was only used in a few of many cases. This reminded me that I had mentioned here that I use the "Module" construct for hardware and whipped out a quickie example encapsulating base functions for the 34401A since that driver that ships with LabVIEW.

I'm wondering if anyone else uses similar methods to encapsulate hardware functions.

Re: Controls not otherwise included

RavensFan — Thu, 28 Apr 2011 19:23:04 GMT

Yes. I will do something like that using an action engine. That way I don't have to worry about the VISA wire everywhere that I want to do some action with my serial port.

Though lately, I've been going a step farther and using it a way that I'm calling it a serial comms engine that I launch as a subVI in parallel to the rest of my code with nothing depending on it. Basically a daemon configuration. Then I will just use queues to pass data and commands into the subVI's while loop. Init, read/write, close, and shutdown. The shutdown or exit command being the one that ends the while loop so that the program can end.

Re: Controls not otherwise included

JÞB — Thu, 28 Apr 2011 19:47:00 GMT

@Ravens Fan wrote:

Though lately, I've been going a step farther and using it a way that I'm calling it a serial comms engine that I launch as a subVI in parallel to the rest of my code with nothing depending on it. Basically a daemon configuration. Then I will just use queues to pass data and commands into the subVI's while loop. Init, read/write, close, and shutdown. The shutdown or exit command being the one that ends the while loop so that the program can end.

Interesting! I've also used it to support independant operation as well add a named queue and the loop exit condition gets off the constant and a T from the close case