MODBUS RTU compatible master and slave driver for High Performance Controllers

Transcription

1 MODBUS RTU compatible master and slave driver for High Performance Controllers Book E26 - Version 2.12

2 MODBUS RTU compatible master and slave driver E26 Version 2.12 Table of contents Chapter 1 Introduction 3 1 Overview Required... hardware 3 3 Required... software 3 4 Required... option lock 4 5 Cabling... 4 Chapter 2 Installation of the driver 5 Chapter 3 1 Initialization... of the serial port 5 2 Installing... a MODBUS master 5 3 Installing... a MODBUS slave 7 4 Uninstalling... a MODBUS slave 9 Do reads and writes with the MODBUS master 10 Chapter 4 More about numbers and types of variables 13 1 Mapping... table of ED&A digital inputs to modbus numbers (using standard i/o configuration) 14 2 Mapping... table of ED&A digital outputs to modbus numbers (using standard i/o configuration) 15 3 Mapping... table of ED&A analogue inputs to modbus numbers (using standard i/o configuration) 16 4 Mapping... table of ED&A analogue outputs to modbus numbers (using standard i/o configuration) 16 Chapter 5 Broadcasting 18 Chapter 6 Protocol details 19 Chapter 7 Troubleshooting guide 24 1 Does... MODBUS master send messages? 24 2 Does... the slave receive these messages? 25 3 Does... the slave react to the messages? 25 4 Does... the answers go from the slave to the master? 26 5 Are... the answers OK or do they contain error codes? 26 6 Do... cable problems cause interruptions? 27 Chapter 8 Examples 28 1 Modsla1.epl Modmas1.epl Modmas2.epl Modmas3.epl Modmas4.epl

3 MODBUS RTU compatible master and slave driver E26 Version Modsla4.epl Chapter 9 Versions book

4 1 Introduction Because communication between industrial controllers and interface equipment is becoming ever more important, E.D.&A. has implemented the MODBUS protocol in their HPC's. MODBUS is a fail safe, multiclient and easy to use protocol that makes communication possible between HPC's or between HPC's and arbitrary MODBUS masters or slaves of other manufacturers. 1.1 Overview This manual describes the use of this MODBUS protocol implementation for all HPC's using the EPL programming language. For details concerning the E.D.&A. HPC hardware and programming, please refer to the E.D.&A. technical reference manuals. There are two MODBUS implementations: a MODBUS master driver, a MODBUS slave driver. The MODBUS master implementation is really the master of the serial line, it reads data from, and writes data to one or more connected slave systems. There is always one MODBUS master on a serial line, but there can be one or more slave systems. The MODBUS slave only listens to the master and sends answers back if it receives valid requests. The driver can be installed multiple times on a HPC, which allows it to communicate through multiple serial ports at the same time, each connecting one or more other systems. Only RTU mode is implemented, this means that data is transferred in binary mode, using a CRC-16 error check sequence. ASCII mode is not supported. 1.2 Required hardware The use of the MODBUS software requires a serial port and an option lock. This option lock is a security key that allows the use of optional software. The hardware reference manuals of each HPC model describe the placement of the option locks: These MODBUS drivers can be used on any serial port of the HPC's, the desired port number must be chosen when the protocol is installed by the HPC program. 1.3 Required software To use the MODBUS driver software, the HPC must have a certain minimum system software version. There are some additions to the MODBUS slave driver that are available from a later system software version. These additions are: reading and writing of char and long variables, relaxed timing capability for communication through modems, RS485 multipoint capability, increased maximum transfers of 512 bools and 64 shorts, and a deinstall() function. This table shows what minimum system software version is required to use a given capability: Capability V5-2xx/3xx V10-2xx V50-2xx MODBUS slave driver v1.30 v1.23 v1.33 MODBUS slave additions v1.36 v2.02 v2.01 MODBUS master driver v1.32 v1.29 v1.33 MODBUS master broadcast v1.36 v2.02 v2.01 The EWB programming software must be version 2.04 or newer. 3

5 1.4 Required option lock One option lock is required for each installation of a MODBUS master or slave driver. When, for example, a driver must run on 4 serial ports, it must be installed 4 times, which requires 4 options. One MODBUS master driver communicating with multiple slaves requires only one option lock. The hardware reference manuals of each HPC system describe the installation and use of the option locks in detail. 1.5 Cabling The MODBUS protocol can run on RS232, RS422, RS485 or current-loop serial communication ports. No handshake signals are required. Their state is ignored, even if they are connected through the serial line. The use of a shielded cable is recommended to avoid interference problems. For RS232, a simple 3-wire cable is sufficient for distances up to 15 meters. For RS485 multipoint cabling, we've got a few rules-of-thumb: When using speeds up to 9600 bps, cables up to 450 meters can be used without termination. When using thin cable (0.14mm²/AWG26), the use of terminators may prevent the network from working because the terminators draw so much current that the cable's resistance causes too much voltage loss. When using longer cables, terminators are required and therefore thicker cable (0.5mm²/AWG20) must be used to keep voltage loss low. The hardware reference manuals for the different HPC's describe the pinning and interconnections of the cables. 4

