Created Date: January 08,2007

Created by: Bent

Hi Jackson,

Yeah, I 've been meaning to setup a Modbus slave simulator but haven't got around to finding or writing one. You got any recommendations?

Anyway, my post was short on details, sorry. The setup was:

DL06 Port 2(Master) to DL05 Port 2 (Slave)

1200,N,1 (1200 baud, No Parity (also tried even, didn't try Odd), 1 stop bit.)

Running through a Dataradio DL 3282 Bell 202 modem and a JSLM radio.

Modem RTS/CTS delay: 30ms (also tried 240ms)

DL06,05 RTS/CTS Delay: Any>= 50ms

Slave #: 7

Modbus Code 3, Read Multiple Registers.

Start Slave Address: 40386

Start Master Mem Addr: V10021

If number of elements is 2, get 50% errors

If number of elements is 3, get around 5% errors.

The 50% error number stays consistent with changes in RTS/CTS delays and changes in parity. Changing these delays and/or the parity should change the statistics of the errors if it was a timing problem in the PLC/Modem/Radio interface, I'm thinking.

What I need to try (and haven't yet) is removing all the stuff in between and doing a direct connection between the DL06 and the DL05. This would be a better indicator of the location of the problem. I'll try to get to that this week and report back.

Thanks,

BenT

Created Date: January 09,2007

Created by: jackson

Ahh...Radios...

Radios will quite frequently sent out the data on RF at some pre determined fashion un related to the Modbus packet structure.

What this causes, some times, is an unusually long delay in the middle of a Modbus request.

The DirectLogic PLCs follow the specified Modbus RTU rules in that a delay time of no longer than 1.5 character times in the middle of the packet is not allowed and they will flush the request if a longer delay occurs.

Most radios, these days, have a setting to get around this. They either intelligently decipher the Modbus message and coherently transmit the packet on the RF or they simply have a 'buffer delay ' setting so that they don't transmit until a certain delay occurs on the incoming data on the serial port.

I would talk to the radio manufacturer about this scenario above. I am certain that they are aware of it.

By the way, Win-tech is ok for a simulator but I am more partial to www.modbustools.com. It is very similar in look and feel to the Win-tech simulators but Modbustools has more whistles and bells and is higher quality in my opinion.

Both of the companies have free demos that you can download and run for a few minutes at the time and the purchase price of both companies ' software is about the same (very cheap).

Created Date: January 09,2007

Created by: franji1

Why cannot both the master and slave have a configurable inter-character timeout? This must be done in firmware, but this setting is REQUIRED if there is ANY type of buffering going on "on the wire ".

If I type

but I break the

information acro

ss

multiple

lines it can sti

ll make sense

especially to a computer!!!

As long as you make the inter-character timeout somewhere between 1.5 "character times " and a REAL packet timeout (which should also be configurable), most radios and other modems would work.

Just my 2 cents worth to the developers of serial devices http://forum1.automationdirect.com/board/biggrin.gif

Created Date: January 15,2007

Created by: Bent

Thanks for all your recommendations.

I am still not sure what the problem is at this point. However, running in Bell 303 mode (at a miserly 300 baud) appears to be promising. However, there appear to be timing problems with the Bell 202 mode.

I tried a direct connection between the PLC's. It looked good. Then I tried a direct connection between the modems...not so good. I'm going to talk to the manf next week about it and find out if they know what the problem could be.

As a Bell 202 modem, I would hope that there wouldn't be any buffering involved. But perhaps the Dataradio modem has some strange internals.

If I get any further with this, I'll update this post with the details. Otherwise, I'll probably ship it at 300 baud (luckily I don't have much data to transfer.)

I 've used other Bell 202 modems sucessfully with DL 05's and 06's.

I'll check out that modbus software. I could use a good modbus interface without having to write one!

BenT

Created Date: February 03,2007

Created by: Bent

A final update to conclude the current chapter on this issue.

The system is running at 300 baud with few errors and will stay that way for now. At 1200 baud there were numerous errors that seemed primarily dependant on the message length.

The problem that I experienced appears to lie either in the modem or the cable connecting the modem to the PLC. The modem is supposed to be a 'dumb ' modem with no buffering or other internal processing other than to change the logic levels to modem signals and handle RTS/CTS timing. I tried several modems (same brand, just switched them around) and had the same result.

For the time being, my best guess (without putting it on an analyzer) is that ringing on the cable was causing the errors. Unfortunately, I didn't have time to investigate it on this project, but I will likely do so in the future.

Thanks to all who weighed in on this issue.

Bent

Created Date: January 08,2007

Created by: Bent

I ran into an interesting one this weekend. When using MRX on a DL06 and using Code 3, Read Multiple Registers, I would get errors on almost exactly half the communications when I requested 2 data words. After checking everything else endlessly, I changed the number of data words requested to 3, and viola!, errors dropped down to 3% or so.

This problem appears to be software related as changes to hardware and hardware setup (parity, RTS delays, timeouts) have virtually no affect on the 50% number.

Has anyone else seen this type of behavior? Is this a known bug?