Ideas for part selection (FactoryTalk View Studio / Studio 5000)

Hi guys,

We have over 500 unique part numbers with new ones being added every other week in our process (Using an Allen Bradley CompactLogix PLC and a PanelView Plus 9 HMI). I am looking for recommendations on implementing part number selection with such high number of parts. I considered RecipePlus and Control lists as an option but have not found any search/sort features, which would mean the operator has to scroll through a big list every time there is a change over. Any thoughts or recommendations would be appreciated!

You do not want to do this in the PLC. All of the part numbers need to be in a database and queried when needed.

Not saying it cannot be done in the PLC, but you will experience excessive lag when searching for a part number.

If the part number you need just so happens to be at position 500, the PLC needs to go and check 500 elements and do string compares on each one.

We tried that here before on an AB L72 and it would take up to 10 seconds and sometimes longer to find the recipe.

An alternative is to break that list down into ones with similar processes.
Meaning, even though you have two or ten different part numbers, they may all be identical when it comes to processing them.
Doing that will bring your count down, if you are able to that is.

Welcome to the forum!

I for one have never used the inbuilt recipe managers in FTView due to exactly the type of limitations you're describing. I prefer to do all recipe management in the PLC. Create a UDT for your recipe structure and then an array of that UDT for your recipe database. Then a single instance of the UDT called "Current_Recipe" or similar. When the operator wants to find a new recipe, they enter a product code into a field on the HMI, and then you use an FSC instruction to search your recipe database array for that product code, and COP the relevant array element into Current_Recipe.

Obviously there's a lot more to it with editing, saving, deleting recipes and whatnot, but that should at least get you started.


One other side note: even better is to store all your recipes in an SQL database, and retrieve them from there. But that requires a lot more engineering/hardware/software/expertise. So in the interests of keeping it simple (stupid), I'd be leaning toward the method above at least to start with.

seth350 said:

If the part number you need just so happens to be at position 500, the PLC needs to go and check 500 elements and do string compares on each one.

We tried that here before on an AB L72 and it would take up to 10 seconds and sometimes longer to find the recipe.

Click to expand...

You beat me to it with the database recommendation


If your FSC is taking 10 seconds to execute though, that works out at 1 string compare every 20ms. That's slow. The only way I can see that happening is if you configured the FSC to only search one record per scan, and then had quite a large program with a long scan time, or a fixed 20ms periodic task.


I've run FSC's on 500-element UDT's before, I generally have them run the whole search in one scan, and never had a problem. If I put in an invalid part number, it has to search the whole 500-element array to determine it doesn't exist, and I always get a result in under 2 seconds. And I'm attributing at least 1.8 seconds of that to the update rate of the FTView screen, not the PLC.

Thank you for the prompt reply guys!

The UDT with FSC idea sounds great! I will start working on it right away and see how things go. I am a rookie when it comes to PLCs and never worked with SQL databases using FactoryTalk. If you guys have any resources that would point me towards how to set things up that would be appreciated. Thanks!

@ASF, that may have been our issue. I wasn't directly involved with that project on startup and by the time I was asked to look into it, they revamped the recipes and didn't need so many.

Thank you for the prompt reply guys!

The UDT with FSC idea sounds great! I will start working on it right away and see how things go. I am a rookie when it comes to PLCs and never worked with SQL databases using FactoryTalk. If you guys have any resources that would point me towards how to set things up that would be appreciated. Thanks!

Click to expand...

If you are new to this, then best stick to ASF's recommendation. Keep it simple.
Using a SQL database with your PLC is not something that can be switched on. It takes a bit of help from IT and some software running on a PC to transmit the data from SQL to the PLC.

If you called your Rockwell distributor, they are going to recommend Factorytalk Transaction Manager. I wouldn't recommend someone new or has never messed with SQL servers to attempt to set it up. Its not all that user friendly and there are many steps (too many) you have to do to get it working. In my personal experience, the data transactions were slower than what we could tolerate.

Most folks will make their own SQL interface from the PLC to the SQL server. I use a RaspberryPi and Node-Red and have used AdvancedHMI (VB.NET) in the past, just for example.

Your UDT (User Defined Tag) used along side the FSC (File Search Compare) will be just fine without the SQL.

If you need more info about to structure your UDT, just ask.

I would strongly recommend using a database to store data and perform all business logic in the database. 3 tier systems work well and are very maintainable.

Tier 1 is the PLC/automation layer. Perform machine related logic here.

Tier 2 is the middleware layer. This can be SCADA or custom windows services. Try to keep this layer as "pass-through" as possible. It is easy to lose discipline and perform business logic here. Try to resist.

Tier 3 is the database layer. Here you perform logic(stored procedures) including searching, sorting, inserting, and managing your company's data. You can have simple web pages to let users manage all of the data.

Keep the PLC as dumb as you can on this kind of stuff.

When I do this with barcode product selection I make a single page with 20 or 40 codes one one page and use Parameter files to call up the next page, up to my maximum.


I have also used just a data entry field the operator enters the product code, and it uses the FSC in the PLC to find the barcode to look for.


I agree a database on a server would be better, but I don't think a PanelView can query it. I have used recently the Factory Talk Transaction manager to monitor a PLC tag that goes high, then queries the database and sends it to the PLC directly. That works very well but you need a server.