So I have a sort of unique situation where I'm wanting to run a PF755 from the IO and over ethernet. Of course, this comes with it's own set of challenges. It's tied into a multi-stage exhaust fan system for some emergency equipment. I need the hard-wired system to over-ride ethernet commands, always. What really makes this a pain is that I can't necessarily count on an ethernet connection being present. I basically need the IO terminals to over-ride the EIP commands. I'm really trying my best to keep this system's wiring as close to the original as possible.
I have two interposing relays with two sets of contacts. Each one switches DI RUN and it's DI Speed Sel. One relay sets the drive's speed at 20 Hz, one sets the drive's speed a 60 Hz. When neither is made, the drive sits at Speed Ref A, which is the EENET port. Once one of them pulls in, it uses the appropriate speed reference.
There is an emergency over-ride, but it's only for a single speed. Parameter 172, manual would be good to force the IO terminals to override ethernet control, but it forces you to use the manual speed reference, and I need to use the DI Speed select.
When I started this, I spoke with Rockwell and was told that the IO terminals would always over-ride ethernet on Run level and 2-wire control. The issue is that without that run input made, the drive start is inhibited. I also tried to use an additional Run Enable terminal, but on 3-wire control, terminals have to be made and broken. I was also told that using 2-wire and run level, if I sent a stop command over ethernet, the drive would stop, but then take back off. This isn't true. Even on 2-wire control the DI for Run must be broken and then made again. I'm going to test again, but I believe if I'm using the Run bit over ethernet and I take it away with the DI Run made, the drive's speed reference won't update. Using the onboard relay isn't an option as the contacts aren't rated for such a low current and the extra failure risk isn't acceptable. I've spoken with four separate people from Rockwell support and have yet to get a good answer.
Devicelogix was suggested, and I've been thinking about ways to manipulate parameters. I'll certainly need to do some testing, but I'm wondering if there might be a way to ignore ethernet commands. I'm thinking perhaps I can mask off certain sources using the 32x parameters.
Initially, my plan was: have the drive sitting with no inputs made, starting with run level, use DI status to switch to run edge if no DI's are made, use ethernet control. This is actually not necessary, as the logic doesn't work the way I was informed.
Now I'm thinking about using device logix and the mask parameters:
On initial startup, use devicelogix to perform checks. "resting" state on the drive's configuration would be that ethernet is masked off and only DI logic commands are allowed. I can't mask a stop command, BUT I can use the RUN bit from the PLC, so a stop command wouldn't be necessary. If the PLC can't send a stop, it won't be an issue. I'll also mask off the drive's speed reference to the DI in it's resting state. If no inputs are made, then allow the ethernet speed reference. As soon as any input is made, disable it. There other issue I'll have to verify through testing is that I may have to stop the drive either before or after applying this masking.
What I'm going for here is predictability in how the drive will behave. I want to integrate it into our control system for monitoring and HMI control, but be certain enough about how the drive will be have, and that the IO will over-ride ethernet commands without actually doing this in the PLC. I also need to make sure that should the drive start up, it's going to run on the hardwired system as it should. When I agreed to tackle this, I honestly thought there would be a terminal I could assign to just pick a dominant logic source. There are certainly better ways to go about doing what they want with this system, but I'm in it now. Just typing this out has helped some, but I know there are some members here that might have ideas or suggestions.
I have two interposing relays with two sets of contacts. Each one switches DI RUN and it's DI Speed Sel. One relay sets the drive's speed at 20 Hz, one sets the drive's speed a 60 Hz. When neither is made, the drive sits at Speed Ref A, which is the EENET port. Once one of them pulls in, it uses the appropriate speed reference.
There is an emergency over-ride, but it's only for a single speed. Parameter 172, manual would be good to force the IO terminals to override ethernet control, but it forces you to use the manual speed reference, and I need to use the DI Speed select.
When I started this, I spoke with Rockwell and was told that the IO terminals would always over-ride ethernet on Run level and 2-wire control. The issue is that without that run input made, the drive start is inhibited. I also tried to use an additional Run Enable terminal, but on 3-wire control, terminals have to be made and broken. I was also told that using 2-wire and run level, if I sent a stop command over ethernet, the drive would stop, but then take back off. This isn't true. Even on 2-wire control the DI for Run must be broken and then made again. I'm going to test again, but I believe if I'm using the Run bit over ethernet and I take it away with the DI Run made, the drive's speed reference won't update. Using the onboard relay isn't an option as the contacts aren't rated for such a low current and the extra failure risk isn't acceptable. I've spoken with four separate people from Rockwell support and have yet to get a good answer.
Devicelogix was suggested, and I've been thinking about ways to manipulate parameters. I'll certainly need to do some testing, but I'm wondering if there might be a way to ignore ethernet commands. I'm thinking perhaps I can mask off certain sources using the 32x parameters.
Initially, my plan was: have the drive sitting with no inputs made, starting with run level, use DI status to switch to run edge if no DI's are made, use ethernet control. This is actually not necessary, as the logic doesn't work the way I was informed.
Now I'm thinking about using device logix and the mask parameters:
On initial startup, use devicelogix to perform checks. "resting" state on the drive's configuration would be that ethernet is masked off and only DI logic commands are allowed. I can't mask a stop command, BUT I can use the RUN bit from the PLC, so a stop command wouldn't be necessary. If the PLC can't send a stop, it won't be an issue. I'll also mask off the drive's speed reference to the DI in it's resting state. If no inputs are made, then allow the ethernet speed reference. As soon as any input is made, disable it. There other issue I'll have to verify through testing is that I may have to stop the drive either before or after applying this masking.
What I'm going for here is predictability in how the drive will behave. I want to integrate it into our control system for monitoring and HMI control, but be certain enough about how the drive will be have, and that the IO will over-ride ethernet commands without actually doing this in the PLC. I also need to make sure that should the drive start up, it's going to run on the hardwired system as it should. When I agreed to tackle this, I honestly thought there would be a terminal I could assign to just pick a dominant logic source. There are certainly better ways to go about doing what they want with this system, but I'm in it now. Just typing this out has helped some, but I know there are some members here that might have ideas or suggestions.
