Marlin 1.1.x with original Anycubic i3 Mega display support

Anycubic_I3_Mega Firmware Marlin TFT_Screen

Please Login to Comment

Comment has been deleted

Here is a preliminary main topic, because the main article was deleted.

Link to the git... right now its based Marlin 1.1.9 (branch 1.1.x) or bugfix-1.1.x (branch bugfix-1.1.x):

Additional features:

  • Subdirectory support ... you have to press the round arrow after selecting a directory
  • Special menu in the SD file menu ... you have to press the round arrow after selecting a special menu item

Changed features:

  • Leveling uses auto bed levelling... you can can check the positions afterwards

Missing features:

  • Outage support
  • Beeper
  • Testprint after leveling

Things to mention:

  • FAN0 gives full 12V on M106 255


if the newest firmware based on 1.1.9 why some files have different variables.

In stepper.h for example 1.1.9 uses:
static int32_t delta_error[NUM_AXIS];
static uint32_t advance_dividend[NUM_AXIS],

In your custom firmware it is:
static int32_t delta_error[XYZE];
static uint32_t advance_dividend[XYZE],

I also discovered that in some files the original 1.1.9 uses typedef union and in your files not. Am I wrong?

I just did a compare on GitHub and there are none of those differences.

The bugfix branch lag behind, as it does require a significant amount of work to keep it in sync.


I wanted to try your firmware on my 03 model, but since I'm pretty new to Arduino development, I'm running into some issues when compiling. I'm using the ultrabase example Configuration.h with Arduino IDE v. 1.8.8

First error was the MOTHERBOARD BOARD_TRIGORILLA being unkown (Then I tried using BOARD_TRIGORILLA_14 instead. I'm not completely sure that is correct)

Second error is with the Configuration.h version being old. Any hints on how to fix this?

Do u have the 32bit board , sounds like it ?


I have the 8-bit board and version 03 of the printer. I took the bottom off to see if I could replace the drivers with TMC2208, which will be my next project. Right now I just need to setup my Arduino build environment properly to be able to compile Derhopp's firmware version.

Your setup should look like this:

Comment has been deleted

Your Firmware is working perfectly on my I3 MEGA but I have one question:

Do I need to change something in the configuration.h to get my TMC2208 working
or will they just work with the default settings?

If you are using the TMC2208 in standalone mode, it not really required to change anything. But I would recommend, to set the TMC2208_STANDALONE setting for the specific stepper. Just search for X_DRIVER_TYPE in Configuration.h.

Thank you! Installed them today and worked flawlessly without changing anything in the FW :)

2018-10-30: Branch Bugfix-1.1.x has been updated to recent upstream Marlin.

Hello derhopp and thanks for sharing this!! I just updated my printer because I wanted to try using linear advance to help me get rid of some problems, it actually solved them but now the thing is that my prints are taking way longer to print compared to the estimated time of cura (before update it took exactly that time, every single time) I just want to know if that is normal or if maybe I have a problem with my settings.

Thanks in advance, Juan

Comment has been deleted

Hi, Marlin 1.1.9 has just been released.

Could you update your release to 1.1.9?


My git is now on 1.1.9.

Comment has been deleted

I am on it. But anyways pull request are always welcome. (:

hello, wainting for it hehhe. good work

FYI, I investigated the problems I had with the bltouch clone : I made it work with your 1.1.8 bugfix branch.
This morning I tried 1.1.9, still probing failed. Then I found that I'm not alone and 1.1.9 seems to be more sensitive to noise.
Enabling ENDSTOP_NOISE_FILTER does the trick but I need to add a 100nF capacitor to filter that noise...

Marlin developpers tend to exhort people to switch to 32 bits boards.
BTW I'm going to test klipper on the i3 Mega and report my results :)

Hello Derhopp,
Been using your firmware fork for couple months with bltouch and it's been wonderful! Very nice to not manually level the bed, probably the best change I've made to the i3 Mega.

Curious if it's possible to add support to display M117 command on the TFT display? I use OctoPrint and it would be very handy to show status messages, ie progress, on the display.

Thanks and appreciate your work on this project!

Unfortunately it is not possible to display any additional text or message. Neither it is possible to include dual extruder / hotend support... so I hardly use the display anymore. ):

My suggestion is to attach a display to the RPi you are running OctoPI on. There is an add-on/skin for touch display use.

That's too bad. Was hoping to be able to use the status area of the TFT that shows heating and other info. Not too keen on running a GUI on the Pi for this info. Would like to leave it headless and only processing OctoPi tasks. Looks like it's possible to send the OctoPi status via MQTT to a tablet, might go that route. Thanks!

Short question.
I don't get the D11 and D12 (Servo Pins) into PWM.
D4, D5, D6 are fine but D11 and D12 could not be changed.
S255 switching them on but less than S255 is OFF.

Any hint for me?

Using D4 for Laser, and D5, D6 and D11 for RGB-LEDS, which should have mixable colors while changing the S values.
Please advise


thank you very much for posting this. I downloaded it, adapted it to my anycubic i3 mega ultrabase and started using it. It worked fine until yesterday when I made a 6h print from sd-card which stopped midprint after ~3,5h. I had no error messages on the display but maybe there was one which disappeared automatically. The machine seemed to work fine, manual controls worked. I have no idea what happened. Is there any way to get a log while printing or something else to debug?

Also, do you know if there is a repository with the original sources for the i3 mega available anywhere?

Update: Got this link from anycubic: https://github.com/ANYCUBIC-3D

That just sounds like your .gcode was faulty, i hope you don´t use the SD card that came with the printer...

I used the ooriginal card with the original firmware, had no issues with it. For some reason the old card isn't recognized by this firmware, so I used a 8GB card which I had. It is FAT32 formatted. Are there any restrictions on the naming of the files or the file size? This gcode file is about 14MByte large. Other prints worked without problems from this card.

