This commit is contained in:
2026-04-17 14:55:32 -04:00
commit bc3ac1d4c9
18017 changed files with 4371742 additions and 0 deletions

View File

@@ -0,0 +1,113 @@
---
source_files:
- DataPRO/CanFDApiProxy/Interfaces/ICANFDApi.cs
generated_at: "2026-04-16T04:03:01.127013+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "b35bfae408176fa6"
---
# Interfaces
## Documentation Page: `ICANFDApi` Interface
---
### **1. Purpose**
The `ICANFDApi` interface defines the contract for a proxy layer that abstracts communication with a remote CANFD device (e.g., a hardware diagnostic or data acquisition unit). It provides a standardized set of asynchronous methods to *retrieve* (GET) and *modify* (SET) device state and configuration across multiple subsystems—including USB, serial, LEDs, clocks, CAN bus, power, battery, network, recording, and event pins—while also supporting file operations (download, upload, delete) over USB. This interface decouples client code from transport-specific implementation details (e.g., HTTP, serial, or custom protocol), enabling testability and modularity in the broader system.
---
### **2. Public Interface**
All methods are `async` and return `Task<T>` where `T` is a specific message type defined in `CANFDApiProxy.Messages`. Each method accepts a `deviceHost` (string, likely an IP or hostname) and a `CancellationToken`.
#### **GET Methods (Read-Only Queries)**
| Method | Return Type | Description |
|--------|-------------|-------------|
| `GetUsbTree(string deviceHost, CancellationToken ct)` | `Task<UsbTreeMessage>` | Retrieves the USB device tree (e.g., connected USB devices and their hierarchy). |
| `GetUsbStats(string deviceHost, CancellationToken ct)` | `Task<UsbStatsMessage>` | Retrieves USB statistics (e.g., throughput, errors). |
| `GetSerial(string deviceHost, CancellationToken ct)` | `Task<SerialMessage>` | Retrieves current serial port configuration/settings. |
| `GetLEDs(string deviceHost, CancellationToken ct)` | `Task<LEDsMessage>` | Retrieves current LED states (e.g., on/off, color). |
| `GetClocks(string deviceHost, CancellationToken ct)` | `Task<ClocksMessage>` | Retrieves current clock/time settings. |
| `GetEventPin(string deviceHost, CancellationToken ct)` | `Task<EventPinMessage>` | Retrieves current configuration/state of the event pin (e.g., armed/disarmed, trigger mode). |
| `GetCANConfig(string deviceHost, CancellationToken ct)` | `Task<CANConfigMessage>` | Retrieves current CAN bus configuration (e.g., bitrate, mode). |
| `GetCANInfo(string deviceHost, CancellationToken ct)` | `Task<CANInfoMessage>` | Retrieves static CAN hardware info (e.g., controller type, supported modes). |
| `GetCANState(string deviceHost, CancellationToken ct)` | `Task<CANStateMessage>` | Retrieves dynamic CAN bus state (e.g., error states, active/inactive). |
| `GetCANStats(string deviceHost, CancellationToken ct)` | `Task<CANStatsMessage>` | Retrieves CAN bus statistics (e.g., frames sent/received, errors). |
| `GetBattery(string deviceHost, CancellationToken ct)` | `Task<BatteryMessage>` | Retrieves battery status (e.g., voltage, charge level, health). |
| `GetServices(string deviceHost, CancellationToken ct)` | `Task<ServicesMessage>` | Retrieves list of running/available services on the device. |
| `GetNtp(string deviceHost, CancellationToken ct)` | `Task<NtpMessage>` | Retrieves NTP (network time protocol) configuration/status. |
| `GetPower(string deviceHost, CancellationToken ct)` | `Task<PowerMessage>` | Retrieves current power state (e.g., AC/battery, power mode). |
| `GetDeviceInfo(string deviceHost, CancellationToken ct)` | `Task<DeviceInfoMessage>` | Retrieves device identification and firmware info (e.g., model, serial, version). |
| `GetRecording(string deviceHost, CancellationToken ct)` | `Task<RecordingMessage>` | Retrieves recording status (e.g., running/stopped, file path, duration). |
| `GetNetwork(string deviceHost, CancellationToken ct)` | `Task<NetworkMessage>` | Retrieves network interface configuration (e.g., IP, gateway, DNS). |
#### **SET Methods (State Modifications)**
| Method | Return Type | Parameters | Description |
|--------|-------------|------------|-------------|
| `SetSerial(string deviceHost, SerialRequest request, CancellationToken ct)` | `Task<SerialMessage>` | `SerialRequest` | Updates serial port configuration and returns the new state. |
| `SetLEDs(string deviceHost, LedName led, LedCmd cmd, LedColor color, CancellationToken ct)` | `Task<LEDsPostMessage>` | `LedName`, `LedCmd`, `LedColor` | Sets a specific LED (`led`) to a command (`cmd`, e.g., ON/OFF/BLINK) and color (`color`). Returns updated LED state. |
| `SetClocks(string deviceHost, DateTime dateTime, CancellationToken ct)` | `Task<ClocksMessage>` | `DateTime` | Sets the device clock to `dateTime` and returns updated clock state. |
| `SetEventPinArm(string deviceHost, CancellationToken ct)` | `Task<EventPinMessage>` | — | Arms the event pin (e.g., enables triggering on external events). |
| `SetEventPinDisarm(string deviceHost, CancellationToken ct)` | `Task<EventPinMessage>` | — | Disarms the event pin (e.g., disables triggering). |
| `SyncClocks(string deviceHost, CancellationToken ct)` | `Task<ClocksMessage>` | — | Triggers clock synchronization (e.g., via NTP or PTP) and returns updated clock state. |
| `SetCANConfig(string deviceHost, CANConfigRequest request, CancellationToken ct)` | `Task<CANConfigMessage>` | `CANConfigRequest` | Updates CAN bus configuration and returns the new state. |
| `SetPowerOff(string deviceHost, CancellationToken ct)` | `Task<PowerMessage>` | — | Initiates device power-off sequence. Returns final power state. |
| `SetPowerReboot(string deviceHost, CancellationToken ct)` | `Task<PowerMessage>` | — | Initiates device reboot. Returns final power state. |
| `SetRecordingStart(string deviceHost, CancellationToken ct)` | `Task<RecordingMessage>` | — | Starts data recording and returns updated recording status. |
| `SetRecordingStop(string deviceHost, CancellationToken ct)` | `Task<RecordingMessage>` | — | Stops data recording and returns updated recording status. |
| `SetNetwork(string deviceHost, NetworkRequest request, CancellationToken ct)` | `Task<NetworkMessage>` | `NetworkRequest` | Updates network configuration and returns the new state. |
#### **File Operations**
| Method | Return Type | Parameters | Description |
|--------|-------------|------------|-------------|
| `Download(string deviceHost, string usbPath, string destinationDirectory, TimeSpan timeOut, CancellationToken ct)` | `Task` | `usbPath`, `destinationDirectory`, `timeOut` | Downloads a file from the devices USB storage (`usbPath`) to the hosts `destinationDirectory`. Throws on timeout (`timeOut`). |
| `Upload(string deviceHost, string uploadUsbPath, string sourcefile, TimeSpan timeOut, CancellationToken ct)` | `Task<StatusMessage>` | `uploadUsbPath`, `sourcefile`, `timeOut` | Uploads `sourcefile` to the devices USB storage at `uploadUsbPath`. Returns a `StatusMessage` indicating success/failure. |
| `Delete(string deviceHost, string usbPath, CancellationToken ct)` | `Task<StatusMessage>` | `usbPath` | Deletes the file at `usbPath` on the devices USB storage. Returns a `StatusMessage`. |
> **Note**: `LedName`, `LedCmd`, and `LedColor` are enums (defined elsewhere) specifying LED identifiers, commands (e.g., `On`, `Off`, `Toggle`), and colors (e.g., `Red`, `Green`, `Blue`). `SerialRequest`, `CANConfigRequest`, and `NetworkRequest` are request DTOs (defined in `CANFDApiProxy.Requests`) containing structured configuration data.
---
### **3. Invariants**
- **Consistent `deviceHost` usage**: All methods require a `deviceHost` string identifying the target device; this must be a valid address (e.g., IP or hostname) resolvable by the underlying transport.
- **Cancellation propagation**: All methods accept a `CancellationToken`; implementations must respect cancellation and propagate it to underlying I/O operations.
- **Timeout handling for file ops**: `Download`, `Upload`, and `Delete` accept a `TimeSpan timeOut`; operations exceeding this duration must fail (e.g., via `OperationCanceledException` or `TimeoutException`).
- **Idempotency not guaranteed**: SET methods may have side effects (e.g., reboot, start/stop recording); repeated calls may not be idempotent (e.g., calling `SetPowerOff` twice may not be safe).
- **State consistency**: GET methods return the *current* device state at the time of the call; SET methods return the *new* state after applying the change.
---
### **4. Dependencies**
#### **Internal Dependencies**
- **Namespaces**:
- `CANFDApiProxy.Messages` — Defines response message types (e.g., `UsbTreeMessage`, `StatusMessage`, `LEDsMessage`).
- `CANFDApiProxy.Requests` — Defines request DTOs (e.g., `SerialRequest`, `CANConfigRequest`, `NetworkRequest`).
- **System namespaces**: `System`, `System.Threading`, `System.Threading.Tasks` — Standard .NET async/await and cancellation support.
#### **External Dependencies (Inferred)**
- **Transport layer**: Not specified in the interface, but implementations (e.g., `CANFDApi` class) likely depend on HTTP clients, serial ports, or custom socket protocols.
- **Serialization**: JSON or binary serialization may be used for requests/responses (not visible here, but implied by DTO usage).
- **Consumers**: Any module requiring device control (e.g., UI, automation scripts, logging services) would depend on this interface (via DI or direct reference).
---
### **5. Gotchas**
- **No validation on `usbPath`/`destinationDirectory`**: The interface accepts arbitrary strings for file paths; implementations must handle path traversal, permissions, or invalid paths (e.g., `../secret.bin`).
- **`SetLEDs` uses discrete parameters**: Unlike other SET methods that take a request DTO, `SetLEDs` uses primitive parameters (`LedName`, `LedCmd`, `LedColor`). This may indicate legacy design or a simple, fixed API surface for LEDs.
- **`SyncClocks` vs `SetClocks`**: Two distinct clock-setting methods exist:
- `SetClocks` sets an *explicit* `DateTime`.
- `SyncClocks` triggers *automatic* sync (e.g., via NTP). Confusing usage may lead to unintended time overrides.
- **No error details in return types**: Most methods return *state* messages (e.g., `PowerMessage`, `RecordingMessage`) but not explicit error payloads. Failures likely manifest as exceptions (e.g., `HttpRequestException`, `TimeoutException`), not `StatusMessage` with error codes.
- **`Download` returns `void`**: Unlike `Upload`/`Delete`, `Download` returns `Task` (no `StatusMessage`). Clients must infer success/failure via exception handling only.
- **No batch operations**: Each GET/SET call is atomic; no support for bulk updates (e.g., setting multiple LEDs in one call).
> **None identified from source alone** for other categories (e.g., thread-safety, ordering guarantees).

