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.

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.

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 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.

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

Damn!! 😂

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.

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...

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 🤔

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

😓 it was intended to be between the original file and the arc combined with binary file. However that is actually a 110% difference. 🤷‍♂️

😯

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.

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.

SD card storage:

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

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

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.

Your right I believe my math was from non g2/g3 to arc support and binary gcode.

the MK3's 8 bit board or the Prusa Buddy 32 bit boards?

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)

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.

Because Prusa control boards suck?

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

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 🙏

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

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