It´s just typical that mid print fails are usually errors in the .gcode files due to bad sd cards or other errors, i would get a other card and
try again...

That would mean when I try to read the code from the card with a PC I see a corrupted file or isn't that necessary the case?

No the pc would tell u that he found some errors on the card, but your slicer should show if the .gcode is corrupted...

I can read the gcode file from the card with cura with no problems.

If windows didn´t notice anything i must say i´m clueless...

I updated your fork to 1.1.x-bugfix due to the numerous important bug fixes (broken reverse planner leading to bleeding edges, new Linear Advance 1.5 etc.).

I wouldn't mind if you take it and update your own repo, I basically just applied your modifications and fixed 1 compile error by including printcounter.h to some AnycubicTFT.cpp file.

For anyone who wants it, it is avalable here: https://github.com/Beaving/Marlin-Anycubic-i3-Mega-Ultrabase-TFT-Support-Bugfix-branch


Maybe a question allready asked...but i could not find it.

I wanted to upgrade my anycubic i3 Mega with the newest firmware. I tried to flash it using Cura (version 15.04 and 3.3 beta) but halfway the upgrade i get an error message that it failed to upgrade. This messages appears on Cura, i dont see anything happening on the lcd screen.
Is there something i am missing ?

The branch bugfix-1.1.x should be in sync with the upstream repo. Just give it a shot.

So does your link here have Linear advance then? So I could use the M900 K command with it?

Hoping to print with linear advance and see what kind of speeds I can get.

Derhopp‘s version has linear advance, too. My updated version has Linear Advance 1.5, it is working better with Bowden setups, but thats it.

Beaving & Derhopps, do you mind if you could share an .HEX file for us that are not too savvy to flash via Octoprint?
I would like to try some of the new features like linear advance.

Thank you!

Wow, are people REALLY that lazy today?

I would never expect a SILLY comment like this @ Thingiverse.

I mentioned I don't know how to compile, I would like to flash it over my Octoprint, so I kindly asked for it.

The versa of your reply is that I was contacted via private message 2 hours ago with the opposite, someone sharing an already compiled file.

Thanks @petrzmax, you-know-it-all...

Glad someone gave you a compiled hex file. But in the future, if you want to make changes for yourself:

  • Download Arduino IDE
  • Download the version of Marlin you want to play with
    -Open the Marlin.INO file, then Arduino IDE should open up with all the files loaded as tabs.
    -Configure which ever value you want in the tabs (usually just configuration.h)
    -When you're ready to compile: Sketch > Export compiled Binary
  • You will get a few files. Two of the files will be Hex files. Disregard the *bootloader.hex

You may have issues finding the hex file, if so it will be somewhere in a temp directory. If you dont like this, you can modify where Arduino will save its compiled files by following these directions: https://www.kanda.com/blog/microcontrollers/avr-microcontrollers/find-arduino-hex-files-output-binaries/

Thank you very much @jaywuzhere,
I will definitely do it, knowledge is never too much.
Your's was a Thingiverse comment ;)

Glad I could help. Good luck and have fun!

Any chance you would have some gcode for that?

I pulled this from an MK2S S3D profile - would it work with the i3 mega if flashed with one of those firmware?

M900 K32 ; k value

{REPLACE "; outer perimeter\n" "; outer perimeter\nM204 S800\n"}
{REPLACE "; inner perimeter\n" "; inner perimeter\nM204 S800\n"}
{REPLACE "; solid layer\n" "; solid layer\nM204 S1000\n"}
{REPLACE "; infill\n" "; infill\nM204 S2000\n"}

Also, what speeds do you usually do for linear advance on the i3 Mega?

Sorry for the questions, just super excited to try this.

I don‘t use LA since I have only had bad experience with it, especially on Bowden setups like i3 Mega, unusable results. M900 gcode works on all Marlin versions if the code is not bugged.

I can add it. Could make a push request against my git, then its quite easy to put in.

Well, best would be to add it properly to the official Marlin repo :P. I thought about it, any reason you just copied the RAMPS board, did the necessary changes and not just include the RAMPS board in your Trigorilla.h and override the needed values? But I guess they wouldn't like the "custom" filament runout definitions and some other stuff either because they want to keep it as generic as possible.

The code it too specialised on the Anycubic Mega i3. Marlin is more a generic firmware.

I found this video today: https://www.youtube.com/watch?v=zVJC_jGTYwQ

Assisted auto leveling on display looks nice. Author of the video link this repository in comments: https://github.com/ANYCUBIC-3D/I3-MEGA

Maybe some code from it can help.

I tried uploading the sketch using ArduinoIDE and the LCD remained the same along with version 1.1.0 in the info section :(

That's because the LCD screens aren't updated. If you connect with octoprint, you'll see you have marlin 1.1.8.

That explains a lot actually hahaha since the unit wouldn't beep and the log says that the beep doesn't work yet in the build. I'm really interested to find out how the guy in the video altered the LCD menu https://www.youtube.com/watch?v=zVJC_jGTYwQ Anyone have any ideas?


First of all: Thanks a lot for awesome piece of work. Now this great printer can be moded freely and become one of the best for it's price.
I have a request for You. I'm using a TMC2208 drivers in my printer and I wantet to connect them to a mainboard, so they can cooperate with Marlin. But when I turn TMC2208 support in config files it won't compile. If I understood right pins for connecting TMC drivers to Trigorilla board aren't defined in the code. I'm really not into Marlin build so it can be prettty hard for me to do it. If You will have time, You should consider defining them because it is a really small thing that would make this printer a lot better.

Best regards from Poland

Hi there,
as far as i know you don't have to change the TMC2208 support in the config files. In my printer they work just fine with the standard configuration!

Greeting from Germany!


Yes You are right they are working fine but if You would like to make them inteligent (reduce current when motors are just holding position, or control the current from Gcode) You need to conenct them into others pins on the motherboard :)

