Main Menu Driven Project Structure in V3.99s

[Archie]

A couple new items were added to version 3.99s that make it easier to build main menu driven project. This works by having a main menu form that stays open all the time. This form will contain all of the Form Change navigation buttons.
To use the new items:

- In Solution Explorer, right click the AdvancedHMI project and select Properties
- Under the application tab change the Startup Form to MainMenu

You will now create new forms. Be sure to set the FormBorderStyle to None for all forms. After creating additional forms and Building the project, you can now add menu buttons for them:
- In Solution Explorer, expand down the AdvancedHMI project, then expand down to FormChangeControls\MainMenuDriven
- Double the MainMenu.vb to open in Design View
- From the Toolbox add a MainMenuButton for each new form
- Set the FormToOpen property
- You can also set the OpenOnStartup property for one button to indicate the default startup form

On the MainMenu is an Exit button. This button is used to search for hidden forms to ensure they are properly disposed when closing an application.

The Main Menu form can also be used for "global" style functions such as changing forms based on a PLC value since it stays open and will always keep PLC communications active.

[Noe]

This should be on wiki!

[patrick.n]

Does this approach mean you only require one Comms Driver on the Main Form (which will also serves additional Forms)? 
Or does each form require its own instance of a Comms Drv?

(Is this approach still "best practice" as of Oct-2019?)

[Archie]

This does not eliminate the need for a driver on every form. It eliminates the need to keep a hidden form's communication from having to keep putting data on the wire by allowing things such as data collection to be handled from the MainMenu.

The driver on every form becomes trivial when using the INI file feature by moving all driver instance properties to a single location in a separate text file, such as IP address.

I consider this a good practive and use it on nearly every project I do.

[prof-nova]

It would be convenient for us - simple mortals - to have a multi windows project frame. Something like a main form with a menu to select a couple of pages (process / alarms / trends) and also with a comm component implemented like you say. This way, it will be still faster to start a new project.

[patrick.n]

Thanks for prompt reply, Archie.

Not sure I understand what you mean...What happens to the comms driver on a hidden screen?  And how does a comms driver on the main screen help?

Sorry for the newbie question. Keen to understand what's happening under the hood. Hope its quick and easy to explain.

Cheers
Patrick

[Archie]

Not sure I understand what you mean...What happens to the comms driver on a hidden screen?  And how does a comms driver on the main screen help?

Behind the default MainForm is a code snippet that stops communications when the for is hidden. This code snippet should be copied to every new form added to the project. Without the code snippet all of the data will continue to update even though it is not visible. The result is a bottle neck in communications with the PLC therefore causing everything to become slower as more forms are added and opened.

The problem with the communication stopping is when you have things like a datalogger because they will stop also. So by using the MainMenu to hold items that need to always be updated, you can then stop communications on the forms that only display data.

[patrick.n]

Ok. That's clear.

So a further question if I may...

Is it a .NET scope thing or similar technical issue that restricts developing an application with one comm driver object on Main Page and  subsequent Forms utilizing that same Comms driver obj?

Perhaps its a problem with propagating events between forms?! 

[Archie]

Is it a .NET scope thing or similar technical issue that restricts developing an application with one comm driver object on Main Page and  subsequent Forms utilizing that same Comms driver obj?

Perhaps its a problem with propagating events between forms?!

The reason for needing a driver instance on every form is so the controls can hook to the driver. The WinForms designer only allows controls to access controls/components on the same form. You can use a single driver, but you would need to write code to transfer the data to any of the controls. With a single driver you would not have the granularity to pause communications to only groups of items.

[patrick.n]

Thanks for the explanations Archie.

It's been really helpful.

To just to summarise: - a sample app has 5 forms:

-therefore there are 5 driver instances - one on each form
-each driver would consume one CIP connection of the device we're talking to.  (?)
-through code snippets you put on each form, you can control whether a hidden form stops or continues polling device
-through the code snippets you can thus manage the traffic burden your HMI places on the device

[Archie]

-therefore there are 5 driver instances - one on each form
 YES
-each driver would consume one CIP connection of the device we're talking to.  (?)
 NO - all driver instances that connect to the same PLC use a common transport layer only using 1 CIP connection
-through code snippets you put on each form, you can control whether a hidden form stops or continues polling device
 YES
-through the code snippets you can thus manage the traffic burden your HMI places on the device
 YES

[patrick.n]

All driver instance using one common transport all use the same connection - Brilliant!

Things very clear now.  Excellent job you've done with this.