6 2 Installation of the driver To use the MODBUS driver, two things must be done: 1. first open a serial port, 2. then install the driver on it. 2.1 Initialization of the serial port Two functions can be used to open a serial port on a HPC: ComOpen() and ComOpenq(). ComOpen(): Is simpler to use, but it configures the port with the default buffer sizes of 256 bytes for the transmit buffer and 128 bytes for the receive buffer, which are rather large for MODBUS. This works fine but may be a problem when many serial ports are used because they all need there transmit and receive buffers. Example: open com port 1 for 9600 baud, no parity, 8 data bits and 1 stop bit. Store the return value in the variable S1: S1 = ComOpen( 1, "9600,n,8,1"); ComOpenq(): Is a bit more complex, but it allows the programmer to control the sizes of the queues (buffers) and therefore use more serial ports without running out of memory. Example: open serial port 1 for 9600 baud, no parity, 8 data bits and 1 stop bit. Allocate a 100-byte queue for transmission and a 50-byte queue for reception. Store the return value in the variable S1: S1 = ComOpenq( 1, "9600,n,8,1", 100, 50); The number of data bits MUST be 8 for MODBUS. The other parameters: baud rate, parity- and stop bits can be chosen freely. It's necessary however that they are the same for the master and all the slaves on the serial line. It's possible to use the programming port of the HPC. This serial port can be used as serial port 0. The port must be in "communication" mode and not in "programming" mode. The hardware manuals describe the settings of the programmer port. 2.2 Installing a MODBUS master Purpose: Installs a MODBUS master driver on a serial port. Other functions must then be used to initiate read and write operations to connected slaves. The MODBUS master driver must be installed and initialized before it can be used. The operational parameters like timeout and number of retries in case of an error, are specified with this installation. Notation: 5

7 short InstallModbusMas( short comnr, short buffer, short timeout, short tries); Parameters: comnr: Parameter of the type short. Number of the serial port where the MODBUS master is installed on. buffer: Parameter of the type short. The size of the buffer that the driver uses to build the requests that it transmits and to store the answers that it receives. See the remarks below on how to choose the size of the buffer that is required for your application. timeout: Parameter of the type short. The time that the driver allows for a slave to respond, in milliseconds. If the slave does not answer in time, the request has failed. An other request is started then if the number of retries is bigger the 0. tries: Parameter of the type short. The number of times that the driver will try to send each request to a slave. If all these attempts fail, the request will be returned to the user program with status 'failed'. Return value: InstallModbusMas() returns 1 if the installation was successful. Negative values indicate an error: -41: means that one of the initialization parameters is wrong. -45: means there are no more option locks free to allow the use of the driver. -47: means the serial port is not available or not initialized. Remarks: The parameters are used for all the subsequent reads and writes through this port, they are permanent and cannot be changed without restarting the HPC. To install more MODBUS master drivers, simply call the same function for the other serial ports. The serial port must be initialized first with the ComOpen() or ComOpenq() function. How to determine the required buffer size: The worst case for reading or writing registers is 9 fixed bytes + 2 bytes per 16-bit register. When transferring Boolean variables (bool), 1 byte is needed per 8 Boolean variables. The 9 fixed bytes are also needed. For example, read 20 registers from a slave: 8 bytes needed to transmit the read request. The answer containing the data can be received with a buffer of 9+2*20 = 49 bytes. Rounded to 50 bytes will do fine. In the included examples, a buffer of 100 bytes is configured, which allows reading or writing 45 registers in one transfer. A MODBUS master does not have a number, because it is the only node that initiates requests, and answers are always directed to the master. Only slaves have numbers. 6

8 Only one MODBUS master can be active in a network. A master can not communicate with another master. A HPC can be MODBUS master and slave at the same time on different serial ports. Example: Install the driver on COM port 1, use a buffer of 100 bytes, allow a response time of 1 second, which agrees with 1000 milliseconds, and try 3 times before giving up. Store the return value in the variable S1: S1 = InstallModbusMas( 1, 100, 1000, 3); 2.3 Installing a MODBUS slave Purpose: Install a MODBUS slave driver on a serial port. Once installed, the driver will automatically work in the background and process incoming request. The MODBUS slave driver must be installed and initialized before it can be used. The slave number to which the driver will respond is also specified when the driver is installed. Notation: short InstallModbus( short comnr, short slavenr, short options); Parameters: comnr: Parameter of the type short. Number of the serial port where the MODBUS slave is installed on. slavenr: Parameter of the type short. This number defines the slave number to which the driver will respond. Each slave must have a unique number on a serial line. The master sends its request to a certain slave number, and only that slave will answer. There are two ways to define the slave number: If slavenr is zero will the HPC address be taken as slave number. The adjustment of the address number is described in the hardware manual. The slavenr parameter is taken as slave number directly if the number is greater the zero. option: Parameter of the type short. The options parameter, that normally = o, is a bit pattern by which several options of the modbus slave driver can be switched on. If you want to switch on several options together, the sum of the option values has to be inserted. Option value 1: MODBUS slave will work with a minor strict timing (relaxed timing). The timeout that indicates the end of a message is now 40 character times instead of 4 character times. This allows the use of a modem in a serial line. Only point to point connections are possible with this relaxed timing. Multipoint RS485 is not possible. Option value 2: this is only available for the recent HPCs. All the markers and the short variables are accessible via modem instead of only the first The digital inputs are no longer approachable from marker 9001 and the analog outputs are no longer approachable 7

9 from short Return value: InstallModbus() returns 1 if the installation was successful. Negative values indicate an error: -41: means that one of the initialization parameters is wrong. -45: means there are no more option locks free to allow the use of the driver. -47: means the serial port is not available or not initialized. Remarks: The MODBUS slave driver runs automatically. Nothing must be done besides initializing a serial port and installing the protocol driver on that port. Because it's a slave driver, it will automatically answer all read or write requests from the MODBUS master. The number of variables that can be read or written in one read or write request is limited: variables of type 'bool': maximum 512 variables of type 'short': maximum 64 variables of type 'char': maximum 128 variables of type 'long': maximum 32. The data that are read or written with the MODBUS protocol, are processed between two cycles of the program: If the MODBUS master reads data are this data placed in a buffer and then transmitted to the master. If the MODBUS master writes data to the HPC, are this data placed in a buffer until the complete messages is received. All the data are then written to the variables of the user program at once, just before the user program starts a new cycle. In this way is it impossible that during a cycle of the user program data is read or written by the MODBUS master. Example 1: These statements initialize serial port 1 for 9600 baud, no parity, 8 data bits and 1 stop bit and install a MODBUS slave on that serial port with slave number 1. Store the return value of the ComOpen() function in the variable S1: S1 = ComOpen( 1, "9600,N,8,1"); InstallModbus( 1, 1, 0); The return value of the InstallModbus() function is not stored in a variable. On a V5-2xx and a V5-3xx HPC, specify 0 as serial port number with the comopen() and installmodbus() functions. The parameters for the serial port (baud rate, parity and stop bits) must always be the same for the MODBUS master and slave. The number of data bits must always be 8 for MODBUS. Example 2: Install modbus on 2 serial ports. On com3 with even parity and slave number 1. On com4 without parity, as slave number the HPC address that was adjusted via the dip switches is taken. All the markers and short variables are made accessible. 8

