Tsentry Control Platform

System Description

The Tsentry system is a general-purpose, stand-alone process control system platform based on the Microsoft Windows 2003 Server operating system. It utilizes industry-standard hardware architecture, system software, program development facilities, human-machine interface facilities, and communications protocols. This reduces the cost and complexity of expanding and upgrading the system as necessary to keep abreast of rapidly-changing computing technology.

Tsentry is supplied as a layered product, complete with all facilities required to develop and support real-time computing applications with program repetition rates as fast as 1 millisecond. It is specifically designed as an open-architecture, real-time computing platform for hosting high-speed process control, monitoring, signal processing and human-machine applications. It is proven technology, with over 80 systems in operation worldwide

Human-machine interface (HMI) displays are implemented as standard Internet web pages hosted by the Tsentry system. The standard Tsentry product includes all facilities required to develop and support a human-machine interface system based on standard web pages. These facilities include custom controls for building animated displays with Microsoft Visual Basic .NET. Automated processes are included for building web screens to execute the controls and for publishing the controls to client workstations. Any network-connected PC workstation with a standard web browser and proper security credentials can be used as an HMI client.

The Tsentry system consists of the following components:

  • Standard Intel Pentium-class PC hardware platform
  • Microsoft Windows 2000 or 2003 Server operating system
  • VenturCom RTX Real-time operating system extensions
  • Real-time computing facilities:
    • Table-driven system startup and shutdown facilities
    • Data dictionary building and management functions
    • Data dictionary access to process variables
    • Standard process management services
    • Program templates for real-time system processes
    • Global shared region OPC server
    • Web browser based, high-speed, real-time HMI system
    • Real-time and historical trending systems
    • System support procedure scripts
  • System libraries for:
    • Process management
    • Global shared memory management
    • Message logging and error reporting
    • Configuration file processing
    • Timer support functions
    • Utility functions
    • Process I/O device drivers
    • Communication services
    • Automated rules processing

Tsentry Hardware

The Tsentry host computer is an off-the-shelf Intel Pentium-class PC running the Windows 2000 Server or 2003 Server operating system with VenturCom RTX real time extensions. All hardware employs industry-standard, open-architecture systems commercially available from multiple equipment suppliers. Communication is via industry-standard TCP/IP protocol over ETHERNET.

The host system is a standard IBM-compatible personal computer and can be configured according to customer requirements. Though it is not required, this can include mirrored disk configurations, PC server architectures, and alternative PC form factors. Prior to commissioning, performance tests are conducted on all systems for extended periods of time to assure reliability.

Graphical HMI/Engineering workstation displays are implemented as standard Internet web pages allowing display using standard web browsers and screen building using standard web page development tools.

A fully-redundant backup/development CPU can be included in the architecture, but is not required. If the backup CPU is available, switchover from the primary CPU to the backup consists of simply re-assigning network addresses and moving local I/O cables. In most cases, the switchover can be performed manually in less than 15 minutes. If no physical cables must be moved, application-specific software can be used to perform the switchover automatically.

This system interfaces to several varieties of commercially available process I/O hardware. In a typical configuration, the Tsentry host computer is interfaced to RTP I/O hardware from RTP Corporation via a high-speed ETHERNET link available commercially from the I/O equipment manufacturer. Device driver software already in wide commercial use is supplied to manage the data exchange.

A typical Tsentry host is configured as follows:

  • Intel Pentium 4 CPU: 2.4 GHz or faster
  • 512 MB memory
  • CDRW drive
  • 60 GByte hard disks or larger
  • Graphics controller
  • 19" color monitor
  • 2 ETHERNET controllers:
    • Backplane: Intel PRO 10/100 or equivalent for the process LAN connection
      • Connection to operator HMI and maintenance support workstations
      • Connection to external file servers, scheduling systems, etc.
      • LAN to LAN router to remainder of site network
    • 3COM 3C905-TX for dedicated control I/O LAN connection
      • High-speed ETHERNET connection for remote I/O
      • PLC connections
      • Isolated from all other network traffic
    • Controller for local I/O (optional)

The automation architecture permits remote technical support through a secure ETHERNET connection. To enable remote support, the customer provides an ETHERNET LAN connection available to a trusted external site and a bridge to isolate the process control computers from the external network.

A typical hardware architecture design for rolling mill automation is shown in the following diagram:

