gsender
gsender copied to clipboard
Sienci-Labs
Travel exceeded when soft limits on
It looks like on machines of different sizes the jogging feature of the program is calling for metric incremental move at -1250mm statically at whatever feed rate is set and cancels the command when you let off the button (hotkey or on screen). This poses a problem as it falls outside of the limits essentially every time with soft limits enabled. eg. G21G90 X-1250 Y-1250 F10000
I don't see a scenario where soft limits can be used at all with jogging, as -1250 in any direction at any time will fall outside the soft limits on around 99.99% of machines. The only thing I can think of to rectify that is to have the machine firmware queried, subtract the limit from the current location, and the command to jog based on that. I realize that diagonal movements would be slightly more complicated as the equation would have to find out the max travel distance in 2 directions.
For instance, if $130 (X-axis maximum travel) is set to 1000 and the machine is currently at X-200 and you want to jog in the positive it would be 1000-200=800. 800 would be the max distance you can call the machine to jog with the command without triggering the travel exceeded error. The same would work in reverse altho would just use the current location as you are working back to 0
Alternatively, if you wanted to travel diagonally in the positive direction, you would have to calculate $130 and $131 which is X max travel and Y max travel respectively. So if the machine is currently at X-200 and Y-300 the jog command would be G21G90 X-800 Y-700 F[whatever].
That should theoretically solve the TRAVEL EXCEEDED error thrown by every machine and resolve the issue completely.
With that being said, hopefully, someone has the time to implement it because gsender is absolutely the best software I have used to control desktop CNC's. I'm currently using it on a shapeoko 3 XXL and it works pretty flawlessly with the exception of the soft limits and another issue with the tool change settings
.
We already run this calculation when soft limits are enabled - the 1250 value is only when soft limits are not enabled, otherwise we calculate the distance based on current machine position.
We've discovered a math issue that we're resolving in the next build that should help continuous jogging - an offset wasn't being applied for some homing locations and GRBL doesn't handle exact limits very well which was resulting in the soft limit error. This should hopefully resolve the issue.
We already run this calculation when soft limits are enabled - the 1250 value is only when soft limits are not enabled, otherwise we calculate the distance based on current machine position.
We've discovered a math issue that we're resolving in the next build that should help continuous jogging - an offset wasn't being applied for some homing locations and GRBL doesn't handle exact limits very well which was resulting in the soft limit error. This should hopefully resolve the issue.
Thank you! I can confirm that the update did in fact fix the issue.
@SienciLabs @kglovern I am re-opening this issue as the issue has returned in the 1.20 and beyond releases. It appears that the fix that @kglovern referenced that fixed the issue has returned with vengence. I will note that the fix that @kglovern talks about never made it to any of the EDGE builds at all, so it seems whatever the fix was slipped through the cracks.
There was a regression between versions - this will be fixed again in the next release.