Tray Loading Queue help

[jrupp82]

Hi all,

First of all, so I keep everyone square, I'm running a CompactLogix PLC with RSLogix5000.

I'm looking for some help with an application I have built in-house. I have a robotic pick & place machine that I have in production, and I'm looking to make an enhancement to a Tray Loading feature that I use. Currently, the machine will accept stacks of trays that we place parts into, unstack those trays, feed singles into the Robot Zone, then restack them after exiting the zone as a full tray. These said trays are typically the same size for a production run, however, on some occasions, we will run out of available trays of the desired standard size, and substitute it for another that will work, which is just taller/shorter.

Now, my machine is currently setup to handle all of the variety of trays that we have in house, that's not the issue. The issue is that currently, the only way to change tray size is to out the remainder of the current trays until the machine is empty, change tray size on the HMI, and load the new trays in. All in all that works, but we try to run this machine with what we call a partial operator. That person is responsible for 4 other machines to keep running, and what is going to happen is the machine will sit empty, shut off, for several minutes until they come back around to it.

What I would like to create is a queue for the front of the machine, where typically it would be populated with 7 stacks of the "standard" tray. The information that I would store for that would be tray size & number of trays per stack. When an instance comes up that the operator has to change tray sizes, they will access the machine through the HMI, indicate how many more standard tray stacks are in line, if there is a partial stack of standard trays (and how many in it), and then the new tray size and quantity per stack. That way, the machine doesn't shut down, I'll just keep track of the queue and I'll know when to change over to the new size.

I've been reading this, and other forums searching for a solution, but I still don't quite understand how to handle this. I don't know whether to use the FIFO instructions, or to write my own code to handle it, or....Just looking for some insight from others who have had more experience than myself.

Thanks in advance!

 

[gclshortt]

It looks like FFL and FFU instructions will work for you in your application.

http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm003_-en-p.pdf

The examples in the above reference are good.

I do not know exactly how many bits or words you need to determine the number of trays, but using indirect addressing would work as well.

Hope this helps,
Garry
http://www.accautomation.ca

 

[jrupp82]

So my I think I understand how the instruction works, but I have a question. If the FIFO is full, of let's say my "standard" tray size, could I redirect the .POS value to the point in the FIFO to overwrite those values to my new tray size? Does that work, or does it bump the other values, or is something like this not even possible?

 

[gclshortt]

You can set the size of the FIFO so that it would never be full. If you need to change the value then use the .POS value to right the value directly in the array position.

You can experiment with this once you have the program written.

Regards,
Garry
http://www.accautomation.ca

 

[Doug-P]

If the FIFO is full, of let's say my "standard" tray size, could I redirect the .POS value to the point in the FIFO to overwrite those values to my new tray size?

Yes. But this is inviting trouble, IMHO. It would be preferable to find the position in the FIFO which needs alteration and use that value as an address modifier (indirection) in another instruction, say a MOV or FAL.

...does it bump the other values?

No. The other values in the file aren't moved 'til either associated FFL or FFU goes false-to-true.

As an aside, I would lock out FIFO unloads by the stacker while the HMI screen is open - you wouldn't want the FIFO data shifting while new stack data is being entered.

Now here I'm just thinking out loud: If the different trays could be somehow tagged and an LED light curtain mounted, the PLC could determine for itself which type and quantity of trays are on a stack. More $$$ for sure but less human intervention.

 

[jrupp82]

Doug-P, would you say it is inviting trouble because of the code then required to point to the end of the table once altered? Or is it just not good practice to go scribbling in the FIFO array out of order?

On you side notes, I was also thinking that should an unload be attempted when the HMI is accessed, then I would halt the process until the mod's were complete. Otherwise, just like you're thinking, it will be too easy for the operator to miss this index and get the stack details messed up.

As for the PLC ID'ing the trays on its own, I like taking the human error out. I could possibly accomplish this with some sensors to look at and determine the stack, I don't think the benefit outweighs the cost for that add-on.

 

[DSMR]

As for the PLC ID'ing the trays on its own, I like taking the human error out. I could possibly accomplish this with some sensors to look at and determine the stack, I don't think the benefit outweighs the cost for that add-on.

I disagree. Any time you can automate a certain process to take control away from an operator, it is a great thing. This will save several headaches down the road. As you said before, the operator is working in many places at once, so the last thing they need to do is remember to enter in a que correctly in the correct index.

Look up Poka-yoke: https://en.wikipedia.org/wiki/Poka-yoke

I am a firm believer in this. I found out early that it may be quite easy for me to understand a system because I was the one who implemented and programmed it. For others, it was a hassle. So when given the option, always try to automate the process and mistake-proof it.

 

[Doug-P]

Doug-P, would you say it is inviting trouble because of the code then required to point to the end of the table once altered? Or is it just not good practice to go scribbling in the FIFO array out of order?

This is my opinion, others may see it differently. To do what you want some extra logic is required, whether manipulating the position within the FIFO or using a value outside the FIFO. POS is how the instruction knows to turn on the DN (full) or EM bits at the right time and also where the next value is pushed/popped from. If POS is at four and it's changed to two and inadvertently left there - you're doing things behind the instruction's back, as it were - you've now lost access to two of the values in the FIFO - at least as far as loading and unloading via the instruction. The values are still there, they just don't exist as far as FIFO is concerned. How to recover?

There's a still worse possibility. If POS gets loaded with (starting element + .POS) > FIFO array size you'll fault the processor. To prevent this you'd have to add some validation logic on the POS calculation.

My approach would be to write logic apart from the FIFO to determine which position is to be altered.