Advice on Solution Approach

General Discussion
1

I’m interested in advice on how I might approach a problem:

An assembly machine has 20 stations. Parts move on pallets through the stations, and at each station a component may be added (depending on the BOM/Recipe) and then a test is conducted. If the part fails at any point then no more components are added to the pallet and all the parts on the pallet are scrapped at the last station.

A recipe for the final assembly can call for components to be added at all of the stations or just some of the stations. And, the component added at each station can be one of hundreds of different available components.

If a pallet is marked “bad”, it travels to the last station and all the components are sucked off into a scrap bin.

So for example, If stations 1-5 add components A-E respectively, a test failure at station 1 makes one scrap unit of “A”, but a failure at station 4 will scrap out one each of A,B,C,D.

The question at the end of the shift is “how much scrap of each component did we have and what station did it come from?” The cycle time is about 3 seconds and the entire finished assembly will fit in the palm of your hand, so there are little parts flying around pretty fast. Manually tabulation is impossible.

I know that all parts start at station 1 and they all finish at station 20, and I know which stations are running and what component they are adding, and I know if they pass or fail the test at each station.

I’m a PLC/Automation guy with limited experience in developing solutions in Ignition. I’m curious if anyone has a high-level suggestion of how they might approach this. I’m thinking about using the PLC to dynamically build an array of components at each station, and then when there’s a failed test I’d use that array to load a FIFO and use the SQL Bridge to unload that FIFO into a db table whenever I detect that it’s not empty, but I’m curious if you ppl who are more familiar with Ignition have some suggestions for an approach that is less focused on the PLC……something that I might not see. Would you have gateway scripts for each different station and do something in scripting?

Thanks!!

1 Like
2

My question would be, where is the recipe stored? If the recipe is in a database that Ignition can access then all you need to pass to Ignition is the recipe and which station it failed at. Knowing this I would assume you would be able to determine, from the recipe, what components would of been on it at that point.

If the recipe doesn’t change very often then you could also just store the recipe number/reference, the station it failed at, and the time. Then when you go to run a report on it, your query can pull together the rest of the information.

3

Yes, the recipe is stored on another server, and I can also read the component part numbers from a string at each station. But I think I still need to build a list for each station of the “upstream components”, right?

4

Without seeing how it is stored in the database, I’m assuming the stations are sequential. If they are you may be able to pull a list of all components prior to and including the station it failed at through a query. If you can then building a string as you go isn’t needed. Even if you want to log the list at the time to prevent a chance of a recipe change throwing off your count, you can build your list through a query then write it into another table with the time and any other information needed.

5

So, I've built a system that does exactly what you're describing (and much more functionality) before. It was a behemoth to say the least. It was an incredible experience. What you're describing is 100% possible with Ignition, a database, and your PLCs.

This was the approach that was taken before I arrived in at that facility. It worked, meaning, it took those recipes and pushed a fifo queue around in the PLC with huge multi-dimensioned arrays. Also included was a fixed UDT to define an "instruction". An Instruction might call out a pick light, require a quality test of some kind, wait for a torque wrench to complete, popup a button confirmation for the operator, wait for a robot interlock, etc.. It also managed AGVs similar to how you've described the pallets in your context.

Then we completely redesigned everything.

Your suspicion is correct, there's tools and techniques in the Ignition/Database toolbox that can make what you're trying to achieve.

The design challenge, in my experience, is the balancing the sliding scale of all PLC versus all Ignition/Database. The team that created the original system, they went all PLC. As in, there wasn't a single tag in Ignition that wasn't an OPC tag. It was a terrible way to use Ignition IMHO. We probably took our slider too far into the Ignition/Database side. That was many years ago, and some improvements to Ignition (especially with 8), would probably yield a better experience, but there's a balance to achieve.

The PLC-heavy approach earns you reliability, speed (in the sub-100ms category, not a consideration for most), and in your case familiarity.

The Ignition/Database-heavy approach is going to get you flexibility, modularity, and scale. You can solve nearly all of the reliability issues, but it cost a lot of money for the network and server infrastructure to support it. My company was willing to pay for that, your mileage may vary.

All that said, here's the basic approach I would take: Store the recipe (in 3rd normal form) in the database. Including what "actions" happen at which station (an action could be adding a part, checking a part, doing some action, whatever). Build a UI for process engineers to add/edit/delete actions so they don't have to call me. Create a unique record in the database for each "build" (unique constructed item). Each time an action is completed at a station, insert a record into the database identifying the build's ID, the action's ID, and any additional "status" or "result" columns you may want to know about what happened. That log table then becomes the basis for the analysis you're talking about. If you store all of the raw information in a well designed database, you should be able to calculate most anything you need.

As far as control, I recommend a combination of SFCs and PLC sequencers to place nicely together. The SFCs run on the gateway and keep all your scripts out of the tag engine and the gateway shared threads (believe me, this is worth it, you don't want to clog up the tag engine). Plus it makes the code super readable. Just keep in mind, that if you move the control to the SFCs, you're production process will become dependent on Ignition uptime, I've done it, as have many others, its very doable. Just know that if your business doesn't already depend on Ignition to produce output you'll have a lot of i's to dot and t's to cross. If your business (or you) aren't ready to take that step, I recommend moving things to the PLC.

2 Likes
6

This has given me a lot to consider. I really appreciate the detail and depth.

Thank you so much!

B.