3.5.0b1+ don't wait for commands to finish before moving on
-
Anyone else with 3.5.0b1+ thats willing to try recreating this issue?
Shouldn't be anything super exotic that needs to be changed to try this out on other machines
😅
I've looked to the code so many times now I'm sure I wouldn't find a fault if it jumped at me lol
-
@Exerqtor what's happening is that there are now two GCode File channels used to process print files, one for each motion system. Normally, only the first one of them executes commands. The other typically reaches end of file or the M0 command if there is one, and waits for the first to catch up.
What I hadn't allowed for is that both File channels will execute GCode meta commands such as echo, and set. This is why you are seeing some echo commands being executed ahead of time, and why global.bed_trammed is being set to true.
I propose to change the behaviour as follows, which I hope will resolve this for you:
- Only execute echo, global and set global commands commands from the File channel that is currently selected.
When either channel reaches a command that involves waiting for temperatures to be reached, add a sync point there so that both File channels wait. no, that would not be appropriate e.g. when changing tools and waiting for a hot end to heat.
-
@dc42
Uuuhm oook, how do i know what file channel is in use? Sounds easier/less issue proned (for me) to just don't usestart.g
and scrap it to be honest. -
@Exerqtor my aim is that you won't need to modify start.g; but if you do, the modification needed should be simple.
-
@dc42
Ah I missunderstood what you meant! Do what you feel is the best way of solving/moving around it, I haven't got a good enough understanding of how it all ties together to weigh in on it -
-
@Exerqtor can you confirm if the issue with start.g other than the one with M190 you reported here: https://forum.duet3d.com/post/308884 are resolved?
-
@T3P3Tony
I've ditched using start.g totally because it made more problems for me than it solved.If my recollection serves me right though, i'm pretty sure the changes David did in b2 solved this perticular issue.
I'll remove this thread as a question so it won't remain as "unsolved" at least.
-
-