Figure 1: Example Tsentry Hardware Architecture

Tsentry System Architecture

Tsentry Software

System software includes:

  • Windows 2003 Server operating system
  • Microsoft Visual Studio .NET software development environment
  • VenturCom RTX real-time operating system extensions
  • TelePro Tsentry real-time process control system libraries
  • Microsoft Terminal Services
  • Symantec PCAnywhere

Real-Time Human-Machine Interface (HMI) System

Graphical human-machine interface (HMI) displays are implemented as standard Internet web pages hosted by the Tsentry system. Displays are developed using a combination of Microsoft Visual Basic .NET and Active Server Pages. Complete facilities for developing and publishing custom HMI displays are provided to the end user.These include:

  • Custom controls for building animated displays with Microsoft Visual Basic .NET.
  • Automatic communications client object for accessing global shared memory variables over the TCP/IP network.
  • Automated processes for building web pages to execute the controls and for publishing the controls to client workstations.

Any network-connected PC workstation with a standard web browser and proper security credentials can be used as an HMI client.

Examples of HMI displays for various process control applications are shown in Figures 2 through 7. Figure 2 is a rolling mill operator's display, showing target and actual measured exit stress distributions, work roll zone spray flow levels, entry and exit thickness deviation trend plots, roll bending and HGC tilt feedback, separating force, mill speed, and other process variables. This display is updated once per second. Data for the trend plots is sampled every 20 milliseconds.

Figure 2: Graphical Operator's Display

Cold Mill Process Display

Examples of maintenance support displays for rolling mill control functions are shown in Figures 3 through 5. Figure 3 is the work roll bending controller component of an automatic sheet flatness control (AFC) system for a cold rolling mill. Figure 4 shows internal detail for the feedback automatic gauge control (AGC) function on a rolling mill. Figure 5 shows the feedback AGC activation logic.

Figure 3: AFC Work Roll Bending Controller

WRB Main Display

In the diagram above:

  • Clicking on the box marked "PID Control" displays additional levels of algorithm detail.
  • Gain KS is a commissioning value with nominal value 1.0 which can be changed directly on the display.
  • Other values displayed on yellow backgrounds are data entry as well as display fields on the screen. Security is provided to assure that only authorized personnel are permitted to make parameter changes.
  • The function buttons at the lower left of the screen switch to other system displays.
  • Boxes at the lower right of the display are real-time variable trend plots and vector displays of critical controller variables.

Figure 4: Feedback AGC Controller

FBG Controller Display

In the diagram above:

  • Clicking on the box marked "Monitor PID" displays additional levels of algorithm detail.
  • The box at the lower right of the display is a real-time variable trend plot of a critical controller variable.

Figure 5: Feedback AGC Activation Logic

FBG Activation Logic

In the diagram above:

  • True states are indicated by filling the associated box (for inputs) or circle (for outputs) with green. False states are indicated with red.
  • The state of the maintenance enable logical can be changed by clicking with a mouse device directly on the state indicator.

Figures 6 and 7 are displays from a real-time thickness and flatness performance data collection system for rolling mills. Figure 6 shows two thickness deviation power spectrum "waterfall" plots in which all of the power spectra calculated during the rolling of a single coil are stacked one behind the other to produce a 3D plot. Figure 7 shows a 3D surface plot representing sheet flatness through an entire coil. The beginning of the coil is at the left of the plot.

Figure 6: Power Spectrum Waterfall Plots

Power Spectrum Waterfall Plots

Figure 7: 3D Flatness Performance Plot

3D Performance Plot

Real-Time / Historical Trend Facility

The Tsentry computing platform provides a real-time / historical data trend facility which supports Internet web page based editing and display of process variables. Data may be displayed and edited from a browser run on the system console or on any network-connected Windows workstation. Both graphical and tabular data displays are provided.

