search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.27k stars 19.23k forks source link

[BUG] UBL bad behavior #22486

Closed rethys1 closed 2 years ago

rethys1 commented 3 years ago

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

This is a correction to the bug report #22485 to which the incorrect config files were uploaded. I am attempting to install an SKR v1.3 board into an Adimlab gantry machine. I have successfully compiled Marlin 2.0 for the machine and all functions work in normal operation. I am attempting to enable UBL leveling, which I am quite familiar and successful with on the original Mega 2560 board using Marlin 1.1.9. However, making the same configuration.h and configuration_adv.h changes results in the probe, upon inputting G29 P1, moving to the first grid location and then repeatedly moving up and down without any further movement along the X or Y axes. Additionally, the movement along the Z axis rises to the height set by #define Z_CLEARANCE_DEPLOY_PROBE rather than the lower height that would normally go to between probes. There does not seem to be any recording of the probe position when it's triggered at the low point. If I leave it go for the full 100 (10 x 10) points of the grid, a G29 T shows an empty grid. I am using a capacity of probe which physically triggers, as indicated by the LED on the sensor, and which the board logically sees as shown by the M119 command changing from open to triggered in concordance with the LED. I have attached zip files of my configuration folders as well as an error log from the M111 S247 command. I have changed various parameters including bed size, margins, mesh insets, and Z probe low point.

Bug Timeline

This is a new issue.

Expected behavior

I expected the probe, upon a G29 P1 command, to home and then move up 25 mm, move on the X and Y axis to the first mesh position, lower to trigger the sensor, raise back up 10 mm or so and move along the X or Y axis to the next point on the mesh. I expected this behavior to repeat until the hundred points of the mesh were measured.

Actual behavior

Upon a G29 P1 command, the probe moved to home and then moved up 25 mm, moved on the X and Y axis to the first mesh position, and then it proceeded to move up and down on the first mesh position repeatedly. Instead of moving up only 10 mm or so it moved up the full 25 mm. The LCD was recording each set of vertical movements as a position on the mesh, 1/100, 2/100 etc. The M111, S33 log shows 2 probing failed messages for each vertical movement. At the end of 100 vertical movements, the procedure stopped as if it had succeeded. However, the mesh was empty.

Steps to Reproduce

  1. Load firmware.bin compiled from the attached configuration files.
  2. Issue a build cold mesh command from a computer attached via USB or from the selection of the LCD.
  3. Probe functions as indicated.

Version of Marlin Firmware

Marlin 2.0 release version (tested on Bugfix as well)

Printer model

Modified Adimlab Gantry

Electronics

SKR v1.3 with a riprap discount full graphics controller.

Add-ons

18 mm capacitive probe attached to a fan socket for power and the Z max end stop socket for signal with a 5v IC voltage limiter in-line. This hardware configuration has been extensively tested on numerous machines including the gantry with the stock control board.

Your Slicer

Cura

Host Software

Pronterface

Additional information & file uploads

Marlin.zip LEVELING ERROR LOG.zip

thinkyhead commented 3 years ago

Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information so that we're not just taking stabs in the dark. Here is the boilerplate:

Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on with your machine.

rethys1 commented 3 years ago

I found the problem. I guess you've added a new error, probe triggering too early, in Marlin 2.0. I saw it show up in the m111 s247 log. Previously, I paid no attention to the configuration of the probe height versus nozzle height and setting up the firmware since my procedure for configuring the ubl took care of all that once the system was running. When I saw the error I measured the nozzle height at triggering, the probe height at triggering and the probe height at home viv a vis the bed surface and plugged all of those values into the firmware. It is now running as expected. I would suggest, though, that you create a new error message instead of probing failed when this is triggered.RaySent from my Galaxy -------- Original message --------From: Scott Lahteine @.> Date: 8/9/21 6:26 AM (GMT-05:00) To: MarlinFirmware/Marlin @.> Cc: rethys1 @.>, Author @.> Subject: Re: [MarlinFirmware/Marlin] [BUG] UBL bad behavior (#22486) Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information so that we're not just taking stabs in the dark. Here is the boilerplate:

Download Marlin bugfix-2.0.x to test with the latest code. Enable DEBUG_LEVELING_FEATURE and M114_DETAIL and re-flash the firmware. Connect to your printer from host software such as Cura, Printrun or Repetier Host. Send M502 and M500 to ensure your Configurations are applied. Issue the command M111 S247 to enable maximum logging. Perform a G28 to do your standard homing procedure. Do a G29 to probe the bed. This will also enable bed leveling. Copy the log output into a .TXT file and attach it to your next reply.

Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on with your machine.

—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.

DerAndere1 commented 3 years ago

