Joystick managed by Marlin

Mostly Printed CNC - MPCNC Hardware Development
53

They are like ADC values but the way Marlin does the sampling they are summed/averaged so they behave as if they are 14 bit values.

What hardware are you using? I am guessing an encoder based jog wheel? I can see the value in a jog wheel but I would be a little concerned it might not feel like what you are expecting. Either way I am interested to hear what you find.

Also, not to discourage you from the analog joystick method but if you already have an external processor you could inject gcode like the other joystick approach I’ve seen.

1 Like
54

Ahh okay, so 2^14 = 16384 resolution. Thanks. :+1:

That should give me enough to be able to calculate voltage levels based on the resistance of the joystick and your JOY_X_LIMITS.

I did look at the example in the link. The issue for my setup is that I am using the serial port with an HC-06 bluetooth module so that I can use CNCjs on my laptop, which leaves me with having to use an alternate method. (I’m using a rumba board).

Hardware is a regular CNC style encoder jogwheel and simple selector switches for the axis and speed. (X, Y, Z & X1, X10, X100). A regular MPG jogwheel pendant will also work.

IMG_8879
IMG_88794032×3024 2.01 MB

How it works: Essentially the jogwheel will always output a voltage equivalent to the centre of range (lets say 2.5v - an arbitrary voltage value just for explanation) so no movement will occur as this should equate to the centre of your defined dead band. Then if X1 is selected and the jog-wheel rotated, it will output either 2v or 3v depending on direction - so this mimics a small joystick movement. As the speed selector is increased, the voltage outputted also increases (1.5v & 3.5v) which mimics a larger joystick movement. It’s these voltages I need to calculate.

Of course the movement will only be one axis at a time and only at the selected speed. There is opportunity to make the output speed proportional to the speed that the jogwheel is rotated, but that’s not how it’s currently set up.

The code also detects the speed of the wheel rotation, so for small / slow movements it will output a pulse for each jogwheel click. For faster movements it will maintain the output to smooth the movement, otherwise each jogwheel pulse will generate a jerky movement.

On the bench it appears to work very well, with the voltage output seemingly stable and changing in accordance with the selected speed. Now I have some idea of the required output values I can move to testing on the machine and see how it actually works.

I’ll post up my findings in another thread as I don’t want to hijack yours.

1 Like
55

(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.

56

:+1: 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.

57

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. :slight_smile:

2 Likes
58

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 :slight_smile:

-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.

4 Likes
59

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!

1 Like
60

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 ?

61

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:

62

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.

63

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.

64

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.

20200104_135753
20200104_135753.jpg2448×3264 1.15 MB

65

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.

66

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.

1 Like
67

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.

2 Likes
68

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.


5 Likes
69

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?

70

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.

1 Like
71

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!

72

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).