Ender 3 V2 / Pi3b+ or Pi4 : lot of "unknown commmand" and UTF8 chars (Electro Magnetic Interferences)

koreth · September 28, 2020, 3:45pm

What is the problem?

Lot of messages "Recv:echo:Unknown Command" with UTF-8 chars
Overall quality of my print are bad, compared to prints ran from SD Card.
One of my print stopped, the printed kept requesting a re-send of a line, communication was stuck.
One of my print became crazy, rolled back the extruded at a very high speed, retracting all the filament.
The serial.log shows a strange behaviour : printer and Octoprint are sending and receiving at the same time.

What did you already try to solve it?

Try to print from SD : works, quality is good.
Change the USB cable : done, no improvement.

Have you tried running in safe mode and if so did it solve the issue?

Done, no improvement.

Complete Logs

Here are example of Unkown commands sent by the printer.

2020-09-28 17:17:23,347 - Recv: echo:Unknown command: "01.093 E501.74467"
2020-09-28 17:17:23,353 - Recv: echo:Unknown command: "õ"
2020-09-28 17:17:23,361 - Recv: echo:Unknown command: "Y102.174 E501.81515"
2020-09-28 17:17:23,386 - Recv: echo:Unknown command: "526 Y103.615 E501.92092"
2020-09-28 17:17:24,923 - Recv: echo:Unknown command: "Y103.161 E501.8857"
2020-09-28 17:17:24,937 - Recv: echo:Unknown command: "¼Ü[¨ÿm"
2020-09-28 17:17:24,947 - Recv: echo:Unknown command: "03.615 E501.920Y104.043 E501.95612"
2020-09-28 17:17:24,971 - Recv: echo:Unknown command: "104.446 E501.99138"
2020-09-28 17:17:24,978 - Recv: echo:Unknown command: üE"
2020-09-28 17:17:24,987 - Recv: echo:Unknown command: ""
2020-09-28 17:17:26,890 - Recv: echo:Unknown command: "Y105.766 E502.1324"
2020-09-28 17:17:26,912 - Recv: echo:Unknown command: "106.021 E502.16766"
2020-09-28 17:17:26,918 - Recv: echo:Unknown command: "Y106.245 E502.20291"
2020-09-28 17:17:26,927 - Recv: echo:Unknown command: "Y106.437 E502.2381"
2020-09-28 17:17:26,946 - Recv: echo:Unknown command: "15 Y106.827 E502.34386"
2020-09-28 17:17:27,466 - Recv: echo:Unknown command: "ïÿ®ÿèÿ"
2020-09-28 17:17:27,477 - Recv: echo:Unknown command: "Y106.245 E502.20291"
2020-09-28 17:17:27,482 - Recv: echo:Unknown command: "8 Y106.599 E502.27333"
2020-09-28 17:17:27,485 - Recv: echo:Unknown command: "Y106.73 E502.3086"
2020-09-28 17:17:27,855 - Recv: echo:Unknown command: "÷4ÿs"
2020-09-28 17:17:28,705 - Recv: echo:Unknown command: ""
2020-09-28 17:17:29,743 - Recv: echo:Unknown command: "uÿà»"
2020-09-28 17:17:29,763 - Recv: echo:Unknown command: ""
2020-09-28 17:17:29,771 - Recv: echo:Unknown command: "115.378 E505.21086"
2020-09-28 17:17:29,780 - Recv: echo:Unknown command: "114.867 E505.11996"

Example of cacophony

