Pressure advance weird behaviour in 3.4
-
@oliof definetely not a mechanical problem. I changed the cables, I tested the extruder motion, Mnaually extruding from interface shows no problem. And As my description above, I can repeat the problem.
-
@ccs86 this the gcode wich I used to write the description above. This gcode start failing and as soon as I pause the print and resume, everything goes normal. I have uploaded only the first layer
[dualtest4.zip](Invalid file type. dualtest4.gcode
-
@tinchus I had a quick look at your gcode file. I see lots of retractions inserted by the slicer, what makes you think they are not there? The gcode file invokes: /macros/loaded_material and also seems to perform a tool change between T0 and T1 (and it looks like it switches back again). This means folks will need to see the macro file "loaded_material" and also your tpre0.g, tpost0.g, tfree0.g, tpre1.g, tpost1.g, tfree1.g so that they can check what exactly is happening at the start of the print. Also if you have a start.g file you should probably post that. You also mentioned that your retraction is only 1mm but the supplied gcode file has the following in it:
G1 E-0.9 F1500 G1 Z1.2 F18000 G1 E-5.1 F1500 G1 X97.434 Y110.037 F18000 G1 Z0.2 G1 E6.5 F1500 ; custom gcode: tcr_rotated_gcodeWhich looks like a total retraction of 6mm followed by a 6.5mm extrusion. This could easily cause a jam with many hot ends. Finally looking at the gcode it seems to contain a lot of very short extrusions, I wonder if this is correct (might be worth checking your settings or looking at other gcode files you have printed in the past) or could be contributing to the problem?
-
@gloomyandy I dont see th retraction you are talking about. The retractions I can see should be there since they are end of paths.
But the problem Im talking about can be seen right at the beginning, in the wipe tower the problem start. And if we look at the code:
; CP WIPE TOWER FIRST LAYER BRIM START
G1 X96.977 Y109.580 F7000
G1 Y135.908 E2.4068 F2100
G1 X127.805 E2.8182
G1 Y109.580 E2.4068
G1 X96.977 E2.8182
G1 X96.520 Y109.123 F7000
G1 Y136.365 E2.4904 F2100
G1 X128.262 E2.9018
G1 Y109.123 E2.4904
G1 X96.520 E2.9018
; CP WIPE TOWER FIRST LAYER BRIM ENDWe can see there the extrusion, they are all positive and in relative mode, and the re is no retraction at all there in the code. But I can visually see retractions when looking the print. So they have to come from firmware
-
That looks like a fairly high extrusion rate. Perhaps you're just seeing the extruder falter and click back?
I've never heard of Smart3dSlicer before. Have you tested with a different slicer yet to see if it's related to that?
-
@Tinchus There is a retraction both before and after that gcode, in particular that second retraction is very large -5.1mm...
G1 E-0.9 F1500 G1 Z1.2 F18000 G1 E-5.1 F1500 G1 X97.434 Y110.037 F18000 G1 Z0.2 G1 E6.5 F1500 ; custom gcode: tcr_rotated_gcode ;HEIGHT:0.200000 ;TYPE:Wipe tower ;WIDTH:0.500000 ;------------------------------------- ; CP WIPE TOWER FIRST LAYER BRIM START G1 X96.977 Y109.580 F7000 G1 Y135.908 E2.4068 F2100 G1 X127.805 E2.8182 G1 Y109.580 E2.4068 G1 X96.977 E2.8182 G1 X96.520 Y109.123 F7000 G1 Y136.365 E2.4904 F2100 G1 X128.262 E2.9018 G1 Y109.123 E2.4904 G1 X96.520 E2.9018 ; CP WIPE TOWER FIRST LAYER BRIM END ;----------------------------------- ; custom gcode end: tcr_rotated_gcode G1 E-0.9 F1500 G1 Z1.2 F18000 G1 X88.713 Y102.35 G1 Z0.2 G1 E0.9 F1500Are you saying you are seeing retractions during the printing of the wipe tower?
But anyway as I have said before you really need to provide all of the other gcode files that are involved in printing that file if you want folks to be able to understand exactly what is happening. At the moment we only have a part of the picture...
-
A video of the print in action can tell us a lot too.
-
@gloomyandy Sure. Here are the files:
loaded_material.g
tpre1.g tpre0.g tpost1.g tpost0.g tfree1.g tfree0.gRegarding the retractions: yes. I see extrusion and it looks like for every extrusion there is a retraction following it. So basically the filament is all the time going forward and barkward. And as I said: the same gcode, if I pause extrude, and then resume, continues the print with no problem
-
@Phaedrux I have new information and a "solution", but I think the problem is a bug, since this was not happening on 3.3.
As you saw, I have at the beginning of my config.g and M83 command (actually by error, Y have also another M83 near the end of it, so it is called twice)
That should be enough for stating that I want to use relative extrusion, since I have triple checked my slicer configuration (wich has not changed since I was using 3.3 firmware). My slice has the "use relative extrusion" option activated.
But there was a small change on my start gcode: My start gcode had at the very beginnign an M83 command. Recentrly I was cleaning the code, and since the config.g had M83 and the slicer was using the relative extrusion command, I decided to remove the M83 command.
I have edited the above gocode, I added an M83 at the begginig of it and the problem is solved!
So the thing to investigate would be: why the M83 in the config.g of the printer is not being used. I have checked againg all the other config files and there are not absolute extrusion commands that could override the M83 (Actually I have never used absolute extrusion in my life).
SO problem is solved, just adding an M83 at the beggining of the start gcode, but question remains: why the M83 in the config.g is not being used...
Thanks all for the help
-
Can you check whether a particular input is set to relative or absolute extrusion by looking in the 'inputs' section of the OM? This way we could see if it's getting set correctly at startup and how it changes or not when the print is started with or without your change to the start gcode.
-
@phaedrux What input are you interested in? I have from 0 to 11, and under name of each one of them none says "extruder"
