text:
Can I use 3 kg filament spools in an Ender 6 3D printer?
In order to save some money on a project, I'm considering using 3 kg spools on my Ender 6.
However, I never attempted this before, and could not find a firm stance on the web.
I know that it is possible to build a filament hanger/holder separately, but is it necessary on the Ender 6?
For reference, the spool hanger/holder on my Ender 6 extends 9 cm outwards of the printer.
The filament loaded in the printer (see photo) is a 1 kg white PLA. The dimensions of the filament drawing are for the 3 kg filament to be used.

You should add a little more information, first a side view of the printer with the holder (what is the length of the holder to fit a spool) and a spool on the holder (give the diameter of the spool) and also give the dimensions diameter and width of the 3 kg spool. With this information our users can help you if it is going to fit, else you will get answers to put it on a separate holder, but that would not be the point of this question (considering the last sentence). Otherwise this question should be closed, there are lots of separate holders to find.

I have had a look at the Ender 6 specs and surprisingly they don't seem to specify the max. weight supported, so this seems to be a valid question. What does the default support look like? Is the spool mounted vertically or (less likely) horizontally? If horizontally, then the additional weight probably wouldn't matter as much. What are the differences in dimensions of 3kg spool versus a 1kg spool. If the spool is much larger, then would it even fit? Have you tried fitting a larger spool already, and if so, what issues could you foresee? Please [edit] and update question with any new info

Also, do you mean I know that it is possible to build a filament hanger separately? The "but" seems to be incorrect.

I'm not particularly concerned about the weight, the dimensions and the location near the filament sensor and the top of the table the printer rests on might be more important.

I suppose I was just interested in knowing if anyone had successfully used 3kg spools directly on the Ender 6. Just give me a minute, I'm going to edit the question to make it better to be answered, take the necessary photos, as per @0scar suggestion.

It is indeed not possible. Thanks for everyone that helped with this question; thank you @Greenonline for going into the trouble of looking into the Ender 6 specs.

You're welcome, I'm glad the comments helped you realize you could solve the question yourself! And good that you answered it yourself!

Get a real spool holder, preferably with a rewinder. Using holders where the spool slips on a central axis is begging for a failed print due to tangled filament. The extruder pulls filament, spool overcomes static friction releasing more filament than necessary, wobbles, and the most recent loop of filament gets trapped under an earlier loop. The extruder pulls the filament taut, and your print fails as the extruder can't feed any more. And you end up blaming the filament manufacturer. Been there, suffered through that, never again.

While editing this question and analyzing the input the community provided, I've concluded that it is not possible to use a 3 kg filament spool directly on the Ender 6.
The actual answer depends on the filament spool dimensions you are going to work with.
For one thing, the spool hanger has a length of only 9 cm, while the filament spool has a width of 10.2 cm. I don't think it is a good idea to leave the spool hanging loose.
Secondly, the filament spool would hit the filament shortage sensor.

Many thanks for answering your own question! IMHO this answer shoud be the accepted answer as this answers the actual question at hand! Note that accepting self-answered questions may take up to 48 hours to be able to do this.

Why can't you use a big spool with a better spool holder than the peg on the side, which isn't that great for little spools anyway. A better spooler is one of the best bang-for-buck upgrades for your printer. Maybe the question should be "can i use on a fully stock ender?"...

I would absolutely make a more sturdy spool holder that is designed for 3KG filament spools. Spools tend to be filled up to the rim these days, so support your spools as good as you can to ensure straight unwinding.
You really don't want to come back to your printer making a terrible grinding noise where the filament has come off the spool sideways or the spool has fallen off the holder.


text:
Carima non-toxic resin?
I just discovered a resin from Carima which says it's non-toxic. They have a link to a technical data sheet, but it leads to a page that requires me to request access, so I haven't read that yet. Has anyone tried this resin, or even heard reports on its quality and ease of use as resin? I really like the non-toxic idea, but it has to work well, too.

source: Stack Exchange

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

sort: votes


text:
Clear, gasoline resistant resin
I’m wondering if there was a resin that could help me produce this:
Some old carburetors from the 1960’s had glass bowls.  Well, I’d love one, but to find one on eBay it’d cost more than my engine.  Wondering if there’s a way to print a clear one

A quick search for "fuel resistant uv resin" turned up  https://www.liqcreate.com/supportarticles/chemical-compatibility-of-3d-printed-resin-parts/  . That said, this seems extraordinarily dangerous, as any failure would pretty much spray your legs with fuel.

I actually visited that site before posting, it seems like the only material listed there suited for gasoline was not clear. Well, with the possible exception of the bio-med clear, but that didnt seem as 'tough' and impact resistant as the others.  Which, as you said, would be a chief concern.
I do agree its probably not as safe as metal, but can't imagine its any LESS safe than glass.

@JosephCrozier Thick glass is surprisingly impact and wear resistant

Unlike plastic, glass is dimensionally stable, insoluble in gasoline, and won't fail "just a little" or "over time" the way plastic will.  If the glass were to fail, it would be due to a very hard impact that would probably also result in damage to more of the bike and rider.

This might be venturing outside the scope of stackexchange and be more of a 'forum' thing, but I'm not opposed to glass, but not sure how to fabricate something like that without exorbitant expense (at which point I'd just buy it).  I did xometry might be able to 3d print in silica glass, but despite the name, didn't actually appear clear.

If you can 3d print what you want, there's a good chance you can find somebody to make a mold and pour the glass for you.

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


text:
Auto Build Marlin extension showing random board and environment?
I am trying to compile firmware for an Ender 5 Plus with its stock 8-bit board with ATmega2560. The environment is set correctly and it compiles the hex file as it should when I use PlatformIO:Build (and runs fine when I can actually get it to upload).
I want to try Marlin AutoBuild to try uploading via their utility. However, as you can see it populated with some random board for a printer that is not hooked up and not specified in platform.ini
Where are these fields being populated from?
Again, the firmware folder that is loaded currently is for the Ender 5 Plus and I have not had any others loaded recently that used the BTT board.

[platformio]
src_dir     = Marlin
boards_dir   = buildroot/share/PlatformIO/boards
default_envs = E5P_BIL

[env:E5P_BIL]
platform      = atmelavr
extends       = common_avr8
board         = megaatmega2560
build_flags = ${common.build_flags} -DMachineEnder5Plus -DHotendAllMetal - DBedDC

Hello, benram14159. Please don't upload images of text, code, or errors. They are not searchable and are inaccessible for the visually impaired using a screen reader. Please [edit] your post to include actual text. (For more info, please see Why should I not upload images of code/data/errors?)

@agarza thanks for the advice. I will follow whenever possible. Unfortunately that window in VSCode does not let me select any of the text to copy/paste it here.

In a situation like the VS Code window, it is understandable to have an image of that. But simple text, code, or errors should be actual text. Thank you for understanding.


text:
Is there a filament that exhibits less deformation than PETG (when subjected to stress for a particular application)?
I've printed a "clamp" in PETG which locks a power switch down (the "On" position). After a few days, the print is not working anymore. So I was wondering if PLA (or any filament) would be able to stay in place without deformations due to stress.

Hi, welcome to 3DPrinting.SE! Please visit [help] and take the [tour]! It's important to recognize that queries about "the best" often invite subjective responses, as they are inherently debatable and can draw opinions rather than factual answers. A more objective approach might be to reframe the question: "Is there a filament that exhibits less deformation than PETG (when subjected to stress for a particular application)?" For a comprehensive response, it would be beneficial to provide details regarding the exact clamping stress/print you're considering.

Hi, thanks for the explanations but I'm not asking which filament is better. My question is which filament is least prone to deformation if put under stress at room temperature. I'll edit my question.

This would be a design flaw rather than the wrong filament choice.

@Kilisi That sounds like the start of an answer! ld be great if the question had more details on the design.

@Kilisi yeah probably, I’ll post more details on the part when I have time. Thanks to both of you


text:
Any good way to recycle filament?
With a good amount of failed prints, I now have a bunch of filament that is... trash.
Is there a good way to recycle it, or any services that you send them your lost filament to then melt it back into a new filament?
I kinda hate the amount of trash im producing with 3d printing.

You mean just failed prints that are in printed shape or rests of filament spools?

Does this answer your question? How to recycle filament material from printed parts? & Uses for PLA scraps?

I throw fails in the hidden corner of my backyard. They are gone in a year.

Many makers will reuse the filament from spaghetti prints as filler material when joining print sections together. Usually by heating it along the seams.


text:
Ender 3 S1 Pro error "extrude below min temp"
When I start my print it goes to home the z-axis and then I get the error "extrude below min temp" error (I have an Ender 3 S1 Pro)

We will probably need (a lot) more details in order to be able to provide a solution - take a look at other highly voted questions to see what is required.

There are details missing here, but it is possible that the OP is new enough to 3D printing that they don't know what is helpful.

Hi and welcome to 3DPrinting.SE! Indeed, it is hard to answer this question without a little more context. Know that printers are usually protected against extrusion at low temperatures (usually 170 °C), so you are either extruding at a too low temperature or there is something broken in the electric circuit. Please troubleshoot a little and put that in the question!

Please excuse this answer if it is too simplistic or pedantic.  I don't know how much experience you have, and getting started can be very confusing.
The error message is because, for some reason, the hot end is not being measured as hot enough to soften the plastic enough for the extruder to push it through the nozzle.  Why can this be?
If your printer has a nozzle temperature display, check that it is in the right ballpark, 180 °C or higher.  My printer shows both the commanded and measured temperatures.  I am unfamiliar with your printer.  If the commanded temperature is 0 °C, the G-code may be wrong, ie., it may not have a temperature setting command, or the sensor could be broken.  If the commanded temperature is not displayed, or the actual temperature displays as roughly ambient temperature, the temperature command could be missing, or there could be a problem with the heating system.  If the actual temperature displays as significantly (more than 10 °C) different from ambient, I would look to the sensor for the problem.
Moving to the nozzle, check to see if it is hot when the error is displayed.  At full temperature, you should be able to melt a piece of filament by pressing it against the nozzle.
I could explore the failure tree further, but if you check these things the answer may be clear.  If not, please add your observations to this question.


