Suggestions for PLC Recipe Program?

P

Thread Starter

Pete Arthur

I have successfully created the application the customer desires with the PLC and a PanelView 300. Essentially, the machine is setup to run 1 profile. This profile can be adjusted via the PanelView. Currently, the operator is adjusting about 25 timers. Now, the customer would like to have several "hard coded" recipes that can be called up from the PanelView. By "hard coded", I mean that the PLC will need to have specific, non-alterable ladder programs for a given recipe. As someone who has limited knowledge of the ins and outs of RSLogix 500 software, I was wondering what the easiest way to accomplish this would be? Thanks, Pete Arthur
 
D
The easiest way would be to set up multiple ladder files and put a set of logic in each file. Use file 2 to call the ladder file you want as a subroutine, based on the recipe number. Since you only scan one of "recipes" it won't affect your scan time to have multiple copies of essentially the same ladder. For example, if there are 6 recipes you would use file 2 for subroutine calls and Panelview servicing, and files 3-8 for your logic. Move your existing control logic into file 3, then copy it to the others (assuming it is the same for each recipe). Modify your timers in each file then you're done. If the customer only wants to save his operators the trouble of entering 25 timer presets, an easier option is to simply create recipe files with the timer presets. For example, N10:0-N10:24 may contain the timer presets for one product. N10:30-N10:54 may contain the timer presets for another, and so on. Based on the recipe number selected, use the COP function to copy the desired recipe file into the the timer presets (all the timers will need to be contiguous to do this, e.g. T4:0-T4:24). For example, copy #N10:0 length 25 to #T4:0.PRE. Cheers, Dean
 
R

Ralph McDonald, P.E.

