Fun discovery of the day: PrusaSlicer (at least for the Mini) actually _enforces_ the machine limits by emitting appropriate G-code when slicing. Among other things, this means that if you want, say, higher accelerations, you can just request them.
This is probably because the Mini can't save anything to EEPROM, which means any change to presets requires a firmware upgrade.
Unfortunately, I stopped caring about the acceleration limits and everything in #PrusaSlicer since I started to run #Klipper because it actually tells you that the limits are only for time predictions and aren't Ctually emitted to #Gcode.
But when you use #OrcaSlicer and you insert custom accelerations and dynamic-overhang-speeds and limits, the printer actually honors it.
So, not only are my time predictions with OrcaSlicer more accurate, but I am actually printing at the rate that I want to and chose in the slicer.
But then finally, I have to say. OrcaSlicer does not honor flow-rate limits as well as PrusaSlicer does. If I tell PrusaSlicer to never exceed 12mm^3/s, it would slow itself down.
OrcaSlicer justs YOLOs itself past that limit, and my exteuders start to skip!
The other thing is. With #PrusaSlicer in the printer's custom #Gcode where you set the start, end,layer-change, etc. Gcode. You can access variables such as temperature and layers, etc.
You, however, can't access variables like acceleration limits and use those values to emit them to your Macros when you run #Klipper.
So I need to look at a print, think a bit. Set limits in Klipper, transfer said limits to #PrusaSlicer, generate gcode, and then print.
#OrcaSlicer actually will honor your request to print slower or faster, but there is something wrong with its flow rate.
If you slice an object and switch to the flow-rate view. The color codes clearly show that it exceeds your set max. However , in speed-view, you can see that the speed is correct. And in #Mainsail during printing and can actively see how it changes the acceleration limits as it prints overhangs, perimiters, and briges.
As you can see, I am between 2 slicers here
@Stark9837 @3dprinting You actually can: https://help.prusa3d.com/article/list-of-placeholders_205643#placeholders-for-configuration-options
This can definitely be used for printer options, which is where the acceleration limits are set.
@Stark9837 @3dprinting Heck, PrusaSlicer's stock starting G-code for the Mini even does this:
M204 T[machine_max_acceleration_travel] ; restore travel acceleration
@Stark9837 @3dprinting Here's the funny thing: it absolutely does, you just can't write to it. Prusa's firmware builds disable the Marlin build flag that permits this. If you use a firmware build with this enabled, you can save no problem.
The reason you can't just fix this yourself is because Prusa's firmware is signed, and without a physical mod to the board, you can't flash anything whose signature won't match.
Sounds like it is about time we fork it and make firmware and changes that it needs that the community can update their printers. #Opensource off course.
@Stark9837 @3dprinting Someone already did that: https://github.com/matthewlloyd/Llama-Mini-Firmware#readme
Unfortunately, this isn't an optimal solution because
1. It's not maintained and is quite behind now; and
2. You can't flash it anyway unless you want to physically modify the board.
However, in principle, I totally agree. Prusa's recent 'commitment' to open source feels like empty words.
Whay physical changes to the board do you need to make? Also, does it void the warranty and restrict you from returning to the original firmware?
@Stark9837 @3dprinting Yes, this will void the warranty, but won't restrict you from returning to original firmware.
The change is described here: https://help.prusa3d.com/article/flashing-custom-firmware-mini_14
Thanks, I'll check it out. It kinda sucks because on my #Creality, I can easily jump between firmwares, no problem at all, and no one will ever know, on inspection of the printer if I resturn to stock firmware.
It actually comes down to quality control and reputation. Every time I look at an #Apple #iPhone or #Mac, I think: damn that looks great, and it is so attractive. Also, users alway enjoy their experience.
Looking at all these #Linux subsytems and #Android setups, I sometimes look at an Android phone and think: WTF is going on here?
By limiting the user to always have a product that can still advertise itself and carry the promised quality through to word-of-mouth of other viewrs and users, you build a reputation.
Similar to #Bambu.
A good example is to look at the mod-ability of the #Ender3 and then search for it on #Reddit and r/3dprinting. It is the printer with the most problem. While r/prusa and r/bambu are just full of praise.
The opposite is, of course, true for the #Creality #K1, where they just delivered a shitty and broken system-locked printer.
@Stark9837 @3dprinting I do agree, but I actually don't feel the two have to be mutually incompatible. The MK3S+ combined both quality out-of-the-box and moddability for its time, and nobody had any issues.
The Mini was kind of the beginning of the end for this from Prusa, and lately, stuff's been _real_ bad. The MK4's new extruder is _so_ proprietary, opening it up is a warranty void.
I think it is all due to the "Stae of #opensource in #3dprinting" by Josef #Prusa that led to this.
We have 3 routes we can take now. #Closedsource #Bambu printers, semi-open #Creality (which is just a copy of everything out their basically), and #Opensource #Voron.
I am disappointed in Creality just becoming copy-cats and also releasing stupid stuff like the Creality #SonicPad and locking it up as much as the #FLSun 400 controller.
But companies like #AnyCubic aren't even trying to copy #Prusa. They are just cntrl+f'ing them by now.
@Stark9837 @3dprinting I feel that 'The State of Open-source in 3D Printing' is a symptom, not a cause. The Mini stuff I'm describing dates back from 2019. Basically, Prusa are hunting for a justification for stuff they already decided to do, probably for business reasons, at least IMHO.
I agree with the rest though, and to be honest, they _all_ have issues. Yes, even Voron and their awful monoculture of RPi promotion.
@Stark9837 @koz @3dprinting me and some folks on the Reprap festival circuit have been trying to resurrect the open source #deltaprinter scene with new designs and techniques.
It's been rough since Voron sucked a lot of oxygen out of the room and SeemeCNC has been nigh absent.
I've been working on some stuff to get more interest but time has been rough.
@Stark9837 @koz @3dprinting I'm less likely to do big huge prints vs lots of small high travel parts and weird big vertical pieces meant to be reinforced with carbon rods.
I've also been working on a delta optimized for XY at the expense of Z . Allows huge plate sizes and all it needs is a box to sit in. That one if it works good would be a game changer for alot of print tasks
"To flash your own (or a community-made) unsigned firmware, you’ll have to break the appendix on the logic board (called the Buddy board) and move the jumper in a correct position. Breaking the appendix on the Buddy board is irreversible and voids the warranty of your printer’s electronics."
Sounds a lot like those encryption boards you get. Whick I think #Bambu went crazy with, but tehirs are part of the #PCB, so it is more difficult to bypass it. I am quite surprised that not a lot of people have just removed the hardware from the #X1C and just installed #Klipper.
Probably because then you lose the beautiful touch display and wase of use of the #AMS. Although Klipper has many good color changers.
I welcome new licenses, and #Prusa is an excellent partner to do so because they can afford the laywers that we need to construct new licensing.
This really isn't my specially and would love a lawyers input. But is it possible to have a license where no one may sell your product, but it is still open and communities can extend and mod it?
Yes, it sounds like most licenses on #Thingeverse and #Printables and a lot like what #Gridfinity has done. But #Prusa keeps on using licensing so that people can actually sell their product.
For example, anyone can just recreate an original i3 or #Ender3
The key is non-commercial use.
The short answer to this is no, because contributions cannot be merged back: Non-commercial licenses are effectively one-way.
As a clear example of this, the Hero Me toolhead is non-commercial license but lacks support for the Anycubic Kobra. I will be publishing Anycubic Kobra support hopefully 'soon'.
However the Hero Me creator will not be able to merge these back because he wants to use this work commercially and I cannot let him do that without getting in to a complicated legal agreement.
The long answer is you need to beware of licensing systems and contracts in general that favor one party: Prusa's lawyers are not YOUR lawyers, Prusa is not a partner to any binding agreement with the community.
Especially since Prusa can't be trusted when it comes to open source: They don't release source code already for their bootloaders, possibly the most boring part of embedded firmware.
If Prusa is serious about balancing open source and capitalism they need to create a foundation that escrows source code that is legally bound to publish it after X years have passed. Prusa will then get a small edge and we will reap the benefits. Everyone's happy.
But I get the feeling they want exclusive rights over their code FOREVER, well past the date it is useful as a trade secret. This is not an acceptable compromise.
I actually had a falling out with the #HeroMe developer. He actually took the product over from someone else when it was open. And now, "to help support development," he wants monthly subscriptions.
Bullshit. He doesn't put out enough to justify a permanent subscription. Also, once you build it, why do you even need a subscription and support. It is not as complicated as a printer or #Voron where you need constant support.
Furthermore, he bombards you with "free" files. A folder with 100s of files, pretending he supports every single printer.
Then you buy the instructions because you are overwhelemed and then on the third page it shows all the printers which are unsopported.
You need to pay to see if your printer is not supported. I bought it and publicly shared that page, and he copyright striked me, and his followers attacked me online as if it is some cult.
He is a money grabber. Some of the pay-wall information should be free.
The NC license also means actual commerical printers can't implement this as a baseline toolhead. So we will continue getting bad toolheads forever. Yay!
Also, do we have any news regarding the #Prusa #MMU3 at all? Like we heard some stuff and got a nice trailer for the #MK4 when it was lanuched. But we still don't know anythjng of the MMU3 and based of the MMU and MMU2, it was utter disappointments.
I think I am just going for the #EnragedRabitCarrotFeeder
@Stark9837 @LordofCandy @koz @3dprinting J. Průša mentioned it briefly in the summer update on June 15. (two paragraphs near the end)
https://blog.prusa3d.com/prusa-summer-update-mk4-xl-mmu3-assembly-kits-and-more_79420/
A couple of incredibly busy weeks are behind us. I went on a tour around the North America (which was amazing!) and meanwhile, the team back at the HQ managed to wrap up a ton of things - both figuratively and literally....
@OttersDangerDen @Stark9837 @LordofCandy @koz @3dprinting I got a good pic of it. Much simpler construction, and uses a linear rail so less complex parts.
Didn't look at the filament sensor part, I may adapt the ERCF one I brought to MRRF.
@reprapryn @OttersDangerDen @LordofCandy @koz
Here, it is directly from the manual
Source: https://github.com/EtteGit/EnragedRabbitProject/blob/main/Documentation/ERCF_Manual.pdf
@reprapryn @OttersDangerDen @LordofCandy @koz
Here is the repository for those interested: https://github.com/EtteGit/EnragedRabbitProject
@Stark9837 @OttersDangerDen @LordofCandy @koz @3dprinting little bit different. It's the part in the selector carriage used as an antijam sensor and presence sensor.
The head filament sense sensor you don't actually need and ERCF and others new versions aren't using it anymore. The selector sensor is necessary though.
@Stark9837 @3dprinting Running Klipper on the MK3 isn't worth it: the stock firmware has some pretty amazing features that Klipper lacks, and the serial line isn't stable enough. The second thing is fixable, but requires an SPI flasher, so very few people do it.
Unsure about the MK4, but I suspect similar things hold. Plus, the MK4 inherits the Mini's 'must physically mod to flash own firmware' problem, which the MK3 thankfully lacks.
@Stark9837 @3dprinting The MK4 input shaping is on the whole a disappointment. All that for 4.5ish K accelerations?
They also said already the MK3 board can't support it, and won't.
Is it even input-shaping if it isn't uniquely measured for every printer? Spunds more like "kinematic optimization"
Koz Ross
Stark
Tofu
Rep Rap Ryn :3
tyx
Fritz Adalis
Henry Jeynes
Andy
Kernel Bob 
OttersDangerDen
