PID Loop Issue

[Mike Nash]

I think what I'm going to do is turn the accel times way down on the drives, have the speed setpoint be slowly ramped by the PLC (rather than having the drives just slowly accelerate to speed) so that the PID loop will have much better drive response.

Everything sounds good to me, especially your last paragraph. You probably have a fast enough comms update rate with the GS-EDRV100 cards* that the response to your PID won't lag at only 500 FPM max. I know it doesn't seem like ramps should hurt you at the drive, but they are killers.

* never used them but hopefully they speed up the overall update rate by offloading the serial comms to the card rather than the PLC having to wait.

[Controls Guy]

The winder tension is controlled by the dancer, as it has air cylinders on it that I control the pressure to via transducer on the analog output. As far as drive control, I'm communicating using GS-EDRV100 controllers connected to the PLC via Ethernet.

If the dancer position is already independent of tension, then trying to control the position with PID is pointless, and potentially to your disadvantage.  The I term will wind up and limit response when speed changes while accomplishing nothing you need.  Just take the actual main speed, add trim proportional to dancer position, then correct that sum for accumulated roll diameter.  Feed that signal to the follower drive, whose accel and decel have been shortened.  I'd take just the middle 50% or so of dancer travel and scale that out to the entire amount of trim (+/-17.5% in your implementation), so the trim is maxed out (or minned out) while there's still some available dancer travel.

Also, your dancer should have enough accumulation of web to allow time to match speeds.  Take the difference between the longest web path around the dancer and the shortest and divide by line speed to get differential accumulation in terms of time.  You probably have a decent amount because it generally works now.  And you don't need to reduce the accel and decel rates on the main drive, only on the follower.

[Mike Nash]

I'm just wondering out "loud" what the benefits are vs pitfalls of your PID-less method are Controls Guy.

I usually have to calculate diameter from the line speed and spindle speed, trusting the dancer to stay in position and not influence the calculation due to web path length changes. Of course the dancer position error correction is what forces the diameter calculation to be correct in the first place. Hazard is tail wagging the dog if it starts hunting.

I tend to disagree with the statement "the dancer position is already independent of tension" though. The force the dancer is applying to displace the web is that needed to give the desired web tension while the dancer is in-range and steady-state. Other than geometry differences, any stable position is essentially the same tension. The dancer position does not cause the web tension, rather the web tension is what causes the dancer to be in a particular position (in-range or against the stops).  But most dancer assemblies are anything but mass-less and friction-free so a dancer that is changing velocity is imparting tension variations in the web which can potentially cause undesirable problems with the rolls coming off the winder. This is why it is desirable to have the dancer as close to a stable run position as possible even at zero web speed. Transferring to a new spindle core works best if the dancer does not need to travel much.

I would like to play around with a real system at some point and pit these two concepts against one another. Not likely to happen though since I don't have a winder test stand and customers frown on making scrap.

Maybe Evilbeard would like to?

[BobO]

Don't miss the next episode of Spike TV's Engineering Throwdown! Pretty? No. Graceful? Hardly. Agile? Perhaps. Tune in at 8:00PM for Dancer Wars...only on Spike TV!

[Controls Guy]

Mike Nash, your application experience appears more directly relevant than mine.  As I said, my apps haven't been highly critical for tension, but they did work very well for what they did care about, and it seems to me like the same concept "should" work OK here too.  Like you said, there's no way of telling till you test it, so I wish that were feasible too.  I do try to make dancers as frictionless and low-inertia as possible, so we're in agreement about those issues.

[BobO]

So no throwdown? Sad.

[Mike Nash]

So no throwdown? Sad.

Sorry Mr. O., but there was never even a challenge issued.

Mike Nash, your application experience appears more directly relevant than mine.  As I said, my apps haven't been highly critical for tension, but they did work very well for what they did care about, and it seems to me like the same concept "should" work OK here too.  Like you said, there's no way of telling till you test it, so I wish that were feasible too.  I do try to make dancers as frictionless and low-inertia as possible, so we're in agreement about those issues.

Seems like textiles are one of those tension-less loop processes. I don't see so many of those anymore since most have vamoosed. Rotary die cutters for paper and cut to length feeders for steel use the loops, usually without dancers though.

I'm still wondering what type of applications you deal with mostly. Whatever they are, I'm glad I don't, as the complexity seems rather high based on the questions, suggestions and other statements you have made over the years.

I've always approached things from the standpoint that an OEM knew what they were doing. Since we mostly do retrofits in whatever industry, I don't try to reinvent the wheel. Sometimes though, I finally have to step back and realize someone had no idea what they were doing and I don't know how the customer ran the machine this long. I have had occasion a few times to come back years after a retrofit I was involved with, add a resistor in a strategic spot and be amazed at how things suddenly start working beautifully. It wasn't that hard, I just didn't have the knowledge/experience before to realize what it needed. Sadly, I sometimes still don't.   I recently had a vendor point out something that should have been obvious (no integral) but I had ignored it since I had the files that said it had never had any integral. Wow, what a difference.

I really would like to have a winder test stand, but have never been willing to spend the time to try to build one.

