Yet more conditional gcode help required
-
@dc42 said in Yet more conditional gcode help required:
Another way is to use your original code but replace all the XYUVABC coordinates in the G1 commands by calculated values, something like this:
G1 X{0.5+0.1 * iterations} Y{-(0.5+0.1 * iterations)} ...
Ahhh - that looks good! I tried something similar but it didn't work - because I used plain braces rather than curly ones. I'll give that a go..............
-
For the sake of completeness, here is the final code that I ended up using. After playing around with it, I ended up using just G1 X{0.5+interations}........etc, rather than using fraction's of "iterations".
G91; Set relative M400; wait for any moves to finish G1 F6000 ; set feedrate to 100mm/sec M118 S"Trigger 5 - Joystick" while sensors.gpIn[5].value=0 | sensors.gpIn[6].value=0 | sensors.gpIn[7].value=0 | sensors.gpIn[8].value=0 if sensors.gpIn[5].value=0; joystick left if sensors.gpIn[7].value=0 ; joystick left and forwards M400 G1 X{-(0.5+iterations)} U{-(0.5+iterations)} A{-(0.5+iterations)} Y{-(0.5+iterations)} V{-(0.5+iterations)} B{-(0.5+iterations)} echo "Left and forward" elif sensors.gpIn[8].value=0; joystick left and backwards M400 G1 X{-(0.5+iterations)} U{-(0.5+iterations)} A{-(0.5+iterations)} Y{0.5+iterations} V{0.5+iterations} B{0.5+iterations} echo "Left and backwards" else ; joystick left only M400 G1 X{-(0.5+iterations)} U{-(0.5+iterations)} A{-(0.5+iterations)} echo "Left" elif sensors.gpIn[6].value=0; joystick right if sensors.gpIn[7].value=0 ; joystick right and forwards M400 G1 X{0.5+iterations} U{0.5+iterations} A{0.5+iterations} Y{-(0.5+iterations)} V{-(0.5+iterations)} B{-(0.5+iterations)} echo "Right and forward" elif sensors.gpIn[8].value=0; joystick right and backward M400 G1 X{0.5+iterations} U{0.5+iterations} A{0.5+iterations} Y{0.5+iterations} V{0.5+iterations} B{0.5+iterations} echo "Right and backwards" else ; joystick right only M400 G1 X{0.5+iterations} U{0.5+iterations} A{0.5+iterations} echo "Right" elif sensors.gpIn[7].value=0 ; joystick forwards only M400 G1 Y{-(0.5+iterations)} V{-(0.5+iterations)} B{-(0.5+iterations)} echo "Forward" elif sensors.gpIn[8].value=0 ; joystick backward only M400 G1 Y{0.5+iterations} V{0.5+iterations} B{0.5+iterations} echo "Backwards" else break
Thanks for all the help guys.
-
For further completeness, I've added a "turbo button". So instead of increasing the distance using "iterations", I simply press the button in conjunction with moving the joystick. What that does is move the gantries 20mm if the button is pressed or 0.5mm if it isn't. I prefer this method but either one works.
I've also wrapped the entire thing in a "if state.status != "processing"" statement (thanks for the suggestion @T3P3Tony). What that does is checks to make sure that a print is NOT in progress which will do what the M581 R2 parameter will do in the next firmware. Here is that version of the code
if state.status != "processing" ; make sure that a print is NOT running G91; Set relative M400; wait for any moves to finish G1 F3000 ; set feedrate to 100mm/sec M118 S"Trigger 5 - Joystick" while sensors.gpIn[5].value=0 | sensors.gpIn[6].value=0 | sensors.gpIn[7].value=0 | sensors.gpIn[8].value=0 if sensors.gpIn[5].value=0; joystick left if sensors.gpIn[7].value=0 ; joystick left and forwards M400 echo "Left and forward" if sensors.gpIn[4].value=0 ; check for long move button press G1 X-20 U-20 A-20 Y-20 V-20 B-20 else G1 X-0.5 U-0.5 A-0.5 Y-0.5 V-0.5 B-0.5 elif sensors.gpIn[8].value=0; joystick left and backwards M400 echo "Left and backwards" if sensors.gpIn[4].value=0 ; check for long move button press G1 X-20 U-20 A-20 Y20 V20 B20 else G1 X-0.5 U-0.5 A-0.5 Y0.5 V0.5 B0.5 else ; joystick left only M400 echo "Left" if sensors.gpIn[4].value=0 ; check for long move button press G1 X-20 U-20 A-20 else G1 X-0.5 U-0.5 A0.5 elif sensors.gpIn[6].value=0; joystick right if sensors.gpIn[7].value=0 ; joystick right and forwards M400 echo "Right and forward" if sensors.gpIn[4].value=0 ; check for long move button press G1 X20 U20 A20 Y-20 V-20 B-20 else G1 X0.5 U0.5 A0.5 Y-0.5 V-0.5 B-0.5 elif sensors.gpIn[8].value=0; joystick right and backward M400 echo "Right and backwards" if sensors.gpIn[4].value=0 ; check for long move button press G1 X20 U20 A20 Y20 V20 B20 else G1 X0.5 U0.5 A0.5 Y0.5 V0.5 B0.5 else ; joystick right only M400 echo "Right" if sensors.gpIn[4].value=0 ; check for long move button press G1 X20 U20 A20 else G1 X0.5 U0.5 A0.5 elif sensors.gpIn[7].value=0 ; joystick forwards only M400 echo "Forward" if sensors.gpIn[4].value=0 ; check for long move button press G1 Y-20 V-20 B-20 else G1 Y-0.5 V-0.5 B-0.5 elif sensors.gpIn[8].value=0 ; joystick backward only M400 echo "Backwards" if sensors.gpIn[4].value=0 ; check for long move button press G1 Y20 V20 B20 else G1 Y0.5 V0.5 B0.5 else break else break
-
@deckingman I have followed this with interest but then I thought what was the actual problem? When I use the XY buttons in DWC my main XY and UV carriages move together and in sync. Have I not understood the problem?
-
@appjaws said in Yet more conditional gcode help required:
@deckingman I have followed this with interest but then I thought what was the actual problem? When I use the XY buttons in DWC my main XY and UV carriages move together and in sync. Have I not understood the problem?
Hiya. I've changed things around a bit so that I no longer combine the axes after homing. So the DWC buttons only work for individual axes. i.e. XY moves will only move the hot end - not the hot end and extruder gantry (as they used to do when the axes were combined)
The reason being that I've exploited the fact that, because the extruders are connected to the hot end via short Bowden tubes, that extruder gantry doesn't have to exactly follow the hot end gantry. It doesn't have to replicate every tiny move that the hot end does - it only has to follow it within an allowable tolerance. So if there are small features (say a hole or a cylinder) then I can "park" the extruder gantry in the centre of that feature and let it sit there while the hot end does all those short moves which make that feature. The same applies to other short zig-zag type moves where the extruder gantry sits still while the hot end does the short zig-zags.
I made a couple of YouTube videos which explain it in a bit more detail
https://www.youtube.com/watch?v=rOP9QYAlhZU
and
https://www.youtube.com/watch?v=mTPV3Ss1D-4So that's the reason why the axis button on DWC are no longer much use to me. A fuller explanation of what I wanted the joystick to do, and how that works in practice is here
https://www.youtube.com/watch?v=wCR5Ao0iH-c -
Hi again,
Very impressive videos @deckingman . Is it possible to have a copy of your python script that generates the movement please.
My machine really vibrates during short movements so your solution should solve it for me. -
@appjaws Sure. It's been a few years since we last communicated. Is your email address still the one ending ......ve.co.uk? If not, pm me with the address to use.
Be aware, that it's quite a lot of work to run the machine in "true" CoreXYUV mode. You need to change all you homing files so that they do not re-combine the axes, and change the "P" parameter in M581 so that the 5 axes are visible. Also any macros or gcode start and end scripts that have XY moves will need to be changed to incorporate XYUV moves.
Also be aware that, although the python code gets the job done, I'm not a writer of code, so it ain't pretty.
-
@deckingman Yes same email address.
I was wondering if I could just change the XYUV to be individual just during a print similar to the way homeall.g works.
M584 X0 U3 Y1 V4 Z7:8:9 E2:5:6 P5 ; temporarily separate and map drives to U and V axescomplete the modified gcode part file using separate XYUV axes
M584 X0:3 Y1:4 Z7:8:9 U10 V11 E2:5:6 P3 ; put motor mapping back to normal so that X uses drives 0 and 3 Y uses 1 and 4
then once the printed part is removed from the bed run homeall.g
can you see any problems with this?
Thanks for your help
-
@appjaws said in Yet more conditional gcode help required:
@deckingman Yes same email address.
I was wondering if I could just change the XYUV to be individual just during a print similar to the way homeall.g works.
M584 X0 U3 Y1 V4 Z7:8:9 E2:5:6 P5 ; temporarily separate and map drives to U and V axescomplete the modified gcode part file using separate XYUV axes
M584 X0:3 Y1:4 Z7:8:9 U10 V11 E2:5:6 P3 ; put motor mapping back to normal so that X uses drives 0 and 3 Y uses 1 and 4
then once the printed part is removed from the bed run homeall.g
can you see any problems with this?
Thanks for your help
I can't think of a reason why that wouldn't work. That is to say, it'll allow you to use the DWC buttons to jog all the axes in sync before and after a print, and also run any macros that aren't run during a print.
What I mean by that, is that I use macros to wipe and purge the nozzle, and these macros are called by the slicer gcode as part of the start and end scripts. As the axes are separated before the print starts, then these particular macros have to be modified. But of course, if you don't call any macros from the slicer gcode file that have G1 moves, then you won't need to worry about it.
-
@appjaws Email sent....
-
@deckingman This is my simplify3D start and end scripts
Starting script
M98 P"0:/macros/extra/Set LED Red"
if !move.axes[0].homed || !move.axes[1].homed
G28
G28 Z
;M98 P"0:/macros/Conditional/Auto_Bed_Levelling"
M98 P"0:/macros/Auto Nozzle Cleaning"
M98 P"0:/macros/Move to Print Position"
M98 P"0:/macros/extra/Set LED Blue"
M98 P"0:/macros/MapDrivesXYUV"
T0Ending script
M98 P"0:/macros/End of Print"
M98 P"0:/macros/CombineDrivest"
M291 P"Print Completed " ; Display messageThese are untouched by the the generator
Will be running the whole system later today, have sent you an email, requesting some advice.Paul
-
@appjaws Yup, the script only adds UV (and AB) moves to existing gcode files. It doesn't modify any macro which might be called by the slicer start or end codes. But it looks like you are keeping the axes mapped to XY to do the other stuff, then mapping them to XYUV just before the print starts - so that ought to work I would have thought (make sue that you use an M400 at the start of your "MapDrivesXYUV" macro to ensure any moves are completed first).
I've replied to your email.
Ian