Recipe Arrays In Compact Logix

Hi,

I have a project where it has been asked of me to provide a means of loading a recipe by scanning a barcode. Basically the operator will scan the barcode and the settings associated with that recipe will be loaded.

I have previously used the recipe plus function in the panel view plus terminals and I was planning on using this function again as the barcode was not requested at the outset.

I will be using a compact logix to control this machine. I have decoded barcodes before to show details of a batch order on a hmi.

I will be connecting the barcode scanner to the serial port of the plc and interpeting its data like I have done previously. The information being scanned is just the recipe name. There are two timer values associated with each recipe and I want to load them when the recipe I scan matches the recipe in the database sort of speak.

If the recipe name loaded does not match the barcode that has been scanned, it will flag an error.

If I could get a few ideas or a discussion started, it might put me in the right direction. I will greatley appreciate any comments given.

Thank you.

This is becoming a very popular scenario.

Scan Barcode
Pick recipe from a list
Return some data, do process
error if not in list or wrong scan

PCs are better at databases and lookup tables than PLCs.

One method is to scan the barcode into a PC then lookup the recipe and send it to the PLC.
The PLC then runs the process and returns a result.

Another method is to scan the barcode into the PLC directly with a serial input and parse the data. In this method, the PLC must also hold the possible recipe choices and compare the scan to determine which one to use.

Another method is to scan the barcode to a PC and then look up the recipe, but only send the information for one step to the PLC and then send each remaining step one at a time. Each time waiting for the PLC to return the results from the previous step.

I find the first method to be reasonable. I have used the first and second method. I narrowly avoided the third method.

The third I think is an attempt to use a PC to control a process without actually doing the programing to really control anything. The PLC still has to do all the control, then wait for the ok to continue at every step. This makes constant communication critical to every step. If anything goes wrong it is more difficult to determine the source and house keeping is a major concern. PC people love this though, so it will probably gain traction.

I would, and have done so many times, put all the recipes in the PLC.

The barcode can be scanned and sent to the PLC serially, and the PLC retrieves the correct recipe from where it is stored.

Since you are using CompactLogix, I would create a User-Defined Data Type (UDT) to define the whole recipe structure, and then create an array of the that UDT to hold all the recipes.

Let's say you have 20 recipes, you can create, from your UDT, an array tag like Recipe[21]. That allows you to have Recipe[1] to Recipe[20] as your stored recipes, and Recipe[0] as your "working" recipe.

The code is very easy....

LIM,1,Barcode,20 COP,Recipe[Barcode],Recipe[0],1

...whenever the Barcode value is 1 to 20 (a valid recipe pointer), the correct recipe is copied into the "working" recipe area, Recipe[0]. The length of 1 is correct for a UDT array element.

I often make an alias tag WorkingRecipe which is an alias for Recipe[0] which helps when reading (and writing) the code.

I would also include the recipe index number as an element of the UDT, so that you can continuously check that the correct recipe is still loaded, by comparing WorkingRecipe.Index to Barcode.

I don't favour the idea of passing recipe data through communications from another machine. The above method allows the PLC to continue production even if the PC or HMI is not "on-line" for whatever reason

Totally agree with "daba". Storing a recipe in PLC will eliminate all slue of computer related problems. Additionally, validation process (if any) is also simple. ControlLogix for example allow to have very sophisticated data structures in easy to use "tag" formats. If you have multiple steps in each recipe, 2-dimentional arrays may be very handy.

But daba, the front office people will not be able to change the recipe while the machine is running from their desk.

And if all the data is in the PLC all at once it will not stop as often.

And how will they get all that data into a database so they can make the production charts update in real time?

This is way too productive. (the second choice from my previous post is also my favorite)

I really need to do some new AB if it is really that easy.

Of course, I could also do this pretty easily in Step7 and Unitronics, not sure how I would do it in a SLC500 though.

How would you do this in a SLC? Can they do arrays of UDT?

Additional programming hints:

Have a mode in which you teach the matches, so you don't have to do a bunch of manual entry into the controller tag values. So, you log in as an Enigneer on the HMI, the operator scans a barcode, and it's value gets stored (MOV or COP) into a member (string is often a useful type) of a controller scope Tag of the type (your UDT) we'll call this element "NewRecipe". Then you can edit the fields for a recipe index number, (separate tag), RecipeName (human readable product description) and any other parameters your UDT contains. Then you can choose to save that new recipe setup in place of an existing one in the array of stored recipes.

