GENMOD3

Bailey Controls to MODBUS Protocol Device Interface
Table Of Contents
1.0 INTRODUCTION ............................................................................................................................. 1 1.1 SYSTEM DESCRIPTION ...................................................................................................................1 1.2 SYSTEM OVERVIEW........................................................................................................................2 1.3 DOCUMENTATION TERMINOLOGY .................................................................................................3 2.0 HARDWARE ..................................................................................................................................... 4 2.1 HARDWARE DESCRIPTION .............................................................................................................4 2.2 TERMINATION UNIT LAYOUTS ......................................................................................................4 2.2.1 NIMF01 LAYOUT .........................................................................................................................4 2.2.2 NIMP01 LAYOUT .........................................................................................................................6 2.2.3 NTMP01 LAYOUT ........................................................................................................................7 2.2.4 NTMF01 LAYOUT.........................................................................................................................8 2.3 TERMINATION UNIT CONFIGURATIONS .........................................................................................9 2.3.1 NIMF01 DCE CONFIGURATION ....................................................................................................9 2.3.2 NIMF01 DTE CONFIGURATION ..................................................................................................10 2.3.3 NTMF01 DCE CONFIGURATION .................................................................................................20 2.3.4 NTMF01 DTE CONFIGURATION..................................................................................................21 2.4 MODULE DIPSWITCH SETTINGS....................................................................................................22 2.4.1 MULTI-FUNCTION CONTROLLER DIPSWITCH SETUP.....................................................................22 2.4.2 MULTI-FUNCTION PROCESSOR 1/2 DIPSWITCH ............................................................................23 2.4.3 MULTI-FUNCTION PROCESSOR 03 DIPSWITCH SETUP...................................................................25 2.5 COMMUNICATION PARAMETERS ........................................................................................... 27
2.6 FOREIGN DEVICE EQUIPMENT SETUP.................................................................................. 27
2.7 HARDWARE ................................................................................................................................... 28 2.7.1 MFC03 HARDWARE CHECKLIST ..............................................................................................28 2.7.2 MFP01/02 HARDWARE CHECKLIST ..........................................................................................29 2.7.3 MFP03 HARDWARE CHECKLIST ...............................................................................................29 3.0 SOFTWARE .................................................................................................................................... 32
1
3.1 GENERIC INTERFACE DESCRIPTION ..............................................................................................32 3.1.1 GENERIC FILES LIST..................................................................................................................35 3.1.2 STANDARD DATA FILE FORMAT ................................................................................................36 3.1.3 GENERIC BLOCKWARE..............................................................................................................37 3.2 MODBUS PROTOCOL SPECIFIC C PROGRAM DESCRIPTION.......................................... 41 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 CONCEPT OVERVIEW.................................................................................................................41 DATA POINT CAPACITY.............................................................................................................41 MPD COMMANDS SUPPORTED..................................................................................................42 MODULE -DRIVER MEMORY REQUIREMENTS ...........................................................................49 SPECIFIC DATABASE /DATA FILE FORMAT ...............................................................................49 QUALITY AND DEVICE STATUS REPORTING..............................................................................59 BACKUP COMMUNICATIONS PORT SWAP DESCRIPTION...........................................................62
3.3 FILES LIST...................................................................................................................................... 64
3.4 OPERATION.................................................................................................................................... 64 3.4.1 SETUP ......................................................................................................................................... 64 3.4.2 STARTUP ....................................................................................................................................64 3.4.3 MONITORING EXECUTION .........................................................................................................65 3.4.3.1 BLOCKWARE ..........................................................................................................................65 3.4.3.2 DATA REPORT FILES...............................................................................................................66 3.4.4 ERROR CODES /DESCRIPTIONS...................................................................................................68 3.5 SOFTWARE CHECKLIST............................................................................................................. 72
4.0 DATABASE...................................................................................................................................... 73
5.0 REVISION ....................................................................................................................................... 74
9.0 KWIKEDIT DATA FILE EDITOR............................................................................................... 83 9.1 INTRODUCTION.............................................................................................................................83 9.2 BEFORE PROCEEDING...................................................................................................................83
9.3 OPERATING THE KWIK EDITOR............................................................................................. 84
10.0 MULTI-FUNCTION CONTROLLER/PROCESSOR UTILITIES .......................................... 87 10.1 INTRODUCTION..........................................................................................................................87 10.2 BEFORE PROCEEDING.................................................................................................................87 10.3 USING THE MULTI-FUNCTION UTILITIES....................................................................................88
1.0 Introduction
This document describes the design, installation and operation of the Generic Modbus Protocol digital interface package. The interface establishes a data link between Bailey's control network and any Modbus Protocol Device. This document is intended to provide information about the operation of the designated interface package. It is not intended to support any modifications or enhancements of this package.
1.1 System Description

This package is used to communicate data between Bailey's Multi-function Controller/Processor, (MFC/MFP), and a Modbus Protocol Device (MPD), over an RS-232 or RS-485 (2 and 4 wire) serial data link. The interface package is composed of a C language 'driver' program, Bailey Controls function codes and a standard format data point file. The C interface program handles the conversion of data according to Modbus protocol (necessary for communication and data exchange between the MFC/MFP and the MPD) for control and/or display use in the Bailey network. The data consists of analog and/or digital points. Data obtained from the MPD by the MFC/MFP module is processed, and stored in function blocks by the interface program. Likewise, data may be retrieved from function code blocks and transmitted to the MPD. Function blocks are software control algorithms that can be used to perform specific tasks such as input, output, or an operation on an input or output. The standard format data point file contains information about each data point exchanged on the communication link.
1.2 System Overview
Bailey Infi 90
Bailey Controls Cabinet

Bailey Module
MODBUS Protocol
TU
Device Serial Data Cable

COMM Module
1.3 Documentation Terminology

Interfaces: 1) 2) 3) 4) Hardware: 1) 2) 3) 4) 5) 6) 7) 8) 9) 10) 11) 12) 13) 14) 15) Software: 1) 2) 3) 4) 5) CADEWS - Computer Aided Drawing Engineering Workstation CUP - C Utility Program TXTEWS - Text Engineering Workstation DFM - Data File Manager MFUTILS - Multi-Function Utilities CIU - Computer Interface Unit CTM - Configuration and Tuning Module EWS - Engineering Workstation LIS - Loop Interface Slave MCS - Management Command System MFC - Multi-Function Controller Module MFP - Multi-Function Processor Module MMU - Module Mounting Unit NIMF0x/NIMP0x - MFC/MFP High Density Termination Unit NKTU01 - Cable Connecting MFC/MFP to Termination Unit NTMF0x/NTMP0x - MFC/MFP Low Density Termination Unit OIS - Operator Interface Station PCU - Process Control Unit SBM - Superloop Bus Module SPM - Serial Port Module NET90 - Bailey NETWORK 90 INFI90 - Bailey's INFI 90 control system; the successor to the NETWORK 90 system. MPD - Modbus Protocol Device. COMMUNICATION MODULE - Refers to the protocol specific communication module.
2.0 Hardware
2.1 Hardware Description
The interface package establishes a data link between the Bailey module and the MPD through RS-232 or RS-485 data line(s). The link is terminated at the Bailey end with a Termination Unit (TU). The TU is cabled to the CPU board of the MFC/MFP module which executes all of the interface program code and communicates with the Bailey control network. The following figure displays the connectors available with Bailey termination units. If the cabling is redundant, both TU ports (labeled TERMINAL (port 0) and PRINTER (port 1)) are connected to the appropriate MPD's communication module ports. If one cable is adequate, the terminal port can be connected to a dumb terminal for display of diagnostic messages. Refer to the configuration sheet at the front of this document for the specific hardware for this application, then refer to section 2.2 for layout diagrams of the termination units, section 2.3 for configuration diagrams of the termination units, and section 2.4 for diagrams of the MFC and MFP dipswitch settings. Table 2.1 - Termination Unit Port Connection Types
Terminatin Unit Type NTMF01 NTMP01 NIMF01 NIMP01 Serial Transmission Type RS-232 RS-232 RS-485 RS-232 RS-232 RS-485 2 2 1 2 2 1 Number and Type of Port Connection DB-25 Female DB-25 Female DB-9 Female DB-25 Female DB-9 Female DB-9 Female
2.2 Termination Unit Layouts 2.2.1 NIMF01 Layout

The termination unit provides access to the serial communication ports. The termination unit used on this project has the following features: Two DB-25 Female connectors used for connection to the foreign device. The foreign device may be either DCE (Data Communication Equipment) or DTE (Data Terminal Equipment). Dipshunts XU1 & XU2 configure the signals for the terminal port and dipshunts XU3 & XU4 configure the printer port.
4
Figure 2.2.1 - NIMF01/02 Overview
2.2.2 NIMP01 Layout

The termination unit provides access to the serial communication ports. The termination unit used on this project has the following features: Three DB-9 Female connectors (2 RS-232 and 1 RS-485) used for connection to the foreign device. The foreign device may be either DCE (Data Communication Equipment) or DTE (Data Terminal Equipment). Jumpers 2, 4, 5, 6 & 7 configure the signals for the terminal port and jumpers 1, 3, 8, 9 & 10 configure the printer port.
Figure 2.2.2 - NIMP01/02 Overview
2.2.3 NTMP01 Layout

The termination unit provides access to the serial communication ports. The termination unit used on this project has the following features: Two DB-25 Female connectors (RS-232) and 1 DB-9 Female connector (RS-485) used for connection to the foreign device. The foreign device may be either DCE (Data Communication Equipment) or DTE (Data Terminal Equipment). Jumpers 2, 4, 5, 6 & 7 configure the signals for the terminal port and jumpers 1, 3, 8, 9 & 10 configure the printer port.
Figure 2.2.3 - NTMP01 Overview
2.2.4 NTMF01 Layout

The termination unit provides access to the serial communication ports. The termination unit used on this project has the following features: Two DB-25 Female connectors used for connection to the foreign device. The foreign device may be either DCE (Data Communication Equipment) or DTE (Data Terminal Equipment). Dipshunts XU1 & XU2 configure the signals for the terminal port and dipshunts XU3 & XU4 configure the printer port.
Figure 2.2.4 - NTMF01 Overview
2.3 Termination Unit Configurations 2.3.1 NIMF01 DCE Configuration

A set of dipshunts are supplied on the termination unit. They configure the signals coming through each port on the serial data cable to a format the MFC program expects. It is important that the correct cuts are made on each termination unit before the data link will function. This configuration is performed once at installation and should never have to be repeated.
Figure 2.3.1 - NIMF01 DCE Dipshunt Cuts
2.3.2 NIMF01 DTE Configuration

A set of dipshunts are supplied on the termination unit. They configure the signals coming through each port on the serial data cable to a format the MFC program expects. It is important that the correct cuts are made on each termination unit before the data link will function. This configuration is performed once at installation and should never have to be repeated.
Figure 2.3.2 - NIMF01 DTE Dipshunt Cuts
10
2.3.3.1 New NIMP01 DCE configuration

A set of jumpers are supplied on the termination unit. They configure the signals coming through each port on the serial data cable to a format the MFP program expects. It is important that the correct settings are made on each termination unit before the data link will function. This configuration is performed once at installation and should never have to be repeated.
Figure 2.3.3.1 - New NIMP01 DCE Jumper Settings
11
Figure 2.3.3.2 - Old NIMP01 DCE Jumper Settings
12
2.3.4.1 New NIMP01 DTE configuration

Figure 2.3.4.1 - New NIMP01 DTE Jumper Settings
13
2.3.4.2 Old NIMP01 DTE configuration

Figure 2.3.4.2 - Old NIMP01 DTE Jumper Settings
14
2.3.5.1 New NTMP01 DCE Configuration

Figure 2.3.5.1 - New NTMP01 DCE Jumper Settings
15
2.3.5.2 Old NTMP01 DCE Configuration

16
Figure 2.3.5.2 - Old NTMP01 DCE Jumper Settings
2.3.6.1 New NTMP01 DTE Configuration

17
Figure 2.3.6.1 - New NTMP01 DTE Jumper Settings
18
2.3.6.2 Old NTMP01 DTE Configuration

Figure 2.3.6.2 - Old NTMP01 DTE Jumper Settings
19
2.3.3 NTMF01 DCE Configuration

A set of dipshunts are supplied on the termination unit. They configure the signals coming through each port on the RS-232C cable to a format the MFC program expects. It is important that the correct cuts are made on each termination unit before the data link will function. This configuration is performed once at installation and should never have to be repeated (see figure 2.3).
Figure 2.3.7 - NTMF01 DCE Dipshunt Cuts
20
2.3.4 NTMF01 DTE Configuration

A set of dipshunts are supplied on the termination unit. They configure the signals coming through each port on the RS-232C cable to a format the MFC program expects. It is important that the correct cuts are made on each termination unit before the data link will function. This configuration is performed once at installation and should never have to be repeated (see figure 2.3).
Figure 2.3.8 - NTMF01 DTE Dipshunt Cuts
21
2.4 Module Dipswitch Settings 2.4.1 Multi-Function Controller Dipswitch Setup

The MFC is supplied with three dip switches; U72, U73, and U75 on the CPU board. Dipswitch settings are vital for correct interface operation. Dipswitch U72 determines in which mode the MFC will run. Dipswitch U73 determines the baud rate of both the TERMINAL (switches 1-4) and PRINTER (switches 5-8) ports located on the Termination Unit. Dipswitch U75 sets the module address (switch 1 has a binary weight of 16). NOTE: If the MFC setup is redundant, the secondary MFC must have the same settings as the primary MFC, except for switch 8 on dip switch U72, which must be in the open position. CAUTION: Because of the extreme importance these dipswitches have in the correct operation of the interface, DOUBLE CHECK their setting before plugging the MFC into the cabinet.
Figure 2.4.1 depicts an MFC03 with an address of 5 and baud rates of 9600 for both the terminal and printer ports. Please consult the configuration sheet at the front of this manual for the appropriate dipswitch settings for this application.
Figure 2.4.1 - Example MFC03 Dip Switch Setting for Module Address 5 with Baud Rates of 9600.
22
2.4.2 Multi-Function Processor 1/2 Dipswitch

