CONNECTING TO ECOM100 CARDS

[PLCGuy]

I have in house ecom100's and no problems talking to them using Directsoft or Netedit3. Except for wireless, that is another problem. Netedit does not like wireless. This thread is concerning our hardwired system. Now the cards in another plant is another story. In one machine, there is a H2-ECOM100. I can ping this one and use Directsoft all day and no problems. I have DL240 CPU in that machine. Now the other is a DL430 with a H4-ECOM100 and that is a problem. I pinged it to see what the time is on it and set it a little higher in the card setup. I can ping it once and never again, at least for the day. DirectSoft always says transport error, or can not see plc ID. So why the difference in the two? The IT guys at both plants do not know what to do. Either do I. Any help would be helpful. I see others having connecting problems too. Is this something someone at AD has to improve on? More and more need for ethernet is being seen. It has to be more reliable to work.

[Greg]

NetEdit3, nor DirectSOFT, nor the ECOM100s "know" whether you are using wireless or not. NetEdit3 and DirectSOFT both use Ethernet broadcasts to "find" ECOM100s. Some wireless (and wired) network devices block broadcasting, and this is why DirectSOFT and NetEdit3 cannot "see" the devices. However, if you can ping the device, then you should be able to connect. There is no reason why the H2-ECOM100 would respond to pings and the H4-ECOM100 would only respond to one ping. We have never seen any ECOM100 ever fail to respond to a ping. Of course, the only certain way to tell what is going on is to sniff the network at the H4-ECOM100 and see what is going on. An Ethernet trace would reveal the problem, most likely. I would venture to say that either the ping is not reaching the H4-ECOM100, or the response is not reaching the PC. There is probably an Ethernet device that is causing the problem.

You can use Wireshark to sniff the network at the H4-ECOM100. This is a free Ethernet sniffer (www.wireshark.com) that runs on a PC. Of course, you would have to have an Ethernet hub (not Ethernet switch) installed at the H4-ECOM100 in order to be able to sniff the network. If you cannot understand the telegrams that you see in the Wireshark trace, please feel free to forward them to me (my e-mail is support@hosteng.com).

BTW, "Transport protocol error" is just DirectSOFT's way of saying that the connection "timed out".

[PLCGuy]

I went to the www.wireshark.com and it brings up a page but there is nowhere to click on for downloading of software.

[franji1]

Is this something someone at AD has to improve on? More and more need for ethernet is being seen. It has to be more reliable to work.

As Ethernet becomes more popular, one (or both) of the following is going to have to occur:

1. IT Network guys are going to have to become PLC savvy and understand all of the various Modules/Hardware (ECOMs, EBCs, c-More), tools (NetEdit3) and programs (DirectSOFT, KepDirect, c-More configuration s/w) that utilize these connections, their basic transport protocols (e.g. why a point-to-point connection via DirectSOFT works but a broadcast from the configuration software, NetEdit3, does not work).

2. PLC people are going to have to become more IT/Network savvy.  Routers, Subnet Masks, Hubs, Gateways, Packet Sniffers, etc. are going to become tools in the PLC guy's toolbox.

For example, we added DHCP support to ECOM100, but it doesn't exist in the ECOM.  DHCP can be enabled and disabled in the ECOM100.  What does that mean to a PLC person and how they set up their network that contains ECOM100s and/or ECOMs?  What does that mean when you have a test system in an engineering office that has access to a DHCP server, but the final installation location has no access to a DHCP server?

Greg is great at helping educate either the PLC person or the IT guy, so you've come to the right place! 

[Greg]

Sorry PLCGuy, it was hard to find the download at the place I gave you. I should have pointed you to:

www.wireshark.org

[MikeMc]

Well here's one for Host and AD.

We have recently started having problems with 06 Ecom100's acting very strange. I have one that locks up everytimie we download a program into the 06 plc. A power cycle fixes the problem until the next download.

And then there is the one that I had the other day. I could communicate with it locally but NETEdit could not find it over the wireless connection. It had no problem finding the other 20 or so PLC's but it would not find that one. It was assigned an module ID of 5 and given a valid TCP/IP address (remember we could communicate with it on the local switch). Much discussion with wireless vendor led to taking PLC to another location that was working over the same radio link and plugging it in there. Still no joy. Put the old one back in and took the PLC back to original location. Changed out ECOM module with another PLC and it worked with those settings. Took the original module and installed it in the other PLC and now it would not work. After 3 days of running in circles I gave it an address with the hardware switches (still module ID 5) and now NETEDIT can find it and Directsoft can program it.

This is a new error that has started in the last 6 months or so. We have several older units without the dip switches set and they all work 100%. None are hiding from us playing peek-a-boo or getting lazy and taking a nap after working so hard downloading a program.

A fix for this and the DS5 crashing problem could earn you a beer.

Mike McClanahan
Veolia Water North America

[Greg]

We have recently started having problems with 06 Ecom100's acting very strange. I have one that locks up everytimie we download a program into the 06 plc. A power cycle fixes the problem until the next download.

I've tested this extensively and cannot duplicate this problem.   

Questions:
(1) If you replace this H0-ECOM100 with a different one, does the new one work?
(2) Does the RED ERR light come ON on the H0-ECOM100?
(3) Using Config I/O (serially) in DirectSOFT, can the PLC see the H0-ECOM100 properly?
(4) Is this a wireless connection?

...I could communicate with it locally but NETEdit could not find it over the wireless connection...

NetEdit finds PLCs via broadcasting. It could be that the wireless switch got confused over that one port. That happens. However, it makes no sense that the setting of the dipswitch would cause it to work now. Unless you are forming your links by IDs instead of IP or IPX addressing. The dipswitch shouldn't have "fixed" anything. NetEdit doesn't care about it (other than to report possible conflicts post-scanning of the network).

Of course, if we can't duplicate the issue, it is difficult to fix. 

[MikeMc]

No the new H0-ECOM100 did not fix the problem
Yes the red error light comes on
Yes the PLC can see the H0-ECOM100
Yes this is a wireless connection

I will be leaving 9-8 to go back to the site having the problem locking up the ecom on downloads and I will make sure that it has the dip switches set on it.

Don't worry I am used to being told for months on end that no one can duplicate the problem but eventually you find it. Just like the crashing problem in DS5 (which now crashes everytime I try and use the help file).

Mike McClanahan

[Greg]

...Yes this is a wireless connection...

In order to see what is happening, is it possible to use Wireshark at the H0-ECOM100 and record the telegrams when the lockup occurs?

...Just like the crashing problem in DS5 (which now crashes everytime I try and use the help file)...

In order to see what is happening, is it possible to use Process Monitor and record a log file as you press the Help?

Thanks!