Micrologix 1500 Recipe Question

From a previous thread someone suggested I use a Micrologix 1500 LRP for recipe control as this has 48K bytes. I am giving this method a little more thought here.

This is the situation; using a barcode scanner to scan a barcode that will automatically send values to an HMI to reduce setup times. The way I want the program to be set up is once the barcode scanner has scanned a barcode, search through 200 part numbers (use indexed addressing here) and if that part# is there, move the value from where the indexed address found the same part# to a different address (let's just say N7:0). From here, I would also turn on a bit which would activate the recipe command which would have N7:0 as the recipe number as it's address.

If this is a bad way to set this up then let me know, the reason I have it this way is because we will have new part's coming in so we would like for the operator (accompanied by a supervisor who will have a password to go to a specific screen) to be able to create a recipe right on the HMI. I realize that this can be bad but that is why the password would be there.

Here finally comes the question, based on if the answer is yes will prompt even more questions. I am reading that the MicroLogix 1500 LRP has 10K memory for the user program and 4K memory for user data. Can I use the 10K memory if I go over the limit of 4K memory data? I believe you can but I might have that backwards. The reason I know I will go over this limit is because I need to search through approx 200 part#'s, so at 200 strings at 82 characters plus the integer for the field length, is well over that limit. Which leads to a follow up question if I can use th 10K data for also user data, I know for a fact that the part#'s will be only like 20 characters long so I could use in theory 11(11 due to field length) 16 bit integers and then just move those to a string. A problem I can see with this is I will need more than one data type of integers to do this (eg N9,N10...),so that could be a problem to. If there was a way to compare the part# to a string in the recipe file would be great as well, just not sure that is possible.

Please post your comments/suggestions on this one!

Can I use the 10K memory if I go over the limit of 4K memory data?

Click to expand...

Yes, you can use User Memory for your recipe files. If you do, you gain a 5-to-1 ratio. 1 k of User Memory = 5 of Recipe data memory! 10 k of User Memory = 50 K of Recipe Memory!


See the MicroLogix 1200 and MicroLogix 1500 Programmable Controllers

Instruction Set Reference Manual, Publication 1762-RM001G-EN-P, Chapter 22, Page 359.​

Data Log Queue - For 1764-LRP processors, you can store recipe data in the

data log memory space (48K bytes).
. . .
The advantage to using Data Log Queue memory is that the recipe data will not consume User Program space. If you are not using the data logging function, choosing Data Log Queue memory allows you more memory (up to 48K bytes) for RCP files.
You can use the Data Log Queue for data logging and recipe data, but the total cannot exceed 48K bytes.
. . .
If you choose to use the Data Log Queue for one RCP file, all the RCP files in your project will also use the Data Log Queue memory space. See step 2, “Create a RCP File” on page 361 for the recipe file procedure.​

IMPORTANT:

​

​

​

​

While recipe data stored in User Program memory can be saved to the controller’s memory module, recipe data stored in Data Log Queue memory cannot be saved to a memory module. Data Log Queue memory is battery-backed, but cannot be saved to a memory module.

. . .

Addressing Modes and File Types are shown in the following table:
RCP Instruction Valid Addressing Modes and File Types​

(Files O, I, B, and N can be used to store recipe numbers. Addressing Modes: Immediate and Direct, but not Indirect. Address Level: Word.)

. . .
User Program - You can allocate User Program (ladder logic) memory for recipe operations. Once User Program memory is assigned for recipe use, it cannot be used for ladder logic.​

​

​

​

​

TIP: User Program memory can be changed back from recipe operations to ladder logic.

IMPORTANT: When User Program memory is used for recipe data, the usage is as follows:

1K words of User Program memory = 5K words of recipe data memory.
. . .

Like your ladder logic, the recipe data stored in User Program memory can be saved to the controller’s memory module (1764-MM1, -MM2, -​

​

MM1RTC, -MM2RTC).​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

Click to expand...

​

​

​

​

​

​

​

​

I will be using the data log queue for the recipe files, but I will be using user data memory (and hopefully some of the 10K from user program) to compare the string found from using the scanner vs a whole bunch of part#'s already in the PLC. Not sure my idea for storing integers for string files would work good since I have to have the whole string before comparing them to the scanner, is there 83 bytes per string?

Not sure my idea for storing integers for string files would work good since I have to have the whole string before comparing them to the scanner,...

Click to expand...

One of the disadvantages of using the MicroLogix 1500-LRP RCP (Recipe) file is that the format is pre-defined, and you will not be able to change it. However it seems to be fairly flexible.

File - This is the number identifying the RCP file. It is the Recipe File Number used in the RCP instruction in your ladder program and identifies the recipe database.

Number of Recipes - This is the number of recipes contained in the RCP file. This can never be more than 256. This is the Recipe Number used in the RCP instruction in your ladder program.

