Waiting for command

Hello, I've been having this issue with my new printer and after trying what I've seen on other threads my issue persists and I'm uneable to fix it.

I'm using a Microdelta Rework from Emotion-tech with firmware 1.7D without heated bed (https://www.emotion-tech.com/support-microdelta#files) and the version 2.1.6 of repetier with the MDRPlugin. The repetier-server is not installed and I also tried using version 1.6.2 of repetier.

When I connect the printer to repetier i get the following lines:  

19:08:17.395 : No start signal detected - forcing start
19:08:17.397 : N1 M11034
19:08:17.397 : N2 M11536

19:08:17.397 : N3 M10536
19:08:17.398 : N4 M11435

19:08:17.426 : N5 M111 S698
19:08:17.427 : N6 T060

19:08:17.427 : N7 M2022
19:08:17.429 : N8 M8019

19:08:17.429 : N9 M10546
19:08:17.495 : Begin file list
19:08:17.501 : Could not open directory /sd
19:08:17.502 : End file list
19:08:20.460 : N10 M10522

19:08:23.517 : N11 M10523
19:08:26.583 : N12 M10520

19:08:29.646 : N13 M10521
19:08:32.704 : N14 M105
19:08:35.769 : N15 M105*19

It always stops at N14 or 15 and stays with "Waiting 1 command"  for a while, then it gives the following or it does not give anything at all:

19:09:15.803 : Communication timeout - reset send buffer block
19:09:15.803 : N16 M105*16

If you send commands before the N15 line, for example the homing command, the printer does it as expected. Also I tried the calibrating sequence of this printer, if sent before the N15 it starts but stops in the middle of the calibration.

I have tried everything said here: https://www.emotion-tech.com/support-microdelta#faq (in the last cage)
I have also tried what whas said in the forum, I tried different ports and baudrates (From 115200 to 250000, even though the config has the baudrate set at 115200). 

I need help with this.


  • Was ack enabled in log? I miss the firmware answers of "ok" here.

    When commands get executed the baud rate would be correct. Make sure protocol is automatic or ascii, not binary assuming it is not repetier-firmware. If you get no "ok" try changing DTR/RTS setting until you see answers from firmware.
  • I enabled the ack and tested all possible DTR/RTS configurations with no avail, it usually got until N17 before stopping. I also tried with the smoothieboard firmware but with it only got until N20 before stoping sending the ok.

    Here I put the log example:

    14:51:27.266 : No start signal detected - forcing start
    14:51:27.268 : N1 M110*34
    14:51:27.269 : Smoothie
    14:51:27.269 : ok
    14:51:27.269 : N2 M115*36
    14:51:27.269 : Smoothie
    14:51:27.269 : ok
    14:51:27.269 : ok
    14:51:27.269 : ok
    14:51:27.269 : N3 M105*36
    14:51:27.270 : ok
    14:51:27.270 : ok
    14:51:27.270 : N4 M114*35
    14:51:27.301 : N5 M111 S6*98
    14:51:27.301 : ok
    14:51:27.301 : ok C: X:0.0000 Y:0.0000 Z:0.0000 E:0.000
    14:51:27.301 : ok
    14:51:27.301 : N6 T0*60
    14:51:27.302 : N7 M20*22
    14:51:27.302 : ok
    14:51:27.302 : ok
    14:51:27.302 : N8 M80*19
    14:51:27.302 : N9 M105*46
    14:51:27.302 : ok
    14:51:27.302 : ok
    14:51:27.304 : Begin file list
    14:51:27.304 : system volume information/
    14:51:27.304 : config.txt
    14:51:27.304 : read_me.txt
    14:51:27.304 : spoolholder_v2.gcode
    14:51:27.304 : firmware.cur
    14:51:27.305 : End file list
    14:51:27.305 : ok
    14:51:27.305 : ok
    14:51:27.305 : ok
    14:51:27.307 : ok
    14:51:27.311 : ok
    14:51:30.330 : N10 M105*22
    14:51:30.334 : ok
    14:51:33.395 : N11 M105*23
    14:51:33.400 : ok
    14:51:36.454 : N12 M105*20
    14:51:36.456 : ok
    14:51:39.517 : N13 M105*21
    14:51:39.518 : ok
    14:51:42.578 : N14 M105*18
    14:51:42.580 : ok
    14:51:45.642 : N15 M105*19
    14:51:45.644 : ok
    14:51:48.703 : N16 M105*16
    14:51:48.705 : ok
    14:51:51.766 : N17 M105*17
    14:51:51.768 : ok
    14:51:54.829 : N18 M105*30

  • Ok I see you have a smoothie board/firmware and communication is working.
    What is strange is the 0 returned for every M105 - should respond with a temperature information unless you have checked in printer settings ->Printer->Remove temperature requests from log. But that would also remove M105. 

    I don't know anything about a MDRPlugin plugin. From what I see the firmware starts blocking with line 18 - no "ok" after that. Guess after a while you get a timeout and host sends more commands?

    What else can you do? You can use a serial monitor to connect to the printer directly and not with host. Then you see unfiltered communication. Then check if you can send manually more lines with responses and especially what M105 returns. 0 is not the expected answer so much I'm sure. Should look more like
    T:25 /0 @:0 B:24 /0 @:0

    There are some variances, but all like a bit like that line.
  • Apparently after copying the log the @ got lost but it appears on the log as you pointed out. I tried using a serial monitor and send the commands manually but it stops sending the ok after a while, depends on how fast I am at sending the commands. 

    I do get the timeout after a while but the host still not receives any answer.
  • With serial monitor stopping as well after 18 commands or so I guess the firmware has a problem. I'm not familiar enough with smoothie firmware, but I would ask in their forum maybe if that is a known problem. Maybe it just a configuration issue in their config file or a bug in the version on your sd card. You can test if new firmware works better. As far as I know you just need to copy a installer file on sd card and reinsert it to install a new firmware.
  • So I returned the printer to the friend that lend it to me and using the same firmware and hardware the printer works and doesn’t have this issue. So I think the issue is with the computers in my house (?) or something like that which is pretty frustrating but I don’t care any more.

    Either way thanks you for your help, it was pretty useful.

Sign In or Register to comment.