The MFP01/02 modules have two configurable dipswitches and four jumpers. Each dipswitch has eight poles. The leftmost dipswitch, switch SW3, sets the module address on the controlway. The rightmost dipswitch, switch SW4, sets the module options and special operations which include redundancy. The four jumpers are for special MFP01/02 hardware applications. There are several switches that are not currently in use. All switches marked NOT USED must be kept in the closed (0) position. The MFP may not operate properly if these switches are set in the open (1) position. The four jumpers are located near the back of the MFP board by the P3 edge connector. They allow certain signals to be routed to the termination unit. They are factory set and it is vital that these jumper settings REMAIN INTACT AND MUST NOT BE CHANGED. NOTE: If the MFP setup is redundant, the secondary MFP must have the same dipshunt and jumper settings except for switch 8 on dipswitch SW2, which must be in the open position. CAUTION: Because of the extreme importance these dipswitches have in the correct operation of the interface, DOUBLE CHECK their setting before plugging the MFP into the cabinet.
Figure 2.4.2, on the next page, shows the proper dipswitch and jumper settings for an MFP01/02 with an address of 5. Please consult the configuration sheet located at the front of the manual for the appropriate dipswitch setting for this application.
23
Figure 2.4.2 - Example MFP01/MFP02 Dipswitch Setting for Module Address 5

24
2.4.3 Multi-Function Processor 03 Dipswitch Setup

The MFP03 module has four configurable dipswitches and five jumpers. Each dipswitch has eight poles. The leftmost dipswitch, switch UUB0, sets the module address on the controlway. The second dipswitch from the left, switch UMB1, sets the module options and special operations including redundancy. The jumpers are for special MFP hardware applications. There are several switches that are not currently in use. All switches marked NOT USED must be kept in the closed (0) position. The MFP may not operate properly if these switches are set in the open (1) position. The jumpers J1-J4 are located near the back of the MFP board by the P3 edge connector. They allow certain signals to be routed to the termination unit. They are factory set and it is vital that these jumper settings REMAIN INTACT AND MUST NOT BE CHANGED. Jumper J5 can enable the module to operate in a MMU that uses -30 VDC. NOTE: If the MFP setup is redundant, the secondary MFP must have the same dipshunt and jumper settings except for switch 8 on dipswitch UMB1, which must be in the open position. There is also a redundancy cable (NKMP03) that connects the two IMMFP03 modules. CAUTION: Because of the extreme importance these dipswitches have in the correct operation of the interface, DOUBLE CHECK their setting before plugging the MFP into the cabinet.
The MFP03 provides only data and control signals for serial I/O. The necessary circuitry for the serial ports is provided to the MFP03 by use of an auxiliary I/O card that attaches to the MFP. The Multi-Function Processor Interface (MPI01) gives the MFP access to the TU. Control and data signals from the MFP03 travel through a 60-pin ribbon cable to the MPI01. The MPI01 requires an additional card slot. Figure 2.4.3, on the next page, shows the proper dipswitch settings for an MFP03 with an address of 5. Please consult the configuration sheet located at the front of the manual for the appropriate dipswitch setting for this application.
25
Figure 2.4.3 - Example MFP03 Dipswitch Setting for Module Address 5.
26
2.5 Communication Parameters

Communication parameters define the format of the packet that passes each byte of data between the Bailey Net90 and the MPD. Please consult the configuration sheet located at the front of the manual for the parameters required for this particular application. Table 2.5 Communication Parameters
Parameter Baud Rate Stop Bit(s) Data Bit(s) Parity Handshaking Enable/Disable Break Detection Disable Xxxxx Xx Xx Xx Off Value
2.6 Foreign Device Equipment setup

The serial data cable(s) running from the Bailey termination unit(s) is/are terminated at the MPDs communication adapter modules serial port. See the MPD communication module's manual for the specific location of this port.
27
2.7 Hardware
2.7.1 MFC03 Hardware Checklist
The following constitutes the hardware checklist for the MFC03: Table 2.7.1 MFC03 Hardware Checklist
[] [] MFC03 contains the latest revision of firmware MFC03 U72 Switch - Options. Switches 1-8 closed. If redundant MFC03 pair: Primary switches 1-8 closed. switch 8 open. [] MFC03 U73 Switch - TERMINAL and PRINTER port baud rates. See figure 2.4 for proper dipswitch settings. Switches 1-4 determine the TERMINAL port baud rate and Switches 5-8 determine the PRINTER port baud rate. If redundant ports are specified, both ports must have same settings. Likewise if redundant MFC03s are specified both modules must have the same settings. [] MFC03 U75 Switch - Module Address. See figure 2.4 for proper dipswitch settings. Switch 1 is the MSB and has a binary value of 16. If redundant MFC03s are specified, both must have the same settings. [] MFC03 plugged in with green LED steady (at the top of the module) and red LEDs 7 & 8 lit (Execute Mode). If redundant MFC03s are specified, the Primary module will have the green LED steady and LEDs 7 & 8 lit while the secondary module will have the green LED and LED 8 lit (MFC03 has copied the primary configuration and is ready). Termination unit cable plugged in on back of MFC03 on one end and the termination unit on the other end. The termination unit has appropriate power, good fuse and the green LED is lit. Dipshunts are cut per the supplied drawings found in section 2.4. If redundant MFC03s are specified, insure that the expander bus dipshunts are installed and that Spec 3 in the extended executive function code 90 is set to the value '1' in both MFC03s. RS-232 Cable connection from the termination unit to the MPD communication module is correct. If displaying diagnostic messages during MFC03 operation on a PC or terminal, connect a 25 pin straight-through cable from PC/terminal to the termination unit TERMINAL port (port 0). Cabinet and system have been properly grounded 28 Secondary - switches 1-7 closed.
[] [] [] [] [] [] []
[]
Cabinet power supply is adequate and good.
2.7.2 MFP01/02 Hardware Checklist

The following constitutes the hardware checklist for the MFP: Table 2.7.2 MFP01/02 Hardware Checklist
[] [] MFP contains the latest revision of firmware. MFP Switch SW1 (Module Address). Switches 1 and 2 are in the close position. Switch 3 set open selecting Module Bus Switch 3 set close selecting Controlway Switches 4-8 reflect the module address in binary (switch 4 has binary value of 16). MFP Switch SW2 (Module Options and Diagnostics). if non-redundant MFP: Set switches 1-8 in the closed position. if redundant MFP pair: Primary MFP, set poles 1 - 8 in the closed position. Secondary MFP, set poles 1 - 7 in the closed position and pole 8 in the open position. For switch SW2 special operation settings: Refer to section 3 of the Bailey Controls Multi-Function Processor Module instruction manual located in section 7.0 of this document. If redundant MFP pair, insure that the expander bus dipshunts are installed and that Spec 3 in the extended executive function code 90 is set to the value '1' in both MFPs Cabinet and system have been properly grounded. Cabinet power supply is good. MFP plugged in and green LED on steady (top of module) and red LEDs 7 & 8 lit (MFP is in execute mode). If redundant MFP pair, the above applies to primary module. The secondary module will have the green LED on steady, and only LED 8 lit red (MFP has copied the primary configuration and is ready). Termination unit cable is plugged in on the back of the MFP on one end and the TU on the other. The termination unit has appropriate power, good fuse and the green LED is lit. If displaying diagnostic messages during MFP execution on a PC or terminal, connect a 25 pin straight-through cable from PC/terminal to the termination unit port 0. Appropriate cable connected from TU printer port 1 to foreign device. Verify cable against drawings If using RS-485 port, verify that the RS-485 select jumper is set correctly. Also note that displaying of diagnostic messages with a dumb terminal is disabled when using RS-485.
[]
[] [] [] []
[] [] [] [] []
2.7.3 MFP03 Hardware Checklist

The following constitutes the hardware checklist for the MFP03:
29
Table 2.7.3 MFP03 Hardware Checklist

MFP contains the latest revision of firmware. MFP Switch UUB0 (Module Address). Switches 1 and 2 are in the close position. Switch 3 set open selecting Module Bus Switch 3 set close selecting Controlway Switches 4-8 reflect the module address in binary (switch 4 has binary value of 16). MFP Switch UMB1 (Module Options and Diagnostics). if non-redundant MFP: Set switches 1-8 in the closed position. if redundant MFP pair: Primary MFP, set poles 1 - 8 in the closed position. Secondary MFP, set poles 1 - 7 in the closed position and pole 8 in the open position. For switch UMB1 special operation settings: Refer to section 3 of the Bailey Controls Multi-Function Processor Module instruction manual located in section 7.0 of this document. If redundant MFP pair, insure that the expander bus dipshunts are installed and that Spec 3 in the extended executive function code 90 is set to the value '1' in both MFPs. Also verify that the NKMP03 cable is connected to the back of both MFPs. Cabinet and system have been properly grounded. Cabinet power supply is good. MFP plugged in and green LED on steady (top of module) and red LEDs 7 & 8 lit (MFP is in execute mode). If redundant MFP pair, the above applies to primary module. The secondary module has the green LED on steady, and only LED 8 lit red (MFP has copied the primary configuration and is ready). MPI01 plugged into the slot immediately to the left of MFP03. Both MFP03s of a redundant setup require an individual MPI01 Special 60-pin cable is plugged into the MFP, threaded through the slot on the MFP, and plugged into the MPI. Termination unit cable is plugged in on the back of the MPI on one end and the TU on the other. The termination unit has appropriate power, good fuse and the green LED is lit. If displaying diagnostic messages during MFP execution on a PC or terminal, connect a 25 pin straight-through cable from PC/terminal to the termination unit port 0. Appropriate cable connected from TU printer port 1 to foreign device. Verify cable against drawings If using RS-485 port, verify that the RS-485 select jumper is set correctly. Also note that displaying of diagnostic messages with a dumb terminal is disabled when using RS-485. 30
31
3.0 Software
3.1 Generic Interface description
A general protocol driver is a C language program which is used to 'drive' data over a serial data link to various devices which conform to a common communication protocol. Protocol drivers are capable of reading standard format data point files, ('.dta's), and converting the file information into a series of message packets. These packets transfer the information between the foreign device and the Bailey Control System. Generic driver programs operate in one of two modes; initialize or communicate. The initialize mode runs first. It begins by checking for the existence of files "101", "102" and "103" in the modules battery backed memory. These files store a message list, a lookup table, and a device table which are described later. If they do not exist, it parses through the data point information contained in file "100" (the standard format data point file). The program will actually make two passes through this file. The first pass counts the total number of points in the file, the number of analog points, the number of digital points, the number of messages required to pass all of the data points, and optionally other measures which size up the memory requirements of the data file. In the second pass, dynamic memory regions are allocated and initialized to hold a message list, a look-up table and a device table. The message list region stores all of the information needed for every message required to transfer all data points in the data list. Typically, entries include the time interval between retransmitting a message, the foreign device node, the range of addresses in the foreign device, a checksum or crc value (for messages that read from the foreign device) and an offset into the look-up table. The look-up table contains a record of information for each point in the interface including: the local block number, scale factor and offset value for each point in the data list. However, there is no scale factor or offset value for digital points. The device table contains information such as the device address and the local block number of a function block which holds the device status value. This information is used to report quality on a device basis to a diagnostics terminal or to function blocks. It is also used to avoid sending unnecessary messages to devices that are offline.
32
Next, file "100" is reduced to a length of zero (0) bytes to maximize the amount of available file space. Then, the contents of the three dynamic memory regions are written to three separate data files in the module. The message list is written to file number "101". The look-up table is written to file number "102". The device table is written to file number "103". This is done for three reasons. First, if only one module is present, subsequent restarts of the module can use the three files and avoid the lengthy file "100" parsing operation. If and when modifications are necessary to be made to the database, file 100 will need to be reloaded into the MFP/MFC, and files 101, 102, and 103 will have to be deleted. This signals the computer to repeat the parsing operation. The second reason is that the three file are automatically checkpointed (copied) to the backup module if the interface uses redundant modules. If the primary module fails, the backup module only has to read the files into two memory regions and then it is immediately ready to begin communicating. This avoids the time required to make two passes at the data point file ("100") and, therefore, minimizes the 'bump' in throughput between when the primary module fails and the backup module begins communicating. The third and final reason for the three files is simply to provide a mechanism by which the users of the generic driver are informed as to how the driver broke up the data point list into separate messages and what each message is to do. The user can use CUP to upload the module files "101", "102" and "103" into DOS files "101.dta", '102.dta' and '103.dta', respectively. Then, a driver-specific reporting program can be run which will translate these three files into ASCII reports which can be displayed and printed. In this case, the three report files are named 'msg.rpt', 'tbl.rpt' and 'device.rpt'. After the data point file is parsed and the three report files are created, the driver program completes the initialization routine. This includes waiting for the startup flag to expire (defaults to fifteen seconds), determining the portopen mode parameter from various function blocks on the standard first CADEWS sheet and opening one or both ports (based on port redundancy selection). At this point, the program initialization is complete. Finally, the generic driver goes into the communicate mode. This mode varies from protocol to protocol, but typically includes calls to a scheduler function to determine what messages are due to run, a call to a message builder, and a call to a transceiver function to transmit the message and collect the response. If peer-to-peer or slave node protocol is supported, the communicate mode might also contain calls to an inque checking routine and reference to a pending messages queue. In all cases, a comprehensive group of information and error messages may be sent to an optional diagnostic terminal. The message scheduler, when turned on, will process messages in given intervals (1/100s of a second) to regulate control and give priority to some messages. For example, a message with all points having a DL_TIME value (the database name for a time interval) of 100, will be run every second. Along with message scheduling, the scheduler insures that blockware is run within the time it is specified, assuming that the module is not overloaded. If the message scheduler is turned off, every message in the interface is processed each time the C Program is executed. As of version 5.0, a technique called exception writing can be used when transferring data from
33
the Bailey network to a foreign device. This technique involves checking the value of each data point and sending to the foreign device only those points which have changed in value since the last cycle of the interface program. This greatly speeds up the rate of data transfer when only infrequent changes are occurring in the values of the configured points. If frequent change of many of the point values is anticipated, this technique should not be used. The selection of this technique is done on a point-by-point basis during configuration of the point list. This is explained in detail later in this document. As of version 5.2, a technique called exception bouting is used when transferring data from the foreign device to the Bailey network. This technique, like exception writes, only sends data to the Bailey network when a change of value is detected. A considerable increase in data point throughput results for some point types. This feature is enabled whenever the device mode status is DEV_GOOD. Whenever the device mode status is not equal to DEV_GOOD, exception bouting is disabled. As of version 6.41, a port access delay timer was added to force a minimum delay between a response and transmission of the next request message.
34
3.1.1 Generic Files List