you can use TMC2208_STANDALONE in configuration.h but then again, they will be in dummy mode. So the choice is either soldering iron galore or being stuck with default stealthchop ....which wouldn't be too bad ....if the drivers were running in 24v... but no, they are in 12v

I ahve figured it out a long time ago. They are working in smart mode ;)

Newest Update:
2018-02-01: Added pull request by bartolomeus with a proper configuration for the ultrabase version. Check it out in the example_configurations directory.


Have just purchased a Anycubic i3 Mega, the latest version with ultra base and dual Z stops. I also run an A8 with Marlin and was wondering how safe it is to install Marlin on the Anycubic? Does it support the touch screen? Any resources on how to install via Arduino software and what settings to use? Also does Marlin support all versions of the motherboard Anycubic are using, I think newer machines have a 32bit version now, not sure what one I have and indeed how to check.

Many Thanks

Check what you have first. I believe that if you navigate to the info screen on the TFT display, it tells you which version you have. If I am correct V1.1 = 8 bit Marlin and V1.4 is 32 bit 'something' firmware. You can also check by opening the case at the bottom and inspecting the motherboard. If you have replaceable drivers, it's probably 8 bit Marlin. Intregraded stepper drivers = 32 bit. I say probably bacuase you never know what they change.....

If you have the 8 bit board, it's perfectly safe to install this version. Just go through the config files and adapt to your need. One thing to be aware of is the max temp for the hotend. The current setting it's too high for the stock hot end.

Touch screen becomes more responsive and you have access to all the features of Marlin (12v output to part cooling fan, ABL, PID, Lin-Advance....).

Thanks very much. I have version 1.1.0 installed.

What settings do I use in Arduino software for connecting regards board type. Any useful info somewhere on the flashing process specifically to Anycubic? I have done the A8 already so partly familiar with the process. Its a work machine so don't want to bugger it up by getting it wrong. Is it possible to go back to stock from Marlin ?

Will I loose any features by moving to Marlin. I didn't think the code for the touch screen had been released and we were not able to use it.

All you have to do is:

  • in Arduino select Amtega2560 as board type
  • go through the configuration.h and adjust some settings (disabling all probe stuff as I presume you do not a have a z probe). At this point that file is still configured towards a V1 Mega which has a z probe.

After you upload the firmware to the printer, first verify all axis movements via the menu with the smallest steps. Then check homing all axis individually. For the z axis test homing by pressing the switches yourself, if they dont work you can turn off the printer in time. These are all precations, when I flashed for the first time, evertything worked as expected.

Hello derhopp and bartolomeus,

First off: Thank you for the amazing work, I will be installing it next week and report back :)
It would be fair if we could contribute with donations or help in any other way.

I am not sure if this helps in bugfixing or with the planned missing features but anycubic just officially released their marlin firmware (still 1.1.0 though...) in uncompiled form to github: https://github.com/ANYCUBIC-3D/I3-MEGA

Grüße! ;)

I'm sorry for annoying another time but I'm still a bit confused.
At the moment it doesn't make a difference whether I make an 'Auto-Bed-Leveling' or not.

What I'm doing:
1) G28; homing all axis
2) manual bed-leveling in the corners
3) G28; homing all axis
4) G29: Auto-Bed-Leveling
Bilinear Leveling Grid:
0 1 2
0 +0.795 +0.795 +0.980
1 +0.748 +0.807 +1.015
2 +0.620 +0.740 +1.000
X:188.00 Y:209.00 Z:9.00 E:0.00 Count X:15040 Y:16720 Z:4000ok

Ok...so far so good
5) misplace the bed (tighten the screws in the back corners)
6) G28; homing all axis
7) G29; Auto-Bed-Leveling
Bilinear Leveling Grid:
0 1 2
0 +1.020 +0.880 +0.927
1 +0.655 +0.578 +0.602
2 +0.217 +0.155 +0.217

So there is a significant deviation

BUT! it does not take an effect during printing. Could it be that the leveling results are not stored in the eeprom? Do I make any mistake?

Thank's in advance

You have to "save" the ABL data...
and you have to "apply" the ABL data...(always after restart... best to put it in you default print script)
M420 S1

I've got the next problem...shame on me

The ABL itself is working well. I'm homing all axis via "G28", starting ABL via "G29" at next and set the new values via and "M420 S1". Now I go to 'new z null' via "G1 Z0" and there is still a (too large) gap between nozzle and bed. The 'G28 z null' nozzle high is a paper thickness above the bed, so the 'new z null' is definitely the 'ABL z null' or 'new z null'.

All right...so far so good.
Then I wanted to figure out the nozzle to probe-trigger-point offset by resetting the z high from 0 to 10 by "G92 Z10" and go down step-by-step via "G91" and "G1 Z-0.1"....nothing happen.
I can read out the new z high via "M114" but I can't go any lower.
It seems that "G92.." doesn't take an effect.

