## Controlling Position of Stepper for Roll Winding

27 posts / 0 new
Author
Message

I'm working on a solution for a paper roll winding application.  As the roll turns, which is powered by a stepper motor, the paper is pulled onto the roll.  As the roll is turning, the diameter is constantly changing.

The current setup is a stepper motor driving the roll, and a rotary encoder that rides directly on the roll, pivoting out as the roll diameter increases.  I've previously tried using a PID control (specifically PI) and the output is not very stable, especially at higher speeds.  The minimum linear velocity of the system is 5 in/min, with a maximum velocity of 100 in/min.

I've been working on an idea where the rotary encoder could be used to measure the current diameter of the roll, and then that data could be used to predict the future diameter (linearly extrapolated) based on the current line speed setpoint.  I've equated that a change of 1 pulse/min from the encoder signifies .006" of accumulated roll diameter by using simple gear train calculations.  The pulses could be measured at 5 sec intervals in order to collect enough data to "filter" any noise (errant pulse) that had been picked up.  With a previous pulse/5 sec event along with the current pulse/5 sec event, a predicted pulse/5sec event could be generated, and then used to calculate the predicated roll diameter.  This predicated roll diameter would then be used to find the required RPM of the roll based on a line speed setpoint in inches/minute (user defined).  This required RPM could then be used to calculate the number of steps/min required of the stepper motor.  From there, the required steps/min would be compared to the current steps/min that has been tracked in the program, and the step delay adjusted accordingly to meet the next steps/min.

I've attached a spreadsheet which shows the calculations that I've worked up.  I'm thinking this control scenario would work, but would appreciate input to the contrary, as well as other ways of tackling this problem.

Thanks,

Ben

## Attachment(s):

Last Edited: Sun. Feb 7, 2016 - 12:27 PM

I can't see why you need a feedback system. You can determine the diameter from the number of turns the roll has made and then determine the number of turns from the number of steps. For a given step rate, what will change is the linear speed of the paper. So for constant linear speed, you'll need to compute your step rate.

The length of paper is related to the number of turns.
For a failsafe, i'd have a spring loaded lever and a potentiometer that rides on the paper roll to give a rough approximation of the diameter and a microswitch to kill power to the motor if the roll exceeds a maximum size. Add a solenoid to activate the lever so you can test the operation of the microswitch and the potentiometer. Thus the machine can verify the failsafe operation. Putting a simple encoder to give a couple of pulses per revolution will allow you to detect a motor stall. Add a bit of code and a led or display, you can detect most critical failures and report them.

Kartman wrote:
I can't see why you need a feedback system. You can determine the diameter from the number of turns the roll has made ...

I agree in principle, but for that to work you also need to know the weight of the paper if it is a variable. 120gm paper is thicker than 80gm. I had a job 20 years ago where I had to determine the optimum selection of packing cartons for wire-bound books of varying page thicknesses, external dimensions and quantities to minimise the cost to the bookbinder business of the packaging. An interesting problem. So the steps to diameter relationship will also be a function of the paper thickness (defined as a weight in the industry).

Ross McKenzie ValuSoft Melbourne Australia

zipfactor wrote:
I've previously tried using a PID control (specifically PI) and the output is not very stable, especially at higher speeds.  The minimum linear velocity of the system is 5 in/min, with a maximum velocity of 100 in/min.

So what exactly are you trying to control ?

Do you want a nominally constant paper linear velocity ?

If you have a rotary encoder, you know the paper linear velocity, and if the Stepper is not missing counts, you can set the spool angular speed by the step rate.

As the control is essentially unidirectional, you may be able to do something as simple as

a) Ramp the step rate to start paper run

b) when Paper speed is > Limit, increment the Stepper Timer Delay (ie click down the stepper speed)

This gives envelope control, with the stepper bumping down in speed, and the paper speed has a sawtooth ripple.

I should have been more clear initially. I am trying to keep the linear velocity constant as the paper is being coated with a knife coater.

When you say saw tooth ripple, do you mean the motor speeding up / down on constantly in order to match the constantly changing velocity measured by the encoder? This sounds like an option, Although the open loop method mentioned above would have a more linear speed profile, without the motor "hunting" for speed

Last Edited: Sun. Feb 7, 2016 - 02:13 AM

I had previously tried controlling the speed by increasing / decreasing the stepper motor delay based on the velocity feedback from the encoder. Perhaps this would work better if I adjusted the step rate (I.e. Steps/sec) instead of directly adjusting step delay?

