Recipe Arrays In Compact Logix
- Thread starter noely
- Start date
I heard this same argument from others and I had to inform them that I can easily alter the sequence of events and even the order of events in the PLC.
I even wrote the base program and uploaded here to serve as the example.
The phase / step / sequence can be loaded as part of the recipe and I can go from there.
"In such cases you cannot program it all into the PLC sequences as you do not know what they will be."
I can if you tell what they are.
Remember, you are never going to actually change the logic of any step or phase, so that is fixed, and should be to avoid chaos.
I believe that there is a recent shortage in PLC programmers and a glut in PC programmers. This is causing people to try to make one person do both jobs. We play to our strengths, naturally.
I still can't figure out why the PC camp doesn't just do it all in the PC and be done with it. It is easier and simpler to use an I/O adapter directly to the PC than have to program two devices to interface each other.
Then you would have the ultimate flexibility.
As long as the industrial grade CPU remains in the control room or the plant is air conditioned, you would have limited hardware failures. Might have to switch to Linux OS too.
There are a lot of creative ideas, I don't like any of them that reduce efficiency, functionality, or ease of use.
Maybe if the S88 standard is properly implemented it is a good thing, I have not seen this.
I mostly just watch and wonder what people are thinking, nothing I say or do will change any of this, but I would I would like to understand it.
FrancisL
Member
daba
I always shudder when I hear S88 !!
There have been many shudder inducing implementations. Possibly because they did not pay enough attention to the PLC people!
Doesn't the standard just state that the "recipe" can specify which procedure to run ?
No, it defines a procedure as being part of a recipe. Of course many recipes should be able to use the same procedure.
Does "the recipe" contain the actual code in Ladder, STL, SFC, or whatever?
Explicitly S88 does not tell you how to program anything, so it does not define languages to use but hints at SFC types for procedures
I always shudder when I hear S88 !!
There have been many shudder inducing implementations. Possibly because they did not pay enough attention to the PLC people!
Doesn't the standard just state that the "recipe" can specify which procedure to run ?
No, it defines a procedure as being part of a recipe. Of course many recipes should be able to use the same procedure.
Does "the recipe" contain the actual code in Ladder, STL, SFC, or whatever?
Explicitly S88 does not tell you how to program anything, so it does not define languages to use but hints at SFC types for procedures
FrancisL
Member
dahnuguy
I heard this same argument from others and I had to inform them that I can easily alter the sequence of events and even the order of events in the PLC.
Me too, and OK for simple sequences but what if a new procedure requires multiple parallel operations? For example there are multi purpose plants where the process units can be connected in many ways so you might have a train of 3 units for recipe 1 but 5 units (with the 2nd and 3rd in parallel) for another recipe and so on.
I heard this same argument from others and I had to inform them that I can easily alter the sequence of events and even the order of events in the PLC.
Me too, and OK for simple sequences but what if a new procedure requires multiple parallel operations? For example there are multi purpose plants where the process units can be connected in many ways so you might have a train of 3 units for recipe 1 but 5 units (with the 2nd and 3rd in parallel) for another recipe and so on.
Yep, can do that too, same example works. Just send me the recipe and the steps or phases you want and the order of the sequence at the beginning and then I will run it. I can see wanting periodic updates, but those are outgoing. If they fail, it doesn't have to stop the process. Waiting for "mother may I" and handshaking and error checking at every step just adds complication and points of failure.
I admit I am a flex junkie. I love to make a machine easy to modify, multi functional and I love making software flexible and portable.
(The first time you write something fixed and non portable, you will learn during the multiple re-writes that while it is slower in the beginning, flexible, modular code is better in the long run.)
I guess I am in the minority on that one because people keep telling me about all these things that PLCs can't do. I explain that it can do it, then I demonstrate or explain it, they ignore me and do it the other way anyway.
So maybe it's just me. I enjoy handcrafted code, robust and solid and flexible and hard to break.
I don't stop when it works, I stop when I can't make it not work.
My example code I uploaded to this forum is a small simple base code for one of my favorite ideas. Up to 32000 steps in any order and or parallel. (could be more if we use a UINT or UDINT ) Parallel with both done to go next or one done to go next. Or series, or series parallel. Of course nothing really happens in parallel with one CPU, but the parallel branches will all execute in the same ladder scan.
And I am not even the at the top of the PLC world. Just imagine what some of the guys here could do.
Some information
I found this helpful.
http://www.batchcontrol.com/s88/
http://www.pacontrol.com/Batch.html
http://www.batchcontrol.com/s88/selling/merits.shtml
This is the part that caught my attention:
"S88 isolates recipes from equipment. When the software (S88-compliant or otherwise) that defines a product (recipe procedure) and the software to run equipment (phase logic) are in the same device (such as a PLC or DCS), the two different sets of code eventually become indistinguishable and, in some cases, inseparable. This makes recipe and equipment control difficult, if not impossible, to maintain. Every additional ingredient and process improvement can lead to lengthy and error-prone software changes. Documenting and validating such a system is also extremely difficult, and doubly so if not S88-compliant.
(depends on the PLC program and how long you give someone to write it, but I get the point)
If recipes are kept separate from equipment control, however, the manufacturing process is more flexible and can provide significant
advantages: Automation engineers can design control software based on the full capabilities and performance of the equipment rather than on the requirements of the product.
(***** That is what caught my attention right there. That makes perfect sense. I do this now. Program the machine to do what it can, then use the recipe to define how far it goes. But I thought this was more common place. I like runtime editable variables in place of constants.)
Similarly, scientists, process engineers or lead operators who create the recipes can now easily create and edit them."
Now that I have read more about it, I see the merits in S88.
However, like everything else, a poor implementation of the best idea is still no good. The 2 times I have seen this, I did not like it.
Only so much isolation from the equipment is possible though. The level of flexibility they claim in S88, can be achieved without a PC using a PLC and an HMI. Any change in recipe that requires additional hardware will still require additional programming. Any change in the recipe that does not require additional hardware I can accommodate without a PC stopping every step.
Of course I could also do it one step at a time with more coms and overhead.
My only issue with these ideas are when people say it is better because you can't do it otherwise, or the PLC wont do X or Y when I know it will.
I also see the additional points of failure and added coms as a negative.
I assume there is more to this or a lot I don't understand.
I found this helpful.
http://www.batchcontrol.com/s88/
http://www.pacontrol.com/Batch.html
http://www.batchcontrol.com/s88/selling/merits.shtml
This is the part that caught my attention:
"S88 isolates recipes from equipment. When the software (S88-compliant or otherwise) that defines a product (recipe procedure) and the software to run equipment (phase logic) are in the same device (such as a PLC or DCS), the two different sets of code eventually become indistinguishable and, in some cases, inseparable. This makes recipe and equipment control difficult, if not impossible, to maintain. Every additional ingredient and process improvement can lead to lengthy and error-prone software changes. Documenting and validating such a system is also extremely difficult, and doubly so if not S88-compliant.
(depends on the PLC program and how long you give someone to write it, but I get the point)
If recipes are kept separate from equipment control, however, the manufacturing process is more flexible and can provide significant
advantages: Automation engineers can design control software based on the full capabilities and performance of the equipment rather than on the requirements of the product.
(***** That is what caught my attention right there. That makes perfect sense. I do this now. Program the machine to do what it can, then use the recipe to define how far it goes. But I thought this was more common place. I like runtime editable variables in place of constants.)
Similarly, scientists, process engineers or lead operators who create the recipes can now easily create and edit them."
Now that I have read more about it, I see the merits in S88.
However, like everything else, a poor implementation of the best idea is still no good. The 2 times I have seen this, I did not like it.
Only so much isolation from the equipment is possible though. The level of flexibility they claim in S88, can be achieved without a PC using a PLC and an HMI. Any change in recipe that requires additional hardware will still require additional programming. Any change in the recipe that does not require additional hardware I can accommodate without a PC stopping every step.
Of course I could also do it one step at a time with more coms and overhead.
My only issue with these ideas are when people say it is better because you can't do it otherwise, or the PLC wont do X or Y when I know it will.
I also see the additional points of failure and added coms as a negative.
I assume there is more to this or a lot I don't understand.
I don't know which side of the fence you are sitting from your post, there are many ambiguities.
I particularly noted the statement ....
.... Automation engineers cannot design control software that exceeds the capability and performance of the equipment !
I didn't work on the project, thankfully, but I know of an S88 implementation that took 4 times as long to complete a similar sized project that used "conventional" PLC control techniques. It was so troublesome they discarded it 18 months later.
No : the code in the PLC, in whatever language, isolates the recipe from the equipment, it doesn't have to be S88 compliant
That's rubbish - how can a piece of code labelled or commented correctly be misinterpreted as to it's function. How can you look at a piece of code that looks at manufacturing parameters in a recipe, and not distinguish it from a Valve handler...
badly written PLC code ???
I'll say no more....
FrancisL
Member
I don't disagree with a lot of your comments, and you can see some of my observations about actual S88 implementations here
And much more on my blog, S88Control.blogspot.com
As for "I don't know which side of the fence you are sitting from your post," I am in favour of using S88, but that does not preclude implementing it in a PLC/SCADA. I really like PLC's and have a lot of respect for good PLC programmers. But they should be aware of S88 and wary of people who promote it but don't understand PLC's.
And much more on my blog, S88Control.blogspot.com
As for "I don't know which side of the fence you are sitting from your post," I am in favour of using S88, but that does not preclude implementing it in a PLC/SCADA. I really like PLC's and have a lot of respect for good PLC programmers. But they should be aware of S88 and wary of people who promote it but don't understand PLC's.
If you read the link, you will see what part of my post was a quote. I assumed the audience had read the material in the link and I was referring to it. However I failed to delineate sufficiently my thoughts from the texts.
I am in favor of flexible code that works reliably, period. I try not to be biased or closed minded to new ideas. However I am very skeptical and I do not accept new ideas just because they are new or because someone tells me it is a great thing.
With this in mind, I read through the S88 explanations and realized that much of what S88 claims is very similar to what I already do. What I have been resisting is a poor implementation of a similar idea using a home made VB6 HMI to control a PLC sequence. Much like your experience, it did not go well.
The idea of S88 is probably being mis applied in situations where people have uncreative PLC programming and lots of PC fans around with databases that need to be filled.
I suppose some of my PLC code would qualify as S88. It is very flexible. Some people think I take too long, but at the end it is nice.
No one claimed that the hardware could be exceeded.
Quote from link "Automation engineers can design control software based on the full capabilities and performance of the equipment rather than on the requirements of the product." end quote.
I think you are missing a detail here. Most people write fixed PLC code to do job A, using constants that are specific to that process to do just that one thing.
They do this for several reasons:
It is quick
It is easy
It doesn't require any advanced programming to think about
It meets the spec
They still get paid
They get paid again to edit the code every time there is even a minor change in the process.
I don;t think you write that way, I certainly don't. Once you realize that a lot of people are writing inflexible specific code , you then understand the issue.
Imagine you are a process guy who has worked with machines written in this inflexible way. It would get old quick and even cause a drag on innovation as new ideas are shot down due to cost of re-programming.
Even worse are these PLC guys who re-write by patching the old code to death. (sometimes you have to be quick, I know) Then after years of patching, the process IS embedded in the PLC code and is inseparable.
Imagine you wrote a bunch of code to do one thing exclusively.
Now add another function, without changing the original. Just add a branch.
Now do that for every new case.
Now do that for 12 cases. And each one brings a new set of conditions to every decision branch all the way through.
That is ugly. At first it seemed quick and easy, years later it is a mess.
See above........it all merges together. I have seen it, many times, and I have been asked to add more patches. I was forced to patch it. Re-writing it would have taken months. I had Saturday.
It was painful. I did not enjoy it, and it bugs me still. I still remember all the **** I was forced to do and all the things I was not allowed to fix.
Maybe that explanation will help.
It is a constant struggle working under people who make decisions that have a huge effect on your work.
When these people trust your judgment and let you demonstrate ideas, it is great.
When they force some odd structure on you due to legacy code or some cheaper way to do something that costs double in programming time and you wind up working over for free to make it all happen, well, that's not so fun.
To anyone listening, writing your own PC based HMI / control in VB6 or C# is not a good idea. (Just buy Wonderware or something and get over it)
When the two guys that wrote the original HMI PC code are not with the company anymore, you have no support, no documentation, and everybody has to deal with it or try to copy and paste all the old stuff over to new projects and then try to connect it all. And it looks like a toy control system.
And management doesn't want to learn all these complex things to make an informed decision, so they let the people working on it fight over every thing.
If you don't argue about every detail, you wind up agreeing to some weird convoluted mess and then it's somehow your fault when it doesn't work.
If you do argue over every detail, they get mad and you're not a team player.
It never ends.
In these cases, I would like to follow the spec and write something complete and then have it judged.
Or at least have some standard, defined interface that doesn't change every week and then let me do my part to fit the interface to the PLC.
Yes I segued into a mini rant...............I should let it go. I am working on it.
ManFromMichigan
Member
Hello Daba. I know this post is kind of old but I am trying to do very similarly what you describe but I am not quite getting it. How does the limit test copy the specific recipe in the UDT array into the working spot aliased? Is BARCODE an item in your UDT? Would it be possible for you to show a picture of your logic and UDT tag for an example? I'm not sure if you still hang out here but thought I'd give it a shot. Thanks.
In the past I have been involved in recipe handling in many ways, one system I was involved in became a little complex due to the mis-understanding by the supplier on how recipes were loaded from an SQL database.
The system involved a number of stages, firstly the recipe was created on the factory management system (I was not involved with this but I believe it may have been an old unix system ported to Windows server it was a dos window that's about all I know about it). The development team created the recipes, using some proprietary software it was downloaded into an SQL database, the recipe structure was recipe name, valid to date then each addition max of 16 held things like type of addition, descriptions of ingredients, weights, speeds times etc. The Scada (originally thought to be operator control by supplier) would not reside on the factory floor, so the end solution was the development team would download the recipes to the PLC's, which then would be copied to the HMI's the recipe ingredients weight was based on 100kg batch size so when the operator selected a recipe they would enter the batch size & the plc would calculate the required weight for each ingredient. the ingredient type would decide the operation i.e. add starch, add manual ingredients, cook to a temperature etc. There was a trade off between having recipes stored on the HMI's and not being syncronised with the SQL database but the main plus was if the factory network or servers were lost the process could still be used, there was a check done when loading a recipe by requesting the recipe checksum from the SQL server, this could be overwritten by supervisor level if the higher level system was down. The recipe handling was to S88 (well close).
On another system I did involved reading bar codes to select a recipe, this was a stand alone system, the recipes were stored on the HMI, the operation was pretty simple, the barcode was read, the PLC then compared the barcode with the recipe name & loaded the recipe from the HMI into the PLC working recipe. fortunately the HMI's used had very good recipe handling that could be controlled by PLC code. I'm a great believer in keeping a backup type copy of recipes from higher level systems, for example one system I did used the same recipes from the SQL server as in the first description, these were loaded directly by the operator from the Scada/HMI, however, every time a recipe was loaded, a copy in csv format was stored locally on the Scada just in case the factory Databases were down, this allowed continued operation should higher level systems were down.
I definitely agree with Dabba, Read a barcode, the barcode becomes the recipe name (or some form of it) iterate through the recipe names stored in the PLC memory until a match is found, load the data. This is a reasonably simple operation.
The system involved a number of stages, firstly the recipe was created on the factory management system (I was not involved with this but I believe it may have been an old unix system ported to Windows server it was a dos window that's about all I know about it). The development team created the recipes, using some proprietary software it was downloaded into an SQL database, the recipe structure was recipe name, valid to date then each addition max of 16 held things like type of addition, descriptions of ingredients, weights, speeds times etc. The Scada (originally thought to be operator control by supplier) would not reside on the factory floor, so the end solution was the development team would download the recipes to the PLC's, which then would be copied to the HMI's the recipe ingredients weight was based on 100kg batch size so when the operator selected a recipe they would enter the batch size & the plc would calculate the required weight for each ingredient. the ingredient type would decide the operation i.e. add starch, add manual ingredients, cook to a temperature etc. There was a trade off between having recipes stored on the HMI's and not being syncronised with the SQL database but the main plus was if the factory network or servers were lost the process could still be used, there was a check done when loading a recipe by requesting the recipe checksum from the SQL server, this could be overwritten by supervisor level if the higher level system was down. The recipe handling was to S88 (well close).
On another system I did involved reading bar codes to select a recipe, this was a stand alone system, the recipes were stored on the HMI, the operation was pretty simple, the barcode was read, the PLC then compared the barcode with the recipe name & loaded the recipe from the HMI into the PLC working recipe. fortunately the HMI's used had very good recipe handling that could be controlled by PLC code. I'm a great believer in keeping a backup type copy of recipes from higher level systems, for example one system I did used the same recipes from the SQL server as in the first description, these were loaded directly by the operator from the Scada/HMI, however, every time a recipe was loaded, a copy in csv format was stored locally on the Scada just in case the factory Databases were down, this allowed continued operation should higher level systems were down.
I definitely agree with Dabba, Read a barcode, the barcode becomes the recipe name (or some form of it) iterate through the recipe names stored in the PLC memory until a match is found, load the data. This is a reasonably simple operation.
OK, I'll start from scratch (new project) so there's no other data to muddy the waters.
I'll create a recipe system for, say, 35 mixing recipes.
Firstly, I will define my recipe structure as a UDT. See pic "Recipe_UDT". Obviously that data structure could include anything you want, name, index number, created date, last edited date, last production date, etc. etc.
Then I create my Recipes array from that UDT - picture Recipes_TAG". Note that I have created an array of 36 elements, 35 for the database recipes {1} thru {35], and [0] could be my working recipe, or it could equally well be my recipe editing area. I'll continue with it being the "working" recipe.
Now when we look in the tag database (where we created "Recipes", we can see out Recipes[0] to Recipes[35].
We are going to designate Recipes[0] as our "working recipe", si I create an alias tag called "WorkingRecipe", aliased to Recipes[0] - pic. WorkingRecipe_ALIAS
That's all we need for recipe data, then we will have the desired recipe number (possibly from the HMI), and a LoadRecipe command. - pic "All_Data".
Now the code to get a recipe from our "database" of recipes into the WorkingRecipe tag is straightforward. - pic "Get Recipe"
The LIM instruction simply tests that the RecipeNumber specified is valid, otherwise we'll have a processor faulting on us. The COP copies the specified recipe number into our Working Recipe. Obviously there will likely be interlocks so that we don't load a recipe into our WorkingRecipe tag while it is in production. The OTU at the end simply makes the COP happen just once, no matter how long the command bit is on.
Jobs I have worked on in the past have allowed the operators to change the data in the working recipe, but not the "master" recipe in the database. You could easily add code to allow the modified recipe to be saved, overwriting the master, it depends what you want to do.
So that's "bare bones", hope the explanation helps.
Similar Topics
I'm using legacy recipe to download a recipe to the PLC. A little background, the recipes are large. They are broken down into 6 tables, each 16...
Hi guys, got one problem PLC model fp-xh c60t and HMI model TG765S-MT
I've encountered an issue which is the recipe file went missing if i swtich...
Can anyone help me find where is recipe plus or recipe manager in View desginer(studio 5000) software. i want to create an recipe but i am unable...
Need to add new tags to some recipe inside a Wincc Tia Hmi .
Do we have an option to download the recipe , with the newly added elements ...
Hello all. Is it possible to create a shared folder between my laptop and my PV+ 7- standard......2711P-T10C21D8S Series D? What I would like to...