Automatic Device Configuration Possible Safety Concern?

kentuckytech

Member
Join Date
Aug 2008
Location
Kentucky
Posts
62
Hello everyone, I was hoping someone with a lot of experience with Automatic Device Configuration would chime in with any of your thoughts on this possible scenario. I am currently setting up 4 pumps with identical Powerflex 525s and I am setting up a Stratix 5700 6 port managed switch for communications. I have set up ports 3-6 using DHCP persistence so that in the event of a drive failure the mechanic just wires up the new drive and the stratix will assign the IP address and the PLC will download the parameters. I have successively set this up on my test stand and it does function properly. While playing around with the equipment I swapped 2 ethernet cables in ports 3 (pump 1) and port 4 (pump 2) and the drives lost communication and then re-established communication and continued to run their respected pump. The issue I found was as soon as the drives had a power failure and then powered back up they received the IP address of the port I swapped them to, thus pump 1 just became pump 2 and pump 2 became pump 1. The reason I bring this up is because we have mechanics that while troubleshooting a pump or motor issue sometimes get it in their head it might be a communications issue and they will swap ethernet cables on the switch thinking the ethernet port contacts could be dirty causing the issue. Doing this wouldn't cause an issue until some time later if the power cycles to the drive and then long after the mechanic that did it has gone home and it happens on a different shift the PLC is now running the wrong pump if it tells pump 1 to run. This scenario isn't a great deal with my application but I could imagine some scenario where this could be a safety issue. I hope I explained this clearly enough. My thoughts are if the drive parameter C128 is set to 2 (BOOTP) like it is using DHCP persistence, the drive should dump the IP address if communication fails so that when it is re-established the IP address of the swapped port would be assigned at that time instead of after the drive power is cycled. If this was the case the mechanic that swapped the cables would most likely see the issue he created and could correct it. Yes, i know the mechanics should know not to swap the cables but I know what happens here at my plant with different mechanics coming and going. Anyways what are you guys thoughts on this?
 
I don't think I am saying anything you don't already know: unless Stratix has a "use DHCP table's IP assignment for these four known MAC addresses, for unknown MAC addresses assign IP address by port" option, you are between a rock and a hard place for whatever approach you take.

I think you have done well to consider a "what if?" scenario and identified an issue.

Not knowing your process, I can't comment on the safety, but in summary the concern you raise is a consequence of synergy between

  • the choice made to tie the DHCP server-assigned IP addresses to the Stratix port instead of the 525s' MAC addresses, and
  • mechanic training and behavior.
Since it is easier (I assume) to swap cables than to swap 525s, one suggestion would be to go back to the normal DHCP server behavior and tie the IP addresses to the MAC addresses. The consequence of that would be to add a step, i.e. of updating the DHCP IP address table in the Stratix, to the procedure for changing out a 525. Perhaps a VPN or temporary network connection to the Stratix could be made available in case that needed to be done at 3am.

Another option would be to assign static addresses to the 525s and not use DHCP at all. That would require a procedure to assign the IP address when a spare 525 is to be installed, but that could be done offline before the swap, perhaps an app of some sort, with large comfortable buttons and easy-to-follow steps, could be created to do it.

If there are at least four spares, then the assignment, static or MAC-address-based, could be configured ahead of time, and the mechanic would then need to read a label to select the particular 525 from the spares store that will replace the one that failed.

Again, I won't comment on the safety issue, but at least with the other approaches (MAC-based DHCP or static IP assignment) the worst case is that a 525 is not configured to run after it is installed, but that happens only after the 525 it replaced has failed, so those other approaches do not make the situation worse.

If the mechanics cannot be relied upon to not swap cables, even if you put labels on the cables and the ports with your phone number in large red letters, then port-based IP addressing may not be an option, even if it add steps to swapping out a failed 525.

Bottom line: training and behavior are the root issues; you can't fix ...

TL;DR

Also, it may not only be power failures that cause the switch back if the cables have been swapped. If the DHCP assignments have leases that expire (usually after some number of hours or days), then one or more 525s will attempt to renew its lease. What does the Stratix do then, because the port-assigned IP address will already be assigned to a 525 on a different port? The same scenario could occur if just one 525 had a power failure, or a cable was disconnected long enough for it to request a new DHCP assignment. The Stratix DHCP server would be configured to give that 525, which is requesting an IP address on that port, an address that was already assigned to another 525.
 
Last edited:
I don't know the ins and outs of the powerflex drives and stratix stuff, but with the Schneider M340 and M580, which also have a DHCP based address assignment function, its done by what they call "role name". So you tell the drive during set up "you are PUMP314" or whatever, and it includes that in the DHCP request.

I don't know if this is relevant, but it could be worth a look to see if it's possible to do it this way rather than by port assignment.

