Is Binary Gcode The Future For 3D Printing ? (PrusaSlicer 2.7)
Вставка
- Опубліковано 2 жов 2024
- Love the channel? Consider supporting me on Patreon:
www.patreon.co...
Get Great Filament From PolyMaker & Help Support The Channel:
bit.ly/3P5MRD7
Download Prusa Slicer 2.7 here:
www.prusa3d.co...
Prusa Slicer Releases:
github.com/pru...
Prusa Slicer Modifier Documentation:
help.prusa3d.c...
ModBot Merch Store is now live! Get yours here:
bit.ly/3qhJ8Yl
Join the official ModBotArmy discord server: / discord
Prusa Slicer 2.7 has official dropped and with it comes some design and performance additions. In this video we take a look at these changes and how they work. I am really hoping to see some of these expanded upon and ported into other slicers.
(´∀｀)♡ As an Amazon Associate I earn from qualifying purchases:
Buy now on Amazon: amzn.to/2jQAOgV
Subscribe To My 3d Printing Blog! :
Lets Get Social!
Facebook: / dopesoner930
Twitter: / modbotarmy
Instagram: / modbotarmy
Twitch: / dopesoner930
Im down on compiled gcode.
Its too much complication vs archiving for transport and just serves to make tinkering ane custom gcode harder.
You lose comments, you introduce a decompile step if you want to even try to read the lossy conversion, and for no benefits over simple compression.
To me its just another pseudo proprietary move by Prusa, the "open source" company that hasnt released the hardware source for their past 2 printers, dislike open source publicly, and designs so their designs are harder to reproduce.
I appreciate these videos on new slicer releases.
One other thing G2/G3 brings (or at least should bring) is much better quality for round features / objects, if those are imported as .stp or some other format that's not just a bunch of triangles ( even then it might fit an arc where there's just triangles). Now instead of a bunch of facets we should be getting nice round curves. G2/G3 is always used in CNC machining and I was very surprised finding out that it hadn't been used in 3D printing.
Slicers work on the triangle soup foundation since they don't share the heritage with CNC pathing tools, and the "Arc Welder" is as its name suggests a G-code post process that detects arc like features in the line segment G1 stream and approximates them into an arc command; then a second approximation pass occurs when the printer's G-code input stage breaks them down into line segments again.
OCCT that performs STEP triangulation may not always choose sufficient resolution for either good print quality or the welder to recognise the arcs.
But i suppose once the workflow is established it may create enough demand for improvement.
Part of the problem is that slicers should ideally plan speeds and accelerations to maintain suitable pressure windows, but dragging arcs through this process would explode the complexity threefold or more. And it's already a pretty spicy and problem prone area. I wouldn't expect arc based planning to be on the horizon within 2-3 years.
I also think G2/G3 is a bit of a half measure, and you'd really want spline based everything (G5) but that's even harder. There is firmware support though, even if largely untested.
Arc based planning could be a very interesting place to try generative AI.
@@jtjames79that is literally not required or useful. Stop trying to slap AI onto things that don't need it
@@SianaGearz Not that I have tried it, but shouldn't PrusaSlicer importing STEP files mitigate this ? (first part, the acceleration planning etc is absolutely a dream so far)
@@XAD566 PrusaSlicer uses OCCT (same foundation library as FreeCAD) to ingest and triangulate STEP files. The models are treated as triangle soup still.
Historical comment. In the early RepRap days we had binary gcode. Back then the purpose wasn't to save file space but rather to reduce the amount of (compiled) code which the 8bit processors had to have onboard to parse gcode. By pre-parsing the gcode and sending the results in a binary format to the printer, simpler code was needed in the very tight 64K program space of processors like the ATmega644p used in the early reprap electronics. With 128K of program space (e.g., ATmega1284p) firmwares moved away from the binary gcode of that time. Makerbot, however, continued to use the binary format long after everyone else had moved on. As a result, much of the growing community began to associate .x3g -- the file extension commonly used -- exclusively with Makerbot, forgetting that it saw use, albeit thankfully briefly, outside of Makerbot printers.
I do miss my reprap Mendel. I don't miss having to adjust it more frequently than printing with it. Lol. It's awesome how far this community has come since the beginning. I remember thinking how cool it was when the makerbot thing-o-matic kit came out.
@@AmericanMakingdon’t forget how it would break and go rouge if you tried to change anything while it was printing. Or at least the one I worked on did.
@ZeFoxii Ah, the good Ole Days.
@@ZeFoxii And slicing with the early Repeteir. Brutal! Just a wall of settings entry cells with very limited description on what changing a given value would actually do. I lost months of my life in that interface. 😕
@@AmericanMaking I pleasantly forgot about that until just now. I thought the creators were sadistic while using the program because nothing made sense, you could change “1” setting and it would just refuse to function.
If the point is just to make a smaller file, IMO this binary gcode is not the way... It would be easier to do what SVG does which is GZIP compress and change to SVGZ! In this case it would make a lot more sense to take the GCODE file, GZIP it, and call it GCODEZ
Would it be more difficult for the firmware/controller to read a zipped form of gcode over binary? Or really it is not any different from the firmware side?
@@ModBotArmy You need a chunk of memory in the tens-of-kilobytes range to handle the decoding. The more memory, the better you can compress it. The best next step would be to find some big files, zip them up, and see how much space it saves. A specific compression is almost always going to be better than a generic compression, and you could still apply the zip compression to the binary gcode if you wanted.
@@ModBotArmy not really, as GZIP data can be streamed (like it does with this binary format), so impact is negligible. The advantage of using GZIP is obvious, as one could just decompress the archive and get the original text GCODE! So until I get more data on this, I am not sold on this new binary format...
You want it in Klipper? But why... binary gcode exists mainly due to one reason. Very slow networking capabilities of Prusa printers (0.1-0.4MB/s). Binary gcode gives you neglectable speed benefits on printers that have "normal" networking like klipper on raspberry pi using wifi - 10MB/s is normal on these (25 to 100 times faster than on Prusa printers).
I don't even see gcode parsing on AVR 8-bit Marlin printers from SD-Card as a bottleneck at all. And then inspecting and modifying binary files is harder.
There is a bottleneck where it may help, specifically printers connected by real serial connection (i.e. same those 8-bit AVR devices) to a network spooler such as Octoprint. Though i don't think in that case, that the slicer should be handling the conversion, you can transmit the data to the spooler as text, and the spooler should then convert it.
Does the slicer support reading compressed code directly? Compressing textual and binary code should produce roughly equivalently sized files.
The user shouldn’t necessarily have to care what’s sent over the network though.
@@DannoHung Binary G-code is slicer output rather than input.
Compressed G-code is pretty much not a thing, because 3D printer microcontrollers don't have the requisite RAM to run dictionary, lookback, arithmetic coding or Huffman decompression, and all the RAM they do have is best used for the move planner, as more planning lookahead achieves higher printing speed. This is why they invented binary G-code, in order to cut down on transfer volume while not using up any extra RAM, and it also reduces the text parsing overhead.
Compressed (3MF) and binary (optional in STL) models are common but that's not the topic.
@@SianaGearz I guess I was just thinking about archiving sliced output on a computer. Wasn't thinking it through completely.
Smaller file sizes to support my gcode hoarding habit
The problem I ran into already with bgcode was when I had a print fail half way. With normal gcode you can just find the height it failed and delete the gcode before that point. I couldn't figure out a way to do that with bgcode.
With 2.7 you can finally "paint on" fuzzy skin using the text modifier trick without the slicer crashing which is nice. Can't wait until it becomes as easy as paint on supports.
In theory its reversable, so you should be able to convert to text, make the change as you suggested and then change it back (or run it as .gcode).
Or even better would be add a feature that restarts a print at a specified layer height. Then I wouldn't ever really need to read the gcode. Easy enough thing to code maybe I'll add it.
I've been pretty pleased with 2.7 so far; I used the simple shapes and svg embossing to make some wargaming tokens very quickly from scratch. What I'd really like to see is some expansion of their mSLA features to expand beyond prusa specific machines.
I don’t think It’ll ever get chitu printers support sadly
@@arturofernandez8487 I think that's an issue with chitu wanting their own ecosystem iirc. They aren't really open to the idea of people being able to easily tinker with the board either; not outright stopping people, but not really having many resources available on how they work. I have had many issues playing around with FFF Printers that use boards made by them- even simple configuration like setting Extruder calibration and PID tuning is a pain because those boards often use non-standard commands (No M503/502/501/500 for example), non-standard things like using mm-per-step instead of e-steps/mm, and seem to be based of some firmware from before 2015.
I know complaining about grammar on the Internet makes me a dick, but oh god this one is driving me nuts. "Furthermore" means "in addition to what I just said." So it can't be the *end* of a phraseor sentence, because one must say the "addition" part!
So, "If you do want to support the channel furthermore" constantly has me going "furthermore *what*?" It just sounds so wrong. A better sentence would be "If you do want to support the channer *further*," which would mean "if you do want to support the channel even more." Or else, "Furthermore, if you do want to support the channel," which means "In addition, if you do want to support the channel."
I know, I know, English grammar doesn't have rules so much as guidelines, and grumbling about it just makes me old and cranky, but man does that phrase sound wrong to my overly-educated ear. Hopefully this rant isn't too offensive.
You missed such a good opportunity to rick roll your audience with that QR code haha
Damn!! 😂
I thought binary g-code was implemented to solve the slow wifi transfer on Prusa printers mostly...?
Binary GCode is going to be a problem. I still remember the days, when my makerbot would just take binary GCode files 7 years ago. Especially with Klipper, File Size isn't really a problem anymore
I agree. There are still things that are customized, like the exclude object tags. Having to update the binary format to handle those changes, especially if the binary version requires something special, is going to be a pain.
If you want performance increases, Klipper itself could compile the file to binary before printing (or maybe during upload), rather than having the slicer do it.
@@Raytenecks Klipper technically already does this. Just on an even lower level, for the motor steps
I've made an OctoPrint plugin to support this new feature that is awaiting review in the plugin repository. It simply converts the binary gcode to ascii gcode on upload, gaining the benefit of faster upload speeds. After that it prints from OctoPrint like any other gcode.
Do you really see user noticeable benefits (and not only benchmarks) ? Here uploading to raspberry pi (or whatever OctoPrint host is) was never a bottleneck.
@arekx yeah I use an old laptop for octoprint and my transfer speeds are limited only by the speed of the M.2 drive in it. On the other hand G2 and G3 are really nice for increasing print quality by printing arcs and circles instead of lines, but that only matters if the slicer assumes the stl files intended a circle instead of an insane ammount of lines. Which as far as i know they don't unless you use a .stp file which I think only Bambu Slicer and Orca slicer do. Nevermind that most wont have access to the file in step format and even less will have access to the original model and a CAD program that will even allow them to export in step format such as ModBot probably did with the ModBot model.
@@Guardian_Arias G2/3 are unrelated to binary gcode. These can be emitted into ascii gcode, too.
@@arekx I'm aware, I've been using G2 and G3 since the plug in first came out for Cura but migrated to orca slicer the moment i found out it supported step files since I use mostly my own models or at minimum a model I've reworked.
@@Guardian_Ariasarc welder takes line segments that look like an arc and converts them to a single arc. Does some mathematical curve fitting with error margins, so the result is an approximation of a curve. I don't think any process actually uses curves from step files, they probably all create a mesh estimate use straight segments, then create an arc estimate from that
It would be cool to cancel object be built in to something like spaghetti detector (if it's not already)
I used the SVG tool for a few things:
Material recycling markers can bow be added easily.
I designed custom chocolate coin molds in Inkscape and used the svg tool to shape them into objects.
One admittedly pedantic note. Prusa has not released binary g code as a standard. They have proposed a new format. It will only be a standard if a significant number of other people agree that it makes sense and adopt it.
Some nice quality of life features added, in regards to the file size, I can't be certain, but I'm pretty sure the push to Binary Code is due to the throughput bottle neck on some of the Prusa control boards, but it will help those with bad wifi throughput as well, but storage is cheap, and most running Klipper have larger than needed storage, and its very easy to add a large cheap USB drive and symlink the printer_data folder to it.
Yep, it's motivated by Prusas atrocious network speeds, but it'll also benefit their cloud services, the reduction will be massive at that scale. Others may adopt it for same reason.
Eventually, CAD and slicer merge.
Why waste time on file sizes? With network speeds getting so fast, and memory costs so low. Even if a file gcode is 500Mbytes, who cares? would transfer to my Klipper printers on a 1G network connection in seconds still!
Because Prusa control boards suck?
text tool is quite powerful, people should use it to tag 3d prints with a resin code, while recycling plastic is still a uncommon practice, one could wish for the day its not, but a big helping hand would be taging things printed with the polymer, especially black plastics. this could help people sort 3d prints better and if you are collecting your failed prints to oneday recycle yourself, itll help prevent a fair bit of contamination.
I like this idea.
In big picture, it might work for PET (not -G), PC, PP and possibly ABS - *without additives*
PETG, PLA and anything with CF, GF, wood or minerals go to energy waste anyway (unrecyclable waste is burned for heat and electricity. It's also possible to capture CO2 and reuse it).
For home recycling, I don't think many people would want to collect scrap waiting for home (or community) re-extruders 🤔
The benefits of binary G-code are pretty neglible. The format is already simple enough for a parser to work through the file. It might make for a slightly smaller file and easier to embed stuff like thumbnails into the file but that's more or less the beginning and end of its advantages. I wonder how it copes with the likes of Klipper that might embed macros into the G-code.
It's a terrible idea just like binary logs in systemd. It makes everything worse. gcode is meant to be human parse-able so you can tweak, fix problems, do fancy tricks, etc. In fact that was the only way to do it back in the day.
@@_droid this isn't analogous to binary logs in systemd which exist for a purpose - they're indexed for faster searching, tamper protection and for log rotation. And if you want text logs in systemd you can do it easily by changing journald.conf to forward messages to syslogd where they get written out however you like.
The beginning of 3D Modeling in slicer software.
Thanks @Modbot great info as always. I switched from Superslicer back to Prusa for the new features. I haven't converted to Orca slicer yet, but need to try it as well.
11.5MB to 4.9MB is a 57% reduction, not an 80% reduction.
Your right I believe my math was from non g2/g3 to arc support and binary gcode.
I don't see the advantage of minimizing file size. Storage is extremely cheap. What am I missing?
I do see arcs as an improvement because it lets the printer be smarter about how it moves without having to do funny business like lookahead (common in high-end CNC), but it's something usually turned off in high-end CNCs because programmers don't trust it. :)
nice daniel gonna try it
still think we need the bottom slicer to have same options as the right ill show ya what happens
Nice! Just converted to Prusa after being a longtime Cura user. Just having access to the labeling feature is worth learning ANOTHER new app...
Binary GCode is about as relevant as finding a stronger compression for midi-music: Useless.
Filesize is not a problem. If you are running a Prusa-printer with their proprietary everything then you are not impacted by just a couple MB of data. can you even get SD-cards from reputable sources that are smaller than 4GB?
We can all go back to 16bit motherboards while printing at 200mm/s now!
Seriously though pretty cool stuff (image files as modifiers could be nice)
Need to download the update. The ability to add all the graphics I make for my laser to 3D Prints sounds like it has some pretty awesome potential.
The "add text" or SVG part to the slicer is next level, that is going to be so good to easily make nametags and other things for blank plates.
I seem to be in the minority but I fully support switching to binary GCode.
I understand the the file size isn't a bit deal in regards to storing it on a USB stick and it's only a minor advantage for transport.
But it can be a big deal for the memory usage of 32 bit printers!
Besides, if you really want to view or edit the GCode you con do it on the Slicer side before you send it to the printer.
Being a Klipper and raspberry pi user, Id rather just send a file to the printer that was the geometric data and the slicer settings and then the pi host runs a headless version of my slicer that always slices the same way the desktop version I'm running does. I'd like this so 3d printing files were more reusable and adjustable without having to reslice and resend as much. Sending gcodes is really tedious when I want to make small adjustments or use something on another printer. I'm sure this can be refined and might not be as smooth as what I have in mind but I generally like the idea. Something I've been thinking about quite a bit lately.
I want to learn about Prusa slicer... but for some reason it doesnt work for my Snapmaker J1 printer.
He's been crushing it since the dopesoner days with the 360 mods! Keep it up homie!
Why is reduced file size important?
Why does file size matter with regard to binary gcode?
Does Klipper have support for this format?
wow this might make finally leave cura
Silly you.. binary gcode is a downgrade.
Please stop i just moved to orca sclicer now prusa is better come on :(
am i the only one who used the qr code on your phone to see where it led? spoiler it sends you to their youtube.
Kinda feel like this whole video missed the mark.
Thanks for the review on this machine. I have had their Adventurer 3 since it came out and liked the experience, whilst staying with their Slicer. So far so good.
Now I'm looking to enclosed CoreXY as my next printer in the fleet. This wasn't on my radar until your video today. Colour me impressed. But, the Flashforge attitude to the software troubles me greatly. What you have described is not a good look! I'm currently transitioning to Orca from PrusaSlicer across my other machines. The choice of CoreXY has to come along with the plan also.
So what to do? Buy into another Flashforge or go elsewhere. My hot favourite is the Bambu Lab. This definitely tickled my interest. But I think I cannot commit on this occasion.
YO. i had a project i put off for MONTHS because the prusaslicer macro editor was unusable. this changes everything for me.
Cancel Object i would've reaaally needed yesterday :/
That print was running on SV07 Plus with klipper
Hey! I have an important question: is there a way to partwise print with the sequential printing options? I have a few objects with a base color and an embossed but maybe with different color, so I want to print subsequently all the bases and then subsequently print all the embosses obviously with color change… is there a plug in or so? I have a prusa mk3…. My objects are 7mm in total height!
And why is filesize an issue? i have terabytes of storage space on my desktop >.>
SD card storage:
How to configuration .8 Nozzle setting in this software.
In what universe is 11.5 to 4.9 80% reduction? :D
😓 it was intended to be between the original file and the arc combined with binary file. However that is actually a 110% difference. 🤷♂️
binary gcode is mainly a prusa problem for their sub-par MCUs
the MK3's 8 bit board or the Prusa Buddy 32 bit boards?
Issue with G2/G3 is your printer needs to be updated to be able to perform this and some older ones don’t have enough room in memory for this feature without loosing others.
No, no and no. That's 57%
Modifier masking from SVG is awesome, cant wait to use this
Another great video walk through, love it👍😀
Thanks for sharing your experience with All of us 👍😀
Love the Lightburn shirt. That's what I use on my co2 and fiber lasers.
Literally, this video just saved me so much frustration
link to frame 0.39 pz
One problem with binary is how do you manually review and edit your gcode if it isn't human readable? Do you have to translate it and edit then translate back? Also it being a Prusa only feature might speak volumes on it's own considering their units are still loosely based on a variation of the Mendel and are priced out of their performance branch in the market. Why fight and limit the open source that created the successful RepRap formula to begin with?
binary gcode is open source, so is the code to convert it to ascii and vice versa. It is only implemented on Prusa because it would be bizarre if the inventor of the format wouldn't want to use their own format and the fact that you can't expect a firmware update for other manufacturer in a month for a support on a feature that just has been invented that month. i literally don't know what could be more reprap spirited than this
Klipper isn't really compatible with arc fitting (G2/G3). It works but it will break it down into G1 again. This can lead to very big load, overwhelming a raspberry pi 3 core. Klipper printing isn't multithreaded. Arc accuracy at 0.1mm (or less) in Klipper settings and 250mm/s printing speed will choke the pi and results in print error and shutdown.
😯
Fundamentally, that's how all firmware handle arcs, by line segmentation. Of course you want a sensible setting that is computationally and physically suitable for your machine. You probably don't want segment size much smaller than nozzle size anyhow.
Klipper's handling lacks robustness but does it even matter? I mean what would happen if you supplied 0.1mm segments in G1? Probably nothing good. Arc segmentation is fairly computationally simple and parsing overhead is less.
I've not had any issues with arcs in Klipper, running pi4s though.
those new features are pretty sick. 👍👌
I wonder why binary is not default. Are there any downsides to using it?
Impossible for a human to understand and troubleshoot. Not backward compatible with older machines or firmware.
It's kind of pointless. Being able to read the file is far more useful than saving a bit of data. I've never had any issues with gcode file sizes, sd cards are far larger than the average person's print volume
@@zapl80 For expert users as yourself sure, but I bet 95% of people with 3D printers can't even read GCode.
It WAS as set to default on my instance of 2.7, and that is a problem because I am printing through Octoprint and it does not know how to handle the binary version. Had to search for the setting and disable it. Thank gawd for the setting search function!
You should ask the other way around:
Are the any benefits to binary-code?
Filesize? really? going from 15MB to 10MB ... are you still using Floppies? Cause that is negligible.
Binary representations had been used before - when the code was read by tiny micro-controllers that had so little RAM (just a couple kb) that even parsing a string became a problem. And after even the cheapest chips could handle parsing it was just obsolete.
On the other hand - G-Code is a many decade old STANDARD. That is the whole purpose of having standards - that they "just work". There is no benefit to completely breaking compatibility with literally millions of machines.
i never understood why they only use coordinates instead of using ISO code (what all you ladies call Gcodes is only a handfull of codes taken from ISOcode... what many CNC machines use allready for over 50 years as far as i know...) Over 20years ago we had to program cnc machines in pure 'Gcodes'. Imagin having to know all 'Gcodes' from the head...
ISO is an attempt to standardize gcode in Europe that was previously invented in America. Slicers do produce gcode using standard stuff like G1 but since gcode for multi axis cutting machines has many more and different requirements than a printer there were some necessary adjustments and it's obviously only a subset of one of the many competing standards
Love your content, hate your intro arm swoop thing. You just look silly doing it and the way you say what you say just feels forced. I'm just one opinion, and not trying to be mean.
It started as almost a joke, but when I mentioned I was gonna remove it there were way more that said they would miss it. I think it’s okay to be silly. I try to not take myself to seriously.
You must be a fun guy....jesus christ
Arc Fitting and "binary GCode" are features that Bambu Studio had from the start, which makes me wonder how a fork from Prusa Slicer took so long to backport. The Bambu binary GCode is jsut a 3MF file with the GCode file inside it (basically a ZIP with some predefined files in it, unzippable with the gzip library)
Lately it looks like "Prusa Research" is just waiting for someone else to do it then copy their homework.
Bambu probably also just took arc welder lib, which existed as octoprint and cura plugins for quite a while
@@zapl80 It's all open source. Anyone can use or implement it. The real question is why prusa took so long?
I cant wait until 2024 when they invent multiple build plates in slicer.
@@hawtdayum I know, they are all forks of slic3r in the end which started out as more or less gui-less perl script "for RepRap 3D printers, aiming to be a modern and fast alternative to Skeinforge." (which was pretty terrible). But since prusa, bambu, superslicer, orcaslicer should all work fine for any printer, why rely on prusa? (fork tree looks like this: slic3r -> prusa -> bambu -> orca and superslicer which was forked from prusa - they all mix and include parts from cura as well, like the arachne slicing engine)
Great video, but its time to hit the gym. That is not meant to be hurtful, it's a friendly reminder from a subscriber who cares
First pearson ;) good job man, keep it going!!!
I fail to see the value of smaller 3D printer file sizes. STL's are already tiny compared to a lot of other computer files. Unless it leads to faster printing it seems like a lot of nothing.
STL files can become quite large depending on your output settings. I've often had files with well over a million triangles.
The file size compared to most native modeling files is actually very large. Aka compare the size of a STL file to a SolidWorks model file or any native cad file.
It's not just smaller file sizes, STL's are a bunch of triangles, not really an accurate way make moves while printing or machining models with arcs (to exaggerate think of a low poly model). STL's are only straight line moves, so an arc or circle consist of single G1 moves (X,Y to X,Y) enough to complete the arc or circle. G2 (clockwise)/G3 (counter clockwise) is an arc code with one line of input and can complete up to a quarter circle (so 4 lines per circle) this makes for smoother completed models with more accuracy. I always convert to STEP before slicing for this reason, the smaller file is a bonus side effect that is also beneficial. And technically, it should be faster at printing as well with less harmonics.
Binary Gcode is the cemeting of proprietary gcode. Just in a few years nobody will be able to edit gcode, and it will become incompatible among the brands. So that nobody can run gcode for one printer brand on another. It's of course will be done for you safety.
Binary gcode is a completely open standard/specification. Prusa even provide the code and tools to convert back and forth. A company wanting proprietary gcode wouldn't have to wait for Prusa to create a specification, they would just have done it already (as several have, like Zortrax).
Wait till 3D printers go subscription model like everyone is attempting these days. You pay a yearly subscription for the right to use the hardware you bought and own. And they can disable or brick your machine at will.
And for those have been living under a rock the past 10 years…. Yes this is a hugely relevant very common thing these days.
their Nextruder isnt patented, so subscription model will not happen anytime soon@@ericrandall3539
I really want to watch these videos, but as usual, I had to either skip a ton of commentary filler or search the video for anything related to the title. (Binary GCode starts at about 3:44 and the videos don't have chapters.)
This could be excellent content with better editing.
your that guy! It's only 7 freaking minute video, it's not like it's over an hour. Your the the reason why I never publish my stuff to the public, life is too short to deal with people like you.
Yeah after making videos for over a decade I have really had to stop trying to please everyone. The reality is there is always going to be some that are not happy. The good news is the positive feedback far outweighs the negative 😊. Complaining about having to skip through a 7 minute video when I spent 6-7 hours (at least) chopping and placing things. 👀
@@ModBotArmy Keep it up man, your doing great. your discord is very helpful also!
@@allisterfiend_2112 I appreciate it 🙏
besides being able to fit more 20mb .gcodes on my 32gb, so thats around 1600 files, more than ill ever prinit.. does the file size affect the print?