TWinSoft FAQ - Communication

Eng: 1.03 

TBox, TWinsoft 

FAQ, 

tips & tricks 

1. COMMUNICATION 

COMMUNICATION, 

, PROTOCOLS PROTOCOLS, 

, ...

Disclaimer 

Every effort has been made to ensure the accuracy of the information in this guide. However, Semaphore. assumes 

no responsibility for the accuracy of the information. Product information is subject to change without notice. 

TWinSoft and A are registered trademark of Semaphore. 

Windows is a trademark of Microsoft Corp. 

Copyright 

© 2007-2008 by 

Chaussée de Bruxelles, 732a 

B-1410 Waterloo 

Edition: September 18, 2007 

Author: Jean Burton 

Version: 1.03 FAQ, tips & tricks – COMMUNICATION 2

TABLE OF CONTENTS 

INTRODUCTION.....................................................................................................................................5 

1. RESTORE COMMUNICATION WITH TBOX-MS / TBOX-LITE................................................6 

1.1.INTRODUCTION..............................................................................................................................6 

1.2.GLOBAL RESET.............................................................................................................................7 

1.3.TOTAL RESET...............................................................................................................................8 

1.4. GLOBAL RESET WITH TBOX-CPU3.................................................................................................9 

2. MODBUS VS. J-BUS ADDRESSING ISSUE...................................................................................10 

2.1. INTRODUCTION...........................................................................................................................10 

2.2. ADDRESS PREFIX (MODICON STANDARD).........................................................................................10 

2.3. ADDRESS OFFSET (MODICON STANDARD)........................................................................................10 

2.4.MODBUS ADDRESSING OF TAGS IN TBOX.........................................................................................11 

2.5. ACCESSING REMOTE DEVICE FROM TBOX.......................................................................................11 

2.6.ACCESSING TBOX FROM AN EXTERNAL DEVICE (HMI, SCADA, PLC, ...).............................................12 

2.7. ABOUT HARDWARE.....................................................................................................................12 

3. CREATING A REMOTE TAG 'SERIAL': STEP BY STEP...........................................................13 

3.1.SET THE COMMUNICATION CHANNEL..................................................................................................13 

3.2.CREATE THE REMOTE DEVICE........................................................................................................13 

3.3.CREATE THE TAG........................................................................................................................14 

3.4.CREATE THE REMOTE TAG............................................................................................................14 

3.5.TESTING....................................................................................................................................15 

3.6. BLOCK COMMUNICATION..............................................................................................................15 

4. REMOTE TAG: TBOX TAG VS. QUANTITY OF VARIABLES.................................................16 

4.1. WITH ANALOG TAGS...................................................................................................................16 

4.2. WITH DIGITAL TAGS...................................................................................................................17 

5. MODBUS: HANDLING 32 BITS VARIABLES...............................................................................18 

6. MODBUS ADDR. ISSUE WHEN CONNECTING TO MODBUS DEVICES (EXOR, HMI, ...).19 

6.1. EXOR WORKS AUTOMATICALLY WITH ‘BLOCK COMMUNICATION’.............................................................19 

6.2. WORKING WITH ANALOG VARIABLES.................................................................................................20 

6.3. WORKING WITH 32 BITS VARIABLES................................................................................................20 

6.4. DIFFERENCE BETWEEN TBOX-MS -LITE AND TBOX CPU3..............................................................20 

7.COMMUNICATION ERROR – MODBUS EXCEPTIONS.............................................................21 

8. TWINSOFT IS UNABLE TO OPEN A SERIAL PORT..................................................................22 

9. TESTING COMMUNICATION WITH TBOX................................................................................23 

9.1.LEDS OF COMMUNICATION PORT.....................................................................................................23 


10. IP SETTING ISSUES OF THE TBOX............................................................................................24 

1. IP address..........................................................................................................................................24 

2. IP subnet............................................................................................................................................24 

3. Gateway address................................................................................................................................25 

4. IP addresses handling in TBox MS and TBox LITE...........................................................................25 

11. INTERFACING TO SCADA. CLARIFICATION ABOUT OPC.................................................26 

12. TRANSMISSION TIME IN MODBUS PROTOCOL....................................................................28 

12.1. BLOCK COMMUNICATION............................................................................................................28 

12.2.TRANSMISSION TIME...................................................................................................................28 

13.TCP/IP HIGH END DEBUG USING “WIRESHARK”..................................................................29 

14. IP ADDRESS AND MAC ADDRESS ARP TABLE.......................................................................31 


Introduction 

The goal of the FAQ document is to provide detailed explanations on specific topics, to insist on 

certain points and to answer regular questions. 

It does not provide general information on how using TBox, but it can help you to solve 

selective problems while developing a project. 

In order to help you finding the information, the FAQ are divided into different manuals: 

TBox/TWinSoft FAQ documents: 

1. Communication: general information about ModBus, local communication (this 

document) 

2. Modem: all you want to know about dial-up connection 

