Octoprint: AnyCubic i3 Mega - non standard responses

[gregopti]

What were you doing?

I've recently received custom firmware from AnyCubic with ability to connect it with Octoprint. There was some baudrate and serial driver issue with original one. See: https://github.com/guysoft/OctoPi/issues/452

I tried to print something.

What did you expect to happen?

Since I've notice different comunication protocol, I knew it won't work.

I have tested it on computer using Simplify3d and got this communication.
Note: Printer started printing normally.
https://pastebin.com/JUNCAVVB

What happened instead?

When trying to print I've faced another issue: non standard responses to M190 and "OK" confirmations.
That caused OctoPrint to send new requests even if last one was still not finnished. At the end that meant printer started to print without heating the extruder and going to home position - those was skipped. Printer was sending wait responses but Octoprint kept sending new requests.

Octoprint kept sending new requests even though printer replied "wait" and sent "OK" for other requests.

The issue is that printer sends wait responses during heating up and also sends OK responds with line number, meaning they can be confirming some past line and not neccesarely the previos one. When it is heating the extruder, it is just sending "wait" respond and doesn't send the temperature.

Example (Octoprint - Anycubic i3 Mega):

https://pastebin.com/tu6328uy

Here is an example of connecting printer:

https://pastebin.com/9KKZ0VxJ

Did the same happen when running OctoPrint in safe mode?

Version of OctoPrint

OctoPrint 1.3.6 running on OctoPi 0.14.0

Operating System running OctoPrint

OctoPi 0.14.0

Printer model & used firmware incl. version

Anycubic i3 Mega (Ultrabase varsion) - customized by Anycubic to work with 115.2kbps

Browser and Version of Browser, Operating System running Browser

Firefix/Chrom, Windows 10

Link to octoprint.log

https://pastebin.com/9VMjpt64

Link to contents of terminal tab or serial.log

https://pastebin.com/tu6328uy
https://pastebin.com/9KKZ0VxJ

[GitIssueBot]

Hi @gregopti,

It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Read the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).

If you did not intend to report a bug but wanted to request a feature or brain storm about some kind of development, please take special note of the title format to use as described in the Contribution Guidelines.

Please do not abuse the bug tracker as a support forum - if you have a question or otherwise need some kind of help or support refer to the Mailinglist or the G+ Community instead of here.

Also make sure you are at the right place - this is the bug tracker of the official version of OctoPrint, not the Raspberry Pi image OctoPi nor any unbundled third party OctoPrint plugins or unofficial versions. Make sure too that you have read through the Frequently Asked Questions and searched the existing tickets for your problem - try multiple search terms please.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2018-01-04 15:50 UTC) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.

[crckmc]

I have the same problem with the latest OctoPrint (Version 1.3.6) on Windows is there any known workaround?

[electron23]

I have also the problem. Is there already a fix?

@gregopti where can I find the firmware? What is this for an version?

I have already tried to flash the new 1.1 firmware over my existing 1.1 firmware but with no success. Cura told me that no printer was recognized.

For debuging, that is my terminal log when connection to the printer with 250000 baud:
https://pastebin.com/JbWu5iP7

Btw: With Cura on Windows I have no problems.

[gregopti]

I guess I can share it here, since it is the same firmware, with only difference that it works on 115.2kbps.
Unzip file, Copy the modified firmware (update.zw) to SD card , plug it into the printer and then reboot the printer, wait for the firmware update is complete. Remove file from SD cards afterwards.
update.zip

[foosel]

This actually rather looks like the firmware is sending out an extra ok here that confuses things:

Changing monitoring state from 'Operational' to 'Printing'
Send: N0 M110 N0*125
Recv: ok N:0                         <- This obviously belongs to M110 (N matches)
Send: N1 G90*17
Recv: //####checkSum error expect:0x7e,actual:0x7d!str:N0*125
Recv:
Recv: ok                             <- Where does that come from? It can't belong to the G90...
Send: N2 M82*27
Recv: //####checkSum error expect:0x0,actual:0x7d!str:*125
Recv:
Recv: ok N:1                         <- ... because THAT seems to belong to G90 (N matches)
Send: N3 M106 S0*100
Recv: ok N:2                         <- M82
Send: N4 M140 S60*87
Recv: ok N:3                         <- M106
Send: N5 M190 S60*91
Recv: ok N:4                         <- M140
Send: N6 M104 S200 T0*37
[...]
Recv: ok N:5                         <- M190

So the question is, why does the firmware send an extra ok here? It shouldn't, and doing so causes the whole ping-pong-sending-protocol to collapse here. And also: What is going on with its parsing of that M110 line there? It appears to think that the parameter N0 [1] is its own command and then really hiccups hard when trying to parse that.