So I've tried another way. I undefined the "#define MIN_SOFTWARE_ENDSTOP_Z" (Configuration.h ~l.810), repeat the steps "G28, G29, G1 Z0, G92 Z10, G1 Z9.8, ..." to figure out the offset (it's 0.8). Then I edit the offset via "#define Z_PROBE_OFFSET_FROM_EXTRUDER -0.8" and definied the MIN_SOFTWARE_ENDSTOP_Z again.
No success!! :-(

So at the moment the probe is triggering between Z0.1 and Z0.2 but it's still 0.8 to 0.9 away from the bed and I'm not able to go lower.

I'm sure some of you have some great ideas! ;-)

You can tune the z probe distance with M851 Znnn

I've got the next problem shame-on-me

The ABL works and it also adjust the z-high due to the measured points.
Now I want to adjust the diffence between the nozzle and the probe-trigger point in the way like Thomas Salander did it.

After ABL I'm going to Z0 via G1 and there is a too large gap between nozzle and bed. The problem is that I can't go lower as the current position even with a manual offset via G92. In the "abl protocoll.txt' I copied the g-code command history. The "G1 Z-0.1 F300" doen't take an effect.

So I've tried to compensate the difference by manual figuring out the probe/nozzle distance and setting it via FW (Configuration.h ~l.690)
"#define Z_PROBE_OFFSET_FROM_EXTRUDER -1.2 // Z offset: -below +above [the nozzle]"
But this doesn't take an effect as well.

I've also read that I've to undefine the MIN_SOFTWARE_ENDSTOPS but it can't be the right way?!

Hi Christian,

it works. Thank you very much for your help and effort.

I've just uploaded the latest version of 'your' Marlin and at first of all...great job! Thank you!

But there is an issue with the z-endstop and I can't figure out what is wrong.
The x and y endstops work perfectly. When I'm moving the axis and push the switch manually the axis will stop immediately. Obviously 'homing' x and y works as well.
But there is something worng with the z axis. When I'm moving down towards the endstop even by homing or gcode (e.g. G1 Z-20) and activating the z-switch there is nothing happen. And it doesn't matter whether I'm pushing the switch or activate the probe with a piece of metal.
So the only possibility to stop the z-axis is killing the entire printer.

What I've done:

  • checked all connections
  • flashed an old firmware version (the endstops are working)
  • M43: Pin report and debug
  • M119: get endstop status

Reporting endstop status
z2_min: open
z_probe: open

Reporting endstop status
x_min: open
y_min: open
z2_min: open
z_probe: TRIGGERED

Reporting endstop status
x_min: open
y_min: open
z_probe: open

I hope you have an idea what is going wrong.

Start by undefining these:
"#define X_PROBE_OFFSET_FROM_EXTRUDER -7 // X offset: -left +right [of the nozzle]"
"#define Y_PROBE_OFFSET_FROM_EXTRUDER -24 // Y offset: -front +behind [the nozzle]"
"#define Z_PROBE_OFFSET_FROM_EXTRUDER 0 // Z offset: -below +above [the nozzle]"

I am not sure if all these are necessary but it works for me.

Hi bartolomeus thank you for your effort.
I've tried it but on the one hand it does not fix the issue and on the other hand it disable the auto-bed-leveling function which is the main reason for this update.

I think I could exclude a hardware issue because the software is recognizing any switching event (as well by the probe as by the limit switch).
What I'm wondering about why the M119 is listening the "z2_min" and not the "z_min". Could that be the reason?
Does anybody know in which code segment the software is recognizing an switching event and instruct the stepper to stop?

Which probe are you using for auto levelling? Do you have the i3 Mega or the i3 Mega Ultrabase?
I was assuming you had the Mega Ultrabase....

I'm using the first(?) gen with the original endstop switches and probe. Not the Ultrabase.

Comment has been deleted

oh crap, sorry for that. Then disregard the changes I posted.
There was a change introduced in configuration_adv.h to enable dual endstops on the z axis. I think you should start by disabling it for the V1.

Undefine this line:

Oh WOW!! :D
You are absolutly right! I've now disabled the dual endstops (configuration_adv.h) like you said and it works!

I always thought that I definitely need this part because I use one endstop for both z-steppers. But in which case do I need this part?

Thank you very much bartolomeus!!! ;-)
PS Auto-Bed-Leveling works as well.

You can thank Christian for his effort in making this available to us.
The dual z endstops were introduced to automatically level the x-axis.

Correct... I made the change in the git, to reflect the most common V2s. For V1 you have to disable it.

Thank you for your work!
It's good to see that someone keeps the firmware for the i3 mega up to date!
Keep up the good work!

Is anyone else getting occasional crashes at the first 5 mins of a print? It just stops printing, when I watch communication via USB it says Firmware unresponsive. I have only Re-Flashed the firmware Via Arduino and calibrated the PID. Are there any other libraries or special procedures I have missed? Should I not include the G5 command?

*Stock I3 Mega Ver. 2


I haven't seen this behaviour before. Make sure that you usb cable is okay, because a usb reconnect forces a reset in marlin. Did it stop during SD card or usb print?

I haven't tested bezier curve support but it do not expect any i3 mega related problem, as long as it doesn't take too much RAM, stack or CPU time.

If you can compile, flash the firmware and bring up the software you have all libraries.

I disconnected the USB prior to print and am printing via the SD card. Although I did not change any of the config_h settings within the build and didn't un comment the Z probe things. I will give that a try.

Okay ... you can't use G5 as bezier support is disabled by default. Never connect usb during a print (either connect it before or after)... the print is lost in that case.

Having the probe stuff enabled should not affect stability. My i3 Mega has a z probe connected and it runs perfectly.

Did you adapt the firmware to the V2 mega? I believe now the two z endstop are defined by default, but you still have to uncomment all z probe related stuff. Unless you are using a z probe oc.

The difference between V2 and V1 is the additional z endstop (Z_DUAL_ENDSTOP in Configurations_adv.h) and the missing z probe (AUTO_BED_LEVELING_BILINEAR in Configuration.h).

@HighWattage Are you using the firmware that derhopp has ported? If not, please keep this on topic, i.e. related to this specific (custom) firmware and not for printer troubleshooting in general. You're very welcome to join the Anycubic support group on Facebook ;)

Yes of course I am using the ported firmware for the Anycubic, otherwise I wouldn't have posted here. I am using 1.1.8 from the link above.

for which printer (exactly) is this software?
Can I use this firmware for anycubic i3 mega ultrabase?
do I have to change something?

The firmware should work for V2 (the one with ultrabase) out of the box.

You should disable AUTO_BED_LEVELING_BILINEAR because it doesn't make sense for a V2 as you don't have a sensor for it.

You can make a sensor for it, by allocating pin2 to the probe for BLTouch.

I've tried this, and it works. However, although g29 i get a full 5 x 5 grid of points on the ultrabase showing it's non-uniform, and the dual endstops are both working, when I start a print, it's not applying the z axis probe measurements to account for the non-linear base. Any idea why this might be? I've attached my start gcode for your reference. Some is redundant, but I added it to ensure that ABL would be enabled....



G1 Z15 F1000; lift the z 15 mm
G28; Home all 3 axis
G29; run auto level
M500; save autobedlevelling
M420 S1; Enable bed levelling
M190 S[bed_temperature]; set bed temp and wait for it to come up
G21 ; [mm] mode
G90 ; absolute mode
G1 Y15 X15 F3000; move to a safe spot
G92 E0; reset the extruder
M109 S[extruder_temperature]; set hot end temp to first layer temp
G1 Z0.1 F300; Lower nozzle
G1 E8 F150; Prime extruder 8mm
G1 E-1 F3000; retract extruder 1mm
G92 E0;
G1 Z2 F300; Lift nozzle start printing
M420 S1

Data output from G29
Recv: Bilinear Leveling Grid:
Recv: 0 1 2 3 4
Recv: 0 -0.010 -0.012 -0.012 -0.012 -0.012
Recv: 1 -0.015 -0.012 -0.015 -0.015 -0.017
Recv: 2 -0.017 -0.017 -0.020 -0.020 -0.020
Recv: 3 -0.017 -0.020 -0.022 -0.025 -0.042
Recv: 4 -0.017 -0.017 -0.012 -0.017 -0.020
Recv: X:203.00 Y:219.00 Z:10.02 E:-5.00 Count X:16240 Y:17520 Z:4000
Recv: ok

Data output from a M503 to read the romdata
Recv: echo: G21 ; Units in mm
Recv: echo:Filament settings: Disabled
Recv: echo: M200 D1.75
Recv: echo: M200 D0
Recv: echo:Steps per unit:
Recv: echo: M92 X80.00 Y80.00 Z400.00 E92.60
Recv: echo:Maximum feedrates (units/s):
Recv: echo: M203 X500.00 Y500.00 Z6.00 E60.00
Recv: echo:Maximum Acceleration (units/s2):
Recv: echo: M201 X3000 Y3000 Z60 E10000
Recv: echo:Acceleration (units/s2): P R T
Recv: echo: M204 P1000.00 R2000.00 T3000.00
Recv: echo:Advanced: S T B X Z E
Recv: echo: M205 S0.00 T0.00 B20000 X10.00 Y10.00 Z0.30 E5.00
Recv: echo:Home offset:
Recv: echo: M206 X0.00 Y0.00 Z0.00
Recv: echo:Auto Bed Leveling:
Recv: echo: M420 S1 Z0.00
Recv: echo: G29 W I1 J1 Z-0.01000
Recv: echo: G29 W I2 J1 Z-0.01250
Recv: echo: G29 W I3 J1 Z-0.01250
Recv: echo: G29 W I4 J1 Z-0.01250
Recv: echo: G29 W I5 J1 Z-0.01250
Recv: echo: G29 W I1 J2 Z-0.01500
Recv: echo: G29 W I2 J2 Z-0.01250
Recv: echo: G29 W I3 J2 Z-0.01500
Recv: echo: G29 W I4 J2 Z-0.01500
Recv: echo: G29 W I5 J2 Z-0.01750
Recv: echo: G29 W I1 J3 Z-0.01750
Recv: echo: G29 W I2 J3 Z-0.01750
Recv: echo: G29 W I3 J3 Z-0.02000
Recv: echo: G29 W I4 J3 Z-0.02000
Recv: echo: G29 W I5 J3 Z-0.02000
Recv: echo: G29 W I1 J4 Z-0.01750
Recv: echo: G29 W I2 J4 Z-0.02000
Recv: echo: G29 W I3 J4 Z-0.02250
Recv: echo: G29 W I4 J4 Z-0.02500
Recv: echo: G29 W I5 J4 Z-0.04250
Recv: echo: G29 W I1 J5 Z-0.01750
Recv: echo: G29 W I2 J5 Z-0.01750
Recv: echo: G29 W I3 J5 Z-0.01250
Recv: echo: G29 W I4 J5 Z-0.01750
Recv: echo: G29 W I5 J5 Z-0.02000
Recv: echo:Endstop adjustment:
Recv: echo: M666 Z0.00
Recv: echo:PID settings:
Recv: echo: M301 P17.34 I1.24 D60.73
Recv: echo:Z-Probe Offset (mm):
Recv: echo: M851 Z0.20
Recv: echo:Linear Advance:
Recv: echo: M900 K0.00
Recv: ok

Updates 2018-01-16

  • Bugfix: Don't leave fans running on stop
  • Dual-Z-Endstop enabled by default in Configuration_adv.h

Updates 2018-01-17

  • Updated to most recent upstream stable Marlin

got the Mega V1 with only one Z-endstop.
But the software is acting like I have 2 Z end stops, any idea?
The right stepper stops on triggering the endstop, but the left one keeps turning, til it hits the block
As far as I can judge, the is no #DEFINE Z_DUAL__ENDSTOP enabled, at least, I did not find one.
Any hints are welcome.


you have to look for #define Z_DUAL_ENDSTOPS in Configuration_adv.h and comment it out. I have enabled it in the latest git push, because most users have a V2 or a V1 with dual endstops nowadays (as well as me).

I checked the GitHub again and now it is enabled, the version I got from the hub, was disabled, very strange, sorry for bothering.

Comment has been deleted

