PowerFlex 755 F12 (HW OverCurrent)

[PaulKim1003 1]

Hello

I have a few of powerflex 755 and a couple of them are getting F12.

We did not get this fault before and all of sudden, we are getting it.

Can anyone tell me why i am getting this fault?

Thank you :)

[ElectronGuru 69]

If they've been in service for quite a while and are just now starting to get these faults, the real question is, what changed? If you have saved and off-line project somewhere in Drive Executive or CCW, I'd run a compare tool first to check the known good files against those on the drives. If you do not have drive tools software, use the HIM on the front of the drive and navigate to the parameters of the main control board. You will see a list that gives options like, "linear list, file groups, changed, access level". Selected changed parameters and this will show all the parameters that have been changed to something other than the default values. Write them down and compare against those in the drive that are not faulting. This will ensure that nobody has changed the parameters pcmccartney referenced above.

If this doesn't produce any meaningful results, then you want to work your way through the mechanics of the system to see if you've got an actual excess load (bad bearings, worn gear boxes, etc), loose wires anywhere in the system, excessive environmental temperatures, etc. If you have several drive that have just started doing this, it has to be something that is common to all of those drives.

[BobLfoot 272]

You may also want if conditions permit and you have two identical drives, one experiencing the F12 and on not, to swap their positions and their programming.  See if the problem stays with the Drive Hardware or the controlled mechanical system.  And then troubleshoot accordingly.

[VFD Guy 12]

F12 on a 755 is caused by 2x drive rated current outputted for longer than 8 us. It is important to know when this occurs. On start or while running. If there's and encoder installed, try running open loop. A failing encoder may cause this. Also, starting into a rotating load without flying start on. This is also caused by motor winding shorts, but probably not your case if you have many drives doing this. 

[speakerman 4]

Hey everyone;

We are having these exact same faults with PF750 series drives that are testfired with their local disconnects open. This is the standard required by our local safety authority: when locked out on a local disconnect, full motor control voltage must be sent to the open blades to prove the motor is physically disconnected from the drive. A running status and no motion on the equipment constitutes a successful testfire.

I can see how motors with encoders could have a hardware overcurrent fault after this is done, as of course the encoder does not move with the local open. I am assuming the drive must wind up the amps to try and move it.

The problem is the HW Overcurrent Fault 12 is supposed to be resettable, but in this case it isn't. The drive will let you reset the fault on the faceplate or through the network over and over, but then immediately fault again as soon as it tries to run. It will fault even if the motor is being told to run zero speed, so it's the action of fluxing up the motor that causes this HW Overcurrent fault, not the load on the motor itself.

We also have times where the fault isn't there until we try and run the drive, so we have no idea it's going to fail on the first try. The VFD shows ready to run until it's commanded to, then it faults. The only way we can get rid of this recurring fault is to cycle the power to the drive. After that it runs normally every time. Allen Bradley has not been helpful with this issue, so I'm wondering if anyone else has faced it and solved it.

We have many other VFDs that we testfire with the local disconnect open without this fault, and if they don't have an encoder, it works just fine. I am considering trying to do an SSV to change the motor feedback during testfire to open loop, and then change it back afterwards to encoder. Seems a dirty way around what appears to be a firmware problem of the fault not properly resetting. If the fault would actually reset, this wouldn't be an issue.

Any leads that someone has on this issue would be welcome, it's a pain.

[ElectronGuru 69]

That's quite a tale and I can't wait to hear how (and if) you're able to get it solved. 

Since this works on some drives and not others, my first inclination would be to run online compare tools in CCW or Drive Executive to see what differences there are in firmware, I/O configurations, and parameter settings. For me personally, I've found that encoders can cause a lot of issues when running test modes such as what you described above, especially if the encoders are set to quad check. Maybe start there from within the compare tool(s)?

 

[BobLfoot 272]

I am going from anecdotal and tribal knowledge here and not the manual, but in my experience I've never reset an F12 any other way than by turning off the incoming power and letting the internal caps bleed off and reapplying power.

I'll be curious on your resolution.

[speakerman 4]

Hey BobLfoot and ElectronGuru;

Thanks for the quick reply. I should back up my original comment and say that Rockwell tech support has now gotten back to me, and there's a fellow trying to help. He had some interesting things to say.

