I’ve finally started moving back over to CNCjs from Carbide Motion. I have everything set up and working, BUT I can’t for the life of me figure out how to do smooth joging. Judging by the excellent post that @Julien put up here CNCjs handwheel pendant (detailed howto for nerds) it looks like this might not be possable? I’m willing to write a widget for CNCjs if that’s what it comes to, but I cant believe that no one has solved this problem yet.
Also does anyone know how this is actually done on a full sized machine? It looks like the general solution is to spam the machine with jog requests, but if that’s true then can’t the requests build in the planner que and you may over endup with jog commands in the que after you stop pressing the jog button, or spinning the wheel ?
I had this in my todo list (modifying CNCjs code itself to support smooth jogging natively), but it’s too low to happen anytime soon. I know @neilferreri wanted to do this too, not sure if he had a chance to make progress on this.
I also could not believe that no one had done it yet, but try as I might I was not able to find someone who did.
Smooth jogging is very easy in its principle: spam the machine with $J commands, they do stack up in the planner, but immediately when the user releases the button, send the jog cancellation command (0x85), it will stop everything AND clear the queue, so movement stops immediately.
So if you feel like taking a dive in CNCjs code and adding the $J and 0x85 in just the right places, you could become famous overnight
EDIT: there is also a good article here about making GRBL smooth jog, to implement it in a “smart” way to minimize the spamming yet ensure movement continuity. But brute force approach works
Nice find with the GRBL smooth jog link! Everything is well implemented, and documented. Incidentally that is how C3D did it in Carbide Motion 4. I’m thinking instead of forking the current build of CNCjs I might try to write a Jog widget. I think this could have two advantages:
Independance from build updates to CNCjs. I personally don’t have time to maintain a build…
Ease of implementation. It looks like there’s enough code behind the normal jog widget that it would take a while to get it right, and without a known good jog interface it’ll be difficult to test. With a widget I can always jog around normally during testing.
If anyone has recommendations or experience building a widget for CNCjs let me know.
EDIT: Just realized I can fork a widget… so there’s the winning approach.
Hahaha, ya, I should have been more specific about that one… That was what it looked like from the “Hidden API”, but you guys definitely had some secret sauce in there somewhere. TBH I never looked past the API since it just worked; no point in fixin what aint broke. My assumption though is that you were doing the maths to find proper jog distance and minimize latency.
Not since that snippet I sent you a few weeks ago. Trying to teach remotely, managing two preschoolers at home, and we now have a new baby, all during the pandemic. No time yet.
@TheSilentEngineer Try the CNCjs issues on GitHub. Development is active there.
When you say active you’re not kidding… It looks like those smarter than I are on top of this! I’ve spent about a day picking through the code just trying to find things. It appears as though it’s not as easy as just SomeObjectName.Send(“InsertG-codeHere”, Port) so my plan of cannibalizing what’s available is out the window. Plus I’ve yet to find a well documented API for the core program, so knowing what a widget can access and how to do it is still a mystery I’ve yet to solve. Not saying it’s impossible, or even hard, just beyond me at this point.
