Sign in to follow this  
Followers 0
billjr

Motor Speed Command based on Analog Signals

19 posts in this topic

Hello, We have a shredding macine with an analog input ( 0-10V) from the Motor going to a Control Logix. The infeed Conveyor to the shredder has a analog output (0-10V) for speed reference . The more load on the Motor the slower the infeed goes and less load more infeed speed. What would be a good instuction(s) to use to give a speed reference to the infeed conveyor based on the Motor Load. I have the analog signals scaled form 0-100% Thanks in advance

Share this post


Link to post
Share on other sites
This sounds like a classic PID Loop situation using PI should be adequate I would think. Those more skilled than I in the "Fine Mystic Arts of PID" {pun intended} will probably chime in with relevant advice once I make this post.

Share this post


Link to post
Share on other sites
Thanks, I was wondering if that was the direction to go. I have not used that instruction before. Any links or documents on hoe to use it properly?

Share this post


Link to post
Share on other sites
This sounds very similar to a posting, possibly on another forum, but i can't find it now - varying speed output based on the inverse of the current input from another drive.

Share this post


Link to post
Share on other sites
This one? http://www.plctalk.net/qanda/showthread.php?t=61537

Share this post


Link to post
Share on other sites
No one has actually given you an answer yet except for the suggestion of the PID instruction. If you really aren't too worried about the specific current level that the shredder ends up at then you can always try: Infeed Conveyor Speed = 100 - Shredder Current In all likelihood this will give you poor performance with much oscillation of speed and current finally ending up around 50% But if that's OK then fine. Using the PID instruction you can define the desired level of current (SetPoint). The speed of the Infeed Conveyor (ControlledVariable) will be changed until the current input from the shredder VSD (ProcessVariable) matches the 'setpoint'. The setting of a PID loop with its various timings and gains in considered a voodoo art, at least by me. If it were me I would decide on a level of current from the shredder which is acceptable. If the feedback current is not currently up to that then add a little bit to the Infeed Speed. If it's above that then subtract a little from the Infeed speed. Do this operation on a timed basis, not every pass through the logic. Now here's the fun part. You get to figure out, by experimentation, how much is a 'little bit' and how often (timed basis) this should be done. No one here can give you real numbers that you will end up with. But start with a long time (many seconds) and '1' as the 'little bit' slowly increase the 'little bit' while decreasing the time. In essence you end up with a home-made version of a PID loop. But you'll be much wiser for the experience. Edited by b_carlton

Share this post


Link to post
Share on other sites
This can be approached in a few different ways and it doesn't need to be accurate. First I would implement the conveyor speed control with a simple feed forward and proportional gain. This should be easy. If you know how fast the conveyor should be moving then the control output to the motor should be proportional to how fast the conveyor moves. I would add a proportional gain that would correct for errors between the feed forward's estimated control output and the required control output. There will probably still be speed errors but they will be small. To reduce the control output when the torque is high I would integrate the torque error and subtract that from the speed control output. The integrator should only subtract from the control output and not add so a low torque doesn't make the conveyor go faster. The integrator should not subtract from the speed control so much that it makes it go backwards. Another way of doing this is to use the PI part of the PID block. Then integrate the error between the limit and actual torque and multiply that by a gain and subtract torque term from the accumulated PID block integrator. This would reduce the speed control's output when the torque integrator started to build up. There are three things going on now. The proportional gain and the two integrator gains. The torque integrator gain must be higher than the velocity integrator gains so the torque integrator can override the velocity integrator and slow the system down.

Share this post


Link to post
Share on other sites
Not to seem simple, but is there an example of what your trying to say that you could post that we could look at..??? Maybe looking at it could make me understand this better. PID's kind of makes me kringe.. Thanks, Mark

Share this post


Link to post
Share on other sites
I do not see any comment about how much material is dumped into the shredder in proportion to either time or conveyer speed. I think this is what really needs to be controlled and is the challenge. SO how is volume or weight controllled is it placed manually and can vary from one inch to six inches thick? If that is the case then infeed speed control will not handle this variable. If so I agree with Bernie the speed on infeed conveyer will vary by quite a bit - that just may be the way it is and may be acceptible. The good side of it is infeed is slowed stopped to let shredder handle an overload. Dan Bentler

Share this post


