e.cruz/Industrial_Emulator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Name updated, Categories folder to ModbuPoints, less generic to be self documented

Browse Source
This commit is contained in:
Emmanuel Hernandez Cruz
2025-09-15 12:51:34 -05:00
parent 5a0b02ccdf
commit 14cf23281d
24 changed files with 274 additions and 297 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
README.md
View File

@@ -72,24 +72,24 @@ The **Decorator Pattern** lets us "wrap" a basic Modbus point to add this extra
* **Analogy:** Think of a basic 4-20mA analog input card. That's your base object. Now, you add a "scaling block" in your PLC to convert the raw 4-20mA signal into a temperature in Celsius. That scaling block is a "Decorator". It doesn't change the input card, it just wraps its output to make it more useful.
* **How it works here:**
* We start with a basic `ModbusPoint` (like `ModbusHreg` for a Holding Register).
* If a point needs to be treated as a float, we "decorate" or "wrap" it with a `ModbusFloatDecorator`. This decorator knows how to take two 16-bit registers and combine them into a single 32-bit float value, and vice-versa.
* If a point needs to be scaled, we can wrap it with a `ModbusScaleDecorator`.
* We start with a basic `Modbus_Point` (like `Modbus_Hreg` for a Holding Register).
* If a point needs to be treated as a float, we "decorate" or "wrap" it with a `Modbus_FloatDecorator`. This decorator knows how to take two 16-bit registers and combine them into a single 32-bit float value, and vice-versa.
* If a point needs to be scaled, we can wrap it with a `Modbus_ScaleDecorator`.
* **Key Benefit:** This keeps our code clean and avoids an explosion of classes. We don't need `ModbusFloatHoldingRegister`, `ModbusScaledHoldingRegister`, `ModbusLongInputRegister`, etc. We have our basic point types (`Coil`, `Hreg`, `Ireg`) and we simply "decorate" them with the data handling logic they need. This is all handled automatically by the `ModbusPointFactory`.
* **Key Benefit:** This keeps our code clean and avoids an explosion of classes. We don't need `ModbusFloatHoldingRegister`, `ModbusScaledHoldingRegister`, `ModbusLongInputRegister`, etc. We have our basic point types (`Coil`, `Hreg`, `Ireg`) and we simply "decorate" them with the data handling logic they need. This is all handled automatically by the `Modbus_PointFactory`.
* **Files to see:**
* `Categories/ModbusPoint.h`: The base for all points.
* `Categories/ModbusPointDecorator.h`: The base "wrapper" class.
* `Categories/ModbusFloatDecorator.h`: A specific wrapper that adds floating-point logic.
* `Categories/ModbusPointFactory.cpp`: The factory that automatically creates and decorates points based on the `config.h` map.
* `Modbus_Points/Modbus_Point.h`: The base for all points.
* `Modbus_Points/Modbus_PointDecorator.h`: The base "wrapper" class.
* `Modbus_Points/Modbus_FloatDecorator.h`: A specific wrapper that adds floating-point logic.
* `Modbus_Points/Modbus_PointFactory.cpp`: The factory that automatically creates and decorates points based on the `config.h` map.
## Project Structure
* `BaseEmulator.ino`: The main entry point of the Arduino program. It handles Wi-Fi setup, initializes the Modbus server, and runs the main loop.
* `config.h`: The central configuration file. **This is where you define all the Modbus points for the device.** You set the register type, address, and description here.
* `/Equipment`: Contains the `Equipment` class, which represents the overall state machine.
* `/Categories`: Contains the classes for different types of Modbus points (`ModbusCoil`, `ModbusHreg`) and the Decorators (`ModbusFloatDecorator`).
* `/Modbus_Points`: Contains the classes for different types of Modbus points (`Modbus_Coil`, `Modbus_Hreg`) and the Decorators (`Modbus_FloatDecorator`).
* `/States`: Contains the different operating modes for the `Equipment` (e.g., `State_Running`).
* `/Strategies`: Contains the reusable behavior algorithms for Modbus points (e.g., `Strategy_Ramp`).