What could be is that this wonky parsing issue here triggers this extra ok. To check, you could try placing this small plugin in ~/.octoprint/plugins. On OctoPi just SSH into your Pi, download the file to the plugins folder and restart OctoPrint:

cd ~/.octoprint/plugins
wget https://gist.githubusercontent.com/foosel/924a6518b2dea77c9a6ff1f2561b8bb7/raw/46dcd2cd651817683746772907917b72d0c201a5/strip_m110_parameter.py
sudo service octoprint restart

Then test. What it does is it rewrites any M110 commands to be parameterless, so N0 M110 N0*125 becomes N0 M110*35 instead.

[1] OctoPrint sends an N parameter here because that is what some firmware require to function. Others require M110 to be sent with the line number its supposed to reset to. To be compatible to both without users having to endlessly toggle checkboxes, OctoPrint simply sends both and so far no firmware that I encountered had a problem with that... Anycubic's the first there, hooray!

PS: I really wish printer vendors would just stop messing with firmware if they don't fully understand the protocol in place and just use what's already available instead of cooking up their own variants... Trying to keep things working in this environment of vendors just doing what they feel like and breaking stuff left and right in the process for end users is making this job extraordinarily frustrating to a point where I sometimes just want to scream.

[gregopti]

The plugin unfortunately didn't help.
I think the main problem is that when printer sends "wait", Octoprint sends new request instead of waiting for the request to complete.

I'm sending complete serial.log from the moment of connecting, then starting printing a cube, canceling due to unheated extruder and skipped commands (heating extruder, home position, intial script and begining of print) and finally disconnecting the printer.
https://pastebin.com/FiF71gWG

I think the solution could be, that whenever printer sends "wait" it doesn't sends anything new till the printer sends something else than "wait". Or simple consider reply "wait" as not reply at all, meaning Octoprint shouldn't send new requests if it doesn't receive reply, right?

PS: I also think that where there is some standard people should stick to it as it makes life easier for everyone.

[foosel]

What OctoPrint does is correct, Anycubic is just misusing the wait here. It should only be sent if the printer hasn't received a command in a certain timeout and its planner buffer is dry. Instead here it is being abused as something similar to the busy protocol.

Another idea, new plugin. Installation:

cd ~/.octoprint/plugins
wget https://gist.githubusercontent.com/foosel/77e4792921db744a157764f66d1d72a5/raw/89995d42b2cae5a0f403bea49d161e7959f9f3ce/rewrite_wait_to_busy.py
sudo service octoprint restart

This one internally rewrites the wait to echo:busy processing so that OctoPrint won't interpret it the normal way. Don't uninstall the other one, you need both.

As a side note:

2018-01-11 12:02:09,278 - Send: N1 M115*39
2018-01-11 12:02:09,286 - Recv: ok ZWLF make it.Date:Dec 19 2017 Time:20:47:53

Nope... Just nope. That is not a well formatted response to an M115. Also:

2018-01-11 12:04:44,385 - Send: N103 G1 X110.754 Y95.480 E0.5554*103
2018-01-11 12:04:44,387 - Recv: ok N:101
2018-01-11 12:04:44,389 - Send: N104 G1 X114.520 Y99.246 E0.7148*110
2018-01-11 12:04:44,434 - Recv: ok N:102
2018-01-11 12:04:44,436 - Send: N105 G1 X114.520 Y99.812 E0.7318*99
2018-01-11 12:04:44,437 - Recv: Resend:103
2018-01-11 12:04:44,438 - Recv: ok
2018-01-11 12:04:44,439 - Send: N103 G1 X110.754 Y95.480 E0.5554*103
2018-01-11 12:04:44,442 - Recv: //last:102 curr:104 rcv:N104 G1 X114.520 Y99.246 E0.7148*110
2018-01-11 12:04:44,442 - Recv:
2018-01-11 12:04:44,443 - Recv: 3
2018-01-11 12:04:44,445 - Recv: Resend:103
2018-01-11 12:04:44,446 - Recv: ok
2018-01-11 12:04:44,447 - Send: N103 G1 X110.754 Y95.480 E0.5554*103
2018-01-11 12:04:44,451 - Recv: //last:102 curr:105 rcv:N105 G1 X114.520 Y99.812 E0.7318*99
2018-01-11 12:04:44,454 - Recv: N103 G1 X110.754 Y95.480 E0.5554*103
2018-01-11 12:04:44,455 - Recv:
2018-01-11 12:04:44,455 - Recv: 3
2018-01-11 12:04:44,461 - Recv: ok N:103

Resend request lacking the Error: line that indicates what the problem even was (which in some scenarios sadly is needed) 😕

[gregopti]

I've tried the new plugin/hook and result was it couldn't connect to printer.
https://pastebin.com/23TfUvPH
Later I went to change the hook and reboot OctoPrint. (I added "line" after "return")

