AutomationDirect Customer Forum  

Welcome to the AutomationDirect Customer Forums.
These forums are intended as a place for AutomationDirect customers to help one another, share information, and share ideas.
The forums are not routinely monitored by AutomationDirect Technical Support staff. While staff members may answer questions occasionally, for a prompt response to a problem please contact Technical Support directly at: 1(800) 633-0405 or (770) 844-4200 or e-mail Tech Support.

For product questions, start here: Online Manuals and Product Inserts


Go Back   AutomationDirect Customer Forum > Communications

Reply
 
Bookmark and Share Thread Tools Rate Thread Display Modes
  #1  
Old 05-26-2010, 11:58 AM
harncw harncw is offline
Registered User
 
Join Date: Apr 2010
Posts: 23
overworking a DL06 H0-ECOM100 with modbus tcp

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?
Reply With Quote
  #2  
Old 05-26-2010, 12:45 PM
harncw harncw is offline
Registered User
 
Join Date: Apr 2010
Posts: 23
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]
Reply With Quote
  #3  
Old 05-26-2010, 04:46 PM
harncw harncw is offline
Registered User
 
Join Date: Apr 2010
Posts: 23


if anyone wants to play around with my testprogram.

http://globalsoftware-inc.com/harncw/ModBusTest.exe
Reply With Quote
  #4  
Old 05-27-2010, 11:11 AM
harncw harncw is offline
Registered User
 
Join Date: Apr 2010
Posts: 23
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
Reply With Quote
  #5  
Old 05-27-2010, 04:40 PM
franji1 franji1 is offline
Registered User
 
Join Date: Aug 1999
Location: Johnson City, TN USA
Posts: 2,050
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.
Reply With Quote
  #6  
Old 05-27-2010, 05:54 PM
harncw harncw is offline
Registered User
 
Join Date: Apr 2010
Posts: 23
Quote:
Originally Posted by franji1 View Post
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.

Quote:
Originally Posted by franji1 View Post
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.

Code:
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
Reply With Quote
  #7  
Old 07-29-2010, 05:51 PM
stimpsonjcat stimpsonjcat is offline
Registered User
 
Join Date: Feb 2005
Posts: 315
Have you tried slowing it down?
__________________
"...Specialization is for insects." - Heinlein
Reply With Quote
  #8  
Old 07-30-2010, 09:51 AM
harncw harncw is offline
Registered User
 
Join Date: Apr 2010
Posts: 23
Quote:
Originally Posted by stimpsonjcat View Post
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?
Reply With Quote
  #9  
Old 07-30-2010, 03:36 PM
GKiser GKiser is offline
Registered User
 
Join Date: Apr 2002
Location: Jonesborough, TN, USA
Posts: 424
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).
__________________
Greg Kiser
Hos Engineering, Inc.
support@hosteng.com
http://forum.hosteng.com
This isn't all true.
Reply With Quote
  #10  
Old 07-30-2010, 03:38 PM
harncw harncw is offline
Registered User
 
Join Date: Apr 2010
Posts: 23
Quote:
Originally Posted by GKiser View Post
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!
Reply With Quote
  #11  
Old 08-02-2010, 10:40 AM
jackson jackson is offline
Registered User
 
Join Date: May 2003
Posts: 387
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.
Reply With Quote
  #12  
Old 08-02-2010, 12:54 PM
harncw harncw is offline
Registered User
 
Join Date: Apr 2010
Posts: 23
Quote:
Originally Posted by jackson View Post
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.
Quote:
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

Quote:
Originally Posted by jackson View Post
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.
Reply With Quote
  #13  
Old 08-02-2010, 02:24 PM
franji1 franji1 is offline
Registered User
 
Join Date: Aug 1999
Location: Johnson City, TN USA
Posts: 2,050
Quote:
Originally Posted by harncw View Post
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)
Reply With Quote
  #14  
Old 08-02-2010, 03:58 PM
harncw harncw is offline
Registered User
 
Join Date: Apr 2010
Posts: 23
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
Quote:
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
Quote:
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.
Reply With Quote
  #15  
Old 08-31-2010, 08:56 AM
harncw harncw is offline
Registered User
 
Join Date: Apr 2010
Posts: 23
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
Reply With Quote
Reply

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is On

Forum Jump


All times are GMT -4. The time now is 09:40 AM.


Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.