Many layer shifts since v2.xx (?)



  • Hi there,

    I'm using duet wifi since 1 year and I really like it.
    I have a printer originally based on a Anet A8, but completly redone with v-rails and so on...

    In the last year I was printing with the same settings like now for months and had never problems with layer shifts. In the sommer months I stopped printing due to high temperatures in my room and I started printing again 2 weeks ago.

    After some prints without problems ( I was looking to new versions and updated from v1.20 to v2.02RC2.:
    Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
    Firmware Electronics: Duet WiFi 1.02 or later
    Firmware Version: 2.02RC2(RTOS) (2018-09-07b2)
    WiFi Server Version: 1.21
    Web Interface Version: 1.22.3

    Since then I really struggle with layer shifts... Sometimes I have many layer shifts (about 0.3-0.5mm per shift) in one print. I printed one part 4 times with the same G-code. 3 times it had layer shifts at the same position, 1 time it was OK.
    The shifts are on my y-axis (heatpad) and seem to be always in the same direction.
    I already reduces jerk (half of the value before) and reduced acceleration a bit (still at 4000mm/min), but it did not help.

    Here my current movement settings.
    M906 X1000 Y1000 Z1000 E1100 ; Set motor currents (mA)
    M201 X4000 Y4000 Z100 E6000 ; Accelerations (mm/s^2)
    M203 X15000 Y15000 Z1000 E10000 ; Maximum speeds (mm/min)
    M566 X350 Y250 Z60 E600 ; Maximum jerk speeds mm/minute

    I can imagine, that my acceleration is to much to move my heatbed, but it worked well for months before summer with version v1.20 and below.
    I also did not hear, that there were missed steps when the shifts happened.

    Do I miss something? Do you have some idea?

    Thank you very much,
    apo

    M122 after a print with at least 3 layer shifts:
    === Diagnostics ===
    RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02RC2(RTOS) running on Duet WiFi 1.02 or later
    Board ID: 08DDM-9FAM2-LW4SD-6JKFD-3S86N-9MWVX
    Used output buffers: 3 of 20 (10 max)
    === RTOS ===
    Static ram: 28460
    Dynamic ram: 98312 of which 0 recycled
    Exception stack ram used: 460
    Never used ram: 3840
    Tasks: NETWORK(ready,328) HEAT(blocked,1232) MAIN(running,3484)
    Owned mutexes:
    === Platform ===
    Last reset 03:24:21 ago, cause: power up
    Last software reset at 2018-10-10 23:56, reason: User, spinning module GCodes, available RAM 3888 bytes (slot 3)
    Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
    Error status: 0
    Free file entries: 10
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 82.4ms, max retries 0
    MCU temperature: min 25.9, current 31.3, max 34.6
    Supply voltage: min 23.7, current 24.4, max 24.7, under voltage events: 0, over voltage events: 0
    Driver 0: standstill, SG min/max 0/1023
    Driver 1: standstill, SG min/max 0/1023
    Driver 2: standstill, SG min/max 12/159
    Driver 3: standstill, SG min/max 0/152
    Driver 4: standstill, SG min/max 0/1023
    Date/time: 2018-10-12 01:14:04
    Slowest loop: 207.99ms; fastest: 0.06ms
    === Move ===
    Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 126, MaxWait: 829011ms, Underruns: 0, 0
    Scheduled moves: 0, completed moves: 0
    Bed compensation in use: mesh
    Bed probe heights: 0.000 0.000 0.000 0.000 0.000
    === Heat ===
    Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
    Heater 0 is on, I-accum = 0.3
    Heater 1 is on, I-accum = 0.6
    === GCodes ===
    Segments left: 0
    Stack records: 2 allocated, 0 in use
    Movement lock held by null
    http is idle in state(s) 0
    telnet is idle in state(s) 0
    file is idle 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 ===
    Slowest loop: 209.62ms; fastest: 0.01ms
    Responder states: HTTP(0) HTTP(2) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
    HTTP sessions: 1 of 8

    • WiFi -
      Network state is running
      WiFi module is connected to access point
      Failed messages: pending 0, notready 0, noresp 0
      WiFi firmware version 1.21
      WiFi MAC address 5c:cf:7f:ee:64:e7
      WiFi Vcc 3.39, reset reason Turned on by main processor
      WiFi flash size 4194304, free heap 13064
      WiFi IP address 192.168.100.95
      WiFi signal strength -64dBm, reconnections 0, sleep mode modem
      Socket states: 4 4 0 0 0 0 0 0
      === Expansion ===


  • Check that the bed moves smoothly when the belt is disconnected. Perhaps something has shifted mechanically and it's binding slightly.

    Are you running on v wheels? Perhaps a wheel bearing is failing. Of its a linear bearing perhaps you need to clean and lube it?

    Can you verify what motor current you're running? Is it possible it's been reduced along the way? Send M906 during the print to see what the actual current is. Then send m913 to see if it's being reduced by a percentage.

    4000 is a bit high for acceleration on a Cartesian Y axis.



  • Hi and thanks for your answer.
    Yes I'm running on v wheels.
    The Y-axis is a C-Beam linaer rail (https://openbuildspartstore.com/c-beam-linear-rail/) with this plate: https://openbuildspartstore.com/c-beam-gantry-plate-xlarge/.

    With disconnected belt it starts moving when I tilt the printer only a little bit and I can move it easily very fast.

    17:48:29 M913
    Motor current % of normal - X:100, Y:100, Z:100, E:100
    17:48:20 M906
    Motor current (mA) - X:1000, Y:1000, Z:1000, E:1100, idle factor 30%

    I today watched the printer a little bit more and the printer went loud sometimes when doing fast direction changes (resonace vibrations?), but did not have layer shifts. But I think that could cause layer shifts?
    But I'm really sure it did not happen when I watched the print yesterday. It wasn't louder than normal and I couldn't see something special. And suddently there was a layer shift.

    For the beginning, I will reduce acceleration and observe the problem.


  • administrators

    I can't think of any changes made to the Duet WiFi firmware that would introduce layer shifts that were not happening before; and I don't think anyone else has reported anything similar. So I suspect it is coincidence that the problem started after you updated the firmware, or perhaps you changed something else at the same time.


 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.