Great! You probably already realized, by disabling the joystick via the enable switch, you can move the joystick and use M119 to view the measured values which makes it relatively straightforward to tune the range and dead band values to your particular joystick.
I recommend setting the min and max a bit wider than the extreme values that your joystick produces, because if the joystick exceeds the min or max value, the movement will stop. This is again for safety but it can be annoying if the movement suddenly stops when you are trying to jog near top speed. (At least it will obey acceleration.)
I was pleasantly surprised to find out that when the joystick is enabled and a gcode is loaded, the joystick is temporarily disabled until the gcode is completed. I didn’t expect this behavior, I thought that the joystick while enabled would send movements to the machine no matter if it was doing a job. I’m not complaining, on the contrary, that will help to avoid accidental movements, but I thought that was the function of the switch mapped in my case on pin 42.
The brown wire is another GND pin and the yellow is the enable line. When the button is open the enable pin is at +5 with an internal pullup, and pressing the button shorts to GND, pulling the pin low to signal enable.
The method I had in mind would include calibrating the values for a particular joystick, since joysticks even of the same model are not likely to have precisely the same voltages or ADC readings. Once you can see the M119 values changing in response to moving the joystick, it means that it is physically working and reading the voltages. The limits values in Configuration_adv.h represent the maximum and minimum values that are expected from the joystick, so that it is properly scaled and it will go full speed when the joystick is pressed all the way. These values also define a dead zone in the middle of the range so when the joystick is released it won’t move at all. Without a dead zone it would slowly creep in one direction or the other when the joystick is released.
I hope this is helpful. I’m not sure which area might need more elaboration so just ask about the areas where you are getting stuck.
The “PWM header” is six pins in a line. The leftmost pin is +5V and the second pin is GND, which what I am using. It is equivalent to the other black wire but was easier to use the GND pin from the PWM header rather than splicing and soldering both connections to a single GND pin.
Thanks for the clarification. One thing I just thought of. Some people are connecting their joystick to a Nano… then the Rambo… any advantage to this route?
I have no experience with Jamie’s code, but in theory an integrated joystick should be smoother, faster, and quicker to stop…and it requires no additional hardware and no programming beyond the joystick. An Arduino-driven joystick opens the possibility of injecting arbitrary gcode into the system to implement any functionality. This type of control is often referred to as a ‘pendant’. There are some posts on the forum about nano-driven pendants as well as at least one project on Thingiverse. I’ve created my own pendant. It still a work in progress, but I use it all the time.
That is a very different approach where the nano measures the joystick position and feeds gcode to the main controller. It has the advantage that additional buttons can be added for special functions. It is not as closely integrated with the movement queue of the main controller. By measuring the joystick with the main controller it can monitor the queue depth and the hope is that it would get smooth movement and quick response so there is minimal lag between joystick movement and physical response.
I think a quick response and smooth movement should also be possible with the nano approach if it were to flood the queue with small movements until the ‘ok’ response doesn’t come back immediately. I don’t know if the nano firmware does that, but I think in principle it should be possible to get nearly the same responsiveness.
I’m not sure exactly how the nano firmware works but I would think it must put the controller in relative mode (G91 and G90). This is probably bad news if you accidentally move the joystick while a job is running. The analog joystick has access to internally insert incremental moves without switching modes, and for safety is also disables itself if a job is running, which it detects by peeking at the queue depth. An external controller doesn’t have that level of access.
The external nano has more flexibility in the types of input, so besides buttons, an encoder-based jog wheel would also be an option. Adding encoder-based jogging to Marlin directly would be a brand new feature we would have to start from scratch. More broadly, an external controller like a Raspberry Pi can really do anything, like using a camera to home optically based on fiducial marks. Marlin would never be able to do that on its own. The analog joystick in Marlin is purely a single function.
It is also possible to use both, where an analog joystick connects directly to the main controller and an external controller offers additional features.
I am of the opinion that the thing we really need is a gcode spec for Jamie’s joystick movements. If we could send a special G1 command or a new command that would do that, the hardware choices would really open up.
I am a big fan of your motion system Jamie. But I wish we could just use something like a tft35 instead.
I like the idea of a joystick connected directly to the main controller and then a jogwheel to an external for additional features. Once i get the joystick working, I’ll look to incorporating the jogwheel + nano + butons.
It is also possible to use both, where an analog joystick connects directly to the main controller and an external controller offers additional features.
If I was starting from scratch, I would strongly consider this approach. When I built my pendant, I did not know your code existed (wasn’t following the forum).
I’ve looked at the firmware for two other pendants. Each approach the problem a bit differently. Personally I use absolute coordinates, break all movements into small pieces and send each piece over time at a rate that the machine can process without filling up the queue. The result is a slower than the machine is capable movement with some stuttering in the movements. Not really an issue…just does not feel professional.
This is probably bad news if you accidentally move the joystick
Yep. The external Nano solution has no safety net…and since I’m using absolute coordinates and the pendant does not know the current coordinates during cutting, bumping the joystick would likely be catastrophic.
Maybe it would be as simple as extending G1 with “G1 … R” to always move relative irrespective of G90/G91 state. (This seems like it would make sense anyway for jogging with Octoprint or CNC.js).
And perhaps a generalization of “G4 ... D<n>” could wait until the queue depth is less than or equal to n, with n=0 by default.
It would be some extra traffic to have G1, G4, G1, G4, … but an external controller would probably be able to achieve the same smoothness without much extra magic.
That seems like a very elegant solution. The D4 is a critical piece, right?
I wonder if they will be worried about adding complexity to the G1/G4 commands, since they need to be executed as fast as possible. Although, they could have made it not see any difference in speed if you don’t add R or D.
How critical is the R part of it? Can’t you assume the user will not be jogging intentionally during gcode sending? If they do, isn’t that a problem with the pendant safety or the user?
