Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations waross on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Help with hoist application needed 1

Status
Not open for further replies.

tmckeown

Electrical
Jul 3, 2008
11
Hi,
First time posting here. This is a great forum. I've learned a lot from just reading it all day.
I've been assigned to make a cable hoist for our company. I finished the first batch of them and they turned out pretty well, but I'm having a few problems that I could use some expertise on. First, I'll give you the parts that I'm using, so you get a better picture of what's going on.

1) ABB ACS350 vector drive
2) Brother mid series 1HP gearmotor (1268 in-lbs @45RPM)
3) Dynapar encoder (on drum shaft for positioning)
4) 8" Diameter grooved drum
5) Custom controller (we made it)

The spec I needed to meet was:
Must be able to accurately position a 300# load
Must be able to move it from zero speed to 100 feet per minute
Must fit into a specific lighting truss

Description:
A user sends a command from a lighting console (DMX) to the controller. The controller keeps track of positioning as well as translating the desired speed and destination info from the lighting console. The controller sends the drive speed (0-5 volts) and direction info. The controller also creates the ramps up to speed, down to stop and it sets the brake when at the destination. The drive obviously controls the motor. The drive is set to have the fastest ramp .1 sec. This is so the controller can handle the ramping. We are running the drive in vector torque mode, though we have done tests in vector speed mode as well. The motor has a brake. Both the controller and the drive have to tell the brake to be released before it gets released. When the drum is moving, the controller counts the encoder pulses to determine its position. When its within X steps from the destination, it start a ramp down of the control voltage feeding the drive. When the destination is reached, we set the brake and remove voltage to the drive as well as telling it to not move either up or down.

For the most part, it works well, though we're not completely satisfied with the performance. I'm hoping someone might be able to fill in the blanks of our knowledge and help us get the project completed.

We chose the Brother gearmotor due to it's size 15"H and it's weight 44#. We chose the ABB drive simply because a sales rep said it would do what we needed. On an 8" drum, the motor is able to give us 317# of torque. We pushed the max frequency of the drive to 69HZ, which lets us hit the desired 100' per minute. We can get very good repeatability on positioning.

So, what's the problem?
We are having trouble controlling the motor at very slow speeds. We find that we are not able to release the brake immediately upon start of a move, or it will drop the load. So, to get around that, we have tried two things. (not simultaneously)

1) We set the drive to release the brake once it's reached a certain speed.
2) We send the drive a minimal control voltage and keep it there for a few seconds before releasing the brake.

In both cases, it does prevent the load from falling, but the initial move is a bit of a jump. If we lower either of those two values, the load drops. We could almost live with the jump, but we see another related problem when we try to do very short 1"-2" moves. When we do a very short move, occasionally after the move is completed and the controller has turn on the brake, the drive won't shut off. We can hear it pulsing; trying to move. We checked the current to the motor, and the drive is sending the max current we allowed (6.2A). If we then try to do another move in the opposite direction, the drive still retains control and tries to move the motor in the previous direction. When that happens, the drive keeps moving the motor until it reaches the torque that is set by our control voltage and then quickly starts moving in the correct direction. Pretty odd eh? For the longest time, we though the controller had a software bug. After days of testing, we found that we can reproduce this glitch at will.

We have spoken to the drive engineers at ABB. They tell us it is because we are not allowing the drive to ramp down before we set the brake. We don't want the drive to do a ramp. We are creating the ramp in the controller and sending the control voltage to the drive. If we allow the drive to handle the ramp, there is no way for us to stop at the correct destination. The encoder for positioning connects to our controller.


This brings up a number of questions:
1) Is a servo motor a better option for a cable hoist? They seem very expensive and much larger than the Brother motor.
2) Should we change the Brother motor to one with an encoder? The brother has no place to mount an encoder. The brake is on the end of the motor and there is only about 1/4" of shaft sticking out from there, but it's all under the fan housing. Maybe someone knows of an encoder we could add?
3) Should we change the drive? Maybe there is one that could give us full torque holding without a motor encoder.
4) Have we reached the limit of what we can do? Do we need to de-rate the hoist to a lower lifting weight, so we can move slower and avoid these problems?

I know I've probably created even more questions with my questions. Thanks for the help.

Tom
 
Replies continue below

Recommended for you


The control system you need will be similar to the Drawworks control as used on a drilling rig. They incorporate a brake ( electric eddy current or disc type) into the control system.The drive motor is also controlled by a VFD drive, which can 'stall/hold' the load.
The companies to contact for info on the control system are NOV-Varco or Maritime Hydrulics.
These controls are for systems up to 3000 hp, but the principles are the same for smaller loads.