The following list summarizes the files necessary to implement a generic interface driver package. Note that the word 'driver' refers to the particular protocol driver name (e.g. 'ab', 'modbus', 'gemk', etc.). The word 'projname' refers to the filename that was initially assigned to the project dBase file, and is normally based on the loop, PCU, and module number of the MFC/MFP. driver.lms driver.csp driver.map projname.cfg The MFC/MFP load module file. This is the compiled and linked driver program file. The C specification file for the above driver program. This file is supplied with each driver. The C map file for the above driver program. This file is supplied with each driver. The function code logic configuration file. This file is produced by the CADEWS compiler from the CAD sheets generated manually by CADEWS. The module header file. This file is produced manually before CADEWS is run. The standard format data link point list file. This file contains information on each point in the data point list. It is created/modified manually by KWIKEDIT.
projname.mhd projname.dta -
The following files hold the data files and report files obtained from the standard format data point file (100), after the generic driver has parsed it. 101.dta 102.dta Contains a copy of the message list developed by the generic driver program. The data in this file is stored in a binary (non-readable) format. Contains a copy of the lookup table developed by the generic driver program. The data in this file is also stored in a binary (non-readable) format. Contains a copy of the device table developed by the generic driver program. The data in this file is also stored in a binary (non-readable) format. This file is produced from the 101.dta file using the driver specific dump routine mentioned on the next page. It contains a structured report of the lookup table information in ASCII (human-readable) format.
35
103.dta -
msg.rpt -
tbl.rpt -
This file is produced from the 102.dta file using the driver specific dump routine mentioned on the next page. It contains a structured report of the lookup table information in ASCII (human-readable) format. This file is produced from the 103.dta file using the driver specific dump routine mentioned on the next page. It contains a structured report of the device table information in ASCII (human-readable) format.
dev.rpt -
Along with all of the program and data files, the following executable program files should be available to load, monitor and report on the generic driver module. txtews.exe The Text Engineering Work Station program. This program is used to load the .cfg file containing the function code logic and the .nbs file containing the c program and data files. The Configuration/Loader System (CLS) program from Bailey Canada. This program is similar to TXTEWS. If TXTEWS is available this program is not needed. The Quick Editor. This program can be used on the PC to create/edit the '.dta' file containing the data point information.
config.exe -
kwikedit.exe -
driver_dump.exe - The protocol specific Dump program. This program is used to 'dump' the data files '101.dta', '102.dta' and '103.dta' into ASCII text files 'msg.rpt', 'tbl.rpt' and 'dev.rpt' for user reference. cup.exe The C Utility Program. This optional program is used to format the MFC/MFP module, load the driver program, and load the standard format data point file.
3.1.2 Standard Data File Format

NOTE: The following is a detailed layout for the data point file. It is not necessary to know this information to configure the data point file. It is presented for information only. There is specific information which must be entered for each data point in the interface. The information must be entered into a file with the format given in Table 3.1.2. This information can be modified/created by using the program 'kwikedit.exe'.
36
Table 3.1.2 Bit Map of Data File

Field Name Version Descriptor Length 1 byte 1 byte Size Description Bailey file format version #. Only appears once as first byte in the file. Descriptor length byte. Only appears once as second byte in the file. Bits 6 and 7 of 1st byte Bits 1 through 5 of 1st byte Bit 0 (zero) of 1st byte Bytes 2 and 3 (Unsigned Short) Byte 4 (Unsigned Char) Bytes 5 and 6 (Unsigned Short) DL_SUB_LOC DL_LOC_BLK DL_SCALE DL_OFFSET SPECIAL_2 DL_TIME DESCRIPTOR 3 bytes 2 bytes 4 bytes 4 bytes 1 byte 2 bytes 0-28 bytes Bytes 7 and 8 (Unsigned Short) Byte 9 (Unsigned Char) Bytes 10 and 11 (Unsigned Short) Bytes 12 through 15 (IEEE Real4 Format) Bytes 16 through 19 (IEEE Real4 Format) Byte 20 (Unsigned Char) Bytes 21 and 22 (Signed Short) If the Descriptor Length byte is zero, this field is not used. Otherwise this field may use up to 28 bytes of ASCII Characters starting with byte 23.
The following fields are repeated for each record of the data. DL_STORAGE SPECIAL_1 DL_DIRECT DL_DEV_ADR DL_LOC 2 bits 5 bits 1 bit 2 bytes 3 bytes
3.1.3 Generic Blockware

The first standard CADEWS sheet contains information used for all generic protocol drivers. The following is a listing of the blocks used on the first standard CADEWS sheet and a description of what they do. Refer to Section 6 of this manual to view the hard copy of the first sheet. Block #15 - Previous Scan Time displays the time (in milliseconds) required to execute the C code and the function code logic. This time will vary widely based on the protocol, the number of data points, the number of messages, and the 'time in C' parameter of the message scheduler. However, it is a useful value when calculating message throughput. Block #16 - Current Scan Time displays the time (in milliseconds) spent so far in the current module scan. This value is very useful for detecting when the program has become caught in an infinite loop. In that case, this value would simply continue incrementing beyond the normal scan
37
time. Block #20 - RS-485 2 Wire Switch enables RS-485 2 wire communications when spec 3 is set to 1000. Note: jumper pins 1 and 2 on J18 of the termination unit. Block #3001 - Diagnostic On/Off Switch holds a binary switch which determines whether or not (in non-redundant port mode) diagnostic messages will be sent to the terminal port and optional dumb terminal. When not using serial ports in a redundant setup, it is advisable to turn the diagnostic message block on for testing. Once valid operation is determined the diagnostics should be turned off. Block #3002 - Delay Between Diags holds the approximate amount of time (in milliseconds) delayed after each diagnostic message is printed out. This value is used to slow down the display of diagnostic messages to a more human readable rate. Block #3003 - Module Type defines how the program opens the printer/terminal ports on the TU. This block is used to specify what type of module is being used. 0 is defined for MFC03's, 1 is defined for MFP01/02's Block #3004 - Time In C holds the approximate amount of time (in milliseconds) that the program spends in the C program for each module scan. This value can be increased to allow more messages per scan to be transmitted, or decreased to allow the function blocks to run more often. For best efficiency, it should be tuned so that the actual scan time (block 15) just exceeds the target scan time shown in spec 2 of block 15. Block #3005 - Schedule Speed allows the user to select one of two possible scheduler operating modes. 'Scheduled speed' means that normal scheduler operation will occur where messages due to run will be sent until the 'Time In C' value is exceeded and then function blocks will be run. 'Fast as possible' means that all of the messages in the message list will be run once and then function blocks will be run. This second selection provides the greatest throughput. Block #3006 - Redundant Comm Ports determines whether or not the driver program will attempt to use the modules other serial port as a data link port upon failure of the primary (printer) port and vice versa. When selected, this option disables the diagnostic port feature. Block #3007 - Test Mode allows the C program to avoid timesynching with the loop. This binary switch is normally used for testing purposes. Block #3008 - Stalled Writes Block determines how the driver program will perform writing of data to the Modbus device. If the value of this block is zero, no write messages will be performed. If the value in this block is negative, the value in this block will be read into the driver program and converted to a positive value which represents the number of SECONDS that the module will be in SYNCHING mode. SYNCHING mode is the state when only READ messages (->DCS) are sent to the Modbus device. This occurs during module startup, whenever communications are
38
disrupted and on a failover case if redundant modules are used. Write messages will take place if all messages were good while the module was in SYNCHING mode for the designated time period. If the value of block 3008 is a positive number, the driver program interprets this number as the block number of a BOOLEAN signal which acts as a write permissive signal. When the state of this signal is a 1, the driver program will permit write messages to be sent to the Modbus device. This signal is checked during each cycle of the module, thus it is possible for writes to be disabled or enabled on the fly based on the state of the write permissive signal. If the block number indicated by block 3008 is invalid (either incorrect or doesn't exist in the configuration), then write messages will not be sent to the Modbus device. Block #3009 - Quality Permissive Block this block lets the user decide whether or not quality should be passed to blockware along with the value for each point. When permitted, quality is determined by the driver program based on foreign device status and message status. Enter a zero (0) to force quality to good all the time or a one (1) to have the driver determine quality. Block #3010 - Timeout Period is the number of milliseconds that the interface will wait before retrying a message or reporting a timeout of a retried message. If the number in this block is <= 0, a default value of 1.5 seconds will be used. This block is only accessed during a startup of the interface. Block #3011 - Baud Rate. This block holds the baud rate for the data link. This value applies to MFP modules only; baud rate is specified using dipswitches on MFC03 modules. Enter the actual baud rate: valid values are 19200, 9600, 4800, 2400, 2000, 1800, 1200, 600, 300, 150, 134.5, 110 & 75. Typically, 19200 baud and 9600 baud are used. Block #3012 - ^S & ^Q. This block determines whether or not Control-S/Control-Q (XON/XOFF) support is present for the data link. This option (sometimes called "software handshaking") is necessary for some protocols to avoid overflowing the communications buffers in the driver program. Set the block to zero (0) to disable support (this is the typical setting for most GDI programs). Set the block to one (1) to enable support. Block #3013 - RTS & CTS. This block determines whether or not the Request To Send (RTS) or Clear To Send (CTS) lines of the serial port are active or held on. This option (sometimes called "hardware handshaking") is necessary for some protocols to avoid overflowing the communications buffer in the driver program. Set the block to zero (0) to hold these signals ON (the normal state for GDI programs). Set the block to one (1) to enable dynamic assertion of these signals. This values applies to MFP modules only. Block #3014 - Break Detect. This block determines whether or not a "Break" will be detected on the data link. None of the GDI programs requires this support. It should be set to "no" by setting the block to zero (0). Block #3015 - # Stop Bits. This block holds the number of stop bits selected for the data link. This value specifies the number of bits used to end a single byte transmission in a serial data link. It is project/data link dependent. Enter zero (0) for one (1) stop bit or one (1) for two (2) stop bits.
39
Block #3016 - Parity. This block holds the parity "sense" selected for the data link. Parity is a byte-wise error checking technique. It is project/data link dependent. Valid entries are 0 for even, 1 for odd, 2 for low (space), 3 for high (mark) and 4 for none. Block #3017 - Data Bits. This block holds the number of data bits selected for the data link. This value specifies the number of bits of information contained in each byte which is transmitted over a serial data link. It is project/data link dependent. Set the block to zero (0) for 7 data bits or one (1) for 8 data bits. Most GDI interfaces will use 8 data bits. Block #3018 - Port Type. This block determines how the port will be opened for communications. A zero (0) means RS-232. A one (1) means RS-485 4 wire communication. A two (2) means RS-485 2 wire communication. Block #3019 - Port Delay. This block determines the delay (ms) between a response and the next transmission of a request. This applies to all RS232/RS-485 2 and 4 wire communications. Block #3020 - Backup Port Checks. This block determines the time (seconds) between backup port checks. If redundant ports is selected and this block contains a positive value, the driver program will transmit loopback messages out of the backup port for the time specified. Blocks #1019 thru #1022 - The Error Historian blocks display the current error code (0 if none) and the last three error codes, respectively. See section 3.4.4, Error Codes/Descriptions, for the meaning of each error code. Block #1023 - Communication Trouble Block flags any errors occurring with the interface/communication. If there are no errors indicated in the "current status" block (block #1022), the value of this block is 0. If an error is indicated in the "current status" block, the value of this block is set to 1 until the error historian is cleared. Blocks #3022 & #3023 - Inque / Outque Length blocks display the number of characters currently in the input queue and output queue, respectively. This is useful for determining if the driver program is keeping up with or overrunning the foreign device. Block #3024 - Driver Software Revision displays the current revision number of the driver program. Blocks #3025 & #3026 - Foreign Device Status displays the foreign device status and extended status, respectively, where appropriate. Block #3027 - Current Message Number displays the number of the communication message currently being transmitted or received, depending on the protocol driver. Block #3070 - Backup Port Status Block. Can only be used in RS-232 mode with diagnostic messages turned off (Block 3001 = 0, Block 3018 = 0). This block can trigger a switch-over to the second comm port for communications with the MPD. Setting the block value to one (1) will force the active communications port from port 0 (Printer) to port 1 (Terminal).
40
Block #3091 - Redundant Startup Flag. This block indicates whether or not a redundant startup is occurring. The first time that a redundant digital interface is started, this block will hold the default value of zero (0). Soon after program startup, it will be bout'd to a one (1). From then on, it will hold a one (1) throughout all redundant startups until both modules are again "cold" started. This information, coupled with the value of the Current Port Number (block #3092; see below), lets the driver program know which port to startup on after a primary module has failed. In this way, the foreign device does not encounter an unnecessary port swap just because a redundant Bailey module failover occurs. This block only applies when both redundant modules and redundant ports are selected. Block #3092 - Current Port Number displays the current port number being used (0 for terminal port and 1 for printer port). Block #3093 - Backup Port Status displays the status of the backup port status. If the redundant communication ports block (3006) is selected (1) and the Backup Port check block (3020) is enabled (positive value) current port number being used (0 for terminal port and 1 for printer port). Block #xxxx - Invoke C Program. This block calls the C language driver program to begin executing. It is not numbered initially because its number may need to change based on what other functions are performed in function codes. However, in most cases it is given a number above the highest number used on the first sheet (often block #3999 is used). It is good practice to place blocks bin'd into the driver before the 3000 block range of the first sheet and place blocks bout'd out of the driver after the 3999 block. This allows data to move between Bailey and the foreign device in both directions in a single module scan.
3.2 Modbus Protocol Specific C Program Description

3.2.1 Concept Overview
The Modbus Protocol Driver program was designed and written for maximum functionality between a Bailey MFC/MFP module and any Modbus Protocol Device. The program allows communication to Modbus Protocol Devices through a sorted list of messages and a data table created from a standard format data point file. The program was written to keep things as simple as possible. All the read and write information for the MPD are contained in a single data file, (100.dta). This data point file can be easily modified, which makes changes to the interface very simple. However, any changes in the data point file may require modification to the function code logic portion of the module configuration. Therefore, changes should be thought out completely before being implemented.
3.2.2 Data Point Capacity

The Modbus Protocol Driver program has certain data point size limitations that must be kept in mind when modifying the standard data point file (100) and the associated blockware for the '.cfg' file. These limitations are based on the amount of battery backed memory (NVM) and the amount
41
of RAM available in the different types of modules.
3.2.3 MPD Commands Supported

The following is a list of the commands supported by the Modbus Protocol Driver Program. The Modbus Protocol read functions consist of an eight byte message and at least a six byte response. The Modbus Protocol write functions consist of at least an eight byte message and an eight byte response. A response of five bytes will be sent if an error has occurred. The Modbus Protocol 'C' program supports eight function codes: Table 3.2.3.1 Function Code Descriptions
Function Code 1 2 3 4 5 6 8 15 16 Read Coil Status Read Input Status Read Holding Registers Read Input Register Force Single Coil Force Single Register Loopback Diagnostic Test Force Multiple Coils Force Multiple Registers Description
These function codes are briefly reviewed on the following pages. Consult the Gould Modicon Modbus Protocol Reference Guide located in section 8.0 of this document for a more detailed explanation of these functions. Note: Codes 5 and 6 are used for exception writes(16-bit integer values only). . Function Code 1 - Read Coil Status Read Coil Status - Obtain the current status, (ON/OFF), of a group of logical coils. Message: Module Address FUNC 01 Data Star Point HO Byte Response: (Message ok)
42
Number of Coils HO Byte LO Byte
CRC Error Check LO Byte HO Byte
LO Byte
Module Address FUNC 01 8 Coils Data Coil Status Bytes 8 Coils 8 Coils CRC Error Check LO Byte HO Byte
NOTE: The bytes in the message are displayed in a hexadecimal format. Each Data Coil Status Byte contains the status for 8 coils. The number of Data Coil Status Bytes in the response is dependant on the number of points in the query, (query total/8 rounded up to the next whole number). Ex: The number of bytes required for 34 coils is 5 (34/8 = 4.25, round up to 5). Function Code 2 - Read Input Status Read Input Status - Obtain the current status, (ON/OFF), of a group of discrete inputs. Message:
Module Address FUNC 02 Data Star Point HO Byte LO Byte Number of Coils HO Byte LO Byte CRC Error Check LO Byte HO Byte
Response: (Message ok)

Module Address FUNC 02 Byte Count 8 Inputs Data Discrete Input Bytes 8 Inputs 8 Inputs 8 Inputs CRC Error Check LO Byte HO Byte
NOTE: The bytes in the message are displayed in a hexadecimal format. Each Data Discrete Input Byte contains the status for 8 discrete inputs. The number of Data Discrete Input Bytes in the response is dependant on the number of points in the query, (query total/8 rounded up to the next whole number). Ex: The number of bytes required for 34 coils is 5 (34/8 = 4.25, round up to 5).
43
Function Code 3 - Read Output Register Read Output Register - Obtain the current binary value in one or more holding registers. Message:
Module Address FUNC 03 Starting Register HO Byte LO Byte Number of Registers HO Byte LO Byte CRC Error Check LO Byte HO Byte

Module Address FUNC 03 Byte Count HO Byte Output Register Bytes LO Byte HO Byte LO Byte CRC Error Check LO Byte HO Byte
NOTE: The bytes in the message are displayed in a hexadecimal format. Each Output Register contains two bytes, (1 HO, 1 LO). The number of Output Register Bytes in the response is dependant on the number of points in the query, (query total*2 or 4 depending upon point type). Function Code 4 - Read Input Register Read Input Register - Obtain the current binary value in one or more input registers. Message:
Module Address FUNC 04 Starting Register HO Byte LO Byte Number of Registers HO Byte LO Byte CRC Error Check LO Byte HO Byte

Module Address FUNC 04 Byte Count HO Byte LO Byte HO Byte LO Byte Input Register Bytes CRC Error Check LO Byte HO Byte
NOTE: The bytes in the message are displayed in a hexadecimal format. Each Input Register contains two bytes, (1 HO, 1 LO). The number of Input Register Bytes in the response is
44
dependant on the number of points in the query, (query total*2). Function Code 5 - Force Single Coil Force Single Coil - Force a single logic coil to define ON/OFF state. Message:
Module Address FUNC 05 HO Address LO HO Data On/Off LO CRC Error Check LO HO

Module Address FUNC 05 HO Address LO HO Data On/Off LO CRC Error Check LO Byte HO Byte
NOTE: The bytes in the message are displayed in a hexadecimal format: 0xFF00 = ON, 0x0000 = OFF. Function Code 6 - Force Single Register Force Single Register - Place specific binary value into a holding register. Message:
Module Address FUNC 06 HO Address LO HO Data Byte LO CRC Error Check LO Byte HO Byte
45

Module Address FUNC 06 HO Address LO HO Data Byte LO CRC Error Check LO Byte HO Byte
NOTE: The bytes in the message are displayed in a hexadecimal format. Function Code 8 - Loopback Diagnostic Test Loopback Diagnostic Test - A Diagnostic Code and Data of zero (0) is used to test the communication system. The controller responds with the query data. Message:
Module Address FUNC 08 Data Diag Code HO LO HO Data LO CRC Error Check LO Byte HO Byte

Module Address FUNC 08 Data Diag Code HO LO HO Data LO CRC Error Check LO Byte HO Byte
NOTE: The bytes in the message are displayed in a hexadecimal format.
46
Function Code 15 - Force Multiple Coils Force Multiple Coils - Force a series of consecutive logic coils to define ON or OFF states. Message:
MOD ADR 0F HO LO HO LO FUNC ADDRESS QUANTITY BYTE COUNT HO LO DATA COIL STATUS BYTES HO LO CRC ERROR CHECK LO Byte HO Byte
Response: (Message ok) Module Address FUNC 0F HO Byte Address LO Byte HO Byte Quantity LO Byte CRC Error Check LO Byte HO Byte
NOTE: The bytes in the message are displayed in a hexadecimal format. Each Data Coil Status Byte contains eight coils/bytes. The number of Data Coil Status Bytes in the message is dependant on the number of points in the query. Function Code 16 - Force Multiple Registers Force Multiple Registers - Place specific binary values into a series of consecutive holding registers. Message:
Mod Adr Func 10 Address HO LO Quantity HO LO Byte Count HO LO Data Bytes HO LO LO Byte CRC Error Check HO Byte

Module Address FUNC 10 HO Byte Address LO Byte HO Byte Quantity LO Byte CRC Error Check LO Byte HO Byte
NOTE: The bytes in the message are displayed in a hexadecimal format. Error Response - All Function Codes
47
A five byte response will be sent back from the MPD if a correct message was not received. Response: (Message ok)
MODULE ADDRESS FUNCTION CODE NUMBER LO Byte HO Byte EXCEPTION CODES CRC ERROR CHECK
The function code field will contain the original function code with the high order bit set. The exception code field will contain one of the exception response codes displayed in the following table. Table 3.2.3.2 Exception Response Codes
Code 01 Name Illegal Function Meaning The message function received is not Function an allowable action for addressed slave. If a poll command was issued, this indicates no program function preceded it. The address referenced in the data field is not an allowable address for the addressed slave location. The value referenced in the data field is not allowable in the addressed slave location. The slave's PC has failed to respond to a message or an abortive error occurred. (See Note).
02 03 04
Illegal Data Address Illegal Data Value Failure in Associated Device
NOTE: An EXCPT Code 4 may indicate that only part of the associated query was processed before an unrecoverable error occurred within the responder station. Receipt of EXCPT Code 4 requires immediate supervisory notification.
48
3.2.4 Module-Driver Memory Requirements

This page lists the memory map format of the '.csp' file used by CUP. MFP01 Memory Format Spec's. Total Ram Alloc'd to C (bytes): Total NVM Alloc'd to C (bytes): Maximum Number of Data Files: C User Ram Spec's. Max Size of C's Idata (bytes): Max Size of C's Udata (bytes): Min Size of Dyn_Mem_Pool (bytes): Max Size of C's Code_Sect (bytes): Number of Checkpoint Buffers: Size of Checkpoint Buffers (bytes): Number of MBF Buffers: Size of MBF Buffers (bytes): Memory Totals. Amount of Ram Req'd (bytes): Amount of NVM Required (bytes): Memory Summary. Total RAM Available (bytes): RAM Formatted for C (bytes): RAM Required by C (bytes): Unused RAM (bytes): Total NVM Available (bytes): NVM Formatted for C (bytes): NVM Required by C (bytes): NVM for Data Files (bytes): 155,648 93,000 92,748 252 59,354 39,152 31,650 7,502 339,968 100,000 92,748 7,252 191,450 96,912 31,650 65,262 1,564,608 100,000 92,748 7,252 420,828 96,912 31,650 65,262 92,748 31,650 92,748 31,650 92,748 31,650 6,000 4,400 2,000 25,000 1 1,024 1 1,024 25,000 1 1,024 1 1,024 1 1,024 6,000 4,400 20,000 6,000 4,400 40,000 25,000 1 1,024 93,000 39,152 5 100,000 96,912 5 100,000 96,912 5 MFP02 MFP03/MFP05(BRC)
3.2.5 Specific Database/Data File Format

Table 3.2.5 lists the generic point database file fields along with a description of each field. A database listing conforming to this structure containing specific information for this project can be found in section 4.0 of this document. The database file has also been supplied on disk from Bailey. Refer to the configuration sheet at the front of this manual for the name and location of this file. It is recommended that any data point changes/additions made in the 100.dta file should
49
also be made in the database file for a record of the changes/additions. NOTE: The fields used in the 100.dta file are highlighted for the Modbus protocol drivers.
50
Table 3.2.5 Database Fields

Field Name TAGNAME DESCRIPTOR EUDESC EUINDEX DL_STORAGE DL_DIRECT DL_DEV_ADR DL_LOC DL_SUB_LOC DL_LOC_BLK RING PCU MADR BLKN DL_SCALE DL_OFFSET VAL0 SPAN SIGCHG HALARM LALARM ALMST_IND BIN_MODE REV_LEVEL TEMPLATE SPECIAL_1 SPECIAL_2 DL_TIME Description Interface point tag name I/O text descriptor Engineering Units Engineering Units Index Type of data point Data flow direction Foreign device node addr Location in foreign device Sub-location Local block number X-report ring number X-report pcu number X-report module number X-report block number Scale factor Offset value Low point of data range Span of data range Significant change (% span) Analog alarm high limit Analog alarm lo limit Digital alarm status Pulse/maintain mode Point revision level For Future Use Write type Analog data type Message time interval char char char numeric char char char char char numeric numeric numeric numeric numeric numeric numeric numeric numeric numeric numeric numeric numeric char char numeric char numeric numeric Type Size 14 30 8 3 8 8 5 10 10 4 3 3 2 4 9 9 11 11 11 11 11 1 1 4 2 1 3 6 Dec 0 0 0 0 0 0 2 4 3 3 5 3 3 0 0 0 0
51
The following is a detailed explanation of each field. The highlighted fields are those that can be edited with the use of the kwikedit program. TAGNAME An alpha-numeric name used to reference the data point. A brief description of the data point's use in terms of the process the point is involved in. The engineering units of the data point. For example: Gals, Lbs, Rpm, kW. The Bailey console engineering unit descriptors' index number, (see MCS/OIS instruction manuals). This value is used in spec 2 of AO/L function codes. Valid entries range from 0 - 255. The storage type of the data point in terms of the foreign device. Enter 'A' for analog storage type. Enter 'D' for digital storage type. Enter 'SA' for '>DCS' direction digital points stored in analog registers within the MPD. This last storage type is referred to as a 'transitional' type. The direction that the point flows over the data link. Enter '->DCS' for data moving from the foreign device to the Bailey system. Enter 'DCS->' for data moving from the Bailey system to the foreign device. The node number of a message destination on the foreign device's network. Enter a value in the range 000 through 247. This field is not used unless your Modbus address is in the extended six digit addressing range of 000001 through 465535 (excluding 200000 through 300000). If the address is in the extended addressing range, then this field contains the prefix byte, and upper/lower bytes. The prefix byte must contain the character A to indicate extended register range (more than 10000). The high/low bytes contain the sixth digit of the register number. For example, the extended register address numbered 300201 is represented as follows: High Low Prefix Byte Byte A 0 3 The rest of the register address (00201) is placed in the DL_SUB_LOC field as described below. DL_SUB_LOC This field contains the register number for analog points, the coil number for digital points or register number and bit position for 'SA' type transitional points. (i.e. 0-65535 for analog and digital, and 0-65535:15 for 'SA' type transitionals). Note that all the values are entered in decimal. Valid addresses range from 000001 through 465535 (excluding 200000
52
DESCRIPTOR EUDESC EUINDEX -
DL_STORAGE -
DL_DIRECT -
DL_DEV_ADR DL_LOC
through 300000). Valid bit positions range from 00 to 15. To continue the illustration for the extended register range of 300201 started above in DL_LOC, the remainder of the address (00201) is entered into the field as follows: High Low Bit Position Byte Byte 201 DL_LOC_BLK The local block number directly referenced by the interface program. For example, if the data flow direction is '->DCS', the local block would indicate where the point is bout'd to. If the data flow direction is 'DCS->', the local block would indicate where the point is bin'd from. Valid entries in the DCS-> direction range from 0 through 9998. Valid entries in the ->DCS direction range from 30 through 9998. The ring (or loop) number where the data point is exception reported. For example, if the data flow direction is 'DCS->', and the point is exception reported from another module, use the ring number of the other module. If the data flows in the opposite direction, reference the ring number from which it is exception reported onto the loop. If the point is not exception reported, leave this field blank. The process control unit, (PCU), number where the data point is exception reported. For example, if the data flow direction is 'DCS->', and the point is exception reported from another module, use the ring number of the other module. If the data flows in the opposite direction, reference the ring number form which it is exception reported onto the loop. If the point is not exception reported, leave this field blank. The module address, (MADR), number where the data point is exception reported. For example if the data flow direction is 'DCS->', and the point is exception reported from another module, use that modules address number. If the data flows in the opposite direction, reference the module number from which it is exception reported onto the loop. If the point is not exception reported leave this field blank. Valid entries range from 0 through 31. The block number, (BLKN), where the data point is exception reported. For example, if the data flow direction is 'DCS->', and the point is exception reported from another module, use that modules exception report block number. If the data flows in the opposite direction, reference the block number where it is exception reported. If the point is not exception reported, leave this field blank. Valid entries range form 30 through 9998. A scale factor, (slope), which is applied to raw data values to convert them to common engineering units (EU). The following equation is used:
53
RING
PCU
MADR
BLKN
DL_SCALE -
EU = (raw value / scale factor) + offset value Note: enter a value of one (1), if no scaling is required. DL_OFFSET An offset value, (intercept), which is applied to raw data values to convert them to common engineering units. See the above Equation. NOTE: enter a value of zero (0), if no offset is required. VAL0 The low end, (zero), of the valid range for an analog value. Required for analog exception reported points in the '->DCS' direction. This spec is used in spec 3 of AO/L function codes. The span, (range), of the valid range for an analog value, referenced from VAL0 above. Required for analog exception reported points in '->DCS' direction. This value is used in spec 4 of AO/L function codes. The amount of change (in % of span) in the value of an analog data point that is required to initiate an immediate exception reporting of the value. Required for analog exception reported points in '->DCS' direction. This value is used in spec 7 of AO/L function codes. An analog data point's high alarm limit, specified in engineering units. Required for analog exception reported points in '->DCS' direction. This value is used in spec 5 of AO/L function codes. An analog data point's low alarm limit, specified in engineering units. Required for analog exception reported points in '->DCS' direction. This value is used in spec 6 of AO/L function codes. ALMST_IND - A binary data point's alarm status as specified by the following table: 0 = alarm on zero. 1 = alarm on one. 2 = no alarm. Required for digital exception reported points in '->DCS' direction. Used in spec 2 of DO/L function codes. BIN_MODE REV_LEVEL Reserved for future use The revision level of each point in the database. For example, all values are initially set to 'A' or '1'. As new points are added or changes are made to existing points, their revision level is incremented to 'B' or '2', then 'C' or '3', and so on.
54
SPAN
SIGCHG
HALARM
LALARM
TEMPLATE SPECIAL_1
For Future Use. Exception Write Flag or Device Status Flag. An 'X' placed in this field for write points (DCS->) indicates the point will only be sent to the foreign device once after each transition using either function code 5 for digitals or 6 for analogs. Upon startup or loss of communications, the program will send all exception writes after synching with good read messages for 15 seconds. NOTE: Only 16 bit registers in the range of 0xxxx for Exception coil writes and 4xxxx for Exception holding register writes. For device status points enter an 'S'. This designation tells the driver program to use this points local block number to report the current state of each foreign device node being addressed. Specify 'A' (analog) for the point type (DL_STORAGE) and specify a legitimate but unused analog point address (DL_SUB_LOC) (typically 49999). After the data link comes "online", these blocks will display a number from 0 to 3 indicating the device status. The meaning of each status number is shown below: 0 - BAD: no communication at all 1 - UNKNOWN: not known what state device is in 2 - SYNCHING: can monitor; waiting to command 3 - GOOD: device is fully functional
SPECIAL_2
This field designates the data type of the register (dl_sub_loc) address in the foreign device. The following byte stream is used to define each of the possible storage types for a data value of 1. In the following examples, the text above the boxes represents the byte order that the MPD will send data to the MFC/MFP, from most significant byte (MSB) to least significant (LSB) byte. The text underneath the boxes represents the order that the MFC/MFP will interpret the data in bit order (from highest position to lowest position) of the data value, while the data within the boxes represents the actual data transmitted (data value = 1). Note: this field is dependent on data transmission order/data type to the MFC/MFP, NOT the internal data storage arrangement within the MPD. original byte transmission order:
2 byte short: msb byte1 00 lsb byte2 01 msb byte1 00
4 byte long: Lsb byte2 00 byte3 00 Byte4 01 msb byte1 3F
4 byte IEEE float: lsb byte2 80 byte3 00 byte4 00
16-9
8-1
32-25
24-17
16-9
8-1
32-25
24-17
16-9
8-1
point type 0 - Unsigned short (1 register, HO LO)

