The NtRtMgr is the primary manager task of the Tsentry system.  It provides the following services:

•  Allocate data dictionary global shared memory region

• Populate memory resident data dictionary with disk resident information

• Allocate global shared memory regions

• Initialize and restore contents of global shared memory regions

• Start and monitor all process tasks

• Display current status of all process tasks

• Display recent contents of LogMsg message queue

• Start/Restart/Suspend/Stop/Configure processes via console window

• Shutdown system when requested

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:

• System initialization file       

• Process initialization file

• Data dictionary definition file

• Data dictionary variable initialization file

• LogMsg initialization file

This system initialization file defines:

• The remaining fully qualified initialization file names to be used by the startup process:

• Process initialization file

• Data dictionary definition file

• Data dictionary variable initialization file

• LogMsg initialization file

• System-wide and application parameters

An example file follows:

# ------------------------------------------------------------------------
#  A Foil Mill Initialization File

[IniFiles]
#define the Data Dictionary Structure definition file
DDStruct=d:\locNtRt\afm\pif\afmStruct.ini

#define the Data Dictionary variables definition file
DDVars=d:\locNtRt\afm\pif\afmVars.ini

#define the process definition file
Procs=d:\locNtRt\afm\pif\afmProcs.ini

[AppParams]
# System Name
SystemName=A Foil Mill

# Shutdown executable
ShutdownExe=d:\locNtRt\tpriNtRt\bin\NtRtStop.exe

# Splash screen picture file
SplashPicture=d:\locNtRt\afm\Pif\afmLogo.bmp

# GUI Options: '&'-delimited list of one of more of the following strings:
#    NoConsole           Do not display the NtRtMgr screen
#    NoStopSystem        Do not allow the interactive user to stop the NtRtMgr
#    NoExecProcess       Do not allow the interactive user to 
#                           start/stop/suspend/resume processes
#    NoEditProcess       Do not allow the user to edit process parameters
#    NoProcessMenu       Do not display any menu via right clicks on the
#                           process list
#    NoConsoleLogMsg     Do not allow the user to insert LogMsgs from the console
#    TrayIcon            Minimize the NtRtMgr screen to a tray icon
GuiOptions=

# Option not to query if system should kill existing processes on startup
#QueryKillExistingProcesses=No

# Directory for NtRtCmd files
NtRtCmdPath=D:\locNtRt\afm\NtRtCmd\

# ------------------------------------------------------------------------

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:

# -------------------------------------------------------------------------------
[Process]
# This is the process.ini file for the Application system.
# This file is read by the startup process at system startup.
# Processes are started in the order they are listed in this file. 
# This file is also read by each process at startup (by method PrIni)
#
# The format of the process.ini file is as follows:
#
# Lines beginning with a "#" are comments
#
#  AppName        - Application name of the process that is to be run.
#
#  BinName        - Fully qualified system executable binary file name of
#                   the process associated with AppName
#
#  Uses NtRt      - Flag indicating if this process uses the tpriNtRt library
#                   for process management
#
#  Priority       - the priority that the task is supposed to run at.
#                   Options for Priority are:
#                       0 - 15   Standard Windows NT dynamic priority (mode=Std)
#                                 0 = lowest
#                                15 = Highest
#                      16 - 31   Standard Windows NT realtime priority (mode=Std)
#                                16 = Lowest
#                                31 = Highest
#                       0 -127   Hard Real-Time (mode=Rt)
#                                 0 = Lowest
#                                127= Highest
#
#  Timer Delay    - Initial Timer delay (milliseconds) before first 
#                   execution.  Zero if no timer specified.
#
#  Timer Interval - RepRate Timer Interval in milliseconds.
#                   Zero if no timer specified.
#
#  Run Mode       - indicates whether a task is to run as "standard" or
#                   "realtime" process.
#
#  Auto-Restart   - "yes" or "no"; specifies if the process is to be
#                   automatically restarted should it is unexpectedly
#                   terminated.
#
#  MemLock        - Lock in memory option
#                   "yes" indicates locked in memory
#                   "no" indicates not locked in memory
#                   All Hard Real-Time processes are always
#                   locked in memory.
#
#  Trap Crash     - Combination of character flags specifying how process 
#                   crashes/exceptions should be handled
#                   N = Default handling (windows displays message box)
#                   T = Terminate process
#                   D = Log description
#                   S = Try to find symbol and source line
#                   W = Walk back along stack and dump info
#                   R = Dump register values
#                   Y = Default 'Yes' = Same as 'TDS'
#
#  Debug Mode     - Debug mode / level. Values are process dependent.
#                   Normally lower values indicate less debug and logging
#                   Higher values indicate more debug and logging
#
#  Startup Delay  - Defines delay time (milliseconds) before starting
#                   this process.  A negative value indicates that this
#                   process should not be automatically started at system
#                   startup.  
#                   Negative Startup Delay's are (usually) used for the
#                   startup process itself and for any demand process
#                   that needs to run periodically, but not when
#                   the system is started.
#
#  Init Wait      - Defines the delay time (milliseconds) to allow for 
#                   this process to initialize itself before proceeding
#                   to the next process in the list.
#
#  Kill Wait      - Defines the delay time (milliseconds) to allow for 
#                   this process to react to a deactivation request and
#                   gracefully exit before it is forced to terminate.
#                   Negative times indicate that the process will never
#                   be terminated without its permission.
#
#  Pulse Timeout  - Defines the timeout (milliseconds) for the process
#                   pulse.  Every time the process calls PrWait it resets
#                   an internal timer to this value.  The NtRtPulse
#                   decrements this timer and kills the process if it
#                   expires.
#
#  CTail            Command tail to be passed to the process
#                   This parameter is optional
#                   If the command tail is supplied, it must
#                   be enclosed in double quotes
#
# ---------------------------------------------------------------------------

