Weighing Control Algorithm
 

At work I'm a project tech for a chemical weighing system, it weighs up bags
of chemical according to the chemists recipes for mixing some 4 million
pounds of rubber per day. This program was written by Germans that do this
kind of thing full time, they are expert Siemens programmers but not
necessarily experts is controlling weighing systems.

The system we have is taught at 10 speeds and records the flow rate and
"infly" at each speed. The Infly is the amount the weight increases after
the dosing is shut off, it's "In flight" dropping onto the scale.

So, instead of teaching each chemical, I'm working on trying to come up with
a dosing algorithm that will learn as it is ran. So it runs on the slow
side, learns and runs faster on the next cycle, until it's going about as
fast as it can with the accuracy desired. I set up a program that mostly
monitors the system, it measures flow rate and takes the weight from the
time the dosing stops until the weighing controller sends a "StandStill"
signal.

So I measure flow and "infly" and calculate a "FlowMultiplier", InFly = Flow
X FlowMultiplie, and FlowMultiplier = infly/flow. My actual is
FlowMultiplier = (Infly/Flow + FlowMultiplier)/2, that amounts to the
average of the new measurement and the old measurement.

So it appears to work well except when there is a large change in flow, it
underestimates the infly, the weight is heavy and the operator has to scoop
some chemical out of the bucket. I'm experimenting now with some
exponential algorithms, flow^2 overreacts but flow^1.25 seems in the ball
park.

So infly is proportional to flow but doesn't appear linear, perhaps I need
an exponential calculation or maybe to pay attention to rate of change of
flow, trying to predict the acceleration or deceleration of the flow rate.

Perhaps PID control but there is a pretty good lag between a change at the
controller and a change at the bucket, half second or so lag.

I also thought of calculating a trajectory, maybe accelerate for a second,
and flow to the point to decelerate for a second, a control algorithm to
correct for error.

One problem is that operators are allowed to make settings but they haven't
been told what the settings are all about. I saw an operator set a station
to dose over 20 lbs in 500 milliseconds with 1.8% tolerance, it worked much
better after he set the time to 5000 milliseconds.

Thought maybe someone has some ideas for a control algorithm for this.
right now I'm estimating infly=flowmultiplier * flow^1.25 and FlowMultiplier
= infly/flow^1.25, it works ok most of the time but not enough reaction to
flow increases. For example if a flowrate of 1 lb/sec gives an infly of .55
lbs, 1.5 lbs / second might increase infly to 1.5 lbs. If it's stable, the
system learns and hits close every time.

RogerN

Weighing Control Algorithm
 

On 8/29/2013 5:52 PM, RogerN wrote:
At work I'm a project tech for a chemical weighing system, it weighs up bags
of chemical according to the chemists recipes for mixing some 4 million
pounds of rubber per day. This program was written by Germans that do this
kind of thing full time, they are expert Siemens programmers but not
necessarily experts is controlling weighing systems.

The system we have is taught at 10 speeds and records the flow rate and
"infly" at each speed. The Infly is the amount the weight increases after
the dosing is shut off, it's "In flight" dropping onto the scale.

So, instead of teaching each chemical, I'm working on trying to come up with
a dosing algorithm that will learn as it is ran. So it runs on the slow
side, learns and runs faster on the next cycle, until it's going about as
fast as it can with the accuracy desired. I set up a program that mostly
monitors the system, it measures flow rate and takes the weight from the
time the dosing stops until the weighing controller sends a "StandStill"
signal.

So I measure flow and "infly" and calculate a "FlowMultiplier", InFly = Flow
X FlowMultiplie, and FlowMultiplier = infly/flow. My actual is
FlowMultiplier = (Infly/Flow + FlowMultiplier)/2, that amounts to the
average of the new measurement and the old measurement.

So it appears to work well except when there is a large change in flow, it
underestimates the infly, the weight is heavy and the operator has to scoop
some chemical out of the bucket. I'm experimenting now with some
exponential algorithms, flow^2 overreacts but flow^1.25 seems in the ball
park.

So infly is proportional to flow but doesn't appear linear, perhaps I need
an exponential calculation or maybe to pay attention to rate of change of
flow, trying to predict the acceleration or deceleration of the flow rate.

Perhaps PID control but there is a pretty good lag between a change at the
controller and a change at the bucket, half second or so lag.

I also thought of calculating a trajectory, maybe accelerate for a second,
and flow to the point to decelerate for a second, a control algorithm to
correct for error.

One problem is that operators are allowed to make settings but they haven't
been told what the settings are all about. I saw an operator set a station
to dose over 20 lbs in 500 milliseconds with 1.8% tolerance, it worked much
better after he set the time to 5000 milliseconds.

Thought maybe someone has some ideas for a control algorithm for this.
right now I'm estimating infly=flowmultiplier * flow^1.25 and FlowMultiplier
= infly/flow^1.25, it works ok most of the time but not enough reaction to
flow increases. For example if a flowrate of 1 lb/sec gives an infly of .55
lbs, 1.5 lbs / second might increase infly to 1.5 lbs. If it's stable, the
system learns and hits close every time.

RogerN


Roger,
You need to give definitions of words used in your definitions!

It's been 40 years since my one class in operations research, but I
think you need to spend much more time in mathematically analyzing each
variable in the process and it's effect on each part of the remaining
process. You can't deal with a process like this by estimating that and
guessing at this.

You will end up with a big list of equations with a similar number of
variables.

Then you can think about doing some programming to implement the system
of equations.

Paul

Weighing Control Algorithm
 

As an old process engineer, i would take just the opposite approach.

i don't completely understand this process. Looks to me like a default
machine speed vs. batch weight equation could be empiracly determined.
Spend some time getting as good a curve as you can. The control PLC
would then just need to look at how much it missed by and adjust the
offset. I'd use a technique called exponetial smoothing to prevent the
control chasing itself. This is simpler to implement than it sounds.

My approach was always KISS (keep it simple stupid)

Karl

Weighing Control Algorithm
 

On Thu, 29 Aug 2013 19:52:19 -0500, RogerN wrote:

At work I'm a project tech for a chemical weighing system, it weighs up bags
of chemical according to the chemists recipes for mixing some 4 million
pounds of rubber per day. This program was written by Germans that do this
kind of thing full time, they are expert Siemens programmers but not
necessarily experts is controlling weighing systems.

The system we have is taught at 10 speeds and records the flow rate and
"infly" at each speed. The Infly is the amount the weight increases after
the dosing is shut off, it's "In flight" dropping onto the scale.

So, instead of teaching each chemical, I'm working on trying to come up with
a dosing algorithm that will learn as it is ran. So it runs on the slow
side, learns and runs faster on the next cycle, until it's going about as
fast as it can with the accuracy desired. I set up a program that mostly
monitors the system, it measures flow rate and takes the weight from the
time the dosing stops until the weighing controller sends a "StandStill"
signal.

So I measure flow and "infly" and calculate a "FlowMultiplier", InFly = Flow
X FlowMultiplie, and FlowMultiplier = infly/flow. My actual is
FlowMultiplier = (Infly/Flow + FlowMultiplier)/2, that amounts to the
average of the new measurement and the old measurement.

So it appears to work well except when there is a large change in flow, it
underestimates the infly, the weight is heavy and the operator has to scoop
some chemical out of the bucket. I'm experimenting now with some
exponential algorithms, flow^2 overreacts but flow^1.25 seems in the ball
park.

So infly is proportional to flow but doesn't appear linear, perhaps I need
an exponential calculation or maybe to pay attention to rate of change of
flow, trying to predict the acceleration or deceleration of the flow rate.

Perhaps PID control but there is a pretty good lag between a change at the
controller and a change at the bucket, half second or so lag.

I also thought of calculating a trajectory, maybe accelerate for a second,
and flow to the point to decelerate for a second, a control algorithm to
correct for error.

One problem is that operators are allowed to make settings but they haven't
been told what the settings are all about. I saw an operator set a station
to dose over 20 lbs in 500 milliseconds with 1.8% tolerance, it worked much
better after he set the time to 5000 milliseconds.

Thought maybe someone has some ideas for a control algorithm for this.
right now I'm estimating infly=flowmultiplier * flow^1.25 and FlowMultiplier
= infly/flow^1.25, it works ok most of the time but not enough reaction to
flow increases. For example if a flowrate of 1 lb/sec gives an infly of .55
lbs, 1.5 lbs / second might increase infly to 1.5 lbs. If it's stable, the
system learns and hits close every time.

RogerN

Can't help with the algorithms, but would it be possible using VFD's to
ramp down the flow when stopping to make the infly more manageable?
The VFD's for each part of the machine could be tied together electrically
to follow the leader.

basilisk

Weighing Control Algorithm
 

"basilisk" wrote in message
...

On Thu, 29 Aug 2013 19:52:19 -0500, RogerN wrote:

snip

Can't help with the algorithms, but would it be possible using VFD's to
ramp down the flow when stopping to make the infly more manageable?
The VFD's for each part of the machine could be tied together electrically
to follow the leader.

basilisk

I thought about trying something like that, seems that as the speed
approaches zero, the infly would approach zero. The auger / screw dosing
stations are currently using a coarse and fine speed, they run on coarse for
a certain % of the weight, then run fine for a few seconds, the target
weight is easier to hit at the slow speed. The vibratory feeders have
problems if you change speeds, at different speeds, they feed a different
depth of chemical in the vibrating troughs. Running coarse and fine on
vibratory feeders causes waves in the chemicals, causing the rate of feed to
go up and down, hard to predict infly.

Today I tried an experiment using rate of change of flow, I took the flow
from the most recent 0.2 seconds and compared to the previous 0.2 seconds,
to see if flow is increasing or decreasing. I didn't get time to come up
with anything to compare and see if it predicts infly better than flow
alone.

RogerN

Weighing Control Algorithm
 

"Karl Townsend" wrote in message
...

As an old process engineer, i would take just the opposite approach.

i don't completely understand this process. Looks to me like a default
machine speed vs. batch weight equation could be empiracly determined.
Spend some time getting as good a curve as you can. The control PLC
would then just need to look at how much it missed by and adjust the
offset. I'd use a technique called exponetial smoothing to prevent the
control chasing itself. This is simpler to implement than it sounds.

My approach was always KISS (keep it simple stupid)

Karl

On what I did, I calculate the new value + the old value then divide by 2,
making 50% correction, keeps it from chasing its tail too much.

Sometimes the flow speeds up, the calculations evidently aren't linear, if
it keeps feeding at this higher flow, it learns and works fine, but it
speeds up and slows down. I'm trying a rate of change of flow,
acceleration, to see if I can hit the target better.

RogerN

Weighing Control Algorithm
 

On Fri, 30 Aug 2013 21:48:55 -0500, "RogerN"
wrote:

"Karl Townsend" wrote in message
.. .

As an old process engineer, i would take just the opposite approach.

i don't completely understand this process. Looks to me like a default
machine speed vs. batch weight equation could be empiracly determined.
Spend some time getting as good a curve as you can. The control PLC
would then just need to look at how much it missed by and adjust the
offset. I'd use a technique called exponetial smoothing to prevent the
control chasing itself. This is simpler to implement than it sounds.

My approach was always KISS (keep it simple stupid)

Karl

On what I did, I calculate the new value + the old value then divide by 2,
making 50% correction, keeps it from chasing its tail too much.

Sometimes the flow speeds up, the calculations evidently aren't linear, if
it keeps feeding at this higher flow, it learns and works fine, but it
speeds up and slows down. I'm trying a rate of change of flow,
acceleration, to see if I can hit the target better.

RogerN


Another way to state what you did:
alpha= exponetial smooth value = 0.5

new run average reading = alpha*last reading + (1-alpha)*run average
reading

Do it this way and play with values of alpha. You can even change
alpha on the fly if you need more response during startup, then very
stable after some run time.

Karl

Weighing Control Algorithm
 

weight is easier to hit at the slow speed. The vibratory feeders have
problems if you change speeds, at different speeds, they feed a different
depth of chemical in the vibrating troughs. Running coarse and fine on
vibratory feeders causes waves in the chemicals, causing the rate of feed to
go up and down, hard to predict infly.
....

Ah, you bring back memories. I used to work with cellulose acetate
flake. Couldn't use air to move it - explosive that way. Augers didn't
work, it would just compact. Vibrating troughs was the only way.
management wanted to speed up. Very hard to speed up a trough without
just building another. We were doing about same thing you are, mixing
acetate, plastisizer, several small ingredients, then running through
a pelletizer. Last improvment I worked on was going direct from raw
material to extruded film. You know the product, that roll of magic
tape on your desk. The factory I worked in averaged 1,000,000 finished
rolls of tape packed out every day.

karl

Weighing Control Algorithm
 

I've been calculating values for cut off points for the weighing controller,
yesterday I started working on a speed controller for the dosing weights.
It still has some bug but I made some changes to try out Monday if I get a
chance.

Today they were running a recipe that uses 8 of the 9 dosing bins on the
line. This run is normally difficult because if any bin messes up, the
operator has to scoop some chemical out of the bucket. It's bad enough just
running 3 or 4 chemicals, a major headache to run 8 chemicals. The
supervisor said about the best time they ever get on that recipe is around
24 seconds with a lot of operator intervention required. So I enabled my
controller to take over the dosing control, one bin at a time. I didn't
have it installed yet on bin 6, and bin 1 had a low weight that my
controller didn't adjust to right away, so I shut that one off.

My controller was controlling 6 of the 8 bins and we were getting 17 -18
second cycle times and operator intervention was rare, mostly only when a
bin ran empty and the operator had to refill a bin. The result was faster
dosing and more consistently in tolerance.

The problem with the bin with the light weight is that I had if the flow
rate is less than 50% of desired flow, it speeds up at 2% per second, if
it's above 50% and below 90%, speed increases 1% per second. This worked
fine for most except for the light weigh (0.452 lbs). So now I have set it
for .2% per second per lb, so a 10 pound set point increases at 2% per
second, one pound at 0.2% per second, and so on. Now the correction is
proportional to the weight amount.

Now I need to make a way for the operators to be able to turn my controller
on or off, now I do it manually from the program and it's working ok, but no
one knows how to disable it if there is a problem where it should be shut
off. There is a time setting for the existing controller, I thought maybe
make it so they enter a specific time to enable my automatic controller.
They normally use something like 5000 for 5 seconds, if it runs too slow or
too fast, they adjust up or down to try to speed it up or slow it down.
Note a 5 second set point on the OEM's controller means they pick a speed
that they hope it runs at the correct rate. So I thought about make it so
they enter some number like 5001 and my controller would enable.

The problem is that the way they complicated things, the address of the time
setting number is determined for each run, it matches the chemical from
taught data and the time settings are stored their, at one of 400 different
locations depending on where the data for that chemical is stored. So to
use that I'll have to search the array of data structures to find the
chemical match and then look at the coarse dosing time field in that
location.

Anyway, so far the bottom line is that it has ran better than that recipe
has ever ran before and there is still room for improvement! Much more
trial and error to come.

RogerN

Weighing Control Algorithm
 

On my weighing control, it learns by calculating it's previous error and
using a percentage of correction in the next calculation.

So now I use InFly = (Final Weight) - (weight when dosing is stopped)

FlowMultiplier = InFly/Flow (for 50% correction I actually use
FlowMultiplier = (FlowMultiplier * 0.5) + (InFly/Flow * 0.5) )

Estimated Infly = Flow * FlowMultiplier

I noticed the actual results don't work so well with different flow rates,
the flow multiplier changes with different flow rates.

So, since flow is a rate, and there is a little infly at 0.5 lbs/sec but
much more at 1 lb/sec. I thought maybe this would better be calculated like
you calculate braking distance in a car. You travel a lot further braking
from 60-30 then you do from 30-0.

So messing around with the formula and using a learned multiplier instead of
coefficient of friction and gravity, I came up with

Estimated InFly = (Flow**2)/(2 * Constant)

and Constant = ((Flow**2) / (InFly)) /2

I went to test this out, just watching the calculations to see if the new or
old formula best predicted the actual infly weight from flow rate. They
didn't run the line I was testing on very much so I didn't get a good test.
I'm wanting to see if the "constant" stays close to the same value at
different flow rates. If so, I hope to keep it in tolerance at slower and
faster flow rates.

I also added in where it will record the last 20 final weights, I can then
try to do machine capability calculations (CM and CMK) on my data. And this
will be used to adjust dosing control algorithm to try to achieve better
results.

Next I'd like to try to ramp the speed down, as flow approaches zero, infly
should approach zero, all as error approaches zero.

RogerN