Offshore Engineering&Design
 
It sounds like you do need position information to the drive not just your controller. That way you can properly slow and stop the motor holding it with the vector VFD then apply the brake and then power down the drive.

Next move you power up the drive. Command zero velocity with your controller. Release the brake and no motion should occur. Then ramp your velocity however you want.

Otherwise you're running a sort of kludgey brake-un-brake scheme here that is 'sort of' working pretty well but not perfectly.

Keith Cress
kcress -
 
Thanks for the replies,

Keith,
Do you have any recommendations on motor manufacturers? We went with the Brother because it was light and small, which were pretty critical to our design. Unfortunately, they don't have an encoder option. There are some third party add-ons from Dart, but the resolution is only 40 pulses per revolution. The encoder we use for positioning is on the drum shaft, which is 40:1 to the motor. So, I don't think I can use that either.

Thanks for the help,
 
The actual brake control and hoist control should be possible with that VFD or another VFD using an encoder feedback. A properly set-up VFD could hold the hoist stopped without the brake. I'm quite certain there are some VFD's with a "hoist" macro that do all the controlling you want themselves. I don't know if that particular ABB drive does but ABB will have a model that does.

Basically, your controller would be there just to provide a speed and direction signal as well as a run/stop to the VFD.

If you are going to continue down the path you are going then maybe consider using the voltage mode on the VFD. When using the vector mode the VFD attempts to control the speed based on the motor data it's measuring which can cause the problem you're describing.

You also need to consider the motor heating when holding the hoist stopped or running at slow speeds.

Hopefully, some others here with more closed loop VFD experience will chime in with some more specific information.
 
This drive has been used in applications like yours - without any encoder om the motor. I was somewhat involved in that drive a long time ago but have no interest in the actual company.

Gunnar Englund
--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...
 
Gunnar; I'll check out that drive. maybe we just need a different one. I'll also call ABB again, since they helped spec the 350 series.

Lionel; From all my reading we "should" be able to get it to hold at zero speed, though so far we have not been able to do that. I think having an encoder on the motor would improve the chances of success.

I might have stumbled on something else too. On one of the forum posts, I found this formula for calculating the HP needed:

1HP = 33000 LB * FTperMin
P = LB * FTperMin / 33000/Eff

So, if the efficiency is 75%, then my calc for the 320LB@ 100 ft per min I need to move is this:
320*100/22500 = 1.42 HP needed

If the formula is correct, then I'm using too small of a motor to do what I need to do. Can anyone confirm the formula? I believe it's correct. This would explain why we are having troubles.
 
I think a third party add on would work fine even with 40:1.

Maybe someone can confirm that.

Also while a 'hoist' VFD would be easier they are far and few between and likely charge a premium for them. Since you already have an external working controller I would just look to have a setup that can be commanded to 'hold position'. For a VFD to do that, at zero rpm, you generally need an encoder.

Keith Cress
kcress -
 
Your 100 feet/minute equal around 30 m/min or 0.5 m/s

Your 300 pounds equal around 150 kg, which results in around 1500 newton.

So, your power will be 0.5*1500 = 750 watts or one HP.

Efficiency of gear may be 75 % - that is something you have to find out yourself. Since this probably is a rather low duty cycle operation, the motor should be able to handle the load, at least at the 75 % efficiency.

You must not set the drive's current limit equal to motor rated current, but you shall set motor rated current in the drive's thermal protection. Most drives can deliver about 50 % overcurrent for short periods. So I don't think that is your problem.

One of your problems is that you use the torque mode. Don't. Your controller is asking for speed. Then give it speed. So, you shall change mode from torque control to speed control.

Still, for a hoist application, you need an encoder - or a special drive that can handle the load also at 0.0 Hz.

Gunnar Englund
--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...
 
The drive has to run at a very slow speed to compensate for the slip of the motor. It is difficult to get the exact right speed without an encoder.

The thing about using a VFD set-up for hoist control is that I believe when you give it a start command it will begin to take up the load and then drop the brake out when it's got control. Meaning, it will not drop or raise the load when it drops the brake and if it does it will move the load back to where it was.

Of course, with this small hoist application have you ever considered using a worm gear drive in the hoist? The load would not be able to back-drive the motor making everything much simpler.

 
Kieth,
I checked further into the ABB ACS800 drive with DTC (Direct Torque Control). It's supposed to hold a load at zero speed without an encoder. The price is 3X the price we paid for the ACS350 we currently use. I got a quote of around $1200, as opposed to the less than $300 for the ACS350. man, does this get expensive. I'm not sure if it's possible to put an encoder on the drive shaft as opposed to the motor shaft. I do have open area I could put a hollow shaft encoder there. I just can't see a way to put an encoder on our motor shaft. In making the motor very small, they left no provision for adding a tach\encoder.

