Front panel architecture

[Yddet]

Hello,

I am looking for a better architecture to update the front panel of the program I inherited.

There are 200 graphs, indicators and controls. I am trying to centralise all the proprieties and value changes in one VI (let's call it FPUpdate.vi). The goal is to improve the maintainability and being able to add controls easily in the future. Also I believe it is a good idea to update the controls and indicators all at once.

I started a new project to make some tests, here is what I tried so far. The consumer loop put the data in a queue and FPUpdate.vi dequeue and change the values of the indicators. This way, only FPUpdate.vi needs to have the references to the FP.

The data queue contains a cluster of all the data displayed. The user does not need to see all the values, only the newest are interesting. That is why the data queue is limited to 1 element.

This simple program works but there is only one place where I enqueue the data. The real program must be able to change the values from multiple places and I didn't find an easy way to avoid race conditions with this architecture. 

Another idea would be to write the data in a global variable and FPUpdate.vi would read this variable periodically to update all the indicators.

Do you have any advice ? You probably even have a better way of doing things ?

I saw a lot of discussion about data architecture but not so much for the front panel. If you have a link to a good example please share it.

Using LV2018

Yddet

Please open "FP architecture.lvproj" then main.vi. I included OpenG Vi's in the zip file.

Snippet Main.vi

 

Snippet FP update.vi

[Ben · Accepted solution]

This album has images associated with what I can a "GUI_Controller".

It is a type of Action Engine which can be used to avoid Race Conditions.

Ben

[crossrulz]

I much prefer to use User Events to command updates to the front panel.  This way, all of your UI is handled by a single loop (events from value changes, etc. and indicator updates).

[mcduff]

---

Don't have 7z, but here are some comments from the snippets posted.

@Yddet wrote:

The data queue contains a cluster of all the data displayed. The user does not need to see all the values, only the newest are interesting. That is why the data queue is limited to 1 element.

The queue in the snippet is not limited to 1 element; my suggestion is to explicitly wire the number of elements terminal to 1 and always use a lossy queue insert, that way you always have the latest value.

---

This simple program works but there is only one place where I enqueue the data. The real program must be able to change the values from multiple places and I didn't find an easy way to avoid race conditions with this architecture. 

---

Queue can have multiple producers and a single consumer, that is, many to one. You will always have the latest value with this method, unless, your clustersaurous has muliple elements updated in different parts of your program.

---

@Yddet wrote:

This way, only FPUpdate.vi needs to have the references to the FP.

Another idea would be to write the data in a global variable and FPUpdate.vi would read this variable periodically to update all the indicators.

---

Just guessing, it looks like you are updating the front panel using the value property and a control reference, never a good idea. Why like make a loop in your main program where you dequeue your queue and update the indicators directly?

mcduff

[drjdpowell]

Here's another type of front-panel architecture that might be worthy of consideration:

 

[Ben]

mcduff posted;

"

Just guessing, it looks like you are updating the front panel using the value property and a control reference, never a good idea.

"

Never is a strong word.

If you have many controls and indicators that need to be updated and the update rate is low (once a second or once every 5 seconds), control refs are just fine.

I recently delivered an application that monitors a very slow production process but required a hundred or more GUI attributes and values be updated. The updates included back ground color changes, enable/disable, caption updates... And the GUI updates is just small sliver of what the application did.

They may have been 30-50 sub-VIs involved in the logic to get it all correct. Putting all of those updates in the top-level VI would have completely obfuscated the top level VI.

I realize that most LV applications are not that complicated but...

"Never" is s strong word.

😀

Ben

[drjdpowell]

A slightly more useful answer:

If I were presented with a monolithic program with 200 controls/indicators, I would NOT be looking to centralise, I would be looking to modularise, dividing the problem up into cohesive components.  Then for a UI I would largely delegate to the components and then assemble a final front panel using sub-panels.  Often my "top-level" VI has only a large sub-panel, plus some (often tab-like) selector control for the User to select which Module's sub-front panel to look at.   

[Yddet]

Thank you Ben, I will look at this album and study the action engine.

---

@crossrulz wrote:

I much prefer to use User Events to command updates to the front panel.  This way, all of your UI is handled by a single loop (events from value changes, etc. and indicator updates).

---

I get it when the user changes a value, press a button, etc. But how do you refresh a graph automatically during a data acquisition ?

---

@mcduff wrote:

The queue in the snippet is not limited to 1 element 

---

I used the wrong name sorry for that. I was referring to the FP queue which contains data to be displayed. I will try to edit the first post.

@mcduff wrote:

your clustersaurous has muliple elements updated in different parts of your program.

---

Yes it does.

---

@mcduff wrote:

Just guessing, it looks like you are updating the front panel using the value property and a control reference, never a good idea. Why like make a loop in your main program where you dequeue your queue and update the indicators directly?

---

---

@drjdpowell wrote:

Here's another type of front-panel architecture that might be worthy of consideration:

 

---

The main VI currently uses a lot (600) of propriety nodes and local variables. I am trying to reduce this number but I don't have time to re-write everything to only use the terminals (at least I don't know how to do it quickly). The main VI is enormous and I can't create sub-vi's because of the propriety nodes. My plan was to replace the propriety nodes and write in queues the data and proprieties. Then only one VI would handle the updates with propriety nodes. 

Another reason I did not suggest the use of terminals is to reduce the size of the main vi (200 controls).

I am also considering sub-panels but I never used them in a large project and I don't know how easy it would be to implement in this program.

Yddet

 

[crossrulz · Accepted solution]

---

@Yddet wrote:

---

@crossrulz wrote:

I much prefer to use User Events to command updates to the front panel.  This way, all of your UI is handled by a single loop (events from value changes, etc. and indicator updates).

---

I get it when the user changes a value, press a button, etc. But how do you refresh a graph automatically during a data acquisition ?

---

User Events.  Yes, a poorly named feature.  But they are very useful.

Quick examples I was able to find:

User Events Demo

User Event Example

[Ben]

Dr Powel wrote;

"

If I were presented with a monolithic program with 200 controls/indicators, I would NOT be looking to centralise, I would be looking to modularise, dividing the problem up into cohesive components.  Then for a UI I would largely delegate to the components and then assemble a final front panel using sub-panels.  Often my "top-level" VI has only a large sub-panel, plus some (often tab-like) selector control for the User to select which Module's sub-front panel to look at.   

"

Sometimes yes sometimes no.

If we do break things up into sub-panels (which was the case in the app I mentioned above), we can not always break things up into nice little sub-panels.

Consider for example an overview of one of the processes being influenced by a Maint. view in addition to a config. view. Change to one of the views has an influence on the other views. It can get sticky.

Using a "centralized" set of logic that ensures all of the available views are consistent can make things easier to support. Scattering the logic may introduce more work trying to implement changes.

Example that comes to mind:

When in Main mode, the widget name indicator should change to a red background.

If we use multiple sub-panles it would have to change many places.

Ben