3. Miscellaneous: all the rest (coming soon) 

You will also find FAQ document about WebForm Studio and TView. 

All those documents available at: http://tbox.biz/uk/telecharg.php --> FAQ/Technical Notes 

There is no hierarchy between the different topics. Unless specified, each topic can be read 

independently from the others. 


1. Restore Communication with TBox-MS / TBox-LITE 

This topic describes how to restore a communication with a TBox and how the firmware and 

application levels are organized in the RTU. 

1.1. Introduction 

In some cases, it may happen you cannot communicate anymore with your RTU, because you 

don't know the settings of the com. port of TBox you are connected to (Baudrate or IP settings 

and/or protocol). 

To test the communication, you use the menu “Communication” “RTU identification”. If it 

does not show you anything, it means you are not communicating with your TBox. 

To restore communication, you can set the RTU to a known, default configuration. 

This is called the global reset of the RTU: you stop the application running in the RTU. 

This operation does not erase the application, but stops it. 

A single push on the 'Reset' button will restart the application. 

The procedure for TBox CPU-3 is explained at chapter 1.4. 

Previous to act on the application, let's see how the different software levels are organized in 

TBox. 

The software is organized in three levels, with: 

Application 

O.S. 

Loader 

1. the application 

it corresponds to the development done with TWinSoft 

2. the O.S. (Operating System) 

it contains all features on TBox (alarms, datalogging, process, TCP/IP, ...) 

3. the loader 

it handles local communication in ModBus protocol 


1.2. Global reset 

With TBox MS and TBox LITE you maintain the reset button to ‘Reset’ position and let the 

LED 'Run' flashes 3 times. You release then the button. The application stops and the RTU 

runs with the Operating System (O.S.). 

The LED 'Run' flashing at ½ Hz indicates the application is stopped. 

Application 

O.S. 

Loader 

Factory OS settings: 

- Station address (ModBus)= 1 

- Serial ports = 9600, N, 8, 1 - protocol: ModBus-RTU 

- IP address = 192.168.1.99 - protocol: ModBus/TCP 

Once the global reset has been carried out, you adapt TWinSoft “PC Setup” (from the main 

menu “Communication”) to the current TBox configuration (see O.S. settings above). 

Then you test communication doing 

from the main menu, 

Communication RTU 

identification. 

The following information (adapted 

to the model of TBox you are using) 

must be display: 

Then you can send your own program, with new communication settings. 

If you had sent the sources of the application to the RTU, you can then also retrieve it from 

the menu “Communication “Download” Program sources”. 

If you wish to re-start you the RTU, without modification, press the button once to the 

'Reset' position. The application restarts. 


1.3. Total reset 

The total reset may be needed in very rare situation, but at least you will understand what 

happens if you press longer the button 'Reset'. 

To carry our a total reset, you maintain the reset button to ‘Reset’ position and let the LED 

'Run' flashes 5 times. 

The RTU is back to the loader level (below the O.S. level). In this mode, you can only send 

