Hi all, got a bit of a technical problem I'm trying to solve and I've got very little programming experience.
Basically, I'm trying to create a folder with a bunch of filament profile cfg files, with things like retraction distance, temperature, flow rate etc preloaded into them. That way, I can slice a model for a 0.6mm nozzle, send it to Klipper, and run it with any filament I want without having to re-slice, just change which cfg file is loaded.
This is going pretty well and I've figured out how to get most of what I want into the cfg. However, I want to limit my print speed by my maximum volumetric flow rate, a variable that Klipper does not support (and Kevin has more or less denied requests to have it added). To solve this issue, I want to limit the max speed instead, using a formula like this:
print speed = (max vol. flow) / (nozzle width) / (layer height)
(max vol. flow) and (nozzle width) would be defined manually by me for each profile. The only issue is (layer height), which of course can change from print to print. I know that my slicer puts the layer height and total number of layers in the header of the gcode, I also understand that that's where Klipper gets this info from and how it displays those numbers once you've selected a file. What I'm having trouble figuring out is how I can send that number into the above formula; I found this which seems to be almost what I need, but I can't figure out how to use the "print_stats object" in my cfg.
A potential workaround is to find my maximum layer height for each nozzle/filament combo and set the max speed assuming that later height, but if I'm printing something at say half my maximum layer height that's going to severely unnecessarily reduce my print speed.
Any advice?
When viewing a single child comment thread (ie viewing a response to your comment that is already a few comments deep in a thread), you are given two options at the top of the comment section, one to "view full context" of the thread you're in (expected behavior: give context up to the parent comment and show only comments in that thread) and one to "view full comment section".
As of now, at least for me, both options simply give me one additional parent comment above what I can already see (in my previous example, it would show the comment I originally replied to). To get to the full comment section, I have to press the option and reload the comment section over and over until I get to the parent comment, at which point "view full comment section" actually does what it says.
Hi everyone, a week ago my printer (heavily modified Neptune 3) started randomly shutting down in the middle of prints. I come back to a print with the "Klipper reports: SHUTDOWN / Lost communication with MCU 'mcu'" error message.
The printer has been "under construction" for the last couple of weeks, but it has been in varying states of "working" for most of the time - working well enough for me to print the parts I needed to get it back to "fully operational". During this time, the printer never shut down like it is now.
Only once I started making little cosmetic changes did the problem present itself. I was running a known-good print, and I got the above error twice (first time after ~2 hours, second time after ~1 hour) before I got a successful print off of it. This was last week.
After this successful print, I continued other prints with no issues. After a day or two with no problems, an hour long print threw the error at me four consecutive times between 10-45 minutes into the print. This is when I started looking into my klippy log and found some relevant articles citing things like EMF interference, bad power supplies, faulty cables etc. I realized that one of the changes I had made rerouted the printer USB cable right around the Z-stepper, so I rerouted it to how it was originally and immediately managed a successful print. This was 5 days ago.
After moving that cable I had no issues with printing several-hour long prints... until last night. I had been printing all day, then the problem came back. After one print finished, I queued up another print with a plate full of parts, it failed after 1.5 hours. Tried the same print again, failed in 30 minutes. I re-sliced to only a handful of parts to see if I could get those to print before the error occurs, and it's failing 15 minutes into the print.
The printer power supply is the unit that came with the Neptune, and it isn't powering anything besides stock hardware (exception being the SKR mini board), so I don't think it's that. The pi is on a quality unit. The USB cable has been working for a long time so I also don't suspect that, but I'm probably going to buy a new one today just to be sure. I adjusted my enclosure setup so that the Pi and SKR are able to get cool air (at one point had a personal fan pointing at the open electronics box, still failed).
Here is a link to my most recent klippy log (abridged to the start of the last failed print). I'm not very familiar with reading through this and finding oddities, but I do think it's strange that it seemed to load my preheat script in the middle of printing right before the EOF error. (It should be noted that this preheat script was made 1 or 2 failed prints before this most recent one, so it isn't the source of the error as prints were failing before the script was made). If there's anything I'm missing or something else I can try, please let me know!
Edit: While typing this post, I was running the same failed print without filament and both heaters turned off. It ran for about 45 minutes (most recent failure occurred at 12 minutes) so I cancelled the print and started it again with heaters turned on, still without filament. It again ran for about 45 minutes, so I again cancelled it and started the print again, this time with filament loaded. It failed in 5 minutes.
Edit 2: A test print with heaters on and no filament failed after 1h8m. So it isn't an issue with extruding filament.
Edit 3: New cable with the 5v leads taped off per @SzethFriendOfNimi@lemmy.world's advice. Ran the print without filament until completion. Reloaded the same file with filament, print ran without issue until the 1h14m mark, at which point I tapped my Klipperscreen device to wake up the screen, and as soon as it displayed the status, the printer errored out. This can't be a coincidence, can it? Whenever the print goes unmonitored for a long time, it fails as soon as I do something (load mainsail, turn on the klipperscreen) to check the status of it.
Hi guys, been thinking about this for a couple weeks now but can't seem to find anything online about anyone who has tried it.
I'm considering converting my printer into a voron. However, since I currently have a fully functioning printer, I wondered why I can't print the extrusions rather than purchasing them? Of course they are larger than my printer's volume, but there was this video posted here a while back about a great way to create strong permanent joints for parts just like this:
The way I would do this would be to model the extrusions as a solid piece and make cutouts in the areas that bolts are meant to be ran through.
Is this even within the realm of possibility, or is there a specific barrier that has prevented others from trying this? The obvious concern is stability/ rigidity, but if everything is printed at voron part standards or thicker with an infill pattern like gyroid, would the decrease in rigidity be too much for input shaping to compensate for?
Thanks for any ideas or input! If there aren't any major road blocks or examples of this failing I think I'll try it out once I've got the space for it.
Hi guys. Please check my previous post for any background questions, I don't have it in me to go over everything again.
Long story short, I was having issues with clogging that were being caused by my hotend not reaching the reported temp. After a few days of troubleshooting and diagnosing the motherboard and Klipper settings, I gave up and decided the motherboard was faulty (even though I could not perform any tests to determine in) and bought an SKR mini. I got that all set up, and the printer has been working flawlessly since then.
Until now.
Same exact problem; one print goes perfectly fine, next print, failing to extrude by the 4th layer. I removed the clog, restarted the print, now can't even extrude the priming line. Fearing the worst, I disassemble the hotend, try hand feeding filament, and once again I am unable to push more than a few centimeters through before it gets clogged up. A probe thermometer reads ~160C while Klipper reports 200C.
What could possibly be happening here? The board is an aftermarket replacement from a completely different company, so I doubt it's a recurring manufacturer defect, but I have no idea what else can be causing this.
At this point I've spent so much time and money trying to fix this printer that I could almost buy a new one, but at this point I'm not convinced even that would solve the problem.
I couldn't find a great way to describe what I'm seeing. But if you're deep in a comment thread, or viewing a reply to your comment, and have parent comments collapsed, if there are additional comments, choosing to show them adds the number of context indicators (the little lines on the left) that it would have were the parents not hidden.
The comment from FlyingSquid was the comment hidden by "show 1 more reply".
OK guys, I finally found what the issue is, or at least kind of where it's coming from.
As some of you (and myself) suspected, my hot end is not reaching the reported temperature. I previously blamed the low readings on my IR thermometer on not being able to point the laser directly at the hotend, but it seems it was reporting accurate readings (around 95C when klipper reports 200C).
Now, here's where things get a little weird. At this point, I've used multiple thermistors, but swapped in a new one anyways. My board also has a pin for a second extruder thermistor, so I plugged it in to that one and changed the pin in my printer.cfg. No change.
I tried switching the bed and hot end thermistors on the board and in printer.cfg, no change.
I changed the thermistor "sensor type" from "EPCOS 100K B57560G104F" (same as the bed) to "Generic 3950", no change.
I found an article about tuning your pullup_resistance value. My cfg file did not have this value specified, so I added a line and started with the default of 4700, which made no difference (I'm assuming this value is loaded from the sensor type by default?). I toyed with the values until my thermometer read ~220C when setting the printer to that temp. However, to achieve this I had to adjust the pullup_resistance from 4700 to 13k+ (far beyond what should be needed) which makes klipper report 6C at room temp (print bed reports 27C). Unsurprisingly, I can hand-feed all the filament I want, but the temp reading is only now only accurate at 220C rather than only being accurate at room temp.
The thermistor, I feel, can be removed from the suspect list, as multiple thermistors exhibit identical properties.
I also feel the motherboard can be removed as well; there are three pins for thermistors, all three show accurate readings for the bed but identically inaccurate readings for the nozzle.
This only leaves software/ firmware, which I find incredibly odd for three reasons. For one, the printer was not even shut off in between "working" and "not working"; I successfully completed a print, and without shutting down, updating any configs, changing any settings etc., I swapped out the nozzle, and the printer hasn't worked since. Second, both the bed and nozzle thermistor are configured exactly the same, so if the nozzle is not set up properly the bed should be wrong too. Finally, Klipper is really straightforward and it's easy to configure things that commonly need configuring, it doesn't seem right that a configuration got changed and I'm completely incapable of finding what happened and fixing it.
As a Temporary Fix^TM^, I'm inclined to get a nice reliable probe thermometer, calibrate a pullup resistance value for common print temps, then updating my cfg whenever I want to change temps more than ~5c. This is obviously not even close to an ideal solution, but I don't know what else to try. Everyone else I've seen with this issue has resolved it either through hardware replacement or fixing settings, and I've tried all I can with both.
@papalonian
@lemmy.world