10 init() { S1 = ComOpen( 3, "9600,E,8,1"); S2 = InstallModbus( 3, 1, 0); } S3 = ComOpen( 4, "9600,N,8,1"); S4 = InstallModbus( 4, 0, 2); 2.4 Uninstalling a MODBUS slave Purpose: Remove a MODBUS slave driver from a serial port. This allows the application program to use the serial port for other purposes. The MODBUS slave driver can be re-installed using the normal InstallModbus() function. Notation: short DeinstallModbus( short comnr); Parameters: comnr: Parameter of the type short. Number of the serial port where the MODBUS will be removed from. Return value: DeinstallModbus() returns 1 if the removal was successful. Negative values indicate an error: -41: means that the removal failed because no MODBUS slave driver was installed on the port. Example: Remove the MODBUS slave driver if it was previously installed on port 1. Store the return value in the variable S1: S1 = DeInstallModbus( 1); 9

11 3 Do reads and writes with the MODBUS master Purpose: Do read and write actions to the MODBUS slaves. The MODBUS master can communicate with all the slaves on the serial line. There's a function to read values from a slave, ModbusRead(), and a function to write values to a slave, ModbusWrite(). A MODBUS master driver must be previously installed on the serial port. Notation: short ModbusRead( bool *startflag, short comnr, long *transferblock); short ModbusWrite( bool *startflag, short comnr, long *transferblock); Parameters: startflag: Parameter of the type 'pointer to bool' or 'address of bool'. This is a marker to indicate that the ModbusRead() or ModbusWrite() function must do its data transfer. The user program must set this flag (set the marker to 1). The transfer will be done as soon as the port becomes available. The flag remains set while the function waits for the port to become available, and while the transfer is actually done. When the transfer is done, the startflag is automatically set to 0 by the ModbusRead() or ModbusWrite() function. If the user sets this startflag to 0, the transfer will be canceled. comnr: Parameter of the type short. This is the serial port number on which the read or write action must be done. transferblock: Parameter of the type 'pointer to long' or 'address of long'. The beginning of a block of 5 long variables. These contain more details about the transfer; such as slave number and which variables are transferred. See below for more information. Return value: The function returns a value that indicates whether the transfer is busy or finished, and whether the transfer was successful or not. Negative values indicate an error. The return value is also placed in the fourth long of the transfer block (see below). This makes it easy to verify whether a transfer was successful. All you have to do is display the fourth long of the transferblock. The return values have the following meaning: 2 Indicates a successful transfer has been done. 1 Indicates the function is waiting for the port to become available, or it is actually doing the transfer. 0 Indicates that the function is not active. It is just waiting for the startflag to become set No MODBUS driver on the com port The number of the variable is invalid. This indicates an error in the second long of the transferblock The buffer is too small for the transfer of the requested number of variables. You need to lower the number of variables specified in the third long of the transferblock, or specify a larger buffer during installation of the MODBUS master driver Timeout, the master did not receive a valid answer from the slave. The serial port is in "programmer" mode and not in "communication" mode. A jumper connection on the 10

12 programming connector can cause this, or a dip switch that puts com port 0 into programming mode, like dip switch 6 on the V5-1xxx HPC's Checksum error Protocol error: an invalid reply message was received from the slave Protocol error: the slave replied with exception code 01, 'illegal function'. This means that it did not understand the function code in the request message Protocol error: the slave replied with exception code 02, 'invalid address'. This means that the request message had an invalid variable address, invalid length, or that address + length goes past the last variable of the slave Protocol error: the slave replied with exception code 03, 'illegal data'. This means that the master attempted to write an invalid value into a variable Protocol error: The slave replied with exception code 04 "Slave device failure". For some reason, the slave can not execute the command. Check the documentation of the slave Protocol error: the slave replied with exception code 06, 'busy'. This means that it is busy. The request could not be processed Protocol error: The slave replied with exception code 07 "Nak-negative acknowledgement". For some reason, the slave can not execute the command. Check the documentation of the slave Protocol gateway error: The gateway replied with exception code 10 "Gateway path unavailable". Can occur when the modbus communication passes through a gateway. The gateway doesn't know how to forward the modbus command to the slave Protocol gateway error: The gateway replied with exception code 11 "Gateway path unavailable". Can occur when the modbus communication passes through a gateway. The gateway has forwarded the modbus command to the slave, but did not receive a response from that slave. Remarks: The MODBUS master driver must be installed on a serial port first, by calling the function InstallModbusMas(). Multiple read or write transfers can be started at the same time. The system will automatically do one transfer after another. Startflag must be unique for each transfer; different start markers must be used for each read or write request. It's very important that the ModbusRead() or ModbusWrite() statements are executed in every cycle of the program when a read of write action is in progress. This means that the following example is wrong: if( ^/b5s) /* read every 5 seconds */ { m20 = 1; S1 = ModbusRead( &m20, 1, &L100); /* WILL NOT WORK!! */ } But this is correct: if( ^/b5s) /* read every 5 seconds */ { m20 = 1; } S1 = ModbusRead( &m20, 1, &L100); /* WORKS */ The return value is stored in the variable S1. The transfer block: This is a block of 5 longs, which contain the details of the read or write actions. 11

