If dismissive means for you that the first reaction is not “Oh, I just LOVE your idea, let me drop everything and concentrate on this”, then maybe it is dismissive.
On a very personal note:
What is concerning me, is that such pointy-headed and demanding attitude mainly comes from people who just are taking benefit and never appeared in contributing, be it development, maintenance, documentation, funding or support.
If you need all these questions answered and if the feature is important to you, then make it happen. It is open source and you have all possibilities at hand. Be it either by personal effort or by finding / motivating / paying someone who does.
And, if you had read the thread, then you would have noticed that the arguments pro and con have been exchanged pretty exhaustively:
PRO:
Marginal benefit in the time taken to send the file from the webif
Marginal benefit in storing it on the SD card (just my personal opinion: If you were to store multiple GBs of sliced gcode on your printer’s SD card, then it would be time to rethink the workflow)
Integrity checking (Two notes: (a) would be as well possible with today’s gcode and (b) in my 11 years of 3D printing never had a single issue that would have been prevented by this)
CONTRA:
No or at best a minimal real world benefit for Klipper (Marlin might be a different story, but we are not Marlin)
Additional layer of obscurity in an already obscure language
Additional development expenses to implement the feature
Even more effort to write a decoder to facilitate troubleshooting (in fact, only here, this is quite regularly needed)
Additional development effort in associated products like Moonraker, etc
On all affected products, extra effort in maintaining, documenting and supporting it
If this worked, then it would be a nice way to harvest the only real benefit in speeding up the transfer from the webifs to the host on weak WiFi connections.
"Additional development expenses to implement the feature.
Even more effort to write a decoder to facilitate troubleshooting (in fact, only here, this is quite regularly needed)"
This only shows that you didn’t take a second to inform yourself about the topic. There’s no need to write either encoder, nor decoder. The functionality already is provided in a library. So it’s a matter of integration.
Additional development effort in associated products like Moonraker, etc
On all affected products, extra effort in maintaining, documenting and supporting it
That’s a point. But as mentioned in an earlier post, the Klipper God’s implemented much more useless stuff, that’s only relevent to the minority of users, earlier.
I’m well aware of this and what is today going by the name libbgcode is in fact existing since beginning of 2021 under the name meatpack.
Does this integrate it into multiple products? No
Does it create a standalone app to potentially decode a file for troubleshooting? No
Except for the slightly faster (if coupled with weak WiFi) transfers between webif and host, nobody could furnish a convincing reason so far.
So, what is your point?
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?
I completely understand that. My point is more on the communication aspect. I know I fail at it sometimes as well, but not just dismissing ideas out of hand can really help.
Using another large project as an example. I have not contributed to the Linux kernel despite writing patches for myself because I just don’t want to deal with the pain. Every project has some learning curve of how to submit patches, making sure they’re sent to the right person/repo and properly shepherded until their merged. Linux using E-Mail lists, instead of the GitHub/GitLab style PRs, and said lists being known for their toxicity is just not worth it.
I don’t want to come across as dismissing an idea. That’s not my intention at all.
So let me rephrase:
It sounds like you have an understanding of how big projects work and how quickly things can get out of hand if everyone’s ideas are implemented.
The typical way to get everyone on board is showing a real world use case on how implementing this is a net improvement over the current setup.
I 100% know how it feels to be the one person with an idea that everyone dismisses off hand only to have to fight and claw and prove my point only for people to say “OH, That makes sense”.
Anecdotal story: One year at work it took an ENTIRE YEAR for me to layout a plan and explain it to various levels of Management on how we could do something RADICALLY different than we had done for at least a decade. I got varying responses from a minimal “Hmm, I’d be cautious with this” to “You’re an idiot and you’re going to ruin the entire thing.”
But I KNEW I was right and could prove it, and I kept at it and kept refining it and kept pushing it. Finally everyone agreed to give it a shot and it was a unanimous “This is one of the best things we’ve ever done.”
So definitely don’t let me or anyone else tell you something can’t be done or is a stupid idea.