Link to post
Share on other sites
b_carlton is describing a P (proportional) only loop which is so simple that you don't need the PID loop overhead, but some days it will overshoot and others it will undershoot. So whether he knew it or not, he was recommending a P(roportional) control loop. These work OK. Most folks using PID loops usually just use them as PI loops by the way...I rarely see the derivative gain set to anything other than zero. As a first pass with any control system, see if you can actually do what you are asking for manually. If you can't then right away I can tell you that it is unlikely that a control loop will work. Any time I'm asked to automate something my first question is whether or not an operator can do what is being asked now. If the answer is no, then my automatic response is that I'll give it a shot but I can't perform miracles. The second problem in this case is that quite often in "choke feed" type systems, the response from the motor is very nonlinear...basically going from minimum to maximum speed, the trend tends to be no load, no load, a little load, overload. PID loop controllers are linear by nature so it's not always the best option. If that is the case, sometimes sliding mode controllers work. SMC is very simple but the math is kind of ugly, so the academics would rather talk about something else. AB's PID instructions on the surface appear extremely complicated because there are a lot of features packed into it, and you won't ever use most of them. I've been at it for a while and I,ve used about half the features in it. To begin with, understand that for instance both Allen Bradley and Ron Beaufort treat "PID loops" as a one week class. In Allen Bradley's case, they spend a lot of time discussing all the various features in excrutiating detail. In Ron Beaufort's case he spends a lot of time on all the stuff surrounding the PID loop because usually when you get called in to "troubleshoot" a control loop, it's not the loop controller that's the problem, and since it's more complicated than simple on/off systems, they often drive technicians up the wall. The keys to making a PID loop work are: 1. PID loops do not work in ALL cases. The control loop must be reasonably linear. So for instance pH control is very difficult because pH is on a logarithmic scale and because K factors (a chemistry issue) make the response nonlinear. PID loops also perform very poorly with long time delays in the system. No control loop is going to perform well if it is controlling the wrong thing or if some uncontrolled variable is a bigger influence than the controlled one. 2. PID loops are always reactive...like looking in the rear view mirror while driving forward. It works, but it can't anticipate or react to things coming up. So for instance even in a chemical plant (where they are popular),, a big change in the set point may throw the loop out of control. A combined feed forward/backward system may be necessary for performance reasons where the main loop is feed forward and the PID loop is just there for "fine tuning". The easiest way to do this is to calculate a "proportional gain" (divide the PV by the CV at a reasonable operating point). The outside the loop, your feed forward equation will be output=SP / process gain. Add this output to your PID output so that the "feed forward" loop runs in parallel with the PID loop. Add some external clamping to avoid outputs beyond the extremes (keep it 0-100%). This makes your overall system attempt to jump right to the correct output whenever the set point changes, followed by the "get it right eventually" response from the PID loop. The feed forward loop can be more complicated (overexciting the output for faster response) but in most cases this simple proportional feed forward works well in practice, but PI loops alone also work well in practice. 3. The PID loop in an AB PLC has a "time base" in it. Everything in the loop is programmed in terms of changes per unit of time. If the unit of time changes, then the loop response WILL not be constant and it will eventually be out of tune and do something unexpected. Many professional programmers screw this one up because they don't understand this subtle detail. The simplest, most reliable solution is to ALWAYS run the PID instruction in a "timer task". CLX has timer tasks. In SLC and PLC-5 it is called an STI (software timed interrupt). Note that especially on CLX and SLC you have access to a high resolution timer and that you can manually update the time base constantly. Also if the loop is roughly 10-20 times slower than the scan time and the program will never grow large enough or have any "housekeeping" activities like totalizers that violate this (when you get a really slow scan once in a while), you can get away with a free running timer. My advice is don't do it. A constant time base ladder is very simple and eliminates the problem. Timer tasks are simple and totally eliminate the issue from ever happening. 4. The PID loop comes in multiple flavors. Use the one that uses a PD data type on SLC/PLC-5 or equivalent on CLX. The PIDE instruction on CLX has roughly 4 times as many features making it even more confusing. About the only positive improvement is that they have an autotuner (if you pay for it). 5. Carefully read the manual about scaling. Again, no it's not obvious. The PID instruction can read the input directly but you have to usually copy the output yourself. 6. There are two "manual" bits (except PIDE...still not sure I understand that one). The software (SWM) manual is the one you want. Feed the operator manual input (.SO, set as 0-100) and read the resulting output from the PID loop. 7. Forget about the "tieback" register. That's for if you have an external controller and want to provide some sort of backward compatibility. Trust me, just set it to a bogus register and forget about it. 8. The function of PID is to try to drive the PV (process variable, the input) to match the SP (set point) by adjusting the output (CV). Best way to tune the loop is by making a trend chart with these 3 variables on it. Hand tuning it without a visual chart is a nightmare. 9, The "bias" register is NOT a feed forward register. Just forget about this one too. If you must do feed forward, write your own in parallel with the PID instruction. If none of this makes any sense, forget about it. 10. Realize that many loops have troublesome startup characteristics or handle a process "bump" poorly. So much so that you may as well plan on starting in manual and only switch to auto once everything is running. Usually adding feed forward takes care of this, but this requires more programming than just the PID loop. If this is the case, turn on the "PV following" bit. What this does is that when the loop is in manual (and you MUST use the .SO and .SWM functions for your manual routines for this to even work), the PID instruction overwrites the setpoint (SP) with the current PV. That way you can adjust all you want in manual. Once you set it in automatic, it "locks on" and tries to hold the PV steady. 11. Use the independent gain equation. Academics are the only ones that prefer the dependent gain equation because that's the one in the book. Also do NOT expect the loop gains on vendor A's equipment to work on vendor B because every implementation is slightly different. If you have a choice use the velocity equation (only possible with the PIDE instruction on AB hardware....as I said this should be avoided for other reasons). 12. If you have a servo or other mechanical system, it is possible to actually calculate exactly what the correct tuning factors are. But if it's process control, this can often be difficult or impossible to do. There are various "auto tuners" and tuning software out there. It's both expensive and frequently doesn't work all that well. So for the rest of the world, there is manual tuning. 13. For manual tuning, what I'm about to say is all heresy. It works in practice. It is not the engineer approach. Forget about the words "Ziegler Nichols". Folks who mention ZN have either never actually done it or just tell you that because it sounds good. I've never met anyone who did ZN by the book and did not manually tune parameters after that, and most don't even do ZN the way it is supposed to be done (because the "steady oscillation" test is difficult to achieve in practice). I've tested my final settings against tuning software and found that I get the same results so as simple as it sounds, it "works". I've also noticed that most people use roughly similar manual tuning methods as well. This particular method is best for strictly PI loops or those with slight amounts of derivative control (basically, first order). If you have lots of time lag and/or an integrating loop it will still work (if it can work at all) but it takes longer to find the correct values. Start with the loop in manual and near the normal operating range. Adjust the output up or down by a significant fraction and wait for it to stabilize (based on the trend chart). Carefully calculate the first gain, proportional. Calculate the delta of the PV's. Calculate the delta of the two CV's. The ratio (PV gain divided by CV gain) is the proportional gain of the loop. As a first cut, set the integral gain to 10% of the proportional gain. Switch to auto and watch what happens. Adjust the integral gain so that it "pulls in" the loop to get the PV and SP to match as quickly as possible without causing too much oscillation. Adjust first in increments of 10 fold (multiply or divide by 10) then double/half. Once it is reasonably tuned, you may try adjusting the proportional gain as well. Once this is working reasonably well, try increasing the differential gain in the same way. You will be able to increase the reaction rate of the loop overall while not ringing too much by adding derivative gain but many times the loop just doesn't need it. Once everything is reasonably tuned up, make one more pass using even smaller increments if you want to eek a little more performance out.