2020-09-28 17:17:25,014 - Send: N9379 G1 X78.449 Y104.819 E502.02664*100
2020-09-28 17:17:25,018 - Recv: ok
2020-09-28 17:17:25,023 - Recv: Error:Line Number is not Last Line Number+1, Last Line: 9374
2020-09-28 17:17:25,025 - Send: N9380 G1 X79.123 Y105.164 E502.06189*104
2020-09-28 17:17:25,027 - Recv: Resend: 9375
2020-09-28 17:17:25,034 - Recv: ok
2020-09-28 17:17:25,038 - Recv: Error:Line Number is not Last Line Number+1, Last Line: 9374
2020-09-28 17:17:25,041 - Send: N9381 G1 X79.81 Y105.48 E502.0971*86
2020-09-28 17:17:25,042 - Recv: Resend: 9375
2020-09-28 17:17:25,048 - Recv: ok
2020-09-28 17:17:25,052 - Recv: ok
2020-09-28 17:17:25,054 - Send: N9382 G1 X80.512 Y105.766 E502.1324*92
2020-09-28 17:17:25,058 - Send: N9383 G1 X81.225 Y106.021 E502.16766*108
2020-09-28 17:17:25,381 - Recv:   TT::211.99211.99  //0.000.00  BB::74.0374.03  //0.000.00  @@::00  BB@@::00
2020-09-28 17:17:25,386 - Recv: 
2020-09-28 17:17:25,828 - Recv: ok
2020-09-28 17:17:25,832 - Send: N9384 G1 X81.948 Y106.245 E502.20291*99
2020-09-28 17:17:25,983 - Recv: ok
2020-09-28 17:17:25,988 - Send: N9385 G1 X82.679 Y106.437 E502.2381*95
2020-09-28 17:17:26,473 - Recv: ok
2020-09-28 17:17:26,479 - Send: N9386 G1 X83.418 Y106.599 E502.27333*99
2020-09-28 17:17:26,882 - Recv: ok
2020-09-28 17:17:26,888 - Send: N9387 G1 X84.164 Y106.73 E502.3086*97
2020-09-28 17:17:26,890 - Recv: echo:Unknown command: "Y105.766 E502.1324"
2020-09-28 17:17:26,893 - Recv: ok
2020-09-28 17:17:26,898 - Send: N9388 G1 X84.915 Y106.827 E502.34386*110
2020-09-28 17:17:26,901 - Recv: Error:Line Number is not Last Line Number+1, Last Line: 9379
2020-09-28 17:17:26,904 - Recv: Resend: 9380
2020-09-28 17:17:26,907 - Recv: ok
2020-09-28 17:17:26,911 - Send: N9380 G1 X79.123 Y105.164 E502.06189*104
2020-09-28 17:17:26,912 - Recv: echo:Unknown command: "106.021 E502.16766"
2020-09-28 17:17:26,915 - Recv: ok

Additional information about your setup

Server : OctoPrint 1.4.2 Python 2.7.16 OctoPi 0.17.0. No modules, bare install. Raspberry Pi 3, SD Card class 10 / 32Go (tried with a smaller one).
Printer : Creality Ender 3 Pro "v2", with the 4.2.2 board (shipped Aug. 2020)
Firmware : Custom Marlin 2.0.1 offered by Creality 3D on their Website (local v1.0.1 for Ender 3 Pro, 32 bit, w/o BLTouch).
Browser : Firefox (not relevent, I think)

My comments

Hey,

First topic here, so : first of all, thanks.
Context : I'm new to 3D printing, but not new to computer tech (esp. Linux / Arduino / Raspi). My experience in electronics is limited
Troubleshooting : a single model whitch prints very well from SD, but not from Octopi.
TL;DR; : I do think that the firmware offered by Creality sucks. But I'm wondering if my troubleshooting is done.

I've encountered multiple error with the Ender 3 Pro "v2" model, when printing via Octoprint. Overall, a lot of mistakes in the print, the head is moving very weirdly. Example : at a point, head goes 10cm away on x &y, then come back, and print again. Also, big moves from the extruded sometimes, like "taking back 30cm of filament for no reasons" or "pushing 20cm of filament".

I looked the GCODE, no commands are for asking this behavior.

But when looking the serial.log (see above), it seems like the printed is sending nasty things through the serial. Even when I just turn the printer on, and do nothing, it sends me these UTF-8 chars.

The problem seems to reside in the cacophony :

octoprint send things
while the printer is busy sending shit
the printer says "ok"
then a few seconds later, the printer complains about not having received a line

The print sometimes fail because the printer continue to ask for a singe line. I tried to turn on the option in octoprint to "simulate OK on resend", but no improvement, the print crashed after 60 seconds.

My feeling gut : the serial line is busy with the printer sending shit and not really listening to what octoprint says, sending "ok" where obviously things are not okay.

Do anyone have stronger experience ? Maybe someone even encountered the same problem ? Should I try new things ?

Thanks a lot, again.
K.

Ewald_Ikemann · September 28, 2020, 4:16pm

Hello @koreth!

First of all, because of this:

You are in need of this plugin:

Then, what you see in the first listing are just the echos of what the printer receives:

2020-09-28 17:17:25,054 - Send: N9382 G1 X80.512 Y105.766 E502.1324*92
-->
2020-09-28 17:17:26,890 - Recv: echo:Unknown command: "Y105.766 E502.1324"

or

2020-09-28 17:17:25,988 - Send: N9385 G1 X82.679 Y106.437 E502.2381*95
-->
2020-09-28 17:17:26,927 - Recv: echo:Unknown command: "Y106.437 E502.2381"

