This chapter contains specifications about a variety of technical areas of the TSENTRY process control system.

Windows 2000 Process Scheduling

The operating system, as well as some real-time applications use interrupts to ensure that external events are noticed by the operating system in a timely fashion. It is critical that interrupts be handled promptly and according to their relative priority.

Within Windows 2000, the kernel and the hardware abstraction layer (HAL) are tuned to optimize interrupt delivery and event dispatching. The kernel provides interrupt dispatching to the rest of the system. The kernel can operate at one of 32 possible interrupt levels, as shown in the table below. These levels help prioritize the tasks that must be accomplished before other, less time-critical work. The kernel reserves eight interrupt levels for its own use. The remaining 24 interrupt levels are mapped onto hardware interrupts with the HAL.

Interrupt Level(s)	Definition

Interrupt Level(s)	Definition
31	Hardware error interrupt
30	Powerfail interrupt
29	Interprocessor interrupt
28	Clock interrupt
12–27	These levels map to the traditional interrupt levels 0–15 used in PCs
4–11	These levels are not generally used
3	Software debugger interrupt
0-2	Reserved for software-only interrupts to prioritize work within device drivers and executive components

Windows 2000 handles interrupts on a preemptive basis. When an interrupt occurs, all execution at lower interrupt levels is suspended and execution begins immediately on the highest-level request. Processing continues until the highest-level process has been completed. This places a responsibility on device drivers in that system responsiveness is directly related to how quickly a device driver exits its interrupt routine.

All execution by the processor at an interrupt level is at a higher priority that all priority levels associated with a process thread. The allowed process thread priorities are described below.

A process within a Windows 2000 system is an independently executing instance of an application/program. A process comprises an address space (generally separate from all other process), object handles, and one or more paths of execution (threads). Microsoft Word, Notepad, and Internet explorer are examples of familiar processes within a Windows 2000 system. A process is created by the O/S using an program executable image stored on the disk as a “.exe” file. One or more instances of a disk based program may be started and executing at any time, and each becomes an ‘instance’ of the program, and an independent process.

A thread is an independent execution path within a process. Each process has at least one thread, the primary thread. When a process begins, the O/S begins the process by executing this primary thread.

Additional threads may be started by the process. These threads operate as part of the process and within the virtual space of the process. However, these threads are scheduled for execution independently from the execution of the primary thread. This might be done by the process to handle additional work items such as maintenance / background functions, or additional work items. Each thread may operate completely independently from the other threads within the process (as far as CPU utilization is concerned). Often, in a standard windows process, user interface thread(s) are used to handle user input and output, while worker threads are used to handle tasks requested by (or done on behalf of) the user requests.

The standard Windows 2000 system supports 32 priority levels for scheduling threads within a process. These priorities are numbered 0 through 31, with priority 0 being the lowest and 31 being the highest priority. The Windows 2000 scheduler is a pre-emptive scheduler; it will attempt to execute the thread with the highest priority at any instant in time. Whenever the dispatcher reschedules a processor, it will find the highest priority thread available (and able to use a processor resource) and assigns the processor to execute that thread.

Windows divides the 32 priority levels into two (2) groups or ‘classes’. When a process is started in standard Windows 2000 system, it will be started as either a ‘Normal’ or a ‘Real-Time’ process. Once the process is started as Normal (sometimes called the Dynamic or Variable-Priority) or Real-Time, all of the threads in that process will have priorities reserved for that type of process.

The priority of a thread of a ‘Normal’ process ranges from priority levels 1 through 15. The ‘Real-Time’ priority range includes priority levels 16 through 31. Thus, all threads within a ‘Real-Time’ process are scheduled for execution before any of the ‘Normal’ threads.

Typically, real-time processes will run at priority 24. Other applications (dynamic classes) have a base priority class of 15, 13, 9 (normal foreground process), 7, 4, 1, and 0.

