• Tags
  • Documentation
  • Order
  • Register
  • Login
Duet3D Logo Duet3D
  • Tags
  • Documentation
  • Order
  • Register
  • Login

[SOLVED] Lookahead error (and possibly related layer shifting)

Scheduled Pinned Locked Moved
General Discussion
2
4
805
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • undefined
    iratecrayons
    last edited by iratecrayons 10 Nov 2018, 16:38

    I'm trying to investigate a layer shifting problem that happens only after printing for many hours. In doing this, I've noticed a few consistently reported Look Ahead errors in my log.

    I cannot say for certain that these are related, since I receive 2 LaErrors several hours apart, but only 1 layer shift and was not on hand to witness that the error and shift happened at the same time.

    None the less, the details follow

    === Diagnostics ===
    RepRapFirmware for Duet 2 Maestro version 2.02RC3(RTOS) running on Duet Maestro 1.0
    Board ID: 08DGM-95762-FD3TD-6JTDD-3SW6S-18AZH
    Used output buffers: 3 of 20 (16 max)
    === RTOS ===
    Static ram: 22524
    Dynamic ram: 95528 of which 0 recycled
    Exception stack ram used: 408
    Never used ram: 12612
    Tasks: NETWORK(ready,456) HEAT(blocked,1300) MAIN(running,3632)
    Owned mutexes:
    === Platform ===
    Last reset 16:10:15 ago, cause: software
    Last software reset at 2018-11-09 19:20, reason: User, spinning module GCodes, available RAM 12600 bytes (slot 3)
    Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x04418000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
    Error status: 0
    Free file entries: 10
    SD card 0 detected, interface speed: 15.0MBytes/sec
    SD card longest block write time: 5.0ms, max retries 0
    MCU temperature: min 35.7, current 36.0, max 36.8
    Supply voltage: min 22.6, current 22.9, max 23.1, under voltage events: 0, over voltage events: 0
    Driver 0: standstill, read errors 0, write errors 0, ifcount 54, reads 2535, timeouts 0
    Driver 1: standstill, read errors 0, write errors 0, ifcount 54, reads 2535, timeouts 0
    Driver 2: standstill, read errors 0, write errors 0, ifcount 54, reads 2535, timeouts 0
    Driver 3: standstill, read errors 0, write errors 0, ifcount 40, reads 2526, timeouts 9
    Driver 4: standstill, read errors 0, write errors 0, ifcount 54, reads 2534, timeouts 1
    Driver 5: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 2536
    Driver 6: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 2536
    Date/time: 1970-01-01 00:00:00
    Slowest loop: 4581229.00ms; fastest: 0.12ms
    === Move ===
    Hiccups: 0, StepErrors: 0, LaErrors: 2, FreeDm: 240, MinFreeDm: 150, MaxWait: 0ms, 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, chamberHeaters = -1 -1
    Heater 0 is on, I-accum = 0.0
    Heater 1 is on, I-accum = 0.4
    === 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
    lcd is idle in state(s) 0
    autopause is idle in state(s) 0
    Code queue is empty.
    === Network ===
    Slowest loop: 4581229.00ms; fastest: 0.03ms
    Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
    HTTP sessions: 1 of 8
    Interface state 5, link 10Mbps full duplex
    === Filament sensors ===
    Extruder 0 sensor: ok

    And the info from the serial port:

    (First error)
    DDA.cpp(971) tn=63.789 DDA: start=[145.475998 106.597000 139.229996] end=[123.108002 118.694000 139.229996] s=25.429602 vec=[-0.879605 0.475705 0.000000 0.000000 0.000000]
    a=590.270813 d=590.270813 reqv=100.837936 startv=16.817129 topv=100.837936 endv=63.788532 sa=8.373676 sd=5.166537
    cks=302827 sstcda=1147363319 tstcddpdsc=85807 exac=7694

    (Second error)
    DDA.cpp(971) tn=28.953 DDA: start=[210.080994 92.476997 229.830002] end=[210.432007 92.358002 229.830002] s=0.370635 vec=[0.947059 -0.321059 0.000000 0.032903 0.000000]
    a=630.855957 d=630.855957 reqv=60.000004 startv=20.305973 topv=29.310781 endv=28.953011 sa=0.354114 sd=0.016521
    cks=13913 sstcda=1146301974 tstcddpdsc=71917 exac=22
    DDA.cpp(971) tn=7.454 DDA: start=[139.722000 165.498993 246.629990] end=[138.919006 165.173004 246.629990] s=0.866642 vec=[-0.926558 -0.376152 0.000000 0.033772 0.000000]
    a=614.104492 d=614.104492 reqv=60.000004 startv=27.890314 topv=30.804615 endv=7.454000 sa=0.139272 sd=0.727370
    cks=40096 sstcda=1146608198 tstcddpdsc=63662 exac=0

    Should I be concerned about these errors?

    undefined 1 Reply Last reply 12 Nov 2018, 11:04 Reply Quote 0
    • undefined
      dc42 administrators @iratecrayons
      last edited by 12 Nov 2018, 11:04

      Thanks for reporting these errors - they are on my list to look at later today.

      Duet WiFi hardware designer and firmware engineer
      Please do not ask me for Duet support via PM or email, use the forum
      http://www.escher3d.com, https://miscsolutions.wordpress.com

      1 Reply Last reply Reply Quote 0
      • undefined
        dc42 administrators
        last edited by 13 Nov 2018, 11:56

        I've looked at those errors. There are three of them, and they are all caused by small rounding errors. I think it is unlikely that they are causing the layer shifts; however there is a small possibility that they are, so in the forthcoming 2.02RC4 release I have changed the code to avoid that possibility.

        Duet WiFi hardware designer and firmware engineer
        Please do not ask me for Duet support via PM or email, use the forum
        http://www.escher3d.com, https://miscsolutions.wordpress.com

        undefined 1 Reply Last reply 14 Nov 2018, 22:42 Reply Quote 1
        • undefined
          iratecrayons @dc42
          last edited by 14 Nov 2018, 22:42

          @dc42 Thanks for taking a look so quickly.

          Since the shifts only happen after 12-24 hours it's been a bit slow to confirm, but in the end it looks like it was caused by a bad cable that otherwise passed a visual inspection of the crimps.

          I hope the bug report has helped in other ways at least.

          1 Reply Last reply Reply Quote 1
          3 out of 4
          • First post
            3/4
            Last post
          Unless otherwise noted, all forum content is licensed under CC-BY-SA