script to drop temperature during ramming  

Ramming temperature different from print temperature

Any thoughts on the idea of being able to set a ramming temperature separately from the print temperature? It would be similar to the script for turning the heater off during ramming but with more control.

I've found a couple of cases where the temperature that's preferable for printing is not the same as the temperature that gives a good tip when ramming. It seems like this could be a useful feature.

Re: script to drop temperature during ramming

Yes, there has been discussion on this feature. KISS already has it, apparently. There is more to it than just "set ram temperature", however. They'll have to decide:

- when to change temperature (just before/after ramming? full purge?)
- whether to wait for the temperature to stabilize before ramming or set the new target and go

Re: script to drop temperature during ramming

(shifted from inland thread)

OK, that picked up all the temp changes. However, it cut off the end of the file

I uploaded it to the shared folder

Chris, can you explain your issue more? I don't see it cut off.

I did notice I'm matching on commented out 'temp change like strings' at the end of the file, I've fixed that.

Re: script to drop temperature during ramming

If you open 3C_Lizard_1_0.2mm_PLA_MK3MMU2_ramcool.gcode and go all the way to the bottom, the last line is:
G1 X91.156 Y98.320 E-0.10979

If you open 3C_Lizard_1_0.2mm_PLA_MK3MMU2.gcode and go all the way to that line, there are literally hundreds of lines after that

Re: script to drop temperature during ramming

If you open 3C_Lizard_1_0.2mm_PLA_MK3MMU2_ramcool.gcode and go all the way to the bottom, the last line is:
G1 X91.156 Y98.320 E-0.10979

If you open 3C_Lizard_1_0.2mm_PLA_MK3MMU2.gcode and go all the way to that line, there are literally hundreds of lines after that

Ok, I see the difference on your files. When I run with this command:

../mmu2_ram_cool/cool_ram.py -i 3C_Lizard_1_0.2mm_PLA_MK3MMU2.gcode -o temp2

my 'temp2' output file exactly matches yours, except mine doesn't cut off at the end. Did you get any error message when it ran? There is nothing special about where yours stopped that seems like it could have plausibly hit a bug in my script. Your previous 'unicode' error seemed to kill the script in the middle as well.

Either way, since I can't reproduce it I'm stumped for now. Try a different python version or a mac/linux box?

I plan to look at your suggestions for shifting the temp location this weekend. You are correct, I am working with filament with all the same temps, but I can see the timing of temp shift would be much more critical if that varied. I'll see what I can do.

Re: script to drop temperature during ramming

I keep getting that same error message every time

Re: script to drop temperature during ramming

I keep getting that same error message every time

Ok, some progress. https://stackoverflow.com/questions/36303919/python-3-0-open-default-encoding

Looks like python picks some local environment character encoding. I've modified the file open/close to force UTF8 encoding and committed it to github. Let me know if that helps or does nothing.

My guess: you made it to 99%, and it seems likely that no characters in the normal gcode would cause any issues (or it would have happened earlier). However, at 99%, you are very close to the end where Slic3r dumps all these settings/strings/stuff into comments. My guess is somewhere in that dump of your settings is a character that the default Windows encoding can't handle.

Try the latest version, see if it helps. If it doesn't, try deleting everything in the original gcode file after:

G1 Z47.4 ; Move print head up
G1 X0 Y200; home X axis
M84 ; disable motors
; filament used = 1700.1mm (4.1cm3)
; filament used = 5.1


Then run that through. That would at least narrow it down to the "end comments are messing with the text encoding".

Re: script to drop temperature during ramming

That did the trick. The error is gone and the gcode is complete. I will run it on the printer and see how it likes it. I really believe you are on the right path here.

Thank you so much for all your effort to make this work for me. I am very excited!

Re: script to drop temperature during ramming

I made a few changes to your script to better suite my situation of filaments that have different temps:

# if we are in idle state and we are at a line that set the temperature:
if (state == "idle") and (temp_set_match is not None):
# "group(1)" of the temp_set_match will contain the
# temperature being set as a string variable ("200" or whatever)
current_temp = temp_set_match.group(1)

# output a comment line indicating we grabbed this temperature (debugging only)
outfile.write(";matched temp! :" + current_temp + "\n")

This fixes the case where Slic3r has set the temp for the next filament when we want to be in a cooled state

This is what we used to get:
M104 S210
;matched temp! :210
G1 Y158.220
G1 X170.750 E10.0000 F452
G1 X207.090 E-10.0000 F377
G1 X170.750 E10.0000 F302
G1 X207.090 E-10.0000 F226
G1 E-50.0000 F2000
M73 Q5 S261
G1 Y158.300 F2400
G4 S0
M104 S210 ; restore temperature
T3

This is what we get now:
G1 E-2.0000 F360
;matched temp! :210
G1 Y158.220
G1 X170.750 E10.0000 F452
G1 X207.090 E-10.0000 F377
G1 X170.750 E10.0000 F302
G1 X207.090 E-10.0000 F226
G1 E-50.0000 F2000
M73 Q5 S261
G1 Y158.300 F2400
G4 S0
M104 S210 ; restore temperature
T3

In other words , we are once again in control of when the temp goes back up.

Let me know what you think.

Re: script to drop temperature during ramming

Thanks for the changes, and glad the other part helped. I should have time this afternoon to dig through, understand your improvements, and roll them in.

Re: script to drop temperature during ramming

Sounds good. I have more ideas about increased functionality, but they would add a lot of complexity to the script. For example, I have filaments that are already working perfectly without cooling during ramming. I would love to see this allow different settings for different filaments. Including whether or not you cool or wait for temp to stabilize or not. For example, when switching from a 200 degree filament to a 235 degree filament.

Re: script to drop temperature during ramming

Sounds good. I have more ideas about increased functionality, but they would add a lot of complexity to the script. For example, I have filaments that are already working perfectly without cooling during ramming. I would love to see this allow different settings for different filaments. Including whether or not you cool or wait for temp to stabilize or not. For example, when switching from a 200 degree filament to a 235 degree filament.

Pretty straightforward, but I would definitely need help testing, and it would be a longer term project.

I'm putting my mmu2 back together with my new filament control setup. Once I figure out it doesn't work and need to print a new piece I'll look at your first round of changes.

Re: script to drop temperature during ramming

What is your new setup like?

I hate the Prusa spool holders and filament brakes

Re: script to drop temperature during ramming

Plywood shelf over the mk3 (slightly too tall, need to cut it down 1/2 inch). Another shelf on top of that with inverted Rubbermaid 5L containers with individual spools in them.

Great idea, but doesn't currently work to my satisfaction. Two things to fix, one easy, one hard:

Easy: I need to start playing with my wallet geometry to get a good unload with stiff filament

Hard: I want it to be *really* easy to load/unload filament. The problem now is that all the loading/unload happens behind the MMU2 and is difficult to get to. I'm rethinking the whole thing and working out how to use guided PTFE tubes to bring the filament from the back of the MMU2, turn 180 degrees to be over the front where it is easy to load/unload filament from the MMU2.

My goal for loading a new filament:

I'm heading in the right direction, but I don't like how high the whole thing is getting, and my wallet-style thing is too small. Rethinking.

Re: script to drop temperature during ramming

Ok, I think I see the issue.

With a single temp filament, my script grabs each temperature change (which generally only happens at the start and between layer0/layer1), and remembers that as the "current_temp". When I get to a ";CP TOOLCHANGE START" comment, I insert a command to drop the temperature to the desired value (either M104 for 'no wait' or M109 if you want to wait for the temp to stabilize). [This is the start of the 'cooled' state]. I then wait for the end of the ramming indicated by the actual tool change (T0, T1, etc.). I increase the temperature back to the 'current_temp' just before the tool change, again with M104/M109. [This is the end of the 'cooled' state where I go back to 'idle']

In the multiple temperature mode, however, there is a temperature change in the middle of the cooled state. Not a problem, my script remembers it as current_temp, and at the tool change it sets that temp. However, the temperature change that happened during the 'cooled' state is also left in the file. It therefore starts heating up the head several moves before the tool change. You would like the script to actually keep that Slic3r inserted tool change temperature set out of the file, and only use the temperature set that is actually at the T[0-4] tool change.

I can do that, but I've got a few questions/concerns:

Why is Slic3r putting the temp change so far in front of the tool change? It uses M104, so it isn't waiting for temp to stabilize. They may have decided that the tool change time isn't enough time for the temperature change, so they shifted it forward a bit. If you are doing a big temp change (210 -> 235 or something), you may start pushing the new filament through before the temperature is high enough.

Do you think that should be M104 or M109? My leaning:
- Delete the M104 Slic3r added
- Use M104 (if -nw) or M109 just before the tool change
- Add optional M109 just *after* the tool change if the new filament requires a higher temperature

I'll go ahead and roll that in tonight, as the 'extra' m109 is optional and won't hurt anything if not used.

Re: script to drop temperature during ramming

If you look at the change I made to the script, the effect is what you are proposing. The Slic3r added temp change is eliminated because it occurs during cooled state. As far as the optional M109, what do you think about a command line delta option. User chooses a difference in temp between -t option and the Slic3r set temp for the filament. Anything change equal or greater gets an M109.

Not sure if that makes any sense

Re: script to drop temperature during ramming

Maybe an example will help:

You run the script with -nw -t190 -d25
1st filament has a printing temp of 200
2nd filament 215
3rd...235

1st: 200-190=10 so no optional M109
2nd: 215-190=25 so yes optional M109
3rd: 235-190=35 so yes optional M109

We could test and decide on a default -d based on what our printers do. I know mine cools off kinda slow and heats up quite fast. I think it might have something to do with the fact that I run a sock on mine.

FYI, I would be happy to help you test!

Re: script to drop temperature during ramming

Can a script be placed in the tool change g-code box in slic3r? say 198*C?

Re: script to drop temperature during ramming

Can a script be placed in the tool change g-code box in slic3r? say 198*C?

I don't think so, but I'm not sure. The script definitely can't be placed there (it's on python, not gcode). Even getting the same effect might be difficult, but you could try. My concern is that there is only one 'tool change' gcode box, and I'm not sure where it inserts the code. My script is doing three things that might be difficult in the tool-change gcode box:

- monitoring what the most recent nozzle temp is
- dropping the temperature at a certain spot when the head hits the wipe tower (pre-ram)
- raising the temp again near the tool change

I don't know how to do any of that with static gcode in the tool-change gcode box.

Re: script to drop temperature during ramming

Paul,

Thank you again for all your help. I got out 2 filaments that I had tried to print with before and had nothing but problems. Inland(cheap version) Blue and Inland Premium Plus Red. The red had been especially bad...very stringy. Well, guess what? They both printed beautifully and finished a 5 hour lizard without any help from me. WooHoo!!

* I said it before and I will say it again. Controlling ramming temp is key to getting many different filaments working with MMU2 *