If you use a DDS technique of controlling the stepper motor step rate, you'll have much smoother speed control. This should allow the PID to work better.

What is the DDS technique?

Have something like a 32 bit variable. This is called the phase accumulator. Add a variable number at a constant rate. Whenever bit 31 changes, issue a step.

You should be able to compute the diameter,the weight of the paper(thickness) and length by using an encoder to measure the paper speed and control the motor speed to achieve constant paper speed.

You'll need to have your control loop use fixed or floating point calculations, otherwise integer roundup will cause errors to increase.

zipfactor wrote:
When you say saw tooth ripple, do you mean the motor speeding up / down on constantly in order to match the constantly changing velocity measured by the encoder?

Close, the motor never speeds up tho. That only decreases in speed.

The Encoder / paper speed increases due to more-paper, then the Stepper-Spacing is incremented when that gets too fast.

Paper speed slows a little, then builds again with thickness.

Size of the sawtooth, is set by the time-step, but the idea above of DDS is good, as that dithers the step, with more granular choice.

You rely on the inertia to average things out.

What Step-rate-range are you using now ?

Well, I'll throw out an alternative idea.

How about adding a paper tensioner roller, and measuring the tension / pressure etc to maintain a roughly constant paper tension?

Rough drawing is attached.

There are three little rollers, the outer two are fixed.

The middle one "floats", (with fixed endpoints, obviously).

It is a roller with either a spring pressing it downwards from above, or a spring or weight pulling it down from below.

The faster the pickup roller is spinning the higher the tension in the paper and in the floating roller.

Tension is above the setpoint (or window), slow the roller down a little bit.

Too much "slack", and too little tension, then speed up the pickup roller a little bit.

I guess one could also measure the absolute position of the floating roller, (i.e. its displacement from a setpoint), instead of the tension on the roller, but the overriding concept is the same.

This approach eliminates the radius of the pickup roller as an important variable.

The rpm of the pickup roller will change as the diameter changes, but the variable being tracked is the tension (or displacement) of the floating roller.

Measuring the position of the floating roller could be done a number of ways, a linear pot, a string (wire or chain, really) and a pulley and a rotary pot or encoder, a gear toothed rod against a rotary encoder  or pot, ultrasound position measurement, or even one of those expensive lidar ranging modules, (My ability to increase the complexity of a project is never ending...), a string of hall sensors, or other approaches.

If you are lucky there is already a tensioner roller within the system, and all you would have to do is instrument it for a trial.

JC

Edit: I think general engineering principles are often discussed in the General Electronics Sub-Forum, and perhaps you might get more suggestions if this Thread were moved there.

JC

Moved.

Last Edited: Sun. Feb 7, 2016 - 12:28 PM

With this technique random noise in the form of a step is being generated then in order to make the system appear to have more step resolution than it has?

Right now I calculate the velocity by accumulating pulses, and then having a velocity calculating function fire at 50ms intervals. The RPM is calculated by the pulse frequency (x pulses / 50ms) x 60000ms/1 min divided by 600 pulses per rev (encoder resolution). From the RPM I can calculate linear velocity by RPM x Encoder wheel radius x 2pi.

I'm trying to avoid using paper thickness in the calculations as there is the potential for this to change in the future.

Last Edited: Sun. Feb 7, 2016 - 01:16 PM

The range for the step rate is from 3 steps / sec to 20 steps / sec

Thanks for moving the thread JC.  My intention initially was that this was code-related, but with the great suggestions from everyone it has turned into a engineering discussion.

I like the idea of the tensioner roller.  I'm going to try and make the setup I have currently work, but if it seems that I can't, I would certainly consider the floating roller idea.  I believe that this is the way that is commonly used in commercial rewinders / slitting machines (web handling), and that they call that roll the "dancer" roll.

The current setup is a stepper motor driving the roll, and a rotary encoder that rides directly on the roll, pivoting out as the roll diameter increases.

It will be minimal, but the pivoting action will add a phase error to the encoder output, dependent upon the roll radius, the pivot radius, and the stock thickness.  I suspect you can ignore it.  If you can't then switch to a linear carriage for the encoder instead of a pivoting carriage, or incorporate the phase error into your calculations.

I've previously tried using a PID control (specifically PI) and the output is not very stable, especially at higher speeds.

This suggests that you need to tune the PI parameters.  Perhaps explore a PD or full PID algorithm.

The minimum linear velocity of the system is 5 in/min, with a maximum velocity of 100 in/min.

