Situation:
The PCD is configured as Modbus client with the Saia-Modbus client F-Boxes and you have to communicate over Ethernet with a Siemens S7-314C-2 with the Modbus protocol.
Randomly, some read or write F-Boxes are working fine and others not.

Problem:
The problem is that the Siemens device sends a ‘reset’ telegram after sending the response to the PCD.
Since the PCD has received the response from the Siemens, the PCD does exit from the Modbus communication state machine and end the task correctly.

If the PCD now receives this unexpected ‘reset’ telegram from Siemens device, then the PCD thinks, that this is an error message from the Siemens device and does close the communication and the F-Box goes in error state.

The transmission/reception F-Box which is in the queue to proceed the next Modbus request is now no more able to communicate with the Siemens device.

Solution:
Use the Modbus Initialization Client Extended F-Box.
In this F-Box you have the possibility to set a minimum request delay.
Set the minimum request delay to 100ms

This problem occurred for example with a Simatic S7-314C-2 Siemens device.

As the hardware probes do work as USB dongles for the software Serialtest Async (version 10.12.22.0 and later), the according USB drivers need to be installed before starting the installation of the software.

Procedure for installing Serialtest Async

• Make sure your hardware probe (USB probe for RS232 or RS485 networks) is up to date
• Get the right USB device drivers for Windows
  in case you'll install Serialtest Async 10.12.22.0 you can use the driver files attached to this FAQ
• Plug the USB probe to your PC
• When Windows asks you for the driver files, browse to the (unzipped) driver files (e.g. the ones from this FAQ)
• Once the USB device is successfully installed, launch the installer for Serialtest Async from Frontline Test Equipment, Inc.

In this FAQ a Modbus data exchanged between a CLIENT and a SERVER displayed with the Wireshark analyzer is explained.

The below telegrams are produced by using the SBC Modbus FBox library.

Protocol: Modbus/TCP
Used port: 502 (default for Modbus)

Modbus Client: (PCD3.M3330)
IP Address: 172.16.1.45

Modbus Server: (PCD3.M5540)
IP Address: 172.16.1.46
UID: 33 (Unit Identifier)




Modbus telegram request:

function(code):
--> indicates what kind of REQUEST is sent to the SERVER (READ or WRITE)
--> indicates on which of the Modbus variables the request will be applied (HOLDING REGISTER, INPUT-REGISTER, DISC-INPUT, COIL)

reference:
--> indicates the address of the first Modbus variable/media which the request accesses.

word count / bit count:
--> indicates the number of Modbus variables/media which the request accesses.

byte count:
--> indicates how many bytes shall be read/written from/to the corresponding Modbus variable/media.

Data:
--> contains the required data from the request.

In some cases (if the Modbus server is rather slow) a minimum delay between two Modbus requests (which are sent by the Modbus client) is to be respected (e.g. if the server needs some time to correctly prepare its next response).

If the Modbus client (or master) doesn't respect this minimum delay time the Modbus server (or slave) can't treat all requests which will lead to communication errors.

How to define a minimum delay between two Modbus requests?
In PG5 1.4.300 (or higher) with version 1.0.17 (or higher) of the SBC Modbus FBox library it is possible to delay the request sent by a ModBus client to a Modbus server each time the request is sent.
The same function is available for PG5 2.0.110 (or higher) with the version 2.6.101 (or higher) of the SBC Modbus FBox library.

You can configure this Minimum Request Delay parameter either in the Init Client TCP extended FBox or in the Init Client RS extended FBox.

The TME Ethernet Thermometer can be connected over Modbus TCP to a PCD that supports Modbus.

Problem
Since the documentation for this thermometer is very limited regarding Modbus it is only possible to connect it via reverse-engineering. This is why we did a test.

Solution
The thermometer has a Web-Interface. With the base IP address it is possible to connect to the thermometer and set an IP address that corresponds to the network.
Afterwards the thermometer can be connected to the network. The temperature is available over Modbus TCP on "Input Register" 0. It is a 16 bit signed value. If more than one thermometer is in the network, each thermometer needs a different IP address, since they all have UID 1. A small demo project for the SBC-Modbus and Engiby-Modbus solution is attached to this FAQ.
In the attached PG5 program example the thermometers have the addresses 172.16.1.66 and 172.16.1.64.

Status Register
The following "Input Register" 1 contains the status of the thermometer. It is 0 if the thermometer is working correctly and it changes to 1 in case of error. If necessary you can read 2 "Input Registers" 0 and 1. The first will contain the temperature and the second the status.

Yes, this is possible.

Server
As Modbus Server you have to define the local port. Per example Port number: 502.

Client
As Client you have to define the remote port. Per exampe Remote Port number 502

If the PCD is server and client at the same time the local port can be 502 and the remote port can be 502 as well.

This FAQ contains a list of the main differences between FBox library versions for Modbus (SBC version).

Version 2.6.220 (April 2012)

• FBox "Define Unit Server":
  The FBox has a new option for the "Unit ID" (UID) to take the value of the:
  - S-Bus station
  - IP node or
  - IP address

• FBox "Define Unit Client" (Direct/Indirect):
  - Added option "Offset 1->0" 

• The error output of the FBox "Mapping" could be high even if there is no mapping error. In case this FBox is placed elsewhere in the project the error disappears (corrected for PG5 1.4 in version $1.0.017; this is the last version for PG5 1.4).

• Translated FBoxes and online help to German and French

When adapting a Fupla program which has been realized with the FBoxes for Modbus from Engiby to the Modbus FBoxes from SBC, the following points could be from interest.

In the FBoxes from Engiby the 32 bit values can be configured to be transmitted with Little- or Big Endian. In the FBoxes from SBC, the same feature is called with or without "words swap". Please refer to the table below for the correspondance between these two configurations.

Additionally in the "Master Link RS" FBox of the Engiby library there is on parameter more: The "Address offset".
The address offset option "1 (Modicon)" in the Engiby library corresponds to the parameter "Offset 0->1" from the SBC library (in the FBox "Def Unit Server").

It is possible capturing the traffic on a Ethernet network and stop this capture based on a specific condition, like e.g. the lack of Ether-S-Bus telegrams from a specific station for a certain time. However, this can't be done within Wireshark itself, but by using its command line tool TShark which is piped to a Perl script.

Introduction
The attached script written in Perl (a free dynamic programming language) does call TShark which is the command line interface of Wireshark. TShark will then output the interpreted telegrams to the script, which will load a timer every time an Ether-S-Bus telegram from the station in question is "seen". If this timer elapses, the capture is stopped.

Usage
In order to use this script, execute the following steps:

• Install Wireshark 0.99.2 or later (latest possible is 1.4.9; 1.6 does no longer work)
• Install the scripting language Perl (ActivePerl)
• Open the script with a text editor and adapt the IP addresses
• Run the script