def rewrite_wait_to_busy(comm_instance, line, *args, **kwargs):
    if line != "wait":
        return line
    return "echo:busy processing"

I tried it first time. The result was, that printer did everything as it should and printed a cube although with too low first layer. (note for later: printer was already in home position) Unfortunately I didn't save the serial log.

So I tried to print it again... No success this time. Printer started to print in middle of air with cold extruder.
Try no. 2: https://pastebin.com/Y5yE0xpw
(Serial error on the end because I turned the printer off.)

In third try, nothing else changed... Printer heated the extruder, but didn't go to home position and started printing from the point where extruder was.
Try no. 3: https://pastebin.com/rrZGYKdE
(Serial error on the end because I turned the printer off.)

Forth try was in principle same as second one, unheated extruder, mid-air printing.
Try no. 4: https://pastebin.com/HQVZAKbp
(Serial error on the end because I turned the printer off.)

For some reason it is skipping some commands and doesn't send "Resend:" when it should...

[foosel]

First of all sorry for the missing return parameter... That was a copy paste error from the previous plugin 😳

But from the logs it looks like it's not actually doing anything anymore starting with your second try. Let's try adding some logging, just to make sure it's actually running into that code. I've updated the gist (including your fix), install should work with wget https://gist.githubusercontent.com/foosel/77e4792921db744a157764f66d1d72a5/raw/0e23f2867971cc9b2347dcaa269fd0e31572753c/rewrite_wait_to_busy.py at the usual location (you might have to delete the old version first via rm rewrite_wait_to_busy.py, I'm not sure right now if wget will overwrite existing files by default or not).

[SchizoDuckie]

That looks like a brilliant solution!

I have one of the upgraded models myself. I'll try to verify if the
'updated version' has the same behavior as soon as my pi arrives.

On Thu, Jan 11, 2018 at 5:43 PM, Gina Häußge [e-mail]
wrote:

First of all sorry for the missing return parameter... That was a copy
paste error from the previous plugin 😳

But from the logs it looks like it's not actually doing anything anymore
starting with your second try. Let's try adding some logging, just to make
sure it's actually running into that code. I've updated the gist
https://gist.github.com/foosel/77e4792921db744a157764f66d1d72a5
(including your fix), install should work with wget https://gist.
githubusercontent.com/foosel/77e4792921db744a157764f66d1d72a5/raw/
0e23f2867971cc9b2347dcaa269fd0e31572753c/rewrite_wait_to_busy.py at the
usual location (you might have to delete the old version first via rm
rewrite_wait_to_busy.py, I'm not sure right now if wget will overwrite
existing files by default or not).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/foosel/OctoPrint/issues/2309#issuecomment-356987048,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAG0Xszcy27Bcjj6NbU8wpezGUgzlZBeks5tJjpLgaJpZM4RJ_2C
.

[gregopti]

Now this seems to be working :)
Octoprint now waits and doesn't sends new requests after "wait" signals, also you can see in octoprint.log that it is replacing the wait signals with echo:busy processing. (I have later disabled this logging) And it prints quiet well.
https://pastebin.com/8JsAuLyf

But after succesful print I have noticed that ending script was not as set, and I got this errors, repeating on terminal:
https://pastebin.com/VGT51Pz9

[foosel]

Recv: Resend:7034
Recv: ok
Send: N7034 G28 X*91
Recv: //last:7033 curr:7035 rcv:N7035 M84*46
Recv:
Recv: 3
Recv: //sd cmd error cnt:16175 len:15 :N7034 G28 X*91
Recv:
Recv: ok
Send: N7035 M84*46
Recv: Resend:7034
Recv: ok
Send: N7034 G28 X*91
Recv: //last:7033 curr:7035 rcv:N7035 M84*46
Recv:
Recv: 3
Recv: //sd cmd error cnt:16176 len:15 :N7034 G28 X*91
Recv:
Recv: ok

This is funny :D

Printer: Hey, please resend line 7034!

OctoPrint: Sure, here you go! sends line 7034

Printer: Ok, great! Ready for the next line!

OctoPrint: Perfect, here you go! sends line 7035

Printer: Errr.... eek... abort, abort... Hey, please resend line 7034!

OctoPrint: Sure, here you go! sends line 7034

Printer: Ok, great! Ready for the next line!

[and they lived angrily shouting at each other ever after]

So... I have no idea what triggers this merry go around, so I don't know if might be able to fix this by yet another workaround plugin (to be then merged into one I guess because it's starting to become a bit much). What I'd need is a full serial.log from a whole print, including the end of it and the start of the loop.

Also, please share your start and end script and the printed GCODE file so all of it can be matched up against what we'll be seeing in the serial.log.

I can't promise though that we'll get it to work fully... this firmware is really messed up, and I'd strongly suggest to write an angry letter or two to the manufacturer. What they are doing there roughly resembles the regular GCODE based communications on first glance, but behaves nothing like it or outright goes against it in some places (e.g. the wait usage).

