Measuring problem

[milldrone]

I'm having some difficulty with some equipment that has two ACS600 drives. Sorry if this is a little wordy. The drives may not be the problem, but the symptoms lead one to think that they might be part of the problem.

The drives (2) are in DTC mode and they power two conveyors, one feeding to another with a gap in between. The gap is about 28" and there are four cameras (top, bottom and each side) viewing the product (lumber) in the gap as it passes from one conveyor to the other. There is only one encoder it is currently driven by a synchronous timing belt from the drive shaft of one conveyor. There are no gear boxes. Each conveyor has identical timing belt drives with a jackshaft for reduction. The conveyor belt itself is a synchronous timing belt with a special high friction surface that contacts the lumber. This conveyor belt runs on timing belt pulleys for head and tail drums. The timing belts are in good condition (no missing teeth). The timing pulleys are in good condition (no missing teeth). All shaft connections look good. It appears there is no slippage between the motor shafts and the conveyor belts as it is 100% timing belt drive. There are elastomeric tensioned hold down wheels to pinch the lumber between the wheels and the conveyor belt.

The motors are identical (Baldor super E gold 3 hp@ 1750). Typical production speed is 1250 rpm at the motor. The ACS600's get their speed reference from a 0-10v analog signal from a AD DL240. The drives share the same analog voltage reference. In production the speed reference never changes while lumber is present (except for catastrophe). Any lumber that is scanned when the speed is changing is set aside and rerun. The motors have been tuned to the ACS600 drives by disconnecting the belts and letting the the drives do their “magic” for tuning DTC. Percent of torque readings from the drives digital displays are 13% and 18% respectively. Hand held tachometer/ speedometer readings are steady on one conveyor at 398 ft per min. the other conveyor reads 398 for 98% of the time then gives a 397.5 flicker. The readings are while the the conveyors are running but no lumber is present. While lumber is running the digital displays of “P speed” change by one digit ie. 398 to 397.

Now for the problem. Length measurements are inconsistent from the encoder with reality. If we scan the same board twice we get the same reading both times. If we find boards of exact length (+- .030”) we get results that are 1.25” to 2” different.

What I have done is installed a second encoder ( with a DL06) to test against the original. Then I was able to run both encoders at the same time. The results were the same (whithin tollerance) as far as the original encoder reading vs my temporary encoder ie. 242.8” vs 242.7” and the board measured 240.2. The next board was the same actual length 240.2” and the encoder readings original= 240.4” temp= 240.3”. By the way the second encoder is totally separate and so is the measuring photo eye. This testing has confirmed (to me) that the boards are slipping on the conveyor surface. In another test I measured the boards with a measuring wheel on my test encoder there by bypassing the conveyor to board slippage issue. When measuring the lumber directly with the wheel the measurements agree test encoder to reality.

Now for the second part of my problem. The vision system needs to be recording encoder pulses while the lumber is in the gap with out anything obstructing their view. This is why the Oem tied the encoder to the conveyor driveshaft with a timing belt. The Oem controller will not accept two encoders at once. I'm confident I will never be able to eliminate the mechanical slippage between the conveyor belts and the lumber.The mechanical arrangement does not lend itself to one drive. If more details are required I will be glad to respond, this post is already a little long. Has anyone switched between two encoders to one controller?

 

[Lancie1]

There are elastomeric tensioned hold down wheels to pinch the lumber between the wheels and the conveyor belt.

When measuring the lumber directly with the wheel the measurements agree test encoder to reality.

Therefore, what makes the lumber slip? HAs it ever worked correctly in the past? If so, then possibly your hold-down wheels are worn, not round, have too much tension, or have bad bearings, and actually CAUSE the slip instead of preventing it.

Test this by removing the hold-down wheels, or releasing the tension, so that boards are only held by gravity. If an improvement is seen, there's your answer.

At the only lumber mill that I have experience with, the boards did not have ANY hold-down wheels.

 

[milldrone]

Lancie,

Thanks for the bump. I know you make a point of answering unanswered posts.

The hold down wheels are in excellent shape. This question has been addressed by myself and other concerned parties. There have been several suggestions for tests and wheel adjustments. Yours was the first to suggest no wheels! I did try your suggestion, the results were very very bad.

I'm attempting to post a pic of the conveyors as my description leaves a lot to be desired

Each conveyor is approximatly 40 inches long but the lumber is up to 20 feet. These conveyors are feed by a "latteral feeder". If you have been in a Planer mill, think pineapple feedtable. A "latteral feeder" is much the same but does not butt the boards end to end. The "latteral feeder" singulates the boards on demand.

The hold down rolls are nessisary to pull the boards from the "latteral feeder". If the "latteral feeder" were to feed the boards through the scanner with it's feed rolls then that would be another motor to have to syncronize speed with.

If there are any more questions I will glad to reply

 

[rdrast]

Hrm. This is actually not an atypical problem.

Vaughn, if you can, sometime... Please use your hand tach, and measure the conveyor surface speed across the flat, and again at both the idler roller and the drive roller. From your drawing, I'd actually like to see two measurements of the belt speed going over the roller's, one at 45 degrees from the flat portion, and one at 90 degrees (where the belt is going vertical). Use whatever range gives the best accuracy on your tach, either FPM or IPM (or cm/min) if available.

