overworking a DL06 H0-ECOM100 with modbus tcp

[harncw]

We are looking hard at and playing around with a DL06 H0-ECOM100

Our goal is to be able to communicate with it via MODBUS TCP.

I've found with my testing here that I'm able to swamp the PLC with modbus requests, and even after I remove the load, the PLC is in a state where all the MODBUS TCP response packets are exceptions. It's as if the PLC never recovers, save powerclearing.

The responses themselves are curious.
I send a function 01h (ReadCoils)

Normally I receive a func. 01h when all is well.
However I'm receiving a function 81h after I've managed to get the PLC in this state.
Also the length is 3 instead of the correct 6.

Also when the PLC gets in this state we can only connect to the PLC from DirectSoft via DirectNET Protocol link, ECOM and K Sequence are unable to connect.

So basically I'm blasting out MODBUS TCP requests, at such a rate that I am able to get the PLC to choke, and then it never recovers. Granted I probably shouldn't be cramming so many requests, but shouldn't this issue be recoverable for the PLC?

[harncw]

to further clarify the responses I'm getting are

FunctionCode = 80h +
ExceptionCode = 04h

04h seems to be defined as:

SLAVE DEVICE FAILURE
An unrecoverable error occurred while the server (or slave) was attempting to perform the requested action.
[MODBUS Application Protocol Specification V1.1b]

[harncw]

if anyone wants to play around with my testprogram.

http://globalsoftware-inc.com/harncw/ModBusTest.exe

[harncw]

upgraded
from h0ecom100_4_0_224
to h0ecom100_4_0_227

at least I'm not seeing a red error light anymore

the modbus tcp still returns a function >128 with exception code 04

[franji1]

Look at FAQ #38
http://www.hosteng.com/FAQFiles/ECOM.htm#FAQ0038
and look at the link to the document that maps Modbus Address to the DirectLogic element address.

The problem may be that your FC 16 is asking for a Modbus Address out of range in your DirectLogic PLC.

[harncw]

Originally Posted by franji1

Look at FAQ #38
http://www.hosteng.com/FAQFiles/ECOM.htm#FAQ0038
and look at the link to the document that maps Modbus Address to the DirectLogic element address.

Saw that thx, got it printed out on my desk here.

Originally Posted by franji1

The problem may be that your FC 16 is asking for a Modbus Address out of range in your DirectLogic PLC.

All I'm sending are 2 identical requests over and over again.

0000   00 01 00 00 00 87 01 10 02 00 00 40 80 00 00 00
0010   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0050   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0070   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0080   00 00 00 00 00 00 00 00 00 00 00 00 00

0000   00 02 00 00 00 87 01 10 02 40 00 40 80 00 00 00
0010   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0050   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0070   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0080   00 00 00 00 00 00 00 00 00 00 00 00 00

And it works! for awhile... it's the quirkyness of "awhile" and the fact that after it dont work it wont until I hit the power... and I've come near to shocking myself several times today pulling the cord from the powerstrip