# ---------------------------------------------------------------------------
#
# GroupName     Init
#               Active
#
# ---------------------------------------------------------------------------
[AppGroups]
Application     Y


# ---------------------------------------------------------------------------
#
# AppName BinName          Uses Prty Tmr  Rep  Run Re-  Mem Trp Dbg StUp Init Kill Pls CTail
#         (FileName)       NtRt      Dly  Rate Mod strt Lck Crs Lvl Dly  Wait Wait TO
#
[System]
NtRtMgr   D:\xx\NtRtMgr.exe   Y 10   500  500  Std No   Y   N   30  0    0    -1   0
NtRtMtr   D:\xx\NtRtMtr.exe   Y 31   10   10   Std Yes  Y   T   30  0    0    -1   0
RtxTcpip  C:\ww\rtxtcpip.rtss N 120  1000 1000 Rt  No   Y   T   0   -1   0    500  0   "zz.ini"
GsmOpcSvr D:\xx\GsmOpcSvr.exe Y 10   500  500  Std No   Y   T   30  0    0    5000 0
TrendMgr  D:\xx\TrendMgr.exe  Y 10   200  200  Std No   Y   T   30  -1   3000 3000 0   "zz.ini"
TrendGsm  D:\xx\TrendGsm.rtss Y 20   20   20   Rt  Yes  Y   T   30  -1   5000 5000 0   "zz.ini"
TrendSrv  D:\xx\TrendSrv.exe  Y 10   1000 1000 Std Yes  Y   T   30  -1   0    5000 0

[Application]
# Insert each of the application processes here
RTSSTask  D:\yy\RTSSTask.rtss Y 20   100  100  Rt  No   Y   A   30  0    5000 5000 2000
W32Task   D:\yy\Win32Task.exe Y 8    100  100  Std No   Y   A   30  0    0    5000 2000

# ---------------------------------------------------------------------------

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.

Data dictionary variable

This 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 file

This configuration file initializes the LogMsg subsystem.  It is described in detail in the [LINK] Libraries section.

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:

1. Request orderly and graceful stop of all processes

2. Forcibly terminate tasks that do not stop via graceful request

3. Save contents of global shared memory regions

4. Deallocate global shared memory regions

5. Stop operation of Startup task

The NtRtSvc task is used to run Tsentry as a system service.  This allows Tsentry to start automatically on system startup, continue to run whether or not the console is logged in, and gracefully stop upon system shutdown. 

The NtRtSvc service can be installed by running the following command from a DOS command prompt:

D:\locNtRt\tpriNtRt\bin\NtRtSvc -install D:\locNtRt\tpriNtRt\bin\NtRtMgr.exe D:\locNtRt\sys\pif\sys.ini

where D:\locNtRt is your root installation directory and sys is your system ID.

This adds the entry ‘Tsentry Manager Service’ to the list of services in your system.  By default, the service is configured for:

• Automatic startup

• Log On as local Tsentry user

It is strongly suggested that a separate user (e.g. username NtRtMgr) be created to run the NtRtSvc service instead of running as the Local System account for several reasons:

• Access to appropriate directories can more easily be managed if the system is started under an account other than the Local System account

• Access to the GsmOpcSvr is greatly simplified since the GsmOpcSvr can be configured to run under this same account while preventing any users from having DCOM launch permissions. 

This new user however must have administrative rights to perform functions such as creating and sharing global common segments, starting RTSS tasks, etc.

The NtRtSvc service can be started in several ways:

• If the Startup Type is configured as Automatic, the NtRtSvc will automatically start when the system is booted.

• From the Service Manager (Control Panel->Administrative Tools->Services), right-click on the ‘Tsentry Manager Service’ and choose ‘Start’.

• From a command prompt, type ‘net start NtRtSvc’. 

You must have administrative rights to manually start the NtRtSvc service via either of the last two options above.

The NtRtSvc service can be stopped in several ways:

• Shutdown Windows.  The NtRtSvc will automatically detect the system shutdown and gracefully stop itself and all Tsentry processes.

• Execute the NtRtStop process.

• From the Service Manager (Control Panel->Administrative Tools->Services), right-click on the ‘Tsentry Manager Service’ and choose ‘Stop’.

• From a command prompt, type ‘net stop NtRtSvc’. 

You must have administrative rights to manually stop the NtRtSvc service via either of the last two options above.

The current command line that the NtRtSvc service will start can be displayed by running the following command from a DOS command prompt: 

D:\locNtRt\tpriNtRt\bin\NtRtSvc -display

where D:\locNtRt is your root installation directory.

The NtRtSvc service can be removed by running the following command from a DOS command prompt:

D:\locNtRt\tpriNtRt\bin\NtRtSvc -remove

where D:\locNtRt is your root installation directory.

The NtRtStop process is used to kill all Tsentry tasks.  This performs the same shutdown sequence as NtRtMgr does when it shuts down.

The NtRtMtr task is designed to monitor the remaining Win32 processes and ensure that they behave properly.  It is effectively a worker thread for the NtRtMgr manager task, but because its duties require that it execute at the highest Win32 priority (31), it must be run as a separate process from the NtRtMgr GUI. 

Currently the NtRtMtr task provides the following services:

• Monitor all Win32 tasks to ensure that their respective pulse timers do not expire

• Request termination of any Win32 tasks whose pulse times do expire

The ProbeSvr task is a variable data server for Tsentry global shared memory.  Upon startup, the ProbeSvr process opens a listen socket on TCP/IP port number 2252 and waits for connections from remote clients across the network.  In most cases, these clients are Texplore browser sessions looking to retrieve global common variables from the host TSENTRY system. 

Once a client connects and exchanges initialization information with the server, the client can request a list of global common variables from the ProbeSvr process.  The host will then periodically send the values of each of these variables back to the client on a periodic basis or at any time that the variable value changes on the host. 

In addition, clients may choose to write new values for the requested variables back to the host system.  These new values will be immediately written directly into the corresponding global common variables.  The ProbeSvr process supports logging of custom messages when a client changes the value of a variable in global common by logging the change data to a specified LogMsg queue.  A custom application can then be written to process the change data logged to this queue and log the data as appropriate for the application.  The following data is available for logging:

• The fully qualified name of variable that was changed

• Date and time of the change

• Both old and new values of the variable

• Size (in bytes) and type (variant type) of the variable

• Array dimensions of the variable

• Username of individual (according to the client system) that made the change

• Computer name from which the user client connected to the host system (IP address or DNS name)

• Screen name (or equivalent) from which the change was issued on the client system

• Description of the change as indicated by the client system