text:
Ender 3v2 with CR touch, X and Y axes off on the build plate
I'm new to the 3D printing world. I made a mistake in thinking that my auto leveling wasn't working because of the firmware and reset it to the Creality standard one. After changing the firmware, my X and Y axes have been out. The point hangs over the front section of the plate. I've tried changing this but have been unsuccessful. I have watched many YouTube videos and just don't have a clue what to do!
Can anyone help me how to retune my build plate so that it's centre and uses the max plate dimensions?

Hi and welcome to 3DPrinting.SE! This is reaaly not much to work with. What is meant by The point hangs, are you implying the nozzle? Most probably your offsets from the endstops are incorrect, this can be easily fixed. Have you seen this answer?


text:
College student personal project - developing a 3D printer design, seeking guidance
I am currently a junior studying mechanical engineering. I have been wanting to start a personal project focusing on 3D printing/printers for a while, yet I have been struggling to develop a course of action.
Some topics that I've been thinking of addressing include:

Speed and sound: work to create a printer that is fast, but does not sacrifice low sound levels for higher speeds. I feel as if this is simply a motor optimization problem.

Experiment with 4 or 5-axis printers: Probably one of the most difficult options, but it sounds like people want the higher-axis/higher degree of freedom printers to be more commercialized.

Large print volume: 'nuff said!

How do you all feel about these ideas? Would you suggest other topics or ideas? I am seeking any guidance I can get, as I really want to make an impact.

"I feel as if this is simply a motor optimization problem." Yes, motor optimization is a big part of it. There's nothing simple about it.

I really want to make an impact in what respect? For your personal development, or in the 3D printing field? Maybe first build a regular 3D printer first (enough challanges to make a proper printer) before you endeavour into the exotic options. P.S. I think most options are already been explored. 1. There is a printer with linear maglev motors, 2. this is industrially common, using existing robot arms, 3. also done before, but remember the bigger the more issues with heating, sticking and big products take very long to build.

Most of all, I would ask yourself what you want to get out of this. Is it just engineering experience, or something you'd actually make good use of (moreso than a printer you could just buy), or some combination of the two?
While more-than-3-axis printers are very cool, I would lean against that option unless you really want this to be a software project too. The big reason they haven't taken off isn't that the engineering is hard (although it does have some challenges), but that the slicing software is not there to take advantage of them, so you end up having to either do the gcode "by hand" or hack together a primitive slicer whose output is so much worse than just living with 3-axis but all the modern path generation of mainstream slicers.
I think I agree with your assessment about low-noise. Also, for high speeds, with most materials you need heavy cooling, which is a lot louder than motion system noise.
Large build volume could be interesting, especially if it's something you could use. So many of the large build volume projects I see are not really well-engineered, just scaled up with no consideration for how that affects rigidity/accuracy. Making a large form printer that prints at high quality and decent speed is a fairly hard engineering problem, and one that you might enjoy and learn a lot from.
There's also an option to try different kinematic systems, which have a lot of different engineering tradeoffs in:

BOM (parts) size/cost/complexity
Rigidity
Sensitivity to inaccuracies in build procedure
Speed and acceleration capabilities
Ease of enclosure
How motion component sizes scale with desired build volume

etc. etc. etc.
Beyond whatever ideas you might get from folks here on SE, in my experience, some of the best communities for getting ideas and feedback on custom printer designs are the Rolohaun and Annex Engineering Discord servers. The former is more novice hobbyist/DIY geared while the latter is more extreme performance geared, but both are friendly to this kind of activity.


text:
First layer disaster: auto-leveling the bed. Need guidance
I have been printing on and off for years. Generally, I have had no issues until recently. Upon thinking back I don't think I used the Z-offset at any point and only manually leveled my Ender 3 S1 Pro.
I'm not sure if it's material or me, or both.
I have to learn this. I bought a new, expensive printer which is ABL only. No knobs, only Z baby-stepping in software. The card reader in my S1 broke so I bought a new board and discovered I needed to do this process again. Since I purchased a Sonic Pad, I changed over to Klipper and printed TPU for 2 weeks fine.
I bought a spool of Overture PLA, it's been a disaster. Before trying to dial this in last night the spool had been drying at 45 °C for 12 hours. Doesn't seem to print any differently.
Instead of the config steps, after manually leveling and getting the mesh, I made a one-layer print of concentric squares with a solid 1" box in the center. I'm baby stepping trying to find the sweet spot and think I do. I begin printing my model, 5 copies, layer 1: 1 - doesn't stick; 2 - sticks; 3 - sticks; 4 - sticks. I stop and clean the bed with IPA. Copy 1 - sticks; 2 + 3 - doesn't stick. Stop printing, manually level, and find no resistance with paper. Re-level manually only, print, skirt doesn't lay down right.
Tried the Creality "BuildTak" bed first, and worse.

Printer: Creality Ender 3 S1 Pro - Sonic Pad (Klipper)
Nozzle: 0.5 mm Hardened Steel @ 215 °C
Bed: 60 °C PEI and "BuildTak"
Layer Height/Width: 0.3 mm 0.5 mm
Filament: Overture PLA Highlight Yellow
Speed: 25 mm/s

What's the process? 1) Manual 2) Probe 3) Mesh? Does the order of 2 and 3 matter?
Mesh and manual are easy enough. I won't be at my printer until 7 pm Central be eager to read any advice during the day. I have Googled this also; obviously, I missed something.

As I was z-baby stepping down with my concentric boxes, I assumed when it not sticking well or looking good the z-offset was too high. When looking good it was okay. And continuing down, it started to come off the bed in some areas... I assumed to low. But this seems to allow the paper when manually levelling to have zero resistance under the nozzle.

Elephant's foot compensation, could this be the problem? It was at 0.1 mm and now at 0.05 mm. Leave it at 0?

I printed a temperature tower beforehand: 190-230 at 5 degree increments. It broke off the bed during 195. All overhang areas severely curled up.

I'm not claiming this is the definitive answer but I made a successful print with these changes.
There were several things I did that may have helped but I don't think solved the problem. I eliminated the elephant's foot compensation. I brought up the flow ratio to 1.01. Even though I had indicated no cooling on the first layer, I unchecked the box that indicated fan Always on.
The real solution I believe, increasing the nozzle temperature to 230 °C and bed temperature to 70 °C for the first layer and afterward dialing it back to 210 °C and 60 °C respectively.
I've had rolls of PLA for a long time. Perhaps the formulation has changed over time but I didn't have to go through such steps before, nor print so hot on layer one.


text:
Prusa I3 MK2s with tilt in the X and Y directions
So I converted my Prusa MK2S to use Duet electronics. I have always had problems with bed leveling. It doesn't appear to help much if any.
So I can complete a bed probing session but the result is never ever useable.
I think the problem I have is the bed is tiling in both the X and Y directions. I have gently crashed the Z-axis into the mount that holds the threaded rod and smooth rod. This is to ensure the X axis is parallel and not slopping to one side.
I have tried to manually level the bed using a metro link ticket. I think I have managed to get it close. However, I am unsure how to resolve the tilt in the Y direction.
If you're standing in front of the printer, it apppears to tilt towards your face. I have verified this using the metro link ticket. It feels closer at the back than towards the front.
What is the cause of this? How can I rectify this?


text:
Support on tiny leg
When slicing with Cura, a "flying" support was added. Why would it happen and how to fix it?
Top-side view:

Bottom-side view:

Bottom view:

As expected, the support failed.
Note, the images are flow maps. Support is colored red. I used lines pattern for support. Both support and inner walls are printer on 60 mm/s, so they are both red. The green you see under the support is a support base. But, for some reason it's disconnected from the support.

In one-off cases like this, the best solution is adding a manual support.

Select the part. Select 'support blocker' from the right menu, then click somewhere on the part - a semi-transparent cube will be added.

Translate, Scale and Rotate the cube to the shape of the support: connecting the build plate with the critical point. Make it embed the problem point with a good margin - Cura will isolate it from the actual print body automatically, so don't worry about it merging with it.

Change its type to 'Print as Support' using the 'Per Model Settings'

That way you can support anything Cura fails to support automatically.
Additionally, I found using Tree Supports works vastly better than standard supports in great most cases - not just with 'organic' models - they work quite well with 'technical' models where you need to support a large flat area, and tend to succeed in cases where normal supports fail miserably.


text:
Problematic 3D models that will collapse while being 3D printed by SLA technology
I'm working on an algorithm that predicts the probability of collapse for 3D models while being 3D printed by SLA technology.
I'm looking for some 3D model that will collapse while being 3D printed. I wonder if there are any standard ones.
Note
Maybe I can rotate the famous teapot in way that it will collapse...

Interesting. It's maybe better to have an actual question for a title and an example of one a model that is 'collapsed' to better understand what you're searching for. Also in what format? Are you training a prediction model using deep learning or using another statistical or mathematical approach?


text:
Is it possible to change slicing line direction/type for small geometries?
Using Cura, I'm trying to change the direction of just a section of my print. I want it to print zig zag instead of straight lines. Just the way my part is intended to be used it'd be much better to do it like that. Is this possible?
I tried using a cutting mesh, and changing the top/bottom line direction, and many other things with the word direction in the name, I also tried rotating the part (not that I thought it would make a difference).
It was requested I add a file to test with. It's not the same model in the picture, but should work just the same for testing purposes. It should be oriented so that there is an overhang.
Test File

Can you link to the model? E.g. is it freely available? Otherwise, create a model with this specific problem you can share. We can then try to work it out, I have some ideas to solve this.

The test file is different in that the overhang is much thinner on the example image shown in the question. I've made an example based on the shown image which I use in my answer.

Yes this is perfectly possible to do in UltiMaker Cura. The technique to use is described in question Different infill in the same part and explained in this answer  for 2 separate slicersm this answer focuses on the Ultimake Cura slicer per the question.
Considering the following example geometry based on the sliced image from the question (disregarding the linked test file to better comply to the question at hand):

In Cura this model can be sliced using a support blocker that has the Per Model Settings configured with the Cutting mesh option:

