Weighing Control Algorithm

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

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

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

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

...

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

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

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