I know that there is no access method for all information about a running batch executive recipe available to control modules for reading.
I would like some way from the controller to read when a particular recipe or phase *instance* is active (the unit's UNITPROCEDURE, OPERATION, and P1-P10 parameters only the yeild the recipe or phase class name, e.g. OPERATIONABC vs. OPERATIONABC:x-y, where x is configured instance and y is executed instance.). I want to take controller action when OPERATION:2-1/PHASE:1-2 loads, for example.
Does anyone have clever ways of inferring batch recipe information within the controller *without* a lot (or any) recipe/phase retrofit logic.
I'm considering something like counting how many times the UNITPROCEDURE,OPERATION, or P1-P10 parameters see the same phase or recipe object loaded within a single batch ID to imply a configured instance, but an iterated instance would have to counted differently.
Thanks.
In reply to gamella:
I know this is not an answer to the question that was asked but...
I think the recipe/phase retrofit logic you are avoiding is the best solution.
When the lower level code needs to look for information about what is going on in the higher level code, it is a sure sign that something is missing or wrong with the application design. In this case, I think DeltaV is actually protecting you by making it difficult to do something that will result in a very fragile application. Rather than looking for a clever work-around to the constraint, you will be better off in the long run by eliminating the need for the controller to know what instance of an Operation or Unit Procedure is running.
I really like this answer, because i fundamentally agree with it and it challenges my design concept.
However, would the challenge still hold true if the function of the lower level code was simply to support batch reporting?
Rather than having to edit a myriad of phases and recipes to tell the logic when to gather/monitor report information, I want to centralize the reporting function to watch for sequence events to gather the data (an activity best done in the reporting software package, i agree, but that is a different argument). I introduce risk to the system by having to track, edit, and download logic that controls process execution just for recording data; instead i could separate those functions.
Additionally, as i am sure the requirements will change during design and implementation, I feel it would be easier to make changes in the address of watched events in a monitoring module, instead of having to delete/move phase/recipe logic that only collects data.
In reply to Youssef.El-Bahtimy:
To me, it would still hold true that the controller code should not have to monitor what part of the recipe is running, even to meet reporting requirements. At least with the way I envision what you describe, the reporting would break when someone changed some other part of the recipe and either the count changed or the name of the Operation instance changed.
It sounds like centralizing the reporting function is the right way to go but does that mean that some controller level code needs to monitor the recipe and keep track of where the recipe is in its sequence? One option might be to create a reporting phase that can be designed to pull data from recipe configurable locations on the unit and then include that phase in the recipe at the points where you need to collect the data. There must be other approaches that would meet all your criteria as well.
In reply to carllemp:
Thanks again, this is becoming a good discussion.
The concern about changes 'breaking the reporting' is universal. Let's say I am interested in when a weight > low limit in a phase. In the automation, they'll use a recipe param for low_weight_limit to dictate when a transition occurs. In the subsequent step(s) there will be an action to capture the weight for reporting. Next year, someone comes along and decides to move the step for weight transition to after where I snapshot the weight for reporting, causing a report with the wrong weight. (This has happened to me). Just because I have the reporting rigidly built into the phase or recipe it doesn't make it any easier to keep track of it.. if anything it is harder because the ability to search for where the report parameter is set in this phase or even recipe is not easily done in control studio or recipe studio; we do this usually by searching the FHX. If I have a module that is clearly named Unitname_REPORT, then I basically can have a table of reportable addresses which can be used to reference how changes for that unit will potentially effect reporting.
The real trouble is getting the automation engineers to be cognizant that recipe/phase changes must include assessment of how reporting, MES, or any other supporting or supervisory functions are impacted. All too often, I am asked after a change is already implemented whether the batch reports are going to be ok.
Ultimately, I would prefer to do all the reporting logic configuration in the Reporting Software to achieve the goal of central management and ease of implementation and long term administration.
Thank you again for your feedback.
It sounds like we all agree on what should be done but, like so many real world project, you can't do that because of time/cost constraints or limitations of the current software. That leaves some variation of a controller based solution and the question is: Should the data collection events be triggered from within the recipe or from software that lives outside the recipe and monitors the progress of the batch? I think the outside-the-recipe monitoring will always be more complex and less robust because you have two independent software components that must be coordinated. It also means that you have to build your monitor to anticipate all possible future structures in the recipe or you have to keep modifying that software as unanticipated requirements come up. You said: "Next year, someone comes along and decides to move the step for weight transition to after where I snapshot the weight for reporting, causing a report with the wrong weight. (This has happened to me). Just because I have the reporting rigidly built into the phase or recipe it doesn't make it any easier to keep track of it." Based on that, it sounds like you are envisioning a recipe in which the processing steps and the reporting steps are freely interspersed at the same level of the recipe. With that structure, I agree that it would be fragile. IMO, not as fragile as an external monitoring solution, but fragile nonetheless. I was envisioning a recipe structure where the reporting steps are included with the processing steps (either in parallel or in series) as part of the Operations or Unit Procedures so that the reporting steps always move with the processing steps. I assume that you only need to report weights in parts of the process where the weight will be changed. If that is the case, then the weight monitoring transitions and reporting steps can be included in the operations that call phases which can change the weight. Recipe parameters could be used to select if weight reporting is required for each individual instance of the operation or UP.
It sounds like we all agree on what should be done but, like so many real world project, you can't do that because of time/cost constraints or limitations of the current software. That leaves some variation of a controller based solution and the question is: Should the data collection events be triggered from within the recipe or from software that lives outside the recipe and monitors the progress of the batch?
I think the outside-the-recipe monitoring will always be more complex and less robust because you have two independent software components that must be coordinated. It also means that you have to build your monitor to anticipate all possible future structures in the recipe or you have to keep modifying that software as unanticipated requirements come up.
You said: "Next year, someone comes along and decides to move the step for weight transition to after where I snapshot the weight for reporting, causing a report with the wrong weight. (This has happened to me). Just because I have the reporting rigidly built into the phase or recipe it doesn't make it any easier to keep track of it."
Based on that, it sounds like you are envisioning a recipe in which the processing steps and the reporting steps are freely interspersed at the same level of the recipe. With that structure, I agree that it would be fragile. IMO, not as fragile as an external monitoring solution, but fragile nonetheless. I was envisioning a recipe structure where the reporting steps are included with the processing steps (either in parallel or in series) as part of the Operations or Unit Procedures so that the reporting steps always move with the processing steps. I assume that you only need to report weights in parts of the process where the weight will be changed. If that is the case, then the weight monitoring transitions and reporting steps can be included in the operations that call phases which can change the weight. Recipe parameters could be used to select if weight reporting is required for each individual instance of the operation or UP.