Part tracking

Hello guys,

I have an application where up to 10 fixtures are transported On a conveyor system. Each fixture goes through a series of 7 operations. Would anyone have any tips On how to keep track of which part is in which state throughout the process, so that the parts are processed properly?

My thought was to have a byte for each fixture. Each bit of each byte represents the current state for that fixture. Each time a sensor is triggered i.e. step is complete the system checks starting with the first part whether that part is in the state prior to the One triggered. The part that meets this criterion is advanced a state, meaning the bits in that Byte are shifted left. The process is repeated each time a sensor is triggered. When a part is finished and removed from the belt, the bytes are shifted up one.

This should work fine as far as i can tell, but if the setup is put in Manual mode, and the parts are sent back the other direction On the conveyor, restarting automatic will be a problem unless i keep track of every fixture through every state in the process no matter what mode, even when they go backwards.

There're probably better ways of doing this, anyone have any recommendations? This is more of an educational project for myself, but I'm wondering what are some common ways of doing this out in the field.

Thanks!

Do you have some sort of feedback that allows you to uniquely address each fixture?

I might take a different approach based on what controller I am using.

If we are talking Step 7 I would use three separate words.
Each bit in the words would setup just like you mention.

I would keep track of:
Word 1: Part Loaded
Word 2: Part In Process At Station
Word 3: Part Complete Process Successfully

The part loaded would just be an indication that there is a part in the fixture that needs to be processed. This would be if you do not have a part present sensor at every station. You didn't indicate if you have a situation where you system will index regardless of whether a new part was loaded, so this makes the assumption that empty fixtures may be indexed in.

The "In Process" status is set as soon as you start operating on that fixture at that station. This bit will help you prevent parts that have been previously processed from being reprocessed. Depending on the nature of the process, you might not care if it processes it again. In other instances, if it is aborted at any time prior to complete you may just have to call it bad.

The "processed successfully" is obviously so you don't waste resources processing a part that already failed to complete a previous operation. You didn't mention sorting good or bad parts, but this would indicate to the unload station where the part should go.

A lot of these things will depend specifically on the machine itself and what you are doing.

Hi Damian,

Thank you for the response. There is no provision for identifying parts individually, but all steps have a part present sensor. This is a conveyor setup using old industry equipment that we've built for educational purposes. I'm trying to program it assuming that at any point the operator can switch to manual, move the fixtures backwards or forwards (without picking them up, wouldnt be able to detect this) and have the machine remember what process was completed On what part. Not even sure how reasonable this expectation is, without individual IDs On the fixtures.

Yes, I'm using step 7 (tia Portal), its a s7-1214C cpu. So each word has the Information for all of the parts? Bits are set after each process step, sounds reasonable. Then how specifically would the cpu be able to know if fixture 2 or fixture 5 is triggering a specific Prox sensor if theyve been moved back to the beginning in manual? Can't imagine any way other than counting, but not really sure how to implement that in the code.

Thanks

You could look at which way the motor is being commanded to go when the part present sensor is made. If forward, index your parts in that direction, if reverse, index them backwards.

For 10 fixtures, if you really want to know what is where, you could use 4 sensors at one station and a binary code plate on each fixture.

Station 1 could read the code on the fixture each time it parks and then you'd know for sure what fixture is there.

If the end result is not critical then you could simply get away with keeping track of your directions and transitions and shifting the registers both forward and backward. If it is critical and zero error can be tollerated then you're looking at coded setup like Christoff mentions, or more main stream would be to use either RFID (if your nesting fixtures and be moved around) or an absolute encoder on the drive mechanism that allows you to identify where each fixture is.

When going backwards you have the choice of shifting the information off and losing it completely after going beyond the first station, recirculating it back onto itself, or making station one in the center of your shift registers to effectively shift into a negative region. In any of those cases I would probably limit the number of backward indexes they are allowed to make. If they cross backward over the zero point you will have to make determinations on what bits should be reset based on the nature of the process.

There has also been an assumption on my part that each fixture on the belt gets operated on every index. What I mean by this is belt position 1 is station 1, position 2 is station 2, etc. If there are gaps between stations then you definitely want to build the gaps into you shift register. Or to be more clear, your shift register in my opinion should be based off the total number of "nests" on your conveyor and not just the stations. That makes keeping track of FWD and REV much easier, and lends itself well to both stations being moved and stations being added in the future. That way the bit shift routines take care of everything and your not trying to keep counts of anything. Bits are cheap.