Discussion: Dynamic Batch Process Modelling

This is a Discussion Page with supplementary user information. It is not part of the core SysCAD Help Documentation - please refer to the User Guide for full documentation links.

Navigation: Product Blog ➔ Discussion Pages ➔ Dynamic Batch Process Modelling

Related Links: Dynamic Centrifuge Example Project

Dynamic Centrifuge Example Project

A dynamic example project was released with Build 139.35250: Dynamic Centrifuge Example Project. This example project demonstrates how SysCAD can be used to set up and run batch process with predefined cycle times. This could be used as the foundation for building your own dynamic project simulating batch processes.

In this discussion page, we'll go through the subroutines used to define the batch process.

Dynamic Batch and Class PGM Code Overview

Users can refer to the example to see the actual PGM files used in the project. Note that the code uses PGM Classes, and the centrifuge class file is written as an include file: CF_Class.pgm.

The major components of the PGM code in the project are as follows:

1. General process set points and information (PlantControl.pgm)
2. Class subroutine definition (CF_Class.pgm)
   • Class unit settings
   • Local variable declaration
   • Initialisation
   • Find state subroutine
   • State instruction subroutine
   • Execution subroutine
   • Reporting subroutine
3. Initialise prestart subroutine (PlantControl.pgm)
4. Initialise solution subroutine (PlantControl.pgm)
5. State triggers and other dynamic control logic (PlantControl.pgm)
   • Note that the main control logic is specified outside of the class PGM file.

Modelling Dynamic Batch Process in SysCAD

To successfully code a batch process in a dynamic model, there are two major tasks the logic must achieve:

1. Identifying the state of the batch process
2. Instructing the behaviour of the model during the state

It is best to separate this process into two different subroutines in the code to ensure there are no gaps in the logic as the batch process progresses.

Identifying the State of the Batch Process

In this example, the subroutine used for this identification is “FindState”.

Sub FindState()
	If (CF_OpState == Fill)
		MaxWait   = WaitTime
		FillTime  = SimTime - StartTimeFill
		if((CF_FillFrac >= 99.8) or ([CF_Feed_Tag]<= 0.0)) ;terminate if reach level or feed stops
			CF_Opstate = Spin
			StartTimeSpin = SimTime
		EndIf
	ElseIf (CF_OpState == Spin)
		SpinTime = SimTime - StartTimeSpin
		If (SpinTime >= CFSpinTime)
			CF_OpState = Empty
			StartTimeEmpty = SimTime
			[CFWashOutQmTag] = PurgeRate
		EndIf
	ElseIf (CF_OpState == Empty)
		EmptyTime = SimTime - StartTimeEmpty
		if(CF_FillFrac <= 2.0)
			CF_Opstate = Wait
			StartTimeWait = SimTime
		EndIf
	ElseIf (On == 0)
		CF_OpState = Off
	Else
	  CF_Opstate = Wait
	EndIf	;Note that there is no off and wait states specified in this subroutine because the trigger
			;logic is elsewhere in the project outside of the calss controller
EndSub

Although each scenario is unique, there are some common elements that belong in this subroutine in most batch simulations:

1. The batch process will always be in one of the states, this is where the logic to trigger swapping to a new state will be. These triggers are typically nested if statements.
   • For example, in the project, when the time the centrifuge has been spinning exceeds the spin time set point, the state changes to Empty.
   • Note that not all triggers might be in this subroutine, especially in instances where there is class logic. For example in this project, the logic to determine when a centrifuge should switch out of wait and into fill is outside of the FindState subroutine.
2. Any code that needs to record a value at the start or end of a state should be set in this subroutine. Some examples of this include:
   • When setting start times of states, this must be done as the state is being stepped into. For example, in this project, the StartTimeEmpty variable is being set during the solver iteration that the centrifuge steps out of spin and into empty.
   • Process information that needs to be recorded once each batch. For example in this project, the PurgeRate.
   • Resetting any statistics that are collected on a batch by batch basis. For example, if you are collecting information about the total flow through a line per batch, one way this could be done is resetting the statistics being collected by that line.

Instructing the Behaviour of the Batch State

Once the state of the batch has been identified, a subroutine is needed to instruct the actual model behaviour in that state. In this project, the subroutine is called “CentrifugeLogic”.

Sub CentrifugeLogic()
	If (CF_OpState == Off)
		CFWashOutQm = 0.0
		CFMagmaOutQm = 0.0
		WaitTime  = 0.0
		FillTime  = 0.0
		SpinTime  = 0.0
		EmptyTime = 0.0
	ElseIf (CF_OpState == Fill)
		CFWashOutQm = 0.0
		CFMagmaOutQm = 0.0
	ElseIf (CF_OpState == Spin)
		CFWashOutQm = iif((CF_Moisture >= Moisture_SP), (PurgeRate  * CF_Moisture * 0.01), 0.0)
		CFMagmaOutQm = 0.0
	ElseIf (CF_OpState == Empty)
		CFWashOutQm = 0.0
		CFMagmaOutQm = PlowRate
	ElseIf (CF_OpState == Wait) 
		CFWashOutQm = 0.0
		CFMagmaOutQm = 0.0
		WaitTime  = SimTime - StartTimeWait
		FillTime  = 0.0
		SpinTime  = 0.0
		EmptyTime = 0.0
	Else
		CFWashOutQm = 0.0
		CFMagmaOutQm = 0.0
	EndIf
	[CFWashOutQmTag] = CFWashOutQm
	[CFMagmaOutQmTag] = CFMagmaOutQm
	WWQm   = (CF_Capacity * WashWater_Frac * 0.01) * (3600.0/CFSpinTime)
	Water  = iif(CF_OpState == Spin, WWQm, 0.0)
EndSub

A few notes about this subroutine:

1. Although not required, it is good practice to set the same variables in each iteration of the if statement even if they do not change. This will ensure there are no gaps in the logic if there is any irregularity in the order the states progress.
   • An example in this project of this is setting CFMagmaOutQm to zero in both the fill and spin stages even though they happen concurrently under normal operation.
2. Some timing logic can occur here. Any time tags that should only change during a particular state should be set in this logic.
3. It is good practice to include one large if statement for this subroutine so that there is never a gap in the logic.

Combining Batch and Class Dynamic Modelling

This project example combines the use of batch and class dynamic modelling. There are a couple of important things to keep in mind when combining these coding elements:

1. Be aware of what triggers for changing batch states need to be included or excluded from the class subroutine. Triggers to change states that involve other elements of the class should be outside of the class routine and need to be addressed individually. Care needs to be taken when coding references to batch states or variables for individual members of the class outside of the class.
2. Make sure that there are not gaps in the logic finding or executing states, especially if some of the logic is outside of the class controller.

---

First Posted: March 2025

Reference Build: 139.37016

For questions or feedback, please contact us at [email protected].