A process is assigned a ‘base priority’. Each thread has a current priority derived from the process' priority class. By using an application programming interface (API) call that varies up or down from the process' base priority, you can vary the current priority up or down within defined limits. For example, a process running at real-time class 24 can have threads that run anywhere between classes 26-22, depending on their own independent priority. However, these threads will always stay within the real-time priority class.

The 5 priorities clustered around Base Priority (BasePriority-2 through Base Priority+2) are used to assign a specific priority to a thread. (These are often termed: Lowest, BelowNormal, Normal, AboveNormal, and Highest).

The Windows O/S scheduler will adjust the priorities of threads within the ‘Normal’ (or Variable-Priority) class in an attempt to optimize system response time. CPU bound threads will tend to have their priorities reduced while threads ending a wait (for a resource, time interval,…) will have their priority raised.

Threads are independently scheduled by the executive. Associated with the process is a quantum (the maximum amount of time a thread can execute before the system checks to see if other threads with the same priority want to execute). In general, real-time processes will have priority over almost all other activities or system events. However, for processes in the spectrum of dynamic classes that are running at lower priority levels, a number of events within the system, such as I/O completion, could cause a temporary priority boost for a thread, giving it priority within a process.

With the installation and use of the VenturCom Real-Time extensions:

Real-Time Execution (RTX) functionality is added to the Win32 environment, and
an RTSS environment is added to the standard Win32 environment.

Some objects are valid only in the environment in which they were created (Ex: thread, timers, interrupts). Other objects (semaphores, events, mutex objects, and shared memory) may be used to synchronize and communicate between RTSS and Win32 processes and threads.

RTSS Environment

An RTSS thread is a unit of execution in the RTSS environment. A ready-to-run RTSS thread is scheduled before all Windows 2000 threads. Unlike a Win32 thread, which may have the processor removed by the O/S, an RTSS thread runs until it gives up the CPU. A thread gives up the CPU when it:

Waits for a synchronization object
Lowers its own priority or raises another thread’s priority
Suspends itself
Returns from the timer or interrupt handler (applicable to timer and interrupt threads) routines
Calls Sleep with an argument of 0

The RTSS environment has no distinct priority classes, so the threads of all RTSS processes compete for CPU using the thread priority only. An RTSS thread runs at one of 128 distinct priority levels. Threads execute in priority order and in “first in, first out” order within any single priority. Threads are not subject to time-sliced sharing of a processor; that is, an executing thread runs until it gives up the CPU, or until an external event readies a higher priority thread. RTSS scheduling uses a priority promotion protocol to eliminate unbounded priority inversion.

Win32 Environment

A Win32 RTX program starts execution in the real-time priority class. RTX provides a mapping between RTSS and Win32 subsystem priorities. However, Win32 scheduling may exhibit unbounded priority inversion.

Programming Considerations

All processing in the RTSS environment takes priority over all processing in the Win32 environment.

VenturCom RTSS vs. Win32 Priority Spectrum

RTSS Priorities in the Win32 Environment

The following table, RTSS to Win32 Thread Priority Mapping, shows how RTSS symbolic priority names translate to and from requests for a particular Windows 2000 priority when RtSetThreadPriority is called by a Win32 program.

RTSS Symbolic Priority Name	RTSS Value	Windows 2000 Symbolic Priority Name for Real-Time Priority Class	Win32 Value

RTSS Symbolic Priority Name	RTSS Value	Windows 2000 Symbolic Priority Name for Real-Time Priority Class	Win32 Value
RT_PRIORITY_MIN	0	THREAD_PRIORITY_IDLE	16
RT_PRIORITY_MIN + 1	1	THREAD_PRIORITY_LOWEST	22
RT_PRIORITY_MIN + 2	2	THREAD_PRIORITY_BEOW_NORMAL	23
RT_PRIORITY_MIN + 3	3	THREAD_PRIORITY_NORMAL	24
RT_PRIORITY_MIN + 4	4	THREAD_PRIORITY_ABOVE_NORMAL	25
RT_PRIORITY_MIN + 5 .. +126	5…126	THREAD_PRIORITY_HIGHEST	26
RT_PRIORITY_MAX	127	THREAD_PRIORITY_TIME_CRITICAL	31

