› ›

Unknown Firmware / Waiting For Temperature Error - SKR Mini E3 V3 (Marlin)

jhunter84jhunter84
in Bug Reports
Good morning all. I recently updated my old RigidBot board with the SKR Mini E3 V3 and got everything working great but having connection issues in Repetier which is my absolute favorite host. Here is what is going on
  • Printer connects fine but every time has 5 commands waiting and the bottom status bar shows "unknown firmware...waiting for temperature".
  • I can Fake OK to clear the commands and start to communicate and control the printer but it always goes back to "1 command waiting"
  • The commands that are always waiting on startup that I Fake OK to clear are listed at the bottom here.
  • I am running Latest Stable Marlin 2.1.2.2
  • I don't have any problems connecting / controlling / printing in Pronterface or Cura - both are working perfectly including all temp sensors.

8:59:27 AM: Attempting to connect to printer
  8:59:27 AM: Connection opened
> 8:59:33 AM: N31 M110 *49
< 8:59:33 AM: ok
> 8:59:33 AM: N32 M115 *55
< 8:59:33 AM: ok
< 8:59:34 AM: ok
> 8:59:35 AM: N34 M111 S6 *112
< 8:59:35 AM: ok
> 8:59:35 AM: N35 M111 S7 *112
   9:00:23 AM: Communication timeout - reset send buffer block
              

Comments

  • RepetierRepetier
    Can you activate ping pong mode for communication. That way you know exactly which command is causing the trouble. Also disable temperature filter. Line 33 was M105 I guess.

    When you compile your self enable line numbers in marlin (configure_adv.h) so missing ok are automatically detected.
  • jhunter84jhunter84
    I had ping pong on when I pulled that log above, but I've tried with and without. 

    For the disabling temperature filter, do you mean setting the thermistor to 998 or 999? I tried that as well and it didn't work.

    Also sorry but what settings in the configuration_adv.h enables line numbers? I don't see it in there.
  • RepetierRepetier
    No, I meant in log is a filter to hide them (or in printer settings).

    If that is with ping pong the first M111 succeeded while second one not. M111 is just changing debug options so nothing complicated or time consuming. Makes not much sense that it would block. Which os are you using? Might there be some other software accessing the port. Would only be on linux - windows allows only one program to open connection.
  • jhunter84jhunter84
    OK - I am using MacOS Monterey. I fixed the filtering and it is the M105 that always comes back after I Fake OK for all commands waiting.

      10:37:04 AM: Connection opened
    > 10:38:10 AM: N134 M110 *5
    < 10:38:10 AM: ok
    > 10:38:11 AM: N135 M115 *1
    < 10:38:11 AM: ok
    > 10:38:11 AM: N136 M105 *3
    < 10:38:11 AM: ok
    > 10:38:12 AM: N137 M111 S6 *66
    < 10:38:12 AM: ok
    > 10:38:12 AM: N138 M111 S7 *76
    < 10:38:12 AM: ok
    > 10:38:12 AM: N139 M155 S1 *75
    < 10:38:12 AM: ok
    > 10:38:12 AM: N140 M105 *2
    < 10:38:12 AM: ok
    < 10:38:12 AM: ok
    > 10:38:12 AM: N141 M105 *3
    > 10:38:17 AM: N142 M105 *0
    < 10:38:17 AM: ok
    < 10:38:17 AM: ok
    > 10:38:18 AM: N143 M105 *1
    > 10:38:19 AM: N144 M105 *6
    < 10:38:19 AM: ok
      10:38:22 AM: Connection closed

  • RepetierRepetier
    The log is complitely missing expected answers especially if i assume all ok come from fake ok. M105 is often as it gets inserted every second and due to delay it is most frequent. My guess is that you have hatdware flow control on the new board and it therefore needs a certain rts/dtr setting to work.

    Also on mac you should better use repetier-server for communication. Works much better than the old mac host.
Sign In or Register to comment.