The real-time / historical trend system includes the following functions and features:

  • Access by name to any process variable in host global shared memory by means of a data dictionary.
  • Data dictionary build process. This process automatically updates the global shared memory data dictionary when new variables are added to the system and old ones are deleted.
  • Real-time trend data acquisition. Data is acquired at a 20-millisecond rate (50 samples per second per point) and made available for display on networked HMI / maintenance support workstations.
  • Real-time trend data display. Web page screens are provided for graphical and tabular display of high-speed, real-time data.
  • Display pan and zoom features.
  • Trend data can be exported as individual Windows files.
  • Storage, retrieval, and editing of trend set files, which define graphical and tabular data display configurations: variable names, scaling, display attributes.
  • Dynamic trend display editing allows interactive modification of trended variable names, time scales, signal magnitude scales, and text display formats.
  • Historical trend display integrated with real-time trend displays.
  • Facilities for starting and stopping historical trend data acquisition based on user-defined trigger events.
  • Support for multiple variable types: floats, integers, character strings, Booleans.
  • Multiple value display formats: float, character, decimal integer, hexadecimal integer, and binary.
  • Process variable "Probe" screen. A web page is provided for displaying and modifying any process variable in shared memory by name. The screen is accessible from a web browser run on the system console or on any networked Windows workstation. Data write access can be password protected.
  • Process variable "ProbeA" screen. Same functionality as "Probe" for multidimensional array data objects.
  • Process variable "TrendX" screen. View up to 24 simultaneous signal trends in real time on up to six independent Y axes.

Examples of the Probe, ProbeA, and TrendX screens are shown in the Figures 8 through 10.

Figure 8: Process Variable "Probe" Screen

ProbeX

Figure 9: Process Variable "ProbeA" Screen

ProbeA

Figure 10: Process Variable "TRENDX" Screen

TrendX

Real-Time Computing Facilities

Tsentry provides all computing facilities necessary to develop, deploy and support real-time applications with program repetition rates as fast as 1 millisecond. This includes the associated HMI displays implemented as standard web pages. These facilities are summarized in the following sections. Additional detail is provided in the on-line Tsentry documentation at http://www.tsentry.com.

Table-Driven System Startup And Shutdown Facilities

The NtRtMgr process performs system management in the Tsentry system. It is executed on system startup and passed the name of the system initialization file. This file defines system parameters and options such as the system name and GUI options. It also defines path names for other configuration files used by NtRtMgr to start the system. These configuration files consist of the following:

  • Process initialization file - Contains the following parameters for each process to be started:
    • Application name of the process.
    • Name of the binary executable file for the process.
    • A flag indicating if the process uses the Tsentry process management library.
    • The process priority.
    • Initial delay (milliseconds) before first execution.
    • The process timer interval in milliseconds.
    • The process run mode (standard Win32 or RTSS real-time).
    • A flag indicating whether the process is to be automatically restarted if it terminates.
    • A flag indicating whether the process is to be locked in memory.
    • Flags specifying how process exceptions should be handled.
    • The process debug level.
    • Delay time (milliseconds) before starting the process.
    • Delay time (milliseconds) to wait before proceeding to the next process in the list.
    • Delay time (milliseconds) to wait for deactivation before forcing the process to terminate.
    • The process stall timeout limit (milliseconds).
    • The command tail passed to the process.
  • Data dictionary definition file - Contains the definition of global shared memory.
  • Data dictionary variable initialization file - Defines the global common structure and global shared variable attributes: minimum value, maximum value, initial value, text description, and whether the value is saved to disk on shutdown and restored on startup.
  • LogMsg initialization file - Initializes the message logging subsystem.

The NtRtMgr process performs the following functions based on the contents of the system configuration files:

  • Allocates a global shared memory region for the data dictionary.
  • Copies the data dictionary definition from file to memory.
  • Allocates global shared memory regions for the applications.
  • Initializes/restores the contents of global shared memory regions.
  • Starts and monitors all process tasks.
  • Displays the status of all system processes on the Tsentry console.
    • Active/Inactive status
    • Elapsed time in current status
    • Run mode (standard Win32 or RTSS real-time)
    • Priority
    • Process ID
    • Percent utilization of repetition interval
  • Displays the most recent contents of the message logging queue.
  • Starts/Resumes/Suspends/Stops/Configures processes via a console window.
  • Shuts the processes down when requested.
  • Saves the contents of global shared memory regions to disk on shutdown.
  • De-allocates global shared memory regions.

Data Dictionary Building And Management Functions

The GsmPifBld process builds the data dictionary file used by the NtRtMgr system management process to allocate global shared memory regions. It parses the C/C++ global common header files. These files are created as part of the application software to define variables and structures residing in global shared memory. It then generates the data dictionary definition file. This flat ASCII file contains the definition of global shared memory in the format required for NtRtMgr. Therefore, the global shared memory data dictionary is automatically built directly from the application code. This significantly simplifies the task of managing global shared memory.

