Cura Startup G-code for multi-tool FDM process

Danal

I have a similar situation. I have a Jubilee. It also has a z probe that would not work properly with any tool mounted. I.E. the tool carrier must be bare.

I wrote a macro to "prep the printer". That macro unmounts all tools (i.e. T-1), homes all axis, levels the bed, etc, etc. At the end of this macro, everything is ready and no tools are mounted.

Note that depending on the power-cycle status of the printer, and several other things, I may choose to manually unmount any tools, even before I run the prep macro. This is normally only needed at first power up of the day.

After the "prep the printer" macro, then I start the job (from whatever slicer). Of course, I could invoke that macro as the very first thing in the slicer G-Code. The main reason I don't depend on this is because I use several different slicers. Including Cura.

Anyway, this whole process adds up to no need for the G-Code to "remember" anything.

greenlee

@Danal
the "prep the printer" macro you described is basically what I'm doing now.
Unfortunately in Cura 4.4.0 the slicer added the call for the first tool head before inserting the Start G-code, so adding anything to Start G-code that uses the Z axis limit sensor is off the table unless you first unload the previously loaded tool.

Phaedrux

Could you use the start.g macro? It gets run at the start of every print before the sliced gcode gets executed.

Danal

Cura menu: Extensions -> Post Processing -> Modify G-Code
Use "Add a script" drop down to add "Search and Replace".
Search for ";FLAVOR:RepRap" (Look at a G-Code file you've created in the past and verify this is the very first line in the file).
Replace with whatever G-Code you wish, such as T-1, or a call to the prep macro, or whatever.

This will be the VERY FIRST line in the G-Code file; therefore, I believe it will defeat the issues you are having caused by commands that occur before the regular start g-codes.

greenlee

@Phaedrux start.g is a good idea but doesn't have an option to pull the heater temps out of the gcode. that I know of.
I

greenlee

@Danal looks like a good idea. Same issue with heating as start.g as far as i can tell.

TC

@Danal Hi Danal, how does your macro know which tool is connected after power up (I assume unmounting means to park it)?

Danal

@TC said in Cura Startup G-code for multi-tool FDM process:

@Danal Hi Danal, how does your macro know which tool is connected after power up (I assume unmounting means to park it)?

It doesn't. T-1 will unmount whatever tool is mounted. For example, if the prior print job left a tool mounted.

Additionally, there are circumstances where the printer itself does not 'know' which tool is mounted. The most common occurrence is a power down or full reset with a mounted tool. At the next restart, the printer will act as though no tool is mounted. This is a fundamental constraint that no amount of firmware, g-code, macro, etc. can get around.

The correct answer is to manually unmount the tool after a power up or restart. Note: I do not mean "manually issue the unmount command". I mean manually unlock the tool (on my printer, homing axis U will accomplish this), remove the tool from the carriage by hand and place the tool back on its parking posts by hand.

I don't know of any other feasible sequence of actions, after a power or reset.

dc42

@Danal said in Cura Startup G-code for multi-tool FDM process:

The correct answer is to manually unmount the tool after a power up or restart. Note: I do not mean "manually issue the unmount command". I mean manually unlock the tool (on my printer, homing axis U will accomplish this), remove the tool from the carriage by hand and place the tool back on its parking posts by hand.
I don't know of any other feasible sequence of actions, after a power or reset.

When we have conditional GCode in RRF3 (for which I did some more preparatory work over the weekend), it could be done automatically if each tool dock had a switch to sense when the tool is docked.

Danal

@dc42 said in Cura Startup G-code for multi-tool FDM process:

if each tool dock had a switch to sense when the tool is docked.

There has also been some discussion about a switch (or other) on the carriage. The E3D toolchanger architecture is very reliable*; however, it does on very rare occasion drop a tool. The carriage switch could be used to stop if a tool mount ends with a tool NOT mounted... and be used to modify startup, maybe full auto, maybe "stop and ask for help", if a tool IS mounted.

Lots of options if there are switches (sensors) on the carriage and/or the parking slots.

*I have only had a toolchange printer for a couple of months, and I'm already doing prints with 3 and 4 thousand toolchanges in that single print. After a solid commissioning the whole thing has proven itself very reliable.

dc42

Yes, a switch on the carriage and a switch on each dock wold be ideal. The carriage switch would confirm that a tool is loaded, and the dock switches would indicate which one it was.

I've been working with my tool changer yesterday and today. I've managed to get stall homing working on the coupler, and I am developing a set of configuration files for RRF3 on Duet 2. I'll also be moving the origin to the centre of the bed, which is what I use on all my 3D printers.