Cura work-around

jens55

@jens55 I don't know where you are putting the placeholders, but surely they are meant to be used in the start gcode. Can you try this and see if it works? Where would the placeholders go? Why would they exist?

I tried it in my first post from today where I laid out the whole issue again.
The place holders are inside Cura for Cura's use and have a very narrow focus or scope.. If you set up a startg file for let's say tool1 and in that file you set G10 P{extruder_nr} S(material_print_temperature), the resulting gfile that is the print file will simply have the literal command in there ... like

G10 P{extruder_nr} S(material_print_temperature)

Ok, I am now confusing myself ..... I will have to do some tests .....

bot

I don't know what you are doing, but I just tested this and it all works as expected. Put these commands in the area shown here:

This results in the following G-Code in the file:

; Start
M82 ;absolute extrusion mode
; CUSTOM TOOL START

G10 P0 S200

T0
M83 ;relative extrusion mode
M83 ;relative extrusion mode
G1 F1500 E-6.5
;LAYER_COUNT:249
;LAYER:0

jens55

Well damn ... in my earlier tests I had some normal brackets slip into my code instead of the curly brackets.
If I insert the following into the start g code of extruder 0 in Cura
G10 P{extruder_nr} S{material_print_temperature}

it is evaluated into
G10 P0 S200

in the gcode file

So in theory, I could put the correct G10 command in every one of the Cura tool start.g files.
I would then have to delete (in post processing), all instances of T(n) commands that start just after a new line character.

This will require a bit more contemplation but might just work. I need to replace all of the instances as a standard tool change given as T(n) doesn't specify temperature so if you have a cold extruder it will not purge. Anyway, back to the problem at hand for more experiments ....

To be continued .....

bot

@jens55 I think you're overthinking things. Either that, or cura is not suitable for your printer.

With RRF, once you set the standby and active temperatures, they're set when the tool is selected or deselected. You only have to set G10 temps once, in the corresponding start gcode for the extruder, in cura.

And, with the curly bracket replacement strings, you can make every extruder's start gcode the same template.

Then, you have to search and replace only that one single errant Tn command at the beginning of the file. All subsequent Tn commands would be desirable, and should work as is.

jens55