Windows 2000 Symbolic Priority Name for Real-Time Priority Class	Win32Value	RTSS Symbolic Priority Name	RTSS Value

Windows 2000 Symbolic Priority Name for Real-Time Priority Class	Win32Value	RTSS Symbolic Priority Name	RTSS Value
THREAD_PRIORITY_IDLE	16	RT_PRIORITY_MIN	0
THREAD_PRIORITY_LOWEST	22	RT_PRIORITY_MIN + 1	1
THREAD_PRIORITY_BELOW_NORMAL	23	RT_PRIORITY_MIN + 2	2
THREAD_PRIORITY_NORMAL	24	RT_PRIORITY_MIN + 3	3
THREAD_PRIORITY_ABOVE_NORMAL	25	RT_PRIORITY_MIN + 4	4
THREAD_PRIORITY_HIGHEST	26	RT_PRIORITY_MIN + 5	5
THREAD_PRIORITY_TIME_CRITICAL	31	RT_PRIORITY_MAX	127

Access to a Microsoft Windows 2000 System

Process control systems often have the need to support multiple sessions from remote locations for program development, support, and maintenance. Historically this has been accomplished using an asynchronous communications connection or a Telnet server on the process control system and initiating standard terminal or Telnet sessions from a client on a PC based workstation.

Although Windows 2000 systems are often considered single user systems, there are a number of attractive and easily managed alternatives for supporting system access with simultaneous sessions when Windows 2000 is configured as a process control system host. These include:

FTP access to files
Sharing Drives and Directories
pcAnywhere console sharing and remote access
Terminal Services

An FTP server is configured on each process control system. With proper configuration some or all of the files resident on the system may be made accessible via FTP. For the Tsentry systems, read and write access is provided to all source, program development, and process data files for users with satisfactory security credentials. Access to these areas is strictly controlled and implemented with the use of standard NT User ID and Password security.

A standard feature of Windows 2000 is the ability to share host system directories and drives. Normal User Id and Password authentication is provided so that access to these resources can be controlled on a file, directory, or drive basis.

A remote PC workstation may map a process control host system shared resource and use it as a local resource.

All program development facilities are available using this method. All of the program development functions, including source editing, linking, and testing can be accomplished in the safe environment of the workstation. Edited source may be maintained on the workstation or on the host system.

Given that any directory or drive may be mapped as a local drive on a Windows workstation, tools of the software developer’s choice may be used to edit any source modules. For the Tsentry systems, procedures are also provided to build all executables from a text based, command line interface. Multiple users may shared mapped drives and develop simultaneously.

Optionally, SourceSafe, a standard part of the Microsoft Visual Studio software development environment, can be installed as a check out and check in source management tool. Multiple codes sets and source trees may be maintained within SourceSafe, and large projects may be managed. This is a significant advantage where multiple, remotely located developers are working on the same code set.

pcAnywhere, a 3^rd party product from Symantec, provides a convenient mechanism to access the complete console environment of a Windows system. pcAnywhere makes any workstation that is connected to the control system by the network capable of acting as the system console. The latest version of this software provides access to a single system console simultaneously from multiple workstations.

pcAnywhere has been carefully tested in the Tsentry real-time process control operating environment. It is very robust, and is installed and operational on all control systems.

When the Tsentry system is hosted on a Microsoft Windows Server, a standard extension of that system is Terminal Services. Terminal Services provides a complete graphical user interface (the familiar Windows desktop) for remote workstations.

Data Dictionary

The Data Dictionary is a set of functions and utilities tasks to provide access to variables from a number of sources. Processes are provided to:

