Does firmware 1.19 handle extruder rate limiting any differently?

[burtoogle]

I've just started noticing a problem on my mini Kossel bowden extruder that's never happened before. At certain points in the print (quite repeatable) the extruder tries to extrude far too fast and just makes a ripping noise. I think I have tracked the locations down to where the slicer is producing very short lines (of the order of a couple of um long). I'm guessing that with such short lines, rounding errors could produce an overly large extruder rate. I would expect that the rate calculated for a line would be limited by the M203 E? value which is currently set at 1800 but I'm still getting the problem. Has the extruder rate calculation and its limiting been changed in RRF for the 1.19 release?

Obviously, stopping the slicer producing insanely short lines would be a good idea but I would hope that RRF would be immune to calls for silly extruder rates.

Thanks.

[burtoogle]

I just realised that the extruder rate limit is based on what the extruder can handle when it's retracting/priming, not what it can handle while extruding a line segment. So the problem must have been introduced by a recent change to the slicer.

[burtoogle]

Hello again. I am revisiting this because it's not yet clear why I am now seeing extruder skipping on very short extrudes when I did not before. As both the printer firmware has changed (1.18 to 1.19) and the slicer gets changed regularly, I can't definitely say where the problem lies. All I can say for sure is that a sequence like the following can cause extruder skipping but longer extrudes at the same x/y speed do not.

G0 F18000 X-1.408 Y9.871
G1 F2250 X-1.407 Y9.871 E0.00004

So, the original question of has anything changed in 1.19 that could cause the extruder rate to be too high when the travel distance is very small still needs answering.

Thanks

[dc42]

When you send that G1 command, do you definitely have relative extrusion selected (M83 command)?

[burtoogle]

It just struck me that on that printer, the extruder steps/mm is 643 so an extrusion of 0.00004 mm should not generate any steps at all. So why am I getting extruder skipping????

[burtoogle]

@dc42:

When you send that G1 command, do you definitely have relative extrusion selected (M83 command)?

Oh yes, it's set at the beginning of the print.

[dc42]

I agree, there should be no steps. That's why I thought you might be using absolute extrusion.

[burtoogle]

@dc42:

I agree, there should be no steps. That's why I thought you might be using absolute extrusion.

A very reasonable thought, but not the case here, it's definitely using relative extrusion. Also, pressure advance is not being used.

[dc42]

I've just tried those commands on one of my printers, and I get no extruder movement. I used a macro command containing this:

M302 P1
M83
G0 F18000 X-1.408 Y9.871
G1 F2250 X-1.407 Y9.871 E0.00004

Please can you upgrade to the latest 1.19.1 candidate (see separate thread) and test again. If it's still a problem, please can you connect via USB and Pronterface, send M111 S1 P4 and then M111 S1 P6. Then send that G1 E command (or both of those commands if it is easier) and post the output you get in the Pronterface console here. After that send M111 S0 to get back to normal.

[burtoogle]

OK, I did that and did not get any extruder steps.

Could you please try printing the following example. When I print this, I get extruder skipping during the infill on layers 12 and 13. It has been sliced for a kossel mini with a bowden extruder.

https://www.dropbox.com/s/06uw4yzmxgcpo2n/KM_capture-switch-housing.gcode?raw=1

[dc42]

I'm rather disturbed by all the M566 commands in that gcode file. Maximum jerk is normally a function of the mechanics of the printer and I would not expect a slicer to alter it. Changing jerk between commands won't work in RepRapFirmware, and I suspect it won't in most other firmwares either. This is because RRF (and all other 3D printing firmwares) maintain a queue of moves, and as new moves are added to the queue, the details of the previous moves in the queue may be changed. In particular, when a sequence of very short moves is added, the firmware has to assume that the printer may have to come to a stop after adding a move; but when another move is added, it knows that the previous move does not end in standstill; so it can increase the ending speed of the move and recalculate the move. The current jerk settings are applied when deciding how to match each move with the previous and next move.

I am wondering whether the changes to maximum jerk are part of the problem. The planner might sequence a few moves using one setting for maximum jerk, then if the jerk is reduced and another move is added, the sequence it has already scheduled might be illegal using the new jerk settings, which could cause problems when the existing moves are recalculated to account for the new one.

Please can you try running that file with the M566 commands stripped out - or at least the M566 commands just before the error occurs and up to 30 moves after it.

[burtoogle]

@dc42:

Please can you try running that file with the M566 commands stripped out - or at least the M566 commands just before the error occurs and up to 30 moves after it.

I did that, I removed all the M566s and it still behaves exactly the same. I observed the extruder gear when it skipped and it appeared to be doing a retraction type movement. [EDIT - err, there's a retraction immediately following the problem extrudes, that's probably what I observed].

BTW, I am a little sad to hear that it is not advisable to change the jerk "on the fly" as I have a particular print that has a quality issue that was solved by using a very low jerk setting while travelling. [EDIT - is there a case to have separate jerk values for travel only moves?]

[dc42]

Can you explain a little more about the quality issue you referred to? There may be something I can do in the firmware to resolve it without the need to change the jerk setting.

How certain are you that it's that particular G1 command in the file that is causing the problem?

Have you tried the latest test firmware at https://www.dropbox.com/sh/wq0u70kpapqc3is/AAC6I8TS5Lbwuziq_r3M15Qea?dl=0 yet?

[burtoogle]

Can you explain a little more about the quality issue you referred to? There may be something I can do in the firmware to resolve it without the need to change the jerk setting.

