Sienci-Labs / gsender

Connect to and control Grbl-based CNCs with ease
https://sienci.com/gsender/
Other
178 stars 41 forks source link

Diagonal jogging not working intuitively #498

Closed TITAN3737 closed 4 months ago

TITAN3737 commented 5 months ago

Diagonal controls in the UI works differently when clicked once and when holded continuously. When any of the button diagonal blue arrows is clikced once, it moves the machine exactly one in each direction of the XY move distance. But if clicked and hold (continuously), it does not moves diagonaly but it goes toward the corner of the working area. While I understand this maybe in some cases useful, it is pretty confusing that these buttons behave so differently. In the Wiki page is nothing about this feature. Would it be possible to either make this feature optional or implement some kind of toggle for who want to use it only when needed?

kglovern commented 4 months ago

I'm going to assume you have soft limits enabled because that's the only way this makes sense.

Continuous jogging works by sending a large movement and cancelling when you let up the button. With soft limits, this large movement would trigger an error, so we do some math based on current position and EEPROM max travel for the requested axis and send that as a jog command.

The problem is, if you move diagonally (X + Y), this math is always going to point to the corner since it's the max travel you can do in X in requested direction + max travel you can do in Y in requested direction.

There is not an easy way to fix this and it can't really be made toggleable without coming up with a completely different method to continuous jog.

TITAN3737 commented 4 months ago

Thank you for your reply.

I'm going to assume you have soft limits enabled because that's the only way this makes sense.

I do, makes sense to me as useful safety feature.

From what I can see in the console, there is hardcoded 10000mm distance in each axis when using continuous jogging. So that makes every move to go out of the work area no matter where the machine acutely is. Hence this odd behavior of pointing the machine in different directions based on its current location. Can these 10000mm be calculated to be the smallest distance to edge of work area? Those are work area lengths minus current machine coordinates in that given diagonal direction. For example: Work area x1000y1000, machine coordinates x600y500 / in case of diagonal move to top right corner, than smaller of x1000-600, y1000-500 / than $J=X400Y400F5000 ? Or is it something more to this issue?

kglovern commented 4 months ago

That will not work without limit switches/homing and we can't assume every machine has limit switches. Without homing switches, machine 0 is wherever the gantry is located when connected - which means we can't rely on EEPROM travel.

TITAN3737 commented 4 months ago

I was always wondering what are machine without homing good for, but from what I can tell, without homing and knowing where the tool is in the machine space, there has be very little accuracy overall. So I guess who do not need this precision, does not care about being diagonal move really in diagonal direction anyway. So, can this be the toggle then? I mean no homing = corner arrow sends the machine roughly in that direction, and with homing the solution I have proposed. Only beacuse some machines dont have homing, cannot mean that everybody has to use this inconsistent feature.

kglovern commented 4 months ago

Your solution will result in not ever being able to jog to the machine extants given a non-square work area. While inconsistent, it only effect soft limit behaviour and we don't see it as a significant issue.