How does that translate to encoder pps?  i.e. what is the transfer function from linear velocity in in/min to encoder pulses in pulses/second?

 "Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience.  Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast.  Cheap.  Good.  Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl]

joeymorin wrote:

The current setup is a stepper motor driving the roll, and a rotary encoder that rides directly on the roll, pivoting out as the roll diameter increases.

It will be minimal, but the pivoting action will add a phase error to the encoder output, dependent upon the roll radius, the pivot radius, and the stock thickness.  I suspect you can ignore it.  If you can't then switch to a linear carriage for the encoder instead of a pivoting carriage, or incorporate the phase error into your calculations.

I've previously tried using a PID control (specifically PI) and the output is not very stable, especially at higher speeds.

This suggests that you need to tune the PI parameters.  Perhaps explore a PD or full PID algorithm.

The minimum linear velocity of the system is 5 in/min, with a maximum velocity of 100 in/min.

How does that translate to encoder pps?  i.e. what is the transfer function from linear velocity in in/min to encoder pulses in pulses/second?

I will probably ignore the phase error to begin with, and if the system has issues controlling, consider adding that correction in.  Great point, though.

I had previously tuned the system using an open-loop step response method and obtained the transfer function.  Because of the lag from the actuator range (which at the time was direct control of the step delay in microseconds, versus controlling the number of steps which I believe will have a better response), the loop was instable at the setpoint.  The system is an integrating type of response, so utilizing a PD control is not typical even in the case of motion control.  Including the "D" term had little affect as well.

5 inches per minute gives 1 pulse every 210 milliseconds.  The calculations come out to 0.271 pulses/1 step.  Perhaps another part of the problem is that the encoder wheel needs to shrink in order to provide more pulses (resolution) per step of the motor?

5 inches per minute gives 1 pulse every 210 milliseconds.  The calculations come out to 0.271 pulses/1 step.  Perhaps another part of the problem is that the encoder wheel needs to shrink in order to provide more pulses (resolution) per step of the motor?

That would seem more likely than:

Because of the lag from the actuator range (which at the time was direct control of the step delay in microseconds, versus controlling the number of steps which I believe will have a better response), the loop was instable at the setpoint.

Particularly since:

Right now I calculate the velocity by accumulating pulses, and then having a velocity calculating function fire at 50ms intervals

If your control loop (PI/PD/PID or otherwise) sample period is 50 ms, you will have a lag (and therefore oscillation) if encoder pulse interval is 10-200 ms.  Either decrease the sample period and/or increase the pulse rate from the encoder (such as through gearing).

You haven't stated your requirements w.r.t. error (oscillation) magnitude and frequency.  What is acceptable?  What were you getting with your PI implementation?

 "Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience.  Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast.  Cheap.  Good.  Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl]

Thanks for the feedback joeymorin.

I did in fact try the sampling period of 210ms prior, and for reasons unknown to me, the 50ms period seemed to control better.

For the application, I honestly don't know what would be an acceptable error in magnitude / frequency.  I really won't have an idea on the effects of the speed variation until the first run of coating the paper is complete, and the thickness varation of the paper/coating is measured.  Industry standard seems to be +/- 1%, which in this case would give a range of 4.95 in/min to 5.05 in/min.  I'm unsure of whether this range is an average over a period of 1 seconds, 30 seconds, 1 minute, etc.  For this application, I would say a +/- 1% over a 5 second period would be sufficient.

With the PI implementation, the variation was between 4 in/min to 6.5 in/min within a 5 second window.

zipfactor wrote:
The range for the step rate is from 3 steps / sec to 20 steps / sec

..

5 inches per minute gives 1 pulse every 210 milliseconds.  The calculations come out to 0.271 pulses/1 step.  Perhaps another part of the problem is that the encoder wheel needs to shrink in order to provide more pulses (resolution) per step of the motor?

That's quite low step rates, so you might not need DDS

Taking a nice round 20MHz CLK for calculations that /1M../6.67M

Prescale with /128, and you have  52083..7812 counts for those Step Speeds, at 7812 a +1 is .0128% change

The Encoder pulse rate is also low, but you can measure period here.

One detail to watch, is does the encoder have precise step spacings ?

Phase wobble in each step, is going to impact your system, and any slip on the wheel, is also going to be serious.

Scale the Wheel capture prescaler, so that also is in the upper 16b range, and then you can compare that 16b set value, and increment the Step Spacing Value.

How fast does this need to slew ? (ie what is the time needed to slow from  20 to 3 s/s)