The data dictionary definition file created by GsmPifBld contains the following information:

  • Global shared region names.
  • Names of variables and data structures in each global shared region.
  • Byte offsets of variables and structures within each global shared region.
  • Variable type, size, and array dimensions.

GsmPifBld supports simple and complex C/C++ data types:

  • integer
  • float
  • character strings
  • signed and unsigned modifiers
  • short and long modifiers
  • user defined structures

Data Dictionary Access To Process Variables

Access to variables in global shared memory is provided through calls to system functions in the Data Dictionary support library. These facilities provide system-wide access to global shared variables by their fully-qualified variable names; that is, the variable names as used in the C/C++ application programs. Data dictionary functions are provided to perform the following operations on global shared variables using their variable names:

  • Get/set the current value for a variable.
  • Get/set the minimum value for a variable.
  • Get/set the maximum value for a variable.
  • Get/set the initial value for a variable.
  • Get/set the text description for a variable.
  • Get/set the default format specification for a variable.
  • Get the data type for a variable.
  • Get the size of a variable.
  • Get the array dimensions of a variable.
  • Get the global shared region offset for a variable.

The Tsentry web-based HMI system includes components that also use data dictionary functions to access global variables by name. These components display text values and graphical objects that change size, shape, and color based on global common variable values referenced through the data dictionary.

Tsentry system facilities that initialize the contents of global shared regions, restore global data from disk files on system startup, and save global data to files on system shutdown also use the Data Dictionary support library.

The Data Dictionary is normally built as a standard part of the application build procedure.

Program Templates For Real-Time System Processes

The tpriNtRtAdmin application is used offline for creating empty real-time process shells based on standard templates. This task generation procedure results in the creation of three new files: a Visual Studio C++ project file (newtask.dsp or newtask.vcproj), a C++ source file (newtask.cpp), and a C++ header file (newtask.h). By default, all of these files are copied to a new directory with the same name as the new task.

The process source file contains the standard template for a Tsentry real-time process and can be compiled and executed immediately. The standard process template includes the following sections:

  • Process Initialization
  • Allocation of data dictionary references
  • Insertion of required global shared memory regions
  • Application-specific one-time code
  • Application-specific looping code
  • Delay until next timer expiration
  • Destroy allocated class objects
  • Exit process

Application-specific code is added to each of these sections of the template to complete process development.

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. A managed extensions task also generates a fourth source file mytaskAssemblyInfo.cpp, which provides information for the generated assembly.

Global Shared Region OPC Server

The GsmOpcSvr process is an OPC (OLE for Process Control) server for Tsentry global shared memory. It accepts requests for named variables in global shared memory from any OPC client on the TCP/IP network and returns the current value of the variable to the client. Then, as the value in global shared memory changes, the server pushes the new value out to the client. The server also allows clients to write the values of these variables back into global shared memory.

The OPC server provides network access to variables in global shared memory and is the basis for the Tsentry HMI system.

The TPRI.OpcMgr object is an OPC client responsible for automating all active variables on a Tsentry Visual Basic HMI display. On initialization it searches for any objects on the screen that access global shared variables on the Tsentry host. It then requests updates for these variables by name from the host. Then, as these variables are updated by the OPC server on the host, the OpcMgr object passes these updates back to each of the requesting screen objects.

Application Software Environment

In the Tsentry environment, standard Windows functionality remains intact. This includes the file system, networking facilities, and the standard Windows process scheduling system. The VenturCom RTX real-time extensions provide true deterministic process scheduling under Windows.

Standard Windows(Win32) Process Scheduling

A Windows process is an independently executing instance of an application/program. A thread is an independent execution path within a process. Each process has at least one thread, the primary thread, and may start other threads to handle additional functions. Each of these threads is scheduled for execution independently of the others.

The standard Windows operating system supports 32 priority levels for scheduling threads within a process. These Win32 priorities are numbered 0 (lowest) through 31 (highest). Whenever the dispatcher reschedules a processor, it finds the highest priority thread available and assigns the processor to execute that thread.

The 32 standard Windows priority levels are further divided into two groups or classes: 'Win32 Normal' and 'Win32 Real-Time'. Once a process is started as Normal (sometimes called the Dynamic or Variable-Priority) or Real-Time, all threads of that process have priorities reserved for the same type of process. The priority of a thread of a 'Win32 Normal' process ranges from priority level 0 through 15. The 'Win32 Real-Time' priority range includes priority levels 16 through 31. Thus, all threads within a 'Win32 Real-Time' process are scheduled for execution before any of the 'Win32 Normal' threads.

