Hi Jon,
2x things - firstly I found the currently selected device is reflected in the SSE stream so nothing amiss there, and no action require. But I have found a fairly major oversight (unless I’m missing something).
I’m testing with LightBurn Pro 2.2.00 and a JCZFiber-controlled 5W UV galvo laser.
I’ve encountered an issue with the /api/events SSE stream: Framing and actual marking operations both appear to generate job events with state: "running".
This makes it impossible for my application to reliably determine whether the laser is framing or executing an actual job.
Tests performed
1. Framing only
With the Framing window open, the SSE stream reports:
event: job | data: {"progress":97.8,"state":"running"}
event: job | data: {"progress":99.2,"state":"running"}
event: job | data: {"progress":99.5,"state":"running"}
event: job | data: {"state":"idle"}
No engraving was performed, but my application interpreted this as a job.
2. Actual engraving without framing
I disabled LightBurn’s “Require Framing Before Start” option and ran a real engraving job lasting approximately 14 seconds.
The SSE stream reported:
[13:38:51.897] event: job | data: {"progress":100,"state":"running"}
[13:39:06.497] event: job | data: {"state":"idle"}
The event interval was approximately 14.6 seconds, matching the actual job duration.
3. Framing followed by engraving
With framing active before the engraving operation, the stream continued reporting running events without a reliable idle transition between the operations.
Requested enhancement
Could the REST API expose the type of operation currently running?
For example:
{"state":"running","operation":"framing"}
versus:
{"state":"running","operation":"marking"}
Alternatively, separate SSE events for framing start/stop and marking start/stop would work equally well.
Ideally, the events would also include timestamps corresponding to the actual operation start and completion, rather than just the time the API notification was generated or received.
Why this matters
My application needs to measure total elapsed marking job time, from the start of the actual operation until completion, including galvo movements between shapes.
It does not need to measure individual laser firing pulses.
Framing time must be excluded completely, and timing must be fully automatic without any manual interaction with the companion application.
The existing state and progress fields don’t appear sufficient to make this distinction, as both framing and engraving can report progress values close to or equal to 100%.
Is there already an API property or event that identifies these operations separately? If not, would it be possible to add this to a future release?
Thanks!