Build a data dictionary directly from the source ‘.h’ include files used to build application processes
Store the data dictionary as an ASCII disk file
Load the data dictionary on system startup
Load initialization values to selected variables
Automatically save variable values on system shutdown
Provide real-time access to global common variables by variable name
Provide access to all global common variables to all OPC clients. OPC clients include web screens, VB, C, and C++ applications, and any COM or DCOM aware application such as Excel, Word, PowerPoint, …

The Data Dictionary is built by the standard Tsentry process GsmPifBld. This process:

Reads an INI file to determine the location of the standard C and C++ include files. These include files define the variables and structures which make up global common.
Directly reads the include files from the locations use to build applications.
Builds the data dictionary control files that define global shared region names, variable names, variable types, array sizes, and variable addresses.
Stores the Data dictionary control file on disk.

This process can be (and normally is) called as a standard part of a system application build procedure.

The time required to build a data dictionary with about one thousand variables is about one (1) second.

Management of the data dictionary function is made very simple by the following features:

Automatic creation of data dictionary from program source code include files. No separate databases to setup and maintain.
Automatic saving and restoring of user-selected variables by the startup and shutdown processes. Variables that are not selected for persistence are initialized to zero on system startup.
The size and layout of global common areas can easily be changed between system shutdown and restart. A new build of the data dictionary will automatically update the stored global common layout, placing new variables and re-locating previous variables appropriately so that stored values will be restored properly.

C/C++ Libraries

Several libraries are supplied with the Tsentry system that encapsulate functions used in many of the real-time process control tasks. These libraries are provided for both the standard Windows (Win32) task environment and for hard real-time (RTSS) task environment. These libraries include functions and classes supporting:

Process Management
Global Shared Region Management
Data Dictionary Services
Communications Services
Process I/O Device Drivers

These libraries are completely described and documented in Chapters 5, 12 through 16 of this manual.

A brief description of the library contents follows:

1

Real-Time Process Management Class:

Read initialization file for all processes

Start all system processes in table

Check / restart all processes in table

Activate a process

Resume a process

Suspend a process

Deactivate (kill) a process

Initialize current process

Suspend and wait for next timer event

Resume a process on a timer event

Set up process timers

Get table index for a process

Get ID for a process

Set process priority

Set process application name

Set process executable binary name

Set process timer start delay

Set process timer interval

Set process run mode (Standard Windows / Hard Real-Time)

Set process restart required flag

Maintain process statistics

2

Global Shared Memory Management Class

Read GSM variable initialization file

Create a global shared memory region

Map a global shared memory region

Sort variables

Return variable initial value from file

Return variable minimum value from file

Return variable maximum value from file

Return initial value as formatted string

Return minimum value as formatted string

Return maximum value as formatted string

Save selected contents of global shared memory region

Restore selected contents of global shared memory region

3

Logging and Error Reporting Class

Log a message to logging system

Display log message in console window

Write log messages to disk based log file

Set debug level for writing Log messages

Set debug level for a process

Shared Memory Management

Shared memory regions are supported for all process control (Win32 and RTSS) related tasks in the Tsentry environment. The management functions for these regions include:

Allocation of Global Shared regions on system startup
Mapping and unmapping of global shared memory areas by application tasks
Initialization of all variables
Population of user specified variables with fixed initial values
Population of user specified variables with values saved from previous operations
Saving user specified variables to disk on a timed basis, at user requested times and intervals, and on system shutdown
Access to variables for read and write by variable name

Real-time TCP/IP

A large percentage of process systems need and use a network to provide communications with process I/O related hardware. If network access can be controlled and real-time protocol stacks are available, an Ethernet network is an excellent choice. This network topology can provide a fast, inexpensive, and industry standard interface to a wide variety of devices.

The Tsentry system can be configured to implement a completely separate network to carry process I/O traffic. This separate network, along with a separate protocol stack, provides the following advantages:

Segregation of all process I/O traffic from the site traffic
Protocol stack designed for process I/O needs
- Low overhead
- Minimum latencies
Fast response
Immediate transmission and reception of I/O traffic
User controllable buffering
Low cost network interfaces
Availability of robust hardware
Easily interfaced to other network segments through standard routers

HMI Overview

A Human Machine Interface is a normal part of the Tsentry process control system. It is designed around standard software components and display utilities and is highlighted by the following key functions and benefits:

Screens are built to provide user access to process information for production, engineering, and management personnel.
Screens may be built using a variety of standard Web building tools (FrontPage 2000, …).
Visual Basic may be used to extend the capabilities of simple html code and build screens of any complexity.
Screens are built and published (made ready for display) by a set of tools provided as a standard part of Tsentry. These tools provide an automated mechanism to incorporate the required HTML code, Visual Basic forms, and libraries of controls to make web pages.
Screens are stored on the control system as .htm and .asp files.
Screens are displayed on operator Microsoft NT based workstations using the Microsoft Internet Explorer browser. No special programs or licensed software is required or used on the workstation. Screens may be displayed anywhere that network connectivity is available.
Screens are distributed at run time by the Microsoft Internet Information Server web service. This server is a standard facility of the Windows 2000 system.
Screens may be built to display static information, file based data, or real-time data updated from global common.
Real-time updates on network-based workstations are a default offering. Tabular data is updated at once per second. Graphic screens, including real-time trends, easily display multiple variables gathered at intervals of 20 milliseconds or less. This system is designed to display high speed process data.
A library of real-time HMI objects is provided. These objects may be tied to real-time variables in a host system. The host system variables control the animation of the objects, including the shape, size, orientation, text, location, etc.

No special tools, licenses, or other software beyond that which is normally supplied with TSENTRY is required to implement the HMI.

The HMI Screens and Screen Development sections of this manual provide a complete documentation on the HMI system and the screen building process.

Real-time Trending

A standard part of the TSENTRY process control system is the Real-time Trending features. This feature is built on the basic functionality of TSENTRY using:

HMI Screen Building tools
Global Common management functions
Variable access via the Data Dictionary
High speed data acquisition and display

Real-time trending can acquire any reasonable number of variables (for example, 100-200 variables) simultaneously, each at rates up to 50 samples per second, and serve these variables to a variety of network connected workstations running a standard browser. Displays may be updated with real-time data for up to 30 trends per screen.

A complete discussion of Real-time Trend is found in the Trend System.

Historical Trending

Historical Trending is an extension of the Real-time Trend capability of the TSENTRY process control system. Building on the Real-time Trend facilities, this functionality further includes:

Grouping of multiple variables together into a cohesive set of trending data.
Storing this data on disk files for later access and review.
Triggering the stop and start of data acquisition by a set of user defined trigger definitions.
Acquisition and storage of multiple historical trend files simultaneously.

A complete discussion of Historical Trend is in the Trend System.

Store and Forward Process Information

Information collected and processed by application programs on the Tsentry system can be stored and forwarded to other systems for multiple purposes:

Process quality databases
Shop Floor Tracking
Asset Utilization models and databases
Process data archiving
Operator timekeeping functions
Engineering analysis

A set of example applications is provided to demonstrate the acquisition, processing, and storage of data on the process control system. Additional example programs are provided to demonstrate the forwarding and processing of the data by external systems.

VenturCom Published Real-Time Response Results

The following interrupt and timer response results were obtained from a test system as follows.

The table below presents selected performance numbers for a recent release of RTX on a 266 MHz Pentium 2

Operation	Latency (usec)
Interrupt Thread: avg., max	9, 38
Timer interrupt: avg., max	10, 43
Context switch (yield): avg.	3.5
Context switch (semaphore): avg.	5.5
Thread priority change: avg.	3
Thread yield: avg.	3
Acquire semaphore, uncontested: avg.	1.5
Acquire semaphore: avg.	5
Win32-to-RTSS semaphore call: avg.	50