Share this post


Link to post
Share on other sites
Yes. This would reduce the variance of the torque on the shredder motor but what if this material/time delivered by the conveyor can't be controlled well?. Then the shredder torque limit must be taken into account. This isn't about tuning PIDs, yet. It is about how to approach the problem. What we haven't heard is if the conveyor is controlled by a drive. If so the drive can take care of the conveyor speed control and all that is necessary is to reduce the speed reference to the drive when the shredder torque gets too high. Why not do something this simple? ConveyorSpeedReference=NoLoadConveyorSpeedReference*min(max(1-(ActualTorque/TorqueLimit),0),1); If you want the conveyor to travel at 80% of max line speed the NoLoadConveyorSpeedReference will be 8 volts. If the TorqueLimit is 80% and if the ActualTtorque is at 10% the function will return min() 0.875 which will slow the lime down to 0.875 of 80% line speed. If the ActualTorque reaches the TorqueLimit the max() function will return 0. The line will stop until the actual torque is reduced. The min() and max() functions are necessary to max sure the NoLoadConveyorSpeedReference is only multiplied by numbers between 0 and 1. Look Ma! No PID required! At least not in the PLC.

Share this post


Link to post
Share on other sites
This would be a disaster. It isn't a cutting process which allows for the torque to vary. The key to a shredder is to apply a strain force well beyond the plastic deformation point of the material, leading to breakage (more specifically, tearing). Strain as you know is shear force per unit of time. Although in your scheme shear force remains constant, time does not. The result would be that the shredder "gums up". As I mentioned early on since the goal is to apply strain, as the amount of material increases, we rapidly approach capacity of the motor. Since the shredder head itself draws quite a bit of torque relative to the motor, usually that extra inertia carries it through temporary overloads without incident. But under an overload condition, the twin loss of that inertia and that the only way to clear the overload (roughly a traffic jam scenario) is an exponential backoff of incoming feed (stopping it is usually best), usually results in a jam. Operators with a shredder get used to "what it sounds like" and learn to back off accordingly but by then it's usually too late because the belt already has a bunch of feed stock on it. So the choice is usually to stop the belt or let it overload and clean out. Adding PID control to the belt doesn't give you the exponential backoff that is necessary to recover but often increases the size of the "window" when you go from heavy load where it is recoverable to jammed. The ultimate control loop here is to use incremental increases and exponential backoffs. Studying up on Internet TCP algorithms (Jacobson was something of a genius) is usually very enlightening because the Internet TCP protocol has exactly the same problem to deal with and similar solutions, and similar problems (how to ANTICIPATE impending overloads and reduce/recover before they happen without constantly see-sawing).