55
byte1 00
byte2 01
16-9
8-1
point type 1 - Signed short (1 register, HO LO)

byte1 00 byte2 01
16-9
8-1
point type 2 - Unsigned long (2 registers, HO LO)

byte1 00 byte2 00 byte3 00 byte4 01
32-25
24-17
16-9
8-1
point type 3 - Signed long (2 registers, HO LO)

32-25
24-17
16-9
8-1
point type 4 - IEEE float (2 registers, HO LO)

byte1 3F byte2 80 byte3 00 byte4 00
32-25
24-17
16-9
8-1
point type 5 - Unsigned long (2 registers, AEG Modicon)

16-9
8-1
32-25 24-17
point type 6 - Signed long (2 registers, AEG Modicon)

56
byte1 00
byte2 01
byte3 00
byte4 00
16-9
8-1
32-25 24-17
point type 7 - IEEE float (2 registers, LO HO)

byte1 00 byte2 00 byte3 80 byte4 3F
8-1
16-9
24-17 32-25
point type 8 - IEEE float (2 registers, word swap)

byte1 00 byte2 00 byte3 3F byte4 80
16-9
8-1
32-25 24-17
point type 9 - Unsigned Long (2 registers, LO HO)

8-1
16-9
24-17
32-35
point type 10 Signed Long (2 registers, LO HO)

8-1 DL_TIME -
16-9
24-17 32-25
The time interval between transmissions of the same message. This numeric value represents the number of 1/100s of a second between transmissions. Valid entries range form 0 through 65535.
NOTE: Caution should be taken when editing the data file using KWIKEDIT. When the data file was created, it was sorted on the DL_DIRECT, DL_DEV_ADR, DL_SUB_LOC and DL_TIME fields in order to produce the most efficient number of messages. Inserting points out of sequence or creating gaps by deleting points in the data file may create a
57
situation where the number of messages generated is not optimal and the performance of the interface may be degraded unnecessarily.
58
3.2.6 Quality and Device Status Reporting

Quality and Device Status reporting are optional features which can be used to help indicate communication problems. This can be especially helpful when the driver program is communicating with a network of MPDs. If a device on the network fails, the driver has two mechanisms for indicating communication problems with that specific device. The first mechanism is point quality reporting. Every point read from the MPD and sent to the Bailey loop has an associated quality parameter which indicates the quality of the value. Block 3009 is a tunable "quality permissive" block on the first sheet of blockware. This block controls quality reporting for all points in each device being addressed by the interface. If tuned to a one, quality is reported with every point in the interface. If the MPD is responding to the point read requests, the point's quality will be GOOD. If not the point will have BAD quality. If tuned to a zero all points will always have good quality. This feature is not always desirable for some systems due to the number of alarms generated when an MPD link fails. The second mechanism is device status reporting. Each unique MPD being addressed can have a defined analog point indicating the mode of the communications link between the driver and the MPD. The figure located at the end of this section shows the state diagram for this concept. This device status reporting feature is configured when the database is created. A special type of database point is used by the driver to enable this feature. The database point is created with the SPECIAL_1 field containing an 'S' for Status. The other fields are filled in like any other analog point to Bailey (->DCS). The DL_DEV_ADR field is the MPD address. The other MPD database field (DL_SUB_LOC) is not ignored and must be entered with a unique dummy Modbus address. This feature is controlled by the presence or absence of a Status point for each MPD address. If a driver addresses five unique MPDs, anywhere from zero to five MPDs can have an associated status point. The following text describes the possible state transitions depicted in the logic state diagram included at the end of this section. A device status of 1 (DEV_UNKNOWN) indicates that one of the following four scenarios has occurred: 1) 2) There was no previous state because the interface was in the startup phase. The previous state was 0 (DEV_BAD) AND: There is only one device. OR There are multiple devices, all of which are status 0 (DEV_BAD). OR The duration of time that a particular device (of a group of devices) has been in the 0 (DEV_BAD) state has exceeded the allowable limit (usually 60 seconds). 3) The previous state was 2 (DEV_SYNCHING) AND:
59
The interface is a read only or read/write type AND a read message fails. OR The interface is a write only type and a write message fails. 4) The previous state was 3 (DEV_GOOD) AND any message fails.
A device status of 2 (DEV_SYNCHING) indicates that one of the following scenario occurred: 1) The previous state was 1 (DEV_UNKNOWN) AND the interface has read and write messages or only read messages AND all the read messages were successfully transmitted and received. The previous state was 1 (DEV_UNKNOWN) AND the interface has only write messages. If this is the case the interface will stay in DEV_SYNCHING until either the SYNCHING time period has expired or the write permissive block indicates that write messages are allowed. The previous state was 3 (DEV_GOOD) AND write permissive logic was chosen (stalled writes block > 0) AND the write permissive block indicates that writes are NOT allowed.
2)
3)
A status of 3 (DEV_GOOD) indicates that the following scenario has occurred: 1) The previous state was 2 (DEV_SYNCHING) AND either the Synching period has expired OR the write permissive signal indicates that write messages are allowed.
A status of 0 (DEV_BAD) indicates that the previous state was one (DEV_UNKNOWN) AND one of the following three scenarios has occurred: 1) 2) 3) If the interface to the device has both reads and writes, then at least one of the reads failed. If the interface to the device has only reads, then at least one of the reads failed. If the interface to the device has only writes, then at least one of the writes has failed.
60
Figure 3.2.6 - Device Status State Drawing
61
3.2.7 Backup Communications Port Swap Description

Block 3070 on the Generic CAD first sheet configures the interface for swapping communications from the current (primary) port to the redundant (backup) port. An output of 1 from block 3070 triggers the switch-over from one port to the other. An output of 0 from block 3070 notifies the driver to remain on the current communications port. The device status outputs are used to determine when a failover should occur. If any of the selected device statuses report a failure in communication, the backup port status (block 3070 = 1) will trigger the application driver to swap to the backup port. The diagram on the following page is an example of how to utilize the backup communications port swap feature. The startup in progress flag from the Generic CAD first sheet is also used to force the application driver to remain on the current port during a module startup. Not all of the device statuses need to be represented in the backup port swap logic. Only those which are deemed critical should be used to determine when the failover to the backup port should occur. NOTE: You must delete Block 3070 from the Generic CAD first sheet to avoid duplicate block number (3070) compilation errors.
62

(12)
RTU's STATUS
H//L S2 3 S3 -1
2900 2901
(93) Dev #1 3095 BASRO (93) Dev #2 3096 (93) Dev #3 3097 (93) Dev #4 3098 S2 3 S3 -1 H//L S2 3 S3 -1
(12) 2902 2903
S1
S2 OR (40) 2908 S3 S4
(12) H//L 2904 2905
(12) H//L S2 3 S3 -1 (93) Dev #7 3099 BASRO H//L S2 3 S3 -1 2906 2907
BACKUP PORT STATUS

OR (40) 2920
1 = SWAP TO OTHER PORT 0 = DO NOT SWAP

A N D (38) 3070
(12) 2915 2916
STARTUP IN PROGRESS
TD-DIG
(35) 2912
NOT
(33) 2910
TD-DIG S2 2 S3 .150
(35) 2911
S2 0 S3 60.0 TD-DIG S2 0 S3 90.0
(35) 2912
NOT
(33) 2913
Figure 3.2.7 Backup Port Swap Drawing

63
3.3 Files List