Name - This is a descriptive name for the RCP file. Do not exceed 20 characters.

Description - This is the file description (optional).

Location where recipe data is stored (applies to all recipe files) - This allows you to designate a memory location for your RCP files.

User Program - You can allocate User Program (ladder logic) memory for recipe operations. Once User Program memory is assigned for recipe use, it cannot be used for ladder logic.

Click to expand...

...is there 83 bytes per string?

Click to expand...

It is not "a string" exactly, and each RCP record can contain up to 80 typed or entered characters.

The 1764-LRP processor has 48K bytes (48 x 1024) of additional memory for data logging purposes. Within this memory, you can define up to 256 (0 to 255) data logging queues. Each queue is configurable by size (maximum number of records stored), and by length (each record is 1 to 80 characters). The length and the maximum number of records determine how much memory is used by the queue. You can choose to have one large queue or multiple small queues.

Click to expand...

A typical RCP (Recipe # 1) is attached.

The Recipe record character length and byte size are not easy to calculate. From Chapter 22:

The Recipe record character length and byte size are not easy to calculate.

Click to expand...

It certainly does look confusing. So what I am thinking is it won't be possible then, I need 24 pieces of data stored;
5 floating point
13 integers
5 bits
1 string
That there is more than the 80 character count, unless I go over multiple queues, but then I would get less recipes for each part. Does this sound correct?

In the recipe instruction, there is a choice between load or store in the 'file operation' field. Does store change the value of the initial data? The pieces of data may need changing so being able to change what is in the initial data would be something I need.

That there is more than the 80 character count, unless I go over multiple queues, but then I would get less recipes for each part. Does this sound correct?

Click to expand...

Yes, but if multiple queues for each of your recipes will work, then you may have plenty of memory in a MicroLogix 1500-LRP. You could use 2 or 3 Queues for each of your records. Sorry, correction: Each of your records seem to add up to about 66 bytes, so (48 x 1024 available)/66 bytes per record = 744 records. Is that enough for your job?

The 5 Floating Point numbers may be the biggest problem with a Recipe file. The manual only shows for the Recipe record as having only Integer and Long Integer number types available.

In the recipe instruction, there is a choice between load or store in the 'file operation' field. Does store change the value of the initial data?

Click to expand...

It is time for me to come clean. I have never used the Recipe instruction. I only know what I read in the manual, and there are gaps. The manual does not show much about the use of Load and Store. It does show using Load in a ladder program, so I assume that Load is when you take data out, and Store is when you use your ladder to put data in or change exsiting data.

In addition to using RCP in a ladder, apparently you can store and retrieve raw Recipe data using "DLG" to save files and a logical ASCII read command to retrieve data, like this:

<date><UDS><time><UDS><1st Data><UDS><2nd Data><UDS>…<UDS><Last Data><NUL>

where:
<date> = mm/dd/yyyy - ASCII characters (date is optional)
<time> = hh:mm:ss - ASCII characters (time is optional)
<UDS> = User Defined Separator (TAB, COMMA, or SPACE)
<X Data> = ASCII decimal representation of the value of the data
<NUL> = record string is null terminated​

•​

​

​

​

If the Real Time Clock module is not present in the controller, <date> is formatted as 00/00/0000,
and <time> is formatted as 00:00:00.​

•​

​

​

​

The Communications Device determines the number of sets of data that have been recorded but not
retrieved. See the Data Log Status File on page 370.​

•​

​

​

​

The controller performs a the data integrity check for each record. If the data integrity check is
invalid, a failure response is sent to the Communications Device. The data set is deleted as soon as​

the failure response is queued for transmission.

Click to expand...

I am a little confused myself right now. I feel like the queues and records are used for data logging, not recipe files. I think the data log instruction (DLG) is using the queues and records. So if that is true, that isn't what I would want. I just want to load data, change this data if something is wrong if needed, also if there is a new part then the option to make the recipe on HMI. I'm not sure on this, just trying to tell you what I'm thinking right now.

I feel like the queues and records are used for data logging, not recipe files.

Click to expand...

Right now, the evidence points toward being able to use the recipe-type files for two different functions:

(1) To create, store, retrieve, and make product(s) from a selected recipe. In this mode, the recipe is actually pulled into the ladder logic and operates devices that would normally be done with ladder logic. In other words, the RCP command puts timer Presets in the proper timers, sets bits, sets word values, dates, and times automatically to allow certain products to be manufactured. The example in the manual was for making paint of different colors, each color with a different recipe but similar ingredients and steps. It seems that the best use of this Recipe file (using Queue memory files) is in concert with a ladder program that can use the data directly. It might be possible to use the Recipe data in your HMI, without using it directly in your program with the RCP commmand. I don't know for sure. I would look at ways to use it as intended with the RCP Load instruction in a ladder program as shown in the example in Post #7. If you can't use it that way, then it may not be efficient to use RCP files for your project.

(2) The second way to use these recipe-type files is to store raw data in a certain format using the DLG command, then retrieve it by reading the ASCII string. The 80-character limit for each record is still in effect for this method. This data is not necessarily for a recipe, but only a way to save and retrieve data that could be "used for creating your own application" for a Windows application or a hand-held device (Palm OS) as stated in the manual in Chapter 22, page 373. Using this method, you might set up an interface between DLG files and your HMI, that does not even use the RCP command at all, but merely retrieves, changes, and saves your recipe files.

I had never heard of RCP files until the previous thread. I am thinking that if it was an efficient, easy-to-use method, that you and I would have heard it discussed many times before! It may be one of those Rockwell ideas that found little real use. I bet that information and help with the method is skimpy and hard to find.

Do an "Advanced Search" on this site for "MicroLogix recipe data logging". These 6 old threads might give you a few hints.
http://www.plctalk.net/qanda/search.php?searchid=3005693

Lucky for me, I found an old Micrologix LSP plc that I could do a bit of testing on, so I can give a little info on the recipe command.

What I found out overall is I can't use it because the string I needed for notes will be longer than 82 characters I expected, possibly up to approx 200ish characters, so sadly it can't work.

Every item in the recipe file needs to be a word address, so bit values would have to be in the form of a decimal number. For this, you can have 16 bits for 1 word, I only need 5 but not much I can do there. Floating point numbers are accepted, but string type files is where it gets silly. Since it must be specified to a word level, I would need to have 42 addresses to each word element within the string (ST9:0.DATA[0]...), which may be time consuming as thats 2 characters per address, for every recipe!

Now I wouldn't use the recipe instruction as the manual has it exactly, only difference would be instead of a constant number for the recipe number, I would use an indexed address, as I would want to automatically search through part#'s and compare that to the what the barcode scans and that would load the values. Storing works pretty cool as well, as this changes the intial value of what is in the recipe.

Unfortunately, this is all I can test. One thing I can still try is to see how the recipe file reacts when there is an HMI changing numbers, I do believe what I need to do could have worked if it wasn't for the extra strings I needed in the end. Also, could have tried a full demo if all networked correctly, sadly after a bit of trying to do this, was not able to communicate to everything (slc 5/03, panelview 1000 and micrologix 1500).

The second way to use the recipe files I can't even try as it isn't an option for the LSP model (data logging). So can't comment on this option.

As I stated before this could have worked if it weren't for the extra strings. One thing I'm still confused on is the 80 character limit, I had way more than 14 word adresses(1 word = 6 characters, 6*14 = >80) and it was working fine. Aside from that this could be a decent way to control recipe data, memory restriction is why I won't go any further down this route.

What I found out overall is I can't use it because the string I needed for notes will be longer than 82 characters I expected, possibly up to approx 200ish characters, so sadly it can't work.

Click to expand...

I have worked with computer database files, and sometimes the data can be reorganized, and long text records pulled out into a separate file, maybe even external to the database. This shortens the record length down, making the database more efficient. There is also the Recipe Name (20 text characters), and the Recipe Description (unknown number of text characters) that could be used to reference or tie in an external file that contains the remainder of your notes for each recipe.

One thing I'm still confused on is the 80 character limit, I had way more than 14 word adresses(1 word = 6 characters, 6*14 = >80) and it was working fine.

Click to expand...

I can't explain that, because the manual states plainly in 4 different places in Chapter 22 that the limit is 80 text characters, including the 1-character delimiter between words. The only hint about how it might work is the RSLogix Help file for "Data Log Queue". It seems that the 80-character limit only shows up when trying to retrieve the data. If the record was longer than 80 characters, apparently some get cut off, only found out at retrieval, and not during storage. Notice here that the record limit is mentioned as "80-bytes", instead of 80 characters, so who knows? It does seem clear that you can leave off the time and date stamps, saving those spaces for word storage.

Data Log Queue
Current Address List
The addresses listed here make up the data set (queue). The size of a data set is limited. The limitation is imposed by retrieval. A retrieved sample can contain no more than 80-bytes of information. And since this information includes time and date stamp data as well as internal queue management variables (data integrity check), you may want to cautiously limit the number of addresses in a data set.
RSLogix 500 - Copyright Rockwell Software

Click to expand...

PS: Can you manage to split 200 character records into three (67-character + delimiters) records, then index your record retrieval by 3 each time, so that you really look at records beginning with numbers 0, 3, 6, 9, and so on? Using that method, each Queue file (Q0 to Q255) could contain 85 recipe files, each consisting of 3 records of 80 characters.