FlashForge printers use different internal state models depending on the firmware generation. This document maps these states to a unified client model for consistent application behavior across all printer families.

Applications should normalize printer status into these high-level states for consistent behavior:

Source: HTTP POST /detail

Field: status (string)

The canceling state is sometimes used transiently during a PAUSE sequence, not just during cancellation.

Recommendation: Treat canceling as BUSY and continue polling.

Method: Poll /detail every 1-2 seconds

POST /detail HTTP/1.1
Content-Type: application/json

{
  "serialNumber": "SNADVA5MXXXXX",
  "checkCode": "12345"
}

Response:

{
  "code": 0,
  "message": "Success",
  "detail": {
    "status": "printing",
    "printProgress": 0.45,
    "printLayer": 50,
    "printFileName": "Benchy.gcode"
  }
}

ready -> heating -> printing -> completed -> ready
ready -> heating -> printing -> pausing -> pause -> printing
ready -> heating -> printing -> canceling -> ready
ready -> busy -> ready
printing -> error

Source: TCP commands ~M27 or ~M119

Format: Text response

CMD M27 Received.
SD printing byte 0/100
Layer: 0/0
ok

The last line before ok contains the state information.

CMD M119 Received.
Endstop: X-max: 110 Y-max: 110 Z-min: 0
MachineStatus: READY
MoveMode: READY
Status: S:1 L:0 J:0 F:0
LED: 1
CurrentFile:
ok

Key Field: MachineStatus

READY is a distinct state meaning "M23 (File Select) successful". It effectively means IDLE but prepared to print.

Recommendation: Treat READY as IDLE.

Cloud print states (BUILDING_FROM_SD) may leak into local queries on some firmware versions.

Recommendation: Treat any "BUILDING*" string as PRINTING.

Method: Poll ~M27 every 1-2 seconds via TCP port 8899

Send: ~M27
Response:
CMD M27 Received.
SD printing byte 45234/123456
Layer: 23/100
ok

Parse the last line of the response for the state string.

         +-------+
         | IDLE  |
         +-------+
             |
             | Start Print (M23/HTTP printGcode)
             v
         +-------+
         | BUSY  |  (heating, file prep)
         +-------+
             |
             | Print begins
             v
      +------------+
      | PRINTING   |<--------+
      +------------+         |
             |               |
             | Pause         | Resume
             v               |
        +---------+          |
        | PAUSED  |----------+
        +---------+
             |
             | Cancel or Complete
             v
         +-------+
         | IDLE  |
         +-------+

    [Any State]
         |
         | Error occurs
         v
    +---------+
    | ERROR   |
    +---------+
         |
         | User intervention / Clear
         v
    +-------+
    | IDLE  |
    +-------+

Track the previous state to detect transitions. When the state changes, fire an event handler and record the timestamp.

If an unrecognized state is encountered:

1. Log the raw state value for debugging
2. Treat as BUSY (safe default)
3. Continue polling
4. Update state mapping as needed

When building applications that support multiple printer families:

1. Always normalize to the Unified Client Model
2. Handle both modern and legacy state sources
3. Use discovery protocol to identify printer family
4. Select appropriate state query method based on family