At a rate of 200 mbtcp requests per second (Function 16's for 64 words a total length of 135 bytes) , it fails after a few minutes.
I tested roughly 10 minutes one time and 2 minutes another.

hmmm I think I maybe sending malformed packets which are bombing the ECOM... need to go more on this manana

[stimpsonjcat]

Have you tried slowing it down?

[harncw]

Originally Posted by stimpsonjcat

Have you tried slowing it down?

We went into this issue further host engineering's site as well.
http://forum.hosteng.com/index.php/topic,545.0.html

IIRC Hosteng expressed a concern that they may have an issue with multiple modbustcp frames in a single tcp packet. It may also be that my network card is sending malformed packets. Either way the H0-ECOM100 is getting borked.

To answer your original question.

Yes slowing it down is an option. I'm crashing it by flooding with large requests. Just don't flood it seems to work.
But then that opens the question of "how much to slow it down by?"
Also raises the issue of why is it intermittent?

[GKiser]

We are currently testing firmware which we believe fixes this issue.

The main issue here was multiple requests in a single packet where the last request was split across two packets. The ECOM100 supports multiple requests per packet as long as all the requests are complete. The new firmware will return an error code for the request that was split and ignore any bytes that don't form a valid request. In the process of fixing this, we added code to validate all incoming requests to make sure the request was valid and the data was all there.

This firmware will probably be fully tested and released next week (1st week of August 2010).

[harncw]

Originally Posted by GKiser

We are currently testing firmware which we believe fixes this issue.

The main issue here was multiple requests in a single packet where the last request was split across two packets. The ECOM100 supports multiple requests per packet as long as all the requests are complete. The new firmware will return an error code for the request that was split and ignore any bytes that don't form a valid request. In the process of fixing this, we added code to validate all incoming requests to make sure the request was valid and the data was all there.

This firmware will probably be fully tested and released next week (1st week of August 2010).

Thanks for the update!

[jackson]

That's fine if HOST engineering wants to allow multiple Modbus messages (called ADU's in Modbus TCP speak) within one TCP frame. It's their product. But...

That is a clear cut violation of the Modbus TCP specification. Only 1 Modbus ADU per TCP frame.

If this is your application, you may want to re-consider that methodology. I think you'll have problems with most Modbus TCP servers.

If you are not doing this on purpose, look at the TCP No delay setting (sometimes referred to as the 'Nagle algorithm'). Setting this incorrectly is usually what causes this issue.

[harncw]

Originally Posted by jackson

That's fine if HOST engineering wants to allow multiple Modbus messages (called ADU's in Modbus TCP speak) within one TCP frame. It's their product. But...

That is a clear cut violation of the Modbus TCP specification. Only 1 Modbus ADU per TCP frame.

agreed, it is a violation of the spec, although IMHO violating the spec should not cause the ECOMM to get stuck in this erroneous state, pending a power clear.

6) A TCP frame must transport only one MODBUS ADU. It is advised against sending multiple MODBUS requests or responses on the same TCP PDU

as per MODBUS MESSAGING ON TCP/IP IMPLEMENTATION GUIDE V1.0b

Originally Posted by jackson

If this is your application, you may want to re-consider that methodology. I think you'll have problems with most Modbus TCP servers.

If you are not doing this on purpose, look at the TCP No delay setting (sometimes referred to as the 'Nagle algorithm'). Setting this incorrectly is usually what causes this issue.

I'll look into fiddling with that flag, thanks for the direction.

[franji1]

Originally Posted by harncw

agreed, it is a violation of the spec, although violating the spec should not cause the ECOMM to get stuck in this erroneous state

The issue is that the CLIENT is violating the specification, and the ECOM100 as the SERVER gets HUNG because of this violation. The proposed fix for the ECOM100 SERVER is to
1. Not get hung
2. reject the badly-formed request(s) by the CLIENT (if it can)

[harncw]

well since we are all getting in the koolaid here... and since this is such an interesting conundrum

Can I argue that the Modbus TCP's specification of "only 1 ADU per frame" is a flawed assumption destined to fail?

http://www.drdobbs.com/184416578

TCP is based on a stream of bytes — the only thing it guarantees is that the data will be delivered in sequence and error free or you will be notified of an error. Any program that is written with the expectation that TCP will keep application layer messages separate will fail; it's just a question of when.

http://www.clarion-software.com/inde...oup=9&id=17778

In your case it's not NetTalk that's putting the packets together, but most likely the Winsock layer. There are some OS properties you can tweak to try and manage this, but frankly you shouldn't try. In the real world traffic goes through hubs, switches, routers and all manner of other equipment. And at each place packets can be chopped up, or put together.
This is why TCP/IP protocols typically have some way of knowing where a packet starts, and where it ends.

I looked into fiddling with my Nagle, but it seems like waving a dead chicken to me.

[harncw]

To close out this topic...

Host Engineering released an update, that addressed the issue.

Good job guys!

http://forum.hosteng.com/index.php/topic,545.0.html