13 First long: The slave number: values between 1 and 250 are permitted. Second long: Variable number in the slave. This defines the type and the exact number of variable that will be written to, or read from the slave. See below for more information on how to specify the variable number. Third long: The number of variables that are read or written. The maximum number of variables that can be transferred in a single read or write transaction is limited: variables of type 'bool': maximum 512 variables of type 'short': maximum 64 These maximums can be lower if the slave device has lower maximums. Fourth long: The status of the last action remains in this variable. This number is the same as the return value of the ModbusRead() or ModbusWrite() functions. Fifth long: Contains the address of the HPC variable(s) where the data from the read action must be stored, or where the data for the write action must come from. Transfer block example: When this block is used for a READ action, it reads registers 10 up to 19 from slave number 1, and stores the data in this HPC's short S20 up to S29. When this block is used for a WRITE action, it writes into registers 10 up to 19 of slave number 1, and the data comes from this HPC's short S20 up to S29. L100 = 1; L101 = 40010; L102 = 10; L103 = 0; L104 = (long)&s20; 12

14 4 More about numbers and types of variables MODBUS has its own way to define the different types of variables. All the types of variables (markers, inputs, outputs, numerical registers, ) are indicated with a number between 1 and 49999: a list that contains all types of variables. E.D.&A. HPC's work differently, each type of variable has its own listing (e.g. E1.1, S1, M1, ). To be compatible, E.D.&A. HPC's do a conversion between the MODBUS names and their own names. In MODBUS masters, including the E.D.&A. MODBUS master, the MODBUS name (number between 1 and 49999) usually must be used. The following table indicates what the MODBUS numbers stand for: Variable number in MODBUS form Name in E.D.&A. EPL HPC's Type M1 M1000 internal digital flag (marker) A1.1 A16.16 digital output E1.1 E16.16 digital input AE1.1 AE16.8 analog input S1 S500 internal numerical register (short) AA1.1 AA16.4 analog output See also the 4 mapping tables below. These give the standard mapping of the modbus i/o variables to the ED&A variables for the standard i/o configuration. These tables can not be used if the number of inputs or outputs of the i/o cards are different! This list is correct for all E.D.&A. HPC's that use the EPL programming language. The HPC's that use the ABC programming language have other names for their variables. They can be used with the MODBUS master but the mapping table of the ABC slaves has to be used (see book E25). The maximum usable MODBUS variable numbers are restricted to the capabilities of the MODBUS slave. For an E.D.&A. HPC MODBUS slave, this depends on the number of variables that are configured by the memory configuration of the HPC application program. For example, the short variables have a standard configuration of S1 to S500. This means that the MODBUS variable number has a valid range from to If another configuration is used that defines more or less short variables, the valid variable number range will grow of shrink equally. Inputs and outputs are numbered linear in the MODBUS protocol: they are numbered in the order of the HPC i/o configuration. So modbus input maps to input E1.1. Modbus input maps to input E1.18 if E1 has 18 or more inputs, or it may map to E2.2 if E1 has 16 inputs. Remarks: Char and long variables can not be read or written by the MODBUS master. Only E.D.&A. HPC slaves support this. The only MODBUS master that can use these extra features is the E.D.&A. MODBUS master driver for PC's. Example 1: Read from a slave with number 1, read S1 up to S40, which are 40 registers, store in S101 to S140: L200 = 1; L201 = 40001; L202 = 40; L203 = 0; L204 = (long)&s101; 13

15 Example 2: Read from a slave with number 12, read M400 up to M450, which are 51 flags or coils, store in M400 to M450: L200 = 12; L201 = 400; L202 = 51; L203 = 0; L204 = (long)&m400; 4.1 Mapping table of ED&A digital inputs to modbus numbers (using standard i/o configuration) V5-2xx V5-3xx V5-12xx V5-13xx V5-14xx V5-22xx V5-23xx V5-24xx V V10-22x V10-23x V50-20x V50-22x RCC30-20 RCC30-40 E (E1.1-26) (E1.1-26) (E1.1-18) (E1.1-16) (E1.1-16) (E1.1-16) E (E2.1-18) (E2.1-16) (E2.1-16) (E2.1-16) (E2.1-16) E (E3.1-16) (E3.1-16) (E3.1-16) (E3.1-16) (E3.1-16) E (E4.1-16) (E4.1-16) (E4.1-16) (E4.1-16) (E4.1-16) E (E5.1-16) (E5.1-16) (E5.1-16) (E5.1-16) (E5.1-16) E (E6.1-16) (E6.1-16) (E6.1-16) (E6.1-16) (E6.1-16) E (E7.1-16) (E7.1-16) (E7.1-16) (E7.1-16) (E7.1-16) E (E8.1-16) (E8.1-16) (E8.1-16) (E8.1-16) (E8.1-16) E (E9.1-16) (E9.1-16) (E9.1-16) (E9.1-16) E (E ) (E ) (E ) (E ) E (E ) (E ) (E ) E (E ) (E ) (E ) E (E ) (E ) (E ) E (E ) (E ) (E ) E (E ) (E ) (E ) 14

