LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

User Generated Tab Controls (tabbed pages)

Solved!
Go to solution

Does it have to be a tab? 

Could it be a list and a sub-panel that changes depending on the item selected in the list? 

Message 11 of 26
(381 Views)

I agree that trying to manage 50 floating windows is ridiculous. But having a tab control with 50 tabs is just as ridiculous. The interface for the operator must be distilled down to at most 2~4 windows.

 


@pincpanter wrote:

LabVIEW controls can be highly customized, relocated on screen, resized, hidden and displayed again by programming.


To pincpanter's point, you could over-design the interface and then select only the components used by changing visibility of tab pages or controls. I would not go down the path of reusing controls for different things, though. Instead make the interface itself flexible, and put the details into smaller modules.

 

I maintain a large (60~80 instrument) experiment control system that uses a tabbed interface with subpanels. It is designed with some maximum number of tabs, each with a maximum number of SubPanel controls. Each individual instrument is loaded into its own subpanel. Multiple copies of the same instrument are instantiated and initialized with different configurations (IP addresses, settings, etc.). Looks something like this:

 

tabbed interface.png

 

The tabbed windows can be nested into one of the subpanels if desired to create a hierarchical design that can be nested to any level desired. The windows and subpanels can be sized and positioned by their configuration. Modules can even be recompiled and reloaded while the system is running without restarting. And this all runs in the RTE by the way, so the development environment doesn't hang up execution when it's busy.

 

The operators never look at more than 4 of these high-level tabbed windows at a time, only 2 of which might actually be heavily used for control. Which 2-4 windows they look at is up to them and the state of things.

_______________________________________________________________
"Computers are useless. They can only give you answers." - Pablo Picasso
Message 12 of 26
(371 Views)

Maybe all you need is a clean UI with a few graphs and a good selection procedure to decide what to display in them at any given time. There is no need to have dozens of similar graphs on tabs you cannot see at the time.

 

Instead of changing visibility, just change caption, legends, etc. to match the current content. It is also much less demanding on memory.

Message 13 of 26
(369 Views)

@altenbach wrote:

Maybe all you need is a clean UI with a few graphs and a good selection procedure to decide what to display in them at any given time. There is no need to have dozens of similar graphs on tabs you cannot see at the time.

 

Instead of changing visibility, just change caption, legends, etc. to match the current content. It is also much less demanding on memory.


Thank you for your suggestion. 

 

Unfortunately that is not going to work for us. Our project customers and equipment operators have been accustomed to being able to customize their displays to include up to 30 tabular displays with up to about 160 sensors each, and 30 plot displays with up to 8 sensors each. These are monitored by our technicians and engineers regularly. Asking the user to customize it on the fly is not an option as important decisions need to be made from the trends observed and they need to be easily accessible.

 

We deal with expensive one-of-a-kind items that may involve different teams that monitor their subsystem within a larger system. Our most complex tests can include over 4000 sensors.

 

Because tabbed pages are a design feature that must be included at compile time and are not available at run time, it's most likely that LabVIEW is not (and never was) the right choice for us for this application. I do believe LabVIEW is a powerful application and we'll be able to make good use of it for other purposes.

0 Kudos
Message 14 of 26
(360 Views)
Solution
Accepted by noblepete

@noblepete wrote:

Because tabbed pages are a design feature that must be included at compile time and are not available at run time, it's most likely that LabVIEW is not (and never was) the right choice for us.


Surprisingly for a graphical programming language, some of the UI features of LabVIEW are lacking.

 

Depending on your OS, you could use a .NET Tab Control, this allows you to add and remove tabs as needed at runtime. If you want a LabVIEW solution you could look into that.

 

See https://www.vipm.io/package/mgi_lib_mgi_panel_manager_net_panels/

Message 15 of 26
(352 Views)

@rwunderl wrote:

I agree that trying to manage 50 floating windows is ridiculous. But having a tab control with 50 tabs is just as ridiculous. The interface for the operator must be distilled down to at most 2~4 windows.

 


@pincpanter wrote:

LabVIEW controls can be highly customized, relocated on screen, resized, hidden and displayed again by programming.


To pincpanter's point, you could over-design the interface and then select only the components used by changing visibility of tab pages or controls. I would not go down the path of reusing controls for different things, though. Instead make the interface itself flexible, and put the details into smaller modules.

 

I maintain a large (60~80 instrument) experiment control system that uses a tabbed interface with subpanels. It is designed with some maximum number of tabs, each with a maximum number of SubPanel controls. Each individual instrument is loaded into its own subpanel. Multiple copies of the same instrument are instantiated and initialized with different configurations (IP addresses, settings, etc.). Looks something like this:

 

tabbed interface.png

 

