New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AnyCubic i3 Mega - non standard responses #2309

Open
gregopti opened this Issue Dec 21, 2017 · 68 comments

Comments

@gregopti
Copy link

gregopti commented Dec 21, 2017

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

This comment has been minimized.

Copy link
Collaborator

GitIssueBot commented Dec 21, 2017

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

This comment has been minimized.

Copy link

crckmc commented Dec 31, 2017

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

@electron23

This comment has been minimized.

Copy link

electron23 commented Jan 2, 2018

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

This comment has been minimized.

Copy link

gregopti commented Jan 4, 2018

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 comment has been minimized.

Copy link
Owner

foosel commented Jan 11, 2018

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

This comment has been minimized.

Copy link

gregopti commented Jan 11, 2018

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

This comment has been minimized.

Copy link
Owner

foosel commented Jan 11, 2018

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

This comment has been minimized.

Copy link

gregopti commented Jan 11, 2018

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

This comment has been minimized.

Copy link
Owner

foosel commented Jan 11, 2018

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

This comment has been minimized.

Copy link

SchizoDuckie commented Jan 11, 2018

@gregopti

This comment has been minimized.

Copy link

gregopti commented Jan 12, 2018

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

This comment has been minimized.

Copy link
Owner

foosel commented Jan 12, 2018

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

This comment has been minimized.

Copy link

crckmc commented Jan 12, 2018

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

This comment has been minimized.

Copy link

gregopti commented Jan 12, 2018

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

This comment has been minimized.

Copy link
Owner

foosel commented Jan 12, 2018

@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

This comment has been minimized.

Copy link

gregopti commented Jan 16, 2018

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

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

This comment has been minimized.

Copy link

Commander112 commented Jan 16, 2018

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

This comment has been minimized.

Copy link
Owner

foosel commented Jan 16, 2018

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

This comment has been minimized.

Copy link

electron23 commented Jan 16, 2018

Can you explain the exact steps please.

@coconuthero

This comment has been minimized.

Copy link

coconuthero commented Jan 17, 2018

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

This comment has been minimized.

Copy link
Owner

foosel commented Jan 18, 2018

@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.

@pauledd

This comment has been minimized.

Copy link

pauledd commented Feb 6, 2018

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

This comment has been minimized.

Copy link

electron23 commented Feb 6, 2018

@pauledd Yes, you can

@Angeal87

This comment has been minimized.

Copy link

Angeal87 commented Feb 6, 2018

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

This comment has been minimized.

Copy link

pauledd commented Feb 8, 2018

@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

This comment has been minimized.

Copy link

pauledd commented Feb 9, 2018

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

This comment has been minimized.

Copy link

Commander112 commented Feb 9, 2018

@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

This comment has been minimized.

Copy link

pauledd commented Feb 10, 2018

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

@Commander112

This comment has been minimized.

Copy link

Commander112 commented Feb 10, 2018

@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

This comment has been minimized.

Copy link

pauledd commented Feb 10, 2018

Thanks for the clarification! So I put it in here?:
bildschirmfoto_2018-02-10_08-55-45

@Commander112

This comment has been minimized.

Copy link

Commander112 commented Feb 10, 2018

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

This comment has been minimized.

Copy link

pauledd commented Feb 10, 2018

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

This comment has been minimized.

Copy link

pauledd commented Feb 11, 2018

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

This comment has been minimized.

Copy link

Commander112 commented Feb 11, 2018

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

This comment has been minimized.

Copy link

pauledd commented Feb 11, 2018

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

@thetobby

This comment has been minimized.

Copy link

thetobby commented Feb 15, 2018

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

This comment has been minimized.

Copy link

jjort commented Feb 27, 2018

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

This comment has been minimized.

Copy link

tifrei commented Mar 10, 2018

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

This comment has been minimized.

Copy link

pauledd commented Mar 11, 2018

@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

This comment has been minimized.

Copy link

kamaleonte commented Mar 11, 2018

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

@acdapkus

This comment has been minimized.

Copy link

acdapkus commented Mar 22, 2018

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

This comment has been minimized.

Copy link

apos commented Mar 31, 2018

[[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.


#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

This comment has been minimized.

Copy link

sampsakuronen commented Apr 10, 2018

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

This comment has been minimized.

Copy link
Owner

foosel commented Apr 10, 2018

@sampsakuronen you also need to install the two plugins.

@sampsakuronen

This comment has been minimized.

Copy link

sampsakuronen commented Apr 10, 2018

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

This comment has been minimized.

Copy link

gaminnick commented Apr 20, 2018

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

This comment has been minimized.

Copy link
Owner

foosel commented Jul 16, 2018

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

This comment has been minimized.

Copy link
Owner

foosel commented Jul 16, 2018

@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

This comment has been minimized.

Copy link

pauledd commented Oct 23, 2018

Hi, me again. Sorry but I have to ask again just to be clear about that GCODE settings. So the settings from here #2309 (comment) 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

This comment has been minimized.

Copy link

pauledd commented Oct 23, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment