Drive problems .... Arghhhhhhh

Hi Gentlemen

I wonder if you can help me, I have been called a couple of times as one of our customers uses a box lift that we sold them and installed / commissioned. For some reason, evey now and again, the drive seems to stop driving on the way up and drops straight into the floor, The brake is controlled by the drive and all the PLC is doing is speed selection. The brake contactor has been changed. The drive (ABB 355) is running in sensorless vector control and has no Encoder feedback. I have looked at the parameters and the brake parameters seem fine as they are default and have been verified as correct by ABB. I am at a bit of a loss as to why this would happen. The brake must be off for it to drop but brake gap is ok and seems electrically sound

Any ideas?

Regards

The brake must be off for it to drop but brake gap is ok and seems electrically sound

Click to expand...

The brake engages with power off, correct?

Is it possible the drive is faulting and the brake can't catch the load fast enough, once the drive lets go?

Interestingly, we had to help a customer out with a delay problem he was having with his brakes. There was a note in the brake instructions about breaking both the AC going to the rectifier, and the DC going to the brake coil. It also suggested an MOV across the contacts. They were seeing up to 2 seconds of delay from power-off to brake engagement.

HI Gene ,

Thanks for the reply

Yes the brake is engaged with power off.

It could quite possibly be a fault and the break not reacting fast enough. A fault is shown in the logs (Not on the drive locally as by the time I have got to site power is lost so I cannot get the log) but buy the higher level system that logs faults that are given to the plc by the drive fault digital out.

the above meant that I could not tell if the drive fault was caused before or after the thing had crashed into the ground.

The contactor does break both AC to rectified and also Dc to the coils. there is no MOV across the contacts though

did you apply these fixes and the fault went ?

Kind regards

Yes, it sped up the engagement...

The other issue might be that by the time the brake engages, the inertia is so great that the dynamic torque of the brake can't stop it in time before it hits the floor.

It's tough to troubleshoot an intermittent problem. but perhaps you could manually bring the lift up, and just before the top, kill the power and observe what happens.

I see a few things that can be an issue
Open loop vector drives develop low torque at low HZ there is just no way for the VFD to know that it is not developing the necessary torque to hold the load.
Doing a hoisting application with out either a load brake of flux vector (encoder feedback) drive is a bad move and in my opinion is dangerous.
A load brake will prevent the load from falling in the event the VFD fails. And a good flux vector VFD will detect the failure and set the brake to prevent the load from falling. Check out Electromotive drives they have a good extenuation and supply you with what you need.

I asked the guys on site to drive the lift up and kill the power. They tried it a number of times but could not replicate the fault. They have IR tested the motor supply cable and all ok. There is an identical unit next to it which is running the same parameter set and setup but it does not have the issue !

The site team have changed the motor / drive a number of times but it still has the issue. Could the fact that they are not updating the cos phi of the motor in the drive cause the issue ?

Each motor will have it's own tuning parameters. Despite what the nameplate or spec sheet says, an autotune should be performed for best performance.

As GaryS stated above, some encoderless vector drives do not produce 100% torque down to zero speed, which is needed in most elevator/lift applications. In my experience, encoders on the motor in most of these applications are not required, if you spend the time to tune the motor and the brake control tight enough. While they may not be as consistent in speed from no-load to full-load, normally, they are good enough. When there is an issue, the encoder and cabling is suspect #1, therefore leaving it out makes troubleshooting easier.

Sorry they could not duplicate the issue. It really sucks when you can't catch what the true symptoms are to produce the end result. Believe me, I've been there!

Is this a scissor-lift? In that case, the torque is highest around mid-height... The torque curve is parabolic. Maybe they were taking it too high, and the brake was able to stop the lower torque load before it fell through the higher torque points? Just thinking out loud.

Hi gene

thanks again for the help. A motor ID was done when the Param set was reloaded. I am going to site tomorrow so I
Think I am going to add the MOV anyway. Then maybe monitor the torque as it runs to see if there are any tight spots. It runs on belts with the motor at the top of the mast. The mechanical engineers assure me that the belts are correctly tensioned. I will try and recreate it tomorrow and maybe try and get an encoder working on there

