Refactor code structure for improved readability and maintainability
This commit is contained in:
124
.github/copilot-instructions.md
vendored
Normal file
124
.github/copilot-instructions.md
vendored
Normal file
@@ -0,0 +1,124 @@
|
||||
# Tempering Machine Avalonia - AI Agent Instructions
|
||||
|
||||
## Project Overview
|
||||
Industrial chocolate tempering machine control application built with Avalonia UI (.NET 8). Controls hardware via Modbus RTU over serial communication for chocolate heating, cooling, and pouring processes.
|
||||
|
||||
## Core Architecture
|
||||
|
||||
### Thread-Based Loop System
|
||||
The application runs 5 concurrent background threads from `MainWindow` constructor:
|
||||
- **MonitorPortsLoop**: Hardware communication & recipe execution (highest priority)
|
||||
- **ScreenLoop**: Error handling & UI state management
|
||||
- **InteractiveUILoop**: Visual feedback (flashing buttons/indicators)
|
||||
- **TouchLoop**: Touch input handling for screen dimming
|
||||
- **CheckInternetLoop**: Network connectivity monitoring
|
||||
|
||||
### Hardware Communication Stack
|
||||
```
|
||||
Recipe Logic → MainWindow → ModBusMaster → Serial Port → Hardware
|
||||
```
|
||||
- **ModBusMaster**: Implements Modbus RTU protocol with CRC validation
|
||||
- **serialThreadLoop**: Async queue-based serial communication with retry logic
|
||||
- **HoldingRegister**: State object for motor control, temperature setpoints, and outputs
|
||||
|
||||
### Data Persistence (CSV-based)
|
||||
All configuration stored in root CSV files, managed by `DataBase/` classes:
|
||||
- `Recipe.csv`: Temperature goals, motor settings, pedal timing
|
||||
- `Machine.csv`: Hardware limits, delays, pre-heating settings
|
||||
- `Mapping.csv`: Hardware address mapping (motors, sensors, I/O)
|
||||
- `Screen.csv`: Display settings, communication parameters
|
||||
- `Configration.csv`: PID control parameters per heating element
|
||||
|
||||
## Recipe System Architecture
|
||||
|
||||
### Three-Phase Process
|
||||
1. **Heating Phase**: Reach target temperature (both mixer tank + chocolate fountain)
|
||||
2. **Cooling Phase**: Cool to precise temperature or show delay if already at target
|
||||
3. **Pouring Phase**: Maintain temperature within tight range
|
||||
|
||||
### Critical Temperature Logic
|
||||
- **Heating**: Error only if temperature < (goal - errorLimit)
|
||||
- **Cooling**: Error only if temperature > (goal + errorLimit)
|
||||
- **Pouring**: Error if temperature outside (goal ± errorLimit)
|
||||
|
||||
### State Management
|
||||
Recipe phases use integer states: `-1` (off), `1` (active), `10` (paused)
|
||||
Timers control phase transitions with automatic goal checking.
|
||||
|
||||
## Hardware Mapping System
|
||||
|
||||
### Bit-Based Motor Control
|
||||
Motors controlled via bit manipulation on `holdingRegister.motor`:
|
||||
```csharp
|
||||
// Turn on motor
|
||||
foreach (var bit in motor.BitNumbers)
|
||||
holdingRegister.motor |= (ushort)(1 << bit);
|
||||
```
|
||||
|
||||
### Temperature Control
|
||||
Four temperature setpoints (`setTemp1-4`) mapped to heating elements:
|
||||
- Tank Bottom/Wall, Pump, Fountain temperatures
|
||||
- Values in deciselsius (multiply by 10)
|
||||
- `-10000` = disabled/off
|
||||
|
||||
### I/O Mapping
|
||||
- Input registers: Temperature sensors, pedal, safety switches
|
||||
- Output registers: Motors, heaters, alarms
|
||||
- Mapping defined in `Mapping.csv` with address + bit number pairs
|
||||
|
||||
## Key Development Patterns
|
||||
|
||||
### Async UI Updates
|
||||
Always use `Dispatcher.UIThread.Post()` for UI updates from background threads:
|
||||
```csharp
|
||||
Dispatcher.UIThread.Post(() => {
|
||||
footerMsg.Text = "Status message";
|
||||
});
|
||||
```
|
||||
|
||||
### Serial Communication
|
||||
Use queue-based system via `serialThreadLoop.EnqueueWrite/Read()` - never write directly to port.
|
||||
|
||||
### Error Handling
|
||||
Errors use enum-based system (`Error.GridCondition`) with automatic display/removal via `ScreenLoop`.
|
||||
|
||||
### Temperature Validation
|
||||
Recipe editing enforces logical constraints:
|
||||
- Heating: 40-60°C
|
||||
- Cooling: 20-40°C
|
||||
- Pouring: between cooling and heating goals
|
||||
|
||||
## Build & Debug
|
||||
|
||||
### Development Setup
|
||||
- Standard .NET 8 Avalonia project
|
||||
- Build: `dotnet build` or Visual Studio
|
||||
- Run: `dotnet run` from `DaireApplication/` directory
|
||||
|
||||
### Hardware Testing
|
||||
Serial communication requires actual hardware or simulator. Debug logs in `serialThreadLoop` show Modbus traffic.
|
||||
|
||||
### Common Issues
|
||||
- Serial port permissions on Linux
|
||||
- Temperature sensor calibration
|
||||
- Recipe phase transitions depend on precise timing
|
||||
- CSV file corruption breaks app initialization
|
||||
|
||||
## File Organization Priorities
|
||||
|
||||
When modifying:
|
||||
1. **Recipe logic**: `MainWindow.axaml.cs` (MonitorPortsLoop method)
|
||||
2. **UI views**: `Views/UserController/` directory
|
||||
3. **Hardware mapping**: `DataBase/Mapping.cs` + root `Mapping.csv`
|
||||
4. **Serial communication**: `Loops/serialThreadLoop.cs`
|
||||
5. **Error handling**: `ViewModels/Error.cs` + `Loops/ScreenLoop.cs`
|
||||
|
||||
## Critical Implementation Notes
|
||||
|
||||
- Recipe temperature goals are validated on save, not on start
|
||||
- Motor state changes require serial write to take effect
|
||||
- Phase transitions happen automatically based on temperature + time
|
||||
- CSV files auto-migrate missing columns via `DataPathManager.MigrateCsvFiles()`
|
||||
- Thread safety critical - all hardware state changes go through main monitor loop
|
||||
|
||||
Focus on the interplay between recipe logic, hardware communication, and real-time UI updates when making changes.
|
||||
Reference in New Issue
Block a user