At 3.690 Steps per Encoder click, you do have some lost precision there & I'd try to get more encoder clicks per Motor Step.

If it has precise phase, target at least one step per slowest motor, gives over 6 ticks at the faster end.

If phase is wobbly, get a better encoder, or more steps.

zipfactor wrote:

I like the idea of the tensioner roller.  I'm going to try and make the setup I have currently work, but if it seems that I can't, I would certainly consider the floating roller idea.  I believe that this is the way that is commonly used in commercial rewinders / slitting machines (web handling), and that they call that roll the "dancer" roll.

This also acts as a shock absorber, so has benefits other than control.

zipfactor wrote:

The minimum linear velocity of the system is 5 in/min, with a maximum velocity of 100 in/min.

That's 20:1, but your step range is only given as 6 2/3 :1 ?

In this use, with these step speeds, I would avoid a fixed algorithm rate and update every motor step, the motor cannot respond any faster than the next-step load anyway, so faster updates actually mean less control, but you do want to update as fast as the motor can respond (ie once per step) - A time-variable (Motor Step based) sample, means you always follow the fastest possible envelope.

You want at least one (good quality) Encoder Step per motor step, and the control is then very simple.

Last Edited: Sun. Feb 7, 2016 - 08:47 PM

I've looked at the output of the encoder on the is oscope and the spacings between pulses looked even, so by that i would say that the spacings are fairly precise.

The steps are in fact greater than 20 steps / sec. At 100 in/min at the smallest diameter, the step rate is ~35 steps/sec.

I like the idea of the variable sampling time based on the linear speed set point, as this will solve the low pulse rate issue without modification of the existing hardware setup...software pills for hardware ills.

I'm unsure of whether the PID will help the control scheme more or cause more problems. Is there any sort of rule of thumb on PID versus the "manual" method so to speak?

If linear speed is of paramount importance, why use a roll-driven approach to begin with?  Why not take a page from the audio industry and use a capstan and pinch roller?  That is the simplest way to achieve a constant linear velocity.  Constant capstan speed equals constant linear stock speed.  Motor control then becomes dead easy.  No need even for an encoder, since the radius of the capstan is known.  Just set the step interval of the motor based on a simple linear equation and you're done.  The take-up roll is then driven with a motor on a slip-clutch to maintain enough tension on the stock for a clean roll, but with the capstan drive strength and pinch roller pressure high enough not to slip under the worst-case tension.

EDIT: typo

 "Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience.  Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast.  Cheap.  Good.  Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl]

Last Edited: Mon. Feb 8, 2016 - 04:28 AM

zipfactor wrote:
I've looked at the output of the encoder on the is oscope and the spacings between pulses looked even, so by that i would say that the spacings are fairly precise.

because that's quite important, I'd code some test Software that captures every step, and run some fixed speed, flywheel type tests that report the Period over the serial port.

zipfactor wrote:

The steps are in fact greater than 20 steps / sec. At 100 in/min at the smallest diameter, the step rate is ~35 steps/sec.

OK, good, so you have sometimes 1 period, sometimes 2, to extract Speed from.

You do need to count/capture  both Time and encoder cycles, then  Cycles/Time for Frequency or Time/Cycles for Period.

Cycles will vary with roll fill.

zipfactor wrote:

I like the idea of the variable sampling time based on the linear speed set point, as this will solve the low pulse rate issue without modification of the existing hardware setup...software pills for hardware ills. I'm unsure of whether the PID will help the control scheme more or cause more problems. Is there any sort of rule of thumb on PID versus the "manual" method so to speak?

PID makes more sense when it is linear control, with a Stepper motor, you know the motor speed, as the stepper has stiffness.

So you need to adjust the Stepper to track, and you know that is always going to be down in speed, (once you have ramped to start speed)

With a Stepper you can define speed to .0128% granularity (even non DDS)

Still no reply to how long the total transfer takes ?

That's interesting that you've mentioned this as the pinch roller solution was already tried. The issue with the pinch roller is that it influences the tracking of the paper significantly, causing roll shift. The paper width itself is 8". There isn't active web guiding on the equipment, and the pinch roller could never be adjusted quite right.

How would the capstan speed be measured without an encoder? Wouldn't the system be running open-loop?

Last Edited: Mon. Feb 8, 2016 - 11:45 AM

For the timing I am currently using a microsecond-timed function "gate", which utilizes a counter. My thought was that the pulses are in the multiple millisecond range at their fastest (I.e. 100 in/min at the smallest roll diameter). Would this be sufficient for timing?