The quality issue was a very slight vertical banding along one side of a part that had flat sides and round ends. The z-seam was positioned near the middle of one of the ends to make it as hidden as possible. The vertical banding was visible on the flat side immediately downstream of the z-seam. The other flat side (upstream of the z-seam) showed no banding. The cause of the banding was the deceleration at the end of the move from whatever internal feature was printed before the outside wall. By reducing the travel jerk and travel acceleration, the deceleration was reduced and the banding was very much reduced.

Maybe I can get away with just reducing the travel acceleration and leave the jerk unchanged.

How certain are you that it's that particular G1 command in the file that is causing the problem?

Because if I hack the slicer to omit the short extrudes, the extruder no longer skips.

Have you tried the latest test firmware at https://www.dropbox.com/sh/wq0u70kpapqc … 15Qea?dl=0 yet?

Sorry, no, I haven't yet. I will give it a go.

[burtoogle]

Right, I have tried 1.19+4 and the behaviour is exactly the same, when mid way through the infill of layers 12 and 13 in the above gcode, the extruder skips (well, it makes a ripping sound for perhaps 1/3 second that it doesn't ever normally do).

[dc42]

Can you send me the file with the M566 commands removed that you tested?

It sounds to me that prohibiting jerk at the boundaries between printing and travel moves in the firmware might solve your quality issue.

[burtoogle]

I have copied the new file into dropbox with the same name as before.

Yes, if you could effectively set jerk to zero at the end of a sequence of travel moves that would help greatly. Maybe just ignore jerk completely for travel moves?

[dc42]

I just printed that file and I didn't observe a problem.

What steps/mm are you using? Please post your config.g file. As there is only 0.001mm of movement and 0.0004mm of extrusion, it's quite likely that the whole move will be discarded because there are no motor steps needed.

[burtoogle]

; Configuration file for Mini Kossel kit from Think3DPrint3D for testing Duet WiFi
 
; Communication and general
M111 S0                             	; Debug off
M550 PKossel Mini			; Machine name and Netbios name (can be anything you like)
M551 Preprap                        	; Machine password (used for FTP)
;*** If you have more than one Duet on your network, they must all have different MAC addresses, so change the last digits
M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0xED 	; MAC Address
;*** Wifi Networking
M552 S1					; Enable WiFi
 
M555 P2                           	; Set output to look like Marlin
M575 P1 B57600 S1			; Comms parameters for PanelDue
 
G21                                 	; Work in millimetres
G90                                	; Send absolute coordinates...
M83                                 	; ...but relative extruder moves
 
; Axis and motor configuration
M569 P0 S1				; Drive 0 goes forwards
M569 P1 S1				; Drive 1 goes forwards
M569 P2 S1				; Drive 2 goes forwards
M569 P3 S1				; Drive 3 goes forwards
M569 P4 S1				; Drive 4 goes forwards
M574 X2 Y2 Z2 P1			; set endstop configuration (all endstops at high end, active high)
;*** The homed height is deliberately set too high in the following - you will adjust it during calibration
M665 R104.077 L211.69 B85 H235.4	; set delta radius, diagonal rod length, printable radius and homed height
M666 X0 Y0 Z0				; put your endstop adjustments here, or let auto calibration find them
M350 X16 Y16 Z16 E16 I1			; Set 16x microstepping with interpolation
M92 X80 Y80 Z80				; Set axis steps/mm
M906 X1000 Y1000 Z1000 E1000		; Set motor currents (mA)
M201 X3000 Y3000 Z3000 E3000		; Accelerations (mm/s^2)
M203 X20000 Y20000 Z20000 E1800		; Maximum speeds (mm/min)
M566 X1200 Y1200 Z1200 E1200		; Maximum instant speed changes mm/minute
 
; Thermistors
M305 P0 T100000 B3950 R4700 H30 L0	; Put your own H and/or L values here to set the bed thermistor ADC correction
M305 P1 T100000 B3974 R4700 H30 L0	; Put your own H and/or L values here to set the first nozzle thermistor ADC correction
;M305 P2 T100000 B3974 R4700 H30 L0	; Put your own H and/or L values here to set the second nozzle thermistor ADC correction
M570 S180				; Hot end may be a little slow to heat up so allow it 180 seconds
 
; Fans
M106 P1 T45 H1                          ; thermostatically control hotend fan
 
; Tool definitions
M563 P0 D0 H1                       	; Define tool 0
G10 P0 S0 R0                        	; Set tool 0 operating and standby temperatures
;*** If you have a single-nozzle build, comment the next 2 lines
;M563 P1 D1 H2                      	; Define tool 1
;G10 P1 S0 R0                       	; Set tool 1 operating and standby temperatures
M92 E643	                       	; Set extruder steps per mm
 
; Z probe and compensation definition
;*** If you have a switch instead of an IR probe, change P1 to P4 in the following M558 command
;M558 P1 X0 Y0 Z0			; Z probe is an IR probe and is not used for homing any axes
M558 P0
;G31 X0 Y0 Z4.80 P500			; Set the zprobe height and threshold (put your own values here)
 
;*** If you are using axis compensation, put the figures in the following command
M556 S78 X0 Y0 Z0                   	; Axis compensation here
 
M208 S1 Z-0.2				; set minimum Z
;
T0					; select first hot end
 

[dc42]

You are using x16 microstepping, same as I was the first time I did the print. I tried again with x128 to make sure the G1 move didn't get discarded, but again it printed without a problem.

I have pressure advance enabled, so I'll try reverting to x16 and turning off pressure advance.