His concern is not the encoder feedback but rather the Flux Vector Control mode. He says that changes the way the current loop acts, but is still baffled that we'd get an F12 hardware overcurrent fault with the local open. He is going to get back to me with thoughts on why the F12 comes up, and why it doesn't reset properly. I agree BobLfoot, I have yet to see a reset work. We always have to power cycle the drive to clear it. The manual says it's resettable, and even auto-resettable, so it's a good challenge for Rockwell to make that happen.

In the message above I mentioned using a SSV, but I misspoke. It's actually a MSG instruction using a Set Attribute Single command. We been using this method to disable torque proving on two drives that we need to testfire for over a year now, and it works properly. Those are two of the drives that sometimes have an F12 after a testfire, so I'm going to try Todd's advice and build a MSG instruction to switch the VFD Parameter 35 from 3-FVC to 0-V/Hz while local is down, and see if the faults go away. FVC will be disabled after torque prove is, and re-enabled before torque prove is, so it doesn't generate a config error. 

Will post the findings after this is tried. Should be able to do it sometime tomorrow.

[VFD Guy 12]

An F12 should be resettable. Something else is going on. How big are these drives. How long before they fault after starting?  If you command 0 hz, do you fault?

[speakerman 4]

Hey VFD Guy;

Two drives are 3 HP PF753, two drives are 7.5 HP PF755, and one is 40 HP PF755. All are firmware 13 or higher.

All five run in Flux Vector mode, and all five have encoder feedback. The two 7.5 HP drives are running with torque prove enabled.

The fault happens the instant the motor is told to run. It happens while the motor is being fluxed up, before any motion occurs.

It happens even when the speed reference is set to 0 Hz.

In other news, I tried the programming change to push SVC control into one of the 7.5 HP drives. This worked, no more F12 faults. It did sometimes generate an Output phase loss fault, so we also had to set the Output phase Loss level to 0 or we got that alarm. The output phase loss action was set to 0 - ignore, but it still generated a fault. This is related to the torque prove parameter, as it will ignore the setting if torque prove is enabled. It's still weird, because torque prove was disabled before the testfire happened.

No matter, so far we've testfired the motor 10 times in a row with no faults either way, and it appears to be working. I'll post more when I hear back from Rockwell, they are looking into this non-resettable F12 fault.

**EDIT: Forgot to mention a comment by Todd from Rockwell, that it could be related to a slip compensation value that is calculated to a ridiculous number during the testfire with an open local disconnect, since there is no motion from the encoder while "running" so the "slip" would be... LARGE? Then once the motor is connected it tries to use that level of slip comp and it results in the F12. Power cycling the drive erases this value and the drive starts with default slip comp values and functions normally again. Just a theory so far, but it seems reasonable, I believe he's attempting to prove that now.**

Edited 15 Jun 2021 by speakerman

[VFD Guy 12]

 FV  closed loop mode uses slip regulation. All other modes use slip compensation. You can read about the differences in the manual on these. It’s just a hunch but try setting the flux up time to 0 secs in fv mode. Let me know if it faults in this case. And I haven’t heard of slip used from previous start. I have heard of flux being used from previous start. Try changing the flux current value and then back then start. Let me know if either of these tests work 

Edited 16 Jun 2021 by VFD Guy

[speakerman 4]

Hey everyone;

It has been a long time so I wanted to post an update. We have not heard back from Allen Bradley on this issue. It was resolved for most of our motors by adding the msg instructions to change the control mode on two of the drives, changing one other to SVC, and just power cycling the other two after a down-day.

This type of fault is resettable in the drive so my hope is Rockwell is working on changing the reset action so any value it is holding on to that causes this fault gets cleared when it is reset. That is the distracting part of this problem and it can cause both extended downtime, and in our case, a big mess. I'm sure there are many plants like ours where several motors need to ramp up in sequence for things to go well. I have explained to many people to not reset this fault on the drive, but it just takes one person to hit that button without looking and we can have a plug-up.

Power cycling the drive should not be required if the fault allows a software reset, so I feel this problem does need to be resolved on the firmware level. 

[VFD Guy 12]

Odd solution. Did you try what I suggested above?  I’ve never heard of this fault caused by stored data. I could possibly it as a secondary issue to the flux value when above base speed. I’ve found the best way to force Rockwell on an issue is to continue to call in and ask for updates on the case. But if you are happy with your solution that works too