NtRtMgr
Expand | ||
---|---|---|
| ||
The NtRtMgr is the primary manager task of the Tsentry system. It provides the following services:
|
Expand | ||
---|---|---|
| ||
The Tsentry system can be started by executing the NtRtMgr task and passing the name of the system initialization file.
The following configuration files control the operation of the startup task:
|
Info |
---|
“Nt-” as in 'Nt-Example' is an NtRtMgr Setup sub doc |
Expand | ||
---|---|---|
| ||
This system initialization file defines:
An example file follows:
|
Expand | ||
---|---|---|
| ||
This configuration file controls which processes will be started as part of the real-time control system. The fully qualified file name is passed to the startup process as the first command line parameter. An example process.ini file that contains line format definitions as comments follows:
|
Expand | ||
---|---|---|
| ||
This is the first of two files used by the NtRtMgr to initialize the data dictionary. It is the output of the data dictionary builder process GsmPifBld, which parses the C/C++ global common header files to generate this flat ASCII definition of shared memory. For most purposes you do not need to examine the contents of this file. It is further described in the Data Dictionary [LINK] section. |
Expand | ||
---|---|---|
| ||
Data dictionary variableThis is the second of two files used by the NtRtMgr to initialize the data dictionary. This file defines the various global common segments used by the system and any ‘special’ variables contained therein. It is further described in the Data Dictionary [LINK] section. LogMsg initialization fileThis configuration file initializes the LogMsg subsystem. It is described in detail in the [LINK] Libraries section. |
...
Expand | ||
---|---|---|
| ||
The NtRtMgr task can be stopped by either clicking the Stop System button or the Windows ‘X’, both in the upper right hand corner of the window.
Shutting down the NtRtMgr process performs the following tasks:
|
...
Expand | ||
---|---|---|
| ||
The GsmOpcSvr task is an OPC (OLE for Process Control) server for Tsentry global shared memory. It accepts requests for named variables in global common from an OPC client and returns the current value of that variable to the client. As the value in global common changes, the server continues to push updates out to the client. The server also allows clients to write the values of these variables back into global common. |
...
External Links
Expand | ||
---|---|---|
| ||
TrendMgrThe TrendMgr task [LINK] is the manager process for the trending subsystem. TrendGsmThe TrendGsm task is responsible for trending data from global shared memory. TrendSrvThe TrendSrv task is the server process for delivering trended data to trend clients across the network. TrendTrigThe TrendTrig task is the main process for the historical trending subsystem. GsmExpSvrThe GsmExpSvr task is the server portion of the software-based reflective memory subsystem, discussed in the Data Transfer section. GsmExpRcvThe GsmExpRcv task is the client portion of the software-based reflective memory subsystem, discussed in the Data Transfer section. GsmPifBldThe GsmPifBld process is responsible for building the data dictionary program information files before starting the Tsentry system, discussed in detail in the Data Dictionary section. |
VarIniChk
Expand | ||
---|---|---|
| ||
VarIniChk is a stand-alone utilty program that lists the diferences between the variables defined in the data dictionary and those described by entries in the variable.ini file. The program produces 3 lists of variables:
This program is run from a dos command prompt, as follows:
Where:
|
VarIniSort
Expand |
---|
VarIniSort is a stand-alone utilty program that reads data from a 'source' Tsentry variable.ini file, sorts the contents of the lines in the [VarDef] section by variable name, and writes out the updated contents to a 'destination' file.
This program is run from a dos command prompt.
Program command line calling format: The command line may have one or two parameters: The first parameter is the fully qualified name of the source (input) Tsentry variable.ini file. The second parameter is the fully qualified name of the destination (output) Tsentry variable.ini file. If no second parameter is found, the source file name will be used as the destination file name. File definitions may use environment variables in the file names. Program Return value: Notes:
|
tpriNtRtAdmin
Expand | ||
---|---|---|
| ||
The tpriNtRtAdmin application is no longer supported The tpriNtRtAdmin application is used offline for creating new systems, tasks, and screens. You can find the application at:
The first time tpriNtRtAdmin is started, it will look like this: The tpriNtRtAdmin application uses a configuration file to save and retrieve information. This file can be found at |
Expand | ||
---|---|---|
| ||
Before tasks and screens can be created a new system must be generated. Start up tpriNtRtAdmin and then perform the following actions:
|
Expand | ||
---|---|---|
| ||
Once a system has been created, you may create new tasks. Task generation results in creating three new files: a project file (newtask.dsp), a source file (newtask.cpp), and a header file (newtask.h). By default, all of these files are put into a new directory with the same name as the new task. For example, if you have created a system ID called DemoSys and a new task called mytask, then the new files would be:
You may wish to put these files in alternate locations, which you can do by checking the “Specify Locations” checkbox. Note, you cannot simply move the files manually to their desired location, unless you also manually update all of the location dependencies in the file mytask.dsp (not recommended). There is also an option to generate a task that uses managed extensions. This flag creates a task that is compatible with the Common Language Runtime and .NET Framework libraries. This type of task however cannot be compiled and linked as a hard real-time RTSS task. A managed extensions task also generates a fourth source file mytaskAssemblyInfo.cpp, which provides information for the generated assembly. If you need to add additional compiler or linker flags to the project settings, you can do so by manually editing the file: |
Expand | ||
---|---|---|
| ||
Screens are used to display and modify values using a wide variety of visual tools. The combination of these tools yields a powerful and fully customizable real-time graphical user interface. To build a new screen, follow these steps:
For a more detailed explanation of building an HMI screen refer to the Screen Development section. |
TpriPublisher
Expand | ||
---|---|---|
| ||
The tpriPublisher application is no longer supported The tpriPublisher is used to rebuild and publish HMI screens for viewing through Internet Explorer. It supports VB.NET screens, VB.6 screens, and pure html/asp screens. |
Expand | ||
---|---|---|
| ||
The topmost drop down box above selects the current screen group for publishing. A screen group defines a common set of parameters to be used to build and publish all screens in that group. All screens built in under a given screen group must be stored on disk in individual subdirectories off of the root screen directory specified for the group. Once a screen group is selected from the drop down list, the main list box below is filled with the names of all screens found in the group. This list is populated as followed:
In order to rebuild and/or publish a screen, highlight the screen name in the screen list box and push one of the buttons to the right. The Rebuild button attempts to rebuild the screen from its source code.
The Publish button creates all files required to view this screen in a web browser and moves these files into the web share specified for the group.
The button with two leftward pointing arrows on the right of the Rebuild and Publish buttons performs both actions on each of the highlighted screens. For publishing a cab file containing a library of VB.6 controls included and used on multiple screens, the bottommost dropdown box can be used to select the appropriate included cab file. Pushing the Publish button to the right of this list builds the cab file itself and updates any template files used when creating cab files for screens that must include this cab file. Note that after publishing an included cab file, all screens that use this file must also be rebuilt and republished. |
Expand | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
Creation of the actual web page associated with a given screen is performed as follows:
|
Expand | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
Screen building and publishing operations can also be executed directly from the command line using tpriPublisher.com (rather than tpriPublisher.exe). In this case, all operation is driven by command line parameters and no GUI is presented to the user. The calling format is as follows:
Examples:
|
Expand | ||
---|---|---|
| ||
The tpriPublisher is configured through the same ini file as the tpriNtRtAdmin task, %SYSTEMROOT%\system32\tpriNtRtAdmin.ini. The following sections and keys pertain to the tpriPublisher task:
[BuildInfo]
[Groups]
[TelePro VEG/EE]
[Cabs] This section defines the names of the various user defined cab files available for publishing. Each line specifies the file name of a given cab:
[tpriStdControls] Each cab specified either in the [Cabs] section or by the includeCabs value for a group must have a section defined in the file. The parameters specified in this group dictate how the specific cab file is to be built and/or used by other screen cabs.
A sample
|