[crckmc]

I have (had) the same problen and am very grateful for your patches 👍
I wrote the Anycubic support and send them here.
They say they are working on a fix in firmware:
"Hello:
Thanks very much for your email and support.
Our software engineer will update this feature, and also will give the results as soon as possible.
Thanks again for your suggesttion and support."

Lets hope they fix their software as the hardware is really great for the price.

[gregopti]

Ok, so here we go...
I printed a simple cube and everything went fine except the ending is where things go wrong way.
https://pastebin.com/14wTqYJx
(I had to cut repating error sections otherwise the file is too big, since this error goes up several times in one second - only thing what changes is the "error cnt:" number which keeps increasing )

Here is also complete gcode file:
https://pastebin.com/vihfWvUZ

The G28 X is where it seems to go wrong. Extruder in reality moves towards X home position but never reaches end switch, unless I've missed it, but it stays 1cm from it.

PS: It's funny but at same time sad... tragicomic :P

[foosel]

@crckmc I'll keep my fingers crossed!

@gregopti Is this G28 X part of your slicer's end code? I'd try a variant of this... G28 X0 instead of G28 X. From my experience the correct format of a G28 with axes limitation depends a bit on the firmware variant - and depending on who you ask, either X or X0 is the one and only true form ;)

It's tough to say since it doesn't look like anything regular firmware produces, but maybe this sd cmd error debug output:

2018-01-12 11:56:05,767 - Recv: //sd cmd error cnt:0 len:15 :N2021 G28 X*90
2018-01-12 11:56:05,769 - Recv:
2018-01-12 11:56:05,770 - Recv: ok

is supposed to mean something like "Could not understand this command, seems to be malformatted, please fix and send again" and this then causes the loop?

I'd rather have expected an Error: Unknown command here or something like that. Beats me though why it doesn't immediately request a resend then but instead first sends a normal ok, then asks for the same line that just caused an issue again.

[gregopti]

Ok, problem solved. Thanks for advice.
G28 X0 is the right command.

Send: N7395 G92 E0*127 Recv: ok N:7395 Send: N7396 M105*28 Recv: ok T:198 /200 B:60 /60 @:99 B@:71 Send: N7397 G1 E-5.5000 F3000*33 Recv: ok N:7397 Send: N7398 G1 X0 Y195 F2400*113 Recv: ok N:7398 Send: N7399 M106 S0*83 Recv: ok N:7399 Send: N7400 M104 S0*86 Recv: ok N:7400 Send: N7401 M140 S0*87 Recv: ok N:7401 Send: N7402 G28 X0*106 //<---------------------- Recv: wait Recv: wait Recv: wait Recv: ok N:7402 Send: N7403 M84*47 Recv: ok N:7403 Send: N7404 M107*18 Recv: ok N:7404 Send: N7405 M300 S1500 P100*32 Recv: ok N:7405 Send: N7406 G4 P100*89 Recv: ok N:7406 Send: N7407 M300 S1500 P100*34 Recv: ok N:7407 Send: N7408 G4 P100*87 Recv: ok N:7408 Send: N7409 M300 S2500 P100*47 Recv: ok N:7409 Send: N7410 G4 P100*94 Recv: ok N:7410 Send: N7411 M300 S2500 P1000*22 Recv: ok N:7411 Send: N7412 G4 P500*88 Recv: ok N:7412 Send: N7413 M300 S2500 P1000*20 Recv: ok N:7413 Changing monitoring state from 'Printing' to 'Operational'

[Commander112]

Thumb up
Same Issues with same Printer (Firmware+Hardware)...
So I updated the Firmware of the Printer like @gregopti do, install the rewrite_wait_to_busy-Script, make a few changes on my Start/Ending-GCODE and now all is running perfect!!

Thanks to @foosel aka. Gina for her excelent support!
I think I can do a little support on patreon so you can help us next time again ;-)

[foosel]

Hooray! I've just dared to mark this as solved. Still wondering how best to proceed here though - maybe I should bundle up those two fixes into one "Anycubic Compat Plugin" and push that to the repo? Maybe someone also wants to extend that then to swallow/translate those "unknown/invalid command" errors there in some way, even though I'm not entirely sure how best that could be achieved.

[electron23]

Can you explain the exact steps please.

[coconuthero]

I also have the same problem with my new Ultrabase I3 Mega with firmware: V1.4.ORC23/P3
I yesterday wrote to anycubic about it and also referred to this place and their reply today was:

_Sorry the printer does not support octoprint Raspberry pi , pls use cura if you need to print on line_

Doesn't look like they are aware what octoprint is, or working on a firmware update... :-(
I would definately be interessted to get a noob-friendly fix for this issue incl donation!

[foosel]

