Cimplicity ISN'T


Thread Starter


This is the test bench configuration. Cimplicty HMI is running a project through a Rocketport quad card. This card provides four additional
com ports. Cimplicity is using MODBUS RTU as the protocol, port setting @ 9600,8,N,1 FC=H/W. The com port connects to a V.29 master modem.
The master modem runs out to a telco bridge. Presently, two (2) slave modems are connected to the bridge. Both slaves are attached to

This is the problem. Using Listen and Modscan to monitor data packet validity, trailing data, and other extra bytes are returning after a
poll rendering the received data invalid.

Valid data
Poll [13][03][00][00][00][28][46][a6]

Invalid Data
Poll [13][03][00][00][00][28][46][a6]

These are samples of trailing data

What could be causing the trailing data and the invalid response, and what to do about it? How do I strip the trailing data off?
One of the basic task that a protocol device driver must perform is to be able to detect the start and the end of a message. This is especially important when using the protocol over radio modem.

I don't think there is any hardware solution to your problem.

The Cimplity HMI have an OPC Client interface, which can access any OPC Server. There are a number of Modbus OPC Servers available, some of which may be more robust.

All our OPC Servers (including Modbus) have robust algorithms to detect the start and end of message.

Philip Wong
[email protected]
You need to set your modems for soft carrier de-keying. By default a modem will slam down the carrier immediatly after the last character is sent, this creates some white noise that ends up being transmitted as a random garbage character
(or two ). Modbus RTU wants a delay after the last valid character to signify an end-of-message.

If you can't find this setting, let me know what model modem you are using.

Jay Kirsch