Waiting for command

iguay009

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 M10518
19:08:35.769 : N15 M10519

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 M10516
</span>
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.

Repetier

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.

iguay009

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 M11034

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 : N3 M10536

14:51:27.270 : ok

14:51:27.270 : N4 M114*35

14:51:27.301 : ok T:28.0 /0.0 @0

14:51:27.301 : N5 M111 S698

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 M2022

14:51:27.302 : ok

14:51:27.302 : N8 M80*19

14:51:27.302 : N9 M10546

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.307 : ok

14:51:27.311 : ok T:28.0 /0.0 @0

14:51:27.311 : ok

14:51:30.330 : N10 M105*22

14:51:30.334 : ok T:28.0 /0.0 @0

14:51:30.334 : ok

14:51:33.395 : N11 M10523

14:51:33.400 : ok T:28.1 /0.0 @0

14:51:33.400 : ok

14:51:36.454 : N12 M105*20

14:51:36.456 : ok T:27.9 /0.0 @0

14:51:36.456 : ok

14:51:39.517 : N13 M10521

14:51:39.518 : ok T:27.9 /0.0 @0

14:51:39.518 : ok

14:51:42.578 : N14 M105*18

14:51:42.580 : ok T:28.0 /0.0 @0

14:51:42.580 : ok

14:51:45.642 : N15 M10519

14:51:45.644 : ok T:28.1 /0.0 @0

14:51:45.644 : ok

14:51:48.703 : N16 M105*16

14:51:48.705 : ok T:27.9 /0.0 @0

14:51:48.705 : ok

14:51:51.766 : N17 M10517

14:51:51.768 : ok T:28.0 /0.0 @0

14:51:51.768 : ok

14:51:54.829 : N18 M105*30

Repetier

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.

iguay009

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.

Repetier

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.

iguay009

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.