Yet more conditional gcode help required

deckingman

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

appjaws

@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?

deckingman

@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-4

So 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

appjaws

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.

deckingman

@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.

appjaws

@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 axes

complete 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

deckingman

@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 axes

complete 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.

deckingman

@appjaws Email sent....

appjaws

@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"
T0

Ending script
M98 P"0:/macros/End of Print"
M98 P"0:/macros/CombineDrivest"
M291 P"Print Completed " ; Display message

These are untouched by the the generator
Will be running the whole system later today, have sent you an email, requesting some advice.

Paul

deckingman

@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