Just a little bored, so I thought I would start a thread in one way of using recipes in batching processes, I'm aware there are probably many ways to configure recipes & will depend on the batching process, a number of years ago I had to re-vamp an existing system, this used a recipe structure that was a bit odd, in essence it was fixed in regard to the addition sequences, so not very flexible. for example it required 3 water additions during the process & these were fixed stages & the code produced was effectively 3 routines one for each addition.
This is the way we approached it.
First of all we had a recipe header this contained information that is general in nature like this
RECIPE Header
Recipe_Name : "BSBTK220" (the recipe name )
Description : "jjgjgljgljglgjlgjlgjlgflglfgl" (description of the recipe)
Expiry_Date : (Rarely used but was a requirement in original spec it was allways set to 2099)
Number Of Stages : 7 (the total number of stages in the recipe)
Cooling SP : (Required as a cooling setpoint to chill the product after cooking)
Reduction : (used to boil off excess vapour for a more concentrated flavour)
& so on in other words parameters that are common to the process.
Then we have the recipe stages, now these needed to be flexible so the approach was as follows:
The recipes were all based on 100kg batch size (minimum batch that could be produced so the ingredient weights were based on this), the operator would type in the batch weight required & the system would calculate the ingredients required, for example if tomato paste in a 100kg batch was 30kg then when the operator entered a btch weight of 1000kg then the required weight would be 300kg.As different additions could be added in any order and many additions could be added more than once the recipe stages had the following information
Recipe Stages:
Type of addition: (this is a drop down list where a number i.e. 0-10 would select the type of operation
Examples:
0 - No Addition (used for a heating /mixing/blending cycle)
1 - Oil Addition
2 - Manual addition (this was a semi automatic addition could be different types of product like onions, powders, or other veg done by placing tote bins into elevators to add to the tank).
3 - Water Addition
4 - ...... & so on
Then there would be a number of fields of the description of the addition & weights of that product Note: in our system there was 10 different types of product that could be added manually at that time for example:
1 -"Peppers Diced 10mm" : 5kg
2 - "Coconut 20mm Diced" : 12.5kg
& so on
then a group total Weight : 17.5kg (note this is based on 100kg) PLC would calculate actual required weight based on batch size.
Then other parameters like mix time
Blender required,
Heat time
Heat setpoint
Mixer speed
& so on.
We had 16 possible stages that could be configured most were probably between 4 & 8 stages used.
The way it worked.
Rather than have multiple bits of code for example 3 manual additions the code only had one routine for the manual addition. this routine was just one, so called 3 times during the process and the recipe stage information copied to it.
The operator would select a recipe (in our case from an SQL database), which was downloaded to the relevant PLC (in our case 6 batching tanks) on entering a batch code consisting of Date (automatically encoded) plus a 3 digit batch number (unique) it would check that this had not been previously used. The PLC would load the first stage, call the relevant code for that stage, add the ingredient & do the required process, when complete, the system would check how many stages, if required load the next stage, check the stage requirement & call the relevant code.
This reduced the amount of code, became very flexible & as there was redunancy built in it meant should another type of addition/process could be added with little changes to the system.
So we had a recipe system with say 7 possible functions as above, each stage had upto 10 possible ingredients & 16 possible stages. this took a total of 2,500 registers for the recipe, however, only about 2/3 of these were actually used, but given the possible requirement of the future, there were enough possible stages/ spare stage types & and decsription/weight fields it made it pretty future proof. for example should certain ingredients be moved from manual addition to a fully automatic, no need to change the recipe structure, just set a spare field in the addition type & produce another routine to control it.
Incidently, we used a process sequence variable to control the process for example, on start up a value of 10 was put in the sequence control variable:
So
0 - idle
10-100 Startup
200-400 No addition (Just heating/mixing/ blending, depending on the parameters in the stage)
500-700 Manual Addition
800-1000 Oil Addition
1100- 1300 Starch Addition
1400 1600 pulp addition
1800 - 1900 final stages & checks
2100 - 2200 Transfer to cooling.
Here is the structure of the Recipe header
SELECT TOP (1000) [Rec_Name] For example MBMRC001
,[Description]
,[Rec_Type] (Recipe type as there are at least 3 different types)
,[Valid_Until]
,[Stages_Used]
,[Ings_Used]
,[Clr_Temp]
,[Vac_Ramp_Start]
,[Clr_Agit_Status]
FROM [My_Scada].[dbo].[Recipe_Heads]
& These are the stage information (only 4 shown for clarity)
SELECT TOP (1000) [Rec_Name]
,[Ing1_Stage_Num]
,[Ing1_Code] (Peppers)
,[Ing1_Desc] (Red Pepper Diced 10mm)
,[Ing1_Weight] (12.45)
,[Ing2_Code]
,[Ing2_Desc]
,[Ing2_Weight]
,[Ing3_Stage_Num]
,[Ing3_Code]
,[Ing3_Desc]
,[Ing3_Weight]
,[Ing4_Stage_Num]
,[Ing4_Code]
,[Ing4_Desc]
,[Ing4_Weight]
These are the common to the stages
SELECT TOP (1000) [Rec_Name]
,[Stage_Num]
,[Ingredient_Type] (2) Manual Addition
,[Num_Ingredients] (5)
,[Weight_Total] (34.56) Kg
,[Weight_Tol] (1.3) Kg
,[Temperature] (90.0) Deg C
,[Blend_Req] (1) Yes
,[Blend_Speed] (60) %
,[Agit_Status] (1) ON/OFF
,[Agit_Speed] (100) %
,[Duration]
FROM [My_Scada].[dbo].[Recipe_Stages]
This is only part of the fields as they are too large to really include here but gives an idea of the way the recipes are populated
The above is not the actual one I did many years ago as I do not have that information, however, ironically it is part of one I was involved with in the early 2000's.
This is the way we approached it.
First of all we had a recipe header this contained information that is general in nature like this
RECIPE Header
Recipe_Name : "BSBTK220" (the recipe name )
Description : "jjgjgljgljglgjlgjlgjlgflglfgl" (description of the recipe)
Expiry_Date : (Rarely used but was a requirement in original spec it was allways set to 2099)
Number Of Stages : 7 (the total number of stages in the recipe)
Cooling SP : (Required as a cooling setpoint to chill the product after cooking)
Reduction : (used to boil off excess vapour for a more concentrated flavour)
& so on in other words parameters that are common to the process.
Then we have the recipe stages, now these needed to be flexible so the approach was as follows:
The recipes were all based on 100kg batch size (minimum batch that could be produced so the ingredient weights were based on this), the operator would type in the batch weight required & the system would calculate the ingredients required, for example if tomato paste in a 100kg batch was 30kg then when the operator entered a btch weight of 1000kg then the required weight would be 300kg.As different additions could be added in any order and many additions could be added more than once the recipe stages had the following information
Recipe Stages:
Type of addition: (this is a drop down list where a number i.e. 0-10 would select the type of operation
Examples:
0 - No Addition (used for a heating /mixing/blending cycle)
1 - Oil Addition
2 - Manual addition (this was a semi automatic addition could be different types of product like onions, powders, or other veg done by placing tote bins into elevators to add to the tank).
3 - Water Addition
4 - ...... & so on
Then there would be a number of fields of the description of the addition & weights of that product Note: in our system there was 10 different types of product that could be added manually at that time for example:
1 -"Peppers Diced 10mm" : 5kg
2 - "Coconut 20mm Diced" : 12.5kg
& so on
then a group total Weight : 17.5kg (note this is based on 100kg) PLC would calculate actual required weight based on batch size.
Then other parameters like mix time
Blender required,
Heat time
Heat setpoint
Mixer speed
& so on.
We had 16 possible stages that could be configured most were probably between 4 & 8 stages used.
The way it worked.
Rather than have multiple bits of code for example 3 manual additions the code only had one routine for the manual addition. this routine was just one, so called 3 times during the process and the recipe stage information copied to it.
The operator would select a recipe (in our case from an SQL database), which was downloaded to the relevant PLC (in our case 6 batching tanks) on entering a batch code consisting of Date (automatically encoded) plus a 3 digit batch number (unique) it would check that this had not been previously used. The PLC would load the first stage, call the relevant code for that stage, add the ingredient & do the required process, when complete, the system would check how many stages, if required load the next stage, check the stage requirement & call the relevant code.
This reduced the amount of code, became very flexible & as there was redunancy built in it meant should another type of addition/process could be added with little changes to the system.
So we had a recipe system with say 7 possible functions as above, each stage had upto 10 possible ingredients & 16 possible stages. this took a total of 2,500 registers for the recipe, however, only about 2/3 of these were actually used, but given the possible requirement of the future, there were enough possible stages/ spare stage types & and decsription/weight fields it made it pretty future proof. for example should certain ingredients be moved from manual addition to a fully automatic, no need to change the recipe structure, just set a spare field in the addition type & produce another routine to control it.
Incidently, we used a process sequence variable to control the process for example, on start up a value of 10 was put in the sequence control variable:
So
0 - idle
10-100 Startup
200-400 No addition (Just heating/mixing/ blending, depending on the parameters in the stage)
500-700 Manual Addition
800-1000 Oil Addition
1100- 1300 Starch Addition
1400 1600 pulp addition
1800 - 1900 final stages & checks
2100 - 2200 Transfer to cooling.
Here is the structure of the Recipe header
SELECT TOP (1000) [Rec_Name] For example MBMRC001
,[Description]
,[Rec_Type] (Recipe type as there are at least 3 different types)
,[Valid_Until]
,[Stages_Used]
,[Ings_Used]
,[Clr_Temp]
,[Vac_Ramp_Start]
,[Clr_Agit_Status]
FROM [My_Scada].[dbo].[Recipe_Heads]
& These are the stage information (only 4 shown for clarity)
SELECT TOP (1000) [Rec_Name]
,[Ing1_Stage_Num]
,[Ing1_Code] (Peppers)
,[Ing1_Desc] (Red Pepper Diced 10mm)
,[Ing1_Weight] (12.45)
,[Ing2_Code]
,[Ing2_Desc]
,[Ing2_Weight]
,[Ing3_Stage_Num]
,[Ing3_Code]
,[Ing3_Desc]
,[Ing3_Weight]
,[Ing4_Stage_Num]
,[Ing4_Code]
,[Ing4_Desc]
,[Ing4_Weight]
These are the common to the stages
SELECT TOP (1000) [Rec_Name]
,[Stage_Num]
,[Ingredient_Type] (2) Manual Addition
,[Num_Ingredients] (5)
,[Weight_Total] (34.56) Kg
,[Weight_Tol] (1.3) Kg
,[Temperature] (90.0) Deg C
,[Blend_Req] (1) Yes
,[Blend_Speed] (60) %
,[Agit_Status] (1) ON/OFF
,[Agit_Speed] (100) %
,[Duration]
FROM [My_Scada].[dbo].[Recipe_Stages]
This is only part of the fields as they are too large to really include here but gives an idea of the way the recipes are populated
The above is not the actual one I did many years ago as I do not have that information, however, ironically it is part of one I was involved with in the early 2000's.
