Hopper High/Low Priority Request Logic

I see a lot of replies here offering sujestions
there are many ways to to this job
If you still haven't gotten it working what is it worth to have somebody come in and do it with you so you can learn from the experance
you may want to reach out for some actual help

I sort of agree with Garys, the code shown seems to be over the top, yet again, I now remember a job I did many years ago, 8 hoppers on check weighers, one vibrating conveyor with sol operated shutes feeding them, it was an existing system, the program got so complicated I could not get my head round it. I had a meeting with the operations staff & we decided a re-write was in order, it turned out to be reasonably simple, starting with a shift register where the hopper number was fed into it, initially, if all empty, it was based on 1-8, an initial fill sequence based on that, however, after learning the ability of the feed conveyor to supply all 8 hoppers we plumped for low level or time fill, so once primed (time not high level) then it followed again the initial 1-8, if high level was reached then it moved on, should a low level be detected, this was sorted as first out in the shift register array, again based on time or high level which ever came first. this worked well, the reason for this was the weighers sometimes missed a drop this could be for a number of reasons, no tray, no correct weight to drop (note: multi head weigher so picks between 2-4 shutes for correct weight). yes I know that getting consistent feeds etc. is ideal but logistically on this system was difficult.
The time stamp factor was not needed as the time factor was it's place in the array OR the low level, it was possible that two or more would reach low level at the same time but unlikely, if it was then the priority would naturally fall to the scan of the logic, after all, even seconds difference is not going to matter.

parky said:

The time stamp factor was not needed as the time factor was it's place in the array OR the low level,

Click to expand...

Of course.


And the [timestamp,priority] pairs are an alternative to the two FIFOs, each with its own priority.

So in the [timestamp,priority] implementation, the two FIFOs are not needed and therefore eliminated, and with those gone there is also no need to remove a low-priority (75%) FIFO entry for a hopper if that hopper has a subsequent high-priority entry, which is what the OP was asking about in the first place.

The proof is in the pudding: without FIFOs, the logic was implemented in a baker's dozen of rungs, each of minimal to moderate complexity; with two FIFOs there are many more rungs, and much more complexity per-rung. I would say the FIFO approach is mostly more intuitive to understand, the exception being the logic that removes obsolete low-priority entries.

Comments will be crucial in either case.

That is using a fifo, however, there is also a priority i.e. assume no low levels and the fifo contained the order of filling should a low level be detected then the one with a low level will be sorted in the fifo to move it along the queue.
Then should any other reach low level this again is sorted until it falls behind the first detected low level
example:
order 031245678 no low levels
A low level is detected, i.e. 4 this is then sorted so we end up with
031256784
If another becomes low level i.e. 3 then sorted it becomes
012567834
So in effect you have a fifo where initially (prime at start up) the fifo is populated in order i.e. 1 to 8 (or what ever suits)
Then this continues to shift in a circular manner, if a hopper becomes low level this is moved to the front not by ring shifting but by sorting.
This works as I did it some 27 years ago.
The one thing that any engineer will face is designing code to a spec not very often will give the results in the real world. There are many factors that any engineer will tell you when commissioning come into play.
Some examples are the design of the system i.e. it's ability to move or transport substances, The substance it'self, a couple of examples are cooked rice or marinated meat. these are the most common factors that very often not completely consistent and never will be, take it from me, rice & meat will vary depending on many factors that are difficult to control.
So, Often once on-stite you have to do modifications to get round the variables, it is very rare that the system will perform as expected in an ideal world it would but we are in an industry where there is no unlimited budgets, rely on some others mechanical design & the type of product.
General forms that often can be controlled are things like oil, water, temperature etc. (in an enclosed system), food products are certainly more difficult, meat can vary in fat content or structure, yes it might be possible but the consumer will not pay double or tripple because it is easier for the manufacturer to handle.

parky said:

That is using a fifo

Click to expand...

Yes and no. My code may behave equivalently to two FIFO queues here, but only because it is modeling the same real-world system; specifically it is not a FIFO queue (no FFL or FFU or shifting COP or MOV instructions). It uses a static array where the each element always means the same thing; and the array is never sorted.