It is key to use the Cutting mesh option and add properties you can change for Wall Thickness, Wall Line Count, Top/Bottom Thickness, Infill Density, Infill Pattern and Infill Line Directions. If these are not visible, you can add the settings through the Select settings button.

Wall Thickness: you don't need to change this option, this is overruled by the  Wall Line Count setting
Wall Line Count: set to 0 (you do not need walls in the small area)
Top/Bottom Thickness: no top or bottom shells are required
Infill Density: set to 99.9 %! beware to not set this to 100 % as this triggers Cura to use the Lines infill pattern while you are interested in the Zig Zag line style
Infill Pattern: set to Zig Zag
Infill Line Directions: [90,90] (or [0, 0] depending on the orientation of the print object sliced in Cura); this determines the alternating pattern of the Zig Zag, if the values are the same, each layer is sliced equivalent otherwise each other layer is rotated 90°

Upon slicing this print object you will get the requested results:

So, yes, you can change the direction of the small area you are interested in making clever (mis-)use of the options Cura provides.


text:
How do I move the head?
I have an Elegoo Neptune 4 Pro (love it), and I'm trying to set up a Raspberry Pi with a camera to take a photo every time a layer is complete (to build a time-lapse).
This means I'll have to edit the G-code to move the print head to the X-axis maximum to press a button (shutter release).
I'm using the web interface and would like to know how to get the X-axis position using G-code commands.
I've found Klipper documentation: G-Codes and have tried to run a few of the commands.
M114 gives the following line:
14:58:56 X:141.000 Y:98.000 Z:11.090 E:0.000
However, when I try to send the print head to that location from somewhere else, I get errors.
$ G0 X:141.000 Y:98.000 Z:11.090 E:0.000
!! Unable to parse move 'G0 X:141.000 Y:98.000 Z:11.090 E:0.000'
$ G0 [X:141.000] [Y:98.000] [Z:11.090] [E:0.000]
// Unknown command:"G0 ["
$ G0 [141.000] [98.000] [11.090] [0.000]
// Unknown command:"G0 [141.000] [98.000] [11.090] [0.000]"
$ G0 141.000 98.000 11.090 E:0.000
// Unknown command:"G0 141.000 98.000 11.090"
$ G0 X:141.000 Y:98.000 Z:11.090 E:0.000

All of these tried with G1 as well as G0
Based on the error messages, it looks like the first line above is the way to go; But I'm not sure where to go from here.

Have you tried sending G0 X141.000 Y98.000 Z11.090 E0.000?

G1 X141 F5000 will send the head to X=141 without touching Y and Z, and do it fast. [also, while G0 and G1 can be used pretty much equally, it is "traditional" to use G0 for printing/cutting/work in general, G1 for free movement between work points.]

It seems that the commands are invalid due to improper syntax. The Klipper Documentation site does seem to be a bit confusing. The main list of G-codes can be found on the RepRap wiki.
The site provides the proper usage and examples:

Usage
G0 Xnnn Ynnn Znnn Ennn Fnnn Snnn
G1 Xnnn Ynnn Znnn Ennn Fnnn Snnn

...
Examples
G0 X12               ; move to 12mm on the X axis
G0 F1500             ; Set the feedrate to 1500mm/min
G1 X90.6 Y13.8 E22.4 ; Move to 90.6mm on the X axis and 13.8mm on the Y axis while extruding 22.4mm of material

The provided link shows the correct syntax, the ":" character is not in the Klipper G-code specification and remember the "[" and "]" characters imply that the parameter is optional and "<" and ">" imply: "insert a value here".
From the documentation:

Move (G0 or G1): G1 [X<pos>] [Y<pos>] [Z<pos>] [E<pos>] [F<speed>]

A valid command would be:
G0 X141.000 Y98.000 Z11.090 E0.0001)

1) Note that this is an example based on the provided G-code in the question, the use of the E0.000 is not recommended, this can retract the filament all the way from the extruder based on the last position of E. If you want a move to a position, retract first (using a relative positioning of E), then move (using an absolute positioning of X, Y, Z), take a picture, move back and re-retract the same value (using a relative positioning of E).


text:
Prusa i3 MK2 thermistor connector reference
I think my heat bed thermistor is broken (infinite resistance measured) on my Prusa MK2, so I bought a new one, and I'd like to know which connector I shall use. Where can I find the references of this connector, please ?

Regards,

A better, in-focus, photo might be required

Those are JST SYP 2 pins female.

Please don't forget to mark your answer as the accepted answer, although you may have to wait 48 hours.

The thermistor is just a resistor. Polarity doesn't matter. Connect it wherever the old one was connected. Typically it connects to a pair of male pins on a RAMPS board, so a 2-pin female connector with standard 2.54 mm (0.1") pin spacing is called for, unless your printer uses a different board.
For a visual reference, look at the extruder RTD connection on your printer.


text:
Heater on bed stopped working on Fusion3 EDGE printer
I just received a Fusion3 EDGE printer and tried printing ABS with a 0.4 mm extruder at 260 °C and bed at 115 °C (the temperatures set by the demo print).  The bed started heading on the first print, then stopped heating after a few layers and hasn't heated since after repeated tries.  Does anyone know if the fault state is causing this or if a failed heater is causing the fault state?
I've been going through the document Fusion3 EGDE-Troubleshooting: Heater Faults.
Reset the heater fault and get the heater is heating too slowly.
I'm waiting for tech support's response before moving this to an answer, but this is the result so far.
I measured the voltages on the SRDD100 relay.  When the bed heater was turned on 24 V was across the input and the output passed 24 V to the heater (relay on).  When the bed heater changed to the fault condition, the input had 0 V and the output did not pass the 24 V to the heater (relay off).  Turning the power off on the 3D printer, unplugging the bed heater, and measuring the resistance of the bed heater showed an open circuit.

Note: the ABS not adhering and touching the bed indicated that the bed was indeed at room temperature.

My first step is to go through this document just sent. https://www.fusion3design.com/wp-content/uploads/2023/07/EDGE-TROUBLESHOOTING-Heater-Faults-6.26.23.pdf

Appears to be open circuit for bed heater.

This should be followed up by a call to the vendor or the manufacturer. You wouldn't expect this for such an acclaimed high end commercial printer.

@Oscar I am working with the OEM now.  This was the easiest way to give them images.  If they don't post an answer here, I will post their answer.  I have requested the parts needed to change the bed heater element.

I measured the voltages on the SRDD100 relay. When the bed heater was turned on 24 V was across the input and the output passed 24 V to the heater (relay on). When the bed heater changed to the fault condition, the input had 0 V and the output did not pass the 24 V to the heater (relay off). Turning the power off on the 3D printer, unplugging the bed heater, and measuring the resistance of the bed heater showed an open circuit. The OEM also concluded that the bed heating element failed and is shipping a replacement.
OEM comment:

every machine that is built runs through at least 12 hours of printing high temperature materials before it is allowed to ship. Having it basically show up not functioning is. . really weird.

My response:

This looks like it was on the tail of infant mortality for the heater exceeding the burnin time or a burnin escape.  It only lasted a few minutes into a print with bed at 110C.   Otherwise, it would be a defect caused in the process between burnin and arriving here.

The packaging showed no sign of mishandling and nothing on the unit showed signs of mishandling.  There was no sign of damage to the heater.  The lack of response to this question here supports that this is a rare incident.
The OEM has also requested the return of the failing heater element for analysis (shipping container included with replacement part).
Received new bed from OEM, installed bed, and printed successfully. First print after installing bed:

Below is normally a difficult print to not have strings between the stringers, but the Fusion3 Edge printed with no strings on the first attempt.

When looking at SRDD100 application notes, I wondered why the 3D printer designer switched the positive supply voltage instead of the ground as in the application notes. But, thinking about this, the heater is attached to the grounded aluminum bed. If the designer switched the ground instead of the positive supply, a short to the bed could cause thermal runaway. Thus, the designer had safety in mind.

Even if tested sometimes components do fail prematurely. Kudos for referring to this case being a rare incident and to the support of the manufacturer, this is handled as it should for a high end piece of machinery. Would love to test one!

Please accept the answer after 48 hours!

@Oscar its working great.


text:
Got EOF when reading from device only when heating the bed
I'm having "Got EOF when reading from device" only while heating the bed. however, if I run PID_calibrate for the heater bed and set the temperature to 50 °C. The PID_calibrate will auto-change to 45 °C and I get no shutdowns.
Another point is when the bed temperature is at 20 °C and I manually change it to 40 °C the bed will use 100% power until the bed reaches the temperature around 35 °C and then keeps fluctuating and changing the power from 10% to 40% to 97% to 60%.
Things I have tried that haven't fixed the problem:

Changed the connection cable between the Raspberry Pi and the MCU and changed the cable to power up the Raspberry Pi.
Changed the power supply for the Raspberry Pi.
Removed the camera from the Raspberry Pi.
Changed the board to Raspberry Pi 4 with a stronger power supply, and kept trying different USB sockets to no avail.
I did a clean re-flash and re-install of everything (Klipper and firmware).
Checked the MCU cable that they are connected properly.