The tabbed windows can be nested into one of the subpanels if desired to create a hierarchical design that can be nested to any level desired. The windows and subpanels can be sized and positioned by their configuration. Modules can even be recompiled and reloaded while the system is running without restarting. And this all runs in the RTE by the way, so the development environment doesn't hang up execution when it's busy.

 

The operators never look at more than 4 of these high-level tabbed windows at a time, only 2 of which might actually be heavily used for control. Which 2-4 windows they look at is up to them and the state of things.


Thank you for your response.

 

Our current application has two windows within the main window. One for tabular displays and one for graphs. Each of these windows can then be divided up into 30 tabs each. The user can modify the tab label to make it so the tab takes up less space- sometimes it's just a number but it can also be a useful label (if you don't need the real estate). It doesn't look great but it does the job. 

 

I put more information about what we do (and what we need) in a different reply. I would really like to see a LabVIEW implementation that allows for the display of up to 4000 sensors (up to 50 characters including sensor name and reading), up to 240 plots and allows the user to customize their display.

0 Kudos
Message 16 of 26
(349 Views)

@dkfire wrote:

Does it have to be a tab? 

Could it be a list and a sub-panel that changes depending on the item selected in the list? 


It doesn't have to be a tab. I think that's what most people are used to- especially the people who are used to doing work in our lab. Perhaps it could be a radio button. 

0 Kudos
Message 17 of 26
(347 Views)

@mcduff wrote:

@noblepete wrote:

Because tabbed pages are a design feature that must be included at compile time and are not available at run time, it's most likely that LabVIEW is not (and never was) the right choice for us.


Surprisingly for a graphical programming language, some of the UI features of LabVIEW are lacking.

 

Depending on your OS, you could use a .NET Tab Control, this allows you to add and remove tabs as needed at runtime. If you want a LabVIEW solution you could look into that.

 

See https://www.vipm.io/package/mgi_lib_mgi_panel_manager_net_panels/


Thanks. I've looked around at user-developed LabVIEW packages. I see the one you provided the linked to has only an initial release and was put out over 3 years ago. How often or likely would it be that an update to LabVIEW can kill the functionality of these packages? 

 

.NET tab controls are perfect, but I may as well just re-write my program in .NET. I'm trying my best to justify continuing the implementation of our application in LabVIEW and I appreciate everyone's input. 

0 Kudos
Message 18 of 26
(341 Views)

@noblepete wrote:


I see the one you provided the linked to has only an initial release and was put out over 3 years ago. How often or likely would it be that an update to LabVIEW can kill the functionality of these packages? 


Things don't change with System.Windows.Forms too often.. so you might be safe for a while. But these things are aging and won't be around forever it's true. I doubt an update to LabVIEW would break the code; more likely a Microsoft update might alter an accessor API or something. But I would image this is highly unlikely with something as mature as the System.Windows.Forms interface.

 


@noblepete wrote:


.NET tab controls are perfect, but I may as well just re-write my program in .NET. I'm trying my best to justify continuing the implementation of our application in LabVIEW and I appreciate everyone's input. 


LabVIEW is arguably very poor for developing modern-looking user interfaces. What LabVIEW does right--and almost effortlessly--is data acquisition and massive parallelism. Feel free to choose the right tool for the job, but I generally keep things in LabVIEW for these two reasons.

 

I have toyed with the idea of making HMIs in .NET and keeping the acquisition and processing in LabVIEW. However, the complexity of implementing that type of application versus living with an inferior HMI and keeping things in one IDE is hard to justify.

 

I'll say the other thing LabVIEW does quite well is plotting data. Being able to dump millions of samples into a graph without thinking of how it's implemented is definitely taken for granted. You have to pay thousands for commercial packages to get something like that in WPF.

_______________________________________________________________
"Computers are useless. They can only give you answers." - Pablo Picasso
Message 19 of 26
(333 Views)

@noblepete wrote:

Hi Everyone, 

 

I'm a software engineer who has no experience in LabVIEW. I just started a new job where they would like me to help fix a LabVIEW application that was developed by a third party. This application replaces an existing application where the user could create multiple tabbed windows where they can view sensor readings of their choosing. They can do the same with plots of these readings. Our tests can range in complexity and can contain anywhere from 20-4000 sensors. Hence the need to give the user ability to create their own displays with data in tabular and plot form. 

 

My question is: 

Could a LabVIEW vi have the ability to allow the user to create new tabbed pages within a window? Not really looking for an explanation of how to do it (but an example would be welcome). I just want to know if it is possible.

 

Thank you.


It is difficult to tell from a purely written description exactly what you need.  You might want to show pictures of your existing application, and maybe describe its structure. First thing I would ask if you were a new client is what your database or database-like storage technology is; as "tabbed pages" is trivial.

0 Kudos
Message 20 of 26
(320 Views)