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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 8/29/2013 5:52 PM, RogerN wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Karl Townsend" wrote in message

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Thu, 29 Aug 2013 19:52:19 -0500, RogerN wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"basilisk" wrote in message

<snip>

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

...
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.