Is there a reason the recipes have to be in the machine? Most people go to some trouble to put them in databases where they can be managed. If you are using Edge with a central gateway (and you should), it is likely best to use system.util.sendRequest() to delegate recipe storage to that central gateway.
I would say for instances where the connection to the central gateway takes a dive. It's okay until you have to change over, but it's downtime after that.
I'll have the gateway store the parameters, then occasionally check to see if changes need to be updated.
Can the next recipe on the production schedule not be preloaded into the PLC, so downtime is deferred? Or perhaps a few ahead? Most places know their schedule well enough to do this.
TL/DR; Sure, unless you work in automotive. 
Supply chain issues can mean that orders transmitted from the customer may not alwaays align with components on hand. It can still be pretty fluid, even today. And some customers are crappy at planning.
It also depends on the complexity of the product being produced. An assembly line, for instance, that only has a limited number of products produced-- say, a dozen or so, is different than one that can produce 120 different variations. Some orders can be for just 10 parts, then changeover again. I'ts not unusual to be loved-- er-- to have a lot of changeovers in a shift.
So, for the high complexity lines, I do as you suggest, although I pull a five-day outlook from our ERP. Our ERP is cloud-based and we once lost our interwebz for close to 72 hours. It was painful, but we managed to not shut a customer down.
The low complexty lines, recipes are just stored as a UDT array, and changovers are pretty painless. The complexity is still managed in Ignition, but I only have to monitor for occasional changes.
2 Likes
The middle ground would be two matching Ignition UDTs for recipes, one with OPC tags to the current recipe in the PLC, and the other with memory tags for the "DB". Applying a recipe can be done with tag read/write operations in Ignition, without needing a database, and allowing the same UI programming as a big array in the PLC.
(I'd only recommend this for Edge, or where no local DB is available.)
2 Likes
Wanted to return and explain what we ended up doing to fix the issue, just in case it's helpful for someone else in the future. Your last few comments triggered a light bulb moment. A bulb I should have turned on at the beginning of my project. ha
I simply left the recipe UDT array in the PLC and wrote only the necessary parameters needed for recipe selection from that list to a knew recipe UDT array and imported that into the Ignition project instead, taking my tag count down from 180k to 25k tags.
I've been able to set my tag group back to direct at 1,000ms and seeing a much better response time on all screens.
Thank you all for all you feedback and helpful tips!
1 Like
Just to summarize and with the intention that everyone who reads this post is clear about the strategy to reduce scanning times on tags or PC.
1-Reduce number of OPC tags.
2- Create at least two types of OPC tags, one with a faster configuration 2.1 and the other slower 2.2...
Can you help me complete this point. I haven't been able to follow the thread of which is better for which case. What parameters do we have to use and how to configure them?
In my case I have a Siemens OPC server whose response times are between 1 and 5 seconds, randomly.
At the time, it only distinguished between 2 types of tags: those that are historicized and those that are not historicized. Almost all of them are configured by default.
In the "Periodo bajo" I tried to do a sampling for the tags that do not require a quick update.