16 E (E ) (E ) (E ) 4.2 Mapping table of ED&A digital outputs to modbus numbers (using standard i/o configuration) V5-2xx V5-3xx V5-12xx V5-13xx V5-14xx V5-22xx V5-23xx V5-24xx V V10-22x V10-23x V50-20x V50-22x RCC30-20 RCC30-40 A (A1.1-16) 9001 (A1.1-8) 9001 (A1.1-8) 9001 (A1.1-8) 9001 (A1.1-16) 9001 (A1.1-8) A (A2.1-8) 9009 (A2.1-8) 9009 (A2.1-8) 9017 (A2.1-16) 9009 (A2.1-6) A (A3.1-8) 9017 (A3.1-8) 9017 (A3.1-8) 9033 (A3.1-16) 9015 (A3.1-8) A (A4.1-8) 9025 (A4.1-8) 9025 (A4.1-8) 9049 (A4.1-16) 9023 (A4.1-8) A (A5.1-8) 9033 (A5.1-8) 9033 (A5.1-8) 9065 (A5.1-16) 9031 (A5.1-8) A (A6.1-8) 9041 (A6.1-8) 9041 (A6.1-8) 9081 (A6.1-16) 9039 (A6.1-8) A (A7.1-8) 9049 (A7.1-8) 9049 (A7.1-8) 9097 (A7.1-16) 9047 (A7.1-8) A (A8.1-8) 9057 (A8.1-8) 9057 (A8.1-8) 9113 (A8.1-16) 9055 (A8.1-8) A (A9.1-8) 9065 (A9.1-8) 9129 (A9.1-16) 9063 (A9.1-8) A (A10.1-8) 9073 (A10.1-8) 9145 (A ) 9071 (A10.1-8) A (A11.1-8) 9081 (A11.1-8) 9161 (A ) A (A12.1-8) 9089 (A12.1-8) 9177 (A ) A (A13.1-8) 9097 (A13.1-8) 9193 (A ) A (A14.1-8) 9105 (A14.1-8) 9209 (A ) A (A15.1-8) 9113 (A15.1-8) 9225 (A ) A (A16.1-8) 9121 (A16.1-8) 9241 (A ) 15

17 4.3 Mapping table of ED&A analogue inputs to modbus numbers (using standard i/o configuration) V5-2xx V5-3xx AE (AE1.1-4) V5-12xx V5-13xx V5-14xx (AE1.1-8) AE (AE2.1-4) AE (AE3.1-4) AE (AE4.1-4) AE (AE5.1-4) AE (AE6.1-4) AE (AE7.1-4) AE (AE8.1-4) V5-22xx V5-23xx V5-24xx (AE1.1-8) (AE2.1-8) (AE3.1-8) (AE4.1-8) (AE5.1-8) (AE6.1-8) (AE7.1-8) (AE8.1-8) V V10-22x V10-23x (AE1.1-8) (AE2.1-8) (AE3.1-8) (AE4.1-8) (AE5.1-8) (AE6.1-8) (AE7.1-8) (AE8.1-8) V50-20x V50-22x (AE1.1-8) (AE2.1-8) (AE3.1-8) (AE4.1-8) (AE5.1-8) (AE6.1-8) (AE7.1-8) (AE8.1-8) AE (AE9.1-8) AE (AE10.1-8) AE (AE11.1-8) AE (AE12.1-8) AE (AE13.1-8) AE (AE14.1-8) AE (AE15.1-8) AE (AE16.1-8) RCC30-20 RCC (AE1.1-4) (AE2.1-4) (AE3.1-4) (AE4.1-4) (AE5.1-4) (AE6.1-4) (AE7.1-4) (AE8.1-4) 4.4 Mapping table of ED&A analogue outputs to modbus numbers (using standard i/o configuration) V5-2xx V5-3xx V5-12xx V5-13xx V5-14xx V5-22xx V5-23xx V5-24xx V10-21x V10-22x V10-23x V50-20x V50-22x RCC30-20 RCC

18 AA (AA1.1) (AA1.1-4) AA (AA2.1-2) AA (AA3.1-2) AA (AA4.1-2) AA (AA5.1-2) AA (AA6.1-2) AA (AA7.1-2) AA (AA8.1-2) (AA1.1-4) (AA2.1-2) (AA3.1-2) (AA4.1-2) (AA5.1-2) (AA6.1-2) (AA7.1-2) (AA8.1-2) (AA1.1-2) (AA2.1-2) (AA3.1-2) (AA4.1-2) (AA5.1-2) (AA6.1-2) (AA7.1-2) (AA8.1-2) (AA1.1-4) (AA2.1-4) (AA3.1-4) (AA4.1-4) (AA5.1-4) (AA6.1-4) (AA7.1-4) (AA8.1-4) AA (AA9.1-4) AA (AA10.1-4) AA (AA11.1-4) AA (AA12.1-4) AA (AA13.1-4) AA (AA14.1-4) AA (AA15.1-4) AA (AA16.1-4) (AA1.1-2) (AA2.1-2) (AA3.1-2) (AA4.1-2) (AA5.1-2) (AA6.1-2) (AA7.1-2) (AA8.1-2) 17

19 5 Broadcasting Broadcasting is a mechanism that makes it possible for a MODBUS master to write variables in all connected slaves at once. This is achieved by sending a write function to slave number 0, which is accepted by all slaves. The slaves won't send an answer back to the master to confirm the write request. The broadcast mechanism is useful if you need to send the same data to several slaves. Remember that a broadcast does not require an acknowledge and therefore is not repeated in case of line interference! Therefore it's best to broadcast data periodically to make sure it arrives in all slaves. Broadcasting a read request makes no sense because none of the slaves will answer. Example: Once per second, broadcast the shorts S20..S29 to all slaves into registers the return value is placed in the variable S1: if( ^/b1s) { L100 = 0; L101 = 40010; L102 = 10; L103 = 0; L104 = (long)&s20; m20 = 1; } S1 = ModbusWrite( &m20, 1, &L100); 18