The following is a typical display from the RTSS interrupt latency measurement utility in the presence of a typical NT workload: disk searches, video updates, network activity, screen saver, etc. The lower and narrower sections of the chart's bars represent activity during the last second only.

The following is the Win32 counterpart for the same kind of workload, in this case a Gateway GP5-166 running NT4.0 Workstation SP4. The following screen displays the Win32 timer interrupt latency histogram for a typical workload, where the X axis units = msec, Y axis units = number of samples.

Copious performance results are available from independent evaluations of RTX and other real-time NT extensions [OMAC 98] [Real-Time 98] [Timmerman 98].

VenturCom Performance Evaluator

VenturCom offers a product to measure the real-time response of a particular hardware configuration. Interrupt (and Timer) response and system service times are measured with and without VenturCom RTX extensions over extended periods of times

Measured times on the 2000-vintage IBM configuration have been taken over extended periods of time. Tests were run to determine the maximum elapsed time between a timer (interrupt) event and the start of execution of the interrupt response routine. Servicing routine is a complete process environment (all system services available) and not an interrupt handler. Elapsed times include the time required to take the timing measurements. Results are as follows:

Test Duration: 100 hours
Interrupts: >3.6 * 10⁸
Load Disk, Network, Video, Software Development
Equivalent Rolling Time: 6 months
Max Timer Rsp: < 35 uSec, worst case

‘C’ Structure Template for ‘Standard Application’

Most of the real time processes for this system have the same organization. This allows and enhances the use of standard classes to handle basic process functions. It include the calls to the process and Global Shared Management functions required to set up the task, link it with the proper global common areas, and initiate timers.

Use of a standard organization enables the system owner, when adding another function, to concentrate on the additional functionality and minimizes the work required to insert the additional functionality into the system

The standard real-time process has the following organization:

// ---  startup.cpp  ----------------------------------------------------
// Function:  System Startup
// ----------------------------------------------------------------------
    

   ExitProcess(rstatus);
   }

Major TelePro / SSE Control System Classes

Some of the TelePro / SSE supplied Classes are described in the following table:

Class Names	Methods Properties Events	Description

Class Names	Methods Properties Events	Description
tpriProc		Process Management
	tpriProc	Class constructor
	~tpriProc	Class destructor
	ReadIniFile	Read Initialization file for all processes
	StartAllProcs	Start All processes
	Activate	Activate another process
	Resume	Resume another process
	PrIni	Initialize current process
	PrWait	Wait for next timer event
	TmrSetup	Set up process timers
	CheckProcs	Check / restart all processes
	GetIndex	Get process index
	GetPid	Get Process ID
	Priority	Get/Set Process Priority
	AppName	Get/Set Process App Name
	BinName	Get/Set Process Executable Binary Name
	TmrDelay	Get/Set Process Timer Initial Delay
	TmrInterval	Get/Set Process Timer Rep Rate
	RunMode	Get/Set Process Run Mode (Std / Real-Time)
	Lock	Get/Set Process Lock in Memory flag
	Restart	Get/Set Process Restart required flag
	Record	Get/Set Process Statistics flag
tpriGsm		Global Shared Memory Management
	tpriGsm	Class Constructor
	~tpriGsm	Class Destructor
	ReadIniFile	Read GSM Variable Initialization File
	SortAllVars	Sort Variables
	InitialValue	Return Variable Initial value
	MinValue	Return Minimum value
	MaxValue	Return Maximum Value
	InitialValueStr	Return Initial Value as formatted string
	MinValueStr	Return Minimum Value as formatted string
	MaxValueStr	Return Maximum Value as formatted string
	MapGsm	Map a Global Shared Memory Region
	CreateGsm	Create a Global Shared Memory Region
	SaveGsm	Save a Global Shared Memory Region to Disk
	RestoreGsm	Restore a Global Shared Memory Region from Disk
	tpriLog	Logging & Error Reporting Functions
	LogMsg	Log a message to the console and log file
	DbgLevel	Set Debug Level for Process
	SetLevel	Set temporary debug level
	GetLevel	Get temporary debug level
	SetOptions	Set logging options
	GetOptions	Get logging options
	RestDbgLevel	Restore Process Debug Level
	SetFileName	Set logging file name
	GetFileName	Return logging file name
	Start	Start logging functions
	Stop	Stop logging functions
	Pause	Pause logging functions
	Continue	Continue logging functions


