My Joystick jog control
-
Following on from this thread where I asked for help to write the conditional gcode macro, https://forum.duet3d.com/topic/19541/yet-more-conditional-gcode-help-required/18
I've now got this up and running. It enables me to jog multiple gantries in sync on my CoreXYUVAB machine, using a simple, cheap, switch type joystick. But the code could easily be modified to suit the sort of 3 axis machine that most sane people have.
I chose to mount the joystick onto the machine but it could just as easily have been mounted in a small box to make a sort of pendant.
Explanation and demo here if anyone is interested https://youtu.be/wCR5Ao0iH-c
-
Nice! I have a feeling a number of CNC users especially will be keen to replicate this!
You mentioned needing 3.2 RRF to allow for checking if the printer is currently printing. could you try using
if state.status != "processing"
to check if there is a print running.. we can discuss further in the macro thread if you like.
-
@T3P3Tony said in My Joystick jog control:
Nice! I have a feeling a number of CNC users especially will be keen to replicate this!
You mentioned needing 3.2 RRF to allow for checking if the printer is currently printing. could you try using
if state.status != "processing"
to check if there is a print running.. we can discuss further in the macro thread if you like.
Thanks Tony. Yes, it's cheap and simple enough to do and doesn't need any special parts. For sure I can try that - I wasn't aware of the "state.status" thing - looks like it should do the job. I'm a bit busy today but .....
-
One other thing. I'm thinking of adding another push button to give long / short jog moves rather than using "iterations" to increase the move length. So for example, if the button is pressed in conjunction with the joystick, then the move length would be (say) 10mm, otherwise if the button is not pressed or it is released, the move length will revert to (say) 0.5mm. So use long (fast) jog moves to get somewhere close, then use short (slow) jog moves for fine positioning.
There are kind of endless possibilities really.............
-
@deckingman yep, that would work you can print a big button with "TURBO" on it.
-
maybe instead of having move amount change by interation you keep the same move amount but you increase the move speed ?
-
@arhi said in My Joystick jog control:
maybe instead of having move amount change by interation you keep the same move amount but you increase the move speed ?
Doesn't really work - but maybe a combination of the two might.
For precision adjustment, I need (say) 0.5mm increments, so speed is largely irrelevant. The difference between say 500mm / sec and 50mm/sec when only moving 0.5mm is in practical terms negligible. To get the full width of the carriage (say 400mm) would take a long time in 0.5mm increments, regardless of the speed of each 0.5mm move. So, setting a high speed and increasing the move length is actually the fastest way to travel a longish distance in this particular case. -
@deckingman said in My Joystick jog control:
To get the full width of the carriage (say 400mm) would take a long time in 0.5mm increments, regardless of the speed of each 0.5mm move
it depends on how fast a loop can execute, in theory, if loop is quick enough you want short moves and lot of them with only speed change as in that case they behave like continuous move with speed change, but if loop is too slow so the short moves are not continuous but have both accel and decel for each move, then yes, it will not work..
If you have one analog input left you can probably read that analog input and multiply with the move distance / speed instead of iteration so just a single additional potentiometer should solve it... need to only see how to read analog value from the gcode
-
@arhi said in My Joystick jog control:
@deckingman said in My Joystick jog control:
To get the full width of the carriage (say 400mm) would take a long time in 0.5mm increments, regardless of the speed of each 0.5mm move
it depends on how fast a loop can execute, in theory, if loop is quick enough you want short moves and lot of them with only speed change as in that case they behave like continuous move with speed change, but if loop is too slow so the short moves are not continuous but have both accel and decel for each move, then yes, it will not work..
For sure - but I'm talking about the behaviour that I've witnessed in practice, rather than any theoretical behaviour that might be possible.
The loop appears to run relatively slowly - that may be because of the M400 that gets executed before every move. Dunno - just a guess. But if the loop runs too fast, then I run the risk of several moves being queued so that when I release the joystick, the carriage keeps on moving.
If you have one analog input left you can probably read that analog input and multiply with the move distance / speed instead of iteration so just a single additional potentiometer should solve it... need to only see how to read analog value from the gcode
This is just simple switch type joystick. It uses micro switches not potentiometers. Just digital high/low - nothing analogue happening.
-
The loop appears to run relatively slowly - that may be because of the M400
M400 will prevent queuing for sure and making thing go very slow yes.. I believe there is a move length and speed that will without M400 work great, have not tested myself, will once I get a chance
This is just simple switch type joystick. It uses micro switches not potentiometers. Just digital high/low - nothing analogue happening.
sorry I was not clear enough. You leave your stick as is and add one more pot to it (instead of few buttons) and then with pot you select speed/lenght of the move instead of using iteration+0.5. So instead adding button for .5/1/5mm selection that goes with the stick, I suggest adding one pot selecting from .1 to 10mm
-
@arhi TBH, I'm perfectly happy with it as it is and have no great desire to make any changes. It does what I set out to do so I'll move on to some of the other things that I want to do (like getting a 6 input hot end to mix).
But for sure, one could play all sorts of games with the code to change the behaviour to suit whatever outcome one desired.
-
@T3P3Tony - for info, I've now added a "turbo button" - works a treat. Either using "iterations" to increase the distance or using this "turbo" button both work although I prefer this latter method.
I've also wrapped the entire thing in a " if state.status != "processing" " statement - thanks for the tip. I haven't tested it fully yet because the machine isn't in a state where I can actually print anything just now.
-
@deckingman cool! I did not test the "processing" part with triggers but did a quick macro to confirm it reported properly with/without a print running.
-
@T3P3Tony said in My Joystick jog control:
@deckingman cool! I did not test the "processing" part with triggers but did a quick macro to confirm it reported properly with/without a print running.
@T3P3Tony - I guess we can be fairly confident that it'll work then. I posted the actual code on the other thread. The reason for two threads is that the first is about help with conditional gcode and this one is more about the hardware and the application in practice. But feel free to merge them if you think that would be better.