You have to enable #define Z_DUAL_STEPPER_DRIVERS ... otherwise one of you Z-steppers won't move. The i3 Mega uses the E1 stepper driver for the second Z axis.

Somehow the OP with all the details has been deleted, so here's the link to github: https://github.com/derhopp/Marlin-with-Anycubic-i3-Mega-TFT/tree/1.1.x/Marlin

Hi Christian,

I get a compile error for V2. I'll send the info via messaging, but I belive it's already mentioned in one of the pull-requests.

Why is the main post under moderation???

The pull request with the bugfix has been pushed now.

Thanks, it compiles now for V2.

So... i have pushed the sub-directory and "special menu" support. If you want to go into a sub-directory (prepended with "/") or special-menu (put in "<"/">") and also if you want to use a special menu function (put in "<"/">"), then you have to mark it and press the reload (circular arrow). There is no further feedback by the ui so far, when you use a special menu function. It has right now a lot debug output... it going to be less in the next releases.

I am really happy as it is right now. I do sometimes connect octoprint to run a pid autotune. So, that might be nice: A PID autotune for the hotend (with part fan on) that automatically saves the values to eeprom.


Where can we donate to show our appreciation? What you've done so far will only get better through your additional work and that of others.

Thanks for that... but using, testing and bug reporting is the best appreciation you can give me.

Thanks Christian, 1.1.8 up and running on my V2!

edit: just measured the part cooling fan voltage: 12.6v

Right now I am planing the next changes. Maybe you have some comments on that.

  • I am hassitant to implement the resume from outage. I don't know if I can reliably stop the print instantly, get the coords/temperatures/feedrate and remove the head from the print in time. If I would leave the head one the print then the feature world be useless in my opinion.
  • I want to improve the pause: (1) Move to the head to a safe position. (2) Restore temperatures on restart. (3) Find a way to restore the feedrate.

Is there anything you would like to have as an improvement?

By the way... has any one of you with an unmodified v1tried the firmware... I would like to integrate the configuration.h?