Gunnar,
So, it looks like my calculation I got was not correct. Thanks for figuring that out for me. We had tried the drive in both vector torque and vector speed modes. Surprisingly, we could not detect a speed difference when comparing two hoists, one with 40# and the other with 320#. Either way, the drive hoist would drop the load unless we either told the drive not to release till a certain RPM (usually near 200), or I fed the drive a voltage and kept the brake engaged for a few seconds before releasing.


Lionel,
The Brother motor we are currently using has helical gears, so it doesn't have much holding power, though it's efficiency is about 85% straight across all gear ratios. We originally picked it due to size and weight.

Thanks again for all the help that everyone is giving me.
The project has turned out to be much more challenging than initially expected. I keep thinking we should have it figured out, but then there is another setback.

Can anyone recommend:
1) A drive that can hold full torque at zero speed (like the DTC), but costs less than the ACS800?
2) A different 1HP motor that is small, light and has an encoder? The Brother is only 44LBS and 15" high. I think that will be tough to match.

Thanks again,
Tom
 
Gunnar,
I did look at the Optidrive Plus 3gv. It looks like it may work for us. I've got an email into them to find out pricing and availability. I need 66 of these in a hurry, but just one to make sure it will solve the problem.
 
The ACS350 is a good little drive but for a hoist application you really need encoder feed back. I have used a 350 with an encoder and the speed accuracy was great. To get over dropping the load you need to do what the ACS800 crane drvice does internally and that is it records the load torque when a stop command is received. It then uses this as a torque reference for the next start, and does not lift the brake until the torque is applied.

For your system you can configure the drive analog output for tourque and momnitor that in your controller. Your controller's output is then a torque reference to the drive. The drive has to be in torque control, which means you have chnage the application macro (9902) to Torque control and that the external reference 2 is selected (DI3 ON), and your analog reference signal is connected to the drive analog input 2 (normally 4-20mA, you have to change the dip switch for 0-10V). Your controller will then have to control the hoist speed by adjusting the torque reference, which should be reasy as you are already monitoring the speed using your encoder. The ACS350 does not have to have an encoder on the motor shaft you can use one on the final output of the gear box, you just have to tell it how many pulses there are in a revolution.

If you controller supports communications like CANopen, DeviceNet, or Profi you could do alot more monitoring and control, such as changing between torque and speed control for start up and hoisting.

Hope this helps
 
niallnz,
Thanks for that info. We do have the encoder input module for the ACS350 drive. Unfortunately, the Brother gearmotor has no place to add the encoder. Our drum encoder for positioning is only 60PPR. I'm not sure the drive will be able to do much with that limited information. The motor to drum ratio is 40:1, so each motor revolution will only show a little over one pulse.

I figure I might be able to stay with the 350 drive with an encoder input module. I'd just need to find a replacement motor. That's too bad. The Brother gearmotor is small, light and the brake is very quiet. I hope someone else makes one that is comparable. If you have suggestions of one, let me know. I'm having a hard time tracking one down.
 
Gunnar,
I ordered an Invertek Optidrive Plus 3gv today. I should see it tomorrow and be able to check it in our application hopefully on Thursday. This would easily be the least painful modification to the existing hoists, "if" it works. I'm still actively looking at other options in case their claim of "full torque down to 0HZ is just marketing. I don't need it to hold there long without a brake. I just need enough torque to ramp smoother at slow speeds.
 
Are you in the UK? They have their best guys there.

Gunnar Englund
--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...
 
I wish I were in the UK. Unfortunately, I'm strapped to my office chair in Chicago. I spoke with a couple different guys at Bardac today. One said it probably wouldn't cure the problems and the other said it would. Since time is short, I'm giving it a shot. Before the end of the week I'll know if its a dead-end or not.
 
And no local expertise? That might be a problem. Sorry that I do not have the manual available. But I have seen two demo hoists with that inverter with full load dangling free - no brake, no encoder. One in Sweden and one in Germany. But that isn't Chicago...

RTFM carefully!

Gunnar Englund
--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...
 
How about replacing the encoder on the drum with a high pulse count encoder that also has a z channel (once per rev), and using the z pulse for your control system and the A & B channels for the drive.

Just about every post I have seen on this forum has said that all VFD's have great difficulty controlling high torque loads at motor frequencies of less than 5Hz without encoder feedback. Optidrive appear to have that problem sorted, bit of a pain that the RFI filter and the harmonic Line chokes are separate items, makes the drive look cheeper than competitors that include these itmes as standard.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor