Speed Control on Hydraulic Driven Conveyor

[Sliver]

Why Hydraulic? Real World Application in my world

Old DC drive.
New (15 year old) hydraulic drive.

Look here for more info.

There may be VFDs that could handle this application now but doubtful any would have the low speed torgue required.

And we use encoders.

Brian.

 

[Peter Nachtwey]

Nice article

I wonder what DickDV has to say about harmonic oscillations. Couldn't this just be a tuning problem? I really would like to know.

It was a slow weekend. I hope most noticed the wink. I am not anti hydraulic, just the opposite. Most on the forum know I get involved with hydraulics all the time. However, I don't normally think of hydraulics as being the best for continous duty rotorary motion for efficiency reasons. It is good to see some successful continuous roatary hydraulic apps although I wonder if the electric motors failed due to poor installation or design. Good tools can fail if the not used properly.

I can add a few more advantages for hydraulic over electric systems.
1. If a electric motor loses power there had better be mechanical brakes ( cost and weight ) to stop the motor. Otherwise the load will coast and perhaps hit something.
Hydraulic systems only require a valve shuts and there will be a 'hydraulic lock'. I asked about the mechanical brakes a year and a half ago. At that time we were controlling electric drives.
2. Each electric motor must be size for the peak load. On a hydraulic system the power pack ( one for many axes ) must only be sized to supply the average load for a machine cycle and a little more. During dwell times energy can be stored in accumulators for peak load. This allows the hydraulic motor to run at a constant speed. It does take a little calculating to optimize the size of the power pack and accumulators.
3. Electric motors must have current flowing through the armature to apply force even if the load is not moving. This is why electric motors are seldom used in presses. Hydraulic presses use very little power when applying a force when not moving because there is very little flow.

 

[Foreman174]

More information

Sorry it took me so long to get back. Thanks a lot for the input. Here is some more information about this application. This is a food production plant. We run 2 production lines with 4 variable speed belts on each line. Hydraulic pressure is maintained with 4 central low pressure pumps. Speed is currently controled with a manual flow control valve. The sole purpose for not using and encoder and a VFD is the additional cost of the encoder, processors, and the hassle of running I/O wiring. Dwell time is defined as the amount of time that the product spends on the belt. The range of these dwell times are between 30 seconds and 700 seconds. The timer in my program times 4 pulses - a pulse is defined as a full prox cycle, high to low and back to high. The main problem that I am having is at the low end of the range at dwell times of greater than 400 to 500 seconds. It is taking to long for for the speeds to update. I had thought about using more teeth but when I do this I have troubles with my accuracy at high speeds, 30-60 second dwell times. Thank You everybody for your input.

 

[rsdoran]

I have to see if I understand the application. The operator manually adjusts the flow control to set the dwell time which I assume is shown in seconds on an HMI. The problem is that the slow update when running slow makes the operators over-compensate? or vice versa when you add more teeth.

I think I would use the prox to increase a counter and take the value of the counter over time, move this count into a shift register for 10 values...ie if updating every 100ms then average those value every 100ms. This is just an idea and you will have to determine how to convert the values to conform to your dwell time.

I re-read the original post and now I see you are timing every 4 revoltutions, time every revolution and do something like I mentioned above and create an average routine, this will allow a much faster update. Even if you just time every revolution instead of every 4 you will have faster updates, if there is a fear of missed counts add another prox and double count. I am not sure I would probably just take high counts and not worry about full transitions.

 

[elevmike]

Forman174,

You might need to use an encoder for this application. The best option would be to use an encoder to feedback to a small PLC & have the PLC control a proportional valve that would regulate the speed. That way you can dial in your target speed via a small HMI and let the PLC, Valve, and encoder do the rest. I don’t know about the valve but the PLC & encoder might cost about $400.00. You could just use one PLC to control all four of your conveyers.

Barring all that. If you want a more accurate reading at low speeds then you need to count multiple counts in ONE revolution. This might be just a matter of replacing the prox with an encoder. You didn’t provide enough detail, so it would be a guess at what type of encoder or how many PPR etc... If you want an update once every second then you should try to pick an encoder that would provide at least 10 pulses per second for the lowest expected shaft RPM.

So answer these questions:

What's the slowest expected RPM?
What's the highest expected RPM?
What's the desired update rate?
What are you currently using for a speed indicator?

Option No. 3: Get a tachometer. Mount the indicator in a convenient location for the operator with a cable running back to the shaft.

 

[elevmike]

"The timer in my program times 4 pulses - a pulse is defined as a full prox cycle, high to low and back to high."

Ok so it just dawned on me that you have a PLC?? What make & model? Adding an encoder might not be a big deal as the plc might have a couter input.

 

[Rich1955]

Hey Mike, Could he use the leanth of the pulse to determan speed, lets say if the pulse = 2 sec speed is 10 RPM. Then he could update every pulse.

 

[elevmike]

Rich, that's true also. Good point! That could work so long as the high end speed dosnt result in pulses shorter then what the timer can produce.

We'll know for sure if or when Forman posts the specifics.