Need Part Build Schedule in HMI Ideas

[Chris Elston]

Need some help from you guys getting some ideas on how to pull this off. Working on a project that the customer has different part sizes they build throughout the day. Say like: 100 x 200 100 x 220 80 x 200 80 x 200 Point being the part size changes for each part they make, and I need to monitor the part size. They have a dedicated operator to control the HMI and could assign him a task of manually entering part numbers. If need to be, but I prefer coming up with some kind of list format. Here are my only two ideas so far using only an RS View HMI platform. 1. Build an interface that allows them to enter say 10 parts at a time in a list format then FIFO them out in a PLC somehow in ladder logic. 2. Use a template based Excel Sheet formatted correctly, and download the whole schedule through DDE in the morning to some registers in the PLC then FIFO them out using ladder logic. Another monkey in the wrench is sometimes they want to insert a different part size in the middle of the schedule. I assume I may have an addeum list or schedule on the side they can load up and jump back and forth between the two part lists. Any other ideas how you would program / design this interface?

[Nathan]

1. Does the PLC have any notion of the part size while it's working on it? 1a. If not, are there any values in the PLC that would indicate the size (from lookup tables, etc)? 2. When you say "monitor the part size", what exactly are you tracking? What do you want to pull up later including aggregate data. A lot depends on how much the PLC/computer system knows, how much data is necessarily manually entered, and how you operate. Based on your proposed solutions, I'd recommend focusing on the best way possible to correlate actual production to entered data. The "schedule a list then hope they match up" probably won't cut it in a production environment. This will probably be a setup where you'll run triggered events that log to an SQL database. Edited November 27, 2007 by Nathan

[Ken Moore]

Don't know if this will help or not, but I'll throw it out there anyway. I'm doing something similar on an old TI PLC which doesn't have a FIFO instruction, so I use two "stacks" of integers. I have two stacks of 100 consecutive words. V100-V199 and V200-V299, the plc looks at the top of the stacks for the two "variables" and then runs the code for those two, when finished, the stacks are "Popped" up one word, 198 goes to 199, 197 to 198 etc... and a zero placed in the bottom. (in RsLogix the COP instruction could be used). The contents of all 100 words are displayed on the HMI. The Operator can write values to any place on the stack he likes, except the one in progress, he clicks on the place he wants a new value and a pop-up opens, he enters the value, and then presses enter, so he can only enter one value at a time, don't know if this is good or bad, each "order" takes several minutes to run, so there isn't a rush to get the entry done. We generally do not use all 100 words, only 25-30 at at time, the operator starts at the first zero and loads 5 or 6 values at a time. If you need to run a "rush job" you can over write whatever is scheduled next. He has to reload the displaced "order" somewhere else in the stack, you could get fancy and automate this perhaps. If the top of the stack is zero, an alarm sounds so the operator knows the machine doesn't have any "orders". Anyway, not saying this is ideal, but it works, and it may give you an idea or two. I think I prefer it to the FIFO because it's easy to follow, and easy to insert a rush order.

[Nathan]

Kens suggestion could work if you don't need to log your data. RSView easily displaying and editing those values for a fixed size stack. A queue (FIFO) approach makes more sense than a stack (FILO) in this application. I didn't follow the details of how the 2 stack approach worked, but got the idea that it somehow allows users to enter data "in the middle". This could also be accomplished with a tag telling the PLC where to insert the data and an associated write trigger. The PLC side logic couldn't be too hard. Again, more requirement details are necessary to provide good feedback for you.

[Ken Moore]

His parts have two dimensions 200 x 400 for example. Stack #1 would hold the 200 and stack #2 would hold the 400. You could log the values at the top of the stack for the "orders" processed.

[Nathan]

Oh, I gotcha! I was implicitly thinking (assuming) that his "stack" would be multiple wide to store whatever other data he needs. If all he needs to track is sets of 2 ints, he might even be able to get away with 2 arrays (assuming he'd figured out the insert operation). Again, you're describing a queue not a stack (FIFO not FILO). Think roller coaster line as opposed to a pile of envelopes that you're stamping. He still hasn't even mentioned the type of PLC being used...

[mracer]

How about a bar code for each size? I have a simple bar code reader that I use to tell a ML1100 what is going on at a machine. Things like PM, waiting for material, meetings, indirect work, work orders for R&D and break down/maintenance. I also send the part number that is being worked on. Some simple code using the string could trigger a counter. Maybe that counter could be seen at the HMI or sent to a Excel file. Just a thought. Racer

[Nathan]

I like that idea. I think it's equivalent to using an int, float, string, or whatever value the barcode is storing to represent a size. Using a barcode reader is a convenient input device. You'll need somewhere (database/spreadsheet/hardcode convention) to track the correlation between id and size, particularly if the PLC process varies based on the size. The success of that approach depends on how flexible your requirements need to be.