I don’t know if the depth control on G4 is strictly necessary. It is probably safe to assume a fixed queue depth (16 seems standard) and split the commands into small enough pieces that 16 movements is a pretty short lag, say 1/4 second or so. It might start to get into rate issues in cases of large numbers of very small movements, and Marlin itself will start coalescing movements that are too small into single items in the movement queue. So even though it might not be necessary, I could see it being potentially useful to keep the max queue depth short with larger movements. And you wouldn’t want to completely deplete the queue with G4 because it will want to come to a complete stop between segments.
As far as a “relative override” R option, yes it is risky with existing pendants and there should probably be a safety off switch to reduce accidents. The other risk with G91 … move … G90 is that the machine might not have been in absolute mode to start with. Relative coordinates are rare for our usual workflow/CAM but just from a comfort level I am a bit uneasy at possibly leaving the machine in a different state. A push/pop model would be great but I don’t think that exists.
For a private branch or fork there is no penalty to adding warts to existing commands, but if we’re hoping for an upstream merge, it is worth considering whether changing such a fundamental command is going to have any chance of acceptance. An alternative would be to invent new gcodes that would only be enabled with pendant compile options. This also has the benefit that it would fail gracefully with unrecognized commands doing nothing, rather than proceeding with not-quite-right command interpretation. Or if it works well enough to flood with tiny movements, then this is all moot and no firmware update is necessary.
Hi Guys
I’ve been reading this thread for a while now and decided to add a Joystick to my RAMBO 1.4 as well.
I wired everything as described and according to the pictures and also checked the schematics but still my Joystick does not work as expected.
I’ve got my X, Y and Z also wired up to A3, A4 and A5. Also the definitions are like Jamies example: #define JOY_X_PIN 3 // Rambo 1.4: Use pin A3 on Analog #define JOY_Y_PIN 4 // Rambo 1.4: Use pin A4 on Analog #define JOY_Z_PIN 5 // Rambo 1.4: Use pin A5 on Analog #define JOY_EN_PIN 4 // Rambo 1.4: Use PWM ext pin 6
When I read the readings with M119 in Pronterface the values are returned. But for some reason only the Y axis moves according to my joystick movements. Moving X does not affect the reported readings at all. Moving the Z Axis (rotating the joystick) does change the Z values but the X values change in the opposite direction as well.
Twisting the Joystick all the way clockwise decreases Z to the minimum pf Z15 (I have the Z axis inverted) but increases to the maximum of X16056. Twisting counter clockwise increases Z to the maximum of Z16383 but X goes down at the same time to X73.
I’ve checked the wires with a multimeter and each axis properly changes the voltage gradually from almost 0V to almost 5V when moving it from one extreme to the other. Moving one axis does not affect the voltage of any of the other axes. So electrically everything should be correct and the wires are connected to the correct pins.
So it appears to me that the problem is in the firmware somewhere. For some reason the Voltage coming in from A5 are misinterpreted as being both the reading for A5 and also the oposite reading for A3. Voltages coming in from A3 have no effect on the reported Joystick values.
What am I missing? Is there another option I should set that affects those analog inputs? Or did I break the analog ports of my RAMBO somehow? Everything else seems to work still. Googling around did not produce a lead I could follow.
Didn’t find an edit function so i’m repying to myself.
In case you’re wondering, im using the Firmware Marlin-1CNC_Rambo from Github that I’ve downloaded a Week Ago.
I wired everything up to a Brearboard and metered the live cirquit. But i also metered resistance while disconnected. When disconnected I had to meter the middle pins of the pots once to VCC and once to GND to track the movements.
I could try different ports but I haven’tquite figured out which physical pins correspond to which number in the firmware so I’m not sure which alternative analog pins have a physical pin on the RAMBO and which numbers I need to assign in the config file.
Thanks a lot Greg for the swift reply and help.
The Problem wasn’t the pins or settings but your suggestion to move the plugs to different analog pins helped me to figure out what went wrong.
As it turned out it wasn’t software at all. That Dupont socket coming from the X axsis to the A3 pin was only crimping the insulation of the wire. So in fact it wasn’t connected.
I’ve had so much trouble crimping Dupont sockets to those tiny ribbon wires before. I was quite lucky I only messed up this one. But it’s interesting to know that the Z axis can leak through to X when X is not connected.
Anyway, after re-crimping that socket and wiring it all back up I can finally move my axes the way they should.
Now on to my next problem. When moving any axis the movement is very jerky while speeding up. if I hold the joystick in a fixed movement position the movement speed becomes constant and slowing down also works smooth afterwards. But each time I speed up from the deadzone the movement begins jerky or stuttery for about 1-2 second.
I’ll search around in the forum first. I’m sure ther’s a solution somewhere.
Glad you figured it out! For the jerkiness you can try reducing the min values and increase the max values… if the readings spike out of range it will stop causing jerkiness.
Definitely takes some practice with the crimpers… I find if I crimp to the first click I can feel inserting the wire when the insulation bumps up against the second set of wings so I don’t go to far.
I have seen this before, and I have tried to figure out the root cause but I haven’t figured it out. Specifically, when you’re moving and you press the joystick more, it will not immediately speed up, but it slows down a bit and then speeds up. So I’m sorry to say this might be “normal”.
As for going out of range, this is also possible. If the joystick values are below the min or above the max, it is treated as no movement, as if the joystick were in the dead zone. This was initially intended for safety if the joystick became unplugged it would be less likely to just take off at full speed, but now with the enable switch it’s much less important.
But in any case to avoid going out of range the minimum and maximum values should be slightly wider than the values that the joystick produces, i.e. a slightly lower minimum value and a slightly higher maximum value, so the joystick can’t go out of the programmed range.
If you are using the little cheap joysticks that is pictured in Jamie’s hookup post or you see in my pendant, be aware they are not very good. I found when you first engaging these joysticks, the reading often spike to near max/min value and then settle down. I purchased a package of 10 from Amazon (for $12). I tested 4 of them, and they all had the same problem. If you code for Arduino at all, write a bit of code to output to the console the analog value for each axis of the joystick to see what kind of values the joystick is producing.
And the problem is not just the spiking. Min and max values were reached when the joystick was only half way to the end stop, and there was a pretty good variation between joysticks (and perfect spec) on the min, max and dead stick values.
Sounds pretty much exactly like the joystick I got from Aliexpress. I guess that’s the source of the jerkyness.
I was thinking about that too but haven’t looked any further yet. So far I just sent a M119 via pronterface and tried to hold the joystick in place to get values. Having a continuous output would help.
I’m a dinosaur programmer, i write COBOL But i can interpret C++ enough to adapt existing code. Starting from scratch would be tricky for me. I’ve managed to adapt the Nano firmware of the pendant from Dave S to also act on the button connected to pin D7. So I would know how to send M119s from the Nano via serial to the rambo. But at what intervals without bogging down the rambo? I guess sending M119s every 100ms wouldn’t be the best idea right? After hearing that frequent position polling in CNC.js can briefly interrupt gcode being played I’d assume too many M119 could affect Marlin as well.
In Marlin I’ve just changed the Configuration_adv.h file so far. I don’t have any idea where to put code to write those values to the console in a loop. Or how to read them.
I’ll have to dig deeper into that subject.
Oh one thing that bugs my mind for a while now. Every gcode player software I’ve seen so far and also this Joystick pendant have a Home X/Y button. I have my Primo wired with serial steppers and therefore no endstops. Each time I accidentally press Home X/Y it moves towards zero and crashes into the frame until I reset. So how would I use that function without any endstops connected on X and Y? Or is everyone here using such joystick pendants also using dual endstop with paralell wiring? Maybe I’m missing something. Even Zero X/Y, moving it away a bit and Homing X/Y does not return to the previous zero position but endlessly runs into the frame.
What I was referring to was to take a Nano or other Arduino board (not your Rambo board), hookup the joystick, and write a few lines of code to read the analog pins. I’d be glad to send you the few lines of code to read a couple of analog pins and write them to the console if you like. In theory, you could flash the same code to the Rambo, but I’m leery of that choice.
Oh one thing that bugs my mind for a while now. Every gcode player software I’ve seen so far and also this Joystick pendant have a Home X/Y button…
I’m not sure which specific home “button” you are referring to. For pendants and custom menu items, it is possible to modify the pendent or custom menu code to fix the home issue locally. For an global solution that works everywhere, you have two choices. You can add end stops to your serial setup (this is not dual end stops, just end stops on a serial), or you can ‘disable.’ the end stops. I put disable in quotes because what you will be doing is fooling the firmware into thinking the machine is already at the end stop position.
To fool the firmware, in configuration.h you want to edit this block of defines:
// Mechanical endstop with COM to ground and NC to Signal uses “false” here (most common setup). #define X_MIN_ENDSTOP_INVERTING true // Set to true to invert the logic of the endstop. #define Y_MIN_ENDSTOP_INVERTING true // Set to true to invert the logic of the endstop.
…and change it to:
// Mechanical endstop with COM to ground and NC to Signal uses “false” here (most common setup). #define X_MIN_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop. #define Y_MIN_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop.
So you would be changing two ‘true’ values to ‘false’. On my version of the firmware, this block starts at line 662.
Once changed, the board will looking for an open connection for the home position. Since you don’t have end stops plugged in, will think it is already at home. Note that the machine will move slightly for a ‘retest’. I would recommend this same change if you want to add end stops to your serial setup. Frankly, having had no end stops on my Burly and having end stops on my Primo, I’m now of the opinion that end stops have only minor value.
Ah got it. I quickly hacked together a new code that polls A0 - A2 of the Nano and wired the joystick up to the Nano. But testing it did not show any spikes. At least when polling every 250ms and writing the values to serial I see the values increase/decrease without any jumps. So either I have to poll faster or my joystick is not the issue and the jerkyness is something else. But if that’s a known problem I can live with it I guess.
Thanks for the tip to invert the X/Y endstop triggers. Now my Primo no longer crashes into the frame when I accidentially home and makes my machine a bit safer. I actually have endstops mounted but haven’t botherd wiring them up yet as I read quite often in the forum that you don’t really need them. Now I just need to be careful to not to Auto Home by accident in the LCD menu as that still rams the Z axis into the baseplate if I have no touch plate connected.
This is my first CNC and I haven’t actually cut anything yet. Once I figure out my workflow I might connect the endstops later if I see the need for it.
But I still don’t get why the defaults in the V1CNC_Rambo Firmware expect there to be endstops in the non _dual version while people typically use none with serial wiring. Combine that with Auto Home being very prominent in the LCD menu and other big “Home” buttons in Pronterface, CNC.js etc. makes such functions dangerous at best, since the machine tries to ram into the frame and baseplate when clicking it by accident. The only way to stop a homing process I found so far is resetting or cutting the power. Or is there another way to stop homeing when a crash is about to happen due to no endstops? Maybe those X/Y endstop triggers should be inverted by default in V1CNC_Rambo for Newbies like me, so it’s not that easy anymore to chrash the machine.
So the only use for Homing I could find so far is for Z homing. But only as long as the router bit is grounded and a touch plate is connected underneath. Plus the X/Y enstop triggers must be inverted and the firmware is reflashed. Other than that I guess I just have to be careful not to hit any homeing buttons by accident anymore. Not that easy when the rotary switch of the LCD reacts that wonky. When selecting the “Move Axis” menu it happens very quickly that you accidentially move down 2 lines instead of 1 and select “Auto Home” instead.
You need to sample more than 4 times a second. Try delays between 50ms and 10ms. Flick or move the joystick then immediately uncheck the scroll checkbox on the monitor window. This will allow you to examine the values during the flick or other movement.
still rams the Z axis into the baseplate if I have no touch plate connected.
Make a habit of connecting the alligator clip to your touch plate when it is not in use. The machine will think it is already at the touch plate and only move a tiny bit for the retest. Also, if you don’t have one, an emergency stop button can be a lifesaver when things go wrong.
But I still don’t get why the defaults in the V1CNC_Rambo Firmware expect there to be end stops in the non _dual version while people typically use none with serial wiring.
I searched configuration.h and configuration_adv.h and didn’t find any way to turn end stops off. The roots of Marlin are 3D printing, and I all 3D printers have end stops.
The Arduino serial monitor has a plot function that is very helpful too. 33ms is the standard frame rate for video and that should be pretty good for looking with a plot.
Good idea. I keep that in mind once I wire up the touch plate. I actually do have an emergency stop but that’s wired to the main power lead and cuts the power of the entire machine. I thought it’s safer this way in case my Makita Router is also running and something happens. I was hoping there’s some softer way to stop a homing program. Maybe some Gcode command I could send from my Nano to the RAMBO if I press a button on my pendant. Something that cancels homing but does not reset everything else like it does with the Reset button or the emergency stop.
What happens if you comment out these two on line 626 of Configuration.h? #define USE_XMIN_PLUG #define USE_YMIN_PLUG
I haven’t tested it myself but I would have thought that commenting out these two defines tells Marlin not to expect X and Y endstops. Not sure what would happen if you send a “G28 X Y” and those #defines are commented out.
Great tip thanks. I’ve modified my analog monitor code in the Nano to write the three analog values in 33ms intervals and got a nice graph of the three axes. But still all the graphs show very smooth curves on all joystick movements and no sudden spikes are noticable. Except when starting the graph plotter until the point it has the min/max values for the graph established. Afterwards everything reacts as expected. So I still doubt that the joystick is the reason for the jerky movements.
Hmm, not sure it could be the source voltage. If the source voltage was an issue wouldn’t we see strong fluctuations in the readings when the joystick is in center postition as well. I only see variations of about +/- 1-2 when repeatedly issuing M119s and the joystick is untouched.
Type conversions or decimal overflows of the values might be a reason for the stuttering but then I would only expect to see these stutters when moving the joystick to a max position. But I mostly see them when accelerating from a standstill until it reached the desired speed. Even when I just slightly move the joystick out of the deadzone it stutters for the first few seconds. Once the steppers are moving, further movements in the joystick are translated pretty normal.
Maybe acceleration handling in Marlin could be the problem. The movements almost looked as if one piece of the firmware is trying to accelerate and another is slowing it back down again. Isn’t Marlin taking care that the steppers are not accelerating too much when moving? I’ve seen some Jerk settings in Configuration.h but haven’t looked yet what they do. But I got the feeling that something like this is “fighting” the movements coming from the joystick.
It would be best if there was a way to get such a joystick graph off Marlin or being able to debug what’s going on exactly in Marlin during movements. But I haven’t looked into that yet or know if that’s even possible.
But i can interpret C++ enough to adapt existing code. Starting from scratch would be tricky for me. I’ve managed to adapt the Nano firmware of the pendant from Dave S to also act on the button connected to pin D7. So I would know how to send M119s from the Nano via serial to the rambo. But at what intervals without bogging down the rambo? I guess sending M119s every 100ms wouldn’t be the best idea right? After hearing that frequent position polling in CNC.js can briefly interrupt gcode being played I’d assume too many M119 could affect Marlin as well.