Versions Compared

Old Version 18

changes.mady.by.user Luke Cerwin

Saved on

compared with

New Version 19

changes.mady.by.user Luke Cerwin

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

All HMI Applications in TSENTRY are viewed using the TSENTRY Screen Explorer, or Texplore, which acts as a container application for displaying and navigating between HMI screens.  Texplore uses the various services to exchange information with the TSENTRY host in order to provide a secure yet highly customizable front end to any control system.

...

Texplore

...

Overview

The TSENTRY Screen Explorer, or Texplore, is the application used to display HMI screens to a user.  Texplore is simply an application for browsing the TSENTRY HMI subsystem, much like Internet Explorer is an application for browsing the Internet.  Texplore provides much of the common framework for an HMI such as connecting to a TSENTRY host, reading the HMI configuration file, providing a login screen, and managing the navigation between screens within the HMI application, but by itself does not define any specific HMI screens.

Texplore relies on several processes running on the TSENTRY controller to provide it with information as it operates as the HMI client browser.  These are:

  • The NtRtInfo service, which exposes static information from the TSENTRY controller to client objects in a request/reply architecture.

  • The Tsecurity service, which provides authentication and authorization services to client objects.

  • The GsmOpcSvr process, which exposes the values of individual variables in global memory on the TSENTRY controller.

  • The TrendSrv process, which exposes sampled or trended values of variables in global memory on the TSENTRY controller.

...

Expand
titleInstallation

The instructions for installing Texplore on a client workstation are laid out in the Workstation Configuration section.

...

Expand
titleBrowsing from Screen to Screen

One screen can link to another in a variety of different methods:

  • A screen can have a TPRI.HMI.Controls.CmdButton or TPRI.HMI.Controls.LinkLabel object on its display that specifies the ScreenID of the new screen in its LinkedScreen property.

  • A screen can raise the ITscreen.ActivateScreen(..) event, which is passed a TPRI.Tscreen.ActivateScreenEventArgs object that specifies the ScreenID of the new screen.

The Texplore application internally has a TPRI.Tscreen.TscreenMgr object that manages navigation between screens.  In either of the cases above, this TscreenMgr object will use the ScreenID name to find the appropriate new screen as follows:

  1. If a screen with this ScreenID is already registered in the HMI application configuration file in the AppConfig/ScreenConfig section of the application configuration file.

  2. If there is no screen currently registered with the specified ScreenID, the TscreenMgr will check the assembly of the original screen to see if there is a class whose name matches the ScreenID in the same namespace as the original screen.

For instance, suppose the application configuration file has the following <ScreenConfig> section:

Code Block
<ScreenConfig>
  <Screen ScreenID="MainMenu"
          ClassName="MyNamespace1.MainMenu,MyAssembly1"
          Default="True" />
  <Screen ScreenID="SubMenu"
          ClassName="MyNamespace2.SubMenu,MyAssembly2" />
</ScreenConfig>

When the application is started, a MyNamespace1.MainMenu object will be loaded from the MyAssembly1.dll assembly, assigned a ScreenID of “MainMenu”, and initially presented to the user.  This occurs because this screen is marked with the Default="True" attribute in the HMI configuration file.  At the same time, a MyNamespace2.SubMenu object from the MyAssembly2.dll assembly will be registered with Texplore and its TscreenMgr using the ScreenID of "SubMenu".

If the NtRtMenu screen has a CmdButton on it whose LinkedScreen property is set to “SubMenu”, the TscreenMgr will immediately find the SubMenu screen in its list of registered screens and activate it.

However, if the CmdButton on the MainMenu screen instead specifies “OtherScreen” in its LinkedScreen property, the TscreenMgr will find that there is no screen currently registered with that ScreenID.  Therefore it will check if the MyAssembly1.dll assembly contains a class by the name MyNamespace1.OtherScreen; if it finds one then that screen will be immediately registered, created and activated.  If this class does not exist then the navigation will be canceled.

Consequently, only top-level menus must be specified in the ScreenConfig section of the application configuration file as long as all classes corresponding to screens linked from those menus are located in the same namespace as the top-level menu.

...