The JOB FILES LIST located at the front of this manual contains a complete listing of the program and data files required for this job application. These files should be loaded into the same job directory on the computer's hard drive. It is recommended to save copies of the enclosed diskettes in case of any problems, (i.e. hard drive problems).
3.4 Operation
3.4.1 Setup
Before proceeding with the startup section, it is necessary to make sure that all the hardware connections have been made (see Hardware Checklist section 2.7) and that all of the required files, (from the Files List section 3.3), are available.
3.4.2 Startup
Loading the Module The following text describes how to load the MPD interface package (driver, function code logic and data file) into an MFC/MFP module. It assumes the module is already initialized for Plant Loop or Super Loop (InfiNet). For detailed instructions on this initialization step, refer to Bailey Product Instruction E93-906-7 for MFC03s, E96-201 for MFP01s, E96-202 for MFP02s or E96203 for MFP03s. The following text also assumes familiarity with the operation of the CUP, MFUTILS, DFM or TXTEWS (CLS for Bailey Canada) packages. Separate Bailey Controls manuals are available with detailed instructions on the use of these packages. If using CUP, MFUTILS or DFM, the following instructions apply when loading a module: (Module must be in Configure Mode) 1. Format module. 2. Load C Program. 3. Load '.DTA' File. 4. Using TXTEWS (or CLS) Load CADEWS '.CFG' File. (Module may be put into Execute Mode) If the configuration and data files were created by Bailey, '.CFG' and '.NBS' files will have been provided. The '.NBS' file is a backup of the tested module's C program and data files. The '.CFG' file is the compiled version of the CADEWS drawings for the interface. Both of these files can be downloaded into the module using the TXTEWS program. NOTE: The '.NBS' file should be loaded first, then the '.CFG' file may be loaded.
64
3.4.3 Monitoring Execution 3.4.3.1 Blockware

Use the following procedures to determine if the interface program is executing properly. First, if the module is in the execute mode and no 'red light' condition is present, monitor function block number 16, the time in the current scan value. If this value remains small (typically less than 5 seconds), this is an indication that the module is scanning. If the value is constantly ramping up, then it is probably 'hung', indicating that the module has gotten stuck at some point in the program and is no longer functioning correctly. If the interface is not using redundant data link ports, a "dumb" terminal may be connected to the diagnostic (terminal) port of the TU for the purpose of monitoring diagnostic messages. To activate the diagnostic messages, use TXTEWS to tune function block number 3001 to ON (1). After a brief time period, the terminal should begin to display diagnostic messages. Under normal operating conditions, the terminal will display the program execution which includes such things as the message number being processed and the associated return status. If a recognizable error occurs, the error message associated with that condition will be displayed. Function block number 3002 is the 'delay between diagnostic messages' block. The value in this block represents the number of milliseconds to delay before displaying the next diagnostic message. If the messages are scrolling too rapidly, this value can be increased to slow the scrolling of the messages. Be aware that increasing this time will cause the real-time performance of the interface to degrade. NOTE: Remember to tune function block number 3001 to OFF (0) when finished with diagnostics because viewing diagnostic messages affects the real-time performance of the interface. If the interface is using redundant data link ports, the active port may be determined by monitoring function block number 3092. A value of '1' indicates that the printer port is active while a value of '0' indicates that the terminal port is active. If the interface requires the use of more than one message, function block number 3027 displays the current message number being sent/received. If this number is not changing after several seconds, there may be a problem. An error historian has also been provided which records the current and last three states of the interface program. The current state is held in function block number 1022 and the previous three states are held in 1021, 1020 and 1019 respectively. A zero in these blocks indicates no errors (normal operation) while a non-zero value indicates some kind of error condition. Refer to the table in section 3.4.4 of this document for a numerical listing of the program error codes and their descriptions. In addition to the error historian, there is a binary output block, function block number 1023, which will indicate a '0' if no errors are reported or a '1' if any recognizable error is detected and reported to the error historian.
65
3.4.3.2 Data Report Files

After completing the setup and startup sections, the module will be in execute mode and everything should be running properly. After the module is up and running three data files are created in the module from the 100.dta file that was loaded into file "100". These three data files, ("101", "102" and "103"), can be uploaded from the module to the PC for user reference and verification. It is not necessary, but if interested, the following steps explain how to upload the three files, convert them to ASCII text files, and view the information they contain. There are two methods of uploading the data files from the module. The first method discussed will be using CUP. However, if CUP is not purchased, the second method using the MFUTIL programs may be used. Uploading the Three Data Files To upload the data files "101", "102" and "103" the use of CUP, or MFUTILs is required. If using CUP, see the appropriate section in the CUP manual for the specifics on how to upload data files. If using the MFUTILs the following text applies. Uploading the Data Files using MFUTILs NOTE: Before using any of the MFUTILs make sure they are copied into a directory on the EWS that is in the environment path. To upload the data files "101", "102" and "103" go to the directory where you want them to be copied. At the DOS prompt type: MFREAD [port] module mf_file [pcu] An example of this utility using a Serial Port Module, COM 1 of the EWS, module address 10 and PCU 2, to upload file 101 is: MFREAD 10 101 <enter> Note that when using COM 1 the port does not need to be specified. Also note that when using a Serial Port Module the PCU does not need to be specified. This same procedure should be used to upload module files "102" and "103". Once this has been done there should be three files in the DOS directory, files 101, 102 and 103. Note there are no extensions on these files. The DOS RENAME command must be used to rename these files so they have the .dta extension. An example of the rename command on file 101 is: REN 101 101.dta <enter> This command should be done on files 102 and 103 also. Once all three files have a .dta extension the dump program may be run. Running the Dump Program
66
The three data files, (101.dta, 102.dta and 103.dta), should be in the DOS directory now. These files are in binary form. To translate them into ASCII text files the MOD_DUMP.EXE program must be run. Before doing this make sure the MOD_DUMP.EXE program is in the same directory as the three data files '101.dta', '102.dta' and '103.dta'. To run the dump program simply type MOD_DUMP <Enter> at the DOS prompt. When the program is done there will be three more files made in the directory. These file are MSG.RPT, TBL.RPT and DEVICE.RPT. These files can be printed to the screen or printer to view how the module broke the "100.dta" file up and verify that the information in the module is correct. Detailed descriptions of the ASCII report files MSG.RPT, TBL.RPT and DEVICE.RPT are given on the following pages. The MSG.RPT file is set up in the following format:
Msg # 0 1 3 Lookup Tbl Ofst 0 4 86 Interval Time 500 0 1000 Dev Addr 6 6 6 Func Code 1 1 3 Start Addr 0 4 104 # Regs 2 40 1 Error Check 7cbc 627c 6104
MSG # is the message number being processed. The message number can either be viewed in block #3027 through TXTEWS or if a dumb terminal is used the message number will be displayed as it is being processed. Lookup Tbl Ofst is the decimal lookup table offset of the particular point in the module file 102. It can be used to index the particular point in the "tbl.rpt" file. Interval Time is the time interval between transmissions of the same message. This is the value located in the DL_TIME field of the data point list. This value appears in 1/100s of a second. DEV ADR is the MPD address. This is the DL_DEV_ADR field in the data point list. Func Code is the Modbus protocol function that is being used on the particular point(s) for the specific message. See section 3.2.3 for function code descriptions. # Regs is the number of registers being transferred for the particular message. Error Check is the Cyclical Redundancy Check (CRC) value. This is an error checking value used to confirm data transmission is exact. The corresponding TBL.RPT file is set up in the following format:
67
Table Offset 0 2 4
Local Block # 100 101 103
Scale Factor
Offset Value
Analog Data Type
1.00
0.00
unsigned short
TABLE OFFSET is the decimal offset in the lookup table. LOCAL BLK # is the block number that is bin'd from or bout'd to in the module. SCALE FACTOR is the scale factor which is applied to raw data values to convert them to common engineering units. This is the DL_SCALE field in the data point list. OFFSET VALUE is the offset value which is applied to raw data values to convert them to common engineering units. This is the DL_OFFSET field in the data point list. ANALOG DATA TYPE contains the analog data type stored in the foreign device register location. Possible types are: blank for digital points, unsigned short, signed short, unsigned long, signed long and IEEE floating point registers. The corresponding DEV.RPT file is set up in the following format:
Table Offset 0 30 Dev Addr 5 8 Status Block 505 508
TABLE OFFSET is the decimal offset in the device table. DEVICE ADDRESS is the device address of the foreign device (in decimal). STATUS BLOCK is the local block which contains the device status (0 = DEV_BAD, 1 = DEV_UNKNOWN, 2 = DEV_SYNCHING or 3 = DEV_GOOD).
3.4.4 Error Codes/Descriptions

