Does firmware 1.19 handle extruder rate limiting any differently?

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.

burtoogle

OK, thanks for trying. You only need print up to the 13th layer, it should misbehave by then.

dc42

I tried it without pressure advance - still no problem.

Can you isolate a short section of gcode that exhibits the issue when run by itself?

burtoogle

I think I may have something…

Here's some gcode from the region where the stepper is noisier that normal:

G0 F18000 X2.749 Y8.39
G1 F2250 X2.747 Y8.39 E0.00008
G1 F1800 E-5

And here's the debug output:

DDA: start=[6.274000 9.103000 2.650000] end=[2.749000 8.390000 2.650000] d=3.596386 vec=[-0.980151 -0.198254 0.000000 0.000000 0.000000]
a=1000.000000 reqv=300.000031 topv=61.352169 startv=8.162012 endv=16.394712
daccel=1.848735 ddecel=1.747651 cks=92013
DMX: dir=F steps=168 next=1 rev=169 interval=2111 sstcda=7651 acmadtcdts=21615 tstcdapdsc=107382 2dtstc2diva=6557935337
hmz0sK=7302429 minusAaPlusBbTimesKs=4366961 dSquaredMinusAsquaredMinusBsquared=53317988253696
2c2mmsdak=42915 asdsk=75724 dsdsk=75724 mmstcdts=195592
DMY: dir=B steps=112 next=1 rev=113 interval=3139 sstcda=7651 acmadtcdts=21615 tstcdapdsc=107382 2dtstc2diva=6557935337
hmz0sK=7556800 minusAaPlusBbTimesKs=-2870198 dSquaredMinusAsquaredMinusBsquared=57112973541376
2c2mmsdak=42915 asdsk=75724 dsdsk=75724 mmstcdts=195592
DMZ: dir=B steps=22 next=1 rev=23 interval=11934 sstcda=7651 acmadtcdts=21615 tstcdapdsc=107382 2dtstc2diva=6557935337
hmz0sK=7744420 minusAaPlusBbTimesKs=-519354 dSquaredMinusAsquaredMinusBsquared=59983966240768
2c2mmsdak=42915 asdsk=75724 dsdsk=75724 mmstcdts=195592
Transformed 3.05 3.05 2.65 to 14766 15005 15092
DDA: start=[2.749000 8.390000 2.650000] end=[2.747000 8.390000 2.650000] d=0.002000 vec=[-1.000000 0.000000 0.000000 -2499.883057 0.000000]
a=1.200056 reqv=0.500000 topv=0.049408 startv=0.006400 endv=0.006400
daccel=0.001000 ddecel=0.001000 cks=67196
DM0: dir=B steps=3215 next=1 rev=3216 interval=90 sstcda=5000 acmadtcdts=14623 tstcdapdsc=72196 2dtstc2diva=2954649380
accelStopStep=1608 decelStartStep=1608 2CsqtMmPerStepDivA=911254
mmPerStepTimesCdivtopSpeed=12087 fmsdmtstdca2=0

If i'm interpreting this correctly (a big assumption!) it looks like the small extrude and the following retract have somehow become combined because the DDA line shows a distance of 0.002 (rather than 5.000 which it shows for other retract/primes) and low velocities but then the DM0 line shows 5mm worth of steps. Is that right?

dc42

Looks like the first G1 command has been thrown away because it results in zero steps on all motors. Then the G1 E-5 line has been processed, but because there is some XY movement left over, the feed rate in that command has been applied to the XY movement instead of the E movement. This will cause the E speed to be the maximum you allow in the M203 command. If that is higher than the extruder drive is capable of, that could explain the behaviour you are seeing.

I will investigate this and implement a firmware fix if my diagnosis is correct, but there isn't time to do this before the 1.19.1 release. Your workaround is to set the E speed to an achievable value in M203, for example 1800.

Edit: according to your config.g it already is, so there must be something else going on.

burtoogle

OK, thanks. My workaround is currently not allowing the slicer to emit any extrudes less than 5um long. That appears to stop the problem occurring.

dc42

I'm going to try to put a fix in 1.18.1, if you will be able to run another test today. Which Duet do you have?

burtoogle

Sorry, I've only just seen the above question, I have a Wifi Duet. Please post the link to the test. Thanks.

dc42

See https://www.duet3d.com/forum/thread.php?pid=23326#p23326.