RS logix5000 simple recipe

Hi all,I was reading about recipes in the forums. Bulletproof way seems to be in the PLC which I like.
I have 2 words for the recipe 1 word is the program number & 2nd word is the 16 stations to run, the binary value dictates which one.
Simple not really a recipe as only one ingredient.
probably only need 10-15 programs.
I was going to use the panelview to input a number = program number. and then have 16 buttons that represent the stations to form the other word.
a save button and a retrieve button. maybe a file system - How does this work?

Has anyone got some suggestions, ideas or examples etc

Years a go I used SLC 5/05 to do this. I created a file each of the ingredients. N10, F11, N12, N13, ST14, You get the idea.
Then I used indirect addressing to go get the dat that I needed.

Example The target would be recipe 35 so I would change a pointer to look at N10:35 ,F11:35, N12:35 , N13:35, ST14:35, It worked well for less than 255 recipes.

You could do this easly in a 5000 system.

I would create a UDT myself that represents one element of your recipe. In this case it would have 16 boolean values, and possibly one string for the name. In otherwords call your UDT something like RecipeSetup. Then in that UDT create 16 booleans called Station1 to Station16 and one string called RecipeName.

Each value of those booleans would indicate whether that Station is used or not used in that particular recipe. The RecipeName would hold something that identified the recipe for HMI purposes.

Once the UDT is defined, create an array Tag of that Type UDT to store ALL your various recipes. Also create another tag of type UDT (non-array) to identify the current recipe selected/being run.

Then from your HMI, you simply increment/decrement an integer Tag that's the index into the array of recipes. When you want to 'load' that recipe, you copy it (from where the index is pointing to) to the active tag.

robertmee
Very clean idea I like this. I have not had to do any recipes in that last several years do I haven't even went down that road.

The problem with doing this on an SLC/Micro system is that when Bubba comes out to troubleshoot and downloads an old copy of the program into the PLC without uploading first, you'll lose any changes to the recipes that have been made since then. Too bad RSLogix 500 won't let you download the program without the data files. I'm wondering if this is the same in 5000?

More than once!!!! I have been bitten by this. I had a Excel sheet setup to upload the data every when it was ran. I could then download the new data back to the system. I finally gave bubba access to the download sheet so he could update the values from the last time I saved them.
Man that makes me think about all the little details I had almost forgotten.

Hi,all.
Robertmee I like your idea but I am struggling to fully understand it.
Is a UDT a user defined ?. All I can find is under Data types\ User-defined. This however does sound like the answer. I didn't understand how one would program the recipe from the HMI though.

Yes, UDT is user defined type. It is a means in RSLogix 5000 to create your own data types.

So, per the example, you create a UDT called:

RecordElement

The definition of this UDT is 16 booleans Station1 to Station16 and one string RecipeName.

Now once the UDT is defined, go into your tag creater in Logix and create a tag called RecipeActive and assign it type RecordElement (instead of just boolean or integer).

create another tag called RecipeReview and also assign it RecordElement.

create another tag called RecipeData and assign it RecordElement but of 1 dimensional size of 100 elements.

Now, tags RecipeData[0] to RecipeData[99] will have your recipes stored in it. To access each part of the recipe would be like:

RecipeData[0].RecipeName
RecipeData[0].Station1
RecipeData[0].Station2
RecipeData[0].Station3

(That defines Recipe 0)

RecipeData[1].RecipeName
RecipeData[1].Station1
RecipeData[2].Station2
RecipeData[3].Station3

(That defines Recipe 1)

and so forth.

Now create a tag called RecipeIndex of type Integer. This tag will be the pointer into the RecipeData array. You will access it in the PLC such as:

RecipeData[RecipeIndex] for the entire recipe

or

RecipeData[RecipeIndex].Station1 for the current value of Station1 in that recipe.

From your PV, create buttons that increment/decrement the value of RecipeIndex. In your PLC, on each one-shot of the inc/dec button, increase/decrease the value of RecipeIndex and then do a copy of RecipeData[RecipeIndex] into RecipeReview. On the PV screen display the values of RecipeReview.Station1, RecipeReview.Station2, etc.

Create a 'Load' button. The load button will do a move of RecipeReview to RecipeActive in the PLC. You will use this tag to do all your logic in the PLC. For example, RecipeActive.Station1 being true, means that you should activate Station1 in your program logic.

Create a 'Save' button. The save button will do a move of RecipeReview to RecipeData[RecipeIndex] to record any changes made to the RecipeReview tags in the PV. This allows the operator to make recipe changes and only save them with the save button. When the save button is pressed, the RecipeData repository is updated permanently.

That should give you a good outline on how to proceed.

kolyur said:

The problem with doing this on an SLC/Micro system is that when Bubba comes out to troubleshoot and downloads an old copy of the program into the PLC without uploading first, you'll lose any changes to the recipes that have been made since then. Too bad RSLogix 500 won't let you download the program without the data files. I'm wondering if this is the same in 5000?

Click to expand...

That is true, but that also means they've lost any timer presets that have been changed, program changes, production run data, and so forth. The answer here is to train the personnel to do the job right.

Now, for higher end systems, we use a SQL or Access database to store the recipes and dump them to the PLC, but from a PV based system like the OP is describing, storing the recipes in the PLC is perfectly suitable if not desireable.

Thanks Robertmee It is alot to take in. I understand most of what you are saying. I will try it out and let you know. Thanks for the professional help. I just got off the phone with my AB tech rep and he was pointing me in this exact direction. Keep you updated.

robertmee said:

.
.
.
recipes stored in it. To access each part of the recipe would be like:

RecipeData[0].RecipeName
RecipeData[0].Station1
RecipeData[0].Station2
RecipeData[0].Station3

(That defines Recipe 0)

RecipeData[1].RecipeName
RecipeData[1].Station1
RecipeData[2].Station2
RecipeData[3].Station3

(That defines Recipe 1)

and so forth.

Click to expand...

I think I understand, but did you make a typo? If I understand correctly, then shouldn't the indices be "1" for all the RecipeData for the defines recipe 1?
(
RecipeData[1].RecipeName
RecipeData[1].Station1
RecipeData[1].Station2
RecipeData[1].Station3

(That defines Recipe 1)
)

Yep, good catch....fat fingers and typing before thinking

Hello Robertmee, I have programmed the PV and the PLC ready for testing tomorrow night. I had some errors when I used a move in Rslogix5000. I then used a copy file command and the errors went. I made the length 17 is this correct (16 stations and recipe name). Is using the copy file correct as well? Cheers.

Hello Robertmee, I have programmed the PV and the PLC ready for testing tomorrow night. I had some errors when I used a move in Rslogix5000. I then used a copy file command and the errors went. I made the length 17 is this correct (16 stations and recipe name). Is using the copy file correct as well? Cheers.

Sorry, when I was speaking of 'move' in the outline, I didn't mean literally a MOV instruction. You indeed want to do a COP instruction. However, only size 1, not 17. The COP instruction knows that the UDT is x number of bytes/words, so it takes care of moving all the elements, as long as the Source and Destination are both the same type. If the source tag and destination tag were of DIFFERENT types (and therefore possibly differnt # of total words), the COP instruction could overrrun/underfill the destination tag, but in this example, that's not the case.