@sharmstr, @Giarc, can I please ask for dumps of your Grbl settings (so I can do some motors-disconnected testing with same parameters) for the soft-limits calculation error bug?
Regarding the Grbl / jog Cancel bug, I did some more debugging on that, and it's not Grbl after all (using a different sender of ours, but same methodology (send move on keydown, send cancel on keyup) I cannot replicate it - so will revisit the CONTROL code and see if I can find what it is - good to eliminate one thing though

 

I actually got mine working. My problem was that when I homed, I then jogged and set zero for X and Z which were within the soft limits. For Y, my my soft limits are set for 10000mm so I can round over wood. However, after homing I immediately would set the Y to zero without moving it. By jogging it about 10mm in the Y+ then setting zero, I have not had an issue. My theory is that because my zero was at the home, it thought it could not move in the negative at all. Therefore, it could not cut because it needs some negative space for the endmill to cut around the zero point of the part. Or, I am way off base, and it is working for some other reason.

 

Thanks Sharmstr! I think i have a fix - just internal testing should be out early next week (planned not promised hehe)

 

AppVeyor - 1.0.254
Appreciate the extra testing, spent about 10 mins on last build jogging like crazy and didn't see a glitch, so hopefully sorted - touch wood

 

Was supposed to fix the soft limits error yes. The cause of the jog Cancel is still unknown (though something else we are working on does cancel every time, so it is a CONTROL bug, just still not sure if its a race condition in Chromium (not generating the keyup/touchend/mouseup event) or something in our logic. Will look at it deeper when I get a chance)

Will look at the soft limits fix again later today see why I don't give the installers before

Hehe

The all 100s in the log looks like incremental, was the switch in the right spot? We only calculate distance for maximum continuous move to send (send it to the limit, cancel if you lift off button before)
We dont bother checking Incremental (can if we have to)

 

Thanks for confirming

Something odd then, will dig in after the morning routines



This is what caught me offguard (first thing to check on why then) - as continuous shouldn't be doing round numbers, should be floating point numbers of "distance to go before we hit the end of travel, calculated from max-travel and current mPos)

 

Try 1.0.255: AppVeyor
I added an extra if statement

It waits for the jog to stop before allowing you to actually send the next move, thus as we wait till we know Grbl is "idle" we can trust the DRO to calculate from there

 

Agreed you were! That was the extra "if" the "what should be ignored presses" are ones that was showing up as whole numbers

We can try making Grbl check for updates more often, I think we are on a 400ms loop at the moment - will play a little and see what we can do

 

So a little faster, but looks like to do this all safely, the delay is slightly unavoidable

Added a little error message action in toasts at the bottom, and log saying "Wait for machine to be Idle, before jogging". Not ideal, but "for now" at least better than erroring out.
Also added error popup when you try to jog into the soft limit (it was just sending a 0mm move, user may have no idea why its not jogging, now it will tell them, "Unable to jog toward X-, will hit soft-limit"


I'll think on a better way of doing continuous jog entirely but for now, the tiny delay is a must because of the way Grbl works (doesn't calculate where it can jog internally)

You can test with 1.0.256 AppVeyor

 

what! how! lol

 

THE WOBY CAMERA JIG DIGITAL FILES! — Woby Design
and also see his video