Inventables Community Forum

Grbl Hand-held Controller with Jog Wheel, DRO and built-in sender

X-Carve Upgrades
#1

I’ve been meaning to share this with the community for a few weeks now, but the end of year got in the way. I use a raspberry pi to drive the X-Controller and that has added flexibility to my setup. But this setup does not have a read-out or controls at the machine itself. The computer I use to drive it all is on a desk across the room about 10 feet away. Needless to say, doing tasks such as setting a work position origin had me jumping back and forth between the machine (looking at bit positions) and the laptop, pressing the 0.1mm step button to ease an axis into place. Also, it seemed to me that having to boot up the pi AND my laptop just to home the machine is a huge overhead in effort and time.
I was inspired by many of the projects that have built button controller s or adapted joysticks to drive GRBL, but decided I really wanted a proper jogging wheel, not just buttons to drive the spindle into position. Also, while I was at it, why not build most of the common functions of my workflow into it so I could get everything set up from one place. Instructions like home, set axis zero, move to origin, change workspace, and more, are now available in one place.
As a bonus, and inspired by how 3D printers are set up, the controller can accept gcode from a SD card and can stream it to GRBL itself, no need for a raspberry pi or laptop. This mode works, but does need some extra features that I think would make it more comfortable to use, such as a 2D visualization of the motions and the ability to report them back to a full system in case that is desired. Those things will come with time, but for now, this has made a huge difference in making my workflow more efficient, which in turns makes the work more comfortable and satisfying.
Anyhow, pictures below, some demo videos of the testing. The code is in github, if anyone else wishes to try their hand at it. I am happy to accept help to develop it further or to assist others if they wish to build their own.

IMG_20201230_161804647
IMG_20201230_1618046474640×3472 2.5 MB

IMG_20201230_161826551
IMG_20201230_1618265514640×3472 1.75 MB

Demo videos:
Part 1
Part 2
Part 3

Code: GitHub - quezadaminter/GrblJogCtrl: Grbl hand-held controller firmware.
Schematic : GitHub - quezadaminter/GrblJogCtrlSchematic: Schematic for the embedded GRBL jog controller.

5 Likes
#2

This looks awesome! Great work, thanks for sharing.
When I get more time, I’ll be digging into this fully.

1 Like
#3

Very interested here.
Is this something you’re going to market?

#4

I’d like to have one but that is way over my head. I guess we wait until someone markets them.Very nice work.

1 Like
#5

Thanks guys. I don’t currently have a plan to take this to market. I do see that there is a good chance there could be demand for it. I tried to use components that could be sourced easily and while the firmware part definitely requires some level of experience with embedded programming, everything is connected together with point-to-point wires. Each piece on there is like a block of lego, you piece them together in the right order and it does what the code says :slight_smile: . For those who are familiar with it, I used the Arduino architecture to write the code, hopefully removing a barrier to entry for those who like to tinker.

I suppose I could offer the service of assembling them for folks if they want to pay for that and the parts :). @WayneHall, how much would you pay for something like this if it was offered? :slight_smile:

Keep in mind that the form factor that I chose is based on what I saw from commercial options for hand held DRO controllers. But this one does not have to look like that, in fact after a few days of using it I am thinking of re-working the layout of the components to make things like the SD card connector easier to get to. I did not plan on this at the beginning and thus it ended right up against a selector switch, making it awkward to get the card in and out of the slot. The point is that the user can shape the controller to whatever form factor meets their needs.

1 Like
#6

Not sure what something like that is worth i guess i cames down to what you need to make it and and make a profit.

#7

Totally awesome project, tickling each and every “nerd-gene” present in my body :slight_smile:

1 Like
#8

shut up

2 Likes
#9

Well done. Great project and execution.

#10

I’m a big fan of open sourcing designs if you do not want to make a product of it and try to sell it. It’s rewarding to see other people use you design, and who knows they might improve it which is a win for you. Instructables.com would be a great place to post this design.

#11

It is open source.

#12

I see that the code is available but I could not find any information on the hardware or the hookup. That is kind of what I meant by “open sourcing the design” but maybe that is confusing or not an accurate statement. @MarcoQuezada - do you have a schematic or hookup diagram for your controller design posted somewhere? Maybe I missed it.

#13

@BillWalter, you are correct, I should have included the schematic. I was too giddy to get this posted and was focused only on the code. It should be possible to deduce the wiring from reading the code but it was not my intention to have folks work it out like this. I’ll spend some time today drawing it up and I’ll update the post.

Instructables.com would be a great place to post this design.

Am I posting in the wrong place? I can move it if this was not where it should have been.

1 Like
#14

@BillWalter, I added a link to the schematic repository on GitHub. The project is format is KiCAD v5 but I also added SVG files with captures of the schematic pages so that folks don’t need to have KiCAD to be able to read it. There are notes about the different parts I used and where I got them from. Happy to answer any questions and feedback is welcome. Good luck!

3 Likes
#15

No, this forum is fine and more targeted to CNC. I like Instructables as it is more focused on publishing projects, while this is more of a forum so the project instructions get broken up by posts. I usually publish on Instructables then post a link here. It’s entirely up to you though.

#16

Thanks, adding this to my ever growing list of things to get around to. I’ll let you know if I have any issues.

1 Like
#17

@MarcoQuezada I just came back to this cool project and I have a question. When running a job, does the controller lock out or could you use it for Feedhold / resume? What happens if you accidentally do something (press a button, turn the jog wheel, etc) during a job?

#18

@NeilFerreri1 you are correct, there is currently a risk of pushing an undesired g code command into Grbl while a job is running. What I do with my current build is turn the left selector switch clockwise to the LCD brightness position or beyond and the right switch to the DEBUG position or beyond. This places the controller in a state where the jog wheel will only change the screen brightness or does nothing. However the default behavior of the buttons is still active. So my not-so-elegant solution for now is to put the controller on a safe place where it is unlikely to be bumped while a job is in progress. Grbl will also reject certain commands when it is in the run state, but that still doesn’t give me confidence that something won’t fail.

My initial thought is that I can update the software so that the only buttons active when the selectors are in the state mentioned above should be feed hold and resume. This would work even if a job is not being run. Downside is that it requires the operator to remember to do this.

Another (or an additional) option is to monitor Grbl’s state and lock out the functionality as mentioned above automatically.

Thoughts? Also, if you are so inclined, it may be useful to open this as an issue on the github page to track the development more formally.

#19

@NeilFerreri1 I updated the firmware on GitHub. I added two fixes:

  1. Block certain I/O during run. I modified the code so that the buttons on the matrix are ignored when the Grbl state is Run. The exception here are the Feed hold and start/resume buttons. The selector switches don’t send commands directly, just set states. On closer inspection of the code, the jog wheel already was blocked since it only sends movement commands when the state is Idle or Jog. This feature is now on the block_io_on_run branch.
    I need to implement the spindle speed and feedrate overrides, but that is a pending item.

  2. Soft travel limits. I am working on a different feature that will track the requested travel distance and stop the machine before it hits the ends of the programmed travel. This is on the limit_travel branch. The limits only engage when the machine is homed.

Let me know if you have any questions or need any help/clarification.

1 Like
#20

Wow, thanks! I’ll move any further issues to GitHub. Would you prefer questions posted there as well?
I’m still thinking about how I want to implement this idea