Of course not. Only 9 buttons via 2 analog inputs RAMPS 1.4 and Marlin.
So did you have to modify Marlin, or is there an existing Marlin interface that maps inputs to buttons?
I can’t insert a youtube link to the video, but it can be found by searching for “Keypad9”
Many small changes have been made to Marlin for the display and one program in the Loop.
It’s very simple, but it works. Polling of analog inputs and simple programs like:
while(ReadSensor1(5,CntRead)) {
// Serial.println("Кнопка 9 ");
digitalWrite(Z_DIR_PIN,HIGH);
digitalWrite(Z_ENABLE_PIN,LOW);
for (int m = 0; m < 16; m++) {
digitalWrite(Z_STEP_PIN, HIGH);
delayMicroseconds(3);
digitalWrite(Z_STEP_PIN, LOW);
delayMicroseconds(100);}
// delay (1);
if (ReadSensor0(3,CntReadS)) {
// Serial.println("Кнопка 3 ");
char z_com[12];
sprintf_P(z_com, PSTR(“G01 Z%i F500”),z_up);
SERIAL_ECHOPGM("Button 3: ");
enquecommand(z_com);
// delay (1);
}
Ok, once you are a member for a little while you will get full privileges but in the mean time here is the video:
That approach is quite different from what I had implemented for the joystick, apart from the fact that Marlin is modified.
1 Like
You had a group of students. 
Your Marlin didn’t want to work for me.
Thanks! I implemented it on SKR 2.
- you need to adjust the resistor manually so that there is room for the same maneuver in one direction and the other.
This can be done by unscrewing a few screws .
And in Marlin set the average value (8000±).
2 Likes
I have installed a joystick to control my MPCNC movement. As previously stated in this thread, you can add a switch to enable/disable the joystick to avoid unwanted inputs during a programmed operation.
I’m sure others have already done this, but something that occurred to me whilst figuring out where to put a switch was that if you have the joystick that has a switch button on the top, you can use this to enable/disable the joystick. Just press the button as you push/pull/twist the handle.
Simple really 
3 Likes
this is awesome
i have an skr pro 1.2 im using for my lr3 build
what do the toggle switches do?
and how does the code work? i can copy and paste that anywhere into the bin file then reflash, and its ready to go?
Steve’s neat ESP Now based wireless pendant with very fast jogging reminded me of this topic.
Anyone happily using joysticks with V1E Marlin on their MPCNC and/or LR3? Or has keyboard, or something else been good enough, or better even? Joysticks seem cool, and fun, curious how much people value them.
I should read the code, but am curious how joystick movement ends up triggering motion.
Are G0 commands injected/prioritized or handled differently by Marlin compared to commands coming from a serial connected host (e.g. Repetier or ESP3D?).
Trying to understand whether there’s a low latency trick/advantage available by joystick code being embedded within Marlin, compared to what’s possible for commands sent from Repetier/ESP3D for example.
Edit: Re-read Topic’s first post and some code focused posts. Read through joystick.cpp, .h and saw how inject_jog_moves is called in idle loop. Nice! Currently doubting a serial connected host (e.g. ESP3D) will be able to achieve as fine grained smooth control as a joystick hooked to the ADC pins. Please confirm/correct my understanding? Am still curious to see how responsive things could be from ESP3D though, may try some experiments…
1 Like
I have been thinking of revisiting the joystick as a digital pendant instead of just a dumb analog joystick with the logic in Marlin. The two main things that are not available to an external controller are
- Inserting movements in relative mode without having to constantly switch state between G91/G90. Especially as another source of commands could conceivably issue movements concurrently, I really don’t want to switch the current state, since it could cause the machine to go off into nowhere.
- Monitoring the queue depth. Currently it keeps the queue partly full and stops issuing commands when the queue is more than half full. There is not a way to do this directly but an external controller could fill the queue completely and drop additional commands when the ‘ok’ doesn’t come back right away. This would require a larger number of shorter commands in order to keep the latency down, and it’s possible that it could hit the limit of the command processing rate.
I think it would be straightforward enough to implement custom gcode commands to achieve both of these. A command similar to G1 but always relative regardless of the G90/G91 state should be straightforward enough. And as for managing queue depth, I can envision a few ways that could work.
It would still mean compiling Marlin with custom features, but it could allow a pendant with a lot more functionality.
Maybe it’s even possible to achieve smooth movement without the extra commands. Some experimentation might show that it works fine and I am overly concerned with possible issues. It would be ideal if it could all be implemented in an external controller without having to hack special features into Marlin. I bought a second joystick recently and I am debating whether to try a new approach for my LR3.
3 Likes
I am similarly paranoid. But I am not optimistic.
Grbl has jog specific commands for this. I would love to get something like that pushed upstream into Marlin.
A demonstration of the ways it goes wrong trying to use G90 without knowing the buffer size could maybe convince Marlin.
1 Like
I could also envision a scenario where each serial port retains its own absolute/relative state, but a broader application of that principle probably wouldn’t work. Multiple masters are going to conflict and they can’t be reconciled in the general case.
1 Like
@jamiek what controller software/hardware would you be using to send gcode to the modified Marlin? V1Pi, or something else?
I built a pendant for my machine, and I used an Arduino Nano to send the g-code. You don’t need much in terms of hardware.
1 Like
It could be a small Arduino like @robertbu said, or I had also contemplated integrating it with the TFT35 controller. I haven’t even begun to look at what that would entail so it might not make much sense (e.g. if the TFT35 exposes no analog inputs) but it might be nice to have the ability to display stuff, and the TFT35 + joystick can be a complete UI whereas a pendant-only device just for jogging still needs a separate controller/interface for the job, and start/stop/pause buttons can’t go on the pendant.
Attaching to a Rapsberry Pi for OctoPrint or cncjs is perhaps possible but it’s a pretty different architecture. I’m not considering those options at the moment.
1 Like
Recently tinkered with ESP3D, although V1E stock ESP01S with ESP3D firmware installed, ESP3D also compiles to ESP32, and, ESP32 has two DACs, if only it had 3+… Guess more could be added…
So… Wondering whether more responsive wireless jogging experience for phone/tablet users would be possible, with no Marlin code changes. By connecting ESP32 to SKR PRO’s pins usually used for ESP01S serial comms, but then also have ESP32 connect to the SKR’s ADC temperature pins read by the existing joystick code. Modifying/extending ESP3D WebUI to enable jogging via Marlin’s joystick support, then also extend ESP3D’s web api to expose functionality to downstream browsers/apps/pendants.
Looks like your joystick edits work for SKR Pro 1.2. Nice!
Folks wanting wireless pendants with joysticks and/or TFTs could use websocket connection to Marlin Joystick aware ESP3D/ESP32.
Relatively new to this stuff, so I’m assuming there’s a simpler/better way… For example, I still don’t know what the request-response latency is for existing ESP3D/ESP01S yet, that might be good enough with the right UI/keyboard-shortcuts.
For me, I’ve never been bothered by wires. The issues I find with using a second microprocessor are:
- Lack of smooth movement (not a huge issue and possibly solvable)
- Interference when using two serial inputs (i.e. cannot use it while a job is running to make any adjustments)
- Lack of coordination/sync between the control board and the pendant
All issues Jamie mentions or alludes to.
For the last point, I can request the current position from the control board, but, because of point 2, I cannot request it repeatedly/automatically. I need to do it manually, and if I forget, it is possible to ruin a job. Points 2 and 3 could be solved if the SD card reader and g-code sender were part of the pendant.
Here is my pendant. I built it shortly after I finished my Burly. I know a lot more now, so maybe it is time for a V2.
5 Likes
Love the pendant. But it definitely brought back memories of the paddle Mum would (quite rightly) discipline us with
I don’t know enough to have an opinion and am probably asking too many questions. Going to dig around and experiment a bit. Appreciate the info and look forward to seeing what people come up with. Cheers!
1 Like
Oh i love that! Simple and elegant!
1 Like
I am not a huge fan of running gcode over a uart. I don’t think the protocol handles errors well enough. Uart over USB is fine, but I think some of the (very rare) issues with the tft mode are just because of flaws in the protocol. I would be especially worried if it was over a long cable.