search

winder / Universal-G-Code-Sender

A cross-platform G-Code sender for GRBL, Smoothieware, TinyG and G2core.
http://winder.github.io/ugs_website/
GNU General Public License v3.0
1.88k stars 761 forks source link

Visualizer machine boundary should consider GRBL homing direction mask $23 #2301

Open bertieconfundo opened 1 year ago

bertieconfundo commented 1 year ago

Description

I noticed that the Visualizer now includes a rendering of the machine boundary. Because I don't run my machine in the negative machine space on X and Y axes, my GRBL homing bit mask $23=3, (X and Y are inverted), and I had to manually go into the Visualizer Options and invert these axes to get the machine boundary to show up in the right place. Since you are already getting the machine boundary dimensions from the controller, why not also get the homing direction bit mask so you know which axes to invert? Either that, or use the homing direction bit mask to adjust the sign of the machine boundary limits so that it's not necessary to manually configure the polarity of the axes in the Visualizer Options.

breiler commented 1 year ago

When you write I don't run my machine in the negative machine space on X and Y axes, do you mean that you have compiled GRBL with with HOMING_FORCE_SET_ORIGIN? https://github.com/gnea/grbl/blob/bfb67f0c7963fe3ce4aaf8a97f9009ea5a8db36e/grbl/config.h#L129

This has been a long time issue where the bounding box ends up in the wrong quadrant and was introduced when I "fixed" this for a user running with "HOMING_FORCE_SET_ORIGIN". So for everyone running the default settings (using negative space) the bounding box ends up in the wrong quadrant.

bertieconfundo commented 1 year ago

I have compiled GRBL with HOMING_FORCE_SET_ORIGIN defined. My homing direction mask is 3 (x homes in the negative direction, y homes in the negative direction, and z homes in the positive direction). So, with regard to machine coordinates, I operate in the positive space for X and Y, and in the negative space for Z. The only way for the visualizer to automatically know this would be to get the homing invert mask from the grbl firmware settings, but I think there's probably more to it than that - I had forgotten about HOMING_FORCE_SET_ORIGIN. I'm not sure if this is something you can do completely automatically or not...

breiler commented 1 year ago

OK, now I just feel stupid.

GRBL does seem to report this: https://github.com/gnea/grbl/blob/bfb67f0c7963fe3ce4aaf8a97f9009ea5a8db36e/grbl/report.c#L391

So we could add a new capability here (like MACHINE_COORDINATES_IN_POSITIVE_SPACE): https://github.com/winder/Universal-G-Code-Sender/blob/master/ugs-core/src/com/willwinder/universalgcodesender/CapabilitiesConstants.java

When this is available we'll invert the bounding box like you suggested. In other words reverting this: https://github.com/winder/Universal-G-Code-Sender/pull/2285