The following table is a list of the C Program Error Codes and their descriptions. Table 3.4.4 C Program Error Codes
68
Function main initialize
Error # 1 3 11 12 13 14 15 16 17 18 19 20
Error Description Invalid function type: (fnc type) Schedule message number out of range: (x) Failure to open printer port. Failure to open terminal port. Module not time synched to loop. Unable to bin redundant startup status. Unable to bin redundant port/P485/loopback blk. Can't bin time synch/test mode block (s). Unable to bin startup block. Unable to bin timeout block (TIMEOUT_BLK) Invalid timeout period Unable to bin stalled write blocks Unknown data file version: (version). Unable to allocate lookup table. Unable to allocate messages. Unable to read version byte. Unable to allocate devices. Format error reading from .dta file Invalid data type in special_2: Mixed old style/new style .dta file Invalid .dta file Out of range dl_loc in a new style .dta file Out of range dl_sub_loc in an old style .dta file Unable to open device list file Unable to open message list file Unable to open lookup table file Unable to write message count. Unable to write message list size. Unable to write message list Unable to write lookup table size. Unable to write lookup table. Error writing device list file length. Error writing number of devices. 69
Parse_dta
22 23 24 25 26
Pass_one
31 33 35 36 37 38
wrt_files
40 41 42 43 44 45 46 47 48 49
50 Xceive 51 52 53 54 55 56 57 58 59 60 61 port_swap func_03_04 func_08 func_15 func_05 func_16 71 72 91 96 97 101 102 105 106 111 112 113 func_06 rdy_to_run load_dta 115 116 121 131 132 133 134 135 136 137
Error writing device list Address mismatch Function mismatch Invalid crc Address mismatch Function mismatch Invalid crc A retry was required Output queue not clearing (outque size) Rcvd Modbus exception resp: (resp byte) No response after retrying Echo not received Comm port swapped to terminal port. Comm port swapped to printer port. Undefined data type: Invalid loopback response; device: Missing loopback response, device: Response does not match query Can't bin boolean state Response does not match query Unable to bin boolearn state Response does not match query Unable to bin analog value Undefined data type: Response does not match query Unable to bin No valid files in module. Unable to read message count. Unable to read message list size. Unable to alloc message list. Unable to read message list. Unable to read lookup table size. Unable to alloc lookup table. Unable to read lookup table. 70
138 139 140 141 msg_qual chk_dev_table 320 340 342 343 tell 1001 1002 1003 get_mode 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 bin_bout 1021 1022 1031 1032 1041 1042 1051 1052 chkpt_fl 1061 1062 1063 1064 schedule 1101
Unable to read device table size. Unable to read the number of devices. Unable to alloc device table space. Unable to read in device table. Quality bin failure Unknown Modbus function - device: (dev #) No reads or writes for device: (device #) Unable to bin stalled writes logic block Unable to bin redundant ports status. Unable to bin diag switch. Can not bin diag delay. Invalid baud rate entry: (baud rate). Invalid parity entry: (parity code). Can not bin module type. Can not bin XON/OFF status. Can not bin break detect status. Can not bin stop bits. Can not bin parity sense. Can not bin number of data bits. Can not bin baud rate. Can not bin RTS/CTS option. Bad bin_b block number: (blkn) bin_b from non-boolean block: (blkn). Bad bin_f block number: (blkn). bin_f from non-float block: (blkn). bout_b overflow occurred???: (blkn). Bad bout_b block number: (blkn). bout_f overflow occurred: (blkn). Bab bout_f block number: (blkn). No buffer available - file: (fileno). File: (fileno) too big for buffer. File: (fileno) read error. Problem with backup - file (fileno). NULL pointer passed to scheduler. 71
1102 1103 1104 1105 1106 1107 1108 1109
Illegal s_function passed to scheduler. Queue table already exists. Unable to allocate queue table. Queue table does not exist yet. Invalid message index number. Queue table does not exist. Unable to bin % of target in C. Can not bin speed block.
3.5 Software Checklist

Table 3.5 Software Checklist []
[] [] [] [] []
Complete Hardware Checklist. Load C Driver and Data file.
(Module should be initialized.)
MFP/MFC has Invoke C Block on first CADEWS sheet. (Function Code 143.) Load '.cfg' file. Put module into execute mode and check LED displays. (If the module red lights refer to section 7.0 of this manual.) Verify that the program segment is running. Block 16, (Function Code 82), Shows the elapsed time of current execution cycle. This block should go back to zero within 5 seconds. ** For Monitoring Execution refer to section 3.4.3
72
4.0 Database
73
5.0 Revision
/***************************************************************************** Program file: modbus.c Software: Lattice C (cross-compiled on EWS to MFC 68000 code) Description: This is a generic program which acts as the master of a Modbus digital interface. It supports the following functions: Function Description -------- ------------------------1 Read coil status, 2 Read input status, 3 Read holding registers, 4 Read input registers, 5 Force single coil, 6 Preset single register, 8 Loopback diagnostic test, 15 Force multiple coils, 16 Force multiple registers. History: 5/89 - Version 1.0 - A. Halarewicz, SE, BCCo. - original version. 8/89 - Version 1.1 - A. Halarewicz, SE, BCCo. - functions 5 & 6 were added and the interface was divided into three files; modbus.c, modinc.c and modbus.h. 3/90 - Version 2.0 - A. Halarewicz, SE, BCCo. - scale_from was changed from a multiplier to a divisor. Subroutine diagnostic indenting was added. MSGMAKE.exe was written to create the modbus messages. The Modbus Number field was eliminated from the look-up tables. 5/90 - Version 2.1 - A. Halarewicz, SE, BCCo. - check for block number equal to zero was added. This allows you to enter 0 as a block number in any of the look up tables and the value returned will be zero or it will not be bouted. 5/90 - Version 2.2 - A. Halarewicz, SE, BCCo. - fixed readerror bug. Before error would never clear. Added MASK to header file to initialize readerror depending on the read functions used. Changed BAD BOUT 3 messages in tell routine. 6/90 - Version 3.0 - A. Halarewicz, SE, BCCo. - entire program reconfigured to read database and build messages. Readerror redesigned to handle multiple slaves. File modinc.h was eliminated. Some declarations moved from .h file to .c file. Version block added (#9964). Input to MFC = DATA * scale_from[i]. Output from MFC / scale_to[i] = DATA. SYNC_BLK changed to block 49 from 70.
74
6/90 - Version 3.1 - A. Halarewicz, SE, BCCo. - input to MFC = (DATA * scale_from[i]) offset_from[i]. (Output from MFC + offset_to[i]) / scale_to[i] = DATA. 7/90 - Version 3.11 - A. Halarewicz, SE, BCCo. - few minor bugs eliminated. 9/90 - Version 3.12 - T. Adams, SE, BCCo. - more bugs eliminated. Error codes enhanced. 11/90 - Version 4.0 - T. Herman, SE, BCCo. - complete rewrite of all program functions. Addition of support for reading, parsing, and decoding standard data file input into Modbus protocol messages automatically at module startup time. First fully generic version of the Modbus/RTU protocol driver program. Compatible with version 1.0 standard data files. 12/90 - Version 4.1 - T. Herman, SE, BCCo. - restructured to separate the truly generic definitions and functions from the protocol specific parts. Generic definitions placed in generic.h. Generic functions placed in lcm.l library. Full support of redundant ports and modules. Corrected func_01_02 state bout problem. 1/91 - Version 4.2 - T. Herman, SE, BCCo. - added calls to pck_upck library to pack and unpack shorts and larger into and out of char buffers (necessary due to 68000 based MFP01 & 2 not having all the CPU instructions of 68020 based MFC03s). 3/91 - Version 4.3 - T. Herman, SE, BCCo. - corrected shortcomings in the drivers support for SA storage type points in the pass_one and pass_two functions. Placed 'if' statements on the scaling and offsetting of analog values in both directions. Changed the scaling equations to divide when converting to Eus and multiply when converting to raw counts. 4/91 - Version 4.4 - T. Herman, SE, BCCo. - added support for version 2 standard format data files. 5/91 - Version 4.5 - T. Herman, SE, BCCo. - added a single retry after the initial message request times out. The number of retries is not configureable from function blocks. 6/91 - Version 4.6 - T. Herman, SE, BCCo. - converted symbol def'n references to 'first sheet' block numbers to global external variable references and include 'global.inc' which contains the global variable reference declarations. Corrected missing decode of message after retry bug (see version 4.5). 9/91 - Version 4.6.1 - T. Herman, SE, BCCo. - corrected timing error in re-synch logic of xceive function (fail_msgs = NUM_FAILS). 12/91 - Version 4.7 - B. Lundquist, SE, BCCo. - added support for "RTU" protocol used by GE Series Six PLC. The pass_one function was altered to support SPECIAL_B as a dl_storage type. This type is used to indicate reading digital information from an input table (this only applies to RTU interfaces). The pass_two function contains code which is conditionally compiled based upon whether the interface is RTU or not.
75
The global variables Com_buf0 and Com_buf1 were added to set the size of the input and output buffers instead of using the default size. These variables are used in the function initialize when the ports are opened. 1/92 - Version 5.0 - M. Jenkins, SE, BCCo. - added support for newly added functions 5 and 6 exception based write commands. 2/92 - Version 5.1 - M. Jenkins, SE, BCCo. - split "modbus.c" into "modbus.c" (main I/O processing routines) and "modbus2.c" (initializing routines for pass one and pass two). Added quality based on message status. Device handling based on the "dev.c" file programmed by J.W. Hoffman for the generic AB driver was added with modifications to the maintain_dev_list and resetdevicemsgs functions. 5/92 - Version 5.2 - T. Herman, APD, BCCo. - move initialize() into "modbus.c" file to minimize external references. Moved/renamed/reworked check_dev_table() from dev.c due to new protocol specific references. Optimized up func_05() and func_06(). Added exception bouting feature to func_01_02 and func_03_04. Changed parse_dta() to zero length of 100 file after successfull pass_two(). Changed rdy_to_run() to check for existence of 100 file. Added GERTU specific code to prep_msg(). Corrected send_msg() to support "write only" type devices. 9/93 - Version 5.3 - B. Lundquist, APD, BCCo. - changed the last value value assignment in pass_two() of modbus2.c from 65535 (0xFFFF) to 0x0000. This alligns the last value with the default state of the BASROQ. 1/94 - Version 5.31 - B. Lundquist, APD, BCCo. - added tuneable timeout functionality. Upon startup, a value is "binned" for the timeout period. The value is verified to be greater than zero. If it is not, the default timeout period of 1.5 seconds will be used. The timeout value will be located in block 3010. Added code to change the resynch time period on a redundant failover situation. Block 3008 contains a time duration in msec that the interface will perform only reads. If the value in block 3008 is less than 500, the default value of 15 seconds will be used. During this time period, exception bouting will be disabled. 2/94 - Version 5.4 - B. Lundquist, APD, BCCo. - removed the conditional compilation sections from modbus2.c and modbus.h. 3/94 - Version 5.5 - B. Lundquist, APD, BCCo. - Program now reports error when module is not time synched to loop and test block is not set to 1. Stalled writes concept is now incorporated into driver. The warm failover sync time concept is now superceded by this. 3/95 - Version 5.5.1 - M. W. Jenkins, APD, BCCo. - Replaced all write function calls with putmsg (added #include ios1.h). Linked with new generic.lib which fixed a bug in the tell function call when redundant comm ports was selected. 3/95 - Version 6.0 - M. W. Jenkins, APD, BCCo. - added support for RS485 2 wire communications. This requires the addition of block 3018 (Port type) to the first page, along with
76
tuning spec 3 of block 20 to a 1000. This update requires adding to the initialize(), get_port(), swap_port() and xceive() functions. Utilized the special_1 field (0-4) to allow multiple analog data types to be transferred. blank = unsigned short (2 bytes) 0 = unsigned short (2 bytes) 1 = signed short (2 bytes) 2 = unsigned long (4 bytes) 3 = signed long (4 bytes) 4 = IEEE float (4 bytes) Incorporating this logic required modifications to the initialize functions (pass_one and pass_two) and all analog I/O processing functions (func_03_04 and func_16). Modified code to report any bout data from DEV_SYNCHING mode to any state which is not equal to good (DEV_GOOD). Reduced the size of message buffers from 261 to 10 in functions func_05() and func_06(). Added logic to support loopback test (func_08()) to validate the redundant port and each device on the redundant link. 5/95 - Version 6.1 - M. W. Jenkins, APD, BCCo. - the status variable initialization was changed from UNKNOWN to GOOD in the build message for loop. This corrects the bug of not sending out a valid write message. 5/95 - Version 6.2 - M. W. Jenkins, APD, BCCo. - a check for NULL file pointer (fp_100) was added before we attempt to fclose file 100. If file 100 does not exist in the module, or if this is the first time file 100 is being parsed into files 101-103, the portopen fails for the secondary port (if redunancy has been selected). This occurs because we fclose fp_100 twice (the second attempt fclose a file pointer which is already NULL) in the rdy_to_run function. Subsequent restarts of the MFP will cover up this error since the path for load_dta in the rdy_to_run() function does not attempt to fclose fp_100 twice, or when NULL. Added an initial set timeout for the loopback delay (func_08) message. Updated msg_qual() to increment the pointer to the analog lookup structure after incrementing the register count. A bad bout or wrong value could occur if the quality permissive is ON. 10/95 - Version 6.21 - M. W. Jenkins, APD, BCCo. - fixed code in pass_one and pass_two to not create a new message following SA type points unless the dl_sub_loc field indicates a new message (dl_sub_loc != l_dl_sub_loc + c_l_reg_siz). 3/8/96 - Version 6.3 - M. W. Jenkins, APD, BCCo. - bad quality on a device failure is not reported for every data point associated with the device. Currently, only points associated with messages that fail are flagged as BADQ on device failure. Typically, three messages failure indicate a device failure. I added functionality to flag all points associated with a device failure to BADQ. Updated functions check_msg_stat() and dev_to_bad() functions. 3/8/96 - Version 6.31 - M. W. Jenkins, APD, BCCo. - when using PVCS the latest version of the source code retrieved was version 6.2 instead of 6.21. Thus, changes made in 6.3 were made
77
to 6.2 instead of 6.21. Version 6.31 incorporates versions 6.21 and 6.3. 3/18/96 - Version 6.4 - M. A. Rybka, AAS, BCCo. - this rev allows the use of two additional data types. Numbered 5 and 6, they are the same as data types 2 and 3 respectively. The difference is that data types 5 and 6 expect the LO order register first and the HI order register second in func_03_04(). Version 6.4 - M. W. Jenkins, APD, BCCo. - Renamed #defines for long and floating point data as LOHO and HOLO respectively. Added LOHO byte processing for IEEE floats in func_03_04(). Added additional port swapping logic based on device statuses (blk 3070) in check_dev_table(). Added bout for backup port status OK/FAILED in func_08(). 5/30/96 - Version 6.41 - M. W. Jenkins, APD, BCCo. - Renamed #defines for IEEE_FLOAT_HOLO to IEEE_FLOAT_LOHO and IEEE_FLOAT_LOHO to IEEE_FLOAT_HOLO. Modified xceive() to allow tunable delay between the time a response is read from the device and is checked before the next transmission to request data from the device. This delay is defined in global.inc as 3019 and is for all communication types (RS232/485 2 and 4 wire). Removed the timechk function for memory purposes. 2/12/97 - Version 7.0 - A. Ina, APD, BCCo. - Modified pass_one(), pass_two and prep_msg() to accomodate the expansion of the range of the data points from 10,000 to 30,000 points. The dl_loc field is now used to hold the range type indicator('A') in the prefix byte, and the upper 16bits of the long word address in high order and low order bytes. The dl_sub_loc field has the starting address which can go up to 65535, and is the low 16 bits of the long word address. The long word address corressponds to a register number but is not equal to it. In the old style data base the prefix byte of the dl_loc field was a space (0x20) while 0 is assigned to the high/low bytes. The dl_sub_loc has the register number. (The register number can actually go up to the value of 65535, but is limited by the max address in the device.) The new data point ranges are: (for the 30,000 points request) 1 - 29,999 for functions (1, 5, 15) 100,001 - 129,999 for function (2) 300,001 - 329,999 for function (4) 400,001 - 429,999 for functions (3, 6, 16) New functions added: c_data_loc() ul_lastdataloc() New error codes added: 35,36,37,38 6/97 - Version 7.1 - R.S.Delinsky, AAS, EBCo. - added support for new data types: 8 = IEEE float (4 bytes, reverse word) 9 = unsigned long (4 bytes, LO-HO) 10 = signed long (4 bytes, LO-HO)
78
Deleted coded added in version 6.3 that parsed data array for type 'SA' special_1 field. Code
inadvertently split packed digital data registers into a new message, when a new message packet was not required. Revised code for calculating extended register range and removed function c_data_loc() added in v7.0 Modbus.c and Modbus2.c were reorganized to have all initialization routines in the Modbus.c file and run time functions in the Modbus2.c file. 3/98 - Version 7.2 - M.W.Jenkins, APD, EBPA. - Previous revision (7.1) of the driver used a different Generic.h than the released version. The Modbus source files were Recompiled and Relinked with the previous version of the generic.h FNHO and FNLO macro calls. This driver was successfully tested on the Bridge Controller Module. ******************************************************************************/
79
6.0 Blockware Listing
80
7.0 Network 90 Documents
81
8.0 Foreign Device Vendor Documents
82
9.0 KWIKEDIT Data File Editor

9.1 Introduction
This section describes the operation of the Kwik Editor (KWIKEDIT) program. The Kwik Editor is an easy to use editor for maintaining the contents of Standard Format data files. These files are used with Bailey's library of generic digital interface drivers to specify data points to be passed between the Bailey control network and a 'foreign' device. The editor cannot create a new data point file; its purpose is strictly to maintain existing data files. The Kwik Editor is not protocol dependent. This means that it can be used with any Bailey Controls generic digital interface driver program which uses standard format data files. However, this also means that it does not check the validity of address ranges, device numbers and so on. Therefore, care must be taken to enter each field properly based on the intended type of interface.
9.2 Before Proceeding

Before proceeding with operation of the Kwik Editor, verify that all of the required files, which are located on the KWIKEDIT disk accompanying this document, are loaded on the EWS's hard disk. These files include: kwikedit.exe - The Kwik Editor executable program file. It contains the majority of the editors program code. i_scr267.dsc - A screen descriptor file for the Kwik Editor's field editing screen. Must be kept in the \EWS2 directory immediately off of the root directory. i_scr268.dsc - A screen descriptor file for the Kwik Editor's field editing screen. Must be kept in the \EWS2 directory immediately off of the root directory. projname.dta - The projects standard format data point file. Replace the 'projname' portion with your specific project name. Make sure that the environment path on your computer has access to the kwikedit.exe file and the \EWS2 sub-directory. Make sure that you are currently in the sub-directory containing the .dta file to be edited.
83
9.3 Operating the Kwik Editor

To start the Kwik Editor, simply type 'kwikedit' and press the Enter key. The screen clears and a screen titled "Display Files / Select Data File" is displayed. The following figure shows the layout of this screen.
Display Files Path . Pattern *.dta Display/Remove (D/R) D 1 directories C:\AUTO\KWIKEDIT MODBUS.DTA GEMK.DTA Alt-H Help AB.DTA Select Data File 1 files
Figure 9.3.1 - File Selection Screen The cursor rests on a line labelled "Path". A single dot is placed into this field by default. Since the data point file to be edited is in the current directory, simply press the F10 key to accept the existing path. All of the .dta files in the current directory are displayed on the screen. Once the .dta files are displayed, move the cursor around to highlight the single, desired .dta file. Only one file may be edited at a time. Press the Enter key to select the file and then press the F10 key once again to accept the filename selection. The screen clears and then displays the editing screen which is titled "KWIKEDIT - Digital Interface Standard File Editor". This screen displays all of the fields found in a record of a standard format data point file. From this screen move to and change the value of any displayed field, page up or down to a different data point record, insert records for new data points, delete existing data point records, escape back to DOS (which does not save any changes made) or press F10 to exit (and save all changes). The following figure shows the layout of the editing screen.
84
KWIKEDIT -
Digital Interface Standard File Editor
Rec#: 1
DL_STORAGE: Digital SPECIAL_1: DL_DIRECT: ->DCS DL_DEV_ADR: 1
DL_LOC Char Prefix: DL_LOC File Number DL_SUB_LOC Address: 1 DL_SUB_LOC Bit Position: 0 DL_LOC_BLK: 7101 DL_SCALE: 1 DL_OFFSET: 0 SPECIAL_2: 0 DL_TIME:500
Alt-H Help
F8 Choice Help
Figure 9.3.2 - Data File Editing Screen NOTE: The fields which require editing will vary depending on the type of interface protocol. Please consult the "Specific Database/Data File Format" section of the job manual for more information. All data file manipulation is performed from the editing screen. The following table summarizes the editing function of each keystroke supported by the editing screen. Table 9.3.1 - Kwikedit Keystroke Commands
Keystroke Cursor Down Arrow Cursor Up Arrow Cursor Right Arrow Cursor Left Arrow Page Down Page Up Alt-L Alt-S Escape F10 Function Move to the next lower field on the screen. If already at the bottom, move to the top field. Move to the next higher field on the screen. If already at the top, move to the bottom field. Move to the right in the current field. If already at the end, move to the first character. Move to the left in the current field. If already at the start, move to the last character. Display the next record number. Display previous record number Insert a new record after the currently displayed record. Delete the currently displayed record. Quit the editing session without saving any changes. Exit the editing session and save all of the changes made.
The current record number is displayed in the upper right hand corner of the field editing screen. This number indicates the record number which is currently being viewed.
85
Only upper case entries are allowed in the SPECIAL_1 and DL_LOC character prefix fields. This means that if a lower case value is entered, the editor automatically capitalizes it upon moving off of the field. The DL_STORAGE and DL_DIRECT fields only accept specific character strings. In order to facilitate their entry, 'choice menus' are implemented on the editing screen. These little windows can be called up with the F8 key. They display the allowable choices and place a highlighted bar on one of them. To use them, move to the desired choice using the up and down cursor arrows and press Enter. The data file editor does not allow the deletion of all of the records in a given data file. When only one record remains and the delete operation is attempted, the program beeps to indicate the error. Likewise, when inserting new records into the data file, it is possible (although unlikely) that the computer may run out of available memory. When this happens, the program beeps to indicate the error. When inserting new records into the data file, the program initially fills the new records with default values. If a default value is acceptable, there is no need to reenter it. Most generic digital interface driver programs breakup messages based on contiguous blocks of addresses. Therefore, care should be taken in determining the sequence of data point records within the data point file. By placing contiguously addressed data points in contiguous record numbers in the data file, higher communication efficiencies can be achieved. After completing the editing session, the revised .dta file is loaded into the Bailey MFC/MFP module as file number 100 using the CUP program or the MFWRITE, MFDEL and MFMODE programs.
86
10.0 Multi-Function Controller/Processor Utilities

10.1 Introduction
This section contains descriptions and instructions for the MFC/MFP Utilities located in the MFUTIL directory of the KWIKEDIT disk accompanying this document. If CUP (the C Utility Program) was not purchased, these programs may be used to provide some of the basic functions that CUP would perform.
10.2 Before Proceeding

The following directory listing gives the names of all of the Multi-Function Utilities. These programs should be kept in a directory on the EWS that is in the environment path of the PC. All of these programs should be used with either COM1 or COM2 of the EWS hooked up to a CIU or an SPM. These programs were written using command line arguments. To run one of these programs, type the program name followed by the proper argument values and then press the Enter/Return key. Even though these programs have been tested and used by engineers, there may be some 'bugs' in the software. These programs are not a released product like TXTEWS or CUP, but are merely engineering tools which allow a savings in time and configuration software. If while using one of these programs a 'bug' is found, please discontinue use and contact the Bailey engineer who worked on the particular project on which these utilities were being used.
Directory of A:\MFUTIL MFDIR MFFORM MFLOAD MFMODE MFWRITE MFDEL MFFRM MFDIAG MFREAD EXE EXE EXE EXE EXE EXE EXE EXE EXE 27177 06-16-94 27849 06-16-94 34913 06-16-94 36301 06-16-94 28473 06-16-94 26871 06-16-94 26887 06-16-94 45551 10-11-93 29863 06-16-94 2:39p 2:39a 2:39p 2:39p 2:39p 2:39p 2:39p 10:44a 2:39p
87
10.3 Using the Multi-Function Utilities

The MFDIR.EXE program provides a way to do a directory of a specified module. SYNTAX: MFDIR [port] module [pcu] <Enter> arguments: [port] - 0 for COM1. 1 for COM2. Default port is COM1.
module - The specific module address, (between 2 and 31). [pcu] - The specific pcu (between 0 and 255). Default pcu is 0. NOTE: use pcu = 0 for an SPM. The MFFORM.EXE program provides a way to format a module according to the '.csp' file. SYNTAX: MFFORM [port] module cspfile [pcu] <Enter> arguments: [port] - 0 for COM1. 1 for COM2. Default port is COM1. module - The specific module address, (between 2 and 31). cspfile - The name of the '.csp' file made by CUP with the '.csp' extension. [pcu] - The specific pcu (between 0 and 255). Default pcu is 0. NOTE: use pcu = 0 for an SPM. The MFLOAD.EXE program provides a way to download a C program into a formatted MFC/MFP module. The program requires three files with the same name but different extensions. extensions: file.lms - the C code file. file.csp - the CSP file created by CUP. file.map - the link map file for the C program.
SYNTAX: MFLOAD [port] module file [pcu] <Enter> arguments: [port] - 0 for COM1. 1 for COM2. Default port is COM1. module - The specific module address, (between 2 and 31). file - The name of the C program. [pcu] - The specific pcu (between 0 and 255). Default pcu is 0. NOTE: use pcu = 0 for an SPM. The MFMODE.EXE program provides a way to change the mode of a specified module. It has five functions. It can Reset the module, put the module in Configure mode, put the
88
module in Execute mode, Initialize the module, or get the status of the module. SYNTAX: MFMODE [port] module mode [pcu] <Enter> arguments: [port] - 0 for COM1. 1 for COM2. Default port is COM1. module - The specific module address, (between 2 and 31). mode R for reset. C for config. E for execute. I for initialize. ? for get status.
[pcu] - The specific pcu (between 0 and 255). Default pcu is 0. NOTE: use pcu = 0 for an SPM. The MFWRITE.EXE program provides a way to write a source file such as a '.dta' file from the EWS to a destination file in an MFC/MFP. SYNTAX: MFWRITE [port] module src dest [pcu] <Enter> arguments: [port] - 0 for COM1. 1 for COM2. Default port is COM1. module - The specific module address, (between 2 and 31). src - Any valid data file (include file extension and path). dest - The specific MFC/MFP destination file ID (between 0 and 32768). [pcu] - The specific pcu (between 0 and 255). Default pcu is 0. NOTE: use pcu = 0 for an SPM. The MFDEL.EXE program provides a way to delete a destination file in a specified module. SYNTAX: MFDEL [port] module dest [pcu] <Enter> arguments: [port] - 0 for COM1. 1 for COM2. Default port is COM1. module - The specific module address, (between 2 and 31). dest - The specific MFC/MFP destination file ID (between 0 and 32768). [pcu] - The specific pcu (between 0 and 255). Default pcu is 0. NOTE: use pcu = 0 for an SPM. The MFFRM.EXE program provides a way to format the module according to the specified
89
arguments. SYNTAX: MFFRM [port] module dirfils cnvmsiz [pcu] <Enter> arguments: [port] - 0 for COM1. 1 for COM2. Default port is COM1.
module - The specific module address, (between 2 and 31). dirfils - The maximum number of data files permitted in the module. Refer to section 3.2.3 (under memory formatting specs). cnvmsiz - The non-volatile ram size to be formatted for the C program. Refer to section 3.2.3 (under memory formatting specs). [pcu] - The specific pcu (between 0 and 255). Default pcu is 0. NOTE: use pcu = 0 for an SPM. The MFREAD.EXE program provides a way to copy a file from the MFC/MFP module to the EWS. SYNTAX: MFREAD [port] module mf_file [pcu] <Enter> arguments: [port] - 0 for COM1. 1 for COM2. Default port is COM1. module - The specific module address, (between 2 and 31). mf_file - The specific MFC/MFP data file ID (between 1 and 32795). - Reserved (between 32760 and 32764). - C code file 32765. - C data file 32766. - C map file 32767. [pcu] - The specific pcu (between 0 and 255). Default pcu is 0. NOTE: use pcu = 0 for an SPM. NOTE: The file copied from the module will be named whatever the module file ID name is. It is not given an extension. Therefore, when using this program to download data files 101, 102 and 103 (once they are in the DOS directory), rename them to 101.dta, 102.dta and 103.dta respectively. After renaming the files, the dump program may be run to produce the msg.rpt, tbl.rpt and device.rpt files.
90
The MFDIAG.EXE program is a terminal emulation program. It provides a way to view diagnostic messages from a PC. SYNTAX: MFDIAG <Enter> The MFDIAG.EXE program provides a way to display diagnostic messages from an MFP/MFC interface to an EWS. It may be used in place of a "dumb" terminal. To use the MFDIAG program, connect an RS-232 cable between the Terminal Port of the interface module TU and the EWS. Tune the Diagnostic block in the interface module (typically 3001) to a one (1). Run the MFDIAG program. Note that the default COM port is COM1 and the Baud, Databits, Stopbits, and Parity are 9600,8,1,None. These parameters show up at the bottom of the screen (status line). To change the default parameters, or exit the program, press the <F10> key. Also displayed on the right side of the status line are some RS-232 line signals. These signals are DRS, CTS, RI and CD. If an arrow for a particular signal is pointing up, the indicated signal is active and if the arrow is pointing down the signal is not active.
91

GENMOD3

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GENMOD3

Uploaded by

Copyright:

Available Formats

Bailey Controls to MODBUS Protocol Device Interface

2.6 FOREIGN DEVICE EQUIPMENT SETUP.................................................................................. 27

Bailey Controls to MODBUS Protocol Device Interface

3.3 FILES LIST...................................................................................................................................... 64

5.0 REVISION ....................................................................................................................................... 74

Bailey Controls to MODBUS Protocol Device Interface

9.3 OPERATING THE KWIK EDITOR............................................................................................. 84

Bailey Controls to MODBUS Protocol Device Interface

1.1 System Description

Bailey Controls to MODBUS Protocol Device Interface

1.2 System Overview

Bailey Controls Cabinet

Device Serial Data Cable

Bailey Controls to MODBUS Protocol Device Interface

1.3 Documentation Terminology

Bailey Controls to MODBUS Protocol Device Interface

2.2 Termination Unit Layouts 2.2.1 NIMF01 Layout

Bailey Controls to MODBUS Protocol Device Interface

Figure 2.2.1 - NIMF01/02 Overview

Bailey Controls to MODBUS Protocol Device Interface

2.2.2 NIMP01 Layout

Figure 2.2.2 - NIMP01/02 Overview

Bailey Controls to MODBUS Protocol Device Interface

2.2.3 NTMP01 Layout

Figure 2.2.3 - NTMP01 Overview

Bailey Controls to MODBUS Protocol Device Interface

2.2.4 NTMF01 Layout

Figure 2.2.4 - NTMF01 Overview

Bailey Controls to MODBUS Protocol Device Interface

2.3 Termination Unit Configurations 2.3.1 NIMF01 DCE Configuration

Figure 2.3.1 - NIMF01 DCE Dipshunt Cuts

Bailey Controls to MODBUS Protocol Device Interface

2.3.2 NIMF01 DTE Configuration

Figure 2.3.2 - NIMF01 DTE Dipshunt Cuts

Bailey Controls to MODBUS Protocol Device Interface

2.3.3.1 New NIMP01 DCE configuration

Figure 2.3.3.1 - New NIMP01 DCE Jumper Settings

Bailey Controls to MODBUS Protocol Device Interface

Figure 2.3.3.2 - Old NIMP01 DCE Jumper Settings

Bailey Controls to MODBUS Protocol Device Interface

2.3.4.1 New NIMP01 DTE configuration

Figure 2.3.4.1 - New NIMP01 DTE Jumper Settings

Bailey Controls to MODBUS Protocol Device Interface

2.3.4.2 Old NIMP01 DTE configuration

Figure 2.3.4.2 - Old NIMP01 DTE Jumper Settings

Bailey Controls to MODBUS Protocol Device Interface

2.3.5.1 New NTMP01 DCE Configuration

Figure 2.3.5.1 - New NTMP01 DCE Jumper Settings

Bailey Controls to MODBUS Protocol Device Interface

2.3.5.2 Old NTMP01 DCE Configuration

Bailey Controls to MODBUS Protocol Device Interface

Figure 2.3.5.2 - Old NTMP01 DCE Jumper Settings

2.3.6.1 New NTMP01 DTE Configuration

Bailey Controls to MODBUS Protocol Device Interface

Figure 2.3.6.1 - New NTMP01 DTE Jumper Settings

Bailey Controls to MODBUS Protocol Device Interface

2.3.6.2 Old NTMP01 DTE Configuration

Figure 2.3.6.2 - Old NTMP01 DTE Jumper Settings

Bailey Controls to MODBUS Protocol Device Interface

2.3.3 NTMF01 DCE Configuration

Figure 2.3.7 - NTMF01 DCE Dipshunt Cuts

Bailey Controls to MODBUS Protocol Device Interface

2.3.4 NTMF01 DTE Configuration