View File

@@ -0,0 +1,129 @@
---
source_files:
- DataPRO/CanFDApiProxy/Messages/StatusMessage.cs
- DataPRO/CanFDApiProxy/Messages/ErrorMessage.cs
- DataPRO/CanFDApiProxy/Messages/NtpMessage.cs
- DataPRO/CanFDApiProxy/Messages/LEDsPostMessage.cs
- DataPRO/CanFDApiProxy/Messages/DiagnosticsMessage.cs
- DataPRO/CanFDApiProxy/Messages/ClocksMessage.cs
- DataPRO/CanFDApiProxy/Messages/DeviceInfoMessage.cs
- DataPRO/CanFDApiProxy/Messages/SerialMessage.cs
- DataPRO/CanFDApiProxy/Messages/ServicesMessage.cs
- DataPRO/CanFDApiProxy/Messages/NetworkMessage.cs
- DataPRO/CanFDApiProxy/Messages/CalibrationMessage.cs
- DataPRO/CanFDApiProxy/Messages/CANInfoMessage.cs
- DataPRO/CanFDApiProxy/Messages/UsbTreeMessage.cs
- DataPRO/CanFDApiProxy/Messages/BatteryMessage.cs
- DataPRO/CanFDApiProxy/Messages/RecordingMessage.cs
- DataPRO/CanFDApiProxy/Messages/PowerMessage.cs
- DataPRO/CanFDApiProxy/Messages/EventPinMessage.cs
- DataPRO/CanFDApiProxy/Messages/CANStateMessage.cs
- DataPRO/CanFDApiProxy/Messages/LEDsMessage.cs
- DataPRO/CanFDApiProxy/Messages/CANStatsMessage.cs
- DataPRO/CanFDApiProxy/Messages/CANConfigMessage.cs
- DataPRO/CanFDApiProxy/Messages/UsbStatsMessage.cs
- DataPRO/CanFDApiProxy/Messages/CANInfoInternal.cs
generated_at: "2026-04-16T04:02:31.640911+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "7eb2e08a0b1b3deb"
---
# CANFDApiProxy.Messages Module Documentation
---
## 1. Purpose
This module defines a set of data transfer objects (DTOs) used for serializing and deserializing JSON payloads exchanged with the CANFD API proxy service. These message classes represent structured responses and requests for device status, configuration, diagnostics, hardware state (e.g., LEDs, power, battery, clocks), network settings, CAN bus statistics, USB device tree, and calibration data. They serve as the contract between the API proxy layer and higher-level components (e.g., UI, logging, control logic), enabling type-safe handling of RESTful or IPC-based communication endpoints.
---
## 2. Public Interface
All classes reside in the `CANFDApiProxy.Messages` namespace and are `public`. No classes are `internal` in the public interface (though `CANInfoInternal` is declared `internal`, it is not part of the public API surface).
### Message Classes
| Class | Properties | Description |
|-------|------------|-------------|
| `StatusMessage` | `string status` | Generic status response. |
| `ErrorMessage` | `string Error` | Error response payload. |
| `NtpMessage` | `string Ntp`, `string Fallback` | NTP synchronization status and fallback address. |
| `LEDsPostMessage` | `string status`, `string reply` | Response to an LED control POST request. |
| `DiagnosticsMessageRequest` | `string format` | Request to retrieve diagnostics in a specified format (e.g., `"json"`, `"text"`). Includes custom `ToString()` override. |
| `DeviceInfoMessage` | `string Kernel_version`, `string Os_release`, `string Serial_number`, `string Version_number` | Device firmware and OS metadata. |
| `SerialMessage` | `string Serial`, `string Status` | Serial port status and current value. Includes custom `ToString()` override. |
| `ServicesMessage` | `Service[] services` | List of managed services with `Enabled`, `Name`, `Status`. |
| `NetworkMessage` | `string Current_address`, `bool Dhcp`, `string Interface`, `string Mac_address`, `string Set_address`, `string Ok` | Network interface configuration and status. |
| `CalibrationMessage` | `int Calibration_date`, `string Calibration_date_string` | Calibration timestamp (numeric and human-readable). Includes custom `ToString()` override. |
| `CANInfoMessage` | `List<CANInfo> CANInfoList` | List of CAN interface info objects (`Name`, `Info`). |
| `UsbTreeMessage` | `Child[] children`, `string name`, `string path`, `string type` | Hierarchical USB device tree node. `Child` has same fields and recursive `children`. |
| `BatteryMessage` | `decimal LoadV`, `decimal Current`, `decimal Power`, `decimal Percent`, `bool Enable` | Battery telemetry. Includes custom `ToString()` override. |
| `RecordingMessage` | `string Recording`, `bool Autoarm`, `string Recording_dir`, `string Ok`, `string Reply` | Recording state and configuration. Includes custom `ToString()` override. |
| `PowerMessage` | `bool Battery_enable`, `bool Nvin_pin`, `bool On_pin`, `bool Power_fault`, `string Status` | Power subsystem state. Includes custom `ToString()` override. |
| `EventPinMessage` | `bool? Armed`, `bool? Event`, `bool? Event_pin`, `string File_name`, `string Ok`, `string Reply` | Event pin trigger state and file context. Includes custom `ToString()` override. |
| `CANStateMessage` | `List<CANState> CANStateList` | List of CAN interface states (`Name`, `string State`, `float Last_updated`). |
| `LEDsMessage` | `List<LED> LEDs`, `Battery Battery`, `Pwr Pwr`, `Status Status`, `Sts Sts` | LED states (color per LED), plus global LED groups. `LED` has `Name`, `Red`, `Green`, `Blue`. |
| `CANStatsMessage` | `List<CANStats> CANStatsList` | List of CAN interface statistics (`Name`, `Last_updated`, `Std_data`, `Std_remote`, `Ext_data`, `Ext_remote`, `Err_frame`, `Bus_load`, `Overruns`). |
| `CANConfigMessage` | `List<CANConfig> CANConfigList`, `Pipe Pipe`, `string Status` | CAN bus configuration for up to 4 interfaces (`CANConfig`), plus pipe path and status. Includes `CreateCanConfigRequest()` factory method (see below). |
| `UsbStatsMessage` | `Filesystem Filesystem`, `Swissbit Swissbit`, `Traffic Traffic` | USB storage health and throughput stats. Nested types: `Filesystem`, `Swissbit`, `Lifetime_Info`, `Spare_Block_Info`, `Erase_Info`, `Average_Erase_Count`, `Max_Erase_Count`, `Rated_Erase_Count`, `Traffic`. |
### Factory Method
| Method | Signature | Description |
|--------|-----------|-------------|
| `CANConfigMessage.CreateCanConfigRequest` | `static CANConfigRequest CreateCanConfigRequest(CANConfigMessage canConfigMessage)` | Converts a `CANConfigMessage` into a `CANConfigRequest` (from `CANFDApiProxy.Requests`). Maps the first four `CANConfig` entries to `can1``can4` fields. Returns a `CANConfigRequest` with `Status` set to exception message on failure. |
### Helper Classes (Public)
| Class | Properties | Description |
|-------|------------|-------------|
| `Service` | `bool Enabled`, `string Name`, `string Status` | Represents a service in `ServicesMessage`. |
| `LED` | `string Name`, `bool Red`, `bool Green`, `bool Blue` | Represents a single LED in `LEDsMessage`. |
| `CANInfo` | `string Name`, `string Info` | Represents CAN interface info in `CANInfoMessage`. Constructor enforces non-null `name`/`info`. |
| `CANState` | `string Name`, `string State`, `float Last_updated` | Represents CAN interface state in `CANStateMessage`. Constructor enforces non-null `name`/`state`. |
| `CANStats` | `string Name`, `float Last_updated`, `int Std_data`, `int Std_remote`, `int Ext_data`, `int Ext_remote`, `int Err_frame`, `float Bus_load`, `int Overruns` | Represents CAN interface stats in `CANStatsMessage`. Constructor enforces non-null `name`. |
| `CANConfig` | `string Name`, `int Base_or_arb_bitrate`, `int Base_or_arb_sjw`, `int Data_bitrate`, `int Data_sjw`, `string Filetype`, `bool Included`, `bool Is_fd` | Represents CAN interface configuration in `CANConfigMessage`. Constructor enforces non-null `name`/`filetype`. |
> **Note**: `CANConfigRequest` is imported from `CANFDApiProxy.Requests` and is not defined here. Its structure is inferred from usage in `CreateCanConfigRequest`.
---
## 3. Invariants
- **Non-null `Name` fields**: In `CANInfo`, `CANState`, `CANStats`, and `CANConfig`, the `Name` property is set via constructor and is read-only (`get;` only), implying it must be non-null at construction and never changed afterward.
- **Fixed CAN interface count**: `CANConfigMessage.CreateCanConfigRequest` assumes exactly 4 CAN interfaces (`can1``can4`) and accesses `CANConfigArray[0]` through `[3]`. Index out-of-range exceptions will occur if the list has fewer than 4 items.
- **Nullable booleans**: Fields like `Armed`, `Event`, `Event_pin`, `Rtc_present`, `Rtc_setup` are declared as `bool?`, indicating they may be absent or unknown.
- **Numeric precision**: Battery metrics (`LoadV`, `Current`, `Power`, `Percent`) use `decimal` for precision; CAN stats use `int` for counters and `float` for time/load metrics.
- **String formatting**: `Calibration_date` is an `int` (likely Unix epoch), while `Calibration_date_string` provides human-readable form—both must be consistent.
- **LED color state**: In `LEDsMessage.LED`, each LEDs color (`Red`, `Green`, `Blue`) is a `bool`, implying binary on/off per channel.
---
## 4. Dependencies
### Imports/References
- `System.Collections.Generic` (used in `CANInfoMessage`, `CANStateMessage`, `CANStatsMessage`, `LEDsMessage`)
- `System.Text` (used in `CANConfigMessage.ToString()` via `StringBuilder`)
- `CANFDApiProxy.Requests` (used in `CANConfigMessage.CreateCanConfigRequest()` to construct `CANConfigRequest`)
### Inferred Usage
- **Serialization**: All classes are simple POCOs with public setters, designed for JSON deserialization (e.g., via `System.Text.Json` or `Newtonsoft.Json`).
- **API layer**: These messages are likely consumed/produced by HTTP handlers, gRPC services, or IPC endpoints in `CANFDApiProxy`.
- **Request conversion**: `CreateCanConfigRequest` implies tight coupling with `CANFDApiProxy.Requests.CANConfigRequest`, suggesting this module is part of a request/response pipeline.
---
## 5. Gotchas
- **`CANConfigMessage` assumes 4 CAN interfaces**: Hardcoded array indices `[0]``[3]` in `CreateCanConfigRequest` will throw `IndexOutOfRangeException` if the input `CANConfigList` has fewer than 4 items. No validation is performed.
- **Inconsistent property casing**: Some properties use `snake_case` (`status`, `Error`, `Calibration_date`, `Current_address`) while others use `PascalCase` (`Kernel_version`, `Serial_number`). This may reflect JSON payload conventions but can cause deserialization issues if not handled consistently (e.g., via `JsonPropertyName` attributes).
- **`CANInfoInternal` is internal**: Though defined in the same file, `CANInfoInternal` and its nested types (`Can1`, `Can2`, etc.) are `internal` and not part of the public API. Do not rely on them externally.
- **Missing null-safety**: None of the classes perform null checks in constructors or setters. Passing `null` to `CANInfo`/`CANState`/`CANStats`/`CANConfig` constructors will result in `NullReferenceException` at runtime.
- **`Calibration_date` type**: `int` for a date is ambiguous—could be Unix timestamp (seconds) or `YYYYMMDD` integer. Clarify with API spec.
- **`Ok` vs `status`/`Status`**: Multiple classes use `Ok` (e.g., `NetworkMessage`, `RecordingMessage`, `EventPinMessage`) while others use `status`/`Status`. This inconsistency may indicate legacy naming or different API versions.
- **`UsbStatsMessage` complexity**: Deeply nested types (`Lifetime_Info`, `Spare_Block_Info`, etc.) suggest complex SSD health reporting. Ensure all fields are populated before use; missing nested objects may cause `NullReferenceException`.
- **`ToString()` overrides**: Several classes override `ToString()` for debugging, but these are not used in serialization. Do not rely on them for logging or persistence.
None identified beyond the above.

View File

@@ -0,0 +1,37 @@
---
source_files:
- DataPRO/CanFDApiProxy/Properties/AssemblyInfo.cs
generated_at: "2026-04-16T04:02:38.399382+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "09de3f64edd0a63b"
---
# Properties
## 1. Purpose
This module is a .NET assembly named **CANFDApiProxy**, intended to serve as a proxy or wrapper layer for interacting with a CAN FD (Controller Area Network Flexible Data-rate) API—likely the Vector CANoe/CANoe.FD or similar automotive bus communication stack. Its role is to abstract low-level CAN FD operations (e.g., message transmission, reception, channel management) behind a managed .NET interface, enabling integration with higher-level .NET applications (e.g., test automation, simulation, or diagnostics tools) while maintaining compatibility with unmanaged CAN FD driver libraries via COM interop or P/Invoke. The assembly is versioned at `1.0.0.0`, is not visible to COM by default, and is owned by **VPG** (presumably Vector Product Group or a related entity).
## 2. Public Interface
**No public types (classes, interfaces, structs, enums, or delegates) are defined in this file.**
The file contains only assembly-level metadata attributes (e.g., `AssemblyTitle`, `AssemblyVersion`, `ComVisible`, `Guid`). It does not declare any executable code, types, or public APIs. Therefore, there are **no public functions, classes, or methods** documented here.
## 3. Invariants
- The assembly identity is fixed:
- `AssemblyTitle` = `"CANFDApiProxy"`
- `AssemblyCompany` = `"VPG"`
- `AssemblyCopyright` = `"Copyright © VPG 2025"`
- `AssemblyVersion` and `AssemblyFileVersion` = `"1.0.0.0"`
- `ComVisible` is set to `false`, meaning types in this assembly are *not* exposed to COM unless explicitly overridden at the type level (though no types are defined here, so this has no runtime effect).
- The `Guid` attribute (`0a42ee20-660c-468d-9511-c32c9037cb15`) uniquely identifies the typelib if the assembly *were* exposed to COM (currently disabled).
## 4. Dependencies
- **Runtime dependencies**: This assembly targets the .NET Framework (evidenced by `System.Reflection`, `System.Runtime.CompilerServices`, `System.Runtime.InteropServices`).
- **External dependencies**: None directly declared in this file. However, given the name *CANFDApiProxy*, it is strongly implied that this assembly depends on unmanaged CAN FD libraries (e.g., `canfdapi.dll`, `vxlapi_fd.dll`, or Vectors CANoe API), likely via P/Invoke or COM interop—but such dependencies are not visible in *this* file and must be inferred from other source files (not provided).
- **Dependents**: Unknown from this file alone. Presumably consumed by other .NET modules in the VPG ecosystem (e.g., test harnesses, UI applications, or simulation frameworks).
## 5. Gotchas
- **Misleading module scope**: This file contains *no implementation logic*—only metadata. Developers may mistakenly expect to find proxy API definitions here; the actual proxy types are likely in other files (e.g., `CanFDApiProxy.cs`, `CANFDProxy.cs`, or similar).
- **Versioning**: Both `AssemblyVersion` and `AssemblyFileVersion` are hardcoded to `1.0.0.0`. This may indicate an initial release or placeholder state; ensure versioning is updated consistently across builds to avoid deployment or binding issues.
- **COM visibility**: `ComVisible(false)` is set at the assembly level. If COM interop is intended, this must be overridden on specific types (e.g., `[ComVisible(true)]` on a public interface or class), but again, no such types exist in this file.
- **No documentation comments**: The file lacks XML documentation (`///` comments), so tooling (e.g., IntelliSense, API docs) will not surface metadata about the assembly beyond its attributes.

