Modbus Errors

I have a Field Electronics 1000 analog input module thats using modbus RTU to communicate via a B&B Electronics ESR902 serial to ethernet convertor, to a KEPware Kepserverex OPC server. The problem is that when I request more then 1 register of data from the slave, it replies with bad data.

Here's a good and bad example of what I'm getting.
Good:
TX: 02 03 0001 0001 D5F9 [Slave Address '02', Command '03' Read, Start at Register '0001', reply with '0001' registers, CRC 'D5F9']
RX: 02 03 02 3184 E9B7 [Slave Address '02', Command '03', # Bytes of data '02', Data '3184', CRC 'E9B7']

If I request more then 1 register I get:

TX: 02 03 0001 0004 15FA
RX: 02 03 08 3184 00 0D71 00 17B9 00 0759 F70E 00

The problem seems to be the extra '00' bytes its sending. I have no idea where they are coming from or why.

Anyone have any experience troubleshooting this type of error?

The RTU protocol calls for two bytes per register with no characters in between data values. The first thing you need to do is to figure out whether the Field Electronics unit or the B&B converter is inserting the extra characters. Once you've identified the culprit you can contact their tech support to find out how to make it stop.

See if you can get a computer running Modscan or something similar through a serial port so you can bypass the B&B unit. Send the same multi-register command directly to the Field Electronics module and see what you get in response.

multi register reply

Christoff84 said:

RX: 02 03 08 3184 00 0D71 00 17B9 00 0759 F70E 00

Click to expand...

Are the correct reply values 3184 0D71 17B9 0759 ?
Or are they screwed up, too?

Dan

danw said:

multi register reply


Are the correct reply values 3184 0D71 17B9 0759 ?
Or are they screwed up, too?

Dan

Click to expand...

Those are the correct values. Just seems to put a pause in between them for no reason.

1) I think I've had to update the firmware on every serial to ethernet converter I've ever used. Is the firmware the latest on the one you're using?

2) It has seemed to me that many serial to ethernet converters offer specific models for Modbus RTU to Modbus TCP conversion. I know Lantronix and B&B do

The web page for the B&B ESR902 here:
http://www.bb-elec.com/product_family.asp?familyid=120]
doesn't mention Modbus.

Note that B&B has specific models for Modbus, the MES1A and MES1B Modbus ASCII/RTU to Modbus TCP converters, here:
http://www.bb-elec.com/product_family.asp?FamilyId=275&Trail=1&TrailType=Top

Can it be that a standard serial to ethernet converter just doesn't convert properly?

Dan

danw said:

1) I think I've had to update the firmware on every serial to ethernet converter I've ever used. Is the firmware the latest on the one you're using?

2) It has seemed to me that many serial to ethernet converters offer specific models for Modbus RTU to Modbus TCP conversion. I know Lantronix and B&B do

The web page for the B&B ESR902 here:
http://www.bb-elec.com/product_family.asp?familyid=120]
doesn't mention Modbus.

Note that B&B has specific models for Modbus, the MES1A and MES1B Modbus ASCII/RTU to Modbus TCP converters, here:
http://www.bb-elec.com/product_family.asp?FamilyId=275&Trail=1&TrailType=Top

Can it be that a standard serial to ethernet converter just doesn't convert properly?

Dan

Click to expand...

I have updated to the latest firmware. The funny thing is I have another of these devices, same setup, same hardware, same converter, working flawlessly. Its just puzzling why this one did work and now doesnt.

Can you steal the other 'fully functional' serial-to-ethernet converter long enough to substitute it for this current situation to see if it's the problem or whether the problem is generated elsewhere?

Dan

In the B&B converter make sure you have legacy or throughput mode set. Some converters will insert nulls when there is a charafter break in the device responpse if they ar enot set into the proper mode. A character break is a pause for 1/10 of a msec.

On a seperate not, if the extra characters were simply at the end of the packet there is a setting in the latest Modbus driver for KepserverEx to ignore them. Being embedded is not something that we can overcome though.