Custom probe sources can be defined to allow the ProbeSvr process to serve local application data outside of global shared memory to HMI clients.  For example, the TelePro Thickness and Flatness Monitor system implements a custom probe source in order to display data from historical coil reports on Texplore screens.

Custom probe sources are implemented as a DLL that is dynamically loaded by the ProbeSvr executable at runtime.  The list of custom probe sources is defined in the process initialization file.

Clients can request a variable from a custom probe source by prefixing the variable name with the name of the probe source surrounded by forward slashes.  For example, requesting “/MyProbeSource/MyVariable” will tell the ProbeSvr process to request a variable named MyVariable from the DLL associated with the MyProbeSource custom probe source.

The DLL for a custom probe source must implement two functions.  The first function is called when the ProbeSvr process receives a request for a variable associated with the custom probe source:

//------------------------------------------------------------------------
//
// Function Name: AddVariable
//
// Description:
//    Add a probe variable to the custom probe source.
//
// Calling Format:
//    int fstatus = AddVariable(pVar);
//       where:
//          tpriProbeSrcVar *pVar = pointer to probe variable
//
// Return Value:
//    This function always returns zero.
//
//    In order to successfully add  the variable, the custom DLL must call
//    each of the following methods of the passed tpriProbeSrcVar object:
//     - SetSize(int newSize), where newSize > 0
//     - SetType(int newType), where newType != VT_INVALID
//     - SetDataPtr(void *newData), where newData points to a memory
//          buffer allocated with GlobalAlloc(..) which will not be
//          freed until the RemoveVariable(..) function is called
//     - SetArrayDimensions(int newCount, int *newDimensions) if the
//          returned buffer points to an array of data
//
// Notes:
//    When the function is called, the name of the variable can be
//    determined by calling pVar->GetName().
//
//------------------------------------------------------------------------

The second function is called when the ProbeSvr process determines that a variable is no longer required by any client application and can be removed from the custom probe source:

//------------------------------------------------------------------------
//
// Function Name: RemoveVariable
//
// Description:
//    Remove a probe variable from the custom probe source.
//
// Calling Format:
//    int fstatus = RemoveVariable(pVar);
//       where:
//          tpriProbeSrcVar *pVar = pointer to probe variable
//
// Return Value:
//    This function always returns zero.
//
// Notes:
//    None.
//
//------------------------------------------------------------------------

This initialization file for the ProbeSvr process currently defines:

• Local host address to which the ProbeSvr server socket should bind.  This is required on systems with multiple network interface cards, only one of which should be used by the ProbeSvr.

• The LogMsg queue used for basic text logging when a client changes the value of a variable in global common.  If this queue is not Tsentry’s default LogMsg queue then it must be defined in the sysLogs.ini file so that it is actually created when the TSENTRY system is started.

• The LogMsg queue used for logging custom messages when a client changes the value of a variable in global common.  This queue must also be defined in the sysLogs.ini file so that it is actually created when the TSENTRY system is started.

• Any custom probe sources and the associated DLL used to handle variable requests.

An example file follows:

# ------------------------------------------------------------------------
#
# Probe Initialization File
#
# This is the initialization file for the ProbeSvr process. 
#
# ------------------------------------------------------------------------

# ------------------------------------------------------------------------
# General probe parameters
# ------------------------------------------------------------------------

[General]

# Specify the local host to which the ProbeSvr server socket should bind,
# or leave blank to bind the socket without specifying a local host.
#LocalHost=127.0.0.1

# Specify the LogMsg queue for text-based variable change logging, 
# or leave blank to disable text-based change logging.
TextChangeLog=LogMsg

# Specify the LogMsg queue for binary variable change logging,
# or leave blank to disable binary change logging.
BinaryChangeLog=ProbeLog

# Specify the default timeout for sending a message to a client (ms)
SendTimeout=5000

# ------------------------------------------------------------------------
# Define custom Probe Sources
# ------------------------------------------------------------------------

[ProbeSource]
#SourceName   #DLL file path
QACRS         %TSENTRY_SYSDIR%\%TSENTRY_SYSNAME%\bin\QacrsSvr.dll

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.

The TrendMgr task [LINK] is the manager process for the trending subsystem.