@coconuthero since @gregopti did get a firmware from them that is capable of talking to hosts like OctoPrint, I'd say things don't look that grim. However, I have no idea if that firmware is compatible to your model. I have no idea of the Anycubic lineup of printers (and frankly after seeing bits of their self tinkered firmware I don't want to get too personal with that stuff either).

As a summary on how to get things working once there's a firmware flashed that does allow an initial connection to succeed, here's what to do to get it behaving (instructions for OctoPi via SSH, adapt accordingly if you installed from source):

cd ~/.octoprint/plugins
wget https://gist.githubusercontent.com/foosel/924a6518b2dea77c9a6ff1f2561b8bb7/raw/46dcd2cd651817683746772907917b72d0c201a5/strip_m110_parameter.py
wget https://gist.githubusercontent.com/foosel/77e4792921db744a157764f66d1d72a5/raw/8593ddb36e8d41a67ad9ccc01c36bb2863f5e7c2/rewrite_wait_to_busy.py
sudo service octoprint restart

This installs both plugins written over the course of this thread here that change the non-standard replies and behaviours of the firmware in such a way that communication can succeed (as long as your GCODE files don't contain stuff the firmware doesn't like in which case it starts a resend loop instead of sending an invalid command error).

It probably makes sense to merge these two plugins into one and publish that on the repository. I'll try to get around to do that as soon as I can and then close this ticket with a link to it.

[thetobby]

@gregopti Hi, Do you have the v1.1 or v1.4 firmware original running on your Anycubic i3 Mega Ultrabase? The model is shipped in two versions with v1.4 firmware running a 32bit instead of 8bit CPU, so patching the wrong version might brick. @coconuthero I would recommend not trying, but if you did. Let me know if it worked since I know you got v1.4

[electron23]

I've flashed the patch and I've the firmware 1.4 and all works well.

[thetobby]

Flashed the patch, my Anycubic went from v1.4 RC1 to v1.4RC2 and it now works great with octopi with the plugins provided by foosel.

[gregopti]

Thanks @foosel for your support and great cooperation!

For all those who are asking what is this patched version of firmware for, I can corfirm words of @thetobby.

The original firmware that I had was V1.4.1RC1/P5 which is then after uploading patched firmware addressed as V1.4.1RC2/P5

I cannot guarantee that this version will work with other firmware/software combination.

[foosel]

Any official sources for the 1.4.1RC2/P5 firmware that I could link to from a plugin page? Or is it as of yet unreleased and the link in this thread is the only source so far?

[gregopti]

I think they haven't make it official and we only got what they have sent me via email and I posted here.
The only change in firmware is actually in baudrate which was incompatible with RaspberryPi PL2303 drivers. Instead of 250kbit the baudrate is now 115,2kbps.

Therefore if Octoprint is running on some other OS or if we got different debian/linux drivers for PL2303, I'm almost sure this patched firmware won't be needed and original could be used instead.

[thetobby]

@gregopti Since you already have a dialog with Anycubic, can you poke them for some more information related to this? Perhaps they can release the firmware publicly or have some more information/plans

[foosel]

@gregopti I second this suggestion by @thetobby. Additionally - if you think that would help - you can also bring us into contact and I'll try to poke them a bit as well.

[coconuthero]

And after I had setup my raspberry again because I forgot my password it finally also works for me!
Thank you very much foosel!

[thetobby]

This is the source code for old 1.1 hardware not 1.4hardware, but might help? @foosel
https://github.com/ANYCUBIC-3D/I3-MEGA/tree/master/Marlin_TFT_CR_V1.1.1

[foosel]

@thetobby on first look more confusing than helping sadly. They've completely changed the serial communication, thrown out the gcode parser and replaced it with some custom "a codes". Code is riddled with commented out blocks, very hard to read, but it doesn't look like this firmware in this form is related to what we saw in use here (with this one OctoPrint wouldn't have been able to connect at all, let alone print).

Word of caution though just in case anyone is using that firmware: disabled thermal runaway protection according to the bundled config, that is highly disturbing.

[Angeal87]

Hello,
my Anycubic i3 Mega runs Firmware 1.4.0RC23/P3
I use OctoPi 0.14 / OctoPrint 1.3.6 with installed and activated patches/plugins strip_m110_parameter.py and rewrite_wait_to_busy.py
When I start to connect the OctoPi with my i3 Mega the serial.log tells me the following:

2018-02-04 10:07:45,743 - Connecting to: /dev/ttyUSB0
2018-02-04 10:07:45,894 - Changing monitoring state from 'Offline' to 'Opening serial port'
2018-02-04 10:07:45,910 - Connected to: Serial(port='/dev/ttyUSB0', baudrate=250000, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
2018-02-04 10:07:45,914 - Changing monitoring state from 'Opening serial port' to 'Connecting'
2018-02-04 10:07:45,936 - Send: N0 M110*35
2018-02-04 10:07:55,955 - Recv: �������>2���2�����>���>��22������0���< �<���� ���>�� ����>>>2����

And from then nothing....
Any idea so far?

[electron23]

Set the baud to 115000

[Angeal87]

Nearly the same problem

2018-02-04 10:47:33,561 - Connecting to: /dev/ttyUSB0
2018-02-04 10:47:33,731 - Changing monitoring state from 'Offline' to 'Opening serial port'
2018-02-04 10:47:33,738 - Connected to: Serial(port='/dev/ttyUSB0', baudrate=115000, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
2018-02-04 10:47:33,739 - Changing monitoring state from 'Opening serial port' to 'Connecting'
2018-02-04 10:47:33,747 - Send: N0 M110*35
2018-02-04 10:47:43,766 - Recv: ��#��#��+#��/7�+��4��#������#4�#��4�#���,�$�;3#�����

I've also tried different cables and USB ports...

[Commander112]

@Angeal87
You ´ve to update your Printerfirmware with the Update above (Comment from @gregopti)!! You need V1.4.1.RC2/P3

[Angeal87]

No idea how to get the firmware and how to flash it...

[thetobby]

@Angeal87 Just put the file on the root directory of the SD card and reboot the printer. When it is done, delete the file.

[Angeal87]

Thanks for the info how to flash. Works great :-)

[pauledd]

Hi, just got my I3 Mega with firmware: V1.4.0RC24/P3. Its recognized by my linux host as:

[  490.408116] usb 1-1: Manufacturer: Prolific Technology Inc.
[  490.408590] pl2303 1-1:1.0: pl2303 converter detected
[  490.409292] usb 1-1: pl2303 converter now attached to ttyUSB0

Octoprint cannot detect its baudrate.
Can I use the firmware by @gregopti on my printer?

[electron23]

@pauledd Yes, you can

[Angeal87]

I've printed Benchy two times.
Once via SD card and once via OctoPrint.
For both I took the same GCode file (Sliced on the PC with Cura 15.04.6)
I have the impression that the print quality on OctoPrint is not as good as from SD card

Any idea somebody?

[pauledd]

@electron23, thanks, firmware update succeeded. Do I need to set something else beside the common settings for the anycubic i3 mega? Any special commands?

[pauledd]

Okay, my first Test went ... scary. I set the bed dimensions to 210,210,205. Thats all. Loaded model, pressed print,the printer startet heating up the bed. As it reached it (hotend was still unheated) the motors started to move the bed to the middle upper edge, it seemed to start printing half on the bed, half in the air and there was a horrific rattle noise, I guess from that motor that feeds the filament, because the hotend was not heated it of cause resists to move...
Here is the log, I dont understand it but maybe it is helpfull...
https://pastebin.com/MpaERidx

Iam quite sure I will NOT try octoprint again until it is absolutely clear why this happened...
PS, yes my printer was perfectly leveled

[Commander112]

@pauledd
Can you please poste your used Gcode-File to Pastebin?
The "Logfile" unfortunately starts at N668.

• Plugins (listed above) installed on your Raspi?
• Any Start/Stop GCode-Scripts used?

[pauledd]

@Commander112
Sorry, my fault! I'll give it a second try with plugins this time... Do I need any start/stop gcode scripts?

[Commander112]

@pauledd
The two Plugins are needed! Anycubic uses the Commands on her own way ;-)
For better Workflow you need GCode-Script...
Put the following part in your Octoprint GCode-Script for start printing:
G28 X0 Y0
G28 Z0
G1 Z15 F500
M107 ; fan off
G5 ; enable resume from power failure
G92 E0 ; zero E axis
G1 E3 F200 ; prime

And that for after printer:
G1 X0 Y195 F2400 ; position part removal
M106 S0 ; fan off
M104 S0 ; turn off extruder
M140 S0 ; turn off bed
G28 X0 ; home x
M84 ; disable motors
M107 ; turn off print cooling fan
M300 S1500 P100
G4 P100
M300 S1500 P100
G4 P100
M300 S2500 P100
G4 P100
M300 S2500 P1000
G4 P500
M300 S2500 P1000

Behind the Commands (after ;) are Comments for better knowing the usage of the line.

[pauledd]

Thanks for the clarification! So I put it in here?:

[Commander112]

Yes!
Start-Script at "Before print job starts" and the End-Script at "After print job completed"

With the two pyton-Plugins and these Codes my Printer is perfekt ;-)

[pauledd]

Thanks! It works so far, but I am a bit concerned how close to the bed the hotend moves back after the print has finished. Is this normal? I printed this bed level test with one layer rectangles.
https://youtu.be/t95wq5-5vLo

[pauledd]

What I also noticed is that if I cancel a print the printer immediately stops printing where it currentlyis is, but stays there, it does not move away from the hotbed nor goes home... I dont know if this is intended.

[Commander112]

Sorry, at the moment back from a 24h-Shift.

Both is a GCODE-Script Thing. The Code I poste is very small and for Funktion, if you want more you can change the code with Functions you want (Beep, Liftup, Movement).

For Cancel I use the same GCODE-Script I use at End-Script.

[pauledd]

Okay thanks, I will change that. So far octoprint works beautifully with the i3 Mega! :)