@bot, I think I have it worked out thanks to you. I have not actually run the resulting code in Cura, that will be a job for tomorrow (it's nearing 1am here)

My Cura startg code:

;Cura start gcode
T-1
G10 P{initial_extruder_nr} S{material_print_temperature}
M190 S{material_bed_temperature} ;Start heating bed and wait to bed reach temp before proceeding
M116 ; wait for temperatures to reach set values
T{initial_extruder_nr}

My Cura tool start g code for every tool:

G10 P{extruder_nr} S{material_print_temperature}

My search and replace post processing code:

search string: \nT[0-9]\n
replace string :
(replace string is empty)

This will delete all T commands that are on a line by itself and not affect any T commands that are part of another command. "\n" is a new line character

Also, I would think that it is best to delete all T commands since every instance of T had an instance of G10 added so the T's are no longer needed (and cause problems in the tool changer script I think)

I will post an update tomorrow .... but in theory this meets all my needs - there is no user interaction needed no matter the filament and the purging while the tool is parked should work as well.

I am VERY excited to try this out tomorrow !!!! Thanks !

jens55

Couldn't wait .... but ran into another snag.
I had assumed that a G10 command would set and select the tool which turns out to be false - it only sets the tool parameters and a T command is still required.
This is throwing a wrench in my plan but I should be able to work around this somehow.
The issue now is that the T command comes first, that tells Cura to insert the tool startg which then inserts the G10 for the tool parameters. Unfortunately the same T command that causes G10 to be inserted also initiates all the tool change macros. I end up with a T command followed by the G10 command and when the tool change macros are run, there is the potential for no temperatures being set for the tool.
I don't know yet if there is a way to put a T command into the Cura start g code section and then, in post processing, remove the initial T command that is later replaced by the T command from the Cura tool startg. This would replace the T command with G10 followed by T and would make sure that the tool is heated when called (yes, there needs to be an M116 in there someplace)

My brain is fried for today ....

sebkritikel

@jens55 keep playing with the START section in Cura (as seen in the image bot posted). In those sections you could insert

T{initial_extruder_nr} P0

To select a tool without running a macro. The {initial_extruder_nr} will be replaced during slicing by Cura.

I don’t think it’s the entire solution, but could help you on your path. Some other info here: https://files.fieldofview.com/cura/Replacement_Patterns.html

jens55

@sebkritikel, I am making progress I have the main problem sorted and I am printing my first full multi colour model. I have a lot more of the various Cura settings to work out but it's getting there.
I will post the updated gcode stuff later today.

bot

@jens55 I do not think the search string will work like that.

In my experiments, cura does not accept \n as a newline character. You must copy and paste a newline character for it to work. Also, you MUST include the first line ";Generated by SteamEngine" or else it will indeed search and replace every Tn command that is on its own line (based on the way you wrote it now).

You must do like this:

bot

@jens55 I think you may be assuming that the "Extruder Start G-code" is what is used every time the tool is called. This is not the case. It is only called once at the beginning of the print file, just like normal start g-code, but it is specific to the extruder specified. So, if the extruder is not used, the code won't be in the file. If it is, it will be at the start.

This is my assumption but I'm fairly confident that's how it is.

I'm just trying to clear up all this confusion, because this should be pretty straight forward once we remove that first errant Tn command.

jens55

I have what appears to be a working solution. It does need to be tweaked still but the overall concept works. The user does not need to worry about anything special to modify the g code, the purge works properly with the tool warmed up and there is only a single un-neccessary tool move due to Cura's insistence of sending a T command as the very first line of code even before it sends out the Cura start.g code block.

Details as follows:

Duet start.g:
; This file is called before any print job file is started
T-1
if !move.axes[0].homed || !move.axes[1].homed|| !move.axes[2].homed ; If the printer hasn't been homed, home it
G28 ; home the printer before Cura has a chance to mess it up with loading a tool

Duet tpost0.g:
; tpost0.g
; called after firmware thinks Tool 0 is selected
; Note: tool offsets are applied at this point!
; Note that commands preempted with G53 will NOT apply the tool offset.

M116 P0 ; Wait for set temperatures to be reached
M302 P0 ; Prevent Cold Extrudes, just in case temp setpoints are at 0
G91 ; use relative extrusion
G1 E50 F300 ; purge
G4 T10 ; wait
G90 ; Ensure the machine is in absolute mode before issuing movements.

G53 G1 X-3 Y339 F6000 ; Move to the pickup position with tool-0.
M98 P"/macros/tool_lock.g" ; Lock the tool

G1 R2 Z0 ; Restore prior Z position before tool change was initiated.
; Note: tool tip position is automatically saved to slot 2 upon the start of a tool change.
; Restore Z first so we don't crash the tool on retraction.
G1 R0 Y0 ; Retract tool by restoring Y position next now accounting for new tool offset.
; Restoring Y next ensures the tool is fully removed from parking post.
G1 R0 X0 ; Restore X position now accounting for new tool offset.
M106 R2 ; restore print cooling fan speed

Note that there are several tool changer commands in there that are specific to my setup. All tpost(n).g files are basically the same with only the tool changing and the tool position changing.

Cura post processing, search and replace search string:
T[0-9]\n
Regular expression check box checked
Note: this only works for tools T0 thru T9. If more tools are defined then you need to change this.

Cura startg:
G10 P{initial_extruder_nr} S{material_print_temperature} R{material_print_temperature}
T-1
M190 S{material_bed_temperature} ;Start heating bed and wait to bed reach temp before proceeding
G1 Z15.0 F6000 ;Move the platform down 15mm

Note: the T-1 deselects the initial tool that Cura insists on selecting

Cura tool start.g, same for all tools:
G10 P{extruder_nr} S{material_print_temperature} R{material_print_temperature}
T{extruder_nr};

Note: the ";" at the end of the last line is critical!
What is happening is that all instances of T(n) (only those on their own line, not those as part of another command) are located and a G10 plus a T(n); command is added. Later on, in the post processing search and replace, the original T(n) command is deleted. The T(n); command only remains because of the semicolon so if that is missing no tools will ever get selected.

I think that covers all points.
I hope somebody can make use of this ... it certainly caused me lots of grief to sort this out.

jens55

@bot said in Cura work-around:

@jens55 I think you may be assuming that the "Extruder Start G-code" is what is used every time the tool is called. This is not the case. It is only called once at the beginning of the print file, just like normal start g-code, but it is specific to the extruder specified. So, if the extruder is not used, the code won't be in the file. If it is, it will be at the start.

Cura has a normal start.g block that is called whenever Cura runs. It also has the extruder start.g blocks and they seem to be called every time that particular exruder is called for.

This is my assumption but I'm fairly confident that's how it is.

NOt according to what I am seeing ... but then I have been wrong once or twice before

I'm just trying to clear up all this confusion, because this should be pretty straight forward once we remove that first errant Tn command.

The first errant command is removed in the Cura start.g block with the T-1 which deselects and unmounts the tool that was mounted in the errant T command that Cura insists on.

gain, I would like to thank you for all your help. I would have never got this working by myself! THANKS !

bot

@jens55 Wow, I just checked and you're right. The extruder start gcode is called every time the tool is selected.

I understand now your desire to remove every Tn command, and proceed the way you have.

Sorry for adding some confusion, but I'm glad you've got it sorted. I think you'll be able to make a hands-off profile now!

Wow, cure really is messed up, too. For T0, the Tn command preceeds the extruder start gcode, but for T1, the Tn command proceeds it! WTF!

Cura needs to sort themselves out lol.

Hmm. I just checked the behaviour, and it appears that it is very particular. For your own tool selection commands, ensure you have a comment after it. Then, for the search and replace command, ensure you have the two invisible newline characters both before and after the search string. So confusing, but it's possible to get a working configuration.

jens55

Upate: in the tpost file the following section

G91 ; use relative extrusion
G1 E50 F300 ; purge

should be changed to :

M83 ; use relative extrusion
G0 E10 F300 ; purge

jens55

Another few changes:

Cura post processing, search and replace search string:
T[0-9]\n
Regular expression check box checked
Note: this only works for tools T0 thru T9. If more tools are defined then you need to change this.

Edit : The replacement string box should be empty

I suspect that the T-1 commands are no longer needed but have not tested that