SETUPIP and configuring the ECOMEX for DHCP

[johnr]

Question:

When executing a runtime SETUPIP ladder instruction for the ECOMEX, to configure for DHCP operation, is a DHCP request message sent out immediately to the LAN?  If not, could that possibly be added or are there unwanted consequences of doing so? 

We are having some issues with BRX/ECOMEX PLCs periodically losing their VLAN connections, probably when the IT group's switches/routers are being reset.  When that happens, the only way to re-establish DHCP settings and re-connect to the VLAN is through a full CPU power down, or by popping the POM in and out.  I implemented a manual network reset function that invokes SETUPIP manually, but no luck in reconnecting without power down.

We are still running 2.9.x on these machines, haven't migrated to 2.10.x just yet.

[johnr]

Could someone from Host respond to this, please?  I've got a network of about 25 BRX and 25 DL06/205 PLC's and the BRX units drop off line from time to time whereas the DL's don't.  We're trying to isolate the source of the issue, but we're also trying to figure out our best potential work-arounds.  Thanks!

[BobO]

Under the covers it sets the flags that should trigger a DHCP refresh immediately. DHCP is a background function that operates outside the normal PLC scan, so it isn't synchronous to the scan, but according to Wireshark, yes, I do see the DHCP traffic within a second of executing SETUPIP.

You might try using SETUPIP to force it to a fixed IP, before hitting it with DHCP again, but I got the DHCP traffic following each call to SETUPIP.

The DHCP server and request gives the same IP address every time though, so if there was a problem reinitializing the address if the address changed, we might not be seeing that. I can look at what it takes to force a new address, but generally it is preferred to not do that.

[johnr]

A couple weeks ago, I made our manually invoked "VLAN reset" HMI function into a mini sequence, that first calls SETUPIP to set a dummy static IP address, waits three seconds, and then calls SETUPIP again to switch to DHCP.  It didn't seem to help but my testing wasn't exhaustive.  I think I'll modify and add a few more seconds wait time in between, and see if that gives better results.

The IP addresses being set by the DHCP server are configured to be fixed to a specific MAC address.  If there is no recognized MAC address, no IP address is issued.  So the addresses shouldn't change for a specific unit.  OTOH, you seem to be implying that a DHCP server may not always re-issue an IP address, and since I hear that the ECOMEX doesn't remember it's IP settings, maybe there's a place for things to fall through the cracks with certain sequences of events. 

From our experience to date, forcing an address re-issue sounds like a good thing.  But that could maybe be done as a switch/router configuration change as well as a PLC OS mod.  I'll look into that.  I'll report back what I find, but it may a while before there's any useful info to share.  We work through our central IT group to address all networking issues, so testing and resolving these things takes some time.  Thanks for the feedback.

[BobO]

DHCP servers generally reissue the same address to a given MAC, but if memory serves, that is a config/choice and can't be assumed.

The ECOMEX doesn't store the DHCP issued address, but does allow for a static IP, so that might be an option. The currently active address is saved to DST62 (I think?) so you can know what is configured at any time. It is updated in DST62 at the same time it is updated in the stack.

[johnr]

My desire was for the VLAN to be static IP, but I also wanted all of the PLCs and HMIs to reside on a single subnet, as it allows all connected devices to be easily browsed in Netedit and C-More software from our SCADA server.  The automation lines are spread across multiple buildings so a physically isolated subnet was not possible and I was told that a DHCP-managed virtually isolated subnet was the way to go.

This discussion about forcing re-issue of IP address has got me thinking I may have caused part of the problem, though...

[Holds out wrists in the event that 50 lashes with wet noodle is warranted]

In my ladder logic that invokes SETUPIP, I have first been clearing registers DST62-65, which I thought would guarantee that any previous configurations would be fully cleared, and maybe that would force things.  Now I'm wondering if it would be better off if I just left those registers alone.  Always trying to be too cute by half, I am...

[BobO]

My desire was for the VLAN to be static IP, but I also wanted all of the PLCs and HMIs to reside on a single subnet, as it allows all connected devices to be easily browsed in Netedit and C-More software from our SCADA server.  The automation lines are spread across multiple buildings so a physically isolated subnet was not possible and I was told that a DHCP-managed virtually isolated subnet was the way to go.

This discussion about forcing re-issue of IP address has got me thinking I may have caused part of the problem, though...

[Holds out wrists in the event that 50 lashes with wet noodle is warranted]

In my ladder logic that invokes SETUPIP, I have first been clearing registers DST62-65, which I thought would guarantee that any previous configurations would be fully cleared, and maybe that would force things.  Now I'm wondering if it would be better off if I just left those registers alone.  Always trying to be too cute by half, I am...

Those registers just report what's in the stack. The only thing clearing them does is allows you to know when the real value got updated.

[johnr]

Those registers just report what's in the stack. The only thing clearing them does is allows you to know when the real value got updated.

That's exactly how I use them, It's very helpful that the DST registers allow me a little window into what's going on when we try to connect or reset.  Good to know that's not making things worse.