I think we can close this. If I understood correctly, this was an issue with wrong configuration. From the perspective of the firmware, the error message "probing failed" was correct: If the printer builder puts wrong values into the configuration, there is nothing the firmware can do about it, The required settings and their meaning are documented here: https://marlinfw.org/docs/hardware/endstops.html#configuring-endstops-and-probes.

github-actions[bot] commented 3 years ago

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

rethys1 commented 3 years ago

I'm against closing this report at this time. Since I'm not a programmer, I'll explain as best I can. The behavior described has been noted by a number of users in various circumstances. In configuring Marlin 2.0 for a new printer of my own design, I have run into it repeatedly in changing various parameters, often by tiny values. When using a capacitive probe, for example, it's impossible to pinpoint the probe to bed distance, or the probe to nozzle offset, with any accuracy as the electrical field is not visible, particularly since the field sensitivity can be adjusted on the probe. Mounting changes for the probe require changing these values, and I've run into numerous instances of value combination changes causing this behavior. The firmware constraints have obviously been tightened, since this never happened in 1.1.9, and the result is that this behavior occurs with no clear explanation of what problem the firmware is encountering. Although, technically, the 'probing failed' error may be true, that doesn't tell me the problem the firmware is having, and if the Z endstop limit switch isn't being triggered, the probe is well within the margins of the bed, and the probe is being triggered where expected, probing failed is insufficient. Messages like 'nozzle impacting bed' or 'bed not detected within permissible height range' would be far more diagnostically useful than just 'probing failed'.

thisiskeithb commented 3 years ago

Although, technically, the 'probing failed' error may be true, that doesn't tell me the problem the firmware is having

Please follow the steps Thinkyhead requested above. This enables max logging and provides more information for us to debug with.

rethys1 commented 3 years ago

Done and submitted with the original report. Do you need me to do it again?

thinkyhead commented 2 years ago

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

rethys1 commented 2 years ago

As per Scott's request, tested with the latest Bugfix. Behavior still exhibited.

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description I am attempting to install an SKR v1.3 board into an Adimlab gantry machine. I have successfully compiled Marlin 2.0 for the machine and all functions work in normal operation. I am attempting to enable UBL leveling. Upon inputting G29 P1, probe moves to the first grid location and then repeatedly moving up and down without any further movement along the X or Y axes.

Bug Timeline This is a continuing issue.

Expected behavior I expected the probe, upon a G29 P1 command, to home and then move up 20 mm, move on the X and Y axis to the first mesh position, lower to trigger the sensor, raise back up 10 mm or so and move along the X or Y axis to the next point on the mesh. I expected this behavior to repeat until the hundred points of the mesh were measured.

Actual behavior I am attempting to enable UBL leveling. Upon inputting G29 P1, probe moves to the first grid location and then repeatedly moving up and down without any further movement along the X or Y axes. I am using a capacitive probe which physically triggers, as indicated by the LED on the sensor, and which the board logically sees as shown by the M119 command changing from open to triggered in concordance with the LED.

Steps to Reproduce Load firmware.bin compiled from the attached configuration files. Issue a build cold mesh command from a computer attached via USB or from the selection of the LCD. Probe functions as indicated.

Version of Marlin Firmware Marlin Bugfix 2.0 latest release version

Printer model Modified Adimlab Gantry

Electronics SKR v1.3 with a riprap discount full graphics controller.

Add-ons 18 mm capacitive probe attached to a fan socket for power and the Z max end stop socket for signal with a 5v IC voltage limiter in-line. This hardware configuration has been extensively tested on numerous machines including the gantry with the stock control board.

Your Slicer Cura

Host Software Pronterface

Additional information & file uploads

Marlin configuration.h, configuration_adv.h and M111 S247 error log in Marlin.zip

Marlin.zip

rethys1 commented 2 years ago

My son Chris and I have tracked down the issue. Marlin\src\module\probe.cpp is requiring the value of #define Z_CLEARANCE_MULTI_PROBE in configuration.h to be set higher that the probe position when it detects the bed. Note that I did NOT have multiple probing enabled. With a field probe such as a capacitive probe, the exact position that the bed will be detected is impossible to determine in advance. Even with a BL Touch, the exact distance is difficult or impossible to predetermine. When I ran G29 P1, the probe detected the bed at 5.71mm. Since the value for the #define Z_CLEARANCE_MULTI_PROBE was set to 5, it through a too early error. When I reflashed the firmware with the value set at 8, everything worked. As far as I can determine, there is no reason why the firmware should care where the bed surface is detected, but there it is.

github-actions[bot] commented 2 years ago

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

github-actions[bot] commented 2 years ago

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.