Stuttering while printing

DjDemonD

Large kossel, 1.20 alpha 7 fw
Stuttering whilst printing especially small curves.

 M122
=== Diagnostics ===
Used output buffers: 6 of 32 (10 max)
=== Platform ===
RepRapFirmware for Duet WiFi version 1.20alpha7 running on Duet WiFi 1.0
Board ID: 08DAM-999TL-MQ4S4-6J1FG-3S46M-TPHVY
Static ram used: 15104
Dynamic ram used: 97456
Recycled dynamic ram: 2128
Stack ram used: 1352 current, 9112 maximum
Never used ram: 7272
Last reset 00:40:01 ago, cause: power up
Last software reset reason: User, spinning module GCodes, available RAM 7264 bytes (slot 4)
Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 2
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 303.3ms
MCU temperature: min 19.0, current 38.7, max 39.2
Supply voltage: min 23.8, current 24.2, max 24.6, under voltage events: 0, over voltage events: 0
Driver 0: stalled
Driver 1: stalled
Driver 2: stalled
Driver 3: stalled
Driver 4: standstill
Date/time: 2017-09-30 10:29:54
Slowest main loop (seconds): 0.305532; fastest: 0.000035
=== Move ===
MaxReps: 8, StepErrors: 82, FreeDm: 180, MinFreeDm 120, MaxWait: 240725ms, Underruns: 0, 345
Scheduled moves: 6916, completed moves: 6901
Bed compensation in use: mesh
Bed probe heights: 0.079 0.063 0.010 0.042 -0.001
=== Heat ===
Bed heater = 0, chamber heater = -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.3
=== GCodes ===
Segments left: 1
Stack records: 2 allocated, 0 in use
Movement lock held by file
http is idle in state(s) 0
telnet is idle in state(s) 0
file is doing "G1 X-30.708 Y10.011 E0.29731" in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
Network state is running
WiFi module is connected to access point 
WiFi firmware version 1.20alpha1
WiFi MAC address 18:fe:34:ca:f8:7e
WiFi Vcc 3.11, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 38320
WiFi IP address 192.168.0.109
WiFi signal strength -36dBm
Reconnections 0
HTTP sessions: 2 of 8
Socket states: 4 2 0 0 0 0 0 0
Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
=== Filament sensors ===
Extruder 0 sensor: angle 0.0, no data received, no calibration data

It's not receiving from the filament monitor is this an interupt causing the processor to slow down searching for filament monitor signal?

dc42

There is a bug in the filament monitor support in RRF that causes stuttering if the filament monitor is flashing an error code instead of returning filament movement data. The fix will be in 1.20beta1.

DjDemonD

No problems will check my filament monitor wiring.

Thanks.

dc42

It may not be a problem in the wiring. Look at the red LED on the filament monitor and see whether it is flashing a regular pattern. The common one is 6 flashes, which means that the magnet was not detected.

DjDemonD

Yes that's it the assembly holding the magnet had slipped in the mount moving the magnet away from the pcb a little too far, and it wasn't reading. Spot on as always!

AS-3D Druck

I got the same Thing with my Printer and the Firmware 1.19.2 (2017-09-01).
I thought before my Slicer changed something but i'am happy to know that it is "just" the Firmware.

Is it recommended to update now to the 1.20 Beta Version?

dc42

Let me reiterate, this issue only occurs if you have a Duet3D filament monitor connected and configured and it is flashing an error code.

AS-3D Druck

@dc42:

Let me reiterate, this issue only occurs if you have a Duet3D filament monitor connected and configured and it is flashing an error code.

Oh ok, but I have this stuttering even without the monitor.

DjDemonD

Are you using grid levelling, if so you might see a slight stutter at a grid boundary, as grid levelling requires segmentation. If your bed is physically level try switching grid compensation off.

dc42

@DjDemonD:

Are you using grid levelling, if so you might see a slight stutter at a grid boundary, as grid levelling requires segmentation. If your bed is physically level try switching grid compensation off.

If that is the issue, the remedy is to increase the allowed Z jerk in the M566 command, if your printer can take it.

DjDemonD

Good to know, and makes sense, I see if occasionally on my corexy machine when I'm testing underbed sensors and have z jerk set to 0.