The design of the ranges is such that it won’t move within the dead band, and also outside the max range it will also stop. This was supposed to be a safety feature so if the thing came unplugged (and you were lucky with the floating voltages) it would stop instead of taking off at max speed. With an enable switch this is much less important and probably better to just use max speed beyond the limits too.
But given how it’s written now, the way I set the dead band is to push the joystick to the left and gently release, and note the value from M119. Then push right and gently release, and again note the M119 value. There is likely to be some backlash in the joystick mechanism so these “center” values won’t be the same. Do it several times if you want to get good confidence in the values. Then take these values and widen it a little and it should be within the dead band when its anywhere in the backlash area.
Then for the min and max, do the same thing but pushing the joystick to the maximum position, and then widen a little. But if you are already seeing 0 or 16383 then you can’t widen from that.
Also the M119 works even when enable is off, so you don’t have to worry about crashing while trying to get these readings.
As for crashing, the dual endstop firmware should have the soft stops set for xmin and ymin. If you haven’t homed then it wont let you move to -X or -Y from the point where it was powered on, or if you have homed then it wont let you move past zero. But if you disabled steppers and dragged the gantry in the +X or +Y and then started jogging, then it can crash because endstops are not monitored except when homing. And in any case it can crash at the +X or +Y ends.
Mine seems to stop-start-stop-start even within the max band … was never able to track down exactly why I even changed the code to get rid of the max band behavior and still saw it (to a lesser extent). I don’t do any marlin development so would take a long time to figure out. Maybe it’s got some movement queue that runs empty? Or maybe I just need a new cable… although I still saw the same thing doing exponential smoothing over hundreds of samples.
I have seen “stuttering” motion when moving in (for example) +X when I switch direction slightly to +X with a little bit of diagonal +Y. In my mind I am blaming it on the cornering behavior but really I don’t know. (And it might not be the same thing you’re seeing either…)
I’m seeing that as well. Not sure if it’s related or not but it happens in a straight line semi randomly too. After a few hours of tinkering it didn’t seem like enough of an annoyance to bother with since it doesn’t keep me from working it’s just makes me realize I am a bit OCD
Thanks for the inputs. I managed to get it smoothed out a bit. I opened the dead zone band a lot by following the advice from @jamiek. And opened up range to almost the full width, though it still halts occasionally if I push too fast even if not full travel.
I also found a switch in Configuration_adv.h that gives me an extra decimal point on the LCD display for values with less than three digits. Uncomment the following line:
//#define LCD_DECIMAL_SMALL_XY
Still crashes into the end stops after a G28. These are what I think should be limiting that. Does this look right? Directly below this in the file is something about software endstops (M211), but I have not used those before. LCD menu never needed to.
Those are travel limits, yes, and you have to set your correct X/Y/Z size. Keep in mind that for Z typically 0 is the lowest point and the numbers get bigger, so I don’t know how it’ll react if you set zmin and zmax settings. It might prevent you from moving to -z.
The soft endstops after that will stop the machine after homing. But not by looking at the endstop switches. The dual endstop firmware enables min x and min y, but none of the rest.
I think there is a hard endstop setting elsewhere that will use the endstops all the time, but I have never used it.
FYI I recently had to switch to the latest bugfix version since G38.2 probing was broken in my release version. It seems that I am getting less stutter now and I can move in multiple axis /diagonally smoothly at least some of the time.
Hooray! I finally got my integrated pendant put together that uses the original discount Rep Rap display. A combination a couple approaches from @jamiek and @arminth. Thanks to @tailslide for working out the Rambo pins. I still want to add a couple more function buttons on the Arduino (to store and recall position), maybe some others. Except for the above issues with the end stops and the less than smooth movement it works pretty well. Now if I can only remember to turn off the enable when I am done with it.
NOTE; When using while cncjs is connected it seems to stall at consistent intervals while jogging. I am guessing this is due to the position requests from cncjs interrupting it.
I enabled the soft end stops in firmware but joystick motion does not respect those either. I suspect, but @jamiek would have to confirm, that the joystick module is sending the move instructions directly to the steppers (planner, though I am clueless as to what that really means) while overall maybe, the firmware handles gcode move requests and compares them against the limits before executing the move instructions. I think this is what he meant when he intro’d the project and said it was a dumb joystick? I wish I was a better programmer so I might have a shot at understanding how this all is working.
Not a huge issue, but it would be nice to not have to worry about crashing while whipping around the table.
The joystick should be injecting movements similar to inserting gcode commands prior to limit checking, i.e. it should respect soft stops. I can try turning on soft stops and see if I can reproduce the behavior. I should be able to resolve whether it does or doesn’t respect soft stops.
If it does, then it means we might find a remedy elsewhere in the settings. If it doesn’t, then I can see what it would take to respect soft stops.
Okay, I tried it and saw the same behavior, i.e. joystick does not respect soft stops.
After a little digging I found that buffer_line does not limit motion and I should have applied limits prior to inserting the movement.
I’ve made this change and tested it and it appears to work. I’ve got a PR here. Maybe it will make it in to upstream bugfix-2.0.x or if you want to manually patch your code the PR should have the information you need (one line change).
Edit: merged in 23 minutes! I think that’s a personal best (and now me taking credit for someone else’s work).
Noob question: How often does a mere mortal need to check for Marlin software updates? How long can I use the version that @vicious1 flashed before shipment? I assume I can go a long time if I’m not messing with things like joystick customization, but what if a serious issue is corrected?
And, before flashing an upgrade, how can I backup a copy of what I have now?
You can use it forever. It isn’t connected to the Internet, so no security issues there. The reason to upgrade would be if they added a nice feature you wanted, or fixed some behaviour that was bothering you. New versions have new bugs too though.
Are you sure about those pin assignments? If so, I must be missing something. As far as I can tell (and I admit I have never had to deal with Marlin pin assignments before) Analog Ext 4, 6, and 8 correspond to RAMBO Pins 59, 58, and 57 respectively. This is based on checking a couple different sources - including page 65 of the Rambo Manual. I agree with Pin 4 for PMW Ext 6
Therefore, shouldn’t it be: #define JOY_X_PIN 59 // 3- Analog Ext 4 #define JOY_Y_PIN 58 // 4- Analog Ext 6 #define JOY_Z_PIN 57 // 5- Analog Ext 8 #define JOY_EN_PIN 4 // PWM ext pin 6
Thanks in advance. Also, thanks to Jamie for sharing and of course Ryan for everything.
My DP switches arrived today and my joystick should arrive next week. This is so awesome I can’t wait to try it out.
Mike
EDIT: Since Greg confirmed the pin mappings striking through my original message to avoid confusion for anyone reading this later.