Each standard Win32 process is assigned a 'base priority' when it is started and each of its threads is assigned a current priority derived from the priority class of the process. The Windows operating system scheduler automatically adjusts the priorities of threads within the 'Win32 Normal' (or Variable-Priority) class in order to optimize system response time. CPU bound threads tend to have their priorities reduced while threads ending a wait (for a resource, time interval, etc.) have their priorities raised.

In general, Win32 real-time processes have priority over most other activities and system events. However, for processes in the spectrum of dynamic classes at lower priority levels, a number of system events, such as I/O completion, can cause temporary priority changes for a thread.

The Windows scheduler is a pre-emptive scheduler, meaning that it attempts to execute the thread with the highest priority at any instant in time. As a result, a Win32 thread can be forced to relinquish the CPU by the operating system if a higher priority thread requires the processor.

Real-Time Windows (RTSS) Process Scheduling

With the installation and use of the VenturCom RTX real-time extensions, an RTSS environment is added to the standard Win32 environment. An RTSS thread is a unit of execution in this RTSS environment. A ready-to-run RTSS thread is scheduled before all standard Windows Win32 threads. Unlike a Win32 thread, which may be forced to relinquish the CPU by the operating system, a RTSS thread runs until it gives up the CPU itself. A thread gives up the CPU when it:

  • waits for a synchronization object,
  • lowers its own priority or raises the priority of another thread,
  • suspends itself,
  • returns from the timer or interrupt handler routines (applicable to timer and interrupt threads), or
  • calls function 'Sleep' with an argument of 0.

RTSS threads run at one of 128 distinct "hard real-time" priority levels and compete for CPU time using only that priority. Threads execute in priority order and in "first in, first out" order within any single priority level. 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.

All processing in the RTSS environment takes priority over all processing in the Win32 environment. The relationship between the standard Windows(Win32) and RTSS priority structures is summarized in the following diagram:

Figure 11: Windows Process Priority Structure

Windows Process Priority Structure

Tsentry Application Environment

With VenturCom RTX real-time extensions to the standard Windows operating system, the Tsentry application environment has the following features:

  • Standard Windows system operation remains intact.
  • Provides a simple library of real-time extensions for standard Windows.
  • Permits three basic process types:
    • Standard Microsoft Windows processes (Win32 Normal)
      • Priority levels 0 through 15.
      • Priority can be altered by the operating system to optimize system response time.
    • Standard Microsoft Windows real-time processes (Win32 Real-Time)
      • Priority levels 16 through 31.
      • Generally have priority over most system events.
      • Can be forced to relinquish CPU before completing.
      • Best for lower-speed process repetition rates (100 milliseconds and up).
    • Hard VenturCom RTX real-time processes (RTSS Real-Time)
      • Priority levels 0 through 128 scheduled before all standard Windows priorities.
      • Strictly priority based, not time-sliced.
      • Processes run to completion before relinquishing CPU.
      • True deterministic real-time process scheduling under Windows.
      • Best for high-speed process repetition rates (1 to 100 milliseconds)
  • All process types use the same library of application functions.
  • System and application software built using Visual C/C++ and Visual Basic .NET.
  • All software developed using Microsoft Visual Studio .NET tools.
  • All processes can be developed (code, edit, debug…) as standard Win32 processes on any PC with access to Microsoft Visual Studio .NET.
  • Any process can be changed from one type (Win32 Normal, Win32 Real-Time, or RTSS Real-Time) to another with a simple re-build.
  • C++ classes are supplied to support many process control functions.
  • Complete facilities for developing custom applications are available to the end user.
  • Additional real-time features:
    • Thread creation
    • Timers
    • Interrupts
    • Mutex objects
    • Semaphores
    • Events
    • Global shared memory areas

Tsentry System Libraries

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

  • Process Management
  • Global Shared Memory Management
  • Data Dictionary Services
  • Message Logging and Error Reporting
  • INI File Support Functions
  • Timer Support Functions
  • Utility Functions
  • Process I/O Device Drivers / Communications Services
  • Rules Processing Classes

