Applies To:
  • CitectSCADA 5.xx
  • CitectHMI 5.xx

Summary:
I have setup a VSD with my Citect system to talk via the Modnet driver and an Ethernet-Modbus Gateway. Communications was running fine, but as soon as I add a certain tag, all communication goes #COM and I get a hardware alarm.

The hardware alarm states that "Address is out of range". I have also turned on debugging in the Modnet driver, so in the kernel I see:

Wed Apr 28 10:39:50 2004 20:44:27.297 Error: Address is out of range
READ 0001 PORT1_BOARD1 Hoist 401001 38
Generic 000001 Driver 00008194 (0x00002002)

What does this mean, and how can I avoid this error from occurring? 


Solution:
Some VSDs and remote I/O implement a special version of the Modbus protocol. It responds to all the same Modbus request codes, but they sometimes have a special limit on how many registers can be read using Modbus function code 3. In this specific case, the VSD only allowed 20 continous registers to be read in one request.

From the kernel, we could see the request for a read starting from register 401001, read 38 registers. I.e. read from 401001 to 401038. This is why the VSD is returning the error code 0x2002.

To get around this we need to modify the BIT_BLOCK and MAX_LENGTH Protdir.dbf setting, which dictactes the maximum number of bits that can be read in a single request. The default settings for Modbus and Modnet are:

Modbus:
BIT_BLOCK=400
MAX_LENGTH=2000

Modnet:
BIT_BLOCK=1920
MAX_LENGTH=1920

So in this particular case, the maximum number of bits the VSD will accept, is 20 * 16-bit registers. This is equal to 320. So the new BIT_BLOCK and MAX_LENGTH settings are 320. Once you have modified the entry in the Protdir.dbf file, you must use the SAVE_DBF.XLS macro to save and close the file correctly.

One problem which can arrise from modifying this Protdir.dbf setting is that it effects the performance of the driver. If you have a mix of VSD's and PLC's, each with different performance, the VSD will introduce a reduction in perfomance for the entire system. The prefered method is to have the PLC read and write data to the VSD's and have Citect communicate only to the PLC.

If this is not possible, you can create another Protdir entry for the Modnet or Modbus driver. This will be done for the MODNET driver in the example below:

Step 1. Open Protdir.dbf file, locate entry for MODNET driver. Insert line directly beneath. Copy details from above line to new line. Modify the line so that it matches this:

MODNET1 MODNET 320 320 0x37f

Step 2. Open the save_dbf.xls file to save and close the file.

Step 3. Open the Help.dbf file. Search for the MODNET entry. Create a new line underneath, and copy again the details into the new line. Rename to MODNET1.

Step 4. Again open the save_dbf.xls macro to save close changes to the file.

Step 5. Open the I/O Devices form in the communications configuration of the project. For your special devices like VSD's select the Protocol "MODNET1" from the drop down list. This will now force the I/O device to use the new Protdir.dbf settings. And will not comprimise the performance for other MODNET I/O devices.

Step 6. Make sure incremental compile is not ticked. Pack and Re-compile the project.

Notes:

  • This solution only works for the compile time request size. CTAPI or Alarm servers, trend servers can change the request size dynamically during runtime. The dynamic request size is set by the [Modnet] Maxbits parameter, which should be set to the same value as the protdir settings above. e.g. if you set MAX_LENGTH = 320 in protdir, you should also add [Modnet]Maxbits=320. This is particularly important if you are using CitectSCADA V7.0.
  • If you need to change Citect.ini parameters this will be set for both MODNET and MODNET1 I/O devices. Depending on your application, you might be required to force Citect to load another instance of the driver with special Citect.ini settings. For information on how to do this, contact Citect Support.

See also KB Articles, Q1788, Q2793.

 

Keywords:
MODBUS, MODNET, Address is out of range, 2002, 0x00002002, Protdir  

Attachments