Share this post


Link to post
Share on other sites
My back off is linear. I could easilty make it non-linear. Did you notice that the multiplier of the NoLoadConveyorSpeedReference goes from 0 to 1. Pick a function that goes from 0 to 1 as a function of torque. I could change the function to ConveyorSpeedReference=NoLoadConveyorSpeedReference*min(max(1-(ActualTorque^2/TorqueLimit^2),0),1); So what is your suggestion? Your long winded post avoided the topic of torque.

Share this post


Link to post
Share on other sites
1. Leave shredder speed constant. Don't screw with it. A drive isn't really needed for it since speed variation is not needed. 2. Feed onto the belt should be relatively constant if possible. Sometimes something as simple as a hopper or an adjustable "gate" to create a choke point over the belt is all that is needed. Beware that operators will of course try to cut it out or open it more to increase flow rates, not realizing that EVEN rates is the key, no matter what the flow rate is. 3. PID might work OK for feed rate control and I'd try that first. If it doesn't work, I'd switch to the AIMD algorithm: A. Algorithm has 2 internal variables: CV and CI (current increment). B. At each time interval if the torque is below set point, set CI to a constant and ADD it to CV. If it is over the set point, double it and subtract it from CV, Note that CI will double at EVERY time interval until torque backs down below set point and then instant drops back to the additive increase amount. C. Latch CV and CI at the extremes. There are three (possibly 4) adjustable parameters for an AIMD algorithm: 1. The update time constant Usually setting this to something reasonable is good enough. 2. The additive increase amount. This is pretty much the one tunable parameter. 3. The latch values. I usually set them to the extremes (0 and 100%). You don't get "windup" in this algorithm since it always resets when it drops below set point, but I like to avoid math overflows and the like. 4. Optionally, the exponent on the exponential backoff. TCP sets this to 2, and it seems to be a reasonable value in most cases, but more (higher than doubling) or less might be a refinement. All of the above works. Everything beyond this is a refinement. As Van Jacobsen describes it is possible to modify this further by adding a third state where it is "not quite overloaded" and additive decreases might be OK...basically this is where a PID algorithm can work if you don't ever get into full overload conditions, or you can simply add it in. If you convert the "very underloaded" scenario to exponential increases as well (this is Van Jacobson's start algorithm), what we've just come to is a sliding mode controller with exponential responses outside the "window" and linear ones within the "window".

Share this post


Link to post
Share on other sites
??? So what is CV and CI? I don't see where your suggestion is practical whereas a funciton that returns 0 to 1 and can be multiplied by the NoLoadConveyorSpeedReference is easy and understandable. My simple proportional only would work well enough. After that was going the derivative and integrator terms could be implmented. Actually, I would implement a derivative term to the motor torque to and a power limit that would require knowing the speed of the shredder. SMC, are you aware the SMC is basically an ON-OFF type of control? What would you be turning on and off?

Share this post


Link to post
Share on other sites
SMC is more than just on-off. You "slide" into the central window with exponential moves, then use additive increases/decreases.

Share this post


Link to post
Share on other sites
What are these additive increases and decreases? Lets see an example. I don't think you really understand SMC. How does one implement SMC in this application.

Share this post


Link to post
Share on other sites
As I understand it, with SMC, you fire the controller at a set rate (frequency). At each update, look at the error (PV - SP). If the error is below a threshold, then you increment or decrement the value in the CV (control variable, the output) by a set amount. If it is outside the error range, then each move multiplies the error by a constant and adds or subtracts it as needed...the algorithm slides exponentially towards the set point. Examples in these web sites: http://www.ece.rutgers.edu/~gajic/SlidingModeControl.pdf

Share this post


Link to post
Share on other sites
Look at page 11. That isn't what that says. Also the document you referenced adds a non standard twist with the control law. In a motor app the motor would get full postive current or full negtive current by switching an H bridge. Whether the current is going positive or negative depends on the sign of s, Notice that in the control law below the control output is proportional to the error. This is not right. This makes alpha a proportional gain. The destroys the robustness. Note, the on/off control can be integrated but then it integrator 'gain' is just that and if it isn't fast enough the system will not respond well. Look in the downloads sections Sliding Mode Control Excel Speadsheet Temperature systems can be ideal for SMC. Many temperature control system are on off control systems and SMC does that naturally. As long as the SMC switching time is fast it should work well with only one problem. Dead time is a killer. When using a PID the gains can be reduced but that is not possible with SMC as it has no gains. To make SMC work with a dead time one must use a model. A Smith Predictor works well for this.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0