Topics created by bot

@bot I'd imagine it is easier (and more flexible) to reslice with a different parameter (serial number or similar), than it is to dynamically replace portions of existing gcode and handling it on the µC. Especially if the printer is running via an SBC that has more than enough compute power for slicing.

PrusaSlicer 2.4.0 is out now! Out of Beta! So that means the -n8 version is out too!

b719b95c-1848-459b-9f0f-c608ef789d47-image.png

https://github.com/n8bot/PrusaSlicer/releases

@deckingman Oh right yes yes thank you. Similar concept, but different need.

@whopping-pochard Interesting article! Maybe Prusa will jump on this idea.

I'm not sure if the firmware would be able to look far enough ahead while also calculating the time needed for all the moves. If it's possible on firmware that would certainly be delightful.

I'm in the middle of a print, so I don't want to experiment with changing anything, but I noticed I had some settings as follows in DWC:

General:
Save cache in local storage = true
Update delay for cache changes = 4000 ms

I'm not sure of those would affect anything, or if they are the default values, but it's just something I thought to check because I remember seeing them. I wonder if my web interface session is too much because I'm stressing the duet quite a lot with 400 steps/mm on my x/y axes at 16x and ~4600+ steps/mm on my e axis at 16x microstepping. Maybe updating the position of the tiny gcode segments I'm printing is overwhelming something.

I had planed sugesting this for SuperSlicer after PS 2.3 have been released an merged with SS, now it looks like that might solve itself 😅

Hi
it's merged into my latest release of superslicer.
Be careful with "after PS 2.3", because prusa seems to be on a 6-month release cycle, and they may plan it for christmas.

I don't have a duet printer, so i won't notice problem / possible improvement for them, it's entirely up to duet users to report these. Don't count on me randomly noticing things like this one.

Yeah I'm planning on doing that when I get finished with a ton of other things on my to-do list. I'm trying to encourage discussion to see if the idea can be refined further. It's dealing with such theoretical elements, that the real-world tests aren't that important. What's important are the dynamics of the way the firmware will work with this, and how the slicers might implement this feature and how other methods or approaches might be better.

@dc42 thank you for the clarification/confirmation.

I'm starting to get frustrated! I have the infill extrusion rate very consistent, except for some weird spots where the rate suddenly drops for one segment.

The odd thing is, it's dropping to the excact extrusion rate that was required from a previous slice in a previous build. The current settings all request a 0.2 mm extrusion width -- suddenly, it's dropping down to 0.16 mm -- the exact value I was testing before.

Something really wonky is going on. It's possible that the 0.16 mm value was present at startup, and is retained in memory somewhere and mistakenly referenced.

I am an idiot lol

It causes the extrusion rate to suddenly drop by ~300 microsteps per second. Yikes!

[Edit: well, I'm an idiot. The wonky thing that was going on was that my spreadsheet was messed up. Some of the formulas -- where the odd values appear, were erased and somehow a fixed value was in its place.

I fixed it and now the extrusion rate is perfectly consistent. lol. Ooops. move along, nothing to see here!]

[Edit again to clarify: my original assertion, that increasing X/Y gcode decimal precision "completely alleviated" the extrusion rate inconsistency, was basically correct. The problem in my spreadsheet came about at approximately the same time that I implemented the increased precision change.

The end result is that my last build does indeed solve the extrusion rate inconsistency, sort of. Infill (and perhaps other non-perimeter path types) have slightly worse consistency than perimeter paths, but it's still accurate enough so that tiny 0.16 mm * 0.04 mm extrusion paths have extrusion amounts that produce extrusion rates consistent to within ~0.01 microsteps per second at 100 mm/s. Without adjusting the precision, the infill can vary by up to ~20 microsteps per second with the same settings. This is because the rounded vector, having a much different length than the precise length, due to having an absolutely tiny length to begin with, is not used to calculate the extrusion rate -- the precise vector is. I'm referring to vector here to mean the literal vector described by two subsequent G1 lines of code. The underlying math is a vector norm on the set of points before they are rounded for Gcode output.

BUT, there is a feature in solid infill to "adjust spacing to fill the space evenly," which in turn adjusts the flow for some segments of solid infill to be slightly different than other areas. I.e., it's not a fluctuation anymore, the infill (solid only?) is sometimes calculated at a slightly different flow rate. I'm experimenting with new builds that disable this feature, but now extra-large gaps are left -- where there is enough space to fit a whole extra line of infill, so I'm not keen on forcing that change in the experimental builds.]

I'm printing from SD card. This GCode does have lots of small segments, but only on the perimeters and they are printed at 6-12 mm/s.

The problem areas seem to be the infill or support, which are merely rectilinear with small zig zags.

But actually, now that I think about it, the dense support structures from PrusaSlicer draw loops that conform to the curve of the model. This could be it, since I was printing the supports lightning fast with PA enabled.

@oliof thanks, I've added that page.

I looked into linear steppers for 3D printing about 10 years ago.

I was quoted about $1000 per axis, with a 300mm stroke IIRC. That was at volume too.
Most of the companies making them are aiming for 1 micron repeatability, for machines were $1000 is a small cost.

I know of at least 1 person who was working on a low cost linear servo, but he was trying to raise money for it as part of a robotics startup.
You can build something very similar to those NPM linear servos for very little money, the electronics are not super complicated... the hardest part is the control.
With a bit of imagination, you could probably even build a linear stepper in the same style. Thrust output might not be great, but if you can make it a stepper at least control is simple.

@jpomo10 You're welcome! Don't hesitate to report any bugs or recommend any changes. Also, if you have any questions about how to use the profile or configure it for your own printer, I'll be glad to help answer.

@zapta Yes, sadly the license is really only for hobbyist use. I suspect this is due to their academic research funding model. Nonetheless, I find the software useful in exploring slicer features.

@Phaedrux in some tests I did that was determined to be the limit of my extruder system. It's geared ~50:1

But, I've recently changed how the idler works so I may be able to increase it somewhat, but definitely no higher than 120 I bet.

I have my eye on some better stepper motors to transfer the planetary GB to, in order to get more speed out of it, but for now I'm just working with what I've got.

Your diagnosis is correct. The simulated print time may be slightly longer than the actual print time.

@Phaedrux Thanks for sharing your values! They are similar to mine, except my gantry is obviously much heavier because I don't think I could quite get away with your values and still not see ringing.

The way I kind of rooted the problem out is by inserting a tiny but slow move in both x and y at the end of every travel move, which helped the problem but added a lot of unnecessary movement.

It's crazy to think about... but some of these long prints have the print axes travelling in the order of multiple kilometers over the course of a day or two. I digress.

Moved to DWC wishlist.