papalonian

This is a work in progress pic of what will eventually be an army of icy blue-gray skinned orcs. I plan on making a range of colors between pure light gray and pure baby blue, and grabbing colors from different parts for each orc so they'll all have different but similar skin tones.

The models are from Valandar's awesome Orc Horde collection on Thingiverse. These models are a ton of fun and a great balance between high-detail and printability/ paintability. I wish the bases were a little more interesting, or printed separately so I could attach my own, but a flat base allows me to add my own terrain later on.

I plan on doing a typical green-skinned orc army, as well as a fire-red army. Orcs are a fun way to play around with different armor color schemes because if something ends up looking like crap you can just say, "they're orcs! They just grabbed what's available!"

This is my friend's character for a campaign that we are in. He used AI to create the general look of his character, then designed a mini based on the outcome. I printed it out for him and used the AI image as a color reference.

Here are a few other angles:

And here is the AI generated image that the mini is based off of:

(The small girl is the character's sister.)

This is my paint job on Yasashii's "Mind Flayer / Illithid Tabletop Miniature" from Thingiverse.

This was one of the first prints off of my resin printer, and the first piece I attempted air brushing; to make both of these a little easier, I scaled him up a bit, so he isn't quite "tabletop minature" scale, but still much smaller than what I'd been used to painting (~70mm tall).

Everything except for the red eyes and purple highlights on the armor was done with a 0.3mm airbrush.

Here are a couple different angles:

Unfortunately one of the robe dangly bits snapped off the back before I could start painting. I didn't expect the paint job to turn out this decent so I didn't bother reprinting, kinda wish I had.

This is a miniature from TitanCraft's "RPG Mini Starter Kit" on thingiverse. I painted him up just to get some practice painting minis as I'm just starting out on the small scale stuff.

Here he is from a couple of different angles:

I wish that the paint on his face came out a little better, it's something I've always struggled with.

I may be preaching to the choir here, but if you haven't already heard of it, check out TitanCraft. It's another mini maker website, but you can actually download minis that you make for free (they have paid and free assets, but there's a ton of free ones and you don't have to pay anything to download an all-free model). I'm not affiliated with them in any way, but I've been showing it to all my DnD friends and a few of them are sending me minis to print out for them, and it costs us nothing but the $0.25 of resin.

I've been resin printing for maybe a month. I've noticed that on all of the resins that I've got, and all of the profiles I've downloaded for them, the lift speed is usually at least 3 to 4 mm. However, when listening to my printer operate, I can tell that it is fully separating the print within the first millimeter or so. I've changed almost all of my resin profiles to only lift 1 mm, cutting each layer time down like 2 seconds, and absolutely zero change in any quality whatsoever. Am I just lucky with my printer configuration, or my fep is especially tight? Or why else would such a large distance be commonly recommended?

I'm dumb and sometimes tell my phone to do things I don't actually want it to do, like hide posts I actually want to check out. I can't find a way to look at those to bring them back.

I've been helping someone diagnose a technical issue through Lemmy PM's the last month or so, and have accumulated a lot of messages back and forth. (Around 130 I'd say.)

When I get a new message, the total number of messages that I've received shows as a notification for a while, until it eventually disappears. (I haven't fully tested it but I think it disappears on reboot once I've replied.) Receiving comment replies or a new pm brings the notification back.

The screenshot shows what I see when filtering for unread messages. Thus, there are no unread messages, let alone 130 of them.

The entire conversation has been had in the same message thread. Not sure if this is a Lemmy issue or boost issue.

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?

Please I spent all my money on fentanyl

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.