View File

@@ -0,0 +1,84 @@
---
source_files:
- DataPRO/CanFDApiProxy/Requests/SerialRequest.cs
- DataPRO/CanFDApiProxy/Requests/CanPostRequest.cs
- DataPRO/CanFDApiProxy/Requests/FileRequest.cs
- DataPRO/CanFDApiProxy/Requests/ClocksRequest.cs
- DataPRO/CanFDApiProxy/Requests/NetworkRequest.cs
- DataPRO/CanFDApiProxy/Requests/LEDsRequest.cs
- DataPRO/CanFDApiProxy/Requests/CANConfigRequest.cs
- DataPRO/CanFDApiProxy/Requests/CanConfigItem.cs
generated_at: "2026-04-16T04:02:28.102963+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "b4b7d8b4fcb0bb80"
---
# Requests
## Documentation: `CANFDApiProxy.Requests` Module
---
### 1. **Purpose**
This module defines a set of request classes used to serialize configuration and control commands for a CAN FD device API proxy layer. Each class corresponds to a specific type of operation (e.g., network configuration, LED control, CAN bus configuration, file operations, clock synchronization), and is intended for use in constructing JSON payloads sent to a backend service or embedded device. The module serves as a data contract layer—encapsulating structured input for remote API endpoints—without implementing business logic or I/O operations itself.
---
### 2. **Public Interface**
All classes and enums are declared in the `CANFDApiProxy.Requests` namespace.
| Name | Type | Signature & Description |
|------|------|-------------------------|
| `SerialRequest` | class | `public class SerialRequest { public string serial { get; set; } }`<br>• Represents a request to perform an operation using a device serial number. |
| `NetworkRequest` | class | `public class NetworkRequest { public bool dhcp { get; set; } public string set_address { get; set; } }`<br>• Configures network settings: `dhcp` enables/disables DHCP; `set_address` specifies a static IP address (format unspecified). |
| `LEDsRequest` | class | `public class LEDsRequest { public string led { get; set; } public string cmd { get; set; } public string color { get; set; } }`<br>• Controls an LED: `led` identifies the LED (via `LedName`), `cmd` is `"on"`/`"off"`, `color` is `"red"`, `"green"`, or `"blue"` (via `LedColor`). |
| `LedColor` | enum | `public enum LedColor { red, green, blue }`<br>• Valid LED colors. |
| `LedCmd` | enum | `public enum LedCmd { on, off }`<br>• Valid LED commands. |
| `LedName` | enum | `public enum LedName { can1, can2, can3, can4, pwr, sts, status }`<br>• Valid LED identifiers. |
| `CANConfigRequest` | class | `public class CANConfigRequest { public config config { get; set; } public string Status { get; set; } }`<br>• Top-level request for CAN bus configuration. Contains a `config` object and an optional `Status` string (e.g., `"success"`). |
| `config` | class | `public class config { public CanConfigItem can1 { get; set; } public CanConfigItem can2 { get; set; } public CanConfigItem can3 { get; set; } public CanConfigItem can4 { get; set; } }`<br>• Holds per-CAN-channel configuration (up to 4 channels). |
| `CanConfigItem` | class | `public class CanConfigItem(int base_or_arb_bitrate, int base_or_arb_sjw, int data_bitrate, int data_sjw, string filetype, bool included, bool is_fd)`<br>• Constructor initializes all properties.<br>• Properties:<br> - `base_or_arb_bitrate`: int — Bitrate for arbitration/base phase (e.g., 500000).<br> - `base_or_arb_sjw`: int — Synchronization jump width for arbitration/base phase.<br> - `data_bitrate`: int — Bitrate for data phase (used only if `is_fd == true`).<br> - `data_sjw`: int — SJW for data phase.<br> - `filetype`: string — File type identifier (e.g., `"bin"`, `"hex"`).<br> - `included`: bool — Whether this channels config is active.<br> - `is_fd`: bool — Whether CAN FD mode is enabled.<br>• Includes `ToString()` overrides for debugging. |
> **Note**: `CanConfigItem` has no parameterless constructor. All instances must be created via the explicit constructor.
---
### 3. **Invariants**
- `SerialRequest.serial` and `NetworkRequest.set_address` are expected to be non-null and non-empty when used, though not enforced in the class itself.
- `LEDsRequest.led`, `cmd`, and `color` are expected to match values from `LedName`, `LedCmd`, and `LedColor` respectively—**but no runtime validation is performed**; mismatches may cause downstream errors.
- `CanConfigItem` instances must be constructed with all 7 parameters; partial initialization is impossible due to lack of a parameterless constructor.
- `config` object expects exactly 4 `CanConfigItem` properties (`can1``can4`), but they may be `null` unless explicitly set.
- `CANConfigRequest.Status` is a string field with no defined format or allowed values in this module.
---
### 4. **Dependencies**
- **Internal usage**: `CANConfigRequest` references `config`, which is defined in the same namespace (`CANFDApiProxy.Requests`).
- **External usage**: `CANConfigRequest` imports `using CANFDApiProxy.Messages;`, indicating a dependency on the `CANFDApiProxy.Messages` namespace (not provided in source). This suggests `config` or related types may be shared or extended there.
- **Consumers**: These request classes are likely used by higher-level API client classes (e.g., in `CANFDApiProxy.Client` or similar) to serialize requests to JSON for HTTP or serial transport.
- **No external libraries** are imported beyond the standard `System` (implied by C# syntax).
---
### 5. **Gotchas**
- **No validation**: None of the request classes perform input validation (e.g., checking `serial` is non-empty, `set_address` is a valid IP, or `led`/`cmd`/`color` match expected enums). Validation must be handled externally.
- **Enum mismatch risk**: `LEDsRequest` uses `string` properties (`led`, `cmd`, `color`) instead of the strongly-typed `LedName`, `LedCmd`, and `LedColor` enums. This invites typos (e.g., `"Red"` vs `"red"`) and runtime errors.
- **`CanConfigItem` constructor is mandatory**: Since there is no parameterless constructor, deserialization frameworks (e.g., `System.Text.Json`) may fail unless custom converters or `JsonConstructor` attributes are applied.
- **Ambiguous field semantics**:
- `NetworkRequest.set_address`s format (e.g., CIDR notation, `"192.168.1.10"`) is unspecified.
- `FileRequest.path` and `ClocksRequest.time` are defined but no usage context is provided in this module.
- `CANConfigRequest.Status` is present in the request type, suggesting it may be used for client-to-server feedback—unusual for a request object.
- **Inconsistent visibility**: `SerialRequest` and `NetworkRequest` are `public`, while `CanPostRequest`, `FileRequest`, and `ClocksRequest` are `internal`. This implies only a subset of request types are part of the public API surface.
- **No documentation on `filetype`**: Its purpose (e.g., firmware image type, config file format) is unclear from the source.
> **None identified from source alone** for `CanPostRequest`, `FileRequest`, and `ClocksRequest` beyond visibility and field names—behavior is entirely inferred from field names and naming conventions.
---
*End of documentation.*