The difference is, the printer received garbage. The creality boards a known to be quite EMI sensitive. You may check another high quality USB cable, thick, with double shielding and ferrite beads and as short as possible.
If your printer is near to an AC or some other high power device, you may increase the distance.

It's quite weird that the printer sends stuff when it receives nil.

Can you establish a normal connection with pronterface to exclude the RasPi from the culprits.

koreth · September 28, 2020, 5:03pm

Thanks for the answer !

I might have lied — though it was'nt on purpose. The sole plugin that was installed was the Creality 2x Temperature fix. The documentation led me to install it, and I completely forgot to mention it. Just to be 100% I made no other mistake like this, I double checked and this was the only plugin I installed. Thanks for the info

The next big hypothesis will be EMIs. I'm gonna buy a strong cable and do thorough tests with the AC moved as far as possible, the new cable and any other device turned off, to see if this fix my issues. I'm quite sure it won't help with the UTF-8-chars-thing, but it can definitely help with the transmission being weird (I would have expected checksum errors but I found no such errors in my logs). I'll probably message Creality also, just to get their point of view.

I'll also discover ponterface, which is completely unknown to me, to see if I can exclude the Pi from the equation. Maybe I'll try with the Raspi 4 too – it's currently in use somewhere else but I guess it's a good test.

That will probably take me a few days before I can get back to you with real results.
Until that, have some good time and take care. Thanks again for the hints !

Cheers,
K.

foosel · September 28, 2020, 5:12pm

Also, just to rule out a possible source of issues, see if the presence of the SD card in the printer makes any difference. I've seen some weird related to SD cards on printers.

koreth · September 28, 2020, 5:17pm

Oh ! Completely unexpected hint
Added to the list of tests, thanks !

Rendrag · September 29, 2020, 5:49pm

I think you should look at the psi you are using for the pi, if it is giving off bad rf it could be affecting the output through the usb cable to the printer

koreth · October 9, 2020, 5:44pm

Hello,

Small update after multiple tests : I'm now conviced that EMI are the root cause. Problem not fixed, but I'm still chasing.

Here's a picture :

From left to right :

printed from the SD Card, in "wood pla"
printed on Octopi / Raspi3b+ / SD Card inserted (not used)
printed on Octopi / Raspi3b+ / SD Card removed (hello @foosel ;))
printed on Octopi / Raspi3b+, No DS, Extraction Max at 3000mm/min (50mm/sec). I thought it was stringing, and I thought that Octopi could have modified the GCODE to limit the extruder. I was both time wrong

So, the stringing you see is not stringing. Models are printed with nearly no travel. Sometimes, the head just decide to jump in the point n+30. That's why my first message referenced a "weird communication", because I just thought that Octopi was flooding the printer. It still could be, but I doubt.

The good thing is that I know have found a way to make tests. I just start a print from the SD, and monitor the logs in the terminal. Octopi is not the problem, it's the solution. And so, I feel like I should stop asking for help here; I may just use these thread as a log of what I'm trying; maybe someone will find it later.

Here are some interesting logs :

Extract 1 : while the printer is printing, I hit the connect button.

2020-10-09 19:02:42,164 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Opening serial connection"
2020-10-09 19:02:42,180 - octoprint.util.comm - INFO - Connecting to port /dev/ttyUSB0, baudrate 57600
2020-10-09 19:02:42,195 - octoprint.util.comm - INFO - Changing monitoring state from "Opening serial connection" to "Connecting"
2020-10-09 19:02:42,813 - octoprint.util.comm - WARNING - Received line:
2020-10-09 19:02:42,814 - octoprint.util.comm - WARNING - | \x00JJ
2020-10-09 19:02:42,815 - octoprint.util.comm - WARNING - The received line contains at least one null byte character at position 5, this hints at some data corruption going on
2020-10-09 19:02:42,975 - tornado.access - WARNING - 409 GET /api/printer (::ffff:192.168.200.247) 9.56ms
2020-10-09 19:02:44,985 - tornado.access - WARNING - 409 GET /api/printer (::ffff:192.168.200.247) 18.60ms
2020-10-09 19:02:45,827 - octoprint.util.comm - WARNING - Received line:
2020-10-09 19:02:45,828 - octoprint.util.comm - WARNING - | \x00JH\x00Ljj
2020-10-09 19:02:45,830 - octoprint.util.comm - WARNING - The received line contains at least one null byte character at position 5, this hints at some data corruption going on
2020-10-09 19:02:49,110 - octoprint.util.comm - WARNING - Received line:
9vS0-10-09 19:02:49,111 - octoprint.util.comm - WARNING - | ÈNHLzÎê\x00JHLzzjøgú½
2020-10-09 19:02:49,113 - octoprint.util.comm - WARNING - The received line contains at least one null byte character at position 23, this hints at some data corruption going on

