No development hasn’t stopped but it is not actively happening as I’ve heard of no issues. That said, I’m interested in understanding issues.
If you are going to look at the pp, make sure you use the zip at the top of this thread - I’m not sure what GRBL.zip contains.
To determine if the problem you are describing is a pp issue, do the following. Create the simplest F360 project you can that has the issue then enable the debug comment level. This should show you detailed information to help you understand what the pp is receiving and doing.
If you isolate a problem, post the relevant part of the debug output that is wrong and then your expected results.
The pp is basically a formatter, it doesn’t interpret the GCode (other than the enhancements documented). Offsetting by a coordinate position I would assume would be done by F360 prior to the pp being pasted the operation to be output - though I could be wrong.
What you’re describing points to two related gaps in the PP:
WCS selection: The PP currently does not read F360’s WCS setting and map it to G54/G55/G56 etc. It always operates in the default coordinate system. Support for this would require explicitly reading currentSection.workOffset and emitting the corresponding G5x command.
Probe target register: Even if WCS were respected, the probe routine stores its result into a fixed register (effectively G54/P1). To probe into G56, it would need to use G10 L20 P3 Z0 (or the equivalent for X/Y).
As a workaround for now: since you’ve already manually set G56 in your controller, you can add G56 as a manual NC command at the top of your F360 setup (via the “Manual NC” operation). This will cause the PP to emit it verbatim at that point in the gcode, and your pre-configured G56 offset will take effect from there.
WCS support is on my radar as a future enhancement. If others are using multiple WCS offsets, please chime in — it’ll help prioritize.
Unfortunately, at this time I can’t commit to a timeline to make these changes but will add it to my list of things to do