The absolute state of 3D printer firmware
-
When I started considering my guide for those new to 3D printing I considered a mainboard upgrade as part of that. I would not recommend that for most people, but we are all technology and programming. Configuring a couple of files and compiling seemed pretty easy for this group. And it should be.
But it isn't.
It really should be.
But it isn't.
For the past month I have been troubleshooting a random bug where one of my printers would just stop extruding at random times. It hasn't been every time. I had not found a way to reliably reproduce it. Googling for the issue returns the phone book. I would dig in to it here and there as I had time but kept coming up empty.
Now, my first thought was that it was the TMC2209 stepper drivers that I was using on the Z-axis and extruder. TMC2209 drivers are capable of sensorless homing via their StallGuard feature. Basically you can get rid of your endstops or not install them in the first place by setting the StallGuard threshold in firmware on mainboards that support TMC driver programming via UART. The drivers have extra pins to communicate this diag information. General best practices recommends removing these pins for steppers that will not be using StallGuard because "It can cause strange errors".
Well, that never sat well with me because if you don't enable StallGuard for those drivers in the firmware then they should just disregard those signals, right? Well, to be honest, fuck if I know. But I have spare TMC2208 drivers (That don't have StallGuard) sitting around so I swap them in, make the suitable changes in the config files, recompile and reflash the firmware.
Which is my huge annoyance with Marlin. Any big changes like that require you to recompile the firmware and flash it again. I mean, it isn't that big of a deal. When the mainboard boots, if there is a firmware.bin file at the root of the SD card it will flash that to the microcontroller, rename the file to firmware.cur and you're good to go. But it is still an annoyance. Other firmwares have configuration files on the SD card and by making changes in them and rebooting it pulls in the new config without having to recompile and reflash. But oh well. Marlin tends to be where features are innovated before they make it down to other firmwares. If you want the newest features you will probably need to run Marlin. (This is a broad generalization, but true more than it is not)
It's still happening. Since the TMC2208 drivers have higher internal resistance I am now getting prewarnings for overheating. Which means they are running a bit warmer than optimal. Maybe I introduced the same error again, via a hardware change? Unlikely, but I installed a fan on the electronics enclosure blowing right on the driver heatsinks.
This is the printer that I have setup for high temperatures and it is in an enclosure. Maybe the stepper motor is overheating? I mean, it doesn't seem too hot, but it is a pancake stepper motor and I configured the driver to run it up to maximum rated current. I cut the amperage until it starts skipping steps, turn it back up enough to work reliably (as reliably as it had been). Still happening.
I replaced the mainboard with a spare. Still happening. I replace the SKR 1.4 Turbo board with a spare SKR 1.3. Maybe there is some weird hardware incompatibility. Still happening.
I make more and more changes. I even ordered a 40mm heatsink to attach to the stepper driver. At this point I have changed so much shit that if it stops happening I will be to the point that I have NFC what fixed it and might not be much better than I was before. If I revert the rest of my changes to the firmware it might come back and I would be back at the beginning.
Still happening. There are zero errors in the serial logs. I investigate more, make other changes, recompile, reflash. Still happening. Eventually I get a new failure mode and the extruder just fucking stops working as soon as I start a print. If it isn't printing it extrudes just fine. But if I try to print the extruder just stops working. And not just not extruding, it freewheels like it is getting disabled as soon as I start a print.
I'm getting really annoyed.
Then I stumble upon a thread that mentions that TMC drivers on the extruder, with Marlin, with StealthChop and Linear Advance both enabled can cause this. Occasionally. For some unknown reason. The solution is to either disable Linear Advance or disable StealthChop on the extruder motor.
This bug dates back to at least 2018:
Marlin 1.1.9 - Linear Advance causes Trinamic TMC2208 motor drivers to shut off in StealthChop mode · Issue #11825 · MarlinFirmware/Marlin
Description Enabling Linear Advance while using Trinamic TMC2208 stepper drivers on the extruders almost immediately causes the extruder to stop extruding - any K factor larger than 0 has some file...
Another bug report from 2018:
[QUESTION] LIN_ADVANCE 1.5 -- extruder rattles *a lot*. · Issue #10272 · MarlinFirmware/Marlin
Description I'm trying to enable LIN_ADVANCE on bugfix-2.0.x branch on my CR-10s + Cohesion 3d remix board (smoothieboard variant). As soon as LIN_ADVANCE is enabled extruder starts rattling. X...
Another bug report from 2019:
[BUG] Motor stuttering with linear advance on TMC2208 since Marlin 2.0 · Issue #16155 · MarlinFirmware/Marlin
Hey there, in the past I often tried to switch to Marlin 2.0 from 1.1.9 but there was always some hinderance. Eventually I managed to sort out most of it (last was the motor knocking noise where yo...
2020:
[BUG] BTT SKR 1.4 Turbo, extruder stops mid print, TMC2208 · Issue #18357 · MarlinFirmware/Marlin
I installed the BTT SKR 1.4 Turbo and have been able to print for a while. Recently the extruder would stop mid print. X, Y and Z would keep going and heating was kept on. After stopping print extr...
My favorite reply from someone I presume to be a primary dev on the project:
No progress. The only "solutions" they give is to disable StealthChop on the extruder, disable Linear Advance, or run the extruder in standalone mode. Which I guess the last option would be mostly fine. I mean, you're only losing the ability to program it via UART. It takes you back to setting jumpers and configuring stepper current via a trimpot. I guess that is doable but this is a pretty damned old bug.
But I also sort of understand it. I have other printers running Trinamic drivers with StealthChop and Linear Advance enabled and they so far have no exhibited any symptoms.
But this also reminded me of other things I have run into. Like for example, when you run sensorless homing you don't want to double bump on homing. So the first time I setup sensorless homing I disabled home bump. If you double bump on sensorless homing it makes your home position very erratic. It can vary by several millimeters. Which if you are trying to use your entire build volume can be an issue. You can end up with part of your print entirely off of the build plate. Even though I had disabled home bump, it was still doing it.
I dig through documentation. There is no alternate method home bump can be enabled or disabled.
Marlin/Marlin/Configuration_adv.h at cb4e3889ece8fd07030f4c2eeaa781679cd8414e · MarlinFirmware/Marlin
Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your...
That section is the only place it is referenced and the only place you can configure it.
// @section homing /** * Homing Procedure * Homing (G28) does an indefinite move towards the endstops to establish * the position of the toolhead relative to the workspace. */ //#define SENSORLESS_BACKOFF_MM { 2, 2 } // (mm) Backoff from endstops before sensorless homing #define HOMING_BUMP_MM { 5, 5, 2 } // (mm) Backoff from endstops after first bump #define HOMING_BUMP_DIVISOR { 2, 2, 4 } // Re-Bump Speed Divisor (Divides the Homing Feedrate) //#define HOMING_BACKOFF_POST_MM { 2, 2, 2 } // (mm) Backoff from endstops after homing //#define QUICK_HOME // If G28 contains XY do a diagonal move first //#define HOME_Y_BEFORE_X // If G28 contains XY home Y before X //#define HOME_Z_FIRST // Home Z first. Requires a Z-MIN endstop (not a probe). //#define CODEPENDENT_XY_HOMING // If X/Y can't home without homing Y/X firstSet HOMING_BUMP_MM to 0 on the relevant axis and it should not do a home bump on that axis. Easy enough, right?
Nope. If you enable QUICK_HOME then for some fuck reason it configures a home bump. This bug traces back to at least 2018.
I ran into another bug where when using Unified Bed Leveling when it would go to do the 3 point level to tilt the mesh it would fail instantly after the first point was probed. When the firmware is compiled it should calculate the probing positions based on probe offset, bed size, probing margins, etc. But my particular configuration would cause it to calculate a point for the second probing location that it could not reach so it would fail. IIRC, since my probe offset was larger than what I had set for probing margins it would just shit itself. The fix was to manually define the probing locations for the 3 point leveling.
And all of this brings me to my most important and grievous complaint about all of this.
MARLIN DOES SANITY CHECKS WHEN COMPILING BUT THEY DON'T FUCKING USE THEM ENOUGH!!!
Here is a PR that would implement a sanity check to see if sensorless homing and quick home are both enabled.
QUICK_HOME and SENSORLESS_HOMING are not compatible by thisiskeithb · Pull Request #17084 · MarlinFirmware/Marlin
Requirements SENSORLESS_HOMING Description After seeing many issues with QUICK_HOME and SENSORLESS_HOMING enabled in the Facebook groups and again tonight on stream with @codiac2600 & @Ve...
It has just been hanging out there for over a year.
Here is a sanity check to make sure that quick home and CODEPENDENT_XY_HOMING are not both enabled:
Marlin/Marlin/src/inc/SanityCheck.h at cb4e3889ece8fd07030f4c2eeaa781679cd8414e · MarlinFirmware/Marlin
Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your...
There a PR just sitting there for a year to implement the same thing for quick home and sensorless homing and nothing. They could also implement one for my issue with probing margins and probe offset. But they haven't. When I was looking into that issue I also found a PR for a sanity check on that issue. Just hanging out in limbo and not merged.
Don't get me wrong. I understand it is open source and they have limited manpower of free help to do these things in their free time. I get priorities. But when new users have to start tracking down these obscure bugs that they are aware of and could at least implement it into your sanity checks and throw an error at compile time. alerting users to the issue. You could also do something simple like adding a comment to the config line.
//#define SENSORLESS_BACKOFF_MM { 2, 2 } // (mm) Backoff from endstops before sensorless homing #define HOMING_BUMP_MM { 5, 5, 2 } // (mm) Backoff from endstops after first bump #define HOMING_BUMP_DIVISOR { 2, 2, 4 } // Re-Bump Speed Divisor (Divides the Homing Feedrate) //#define HOMING_BACKOFF_POST_MM { 2, 2, 2 } // (mm) Backoff from endstops after homing //#define QUICK_HOME // If G28 contains XY do a diagonal move first, quick home is incompatible with sensorless homing //#define HOME_Y_BEFORE_X // If G28 contains XY home Y before X //#define HOME_Z_FIRST // Home Z first. Requires a Z-MIN endstop (not a probe). //#define CODEPENDENT_XY_HOMING // If X/Y can't home without homing Y/X firstIf you want people to use your shit, make your shit easy to use. It is already bad enough that for anyone to use it outside of the most mainstream purposes and default configurations that you are expected to install VS Code and PlatformIO and compile it yourself. I have to wonder how many new people have been discouraged by these weird bugs that hang around for years and never even get a sanity check implemented for them, even though they are well known enough that you can track forums threads and GitHub issues going back years telling people to disable things because of incompatibility?
I glossed over a lot of stuff here that could probably stand to be explained. If anyone has any questions about what all those terms and features mean or why you would want to use certain features just ask and I will do my best to elucidate.
-
@Polygeekery tl;dr
-
I just switched to Klipper and never looked back. It's written in Python that runs on a powerful enough machine (e.g. a Pi), and configuration is just an INI file.
-
@lights0123 said in The absolute state of 3D printer firmware:
INI file
(dies) seems that might (dies) be a bit limiting in syntax (eyetwitch) but I guess it's (eyetwitch) a familiar format in some parts of the (eyetwitch) consumer space.
-
@lights0123 said in The absolute state of 3D printer firmware:
I just switched to Klipper and never looked back.
No UBL.
I guess I should just get over that and wait for that feature to filter down to others. Hell, I'd be happy with a mesh surviving reboot even if it were only 3x3 or maybe a bit better. Or maybe I should quit being a cheap bastard and get aluminum tool plate to make my print beds from? If I start with something flat, and it stayed that way after heating, then large meshes would not be such an issue.
The other killer feature that Klipper has is being able to control multiple mainboards in a cohesive manner on a single machine. But other than that and configuring via an INI file (which honestly would be amazing) I don't see a big need to change right now.
But to be honest I am pretty sure that decision is a flawed sunk cost analysis on my part. I think a fair number of people switch to Klipper with the promises of sooper-dooper print speeds. But they don't realize that you can only melt, place and freeze filament in place at a certain rate. I've watched the YouTube videos of Voron and Hevort machines running at 500mm/s and it is impressive but those videos are short for a reason. The prints are nothing even close to resembling something worthwhile. The prints are becoming a Salvador Dali painting as they progress. Melted and abstract.
https://www.youtube.com/watch?v=SpZlMYXZW-o
Don't get me wrong, the kinematics to process that speed is impressive, but it is also useless because you cannot do an FDM process at those speeds. Skip to the last 30 seconds and see how the print is developing.
All that being said, Klipper and RepRap are next on my list to evaluate. RepRap is the reason I was trying to order some SKR 2 boards the other night.
But the I suppose the real reason I have not tried Klipper yet is that they only implemented filament runout detection this year. That is disappointing. On the other hand the Marlin devs are looking to copypasta the Klipper implementation of Linear/Pressure Advance from Klipper in an attempt to fix one of the bugs I mentioned. So there's that.
-
@boomzilla said in The absolute state of 3D printer firmware:
@Polygeekery tl;dr
Beards are gay. That's the gist of it.
-
@Polygeekery said in The absolute state of 3D printer firmware:
@boomzilla said in The absolute state of 3D printer firmware:
@Polygeekery tl;dr
Beards are gay. That's the gist of it.
Wait a minute then why was Rock Hudson married?
-
@Polygeekery said in The absolute state of 3D printer firmware:
@boomzilla said in The absolute state of 3D printer firmware:
@Polygeekery tl;dr
Beards are gay. That's the gist of it.
-
@Polygeekery said in The absolute state of 3D printer firmware:
@boomzilla said in The absolute state of 3D printer firmware:
@Polygeekery tl;dr
Beards are gay. That's the gist of it.
It's not the beards who are.
-
@topspin said in The absolute state of 3D printer firmware:
@Polygeekery said in The absolute state of 3D printer firmware:
@boomzilla said in The absolute state of 3D printer firmware:
@Polygeekery tl;dr
Beards are gay. That's the gist of it.
It's not the beards who are.Yeah hence my question about Rock Hudson.
-
Epic rant. Would scroll over without reading again.
-
Blah blah blah blah. I've discovered why I'm not seeing this bug on other boards. The bug only occurs on the last stepper driver in the board and under high accelerations. On other boards I have either unused drivers (that silently absorb the bug because they're not used), or a second Z driver (no high accelerations) or a second extruder motor (which I rarely print on the second extruder so less chance to see the bug).
Last stepper driver in the board indicates an issue with UART. That gives me something to look at but considering my experience working low-level with microcontrollers I don't think it is going to help that much.
-
My wife has these silly cat feeders and waterers that she likes with gravity feed water containers. Kind of similar to this one:
It's not that exact one, but close enough for this conversation.
The caps on the bottles keep breaking at the threads, making the water bottle part useless.
Well, that is an easy enough problem to solve. I sit down with my calipers and the various parts and start designing a replacement cap. I figure if I print it in PETG with 100% infill, it should be strong enough and there is a lot of play in the threads that could be taken up and make the part stronger.
So I need a cylinder to start with:
Then a cut through the middle to make room for the bottle and threads:
Now I need some threads, which I measure out what appears to be a 27X4 (27mm major diameter with a 4mm thread pitch) metric thread. Fusion 360 does not offer those threads in the stock assortment. They have a 27x3, 27x2, 27x1.5...... But no 27x4.
That shouldn't be a problem. I just need to learn how to do arbitrary threads in Fusion 360. Let's do a bit of Googling......hey, there is a KB source from the Autodesk people on how to do arbitrary threads. That should be what I need:
I will save you the reading to see how to make arbitrary threads (which would seem to be a fairly common need in design and prototyping) but their official way to make arbitrary threads is to dig into
%localappdata%\Autodesk\webdeploy\Production\<version ID>\Fusion\Server\Fusion\Configuration\ThreadDataand edit XML files to make arbitrary/custom threads.
The official way to make custom threads in Fusion 360 is to turn on hidden files and folders, go 9 folders deep into Local appdata, one folder of which is a GUID so you need to sort by date to even see which is the folder that you want, and edit an XML file.
If you read the article you will notice that someone has created a plugin that purports to do what I needed to do, but that plugin only creates screws. It does not do internal threads.
Oh, and obviously after you edit this file you have to restart Fusion 360, reopen your file, apply your custom threads, see if that is what you want and if it is not then you have to edit the XML file again and restart Fusion 360......
Why this is not a simple list of options in the GUI boggles the mind.
Oh, and this doesn't really matter since this is a one-off and once I have the STL I should be good to go, but since this folder location is tied to the GUID of this release I would be willing to wager that when Fusion 360 updates my custom thread will be missing. And, if I open this file on another computer it definitely won't be available as it alludes to this in the article:
Notes:
- If this design file is used in Fusion 360 when there is no access to the customized XML file, the following error message may appear:
"...the current thread family has no suitable type..."
-
When modifying a standard thread type, he design file will be modified back to the standard settings if the feature is recomputed on a machine without access to the customized thread XML file.
-
When using this procedure to create a custom thread in Fusion 360, the XML specific formatting is very important. XML typos or syntax errors can cause problems in which standard threads are removed from Fusion, as well as preventing the custom thread from being used in the program. Using an XML Parser such as this one can help ensure the syntax is correct.
-
@Polygeekery I can understand they rushed it to production and didn't get around to a dialog for setting thread parameters. But the STL referencing the thread definition rather than storing the parameters, or even as some lower level primitives, is just … mean.
-
@Bulb STL is, as far as I know, just a pile of points in 3D space, so that one should be fine. I'm assuming @Polygeekery means if he ever wants to tweak the thing or apply the same thread to a new design in Fusion 360
-
@Polygeekery Yeah. I'll rather go with this one:
-
@Rhywden without watching that video I think I know the method. You're basically sweeping a profile around a loft to define your threads and then doing an offset to "cut" them into your mating part?
That works well enough when you're printing both parts and the 90 degree threads they usually have you design are easier to print. But when you have to match up to another 60 degree thread I haven't found it to work nearly as well.
-
@Polygeekery Ah, 60°. yes. that might be a problem.
-
@hungrier said in The absolute state of 3D printer firmware:
@Bulb STL is, as far as I know, just a pile of points in 3D space, so that one should be fine. I'm assuming @Polygeekery means if he ever wants to tweak the thing or apply the same thread to a new design in Fusion 360
Mostly I was pointing out how since the folder where you define the custom threads is tied to a GUID of the latest release I bet that the next time Fusion 360 updates my custom threads are gone.
This whole process is just perfectly designed to confuse and confound anyone that is not the type of person to visit forums like these. Imagine you're not a technologically savvy sort of person and trying to navigate this minefield. They never should have even posted that KB article.
-
@Polygeekery it's the same problem as with programming tools. Only nerds use 3D printers, and nerds are great at finding their way around bad UIs and inventing workarounds. Because of it, good UI isn't nearly as important as with apps for common people, therefore it gets heavily neglected.
-
@Gąska said in The absolute state of 3D printer firmware:
Because of it, good UI isn't nearly as important as with apps for common people, therefore it gets heavily neglected.
I'd say good UI is heavily neglected because it is a niche field that only has few competitors and neither of them wants to throw more money on the product, because the customer base is not that large.
-
@Gąska said in The absolute state of 3D printer firmware:
Only nerds use 3D printers
Not really, and that isn't as applicable in this case anyway. Fusion 360 is marketed as being a 3D CAD (and everything else) software for a broad range of people. Designers, machinists, inventors, sculptors, the list goes on.
See, I have no problem with them only having a library of standard ANSI and SAE and such thread types. I also don't have an issue with them not offering arbitrary thread designs. You can usually get by with a loft and sweep to make them.
Publishing that KB is the retardery. We technical types probably realize that they are storing this config info somewhere. Assuming it is stored in some general file type (which it was) then we can find it and do what it says.
Or some savvy user could figure this shit out and post it on some forum where it can be indexed and found.
But publishing a KB for dissemination to all of the users showing a method where it is so easy to shoot yourself in the genitals and will almost definitely break things in new and unusual ways, and likely has zero chance of surviving to next month when the software updates again, breaking their designs with no way to get them back to the way they were......that is a bad idea.
Either put it in the GUI or don't (as a company) document it for the layperson. Let the enthusiasts and the nerds do that if you wish so at least when shit breaks (which it will) they don't have you to blame for it.
-
@Polygeekery FFS, even Blender, which isn't a CAD program at all, has a plugin that lets you design internal and external threads of arbitrary diameter and pitch. (It only has presets for metric (m3 to m12, I think), but if you look up the numbers for SAE, you can type them in.) I think (but
to launch it again to check) it only does standard 60° thread profile, but that's what you want 99% of the time, anyway.I haven't had good luck printing threads that mate correctly, but that's a printing problem, not a design problem (other than maybe needing to compensate for printing tolerances in the design, but that's going to be true of whatever CAD or not-CAD software I use).
-
FWIW, OpenSCAD doesn't come with any built-in threading functionality, but there are libraries available with standard and custom threads. BOSL is a big general-purpose one that, among other things, lets you design internal and external threads with a customizeable printer slop factor, and I've had success printing working threaded parts designed with it
-
I have no idea if this relates whatsoever to the current topic but since it arose in my undead I'm popping in to mention that my printer has recently acquired the "can't figure out how ho
wt Shit is" syndrome. The build plate usually reads a reasonable value but occasionally goes to 600 plus, and the extruder is starting to get in on the act too, sometimes stalling at the initial heating phase because it can't tell if it's actually hot or not.Perhaps leaving it sitting on the desk was a bad idea...
-
@Tsaukpaetra said in The absolute state of 3D printer firmware:
the "can't figure out how how Shit is" syndrome
It's not the only one...
-
@Tsaukpaetra said in The absolute state of 3D printer firmware:
I have no idea if this relates whatsoever to the current topic but since it arose in my undead I'm popping in to mention that my printer has recently acquired the "can't figure out how ho
wt Shit is" syndrome. The build plate usually reads a reasonable value but occasionally goes to 600 plus, and the extruder is starting to get in on the act too, sometimes stalling at the initial heating phase because it can't tell if it's actually hot or not.Perhaps leaving it sitting on the desk was a bad idea...
Loose connection or broken wires in your thermistors. It's possible it is a board issue but 99% chance that you have a bad thermistor.
I'd start by opening up the compartment where the main board is and checking to make sure all of the terminal block connections are snug. If they are, order two new thermistors and get them replaced and you should be back in business.
-
Status I: One of my friends
hashad a spare 3D printer. The only thing wrong with it was it was missing a controller -- they had since built a bigger rig with more build volume, and decided to reuse the controller but left everything else, even the hot end and extruder. I have a spare Kodama Bardo board so I wanted to throw it in there and use it. It uses Marlin, and the intended printer has a really tiny build volume so I'm going to have to recompile the firmware with much larger limits. But Marlin is open source so their modifications to it must also be, right?... Right?
Status II:
Cube 2: Jammed. Filament snapped at the extruder's pinch roller. Worried about damaging the hot end if I try to free it since it feels like it's also stuck inside the nozzle.
Cube 3: Jammed. Most of the cartridges aren't yet stripped at the bowden, but for whatever reason prints go stringy and then disappear, and the cartridge is useless after that until creative application of soldering iron. Doesn't matter whether I'm using Cubify or Simplify 3D, doesn't matter whether I'm using PLA, ABS, or PLA in ABS mode. Probably needs service, but 3D Systems gave me the
.
Trinus: Jammed. Left it printing unsupervised and after a print finished for whatever reason it kept the hot end hot for several hours. Plastic is confirmed stuck inside the nozzle. Probably going to have to overtemp it and force stuff through, or completely replace the cold end. because of the other two printers.
-
@TwelveBaud just replace the nozzle. They're essentially a consumable item.
Urban Dictionary: Beard
Creating custom threads and thread standards in Fusion