In a FIFO, it is the location of a value that indicates the value's priority; in this case the value represents the hopper number.

In my code, it is the value of the element that indicates the location's priority; in this case the location represents the hopper number.

With a (Rockwell) FIFO, the highest priority hopper number is always the value at location 0 of the array elements composing the FIFO queue data, so determining the next hopper to fill is an O(1) algorithm, while unloading an item from the FIFO queue is an O(N) algorithm.

With my code, the highest priority hopper number is always the location containing the lowest value, so there must be a complete search of the array to determine the next hopper to fill, which is an O(N) algorithm, while removing an item from the array is an O(1) algorithm.

So my code (insignificantly) slower in selecting and (insignificantly) faster in removing* an item from the priority array, with the benefit of removing the complexity of maintaining consistency between the dual-priority FIFOs.

* not the same as, but analogous to, FIFO queue unloading (FFU)

Yes I sort of agree, the original code I posted did not use an in-built shift/fifo but a loop, so in effect a hopper would be placed in the queue, a priority would be shifted down the queue so what would have been the first out of the array would depend on it's initial first in first out position but a low level priority would if you like grab those of lower priority & push them behind.
There are many ways to skin a cat, I visited the site that originally did the hopper feeds replacement some 2-3 years later (not on that project but a small new installation on a different area.), I inquired about how the other had been performing & no issues appart from some bozo changing the timing caused a problem, I noticed they had an almost identical line installed 2 years later, I was interested on how it compared, it worked just as well, I had the privilage to look at the code & the programmer used a different method, actually I was quite impressed & although no better or worse, if at the time I knew that direction perhaps I would have done it that way, the only real difference was the programmer had included a time proportioning on the hopper fills, this was a simple algorithm that would alter the time for deposit based on if a hopper reached low level more often, there was no analogue levels but had put on the HMI a simulated level based on time, not exactly accurate but gave a good indication of the actual hopper level.

Cool .

Lol,I like your caption 5, Yes there is no better way than practical experience, reminds me of two problems I was involved in, the first was rice, our new factory director (supposedly an engineer), asked me to look into a rice cooking process with him, the company was going through a crisis, there was a need to save money, rice is a difficult one originally, rice was cooked in vessels with agitators, the process required the rice & water (plus some other ingredients like oil or saffron depending on the type), the idea was to increase the yield by adding more water, this posed a problem as softer rice caused problems in metering into the trays at packing so we had a chicken & egg situation, occassionally, the customers would prefer a softer texture to an al-dente, getting the yied up would eleviate this, increase profit but caused major problems on final packaging weight. his brief to me was get the water ratio up, both the operators who were chosen due to their expertise on rice & myself argued the facts but we were told in no uncertain terms this is what he wanted, fine I calibrated the system, then came the problems, I discussed this with the team & we came up with the idea of going back to the original rice recipe & adding a metered spray of water to the final pack, this would be absorbed into the rice & when re-heated give the required texture & yield, worked well.
The other was a sauce, again we had an on-line meeting with the plant manufacturers, our CEO, Product development & production, particular sauces required cream, this is notoriuos in causing splitting especially when cooled to below 4 degrees, leaving splitting of the components & a grainy texture with oil bubbles, when re-heated it would dissapear, however, probably did not look appitising to the consumer on the shelf, this had been a major problem for years, I sat in this meeting, all sorts of ideas (most had been tried before) were thown onto the table, I'm no expert in food science but have worked with many product development engineers, I popped the question why not reduce the heat before adding the cream, use a system called Cook time (this is based on the science that you can destroy the spoilers (bugs) at a lower temperture over time), It was commonly used in cooking of meat in hot water over periods of 10 hours or more, the cook time would vary depending on the core temperature, this ensured the required parameters had been met, there was silence in the meeting, I was asked how I knew about this, I simply replied, when my mum cooked with cream I remembered she would tell me that too much heat would cause splitting.
It was trialed, improved the product (Note: there are other factors that will also cause splitting like cooling too fast, cooling too slowly etc.).
It always reminded me of a tale (no idea if it actualy happened) A bus got wedged under a low bridge, firemen, local council engineers spent time discussing things like cutting the roof off etc., a young boy piped up hey mister, why don't you let the tyres down. (yes I'm British so it has a "Y").
Sorry it's a bit long winded, but while technical ability is a must there is also experience.

Peter Nachtwey said:

@GaryS, I disagree. I know a high priority word of bits and a low priority word of bits is simple and effective. The problem is how does one duplicate the ENCODE and DECODE functions that were available long ago.

Click to expand...

To find MSB I use log. Log(integer)/Log(2) = MSB. If multiple bits are set, the whole part of the float/real is the MSB position.

For LSB, a shift until bit 0 = 1 with a count for each shift is the LSB. Works for MSB as well but shift the opposite direction and bit 31 = 1, then 31- count = MSB (change 31 to represent int length).

Oh NO!

durallymax said:

To find MSB I use log. Log(integer)/Log(2) = MSB. If multiple bits are set, the whole part of the float/real is the MSB position.

For LSB, a shift until bit 0 = 1 with a count for each shift is the LSB. Works for MSB as well but shift the opposite direction and bit 31 = 1, then 31- count = MSB (change 31 to represent int length).

Click to expand...

log() functions are very inefficient. Two of them are very bad. Hopefully the compiler is smart enough to make log(2) a constant at compile time.

A PLC is very good/fast at testing bits. Brute force would be faster and easier for the next guy to understand.

What I find very depressing is that so much knowledge is lost after it falls off the front page. It is also depressing that everyone thinks they are the first to confronted with a problem.

If we were lucky enough to have a floating point processor back in the dark ages I would convert the number to a flow and then use the exponent after shifting it and adding an offset.

This page/info has been around for years now. Read the text at the top of the page. No one seems to remember that it exists. Shame.
https://graphics.stanford.edu/~seander/bithacks.html
Everyone should bookmark this link or copy it to a pdf.

BTW, I like the timer idea for estimating levels for determining a priority. I don't think fifos are necessary. Just scan for the highest priory bin using brute force. Obviously the level should be corrected/adjusted if a sensor goes on or off.

I haven't read everything above in detail. The problem is not simple but it should have been solved long before now. I didn't see where this following problem was addressed.

One issue that I see is that the must be some mechanism to keep from switching between filling two bins when their levels/priorities are about the same. There needs to be some minimum difference in priority to switch bins but this must be overridden if a bin is about to be empty

This is a messy but NOT that difficult of a problem. It would be easier with more accurate level sensors. i would avoid the whole two level of priority distraction.

Peter, the one I did some 27 years ago just used loops & indirect addressing as a fifo, to get the priority there was a second loop that itterated through the array so for example if hopper 3 hit low level it would move it down (or up depends on what direction you want to call it), until it either reached the end i.e. first in the queue or behind any others already low level & in the queue.
So we have two arrays (or one with two bytes) the bytes correspond to the hopper number & if low level or not.
It is very simple, some other engineer that programmed another similar line did almost the same but included hopper analogue levels based on a second pulse incrementing or decrementing a register (with simple algorythm for a simulated analogue level), also it incorporated a system where depending on low or high level being reached would adjust the level fill timer over time (system did not fill to high level), the idea being to keep all hoppers at a reasonable level even if the discharge was different i.e. speed of filling packs.
Both the systems put in around 1995 were still in use in 2002 and may still be.

Peter Nachtwey said:

I haven't read everything above in detail.

Click to expand...

Obviously, otherwise you would not have written this:

Peter Nachtwey said:

I don't think fifos are necessary. Just scan for the highest priory bin using brute force.
The problem is not simple but it should have been solved long before now.

Click to expand...

Which describes exactly one of the two solutions posted so far. And that baker's-dozen-rung solution was posted over a week ago, and a sweet FIFO solution was posted well before that.

The with-FIFOs solution reads better.

Peter Nachtwey said:

I didn't see where this following problem was addressed.

One issue that I see is that the must be some mechanism...There needs to be some minimum difference in priority ...

Click to expand...

No, not really, not if a data model is chosen which eliminates that problem; already handled, nothing to see here, move along citizen