Modbus RTU with 5 Click's

[DLTimmons]

I have a Do-more with a Serio-4 that is connect to 5 Clicks by the RS-485 Port. So I have 5 MRX each in a stage by itself that read 12 coils on success jumps to the next stage. Then 5 MWX each in a stage that write 150 coils then to the next write on completion of the last stage jumps back to the first stage and repetes. As long as I only read and write from one of the click it work great. as soon as jump to a stage that address a different Click I start getting error out of the stage. The only thing I found that helps is to put a timer in and wait 100 ms before starting the read even with this delay I still get some error not as many. I get no exception response code.

AD Teck support said I need to get the MWX and MRX out of stages. and said the stage were just a stop gap program measure to correct for some issues. I use stage very heavily I hope it not a stop gap!

[franji1]

What is your baud rate?

[DLTimmons]

Currently at 57600 buy tried 19200 and 38400 saw no difference

[DLTimmons]

I set the time out to 50 ms with no retry and as long as I access only one click zero errors.

[BobO]

I have a Do-more with a Serio-4 that is connect to 5 Clicks by the RS-485 Port. So I have 5 MRX each in a stage by itself that read 12 coils on success jumps to the next stage. Then 5 MWX each in a stage that write 150 coils then to the next write on completion of the last stage jumps back to the first stage and repetes. As long as I only read and write from one of the click it work great. as soon as jump to a stage that address a different Click I start getting error out of the stage. The only thing I found that helps is to put a timer in and wait 100 ms before starting the read even with this delay I still get some error not as many. I get no exception response code.

AD Teck support said I need to get the MWX and MRX out of stages. and said the stage were just a stop gap program measure to correct for some issues. I use stage very heavily I hope it not a stop gap!

Stages are a method of sequencing. Nothing more or less. In my opinion, they are the single best way of sequencing. The MWX/MRX instructions are designed to work with stages to make the user's code cleaner and easier. The failure you are describing has nothing to do with stages.

There may well be timing requirements, which has nothing to do with how the Do-more CPU is programmed. I'm sure you can break it without stages as easily as with. The difference with stage is that it is far easier to get the sequencing correct the first time.

[DLTimmons]

Kind of what I thought when he said it.   So I see no use of taking the 5 reads and 5 writes out of stages

From my point of view Stages make the Do-more!

[BobO]

Incidentally, the Modbus/RTU Client in Do-more has an inter-packet delay parameter. It is set to 3.5ms by default. That may be too low. Ideally it should be about 1.5x to 2x the scantime of the slowest PLC you're talking to with that client. There is some discussion about that in the DmD help file.

[LWgreys]

You may have a wiring problem with the RS-485. Make sure all the devices are in a daisy chain, an interconnecting signal ground and the two end points are terminated correctly. In multiple device connections on RS-485, if I'm correct, you need to enable hardware RTS, CTS on all the device ports in a two wire RS-485. The links below have more good info on RS-485 connections. Note the location of terminator resistors which are not needed for a two device connection.
http://www.lammertbies.nl/comm/info/RS-485.html
http://www.embeddedsys.com/subpages/resources/images/documents/microsys_art_RS485.pdf

Also remember that 2-wire RS-485 is half duplex. Only one device can transmit at a time and you have to wait for the response.

[ADC Product Engineer]

BobO is correct.  The interpacket delay of 3.5ms is too short for Click.  It needs to be in the order or 8-10ms minimum.

[DLTimmons]

You may have a wiring problem with the RS-485. Make sure all the devices are in a daisy chain, an interconnecting signal ground and the two end points are terminated correctly. In multiple device connections on RS-485, if I'm correct, you need to enable hardware RTS, CTS on all the device ports in a two wire RS-485. The links below have more good info on RS-485 connections. Note the location of terminator resistors which are not needed for a two device connection.
http://www.lammertbies.nl/comm/info/RS-485.html
http://www.embeddedsys.com/subpages/resources/images/documents/microsys_art_RS485.pdf

Also remember that 2-wire RS-485 is half duplex. Only one device can transmit at a time and you have to wait for the response.

A blast form the past the old Circuit Cellar Ink have most of the early mags.

I don't think it a wire issue as long as I address only one click it has no error at 57600 baud it when I address a second click that thing go bad. and the Do-more the only master on the system so there should be no conflict.

[DLTimmons]

BobO is correct.  The interpacket delay of 3.5ms is too short for Click.  It needs to be in the order or 8-10ms minimum.

This makes more sense than any thing. It's a shame that AD tech could not tell me this fact.

Now to get in the winter gear and go out there in the sub freeze temps. Long story the big door is open as a construction crew got the isle blocked so forklift have to go out the door. Ever tried typing in gloves

Will try 10 ms and see if that fixes the issue.

Thanks All

[BobO]

Will try 10 ms and see if that fixes the issue.

It's required because Modbus has no real provision for framing other than silence. Most devices can't detect very small periods, it requires them to see an empty buffer during one scan. To ensure that, the time needs to be a scan or two of your slowest Click. Don't know much about Click scan times, but it sounds like 10ms may be good. If that doesn't fix it, I would encourage you to check the max scan time of your Clicks.

[jhadc]

If you consider you have Click A through Click E, plus your Do-more...

EVERY device on the wire must process every message put on the wire.  So even when Do-more and Click A are having a conversation, Clicks B-E receive and analyze every message to determine whether they need to act on it.  They have to process each message (even if just throwing it out) and doing so takes time.

The issue you're running into is that the time delay between a Click A's last transmission and Do-more transmitting its first message to Click B is too short.  Do-more can fire off the message before Click B has finished throwing out the last message it received from Click A.  Click B misses part of the first message from Do-more.

The 10mS delay would be a good way to fix it, but adding a delay to the stage should also work without slowing down ALL the traffic.

The scan time of your Clicks should play a roll in this too.

[BobO]

If you consider you have Click A through Click E, plus your Do-more...

EVERY device on the wire must process every message put on the wire.  So even when Do-more and Click A are having a conversation, Clicks B-E receive and analyze every message to determine whether they need to act on it.  They have to process each message (even if just throwing it out) and doing so takes time.

The issue you're running into is that the time delay between a Click A's last transmission and Do-more transmitting its first message to Click B is too short.  Do-more can fire off the message before Click B has finished throwing out the last message it received from Click A.  Click B misses part of the first message from Do-more.

The 10mS delay would be a good way to fix it, but adding a delay to the stage should also work without slowing down ALL the traffic.

The scan time of your Clicks should play a roll in this too.

That is the purpose of the inter-packet delay parameter...to put the required amount of delay between transactions to allow the slowest device on the network to handle and re-frame as necessary. Once he has the client set right, he shouldn't need any timing in the program...but...the right answer will be dependent on the slowest Click, hence my suggestion to check the max scan times of each Click.

[DLTimmons]

10 ms and it's working like a charm