These libraries are described in detail in the "Task Development Libraries" section of the on-line Tsentry documentation at http://www.tsentry.com.

Brief descriptions of the libraries follow:

Process Management Library

The Process Management Class contains functions for starting and stopping processes, connecting processes to resume timers, priority selection, etc.

Public member functions are provided to perform the following operations:

  • Attach a process to a Process Management Class object.
  • Detach a process from its Process Management Class object.
  • Initialize a process using default parameters read from the initialization file.
  • Suspend a process until one of the following events occur:
    • The next timer interval has expired.
    • Activation of the process is requested.
    • The process is resumed.
  • Activate another process.
  • Resume another process.
  • Suspend another process.
  • Deactivate another process.
  • Return the number of currently running processes.
  • Open a handle to allow for fast resumes of another process.
  • Close a resume handle.
  • Get the application name of a process.
  • Get the binary file name of a process.
  • Get the current percent utilization interval for a process.
  • Get the maximum percent utilization interval for a process.
  • Get the debug level for a process.
  • Get the process group identifier for a process.
  • Get the process ID for a process.
  • Get the auto-restart flag state for a process.
  • Get the repetition rate for a process (ms).
  • Get the run mode (Win32, RTSS) for a process.
  • Get the current state of a process.
  • Get the current state of the Tsentry process manager.
  • Get the start order for a process.
  • Get the amount of time a process has been in its current state (100 ns increments).
  • Get the amount of time a process has been in its current state (1 second increments).
  • Get a description of the specified state.
  • Get a description of the current state of a process.
  • Get the entire process definition for a process.
  • Get the display status string for a process.
  • Set the debug level for a process.
  • Set the auto-restart flag state for a process.
  • Set the current state of a process.
  • Set the display status string for a process.
  • Clear the error state for a process.
  • Return the current time (seconds since 1/1/1970 12:00 am UTC).
  • Return the current time (seconds and milliseconds since 1/1/1970 12:00 am UTC).
  • Return the current local time.
  • Set the watchdog flag for a process.

Global Shared Memory Management Library

The Global Shared Memory Management Class contains functions for mapping and accessing the contents of shared memory segments within a Tsentry process. For most situations, the data dictionary provides higher-level functions to manage the use of all global memory segments. For cases where more specialized functionality is required, direct access to functions in this class is provided.

Public member functions are provided to perform the following operations:

  • Create and/or map a shared memory segment.
  • Attach a shared segment to a shared memory management object.
  • Destroy a shared memory management object.
  • Get the virtual address of the shared memory segment at a given byte offset.
  • Get the current status of a shared memory segment.
  • Get the most recent error for a shared memory segment.
  • Get the name of a shared memory segment.
  • Map a shared memory segment into the current process under the specified name.
  • Zero an entire shared memory segment.
  • Write a binary copy of a shared memory segment to a disk file.
  • Read a binary copy of a shared memory segment from a disk file.

Global Shared Memory Data Dictionary Library

The Data Dictionary Class allows variables in global shared memory to be referenced by their string names.

Public member functions are provided to perform the following operations:

  • Start the data dictionary for a process.
  • Shut down the data dictionary for a process.
  • Parse the true variable name from an augmented name.
  • Return a pointer to a variable, and its size, type, and offset.
  • Return the size of a variable.
  • Return a VARIANT object containing the current value of a variable, and parameters for updating the variant.
  • Update a variant.
  • Write the value of a variant back to memory.
  • Get the data type for a variable.
  • Get the string description of the data type for a variable.
  • Get the GSM Mask bit mask for a variable.
  • Get the initial value for a variable.
  • Get the minimum value for a variable.
  • Get the maximum value for a variable.
  • Get the formatting string for a variable.
  • Get the description for a variable.
  • Get the initial value for a variable as a formatted string.
  • Get the minimum value for a variable as a formatted string.
  • Get the maximum value for a variable as a formatted string.
  • Set the initial value for a variable.
  • Set the minimum value for a variable.
  • Set the maximum value for a variable.
  • Set the formatting string for a variable.
  • Set the description for a variable.
  • Set the current value for a variable.
  • Get structure information for a variable.
  • Get the name of each item in the data dictionary.
  • Search the data dictionary for a string and return the name of the first variable containing the string.
  • Return a pointer to the Global Shared Memory Management object associated with a global shared memory name.
  • Map or create global shared memory region.
  • Attach an existing Global Shared Memory Management object into the data dictionary.
  • Map all global shared memory regions into a process.
  • Restore a global shared memory region from a disk file.
  • Restore a variable by name from a disk file.
  • Restore all variables in a file by name.
  • Restore variables listed in one file from a second data file.
  • Save a global shared memory region to a disk file.
  • Save a variable by name to a disk file.
  • Save all variables in a file by name.
  • Save variables listed in one file to a second data file.