an OS to the RTU (“Communication” “Upload” “Operating System”. 

Application 

O.S. 

Loader 

Factory Loader settings: 

- Station address (ModBus)= 1 

- Serial ports = 9600, N, 8, 1 - protocol: ModBus-RTU 

- IP address = NO Ethernet available 

As you can see, you can only communicate through serial port. 

Then you test communication 

doing from the main menu, 

communication RTU 

identification. 

The following information 

(adapted to the model of TBox you 

are using) must be displayed: 

If you change your mind just after the reset, press the button once to the 'Reset' 

position. The O.S. and application will restart. 


1.4. Global Reset with TBox-CPU3 

With previous generation of CPU, the philosophy of Global Reset and Total Reset are similar, 

but the way to achieve them is slightly different. 

You will use the two small push buttons on the front “PGM” and “RST”: 

– Press and Hold “PGM” 

– Press and Release “RST” 

– Let the LEDs flash 2 times (4 times for the Total Reset) 

– Release “PGM” 

The LED “USR”, after a Global Reset, must be flashing at ½ Hz. 

Features “O.S.” settings “Loader” settings 

Station address 

COM1, COM2, COM3 

COM4 - PSTN 

COM5 - PCMCIA 

COM5 - PSTN 

Protocol 

Ethernet 

9600, E, 8, 1 

V22 

V34 

V34 

ModBus-RTU 

NO Ethernet 

1 

9600, E, 8, 1 

V22 

Not available (*) 

Not available 

ModBus-RTU 

NO Ethernet 

(*): the modem will pick-up the line and synchronize, but there is NO communication. 


2. ModBus vs. J-Bus Addressing issue 

This topic describes basics in ModBus protocol addressing. 

2.1. Introduction 

ModBus is a very simple protocol and very easy to communicate with. It is based on: 

- Station number (0 .. 255) 

- Function index (standard functions: 1, 2, 3, 4, 5, 15, 16) (read, write, digital, analog, 

simple, ....) 

- Address (0.. 65535) 

Historically, Modicon created ModBus-RTU protocol and was the only one that could use it. 

Other companies should use J-Bus (differences explained below) 

To make things clearer for their users (!), Modicon fixed some rules. 

2.2. Address prefix (Modicon Standard) 

As a PREFIX of the address, they indicate an index, telling which kind of variable is concerned: 

Examples: Prefix '0' Coil 

Prefix '1' Digital Input 

Prefix '4' Holding register 

Then following this prefix, they decided that the ModBus address would have maximum 4 

characters: 0000 9999. 

Examples: 

1xxxx = addressing a digital input 

4xxxx = addressing an analog register 

2.3. Address offset (Modicon Standard) 

They decided that the first address '0' would become '1'. 

This has given the distinction between ModBus (start at '1') and J-Bus (start at '0'). 

ModBus (Modicon) and J-BUS are identical, and every one speaks commonly of ModBus. 

But to be exact, TBox supports J-Bus. 

Example: 

If you have a SCADA using the 2 rules presented above, if you want for instance to read the 

TBox analog register at address 123, you will indicate in the SCADA with the Modicon syntax: 

40124. 

But the real address (used in the transaction) is 123. The prefix “4” is not part of the 

address. 


2.4. ModBus addressing of Tags in TBox 

The ModBus address of variables in TBox is always a REAL address (NO prefix, NO offset). 

ModBus addressing of Tags depends on the family of TBox. 

With CPU-3: 

All variables have predefined address you cannot change. 

Examples: 

second=22016 

AIR0=20480 

Ana0 of the CPU=64 

Float0=23040 

With TBox-MS, -LITE, -LP: 

All variables can be assigned any free ModBus address: 

2.5. Accessing Remote Device from TBox 

To read/write data in external devices with TBox, you use Remote Tags (see details chapter 3.) 

The external variable you want to read/write is indicated into the Remote Tags with its real 

ModBus address. 

Depending on the documentation you receive from the manufacturer, you may have to adapt 

the addressing indicated into the manual. 

The trick is to try different addresses, one by one: adding 1 unit, removing 1 unit, removing 

possible prefix, ... 


2.6. Accessing TBox from an external device (HMI, SCADA, 

PLC, ...) 

When an external device using Modicon standard has to access TBox, the format of the address 

(max. 4 or 5 digits) might be an issue. 

Working with CPU-3 

If the format of addresses supported by the SCADA allows only 4 digits, you have to use the 

driver “NewMap” to remap the addresses to 0000 9999, as the addresses in CPU-3 are 

fixed. 

Working with TBox MS and TBox LITE 

There is no problem as you can adapt ModBus address for each Tag (see above). 

Think also about the prefix and the offset. If your SCADA uses the genuine Modicon syntax, the 

address might be like: 4xxxx (to access an analog variable), or 1xxxx to access a digital 

input, ... If the SCADA uses an offset: xxxx=TBox Tag address + 1 

2.7. About Hardware 

Sometimes there are also hardware problems, linked to the fact that one device answers too 

fast, or that a Remote Device reacts too slow, because communication is not its main task. 

- TBox working as a 'slave', 

if TBox answers too fast for the Master, this can be adjusted by 

increasing its 'end of frame detection' of the COM port, in COM port 'Advanced' 

parameters. 

For instance 50 msec. or more. 

As of TWinSoft 10.xx and OS 3.14.xxx, the 'end of Frame' detection is replaced by 

'Incoming Frame Detection' and works in automatic. 

- TBox working as a 'master', 

to avoid TBox starting transactions one after each others to 

quickly, when for instance one 'slave' is still in the answering phase, you can add an 

'IFG' (Inter Frame Gap). 

We suggest IFG should be of minimum 10 ms. (8 ms. With CPU3) 


3. Creating a Remote Tag 'Serial': Step by Step 

This topic describes how to establish a communication between TBox and another ModBus 

device; typically another TBox. 

Do a new clean project! 

3.1. Set the communication channel 

- From the 'Resources', go to 

the tab 'Parameters' of the 

com. port you will use. 

- Select the same Baudrate as 

the one of the device you are 

connected to. You must 

KNOW it, don’t guess it! 

- Select the same data, parity 

and stop bits as the device. 

You must KNOW them. 

- Select the protocol : ModBus- 

RTU 

- In the tab 'Advanced', declare 

an inter-frame gap of 10 ms. 

- Tag the communication 

variable from the COM port, 

tab 'DCV', 'ComX.Noreply' 

3.2. Create the Remote Device 

From the “Resources” “List of I/O”, 

create a “block of I/O” 

- Select “ModBus Device” 

- Type the Station ModBus address of the 

slave 

- Select the COM port of the TBox 

connected to the device 

example: COM2 - RS485 of CPU 

- Select a digital Tag (internal variable) 

used as Trigger, to activate the 

communication. Select the condition 

“High State”. 

The Tag must be initialized to 1. 

Example using COM2 – RS485 of MS-CPU16 


3.3. Create the Tag 

In the below example, the Tag will receive ONE analog value read from the device (let's start 

with one!). 

You have to know the format of the Tag you want to read in the device (8bits, 16bits, 

32bits, float?) and create a Tag with the same format in your TWinSoft project. 

Don’t guess the type, you must know it! 

Concerning Analog Tags, as ModBus only defines addresses of 16bits variable, if the Tag 

you select is of format 32bits, TBox will automatically build a request for 2 addresses. 

3.4. Create the Remote Tag 

A Remote Tag corresponds to a transaction with a Remote Device. It associates a TBox Tag to 

an address in a Remote device. 

In the Remote Tags folder of the TWinSoft project, create ONE Remote Tag. 

- select the Tag you have created (see above). 

- select READ. 

- Quantity=1. 

- Select the remote device you want to read. 

- Chose the type of register you read: Don’t guess it! 

Click “Help” to choose the type. A table associates the types with ModBus Functions. If you 

chose the wrong one, you may have communication errors! 

Check in the documentation of the device to verify which ModBus functions are supported. 

Don’t guess it! 

- Select the address of the remote device you want to read: if the device uses Modicon 

standard, remove the prefix of the address and subtract 1 from the address number: eg. 

3041 -> 40 (see also chapter 2. above). 


3.5. Testing 

Cable the TBox to the remote device. 

Check if the remote device has the same port settings and is in Slave mode, it means it has no 

'Master' configuration. 

Check also the pin out correspondence for the RS485 between the slave and the TBox. 

Upload the project in the TBox and look at the LED 

if the cabling is good, TxD of the TBox must blink to indicate the sending of request. 

If RxD is blinking, it means that Modbus frames are returned by the device 

Results 

To check if TBox receives a value, try to change its value using the key in the list of Tags. 

If the value you type is maintained, there is no communication. 

If you have 'ComX.Noreply' = 1, it means you do not have right communication (time out, 

wrong cabling, wrong CRC for the frame) 

This variable is SET by the OS. Reset it ( in the list of Tags) and check it again. 

3.6. Block Communication 

You can also try a block communication as some devices only answer by block of 8 

addresses especially when transferring digital data: 

- Create 8 Tags of the SAME TYPE with SUCCESSIVE ModBus addresses in TBox 

- In the Remote Tag you declare as Tag the FIRST one and quantity to 8 

- In the Address field, type the ModBus address of the FIRST variable in the slave 

(corresponding to the first of a block of 8 SUCCESSIVE addresses), having the SAME TYPE 

as the one of the Tags in TBox. 

Upload the project in TBox and check that the LED RxD and TxD of the RS485 port blink. Then 

check with TWinSoft the value of the Tags. 


4. Remote Tag: TBox Tag vs. Quantity of Variables 

Chapter 3. above describes the principle of Remote Tags. This topic describes the relation 

between the formats of Tag (8bits, 16bits, 32bits, Float) and the quantity. 

4.1. With Analog Tags 

ModBus protocol is built on 'Bytes', and as far as analog is concerned, it defines the way of 

transferring 16 bits variables. 

Each 16 bits variable corresponds to ONE ModBus address. 

But with ModBus it is possible to exchange 32 bits variables like DWORD or FLOAT 

If you want to exchange DWORD or FLOAT, see also chapter 5. about Handling 32 bits 

variables). 

In Remote Tag configuration of a Analog Tags, the quantity relates to number of variables (not 

to ModBus addresses). 

Examples: 

Operation / Qty / Format ModBus addresses 

of the TBox Tags 

Read / 8 / 16 bits 20480 

20481 

20482 

20483 

20484 

20485 

20486 

20487 

Read / 4 / Floats 22400 

22402 

22404 

22406 

Write / 2 / 32 bits 1000 

1002 

ModBus addresses 

in Remote Device 

1200 

1201 

1202 

1203 

1204 

1205 

1206 

1207 

600 

602 

604 

606 

20000 

20002 

ModBus addresses are chosen as example 

Remarks 

Successive ModBus 

addresses, one by one. 

Successive even 

addresses, as 32bits 

variables need TWO 

addresses. 

Successive even 

addresses, as 32bits 

variables need TWO 

addresses. 

You see how important it is that the format of the Tags of TBox must be the same as the 

format of the variables you want to retrieve! 


4.2. With Digital Tags 

ModBus protocol is based on 'Bytes', and as far as digital is concerned, it transfers digital 

information through Byte(s) (= 8 bits). 

Each Bit corresponds to ONE ModBus address. 

ModBus protocol supports transfer of less than 8 bits. In this case, some bits are not 

interpreted. 

In Remote Tag configuration of Digital Tags, the quantity relates to number of bits (= ModBus 

addresses). 

Working with quantity higher than 8, be sure that everything is multiple of 8: 

– ModBus address of the First Tag 

– Quantity 

– ModBus address of the first variable to access in the remote device. 

With Digital or Analog, check there is no gap in ModBus addresses when working with 

blocks (Quantity > 1). 

Reading block data to TBox MS and TBox LITE (as Slave), if all Tags have not been 

created it will lead to communication errors. 


5. ModBus: handling 32 bits variables 

This topic describes how TBox uses ModBus protocol to handle 32 bits variables. 

The ModBus protocol description does not specify anything regarding 32 bits registers. 

The protocol based on transfer of , describes only 'Boolean' and '16 bits' data 

transmission. 

Therefore, transmission of 32 bits is declared as 2 x 16 bits transmission, corresponding 

internally to 2 x ModBus addresses. Then each manufacturer has to determine a way of 

organizing the bytes with 2 possibilities: Little Endian or Big Endian. 

With TBox families and associated software's (TWinSoft, TView, TComm, ...), bytes are 

transferred in order HI to LO, the same as when transferring a 16 bits (corresponding to Big 

Endian): 

- 16 bits: , , 

- 32 bits: , , 

Example with a Floating point register: ModBus addresses are chosen as example 

Float value : 0.02 

Value in hex.: 3CA3D70A 

Hi Word: 3CA3 (ModBus address 100) 

Lo Word: D70A (ModBus address 101) 

In the frame: ...... 

From HMI, this way of addressing 32 bits is sometime indicated: 

INV FLOAT and INV DWORD 

In case an external device connected to TBox works “from the other side” (little endian), you 

have to invert data of both addresses using BASIC functions ‘Split32’ and ‘Pack32’: 

' Splitting the 32 variables to two 16 bits registers 

Split32(Input,High_W,Low_W) 

' Packing the two 16 bits registers in the other side. 

Pack32(Output,Low_W,High_W) 


6. ModBus Addr. Issue when Connecting to ModBus 

Devices (EXOR, HMI, ...) 

This topic answers questions on how addressing TBox variables in HMI, with EXOR UniOp as 

example. 

This is a general discussion regarding block read and write from any ModBus device to TBox. 

Here is the situation when working with EXOR UniOp, an operator panel that can be supplied 

with TBox. 

The same rules can be applied to any ModBus HMI. 

The issues relate to the connection between Tags in the HMI and Tags in the TBox. 

Some basic rules have to be respected. 

➢ Working with TBox MS and TBox LITE, ModBus addresses of their Tags are not fixed. 

For each Tag, you can change its ModBus address. 

➢ Creating Analog Variables you can also define their format (8 bits, 16 bits, 32 bits or 

Float). 

In order to have the best performance with EXOR, you should be careful about the following 

points. 

6.1. EXOR works automatically with ‘block communication’ 

Working with digital Tags: always be sure that you have defined in TWinSoft blocks of 8 

consecutive ModBus addresses, starting at a multiple of 8. 

Example: you have 9 digital inputs you want to display in EXOR. 

EXOR will ask TBox values for 16 addresses, starting at the first one which must be 

multiple of 8. 

Check in the TBox application the first one has an address multiple of 8 and that 

you have created Tags to have a total of 16 successive ModBus addresses. 

Working with Analog Tags: always be sure that you have defined in the TBox application Tags 

with consecutive ModBus addresses. When it is possible, EXOR builds automatically a block 

from the first ModBus address until the last ModBus address. You can’t leave a gap in the TBox 

addresses. 

Be careful of the Floats/32 bits limitation in a communication block of TBox CPU3. Indeed, 

the maximum quantity of floats/32 bits that the TBoxCPU3 can manage in a communication 

block is 8. For example, if you read the floats 4, 8 and 13, EXOR makes a block of 9 too big 

for the CPU3. The solution is working without communication block using the option “No data 

blocks” in “Project configure controllers select protocol controller setup”. 

If one of those rules is not respected, EXOR will return communication errors. 


6.2. Working with analog variables 

Check you have a block of variables of similar type (16 bits, float,…) with consecutive 

ModBus addresses. 

6.3. Working with 32 bits variables 

For such data, there are two ways of interpreting the data: from left to right and from right to 

left. TBox interprets the 4 bytes of 32 bits from left to right (also known as Big endian). 

In case the HMI interprets them in another order, you should use BASIC functions ‘Split32’ and 

‘Pack32’ to reorder the bytes (see chapter 5. above). 

Concerning EXOR: 

– to display ‘Float variables’ you should select the Data field format: INV FLOAT 

– to display ‘Long-32 bits’ select the Data field format: INV DBL WORD 

It is always possible to change EXOR communication settings to work without block 

communication (see EXOR manual, chapter 4.: PLC Setting PLC Comm…), but for 

performance reason, we advise to keep block communication and adapt Tag settings 

in TWinSoft. 

6.4. Difference between TBox-MS -LITE and TBox CPU3 

In TBox CPU-3, all ModBus addresses exist by default. Then, even if you have not tagged 

variables (I/O, AIR, DIR, STO, ...), the ModBus addresses exist. 


