2. Project Documentation: Industrial Oven Control System

The Industrial Oven Control System is a PLC-based interface designed to monitor and control the temperature of an industrial heating unit. The system provides real-time feedback to operators via a graphical HMI, enforces safety limits, and tracks critical alarm states using CODESYS visualization and alarm configuration features.​

The oven controller combines a simulated process, discrete safety logic, and user interaction to approximate the behavior of a small industrial heating application, suitable for training and prototyping.

2.2 User Interface (HMI) Layout

The HMI is organized into three main functional “cards” to improve operator situational awareness and separate control, status, and alarm information.​

A. Control Panel (Left Card)

• Main Power Switch: Toggle switch that enables or disables the entire heating system.

• Target Temp (°F): Input field where the operator sets the desired oven temperature setpoint.

• Limit (°F): Safety cutoff input; if the actual temperature exceeds this limit plus a configured margin, the system triggers a safety shutdown.​

B. Status & Monitoring (Center & Right Cards)

• Analog Gauge: Large radial gauge displaying the current actual temperature variable (rCurrentTemp) in real time.

• Status Indicators (Pilot Lights):

  • HEATING: Active when the heating elements are energized.

  • READY: Active when the oven temperature is within tolerance of the target setpoint.

  • UNLOCKED / SAFE TO OPEN: Active when the internal temperature is below a defined threshold and the door can be opened safely.​

C. Alarm Management (Bottom Card)

• Alarm Table: Shows a real-time list and history of system faults, including time stamps and alarm messages generated by the CODESYS Alarm Manager.

• ACK ALARM Button: Momentary button used by the operator to acknowledge active “Error” class alarms that require manual confirmation before clearing.​

2.3 Variable Declaration (Data Dictionary)

The main variables are defined in the Global Variable List (GVL) or in PLC_PRG to link process logic and HMI components:

• xPowerSwitch : BOOL – Master power switch.

• rSetpoint : REAL – User‑defined target oven temperature.

• rOringLimit : REAL – Safety limit corresponding to O‑ring rating.

• xAckAlarm : BOOL – Input from HMI ACK ALARM button.

• rCurrentTemp : REAL – Simulated current oven temperature.

• xHeaterOn : BOOL – Output representing heater contactor command.

• xDoorLocked : BOOL – Door interlock (TRUE = locked).

• xSafeToOpen : BOOL – TRUE when temperature is low enough for safe opening.

• xLedPower, xLedRamping, xLedAtTemp : BOOL – Power, heating, and ready pilot lights.

• xAlarmOring : BOOL – Warning alarm trigger (O‑ring / high temperature zone).

• xAlarmShutdown : BOOL – Critical shutdown alarm trigger.

• xSimulate : BOOL – Enables internal temperature simulation.​

A separate spreadsheet-based data dictionary was prepared to list variables, types, descriptions, and visualization bindings, which matches recommended documentation practices for IEC 61131‑3 projects.

https://docs.google.com/spreadsheets/d/13iJtArurLTBK_VNu-Itst2lOpL88kQrg05hTqTPNTqI/edit?usp=sharing

3. Design and testing

3.1 Concept and Requirements

The conceptual objective was to reproduce realistic oven behavior and operator interaction while maintaining clear safety limits. The design focused on three aspects: basic process control (heating and cooling), operator interface (setpoints, status, and indicators), and alarm/safety management (warning and critical shutdown conditions).​

Key functional requirements included manual main power switching, adjustable target temperature and O‑ring limit, automatic heater control, door lock/safe‑to‑open indication, and warning/critical alarms with acknowledgment through the HMI and Alarm Manager.​

3.2 Hardware Description

No physical hardware was used; the system ran entirely on the CODESYS software-based controller and visualization runtime, with internal variables simulating I/O. A conceptual hardware schematic (PLC, heater, temperature sensor, door lock, lamps, HMI) should be included in the final report to illustrate how the simulated variables would map to real field devices in a deployed system.​

