text:
Z-step pulses too short (Marlin 2.0.x)
I was replacing a stepper driver on my Melzi 2.0 board with a A4988 Pololu module and for some reason, it won't cooperate with Marlin.
For reference, I'm using a Melzi 2.0 TRONXY with a ZONESTAR-style 5-button LCD. This LCD may be related to my problem. I'm using a custom configuration of Marlin 2.0.x since I replaced the main board and it's been giving me a lot of problems.
When testing the printer with an Arduino sketch, the Z-axis moves flawlessly. However, when I uploaded my Marlin configuration, the printer once again refused to move. Upon probing the Step and Direction pins with my oscilloscope, I found what I think is the problem. I was giving step commands from the LCD and from Pronterface when I saw this on the Z-Step pin:

Apologies for the blurry picture. The timescale is 20 μs/square and the voltage is 1V/square. What I'm supposed to see is a series of discrete 5 V pulses that tell the stepper to move, but what I got was a handful of tiny ~5 μs blips instead.
What I've taken this to mean is that the pin (digital 3, for those curious) is being set to pulse by the step request, but is being reset by something else. Everything points to the firmware as far as I can tell. Again, I've confirmed that the 1284p, the A4988, and the motor itself all work when programmed correctly with an Arduino sketch. I've also tried swapping the pin definitions for Step and Direction (switched 2 and 3), but I had the same problem.
A possible cause for this I think could be my LCD: It requires the user to define an analog pin for reading the buttons (a quirk of the LCD design). In my pins_MELZI_TRONXY.h and pins_SANGUINOLOLU_11.h files, Marlin defaults to using #define ADC_KEYPAD_PIN  1 (analog pin 1) with the ZONESTAR_LCD selected. On the 1284p, pin 3 (the Z-Step pin) is also listed as AIN1. On the PCB layout for the Melzi 2.0, this pin isn't connected to the 10-pin LCD header. The pin the LCD is actually using is the A1 header pin, which goes to PA1/ADC1 on the 1284p.  But perhaps this definition has caused some confusion in the firmware?
To be clear, the relevant parts of my firmware look like this:
#define ADC_KEYPAD_PIN                     1
        //from pins_SANGUINOLOLU_11.h, which is - as far as I know - the only place this is defined.

#define LCD_PINS_RS                           28 //RS           28
#define LCD_PINS_ENABLE                       29 //EN           29
#define LCD_PINS_D4                           10 //D4 -> RX1 -> 10
#define LCD_PINS_D5                           11 //D5 -> TX1 -> 11
#define LCD_PINS_D6                           16 //D6 -> SCL -> 16
#define LCD_PINS_D7                           17 //D7 -> SDA -> 17
        //the rest of the LCD pin definitions from pins_MELZI_TRONXY.h

#define Z_STEP_PIN                             3
#define Z_DIR_PIN                              2
        //my Z-stepper settings from pins_SANGUINOLOLU_11.h, which I'm pretty sure is normal for all Melzi boards

If anyone can provide any insight into this, it would be hugely appreciated! I'm very new to 3D printer configuration and repair, so I'll gladly take any help you can provide!

Not that I could help here, but does it work with LCD disabled? (You can send G-code commands via serial terminal, can't you?) Why did you have to redefine anything in "pins.h", when "pins_SANGUINOLOLU_11.h" already contain section dedicated to MELZI boards: // LCD / Controller #if HAS_WIRED_LCD #define SD_DETECT_PIN -1 #if HAS_MARLINUI_U8GLIB #if ENABLED(LCD_FOR_MELZI) (and so on) ?

@octopus8 What I meant by "my pins.h files" was the "pins_MELZI.../pins_SANGUINOLOLU...h" files, sorry for the confusion. I edited the post for clarity. On the other note, I have tried operating it with ADC_KEYPAD_PIN disabled and it didn't appear to behave any differently, but I'll try disabling the LCD if nothing else works.

You might actually be seeing intended behavior. A 5uS blip is not technically out-of-spec. The A4988 datasheet lists a minimum pulse duration of 1uS. The MINIMUM_STEPPER_PULSE is configured in Conditionals_adv.h and equal 1uS for the A4988. You could try increasing this value.

By avoiding pin 3 entirely, the Z-axis steppers have started to move correctly. My bed heater went out a while ago, so I redefined the connections in Marlin to use that pin (pin 12) as the Z-step pin, connecting it to the A4988 accordingly. This has caused no issues other than small noise problems so far. Unfortunately, I can't speak to any potential issues pin 3 may have had to cause this behavior, all I have is this one potential solution.


text:
Marlin RAMPS 1.4 reboot problem while printing via SD card
I have a custom 3D printer with RAMPS 1.4 and Arduino Mega 2560 (clone). I installed Marlin 2.0.7.2 firmware and I tested all the motion and heating parts individually and all of them work fine.
Also, I activated SDSUPPORT and the printer can read my .gcode files from the SD card. When I try to print a 20 mm calibration cube by using an SD card, starting G-code works fine (printer goes home point) at the time of reading G-code from SD card, LCD goes weird and after 2 seconds printer reboots itself.
For now I can't print via USB because of distance and cable issues, can you give any suggestion to handle this?

@agarza - Thank you for all of the recent top quality edits. Keep up the good work. Thanks again. :-)

Hi M.SEL! Does it reboot always at the same point - or rather randomly? I wonder if it still could be bug or misconfiguration in firmware or on hardware level (activating board reset, etc.) or some more complicated problem, like floating voltage or some short/dry joint activated by vibration... Doe the same print work OK when executed from serial terminal, or you could never try even once?

@octopus8 hi . it seems it reboots always at  the same point , as if it cant read G-codes from SD card properly.i tried another SD card but same problem occured . i couldnt try serial terminal yet

Try then to narrow down to specific command or command sequence. I.e. execute single lines, but better avoid Marlin's "stop" routine... so I propose following: from the original G-code file, generate more *.gcode files, containing: only 1st line, only first 2 lines, only first 3 lines, only first 4 lines, etc. Then check if they will be properly. Or if not at least one will execute properly, then maybe SD reader or connection is an issue (just compare to https://reprap.org/wiki/Melzi, the 3rd bullet from the bottom)...

I have the exact same issue, did you find a fix to it?

@EstebanYañez yes , i  removed bootscreens and other needless configs that consumes progmem , i think problem is related with memory , you can also try different arduino mega board or use original one

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
OctoPi command v412-ctl not found
I try to set up the focus of my Logitech C920 in OctoPi. I follow several guides, which all propose to set the command sudo v412-ctl --set-ctrl=focus_auto=0 by SSH'ing OctoPrint.
I always receive the answer in SSH, that v412-ctl command not found.
What's wrong?

It's an l (ell) not a 1 (one).

It's an l (ell) not a 1 (one). v4l2-ctl.

well spotted! :-)

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
What are ways to avoid heat creep?
Printer configuration and many settings affect heat creep.  Heat creep stopping extrusion doesn't necessarily involve melting the filament too high above the nozzle.  All it takes is making the filament too soft.  The filament may bend and wad up (the importance to avoid gaps in the hot end allowing this).  On direct drives (not Bowden tubes) the filament can get soft so that the teeth on the direct drive cuts a notch in the filament instead of pushing it through the nozzle.
[moved to answer]

Fig. 1: Some typical signs of heat creep on the filament of a direct drive.  1) notch in filament where gear spins in soft filament. 2) normal teeth marks in filament. 3) soft filament bending. 4) soft filament bunches in open area. With a Bowden tube, the filament widens at the end.

Fig. 2.: Another example of heat creep with a direct drive extruder.
Note: Setting the retraction too high can cause the extruder to jam, but this is not heat creep.  Although, the symptom could be mistaken for heat creep.
Also note: Printing materials like PETG too fast can clog the nozzle because the filament doesn't have time to melt.  This is the opposite cause from heat creep.  On some direct drive extruders you can tell the difference in the appearance of the jammed filament moving too fast versus heat creep because the filament is rigid when  moving too fast and tends to jam in the nozzle giving a similar appearance to heat creep in Bowden tubes extruders.  When PETG jams in a direct drive as shown in Figure 3, both raising the temperature of the extruder (more heat to melt the filament) and improving the cooling of the heat sink (drive teeth digging into stiffer filament) also helps.

Fig. 3.: Filament with end expanded in nozzle showing jam from filament moving too fast and not heating enough.
A defect in the filament can jam in the tube to the hot end, as well as the filament hanging up on the spool or in the path to the hot end.  This can also stop extrusion.
Of course different materials change the characteristics of heat creep, but what are other things affecting heat creep?
This is expanded from How is heat creep characterized?

Actually, I just had thought I need to fight heatcreep on my hotend yesterday... turned out what I thought to be clogging and heatcreep was actually the filament not getting through the extruder  because there was a blob on it.

I've found I need to trim off any bends and distortions in the filament caused from removing it from the hot end or a docked end to the spool.  The shape of the trimmed end is also important.

What I meant was, there was a literal spot that was way thicker and wouldn't enter the filament tube because it was too thick for the fitting. and I thought that it was the hotend. I was prepared to fight heat creep with any means necessary and it was bad filament.

I haven't had any filament troubles other than trying to run some old PLA exposed to atmosphere.  It had too much moisture and kept breaking off when feeding to the printer.  I assume the tick area was too soon in the tube to be steam expanding the filament.  Hopefully the filament doesn't have more spots.

well, I hope so too, but it wasn'T the hotend, that much is sure :) I just meant to tell a cautionary tale that the reason one assumes heatcreep or clog might actually be a bad spot on the filament.

I think it'd be a good idea to move the introductory material including the list of causes to an answer, and focus here on a question like "What are the factors that contribute to heat creep?" As is, the question reads more like a statement with a "did I miss anything?" sort of question at the end to justify this being a question at all.

I think @Caleb has a very strong point, in its current format, it isn't a great question, which we might have to close if this isn't cleaned up. It would be a shame to lose the content, so please address the question and post part of it as an answer. Alternatively, post an answer on the linked question and ask more specifics here linking back to the other question.

Now people will complain about me answering my own question.

@PerryWebb It is perfectly valid to answer your own question, SE even encourages this! Share your knowledge. Thanks for your efforts.

Things to consider (This is expanded from How is heat creep characterized?):

The air volume of the cooling fan on the hotend heat sink affects the temperature gradient across the heat sink.  Usually the size/geometry of the fan depends on the printer design, so the main parameter of a fan that controls air volume is the rpm.  I've noticed fans fitting hotends from 6,000 to 10,000 rpm.  The higher rpm the better as far as preventing heat creep.  Of course, make sure the fan is spinning properly.

The raising the temperature of the extruder increases the chance of heat creep.

A high resistive connection to the sensor will cause a lower that actual temperature reading.  Thus, the controller will raise the hotend to a higher temperature than set, which can cause het creep.

Razing the temperature of the heated bed, especially when the printer is in an enclosure, increases the chance of heat creep because this raises the temperature of the air the fan blows across the heatsink.

What can be useful is using higher extrusion and bed temperatures for the first layer, then set lower temperatures on subsequent layers  to reduce the chances of heat creep.

The slower the print speed the higher the chance of heat creep.  That's because a slower print speed gives the filament more time to heat up in the extruder.  Many slicers have a setting that slows down the print speed if a layer will finish below a given time.  If this slowed down time causes heat creep, the extrusion will stop when the printer reaches these smaller area layers.

Too much travel of the extruder without extruding has a similar effect because the filament isn't moving.  I verified that connecting isolated structures on a design with heat creep can eliminate it.  Using a little more material for thin walls is better than scraping prints.

Example: This is easy to demonstrate with PETG.  Design a table printed top down 100 mm square with four legs 5 mm square and 100 mm long.  Set the parameters so that you start to get heat creep when printing the legs.  Now put four 1 mm thick walls between the legs to get the heat creep to go away.

Sometimes if you start a second print without letting the extruder cool down from the first print, heat creep will cause the extruder to jam.

The heater block might be too close to the heatsink so that they bypass the heat breaks reduction in conducting heat.

Hotends for temperatures 245 °C and below can use such things as Teflon tubing in the heat break to isolate the filament from the metal.  But, +250 °C nozzle temperatures need all metal hotends.

The PID settings in the firmware might be letting the hotend temperature overshoot too high.

Re: #1, fan air volume, with cold ends that have a solid-ish mass of heatsink (E3D Titan Aero for example), static pressure is an important spec- how well the fan cools when pressed up against a heatsink. A printer I bought that came with a Aero and 10mm thick Noctua fan had all sorts of problems jamming- the fan didn’t have enough static pressure to keep the heatsink cold. The 20mm version fixed it: better static pressure.


text:
Calibration cube quality
I built an i3-style printer (it started a few years ago as an Anet A8 and now I replaced basically everything). I've been printing some stuff that doesn't really need to have a good quality look or dimensional accuracy, but now I decided to print a calibration cube and the results are shown in the figure below.
Does anyone have any tips on improving the quality of this print? The height is exactly 20 mm but the width and length are affected by the uneven layers.

About the changes I made to the A8, basically I started with a steel frame but eventually all the electronics and mechanics were replaced to achieve something similar to the 3DSteel V2 from HTA3D.

Welcome to 3DPrinting.SE! It looks like you are slightly over extruding, and repetitive striations usually indicate a mechanical problem, e.g. lead screws movement translation to print nozzle. For an A8 it doesn't look that bad, what upgraded you did? Please include that in the question by [edit].

The last changes I made were to replace the A8 T8x8 lead screws to T8x2 ones, so I believe they are still straight. The one thing left to replace are the elastic couplers connecting the lead screws to the Z motors. I'm thinking about replacing them with the spider couplers - do you think it will solve anything?

Tightening the belt?

Check your filamentwith a caliper capable of showing at least two decimal places. If the diameter fluctuates, it can cause over- / under-extrusion which would appear like this. Also check the rigidity of your frame. Try pushing with one finger on different parts of your machine. You should not be able to move, twist, rotate any parts that are not intended to move in that direction. (a bed should move only in Y direction and should not move in X direction and should not rotate along the Z direction).


text:
EcubMaker TOYDIY 4-in-1 3D Printer Toolhead Hits Platform
I have an EcubMaker TOYDIY 4-in-1 3D Printer. When using the FDM Dual Toolhead, it runs into the platform and I have to shut it down to stop it from making saying terrible sounds. I did use the last engraver and it worked just fine, but the single FDM Toolhead did the same thing, only it was to the top of the machine.
This is happening during the auto home function prior to and when trying to print. The toolhead slides to the Y-axis stepper motor, bumps it, the light on the sensor comes on, then it slides to the left about halfway and begins to ascend. When it reached the top with the single FDM toolhead, it kept trying to go up until I shut the machine down. So I changed it to the dual toolhead and now it goes to the top, backs away, slides to the left some more, and the platform moves into position. The toolhead starts descending and doesn't stop when it runs into the platform, so I must turn it off.
This is new to me, but after changing to the dual toolhead, it went through the whole cupcake cycle just fine and printed my part fantastically, not this problem started once I tried to print another.
I tried resetting to defaults, changing the Z-offset to the one on the manual, but it still hits the build platform.
I updated the firmware to 1.2.9 and now it will do auto-home correctly when I set the Z-offset to 0 just to test it. But when I set the Z-offset, using the auto Z-offset, then click save and exit, and try to print, it still runs into the platform.
The end stops do work because when doing the auto-Z-offset function, it probes the platform several times. I thought maybe it could be a setting in the EcubWare slicing software, but the rest of the print does the same thing. I can't get any answers from support, because I think China closes down until the 19th, for the New Year, and I had something I need to print for Valentine's Day.
Resolution: I have since returned the printer, but it was a problem with the Y-axis endstop being too far away, by several millimeters. But once I moved it, it wouldn't print more than the first layer, over and over again, until it completed the print. I imagine the problem is the Z-axis carriages might be loose, since so many parts of the printer were not completely put together, or tightened properly. This machine had too many issues for $599.

this seems related to either the endstop postion or a wrong firmware definition.

Please cut the resolution text and paste this into a separate answer as this is the solution that worked for you. You can even accept it after 48 hours.


text:
Is there an easy way to add rounded edges to semicircle in OpenSCAD?
I've put together a flashlight mount for a camera coldshoe in OpenSCAD.  I originally modeled it in FreeCAD and it was easy to round the edges of the clamp with a fillet and that makes it a little easier to get the light in and out of the mount.
I'm not sure how to do it in OpenSCAD.  Naively, I'm sure I could calculate where on my semicircle I would need to add some cylinders in order to round the sharp corners, but it seems like there'd be something a little easier than that.
Am I missing something?
Here's the coldshoe light mount SCAD file and this is what it looks like:

I'm far from a wizard with OpenSCAD, but enjoy using the program, learning something new every time. In your case, it's likely that you can use the roundanything library to accomplish your objective.
The library will present various implementations in the samples, making it an exercise for the reader to determine which module calls will present the solution.
The image below shows a part which has had the radii applied in a manner similar to your image:

If you're modeling as a 2D object and extruding with linear_extrude, you can use the offset tranformation with positive r on the (initially undersized) 2D object to smooth corners.

I ended up taking a third option I suppose.  I decided I was cutting the gap wrong.  I was using difference to take a rectangle out of the ring.
I decided I'd simplify that and take out an extruded triangle.
ringRadius = radius + thickness;
verticalOffset = tan(gapAngle / 2) * ringRadius;

linear_extrude(height = height)
    polygon(points = [[0, 0], [ringRadius, verticalOffset], [ringRadius, -verticalOffset]]);

That way, the thickness of the plane that needed rounding is uniformely the thickness of the ring.  Then, it was just a matter of adding cylinders, centering them in the ring, and rotating them into position.
for(side = [-1, 1]) {
    cornerRadius = radius + thickness / 2;

    rotate([0, 0, gapAngle / 2 * side])
        translate([cornerRadius, 0, 0])
            color("blue") cylinder(r = thickness / 2, h = height);
}

Eventually I'd like to make it a little more complex and help accommodate a light better, but for now it gets me the rounded ends I was looking for.

I'm still going to accept the round everything answer because, though I decided it was more complexity than it was worth on this model, it looks like it would solve other rounding issues too.


text:
Ender 3 Pro build not getting power after initial setup
I have an Ender 3 Pro that has yet to be used, since after initial out of the box assembly it doesn't seem to get power. I plug it in, flip the switch, and nothing. No fan in the PSU, no screen flicker, no sign of life in any way.
Double checked all the power cables going from PSU to motor, screen, extruder, etc. and they are all secured. The XT60 cable is firmly connected.
I checked the outlet, but it powers my desktop PSU fine. I checked the cord, but it works for other PSUs. I assumed it was the power supply, but replacing it with a new one gives me the same issue.
What other steps can I take to diagnose/fix this issue??

Have you checked the 110/220 V switch?

Hi, welcome to 3DPrinting.SE! So, you checked and replaced the PSU and still no power to the controller board. You must have a broken controller board then, or some cables? This sounds like a DOA, you should have contacted the seller immediately before tinkering.

@agarza No I haven't, what should I do with that? I'm assuming you mean the voltage switch on the PSU to select input voltage?

@0scar Yeah I probably should've, but I assembled this a while ago and then got super busy with school and work and forgot about it. Controller board sounds like a likely culprit, as the wires all look in fairly good shape and the connections are decent as far as I can see. Thanks for the info.

You can check whether a power supply is woking by looking at an LED near the output cables. Most power supplies have a(n) (green) LED connected to the output that lights up when the PSU is (mostly) working. If you want a more precise check, you can use a voltmeter to check the output voltage, it should be either 12 V or 24 V depending on the power supply (I think Ender 3 V2 uses 24 volt, but I am not sure). You say you have the same result with two different PSUs, which means you should look elsewhere as others suggested. Some mainboards use fuses, some do not, check whether those fine.


text:
Is there a well-tested Ender 3 printer profile for PrusaSlicer available for download?
I am very comfortable with using PrusaSlicer and having a hard time adapting Cura.
Is there any downloadable well-tested PrusaSlicer profile for some of the Creality printers?

Open PrusaSlicer, go to Configuration -> Configuration wizard, then go to page named "Other Vendors", tick the checkbox next to the name "Creality", then click "Next" at the bottom right of the window. A page with a handful of Creality printers should appear including Ender 3. Tick the checkbox under Creality Ender 3. Then click "Finish" at the bottom right. The profile should appear in the selection.
It imports various print settings (from 0.3 mm to 0.08 mm I believe) as well as some basic material presets. You can import more materials by just going to the "Filaments" page in the Configuration wizard and ticking the desired options.
The profiles are tested by PrusaResearch themselves I believe and I think they are based on other profiles found online with some tweaks and adjustments to better fit to PrusaSlicer.
I am using PrusaSlicer 2.3.0
Here is an image, what it should look like. Your colors might be different, I asume you are using Windows, wheras I am using Linux Mint.


text:
BLTouch error causing bed and nozzle temp setpoints to change to zero
I replaced my CR-10 motherboard with no problems and ran fine for a few weeks, then decided to add a BLTouch. BLTouch was enabled from the config.h during compile.
I had heating issues at first but eventually figured out I had the thermistors plugs swapped on the motherboard. In the past, I never used start and stop G-codes because I only printed printer upgrades off of Thingiverse while learning to print. My prints weren't starting until I learned more about G-codes and added G29 and G29 to my Cura start codes.
I tried a piece that I've printed before because I knew it worked ok. I preheated the bed and nozzle first, then started the print. The G28 initiates and homes, then the G29 does the 9 point bed leveling, then just sits there and does nothing.
BLTouch behavior during the process

BLTouch moves to "home" from center, with probe up and red light
With the light still remaining red, BLTouch goes back to the center
The BLTouch light turns blue once at the center, and drops the probe and lowers until probe touches and the light turns red
Then raises again and the light turns blue, lowers again until probe touches bed then the light turns red again
The light stays red and raises Z axis a little - and stays at center, still red
The probe stays at center and red until reaching preheating temps
After selecting file the probe moves to 9/9 points, with probe raised and blue light (drops probe and lowers until touching and turns red, then raises and turns blue)
Once the last probe location is checked, BLTouch is still red and temperature settings from project file are set and heating starts
The setpoints of bed and nozzle are reached (successfully heated)
After heating, the setpoints switch to zero and temps start dropping towards the zero set point (cooldown) and never moves after that and shows status "Stopped"

Pronterface - manual attempts
I connected through Pronterface so I could see the exact details.
When I run a G28, from Pronterface:

It goes to lower corner and is still red
Returns to the center, probe drops and turns blue
A few seconds later it drops until touching the bed and turns red
Raises up again and turns blue, then drops BLTouch again until it touches the bed and turns red
Then raises up again, but stays red this time
I get an error in Pronterface "Stop called because of BLTouch error - restart with M999".

After it levels 9/9 points1, Pronterface shows a BLTouch error, the printer display shows print stopped, and the bed and nozzle setpoints had changed to zero. They both had already started cooling. I kept the start code simple just enough to get the print going.
I have no idea what the BLTouch error is but just that it caused two temperature settings to go to zero. Any help would be great!

1 The 9/9 points I'm referring to is when I run G29 and my config has 3x3 grid option selected so the G29 probes 9 points total with the BLTouch.

Temperature is reset because printer (emergency) stops the print, I bet it is not correlated to the G29 procedure. Please describe behaviour of the BT light during and after the process. How did you enable BL-Touch? from LCD?

@Greenonline Not sure how to close this but I managed to figure it out, decided to try moving the Z-axis wires from the BLTouch plug on the motherboard and plugged them into where the printers Z-axis wires plug in and that solved the problem. No more errors and the print continues now instead of shutting down after the G29 command.

I was wondering if it had something to do with my Z-axis and BLTouch. When I unplugged the Z-axis on the printer, the extruder wouldn't lower, only raise; so I plugged it back in, and it moves in the right direction. The motherboard I'm using is a SKR E3 Mini V2 and the BLTouch is 3.1 On that version motherboard, the BLTouch plug has all 5 wires combined in one plug, whereas on other versions it has a three-wire plug for the BLTouch, and the wires for the Z-axis from the BLTouch have a separate two-wire plug with its own plug-in spot. But I've read about instances where users had to plug those two wires into the motherboard's default plug for the printer's Z axis which is usually unplugged. I decided to unpin the BLTouch Z-axis wires from the 5-wire plug and unpin the printer's Z-axis two wires and repin that plug with the Z-axis from the BLTouch and plug into the spot on the motherboard that is normally used by the printer's wires, and that fixed the problem. There's information on GitHub that the board manufacturer posted about the issue, and thankfully that was my exact problem.


text:
Replacement Z Probe for MP10
Has anyone successfully replaced the inductive Z probe on the Monoprice MP10 (Mini or regular) with a different type, such as BLTouch or IR?
I find that the stock inductive probe isn't so accurate, and since it's inductive it only works with the aluminum build plate but not with glass or PEI, which I much prefer.

From Thingiverse you can find a BLTouch mount for the MP10 (and MP10 mini):

Note that in order to use the BLTouch sensor you need a different controller board that supports connecting a BLTouch sensor as the MonoPrice controller board doesn't support connecting a BLTouch sensor.
From ref.:

A BLTouch adapter for the Monoprice MP10 & MP10 Mini. NOTE: you will need an open source control board to get this to work as the stock firmware on the MP10 line of products does not allow for a BLTouch.

What control board did you use?

@SZH I don't own a MP10, but there are plenty of boards out there nowadays, you are doing good by investing in a 32-bit controller board with enough drivers and options.


text:
How to programmatically resume a paused print in Marlin
A print that is paused with an M0 can be unpaused with M108.
That works with my Chiron running Marlin 2.0.7.2.
However, it also has a display that uses its' own serial protocol to communicate with Marlin. I want that display to be able to unpause my printer when it has encountered M0 in the G-code.
I tried injectCommands_P(PSTR("M108\n")); in the code, but it did not work. Perhaps I should not have a new-line at the end of it.
What is the correct command to do this?
void GcodeSuite::M108() {
  TERN_(HAS_RESUME_CONTINUE, wait_for_user = false);
  wait_for_heatup = false;
}

Above is the Marlin code for M108. Would be great if someone could decipher what TERN means.

TERN is short for "Ternary Macro". Scroll down on this web page to find what it is used for. Basically, this is an if-then statement.

under pause, the next line of G-code isn't read

The correct Marlin-command to unpause seems to be setUserConfirmed(). I have tested that it works.


text:
XYZ DaVinci Mini W "jamming" after exactly 5 layers
I have a DaVinci Mini W that throws a jam error after exactly 5 layers, even if the extruder isn't actually jammed. Is this real jamming, or unethical business practice?

Mini W has both a sensor that checks if there is filament, and a second sensor wheel that checks that the filament is actually moving (so it can deduct available filament length on the NFC tag).
If the moving sensor is not detecting anything for some time, the printing will stop and the LED will go red. I do not know if that will show up as a "jam error" in XYZware or if this is what you experience, but it is my best guess.
I guess the same would happen if you remove the NFC-tag mid-print.


text:
Is there a known fix for when the Photon S has trouble reading from USB flash drives?
I have a new Photon S that I was able to print twice with so far. I've only been able to print the sample file on the Anycubic web site. When I tried to print my first custom object, it wouldn't read the file. It would just popup a message saying "Failed to open file!" I thought that my file might have a problem with it so I tried to print the sample file that I already printed successfully. Same error.
I read that it only supports 16 GB drives so I tried one and it didn't work. I asked people on the FB page which drives they are using successfully and the SanDisk Cruzer was recommended. I got two 8 GB versions of those. One worked intermittently, the other didn't.
I bought a USB tester to check the voltage and found that the voltage was 4.99 coming from an empty port. When I inserted the drive that worked, it dropped to 4.92. The drive that didn't work dropped to 4.93. I asked a fellow Photon S owner what his reads and it was 5.15 empty and 5.11 with a drive in it. My PC has a voltage of 5.20. All of these voltages are within the range of the USB standard but I think my sub 5 volt value has something to do with the failure.
Does anyone out there (an EE) know what's really wrong and has an actual solution or can tell me what I should look for? I know that there are a lot of guesses in the community. Stick with max of 16 GB. Try different sticks. Check internal cable (I also inserted the drive directly into the motherboard), etc. Communicating with a USB drive shouldn't be guess work as long as the drive is of good quality. The guy I asked uses a 32 GB stick which is the FAT32 limit for the standard Windows formatter.
Any help will be greatly appreciated. Thanks.

could be a lot... what format do the files have you want to print? What formating you have on the USB dongles?

I do not have experience here. But I have read Help, Photon S Failed to open File, and reviewed few other random threads, and I feel dizzy. Limit files to one? Rotate and reslice?! It seems that this printer is not properly prepared to read thumbdrives or filesystems? What I would advice is to try format with FAT and FAT32 using different cluster size settings...

I actually did full reformats on the drives. They're formatted to FAT32 with 16k clusters. The files are .PWS from their new Photon Workshop slicing app. @octopus8, isn't it dizzying? They're just posting things they tried before it suddenly worked and calling that a solution. There must be a flaw in the board or a flaw in the soldering of the board. I'm going to keep looking. I want a real, repeatable answer. Thank you for your comments.

I should add that I'm running the latest firmware and was able to print after the updates before it started failing.

Have you confirmed that the USB drives are genuine? Even major outlets have had problems with their supply chains. 5 Tools to Test and Detect Fake or Counterfeit USB Flash Drives lists some utilities to check.

There's no problem with them in a PC, not sure why there should be issues in this printer. Even when I copy files to it, I use the /v flag so the copy is verified.


text:
Ender 3 + SKR 1.4 + Marlin 2.0.x bugfix - what bed size/min/max positions should I use?
On my Ender 3, it seems that the Y-axis can only move forward 220 mm after which the carriage will hit the tensioner. This seems repeatable so I don't think it's a hardware issue (unless it's expected that the nozzle can reach all the way to the front edge).
I'm unclear, with this information, how I can center my nozzle properly so that it is 117.5 mm from each edge, and that the corner leveling feature works as expected (by default, configured to be 30 mm from each edge).

Hi Alex. Are you able to properly home the printer, or not? I understood that after you home, the Y movement is limited by your hardware setup (mounted tensioner) to only 220 mm. But you would like to have full 235 mm. What tensioner is installed there? From your description I could read that there is a collision, so I would say it is a hardware issue... If you can home the printer, you can limit the print area.

The Ender 3 has a printable area of 220x220x250 mm according to the specifications. So, there is nothing wrong. Sometimes heated beds are slightly larger than the actual print area. E.g. 235x235 mm or 310x310 mm. For centering the nozzle to the build plate, you should look into "How to center my prints on the build platform? (Re-calibrate homing offset)" or "Recalibrating Home-position.


text:
Marlin: Why is the extruder stepper jerking?
Environment:

Printer: Anycubic Chiron,
Firmware: Marlin 2.0.7.2,
Settings: FWRETRACT is not enabled,
Slicer: Cura 4.8.0.

When I print using the code below (it is longer, but I do not know where to put attachments), I can see that the extruder-gear is jerking, as if it tries to do tiny retractions between every little movement. Real retractions happens where they should and seems fine.
If I slow down the printing from F2400 to F600, it is almost gone.
I don't say it is a problem, the printer works. I wonder if there are settings that can cause this, if it is as expected or if I can do anything to make my printer work more quietly.
Short film
; example G-code for noisy extruder stepper
; PLEASE DO NOT RUN ON YOUR PRINTER unless you know what it does.
M302 P1 ; disable cold extrusion checking
G0 Z5
G0 F2400 X214.8 Y177.1
G1 F600 Z5
G1 F2400 E0.20522
G1 X214.866 Y177.134 E0.20647
G1 X214.934 Y177.161 E0.20890
G1 X214.923 Y177.189 E0.20990
G1 X214.912 Y177.217 E0.21090
G1 X214.907 Y177.229 E0.21133
G1 X214.813 Y177.456 E0.21927
G1 X214.793 Y177.480 E0.22031
G1 X214.540 Y177.791 E0.23364
G1 X213.982 Y178.218 E0.25701
G1 X214.155 Y178.986 E0.28319
G1 X214.757 Y179.315 E0.30601
G1 X214.962 Y179.542 E0.31618
G1 X214.990 Y179.574 E0.31760
G1 X215.109 Y179.775 E0.32537
G1 X215.124 Y179.801 E0.32637
G1 X215.140 Y179.827 E0.32738
G1 X215.105 Y179.848 E0.32874

I have absolutely the same problem with my custom build printer. I think it's the voltage/current the stepper driver provides, but didn't have time to test it yet. I hope someone can provide an useful answer.

You can post your movie on YouTube or something similar and post a link here.

Quite good analysis of basic possible causes. Could this be just extrusion wheel slipping on filament - or stepper looksing steps due to pressure?

I have bad roller-bearings. That cause extrusion wheel and stepper-motor wheel to be further apart at some parts of every turn of the extrusion wheel. This explains the noise.

But it does not explain that the stepper seems to retract a tiny bit after many/every G1 movements. I have today tested to increase/decrease current through the stepper. Normal voltage for Chiron stepper seems to be around 0.9V. I run the E-stepper at 0.7V. I tested up to 1.3V, but that made no difference. At 0.5V, I could force rotation by hand, so the stepper got weaker as expected.

The setting that makes these small retractions is LIN_ADVANCE.
It is found in Configuration_adv.h and is disabled in the vanilla configuration.
I, on the other hand, is using one of the 46 example configurations that has this feature enabled. It shall be said that most of them them has the value 0 set to this, which means that it has no effect.
To disable the effect of this feature, send G-code M900 K0 to the printer.
More info at marlinfw.org
More info at 3dmakerengineering.com
M900 - If it works, the feature is enabled
Test pattern generator to tune LIN_ADVANCE


text:
Mixing (closed loop) stepper drivers on MKS main board
Can I mix BIGTREETECH S42B closed loop stepper drivers on the MKS Gen L controller board with other drivers?
Are the pins in the same position? Would mixing work?

As far as I know, that should work. You need to define the correctly used drivers in your configuration. For the closed loop drivers, the board (via a break out board) has to provide the pulses to the motor driver (on the back of the stepper). If you use such a closed loop driver you need to disable the stepper driver type in your Configuration.h file for those you plan to insert a closed loop driver. The firmware will assume the A4988 driver is being used:

Now you need to set high enough values for the MAXIMUM_STEPPER_RATE (150000):

and the MINIMUM_STEPPER_PULSE (3):

in Marlin/src/inc/Conditionals_adv.h under HAS_DRIVER(4988).

Hi Oscar, thank you very much! I got a gd deal on some mks tmc2208 and an skr 1.3; couldn't get a deal on closed loops :/ will report bck.


text:
Can I use photoelectric sensors to make auto bed leveling on a glass bed?
I'm pretty much a noob to the 3D printing community. I got a Creality CR10 V2 as my first 3D printer and I know it's compatible with BLTouch but not included in the package. So I'm dying to add an ABL feature to my 3D printer but I'm on an extremely tight budget right now. However, I found some industrial IR sensors (two Omron E3Z-D82 and five Keyence PZ-M71) in my toolboxes. I know those sensors are pretty expensive and totally overkill for ABV but I want to use what I got in my hands.
So the question, can I use those sensors for auto bed leveling? I should say that my printer has a glass build plate. By the way, I'm also open to different cheap alternatives
Here are the links to the sensors for more information:

Omron: https://industrial.omron.eu/en/products/E3Z-D82-2M
Keyence:
https://www.keyence.eu/products/sensor/photoelectric/pz-v_m/models/pz-m71/

Are you aware of this? https://www.youtube.com/watch?v=il9bNWn66BY

Yes, saw that video. But my Sensors are not proximity sensors. They are more industrial type sensors with quick response times. I did test both omron and keyence and the results are not promising. Still trying to figure out. Thanks

Are you sure you want to use a 70 gram sensor on your carriage, when a BLtouch costs 35 Euro and weighs 10 grams? also, I'm not sure how reproducible the measurements are. I couldn't find any data about repeatability.

3D printers like the German Reprap (see image) already uses a photosensor for homing the axes.  The trick will be leveling the leveling sensors.
However, if you use an optical sensor measuring distance, you could mount it on the hotend like we do digital indicators (drop gauge). See Bed leveling method?
You would want a resolution of about 0.01 mm.  That method will keep you planer to the movement of the hotend.  For automatic leveling the photosensor needs to input to your software.
If you want to permanently connect the photosensor to the hotend, probably the most practical communication method would be USB, which could supply power as well as communication to eliminate batteries.  The USB cable could run in the path of the other hotend cables.  Less weight on the hot end is if you could remote the laser and detector from the electronics.
If only attached during leveling, batteries and wireless connection is better.
I'm finding more digital drop gauges (second image below, data in cable is USB) with computer interfaces than photosensors.  Many of the photosensors would need to interface with a meter first.  Because a  drop meter makes physical contact, it's not practical to leave on the hotend during printing.

These industrial sensors won't seem to work I think. At least I'm not comfortable enough to tweak firmware  for now. So I will try to imitate bltouch with an optical interrupter and a micro servo just to be at the safe side. Thanks for your help


text:
Z banding issue
I'm currently facing a Z banding issue that frustrates me more and more.
My printer is a modified Anycubic I3 Mega.
Customizations:

Mainboard: Bigtreetech SKR 1.4 Turbo
Stepper Drivers: TMC 2208 v3
Hotend: E3D Titan Aero
Hotbed: 5 mm aluminum base plate with a 200 W 12 V silicon heat mat and 3 mm hard paper as print base
External MOSFETs for the hotbed and hotend each
Bigtreetech 3.5 inch TFT screen as display
BL Touch sensor
Marlin version 2.0.6.1

What I tried to fix this issue:

check leadscrews for debris
cleaned leadscrews and applied new grease
checked Z couplers and hand tightened all screws
checked tightness of the Y/X axis belts
increased the driver current
replaced the 12 V 25 A PSU with a 12 V 30 A PSU
Extruder steps re-calibration
PID auto tune for hotend and bed

Pictures of the XYZ calibration cubes I printed:

Used slicer parameters (Prusa Slicer):

material: PETG
240 °C / 100 °C hotend/bed
Infill 30 % with 60 mm/s
outer perimeter with 30 mm/s
100 mm/s travel speed
1 mm retraction with 40 mm/s retraction speed

The number of these horizontal lines and their occurrence is different on each print.
Any ideas?

Hi welcome to 3DPrinting.SE. It looks like your Z crew sometimes misses some steps. Did you measure the height of the calibration cubes.

@0scar My calipers are not that exact but yes, it looks like its a litte bit too small. On my latest print I have 4 of those rings and it measures 19.4mm. During print it looks a lot like the z is not moving up for one layer resulting in printing the next layer on the same hight resulting in squishing the old layer which creates these rings.

@0scar so what could possibly cause these missing steps?

Are you sure the stepper drivers for the Z are correctly configured, enough current?

Yes I am. The current ist set to X 860mA Y 860mA Z1 950mA Z2 950mA E 850mA.
M122 shows no errors or anything suspicious.

So it looks like I finally resolved that issue. I compiled a complete new firmware based on the Marlin bugfix branch. Before I was working on the sources provided in the Bigtreetech GitHub. I started from scratch and put all the settings I needed into the Configuration.h and Configuration_adv.h. Now all rings are gone. Either there was really a bug or something or I messed up something in the firmware I used before and beginning from scratch solved it.

Since I cannot login into my other account I cannot mark this aswer as accepted solution.

Hi Christian, many thanks for returning and posting an answer! Please note question "How can one link / merge / combine / associate two accounts / users? (Anonymous / unregistered / cookie, or Google / Facebook / registered)" which directs to "I accidentally created two accounts; how do I merge them?" so you can fix this!

Ah that's a shame, what happened to your previous login? As 0scar states, the accounts can be merged by the moderators, but it would be easier if you could just use your old account. Oh and thanks for updating the question with an answer, nice one, thanks :-)


text:
Why would all of the Ender 5 Pro's axis motors (X, Y and Z) stop being able to move (all at once)?
I have a Creality Ender 5 Pro which has been working properly for some time. During my last print, the axis motors just suddenly stopped working while the extruder motor continued to work properly.
In fact, when I connect the extruder motor wire to any of the axis motors, they respond correctly (mimicking the extruder motor) but neither works or moves when connected to its own wire(s). As a result the printer does not print anymore.
Here's what I've tried:

Switching the wires around to check if any motors are damaged (none are).
Restarting the Creality
Checking the output on the power source (which is 24 V and about 14 A)
Checking to make sure all motor wires are connected correctly on the SKR MINI CONTROLLER (all seem fine) and checking that the board is powered.
All external connections also seem fine.

I'm quite confused why the axis motors would not be working all of a sudden. I'll appreciate your help if you've faced this problem before.

could be a fried board, bd firmware (if you updated it) or just bad G-code... Does Homing work?

No... Anything that requires use of axis motors does not work. including homing.

can you measure the voltage to the motors on a given command?

@Trish was right. The Creality V1.1.5 board was fried. I replaced it with a BIGTREETECH SKR MINI E3 V2.0 32BIT CONTROLLER. After struggling to find a corresponding firmware for the Ender 5 pro, the axis motors worked correctly.

The Creality V1.1.5 board was fried. I replaced it with a BIGTREETECH SKR MINI E3 V2.0 32BIT CONTROLLER. After struggling to find a corresponding firmware for the Ender 5 pro, the axis motors worked correctly.

Usually, steppers not working can be found when the lines are broken. Often this is an unplugged Stepper, but OP checked that.
That 3 steppers at once failed could indicate a bad firmware update, which OP didn't do. So it is sadly a case of blue smoke from the board. Most likely the stepper drivers are either shortened out or get no signal.
I am sorry, but replacement seems necessary.


text:
Klipper BED_SCREWS_ADJUST and SKEW_PROFILE interaction
Klipper lets you define a skew profile that is loaded / unloaded on demand during START_PRINT / END_PRINT macros called during printing of a sliced file. This seems to be the recommended way to apply the skew in Klipper, in fact it is in the documentation this way: https://www.klipper3d.org/skew_correction.html.
My question is, should I also manually load the skew profile prior to executing the BED_SCREWS_ADJUST built-in command in Klipper?
Or does BED_SCREWS_ADJUST ignore the skew entirely so it doesn't matter?

This is not dependant on the printer, it's Klipper/Firmware.

My question is about Klipper, it is true. :)

The skew correction works in X/Y axis while bed screws helps you correct the ax axis. Since they don’t work in the same axis, I don’t see why they would interfere with each other.

Welcome and thank you for your contribution. When you get a chance, please take the Tour to understand how the site works and how it is different than others.

@victor-lazaro But skew correction I am doing has XY, XZ, YZ component - https://www.thingiverse.com/thing:2972743. I thought this meant Z coordinate is adjusted, similar to a mesh. But I could be wrong! Still a bit unclear about it.

You’re right. My bad. I don’t use skew correction on mine, I just fixed the frame.

After some months with the printer, I think I agree that squaring the frame of my little cartesian printer is simple enough to avoid skew correction in software as well.


text:
Nozzle scraping prints in modified Creality Ender 5 Pro
I'm using a Creality Ender 5 Pro which is modified to produce Direct Ink Writing prints. So far the prints are fine, it's just that at higher layers, the nozzle begins to drag across the extruded material which affects the quality of the print. Also, I'm using a high infill percentage (80 %) as with 30 % the material collapses in the middle.
How should I go about in bringing the nozzle up at the higher layers? I've tried increasing the height of the Z end stop so that the nozzle would not go too far down, but it looks like it doesn't solve the issue. Should I increase the height further?
I also tried to search online regarding this issue, and found that over-extrusion is the main cause for this. However, I'm extruding at the lowest speed possible with the inks I'm using. Should I just increase the print speed?
Additionally, would adding a Z hop command in Creality slicer work?
Any suggestions are welcome, I would really appreciate it!

Creality Slicer is a derivative of an old Cura version.


text:
Is FabLab a registered trademark?
I am starting a new company using 3D printers and doing an advertisement, and I want to use the word FabLab to describe the kinds of field that my company is in.
Can I be sued by using the word FabLab in an advertisement? Is it a trademark? I mean, I can find this and this.
From the links it looks like they all trademarked the same non-dictionary word:
https://trademarks.ipo.gov.uk/ipo-tmtext/page/Results

I believe there is a legal StackExchange that you can use to ask legal questions on. EDIT: Yea Law StackExchange: https://law.stackexchange.com/

You last link is showing no results at all, while https://app.trademarkengine.com/trademark-search?type=search&q=fablab does. Did you post the correct link?

Trademarks are national - in which country?

I did a simple search at www.huski.ai, and found 11 trademarks with the mark word "FabLab".

As you can see, most of them are abandoned, but there are 3 alive ones by a company called JO-ANN STORES, INC. Their categories are something like "paper goods", "fabrics", or "furnitures", etc. So I think there's still room for you to register it under electronics.

Sorry, I needed to learn to use the site.  This site shows Fablab as a word mark, the same way it shows Apple: https://www.trademarkengine.com/free-trademark-search/trademark-search

It depends on where
Trademarks are national.
In the United States of America, the USPTO is administering trademark registrations, but they are not mandatory to get basic trademark protection. The search is available at https://tmsearch.uspto.gov/. FabLab is registered in the US with two Marks that are alive in 2022:

FABLAB is registered for a motion picture production company and STEM project since 2016.
Hybrid FabLab is apparently offering Rapid Prototyping, prototyping advice and renting out a fabrication space.

In Germany the DPMA is administring. Unless you register your mark in Germany, you might not have trademark protection in Germany, even if you have the mark or some protection in a different country - unless there is a mutual agreement to update registers between countries. This is how some marks get an EM entry or an IR entry: European mark or international mark. Their search is available at https://register.dpma.de/ and yields these live results as of 2022:

EM: FabLab is a registered mark from Spain which is not famous and only protects the whole picture-and-text mark.
EM: We Found! Fablab ### is one of two marks that are owned by the same company, it is very narrow and fablab here is not the actual protected part, it is descriptive of the origin.
EM: FabLab is an English-French word-mark on nutrition products
IR: Hybrid FabLab mirrors the USPTO entry above
DE: FabLab is for an image mark for only category Nizza 42.
DE: FabLab München is again an image mark, with a broader list of services than the FabLab mark right above (Nizza 40, 41, 42). overlapping with the mark right before only insofar that they both are for category Nizza 42. However, they are both image marks and look nothing alike, so no confusion is likely.

in general: it might not be registrable (on its own)
Do however note that in most countries a mark is only registerable if it is not descriptive. FabLab, short for fabrication lab, might actually be a little too close to being merely descriptive to be registrable on its own for fabrication services. However, as an image mark a lot more can be registered.


text:
Why are fast printed lines thinner?
I have run the K-factor Calibration Pattern generator to tune LIN_ADVANCE and found that when K=0, the whole middle part of the line is thinner.
I was expecting that LIN_ADVANCE would only make a difference short after where the speed was increased or decreased, as described by the first picture on this page.

So from this picture, it looks as the best setting is around K=0.8 and that is also what was set as default in Configuration.h for Chiron. But when I tried the Printing Direction-setting set to 45 degrees the result was different. Then the best setting was around K=0.4.
The picture below shows a second test, where I set K=0 and just changed the fast speed. The faster the thinner lines were printed. I have tested printing long lines and seen that thickness will not compensate, even after a long time.

So why is my printer printing thinner lines when going fast and not using LIN_ADVANCE? Isn't the number of E-steps per mm printed line constant and not depending on the speed?
Here is a zip-file with the files used and pictures. (let me know if not possible to download)
ADDED 2021-02-22:
To learn more about LIN_ADVANCE I made a second test today. To rule out most of the uncertainties that can affect the result, I let the bed stay heated between all four tests. Every test started at 210ºC, then 200, 190 and last 185ºC. The printer waited more than one minute between each temperature change. Bed temperature set to 60ºC. The lines are numbered in the order they are printed. Each test started by printing four lines at 20 mm/s to get "normal" nozzle pressure. Each line is 20+40+20=80mm long. Today I had acceleration set to 1200 and jerk to 8, which are higher than before (500,5). I changed because I use these values in Cura. Unfortunately, the bed is not 100% flat.
LIN_ADVANCE = 0.0

LIN_ADVANCE = 0.4

LIN_ADVANCE = 0.8

LIN_ADVANCE = 1.2

What I learned from these today's test:

Very little ooze when going from 190 to 185ºC. (#46 is good)
At higher temperatures after pausing for a minute, the printer needed some 10 to 15cm of printing distance to get the pressure back. (#16, #17)
Next time I will print every second line as a reference and test fewer speed changes.
Next time I will also test higher temperatures.
The lines are printed thinner at higher speed, independent of temperature when K=0. (I thought it only happened at (too) low temperature).
LIN_ADVANCE setting shall probably be lower when printing at higher temperatures (affected by filament viscosity).
It might be different behaviour between the grey and the orange filament. Orange looks better, but the grey one sticks better to the bed.
It is fun to do testing. :)

I did another test the first day, where I tested K=0 to K=0.8 and where the speed was 20+50+20 mm/s and the length was 60+180+60mm. Temp was 190ºC. It seems to show that even after 180mm of fast printing, the thickness is not recovered:

The pictures above are uploaded at a lower resolution. Original pictures and the G-code can be downloaded from here.

In your case, since linear advance makes the issue disappear, the reason of the thinner lines is the same as explained in the link you provided:

The section (2) simply is very long because you probably have a Bowden setup which takes more than the length of the middle section to recover. However it does recover, see the first line (k=0) in the first image.
At higher (constant) speed the flowrate decreases further due to pressure in the nozzle causing a reduced supply of filament, but this effect cannot be corrected by linear advance because linear advance assumes a linear relationship between pressure in the nozzle and extrusion.

Why can't linear advance also compensate for pressure at the nozzle? I thought that was the whole point.

@R..GitHubSTOPHELPINGICE Maybe it was worded in a poor way, but linear advance is a correction which assumes a linear relationship between pressure and flow, assuming that the increased pressure basically is absorbed by expansion of the components (which is indeed a linear behaviour). Given the assumption, it anticipates the supply of filament to reach the desired pressure at the desired time. However 1) plastic is non-newtonian fluid and 2) the extruder starts sliding/deforming the filament at higher pressures, adding an additional non-linear term which cannot be compensated by LA/PA.

I'm not sure what you mean by (2). The extruder should not slip at all; if it does you have a serious problem to fix. It does compress the filament but that's fairly well modeled as a spring (linear). It's only (1) that should have nonlinear effects and they should be small until extreme speeds.

@R..GitHubSTOPHELPINGICE I meant also deformation of the filament, so in general the motion of the gear does not correspond to the motion of the filament, see http://www.extrudable.me/2013/04/18/exploring-extrusion-variability-and-limits/

I tested if section(2) would eventually get the same flow by extending the fast part to 180mm, but I could not see that it changed it did.But I  found two possible problems with my setup. 1: I used a low temperature setting (185º). That can also contribute to less supply of filament. 2: Then nozzle height might have been too low during the test. I was aiming for 0.2mm, but then I had problems getting the filament to stick to the bed. I will fix these two issues and run more tests later today.

@dotswwe I run PLA at 230°C for best strength. You can go for 210 if you prefer easier bridging but 185°C is barely flowing

I did a final test to see what Marlin actually does. I removed the stepper drivers and connected a logic analyser to X_STEP, E_STEP and their direction pins. Pulseview has a nice stepper-plugin. Using that I could verify what you wrote. The number of E-steps per mm printed line is constant. This is also true when K-value is high, but where they are placed is different. So even if a 180mm fast-printed line is not enough, eventually the line-width would be the same as for the slow-printed line. I see the disadvantage with Bowden now.


text:
Can't get Y-Axis to move with Marlin firmware
Just as the title says. I feel like I have tried everything. I am compiling the firmware for Marlin on a Megatronics board from RepRap. That shouldn't be relevant, because I have validated that it is a firmware issue (and not a pin assignment/hardware issue).
When I turn it on, the Y-axis is active and just constantly holding. The stepper driver on Y-axis gets pretty warm constantly holding (as does the stepper motor).
When I swap the pin assignments for Y and X then the physical Y-axis moves fine when I manually change the X-axis so I know all the hardware and pin assignments are correct.
All the endstops are correctly reporting open (Z is BLTouch but that is also working).
Relevant software endstops are currently disabled, and default homing position is set to 50 to make sure it doesn't think it is at the bounds on boot.
I have a test firmware that checks all the endstops, temperature, and servos, and all servos work fine. As a sanity check, pin assignments match what is in the pins file.
Does anyone have any idea of what in the latest Marlin firmware would cause a software condition to just hold the y axis and not move? I should note that when I try to manually move it in Repetier-Host it shows that it is moving. When I try to give the home command, no movement on the Y but Repetier changes from red to black indicating it received confirmation of homing.
I am completely out of ideas at this point.

Which Megatronics board do you have? What are the stepper driver types? Have you tried to use a free stepper slot (there are 6, so unless you have X, Y, Z1, Z2, E1, E2, you should have at least a spare slot) and or a different stepper driver? Is the driver correctly positioned? Just some ideas for you to play with!

yeah I have actually tried using a free stepper driver slot. Anything that was tied to the logical "yaxis" wouldn't move. I re did the whole firmware with the default config file and it worked. It was some problem with the megatronics default config file

There is a problem in the Megatronics default config file. I used an other default config file and it worked!

Did you spot the problem in the defective config file?

I have spent sooo many hours going through that same config file over and over. I even found multiple different versions of it, and started from scratch, and it always had the same problem. As soon as I used the default it was fine. So no I couldn't figure it out

I ran into the same problem. After looking into the pin layout for the board I saw the following:
#elif EXTRUDERS <= 2
  // Hijack the last extruder so that we can get the PWM signal off the Y breakout
  // Move Y to the E2 plug. This makes dual Y steppers harder

This prompted me to move the stepper driver and the motor cable to the E2 connector on the board. (The one on the other side of the X connector, Order is Z,Y,X,E2,E1,E0)
That worked for me.
So, you could move the stepper driver and motor cable. Or you could commment/remove that code from the pins_MEGATRONICS_3.h file


text:
Acetone making white stains on heat bed
I recently tried cleaning my CR-10S Pro heat bed with acetone and it made this white stain on it.
Anyone have any solutions to this?

What is the question? You want to remove the white stains or solution to clean the bed. P.S. you shouldn't clean the bed surface area with acetone. You can use is on glass to remove left over ABS residue, PLA or PETG cannot be dissolved in acetone.

Acetone is quite an aggressive solvent, so white residue could be part of your heatbed print surface that is dissolved, and then when the acetone evaporates the dissolved part crystalise on the heatbed again.
Acetone should only be used on PEI sparingly, not at all on powder coated surfaces. Use IPA (Isopropyl Alcohol) to clean of residue between prints. If you have problems with adhesion, you can also start by washing the build plate or surface with water and dish soap (with no other additives). The surfactant in the soap traps oils and other impurities and flush them away, instead of dissolving them temporarily and then depositing it on the build surface again when the solvent evaporates.
Like mentioned in other comments, use IPA or water/dish soap to clean off any residue.

Generally, when using any "chemical substance" I used to try it on a small part to chek the impact, especially when this is special item developed in the lab (with ingredients unknown for a user). Another thing, breathing acetone is dangerous and I take care to vent the room quickly just after using (or work outside).

If you use a build surface such as PEI, acetone frosts your surface, leaving a white film appearance.  If you have no additional surface on a glass or metal bed, it is incomplete cleaning.  If incomplete cleaning, you could try isopropyl alcohol (IPA) immediately after acetone, followed immediately by a water based cleaner or DI/distilled water. (IPA dissolves acetone and water dissolves IPA. Once the film dries the next step may not work.)
You can't clean off a frosted surface.  The black surface of the hot bed in images of the CR-10S Pro appears to indicate that the steel bed has a build surface with a plastic material such as PEI.  Reviews of the build surface being difficult to remove prints also implies a plastic build surface on the steel.  Thus, it appears that the white film after cleaning with acetone is actually a frosted surface.
If you use an Elmer's washable glue stick or one with PWP, it will form a barrier between your print and the build surface, that not only will protect your build surface, but will make it easier to clean your build surface with IPA or water based cleaners.


text:
Direct vs Bowden Extrusion when printing in temperature fluctuating environment
I have a Bowden extrusion printer in my garage. (Printing PLA is smelly and is nothing I want to be exposed to for an extended period of time!)
I enclosed the printer within a plastic sheet housing to reduce the energy consumption of keeping the hot bed tempered. I noticed that a strong temperature fluctuation influence how the PLA part turns out.
If I start printing in the morning a print that takes 2 hours to print -- in a cold garage, cold filament, cold tube, I end up with a solid first 4 layers and lacy last 4 layers. The last 4 layer are so thin that they end up to be almost see through.
last layer

first layer

I am assuming that the PLA and tubing heat expansion difference is the reasoning for that undesired under extrusion phenomenon.
The cold Bowden tube is perhaps expanding more then the PLA filament and the tubing is warming up more quickly being directly exposed to the heat during the heating up of the unit; obviously, the PLA filament is inside the tube and is kept colder for much longer.
How can I solve this -- keeping the printer in the garage? And, would a direct extrusion mod remedy this under extrusion?
Most likely preheating the printer would help, but that would call for an insulation upgrade from plastic sheet to Styrofoam. Insulating the Bowden tube may also be worth trying. (Happy printing.)

have you tried putting a thermometer inside the enclosure to know how hot it gets? expansion matters very little, if you reach 30+ °C and PLA gets soft and more difficult to feed. Besides that, try to keep the spool outside the enclosure, there is no need to warm up PLA

@FarO I will add a thermometer to see hat kind of temperature read I get. Currently I have the spool on the bottom where the plastic hub is not quite reaching. I forgot to mention: I am printing at 0.1mm Z with a 0.4 nozzle.

Maybe you could also stay there and observe the print. Are the first layers ALL really properly laid out, or is the printer squeezing the first layer down too much, resulting in excess of plastic which gets "absorbed" by the first few following layers, while the rest of the print appears underextruded overall? In other words: you may have two issues, the first one being wrong first layer height, the second one underextrusion, which gets "hidden" by the first issue at the beginning of the print.

Also, try without enclosure! the bed won't have any problem staying warm and the power consumption for few test prints won't matter.

If it is too warm in the enclosure, you might run into problems with under-extrusion caused by heat creep.

@FarO I forgot to mention that my filament is 1.75 mm in diameter (apparently +/- 0.03 mm.) I set my diameter in Cura to 1.90 mm thinking it would help me better control another problem I am having. It has to do with printed incline and decline angles not matching the design. I think it may be best for me to start another question for that particular issue. It is clear to me that having the filament set to 1.90 mm would reduce the pressure and make thinner lines, but did not think that it would make that much of a difference. (Now I know -- thank you!)

this my related question https://3dprinting.stackexchange.com/questions/15702/how-to-control-fine-details-from-overhanging-part-to-not-build-upwards

I don't think your temperature based explanation makes sense. This looks to me just like a first layer smashed against the bed, possibly too much due to nozzle being too low, followed by underextrusion when there's actually the right amount of space to extrude into. If you have fewer than 3 top layers or less than 0.6 mm of top layer thickness, you will almost certainly have an underextruded top like this just from the first top layer sagging into the space between the infill lines. Since the walls look okay, this is my best guess; if the walls looked bad too I would suspect poorly tuned filament diameter/E-steps-per-mm. Also check that your infill is not too sparse; more than 4 mm or so between infill lines gives a lot of room for top layers to sag into and may increase the number of top layers you need.
I see you added in the comments that your layer height is 0.1 mm. At such thin layers, you probably need at least 5 or 6 top layers; the first 2-3 are expected to sag and not fill the space.

My infill was set to 12%, about 8 mm apart. The top layer was set to 4 layers. Your answer points to under-extrusion -- which is clearly what I had do to having set the 1.75 mm diameter filament  to a diameter of 1.90 mm in Cura. So I guess it is not a heating issues after all. That is very helpful!

I'd try setting infill line distance to at most 5 or 6 mm, possibly using Cura's gradual infill feature if you want to save material on lower layers, and increasing the top layers to 6. I suspect that will get you acceptable results.

And also fix your incorrect filament diameter. I just read your comment where you mentioned it (1.90 - that's a HUGE factor off because it scales quadratically) and that alone could explain the problem; you might even be able to stick with sparse infill and only 4 top layers.

To elaborate: I had filament with a few 1.9 to 2.1 mm blobs on it - those did not even pass the extruder and got stuck there!


text:
What is cause of blob when layer area reduces by 50%?
This is printing PETG extruding at 250 °C, 1st layer bed at 80 °C then 60 °C on other layers.  Nozzle is 0.4 mm; printer is German Reprap X400.  The all metal extruder is clean with no oozing.  The print gets a blob when the wall width changes from 2 mm to 1 mm.  The extruder squishes the blob out the sides of the wall with subsequent layers.  Images below show both sides of wall.  I'm looking for the cause to come up with a fix.  I consistently get the same results in the same location when printing this file.  The reduced area of the layer does cause reduced speed to increase the print time for the layer (speed reduced when layer would print in less than 30 seconds; minimum speed 15 mm/s).
When I printed two, there was only one blob on one of two.  Below shows the speed settings.  The perimeters are three vertical shells, so the walls are all perimeters.  My understanding of the setting is the 2 mm wall printed at 20 mm/s and the 1 mm wall at 15 mm/s.
Printing similarly with 2 mm walls only and the same settings, the print is nearly perfect with only a few stringers.  Printing with only 1 mm walls does not have the blob, but does have stringers.
See solution at the end.

Solution:
Speeding up the print speeds and using thicker walls not only eliminated the blogs, but also completely eliminated stringers, and gave a near perfect print.  Apparently, the actual temperature that PETG extrudes is highly dependent on how fast it extrudes.  Printing too fast clogs the nozzle because the filament doesn't have time to melt.  Printing too slow causes the hotend to stop extruding from heat creep.  Here, the actual temperature of the extruded PETG was decreased by speeding up the extrusion.
s://i.stack.imgur.com/Uhv61.png

Usually these blobs (if coming from the nozzle and not from the outside e.g. seen by the blackened surface) are caused by over-pressure; if the filament has not deposited and over-pressure is in the nozzle these blobs may come out when there is a move.

@0scar I believe the blacked particles are from the outside of the nozzle from when the nozzle crashes into the blob.  However, the blob itself is not from outside the nozzle.

Try lowering your extruder flow rate and maybe temperature as well.
I had this problem once and I thought it was just a bit of gunk that had been hanging onto the outside of the extruder. That is usually not the case and instead it is probably build-up from over-pressure inside the nozzle.
Also note that 250 °C will start degrading your PTFE tube unless you have an all-metal extruder. Lowering temperature can also reduce the stringing visible in the picture, however to fully, get rid of stringing, you may have to adjust your retraction and acceleration.

Actually, increasing the print speed of the PETG greatly improved the print.  This did effectively reduce the temperature of the extruded PETG.

In my experience, when you see mysterious blobs on PETG (especially if they don't appear with other materials and comparable slicing settings), the cause is almost always this: PETG sticks really well, to itself and other surfaces. This means when you move the hot nozzle over already-printed PETG, especially if it's unretracted so that there's still molten PETG in the nozzle orifice, it will tend to "dig up" the material that's already there as a blob and deposit it somewhere it doesn't belong. Not only is this ugly and messy to clean up in postprocessing, but since the material was moved away from the place it actually belonged, it harms layer adhesion and makes your part brittle.
The best mitigations I know are:

Disable combing (either entirely or effectively, e.g. by setting max combing move distance to 0.5 mm or so; the latter avoids slowing down printing of top/bottom skins). This will avoid unretracted moves over already printed material.

Disable slicer features that omit retractions when there are "too many". In Cura this is "Minimum Extrusion Distance Window". Set it to 0. Otherwise retractions will start getting skipped at geometry-dependent points in the print, which may very well be what you're hitting.

Keep travel speed reasonable. Above 80 mm/s is probably too fast and in my experience may dig up already-deposited PETG even if you retracted.

Set "Minimum Wall Flow" (or your slicer's equivalent) to something like 20%, bounded away from 0. If the slicer emits near-zero-width wall lines because they're all that fit due to overlap, the move to print them is essentially a combing move (unretracted travel) because the flow is so low, and the same problems with digging up blobs arise. Better to just omit these lines and leave a small gap.

It did implement to suggestions on retraction although I didn't slice with Cura.

Which slicer do you use? I could try to translate the settings to another one's naming - I'm somewhat familiar with slic3r-derived ones too.

slicer used: Slic3r


text:
Y-axis movement error
I have a used Creality CR-10S and I have been using it for one day.  I seem to be having problems with my Y-axis.  Several times when I selected "Auto home", the bed only moved part of the distance it should have for the head to get to the bottom left corner.  It is only the bed movement that has the problem; the head successfully goes to the extreme left each time.

It does not always happen and when it does, it seems to usually go half as far as it should, but once the bed did not move back at all.  I am having a similar problem on "Bed Auto Leveling". Once when it was supposed to go to the back left corner, the nozzle went past the bed by about 5mm.  I tried to reposition it with "Move axis" but it thinks it is at 0.00 and it won't let me go negative.  One way I can fix it is to "Disable steppers" and then move the bed by hand.
I have done two prints and in both cases there was no Y-axis drift during the print. After first print, "Auto home" only went half way but I was not paying attention to other details.  After the second print the machine was off and I moved the bed by hand in response to @octopus8.  Then I turned it on and selected "Auto home". The head descended and moved all the way to the left but the Y-axis did not move at all.
When I move the bed by hand through its entire range, either with the machine off or after choosing "Disable steppers", it is pretty smooth. It has some resistance to movement, about the same as the X-axis resistance. I can feel very small "steps" if I move it very slowly.  These are both consistent throughout its entire range.  There are no individual spots where it behaves differently.
I have made sure that the bed's belt is tight.  I check the wheels.under the bed.  I cleaned them with a rag.  When I turned them by hand, several were slipping against the rail (not causing the bed to move when I turned the wheel.)  I tightened their bolts and that tightened some of them against the rail but a couple others still slip against the rail.  Is this important? After these adjustments and turning printer on, "Auto home" worked and the steps on "Bed Auto Leveling" also did the correct things.  I will report on more post-adjust experience as I get it.
Ever since I tightened the Y-axis belt and wheels I have not had the problem happen again having done 10+ prints. I tried the gcode that @octopus8 suggested at various speeds and the print head always ended up back where it started.
I will keep printing and if I experience the problem again I will investigate more then.

Hi Brett. The question is what did you check already? The issue may (more or less probable) be anywhere, starting from the firmware, through mainboard (drivers, signals), electric conductivity (cables, plugs, etc.), stepper motor, to the condition of movement mechanisms like wheels (belt, wheels, etc.). Is it completely random? Maybe some wire is broken, and sometimes does not work? Can you reproduce it (e.g. always from the same location)? Can it be related to movement speed (motor loosing steps)? - decresase in config. Anytime during print? When moving by hand, is it always easy and smooth?

Thanks @octopus8.  I will start to do some of the things you suggest and report my results in original post.  I also amended my post to indicate my CR-10S is used.

Ok, so it does not feel like mechanical problem... Maybe too fast movment? I tested behavior moving around the bed (simple square), by using simple gcode file (or just sequence of commands sent via serial terminal): G28 G0 F900 G0 X200 Y0 G0 X200 Y200 G0 X0 Y200 G0 X0 Y0. I then increase speed (the F value) by increments (like x2 or +900) and how steppers behave. This or similar way you could try to detect repeatable issue.

Can you please explain how I make this file.  Is it something I can do in Cura or can I just create a text file with that content with a text editor and save the file as "test.gcode"?

The text file. Use any plain text editor to create file on SD. Also check how to What is a printer console/terminal?. The G-code is actually the way to communicate with your printer's firmware - except for LCD controller, but many things are not available via LCD. I use it a lot, so I advice to learn the basics: there are few common commands, plus many extended. You may read the intro from Wikipedia and check details of particular commands from reprap.org, Marlin Firmware.

Ever since I tightened the Y-axis belt and wheels I have not had the problem happen.  I tried the gcode at various speeds and it always ended up back where it started.  I will keep printing and if I experience the problem again I will investigate more then.

octopus8 recommended doing a series of tests to determine the cause of the problem.
I started with moving the bed by hand (remember to have machine off or choose "Disable steppers" from "Prepare" menu) and the movement was relatively smooth with some resistance, the same as when moving the X-axis.  If you move very slowly you can feel slight, small "steps", this is normal. The movement was consistent across the range of movement.
Since this did not indicate a problem, I moved on to checking the drive belt and the bearing wheels.  The belt had a small amount of slack which I tightened.  Several of the wheels under the bed slipped against the rail they run along.  I tightened these.  This improved the movement of a couple of them but a couple still slipped a bit.
After this I did not have the problem anymore.  For 10+ prints over a week or so, there was no incorrect Y-axis movement and "Auto home" always worked. Nevertheless I continued with the next test suggestion which was to send some simple gcode to the printer via USB.  I used both Ultimaker Cura 4.8.0's Monitor mode as well as [sending the commands from the linux terminal][1].  I sent the commands
G28
G0 F<speed>
G0 X200 Y0
G0 X200 Y200
G0 X0 Y200
G0 X0 Y0

with values of 900,1800,2700,3600 and 4500 for  and everytime the print head returned to the same place.
This is evidence that the tightening of the belt and wheels likely fixed the problem.
[1]: How to directly send G-code to printer from a Linux terminal?

Many advices around say to make still possible to turn wheels in place with 2-3 fingers using force. In place, meaning not moving the device (bed for Y, carriage for X, gantry for Z). Otherwise wheels will wear quickly. For me it was pain to reach this state for gantry, because it requires ideal right angles between both "wheel setups"  and a gantry level. Remedy is to start from tightening wheeled parts ideally. Then add a gantry bar. Then avoid gantry going down by itself. So I had to tighten even more, changing angles. I had to repeat it few times until I learned how tight wheels shoud be.


text:
how to control fine details from overhanging part to not build upwards
I noticed that when printing small teeth on a pulley that the angle is not matching the design angle. I am printing without any support structure.
Overview:

Detail:

Printed:

The printed overhang incline angle under the tooth looks good (maybe not quite steep enough;) but the top angle of the reclining section looks too flat. It is as if the tooth is too perky.
(I have observed a similar behavior when printing overhanging corners. They build upward more quickly.)
What is causing this, and how to prevent it?
I reduced the speed for the outer layer to 30 mm/s, the infill is set to 40 mm/s. Layer (Z) is set to 0.1 mm. Material PLA 1.75 mm, nozzle 0.4 mm.
Cura layer detail:

Cura Prepare

Cura Preview

I think the issue is unsupported overhangs. There is not enough material to support the first layer of each small tooth. Have a look at how your slicer slices the first couple layers at the bottom. It might be that it tries to reduce the angle to 45°, so that it can print overhangs, or the overhangs are drooping before the next layer can assist with support.
Looking at your first two images, I think the printed top part of the tooth is actually quite similar to your 3D design.
You can fix this by making the tooth profile from the side have a 45° slope to maximum height, and the same on the top if you want the teeth to appear symmetrical.

I would like to have it symmetrical, and was considering adjusting my design to be asymmetrical so it would print more symmetrically. I added two side view (last 2 images) of Cura's Prepare and Cura's Preview. It looks like Cura accepted my angle just barely.


text:
Cura G-code Printer G-code settings vs. Extruder G-code settings
I am configuring my Cura G-code settings, and I'm not sure if the Printer G-code settings (printer tab of Machine Settings) should be the same as the Extruder G-code settings (extruder tab of Machine Settings). Does one set of settings override the other? Should they be different?
I'm using the following for Printer Start G-code:
M140 S{material_bed_temperature_layer_0} ;Start heating bed
M104 S{material_print_temperature_layer_0} ;Start heating extruder
G28 ;home
G90 ;absolute positioning
G1 X-10 Y-10 F3000
G1 Z0 F1800
G92 E0
G1 E20 F200
G92 E0

Printer End G-code:
M104 S0 ;extruder heater off
M140 S0 ;heated bed heater off (if you have it)
G90 ;absolute positioning
G92 E0
G1 E-1 F300 ;retract the filament a bit before lifting the nozzle, to release some of the pressure
G28 X0 Y0
M84 ;steppers off

If your printer has only one extruder, leave the Extruder G-Code empty. This setting is useful for multi-extruder printing (e.g. multicolor). The extruder G-Code runs each time you switch to and away from that extruder, and can be used for stuff such as retracting a filament when switching.


text:
Why does a raft adhere to the bed while skirt does not?
I'm experimenting with my new Ender 3 V2 using PETG filament on the textured side of the included glass bed without any additional adhesives.
I'm been having trouble with adhesion until I found out that enabling raft on my prints helps solve the problem. However, I can't help to wonder whether skirts work any different than rafts.
In my test prints, all settings are identical except for the raft vs. skirt setting (using Cura as my slicer). However, the outer line of a raft adheres perfectly to the glass, while the outer line of a skirt fails to stick completely and moves around when the nozzle goes "around the corner".
Is there any difference between the outer border of a raft and a skirt as produced by Cura?
EDIT: I've managed to upload a video comparison of raft and skirt in the same project.

What is your bed and hot-end temperatures you use for PETG? First layer adhesion could be related to your Z-height offset as well. Can you share images of your slicer's first layers for both scenarios? This might help to explain adhesion.

I've settled for 240C nozzle / 85C bed temperatures. I can try getting some images and/or videos, but since anything but the raft is just messy spaghetti, this might prove difficult.

What is the skirt distance? I set it really close, below 1 mm from the printed object. And the bed on sides  is for sure cooler than in the middle... (I got it, it's initial line.)

The raft base (initial layer) is usually printed with very wide lines. Cura's default is double the nozzle diameter, so 0.8 mm with standard 0.4 mm nozzle. This is ridiculously high flow, especially with the default 0.3 mm thickness, which is why the raft base lines are (and must be, unless you have a seriously overpowered hotend) printed so slowly. So, each line has significantly increased (double) surface contact, more pressure against the bed, more forgiveness if the bed clearance is too high (since it will still smash against the bed, just spreading out less than the whole 0.8 mm width), comes out slower (giving it better opportunity to adhere), and does not involve any curves (where the nozzle may "pull" just-extruded material that's not yet adhering).
You may be able to get a lot of the same benefit with skirts (or brims) by increasing the "Skirt/Brim Line Width" setting and slowing down its speed.

Thanks, will try this when my current print is done (it's a long one). However, I've checked Cura's settings and raft speed is 30 mm/s, while skirt speed is set to 15 mm/s, so basically it's already slower than raft. But yes, raft's width is 0.8mm while skirt's width is 0.38mm, so the explanation seems plausible. I assume there is no real benefit in increasing line width on skirt, since the first layer of the print which still not hold? Would changing "Initial layer line width" be sensible?

I'm not sure if "initial layer line width" takes precedence over individual feature widths like brim/skirt one. I would think not; if it does, it makes them pointless. And while you could increase "initial layer line width" to get the same benefit for the actual print, you sacrifice the ability to print small details accurately in the first layer. In the worst case, printing of walls thinner than the increased width will be suppressed completely and the second layer will print in thin air.


text:
Printing issue with X-axis motor
Here's an idea of what's going on. This is a picture of the progress during the first layer:

Printing a simple calibration square, and as you can see, my X-axis is not moving like it should. I turned my speeds down from 30 mm/s to 5 mm/s and this is the result.
What happens:

Printing starts after homing and proper temperatures have been reached.
Starting from lower left, printing starts, filament pushed out.
X-axis motor is told to move, but it doesn't. Takes 0.5 seconds to think about the given order and only then moves. By now, a smudge of filament has been pushed into a blob at the start corner but the move is executed at a proper speed. Reaches "destination" and stops moving. This has resulted in too short of a face for X-axis.
Y-axis receives the order to move and does so properly. Lower left corner is done properly due to Y axis moving instantly.
Y reaches it goal destination, X receives orders to go to left. Lags behind, filament pushed out creates a smudgy corner due to lag. Reaches "destination" (lag is the same so it creates a regular pattern)
Y receives orders to go back to start coordinates and does so.

And this can be seen on the diagonal lines. Y moves constantly, X lags behind so it creates those vertical lines.
No idea what's causing this and causing a bit of a headache.
Things I've tried:

Slowing down
Calibrations
Adjusting belt tension
Different COM port
Printing from SD card
Tightening the pulley teeth onto the stepper motor

Getting this far was already a pain and now I'm kinda stuck.

Is this a new printer to you, or have you had it working fine in the past?

If you try to move the head when the X-stepper is enabled, then the print head sits still?

@fred_dot_u It was working fine when I last used it but that was a long time ago.

@dotswe No. The head will move instantly as commanded. Which makes this really weird.

at first glance, your z-height is improper. The filament should be flatter, implying the bed should be higher or the nozzle lower, depending on the mechanical portion of the printer. Consider to re-calibrate (re-zero) and re-level the bed.

Is perhaps the nozzle loose?

@fred_dot_u That's just because I don't want to clog the nozzle due to the filament being pushed out when there's no movement by the X-axis.

@dotswe not sure what you mean by this, since my X is very visibly not moving when it clearly should be during printing.


text:
Problem with the first layers on the print
I ran out of ideas on what could cause my problem.

Ender 3 Pro
Nozzle temp 200 °C
Bed temp 60 °C
PLA filament

Please look at the pictures. The first layers don't look nice. The top and the sides are perfect.
This happens in every print. With and without raft or brim. The strange thing is that raft and brim looks very good on the bedside. Is there some settings I am missing out on here?
Tried with Creality Slicer that came with the printer, and the Ultimaker Cura slicer.

The filament is not flattened, it looks like the nozzle deposits round filament strings while in fact they should be flattened more. This usually indicates that the nozzle to bed distance is too large. A perfect distance is obtained with plain A4 or US letter paper (usually 0.1 mm thick; or 0.004") during levelling where there is a slight drag/friction force observed when the paper is pulled between bed and nozzle. Alternatively, you can use feeler gauges:

Considering that the raft is printer well, it could well be that the initial nozzle to bed distance is correct, but the distance between the raft and the first layer of the product is too large.


text:
Top and bottom of part not coming out smooth
I have an Ender 3 printer and can not figure out why the top and bottom layer of this print comes out the way it does every print. I have tried increasing the initial layer height to 0.3 mm and increasing the flow rate to 120 % with little to no results. I print on glass with gluestick and get good adhesion I also print at 215 °C with the bed at 60 °C. My bed is leveled with an index card. Any suggestions on what might be causing this issue.
Bototm of part

Hi Carson. What type of material do you print with, PTEG or PLA? Could you describe in much more detail what do you mean by "comes out the way"? These two layers (first and last)... do not stick? to the hotbed? or to other layers? or are shifted against other layers? I give up :) Kudos for what you tried and what is a related setup. (Btw. please read more about heating the bed and slowing down the print to improve adhesion e.g. here. For some PLAs I go even to 90 °C before it sticks acceptable.)

It would be useful to see what the layers actually look like. Smooth is a bit relative because it could be a result of the infill your slicer uses. The bottom layer on glass should be smooth unless the bottom infill leaves gaps between different print lines.

a smaller layer height would help. might go with concentric fill instead of grid/lines, at least for the bottom layer. You can also smooth the bottom with a clothes iron, do experiment to find the right temp/pressure to melt the fine lines together.

Do you just have one solid layer for the top an bottom?  Try adding more solid top and bottom layers.


text:
BLTouch Creality Firmware works, Marlin doesn't
I've had the BLTouch working fine using this kit and following the instructions it shipped with.
I wanted to increase the number of probe points so I've attempting flashing with Marlin to achieve this. With the home-brew Marlin the probe doesn't extend for homing, with the default Creality firmware.
I'm running an Ender 3 Pro on 4.2.2 Mainboard. The wiring diagram has used the Z endstop connector for the BLTouch, I've followed this video, but clearly the wiring mechanic is different.
I've included:
// Force the use of the probe for Z-axis homing
#define USE_PROBE_FOR_Z_HOMING

But it has no effect. x and y work fine, but at z the probe doesn't extend.
Since it boils down to some setting changes in the firmware (since that's the only thing that has changed) I'm hoping someone has the answer to this question already. Unfortunately, I can't find any Creality source code for comparison and since it is working on their firmware and not the home-brew my expectation is I've missed a setting.

Hi welcome to 3DPrinting.SE! How would we know if you have missed a setting? You should at least link to the config files by pasting them on PasteBin or something. Note that Creality runs Marlin themselves, so it must be a setting indeed.

I've made numerous changes to various settings, I can post the current config, but it wont reflect the attempts I've so far made to try and resolve the issue. The file i've copied from is the creality v 4.2.2 config from here: https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x/config
I'll copy it into the post if it will help

There are pre-configured configuration files to be found for most Creality printers here, you could start there instead of a vanilla configuration file. You can also look into TH3D firmware if you're not comfortable with the settings in Marlin, TH3D has made it a bit simpeler with all settings at the top.

Unfortunately, up to now, no answers are given on your question! Have you found an answer yourself? If so, you may add your own solution and accept that after 48 hours. If you have not been able to address the problem please update your question so other people may help you find an answer. You can even decide to delete the question. We need to reduce the unanswered questions list to graduate from the Beta stage.