So then, you can teach a new barcode by scanning it, naming it, and verifying its parameters at run time...if security is a concern, you can disable that feature after commisioning...

OkiePC said:

Additional programming hints:

Have a mode in which you teach the matches, so you don't have to do a bunch of manual entry into the controller tag values. So, you log in as an Enigneer on the HMI, the operator scans a barcode, .........
So then, you can teach a new barcode by scanning it, naming it, and verifying its parameters at run time...if security is a concern, you can disable that feature after commisioning...

Click to expand...

On the HMI????? you mean go on the production floor????? <is joking you...

But that is how I would do it. (and have done it, and it worked great, this is what I would prefer)

But, "they" want to just click a button on a PC and change a database and it all happens unseen through Ethernet.

Just received 2 new machine lines that use the "PC communication after each step" method. I will never understand how these people think.

I just wish the people who come up with this stuff would also be the ones to support it.

After being forced to support their own work, I think they would change their minds. Then again it is difficult to tell. The PC guy tells me he has no idea how a PLC works or what a memory register is. But he is good with VB6..........

dahnuguy said:

On the HMI????? you mean go on the production floor????? <is joking you...

Click to expand...

Nah, only if it's a new palletizing setup, then i have no choice. I do it remotely with a CGM in RSLogix500. I almost always design in run-time scaling, calibration, and teach functions when I get the chance to rewrite a chunk of logic.

It should not require a programmer to edit the source data or the machine functionality (within its machine-designed hard coded limits), when I am done if at all possible.

OkiePC said:

I almost always design in run-time scaling, calibration, and teach functions when I get the chance to rewrite a chunk of logic.
It should not require a programmer to edit the source data or the machine functionality (within its machine-designed hard coded limits), when I am done if at all possible.

Click to expand...

Agreed, this is a well executed system. I would add to your list, a manual mode or maintenance screen. I like to be able to simulate individual functions to test sensors and devices from an HMI. And lets not forget a meaningful alarm message that explains why the machine stopped.

I don't think I have ever been allowed to add all these things to the same project.

The software is expected to be written while the machine is being built and then debugged as the machine is being shipped.

The "extra features" are added while the machine is running production, programmer on bucket in plant, but only after the customer complains about needing the functionality.

I guess it all comes down to rush /time /money /next.

dahnuguy said:

The third I think is an attempt to use a PC to control a process without actually doing the programing to really control anything. The PLC still has to do all the control, then wait for the ok to continue at every step. This makes constant communication critical to every step. If anything goes wrong it is more difficult to determine the source and house keeping is a major concern. PC people love this though, so it will probably gain traction.

Click to expand...

That is of course very much the approach taken by S88 batch implementations where a PC based Control Recipe interfaces with a Phase in a PLC (simplifying a lot!). It does have the many advantages and more for higher level operations that were mentioned. One key is to make the steps (in fact Phases) long enough that minor delays in communications, and even short outages by the PC can be tolerated, but there is much more to phase design than that. And you can interface at higher levels.
While I agree with the approach of keeping some recipes in the PLC's it is not suitable for large scale processes whose recipes span many controllers, integration with a plant MES, multi-purpose plants etc.

FrancisL said:

While I agree with the approach of keeping some recipes in the PLC's it is not suitable for large scale processes whose recipes span many controllers, integration with a plant MES, multi-purpose plants etc.

Click to expand...

I have worked on many projects where PLC-based recipes are used - in the brewing industry.

In brewing there are several processes that make the final brew, and as each brew is moved from one process to the next, the brew recipe moves with it. A simple COP instruction (A-B) can move the whole recipe within the controller, and a MSG can send it to the next controller in the brewstream. There are several brews following on from each other, each with it's own process recipe. In a twin-stream brewery, often it is required that a brew needs to swap to the other stream for one or more of the processes, and the PLC easily keeps track of all the recipe movements as needed.

The recipes at any stage can be viewed on the MES, and certain parameters can be modified "on-the-fly", providing that the parameter hasn't already been used, in which case the MES locks them out. Any changes to any brew parameters are logged to a SQL database, and the final recipe (together with a record of parameter changes made) is stored away for future analysis if needed.

The "Master" recipes, stored in the PLC can be edited from the MES if required (logon authorisation permitting), and again any changes to the PLC recipes is logged to SQL - who, when, and why (a description is required).

