(Can’t find the edit button.)
Also, with regards to the setup in the link. I was concerned with the Gcode command buffer in sending movements. in that there will be moves buffered that will execute long after the jogwheel has stopped. This is exactly the same behaviour you see when you manually control your machine via a printer interface when connected serially.
The big appeal of your solution was the limitation on how the moves are buffered.
Exactly. This is why Jamie’s solution is my favorite. IIRC, there was someone trying to leverage Jamie’s planner commands via a jog command over serial. Grbl does this, I think, so that jog commands are interruptible and relative. Unfortunately, I remember them being $ commands.
Yes, that would definitely be possible, but requires change to the Marlin code. By utilising Jamie’s solution the Marlin code can be used without any need to modify / hack it. Which is far more elegant in my opinion.
I actually think that Jamies solution is brilliant, in both the way that it interfaces with Marlin and the characteristics of the movement. If I had not already have the jogwheel and switches for my build, I would definitely be purchasing a joystick. However I promised myself to get this finished over the Xmas break and there’s no time to wait for new parts to arrive (The joysticks are unfortunately not available locally).
Necessity is the mother of invention as they say. 
The Jogwheel is nice but I wouldn’t use it this way if I were you.
What I’d do would be to use both joysticks and this jogwheel. I know you don’t have joysticks right now, but those things are really super cheap and you can make your project including these even if you did not receive them yet. They can be installed at the very end, it doesn’t matter
-Use the Joysticks to be able to quickly move from somewhere to somewhere else. It’s more convenient since you don’t have to switch between axis and click on a button every time. Much more intuitive.
-Use the jogwheel for precise movements, by correlating the wheel markings to actual dimensional movements. This can be very useful for precision positioning or, even better, for actual cutting in manual mode.
So, this way, you first move to the place you want to cut something using the joysticks, set your origin. Then you use the jogwheel to cut a 25.6 x 38.2mm rectangle, for instance. Basically the jogwheel would be a manual cutting tool, each increment could be 0.1mm of distance or whatever you want, and since you have markings on the wheel yo could easily do very accurate cuts.
That’s probably how I would have done it if I happened to have one of these wheels, the idea didn’t occur to me at that time.
You’d just need a button to switch between joystick mode or jogwheel mode. When pressing this button, you’d have to use both the joystick and the jogwheel together to get a movement.
For instance, you want to move the x axis 2.4mm to the right? Then move your joystick to the right and turn the jogwheel until it reaches 2.4mm. This way you don’t have to bother with “which way should I turn the jogwheel to go right”, it wouldn’t matter since the direction would be set by the joystick, which is much more intuitive.
You want to move the Y axis 5.6mm away from you? Then move the Y axis joystick away and turn the jogwheel until it reaches 5.6mm.
You just moved your jogwheel to 5.6mm and you have to do your next cut which is a 45.7mm cut. You don’t want to do the math? Then jus release the joysticks and move the jogwheel back to zero. No axis shoud move. You’re ready for your next cut, easy.
You can even probably move both axis at the same time so you can have 45 degree movements, using the same principles.
The code would need to be a bit different here, since it would need to be speed driven instead of just distance driven like the one I’m using. But this is probably easy to do.
And if you’re good at coding I suppose you could do some awesome stuff, like circles using some joystick combinations and the jogwheel. (ex: first go to the center, switch to maanual mode, then rotate the joystick all around twice, set the jogwheel to 5 mm and it will cut you a circle of a 5mm radius around the point you just set up as your center). There are lots of awesome possibilities for anyone who like to play around with the code I guess.
I think this would be the perfect remote control, If I wasn’t lazy to start over that’s probably how I’d do it.
The best thing I can think of using a joystick or a wheel is that I will not accidentally click on the Z axis and drive it into the board!
I bought the same joystick… when I hooked it up to my meter with 5v I’m getting 1.8 to 3.3v on x and y and z twist is giving me only 0.05v to 0.10v. Is that normal ?
For x and y that is normal. The values 5600 and 10800 (out of a max range of 16384) correspond to 1.7 volts and 3.3 volts from a 5v supply. In other words the pot doesn’t give full range output.
For z twist you should be getting more range than that and it should be roughly centered on 2.5 volts. In fact the z range on mine is a bit bigger than the x and y range.
For reference:
One more thing just in case: if youre at that stage, make sure you get the polarity right, where higher voltage is plus X/Y/Z and lower voltage is minus X/Y/Z. There is currently no facility to flip the polarity in the firmware so you have to get it right before you solder everything up and discover it’s backwards.
Thanks Jamie! I wonder if I got a bad joystick. I did everything with spade connectors so flipping wires around (or replacing the joystick :/) shouldn’t be a problem.
I’ll carry on and see how well it works.
On the Z direction check all 3 wires with an ohm meter. I think the color coding is weird. I just looked at mine and I think I have white connected to + and red connected to - and black connected to signal. But not completely sure, because it’s a bit of a rats nest.
That was it! I just assumed red and black were power and ground.
For future reference the wires up as you mentioned gives counter-clockwise twist increasing voltage (up). I get 1.5 to 3.5v now.
Yes I have clockwise (looking from the top) moving Z down, like screwing a bolt down into a nut, and counter-clockwise goes up, like loosening that same bolt. So it’s easy for me to remember. I can’t guarantee that the colors are standard, but you can switch it to go whichever direction you prefer.
Edit: misread original post.
Not being able to switch the polarity seemed like a weakness so I added this feature and submitted a PR: https://github.com/MarlinFirmware/Marlin/pull/16466
So you don’t have to be super careful when wiring it up. It’s so easy to get backwards.
Today is Marlin day for me I guess.
Thanks! I got everything plugged in and after some dead zone tweaking it’s working really nice and smooth.
Here’s the pins I used on the (not mini) rambo board… 3 pins plus ground and +5v off the analog extension pins, and enable on the PWM extension pin closest to the analog extension pins. I wound up cutting a network cable making a long and short cable… wired the short one to the board and the long one to the stick. Mounted a Female to female RJ45 keystone jack on my carriage and now I can just plug it in whenever I need it.
#define JOY_X_PIN 3 // 3- Analog Ext 4
#define JOY_Y_PIN 4 // 4- Analog Ext 6
#define JOY_Z_PIN 5 // 5- Analog Ext 8
#define JOY_EN_PIN 4 // PWM ext pin 6
Edit:
Heres a link to a printable joystick enclosure and rambo enclosure.
Also has photos of the Rambo wiring.
Just curious … what are the maximum feed and acceleration rates based on? It moves way faster than when I jog with the lcd and even if I turn maximum feedrate and acceleration way down it doesn’t seem to have an effect. Sometimes if I push the joystick all the way to the extents the motor just stalls. I can probably get around with it by fudging the min and max x and Y values?
There is a bug (as far as i’m concerned) that they introduced when preparing it for Ultipanel or something, I’m not quite sure. They changed it so the joystick max speed is limited to a lower value, the MANUAL_FEEDRATE (if you have an LCD enabled), whereas I had it so the joystick could use the full max feedrate.
I submitted a PR to fix this, which they merged, but it was after Ryan’s 414 version. It is included in Ryan’s 415 version, or you can apply the fix yourself to the firmware according to the commit (it’s just a one line change).
Eventually it will fix itself when the change propagates but there is a window where the joystick is slow and you have to apply the fix to get the full feedrate.
Ok. I actually forked off the release version of marlin from Dec 5 so maybe I am out of date. It’s interesting it doesn’t take the lower of the maximum feedrate or the manual feedrate if they went that route. I’m fine with updating the manual feedrate though now I know where to look thanks!
Actually my fork already has this PR and I am seeing the opposite problem.
(Joystick is moving faster than both the rate on the LCD and the maximum feedrate).
My problem might be I forgot to clear the EEPROM… I’ll try that tonight
Edit:
So managed to mostly solve my issue… the problem wasn’t feedrates at all… I think if you have the limits of the stick config set so that the pot drifts or spikes over those limits then the carriage stops moving… to the point where I had the stick full forward and the carriage moved then stopped for awhile and I had time to run M119 with debug on and verify that the readings still showed the stick full forward. All X Y and Z behaved this way.
I changed my config so the upper limits were 1000 lower and it seemed to almost completely solve the issue with still a little stuttering here and then (if the pots spike over the limits?)
I would also like to know if anyone has got this working with SKR 1.3, and what pins would be able to be used. I am using Dan’s(blomsd) settings for skr 1.3 and uart and I would like to add this joystick. He used a bugfix version from October so it is included, I just need to know what pins to use.
