I'm going to assume that you have some sort of auguring system: a screw that rotates to drop the food in the bag. But it could be a paddlewheel or other arrangement. What you want to do is run the drive at a fixed speed, count the rotations, and then calculate how far you're off. This is akin to celichi's "Spill" method.
Let's say that your target is 500g, which you guestimate will be 100 revs, for an initial ratio of 5 g:rev
The first bag gets filled after 100 revs. Let's say that the checkweigher says that it's got 525g in it. You calculate that, had you gone 100/500 * (525-500) = 5.0 fewer rotations, or 95.0 revs, you would have it hit the mark.
But there's variability in each run, so instead of taking off the whole 5.0 off of the 100, you take only maybe 20% (or 15 rev) of it.
So now the system thinks 500g = 99.0 revs.
Next bag, the augur turns 99.0 revs, and the checkweigher reads, perhaps 515g. Again, you adjust the rotations by 20% of the error, to get:
99.0 - [99.0/500 * (515-500) * 0.20] = 98.4 revs.
And so on. With each bag, the number of revs dials in to where it needs to be.
You can embellish this system by having deadbands, so that if you have too small of a difference, you don't bother to calculate a new g:Rev ratio, because you're "close enough". Likewise, if the bag weigh it WAY out of spec, something went badly wrong, and again, you ignore its influence on the g:rev ratio.
You can get fancy, and run the drive at a high speed (for throughput -- as rdrast suggested) then at low speed for accuracy (per Parky).
You can make adjustments to the ratio up faster than down (30% instead of 20%), because customers don't mind getting extra, but hate being cheated. Or the other way, because of corporate bean counters.
Measure rotation rather than time if you can. It's way more accurate / consistent.
If your checkweigher is way downstream of the filler, so that there are more than one bags which have been filled before the checkweigher can adjust the g:rev ratio, then use a FIFO to track the ratio that the bag was using when the checkweigher makes its adjustment. Also make the % adjustment smaller, since several bags will have not have found the "sweet spot" yet, and you don't want to over-compensate. In this way, what I'm describing is kinda like a PID, adjusting a CV (the ratio) by a fudge factor of the error, over time.
Because you are working with a weight:revs ratio, if you change the setpoint (for a different product / carton size), your program remains unchanged. If the dynamics of the product are dramatically different, the system is still self-adjusting and will find the right ratio.
Of course, it could be nice to store the ratio with the "recipe" for the product for next time. There's all sorts of ways this system can be embellished and improved upon. Bells and whistles galore!
