G4 being executed by both motion systems [3.5.4]
-
I am having some trouble with layer shifts in motion system 1 on layer 2 - which I think is relating to something happening in Motion System 0.
I introduced some delays in motion system 0 at various points so that I could try pin pointing exactly which command in motion system 0 is causing motion system 1's X&Y gantry to shift 10/5 mm's and cause the issue.
This resulted in some strange behaviour - where motion system 1 seemed to get stuck for a while.
I think I have figured out that all of the G4 delays I have put into motion system 0 are also being executed by motion system 1.
Some of the delays are in loops - but I assume the loop logic is probably being ignored and just the G4's are being picked up and executed - or maybe G4's in loops are being ignored.
When I reduce the length of the delays in motion system 0, then motion system 1 seemed to get delayed less.
I think I can work around this by using much smaller delays and putting them in loops - but it does help to explain a few strange delays.
Update: Putting delays into iterations didn't change the behaviour
So I have instead added an if statement to exit out of every macro that is likely to be called when multiple motion systems are active, plus in my general macro caller
if state.thisInput != null && inputs[state.thisInput].active == false M99 if exists(param.A) var P ="0:/macros/"^{param.A} if fileexists(var.P) M98 P{var.P} else var P2 =var.P^".g" if fileexists(var.P2) M98 P{var.P2} else echo "M98.1 Macro file not found",{var.P} else echo "M98.1 Macro Parameter A not found"
-
@dwuk3d thanks for your report. I'll change it so that only the active motion system executed G4 in the next 3.6 internal build and in 3.6.0 stable.
-
@dwuk3d this is fixed in the 3.6.0-rc.3+2 temporary firmware bulds at https://www.dropbox.com/scl/fo/xk6t4cibc602j0s3qmp48/AGouwT4mDySsLdBItGjDUcM?rlkey=k8j1rrfx18ixoyvizvs0hbehz&dl=0.
-
@dc42 Thanks will switch to that version