[thetobby]

I noticed that using octoprint with the above setups it sometimes sound like it is scraping on last layer when printing on X/Y, but with the same Gcode it is fine if run directly from SD card. Anyone else with similar experience or any ideas?

[jjort]

I cant seem to find the plugins directory when I SSH into Raspberry Pi 3 as directed in the instructions
cd ~/.octoprint/plugins
Is there a way to install this plugin through the web interface?

never mind... I found it and now its working perfect
thanks for all your hard work

[tifrei]

Hi, i have also the firmware : V1.4.0RC24/P3 and my octopi wouldnt connect. i already downloaded the firmware mentioned above but how can i install it? i just need to put it on the sd card and than ?

Thanks for any help and sorry for asking that stupid qeustion.

[pauledd]

@tifrei afair I put the firmware on the root directory of the SDCard and then power on the printer with it. It should start the FW Update.

[kamaleonte]

If I update with the gregopti firmware, it disabled thermal runaway protection ?

[acdapkus]

Printer: Xinkebot Orca2

I was having the same issue as the OP, however it is now fixed. Thank you.

My solution:
I applied the 2 fixes linked above, and was left with one error, also listed above. This error was "Recv: //sd cmd error cnt:16175 len:15 :N7034 G28 X*91" in nature.

To fix this final issue, I also had to turn off "Auto Detect Firmware" and check the "Always assume SD card is present" option. After I did this, the errors disappeared.