So, I have to disagree with your statement that PLC-based recipe systems are not suitable for large scale processes whose recipes span many controllers, integration with a plant MES, multi-purpose plants etc.

daba
That sounds quite a good system, although it may be debatable where the master recipes actually live. Maybe I should have said not always suitable - and I don't think your plant is actually multi-purpose.
Is this a custom design or is it based on a commercial brewing software package?

The true master recipes obviously do not "live" in the PLC, but the manufacturing process does not rely on a connection to them, nor is there a method of transfer from where they actually exist to the control system. In fact the actual true master recipes are in a completely different format that that used in the control system, since the PLC recipe structure was developed back in the days of PLC5s.

Formulation of a new recipe involves keying in the parameters via the SCADA. This isn't too much of an onerous task, as there is a copy facility to take an existing recipe into an unused slot and modify from there - a lot of the parameters do not change.

It is a custom-designed system, rolled-out to all UK plants of the multi-national, who's infrastructure allows SCADA (controlled) access to all areas uk-wide from any terminal on the system (eg. Technical brewers can modify brews at any plant from the comfort of the technical centre).

I don't see why exactly the same system couldn't be used in any industry, after all, the recipes are just blocks of numbers. In fact the recipe as-is contains parameters for many different processes, e.g. Malt Transfer (a conveyoring application), to Wort Boiling (a processing application).

In that respect the recipe handling is already multi-purpose, but could also be used without modification on any plant, in much the same way that a PowerFlex drive, whose Parameters could be thought of as a "recipe", can be used in a wide variety of plants.

daba said:

So, I have to disagree with your statement that PLC-based recipe systems are not suitable for large scale processes whose recipes span many controllers, integration with a plant MES, multi-purpose plants etc.

Click to expand...

I completely agree with your disagreement...........

It is a perspective thing. The PC fetish is taking over and the people making decisions do not have a solid grasp of how they are complicating the design and use of the system.

It is so simple to just send the PLC a complete recipe at the beginning and then get process updates as it runs through the steps, then a report at the end.

The people on the PC side do not fully understand the PLC and the ones I worked with do not want to. Further they feel the PC is somehow superior. Maybe because it has hardware that fails frequently and an OS that locks up and is susceptible to viruses and hacking attacks. These are all good things to add to your production system. Oh yeah don't forget to put all your machines on the corporate network and the internet. That makes it easier to cause problems.

If they really want to use a PC in production, then do it all is my point. They seem to like having a PLC do the hardware interface and make all the complex decisions though.

The system I worked with reminded me of a guy with a clip board reading off the next step while the PLC waited and asked "Mother May I?" And I don't mean anything complex either, it was literally "the next step".
PC: "Download recipe, Begin process"
PLC:"OK done, here are the results"
PC:" Do step 2"
PLC:"OK done, here are the results"
PC: "Do step 3"
repeat 12 times......

And it was 1 through 12, no jumping around or exit out if fault. It is a serial process. (even if it did, PLCs could also accomplish conditional jumps and fault recovery)

Like I can't compare results and go to the next step in the process????????? And they actually thought they were doing something. The only purpose of the PC was to get in the way and cause a point of failure.

It was ridiculous and required a lot of handshaking and communication. Any disruption in the PC system would stop the whole process.

The PC never did anything of any actual use. Nothing that reduced the complexity of the PLC task or made it better. I still had to write everything that I normally would, but add a stop and wait to everything and add more communication and error checking.

All that extra work for a less robust, less productive system.

And it was all pushed by a PC programmer with the bosses ear (also a PC programmer).

Even better all the data from PC was real numbers.............but they didn't tell me that until I was done with the PLC code. The PC interface wasn't even defined until I was almost finished.

No one could explain how it was better or even just equal to a system without PC interruption.

There are many flavors of insanity, this was just one of many.

One point.
You talk about recipes as if they are just a set of values. But in the S88 standard the values are just a part of the recipe, a recipe also include the procedure, which defines the sequence of Phases (or Operations).
And there may be several recipes with different procedure, and indeed new recipes may have procedures that are completely new to the plant.
In such cases you cannot program it all into the PLC sequences as you do not know what they will be.
dahnuguy - you may well be right that in this case the PC really served no purpose by running each step via an interface to the PLC. And in fact I have seen many S88 implementations that needlessly broke up the PLC phases into far too small elements.
As I said before one key is to make the steps (in fact Phases) long enough, and more than that they should be phases that start and end in a stable process state.