ECOM Advanced Settings

[sgsims]

Wondering how the Modbus Settings In the ECOM Advanced Settings in Netedit affect the time it takes for the Error Bit in the I-Box IB-741 to go high.  I am testing how long it takes the error bit to go high if Slave device I am communicating with goes down.

When I set the Modbus Master timeout to 500 MS or less I get the expected results.  For example if I set the vale to 400 MS I get the error bit to go high 402 ms after starting the communications with the I-Boox.  However if the timeout value is greater than 500 ms  say 550 ms it takes 2180 ms for the error bit to fire.

The Ecom in the DLO6 in this case is the master communicating with a Cognex camera as the slave.  H0Ecom-100 is the card in the DLO6 slot.

[BobO]

What about Retries? Using 550ms with 3 retries would produce the result you describe.

[sgsims]

So I didn't change any of the retry settings when I tested the various timeout values.  Are the K-Sequence and RX/WX retry settings the ones you are referring to in the ECOM Advanced Settings?

They are currently set at K-Sequence 2 / RX/WX - 1

[BobO]

Not sure why that would be. I'll have somebody check into it at this end.

[sgsims]

Great...thanks.  So am I on the right track as far as understanding the relationship between the error bit and the timeout setting?

I am under the impression that when the ECOM Master initiates a communication it waits for some response from the slave that defines the communication as successful or a failure.  If  the ECOM card doesn't hear anything back that it can use to define the comm as a success or failure it continues to wait until that timeout value is reached and then it deems the comm to be unsuccessful and fires the error bit.

Sound like I am on the right track?-

[Greg]

sgsims, we have duplicated this and are studying what is happening. I'll post something when we know something.

[sgsims]

Thanks Greg!

[Greg]

sgsims, I know it has been a terribly long time (almost a year). But all our testing shows a consistent behavior, bizarre as it is. But there is nothing in our ECOM100 code that could cause this behavior. It seems that the Koyo PLC is behaving this way and we're not sure why. But it is consistent in the fact that not only does the DL06 do this, but also the DL260. Even though they both do something different, the timeout setting where they both start acting bizarre is exactly the same.

I tested this with my DL06 and H0-ECOM100 and following are the results. First I set the RX/WX Settings to something that probably doesn't make any difference:

ACK Timeout: 10ms
Resp. Timeout: 1000ms
Retries: 0

Then I set the KSequence Settings to:
Retries: 0

Then I set various Modbus Settings, only varying the Master Timeout value. I left the Slave Timeout to 20 seconds.

Then I enabled an ECRX to a non-existent Modbus TCP slave. I started a TMRF in ladder logic when the ECRX is enabled and stored its value when the Error bit came ON. Since I used a TMRF the resolution is not going to be very accurate (probably +/- 10ms or something close) Here's what I noticed:

Master Timeout (ms) / Time-to-Error-bit (ms)
100 / 110
150 / 160
200 / 210
250 / 260
300 / 310
350 / 360
400 / 410
450 / 460
500 / 510
550 / 3760
600 / 3760
650 / 3760
700 / 3760
750 / 3760
1000 / 3760
2000 / 3760
3000 / 3760
4000 / 3760
5000 / 3760
6000 / 3760

So after it crossed the 550 ms mark, the time from enabling the ECRX to the Error bit was always 3.76 seconds.

I then tested a DL260 in the exact same manner with the following results:

Master Timeout (ms) / Time-to-Error-bit (ms)
100 / 110
150 / 160
200 / 210
250 / 260
300 / 310
350 / 360
400 / 410
450 / 460
500 / 510
550 / 560
600 / 520 or 530
650 / 520 or 530
700 / 520 or 530 or 540
750 / 530 or 540
1000 / 530 or 540
2000 / 530 or 540
3000 / 530 or 540
4000 / 530 or 540
5000 / 540
6000 / 540

Weird! So, again, the "breaking point" is about Master Timeout value of 550ms, but this time the DL260 "breaks" to a lower value of 530ms instead of a higher value of 3720ms!

Koyo (who makes the DL06 and DL260) is a slow-moving giant, so the fix to the PLC firmware will be a long-time coming. Thus a work around will have to do. What work around you may ask? I don't know, other than realizing this behavior and planning for it. One would simply be not to use timeouts over 500ms.