Never had cause to use CONTROL with bCNC being as comprehensive as it is, though I've dug into the code occasionally. I remember a couple of people complaining about continuous jog and soft limits, but I thought a fix got issued fairly quickly. If it's possible to write a JS macro that takes over jogging duties for analog usage, I'd just do that.

Yeah, PathPilot's just skinned, pre-configured LinuxCNC, so it's using the same HAL files under the hood that I'm writing/editing on my control.

Aha! That sounds promising then, because that was the behavior in question. Apparently Mach 3 was good at it, and other things aren't very cooperative.

Oh, that's cool. You should definitely finish it off! I don't know what IO the PathPilot PC has on it, but it should be pretty easy to integrate.

For a $J=G91 jog, should that calculation even be required? Any requests that go past the jog limits will be refused by the planner anyway. Whatever slider/analog parser is picking the distance/feedrate should just be able to

 

Ahh, that makes sense. Doesn't help for variable speed jogging, but it's a pretty elegant way of doing normal keyboard jogging. Shouldn't be an issue with an MPG and incremental jogging either, but the KeyUp event won't support variable proportional jogging, which would have to constantly cancel and reissue based on the dial/stick position. Maybe some kind of OnChange event?

 

FYI jog cancel fails intermittenly with grbl - I have a made forked version with a fix for the Mega version - the same way I do in grblHAL. Failure happens when there is a jog command in the block input or serial input buffer when it is received, the jog cancel command does not clear those as it should.

 

Ahh, that makes sense. Good catch.

 

The described motion on the github page literally sounds like what Terje just posted this morning:

CONTROL is sending an 0x85 on KeyUp, but there's still something in one of grbl's pre-buffers that didn't get flushed. Maybe sending two 0x85s back to back would fix it?

But if you're only pressing the key and holding, it sounds like in this case, maybe there's a mis-match between a status report coordinate and a distance-to-go calculation order of operations?

I'd have sworn blind I was following you. Weird.

Nice, though! I like my little two-button-plus-e-stop "panel" for my laser, it's so nice to have dedicated buttons for things.

 

Yeah, this is what I meant by

...But didn't phrase it the best. I don't know how you could possibly fix that given that there's a fairly fixed max polling rate for grbl, unless you also track the time since the last status report and calculate how much distance you've likely gone in that time, and subtract that from the previous distance to go.

But when you think about it, shouldn't this issue always result in CONTROL thinking that there's MORE distance available than there actually is? If you start at say, X3, get a status report at X5, let off the button and immediately repress at X6, CONTROL should think it's at X5, when actually it's at X6. It appears that there's extra distance available to go than you really have.

And to further confuse matters, I'm pretty sure there's at LEAST two polling cycles' worth of pause at the second pause location in the video.