View Single Post
  #4   Report Post  
Posted to rec.crafts.metalworking
basilisk[_2_] basilisk[_2_] is offline
external usenet poster
 
Posts: 553
Default 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