Message Logging and Error Reporting Library

The Message Logging / Error Reporting Class provides a mechanism for processes to post text messages to global queues for later processing or asynchronous display. The available logging queues are defined at system startup time through a setup file. The system provides a default queue named "LogMsg" to which any process may post messages. Messages sent to the default queue are also displayed on the Tsentry system console. While only a finite number of messages are kept in memory, Tsentry automatically writes messages posted to the logging queues to disk files.

Public member functions are provided to perform the following operations:

  • Post a message to a queue if the message level is less than the debug level for a process.
  • Return the index of the last logged message in a queue.
  • Get a message from a queue
  • Log the contents of a memory area in hex and ASCII formats.

INI File Support Library

The INI File Support Class provides basic functions for working with .ini files. These include opening a file, finding a section in a file (denoted "[SectionName]"), retrieving lines from a file, and closing a file when finished.

Public member functions are provided to perform the following operations:

  • Find a section (denoted "[SectionName]") within a file.
  • Get the count of lines in a section.
  • Get the next valid line from a file.
  • Get the value associated with a specified key within a section.
  • Get the value associated with a specified key within a section and translate any environment variables in the value.
  • Set the value associated with a section/key in a file.
  • Write a line to a file.
  • Clean all lines of data from a section.
  • Delete an entire section from a file.
  • Delete the specified key from a section.
  • Delete a line from a file.
  • Commit any changes back to disk.
  • Get error/return status for an operation.
  • Return a pointer to a file buffer.
  • Get the size of a file in bytes.
  • Get a string from a line.

Timer Support Functions Library

The Timer Support Class provides basic timer functions. These functions can be called by any application process to set and test timers. The timer values are allocated and maintained in user-defined variables and are tested by user calls.

Public member functions are provided to perform the following operations:

  • Set a timer to expire in a specified number of microseconds.
  • Set a timer to expire in a specified number of milliseconds.
  • Set a timer to expire in a specified number of seconds.
  • Test the current status of a timer.

Utility Functions Library

The Utility Functions Class provides basic support and utility functions. These functions may be called by Win32 and/or RTSS application processes.

Public member functions are provided to perform the following operations:

  • Drive the output LEDs of a test module connected to the system parallel port.
  • Transform a string by translating any system environment variable strings it contains.
  • Delete all files in a directory older than a specified time.

Process I/O And Communications Driver Libraries

Process I/O Device Driver Classes are available to enable the Tsentry system to communicate with several common devices. Both Win32 and RTSS versions of most of the drivers are available.

Supported drivers include the following:

  • National Instruments Process I/O Controllers
  • RTP (formerly CPI) Process I/O
  • VMIC Reflective Memory Driver
  • Allen Bradley PLC 2, PLC 3, and PLC 5
  • Allen-Bradley ControlLogix PLC
  • GE 9030 / 9070 PLC
  • Modicon (Schneider Automation) TSX Quantum PLC
  • Generic TCP/IP Communications Driver
  • Lantronix Terminal Server
  • Generalized Remote Device Connection Driver

Additional detail regarding the Process I/O Driver Classes is provided in the on-line Tsentry documentation at http://www.tsentry.com.

Rules Processing Libraries

The Rules Processing System provides a process engineer with an easy way to implement automated decision making on a process control system without requiring the engineer to write C/C++ code. It allows the engineer to create a set of Operational Rules that are applied to the control system. An Operational Rule is the combination of a set of criteria with a set of actions to be performed when those criteria are met. For instance, an Operational Rule may specify that the resistance target of a given smelting pot should be altered when that pot reaches a specific age.

The Operational Rules System consists of a supervisory process that manages each of the operational rules, tests the criteria to determine if the rule is satisfied, and takes appropriate actions. A single control system may have any number of rules defined, each of which is independently evaluated by the rules manager process. In addition, the Rules Processing System provides a user interface to allow the engineer to create, modify, load and view the status of Operational Rules on the control system.