Otherwise, as DRbitboy says, restricting by MAC address is the safest bet, but requires extra intervention if a drive needs replacement. How often does that really happen though? I don't use any powerflex gear so i don't know how much of a risk this is
 
I don't know the ins and outs of the powerflex drives and stratix stuff, but with the Schneider M340 and M580, which also have a DHCP based address assignment function, its done by what they call "role name". So you tell the drive during set up "you are PUMP314" or whatever, and it includes that in the DHCP request.

I don't know if this is relevant, but it could be worth a look to see if it's possible to do it this way rather than by port assignment.

Otherwise, as DRbitboy says, restricting by MAC address is the safest bet, but requires extra intervention if a drive needs replacement. How often does that really happen though? I don't use any powerflex gear so i don't know how much of a risk this is
Using the Powerflex525s failures are few and far between so far but the Powerflex 4s and 40s fail fairly regular here at my plant. That is why i decided to try the ADC but so far we are having better results out of the 525s.
 
Some other thoughts: I made a ten pump system with PF525s and looked strongly at ADC, but chose against it. It was too blindly automatic if that makes sense. If I could make an HMI prompt to confirm before executing ADC, I probably would have done it.

I also didn't like assigning IP automatically for various reasons. Maybe with an HMI prompt, maybe with messaging to the Stratix... nah. Keep it simple. Every other networked drive in the place is static IP. If a mechanic is already manually setting IP, might as well keep going. Including IP, it's 30 parameters to set in a new drive. Not a terrible burden for the rare occasion. It's a simple V/F application with no motor tuning.

In the end, I put all the needed parameters for setting a new drive on a maintenance HMI window and a laminated sheet in the cabinet. All settings are the same for all drives except IP octet 4 is pump number. I felt a bit weird making pump 1 192.168.1.1 and the ENBT .100 but it's a local network of just drives and the HMI and it's simple for a mechanic.

In other early experimenting for manual ADC-ish, I made a scattered write MSG for each drive to program it. I never used them on the HMI since the mechanic would at least be setting IP, but they're still there with a toggle bit for my rare convenience.

One other tidbit: This is an important vacuum pump system that modulates with demand. Without vacuum, the packaging department doesn't pack. I added "oh no!" switches to the drives with a SPST toggle switch mounted in the side of the L shaped cover of the 10hp PF525. I used Ideal brand switches with built in pigtails to turn on an input set to Jog at 60Hz. If something happens where the PLC doesn't control the drives, we can manually run whatever we need. They're handy other times too. That would not be a thing to do on a system where excessive pumping could create risk. STO is wired to an e-stop on these.

Many of our PF525s have a door mounted HMI with parameters saved. Those are great, but this system wasn't worth them.


Other topic from your comments. We use quite a few PF4/40. I've heard others complain of poor lifespans from these. We don't see that problem with most applications. We use a 5HP drive as the base model if they fit, even with a half HP motor. There are two panels that have the smaller frame drives for space limitations and they are noticeably less robust than the 5HP ones. I perceive the 5HP PF4/40 as reliable even with a 5HP motor. This vacuum system used to have 7.5 HP PF40 for 7.5 HP motors packed tight that didn't fare well. Oversizing to same frame size rated for 10 HP were much better.

In PF525, there are a few 3HP ones around, but we've been using 5HP as the base with these also. Overkill, but not a substantial price difference for extra reliability we at least notice in PF4/40. PF525 are not old enough to know yet.
 
Last edited:
Two words: Risk assessment.

The scenario is similar to that the wrong drive starts due to a programming error. Any personal safety concern should be covered by suitable means such as mechanical guards, local isolation switches or similar.
If the concern is that a maintenance person shall service a device with the guards removed, then the answer is to use LOTOTO procedure. In this ways the device is securely deenergized, even if there is an error in the control system.
 
Your concern is one of a few reasons I never use ADC. I feel like it's a good idea that was implemented very poorly.
 

Similar Topics

Hi everyone, I was just wondering what your thoughts are on using Rockwell's Automatic Device Configuration. How has it worked for you? Have you...
Replies
5
Views
1,930
Good Morning , Thanks so much for your help before. I had to replace some Powerflex 525's on this project because of faulty displays. (...
Replies
5
Views
4,176
I am looking for some information on the Automatic device replacement(ADR) feature enabled on some DeviceNet slaves. One part of ADR is...
Replies
4
Views
3,308
Hello, I need to create an automatic transfer panel that connects to the generator when the mains power is cut. I can draw up to 60kW and draw up...
Replies
0
Views
78
Hello everyone, I'm having trouble solving this one and was hoping someone could help. I have a AB CompactLogix L16ER PLC connected to a AB...
Replies
2
Views
577
Back
Top Bottom