Interest in saving effort by sharing gcode?

Thanks!

Expressing alternate ways to fabricate an object (permutations in gcode) would be something to add if needed after we made static portable gcodes work well. I imagine it would best be done by expressing mappings from machine capabilities to gcode (one mapping per layer or something, I don't know), and not by expressing complete alternate gcodes. The permutations problem is different from, but related to, the portability problem. I suspect permutations are harder than portability.

The easiest route to a minimal viable portability demonstration would be to declare layer heights and widths at the top of each gcode file (I think Slic3r already does this, but I don't know if that is standard slicer behaviour) and have each printer's firmware adapt their behavior accordingly. If gcode said "layer height: 1 mm", then the firmware for a 0.3 mm nozzle printer should refuse starting to try to print that gcode, etc. Max X and Y positions (as assumed by slicer) could also be declared at top of gcode file.

Skimming the file as you suggest would be more robust than slicer-added declarations, and would maybe run fast enough to be usable with modern 32-bit processors. The added declarations on top would help 8-bit processors stay functional, while not preventing 32-bit machines from skimming anyways. =)

---

torbjornludvigsen.com

Quote
frankvdh

Quote
n8bot
How exactly does gcode not serve 3d printing well? I cannot think of a single limitation.

1. If I have a Diamond mixing nozzle, how can I specify that I want the colour proportions to vary with X & Y? I know I can use something like [github.com] to post-process, but that's a band-aid.
2. Or perhaps I have a single extruder... I want to pause the print at some height to change filament. Gcode per se doesn't help... someone's band-aid "Pause at height" plugin is needed.
3. My extruder has jammed 10 hours into a 12-hour print. I'd like to resume from the point where it jammed. Is that a Gcode issue? Dunno, but Gcode doesn't help.
4. Multiple Gcode variants as firmware writers have band-aided it to meet their needs.
5. Gcode files are huge, so transferring them to the printer's SDcard over the wire isn't practical.

On the first point, a bigger problem is that there is no slicer that will even generate the per-segment mixing specification that the RRF implementation of gcode has supported for about two years. If we had a slicer that could do that (which would need to use something other than STL as the input) then it would be a small step to further extend that syntax to support linear variation of the mix along each segment.

On the second point, pause at a specific height can easily be represented in gcode, so it's just a matter of getting it implemented in a slicer.

Third point - gcode does make it possible. I'm not aware of a gcode editor that makes it easy though.

Fourth point - I completely agree, too many firmware developers ignore what has been done before and do their own thing. Also the documentation of how particular gcode features are supposed to work and interact is often far from adequate.

On the last point, yes it is practical to send gcode "over the wire". Almost all Duet and Duet WiFi owners do this, using the web interface. We've gradually increased the upload speed on the Duet and currently most people achieve 0.8 Mbytes/sec. So only a few seconds for most gcode files, and very rarely over a minute. We've considered zip encoding them for upload and decompressing them during printing, but haven't found it necessary yet.

Edited 1 time(s). Last edit at 09/16/2016 10:10AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
frankvdh

Quote
n8bot
How exactly does gcode not serve 3d printing well? I cannot think of a single limitation.

1. If I have a Diamond mixing nozzle, how can I specify that I want the colour proportions to vary with X & Y? I know I can use something like [github.com] to post-process, but that's a band-aid.

with g-code? I don't understand exactly what you mean by "vary with X & Y," but the diamond hotend is far from ideal for accurate "per voxel" colouring -- gcode is absolutely not your limitation here. You could easily use gcode to indicate exact colour data - the gcode files would be massive, and your printer would have to support it...

Quote

[*] Or perhaps I have a single extruder... I want to pause the print at some height to change filament. Gcode per se doesn't help... someone's band-aid "Pause at height" plugin is needed.

how is a gcode pause not a solution? You insert the gcode for a pause... again, how is this not solved with gcode?

Quote

[*]My extruder has jammed 10 hours into a 12-hour print. I'd like to resume from the point where it jammed. Is that a Gcode issue? Dunno, but Gcode doesn't help.

do you think gcode is a magical genie that will help you become a better person? Yes, you can find the exact position in gcode that the print left off and resume from there? This proves how great gcode is... imagine if you had a binary file to input to the printer... this would be better?

Quote

[*]Multiple Gcode variants as firmware writers have band-aided it to meet their needs.

I don't see how this makes gcode bad to use for 3d printing...

Quote

[*]Gcode files are huge, so transferring them to the printer's SDcard over the wire isn't practical.

Sure... but why would an alternative not be huge? Maybe on old electronics it's not practical, but I print 500mb gcode files and upload them to my duet no problem.

You haven't said a single thing that has convinced me that gcode is unsuitable for 3d printing.

Swapping out all of gcode is a larger project than just portability. What do you think about moving machine specifics from ini-files to Configuration.h files? Would you use it? Would it make RepRaps better? Would it bring RepRap to people not currently RepRapping? Would you contribute?

---

torbjornludvigsen.com

Off topic:
I think it might be worth while to have a compact gcode format, both for file transfer and easier parsing in the controller.

After some thought I've come up with a proposal for what I believe may be a simple way to do it at about 50% of current file sizes. Thread is here: Compact Gcode.

(Done with this thread.)

---

My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!