Just wondering about weighing hoppers

[cjd1965]

on a slightly change...these manufacturers usually target the lower tolerance of the product weight to achieve maximum output of products for the least amount of raw materials

 

[Doug-P]

For the interested

Some searching has produced this - these machines are known as multihead weighers, or selective combination weighers.

A .pdf http://www.packaging-machinery.net/pubs/pdf/MU-2005-May-weighing.pdf

Wikipedia item http://en.wikipedia.org/wiki/Talk:Multihead_weigher

Ishida videos http://www.ishida.com/technologies/ccw_principal/ They invented this machine.

It appears genetic algorithms may be involved. http://mathworld.wolfram.com/GeneticAlgorithm.html

 

[ASF]

Multi-Head Weighers and Form-Fill packing machines are a mainstay of the global food industry and are very complex very high speed systems which have to meet all sorts of regulatory as well as engineering standards. Almost all of the machines I have worked with come from a couple of Japanese companies and use custom embedded control systems. I have never seen a multi-head machine controlled by a conventional PLC though it may have been done. Bear in mind that the control system handles the product distribution as well as the weighing functions and there can be very large numbers of individual weighing pans on a single machine which can be carrying out weighing operations at rates of more than one a second.

That's the sort of answer I was hoping for, one backed up with field experience

And yes, I've seen a few of the Ishida's in action filling bags of chips (or crisps for you americans ). Impressive to watch but I've never had the opportunity to take the covers off one and delve into how it works. Which I guess says something about their reliability.

 

[shooter]

chips have a big problem as they fall slowly, simpler is potatoes, they go like a rocket. 5 kilo bags with <0.5% off setpoint, and the sealer can not go any faster. 150/minute.
only MARS bars go faster (1000/minute)
as you want the sealer go steady pace, the weigher only stops the sealer when weighing fails.

For sweets with same weight, it just 'counts' by weighing.
so scale 1 has 4 candys in, scale 2 has 6, scale 3 has 5 etc.
so it counts the number and drops the precise needed number.
If it can not make the count, the sealer stops (it is not closing the sealer) a sideshute is opened, and the weigher needs sometime to fill all scales again. (so the sealer passes several times)
The sealer is PLC operated, and the weighing scale tells the PLC to skip or seal (a simple contact)
the sealer tells the weigher to drop next also with a simple contact.
nothing fancy.
I had to change a simple relais contact with a electronic one as it was just not fast enough.

weighing algorithme is a fancy piece of software as it has filters, and some are not weighing the product, but take the speed of change to get the value. It looks in software like a damped spring system.

 

[matthew1]

My question is, what's the algorithm to do this?

Thanks

I think it has been established that the calculations and algorithms are carried out in a embedded micro controller. regardless of brand Yamato, Ishida, Eagle, Multiweigh, or CFS( the last two are german made ). There are several applications that will change your weighing algorithm. I do not know the specific code that make the algorithm of course, but I may be able to add to the information already posted.

The algorithm is dynamic in that it adapts to the user program. The type of bucket configuration, scale configuration, bucket size and collating chute make the most difference on how the machine weighs. If the machine is a 14 head scale no memory bucket and standard chute 2 litre series size and you are trying to weigh a 400gr combination. It is weighing 4 possible combinations at the same time. It should only use a certain number of buckets per combination depending on the speed you are trying to run and the accuracy you are trying to achieve. The second being the most important. With a 14 head scale you want to target 4 buckets per cycle. That is controlled by how you feed your product. This can be set with rigid parameters that don't change or can be configured in a cascade PID control scheme that ties back into the individual bucket weights. (with one certain manufacturer anyway). As for overweight buckets you can choose for it do drop and start over or to stop and have an operator clean them out.

All in all multihead data weighers are amazing machines. Each bucket actuator has a microcontroller that talk over a network to the main controller that makes the final decision making per your program settings. There are several different algorithms but they are mostly selected during installation. There are also EU weight and measures algorithms that can be used but they are not legal in the US.

Multi-Head Weighers and Form-Fill packing machines are a mainstay of the global food industry and are very complex very high speed systems which have to meet all sorts of regulatory as well as engineering standards. Almost all of the machines I have worked with come from a couple of Japanese companies and use custom embedded control systems. I have never seen a multi-head machine controlled by a conventional PLC though it may have been done. Bear in mind that the control system handles the product distribution as well as the weighing functions and there can be very large numbers of individual weighing pans on a single machine which can be carrying out weighing operations at rates of more than one a second.

