NetEdit not finding Ethernet ports on POM and DM1E-36ER

[Controls Guy]

Having a very strange problem today.  My partner, commissioning in the field, is trying to communicate with an Ethernet POM in a DM1-36ER, but can't get it to show up in NetEdit.  The POM has been used before and should probably have an IP address unless they lose them by sitting, but whether he needs to set one or find the one already set, NetEdit should do the trick, but he can't get it to show up.  If he cycles power, he gets a LNK light as well as an ACT light for a while, but can't find the CPU by scanning.  I tried (I just downloaded 2.1.4 yesterday I think), and I get the same result with the internal port on a DM1E-36ER, but I can see a DM1E-M (that already has an IP address) just fine.  I walked him through all the normal stuff like making sure to explicitly select the right adapter on his PC, but nothing seems to make his PLC show up.

Ideas?

[ATU]

I was working with a customer last week and had the same problem on his corporate Laptop.  The only way we could get it to work was to connect a USB Network adapter.

[Controls Guy]

Well, his laptop is an existing one that hasn't had any recent changes.  Mine is new and this is the first time I've tried to connect to a Do-More, but then two different CPU's are behaving differently, so I'm baffled.

Update:  The one in my shop did already have an IP, which wasn't in the same subnet as my adapter.  I ran Wireshark, scanned with NetEdit, and watched who popped their heads up.  So the CPU is replying to the scan with it's IP address in the respective position in the header, which apparently causes the response to get subnetted out and not show in NetEdit.  You'd expect it to respond to broadcast queries with the IP address as generic data in the packet (if it has one) rather than AS the IP address so it doesn't do that.

[BobO]

Are you selecting an adapter to bind to when you do the query? Windows is increasingly fickle with unbound broadcasts.

[Controls Guy]

Are you selecting an adapter to bind to when you do the query? Windows is increasingly fickle with unbound broadcasts.

Yes, both he and I tried both Default and explicitly selecting the relevant adapter.  And, the same thing that worked for me worked for him -- discover the PLC IP address via Wireshark, adjust the local adapter IP address so the subnets match, and then the PLC would show up (still using a Scan Network broadcast).  I'm on Win7 64-bit with SP1.  Not sure what he has.  Some version of Win7, but not sure of version, bit size, or SPs.

[BobO]

Pretty much nothing after XP would work if there were any subnet conflicts. Things that used to show up, quit doing so, and it wasn't anything we changed. With each version of Windows, there have been new caveats. Frustrating.

[Controls Guy]

Yeah, but can you not fix it purely from the PLC end?  If you receive a Scan Net broadcast message and have an IP address configured, format the response as if you DON'T have an IP address set (but possibly including the IP address, subnet, and gateway as data in the packet if feasible so that NetEdit can still display them)?

[BobO]

Theoretically? Yes. It is probably more nuanced than you think, just because the IP stack has something to say about it (like everything) and the ability to respond when not configured is already a hack. I haven't looked into it, but gut tells me it might be painful to get the stack to play without going through the full initialization.

I like the idea though.

[Controls Guy]

Theoretically? Yes. It is probably more nuanced than you think

Many things are!   I typically go with the assumption that anything I don't know how to do must be easy (paraphrasing Dilbert's PHB)

[Controls Guy]

Other brands take one of a few approaches.  AB ships configured for BOOTP, with a little BOOTP server utility that allows you to set the IP address for the session.  Then you can go online and download a PLC program which is configured with a static IP.  Siemens lets you browse for devices (local network only, not routed), and you can either go online and set an IP, or download a program to a device found in that scan.  Idec and some others ship with a preconfigured static IP, and you can change your PC adapter, load the program, and change back.

None of those approaches would help with the issue I had today (already configured with an IP in a foreign subnet); well maybe the Siemens way would help a little.  But if Windows continues to be more finicky and the unconfigured response hack becomes more tenuous, then going one of those ways might make life easier for out-of-the-box initial setup.

[BobO]

I think PxK has a known static, and probably Click as well. That's easy, but not necessarily the best out of box experience.

I may dig a bit more into the idea of responding unconfigured. We may have to tweak NetEdit a little, but it shouldn't be hard. We'll just have to see how hard it is to get the IP stack to play.

[Controls Guy]

Thank you!

[PLCGuy]

Not sure this applies, but that has happened to me and out of curiosity I changed my notebook to 255.255.254.0 remembering IT expanded the stack, not sure the term, therefore I had to use the 254. then netedit saw the cpu

I really like the IPConfig that comes with do-More. I do not need to use the USB port.
SB port.

[ADC Product Engineer]

Bob, we might should look at integrating the IPConfig tool a bit more tightly into Designer/NetEdit for circumstances such as this.  Just a thought.

I had to use it on a PLC that was returned to ADC a few days ago because the IP that was set in it was unknown and it was the bee's knee's.

[BobO]

Bob, we might should look at integrating the IPConfig tool a bit more tightly into Designer/NetEdit for circumstances such as this.  Just a thought.

I had to use it on a PLC that was returned to ADC a few days ago because the IP that was set in it was unknown and it was the bee's knee's.

That's been mentioned recently and that's a good answer. I'd love it to be automatic though and work like it did in the beginning...that's a great answer.