Although the Ultrabase surface (on v2 units) might defeat resume from outage since it will release the model when it cools down, I still believe that to recover from a short power outage is a feature worthwhile having. I don't believe that there is enough energy in capacitors to move motors after power goes out, even just in the Z-axis direction, so the print head stays in place in any case :/ Also, I'm not aware if there is a power sense line integrated in the TriGorilla board that would allow triggering of an interrupt service routine to record at least the latest position to avoid constant writing to the flash memory. Ofc. it won't be able to continue without user's intervention, but position is enough in my opinion. A user will have to preheat the head, move the head up on the Z-axis, clean the filament from the nozzle/model and then resume the print as one would have to do now. There might be a small defect on the model, but on a bigger print it can prevent wastage of the print time and the material used. You shouldn't concern yourself with some advanced functionality, that is Anycubic's responsibility ;) If we can just get the stock functionality, but with a newer version of Marlin, that would be a BIG win for us :D
@BETLOG mentioned something to me about the way that the stock firmware saves position in the flash after every successfully executed command and if there is no ACK, it assumes a (power) failure. I might got something wrong from his explanation and I haven't red the original source code to see how it's actually implemented :(
Do you have source files from that French forum? On the Facebook group, we have some source files which are a mix of i3 and Kossel code and it seems to be some very very old version of Marlin 1.0.1.
Edit: Thank you for your efforts and time. Happy holidays :D

I was assuming that the index gets written to EEPROM, in retrospect it probably gets written to SDcard, as (afaik) that is the requirement for resume to work in the first place (the file must be on sdcard).
I was reading some configuration_adv.h recently and iirc the source code for handling resume was in there. I wasn;t paying much attention and didnt bother to trace out all of the command invocations to figure out how it worked, but you should locate and examine that code.
Logically it needs to write an index either before or after every instruction set is 'ok'd as completed by the printer. I would think it better to write the index after each completion. That way if an instruction set is killed part way through execution due to power loss it will be repeated after resume. Printing a few lines in duplicate is genberally less damaging to the print that completely omitting any part of a line.
But as always, I am just guessing.

They could use a uSD card, but it's a risky business driven with the assumption that the card is still powered on. When power goes out and if they try to drive the motors, the energy reserve will go flat out. One way it could be done is, to use buffered writes to the card that contain a necessary state of execution. If there is a power outage, simply append some flag to the state and flush the buffer to the card in the power outage triggered ISR, then block in the same ISR. That would cost tens of milliseconds or perhaps even less. I guess there is a time frame of a few hundred milliseconds before uC tries to reset itself.

Nobody would ever code this sort of thing to attempt writes after power loss.
Comparing actual gcode filesize bytes to index position would easily reveal if power had been prematurely cut.

I'll have a look at the code later, if I think about it, but someone who is already familiar with that code would be better qualified to comment on exactly how it functions. My motivation to fix anycubics issues diminished to almost zero a few months ago.

Comment has been deleted

Well... the code how anycubic has done it quite easy. They just write sd file index, head location and extrusion rate to the EEPROM. They hook to INT6 a digital IN (the Outage detection PIN). As soon as it fires they stop everything and write back the data. "Quite simple".
Upon restart they they skip the code to the index and simply continue printing. Thats for the theory.

I know already how to implement it. But implementing this "feature" needs some major changes in the marlin code. That breaks my dogma keeping the changes to the actually marlin code as little as possible. And I don't want to spend too much time and effort in a feature which is not portable and technically useless. If someone relies on that feature should better buy a BackUPS... but thats just my opinion.

Right now I put my effort on bugfixing and having all display related features implemented. Maybe after that I might look into it again.

technically useless

I agree.
When I was researching my first printer I thought the resume function was good, probably mostly because I did not see it on any other printer, so I assumed it was a benefit. Similarly I assumed the TFT would be better.
While TFT interfaces are in general nicer to use, the current implementation - closed source, and unusual wiring - is bad.
In retrospect I can see that the resume function is essentially worthless. As you suggest, a UPS and graceful shutdown via printserver (octopi) is preferable.
I am also a little surprised that a basic resume plugin has not been developed for octoprint... or maybe it has.

Given a choice between bezier curves (the original use of the G5 command) and resume, I would prefer bezier curves. I have a feeling this will be even more important on delta-rostock machines.

Also; Thanks to several months of listening to their silence, and receiving firmware bundles from them that were always clearly bogus, I am still unforgivably sceptical about anycubic's firmware, so I have lost any motivation to flash my mega, at least for now....
....but I have a huge amount of appreciation for the fact that you have produced this work, and are continuing to refine it. Hopefully soon it will be a completely operational firmware bundle that will finally overcome the closed-source shortcomings of the Anycubic i3 Mega.
I wish you and anyone working on this only the best, but please forgive me if my uncontrollable cynicism on this issue resurfaces from time to time. The mega's no-firmware issue has essentially burned me a little far as first 3d printer experiences go. :)

You are completely right. My main focus is to get a stable Marlin 1.1.6 (and following) to work with the stock i3 Mega. All useful display features should be supported. And the implementation should have no impact on the marlin features.

I faced already drawbacks. With this display it is impossible to get "Advanced Pause" and "Unified Bed Levelling" to work, because it relies on the Marlin LCD implementations. So it will be always just a hack... or lets call it a patch-set for those who don't want to have a different display.

As far as my analysis went I will never work on an new implementation for the display it self... attaching a display from eBay takes only an hour. Spending month of coding the Cortex-M0 with a working display code doesn't make sense then.

So for that I will finish the missing display features... z-Offset setup and Bedleveling Testprint (v1). And than I am will to make bug fixes.

But my thanks right now go the people who help me, give me feed back, provide me information and last but not least do the testing. But its also very important to discuss about that topic.

Yeah, there is not much sense in diverging from the stock Marlin implementation, unless if it can work with some really simple addition of an API to handle required things. Marlin is already at version 1.1.8, since yesterday :/ What type of the LCD did you meant, an MKS-TFT? I always try to think about new people that come to use this printer and telling them if they want the upgraded firmware, that they'll have to replace bits on their printers.

Btw. Anycubic is phasing out this "branch" of TriGorilla boards, they've introduced a new version of the TriGorilla board based on an STM32F4 microcontroller that handles the LCD display directly (as in parallel display interface). This will definitely mean closed source in the future from their side :( But, on the upside it would be possible to adopt Marlin 32-bit version at some point :) I'll assume that was the reason that they've stopped updating their firmware.

I am really happy with how Christians firmware works right now. Just some minor LCD bug left, but other than that it's working fine. 30hr print completed without hiccups. For any advanced features I now use octoprint. A pi zero w works fine for basic features and monitoring and only costs €11.


I have several versions of the original Anycubic sources (1.0.0, 1.0.1 and 1.1.1). As I read it... an interrupt is hooked to a digital pin (so called outage pin). The interrupt rises as soon as an outage is detected by the trigorilla. The interrupt handler stops all steppers and heaters (of course to safe power) and writes the position, temperatures and file index to a dedicated area of the EEPROM (its just emulated in the flash). At next start up the firmware should find out, if it was shutdown while printing. In that case it reads the position and temperature data. If you resume the file it will skip to to the file index. Thats to the theory... I got nearly all puzzle pieces... except for one, how does that beast know, that we started with an outage.

Regards and happy holidays.

We know that this flag has to survive a reset, so they have to save it in EEPROM. My guess is, saving of that flag might occur either when the ISR is triggered or in a function call made from the ISR (if they make one). They might add a status byte or alter something when they're saving printing status data. I don't think they are trying to return from that ISR after it happens. It would be a great thing to have a debbuger connected to the ATmega2560 with their original source files and see what happens when interrupt occurs.
They have to have some sort of a global state structure or something, because when I reset my machine when it is idling and when it boots up it will remember certain things/states that were set in menus. Meaning that even during a normal power cycle it will trigger that power outage ISR handler :)

I have forgotten to say: Thanks for your work!

I made a change in the config which may have finally solved a problem I was having: temperature control. Until now my prints were ok, but not perfect. Strange thing was, that different temperature settings had almost no effect on the print quality. Going through configuration of the stock firmware, you can see that they have #define TEMP_SENSOR_0 5.
5 refers to: 100K thermistor - ATC Semitec 104GT-2 (Used in ParCan & J-Head) (4.7k pullup)

However, if you lookup the spare hotend for the i3 Mega, a different thermistor is listed: 1x Thermistor:100K NTC B 3950 ±1%

So, I changed to TEMP_SENSOR_0 5, retuned pid with the part fan on, and am printing right now....

edit: after reading Christians comment, I swtiched back to the default define

The hotend thermistor that came with the V1 is a ATC Semitec 104GT... thus number 5. Every Anycubic source I have uses number 5 (but I haven't checked, if they have overwritten the thermistor curve... at least for 1.0.0 they didn't). But yes, the spare hotend sold by Anycubic is referred as a 3950... actually the most common on most stores. But if you accidentally take the wrong one, you would have a temperature error of roundabout 10-20°C... always check you temperature with a reference thermometer after changing something... and never trust the thermistor description of the shops.

The flickering after finishing the print should be gone now.

I'll have a deeper look then. I checked my hotend and my spare, and I believe they both have the same thermistor.

I tried your previous revision, and the screen still freezes after the print is stopped. Sometimes it doesn't but then when I navigate to the SD card it doesn't show any files.

Edit: I just downloaded your latest version & changed the thermistor back to stock.

The problems with the freezes after print should be fixed now. The update have been push to GitHub. With the new fixes I haven't had any file menu problems jet.