20 6 Protocol details This chapter is intended for those who need to know about the functions and addresses that are used in the internals of the protocol! The following list shows which functions are used in the MODBUS protocol to read and write variables: Function number Function type Range (16-bit address field) function 01 Read coils Read function 02 Read inputs Read function 03 Read holding registers Read function 04 Read input registers Read function 15 Write coils Write function 16 Write holding registers Write function 65 (E.D.&A. extension) function 66 (E.D.&A. extension) function 67 (E.D.&A. extension) function 68 (E.D.&A. extension) Read character variables Write character variables Read long variables Write long variables Which modbus function codes are generated by ModbusRead() and ModbusWrite() The ModbusRead() and ModbusWrite() functions automatically generate a modbus function code from the variable that has to be read or written. This table shows what function codes and addresses are generated: Variable Function code in modbus query message Read (Read coils) Read (Read inputs) Read (Read holding registers) Read (Read input registers) Write (Write coils) Write (Write holding registers) Function 03: Read holding registers: The query message: Address in modbus query message <ADR><FUNC><OFFSET-H><OFFSET-L><LEN-H><LEN-L><CRC-H><CRC-L> ADR: the slave address FUNC: function code 03 OFFSET-H, OFFSET-L: data address, this is actually an offset, and therefore starts at zero for the first variable! LEN-H, LEN-L: the number of variables to read CRC-H, CRC-L: the CRC 19

21 The response message: <ADR><FUNC><BYTECOUNT><DATA1-H><DATA1-L><DATA2-H><DATA2-L>...<CRC-H><CRC-L> ADR: the slave address that sent the response FUNC: echo of the function code 03 BYTECOUNT: the number of data bytes that follow, equal to the number of requested variables * 2 DATAx-H, DATAx-L: high/low data bytes of each 16-bit word read, 2 bytes per word CRC-H, CRC-L: the CRC Example: Read the 10 first 16-bit registers from slave 1 (S1..S10) ADR: 01 FUNC: 03 OFFSET-H, OFFSET-L: LEN-H, LEN-L: 00 0A CRC-H, CRC-L: C5 CD Query message: 0x01 0x03 0x00 0x00 0x00 0x0A 0xC5 0xCD Possible response message: 0x01 0x03 0x14 0x00 0x01 0x00 0x02 0x00 0x03 0x00 0x04 0x00 0x05 0x00 0x06 0x00 0x07 0x00 0x08 0x00 0x09 0x00 0x0A 0x8F 0x16 meaning Reg0=0x0001, Reg1=0x0002,... Function 65(dec): Read character registers (8-bit): (ED&A extension) The query message: <ADR><FUNC><OFFSET-H><OFFSET-L><LEN-H><LEN-L><CRC-H><CRC-L> ADR: the slave address FUNC: function code 65 decimal or 41 hex OFFSET-H, OFFSET-L: data address, this is actually an offset, and therefore starts at zero for the first variable! LEN-H, LEN-L: the number of variables to be read CRC-H, CRC-L: the CRC The response message: <ADR><FUNC><BYTECOUNT><DATA1><DATA2><DATA3>...<CRC-H><CRC-L> ADR: the slave address that sent the response FUNC: echo of the function code 65 BYTECOUNT: the number of data bytes that follow, equal to the number of requested variables DATAx: data bytes of each character read, 1 byte per character CRC-H, CRC-L: the CRC Function 66(dec): Write character registers (8-bit): (ED&A extension) 20

22 The query message: <ADR><FUNC><OFFSET-H><OFFSET-L><LEN-H><LEN-L><BYTECOUNT><DATA1><DATA2>...<CRC- H><CRC-L> ADR: the slave address FUNC: function code 66 decimal or 42 hex OFFSET-H, OFFSET-L: data address, this is actually an offset, and therefore starts at zero for the first variable! LEN-H, LEN-L: the number of variables to be written BYTECOUNT: the number of data bytes that follow, equal to the number of variables to be written DATAx: data byte for each character to be written, 1 byte per character CRC-H, CRC-L: the CRC The response message: <ADR><FUNC><OFFSET-H><OFFSET-L><LEN-H><LEN-L><CRC-H><CRC-L> ADR: the slave address that sent the response FUNC: echo of the function code 66 OFFSET-H, OFFSET-L: echo of value in the query message LEN-H, LEN-L: echo of value in the query message CRC-H, CRC-L: the CRC Function 67(dec): Read long registers (32-bit): (ED&A extension) The query message: <ADR><FUNC><OFFSET-H><OFFSET-L><LEN-H><LEN-L><CRC-H><CRC-L> ADR: the slave address FUNC: function code 67 decimal or 43 hex OFFSET-H, OFFSET-L: data address, this is actually an offset, and therefore starts at zero for the first variable! LEN-H, LEN-L: the number of variables to be read CRC-H, CRC-L: the CRC The response message: <ADR><FUNC><BYTECOUNT><DATA1-H><DATA1-M><DATA1-N><DATA1-L><DATA2-H><DATA2- M><DATA2-N><DATA2-L>...<CRC-H><CRC-L> ADR: the slave address that sent the response FUNC: echo of the function code 67 BYTECOUNT: the number of data bytes that follow, equal to the number of requested variables * 4 DATA1-H, DATA1-M, DATA1-N, DATA1-L: data bytes of each character read, 4 bytes per long, big endian format CRC-H, CRC-L: the CRC Function 68(dec): Write long registers (32-bit): (ED&A extension) The query message: <ADR><FUNC><OFFSET-H><OFFSET-L><LEN-H><LEN-L><BYTECOUNT><DATA1-M><DATA1- N><DATA1-L><DATA2-H><DATA2-M><DATA2-N><DATA2-L>...<CRC-H><CRC-L> 21

23 ADR: the slave address FUNC: function code 68 decimal or 44 hex OFFSET-H, OFFSET-L: data address, this is actually an offset, and therefore starts at zero for the first variable! LEN-H, LEN-L: the number of variables to be written BYTECOUNT: the number of data bytes that follow, equal to the number of variables to be written * 4 DATAx-H, DATAx-M, DATAx-N, DATAx-L: data bytes of each long to write, 4 bytes per long, big endian format CRC-H, CRC-L: the CRC The response message: <ADR><FUNC><OFFSET-H><OFFSET-L><LEN-H><LEN-L><CRC-H><CRC-L> ADR: the slave address that sent the response FUNC: echo of the function code 68 OFFSET-H, OFFSET-L: echo of value in the query message LEN-H, LEN-L: echo of value in the query message CRC-H, CRC-L: the CRC Exception responses: A MODBUS slave, including the HPC MODBUS slave driver, can return exception codes instead of the requested data in case of an error. The ModbusRead() or ModbusWrite() functions will return a negative value if the slave returns an exception code. Exception code Description Return value of ModbusRead( ) or ModbusWrite( ) 01 "Illegal function": if the request message has an illegal function number. 02 "Invalid address": if the request message has an invalid data address, invalid length, or if address + length goes past the last variable. 03 "Illegal data": if the master attempted to write an invalid value into a variable. 04 "Slave device failure": For some reason, the slave can not execute the command. Check the documentation of the slave. 06 "Busy": the slave is busy, the request could not be processed. 07 "Nak-negative acknowledgement". For some reason, the slave can not execute the command. Check the documentation of the slave. 10 "Gateway path unavailable": Can occur when the modbus communication passes through a gateway. The gateway doesn't know how to forward the modbus command to the slave. 11 "Gateway path unavailable": Can occur when the modbus communication passes through a gateway. The gateway has forwarded the modbus command to the slave, but did not

24 receive a response from that slave. 23

25 7 Troubleshooting guide In case the communication between a MODBUS master and slave isn't working, what points can be checked? Summary: 1. Is the MODBUS master sending requests? 2. Does the slave receive the requests? 3. Does the slave react to the requests? 4. Do the answers of the slave get to the master? 5. Are the answers good or do they contain an error code? 6. Cable problems causing intermittent failures? This guide is based on the status LED's that are available on all the serial ports of the E.D.&A. HPC's. If other equipment is being used it might be helpful to use an RS232 test tool with LED's. First, make sure that the MODBUS master program sends packets on a regular base (each second e.g.). The second program example, modmas1.epl, can be used for this. 7.1 Does MODBUS master send messages? Does the transmit data LED (TxD) of the MODBUS master flash once per second? This is a red LED on all E.D.&A HPC's. A flashing TxD LED indicates that the MODBUS master is sending data packets to the slave. The slave will not react as long as the master isn't transmitting data packets, so make sure the master's TxD LED is flashing before proceeding to the next step! Verify the following items if the LED isn't flashing: Check the external power supply of the used serial port if present. Corresponds the serial port where the cable is connected to with the serial port number that is used in the program? The serial port number must be used with the ComOpen() function and the with the InstallModbusMas() function. The serial port of the V5 HPC and the serial port on the CPU boards of the different HPC's is always COM 0 (null)! Check the return value of the ComOpen() function. Negative values indicate an error if the port could not be opened. Check the return value of the InstallModbusMas() function. Negative values indicate an error if the driver could not be installed. The return value of InstallModbusMas() is described in chapter 2.2. The serial port must already be opened when the MODBUS driver is installed because it needs to know the baud-rate to calculate its timing requirements. The install can also fail if the required option lock is not available. Remove the serial cable and see whether the TxD LED flashes now. It might indicate a problem with the cable if the LED flashes now. There could be a short-circuit inside the cable or the cable is a programmer cable which places the serial port in "programming" mode: The serial port is not in "communication" mode but in "programming" mode. The PP-80 programmer cable, or any other cable that is used to send a program to the HPC, puts the serial 24

26 port automatically in "programmer" mode because there is a little extra wire inside the connector. These cables can therefore not be used to communicate with MODBUS on a serial port that also works as a programmer port (= the serial port of the V5-xxx and the port on the CPU of the V10 and V50). It's also possible to force the programmer port in "programmer" mode with a jumper or dip-switch on most HPC systems. The used cable has no influence then on the mode of the serial port: it will always be in "programming" mode. The hardware manuals give a detailed description of this possibility. The user program and MODBUS have no control over the serial port as long as it is in "programmer" mode, so make sure the port is not in "programmer" mode. The ModbusRead() and ModbusWrite() functions give the return value 103 if the serial port is in "programmer" mode. Is the HPC in RUN mode? A HPC that is not in RUN mode is not executing the user program, so the serial communication with MODBUS isn't working either. 7.2 Does the slave receive these messages? If the TxD LED of the master works, check the receive data LED (RxD) of the MODBUS slave. This is a yellow or red LED on E.D.&A. HPC's. This RxD LED should flash with the same rate as the TxD LED on the master. This LED indicates that the data from the MODBUS master arrives at the slave. This LED won't flash if the TxD LED of the master isn't flashing! Check the following points if the receive data LED (RxD) does not flash: Check the external power supply of the used serial port if present. Most serial ports on E.D.&A. HPC's can work in a RS232 and a RS485 mode. The receive data LED (RxD) will not lighten if the serial port is in the wrong mode. The hardware manuals describe the jumpers or dip-switches that set the mode of the serial port. The mode of the port of master and slave must be the same. The cable can be wrong. The connections inside the cables are described in the hardware manuals. It's still possible that the serial cable is wrong when the RxD LED flashes! Especially if: the "signal ground line" and one of the "signal lines" are reversed in an RS232 cable the two wires of a RS485 cable are reversed The RxD LED might flash while the HPC receives garbage data in these cases. 7.3 Does the slave react to the messages? If the slave's receive data LED (RxD) flashes, it receives the request from the MODBUS master. Now the slave should send an answer back. The answer is visible on the red transmit data LED (TxD) of the slave. This LED should lighten shortly after the RxD LED. The TxD LED will only lighten if the RxD LED is working! There are some reasons why this might not be happening: Corresponds the serial port where the cable is connected to with the serial port number that is used in the program? The serial port number must be used with the ComOpen() function and the with the InstallModbusMas() function. The serial port of the V5 HPC and the serial port on the CPU boards of the different HPC's is always COM 0 (null)! Check the return value of the ComOpen() function. Negative values indicate an error if the port could not be opened. Check the return value of the InstallModbus() function. Negative values indicate an error if the driver could not be installed. The return value of InstallModbus() is described in chapter 2.3. The serial port must already be opened when the MODBUS driver is installed because it needs to 25

