Just another perspective, but the use of binary gcode is not entirely be about file size, but the efficiency of processing the file
On the IO rate of a Raspberry Pi, the file is done processing before your printer would even be done processing the move to home one axis of your printer. (Assuming you hypothetically loaded a file and homed concurrently).
I could understand if this was 1985 and we were using the odd-and-even refresh of the video memory to squeeze an extra kilobyte out of the system. But processor throughput is (mostly) a concern of the past.
I say this assuming no one here is printing 500mm x 500mm x 500mm .005 layer height models. I don’t know what the process rate is like on that one, I never tried it.
Thank you. As someone looking to get into Klipper, this dismissive attitude was the first thing I saw and concerns me.
You have to understand that EVERYONE and I mean EVERYONE thinks they have a great idea (That’s not a knock at anyone, I do the same thing constantly), but almost ALWAYS when you get into the nitty gritty details of executing said idea things are MUCH more complicated and nuanced than they seemed on the surface.
Plus, Klipper is far and away one of, if not THE most popular 3d printer Firmware out there right now. With anything that’s used by potentially millions of people, you have to be very conservative with updates to make sure you don’t break one of the thousands of different configurations or setups that people have and that you don’t accidentally introduce other issues.
Hence the “What is the gain of this? Is it worth risking a worldwide user base that is potentially fine with the way things are for an extremely minimal gain?”
On the flip side, The great thing about Klipper is it’s open source. I, along with many others, run their own custom version of Klipper that they’ve made enhancements to which benefit just them. Some of mine may make it into the mainline Klipper one day, but if they don’t, it doesn’t negatively impact me. All you have to do is fork the Github and you can edit it to your hearts content.
I know that not everyone knows how to program, but honestly, neither did I at some point. I never went to school for it, I’m self taught. It’s easier than ever to learn new things with Google, and StackOverflow, Discord etc. etc.
Plus, I bet if you posted in the Developer section with “Hey, I’m messing around and trying to do this and that, has anyone messed with this?”. You’ll get some feedback, though that’s a rather slow section. It’s the one I frequent the most.
I refer you to my own post from a few days ago. I stupidly “upgraded” my Voron printer to be totally ran by CANBus without realizing it doesn’t support multi_mcu homing on a shared axis (With multi_mcus). (This is why you read the documentation).
I cut my stepper wires short to clean up my wiring with my new toolheads so I kinda screwed myself. Rather than giving up, I jumped into the firmware to see if I could fix the issue and I might actually have (needs to be tested by others).
2 weeks ago I had only a vague notion of how Klipper motion control or probing worked at the lower level, Now I feel fairly confident at jumping in to see what else I might fix.
Will my fix ever make it to mainline klipper? Maybe, If it works without unforseen consequences. If it only works for me, I’ll try to make it work for everyone. If I can’t, well… That sucks… But at least I fixed my own mistake?