Extract 2 : while the printer is printing, strange things are received

Recv: echo:Unknown command: "¢\x81\xffÏ\x02\x01¯\x87"
Recv: ok
Recv: echo:Unknown command: "4"
Recv: ok
Recv: echo:Unknown command: "\x04õ¥"
Recv: ok
Recv: echo:Unknown command: "\x01"
Recv: ok
Recv: echo:Unknown command: ""
Recv: ok
Recv: echo:Unknown command: ""
Recv: ok
Recv: echo:Unknown command: "\x05õþ\x01U\xff\xff\x05´u\x11"
Recv: ok
Recv: echo:Unknown command: "\x14"
Recv: ok

My thought, now :

It is not clear if the PSI is the problem, or the USB connection. I doubt, cause I've tested many cables + different power units, including two official RPI; I do a lot of arduino / rpi things, I never encountered such issues, but I also never use serial interfaces …
It is not clear that the issue is not in the Printer's mobo. When plugged of, moving the bed manually will drive enough power from the motors to actually light the screen. I've discovered that when the printers does nothing, there's no noise on the serial line; when the printer is at work, there's a lot of noise ("unknown commands"). I'm convinced that the noise comes from motors, directly in the mobo.

If anyone have an Ender 3 Pro v2 (with the 4.2.2 card) and managed to work with Octopi, I'd be happy to know which setup you use, especially brands of your power unit and usb cables – is that a thing, shielded micro-usb cable ? Can't find one anywhere

Last words : thanks for the hints and help !

Cheers,
K.

koreth · October 11, 2020, 7:16pm

Ooh, that is quite interesting.

I just had my mind blown while thinking to a simple thing : connect the serial to a standard computer. MacBook Pro connected to the printer via USB. Using the command screen -L /dev/cu.usbserial-12345, I look at the console output and see nothing like with the raspi.

Print test : as perfect as from the SDCard. Case solved, Raspi (3b+, 4) are having trouble with EMI. Even with PI far away from the printer. I've used the same USB cable from the laptop and the Pi. Tried the PI with official power sources, also powered from the USB hub of my computer (which is not great, raspi are suffering from lack of power), and power plugs from smarphone manufacturers (Samsung, HTC, …).

Two things I'm thinking about :

powering the Pi from the PSU of the printer may negate the noise
powering the Pi from a (passthrough) powerbank may help
I don't know if "grounding the Pi" is a thing, I may try something like this

Cheers,
K

koreth · October 14, 2020, 10:46pm

I've tracked down the problem. The only thing I managed to do was narrowing the test. I found it fun so I wanted to share it here.

The printer sends nasty things as soon as steppers are enabled.
I first turn the Temp Autoreport on (a proof that the line is clear).
Then, I turn the steppers on (M17). Here comes the mess.
I finally turn off (M18) the steppers to get back to a clean serial line

The next step will be to power the PI from the printer's PSU. If the problem is what I think (the PI not being grounded via it's PSU), that will do the trick. I think I had no issues with arduino, since none of them was grounded to the 220V. There might be something that send noise over the power lines which finishes in my raspi.

See ya

foosel · October 15, 2020, 8:28am

That is a GREAT idea to test with M17/M18, will have to remember that for future debugging help. Also really interested on your further findings!

EMI on a Pi is a new one, I've seen a lot of crap over the years though and it wouldn't surprise me tbh.

koreth · October 16, 2020, 10:13am

Hey

So, I finaly powered the Pi through the printer's PSU.
As expected : it works !

I suspected a lot of noise based on the fact that the Pi and the printer have non-shared ground; as well mentionned here, Creality's printers emits a lot of noise (due to motors, mainly). I never encountered the issue because it's the first time I play with real electricity :D. Arduino+Raspi have no issues for obvious reasons.

So, here's what I've done :

buy some XT60 Y-connector
cut one child of the XT60, goes to a LM2596 to get a 5V from the 24V
power the Pi from this new 5V line
Bonus : power a relay module with this 5V too, pinned to GPIO40 of the Pi
Strap the USB power pin (because uhubctrl doesn't work well with Raspi 3b+)
Install PSU Control and now I can even power off my printer from Octoprint

Octoprint is really a fantastic product. Thanks to the Terminal command, your help and a bit of reading, I spent some wonderful hours debugging this (as many, I love the path more than the destination ;)). Thanks also to Ragheera, I've sourced the relay/duck thing from their print on Thingiverse, they even shared an electronic schema ! (https://www.thingiverse.com/thing:3483446).