I have done something similar for a client. The system runs on an AB 5/05 with maximum memory and Intellution FIX operator interface. We are set up with data tables for 14 current recipies. There are seperate data table for Floating Point parameters ( Temperature, weight, pressure, etc. ) and Integer parameters ( Phase and sequence, timers, batch & job numbers, etc ) The phase & sequence tables allow for different processes on the mixer to be included, skipped, or occur in different sequence for each recipe. When a batch is initilized the stored next batch data is moved to the current batch tables and the selected recipe for the next batch is moved to the next batch tables. The double tables for current and next batch will allow materials for the next batch to be preloaded to weigh hoppers and chemical holding pots, while the current batch is processed in the mixer. When a batch is done all parameters including both recipe and process ( actual weights, times, etc ) are moved to a set of last batch tables where the PI software can record them. We use a lot of data tables but still have memory left to install about 12 more if the client requires it in the future. One of the recipe tables ( #14 ) can be modified by the operator via the operator interface to allow for expemential or low volume batchs. I hope this is of use to you and gives you an idea of how powerfull the data table structure in the AB 5/05 can be. Ralph
 
B
One idea is to use subroutines (program files), each one with different logic for the same group of outputs. You can then selectively call these subroutines from the main program file (#2). You need to be careful to either address all of the same outputs in each program file, or maybe use a move command to turn off all outputs while switching files. If you are not careful, outputs could become stuck on or off. This is a simple and logical approach, but document thoroughly what you do. It looks funny to monitor a program file that is not currently being scanned. It could potentially have true rungs, but the output will be off, or the other way around. This is likely to be a controversial idea. I wonder what the other list members have to say about it. Bill Sturm
 
J

Jeffrey W. Eggenberger

Well it should be fairly simple to set up some sort of indexed addressing, or a sequencer that changes a file pointer to a different "recipe" depending on your input. You could also use sub programs where each recipe is in a sub program that is called depending on the input through the panel view. Jeffrey W. Eggenberger Electrician: Industrial, Commercial, and Residential
 
B

Bruce Axtell

You didn't say which processor you are using. RSLogix 500 works for both the SLC and the Micrologix family, and this makes a difference. It will be easier if you are using the SLC family of processors. The easiest way is to set up a table and use indirect addressing. Use a different data file for each step's data, and each word represents a specific "recipe" or profile. Then you can increment/decrement through the list of profiles and select one or edit the individual segments. With indirect addressing, it is really very simple, but requires some organization of your data files. This would require only two numeric entry fields on your Panelview, one for the profile number and one for the segment number. I would have one screen for entering/editing profiles, and one for operators to select a pre-entered profiles. Bruce Axtell Engineered Control Systems 763-421-8787 763-712-5477 fax [email protected]
 
A
You could have a recipe number register that is written from Panelview and then used in the PLC software as a jump condition ie. Jump over this section of ladder if recipe number not equal to x. I have used a set of registers in Panelview before that indirectly write into an area in the PLC based on a recipe number. This allows easy editing of recipes and can be password protected should you require some security.
 
M

Michael Griffin

At 17:21 06/04/01 -0400, Pete Arthur wrote: <clip> >I have successfully created the application the customer desires with the >PLC and a PanelView 300. Essentially, the machine is setup to run 1 >profile. This profile can be adjusted via the PanelView. Currently, the >operator is adjusting about 25 timers. >Now, the customer would like to have several "hard coded" recipes that can >be called up from the PanelView. By "hard coded", I mean that the PLC will >need to have specific, non-alterable ladder programs for a given recipe. <clip> While I haven't done this with your brand of PLC, we normally do something similar with Siemens PLCs. The approach we use should be able to be used with other types of PLCs provided they have the features you need. We divide parameter data into two classes - part type parameters (data specific to particular product models), and machine parameters (data not specific to any particular product). The part type parameters are values (e.g. analogue limits), timer and counter pre-sets, options (whether or not to perform a specific action), etc. which alter the way a machine behaves, or which may be used to apply limit tests to measurements on the part. Each part may require from one parameter to several dozen, depending upon the machine. Next we define data areas to store one set of parameters for each part type (product model). We normally plan on allowing for more parameter sets than we think we need (from 50 to 100). We store each parameter set in a different data block (in the S5 series - S7-200 is done slightly different). In addition, one data block is used to store the parameters in current use, and another is used as a scratch pad area for editing. In addition to the parameter data, the actual part type is stored in the data block as ASCII text. Part numbers are never hard coded into the OP program. We use the Siemens text OP (e.g. OP17) operator panels to edit the part parameters. A screen is created to select the part type by using soft keys to increment or decrement an index to the appropriate data block (the part number contained in each data block is displayed in its turn). Each increment/decrement copies the next parameter storage data block into the edit scratch pad block. When the desired part number is selected, another soft key is used to select an editing screen. This edit screen operates on the edit scratch pad block. All parameter data, including the part number can be edited. This allows changes to recipes and even new part types to be defined without making any PLC program changes. Changes are saved by pressing a soft key which copies the edit data block to the appropriate parameter storage data block. The appropriate parameter set can be selected for use either manually (via operator action on the OP), or automatically as a result of pallet RF tag data or by other means. The part parameter data is then copied to a working area which the program accesses as required. When parameter sets are selected automatically by an RF or other similar system, they are selected via the "index number", which is the index to the appropriate data block. This for example allows the part number to be encoded into one byte on an RF tag or other system. This index number then must always be stored at a common index position on all machines on the line. The actual "part number" is just there for display to make things easier for people. Editing of data values in the edit scratch pad block is easily done by features built into the OP. Selecting and copying data blocks is done by means of function blocks written in the PLC. If done properly, the PLC code is very re-usable. Machine parameters are different from part parameters in that they are features of the machine which don't depend upon part characteristics. Not every machine would have part parameters, but all machines would have machine parameters. These are typically counter or timer pre-sets, options, etc. Since there would be only one set of machine parameters, the OP machine parameter edit screen would work directly on the same parameters which the machine uses (this normally doesn't cause any problems) and there is minimal PLC logic required to use them. Generally, something can be considered to be a machine parameter if its value is something which must be determined by experience (as opposed to being a physical constant or law of nature). In practice, most timer values end up being machine parameters. Making these editable parameters allows these values to be adjusted by the set-up personnel without having to get someone to make program changes. It also drastically reduces the time and work required to commission a new machine. We have been implementing the above system on all new machines for a number of years now, and have found that it has drastically reduced the number of program changes required. Program changes on these machines are now concerned only with adding new features or fixing genuine bugs, not for tweaking timers or counters. It also eliminates the need to reverse engineer hard coded programs each time a new model is added or an existing model changed. ********************** Michael Griffin London, Ont. Canada [email protected] **********************
 
P
Great idea Dean and thanks for taking the time to reply. This is likely the approach I will use (simple). Regards, Pete Arthur
 
Top