58 lines
5.7 KiB
Markdown
58 lines
5.7 KiB
Markdown
|
|
|
|
## 1. Introduction
|
|
|
|
This document outlines the mechanism employed by the software system to command a connected instrument to switch its communication protocol, specifically to the proprietary Maselli bidirectional protocol. This is a critical function, particularly when instruments might initialize in, or be operating under, other protocols such as ADAM or PROFIBUS, which are often predominantly unidirectional (instrument primarily transmits data) and do not support the full range of commands required by the software.
|
|
|
|
The core of this mechanism relies on sending specific "Super Commands" during the initial phases of communication establishment.
|
|
|
|
## 2. The Challenge: Unidirectional Protocols
|
|
|
|
Certain industrial protocols, like ADAM or PROFIBUS (in some configurations), are designed for instruments to primarily broadcast data or respond to a very limited set of polling commands. In such states, the instrument may not be actively "listening" for or capable of processing the complex command set of the Maselli proprietary protocol.
|
|
|
|
To enable full bidirectional communication, data retrieval, parameter modification, and advanced operations (like image acquisition), the instrument must be switched from such a mode into the Maselli proprietary protocol mode.
|
|
|
|
## 3. The Solution: "Super Commands" for Protocol Forcing
|
|
|
|
The software utilizes a system of "Super Commands" to actively instruct an instrument to change its operational protocol.
|
|
|
|
**Key Components:**
|
|
|
|
* **`ClassStrumentoMaselli`**:
|
|
* Each instrument type (derived from `ClassStrumentoMaselli`) defines a list of `SuperComandi` (of type `List<ComandiDaInviare>`).
|
|
* These `SuperComandi` are pre-defined command sequences specifically designed to be understood by the instrument even if it's not fully in the Maselli protocol mode. They might be very basic commands or specific byte sequences that trigger a mode switch in the instrument's firmware.
|
|
* The `ModalitaMaselli` boolean flag within this class tracks whether the instrument is confirmed to be operating in the Maselli protocol.
|
|
* Flags like `ForzaProtocolloADAM` or `ForzaProtocolloPROFIBUS` indicate the system's awareness that an instrument might need to be switched *from* these protocols.
|
|
|
|
* **`Uc09_Utility.ClassSerialeStrumenti` (Instrument Communication Service)**:
|
|
* This service manages the communication lifecycle for each instrument.
|
|
* It employs a state machine with specific phases for communication establishment. One crucial phase is `SEND_SUPER_COMMAND_FORCED_PROTOCOLL`.
|
|
* During this phase, the `ClassSerialeStrumenti` retrieves the `SuperComandi` from the respective `ClassStrumentoMaselli` instance and sends them to the instrument.
|
|
|
|
## 4. Mechanism of Operation
|
|
|
|
1. **Initialization**: When communication with an instrument is initiated, `ClassSerialeStrumenti` begins its state machine.
|
|
2. **Entering Protocol Forcing Phase**: The service enters the `SEND_SUPER_COMMAND_FORCED_PROTOCOLL` phase (or a similar initial phase dedicated to sending these critical commands).
|
|
3. **Dispatching Super Commands**:
|
|
* The `SuperComandi` defined for the specific instrument type are retrieved.
|
|
* These commands are formatted according to the basic requirements of the Maselli protocol (e.g., `>LLLLAA T;FFFVALUE;cc\r`) but their `VALUE` or `FFF` (Function Number) part might represent a special instruction for protocol switching.
|
|
* The commands are sent to the instrument.
|
|
4. **Instrument Response and State Change**:
|
|
* The instrument, upon receiving and recognizing a valid "Super Command" for protocol switching, is expected to change its internal communication mode to the Maselli proprietary protocol.
|
|
* It should then respond in a way that confirms this change, or at least becomes receptive to further Maselli protocol commands (like identification requests).
|
|
5. **Confirmation and Transition**:
|
|
* `ClassSerialeStrumenti` awaits a response. A successful protocol switch might be confirmed by:
|
|
* A specific acknowledgment response from the instrument.
|
|
* The instrument subsequently responding correctly to standard Maselli protocol identification commands (e.g., requests for memory name or serial number).
|
|
* Once confirmed, the `ModalitaMaselli` flag for the instrument is set to `true`.
|
|
* The `ProtocolChangedToMaselli` event may be raised by `ClassSerialeStrumenti` to signal that the instrument is now ready for full Maselli protocol communication.
|
|
* The communication service then transitions to subsequent phases like `RECOGNIZE_EQUIPMENT` and `LINKED`, now expecting full Maselli protocol interaction.
|
|
|
|
## 5. Rationale and Importance
|
|
|
|
* **Enabling Bidirectional Control**: The Maselli proprietary protocol is bidirectional, allowing the software to send a wide array of commands (read, write, execute functions, request images) and receive detailed responses. This level of control is generally not possible if the instrument remains in a unidirectional or limited-command-set protocol.
|
|
* **Unlocking Full Functionality**: Access to instrument parameters, calibration routines, data acquisition, and other advanced features managed by the software relies on the instrument operating under the Maselli protocol.
|
|
* **Standardized Interaction**: By forcing all instruments into a common, feature-rich protocol, the software can interact with diverse instrument types in a standardized manner once the initial protocol switch is successful.
|
|
|
|
In essence, the "Super Command" mechanism is a foundational step in the communication process, acting as a software-initiated handshake to ensure the instrument is in the correct operational mode for detailed and comprehensive interaction. Without this active forcing mechanism, communication with instruments that default to or are stuck in other protocol modes would be severely limited or impossible.
|