7. Communication Error – Modbus Exceptions 

This topic explains the principle of communication error codes called “Exception Codes” 

When a bad request is sent to a TBox MS and TBox LITE (TBox = Slave), it responds with 

error codes (called exception codes). This helps you to find which parameter is wrong. 

Byte 0 : The Station address of the RTU 

Byte 1 : Modbus function in error + 80h 

Byte 2 : Code which specifies the error 

Byte 4 : CRC16 High 

Byte 5 : CRC16 Low 

Example : 

01 Illegal function 

02 Illegal data address (Modbus address) 

03 Illegal data value 

04 Slave device failure 

05 Acknowledge 

06 Slave device busy 

07 Negative acknowledge 

08 Memory parity error 

The master sends 01 04 50 00 00 01 20 CA 

In details: 01 = Slave device Modbus address 

04 = Modbus function (Read analog variables) 

50 00 = Tag Modbus address (50 00 h = 20480 d) 

00 01 = Quantity 

20 CA = CRC16 

The slave responds the following exception code 01 84 02 C2 C1 

In details: 01 = Slave device Modbus address 

84 = Modbus function (04) + 80 h 

02 = Illegal data address 

C2 C1 = CRC16 

Conclusion : The master tries to read a Tag with unknown ModBus address. Typically, when 

using TBox MS and TBox LITE, it correspond to a missing Tag in your TWinsoft program. 

To understand how the Modbus protocol work, you can use the free software 

“ModBus tester” available on our website : 

“http://www.tboxsupport.biz/free_downloads/ModBusRTUTester.exe” 


8. TWinSoft is Unable to Open a serial Port 

This topic relates to TWinSoft PC Setup and relation between TWinSoft and Windows. 

Setting TWinSoft to communicate with a serial port (from the menu “PC Setup”), it may happen 

that you receive the message: ”TWinSoft is Unable to Open the Communication Port’’. 

It usually means the Communication port has already been captured by another Windows 

application. 

You must verify if you do not run another application using the same serial port. If you do not 

find anyone, you must open the ‘Windows Task Manager’ (press Ctrl+Alt+Del) and verify in the 

‘Applications’ tab, then in the ‘Processes’ tab, that that there is no TWinSoft, TView, 

Hyperterminal, ... process already running (former processes that have not been closed 

properly by Windows). 

If it is the case, close the process(es). 

Some programs, like PLC programs may have installed a driver that takes over the serial 

port. In such case, the driver should be disabled. 

If you removed all the applications using the communication port which were running, you 

should be able to use the port in TWinSoft again. 

If this still does not work, reboot the PC and start TWinSoft before any other task. 

Working with USB Serial interface, be sure of the ID of the COM corresponds to 

the one you are using. 


9. Testing communication with TBox 

This topic illustrates how you can use 'Communication Variables'. 

TBox provides diagnostic variables to monitor communications. For each communication port, 

TBox provides internal variables indicating different status of the port. 

Working with TBox MS and TBox LITE those variables are accessible from the tabs 'DCV' and 

'ACV' of each communication port. 

Working with CPU-3, those informations are available from the “Resources” “Digital and 

Analog Special Registers”. 

Example with TBox MS16 of testing on COM2 (RS485) the quantity of communication errors 

and the time the communication error lasts. The variable used is the DCV [Com2.NoReply] 

Alarms and Datalogging 

You can combine those tests with alarms and datalogging features. 

For instance with the above example, the Tag 'Timer1_Status' could be declared as digital 

chronology and/or Alarm condition. 

9.1. LEDs of communication port 

LEDs are very useful as first verification of communication validity: 

➢ With TBox MS each serial port and modem are equipped with individual Tx and Rx 

LED. 

➢ With TBox CPU-3, there are common LED Tx and Rx for all communication ports, 

except Ethernet port. 

To test ONE port, you should remove connector of the other ports. 


10. IP Setting issues of the TBox 

This topic answers basic questions related to IP addresses in TBox. 

1. IP address 

Each port (all interfaces included) must have a unique IP address 

In case you don't follow this rule, result might be unpredictable and might cause lots of 

communication trouble. 

TBox does not support DHCP (dynamic IP addressing). TBox requires for any of its Ethernet 

port, a fix IP address. 

2. IP subnet 

Be sure the different interfaces are defined into different subnets. 

The possible interfaces are: Ethernet of the MS-CPU16, each Ethernet of MS-CPU32, MS- 

ETHER, MS-ETHER4, modem. 

The subnet is built from the IP address and the subnet mask. 

Example: 

IP: 192.168.1.99 

Mask: 255.255.255.0 

The subnet: 192.168.1.xxx (any address in the range 192.168.1.xxx). 

About the modem subnet, it 

concerns the RTU acting in 

'Server' mode (receiving call). 

You access its configuration 

from the Advanced RTU 

properties TCP/IP. 

Define a range which is in a 

different subnet than any 

Ethernet Port of the CPU. 


3. Gateway address 

