Marlin with Anet A8

[devekrehbiel]

I have been using Skynet but would really like to use Marlin so there is no middle man. Is this wrong? Also because Marlin doesn't need a special Arduino IDE to run it. So the ONLY problem I seem to be having with the very latest Marlin on the A8 is after it homes then levels the bed.. then... rather than going on a down trajectory towards the bed, it stays at the Z level it was at when it finished with the bed level routine. It tries to print from the wrong Z level. If I am on the wrong forum or this is a contentious issue, I apologize profusely. I am so close to making it work! Thanks again!

[benlye]

Is this wrong?

No! I have an A8 and have been running Marlin without SkyNet for months. Welcome to the party ;-)

Sounds like you might be running into a recent issue where Z movement commands were being ignored - have you updated to the very latest bugfix-1.1.x?

If yes, post your start code, because there could be something wrong there as well.

[devekrehbiel]

I don't have any start code that I know of. I just downloaded the very latest and that seemed to fix the problem. You guys must have just fixed it in the last 4-5 days or so. Thank You! Glad I can go to the latest Marlin! :) If you have any suggestions on start code I am all ears!

[naseweiss01]

Hi,
I have exactly the same issue.
When I home with G28 - or home G28 Z, everything perfect in terms of Z-height.
But - when I do a G29 and put a coin at the position of the last measuring point of the G29 sequence and do after the G29 a move with G0 X135 Y110 Z0 back to the initial Home Z position, the nozzle is exact the height from the coin to high above the bed.
I have an inductive sensor. The bed is almost perfect leveled.

Did I miss something to activate auto leveling ?

Thanks,

Naseweiss01

[benlye]

Are you able to move the Z axis at all? Are you using the very latest bugfix-1.1.x build? There was an issue a few days ago where Z move commands were being ignored, but it was fixed.

[naseweiss01]

Hello,
I am on the latest bugfix 1.1.x.
But I did use my 1.1.3 configuration.h & adv from 1.1.3

Yes I can move Z - and if I only use G28 everthing is fine in terms of Z-height.

[devekrehbiel]

I was surprised when I thought I had the latest bug fix at how fast these guys post new bug fixes. I have not yet learned the secret as to how the bugfixes are numbered so they can be told apart, but the very latest one fixed my problem using the old configuration.h file.

[naseweiss01]

Ok,
I now used the configuration.h & adv from the Bugfix branch.
Issue still there - the very last G29 Position is taken as zero for the whole bed.
With a coin that can be easily verified.

[benlye]

Is your Z offset set correctly? What does M851 report?

[naseweiss01]

M851 is zero - I adjusted the sensor in that way, that it is 0.
However, I think it is working now.
Checking bye eye gave the impression that the error is still there.
But when I moved the nozzle over the bed, I realized the correction is working.

But as it is linear and at the coin is ca +3mm at the other end it is 0, it has to be in the middel 1.5mm.

Maybe I should give another leveling method a chance.
The positiv thing is - the bugfix is smaller in terms of bytes and fits with the repeatability test into the Anet V1.0 board. (128mb only)

thanks.

[benlye]

However, I think it is working now.

Cool. One thing you can do so you don't have to check by eye is use the M114 command. The last number in the output line is the number of Z steps. With bed levelling enabled and working you should expect the Z position in steps to change when you move the nozzle around the bed at the same Z height.

E.g. on my printer:

Send: G28
Recv: X:130.00 Y:138.00 Z:13.60 E:0.00 Count X:13000 Y:13800 Z:5440
Recv: ok
Send: G29
Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3      4
Recv:  0 +0.150 +0.170 +0.177 +0.155 +0.050
Recv:  1 -0.088 -0.047 +0.005 +0.003 -0.060
Recv:  2 -0.185 -0.070 +0.003 -0.010 -0.098
Recv:  3 -0.177 -0.082 -0.005 +0.017 -0.045
Recv:  4 -0.080 +0.043 +0.128 +0.152 +0.082
Recv: 
Recv: X:220.00 Y:220.00 Z:13.52 E:0.00 Count X:22000 Y:22000 Z:5440
Recv: ok
Send: G0 X100 Y100 Z5 F6000
Recv: ok[...]
Send: M114
Recv: X:100.00 Y:100.00 Z:5.00 E:0.00 Count X:10000 Y:10000 Z:1998
Recv: ok[...]
Send: G0 X150 Y150 Z5 F6000
Recv: ok[...]
Send: M114
Recv: X:150.00 Y:150.00 Z:5.00 E:0.00 Count X:15000 Y:15000 Z:2023
Recv: ok

Notice that I left Z5 in both G0 move commands, and in the M114 output it shows Z:5.00, but at the end the Z step count is different. That's how I know that bed levelling is working.

[fiveangle]

For 128k boards, in order to use one-time setup features like pins debugging, bed leveling debugging, 100k mem watcher, etc, you need to disable some other needed features temporarily, then re-enable once you have disabled the debugging feature.

A few easy places to regain PROGMEM space for 128k boards:

option|size
---|---
SDSUPPORT| 18036 bytes - when using Octoprint for example
NO_WORKSPACE_OFFSETS| -3146 bytes
AUTOTEMP| 2204 bytes
PRINTCOUNTER| 2048 bytes
SHOW_BOOTSCREEN| 458 bytes
STRING_CONFIG_H_AUTHOR| 220 bytes
PRINTJOB_TIMER_AUTOSTART| 162 bytes

It's a juggling act to work around the limitations for sure, but usually possible.

[fiveangle]

Since a lot of people are strugglig with the 128k boards, I've published my snapshot of PROGMEM usage for many of the features in Config*.h which should help you pick-n-choose the ones that are most important to you, based on usage:

https://github.com/fiveangle/Marlin/blob/progmem_usage_comments/Marlin/Configuration.h
https://github.com/fiveangle/Marlin/blob/progmem_usage_comments/Marlin/Configuration_adv.h

[Bob-the-Kuhn]

From Dave's configuration.h:

 //#define STRING_CONFIG_H_AUTHOR "([email protected])" // Who made the changes. // 220 bytes
 //#define SHOW_BOOTSCREEN // 458 bytes
 #define CUSTOM_MACHINE_NAME "Printrbot Metal" // 16 bytes
 #define POWER_SUPPLY 0 // 0 bytes
 //#define PREVENT_COLD_EXTRUSION // 1918 bytes
 #define PREVENT_LENGTHY_EXTRUDE // 0 bytes
 #define THERMAL_PROTECTION_HOTENDS // Enable thermal protection for all extruders // 448 bytes   // both of these together
 #define THERMAL_PROTECTION_BED     // Enable thermal protection for the heated bed // 406 bytes  // saves 1522 bytes
 //#define FIX_MOUNTED_PROBE // 2444 bytes over PROBE_MANUALLY
 //#define PROBING_HEATERS_OFF       // Turn heaters off when probing // 156 bytes
 //#define PROBING_FANS_OFF          // Turn fans off when probing // 16 bytes
 //#define PROBE_DOUBLE_TOUCH / 0 bytes
 #define DISABLE_REDUCED_ACCURACY_WARNING // -64 bytes
 #define DISABLE_E false // For all extruders // 0 bytes
 #define MIN_SOFTWARE_ENDSTOPS // 128 bytes
 #define MAX_SOFTWARE_ENDSTOPS // 128 bytes // together with MINSOFTWARE_ENDSTOPS, uses 476 bytes
 #define MAX_SOFTWARE_ENDSTOPS // 128 bytes // together with MINSOFTWARE_ENDSTOPS, uses 476 bytes
 #define AUTO_BED_LEVELING_BILINEAR // 11534 bytes
 //#define DEBUG_LEVELING_FEATURE // 3312 bytes
   #define ENABLE_LEVELING_FADE_HEIGHT // 828 bytes
   //#define PROBE_Y_FIRST // 0 bytes
     //#define ABL_BILINEAR_SUBDIVISION // 1802 bytes
 //#define LCD_BED_LEVELING // 2302 bytes
 #define Z_SAFE_HOMING // 256 bytes
 #define EEPROM_SETTINGS // 5268 bytes
   // To disable EEPROM Serial responses and decrease program space by ~1700 byte: comment this out
   #define EEPROM_CHITCHAT // Please keep turned on if you can. // 86 bytes
 #define HOST_KEEPALIVE_FEATURE      // Disable this if your host doesn't like keepalive messages // 626 bytes
 //#define M100_FREE_MEMORY_WATCHER // uncomment to add the M100 Free Memory Watcher for debug purpose // 2578 bytes
 //#define INCH_MODE_SUPPORT // 1126 bytes
 //#define PRINTJOB_TIMER_AUTOSTART // 162 bytes
 //#define PRINTCOUNTER // 2048 bytes
 //#define SDSUPPORT // 18036 bytes
 //#define INDIVIDUAL_AXIS_HOMING_MENU // 242 bytes
 //#define FAST_PWM_FAN // 102 bytes
 #define FAN_SOFT_PWM // 14 bytes

[Bob-the-Kuhn]

From Dave's configuration_adv.h:

 //#define AUTOTEMP // 2204 bytes
 //#define SHOW_TEMP_ADC_VALUES // 122 bytes
 //#define FAN_KICKSTART_TIME 200 // 116 bytes
 //#define FAN_MIN_PWM 50 // 26 bytes
 //#define HOME_Y_BEFORE_X // 0 bytes
 #define HOME_AFTER_DEACTIVATE  // Require rehoming after steppers are deactivated // 0 bytes
 #define SLOWDOWN // 166 bytes
 //#define LCD_INFO_MENU // 1912 bytes
 //#define STATUS_MESSAGE_SCROLLING // 248 bytes
 //#define LCD_DECIMAL_SMALL_XY // 154 bytes
   #define XYZ_HOLLOW_FRAME // 198 bytes
   //#define MENU_HOLLOW_FRAME // 44 bytes
   //#define USE_BIG_EDIT_FONT // 3094 bytes
   //#define USE_SMALL_INFOFONT // 2300 bytes
 //#define USE_WATCHDOG // 30 bytes
 //#define BABYSTEPPING // 932 bytes
 #define ARC_SUPPORT               // Disable this feature to save ~3226 bytes
 // Support for G5 with XYZE destination and IJPQ offsets. Requires ~2666 bytes.
 // To save 386 bytes of PROGMEM (and TX_BUFFER_SIZE+3 bytes of RAM) set to 0.
 #define ADVANCED_PAUSE_FEATURE // 6616 bytes
 //#define AUTO_REPORT_TEMPERATURES // 290 bytes
 #define EXTENDED_CAPABILITIES_REPORT // 474 bytes
 #define NO_WORKSPACE_OFFSETS // -3146 bytes
  * Spend 28 bytes of SRAM to optimize the GCode parser

[thinkyhead]

Updated:

#if ENABLED(EEPROM_SETTINGS)
  //#define DISABLE_M503  // Saves ~2700 bytes of PROGMEM. Disable for release!
  #define EEPROM_CHITCHAT // Print a report on M500. Please keep turned on.
#endif

And EEPROM_CHITCHAT saves about 670 bytes by itself now with the default config. A bit more when used with other chatty features.

[Nightreaver]

that should really be part of the wiki! no question
Dont understand why you advice people to check issues rather than add this right away, even for an estimate this is great

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.