Last but not least, it may be time now to look at plugin writing. PSU Control is cool, I may want to be able to extend it with commands like ... trigger a uhubctl command when receiving a M80

I think I've reached a goal now. I'm in debt, so I'll watch the forums and offer help if possible.

Thanks again !
K

foosel · October 16, 2020, 10:34am

Thank you so much for getting back to us here with the latest findings, and also the kind words.

This is a great example of how to participate in this community that couldn't have come at a better time, thank you so much!

jneilliii · October 16, 2020, 11:17pm

You might be interested in this plugin...https://github.com/OutsourcedGuru/OctoPrint-USBControl.

You cannot be more accurate in that statement. I found it a very positive experience keeping up with this thread and appreciate the time and effort that went into this debugging done by @koreth. It's unfortunate that the new creality boards seem to be so problematic.

koreth · October 17, 2020, 11:22am

Hey

To be fair, my electric system here seems to be hard. It may be that one of my equipment is leaking a lot of noise to the line, and the creality may just be failing at filtering this, which is not a requirement for 99% of users. Plus, I'm a rookie in 3D printing so, I'd be happy to share the responsibility with Creality on that one

Thanks for the hint about the plugin. I tried it, but found no parameters to trigger USBControl upon event (like "print finished"). I know Octoprint has such a mechanism (signals). The thing is, printing from a Rpi3b+, if I shut my USB off, there's no more communication with the printer, so I don't want it permanently. I'm using a strap on the USB cable for now.

In french we say « avoir le beurre et l'argent du beurre » ("keep the butter and the money")

K.

flrnwgnr · December 1, 2020, 11:33am

Hey @users and @foosel !

I'd like to share my experiences with these problems and how I solved them. Maybe you @foosel can include this solution in your FAQs for the new "resend requests".

Soo my printer is an Ender 3S and it worked just fine with an Raspberry Pi 3. But suddenly i experienced all these errors in my terminal, for example:

[Error:Line Number is not Last Line Number+1,]
echo:Unknown command: ...

and so on - especially when the steppers are on!

Vorher

flrnwgnr · December 1, 2020, 11:33am

Because it has worked well so far, I searched for the solution by changing cables, repositioning the RPi or trying another power supply. But I finally found it!

The day before i printed a drawer and pushed the cable for the LCD just behind it - like this:

And that was the problem! After i re-arranged the cable according to the picture below (as I had it before and as you can see on the picture)

flrnwgnr · December 1, 2020, 11:35am

ALL the errors went away - the amount of resend requests went from 16% down to 0% and print artefacts went away.

(sorry, have to split my answers because i cant post more than one image per reply)

Also the problem came back when i pushed the cable back behind the drawer, so in my case this was definitely the root cause of the problem.

So if you are facing these problems: check your printer cable!

Bert_UK · December 30, 2020, 7:10am

Spent a day looking at the resend ratio issue that I was getting, I did the switched to use different Raspi's / cables. Also reinstalled Octoprint on the Pi, installing Octoprint on a windows tablet, and it was all down to the control cable!!! Why would this be the case? Anyway, thank you for the posting your solution it helped me track down the problem, and now I'm back to been able to use Octoprint

Charlie_Powell · December 30, 2020, 10:08am

Bad cables can be very susceptible to interference, since they may not be shielded/twisted together. Or over time, the connections within can degrade and so becomes a bit intermittent at transferring data. There's a whole number of reasons, good that you got it sorted!

Tim_Newton · January 12, 2021, 10:44pm

Thank you sir.. after days of troubleshooting, moving things around.. creating a shielded enclosure for my raspberry pi, cutting power line in a usb cable, adding ferrites, etc.. I knew the problem was only caused when stepper motors are used, but also when using the menus on the Ender 3 LCD.

I had folded the ribbon cable on top of itself and clipped it out of the way. Last night, I ordered another Pi as I was sure that power back from the printer had damaged mine causing EMF sensitivity.. earlier today I read this thread.. I just unfolded the cable and now I am printing with 0 resends again.. with the cable folded.. i was getting them immediately after printer starting printing object (not during rafts) I would have 20% errors within the first 10 mins of printing and the printer would move erratic..

THIS FIX WORKED FOR ME!!! Thank you very much for this insight you have shared.

T.