[WARIO2412]

Before, M495 (path origin, margin, Z probe, auto leveling) runs in the active WCS. When the active WCS differed from the first wcs mentioned in the file before the first move, the Z probe was stored in the wrong WCS and the path origin was taken in the wrong place.

• When a file is loaded, find the WCS it selects before its first move (G53 moves do not count) and send it before M495 on Run and on Margin/ZProbe/AutoLevel. Resume at line is unchanged.
• The start job popup shows that WCS: origin label, origin point, work area, Z probe and leveling points with its rotation, the origin popup and the anchor preselection. The values of a WCS other than the active one come from "get wcs", which the popup requests when it opens.
• Set work origin writes the shown WCS (G10 L2 Pn).

Summary

Contributor checklist

• I am a human submitting this pull request.
• I have read and understand every changed line, and I take responsibility
  for the complete change.
• Pre-commit checks (poetry run pre-commit run --all-files) passes with no errors.
• The changes have been tested with real hardware.
• I have read and understood the contributions guidelines

[SergeBakharev]

Sorry Mark, I forgot to review this last week.

I see two edge cases:

On 4th-axis gcode, apply() still clears rotation with G10 L2 R0 P0 (via Controller.wcsClearRotation()) before the new workspace selection. P0 is the coordinate system that is active now. The job then runs M495 in the program’s system, whose rotation was left alone, and the system the user was actually in loses its rotation.

The “go to path origin” code (in Makera.apply()) still compares CNC.vars["wx"] / wy with xmin / xmax. Those bounds are in the gcode program’s coordinates. wx / wy are in the active system. With G54 active and the file starting in G55, that test enables or omits M495’s P1 from the wrong position, and only then does the code switch system.

It's always been a wierd to me that these are immediately executed, maybe it would simpler if they were buffered.

[WARIO2412]

Sorry Mark, I forgot to review this last week.

I see two edge cases:

On 4th-axis gcode, apply() still clears rotation with G10 L2 R0 P0 (via Controller.wcsClearRotation()) before the new workspace selection. P0 is the coordinate system that is active now. The job then runs M495 in the program’s system, whose rotation was left alone, and the system the user was actually in loses its rotation.

The “go to path origin” code (in Makera.apply()) still compares CNC.vars["wx"] / wy with xmin / xmax. Those bounds are in the gcode program’s coordinates. wx / wy are in the active system. With G54 active and the file starting in G55, that test enables or omits M495’s P1 from the wrong position, and only then does the code switch system.

It's always been a wierd to me that these are immediately executed, maybe it would simpler if they were buffered.

I'll have a look at this soon. After craboulas upcoming changes, we should think about if resetting the rotation is necessary. It was meant to be a safety feature for unaware users. But our software has become more powerful and acts more like a grown controller software, where a wcs rotation wouldn't be reset.

I'll fix the second point and I'll also add visualization for all boundaries in all wcs that are used.

[WARIO2412]

I think I'll be ready to publish the fixes soon!