Printer: Kobra Max
Upgrades: R65 to R65 Jumper
Board: Pi Zero 2 W
Recently when I was checking the Klippy.log I would see NULL lines in the log.
Klippy.log output:
Starting heater checks for extruder
Stats 29.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000000 mcu_task_stddev=0.000000 bytes_write=1997 bytes_read=4261 bytes_retransmit=0 bytes_invalid=0 send_seq=166 receive_seq=166 retransmit_seq=0 srtt=0.002 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199993922  heater_bed: target=0 temp=0.0 pwm=0.000 sysload=0.29 cputime=1.048 memavail=3659392 print_time=0.001 buffer_time=0.000 print_stall=0 extruder: target=0 temp=0.0 pwm=0.000
webhooks client 4131026064: New connection webhooks client 4131026064: Client info {'program': 'Moonraker', 'version': 'v0.8.0-182-g9785387'} webhooks: registering remote method 'shutdown_machine' for connection id: 4131026064 webhooks: registering remote method 'reboot_machine' for connection id: 4131026064 webhooks: registering remote method 'pause_job_queue' for connection id: 4131026064 webhooks: registering remote method 'start_job_queue' for connection id: 4131026064
Stats 30.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000000 mcu_task_stddev=0.000000 bytes_write=2003 bytes_read=4307 bytes_retransmit=0 bytes_invalid=0 send_seq=167 receive_seq=167 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199992990  heater_bed: target=0 temp=33.2 pwm=0.000 sysload=0.27 cputime=1.061 memavail=3659792 print_time=0.001 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
Stats 31.2: gcodein=0  mcu: mcu_awake=0.003 mcu_task_avg=0.000010 mcu_task_stddev=0.000019 bytes_write=2009 bytes_read=4443 bytes_retransmit=0 bytes_invalid=0 send_seq=168 receive_seq=168 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199992513  heater_bed: target=0 temp=33.2 pwm=0.000 sysload=0.27 cputime=1.078 memavail=3659672 print_time=0.001 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
Stats 32.2: gcodein=0  mcu: mcu_awake=0.003 mcu_task_avg=0.000010 mcu_task_stddev=0.000019 bytes_write=2015 bytes_read=4564 bytes_retransmit=0 bytes_invalid=0 send_seq=169 receive_seq=169 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199994131  heater_bed: target=0 temp=33.2 pwm=0.000 sysload=0.27 cputime=1.095 memavail=3659672 print_time=0.001 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
Stats 33.2: gcodein=0  mcu: mcu_awake=0.003 mcu_task_avg=0.000010 mcu_task_stddev=0.000019 bytes_write=2021 bytes_read=4670 bytes_retransmit=0 bytes_invalid=0 send_seq=170 receive_seq=170 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199993743  heater_bed: target=0 temp=33.2 pwm=0.000 sysload=0.27 cputime=1.105 memavail=3659076 print_time=0.001 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
Stats 34.2: gcodein=0  mcu: mcu_awake=0.003 mcu_task_avg=0.000010 mcu_task_stddev=0.000019 bytes_write=2027 bytes_read=4783 bytes_retransmit=0 bytes_invalid=0 send_seq=171 receive_seq=171 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199993249  heater_bed: target=0 temp=33.2 pwm=0.000 sysload=0.27 cputime=1.113 memavail=3655044 print_time=0.001 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
Stats 35.2: gcodein=0  mcu: mcu_awake=0.003 mcu_task_avg=0.000010 mcu_task_stddev=0.000019 bytes_write=2033 bytes_read=4901 bytes_retransmit=0 bytes_invalid=0 send_seq=172 receive_seq=172 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199993184  heater_bed: target=0 temp=33.2 pwm=0.000 sysload=0.25 cputime=1.122 memavail=3653168 print_time=0.001 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
Stats 36.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000005 mcu_task_stddev=0.000004 bytes_write=2039 bytes_read=5020 bytes_retransmit=0 bytes_invalid=0 send_seq=173 receive_seq=173 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199993078  heater_bed: target=0 temp=33.2 pwm=0.000 sysload=0.25 cputime=1.128 memavail=3653168 print_time=0.001 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
Stats 37.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000005 mcu_task_stddev=0.000004 bytes_write=2045 bytes_read=5141 bytes_retransmit=0 bytes_invalid=0 send_seq=174 receive_seq=174 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199992990  heater_bed: target=0 temp=33.1 pwm=0.000 sysload=0.25 cputime=1.135 memavail=3653168 print_time=0.001 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
Stats 38.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000005 mcu_task_stddev=0.000004 bytes_write=2051 bytes_read=5262 bytes_retransmit=0 bytes_invalid=0 send_seq=175 receive_seq=175 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199992945  heater_bed: target=0 temp=33.2 pwm=0.000 sysload=0.25 cputime=1.147 memavail=3652468 print_time=0.001 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
Heater heater_bed approaching new target of 40.000
Stats 39.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000005 mcu_task_stddev=0.000004 bytes_write=2073 bytes_read=5373 bytes_retransmit=0 bytes_invalid=0 send_seq=177 receive_seq=177 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199993184  heater_bed: target=40 temp=33.1 pwm=1.000 sysload=0.25 cputime=1.167 memavail=3652468 print_time=47.779 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.7 pwm=0.000
Stats 40.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000005 mcu_task_stddev=0.000004 bytes_write=2095 bytes_read=5499 bytes_retransmit=0 bytes_invalid=0 send_seq=179 receive_seq=179 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199993465  heater_bed: target=40 temp=33.1 pwm=1.000 sysload=0.31 cputime=1.182 memavail=3649696 print_time=47.779 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
Stats 41.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000005 mcu_task_stddev=0.000004 bytes_write=2101 bytes_read=5633 bytes_retransmit=0 bytes_invalid=0 send_seq=180 receive_seq=180 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199993376  heater_bed: target=40 temp=33.2 pwm=1.000 sysload=0.31 cputime=1.191 memavail=3652476 print_time=47.779 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.5 pwm=0.000
Stats 42.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000005 mcu_task_stddev=0.000004 bytes_write=2107 bytes_read=5739 bytes_retransmit=0 bytes_invalid=0 send_seq=181 receive_seq=181 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199993289  heater_bed: target=40 temp=33.2 pwm=1.000 sysload=0.31 cputime=1.197 memavail=3652476 print_time=47.779 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
Stats 43.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000005 mcu_task_stddev=0.000004 bytes_write=2129 bytes_read=5865 bytes_retransmit=0 bytes_invalid=0 send_seq=183 receive_seq=183 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199993252  heater_bed: target=40 temp=33.3 pwm=1.000 sysload=0.31 cputime=1.204 memavail=3652476 print_time=47.779 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
Stats 44.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000005 mcu_task_stddev=0.000004 bytes_write=2135 bytes_read=5986 bytes_retransmit=0 bytes_invalid=0 send_seq=184 receive_seq=184 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199993197  heater_bed: target=40 temp=33.4 pwm=1.000 sysload=0.31 cputime=1.211 memavail=3652476 print_time=47.779 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
Stats 45.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000005 mcu_task_stddev=0.000004 bytes_write=2141 bytes_read=6092 bytes_retransmit=0 bytes_invalid=0 send_seq=185 receive_seq=185 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199993219  heater_bed: target=40 temp=33.4 pwm=1.000 sysload=0.28 cputime=1.220 memavail=3652480 print_time=47.779 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
Stats 46.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000005 mcu_task_stddev=0.000004 bytes_write=2179 bytes_read=6236 bytes_retransmit=0 bytes_invalid=0 send_seq=188 receive_seq=188 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199993307  heater_bed: target=40 temp=33.6 pwm=0.846 sysload=0.28 cputime=1.236 memavail=3649572 print_time=47.779 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.7 pwm=0.000
Stats 47.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000005 mcu_task_stddev=0.000004 bytes_write=2233 bytes_read=6372 bytes_retransmit=0 bytes_invalid=0 send_seq=192 receive_seq=192 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199993302  heater_bed: target=40 temp=33.5 pwm=1.000 sysload=0.28 cputime=1.246 memavail=3652492 print_time=47.779 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
Stats 48.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000005 mcu_task_stddev=0.000004 bytes_write=2282 bytes_read=6488 bytes_retransmit=0 bytes_invalid=0 send_seq=195 receive_seq=195 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199993262  heater_bed: target=40 temp=33.7 pwm=0.784 sysload=0.28 cputime=1.253 memavail=3652492 print_time=47.779 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
b'Got EOF when reading from device'
Stats 49.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000005 mcu_task_stddev=0.000004 bytes_write=2320 bytes_read=6574 bytes_retransmit=0 bytes_invalid=0 send_seq=198 receive_seq=198 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=199993201  heater_bed: target=40 temp=33.8 pwm=0.875 sysload=0.28 cputime=1.261 memavail=3652492 print_time=47.779 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
Stats 50.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000005 mcu_task_stddev=0.000004 bytes_write=2320 bytes_read=6574 bytes_retransmit=0 bytes_invalid=0 send_seq=198 receive_seq=198 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=1 freq=199993201  heater_bed: target=40 temp=33.8 pwm=0.875 sysload=0.26 cputime=1.266 memavail=3652492 print_time=47.779 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
Stats 51.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000005 mcu_task_stddev=0.000004 bytes_write=2320 bytes_read=6574 bytes_retransmit=0 bytes_invalid=0 send_seq=198 receive_seq=198 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=2 freq=199993201  heater_bed: target=40 temp=33.8 pwm=0.875 sysload=0.26 cputime=1.273 memavail=3652492 print_time=47.779 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
Stats 52.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000005 mcu_task_stddev=0.000004 bytes_write=2320 bytes_read=6574 bytes_retransmit=0 bytes_invalid=0 send_seq=198 receive_seq=198 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=3 freq=199993201  heater_bed: target=40 temp=33.8 pwm=0.875 sysload=0.26 cputime=1.283 memavail=3651152 print_time=47.779 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
Stats 53.2: gcodein=0  mcu: mcu_awake=0.000 mcu_task_avg=0.000005 mcu_task_stddev=0.000004 bytes_write=2320 bytes_read=6574 bytes_retransmit=0 bytes_invalid=0 send_seq=198 receive_seq=198 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=4 freq=199993201  heater_bed: target=40 temp=33.8 pwm=0.875 sysload=0.26 cputime=1.290 memavail=3653008 print_time=47.779 buffer_time=0.000 print_stall=0 extruder: target=0 temp=24.6 pwm=0.000
�������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������


text:
Aquila X3 small firmware does not flash to board
I'm using the MRiscoCProUI firmware on my Aquila X3 printer, but when I enable more features in the firmware, I'm unable to flash the printer.
I already tried several options and independently of the ones chosen, when the firmware gets to around 230 kB, I'm unable to flash it.
The printer has a N32G455RE chip which has a 512 kB ROM, so I should be able to flash it, right?
Any ideas on what can be causing this?
EDIT: Apparently this is due to the bootloader not being able to handle firmware above 228KB.
Does this make any sense?
Is there any way that I can ensure the problem is really this?


