Weighing Control Algorithm

At work we have a system that feeds chemicals into bags in buckets on load cells to weigh out a certain amount of each chemical according to the Chemist's recipes.

We have feeders using vibratory drives and augers with AC variable speed drives.

On augers, we use a coarse and fine dosing. On the vibratory feeders, when it goes into fine dosing, the product feeds out of the vibrating trough faster than it feeds from the bin to the trough, this makes a thin spot in the chemical. So after several cycles on a vibratory bin, you can see waves in the chemical level, thinner where it fine dosed, thicker where it coarse dosed, this created uneven feeding, so we dose all at one speed. This makes the flow more consistent but it's hard to hit tight tolerances.

I'm trying to come up with an algorithm that hits tighter tolerances than the current system.

Currently they stop feeding at the set point - "in fly" and it works OK but not real accurate.

I wrote a routine to take the weight every 40 milliseconds and I calculate the flow based on the last 10 readings, 0.4 seconds. I'm trying to closer estimate the "in fly" amount as a function of flow, figuring if there is more flow, there should be more chemical "in flight". Basic calculations show it's not linear, I thought since flow is a rate, it may be the same formula as braking distance for a car, minus the reaction time, friction, and gravity parts.

I'm thinking that slowing from 2lbs/sec to 1lb/second will flow out more chemical just like braking from 60 to 30 mph takes more feet that slowing from 30 to 0 mph.

If I can get a formula that works for different flow rates, then I can better estimate the point to stop dosing and get fewer out of tolerance after a recipe change with a different set point.

Next, even if I get that closer, there is still too much variation from one time to the next. I'm thinking about, instead of feeding and then stopping, ramping down at a controlled and corrected rate. The idea is that as flow approaches zero and error approaches zero, infly should also approach zero. So maybe after we coarse dose maybe 80-90%, switch to ramping to set point and correct on the way.

BTW, we're using Siemens controls running on a MicroBox Industrial PC. The language I'm using for this part is SCL, a high level text based language similar to Pascal. It seems better for this type of thing than STL, Ladder, and function block diagrams.

Any ideas?

RogerN

Reply to
RogerN
Loading thread data ...

