I really want to get a real jog dial working with the shapeoko.

I really want to get a real jog dial working with the shapeoko. Something just like they use with the big Tormach machines. I found the exact controller they use with those on Amazon and bought one and have been working to get it working with ChiliPeppr. So far, it seems to work. I have a bit more work to do before I share it, but if folks are interested, please let me know.

wow very nice:)

what did you use to interface between your Joystick and chilipeppr?

@Carlos_Tavares ​ the program I wrote sends gcode commands directly to SPJS.

@Frank_Graffagnino I too have been playing with this idea. I have a jog dial ordered and should have been delivered this weekend… Dang snow. Anyhow, I talked a bit to john about this but I am curious to see what the community thinks. I think that extending spjs in a way that does not interfere with the fundamental functions (read flow control, write, etc) would be a good place to go for this. Perhaps a pluggable interface so that you could have spjs load your module that does the translation etc to talk to the websocket. This way we avoid having your little process that has to be running and my little process to work with my pendant.

By communicating with spjs we also get the ability to see certain things directly; are we running a file right now? Is it safe to jog? etc. Just my thoughts as of late.

My number one concern is NOT to have spjs get bogged down, but continue to fast and lite as it is now.

@Riley_Porter_ril3y not sure if I completely follow your idea, but if you are suggesting basically doing away with my program and just have SPJS read the jog dial directly, I TOTALLY think that is the better way to go. Right now, I’m communicating with SPJS over the websocket exactly the same that ChiliPeppr is. If you ran inside SPJS, you could do away with the websocket altogether and get rid of that lag. Also, SPJS could be extended to let ChiliPeppr know what speed it is currently jogging at, what axis is active, etc. This would be way better. Unfortunately though, it would mean some feature creep in SPJS and I’m not sure how John feels abou that. In one of my previous emails, he was open to that idea… he also suggested the alternative of putting my program as a websocket client to SPJS, which is what I went with.

So anyhow, I am certainly communicating with SPJS… but if you were inside the same process, you could be aware of much more that is going on and extend the SPJS API. That’s the better way to go. I’d be happy to help out any way I can, although I’ve never written any golang.

@Frank_Graffagnino what language did you end up writing your jog client/server in? This is really exciting. I think your approach of doing a websocket client right into SPJS was perfect. The jogging seems very responsive in your video. Is the code online anywhere yet?

this is just regular ol’ C code. The jogging lag is not too bad… The time from the motion to the jog is ok, mainly because the two programs (mine and SPJS) are running on the same pi, so the network delay is minimal. However, because Grbl has no jogging support per se, I’m limited to queueing up lots of small motions when you use the shuttle wheel, and since you can turn the wheel much faster than the machine can jog around, you can queue up lots of commands and then the time between the jog motion and the machine motion can get extensive. Only other thing that can be done to combat this would be to implement sending the feed hold and soft reset to stop motion as soon as the shuttle is returned, which they describe in the “jogging” section on the Grbl site here: https://github.com/grbl/grbl/wiki/Interfacing-with-Grbl

But I’m not sure I like that… it would mean you would lose some of your coordinate systems (I think). So, I’m living with that for now.

The code isn’t online yet… I’m still fixing some bugs, adding in some needed items, and then hopefully cleaning it up a bit… then i’ll post it on github.

@Frank_Graffagnino If you use a TinyG you can use Feedhold ! and Wipe %. When you jog in the TinyG workspace I use the living daylights out of ! and % for jogging and it’s a really nice user experience, so that would be the best way to make that jog shuttle work cleanly.

awesome! I don’t have a TinyG, but it sounds like someone will be able to help me upgrade this program for the tinyg very nicely! :slight_smile:

@Frank_Graffagnino What I mean is we define a “plugin” for spjs to call. The plugins just follow a certain onLoad onUnload interface. This way we could use the UI to “load” plugins right through chilipeppr. So you pull up the “Extensions Widget” and you click “enable” your jog dial plugin which just spins up your entry point for your go code or python etc. It still just talks to chilipeppr via websockets but this way we can have a standardized way of creating plugins. Just a thought. I have been through “agent hell” before where you needed to have x y z.exe running with no central management point.

Ahh. I see. Well, in that case I think it would be easier to just start my program when you start SPJS with a whole lot less code to cause problems. Just my opinion.

so, i just saw this note on the release notes for 1.75 of the SPJS: “Jarret Luft added an artificial % buffer wipe to Grbl buffer to mimic to some degree the buffer wiping available on TinyG.”

so, @Jarret_Luft does that mean i can get that behavior that John spoke about above on grbl? Should I jog until the user releases the wheel and then send a feed hold “!” immediately followed by a wipe “%” ?

@Frank_Graffagnino this is the spot where I think folks started thinking “hmm, the arduino uno chip is awesome, butttttt it doesn’t quite have enough power to get me what i want…” and that’s why guys like the Synthetos guys said “i think there’s a better way.”

So, Jarret or John, one other question: is there a way I could send jog commands to SPJS but flag them in some way to tell SPJS not to queue them on the Arduino? Meaning, wait for each command to complete before sending the next one? Or perhaps even better, tell it to only queue one command?

And john, I agree. But there appears to be lots of people running grbl out there so I think making it work with that is probably still a good idea.

interesting… although all of this is making it even more evident that this code probably should run inside the SPJS… then it could send exactly when it should without any gimmicks.

There is a “sendnobuf” command that you can use. It’s documeted on the readme. You have to do a low-level /ws/send pubsub to do that inside CP, or just issue the sendnobuf on your own since you’re doing your own websocket. These will not buffer, but you will overlfow the buffer if you don’t do your own flow control.

very cool. i’ll look into it. Thanks.

so, @Jarret_Luft and @jlauer I’ve tried many combinations and I can’t seem to get SPJS to wipe its buffer and/or not buffer commands to grbl. I tried sending all the motion commands with sendnobuf and then when I get the command to stop motion, I sent a “!\n%\n”. That stops motion, and presumably should wipe any unexecuted commands that SPJS has in the buffer. But as soon as I hit resume, I get motion, that I think was already sent to GRBL. So, I tried various other things (including padding the motion commands to 120 characters with zeroes so that more commands aren’t sent to GRBL) and I can’t seem to find any combination that will work. Let me know if you have any ideas. Basically, I’m just trying to come up with something so that if I wiggle the shuttle back and forth and back and forth and then stop, that the machine doesn’t execute all those commands and it just stops wherever it is. One thing I’m not doing at the moment is reading any responses back from SPJS. I suppose one option would be to read responses and only enqueue a command each time I see a OK come back, but I’d like to avoid that if I could. Let me know if you have any ideas.

I think you should switch to TinyG. I know that’s probably not what you want to hear, but you clearly need to be able to wipe commands on the controller itself and thus you need a more advanced controller.