Level 2: Analog "wuz" Werds
brucechase said:
... I track about 25 items down a system that has about 8 diverter zones. I use latch and unlatch (generously) and pretty much ignore all the arguments of how no one should use these (We can argue this in a different thread if anyone wants to bring this up again). I'm not sure the nomenclature of what this would be. I never really thought about it. Hope this helps.
Bruce, I just finished polishing up a barcode tracking area for cartons of frozen sausage patties. It would be interesting to discuss tracking methods...in tune with the original post...
For those who have read along and understand the was BIT concept...let's move on to the where WUZ it integer word(s).
My tracking logic replaced FIFO stacks that had to be rest 3 to 10 times each 16 hour day. No big deal except the operator had to enter a robot cell to unsort the foul-up, and the conveyor accumulation capacity was both underprogrammed and under sized for any down period over five minutes per hour. The reason the stacks got fubarred was because each section had a FFU/FFL (load onload) totally dependent on fixed field photocells looking at cardboard.
So, I borrowed from an idea that I wrote for a tire tracking program that used an encoder to track the main conveyor end of belt position. That program was slick. I was UN-diverting tires onto a conveyor from 16 drop positions, then following their travel through merge and divert sections. It had to run flawlessly for days on end without messing up to avoid huge production labor "hit$".
The old code just randomly distributed these tires which could be up to 16 different product types, to all the lining cement lines. The new logic took four product codes away from each line and even more when duplicate codes from different conveyor lines were properly assigned.
I used the encoder to drive a pointer, with maximized resolution (raw counts). Every scan the SLC would update the main conveyor position EOB_Raw (DINT End of Belt Raw Counts), then convert it to an float representing feet EOB_ft_exact, and that was rounded to the integer EOB_FT. Since all tires were larger than 1 foot, it was more than adequate to become a pointer to my data table that later represented the conveyor CONTENTS...
I put this logic in first and just watched the encoder rollover point which was about 250 feet. The conveyor measure 210' roughly so I made a full size data table and set my conveyor length encoder up for 210 rollover position.
Then when a tire was dropped from say, DZ1 (Drop Zone 1) it's EDIT:
PRODUCT_ID_INT was popped into a data table with the index = (EOB_FT + DZ1_Offset). If that value was greater than the conveyor length, the conveyor length was subtracted before it was poked into the address. (wraparound)
It was simple to measure my 210' conveyor (luckily it was under 256') and gather the positoins of the drop zones and plug them in.
This was done for all sixteen drop zone sections.
No data had to be moved, the heart of it was just a little math and some overflow logic to create the wraparound effect. The TIRE_DETECT file was called only if the EOB_FT (integer) changed. It was the SBR that cleaned off the end of the belt. I had to build a for next loop with calculated parameters in a 5/03.
TIRE_DETECT: The tire detect logic was a loop that examined 6 feet of conveyor by looking at the values in the data table (with wraparound ie. index 199, 200, 0, 1, and 2 would be checked when the EOB_ft. It compared that with values that represented the EOB position of the EOB_PE (photo eye ON position and photo eye OFF position). A position error was calculated and checked against tunable alarm and fault (faults stopped system).
And the drop zone logic for each zone had a couple branches added to existing rungs.
Very tight code...
I found it to work so well, that when the photocell failed, that was just an alarm and only affected accumulation mode, but when the downstream machinery wasn't backed up, the photocell was optional.
Same thing for the encoder.
I set up self-tuning logic to trend the average accel and decel times and distances, and exact average speed, and wrote a pseudo-encoder routine that would update my dynamic pointer when the encoder card showed a fault.
It once ran for three weeks with no encoder and only two people noticed (because the connector was hanging from the conveyor above their workstations).
So, here at Lopez Foods, I didn't have an encoder and I have more conveyors, most are on motor starters. So I just hand-tached the conveyor speeds and it works good enough to replace FIFO stacks.
I still have to rely on timers and WUZ bits for the diverter solenoid timing, and since there are fewer products in process with multiple barcode readers, I only use my Delta D (distance) value to update the product position which is in a hand made UDT of several different types of files.
Now the line knows how long (in inches this time) each photocell has been blocked, it even detects and pauses when two boxes come through stuck together, because the sort entry eye qualifies the box size based on derived inches of conveyor travel.
The conveyor travel distance, by the way includes accel and decel times as eyeballed by yours truly. These conveyors rarely stop but it's still close enough to work fine when they do.
I need to boil it down to the raw interchangeable nuggets (the code) so it will be more portable and generic.
So, how do you track where your product WUZ?
And Thanks, to RSDoran for the OP, because it IS important to share our ideas and the terms we use to describe them. At the rate our language is evolving especially.
The latest Modern Okie Redneck Dictionary Word:
Beenawhilago....
Beenawhilago since I weedeated behind the barn...
SeeYa!
Okie
