Power Up Order for Ethernet I/O

[Mike Nash]

What happens if a second T1H-EBC100 Rack is powered up AFTER the H2-D1ME rack and the first T1H-EBC100 Rack is powered up?

It seems the power was cycled to the second T1H-EBC100 and that wrecked the system. The "CPU remains in RUN mode on slave error" was ticked for both slave racks. Previously (all 5 or 6 times) I think the second slave was always powered up first. After this happened the rack quit communicating, a new T1H-EBC100 was purchased and it didn't talk either. Attempting to talk the user through the issue, it was found the first rack was now assigned the IP address of the second rack? The original two EBC100s were NOT swapped. The original Rack 2 T1H-EBC100 was put back in and now both IPs are switched around? (DmD can see both EBC100s.) I am not on site and can't be so another tech will have to travel there tomorrow.

I don't know what has happened and now the machine is down. So what is the proper power up sequence? How can this be avoided in the future? We know the power-up sequence will not always be "correct".

[BobO]

Power up order doesn't matter, other than the potential for CPU fatal errors, depending on settings. Note that the "remains in run mode" and "must be present" options both affect startup. Power up order has nothing to do with IP addresses.

[Mike Nash]

So I need to ask then:

What settings will allow all I/O to be recognized regardless of power up order of remote I/O without faulting the PLC processor?

What can I then monitor with the logic to know all the I/O is up and ready before allowing logic execution?

Thanks.

I got word back to the effect that something address-wise was squirreled, but I don't have the details yet how that came to be. Everything is back to working now though.

[BobO]

What settings will allow all I/O to be recognized regardless of power up order of remote I/O without faulting the PLC processor?

"CPU remains in RUN mode on slave error" should be checked.

"Slave must be online to enter RUN mode" should be cleared.

The first option will allow a slave to come or go without generating a fatal error. The second option will allow the CPU to go to RUN mode on startup without requiring the slaves to be online. On powerup, the PLC will wait for a while before continuing to RUN mode without a configured slave...I'm thinking it is about 15 seconds.

What can I then monitor with the logic to know all the I/O is up and ready before allowing logic execution?

$EthIOMaster.SlaveErrors is a bit mask of failed slaves. Any configured slave that is offline will set the respective bit, i.e., Slave 0 will set bit 0, Slave 1 will set bit 1, etc.

[Mike Nash]

What settings will allow all I/O to be recognized regardless of power up order of remote I/O without faulting the PLC processor?

"CPU remains in RUN mode on slave error" should be checked.

"Slave must be online to enter RUN mode" should be cleared.

OK, I had these as you say. I'll try to get some more history on this if I can. Thank you much.

[Mike Nash]

After following up with the tech that got this straightened out:

1) We are not sure exactly how, why or what got screwed up on the IO map or IP address so this one remains a "shrugging of the shoulders."

2) My coworker proved to his satisfaction that the only reliable way to power up the racks was pretty much simultaneously. There could be a few seconds difference, but not much and it made no difference whether the processor or slave was first if the interval between was more than that few seconds. Outside of this, the slave rack was missing in action.

3) The power was reworked to have the processor power and both slaves to all be from the same circuit breaker in the main panel.

I used manual addressing to prevent stupid I/O reassignment if a card was pulled, swapped or a rack didn't power up. (Sorry, but automatic I/O assignment only looks great on the drawing board; in real life it is asking for disaster.*)

_{* Did I get the semicolon right?}

[BobO]

2) My coworker proved to his satisfaction that the only reliable way to power up the racks was pretty much simultaneously. There could be a few seconds difference, but not much and it made no difference whether the processor or slave was first if the interval between was more than that few seconds. Outside of this, the slave rack was missing in action.

I'm troubled then. The Ethernet master is written to be very robust in handling power up/power down/cable pulling/etc type conditions. On startup, the master will wait for 15 seconds before declaring the remote rack as missing. Depending on the settings, it will or won't go to run mode, but either way, as soon as the slave is back, it will log it back in. This has been extensively tested and works well.

To help me understand what you are seeing, it would be great if you would take a screen shot of the Ethernet I/O Monitor showing the failed slave.

[Mike Nash]

To help me understand what you are seeing, it would be great if you would take a screen shot of the Ethernet I/O Monitor showing the failed slave.

While I would love to oblige, the machine is 2 1/2 hours away in another state. I myself have not seen it either as I was already tied up elsewhere.

[BobO]

While I would love to oblige, the machine is 2 1/2 hours away in another state. I myself have not seen it either as I was already tied up elsewhere.

Not to push or nag...but...per his description, it is basically broken. The powerup condition is only one example of how the Ethernet master can fail due to a failed slave. If it is important that it work correctly for you, it really is in your interest to help me identify the issue...