One other thought before you get that information... In your application, it's a bit more difficult, to do a direct length reading, but not much. I'd strongly consider using a seperate encoder and wheel, spring loaded so that the passing board will be forced to make contact with it. A photo-eye just at the contact point would be used to sense the presence of a board. Use the photo-eye to 'gate' the counter (allow it to count), so the counter only accumulates pulses when a board is present. That would allow the wheel to free-spin when it's winding down, without accumulating counts. There are many ways to do this with a PLC, I generally let all of my counter modules in a PLC just plain 'free run', and take a difference every scan between the 'Current_Counter_Value' and the 'Last_Scan_Counter_Value'. Then I add that difference (which, in this case, would be only added if the photo-eye detects a board) to my real 'Count_Accumulator_Value' in the PLC.

 

[milldrone]

Hrm. This is actually not an atypical problem.

Vaughn, if you can, sometime... Please use your hand tach, and measure the conveyor surface speed across the flat, and again at both the idler roller and the drive roller. From your drawing, I'd actually like to see two measurements of the belt speed going over the roller's, one at 45 degrees from the flat portion, and one at 90 degrees (where the belt is going vertical).

rdrast,

Lucky Me, I already have this info! The speed on the flat surface of the conveyor belt is 398 ft per min. If im understanding you correctly , you want the surface speed as the belt curves arround the pulley. That speed is 422 ft per min.This was quite a head scratcher for me for awhile. Then I figured it out. The cord or tensile member of the belt is far from the surface that carries the lumber and near the timing belt teeth. So the pitch length is near the timing belt teeth and why most timing belts are so thin between the gullet and the outside of the belt. My conveyor timing belt has an additional crepe rubber surface for gripping the lumber that stretches while curving arround the pulley.

I'd strongly consider using a seperate encoder and wheel, spring loaded so that the passing board will be forced to make contact with it.

Almost exactly what I was thinking. My sticking point is I need to be generating encoder pulses for the vision system (where I cannot have anything in view of the cameras). Or to put it another way. I need to generate encoder pulses that accurately define the board position but I need to do this for another 4 feet of conveyor travel. The only solution I can figure is to have two encoders with measuring wheels contacting the lumber and switch between the two encoders electricly as there is only one encoder controler. There are lots of encoder broadcasters and encoder isolators. But I can't find a two encoder to one input solution.

If there are any more questions I will be happy to respond.

 

[rdrast]

/nod. I thought so on the first part, but without any slip (as you say you have none), I can't account for your measurement differences between two readings of the same length. In industries where we have to deal with a significantly 'dimesional' object, an encoder on a single-belt conveyor can be problematic. When I absolutely must use that for speed/length measurement, I usually have to scale the count by 1/2 the measured objects 'height' above the conveyor. Unfortunately for you, that won't work, as you aren't dealing with a continuous product, but one with gaps, hence, you will be losing accuracy on the measurement just by the nature of having to accelerate each board up to speed.

Even if you have an extremely high grab nip point, you cannot accelerate a single object up to speed instantaneously, so you will randomly be losing pulses, and therefore losing your length measurement.

The vision system adds another twist, which presents several ugly solutions in my head. (ugly, being defined as something that would be a 'one of a kind, solder it together yourself kind of deal).

A non-ugly, but costly (to the tune of several thousand dollars) alternative might be an actual LASER speed measurement device, something like This Device or something similar (sorry about last LADAC link, they don't have info posted, though I like that companies products). I'm not sure about the options available on them, but the predecessor modles used to have a 'simulated encoder output', which precicely tracked the target.
They are both non-contact, and (at least the models I have, which are of an earlier vintage) are excellent for precisely measuring speed and/or length. I used them as my certified speed/length calibration devices.

You should be able to position either (or any number, well, a small number of similar products) so they can measure just before your vision system, with a small enough gap that you can either account for it (fixed speed systems) or calculate and pulse-delay it (variable speed feed systems) before triggerring the camera system.

Both use non-contact LASER technology, that rely on light being reflected from the target, so aren't 'through-beam' type systems.

 

[milldrone]

Thank you!

rdrast,

Thnks for the links I check it out

 

[Peter Nachtwey]

This shouldn't be a problem

As stated above, this is done all the time in sawmills. The difference is that usually there is an encoder on both the upstream and downstream feed chains/conveyors and the encoders go to the controller than keeps the chains synchronized. Synchronizing the two feed chains is easy then but one must make sure the that wood is held firmly by one or the other feed chains at all times. The variance you see is excessive. You should be able to get a video camera and see what is happening. High speed video cameras are getting to be a vital piece of test equipment.

 

[Lancie1]

Synchronizing the two feed chains is easy then but one must make sure the that wood is held firmly by one or the other feed chains at all times.

That may be the difference. I am familar with using chains with synchronized lugs to transport, measure, and cut lumber. Once a board is placed between two lugs on a chain, it stays in a known place, until it arrives at its destination.

I can see where using a belt would introduce a slippage problem. No matter how the hold-wheels are adjusted, there will be slip caused by the inertia of the wheels. This could be minimized by driving the hold-down wheels at the same speed as the belt. Even then, as the board contacts each spring-loaded wheel, there will be a small slippage. To eliminate slippage entirely, the board would have to be moved underneath ALL the hold-down wheels, before the measurement start-point.

As RD pointed out, your current encoder is measuring the belt travel. You really need an encoder on one of those hold-down wheels, measuring the board travel.