This is 100% correct. I also agree that a conventional PLC control might have been done. Personally I do not think the accuracy and speeds would be close to the proprietary systems. Compared to micro controllers PLC's are very slow and slow even more crunching complex math. Ethernet is also slow compared to a device level ring like canbus or ARCNET. There is a lot of latency with CSMA/CD even if you are running half duplex at 1Gbit/s there will still be bottle necking at the switch with up to 32 devices.( A 32 head scale is the largest I have seen.) This is just my opinion, could it be done of course would it be as efficient doubtful.

hope this helps,

Matthew

 

[sparkie]

We work with a LOT of scales at work, with varying sizes, static and monorail. Every single one of our scales uses an embedded micro-controller in the scale head to handle both weight, settings and the actions (such as outputting the weight over a network). Of course there are other electronics to handle those tasks, the micro-controller tells each component when to do its job.

When dealing with electronic scales, small things like noise can easily become a problem. I would rule out the use of FPGA's either though, they are very fast and flexible, not to mention being full-duplex systems they can change outputs and read inputs at the same time and would be perfect for this sort of application.

Just so you know though, I've only been in the field a few months, so take my statements with a grain of salt.

 

[Doug-P]

Thanks for all the great replies! This thread has certainly turned up some interesting info.

 

[CapinWinky]

I've programmed multi-head weighers and created my own recursive function in ANSI C to do it, though it would be possible to make it non-recursive and do things long hand with FOR loops easily enough (at the cost of processing power). My algorithm works for any number of heads, but the more heads you have, the more possible combinations to check. My program runs on a standard B&R PLC from 2007 and handles 24 head combination scales for a major packaging company at a cycle time of 4 dumps per second. When put on their fastest PLC from last year, it could get the cycle time down less than a hundredth of a second (much faster than the vertical baggers it goes on). So yes, these are run by PLCs these days to great effect.

Lets say you have 24 heads on the weigher (16,777,215 possible combinations of any number of buckets) and they are set to shoot for 20% of the total bag weight (average 5 buckets to get final weight). A vibrator or something starts filling buckets and when they get close to their 20% target, the top gate closes or whatever to stop more product going in. You can end up with buckets with next to nothing in them or really over full ones with like 70% final weight in them. You specify that it will take between 3 and 7 buckets to fill a bag to cut down on combination permutations and you start generating the weight of every possible combination of 3 to 7 buckets to see which one is the lowest that still meets the minimum. Bucket 1, 2 and 3? Too light. Bucket 1, 2, 3, and 4? 3 grams over. Etc.

So yes, good scales are brute force calculating thousands or even millions of possible combinations to pick the best one. The trick is paring things down to speed up the algorithm. You do things like knowing that bucket 1 + bucket 5 is already heavier than your best combination so far, so no need to check any other combinations that contain buckets 1 and 5. Of course, saying up front to only check combinations with 3 to 7 buckets instead of all possible combinations can cut things down a lot, especially if that range isn't near half your sample size (for a 24 bucket head, there are only 24 combinations of 1 bucket and 1 combination of 24 buckets, but there are 2,704,156 combinations of 12 buckets).

You also can show preference to buckets that haven't been used in a while or buckets that are really far off from the 20% they were supposed to contain. This prevents you ending up with buckets that never get dumped for a combination and the product in them going stale or whatever.

The most challenging thing is being very efficient with your program, since the same bit of code is going to run thousands of times. If you are able to remove a single multiplication step, you can save a noticeable fraction of a second.

 

[Doug-P]

When put on their fastest PLC from last year, it could get the cycle time down less than a hundredth of a second (much faster than the vertical baggers it goes on). So yes, these are run by PLCs these days to great effect.

Zounds!

So yes, good scales are brute force calculating thousands or even millions of possible combinations to pick the best one.

I expected it would be something complex. But then, it is complex in its own way. I suppose the old saw 'quantity has a quality all its own' applies.

 

[matthew1]

Good information to know. I always forget that there are processors out that cruch C.