I'll flash as soon as my current print finishes (app 4 hrs left...)

So, I made my config files and flashed the firmware to my Mega V2. Confirmed working so far:

  • Touch screen controls for x,y & z axis movement
  • Touch screen controls for homing individual homing & home all
  • Dual endstops for z axis
  • Pre heating bed via touch screen
  • Pre heating nozzle via touch screen (large overshoot though, have to re-tune pid)
  • Cooling via touch screen
  • Filament sensor warning
  • Reset button working

Bugs so far:

  • scrolling the SD card menu, pressing down button causes a freeze
  • stopping a print causes a freeze

Gonna start a print soon....

I have updated the stop print code to be handled differently.

What do you mean by "scrolling the LCD menu"... do you mean the SD file selection? I gonna check this.

Here is video. When I choose print in the main menu, then screen with file selection is frozen


I have version 2 and I can help with testing.

Can you provide me the terminal output of these incidences? That usually explains a lot... and there might be still a bug with special chars like Chinese which might cause it. I think bartolomeus had this problem with the SD card provided by Anycubic and they have filenames with Chinese chars.

I'll try to check on this during the weekend.

Yes I can confirm. Problem was special chinese chars from anycubic. After delete this folder it no longer freeze.

But there is one more little problem in file list. Video: https://www.youtube.com/watch?v=YolJa03G380
Strange characters in file name, but only when return from TFT Serial Command: A8 S8.

Output in attachment.

Thanks for the bug report. Looking at the terminal output, everything is okay... but video looks looks odd... I have to check it but the debugging will take some time.

Yes, I meant SD card.
Just printed a Benchy. LCD screen freezes after the print finishes. No reaction on the ok button. The finished print message with print time is very dull and flickers.

Comment has been deleted

I was comparing the different configs (official Marlin, yours, and anycubic i3 mega). I could see that only in Anycubic config.h soft_pwm is enabled and soft_pwm_scale is set to 2. What would be the reason for this? Did you notice any different behaviour of fan control when you flashed your firmware?

When I have some time, I am going to flash your firmware.
I'll also get a pi zero w so I can have a backup screen if my lcd gets messed up (my Mega is a V2).

I didn't see any negative (or different behaviour) in the fans for soft_pwm_scale=0 and fan_soft_pwm disabled (but I also ripped out the original fans far before experimenting with this firmware). The problem is, that soft_pwm_scale affects the heaters as well and on the negative side effect is a reduction of resolution. I my opinion for the good control you need to have a good resolution in the pwm. I would expect more swinging in the resulting temperature if you set it to high.

I welcome any help I can get... especially for testing. I wound really appreciate a good configuration.h for V2.

Comment has been deleted

I think you have to enable DUAL_Z_ENDSTOPS in the Configuration_adv.h as well, as the V2 has two z-endstops and I haven't done the upgrade. The PID should be the same... I even use them on my E3D V6 hotend. Thermistor settings should be also the same. DUAL_Z_STEPPER_DRIVERS has to be enabled (in _adv.h).

I thought those settings were already enabled. I'll check again.

Pi is up and running.

I keep my fingers crossed. Be careful especially with the first z-Axis moves... don't do more the 1-2mm. X and Y is no big deal. If you can check the T0 temperature with a thermometer.

I'll see if I can give it a go on friday. If evrything goes well I'll receive my pi zero w tomorrow.

Comment has been deleted

I have a v1 and it has a filament sensor...

I can confirm it... I forgot about it, because I removed it and put it away. I will implement it in a more Marlin-ish way.

This is awesome!
Please upload code on github, when I will have time, I can help to improvement.

I have just put the changes in a marlin fork. I have put it the mainstream 1.1.x in my fork.

Yes, its the pull request to support the Trigorilla board. I gonna check out the differences.

Hi Christian, thank you for the effort that you've put into this mod ;) I haven't tried it out, but now, it is more simpler to give it a go.

Have you seen this repository: https://github.com/DIYElectronicsZA/Anycubic_i3_Mega
The author has a document describing the commands used between the main board and the external LCD.

Also, it seems that he managed to port the version 1.1.5, perhaps you could check if he has already done some work that you might be missing :)

P.S. As for the beeping, I actually like it after putting a piece of tape over the buzzer :) It gives a better feedback than pressing on that resistive TS.

Edit_1: Would you mind joining the Anycubic support group on facebook? https://www.facebook.com/groups/650270968508148/

Edit_2: The author (Mr. Rambo, diyelectronics.co.za) of the code from the GitHub link has responded to my question about the status of his port and here is his response:
" I did manage to get marlin 1.6 working on the Trigorilla mainboard and setup the pin definitions for the odd motor config. ABL or rather UBL is also working. I also have the additional software serial port working for the LCD control panel, however not all commands have been implemented yet, so far only axis homing and temperature reading. The printer can be controlled by the normal serial port normally, I'm using octoprint to do this.

Off the top of my head things to do:

  • Implement all LCD commands
  • Get SD card support working
  • Get filament sensor working"


Author of https://github.com/DIYElectronicsZA/Anycubic_i3_Mega here :)

I'm going to put some more effort into this in a couple days, seeing as there is quite an interest. I will also have a V2 machine soon so I can work on a port for that too.

@derhopp , would you like to collaborate on github? easier to sync changes


Sure, we can collaborate on GitHub. That makes things easier. Especially that I have a V1 machine.

Best Regards


Hi Matej,

I think I ran over the sources while searching for an implementation. But the hint to the translation makes the last pieces easier. Thanks for that.

The buzzer while typing can't be influenced from the marlin side. It's part of the display FW. But the buzzer for levelling, starting, usb-connection and errors it not used by my code.

I am not so much into facebook. I am old school. (: But thanks for the invitation.

Best regards