text:
Creality Ender 3 v2 Neo bed leveling doesn't seem to work
I purchased an Ender 3 v2 Neo a few days ago, but every time I try to do the bed leveling it is either too close and the nozzle touches the bed (even though it was fine while leveling) or just completely misses it and travels a few mm above it.
I tried really thin paper, regular A4 but every time I start a test print (the one that prints a little circle on the corners and in the middle) it's just the worst possible outcome every time.
Tried following multiple YouTube videos step by step but none seem to help.
I made sure that the nozzle wasn't too close to the bed, but no.
Not sure if it's a problem but I also had to use the offset feature to get close enough.
What should I do/change?

I am having the same issue... Although I'm at the part where I'm not sure if I'm the problem or the printer. Gonna start with a detailed manual leveling and messing with the tensions


text:
How to upload firmware to 8-bit Ender-3 1.1.2 without USB port
We have an old Ender-3, and the board is numbered 1.1.2. We're trying to update the firmware, but there isn't a USB port (the previous owner seems to have desoldered the USB port?!) so we're figuring out how to do it by the ISP pins and/or SD card. Using the ISP pins on the board and an Arduino, we've successfully blanked it and put a bootloader on, but we have no idea how to put the OS (Marlin) on now. We can only find versions of Marlin as far back as 1.1.4 as well.
Apparently you can't upload the OS via SD on 8-bit printers, which the 1.1.2 is. Is there a way to do it using the ISP pins or over the SD or something? I'd rather not have to solder a surface-mount USB port to damaged pads on the motherboard without proper surface-mount facilities...
We also have 4.2.2s which I've uploaded OSs to without issue.

you can use a regular iron to surface mount a microusb header, especially one that's already been used (pre-tinned). there's only 4 traces to connect, so even if damaged, you can follow them back and vampire to another exposed pad, like 5v from the voltage regulator for example. in fact, it doesn't even need to be on the PCB; keep the bodge wires short and manually run 4 24awg wires to the various connection points on the PCB and usb connector. that should last enough to re-upload.

@dandavis we're trying to solder to the surface mount pads right now and it's very difficult to get the heat on all the pads at once. we don't have a heat gun to hand so we might need to get/borrow one...? it doesn't help that it's been used because the pads seem damaged

you don't have to get them all at once, one finger at a time works, as does copious solder. You can clean it up at the end with solder braid/wick, or just a stripped stranded copper wire, like you might use for speakers, to soak up an extra solder.

good idea; we'll have a go on monday and let you know, thanks :)

Any news? If it doesn't work, might be a good excuse to get a new/better main board. That's what i did after fixing it twice...


text:
Ender 3 printer won't auto home
After building my Ender 3 printer, installing the CR touch auto bed leveling kit, and the Ender-3 Marlin2.0.6 CR-Touch or BLTouch firmware for it. I turned it on and tried to auto home but it just made a little noise and then displayed "Homing failed printer halted please restart". So I tested the end stops with a multimeter and they all seemed fine. I did some research and found the CR touch firmware could be the problem and installed some newer firmware (Ender-3Marlin2.0.6HW4.2.2GD) and nothing has changed. What should I do?

The reason I was having this problem was because of a file I had extracted that was on the sd card.
I noticed an orange dot at the end of the extracted file, so I thought it was probably flashing and interfering with the firmware. After I deleted the extracted file and flashed the firmware it ran perfectly.

Where was the "orange dot", and how did you see it? Was it in the filename, or inside the file when viewed with.text editor, or did you see it in some other manner?

Also, please don't forget to mark your answer as the "accepted answer" (you may have to wait up to 48 hours). Thanks.

This answer doesn't make much sense to me. You got it homing, but not working with the CR Touch? Shouldn't that be the crux of the question, i.e. getting it to home with the leveling sensor?


