Oven Controller
GitHub: https://github.com/adom-inc/workcell/tree/main/firmware/oven
The oven controller controls all the moving components for the oven. To allow for async control, most component sub systems are run in their own async task where they await commands via signals
Tasks
- Device Control Tasks:
servo_control: One task per servo, waiting on corresponding<SERVO>_CONTROLwatches.fan_motor_control: Waits onFAN_CONTROL.pump_motor_control: One task per pump, waiting onAC_CONTROLorCRYO_CONTROL.heater_control: Waits onHEATERS_CONTROL.
- Core Logic Task:
logic_control: Implements the main state machine (RAMP, MAINTAIN, CHILL, COOL, OFF) based on the watchesCUR_TEMP,TARGET_TEMP, andOVEN_RUNNING. Sends commands to device control tasks via watches.
- Logging & Communication Tasks:
log_oven_data: Aggregates state from various watches intoOVEN_LOG.send_oven_status_can: Periodically sendsOVEN_LOGdata over CAN.
- Qualification Test Task:
qual_test_logic: Manages the execution of automated test sequences, reacting toTEST_STARTand controllingTARGET_TEMPandOVEN_RUNNING.
- Test/Utility Tasks (Optional):
toggle_servo,heater_test,cooler_test: Tasks used during development for testing specific hardware components or logic flows.test_logic_auto: Task used to simulate the incomming CUR_TEMP and test state transitions
Oven Control Logic
The logic to the control the Oven is implemented as a State-Machine
The current state of machine is evaluated everytime there is a change in the cur_temp or target_temp which will come through the CUR_TEMP and TARGET_TEMP watches respectively. CUR_TEMP will be updated through from CAN messages from the TiB, while TARGET_TEMP comes from the Qual Test Logic.
When the oven enters a state, it activates a "scheme" which sends out the grouping of signals which are used to activate the various components
of the oven. Most schemes are activated only once, on the transition into the state. The exception is the MAINTAIN_HOT scheme as that has a pid controller based on the current temperature and thus needs new parameters to effectively control the oven.
RAMP: Heat as much as possible until target temperature is reahcedMAINTAIN_HOT: Components can be adjusted to keep the heat at the target temperatureCHILL: Let AC and the FAN run throug the hot side to cool naturally without CRYOCOLD: Go to the cold side and use cryo to get the cold temp targetsMAINTAIN_COLD: Components can be adjusted to keep the target tempOFF: The Oven is off and nothing should be running
Temperature Interpreter Board and Oven Controller Interactions
The Oven Controller uses the readings sent by the TiB for its logic control and to dictate which state the oven is in, thus the oven controller must have constant communication to the TiB. An E-Stop message should be sent if the communication is lost (Not Implemented).
Logging
Each device struct contains a sender reference to a watch which is used for logging. There is a logging task which awaits any change in any of the device watches and keeps the OVEN_LOG watch up-to-date. The Oven Controller sends out a CAN frame generated by this OVEN_LOG every second, and also will also
use that watch to generate a CAN frame if given an RTR request.
Qual Test Logic
Currently all of the logic of running a qualification test is done on the Oven Controller, although this should later be moved to Tungstun.
Relavent Signals OVEN_RUNNING, MANUAL_MODE, TARGET_TEMP
It currently receives all the information about the Qual Test through a CAN message, then generates the target temps and times, then sends the target temperaure based on the current phase to the main logic loop which controls all of the components. Qual Test logic also does checks which allow the oven to be interupted or throw an error if the oven is not reaching the target temperatures in-time. It should be relatively straight forward to refactor, out of the Oven Controller as long as the OVEN_RUNNING and TARGET_TEMP signals are matched.