A non-DDS solution would be preferred fir simplicity.

The timing requirement to go from 35 s/s to 3 s/s is 5 seconds. Really the machine will be started at the set linear speed, and varied at most by +/- 2 in/min. So the ramp time from high speed to low isn't critical. The total time to coat a roll is estimated at 8 hrs at 5 in/min

How would the capstan speed be measured without an encoder? Wouldn't the system be running open-loop?

The capstan is driven by a stepper motor.  If you know the step frequency of your drive motor (and you do), then you know the rpm of the motor, and of the capstan, and therefore the linear velocity of the stock.  There is no need for a plant sensor, and no control loop to open.

Shame you couldn't get the stock to track properly with a capstan/pinch-roller.  It would seem that would be trivial with the use of guides and fences along the approach to the take-up roll.

 "Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience.  Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast.  Cheap.  Good.  Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl]

zipfactor wrote:

For the timing I am currently using a microsecond-timed function "gate", which utilizes a counter. My thought was that the pulses are in the multiple millisecond range at their fastest (I.e. 100 in/min at the smallest roll diameter). Would this be sufficient for timing?

It should be. One general rule for keeping things simple, is to use prescalers to move expected values to within 16 bit (0..65535)

You could use 24b or 32b, if you had a wider dynamic range.

zipfactor wrote:
The total time to coat a roll is estimated at 8 hrs at 5 in/min

Ok, that number is used to sanity check the control increment size on the delay

Taking the 'prescaled to INT16U' numbers from above

'The range for the step rate is from 3 steps / sec to 20 steps / sec'

=> Prescale with /128, and you have  52083..7812 counts

If you INC by one (or 0) on the control, the fastest slew rate is around 74 minutes

At  3 steps / sec end, each INC is .002%, which could have slew issues, and is very small.

Perhaps smarter would be to have the control increment a roughly fixed percentage INC in time (drop in speed). eg

~0.1% is Delay = Delay + (Delay >> 10)

~0.05% is Delay = Delay + (Delay >> 11)   Slew time across range here is ~ 22 mins

~0.025% is Delay = Delay + (Delay >> 12)

~0.0125% is Delay = Delay + (Delay >> 13 )

Put another way, with a fastest slew of 20 mins and a working time of 8 hours, about one in every 24 possible INC slots, are used, and you have a control step size of .05%, well under your 1% spec.

The deceleration mode pseudo code, is then this very simple envelope tracking, run once per Motor Step

IF  SensorPeriod < SetPeriod THEN

StepDelay = StepDelay + (StepDelay >> 11)  // Too fast ? -> Drop speed by ~.05%, & wait

Last Edited: Mon. Feb 8, 2016 - 07:55 PM

Thanks for the info who-me.  I like the idea of changing the control output to have more "gain" as the selected speed is lower.  I had observed the slew rate issues you mention, specifically on startup when the control would very slowly stabilize the system.  I had attributed this to a poorly tuned loop, when in actuality it was the slew rate.

Unfortunately I won't have the opportunity to implement this until the end of this week.  I'm sure I will have more questions at that point ....

Thanks again everyone for your input.  The level of technical expertise here is what makes this forum!

Kartman wrote:
If you use a DDS technique of controlling the stepper motor step rate, you'll have much smoother speed control. This should allow the PID to work better. What is the DDS technique? Have something like a 32 bit variable. This is called the phase accumulator. Add a variable number at a constant rate. Whenever bit 31 changes, issue a step. You should be able to compute the diameter,the weight of the paper(thickness) and length by using an encoder to measure the paper speed and control the motor speed to achieve constant paper speed. You'll need to have your control loop use fixed or floating point calculations, otherwise integer roundup will cause errors to increase.

After quite a few delays with other projects, I have finally had the chance to get back to this control situation.  I tried this DDS technique that you had mentioned Kartman, with a good degree of success.  I went from a linear speed standard deviation = 0.88 inches/min in a 2 minute interval down to std dev = 0.56 inches/min in a 2 minute interval.

Two questions for you .....

1)  What does DDS stand for?  Are you referring to direct digital synthesis?

2)  Is there a way to further increase this dithering effect caused by DDS?  Perhaps read the 15th bit of a 16-bit variable, or even as far as the 7th bit of an 8-bit variable (inject noise at a greater rate)?

Thanks again for the help, this has been quite the learning experience!

Last Edited: Fri. Feb 26, 2016 - 05:33 PM