Show all posts by user
Printing issues ...
The 5V regulator on the Arduino Mega is pretty weak, and the 200-300mA that the BLTouch pulls is often enough to burn it out. You really need to use a buck converter if you want to power a BLTouch.
by
MMcLure
-
RAMPS Electronics
Yes, but if you didn't do M502/M500, the probe offsets could be wrong in EEPROM so Marlin doesn't understand where to put the probe.
by
MMcLure
-
Firmware - Marlin
Make sure that when you execute `M851` it shows the same offsets you set in the firmware. If it doesn't, execute `M502` followed by `M500` to copy the new settings from the firmware into the EEPROM.
by
MMcLure
-
Firmware - Marlin
Thermistor table 1 stops at 300C in both Marlin 1 and Marlin 2. My guess is that Marlin 2 added code to restrict this for safety reasons. In fact, I'm surprised it doesn't also limit the temperature setting via the LCD. You really need a better thermistor if you want to go all the way up to 300C since there need to be correct values to allow the temperature to exceed 300C for PID to work properly
by
MMcLure
-
Firmware - Marlin
Most likely you have PROBING_MARGIN set to the default of 10 - this means it can't probe any of the rows/columns that are closest to the edges. PROBING_MARGIN is designed to handle probes that are inaccurate near the edge of the bed (inductive/capacitive) and can be set to 0 for a BLTouch.
by
MMcLure
-
General
https://forum.repetier.com/discussion/4773/heated-bed-on-and-off-too-frequently
by
MMcLure
-
Printing
What mode of G29 are you using? I have heard reports of issues with Bilinear leveling - I personally use UBL so I haven't seen any issues similar to yours.
One thing to ensure is that the Z offset is correct before you generate the mesh - you should be able to print something small in the center of the bed without bed leveling enabled so the leveling is only adjusting for variations in the bed su
by
MMcLure
-
Firmware - Marlin
Answer 1: Yes. Assuming nothing has changed mechanically the matrix should be identical within the sensor error.
Answer 2: Yes, assuming your Z probe offset is correct.
The most common cause for meshes changing between runs is the X axis becoming misaligned. When there is no current on the Z motors it's very easy for this to happen. Using dual Z drivers allows you to use G34 to re-level the X a
by
MMcLure
-
Firmware - Marlin
Unless your Z probe triggers after the nozzle hits the bed, your Z offset should always be negative.
by
MMcLure
-
Firmware - Marlin
What you are seeing is expected. When you home the printer, the Z position will end up being Z_AFTER_HOMING minus the Z probe offset. For example, if Z_AFTER_HOMING is the default (10) and your Z offset is -1.60, then after homing your Z will show as being at position Z=11.60
It looks like you have Z_AFTER_HOMING set to 0, which would result in you seeing Z:1.6 in the M114 output.
by
MMcLure
-
Firmware - Marlin
No - you definitely need to make a fork and a branch on that fork
by
MMcLure
-
Firmware - Marlin
That sounds like an excellent feature to make a pull request for. Just make sure you make your pull request against the bugfix-2.0.x branch, as documented in Contributing Code with Pull Requests.
by
MMcLure
-
Firmware - Marlin
That is how it works. Remember, homing doesn't mean "move to 0,0,0", it means "find out where 0,0,0 is". Where the nozzle ends up is irrelevant to the homing process, as long as Marlin knows where the nozzle is at the end of it. If you want to move to 0,0 after homing Z, do "G0 X0 Y0" or "G28 X Y" after the initial "G28". Note that the latter may not end up at 0,0 either - if X_MIN_POS/Y_MIN_POS
by
MMcLure
-
Firmware - Marlin
It's possible that one of the wires going to the hot end heater cartridge is broken inside the insulation, and when the Z axis reaches a certain point insufficient current flows through the heater cartridge so the hot end can't hold temperature. Marlin is turning the heater cartridge on full blast (the "@127" in the temperature output) so this has to be something mechanical/electrical. The SKR 1.
by
MMcLure
-
Firmware - Marlin
I have started writing a document on how to configure the build volume in Marlin. It's early days yet, but the first part (how to ensure that 0,0 is correctly at the front left corner of the bed) is complete. Take a look at https://manuelmclure.github.io/ConfiguringLeveling.html
Essentially, you need to edit your X_MIN_POS and Y_MIN_POS to put 0,0 on the front left corner of the bed (assuming th
by
MMcLure
-
Mechanics
Do you have TMC drivers installed? If so, make sure you cut the DIAG pin from the driver - otherwise the TMC driver's stallguard signal will interfere with your sensor. The SKR 1.3 board had jumpers to disable this, but the SKR 1.4 requires the pin to be cut.
by
MMcLure
-
Firmware - Marlin
Disable MONITOR_DRIVER_STATUS - it should be only enabled for debug purposes as it can negatively affect print quality and cause major problems. The messages shown in the terminal are coming from this setting.
Note that you do not have to enable MONITOR_DRIVER_STATUS to get full output from M122 for your TMC drivers - that's controlled by TMC_DEBUG which does not have the bad effects that MONITOR
by
MMcLure
-
Firmware - Marlin
Setting up the Z probe offset
To determine an initial value for the Z probe offset, use a host program to perform the following steps:
Use M851 Z0 to zero out the probe offset. Home the printer with G28 Disable software end stops with M211 S0 Using your printer's LCD, slowly jog the Z axis down until the nozzle just grabs a piece of plain paper between itself and the bed. Read the value for Z
by
MMcLure
-
Firmware - Marlin
I think that the bed leveling would handle the problems in your Y axis just fine. It's the X axis that generally results in the behavior you're seeing. It doesn't take much - 1/2mm between the rods at one end can result in over 0.5mm offset across the bed.
by
MMcLure
-
Printing
With an Anet A8 (even one upgraded to a metal frame) there are two possible mechanical issues that could cause something like that.
The first is a twisted X axis - if the two rods the X axis moves on are not exactly parallel (it doesn't take much - 0.5mm difference from end to end is noticeable) and the Y probe offset is not 0, then the effective probe Z offset will change across the bed and the
by
MMcLure
-
Printing
Quotecharlie68Looking at the Ramps 1.4 schematic , the MOSFETS for the bed, hotend and fan switch to ground, so if I ignore the RAMPS + terminal and instead wire my fan + to (a fused) 12V, and fan - to RAMPS D9 then my fan is running at 12v with PWM control right?
Correct. That should work just fine to run a 12V fan.
by
MMcLure
-
RAMPS Electronics
It's normal for the Z axis to end up 10-11mm above the bed after homing. If you look at the LCD it should show that value for Z. Homing is not "move to 0,0,0", it's "find out where 0,0,0 is". As long as the printer is correctly showing the right value for Z at the end of homing (it should be 10 minus your z probe offset) then the homing was successful.
by
MMcLure
-
Firmware - Marlin
This is due to a misunderstanding of what "homing" means. Homing does not mean "go to 0,0,0", it means "find out where 0,0,0 is". Whether the nozzle will actually end up at 0,0,0 at the end of homing is very unlikely, however after homing Marlin will know where the nozzle is. If then you execute a "G0 X0 Y0" the nozzle should then correctly go to the 0,0 point (which should be the front left corn
by
MMcLure
-
Firmware - Marlin
If you have bed leveling enabled, the Z axis will move up and down to compensate with X/Y movements. If you enable fade, the correction will be less and less until you hit the fade height, after which correction will be no longer applied.
You cannot specify
#define ENABLE_LEVELING_FADE_HEIGHT 3
ENABLE_LEVELING_FADE_HEIGHT is a toggle, either true or false. The actual fade height is set either
by
MMcLure
-
Firmware - Marlin
TMC_DEBUG is fine to have enabled, it just increases the verbosity of some output. The setting that is resulting in the above messages and is not recommended for production systems is MONITOR_DRIVER_STATUS which continuously polls the drivers for status.
by
MMcLure
-
Firmware - Marlin
"Home" does not mean "move to 0,0". "Home" means "find out where 0,0 is". If you want to move to 0,0 after homing you need to add an explicit "G0 X0 Y0" command after you home.
by
MMcLure
-
Firmware - Marlin
As long as X_MIN_POS/Y_MIN_POS and X_BED_SIZE/Y_BED_SIZE as well as NOZZLE_TO_PROBE_OFFSET are set correctly, you should not need to use PROBING_MARGIN. PROBING_MARGIN is required only for probes that behave badly near the edge of the bed such as inductive or capacitive probes. A BLTouch should not require PROBING_MARGIN.
What you should ensure is that X_MIN_POS and Y_MIN_POS are set correctly s
by
MMcLure
-
Firmware - Marlin
Marlin is hitting hard limits it terms of what the Arduino environment can manage. There are some workarounds (like moving the Marlin source folder to the root of the drive and naming it something short like "C:\M", deleting folder in the HAL that don't apply to your hardware) but that's just trying to hold back a flood with a tiny cork.
The better solution is to switch to using PlatformIO to com
by
MMcLure
-
Firmware - Marlin
The values in EEPROM will override the values set in Configuration.h until you tell Marlin to reload the new firmware values. So all you need to do is execute an "M502" to load the new firmware values and an "M500" to save the new values into EEPROM. It's a good idea to get into the habit of doing this on every firmware upload.
by
MMcLure
-
Prusa i3 and variants
Nothing seems out of the ordinary in your configuration. Note that by default end stops will only be read when homing - once the printer has homed they will be ignored unless ENDSTOPS_ALWAYS_ON_DEFAULT is enabled in Configuration_adv.h. But they should work for homing with the configuration you presented given the fact that M119 is showing the right results.
by
MMcLure
-
Firmware - Marlin