3.3 Software Architecture

All control behavior was implemented in a single Structured Text program PLC_PRG with clearly grouped sections for HMI inputs, outputs/status, alarms, and simulation. The logic effectively behaves as three modes (OFF/Cooling, RUN/Heating, SHUTDOWN), even though the state machine is implemented with Boolean conditions rather than an explicit state variable.​

The HMI elements were bound to these variables using the CODESYS Visualization editor, and the Alarm Configuration object was used to define classes and messages that appear in the Alarm Table.​

3.4 Software Architecture and “State Machine” Concept

All logic resides in the main program PLC_PRG, written in Structured Text and executed cyclically by the CODESYS runtime. The code is structured into logical sections: HMI inputs, outputs/status, alarms, simulation, and button auto‑reset.​

Behavior can be viewed as three implicit modes based on power and alarm conditions:

• OFF / Cooling: Power off or shutdown active; heater off; LEDs off; door eventually unlocks when cool.

• RUN / Heating: Power on and no shutdown; heater cycles to reach setpoint; door locked; warning may activate.

• SHUTDOWN: Temperature above rOringLimit + 10.0; system forces power off, stops heater, and sets critical alarm; requires operator resolution and acknowledgment before restarting.

3.5 Control and Safety Logic

The Structured Text logic follows this sequence each scan:

1. Master power indicator

   • xLedPower := xPowerSwitch; mirrors power switch state to the power LED, allowing instantaneous visual feedback.​

2. Safety and shutdown

   • If rCurrentTemp >= (rOringLimit + 10.0), then xAlarmShutdown := TRUE, xPowerSwitch := FALSE, and xHeaterOn := FALSE, representing an automatic emergency stop once the oven significantly exceeds the O‑ring limit.

   • Else if rCurrentTemp >= 180.0, xAlarmOring := TRUE to present a warning alarm when entering the high‑temperature zone.

   • Otherwise, if temperature is below 180.0, both xAlarmOring and xAlarmShutdown are cleared.​

3. Heating process (RUN)

   • When xPowerSwitch is TRUE and xAlarmShutdown is FALSE:

     • Door is locked (xDoorLocked := TRUE) and xSafeToOpen := FALSE.

     • Heater control: if rCurrentTemp < rSetpoint then xHeaterOn := TRUE else xHeaterOn := FALSE.

     • Yellow lamp (xLedRamping) is always ON while running; green lamp (xLedAtTemp) turns ON when rCurrentTemp >= (rSetpoint − 2.0) to indicate “ready.”​

4. OFF / Cooling logic

   • When power is off or a shutdown has occurred:

     • xHeaterOn := FALSE, xLedRamping := FALSE, xLedAtTemp := FALSE.

     • If rCurrentTemp < 100.0, set xSafeToOpen := TRUE and xDoorLocked := FALSE; otherwise keep door locked while too hot.​

5. ACK button auto‑reset

   • If xAckAlarm is TRUE, it is immediately reset to FALSE so that the ACK button behaves like a pulse input rather than a maintained toggle, which matches common HMI design practice.​

3.6 Alarm Configuration

The CODESYS Alarm Manager was configured with at least two alarm classes:​

• WARNING class: Linked to xAlarmOring; behavior is “report only” so the alarm appears when the condition is true and disappears automatically when cleared.

• ERROR/CRITICAL class: Linked to xAlarmShutdown; configured as “acknowledge required,” so the alarm remains visible until the operator presses the ACK ALARM button, even if the underlying condition returns to normal.

These alarm classes define severity, color, and acknowledgment behavior, and their instances are displayed in the Alarm Table on the HMI.​

3.7 Temperature Simulation

Since no real oven or sensor was available, a simple simulation was used:

• If xSimulate is TRUE and xHeaterOn is TRUE, then rCurrentTemp is incremented by about 0.15 °F per scan, simulating heating.