[BobO]

So no throwdown? Sad.

Sorry Mr. O., but there was never even a challenge issued.

Yeah, I know. And even if there had been, engineers are so engineer-ish I doubt we could've even gotten the smallest amount of trash talking going.

I'm just itching for something interesting. Since I released firmware version 2.0.0 of the Do-more control engine (hint, hint) I'm nearly bored. (OK, that's a lie...I'll never run out of things to do!)

[Mike Nash]

Since I released firmware version 2.0.0 of the Do-more control engine (hint, hint) I'm nearly bored. (OK, that's a lie...I'll never run out of things to do!)

Oh man, I just checked under the tree and I don't see it yet. Was I naughty?

Seriously looking forward to it though. Merry Christmas!

[BobO]

Oh man, I just checked under the tree and I don't see it yet. Was I naughty?

Seriously looking forward to it though. Merry Christmas!

Nah...our delivery mechanism just isn't quite as efficient as Santa's.

[Controls Guy]

Seems like textiles are one of those tension-less loop processes. I don't see so many of those anymore since most have vamoosed. Rotary die cutters for paper and cut to length feeders for steel use the loops, usually without dancers though.

I'm still wondering what type of applications you deal with mostly. Whatever they are, I'm glad I don't, as the complexity seems rather high based on the questions, suggestions and other statements you have made over the years.

I do have some off-the-shelf products of my own, but for the last 15 years or so I've been an independent integrator working with both end users and OEMs that want to shop out their controls, so I get into a little of everything, which I enjoy.

My exposure to continuous-product applications was mostly when I worked with metal finishing (typically electroplating) equipment.  The reel-to-reel products would typically be either fine wire up to maybe 2000fpm, flat metal strip up to maybe 12” in width, or bandoliers of stamped electronic contacts, typically 50-200 fpm for the strip and contacts, and vertically oriented in the machine.  I frequently had accumulators for reel change, which were vertical, I think without exception, but the unwind and rewind could be either vertical or horizontal web (horizontal or vertical axis, respectively) with an invert between them and the line, if needed.

I try to go into a new area with an open mind (which is easy cause I have no idea what I'm doing), and thoroughly understand why the industry standard way is done the way it is, building up understanding of the process from first principles.  I think what you're seeing is more the result of my take-nothing-for-granted approach than that my applications have been unusually complex.  Hopefully, that results in the best bang for the buck.

[Evilbeard]

I ended up making two new subroutines for my program, one for acceleration, and one for deceleration. The PLC compares the current speed with the set speed. If the set speed is above or below the current speed, it starts the proper subroutine. It determines the amount that it needs to adjust the speed, divides it into 10 pieces, and then adjusts the current speed every second by that small piece (I called it the delta) until the line is at the set speed.

I had to go back and rework my PID settings, but I got it pretty dialed in. I set the line to 500FPM. The dancer goes above the setpoint, but not quite to its limit (around 90% of travel), and then dips back to around 10% at the bottom. It then slowly curves toward the setpoint.  I've been working on making the turret speedmatch when the front cuts, and it looks like it's doing a great job, but after it cuts, my outboard arbor isn't shutting off properly. I'm still working on that, but I ran out of scrap film to trial. They're working on getting me some more to finish it out, but I'm very close.

[Mike Nash]

Cool!

I'm betting you can tighten the dancer position up a bit, but not banging the stops at 0-500 is a great start.

I'm thinking a little more proportional gain is where I would head first. The integral is having to pull the dancer into position, but since you are actually running behind in taking up the web travel it is having to increase too much to catch up, then decrease to get the speed back down after the slack is gone. A bit more gain could get you up to speed without too much "slack" (even though the dancer is still keeping the web taut you are behind initially.) And get the accel/decel times as short as possible. You should be able to bump your speed setpoint rate up to 5-10 times a second easily.

Also, are you zeroing the PID output at start? If the integral is allowed to build at zero speed, or worse, while the drive isn't running, you could be starting out with an undesirable error trim you have to slowly get rid of (integral).

[Evilbeard]

I'm "zeroing" the output at start by setting it to 50.00%, since I'm going -7.5Hz to 7.5Hz (as a scaled output). The PID loop doesn't actually get switched into Auto until the drive starts, so I'm not accumulating anything while the drive isn't running.

I started at 1.00 Proportional Gain, and bumped it down to 0.50 and it seemed to smooth out. I might trying bumping it little by little to see where I can smooth it out a bit, but like I said, I'm getting close. My Secondary Drive is set to accel/decel time of 0.1s, and my Rewind Drives are set to accel/decal times of 0.5s

[Controls Guy]

My Secondary Drive is set to accel/decel time of 0.1s, and my Rewind Drives are set to accel/decal times of 0.5s

I think you got that backwards -- the master drive wants to change speed smoothly, and the follower (rewind) wants to be able to overtake (quicker).  If you're providing the master axis a ramp from the PLC, it's OK to have a short accel and decel so as not to be redundant, but I can't think of any reason the follower would ever want to be less nimble than the master.  Like cascaded PID loops for example.  The tail has to move faster than the dog.