tpriHtm		User Interface pre- and post- processing htm forms
	addPrepVar	Prepare a standard variable name/value for page output
	addPrepChkbox	Prepare a variable checkbox for page output
	addPrepRadio	Prepare a variable radio button for page output
	addPrepSelectOption	Prep a variable drop-down box for page output
	addPrepVector	Prepare an variable vector for page output
	addPrepGraph	Prepare a graph for page output
	getPrepVar	Retrieve value associated with a prepared variable name
	freePrepVarList	Destroy the current variable name/value table
	parseSubmit	Parse a string of submitted variables into local table
	getSubmitVar	Retrieve value associated with submitted variable name
	processPage	Read htm file from disk, perform variable substitutions

tpriDDC⁽¹⁾		Direct Digital Control Functions
	tpriDDC	Class Constructor
	~tpriDDC	Class Destructor
	BitClear	Clear a specified bit in an integer word
	BitSet	Set a specified bit in an integer word
	BitTest	Return the state of a specified bit in an integer word
	CopyFloatVals	Copy floating point values from one memory segment to another
	CopyIntVals	Copy integer values from one memory segment to another
	DBType1	ISA Type 1 deadband operation
	DBType2	ISA Type 2 deadband operation
	DBType3	ISA Type 3 deadband operation
	Integral01	Backward rectangular integration approximation
	LagFilt01	First-order low pass (lag) filter algorithm with unity gain
	LagLeadFilt01	First-order lag-lead filter algorithm with unity gain
	LimitFloatVal	Limit a floating point value to a specified range
	LimitIntVal	Limit an integer value to a specified range
	ParallelPID	Parallel formulation of the PID control algorithm
	SetFloatVals	Set a specified number of variables to a given float point value
	SetIntVals	Set a specified number of variables to a given integer value
	TimeDelay	Delay a time series by a variable time period

tpriFbkAGC		Feedback Gauge Control
	tsseFbkAGC	Class constructor
	~tsseFbkAGC	Class destructor
	GetInputs	Localize inputs from shared memory
	PermLogic	Activation permissive logic
	CalcTransDelay	Calculate material transport delay
	CalcCtlError	Calculate controller error
	CalcGMEst	Calculate gaugemeter thickness estimate
	CalcGapDatum	Calculate gap datum (zero) point
	CalcMFEst	Calculate mass-flow thickness estimate
	CalcPIDGains	Calculate parallel PID controller gains
	CalcGapGains	Calculate gap output gains
	CalcSpdGains	Calculate stand speed output gains
	CalcUnwGains	Calculate unwind torque output gains
	CalcRewGains	Calculate rewind torque output gains
	ModeSwitch	Perform mode switching logic
	CalcLimits	Calculate dynamic output limits
	PIDControl	Calculate PID control action
	SLPControl	Calculate Smith Linear Predictor control action
	LoadHMIData	Load mode-dependent HMI data for display
	FirstPass	First active control pass logic
	CalcCorrectionsCalculate individual actuator corrections
	AntiWindup	Perform integrator anti-windup protection
	ReInit	Re-initialize controller between coils
	SetOutputs	Externalize outputs to shared memory
	HandleErrors	Perform error handling and diagnostics