The lift lam weighs the same empty or loaded. It only transports 2 empty plastic crates about the size of a shopping basket

While I really like the ABB350/355 drive series and have used it for a host of applications, it is most definitely NOT a hoist drive. In the ABB family you would need an ACS800 0r 850. The post above recommending Electromotive is right on. These are designed as hoist drives and are excellent.

Cowmanator said:

It could quite possibly be a fault and the break not reacting fast enough

I could not tell if the drive fault was caused before or after the thing had crashed into the ground.

Click to expand...

Cowmanator said:

I asked the guys on site to drive the lift up and kill the power. They tried it a number of times but could not replicate the fault.

Click to expand...

Gene Bond said:

It's tough to troubleshoot an intermittent problem.

Click to expand...

For these intermittent kinds of problems I have found a security camera DVR to be invaluable. set up the DVR with one or two cameras. So that you can view the lift if it "crashes" and a view of a "pilot light" in parallel with the brake coil. Another view of the VFD HIM might also be a good thing.

The tricky part might be saving the data for viewing. If you set it up for "record on motion" many recorders have a delay of about 2 seconds after the first motion so you may miss the event. If you set it up to "record all" and you are not there to stop the recording then it may overwrite with new data.

The unit I have has 30 frames to the second recording, and I sometimes need finer resolution. But for this job I think it would work.

A few things to look at
With an open loop drive the min speed should not be lower then 20Hz, below that you may not have enough torque to hold the load.
Check that you are not losing the speed reference from the PLC to the VFD
a run command to the VFD without a speed reference will cause the brake output to energize with no torque to hold the load.
Most VFD's don't handle overhauling loads very well, when the hoist is lowering the load it is overhauling.
keep in mind that when you command a VFD to run it will energize the brake output weather the VFD is in control of the motor or not. It's a dumb device it doesn't know what you want it do.
even the best have been known to fail.
I always use Electromotive drives on cranes and hoist's unless the customer request otherwise then I make then sign off on all liability for that project. I don't need that grief.
I really don't thing it's a delay in the time it takes the brake to set and hold the load after the output is turn off. that time would be less then a sec
the VFD is clearly holding the brake on while providing no torque to the motor.

Just as a side note Electromotive Hoist drive have both proof of torque and proof of brake as part of there standard setup.

Good evening gentlemen,

I must say that I am very grateful for anyone who has contributed to this post. Much appreciated.

After a long weekend and being about ready to give up, having looked at every available parameter having looked at everything and only found a sensor that was not in a mount on the lift bed, (which detects if the bed is occupied or not), before leaving site I thought, I will just try my best to break the lift by changing direction quickly, power off on , anything I could... etc etc...

At that point I found that if I changed direction really quickly, moving up and then down (strangely not the other way round) the drive started to move down in a very strange slow speed (which was never being selected via the digin speed selection from the plc, as it was almost 0 but creeping along. so I tried this direction change on the sister lift next door. BOOM .. it came crashing into the floor!!!!

As it was late I put a patch in the plc code to stop quick changes in direction and left site.

we then ordered an encoder interface module and requested the OEM to site (ABB).

After working elsewhere for a few days I returned to site, they had not had any issues since I loaded the plc code patch. ABB were also on site

after a large amount of tests done with the engineer, he concluded that all parameters were ok and that basically the drive could not handle the quick change in direction on the mechanics/application that we had. when the direction change took place it seemed to just go out of control and although it looked like it was going down, the direction that the drive thought it was going was actually up, but not with enough power to overcome the interita. he took a scope of the other failure state where it crashes (from a low height) and said he would feedback the results when he had time.

we then enabled the encoder and it ran like a dream even with quick change in direction. we could not re-create the fault.

since enabling the encoder we have not had an issue, and we also have not had the report from ABB. But I can imagine it is difficult to send a report stating that the drive cannot cope ?

anyway case closed and thank goodness that I do have to go back there for a while

Kind regards and thanks again for the help. many respects

I believe that the reason the issue manifest on that lift only was because the photocell that was detecting presence on the lift was blipping, this would make the plc think the bed was occupied/unoccupied and therefor got to pickup/deposit position. making it change direction quickly. hence the issue