You need the Gateway address for outgoing 'Client' connection, to access an IP address which 

is not in the current subnet. For instance when sending e-mail or FTP using an external 

Server. 

The gateway address is always 

in the same subnet as the IP 

address 

4. IP addresses handling in TBox MS and TBox LITE 

IP Forwarding is one of the features of TBox MS and TBox LITE . IP forwarding uses the 

following rules: 

➢ If you send a request to an existing IP address of the subnet, the device will answer. 

➢ If you send a request to an unknown IP address, AND IP Forwarding is not activated, 

the request is lost. 

➢ If you send a request to an unknown IP address, AND IP Forwarding is activated, the IP 

address is tested with all interfaces, starting with the CPU. 

If IP address fits with an interface, the interface will answer (like point 1. here above). 

Otherwise, the request is lost. 

The same in a “computing” format: 

1. If (Dest.IP == Netif.IP) then OK --> TCP/UDP, ... else 2. 

2. If (IP Forward?) then 3. else Discard. 

3. For (all NetIf's) 

if (Dest.IP & NetIf.Subnet?) 

if (Dest.IP==NetIf.IP) then OK --> TCP/UDP, ... 

else IP Output --> Forward 

next for 

Discard 

Dest= Destination 

NetIf= Network Interface 


11. Interfacing to SCADA. Clarification about OPC 

This topic presents different ways a SCADA software can communicate with TBox. 

TBox's native language is ModBus (RTU, ASCII, TCP). 

For Tag sampling, TBox uses standard ModBus functions, but as TBox supports 

datalogging and alarming, some extra ModBus functions that support time-stamping have 

been implemented. 

Then, the protocol TBox uses could actually be renamed "time-stamped ModBus". 

If a SCADA software wants to communicate with a T TBox and only read locally on-line values, 

then you can use standard ModBus protocol (to be more accurate: "J-Bus" protocol. See 

chapter 2. above). 

Note also that besides embedded ModBus protocols, TBox supports other standard SCADA 

protocols: IEC-60870-5-101, -104, DNP3.0, TG800, DF1 serial. 

If any customer or SCADA software editor wants to interface their software to TBox and be able 

to retrieve historical database or alarms, they have several options. 

1. First solution is to write a new driver from scratch knowing the custom functions and 

memory organization. This is hard work and the customer should sign a non disclosure 

agreement. The disadvantage of this method is also that if we make any change in the 

TBox features, or memory organization in the future or if we add new hardware, the 

developer will have to develop new code and will have to recompile the whole thing. 

For those reasons, we don’t allow users to do this. See next solution. 

2. Second solution is to use the "TCOMM.dll" library. The TCOMM handles all difficult 

part of the download mechanisms for the programmer so the development of a TBox 

interface becomes much easier. One limitation: TCOMM supports only Windows 

environment, so no Linux, no Unix... 

TCOMM is free of charge and can be downloaded from our WEB site at: 

http://tbox.biz/TComm/TComm_dll.php. On this WEB page, you'll find an executable file 

that will unzip the library files and gives you the appropriate technical documentation 

(PDF format), examples on how to implement the API's in your SCADA. 

NOTE: TCOMM does not handle the dial up features to the outstations. Those features 

must still be implemented on the SCADA side. 

The following SCADA manufacturers have already implemented the complete TBox driver 

using TCOMM: Wizcon (Axeda – USA), Factorylink (USData - USA), Citect (Citect - 

Australia: driver developed by the french distributor of Citect), Cimview (Aspentech - USA), 

Winlab (Germany), Topkapi (Areal - France), Tablegrabber (Projex - The Netherlands), 

Acron Connect (Dataforum - Germany), ViewStar (Cegelec - Germany), Cube (Orsi-Siemens 

- Italy), PView (Endress+Hauser - Italy), Comsat (Onyx-T+ - France), LabView (National 

Instruments - USA), PANORAMA (France). Most of those drivers have a license fee. 


3. Third solution is to use OPC. 

OPC topology is: 

TBox OPC “Server” OPC “Client” SCADA 

OPC concept: 

OPC “Server”: ModBus/OPC interface to TBox 

OPC “Client”: SCADA driver that connects to the “Server” 

OPC-DA: version “Data Access” of the driver. Standard for local sampling only. 

OPC-HAD: version “Historical Data Access”. This version should be the best solution 

to collect time-stamped data in TBox but is not supported by any SCADA! 

Our Slovenian distributor has recently developed an OPC server dedicated to download 

data through modem. This OPC Server supports all TBox models (standard TBox, Low 

Power devices LP100, LP200 and LP300, TBox MS and TBox LITE). 

For all technical and commercial information about this OPC Server, please contact Mr. 

Tomaz Remih at ELLAB: tomaz.remih@ellab-tr.si 

Another solution, based on OPC-DA, adapted to “time-stamped data” has been 

developed by the French company TECHNILOG. 

Contact person: Eric Decke at eric.decke@technilog.com. Tel: +33 (0)1 69 18 73 00 

4. The newest solution is to use our TVIEW software. TVIEW should be seen as an 

intelligent front-end collecting data from any TBox outstations. 

TVIEW can collect data by two ways: 

Push technology: TBox send data through e-mail or FTP and TVIEW collects it. 

Pull technology: TVIEW dials TBox and retrieve data. 

TVIEW allows on-the-fly export of data to all RDBMS, incl. SQL, Oracle, Access, etc... 

A presentation of TVIEW can be found on http://www.cse-semaphore.com/products/tbox/t-view.php 


12. Transmission time in ModBus protocol 

This topic deals with ModBus protocol and the transmission time. It also illustrates the 

advantage of using 'Block communication'. 

12.1. Block Communication 

TBox can communicate in 'Block' in both 'Slave' and 'Master' mode (see also chapter 3.6). 

It means it transfers data of several Tags in one transaction. This reduces data overhead and 

therefore communication time. 

The rules to use Block communication are: 

– Format of Tags 

Identical format of Tags in one block (Bool, Word, Float, ...) 

– ModBus addresses 

Tags with successive ModBus addresses 

– Digital Tags 

Working with quantity bigger than 8, you have to work with multiples of '8' 

12.2.Transmission Time 

The transmission time depends on Baudrate and quantity of data transmitted. 

In TWinSoft on-line Help, you can find general info about 'ModBus protocol'. 

REMINDER: 

Working at 9600,N, 1 byte transmitted correspond to 10 bits (1 start bit - 8 data bits - 1 stop 

bits) 

Example: Reading 8 x analog 16 bits variables 

Question: 8 bytes: 

[Station - Function - Ad(1) - Ad(2) - Qty(1) - Qty(2) - Crc(1) – Crc(2)] 

Answer: 21 bytes: 

[Station - Function - Qty - Data1(1) - Data1(2) - Data2(1) - Data2(2) - Data3(1) - 

Data3(2) - Data4(1) - Data4(2) - Data5(1) - Data5(2) - Data6(1) - Data6(2) - 

Data7(1) - Data7(2) - Data8(1) - Data8(2)- Crc(1) - Crc(2)] 

Time: 

Question: 8 * 10 = 80 bits. At 9600 bps= 1/9600 * 80 = 8.3 ms. 

Answer: 21 * 10 = 210 bits. At 9600 bps= 1/9600 * 210 = 21.8 ms. 

To this time, you have to add ModBus timeouts: 

End of frame detection: which is 3.5 the time of transmitting one character 

IFG (time before sending the next question): default = 10 ms. 

Then the total time between two questions is: 8.3 + 3.5 + 21.8 + 3.5 + 10 = 47.1 ms. 


13.TCP/IP High End Debug using “WireShark” 

This topic explains how to trace a TCP/IP connection using the free ware “WireShark” in case 

of communication problem. 

Here is the reference to a Window software (Wireshark) to spy TCP/IP communication from a 

PC. 

You have to install the following software: http://www.wireshark.org 

You cable TBox and PC to the same HUB. It is important to use a HUB because we are sure we 

see exactly everything going to the TBox. 

Start the program ‘Wireshark’. Do not be impressed by the complexity of the interface! 

From the main menu, go to Go to the “Capture” → “Options...”: 

Set the above configuration (note the ‘Ethernet driver’ interface type. Depending on Ethernet 

interface available on your PC, you should find something similar). 

Click “Start” 


Further on, to capture new trace, you can click directly from the main menu: 'Capture' 

'Start'. Do capture without filter (like example here above), then we are sure we get everything. 

To stop capture, press button Stop in the Capture window. 

A display filter could be use to filter data and make analyze easier. Typically, you will declare 

the IP address of the PC or the TBox. 

From the button 'Filters', create a filter with the IP address of the PC. The syntax is (example) 

‘ip.addr == 192.168.1.50’ 

Example of Modbus TCP communication with TwinSoft : 

A trace can also be saved with the extension ‘.ACP’ 


14. IP address and MAC address ARP Table 

This topic explains how to erase the APR table in case of Ethernet communication problem. 

The MAC address stays for Media Access Control Address. Each Ethernet interface has a hard 

coded unique MAC address which identifies it in the network. 

A PC has a table called ARP table which associates each IP address to MAC address. If you 

connect several TBox having identical IP address (typically 192.168.1.99), it will be possible to 

communicate only with the first one. 

When you do not succeed to connect a TBox through Ethernet using TWinSoft and you are sure 

of the IP address of your TBox, erase the ARP table may solve the problem. 

Open a prompt window: 

To know the Mac address corresponding to an IP address: 

- Connect first to the equipment with your PC, to refresh the ARP table in the PC. 

- Type he command “arp -a ”: 

To erase completely the ARP table of your PC, type the command “arp -d” 

Under VISTA: Open the Command Prompt window by right-clicking the link and selecting 

“Run as Administrator.

TWinSoft FAQ - Communication

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?