Web     This Site

 | Home | My Account | Post Article | Upload Showcase | Download | Site Shortcuts | Feedback | Partner | About us | My Tokens |

  Home > Consulting > Level 2 Model >

Roll Design
Auto Form
Free Form
Mill Load
Flow stress
Hi-T Data
General Data
Mill Diagnosis


Classified Listing
Product Profile
R&D/Tech Profile


- Metallurgy & Materials
- Metal Working
- IT & Automation
- Industry Review
- Metal Patents
- Research
- Metal Directory
- R&D Roadmaps
- Steel Mills


Mill Level 2 Model Improvements Project Series                        

Three Level 2 systems were developed for Cascade Steel Rolling Mills LLC, a steel minimill in the West Coast of USA. They include EAF Level 2, LMF Level 2, and Caster Level 2. The systems are Windows-based Level 2 packages, developed with C/C++ as implementation language, Oracle as database server, and VB for interface language. Several aspects, especially programming for the Windows-based Level 2 systems, were extracted here for discussion, as outlined below.

Three Level 2

Level 2 General Functionality

Level 2 collects PLC data (with PLCSrv), Chemistry data (with Chemlab from chemical lab) and operation data (such as delay, from MMI with DataSrv), etc. All the data are saved in the MMFs (Memory-Mapped-Files). The DataSrv reads data from MMFs and sends them to MMIs, while DBLog gets data from the MMFs and stores them in the Database server (like Oracle DB).

Scheduling, Steelmaking recipes, chemical analysis, personnel, event, part life as well as energy and material consumptions are also the key functions and are implemented in various sub-systems, such as the Data Server, Heat Tracking and Chem Lab.

Figure 1:  Level 2 General Functionality

As one of the key sub-systems, the Data Server application manages all the communication to and from the HMIs, the communication form Lab the communication to and from others level 2 servers, including mirroring in DB, user actions, etc. It is a network communication program that implements a server socket using a connection-oriented service over TCP/IP.

There is a model screen for each of the application of EAF and LMF. The models predict parameters based on existing input data of the current heat and the experience of the past heat.


Here the EAF DBLog is taken as example of the sub-systems. The DBLog application is used to implement one-way communication from L2 to DB, like inserting, updating or even deleting records. The purpose of this application is to keep the logical separation of the L2 system from the DB, so that the Level 2 can still run smoothly even when the database is down or the connection between Level 2 and database is broken.

As illustrated in Figure 2, DBLog performs all the inserts, updates and deletes made from the L2. Each Level 2 application that may need to perform any of these operations builds a request object and inserts it in a shared queue object, and then sends a message to DBLog, which takes this request and tries to perform it. In case the database is down, the network connection to the DB server is broken or any error in the request at SQL level, DBLog inserts a line in each related log files. Then removes the request from the queue and continues with the next requests, until all of them are performed.

Figure 2:  Functionality of Level 2 DBLog, with relationship with others

In the Figure 2, the Msg1 is a message used to communicate with L2Monitor and other Level 2 applications, while Msg2 handles DB related requests. Two shared memory areas are assigned to store requests from other applications (queue1) and DB related requests (queue2). Two Dynamically Linked Libraries, DLL1 and DLL2, are used to communicate with MMFs and Database, respectively.

The connection to the DB is implemented using either ODBC or ADO technology. In this writing the ODBC technology was chosen because of the speed and reliance of its connections, plus its easy configurations.

DBLog represents the link between Level 2 and DB, so all the tables that may be affected by the Level 2 are really accessed with DBLog.

DBLog does not directly affect any of the HMI screens.

EAFDBLog Implementation

Here again, the DBLog is taken as example for the system implementation.

Three classes are involved:

- L2DBLog: Initialize the MFC Windows project and call the DBLogDlg class object
- L2DBLogDlg: Contain most of the Level 2 specific functions, some being used in implementation of others. It also include some necessary Windows programming functions.
- L2DBLogCmd: DLL class used to assemble SQL commands. The key function in this class is FormQuery(), to be called by the DBLogDlg member functions to query the Oracle database table.

In general, functions in the three classes perform three major types of functionality:

- Windows programming: VC++ project setup (e.g., InitInstance(), OnPaint(), OnReqLive()), Version control (e.g., LoadVersion()), MFC messaging (e.g., MngMsg(),OnInitDialog()), etc.
- Error trapping and recording: LogMsg(), OutString(), ODBCErrorEx(), OpenConnection(), etc.
- Connection to DB, run SQL commands, and write to log: GetDescription(), LoadConfigFile(), Execute(), ExecuteCmd(), OnDBReq(), OnDBReql(), SendRequestToFile(), FormQuery(), etc.


Figure 3: Classes in the DBLog Module and their functionality

Details of the classes are shown in Figure 4.

Figure 4: Class L2DBLog, L2DBLogDlg and L2DBLogCmd

The class L2DBLog is mainly used to initialize the application. The major functionalities are implemented in the class L2DBLogDlg.

The function FormQuery(), the major member function of the dll class L2DBLogCmd, is called by the DBLogDlg member functions to query the Oracle database table.

Classes and global data structures in the Caster Level 2

Here is an example on the Caster Level 2 class structure and data handling. All classes are associated with a set of kernel classes (the included classes in the figure below), which were implemented  separately,  by derivation of composition, etc. Those kernel classes take a set of global data structure as their properties. Each of the global data structure hold a set of data. Some structures also hold substructures. This is a very efficient way to manage data and classes.

Figure 5: Classes and global data structures in the Caster Level 2

VB Screens in the Level 2

The Human-Machine-Interface (HMI) screens and related client-side applications were developed with Visual Basic. Over fifty screens exist for the Level 2 package. Some screens, such as the summary screens for EAF, LMF, Caster and Meltshop overview,  are used in more than one sub-package (EAF Level 2, LMF Level 2, Caster Level 2, etc.). Figure 6 below is the LMF Summary screen.

Figure 6: LMF Summary screen

Besides the HMI applications, there is a separate program that is also written in VB. It's a parameter editor used by a Level 2 administrator to edit Level 2 database parameters. For example, the name of the operators and shift leader, the chemical analysis of each grade, and recipe definition, etc, can be pre-entered into the Level 2 flat file database for Level 2. For example, as long as a grade name is assigned in the schedule, the chemical analysis specification (Aim, Min, Max value for every element, as showed in the above screen) is displayed automatically in the Level 2.

Back to the Project List Page


    Recent Update
Metal Pass recent papers
- Metal Pass mill-related projects
- Mill Level 2 project series
 Metal Pass tech supplies
Consulting - Ask a question
- More ...
    Roll Pass

 Design: AutoForm

 Mill Load

 Design: FreeForm

    Flow Stress Models
Fe-alloy Hot F2 F2F3 A B C
Cold F2 F2F3a - - -
Non-Fe Hot F2 - A B C
Cold F2 F2F3a - - -
   Mill Projects     Ranks
   Publication     Biz Tools
   Submission     Domains
    Project Series
Mill model improvem. projects
Mill related modeling projects
Metal Pass recent publications

| Private Policy | Terms & Conditions | About Us | AdvertisePartnerInvestorSponsorlistings |  

Copyright: 2009 Metal Pass LLC. All rights reserved