Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Evilbeard on December 19, 2016, 11:09:22 AM
-
Ok, I'm sure there's something I'm doing wrong here. My project is a machine that folds and winds up film. There is a secondary nip that sets the speed of the machine behind the turret rewind. My PLC sets the nip to a speed and it runs a constant speed. The rewind I calculate a rough speed, and then trim it with a PID loop to keep a dancer at the setpoint. Currently I have the dancer set to 40 (40% of it's position. 0% is slack film, 100% is pulling way too hard). My PID loop is set to a scaled output of -175 to 175 (add or subtract up to 17.5 hz from the calculated output to the drive).
When I start up the machine, it runs great until about 600 ft on the roll (around 6.5" roll diameter. Then the dancer starts to creep around off the setpoint. It will then seem like it finally overcorrects and the dancer slams one way and then the over, and it kicks out the drives. If you start the machine back up, it runs smoothly, as if nothing happened. It does this in the same position ever time. I've checked my calculated roll diameter (I use the mil of the material and calculate size) versus my actual roll diameter, and they're almost spot on. So I know my calculated speed should be close (I know that I have to run a few percent faster than the secondary or you create no tension most of our machines are 10%).
Is there anything I don't have setup properly in my PID loop that would cause this? I currently have the Gain set to 0.25, the Reset to 2.500, and the Rate set to 0.500. My error looks something like this:
(https://forum.hosteng.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2F2JpVVF9.gif&hash=dc96dfd4725ba0b55519516e9e992fe483e12c92)
-
I'm just throwing out some ideas here.
Ten samples per second seems a little slow.
Derivative is... evil unless you get lucky. (I have had to use it a few times with dancers, but center winders are difficult at best since it is a moving target.)
You are in a sweet spot at core, but as you build diameter your trim from the PID gets proportionally greater. I would suggest multiplying PID trim times core diameter divided by current diameter before adding it to your winder speed reference.
-
Then why does it run out after I stop it? Once I start the roll back up, it runs to the footage setpoint with no further issues. It's just at around 700 feet that there is an issue. I've set it at 2500ft on a roll, and it runs to 700, messes up. I hit stop. I hit start, and it will run to 2500 feet with no issue.
-
So you didn't like my ideas? :'(
I'm just guessing here unfortunately. The derivative is touchy so I would want to zero it out before chasing things further. It does look like an integral kind of period, slow swings but getting worse as it goes, with a long lag before responding. Upping the gain could help there, but that is where ratioing the trim with diameter helps - you can get more gain without it getting out of hand as the spindle slows due to diameter build. My gut feel is 700 feet is just a critical speed / resonance type of problem.
Can you force an oscillation to start at other diameters by manually upsetting the dancer position?
And just to throw it out, make sure you have no slop/backlash in the dancer to dancer position input device.
-
I like the idea of dividing the PID output by the current diameter. Not sure what's special about this particular distance on the web, though.
-
So you didn't like my ideas? :'(
I'm just guessing here unfortunately. The derivative is touchy so I would want to zero it out before chasing things further. It does look like an integral kind of period, slow swings but getting worse as it goes, with a long lag before responding. Upping the gain could help there, but that is where ratioing the trim with diameter helps - you can get more gain without it getting out of hand as the spindle slows due to diameter build. My gut feel is 700 feet is just a critical speed / resonance type of problem.
Can you force an oscillation to start at other diameters by manually upsetting the dancer position?
And just to throw it out, make sure you have no slop/backlash in the dancer to dancer position input device.
Not that I didn't like them, just curious as to why the problem is only at around 6.5-7" of diameter, and not continuing through a larger roll. I upped my sample rate to 50ms, and started adjusting things to try to make it run. I had to turn my Rate up to 6.000 sec. I'm still playing with the settings, but I started the line slowly 25fpm (I've been testing at 350fpm, an average speed for us)and I noticed that my speed reference went ballistic. Turns out, I didn't consider limits on the speed reference. The trim was actually making the speed reference go below zero, which causes some issues. I've made logical tests that when it's < 0 to make it 0, and when it's above 60.0 to make it 60.0. That should take care of that issue.
One other thing, I should want to multiply by the current roll diameter and divide by the core diameter, right? I need more trim at the core, and less on a full roll, correct? It takes a much smaller adjustment at full diameter than it does at the core to make the same adjustment, or am I thinking about this backwards?
-
No, divide by the current roll diameter so that the reference gets smaller as the roll gets bigger.
-
It's probably cleanest to:
spindle ref = (line speed + PID trim) * (core dia / act dia)
At core the the multiplier is 1.0, at twice core diameter it is 0.5, etc.
Just be sure to use consistent units. Most drives with winder software routines will use % of full roll for units, so 5" core on 50" max is 10% for example. You should disable the PID trim, set the diameter to core and hold it there, then adjust the drive max speed to produce 100% surface speed at core with 100% line speed at your nip. This gives a repeatable starting point. If you were calculating diameter from line and spindle speeds, it is required. It is not as critical the way you are calculating.
Done this way, your profiled trim is automatically done.
-
No, divide by the current roll diameter so that the reference gets smaller as the roll gets bigger.
Yeah, I realized this after I posted. I hadn't had my coffee before thinking about math. :-X
I hand tached the winder at 60.0 hz on a small core. It was 700 fpm. I worked backwards and calculated rpm from that. I send the speed to the drive in relation to rpm (calculating roll diameter gives me feet per revolution, and I can work from the set speed). I basically scaled the RPM from 0 to 720 to the output 0 to 60hz. My calculated speed (in rpm) goes in, my speed ref comes out. I disabled the PID, and I'm within about 2fpm of the secondary drive.
-
Well, I've got it working on a slow speed. It "works" at 150fpm. Any faster, and the dancer bottoms out and then either kicks out the drive by pulling too hard, or it slacks up and wraps the nip roller.
Is it possible that I want to let the rewind get closer to speed before kicking in the PID loop? I have it on from the start, and it's just a bit sluggish. Increasing the gain causes instability. Once it's stabilized at slow speed, I can take it to production speed (we're running at 400 fpm today), but it won't start with the drives set to ramp to that speed.
https://imgur.com/tra1Gb1
-
Hmm, you do have the winder drives accel and decel times set really low right? (Or rates really high, whichever your drives use.)
Like 0.5 seconds or less. If not, you will probably never get the PID in the PLC to control tightly because you won't be able to get a reasonable gain set due to overshoot.
I prefer to try to get as close to zero ramp time as the drive will allow and add a little analog input filtering if using analog and it has it.
-
Hmm, you do have the winder drives accel and decel times set really low right? (Or rates really high, whichever your drives use.)
Like 0.5 seconds or less. If not, you will probably never get the PID in the PLC to control tightly because you won't be able to get a reasonable gain set due to overshoot.
I prefer to try to get as close to zero ramp time as the drive will allow and add a little analog input filtering if using analog and it has it.
I think they're currently set to 5 seconds on the rewind and 10 seconds on the secondary. The issue is that the motor for the secondary nip is a 120Hz, 3600 RPM motor, the motors on the rewind are 60hz, 1800RPM motors. I tried to match them up as best I could so they would both have the same approximate ramp time to the setpoint (it's actually a little different due to mechanical setup, the rewind has a huge pulley to reduce speed).
I might play with making the PLC control the ramp of the drives and setting their accel and decal times to 0.5s. I'll just have the operator put in the setpoint they want, and have the PLC slowly speed the drives to the setpoint.
-
That 5 second ramp is definitely a problem. That can only work typically with no integral and just let the dancer be happy wherever things settle out.
Are you using analog references or communications to the drives? If comms, what kind?
-
Agreed. You don't need to make any effort to ramp them at the same rate, because there's a system in place to make the winder follow the line. And...if it needs to make a correction, it needs to be able to do so quick. You might want to oversize the drive so you have plenty of current available.
I've also fed the dancer position directly to the following motor, so not trying to control dancer position per se, just synching the speeds of the two drives. In essence, you end up with a P-only controller (In your case, you'd still need to divide by roll diameter, my follower axes were nips so I didn't need to worry about that) Now when I did this, I wasn't really trying to control tension, just synch the follower to the master; there really was no tension per se, just enough to take up slack and make sure the web didn't unthread itself.
Now you're going to want to control wind tension, so if you do the P-only thing, you'll need to decouple tension from dancer position, if it's not that way already. Sounds like it isn't. You could put weights on the dancer, or even better would be to apply the tension with a cylinder fed by a relieving high-flow precision regulator, because then you avoid the inertia associated with the physical weights. You could even use an I/P controlling a volume booster, which is essentially the same as the precision regulator, but with a fluid pressure setpoint instead of a screw and a spring. Then you can still programmatically control the tension without worrying about dancer position.
-
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.
Here's the general breakdown. I send the desired speed to the secondary nip drive (0-1081FPM -> 0-120.0HZ). On the rewind, I'm working backwards from that speed. Since it's a constant, I'm using the calculated diameter of the running roll (derived from the core diameter and material thickness entered by the operator) to get myself the RPM that the rewind needs to be running. I send the speed to the drive in terms of RPM. So if at 60.0HZ it runs 720RPM, I calculate how many RPM it should be running, input it into a scaling function, and out comes my (what I call) Base Speed Reference.
I have the PID loop output set to scale -100 to 100. This is -10.0 Hz to 10.0 Hz. To get a final speed reference, I add my Base Speed Reference and the PID Output (multiplied by the ratio of CORE OD to ROLL OD per your recommendation), and it gives me a number that I send to the rewind drive (whichever one is inboard).
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.
-
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.
-
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.
-
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?
-
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!
-
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.
-
So no throwdown? Sad.
-
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.
-
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!)
-
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!
-
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.
-
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.
-
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.
-
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).
-
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
-
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.
-
The issue with the drive accelerations is that one is connected to a 120HZ motor, one to a 60HZ motor. If I don't have the rewind at a slightly higher accel / decel times, when the machine stops, it creates slack in the web that causes issue on the next startup. By having the secondary stop a little quicker, it keeps the tension in the web. The rewind drives still seem like react faster than the secondary. I believe this issue has to do with the gear ratio on the mechanics and the difference in maximum frequency.
I could change the accel / decel times and then create a delay in stopping the rewind drives, but that was something I was kinda wanting to avoid for the sake of safety.
-
Dropping the rewind drive after the line stops is pretty standard. You will never have a controlled tension while stopping otherwise, at best you may hit on a compromise that is acceptable such as you have now.
-
The biggest issue I've been having is that it looks like someone got to poking around in my secondary drive and gave it an s-curve acceleration. I set this drive to factory default and then loaded my parameters in it when I started the project. I believe the last person I saw poking around in it was my manager. ::) I took the S curve out of the acceleration, and it looks to be helping. The issue is now that I can't get it to start at production speeds (anything above 250 FPM). If I turn the gain up to make it start, it oscillates. If I turn it down to where it doesn't oscillate, I don't get good response. Like, for instance, look at this curve. The PV goes to the limit 0 (slack in the film), the SP is at 50%. I don't know why the Output flattens out like it does. Shouldn't it continue going toward 100%? It's not speeding up fast enough and causing roll formation issues. If I start the line at 250 FPM or less, it gets to speed and stabilizes, and I can then speed it up to production speed. I'm about to take a hammer to this machine.
http://i.imgur.com/l78TIAw.jpg (http://i.imgur.com/l78TIAw.jpg)
-
Also: Just for clarification, on the DMD, the Reset Rate is what we set? So the output changes by the Gain (times the error) every X sec that the Loop is set to. So, if I have it set to 0.5 Gain and it set to 10 sec of Reset, if my error is 10%, my loop will move 5% every 10 seconds?
-
I don't know why the Output flattens out like it does. Shouldn't it continue going toward 100%?
It is, just very slowly. Your P is maxed out, so the only increase in output will be due to I, and you can see the output is trending parallel to the bias.
There is some fierce deadtime in your system. It takes 5 seconds at an output level that eventually causes overshoot before you can even start turn the PV line (though that could be the dancer on the stops and there's excess slack to take up before the dancer even finds out about it). And that same CV won't get the dancer in position or even close to it in 10 seconds.
What's disturbing the system? Is the feed speed not stable? Put a tach on it. If you have access to a real time line speed signal (and even a winder speed signal), adding those to the trend would be interesting. And are you sure you CAN change rewind speed fast enough to keep up with the disturbances? Big enough motor, plenty of drive, etc. Looking at this, I'm thinking that dancer accumulation length (long path - short path) would be interesting to see.
-
Maybe BobO can answer your questions on how Do-more handles these values and functions. I don't want to steer anyone wrong including me.
It might help if you could trend the speed references you are sending the drives along with the PID PV, Bias and Output. I think what I am seeing is a response to nip speed changes but maybe not?
The integral (bias) is starting at only 25% or so in your graph, why is it so low? The proportional gain is low enough that you can only swing about 25% above or below the bias.
But those huge swings make me suspicious that you have an outside influence issue. I would be checking that there is no slippage of the core on the winder shaft, but that is probably not the problem since it is both spindles doing it.
Another nasty gotcha is a dancer that doesn't always move the pot so there is deadband.
Slippage at the nip when the web tension increases.
Stiction at the dancer pivot where your tension has to increase too much to get it to move then it is easier and overshoots.
A hole in the diaphragm in a rolling diaphragm dancer cylinder. Or blowby at certain spots if rings. Non-diaphragm types are bad to be a source of stiction BTW.
I wonder what Controls Guy posted while I was composing this? Cool, we are on the same page I see.
-
Basically, your loop control is WAY slower than the disturbances in the process, which means you need one of a few things:
1) The process is in a non-ideal state and you need to find the cause or causes of the deviations and fix it (slip on the nip as Mike notes would be a good example)...or, if it's not possible or cost effective to correct the process, then:
2) The control needs to have more response capability. Ample winder motor, make sure the winder drive train is free of backlash, more aggressive tuning, etc....OR
3) More dancer accumulation to buffer transient variation in web speed and let the winder work on the short-term average rather than trying to whipsaw with every variation.
Scenario 2 and 3 will require you to make sure the dancer inertia, friction, and stiction are sufficiently low to follow the web.
-
This doesn't help Evilbeard at this point, but I have been putting together a controlled winder simulator in the simulator today. Just crazy I guess. So far, I have "built":
Ramped master reference
Integrator to calculate footage of web through the master nip
Integrator to calculate footage wound onto the spindle
Dancer position from those two footages
Diameter calculator
PID trim
Spindle reference
Calculated spindle speed
I still need to calculate actual diameter build from footage and thickness. And figure out how to add a banging sound when the dancer hits the stops. ;D
Currently it "runs" and holds the calculated start diameter of 3" for quite awhile. The spindle "manually" creeps the dancer into position when the spindle is started, then the line and PID may be started. It holds position pretty nicely after getting the diameter calculation rate reasonable and tuning the PI and sample rate.
It's almost a pity that it's all "imaginary" in Do-more's simulated mind. :D
I would really, really love to have a packaged RAMP or even a rate limiter. The alternatives get a bit big and clunky.
So far the bottom line is, it looks like a real section control dancer at the moment since the diameter doesn't build yet. I can definitely see a resemblance to Evilbeard's issues. Too little gain makes the integral too dominant and it swings badly though slow. And I don't even have any emulation of real world lag yet either (RAMP RAMP RAMP).
But right now I am late to bed. If I don't lose interest and can pretty it up a little, I may post it in the examples or something as a toy.
I had a little quirkiness with PC CPU usage maxing out and causing huge delays after setting Memory Manager to retain R,C,D and T. It really seemed to get extreme when a timer started timing. I had this even with only one small program block showing status. Odd. Page faults in DMDesigner.exe were about 1000 per second when it would max out.
-
I seem to have a functioning simulator. Just like the ones your daddy tunes! Batteries not included.
It's a bit weird to see the thing act pretty much just like most of the real ones I have had to deal with. All of the quirks with none of the waste and time restringing the web. It would be nice if there were a neat way to have a faceplate or something other than data view and trend, though both are great for sure.
Does anyone have a good suggestion on getting the .dmd set so it plays "out of the box"? I'm thinking maybe an Initialize instruction you can toggle on to reset back to "factory". Also, I have tried to clean up unused memory values, but how do you get it to retain data views and trend views if it decides to load without the simulator? I seem to lose stuff if that happens.
I think I want to try to add simulated drive ramp times for what can be learned about the hazards of such. Backlash on dancer feedback I would like to get in too and shouldn't be too hard. Stiction might be harder since that is more of an issue with the drive's speed loop not tight enough to overcome and might be more than I care to bother with.
Hopefully I can package this up and get it on the forum for anyone who wants to play with it. Maybe even this year.
-
Here is the Dancer Controlled Winder System Simulator
http://forum.hosteng.com/index.php/topic,1925.msg16183.html#msg16183
-
Post attachment size limit so here is the screen shot of High P Gain and no Reset (integral).
Check the Data View for trend view keys.
-
Post attachment size limit so here is the screen shot of Low P Gain and Low (fast) Reset (integral).
Check the Data View for trend view keys.
-
I seem to have a functioning simulator. Just like the ones your daddy tunes! Batteries not included.
Wow, cool! (And you have way too much energy for any one guy) ;D
-
Evilbeard,
I added the spindle drive accel/decel lag and dancer position feedback lag to my simulator. I need to fix a few minor issues before I upload it again.
I didn't get exactly what I expected. I deal a lot with load cell winders and those may be the ones that are terrible with drive lag since they have no storage. The simulation showed I had to have more than a couple seconds of acc/dec before it got unacceptable. Backlash (deadband) was much more entertaining, especially with integral (reset) having a contribution.
-
I'm back to work today, and I'm going to get some material back on the machine and adjust a bit. I'm going to manually set the bias to around 75% and then start up the line and see what that does to my results. I don't know why it was so low. I'll keep tweaking on my settings and see what I can get out of this thing. I feel it has to be a setting issue.
-
I found out last night that setting the PID.Bias before enabling the PID did nothing for me. Setting the PID.Output with a one shot a few rungs before the PID was enabled sets both output and bias and it starts from there. This was only an issue if the bias wasn't at 50% when the PID was disabled previously.
Good luck.
-
Well, I set the Output to 52.5, and I had set the Bias to 0 somehow, causing it to be low. We'll see what happens here in a few minutes. Here we go!
-
Turns out I was having a slight communication issue with my secondary drive. The acceleration wasn't quite acting linear because of the issue in communicating the speed ref. I made it analog and my secondary nip now accelerates smoothly. Once I got that lined out, it was just no time before I had my loop running great. In other words, I'm a doofus.
-
Welcome to the club, my brother! ;D
-
Turns out, I spoke too soon. We ran a light gauge film on the line and ran it at 500FPM start to finish with no problems. The operator came over, put on production film, and now when starting the machine out, it ramps to speed (dancer looks great), and then when it reaches speed, everything stabilizes. Then, the dancer seems to creep out of range, and everything goes to hell. The top pane of the picture is the Dancer (white)/Setpoint (red)/PIDOutput (aqua)/Roll Diameter(yellow). The bottom pane is the Secondary Speed (as a percentage of 0-max in RED)/Drive Base Speed Reference (before being trimmed in Yellow)/ Speed Reference (Aqua.
You can see the acceleration of the line, everything looks good. It reaches speed, and then the drive starts decelerating to allow for the roll building diameter (I verified diameter with a roll tape. I measured 9.93" on my calculated 9.95"). Then, the dancer starts going toward the limit. The secondary nip drive is a steady output frequency (it varies 0.1 Hz now that it's analog). I just don't know why it's doing this, and how I can correct it. I've tried more I to smooth things out, and that didn't help. I tried more I and more gain, it didn't seem to help. I tried less I and less gain, and it didn't seem to help. If I had any hair left, I'd pull it out.
(https://forum.hosteng.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FELz0jVE.jpg&hash=375a2864924f9d8fad437fcdc6eb688fdcda89a0)
-
FYI, Designer's PID View and Trend View have a Trend Archive file format, where you can hit the Record button or Export button in the view's toolbar, and then save it as a Trend Archive file, which you can email to your friends or post here. Anyone can then do File->Import->Trend Archive into New Project to look at it in a static/historical mode, complete with zooming and clicking on data points, etc.
Great for late night PID view discussions (like that ever happens) ;D.
I've attached a sample in a .ZIP file. You will need Designer 1.4 to open it. After importing, please change the time scale on your Trend View to something more reasonable ???.
This forum has a limit of 512K per post. Mine was for just a couple minutes, and zipped it was 64K.
-
Evilbeard: what's your I time and P gain?
BobO: Is I dependent or independent type?
-
BobO: Is I dependent or independent type?
Sadly, I'm going to have to admit that I don't know what that means.
-
If you double your P-gain and it automagically doubles the absolute rate of change of the I term (in percent CV, say) with no change in Ki, then it's dependent. If not, it's independent.
-
There is a single gain term that is applied to each of P, I, and D...pretty sure that means dependent.
-
I hate to sound so seriously ignorant, but we started with the equations Koyo used for DL and fixed quirks as they were pointed out. Once everything was working as expected and blessed by folks who know lots more than me, I pretty much purged it.
-
I hate to sound so seriously ignorant, but we started with the equations Koyo used for DL and fixed quirks as they were pointed out. Once everything was working as expected and blessed by folks who know lots more than me, I pretty much purged it.
I think it's probably documented in the 205 manual, I'll check. Either way is fine, but my response to Evilbeard's trends will vary a little based on the answer.
-
Yup, dependent. If you change Kc, it scales all the terms.
-
Evilbeard, I can't tell what your traces are supposed to represent in that shot as there are no legends and no y scales visible.
My first thought is you maybe have something wrong in your diameter calculation - not the math, but the update speed. If your web is thin it runs fine, but if thicker it gets behind. Are you counting spindle revs and multiplying by film thickness or footage by thickness to get area, adding core area and then getting the diameter or...? If you don't update the spindle ref from diameter build fast enough you will get behind. Thicker film can be a much faster build rate. It looks like you are incrementing about once a second unless that is just your trend sample rate (I don't recall if you can set that and it is late, late after a very long day. Any chance your diameter checks after stopping but you didn't really get the info to the drive fast enough while running? Build at core should be faster, but ramping to speed can reduce that early build rate?
-
Evilbeard -- your dancer position instability seems to cause, rather than result from, the CV oscillation. If so, that would imply there's still some issues in the process.
Also, in the middle part of the trend, the PID output is dead flat, when it should be trying to reset. Since DM PID is dependent, increasing either P or I should make it more aggressive.
I'd still be interested to see what P-only would do, but you're going to need a stable process for that. I will tolerate transient instability better.
-
Evilbeard, I can't tell what your traces are supposed to represent in that shot as there are no legends and no y scales visible.
My first thought is you maybe have something wrong in your diameter calculation - not the math, but the update speed. If your web is thin it runs fine, but if thicker it gets behind. Are you counting spindle revs and multiplying by film thickness or footage by thickness to get area, adding core area and then getting the diameter or...? If you don't update the spindle ref from diameter build fast enough you will get behind. Thicker film can be a much faster build rate. It looks like you are incrementing about once a second unless that is just your trend sample rate (I don't recall if you can set that and it is late, late after a very long day. Any chance your diameter checks after stopping but you didn't really get the info to the drive fast enough while running? Build at core should be faster, but ramping to speed can reduce that early build rate?
Mike, the picture is so large that it scrolls to the right. You can see the y scale on the right. I'm calculating diameter using the area method. I'm doing it with a few simple math boxes, and it's performed on every scan. The incrementing you see is the acceleration of the line, I update the speed every second with my little deltas I calculate in the accel/decel subroutine.
as far as the traces go, they are as follows.
Top Pane
White - Dancer Position
Red - Dancer Setpoint (this is actually inaccurate in this trend, I had manually set it to 42, this is displaying the memory location value, MY BAD)
Aqua - PID Output
Yellow - Roll Diameter
Bottom Pane
Red - Secondary Speed (on a scale of 0-100%)
Yellow - Base Speed Reference to the Rewind (this is the calculated speed I use before it's trimmed)
Aqua - Speed Reference to the Rewind (after being trimmed and combined with the PID output)
Evilbeard -- your dancer position instability seems to cause, rather than result from, the CV oscillation. If so, that would imply there's still some issues in the process.
Also, in the middle part of the trend, the PID output is dead flat, when it should be trying to reset. Since DM PID is dependent, increasing either P or I should make it more aggressive.
I'd still be interested to see what P-only would do, but you're going to need a stable process for that. I will tolerate transient instability better.
I apologize. The red line in the top pane is inaccurate. It was looking at the vmemory location of the dancer setpoint, but I had overridden it and set it to 42 manually. It should be down in the middle of the PID output there. It's misleading. I'll try to get you guys actual trends with accurate data when I return to my computer in an hour or so.
-
I missed the image getting whacked (old eyes and zoomed in too much.) Change trend time divs to match the seconds will help too.
Unless something is loose, the dancer swing looks like too much integral action. Big slow swings getting progressively worse. Proportional gains too high usually have a higher swing frequency. But as Controls Guy says, increasing the gain also increases the integral action so I would want to go up on Gain but increase the Reset value (longer time, slower response.)
So after playing with the simulator, I am having trouble getting anything that looks real similar to your trends. I have a diameter calculator that comes into play though and it can contribute to instability.
However, this once a second reference update thing... does this include with the trim, i.e. you only change the reference once a second period? I can get real ugly looking stuff trying to emulate that.
-
In further investigation, it shows the PLC was slowing the drive down. The yellow line trending down shows the Base Speed on a slow decline. We found that we were having more communication issues. The drive was getting down to 17.0Hz and just sticking there. It wasn't going any further, despite the PLC showing that it was sending smaller numbers. I've wired the speed reference to the rewind to be analog from an analog output.
However, I'm having some more issues. My analog seems to have lost its mind. The dancer, despite being scaled to 0-4095 (12 bit), jumps to like 15000+, and is showing up as erratic. If I go and move the dancer by hand, it showed a smooth curve from 0-4095. I moved it from one input to another, same thing. I changed the scaling to 14 bit, cycled the PLC from run to program and back, and then it showed me 0-4095. I put it back to 12 bit, and I'm getting negative raw numbers. Putting a meter on the input, I never see negative numbers. It's even hooked to a programmable signal conditioner that only puts out 0-10V, so I'm having hard time believing that it's the physical input.
What could be causing me this issue? Anyone have any ideas?
-
I can't get into DMD right now, but try viewing the analog input cast as unsigned. WX0:U for example.
You didn't mention which card you are using.
-
I'm using an f2-8AD4DA-2.
-
I read it as the only resolution needing the unsigned is 16 bit. I don't know what is happening on your issue.
-
If it were a 4-20ma AI, they set the MSB on open circuit, which then looks negative and large magnitude, so it could be a loose wire, but I don't see how that can happen with 0-10V.
-
I think it's noise. After running the analog output wire to the drive, the analog card has been acting super wonky, though. I removed the output wires to the drive completely. I started pulling analog inputs off one by one to see if they were causing the issue. When I was putting one back on, I noticed it's output changed. Multiple of my input were scaled wrong, as they were changed from 12-bit to 14-bit. Nothing I could do would change the raw number I saw on WX1 and WX2. I just ended up having to change my program to scale to 14 bit instead. *shrug* I even had WX2 display a raw number in program mode, and then go immediately to 0 and not change at all when the PLC was in Run. I verified with a meter than it has 1.10VDC on it. I searched the program for all instances of WX2, and there was only one, my scaling function for display on the operator panel. I just don't know. I ended up moving it to another input and it works just fine now.
I made sure all the unused inputs were jumpered together and they were tied to DC common. I pulled a new wire from the signal conditioner (it takes the potentiometer on the dancer and converts it to 0-10V and I've verified it's working properly) all the way to the analog card. I made sure to route it around any power wiring to eliminate noise and terminated the shield on ground. Nothing seems to help this. Something to do with the drives/motors has to be causing the noise. I don't get the issue with the dancer input when they aren't running. I just don't know what else to look into.
Here's a link to the short data set I could get. The first one is the one I started with (the dancer creeping problem) and the second one is the dancer input issue. 0% dancer is film slack. 100% dancer is the short accumulation on the dancer.
-
Just to throw this out there. Using analog voltage signals with drives is rarely a good idea. 4-20ma signals are incredibly more noise immune and less likely to cause these sorts of issues.
-
I second what ADC PE says about ma vs. voltage signals. I always default to ma over voltage for any app, unless the instrument is simply unavailable in ma.
Back in the old days, you might use voltage to transmit a speed or torque setpoint to a drive designed to take one from a pot with no process input per se, but even then you could do the same with a 0-20ma signal and a shunt resistor, which would be preferred.
Even if I were hooking up to a pot-only input today with only a 4-20ma signal output available (no 0-20ma IOW), I'd still put a signal isolator next to the drive and do 4-20 for the whole distance and 0-10 or +/10 just the last foot.
-
We isolated the noise, and found that it was coming from the Ethernet that I set up to control the EDRVs. If you started the drives with the keypad, the dancer was clear of noise. If you started the line with the EDRVs using the Ethernet, it was noisy. I used today to wire up all the drives to analog speed references and discrete operation command. The dancer noise issue was eliminated. I don't know why it would be in the Ethernet. I had a Stride switch, which was grounded (at the power lug as well as the case) and going to the Ethernet port on the DoMore CPU, I wouldnt' think it would create that much noise.
-
Once I got the noise out of the system, everything went swimmingly. I tuned the loops a little, and got everything working. I had to make a few tweaks in going from the EDRVs to analog signals, but otherwise, it was smooth sailing today. Here's what it looks like running production at 425 FPM.
(https://forum.hosteng.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FdAF4tgq.jpg&hash=cb61b9623818954ec97e911dd46b0eda12cc56fb)
I just wanted to thank everyone for their help and patience. It's been a learning experience, and the next time I tackle a project, I think it'll go much smoother.
-
Awesome! Glad you got it working good. :)
Nice video too.