tpriATC		Automatic Tension Control
	tsseATC	Class constructor
	~tsseATC	Class destructor
	GetInputs	Localize inputs from shared memory
	PermLogic	Activation permissive logic
	CalcTension	Calculate tension feedback
	CalcTorque	Calculate acceleration/deceleration torque
	CalcInertia	Calculate coil inertia compensation
	CalcLosses	Calculate friction and windage losses
	CalcCurrent	Calculate winder current references
	CalcCtlError	Calculate controller error
	CalcPIDGains	Calculate parallel PID controller gains
	CalcGapGains	Calculate gap output gains
	CalcSpdGains	Calculate stand speed output gains
	CalcUnwGains	Calculate unwind torque output gains
	CalcRewGains	Calculate rewind torque output gains
	ModeSwitch	Perform mode switching logic
	CalcLimits	Calculate dynamic output limits
	PIDControl	Calculate PID control action
	LoadHMIData	Load mode-dependent HMI data for display
	FirstPass	First active control pass logic
	CalcCorrections	Calculate individual actuator corrections
	AntiWindup	Perform integrator anti-windup protection
	ReInit	Re-initialize controller between coils
	SetOutputs	Externalize outputs to shared memory
	HandleErrors	Perform error handling and diagnostics


TpriAFC		Automatic Flatness Control
	tsseAFC	Class constructor
	~tsseAFC	Class destructor
	GetInputs	Localize inputs from shared memory
	PermLogic	Evaluate activation permissives
	Coverage	Determine partial zone coverage by strip
	ChebyCurve	Calculate a Chebyshev polynomial curve
	SprayPreset	Determine work roll zone cooling spray preset pattern
	CalcRefVector	Calculate shape reference vector
	CalcFbkVector	Calculate shape feedback vector
	CalcErrVector	Calculate controller error vector
	SymmSigProc	Determine corrections for mechanical actuators with symmetric shape sensitivities (roll bending, CVC)
	AsymSigProc	Determine corrections for mechanical actuators with asymmetric shape sensitivities (HGC tilt)
	CalcResVector	Calculate shape error residual vector (error minus mechanical actuator corrections)
	SpraySigProc	Determine corrections for roll cooling sprays
	CalcTransDelay	Calculate material transport delay
	CalcPIDGains	Calculate parallel PID controller gains
	ModeSwitch	Perform mode switching logic
	CalcLimits	Calculate dynamic output limits
	BendControl	Roll bending control
	ShiftControl	CVC shifting control
	TiltControl	HGC tilting control
	SprayControl	Work roll zone cooling control
	LoadHMIData	Load HMI data for display
	FirstPass	First active control pass logic
	AntiWindup	Perform integrator anti-windup protection
	ReInit	Re-initialize controller between coils
	SetOutputs	Externalize outputs to shared memory
	HandleErrors	Perform error handling and diagnostics

	sps	Parent class to profile / shape model classes for inherited functionality

The following group of classes contains the building blocks of the SSE Flatness Calculation System:

	spsRoll	Roll definition and calculations class
	spsStack	Stack definition and calculations class
		public properties: instances of spsRoll
	spsStrip	Strip definition and calculations class
	spsSchedule	Schedule definition and calculations class
	spsOutputs	Main model calculations and results class
	spsFlatness	Model definition class
	solveModel(...)	Make model calculations using: instances of spsStack, instances of spsStrip, instances of spsSchedule, instances of spsOutputs
	spsErrLog	Functionality for message logging to user interface
	spsIOFile	Input/output file processing for flatness model
	spsIOParamList	Defines units, comments, conversions, minimum & maximum values for model parameters
	spsServer	HTML page server for flatness system

TSENTRY Support and Problem Reporting Web Site

A problem reporting and support web site is available for support of the TSENTRY Control System. It has the following options:

Login, with user id and password security
Problem Submission
Problem resolution with revision numbers, notes, and options
Problem Logs
Search & display of problem which meet specific, user defined selection fields
Frequently asked questions
Immediate access to and distribution of current documentation
Software Distribution

The TSENTRY support site is located at http://www.tsentry.com.

Tsentry

Technical Specifications