Mesh leveling about marlin_2.0.x_anycubic_chiron HOT 10 CLOSED

I might end up doing a pull request with the modifications i have made to the files, unless the fork author has a good reason to keeping MBL disabled. I will post in this issue when it will be done.

from marlin_2.0.x_anycubic_chiron.

After a closer review of the code (and further digging into Marlin documentation), it appears that none of the code in anycubic_TFT.cpp file has to do with mesh bed leveling at all (except the code that allows to execute G29 S1 and G29 S2 command via the Special Menu, of course). Mesh bed leveling and auto bed leveling are just incompatible, and using both flavour at the same time should just not be since it alters the way the G29 command behaves.

Few options are available for upcoming pull requests:

1. When mesh bed leveling is disabled and auto bed leveling enabled, there should not be entries in special menu referring to mesh bed leveling. Features such as the chiron PROBE and ADVANCE SETTING menu should work as intended.

2. When mesh bed leveling is enabled, the possibility to use the chiron PROBE menu should not be allowed (in the latter case, the auto bed leveling should be considered). Since it is not possible to change any of the chiron lcd menus, a buzzer tone could be added to indicate to user that the functionnality is not available.

3. In theory, allowing the use of the ADVANCE SETTING menu to help user perform the mesh bed leveling seems to be possible since single points can be modified through the use of G29 S3. I will investigate this further to see what can be done in that regard.

In either case, the README should be updated to notify user mesh bed leveling is disabled.

Cheers

EDIT: for the sake of clarity, when i'm referring to "mesh bed leveling" and "auto bed leveling", I am referring to the defines available into Marlin's Configuration.h

from marlin_2.0.x_anycubic_chiron.

This bug is indeed reproducible. In fact, closer look at the code shows that mesh bed leveling is disabled and instead bilinear auto leveling is used. In the menu, selecting Start mesh leveling actually executes command G29 S1 and according to Marlin documentation, the behavior of G29 S1 for bilinear auto leveling sets the travel speed between probe points, which happens to be realy slow, exactly what is seen here.

To solve this, one must activate mesh bed leveling in Configuration.h rather than auto bilinear leveling. However, it will produces some compilation error in anycubic_tft.cpp.

1. Call to function in fault is refresh_bed_level when it should be reset_bed_level in anycubic_tft.cpp
2. References to z_values is missing in anycubic_tft.cpp. To solve this, the mbl header include must be added and all references to z_values should be replaced with mbl.z_values.

After that, mesh bed leveling behave as it should (also as per the guide described in this fork.).

from marlin_2.0.x_anycubic_chiron.

I have no reason to keep billinear leveling. This code was ported from 1.1.9 and billinear was selected by that default. If one were to update this code and verify its functionality, I'd be glad to push the changes

from marlin_2.0.x_anycubic_chiron.

@sketchydev Ok, now that you confirm it, this is bad. I've indeed noticed something was not right when I performed mesh bed leveling initially, but did not investigate this further. I suggest we start a seperate issue about this one because clearly something is wrong.

from marlin_2.0.x_anycubic_chiron.

I also experienced another weird issue in moving the nozzle up/down by 0.1 increment via the Special menu during mesh bed leveling, but i'll keep that as a separate issue. For reference, sometimes selecting nozzle up/down by 0.1 command actually cancel itself (commands in the terminal actually lowers the nozzle down by 0.1 (-0.1), but is followed immediately by moving the nozzle up by 0.1 (+0.1)­.

from marlin_2.0.x_anycubic_chiron.

Hmm ok.. Thank you for your reply !

For me the best bed leveling ever is the one in this firmware :
https://github.com/dkoch83/Marlin-1.1.9_Anycubic_Chiron

I'd like to integrate it in this firmware.. But for now it's too complex for me unfortunately

from marlin_2.0.x_anycubic_chiron.

@mrjiffy6 There is another issue I've found with MMBL, specifically the special menu. The Z+- buttons don't seem to work as expected.

I had a look at anycubic_TFT.cpp here are the relevent lines (447-458):

    } else if (strcmp(SelectedDirectory, "<z up 0.1>")==0) {
        SERIAL_ECHOLNPGM("Special Menu: Z Up 0.1");
        queue.enqueue_now_P(PSTR("G91\nG1 Z+0.1\nG90"));
      } else if (strcmp(SelectedDirectory, "<z up 0.02>")==0) {
        SERIAL_ECHOLNPGM("Special Menu: Z Up 0.02");
        queue.enqueue_now_P(PSTR("G91\nG1 Z+0.02\nG90"));
      } else if (strcmp(SelectedDirectory, "<z down 0.02>")==0) {
        SERIAL_ECHOLNPGM("Special Menu: Z Down 0.02");
        queue.enqueue_now_P(PSTR("G91\nG1 Z-0.02\nG90"));
      } else if (strcmp(SelectedDirectory, "<z down 0.1>")==0) {
        SERIAL_ECHOLNPGM("Special Menu: Z Down 0.1");
        queue.enqueue_now_P(PSTR("G91\nG1 Z-0.1\nG90"));

The G-code looks sound, but the 'Z Down 0.1' definitely goes more than 0.1mm - e.g. I have a 0.1mm shim that was free moving beneath the nozzle with a visible gap between the shim and the nozzle - pressing Z Down 0.1 caused the nozzle to crash into the bed and required many presses of Z Up 0.1 to rectify. I suspect the 'Z Down 0.02' probably goes down more than 0.02mm as well.

On the face of it, I can't see anything wrong here, but C++ isn't exactly my specialty, most of my experience is C#. I can dig into it a little further, but if you're going to move things to 'Advance Setting' maybe it's not worth it?

from marlin_2.0.x_anycubic_chiron.

@mrjiffy6 created #8 for the z move issue

from marlin_2.0.x_anycubic_chiron.

merged with latest

from marlin_2.0.x_anycubic_chiron.