Just a little bug report on the tool changing scripts: The video of running the toolchange_test.gcode inside the documentation, you see the bed dropping and returning once the tool has been picked up. The returning part however seems to have been omitted in one of the more recent builds of the firmware, so the bed just drops further and further with each tool change instead of returning to its desired point. Sure, easily fixed but I thought it might be nice if it did it correctly out of the box.
Firmware? The control is not driven by firmware. It's driven by GCODE. Welcome to the Duet. I just looked at this, and I think the problem is more with the test appearance, rather than an actual issue with a tool change. You can see the GCODE for the test here: https://github.com/e3donline/RepRapFirmware-SD/blob/master/gcodes/toolchange_test.gcode When changing Tools, other GCODE files control the tool change. So, when switching to T0, this happens first: https://github.com/e3donline/RepRapFirmware-SD/blob/master/sys/tpre0.g This is where you see the Z move downwards: https://github.com/e3donline/RepRapFirmware-SD/blob/master/sys/tpre0.g#L25 Once collection is complete, this happens next: https://github.com/e3donline/RepRapFirmware-SD/blob/master/sys/tpost0.g At some point in the future, we need to change tools so we need to free this tool before moving to the 'pre' for the next tool. So this happens: https://github.com/e3donline/RepRapFirmware-SD/blob/master/sys/tfree0.g Now you can see what's happening, you probably also realise that you can simply tweak these to do your bidding. There's no need to faff around compiling firmware. Now to the question of whether the existing macro's are right, you need to think about the most likely reason for a tool change. You're in the middle of a print, you want to change tools, so you lower the bed, dock, grab the next tool, prime the new tool, then move back to where you need to be. While moving back, you want the nozzle to be above the object being printed, so we don't want to lower the bed by default, post tool change. That said, I think there's room for improvement here. There's no use of stored positions that I can see here. The tool change is functioning like a pause. There's probably a GCODE way to save coords in R1, then when returning to the print location, move there fast to a point above the print, then move down and continue. Part of the challenge is adopting the mindset that the tool could be something completely different from the one that was dropped off.
I know, I was referring to the scripts included in E3D's github with the whole firmware for the Toolchanger: https://github.com/e3donline/RepRapFirmware-SD This is not my first Duet, I've been using it in my BigBox for quite some time. It is already fixed, I just wanted to point out a discrepancy between their scripts and what you'd expect from following the documentation. Here's the vid in question: https://e3d-online.dozuki.com/Guide/10+-+Commissioning./104?lang=en#s1071 All I am saying is that if you just put their image on the SD and run toolchange_test.gcode, it will drop the bed with each change, but not raise it again. The room for optimization that you mention will probably be realized with the next generation of RRF, David mentioned the use of variables and the like, so we will be able to script the hell out of this.
Sorry if I misunderstood. You mentioned firmware and, for me, that meant something quite different from GCODE. Firmware for me was the horror of compiling Marlin and flashing the RUMBA. Thank goodness I don't have to deal with that anymore. How you getting on anyway? Picture of build? First print?
Oh come on now, you’re overreacting. You could automate it with platform.io and have it compile and upload with a single click / shell command. And most of the parameters are in the EEPROM anyways. The true horror is all the bugs in Marlin, especially in TMC driver handling, bed leveling and IDEX code.
Yes, I just called it that because the scripts came bundled with the firmware, sorry for being unclear. You are absolutely correct, once you have experienced the comfort and capability of a Duet, there is no going back. I already have another Duet laying around that will replace the GRBL-based board in my little CNC router, can't wait to ban 8-bit motion electronics from the household for good. First print is currently running, of it is the bundled Benchy but with Colorfabb PLA/PHA instead of E3D PLA. So far, so good, a few imperfections that should be quite easy to iron out, but the Motion system is damn impressive. I think I'll have to play a bit with pressure advance and coasting to get the seams right, but that is just a matter of time. Here are a few pics of my build: https://www.dropbox.com/s/42bl9c4gedg74d4/20190822_131832.jpg?dl=0 https://www.dropbox.com/s/3flsr3tw4wnj11o/20190822_165856.jpg?dl=0 https://www.dropbox.com/s/cmhp3cbpppiifhe/20190822_174225.jpg?dl=0 https://www.dropbox.com/s/xaog5gmaih2y41h/20190824_161703.jpg?dl=0 Overall super happy with the thing, even if it will be a while until it is perfect. Back to the TC scripts: tpre0.g drops the bed by 10mm, tpost0.g does nothing with Z, tfree0.g drops the bed another 4mm. At no point does the bed raise up again, hence the continuous drop - and since all the scripts are on the board and not in the slicer, you can't compensate for that. What I did is have the Pre script drop it, post script raise it again, free script dropping and raising it properly. That way any kind of sequence should end up with Z being correct. It isn't the most elegant way but it gets it done. I am just saying that fix should be implemented in the scripts hosted on Github right from the start - I stumbled over it when trying the toolchange_test.gcode script and the bed kept dropping with each tool change. Have to go to an event tonight, but I'll have more testing time tomorrow (and on Monday unfortunately another multi-week business trip).
"Could". I never found out. The point where my pause script always resulted in a tiny movement of the head so that the next material didn't line up was where I parted ways, after trying to keep up with a few releases, and one which almost required rethinking everything.
There were some nasty issues with the Z axis getting incrementally more and more offset with each toolchange (oddly similar to the OP issue with the RRF scripts, but hardcoded in Marlin) and some downright bizarre edge cases where one X carriage would crash into the other even with the offsets set up correctly. Most of it has been fixed recently, thanks to the fact one of the more prominent contributors running an IDEX setup last x months. I think the only remaining issue is the Z axis discontinuity at mesh borders when using UBL (when the tool crosses the boundary of the mesh, it suddenly goes to offset 0 as if bed leveling was off, and jumps up or down, and when it comes back inside the mesh, it does the opposite - very jarring).