text:
3D printer X-axis sometimes binds up whilst printing
My MK2s has developed a strange problem where the X-axis will bind up whilst printing. This causes it to layer shift. The strange thing is I can move the X-axis manually. It doesn't bind up and feels smooth. But halfway into a print, I heard the X-axis make a scrapping sound that's distinctive to it struggling to move.
The bearings are still the original bearings but have had very little use. Maybe 30 hours of printing if that.
I have already taken the X-axis apart and cleaned it with some bike cleaner( didn't have enough alcohol to form a bath. Before I cleaned it, it wasn't moving smoothly along the rails. Now it does move smoothly on the rails but did bind up mid-print.
I have checked the X-axis belt, it doesn't seem to be too loose or tight. I tighten the screws that adjust the belt tension by hand so I doubt it's too tight. It makes the distinctive sound of a guitar string when you run your finger across the belt.
I am thoroughly confused. Could it be a bad bearing?


text:
Is it possible to easily convert a PDF generated from Solidworks back to a 3d model?
I have a PDF of a 3d model that when I view the document properties in chrome I see it was generated with Solidworks PDF publisher (see attached picture). I could go through the work of manually rebuilding the model, but I don't want to if I don't have to, also I don't know how to use 3d modelling software very well, so there's probably a pretty big learning curve.
Is it likely that the pdf contains the metadata necessary to be imported back into a 3d modelling program of any kind? If so, which program and where would I start with that?

I really don't think this would be possible. The PDF would be a 2D representation of the 3D object, i.e. a photo of a statue as opposed to the statue itself.


text:
How to approximately change the density at a specific point in G-code
So let’s say I have the G-code file for 3D printing a cube, and I have a density function F(x,y,z). How would I change, in G-code, the density at each specific point in the cube, so it has the general distribution of the function?
I’m thinking of just changing the extrusion rate proportional to the density, but I would like something more accurate.

Could you please explain how a change in density relates to 3D printing?

I apologize. I meant, if I wanted to 3D print, in GCode, a cube of a specified length which has a density distribution described some function F(x,,y,z)

Why do you want to do that? And what is the density? Is this related to the infill or the actual density? A G-code is sliced geometry containing the information of the selected options during slicing, if you change the extrusion modifier, your geometry will also change if applied to the walls.

@0scar, I mean the actual density. I want the density of the cube to vary according to the function. I just thought it would be a fun project. Are you saying that if I change the density at the walls, I will have to change the shape of the cube?

If you change the extrusion modifier, the lines get wider, so you need to apply this to the infill only, otherwise you'll get a distorted print object.


text:
Need help identifying cause of frequent Y layer shifts
I'm getting frequent layer shifts, always in the Y-axis.  It's happening on more than one model, at least four to date, and on multiple attempts at the same models.  Some of the models are mine (Tinkercad), some from Thingiverse.  I can't think of any model that has not failed recently except some very small, simple ones.
The printer is a RepRapGuru I3 clone, from a kit, purchased, built, and put in service in Summer 2018.  I've been using it almost daily since.  It's gone through at least 50*1 kg spools of filament in that time so has seen a lot of use.
The printer has a single direct drive extruder, not Bowden.  The frame is acrylic/plexiglass.  The frame is solid, with no loose fasteners and no cracks that I can detect.  There's no "soft foot".
If a model fails, it fails consistently on every attempt to print it.  The layer shifts occur often, but not always, at exactly the same point in the print job.  In those cases where I've witnessed the shift, there seems to always be a very rapid "jitterbug" motion going on, as in inter-wall infill or while laying down a long narrow section of the model or while building overhang.  It happens sometimes, but not exclusively, on the first continuous layer of a "ceiling" above infill and often at or near a corner of the model. I don't believe I've seen it happen on the bottom few layers where the model has a solid "floor" nor during "steady steaming" printing of a large surface.
The magnitude of the shift varies but is typically roughly 5 mm, give or take. One, however, was about 30 mm. When it happens the sound suggests to me that the motor is slipping poles, not that the belt is slipping on the pulley, but that's only an impression. [NOTE: It's just occurred to me that I can put match marks on the belt and pulley.  After a layer shift, if they're still aligned, I can pretty much rule out belt slippage. There's only a 1 in 20 chance they'd still be aligned after a shift.  Will do that tonight.]
The failures I've seen do not occur at the beginning of a layer, i.e. during perimeter printing; they occur somewhere in the middle details of a layer.
The layer shifts began a few months ago.  Prior to that, the machine had no chronic problems.
I few months ago (note the coincidence with the above paragraph) I rebuilt the printer with all new guide rods, linear bearings, belts, and pulleys, in stages over several weeks.
Before and after those updates, the Y carriage moved/moves smoothly and freely through its entire range with no tight spots.
Later still, I replaced the original quarter-inch acrylic Y carriage plate with a 3 mm thick (220 X 220 mm) aluminum one, with four linear bearings (new ones again) in new aluminum pillow blocks vice the original three bearings in split plastic pillow blocks on the original. I replaced the original heated bed with a new one that has, unlike the original, a 3 mm aluminum backing plate.  The very wimpy original heat bed springs were replaced with new, stiffer ones.
The Y layer shifts started sometime shortly before or during the first series of updates.  I'm certain the problem predates the heat bed and Y carriage replacement, but I've included that info above to communicate the current state of the machine.
I'm unsure whether this issue began before, during, or after the guide rod, bearing, belt, and pulley replacement, which were done in phases over several weeks.  I can't definitely tie the issue to any particular phase of those upgrades.  The layer shifts definitely began before the heat bed and Y carriage plate replacements.
Y belt tension is pretty normal, certainly not loose enough to cause it to jump teeth yet not overly tight.  Tension is similar to that of the X belt, but that has a shorter span so maybe apples and oranges.
Speeds slow/fast Settings:

Print: 40/60 mm/s
Travel: 65/80 mm/s
First Layer: 30/30 mm/s
Outer Perimeter: 40/40 mm/s
Inner Perimeter: 40/40 mm/s
Infill: 40/40 mm/s
Skin Infill: 40/49 mm/s

The only changes to these speeds have been to reduce some of them since the layer shift problems began.  None were particularly high to begin with except Travel/High was 150 mm/s vice the current 80 mm/s. Reducing them had no effect on the problem.
I typically run with retraction (2.5 mm; 40 mm/s) and Z-hop (0.5 mm) turned on.
The Marlin firmware on the 2560 main board has never been updated or modified in any way.  I don't know the version but it's whatever RepRapGuru shipped with their kits in mid-2018.  The shield board is RAMPS; I'm almost sure I remember "Version 1.4" on the box it came in within the kit.
I've never attempted to modify acceleration or jerk settings.  They're as they've always been.
I use Repetier V2.3.2 software.  I use the embedded "Cura Engine", which I believe is really an older Cura Steam Engine slicer, not the current Cura slicer.  I have not tried other slicers.
The machine is controlled directly from a PC using the Repetier software and the embedded CuraEngine slicer; there is no SD card slot, digital display, or rotary encoder control.  Gcode comes directly from the Repetier software on the PC to the printer via the USB connection.
Things I've tried:

I've used the "Cut off Bottom" feature of the slicer to print test versions of some of the problem models at partial height, beginning a few layers before the common failure points.  The failures still occur mostly at the same point in the model, indicating height above the bed is not the determining factor.

Where I can identify a common failure point in a model, I've examined the G-code in the vicinity of the failure point of a couple of models and can't see anything anomalous.  I should point out I'm not a G-code expert.

I sent the G-code output from my slicer for an object that is consistently failing with layer shifts, to a friend.  He printed it on his machine without problems (different machine, but still Marlin/RAMPS).  This seemed to absolve the slicer/G-code as the culprit.

I swapped the X and Y stepper motors.  The layer shifts continued, still always in the Y-axis.  Motor shafts were straight and undamaged, motor mounting screws were tight as found, bearings seemed OK, and pulley set screws were tight.  This seemed to absolve the Y stepper motor.

I swapped the Y stepper driver board with the unused E1 stepper board. The layer shifts continued, still always in the Y-axis.  This seemed to absolve the stepper driver. (The motor and driver swaps were performed independently, with a failed test after each.  Motors and driver boards are the originals.)

I rechecked the stepper current limit settings on the driver boards and all were found OK.  The largest discrepancy from the target setting (0.50 V) was 0.03 V.

I had installed "smoothers", i.e. Schottky diode boards, between the drivers and stepper motors on X and Y a few years ago and never had problems but also didn't note any improvement from them at the time.  I removed them during these problems without affecting the layer shift issue.  They remain out.

I put an 80 mm muffin fan on the bench, directed toward the stepper drivers. It had no effect on the layer shifts.

After match marking the Y motor pulley and belt, I ran another test print.  I killed the print after a series of Y layer shifts totaling approximately 8 mm in the +Y direction.  The belt/pulley match marks were still aligned.  This indicates pole slip.
The slips I observed were occurring where the printer was beginning to build a small section of overhang, where a brief but rapid series of short moves were made.  There was a definite, dull clunk each time the motor slipped.
I was monitoring the 2560 Vcc at the time and saw nothing unusual.

I don't know if this should be edited into the body above or in a comment here...   If this is wrong, let me know and I'll move it.  A Repetier Host Forum rep has suggested that the problem is crosstalk between Y endstop wires and other conductors.  Apparently Marlin checks the Y endstop during moves.  I've braided the three conductors to the Y endstop and encased the Y motor cable in grounded, braided copper sheathing.  No change in behavior.

Thanks to some help from an expert this issue is resolved. The culprit was crosstalk between the X motor cable and the sense line of the Y endstop. Re-routing cables to separate the two has solved the problem.
Marlin monitors the endstop switches while printing unless inhibited by an option in the firmware; default is monitoring enabled. If a false low is detected during a move that move is stopped, resulting in a layer shift


text:
How to design for parts that slot into each other
I want a cable management tray for my height-adjustable desk.
I came up with the following design: CableManagementLarge
It appears to fit nicely in CAD but when printed the parts don't fit nicely. You can use force but it distorts the part. I have already snapped 2 of them.
Any advice will be greatly appreciated.
It would have been easier to buy a tray. However, that would have robbed me of the chance to learn more about designing for 3D printing.
Here is an image to show how it distorts the hanger part:

As you can see in the image, the hanger part is bent. I have checked the calibration of the printer, it seems fine on both the X and Y-axis. It's 0.2 mm out on the Z-axis.

To be honest and not trying to insult, the print quality of the parts is really bad. What printer is this?

You can try reducing the size of the part that goes in by 0.5mm and see how it goes. Also I agree with above comment you might want to tune in your printer to to get better prints.

Clearance
For parts that slot into one another, you need to include clearance. This clearance depends on your printer configuration and can be between 0.1 mm and 0.5 mm.
Calibrate your printer!
You might want to calibrate your printer and profile to learn what distance of clearance you need for your specific printer.


text:
What is a good filament for a frame for holding high amp copper busbar?
I need a frame to hold a copper busbar in place.  The busbar is rated up to 200 amps and can be wrapped in an insulator, so the frame will sit around the insulator of the busbar, but I don't know how hot it gets.
I would like to 3D print a frame to hold the busbar in place, what is the most suitable filament for this application?

Without knowing how hot the busbar gets, or a vague temperature range required, it might be difficult to suggest a solution.

I would use ABS, but you shouldn't rely on the filament. This is a job for insulation to take care of. You don't expect the holder to do any more than hold the component in electrical applications.


text:
How can I get PLA to stick to my printer bed?
I'm printing a model, sliced in Cura, on a Monoprice Mini Delta v2.
The model is long, about the width of the print bed. When I print it, the extruder drags the filament (which should stay in place) into the wrong position.
To summarize, my white PLA won't stick to the print bed (which is heated to 40 °C). Is the bed temp too low? Is the nozzle too high (200 °C)?
If someone could tell me how to get the PLA to stick- preferably a long-term option like print or bed temp - it would be greatly appreciated.

Probably the initial distance is too large, and you may increase temperature of the bed to 50 °C or use an adhesive. Could you provide some photos?

what's the print surface? ever since i moved to a slightly textured mat, i've not had to fuss with tape, gluesticks, etc.

I would go with 60 degrees on the bed and check the bed levelling. You shouldn't be having a problem with PLA if the levelling is fine unless your filament has gone bad.


text:
Changing axial fan on CR-10 smart caused temp fluctuation/heat creep
Printer: Creality CR-10 Smart
Slicer: Cura
My axial fan, which cools the heatsink, broke down. I replaced it with a cheap knock-off fan, as it was the only option available. However, this replacement caused temperature fluctuations that went beyond the acceptable range.
Here's what I tried to fix the issue:

I initially tried flipping the direction of the axial fan to make it blow hot air instead of surrounding air. This seemed to work for a while, but it caused heat to build up, and my 3D printer's filament stopped extruding from the nozzle.

I attempted to lower the current supplied to the fan, thinking it might help. However, this turned out to be a bad idea, as I wasn't sure how much current the main board could safely supply through this port. The result was that the resistor I used got fried.

I then decided to mount a 740 Ω resistor in series to create a voltage drop, leaving about 10 volts for the fan. Unfortunately, this also led to heat build-up.

Finally, I tried mounting a 320 Ω resistor, leaving about 14.5 volts for the fan, and this seemed to work fine.

I'm concerned about heat dissipation and the overall reliability of this solution. What are your thoughts on this?
The issue stems from the small size of the heatsink and the large size of the axial fan, which directly faces the heat block. I'm now considering the option of mounting a 24 V, 3x3 cm fan and creating a custom mount for it.

instead of messing around with resistors, get a cheap adjustable fan speed controller with a knob.

not available in my area

After encountering issues with an unknown brand fan overpowering the Creality fan, I experimented with resistors. Initially, a 330-ohm resistor resolved the thermal runaway warning but led to under-extrusion due to inadequate cooling.

A 100-ohm resistor addressed under-extrusion but triggered thermal runaway.

The optimal solution was a 220-ohm resistor, resolving both issues.

I've tested this setup for approximately 1 day, 11 hours, and 7 minutes with successful results.

why is that? the reading on the Multimeter is the voltage drop through the resistor.

True! I misread the connections.


text:
Creality Ender 3 v2 1st layer too high off bed
On my Creality Ender 3 v2, I have performed bed levelling and am fairly confident that the nozzle height is correct - a piece of paper under the nozzle can be pulled out with a gentle tug. For some reason, the first layer that prints always has the nozzle too far off the bed and so it's not adhering correctly.
I'm not sure if I've missed something with bed levelling, or if there is some other setting I need to tweak.
FYI I'm printing with a 0.8 mm diameter nozzle with 0.5 mm layer height and 0.45 mm initial layer height. When I look at the printer in action, the first pass looks like the nozzle is about 1 mm off the bed.

Are you using a BL/CR Touch?

No I don’t think so. That’s the auto-levelling thing, right?

Yes. Have you tried lowering the Z Limit Switch bracket?

No, I did see some article mentioning to make sure it’s straight, but not tried to lower it yet.

Does this answer your question? Nozzle not level and first print failed

Can you add a photo and a link to your G-code to see if there is something wrong in the start G-code? Without much more information, this could be closed referring to the previously mentioned topic as a duplicate.

I think there were two things wrong here:

I was not levelling the bed correctly - I was manually moving the z-axis down to the lower limit - which can be slightly different to the printer lowering until the limit switch activates (Menu > Prepare > Auto home).

Looking at the suggested answer Nozzle not level and first print failed I did check the position of my z-axis limit switch and it was pushed all the way downwards. I decided to try filing a bit off the notch which rests on the base rails so that the z-limit would be hit a bit lower.

Is this an answer that solves your issue, or actually an update to the question? If the latter, then please edit your question and add it there. If the former, then please mark this as the accepted answer.

You can check for offsets to the home positions. M206 will show home offsets. If you have automated bed levelling with probing there is another offset to view with M851. Depending on firmware versions you might have to run M503 to show all the offsets.

As it’s currently written, your answer is unclear. Please [edit] to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.

Thanks for answering. Could you explain how I use those G-codes to get the offsets?


text:
Are fully cured Polyjet parts safe to sand?
I work with poly-jet printed parts, more specifically, Stratasys objet pro, printed in Vero Black.
The parts are always fully cured before taken off the bed.
We are sometimes required to sand these printed parts down once support material is removed.
Is the dust given off during sanding (with sand paper or a Dremel tool) harmful similar to uncured material? can the dust given off whilst sanding still be carcinogenic if you breathe it in? or the fact that the material is cured makes it safe?
Just to add, it's only a few instances I've sanded to the point lots of particles are given off, usually its just a quick dash on the sandpaper.

Do you have an MSDS for the material? It would more than likely have the information you are seeking.

I have found one for Vero Black, though it is not clear if the measures recommended are for the material pre or post curing:                                                        https://protouk.com/3d-printing-data/MSDS-Vero-black-plus-SDS-06142_F_EN_AGHS_RGD875.pdf

It may be quicker to contact the manufacturer than wait for a random person to come across this question to give you the answer.


text:
Print walls coming out with gaps/holes
I'm using a Prusa i3 MK3, with Prusa Slicer 2.2.  It seems to print the raft fine, but then when it gets to the main part, it seems that the extrusion comes out thinner, and leaves gaps/holes in the layers.

Filament: PLA
Layer height: 0.1 mm
Infill: 30% Gyroid
Print speed:

Perimeters: 35 mm/s
Infill: 50 mm/s
First layer speed: 20 mm/s

Extruder temp: 205 °C
Nozzle diameter: 0.4 mm
Retraction length: 2 mm

That is a major example of underextrusion! Have you you investigated the regular suspects? Lower hotend temperature, lower retraction to 0.8 mm @35 mm/s, filament diameter check, increase layer height?

I was initially at 215, so I just dropped it to 205 for this print and saw similar results.  I'll try dropping it a little bit more.

Very interested to learn if lowering it a bit more helped.


text:
What does extensive Z-offset processing in Creality 4.8 slicer mean? How does it differ from a simple Z-offset setting?
I am facing a problem where the nozzle begins scrapping only on one side of the print as the print thickness builds up on the bed. I am building a skirt comprising 10 rasters as well and over there the bed level appears to be pretty uniform on all sides around the print.
In this context, I wanted to understand what the extensive Z-offset processing means and if this could address the problem I am facing. The Z-offset setting I have is -0.06 mm in the slicer and -3.15 mm on the printer. There is no scrapping on any other side of the printed object.
I also want to understand why the build plate adhesion setting (highlighted in the image) is shown as off while I am building a skirt around the print which is set up from the build plate adhesion setting.

TLDR: The Extensive Z Offset Processing option changes the G-code for any/all Z movement.
According to an answer by fieldofView on the GitHub question Z-Offset incrementing in some situations?:

You can try setting the "Extensive Z Offset Processing" option. This will change all the Z coordinates in the gcode instead of manipulating the coordinate system. [bold mine]

I was able to confirm this from an answer by ahoeben on the Ultimaker Community question Cura settings: Improving naming and descriptions:

This is provided by the Z Offset plugin (which - coincidentally - I wrote). Keeping this setting "off" is much faster, since it only needs to insert a couple of lines of code. Turning the setting on will need to process the whole gcode file and modify all moves that have a Z value. The option is there because the better, faster way does not work on some specificly broken firmware versions and printers. [bold mine]

BTW, I turned the extensive z-offset setting on and the problem did not go away. I was printing ASTM D638 type I specimens.


text:
PLA prints with folded walls
Printer: Bambu Lab P1P
Filament: PLA (Ender Series)
All looks good, but for some reason, the outer walls are folded inwards a little bit. All walls are supposed to be straight. I printed it using Bambu Studio with default settings for Generic PLA.
What could cause such a defect and how to fix it?
Previously, I printed out a box that is a bit bigger with separative walls for minidiscs and it printed perfectly. In that model, other walls were thicker.

Does this happen across all speed modes ? have you tried calibrating to your filament

@F.Ahmed I have calibrated the filament, but haven't tried to experiment with speed modes. Thank you. Will try that.


text:
How to maintain 1 mm rounding when I need 3 mm in a single axis?
I have planned a simple object in TinkerCAD from a box with radius set to 1 mm.
However I would need to get a 3 mm rounding on the vertical axis, therefore I have added a quarter circular eraser.
Please see both of these in this shot:

Now it's time to round the red one:

Looks good from top-angle:

But it's not rounded properly from other angles:

I wish to maintain the 1 mm rounding on the whole edge, how can I do that?
I tried many things:
1.) Inverse ring eraser: almost good, but I would need 2 mm width, and 3 mm outer radius which is impossible (for a ring).

2.) Inverse half sphere: not good, as it's not the shape I need
Finally
I succeeded with a "hack": ring with 4 mm width and 6 mm radius, then scaled back to 50 %, making it 3 radius and 2 mm width. Then create variuos inverse-quarters from it (eraser) and tune them even further removing unnecessary halves:

Using these erasers I could finally reach my goal:

However this is super-tedious, is there a better software out (I'm sure it is), which can do this "rounding" effect on any object? Now I'm satisfied, but if I need to

increase the height
change the size

I'm screwed up: will have to "slice" this object to 3 pieces, increase the size of the middle, and then put them back together. Do this for every single axis. (= scale operation I'll need to slice this object to 9 pieces).

TinkerCAD is a fine tool for simple designs, but when you need to fillet or chamfer corners, this involves too many actions where you cut out the parts to get the requested fillet/chamfer. It might be interesting to save time to move to a different design tool.
This geometry is recreated in a few minutes in e.g. Fusion360, considering this is a simple design, you need to change the order of the actions to fillet the object properly. Fillet the corners of the box prior to filetting the box itself:

In case the design is way more complex an alternative solution would be to join a cube in the corner and round that:


text:
Is there a possibility to print supports that have overhang themselves?
I've been looking for various ways to cut down on material costs in my 3D prints. One of them is reducing material in supports, or trying to get rid of supports completely. I do not have a question on how to reduce by changing settings regarding the supports but rather the shape of the supports.
I have an old Creality Ender 3, but it has no issues with printing +/-45° overhangs. Cura generates pretty much vertical supports for anything above a 45° angle, which makes sense. but would it be possible to have a slicer generate support where the walls of said support have overhangs themselves? Another way of putting it, the bottom of the support has a small surface and slowly expands upwards to the size of the roof that it is supporting. As long as the angle is under 45° this should be sturdy, but cut down significantly on support material.

I tried the other support option Cura offers (tree) but it's nowhere near what I mean. I feel like I'm on to something I just wouldn't know how to approach it.

It sounds like you're looking for Cura's "Conical Support" option, which I believe is still classified as "experimental" and not shown by default, but works great in my experience. Search for it and make it visible if it's not visible by default in your version of Cura.
The other option is using tree supports. These will naturally have overhangs (up to "Support Tree Angle"), but differ in lots of other ways that can make them a lot better or some what worse than "classic" supports depending on what you're trying to print.

I have successfully printed several things on a Creality Ender 3 V2 with Marlin 2.x firmware using the newly supported Tree Supports using the free Ultimaker Cura Slicer 5.5 as shown below:

Those supports are basically all overhangs and very easy to remove afterwards.


text:
My 3D printer is only printing 2 hours of a print
My 3D printer is only printing 2 hours of a print before it stops extruding filament. I have an Anycubic Mega Zero 2.0, it printed the print I was printing before but just recently it started happening.
I tried getting new nozzles. At first it seemed to work but I tried printing 3 of the skeleton fish and it just printed for 2 hours.
I don't have an Ender branded 3D printer that's just my build surface.

I dont think that is the model btw

Hi, welcome to 3DPrinting.SE! There are obvious reasons when filament stops extruding, but, a more sharp close-up of the print is required.

Ill have to get my phone then, i took it with my laptop

Is it a direct drive or Bowden tube?

Its through a tube

is it exactly 2 hours, or more specific, is it the exact same time of printing each time it stops? that points to software. If it's different but "about 2 hours", that sounds more like something overheating to me; run a box/stand /room fan over the printer while printing to see if that helps.


text:
Compute failed? Why?
I'm using (as pure beginner, please be respectful to my little knowledge in this topic) FreeCAD v0.21.1 for a simple design I wish to 3D print.
This is how it looks like from the front (at least partially):

Text is made with ShapeText and I applied a small Pocket onto it in Part Design:

I have many operations after this text pocket in the tree.
I'm satisfied with my results.
I however wished to make another one, with different text, so I followed a tutorial to copy my whole "Body_of_ND32" to a new "Body_of_ND16":

After this operation, I have got an error complaining "Recompute failed", and text pocket is containing the original "ND32" pocket, instead my new value.
Of course, I could rebuild the whole thing from scratch adding the text only at the end, to keep everything in shape, but can I somehow detect what's wrong with the recomputation?

A "Recompute failed" is not your fault. Freecad is a free CAD software that is maintained by more than 400 volunteers. It is a bug in the software and happens often, for example because of floating point rounding errors. Just moving or changing a shape or body a tiny amount might fix the problem. It could happen when intersecions happen exactly on a line, outlines make a shape self-intersect or beveled objects produce unexpected results or for other unexpected reasons. If you see a pattern in the cause of the error, you might file a bug report


text:
What causes an unstable ethernet connectivity with Manta M8P/CB1?
I'm working with a Manta M8P and CB1 and the environment I'm working in requires it to be directly connected to the PC via an ethernet cable. (Wi-Fi or ethernet connection to the router is not possible)
However, when I do this, the Mainsail interface is often not viewable and the SSH connection keeps breaking. I remember trying this with a Raspberry Pi in the past and there were no issues seeing Mainsail and SSH work.
Has anyone experienced this or does anyone know what's different with BTT that would cause this? I noticed the device seems to be working when it has an IPV4 address. But it only holds it for a few minutes, and I can tell it loses it when everything starts breaking.


text:
Is there a (common) way to embed used Slicer settings inside the G-code file?
Non-G-code data can be embedded in G-code files, like embedded base64 encoded thumbnails. I was wondering, is there is a common way to include (at least the most important) slicer settings that were used to generate that particular G-code file?
I have more and more design files and sliced G-code files, in OctoPrint folders and I sometimes really want to know what settings I used to slice it. For example, after the new Cura 5.5 upgrade, I was constantly wondering, which version I used for each independent file.
Also, I sometimes chose a different quality (layer height) or different infill percentage or scale. I now work around it by using a self-made file naming convention that consists of this:
ObjectName_v55_n06_q028_s100_i20_a1
- v Slicer Version (in my case always Cura)
- n Nozzle size (in mm)
- q Quality (Layer Height without the dot)
- s Scale percentage (0-100)
- i Infill percentage (0-100)
- a Amount (if object is multiplied)