I've programmed multi-head weighers and created my own recursive function in ANSI C to do it, though it would be possible to make it non-recursive and do things long hand with FOR loops easily enough (at the cost of processing power). My algorithm works for any number of heads, but the more heads you have, the more possible combinations to check. My program runs on a standard B&R PLC from 2007 and handles 24 head combination scales for a major packaging company at a cycle time of 4 dumps per second. When put on their fastest PLC from last year, it could get the cycle time down less than a hundredth of a second (much faster than the vertical baggers it goes on). So yes, these are run by PLCs these days to great effect.

Lets say you have 24 heads on the weigher (16,777,215 possible combinations of any number of buckets) and they are set to shoot for 20% of the total bag weight (average 5 buckets to get final weight). A vibrator or something starts filling buckets and when they get close to their 20% target, the top gate closes or whatever to stop more product going in. You can end up with buckets with next to nothing in them or really over full ones with like 70% final weight in them. You specify that it will take between 3 and 7 buckets to fill a bag to cut down on combination permutations and you start generating the weight of every possible combination of 3 to 7 buckets to see which one is the lowest that still meets the minimum. Bucket 1, 2 and 3? Too light. Bucket 1, 2, 3, and 4? 3 grams over. Etc.

So yes, good scales are brute force calculating thousands or even millions of possible combinations to pick the best one. The trick is paring things down to speed up the algorithm. You do things like knowing that bucket 1 + bucket 5 is already heavier than your best combination so far, so no need to check any other combinations that contain buckets 1 and 5. Of course, saying up front to only check combinations with 3 to 7 buckets instead of all possible combinations can cut things down a lot, especially if that range isn't near half your sample size (for a 24 bucket head, there are only 24 combinations of 1 bucket and 1 combination of 24 buckets, but there are 2,704,156 combinations of 12 buckets).

You also can show preference to buckets that haven't been used in a while or buckets that are really far off from the 20% they were supposed to contain. This prevents you ending up with buckets that never get dumped for a combination and the product in them going stale or whatever.

The most challenging thing is being very efficient with your program, since the same bit of code is going to run thousands of times. If you are able to remove a single multiplication step, you can save a noticeable fraction of a second.

 

[Kizilelma]

I wrote multihead weigher code for Mitsubishi FX5U PLC in ST Language. Can someone check it ? This is working in simulation with for loops

https://github.com/MrBrkers/Multihead-Weigher/tree/main

 

[drbitboy]

...Can someone check it ?...

Weigh_Algorithm.txt

• This subroutine does not exit when it finds a solution, so multiple solutions may be triggered on any one call.
• This subroutine does not test all combinations e.g. the sums of weights of the pair [0,9], or of the triple [7,8,11], will not be checked.
• Look up the knapsack problem; I think this is related to that, and there may be better algorithms available.
• This brute force O(N⁵) algorithm could almost certainly be improved upon
• Each sum could be calculated but once and incrementally at each loop level, instead of twice per IF comparison in the innermost loop, which would reduce the number of [+] operations by a few orders of magnitude.
• Sums that exceed the upper limit in outer loops before reaching the inner loops could be skipped.

Those last four items are only about efficiency; if there are no watchdog timeouts, then brute force may be okay.

 

[drbitboy]

https://en.wikipedia.org/wiki/Subset_sum_problem




https://en.wikipedia.org/wiki/Multihead_weigher


file:///C:/Users/drbitboy/Downloads...optimizationofthemultiheadweighingprocess.pdf

 

[drbitboy]

https://en.wikipedia.org/wiki/Subset_sum_problem


https://en.wikipedia.org/wiki/Multihead_weigher


https://www.researchgate.net/publication/304291607

 

[parky]

I worked closely with a well known weighing company, well a number of their engineers, you definitely need a fast process, indeed the last time I worked with them they were looking at prediction, i.e. the waveform from the locadcells something to do with predicting the final weight by the curve of the increase in weight, do not know the details of exactly they were looking at but one engineer told me it looked promising & would increase the speed they could operate at, the conversion speed of the signals was certainly above a normal PLC or for that matter many loadcells on the market at that time, for precise low weight accuracy. I have no idea if they ever achieved what they were working on but if they did I guess it would be kept close to their chest.