27 know the baud-rate to calculate its timing requirements. The install can also fail if the required option lock is not available. The slave number of the MODBUS slave is not correct: the master sends his request to a specific slave number, so the slave must be set to that slave number. This can be done with dip-switches on the MODBUS slave or with the InstallModbus() function. A detailed description of the dipswitches is available in the hardware reference manual of each HPC. The initialization parameters of the 2 serial ports (master and slave) are not identical: baud-rate, parity and number of stop bits must be the same. The number of data bits must be 8 for MODBUS. The serial port is not in "communication" mode but in "programming" mode. The user program has no control over the serial port as long as it is in "programmer" mode, so don't use a programmer cable on a serial port that is a programmer port also. Is the HPC in RUN mode? A HPC that is not in RUN mode is not executing the user program, so the serial communication with MODBUS isn't working either. The MODBUS slave reacts only to valid MODBUS requests. These are the packets of data that the MODBUS master normally sends. An arbitrary print statement to the serial port of the master will result in an active TxD LED on the master and an active RxD LED on the slave but the MODBUS slave doesn't recognize this arbitrary data, so it doesn't answer. The E.D.&A. HPC's only process binary or RTU mode requests. Requests in ASCII mode are ignored and will therefore not be answered. The MODBUS master is sending broadcasting packets. A MODBUS slave doesn't answer when it receives broadcasting packets, so the TxD LED won't lighten. 7.4 Does the answers go from the slave to the master? If the slave's transmit data LED TxD flashes, it responds to the request of the MODBUS master. The receive data LED (RxD) of the master should also flash. This indicates that the answers from the slave arrive at the MODBUS master. This can be wrong if the RxD LED of the master isn't working: The serial port of the MODBUS master can be in a wrong mode. Most serial ports on E.D.&A. HPC's can work in a RS232 and a RS485 mode. The transmit data LED (TxD) of the master will work normally, but the receive data LED (RxD) remains out in such a case. Check the jumpers or dip-switches that set the mode of the serial port. The mode of the port of master and slave must be the same. The receive data line in the cable might be broken or short-circuited. Again, if the "signal ground line" and one of the "signal lines" are reversed (for RS232) or when the two wires are reversed (RS485), the RxD LED might lighten while the HPC gets garbage data. 7.5 Are the answers OK or do they contain error codes? If the RxD LED of the master flashes, the master's program should now indicate that the MODBUS slave reacted to the request of the master. It's still possible that the slave responds with an error code instead of the requested data, but that is a software or configuration problem. In such a case the master might report a 'protocol error' message. If the MODBUS master is an E.D.&A. HPC, its read or write functions will show an error in their return and status values: If possible, check the request function number, especially if the MODBUS master is not an E.D.&A. apparatus. Return value 111 indicates an unsupported function code in a request. The data address can be too large or the MODBUS master might ask too much data at once. This results in the return value 112. The master might be trying to write an illegal value into a variable. Some slaves accept only a limited range of values. Writing illegal values results in the return value 113. For example, E.D.&A. HPC's programmed in the ABC language accept numerical values in the range from 0 to 9999 only. 26

28 7.6 Do cable problems cause interruptions? Cabling problems may result in permanent or intermittent failures. In an RS485 network, there might be a termination or topology problem. In theory, a communications line should be terminated at both ends and no terminations should appear in-between. In practice, using thin cables may result in other problems. Topology problems may exist if a multipoint network is not built as a bus-topology. Bus topology means one cable hopping from each node to the next, whiteout shunts in between. Star-topology requires the use of repeaters. A communication error because of poor line quality is also possible. This might result in CRC errors or timeouts. One solution is reducing the speed of the MODBUS master and slave to 1200 or 300 baud and see if the communication works then. A better, shielded cable can also solve the problem. Increasing the number of tries of the master may improve things as well. It's much easier to find a problem with the serial line if the communication speed is temporary reduced to 1200 or even 300 baud on the master and the slave system. It will take much more time now for a packet to travel over the serial line, so the transmit and receive LED's will be active longer. It's possible to simulate a MODBUS master with a simple test program on an EPL HPC. This program regularly sends out a row of characters that look just like a request of a real MODBUS master, so the slave will react on it and send an answer back. Pay attention, this program sends a request to SLAVE NUMBER 1. Serial port 1 simulates the MODBUS master; the MODBUS slave is installed on serial port 2. The program is attached as program example 'modsla1.epl'. The easiest way to test this is by connecting the transmit data line (TxD) of serial port 1, (pin 4 on DB9 connectors, pin 2 on DB25 connectors), to the receive data line (RxD) of serial port 2, (pin 2 on DB9 connectors, pin 3 on DB25 connectors). The ground connection is made inside the HPC if the two serial ports are in the same system. The two serial ports must be RS232 ports. It's also possible to use the program if the serial ports are from two different HPC's. A serial communication cable between the two systems is needed then. It's possible to use the same program for the two HPC systems. The LED indicators of the slave serial port show what happens: A flashing receive data LED (RxD), yellow or red: serial port 2 receives the request A flashing transmit data LED (TxD), always red: serial port 2 transmits the answer. So, the MODBUS slave is working properly if its TxD LED flashes. It answers to the requests of the master. 27