If anyone runs into an issue and thinks I can help, let me know. I would be happy to post any logs or settings if requested.

[apos]

[[SOLVED]] The problem occurred uloading generated gcode from Slic3r.

ThenI then gave Cura a try:

• used 115200 Baudrate for connecting (not AUTO), Serialport on AUTO
• added the octoprint plugin.
• altered GCode-script "start" in octoprint: I removed M117 command (which seams to make trouble) and put G5 at the end
• kept everything as described below

I configured Curo on the "remote" PC like advised in the setup instructions of the 3D printer. Astonishing is, that within the gcode settings there is a M117 command.

Now everything works like expected! Thanks a lot.

---

https://github.com/foosel/OctoPrint/issues/2309

Hey,

I applied the alterings to octoprint server (Version 1.3.6) and to my anycubic i3 mega:

• original firmware: V1.4.1RC1/P1
• on my pc connected to the printer installed the above two (!) plugins into ~/.octoprint/plugins ( " @foosel commented on 18 Jan ")
• Installed the GCode-Scripts from above into octoprint ("@Commander112 commented on 10 Feb")
• upgraded the firmware with update.zip/update.zw from "@gregopti commented on 4 Jan" (extract the update.zw into the sdcard root and shutdown/shut-of the printer. while the update is running the printer beeps continuisly - don't interrupt) - now I have Firmware V1.4.1RC2/P2
• I turned off "Auto Detect Firmware" and checked the "Always assume SD card is present" option ("@acdapkus commented 9 days ago ")

But: the printer does not start printing at all. I always get the same error messages - the printerhead does not move at all:

Send: N8 G92 E0*79

Recv: Resend:7

Recv: ok

Send: N7 G1 Z15.0 F{speed_travel}*15

Recv: //last:6 curr:8 rcv:N8 G92 E0*79

Recv: Recv: 3

Recv: //sd cmd error cnt:196139 len:31 :N7 G1 Z15.0 F{speed_travel}*15

Recv:

Recv: ok

Send: N8 G92 E0*79

Recv: Resend:7

Recv: ok

Send: N7 G1 Z15.0 F{speed_travel}*15

Recv: //last:6 curr:8 rcv:N8 G92 E0*79

Cheers
Axel

[sampsakuronen]

I have the same setup and I’m unable to print succesfully. If I can be of help just ask!

1. Installed latest octopi
2. Installed firmware I got from Anycubic: 1.4 RC2
3. Established connection with 115 baud
4. Print ”randomly” stops at some layer. For one file it stops at 5 minutes and for another at 2 hours

One thing to add is that when I’m using the Octoslack plugin the print seems to stop if I query the Slack bot.

[foosel]

@sampsakuronen you also need to install the two plugins.

[sampsakuronen]

Thank you very much! And sorry for not spotting that before 🧐

For the time being it seems that the print is doing ok. Do you get anything if I report to you how it went?

[gaminnick]

I just got an Anycubic and setup OctoPrint. I have had the same issue with not connecting so will follow these direction. I have a question on the GCode changes. OctoPrint has a button that says Upload to SD. I am guessing that uploads the gcode file to the SD card if one is inserted into the printer so I can print from the SD card. If that is the case do I still need the GCode changes? I would always prefer to print from the SD card. Thanks!!

[foosel]

It sadly looks like this broken firmware is now making the rounds in China. I got reports looking identical to the issues reported here for

• Xinkebot Orca 2 Cygnus, firmware version 1.3.17 (see #2724)
• Qidi Tech X-One2, firmware version V1.4.0RC10m4 (see this forum post)

So instead of this getting fixed vendor side, it's now spreading. Wonderful.

---

For anyone just tuning in now, here's the comment with the two minimal plugins that might help get this abomination of a firmware to work with OctoPrint, incl install instructions. Please report back with printer model and serial.log of a connect if that is indeed the case, so that I might be able to find a way to auto detect this mess and work around it in stock OctoPrint or at least prompt the user to install a plugin.

[foosel]

@gaminnick sorry, I just now saw your question.

If that is the case do I still need the GCode changes?

Yes. The firmware is that much broken that a normal communication isn't possible even if all you want to do is print from SD through OctoPrint.

[pauledd]

Hi, me again. Sorry but I have to ask again just to be clear about that GCODE settings. So the settings from here https://github.com/foosel/OctoPrint/issues/2309#issuecomment-364633873 are mandatory? But what happens if I already had some Start/End-GCode set IN CURA and I then print the gcode file in octoprint? Is that start/end code (from CURA) ignored in octoprint? I ask because I usually had this start code in cura:
G1 F200 E12
which extrudes some filament at the beginning. But octoprint seems to ignore that command from cura completely.

[pauledd]

Sorry, I printed the wrong file. My extrusion command set in cura actually gets executed in octoprint...

[nocem]

I really enjoyed this discussion. Mostly because I had the same Problem. Thanks foosel 👍👏

[BrewChef]

Have the same problem on my AnyCubic Predator. The Predator does not run Marlin but Chitu (Chinese Marlin) - I would guess several other of these printers does the same perhaps?

[nocem]

Yeaterday I tried to do an PID autotune and recognized that the Printer still sends these damn wait responses. It Looks like the rewrite Plugin didn‘t work for me. Has something changed in comparison to older versions of octoprint?

[foosel]

@nocem nothing has changed.

Note however that the plugin will not change what is received from printer before it is being logged, but only after. The log always shows what goes on between printer and OctoPrint, unmodified (this is intentional since the goal of the log is to log the communication, not the interpretation of the communication). So just seeing the wait there doesn't mean that the workaround stopped working. Does something actually not work or is it just the messages that threw you off?

[nocem]

Ok. It was kinda my fault. Chitu`s autotune needs the E0 parameter in order to work. I left it out because I assumed it whould choose E0 if nothing is specified (like marlin does).

[grumpypuppygames]

Had same problem with a Tronxy XY-2 Pro. Plugins worked like a charm.

[Zolarayze]

In case anyone has a problem with communication being stuck and a line being send over and over (after installing the 2 scripts and after updating the firmware): check your starting .gcode that you set in Cura (for example).

Alright so it seems like the problem was my starting .gcode that I set in Cura.
Figured this out by receiving a different .gcode file that someone send me.
There were 2 commands on a single line.
I also changed Z endpoint to a new line.

G28 X0 Y0 Z0 ;move X/Y to min endstops
to
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops

and

G0 Z0.15 G92 E0 ;zero the extruded length
to
G0 Z0.15 ;Drop to bed
G92 E0 ;zero the extruded length

So if anyone else has this problem, check if there are multiple commands on the same line.

[GitIssueBot]

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/octoprint-errors-at-end-of-job/16147/6

[GitIssueBot]

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/communication-error/16160/2

[GitIssueBot]

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/qidi-x-pro-tool-0-target-reverts-to-60-degrees-though-actual-is-fine/16400/4

[jangxx]

Quick tip for other Anycubic i3 Mega users: I've been using this firmware (https://www.thingiverse.com/thing:3249319) very successfully with Octoprint for several months now. If you have problems, try flashing this firmware, it might just solve them.

[GitIssueBot]

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/tronxy-x5sa-pro-connects-but-skips-gcode/17446/4

[foosel]

There's now a plugin on the repository that consolidates the two plugins mentioned here: https://plugins.octoprint.org/plugins/fixcbdfirmware/. OctoPrint 1.4.1 will also detect affected firmwares and pop up a warning to install the plugin for the printer to work properly.

There's also now a dedicated FAQ entry for this broken firmware strain here: https://faq.octoprint.org/warning-firmware-broken-cbd

Closing.