• If xSimulate is TRUE and xHeaterOn is FALSE and rCurrentTemp > 75.0, then rCurrentTemp is decremented by about 0.05 °F per scan, simulating cooling toward ambient temperature (~75°F).​

This model allowed observation of the full warm‑up, warning, shutdown, and cool‑down cycle inside CODESYS without external equipment, while still making the analog gauge and alarm thresholds behave meaningfully.

3.8 Testing Strategy

Testing was organized to show that all requirements were satisfied:

• Startup and basic control test

  • With power OFF, confirm heater OFF, LEDs OFF, door unlocked (if cool), and no alarms.

  • Turn power ON, set rSetpoint (e.g., 150°F) and rOringLimit (e.g., 200°F), and observe the gauge and xHeaterOn activating until the setpoint region is reached.​​

• Ready and interlock test

  • Verify that xLedRamping lights whenever the oven is running.

  • Confirm that xLedAtTemp becomes TRUE once rCurrentTemp is close to rSetpoint, indicating ready state.

  • Check that the door remains locked while hot and only unlocks with “safe to open” indication below 100°F.​

• Alarm triggering and shutdown test

  • Increase the target so the temperature passes 180°F, causing xAlarmOring to assert and a WARNING alarm to appear.

  • Continue heating until rCurrentTemp >= rOringLimit + 10.0; confirm xAlarmShutdown becomes TRUE, power is forced off, heater de‑energizes, and a critical alarm appears in the Alarm Table.​

• Alarm acknowledgment and recovery

  • After “resolving” the simulated issue (adjusting limits/setpoints as needed), press ACK ALARM; confirm the critical alarm clears from the table according to its class behavior.

  • Restart by toggling power and verifying that the oven can run again without residual fault states.​

4. documentations

The Structured Text source code is organized and commented by function, including banners for HMI inputs, outputs and status, alarm logic, simulation, and button handling. Clear in‑line comments describe any non‑obvious behavior (such as forcing the power switch off during shutdown and auto‑resetting the ACK button).

Figure 1: Screenshots of the first layout of the system block diagram (PLC, heater, sensor, door lock, HMI mapping).

Figure 2: Screenshot of the Temporary layout of Mode/state diagram showing OFF/Cooling, RUN/Heating, and SHUTDOWN states

Figure 3: Screenshot of the final HMI layout with Control, Status, and Alarm cards and Screenshot of the Alarm Table showing WARNING and ERROR alarms during a test sequence

Figure 4: Flowchart of the PLC Thermal Control Logic 

5. Conclusions

The Industrial Oven Control System project successfully demonstrated how to design, implement, and test a complete PLC‑based control and HMI solution using CODESYS V3 and Structured Text, even without physical hardware. The combination of process simulation, interlock logic, and alarm management provided a realistic learning experience in industrial automation principles.​

From this work, key lessons included the importance of: clearly defined safety thresholds, intuitive HMI design, properly configured alarm classes, and thorough testing across all operating modes. The project also showed how simulation can be used early in development to verify functional behavior before moving to a physical prototype.​

Challenges included configuring the Alarm Table and classes correctly, binding visualization controls to the right variables, and tuning threshold values so that warnings and shutdowns occurred at meaningful points. These were resolved through iterative testing, observation of runtime variables, and incremental refinement of the ST logic and HMI layout.​

Future improvements could include implementing a more realistic thermal model (e.g., exponential heating/cooling), replacing the on/off heater logic with a PID temperature controller, and logging alarms and process values to external storage for analysis. Integrating actual I/O hardware would turn the simulated oven into a deployable lab system and provide an opportunity to validate the control strategy under real‑world conditions.

6. Disclaimer (aI USage)

For this project, Gemini was used to assist with the coding and file organization of the Industrial Oven system. However, this lab report was authored independently. All writing, data analysis, and explanations were produced by the students without the use of AI tools.