Presumably, you *have* actual data from each "dispensing" (else you wouldn't tell us that it "is not real accurate". And, you are ALREADY implementing some sort of control on the feeds (so, each "dosage" *should* be identical -- subject to the variations in your controls AND your physical process).

The fact that you are seeing variations beyond what you would (ideally) like implies that your controls and/or mechanism are the problem. (I assume the excipients don't vary much in the short term... granularity, moisture content, etc.)

So, what have you done to *measure* the performance of your control system? I.e., how do you decide when to "stop"? How does this decision correlate with "reality"? I.e., does the data on which you are basing your "stop decision" have some (variable?) latency in it? Does your control system have deterministic behavior (does it always take the same amount of time to come to a decision)? Do the mechanisms/actuators always react the same way?

I.e., *where* is the variation being introduced? Until you know that, you can't reliably approach a refined solution (at least not without terribly overdamping the control loop)

But can you *actually* control the rate of flow that well? Just because you can adjust the speed of the drives doesn't mean that will directly be reflected in the flow of the material!

Measure, first -- so you know where the problem lies.

If an automobile driver experiences lots of rear-end collisions (i.e., where *he* hits the back end of the car in front of him), the cause might be worn brake shoes/pads. Or, air in the hydraulic system. Or, excessive speed. Or, "following too close". Or, slow reaction time. Or...

Before I'd have the driver examined by a doctor ("slow reaction time") I'd want to know if it wasn't, instead, just "worn brake pads"!

Reply to
Don Y

Thanks for lots of good advice it sounds like to me.

My program runs immediately after the original program that runs every 20 milliseconds. At first all my program did was take data, at the time the feed is stopped, I take the weight and flow at that moment, then I take the weight again after the scale gives a "Stand Still" signal, meaning no movement > 0.002 lbs in 2 seconds.

Currently I use the measured "InFly" (Final Weight - Stop Feeding Weight) and Flow to calculate a "Flow Multiplier". Then I use my "Flow Multiplier" to calculate an "Estimated Infly".

For correcting the "Flow Multiplier" I use half the previous value plus half the newly calculated value. It helps keep it from chasing its tail so much.

So here's some idea, they may be doing a 3.00 lb weighing and the dosing may stop before 1.5 lbs, meaning they are depending on more than half the weighing to flow after it's stopped. This is using the original control, not the new stuff I'm working on, mine doesn't allow the operator to select

500 millisecond dosing time! The machine spec they want is 20 seconds per batch so we don't need half second dosing times.

My (Flow * Flow Multiplier) learns any setting but the Multiplier value changes too much with changes in flow. This becomes a problem when learning a new flow rate, I start at a low flow and increase speed until the calculated flow is reached, sometimes this takes multiple batches to learn the correct speed. So as the speed is changing to reach the desired flow, product weight is out of tolerance until it runs constant speed and the correct flow multiplier is learned.

What I have done so far has helped, I enabled my controller on a run that was taking 24 seconds per batch with quite a few out of tolerance weighing's, my controller ran it at 17 seconds per batch with fewer out of tolerance weighing's. Out of tolerance means the operator has to go and scoop some chemical out of the bucket to get it in tolerance, slows them down quite a bit.

I also measure acceleration at stop, taking the flow from the last 0.2 seconds and from the 0.2 seconds before that and calculate how much it's accelerating or decelerating at the moment that chemical feeding has stopped, it helps but not as much as I had hoped. I think we need to flow slow enough at the stopping point in order to hit a smaller target.

RogerN

Reply to
RogerN

Could you choke the output to the vibrating chute to produce a more uniform flow ?

Reply to
Rheilly Phoull

Things that you're saying don't seem consistent -- I'm not sure why that is, probably just that it's a complex problem.

If the stuff is falling a constant distance, and if the flow is accurate, and if it's coming off of the feeder at the same velocity all the time, then the flow multiplier should be a constant. Basically, there should be a constant delay between a change in feed rate and the flow at the scale. So at least one of those three preconditions isn't being met in the real world.

Understanding what the actual physics of the problem is may be a help to understanding why your collected data does not meet your assumptions.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

Yes, I put it on the PM list to make some kind of baffle at the end so chemical doesn't feed unless it's vibrating hard enough to feed from the hopper. The vibratory bins feed real nice when they are slowed down. The augers seem to feed heavy when the blade comes around, they have wires trying to break it up to flow more even and it helps some, still not as even as vibratory bins.

The program runs 50 times per second so I'm thinking if I can get the flow below 5 * tolerance per second, each pass should be no more that 1/10 of the tolerance, should be able to hit good almost every time.

RogerN

Reply to
RogerN

How about slowing the feeder (gradually) down when you are about to hit the desired weight?

--
Failure does not prove something is impossible, failure simply 
indicates you are not using the right tools... 
 Click to see the full signature
Reply to
Nico Coesel

Let's back up. I'm sure everything "makes sense" to you -- as it's *your* system that you are working on! But, I'd like a better picture of what your controller actually can *see* and

*do* (sensors and actuators).

I *think* all you can "see" is the output from a "scale" (to be colloquial). It presumably provides you with a weight and some indicators -- one of which is "in motion" (what you call "stand still"... i.e., when the scale thinks the weight reading has "settled" and is no longer in fluctuation).

You appear to be computing the *rate* of flow (mass per unit time) by noting differences in the weights reported by the scale and normalizing to some timebase.

But how do we (i.e., *you*) know that this criteria makes sense? I.e., if you are measuring *tons* then this is probably an overly conservative criteria for the weight "settling". OTOH, if you are measuring milligrams, it's useless! :> (I am exagerating to make my point -- what sort of numbers are you *really* seeing?

You are also ignoring lots of "little details" that can have a huge effect on tuning your control algorithm.

I.e., the weighing platform has some dynamics associated with it. If you dropped a 100.0000000 lb weight on it, the "load cell(s)" wouldn't *immediately* report 100.0000000 lbs. (if you hooked a 'scope to the load cell(s) output "under excitation" you wouldn't see the output go from '0' to '100.0000000' as a clean step function!)

Similarly, the indicator (electronics that excite and monitor the load cell(s) and report weights to "you") has some dynamic characteristics. Chances are, the load cells feed an integrating converter that takes a fair bit of time to come up with a "reading" (aka "weight"). This may be tens per second or as few as a handful per second -- depends on the indicator's hardware and firmware.

Then, there is a transport delay as the "reading" is reported to your "PC" (serial port?) -- probably 50-100 characters in that "report" at 1200, 2400, 9600, etc. baud?

And, some amount of time for the report to filter up through the drivers and operating system to *your* "software".

All of this time, the Real World marches on -- excipients are still flowing onto the scale and you won't know about this for a similar amount of time/delay.

Now, you claim to "take the weight and flow at [the moment the feed is stopped]". Yet, the indicator/scale isn't really sure of the data that it is reporting to you AT THAT TIME (i.e., the scale is still "in motion", the indicator is still *integrating* signals from the load cells, etc.). So, you have no idea what that number actually *means*! It's *probably* safe to assume "there is AT LEAST this much material on the weighing platform". But, how much MORE than that is unknown -- unless you could force the scale and mechanism (and flow!) to settle on an accurate reading, "on demand".

[Remember, I don't know what sorts of quantities and times you are talking about so you will have to evaluate this in the context of *your* application...]

To get a feel for what I am saying, stand near the "dispenser" and, AS SOON AS the feed is turned off, put a bag or a piece of cardboard or some other sort of DIVERTER between the flow and the scale so that NO MORE material reaches the weighing platform (i.e., even the stuff "in flight"). If the "when feed is turned off" reading differs from the "final" reading, then the difference shows you how far out of touch with reality your "feed off" reading is (because you deliberately prevented any additional material from reaching the scale so that "feed off" reading should "agree" with the "scale settled" reading that you will harvest shortly thereafter, right?

I.e., if there is ANY difference, then this acts like an error in your "in flight" mass/weight calculation.

Yikes! So, there is a long "transport delay" between the "feed control" and the "output".

[Hint: (almost) all delays are "bad" when it comes to control systems]

Again, figure out what your *real* signals are before you start "playing" with control algorithms. If you don't know what you are measuring, any *apparent* improvements can be purely illusionary; you may discover that changing *anything* in the process causes what looked like "ideal" control to look like total *crap* (because it was just "coincidence" and not "control")

Reply to
Don Y

the flowing substance will impart an impulse on the scale making it read high by g * time_spent_falling

--
?? 100% natural 

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Reply to
Jasen Betts

The mechanical system was designed by Zeppelin, the Hindenburg company, and the controls were designed and programmed by Futronics. This is the first system like this that they did so it's a bit less refined than their later models.

The scale module is a Siemens Siwarex FTA weighing module with 24 bit A/D and communicates by Profi-Bus at 1.5M baud IIRC.

I record the weight every other pass, every 40 milliseconds so that 10 weighings cover the last 0.4 seconds.

The load cells are 30 Kg, the empty bucket weighs around 14.7 lbs, the maximum weight dosed in a bucket is 28lbs, if it goes over that, they break it up into more bags. The 30Kg load cell has an output of 2mV/V and the weighing module provides 10V excitation.

Profi-Bus at 1.5M minimum, up to 12M, it's been a while since I looked up the baud rate on the hardware configuration.

It's been a while since I looked at the scan times. We are operating from Siemens OB37 20 MilliSecond Object Block.

My program runs immediately after the original program, so as soon as his tells the controller to stop, I'm on the same program scan where the original program said "Stop". I'm sure there is some lag in it.

Quantities range from around 0.141 lbs up to around 25.0 lbs for a single station. Seems most are in the 3-8 lb range.

The auger bins have a door that closes when the motors are shut off, it stops the flow but the inflight is what's in the air. Also, product hitting the pile in the bucket has to decelerate and settle, it shows up as a moment of negative flow as dosing is stopped.

IIRC the flow was around 4.5 lbs/second, way to fast to be trying to weigh 3 lbs. The operator knows if they want it to run faster, put in a smaller numbers, if it overweighs too often, punch in bigger numbers.

Definitely!

I know there are time delays involved and that is why I'm thinking about ramping down at the end of dosing. The lower the flow, the less difference there is between stop dosing weight and final weight.

They would like CM's and CMK's of around 1.67 for 1% tolerances, this is hard to hit when they are dosing in at one speed and trying to feed at coarse speed without slowing for final.

RogerN

Reply to
RogerN

You have HISTORY! What a luxury! Log all that data, not looking for ANYTHING initially. Think in terms of empirical curve fitting, as in, don't know why, just works.

You probably have access to Matlab, if you don't, I suggest the free clone octave. Take all your data of past performance and fit your models there. I'll bet your best control algorithm will 'magically' appear.

Reply to
RobertMacy

I think that's the way to go. If it adds a few seconds it should be OK since they won't need to make as many manual adjustments, scooping chemical out of the bucket.

RogerN

Reply to
RogerN

That's certainly a necessary step. You had mentioned something that I interpreted as meaning that you just had two speeds available -- otherwise I'd have said something!

--
Tim Wescott 
Control system and signal processing consulting 
 Click to see the full signature
Reply to
Tim Wescott

Thank goodness someone mentioned this. I'm not sure this is the problem or not, but it certainly is a factor in the load cell reading.

George H.

Reply to
George Herold

Roger, you may be able to do this job adequately with a PID controller, or a PID controller equipped with a hard shutoff when the target weight is either reached or approached (from the bottom).

A PID is by no means the _best_ way to do it, but they're ubiquitous, and sometimes they're valuable just because you can tell someone "I control this with a PID" and satisfy their daily required intake of buzzwords.

A better method would be to constantly estimate the amount of material in flight, and wrap a PID around that estimate, but it sounds like that approach is pretty complicated in your case.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.