DL06 H0-ECOM100 troubleshooting help

[clintonp]

(Cross-posted from ADC forum.)

I am having a problem with an H0-ECOM100 that seems similar to what harncw has described in his post, overworking a DL06 H0-ECOM100 with modbus tcp of 6/1.

We have been working with the ECOM100 for a while now, using it for programming (what a joy versus serial!) and for MODBUS TCP/IP. Periodically we get errors that lock-up the ECOM. I don't think that my problem is related to the speed at which I'm posting requests (as harncw is experiencing); we are polling once each second, requesting only a few words of data. And sometimes we get them when we are not using the MODBUS application, only DirectSoft5.

We can most readily recreate the error by disconnecting the Ethernet cable and then reconnecting it.

Initially, of course, we suspected software. The first problem that we noticed was that our PC code would work and then begin to report socket errors. Only later did we notice that with DirectSoft5 the link was flagged as Disabled, and DS5 could not access the PLC. Accessing the ECOM100 by entering its IP address into a browser always works -- the web page built-in to the ECOM pops right up.

Turning the PLC off and back on DOES NOT clear our problem. The only thing that has ever cleared the problem is turning off the PLC, removing the ECOM100 from the PLC, and then re-seating it. This ALWAYS works. This is very disheartening. It suggests to me something like a nasty error in the ECOM hardware/firmware that locks up, and is held locked by the supercapacitor or the battery in the PLC, something like that. But I'm talking through my hat...

We'd be grateful for a push in the right direction to troubleshoot this problem. [One thing I'm going to try is to remove the battery from the PLC and see if I can them clear the error by cycling the power.]

Thanks in advance,

Paul in Wisconsin
Edit/Delete Message

[rswolff]

wish I had seen these posts before I designed and installed a network using 10 ecoms. Worst h/w I've ever experienced. Lockup and stop communicating to the processor every time the moon shines, toilets flush, radios get turned on, car horns beep, computers are turned on, or people speak. Forget about polling times or data amounts. Perhaps one byte per minute was their design criteria.

[Greg]

Not a very scientific evaluation, rswolff. But I do understand the frustration. The backplane is always the bottleneck as far as thru-put goes. We often find in such rare situations the ECOM is getting hammered by something on the network or there are extreme delays or electromagnetic interference. I've worked with these units for nearly a decade and there are 1000s of them in the field virtually running with no problems that we know of. But with that many in the field we are bound to run into some rare apps that are either abusive to the ECOM or that we didn't account for in our design. Rest assured if we can figure out the issue we'll do our best to remedy the situation to make you happy. However this may require a little more scientific data on your part. I asked some questions on your other post (see http://forum.hosteng.com/index.php/topic,722.0.html) that if you have the time you can answer and we'll see if we can't get you running smoothly.