But I really would like to see those things back in OctoPrint when opening a G-code file, so I can decide if I need to reslice, is there a plugin for Cura and OctoPrint, or a standardized way to save this info embedded in a G-code file and show it in OctoPrint?

While it is not the G-code file, a .3mf file contains all the slicer parameters and includes the 3D model. Would that fill your needs?

I never really checked out the 3mf standard. It seems to be very interesting and what I asked for. Thanks for pointing that out. For reference: https://www.youtube.com/watch?v=BABdR9d8Cp4. Now I need to figure out and test if both OctoPrint and Marlin/Jyers for Creality Ender 3 v2 supports 3mf instead of stl. Do you know of any such solution particular for STL too?

Most slicers support the 3mf file format. From there, just slice the file as normal then send to your printer.

Last comment is my mistake "instead of stl" should be "instead of gcode". But this is exactly my problem. If 3mf can't be send to printer/octo, the actual file on the printer, I just have another file to keep track of. I see the value of 3mf for archiving the model with slice settings, but if there is still a separate gcode file for the printer, it defeats the purpose and doesn't solve my issue. Which is why I need to use the naming convention unfortunately. If I send gcode, my printer or octopi won't know the settings I used and I need to search back for my 3mf file to check.

Wouldn't it be easier to track the 3mf files on your computer instead of saving the G-code files? If the G-code file doesn't have the settings you need, you would still have to reload the stl, adjust your settings, slice the file, and then send it to the printer.

Definitely. However, since a gcode file is always necessary, and I have folders with gcode files only OctoPi (printer), when I quickly want to reprint something on the same machine, I want to be able to quickly know "resolution, version, amount" and that's not possible without my naming convention. Meaning going back to STL and reslicing. For example the upgrade to Cura 5.5 has quite a speed improvement, trash all 5.4 sliced gcode. Sometimes I want to print in higher or lower resolution, no way to know which it was sliced at in Octo or printer. Same for scale and amount.

Then it looks like implementing your file naming convention will be your solution. That will be a lot of work.

Cura already stores all the slicer settings in the G-code file as comments.
Install a G-code file viewer or file editor plugin in OctoPrint to view the used slicer settings for that specific G-code in OctoPrint.
The GcodeEditor plugin has the ability to view the actual G-code.

I'm using two GCode Viewer Plugins but I thought they are only for visualization? https://docs.octoprint.org/en/master/bundledplugins/gcodeviewer.html and https://plugins.octoprint.org/plugins/prettygcode/.

GcodeEditor looks like a good candidate. https://plugins.octoprint.org/plugins/GcodeEditor/

Notepad. Gcode is readable as a .txt file.


text:
What is the best time interval and method to stop heating the bed to start releasing before the print is finished?
I want to end the bed heating approximately X minutes before the print is finished so that the bed starts cooling and releasing the print.
Since an object can have different sizes and printing one layer can take very long or very quickly, I cannot simply insert an M140 S0 before the last layer. What is the best time interval and method to achieve this? Is there a Cura slicer extension for it, an OctoPrint plugin, or should I write a custom script for Cura? I mostly print with a 50 °C heated bed and PLA using OctoPi on a Creality Ender 3 v2 with Marlin firmware. With a printer bed at room temperature, the print could come loose too early while still printing, so 20 °C might be too extreme. Make sure the printer is finished when the bed is around 35-40 °C? Is there any theory and method to back this up? Does this method have a term or name?

Nice energy-saving idea. Similar to turning off the (electric) oven or ring ten minutes early, to allow the residual heat to continue the cooking.

That's another added benefit indeed. Although micro optimizations, this probably could also save some energy: https://3dprinting.stackexchange.com/questions/21565/what-are-the-pros-and-cons-of-automatically-disabling-stepper-motors-after-a-pri.

You barely save energy keeping a plate warm a few extra minutes, certainly with an insulated bottom. It will not cost much electricity. This has been seen before in various answers.
The chance the print releases increases with stopping heating the bed and increases the chance to mess up the print requiring a reprint. This will add frustration, filament costs and energy costs. Best interval is therefore zero (based on experience with printing on glass, at a certain temperature the print comes free from the build plate on glass). But, different surfaces may hold the print even when cold. E.g. PETG on PEI bonds very well.
If you really want to stop heating the bed, you need to determine for a few various sized prints the point at which the print releases. Based on your tests you could device a strategy to stop heating the bed.
If you want to release a print sooner after printing, get a removable build plate, e.g. a flexible coated steel plate or a few sheets of glass and place the print with glass in the fridge or somewhere where it is cooler.

The energy saving, as mentioned in the comments, is of least concern. Do you know of an existing implementation of this strategy (in OctoPrint, Marlin or Cura)?

@BobOrtiz No I don't know of such implementations, that doesn't guarantee it doesn't exist, but I think it doesn't exist for these exact reasons.

In addition to Oscar's answer, there is an OctoPrint plugin that attempts to achieve exactly that. The plugin uses the following and-condition to determine the moment to stop bed heating:
"printing finished for at least 90% and remaining print time is below 5 minutes".
The plugin is called OctoPrint-BedCooldown. Its page describes:

Turns off the bed heater toward the end of a print
For filaments such as PLA, many printers have more than enough stored thermal mass in the bed to keep bed adhesion throughout the print. Therefore, you may want to turn off the bed heater automatically before the end of a print, saving cooldown time.
The bed heater will be turned off during a print, when both conditions are met:

The print time left is below the configured threshold (default 300 seconds / 5 minutes)
The print completion percentage is above the configured threshold (default 90%)
This should cover both long and short prints; you wouldn’t want the bed to turn off 90% into a 20 hour print, or 5 minutes before the end of a 10 minute total print.

Be sure to monitor your print, as turning off the bed heater could cause the print to come loose prior to completion.

Nice find, but Ill refrain from using it!  Considering the caveat at the bottom, be careful!


text:
What are the pros and cons of automatically turning off stepper motors after a print? Does it increase the stepper motor's lifetime?
I've noticed several times that one of my stepper motors is making a slight noise after a print is finished, indicating it's still enabled; also, the axes are still statically positioned and unmovable.
I meant that the stepper motors are still powered. Usually, after a print, the extruder moves up and away, and the bed moves to the front. However, some X seconds after that, I would like to automatically turn off the steppers because it could potentially preserve the lifetime of my stepper motors.

Is this a common practice, and if so, does this method have a name?
Does it indeed potentially increase lifetime?
How to do it? (By simply adding M18/M84 at the end of my G-code using a Cura script or using an OctoPi plugin?)
Are there any other pros or cons to powering off stepper motors after the print has finished?

NAA: De-energising coils will probably extend the life by a certain amount, depending upon usage patterns. That is to say that the gain would be proportional to the times that (1) the printer is normally operational & (2) operationally idle. IOW, if you generally just switch the printer on for a job and then off, then disabling the steppers probably won't extend life much. But at the other extreme, if the printer is on 24/7, but idling for most of that time, then de-energising the steppers coils will help considerably more. Also, saving any amount of electricity is always a good idea :-)

While it's plausible that it might increase lifetime, I doubt it. Unless you're driving them out of spec and allowing them to overheat, motor coils should last pretty much indefinitely. The main wear component in a stepper motor is the bearings, not the coils, and the bearings do not get any additional wear from having the coils energized, only from actually turning.
The advantage you do get from turning off the steppers is energy savings. As long as the stepper is energized, you're burning roughly $I^2R$ watts, where $I$ is the current you're driving the motor at and $R$ is the coil resistance. You also eliminate the stepper hum, which can be really infuriating to some people's ears, and if your board has properly firmware-switchable fans, you let the fans power down too, which also saves energy and cuts noise.
Another aspect that can be an advantage or a disadvantage is that, once steppers are powered off, you can move the motion components by hand. This can be nice for adjusting the toolhead and bed to remove the completed print, but it can also cause the toolhead or bed to fall due to gravity, which can lead to damage to the printed part or the printer. If this is an issue, on most kinematic systems (pretty much anything but delta or corexz) you can leave the Z stepper(s) energized between prints, and only disable the X/Y ones. The reduction gearing/leadscrew lead on most printers makes it so Z doesn't need anywhere near the current of X/Y, so turning off X/Y and just leaving Z engaged still gets you most of the power conservation.


text:
Adding a custom G-code to parse strings from `configuration.h` in Marlin 2.0.x
I'm working with Marlin 2.0.x firmware for a special device, I have added an extra axis to the firmware and it's working well, However, I'd like to implement a custom G-code command that can parse a group of strings I've defined in the Configuration.h file.
Specifically, I want to:

Define a group of strings, for example, G** x** y**, G** z**, M** (like a series of codes) within Configuration.h.

Add a new custom G-code command, let's call it M9999, which, when sent to the printer, would trigger the firmware to parse and use the values of the previously defined custom strings in some way.

I've explored various resources and attempted modifications, but I'm struggling with the exact steps and code changes required to achieve this functionality. Could someone please provide guidance on how to properly define these strings and implement the custom G-code command within Marlin 2.0.x?
I have already checked Macros in Marlin firmware, but macros need to be redefined every time I turn on the printer as they can't be saved in the firmware or in the EEPROM. I have found a way to add a new G-code in gcode.c however I don't know which function can parse a string, or where to add this function.
In M810-M819, I found char * const cmd = gcode_macros[index]; if (strlen(cmd)) process_subcommands_now(cmd);. Can I use the function process_subcommands_now(cmd) to parse and run a group of G-codes predefined in configuration.h?
Your expertise and advice on the necessary modifications and syntax would be greatly appreciated.

I think you'll have better luck asking that question here: https://github.com/MarlinFirmware/Marlin/issues.