--pipe
<pipename>Stream newline-delimited JSON progress updates to a pre-existing Linux named pipe, emitting plate and total percent alongside a message or warning key on each forward-progress event.
Details
When --pipe is supplied with a filesystem path, the slicer opens that path as a writable named pipe (OS FIFO) and streams newline-delimited JSON progress updates to it throughout the slice. A dedicated background thread wakes on each progress change, serializes the state to JSON, and writes it to the pipe descriptor. The option is parsed on all platforms, but the callback manager that actually performs the writes is compiled in only on Linux; on macOS and Windows the flag is accepted without error and then silently does nothing.\n\nEach line written to the pipe is a JSON object with five keys. plate_index and plate_count are integers identifying which plate is being sliced and how many plates exist in the job. plate_percent is an integer from 0 to 100 representing progress through the current plate. total_percent is a derived overall progress value: before plate-level slicing begins it mirrors plate_percent directly; once plate-level slicing starts it is computed as 3 + (plate_index - 1) * 90 / plate_count + plate_percent * 0.9 / plate_count, reserving the first 3 points for file loading and capping the slicing range at roughly 93. The fifth key is either message or warning, never both: normal progress updates carry message, and updates that correspond to a slicing warning carry warning with the same text payload. Progress updates are deduplicated by forward advancement -- if the incoming percent is not higher than the last reported percent, the write is skipped unless the update carries a warning, so message rate is naturally bounded by integer percent increments rather than by a timer.\n\nThe pipe must exist as a FIFO on the filesystem before the slicer starts. The slicer opens it with O_WRONLY | O_NONBLOCK and retries up to 50 times at 20 ms intervals (roughly one second total). If no reader has the read end open within that window, the open fails and the callback manager never starts; slicing continues but no progress is sent to the pipe, with no error exit. Each serialized message is buffered at 512 bytes; a status string long enough to push the JSON object past that limit will be silently truncated.
Examples
{"plate_index": 1, "plate_count": 2, "plate_percent": 47, "total_percent": 24, "message": "Generating supports"}{"plate_index": 1, "plate_count": 2, "plate_percent": 62, "total_percent": 30, "warning": "Layer height exceeds limit"}Watch out for
- ▲ Linux-only at runtime. The option is accepted by the parser on macOS and Windows, but the pipe callback manager is compiled in only for Linux targets. Passing `--pipe` on other platforms has no effect.
- ▲ The named pipe must already exist and have a reader attached before slicing starts. The slicer retries the open for roughly one second, then gives up silently. A race where the reader is slow to attach means no progress is emitted at all.
- ▲ `message` and `warning` are mutually exclusive keys. Each JSON object contains one or the other, not both. Consumer code that expects `message` on every object will miss warning-carrying updates, and code that assumes `warning` is always null-safe will mis-parse normal progress lines.
- ▲ Each JSON message is hard-capped at 512 bytes. A particularly long status string will be truncated mid-object, producing invalid JSON on the pipe.
Related flags
Sign up for free today
No credit card required. Connect unlimited printers and get production automation running in minutes.