Welcome! Log In Create A New Profile

Advanced

Interest in saving effort by sharing gcode?

Posted by tobben 
Interest in saving effort by sharing gcode?
September 05, 2016 04:29AM
Hi All!

I'm posting this thread to poll the attitude towards the portable gcode idea in the community. The idea is to avoid having to slice for oneself. One person slices and distributes gcode (or other kind of RepRap instructions), many people download and print.

The idea has circulated in the community for some time, see gcode alternatives list on RepRap wiki. I'm interested in the idea because I've seen what C did to the Unix community (portability, cooperation, saved effort). I'm teaching RepRap Assembly Workshops, so not having to slice would be a huge time saver for me.

I've noticed that two questions often get discussed simultaneously here on the forums
  1. Should RepRap instructions be more portable?
  2. Should we do more computations on the PC rather than on the microcontroller?
I would like to discuss question 1, and not question 2, because portable gcode seems within reach with relatively small changes to existing firmware. Those who develop and configure firmware could get started with portable single extruder gcode by just
  • Ignoring explicit gcodes that set temperatures, making temperatures into firmware settings instead.
  • Ignoring gcode-set speeds (or setting them rather low by in Slic3r to begin with).
  • Using firmware filament retraction.
  • Treat E-parameter of G1/G0 as a boolean. Should I extrude during this move or not? If yes, the amount is determined by firmware settings.
Those who slice would probably want to disable some settings. Listing some examples from Slic3r here:
  • Disable "nozzle wipe".
  • Disable "XY compensation".
  • Disable "pressure advance".
  • Disable "vibration limit".
  • Disable "Z-lift".
If firmware hackers and printer designers wanted to go further there are obvious paths for incremental improvement. List of suggestions in no particular order:
  • Standardize hot end/tool head enumeration (see M563).
  • Make Z-lift a firmware option. Travel moves are easily detected in firmware...
  • Implement M99: Set axis_hysteresis_mm.
  • Implement what Slic3r calls "pressure advance". This is hysteresis compensation for the E axes.
  • Make already working filament diameter sensor more accessible, or just spread it as it is.
  • Detect layer changes and set a max Z-distance per plastic volume and minute during print, to achieve something similar to Slic3rs "auto cooling".
  • "Skirt" feature could be renamed "nozzle priming" and moved from Slic3r into firmware options...
  • Agree on a range of nozzle diameter for which "portable gcode" will actually be portable to, or make nozzle diameter dynamic.
  • Each G1/G0 move could have a parameter differentiating between perimeters, small perimeters, infill, travel, first layer etc.
I realize I get closer to the coherent and standardized STEP-NC solution suggested in 2010 towards the end of this list, and that PC/microcontroller computation division must eventually be discussed. My point is just that we can get lots of the benefits quickly, and go there in incremental steps together if we want to. Firmware and slicer developers have already set the scene nicely but people don't share a lot of gcode yet.

Are there interest in taking the easy, incremental gcode portability route?


blog
Re: Interest in saving effort by sharing gcode?
September 05, 2016 11:37AM
Are you aiming for drag-and-drop printing? No messing with slicing settings? [edit it seems so, missed the first part]

Edited 1 time(s). Last edit at 09/05/2016 11:39AM by n8bot.
Re: Interest in saving effort by sharing gcode?
September 05, 2016 12:13PM
Yes =) Would you be interested in developing or using portable gcode?

Edited 2 time(s). Last edit at 09/05/2016 12:14PM by tobben.

blog
Re: Interest in saving effort by sharing gcode?
September 05, 2016 02:22PM
Some interesting ideas there. A few quick comments:

Z lift as firmware option: it already is, it's included in the firmware retraction parameters. See M207.

Pressure advance: this is not the same as extruder hysteresis compensation. Already supported by Sailfish, RepRapFirmware, and now Marlin.

Filament diameter sensor: only needed if you are using very cheap filament, or making your own.

Skirt: how would the firmware know how large to make it?

Nozzle diameter: the slicer needs to be able to choose the extrusion width, otherwise solid infill isn't going to work. This will limit the portability. Also the extrusion width assumed by the slicer will need to be declared in the gcode.

Move type included in the G1 command: this would be very useful and I have suggested it previously.


Delta printer calibration calculator, mini IR Z probe, and colour touch screen control panel: [escher3d.com]

Large delta printer, and other 3D printer blog postings: [miscsolutions.wordpress.com]

Full disclosure: I have a financial interest in sales of the Panel Due, Mini IR height sensor, and Duet WiFi/Duet Ethernet.
Re: Interest in saving effort by sharing gcode?
September 05, 2016 11:52PM
=) The best work is that who has already been done.

Pressure advance compensates predictable delay (hysteresis) between extruder acceleration/deceleration and changes in plastic flow observed in Bowden setups. Useful for making corners sharp even if hot end decelerates before it turns. (Edit: Pressure advance is largely superseded by autospeed feature in Slic3r.)

Instead of skirt, I thought each printer design could have its own print head priming procedure. Not a big win or very important, just something fun to work with if people wanted. Would make gcode more closely resemble the geometry of the desired 3d model.

Agree on nozzle diameters! Luckily, gcode sharing will work for many people even if there are a few different standard nozzle sizes out there. Cheap variable diameter nozzle design is very hard but very useful. Just dreaming.

What response did you get when you suggested to include move types in G1 commands? The coding should be doable. Were there opposition/arguments against it, or were there just no slicer coders in the thread?

Edited 1 time(s). Last edit at 09/06/2016 12:02AM by tobben.

blog
Re: Interest in saving effort by sharing gcode?
September 06, 2016 12:42AM
So far, I haven't seen a single model on Thingiverse or Youmagine that didn't need to be edited for my needs. If they were provided as gcode only, then they would be virtually useless.

Why do you spend so much time slicing? For me, a model that takes an hour to print takes less than a minute to slice.

Now, if someone would make a slicer that could consume more sophisticated 3d models like IGES or STEP files, that would be a big timesaver.
Re: Interest in saving effort by sharing gcode?
September 06, 2016 01:05AM
Consuming STEP files would be great, but requires a huge effort. How do you suggest we start a STEP consumption project?

Edited 1 time(s). Last edit at 09/06/2016 01:06AM by tobben.

blog
Re: Interest in saving effort by sharing gcode?
September 06, 2016 01:25AM
S3D slices files instantaneously on my crappy old laptop, so why is portable gcode needed?
Re: Interest in saving effort by sharing gcode?
September 06, 2016 04:53AM
For convenience.

It would make RepRapping easier and allow us to leverage on each others' slicing work as a community.

Examples:
  • I often run into damaged STL-files on CAD sharing sites. Portable gcode would save in on my time and attention even if it made my printer run slower, if it just worked.
  • My teen workshop students want to "just press print" a couple of times before they dig into slicing details. I give them default slicing settings and automatic instantaneous slicing, but it gives them ugly prints.
  • Tools for manipulating gcode, who give visual and fine-grained control, would make more sense to use and develop for portable gcode.
  • Portable gcode would allow people to specialize on slicing well, and we would benefit from their work. Consistent and well-behaving gcodes.
  • I just like the idea of sending off ready-to-use gcodes to my RepRapping friends, especially those who dislike slicing themselves.


blog
Re: Interest in saving effort by sharing gcode?
September 12, 2016 12:15PM
Tobben,
I want to get to the root of your issue, so bear with me - I'm not trying to pick it apart - I am providing possible solutions.

My background is in all facets of design and development of multi-tier computer systems and desktop apps, and I have been working for over a year on analyzing and post processing gcode from multiple slicers.

My basic design rules are:
#1: First carefully describe the output/result that you really want.
#2 There needs to be a good reason/benefit for any work done.
#3 Complexity kills - don't do it.

You listed these goals which I've prioritized and summarized:

(Convenience, Sharing, Just click Print)
1) For convenience.
2) It would make RepRapping easier and allow us to leverage on each others' slicing work as a community.
3) My teen workshop students want to "just press print" a couple of times before they dig into slicing details. I give them default slicing settings and automatic instantaneous slicing, but it gives them ugly prints.

(Portability)
4) I just like the idea of sending off ready-to-use gcodes to my RepRapping friends, especially those who dislike slicing themselves.
5) Portable gcode would allow people to specialize on slicing well, and we would benefit from their work. Consistent and well-behaving gcodes.

(Good Models / Model Repair)
6) I often run into damaged STL-files on CAD sharing sites. Portable gcode would save in on my time and attention even if it made my printer run slower, if it just worked.
7) Tools for manipulating gcode, who give visual and fine-grained control, would make more sense to use and develop for portable gcode.


So here is my analysis:

1, 2, 3 - (Convenience, Sharing, Just click Print)
What is really needed is printers that just print well - because the firmware and slicer settings are tuned properly. This is the root of the problem, and nothing else will fix it, not moving the slicing to a stranger for sure, and not having it sliced from a CAD file, or by an agnostic gcode to tuned gcode converter.

There are several things that would make tuning easier, and multiple complications - since the Reprap community, and it's printers are by definition not "standard".

Solution 1: There could be a central repository of ini files - by firmware type and by printer type. This would help new Reprappers get started tuning their machines by having some sane defaults. This would need to be curated.
Solution 2: A repository of good slicer settings by printer model and slicer. This would help with the more common printers, but there are multiple complications - different hot ends and filament types and even filament batches require different speeds and temperatures, variations in thermistor readings, the temperature of the room, quality of the build, etc. Still, it may help get started with sane values. This also would need to be curated. One could always ask in a forum.
Solution 3: A Guided Calibration program - to guide the user through calibrating each variable (firmware and slicer print settings). This would output gcode specific to their printer to test a specific variable - the user would print the test and visually or by measurement - pick the best result. I know this will work because I have already programmed and tested multiple modules for Guided Calibration, but I'm busy working on other things - gcode post processing for pressure compensation.
Solution 4: For your students - you should go through the calibration process with one of your printers, and supply the students with the conservative slicer settings that you find work well. This is what our maker space does. The default settings in slicers are only good for one printer - the printer the slicer developer used!
Solution 5: Buy a commercial slicer like Simplify 3D if it already has a profile for your printer. This will only get you started tho, you still need a calibrated printer and known good settings for temp, speed, extrusion width etc for your particular printer, hot-end, and filament.

BTW, although it would be nice, it would be of little use requesting the free slicer developers to add default parameters for different printer models. Some are a year or more behind in bug fix requests... Someone has to do the work... often for free, and "someone" would still need to supply the particular tuned profile for each different printer/hot end combination. I think it's better for them to concentrate on making it bug free... I do notice that Simplify 3D has been adding a lot of printer profiles lately for commercial printers.

4, 5 (Portability, Well behaved gcode)
You are talking about printer agnostic gcode that just works. However, as stated above, both the firmware and gcode commands executed need to be tuned for the particular printer, hot end, filament, etc.
So what is going to apply the tuned settings to the Gcode? Shifting the burden to a new PC based program to take the agnostic gcode, and output well tuned gcode (or other instructions) means you must already know what the well-tuned firmware and print parameters are for your particular printer, filament, hot end, etc.

This burden can not be moved to the firmware either for multiple reasons. A) the people writing the firmware have enough on their plates just making the printer do what it's told to do by the gcode. cool smiley The firmware is already complex - adding further complexity will break it on 8-bit machines (not enough processor cycles), and will make it un-maintainable for all machines. C) Firmware should be set-it-and-forget-it. Most firmware requires a recompile to update the settings. (Rule #3)

"Slicing well" means you have done the calibration and test prints, and know the limits of your machine, so you use the right values in different situations.
There needs to be a better calibration guide here - I was planning on writing one for Slic3r - but too busy doing other research, and I've switched to S3D!

6,7 (Good Models / Model Repair)
Good models - Unfortunately you will not get what you want by sharing Gcode. You will only get less or no models, as the free sites you describe will not be publishing gcode.
Solution 1) Use a better model repository that has checked their models.
Solution 2) Buy you model if you have to - your time is worth money.
Solution 3) Create your own model.
Solution 4) Get a good repair tool. I have learned to use Meshmixer. It's free and very powerful. It does have a learning curve, but is better than anything else I have seen for the extensive repairs I have done. Watch the videos.
Solution 5) Request that people also share their models as well as the gcode (so they can be more easily modified)

I have done extensive post-processing including the insertion of angular hops, breaking segments or converting segments to other uses (like early retract or unretract, pressure compensation, etc), calculation of loop acceleration profiles, speed, extrusion rate, so I understand gcode.

Unfortunately there are a few other things that will make sharing gcode impractical.
- The primary thing dc42 alluded to has implications: "Nozzle diameter: the slicer needs to be able to choose the extrusion width, otherwise solid infill isn't going to work."

The fundamental thing that gcode describes is the tool path, not the object shape. There is no getting around this. For example if someone slices using an extrusion width of .65mm, the tool path exactly describes the printhead movement to lay the filament that X/Y distance apart (give or take overlap). It is not practical to move/add to/subtract from/convert the tool path to work with another extrusion width. Please do not suggest multiple versions of the same gcode for different extrusion widths.

The next issue is layer height. The tool path described by gcode lays down the perimeters and infill at a specific layer height. Well, what if they want to print at .15mm instead of .25mm, or vice versa? The converter/optimizer would have to basically re-slice and interpolate, and the unavoidable result will be the loss of precision. An STL or other 3D format better describes the object, and slicers already slice well... Please do not suggest multiple gcode versions of the same object for different layer heights AND extrusion widths.


Quote
tobben
Consuming STEP files would be great, but requires a huge effort. How do you suggest we start a STEP consumption project?

Why do it? (Rule #2). Just output to stl or obj, and slice.


Well, I hope I have provided some perspective and possible solutions!

Good luck with your endeavors.


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!
Re: Interest in saving effort by sharing gcode?
September 12, 2016 06:48PM
Learn to Love Slicing
Re: Interest in saving effort by sharing gcode?
September 12, 2016 10:04PM
Sharing gcode? In my experience, about 50% of the STL files on Thingiverse are trash. If people think nothing of uploading bad STL files, what makes you think they're going to do better with gcode?

The only STL files I've ever had to repair before I could slice were generated by SketchUp. If people would just stop using Sketchup for designing objects for 3D printing a lot of the STL problems would go away. That would just leave the bad designs that people feel the urge to post even if they haven't printed and tested them.

Slicing is where the operator gets to control the print quality. I would not want someone else's slicing preferences dictating the quality of print that I can make.

It's nice to dream about one click printing, but as long as there are differences between printers and the people who operate them, sharing gcode isn't going to work.


Son of MegaMax 3D printer: [www.instructables.com]
Re: Interest in saving effort by sharing gcode?
September 13, 2016 04:12PM
Calibration constants will be the same whether you feed them into a ini-file or a firmware. You do not in general need to compile/upload firmware to feed it some constants. Machine specifics should be contained within the machines, and their interfaces should be kept clean if you care about design principles. Gcode is the interface between the desktop computer and the RepRap.

Firmwares are not complex compared to other small/medium sized c/c++ programs we use every day.

I use print widths between 0.5 to 0.8 mm regularly without changing nozzle and it works well.

I like to slice myself, and would not stop slicing even if portable gcode existed. I would also like to share the gcode I created.

Technical designers often know how their 3d designs should be fabricated in order to function as specified. Portable gcode (or STEP) would give them a language to communicate their knowledge clearly.

Portability and modularity are good things. eye rolling smiley

Edited 1 time(s). Last edit at 09/13/2016 04:19PM by tobben.

blog
Re: Interest in saving effort by sharing gcode?
September 13, 2016 08:22PM
The real answer, then, is for the controller to generate its own gcode. 2d desktop printers have drivers that "slice" the document themselves, with a myriad of options available that are specific to the machine. Is that not the way to achieve "portability"?

Edited 1 time(s). Last edit at 09/13/2016 08:22PM by n8bot.
Re: Interest in saving effort by sharing gcode?
September 13, 2016 08:42PM
Except it can't account for user preferences such as layer thickness and infill, etc. , and without prior knowledge of the filament type it can't really know what temperatures to use(or even if the printer has a heated bed) of what the speed limits should be. If the user has to enter all that at print time they may as well just run the slicer themselves and get maximum control over the print.

If the gcode contained a whole bunch of variations, such as different nozzle diameters, filament materials and temperatures, heated/unheated bed, printer size limits, speeds, etc., and the printer had some way of selecting the appropriate path through the gcode file, it might work...


Son of MegaMax 3D printer: [www.instructables.com]
Re: Interest in saving effort by sharing gcode?
September 14, 2016 12:12AM
Quote
the_digital_Dentist
If the user has to enter all that at print time they may as well just run the slicer themselves and get maximum control over the print.

Agreed, Sigh. Unfortunately the issues are not getting across, so I have to be blunt I guess. And I might be a bit cranky now... It might show.

It might be possible to do very limited slicing on a 32-bit micro-controller that is on a Smoothie, or a Due - but often the entire model needs to be analyzed/sliced before it can be consumed, due to little things like support being added, so for a large model it might run out of memory quick and take an hour or two, and might run out of the relatively tiny amount of RAM, and might run out of memory in the micro-controller's flash to hold the added program, plus it's regular motion control program, and won't be fast enough to run both at the same time. That might be no big deal, I guess. (But why would you ever want to slice in the controller, since you already have a PC with a processor that is maybe 20x faster, has much more memory, a hard drive, a screen, preview options, and a choice of any slicer you want? A big model takes like a second to slice in S3D.) But doing it in the controller is definitely not the real issue here, nor the solution.

For portable gcode: you will still have to have a nebulous "something" convert the "portable" gcode to customized instructions (err.. that would be gcode...) that will print well on any one particular printer.
We could call that "program" a "portable gcode converter". Since, as more than one of us has stated, you would have to tell that "gcode converter" EVERY SINGLE PARAMETERS THAT YOUR PRINTER NEEDS TO PRINT CORRECTLY (which you will only have once you have properly tuned both printing preferences and firmware USING YOUR REGULAR SLICER): you would end up with a "Gcode Slicer" (tm) with a spot for each of these settings ... which I guess you can just copy from your regular slicer for each kind of filament after the tuning... Handy! Every user would have to do that of course, as their printer/filament/hot end is different. The tuned settings are after all the only real issue... (oh... I guess that was mentioned above, so never mind!)

And then the portable gcode converter would have the added complexity of converting the portable gcode back into a 3D object (imprecisely) so it can completely re-slice the object (which it MUST do in order to generate the new paths), and add all those nicely tuned print settings for your printer (for layer height, extrusion width, speed, temps, printer specific overhang limits, etc.), and figure the correct extrusion amount for each segment. I guess it might take a bit longer to process...

Oh, you might want to consider how you will convince the slicer programmers, as a favor, to generate the "portable" gcode to start with, that can only ever be used with the portable gcode converter. Or maybe, as a favor of course, they could re-program their slicer to consume portable gcode, slice it, and output the normal gcode a printer needs, that would be handy! Perhaps after you have re-sliced it, you could even output it again as portable gcode!

Really tho, all kidding aside (well, maybe not), the program needed to consume/convert portable gcode would have all of the supposed "downsides" of a normal slicer, + less accuracy + added complexity. So the benefit to you and your friends/students or anyone else would be absolutely, completely zero.

In the real world: good luck having anyone write it, or use it.

But, oh well, after all... details... never mind...

BTW: someone here now has a working project for doing the motion control in the PC, and just playing something like motion frames in the controller. That is not magic in any way in this context, it just makes the obsolete 8-bit controllers able to just keep up with step generation, which is very nice. But maybe no printing from SD as the output is much larger.
Re: Interest in saving effort by sharing gcode?
September 14, 2016 03:13AM
Changes to both firmware and slicer required to make this work would be small. It's just a matter of moving a few gcodes from the slicer to the firmware to begin with.

Re-slicing gcode doesn't make sense to me. Why would you want that?

Temperatures for different filament types are a real issue. Manual adjustment, the way we already operate, would work as a start. It would be nice to enclose filament specifics in a memory chip on the filament spool. A filament force sensor might also help those who want to automate temperature settings.

I like the idea of including a bunch of variations in the gcode. Printer speed limits and size limits are already in firmware configuration.


blog
VDX
Re: Interest in saving effort by sharing gcode?
September 14, 2016 04:32AM
... I'm going a different route - I've made a heavy modified version of Pronterface for my paste-dispenser, which works with G-code, but can import and parse different data formats like HPGL, Gerber, SVG and 'common' G-code too.

So I've written some parser and "pre-converters", which reads a file and exchange/modify some of the elements to get it running.

This can be XYZ-coordinates, scaling/rotating - and adjusted E-values and other options too ...

Edited 1 time(s). Last edit at 09/14/2016 04:33AM by VDX.

Viktor
Re: Interest in saving effort by sharing gcode?
September 14, 2016 07:28AM
Nice, Pronterface hacking is a lot of fun =)

Would the pre-converters allow a designer to tell my RepRap how it should manufacture an object?

For example, "print with this face down, use 1 mm perimeters, at least 12% infill and 4 solid 0.25mm bottom layers" or similar. The kind of slicing instructions that often go into Thingiverse descriptions and read and written manually into people's personal ini-files.

In the case where your modified Pronterface was widely used, could this manual reading and writing be avoided?


blog
VDX
Re: Interest in saving effort by sharing gcode?
September 14, 2016 08:06AM
... it's more a sort of "niche solution" for a comercial paste-dispenser, actually extended for laser-engraving - you can see some of the actual posts here (in German):
[forums.reprap.org]

I've mentioned it here more as example for "recompiling" G-code to change it for special machine- or application-parameters ...


Viktor
Re: Interest in saving effort by sharing gcode?
September 14, 2016 08:43AM
Wow! Careful and well thought out post-processing of gcode can give developers fantastic flexibility, that's very true smiling smiley Nice work!


blog
Re: Interest in saving effort by sharing gcode?
September 15, 2016 09:48AM
Well...
Toben, you have ignored or do not grasp all of the technical details.
Maybe it's because I've been typing in English, or that I used some irony.
No one does you a favor however by shielding you from reality, so this is my final try (I must be a sucker for punishment).
I am really sorry to have to be blunt (again).

Quote
Toben
Changes to both firmware and slicer required to make this work would be small. It's just a matter of moving a few gcodes from the slicer to the firmware to begin with.

No. Very, very No. This shows you do not yet have a grasp of the technical issues that have been given to you plainly.

So here is a little research project for you:

Take a little time and write a simple program to modify some gcode for a simple object you have sliced - say for a printed sphere or a pyramid.
- Then for three consecutive layers, make the changes needed for a different layer height and/or extrusion width.
- And note, you will not be able to just move the individual segments in or out (X/Y), the size and shape of each loop and segment will be different. So new segments and loops will need to be generated, or removed.
- Entire layers may need to be created, or removed.
- Then output the new gcode to a new file for each layer.
- Then take that gcode and print it. How does it look?
- Too much or too little extrusion? Well, the amount extruded must be different - so you will have to go back and calculate, for each new segment, the proper extrusion amount. How much to use for gap fill?
- How about those new artifacts? Especially with more complex objects, the individual perimeters may not go all the way around the object. Well, interpolating tool paths is not the same as slicing a 3D object at a different layer height or extrusion width, so there will be artifacts. Did you know this?

If you don't have the needed programming skills, you could just write out the logic (along with the math), and have a friend code it for you.

Quote
Toben
Re-slicing gcode doesn't make sense to me. Why would you want that?

Of course you would not ever want to do that. Sigh. I would never suggest that it should be done. However, since (in order to print properly) all printers print with different extrusion widths and layer heights, the so called "portable" gocde (tool paths) would have to be re-converted back into a 3D object in order for the new tool paths to be generated (a slicing process). Do you understand this? If you do not grasp this basic concept, then really - do the above exercise!. If you do not fully understand it, there is really no hope.

Do you understand why others will not be able to use your toolpaths as-is? This is part of why default slicer settings almost never work well.

Quote
Toben
Temperatures for different filament types are a real issue. Manual adjustment, the way we already operate, would work as a start. It would be nice to enclose filament specifics in a memory chip on the filament spool. A filament force sensor might also help those who want to automate temperature settings.

Actually no, you have picked the easiest thing to set (the temperature setting) and made it out to be the hardest, and then over complicated the solution with chips and chip readers.


Quote
Toben
I like the idea of including a bunch of variations in the gcode. Printer speed limits and size limits are already in firmware configuration.

Sigh. Once again I do not think anyone suggests this as a good idea, but what you might do - the variations would be: all possible tool paths - based on other uses required or desired layer heights and extrusion widths (very impractical) - in order to not have to convert back to a 3-D object (imprecisely) and re-slice. Neither option is good! Gcode is tool paths, not a 3D object. Do you understand this?

I do wish you luck on your endeavors, but I am not confident now.

SO, I am inventing a new word: rewasted. Here, I will use it in a sentence:
I wasted my time posting the first time, and now I've just rewasted it again. Or:
Man, I'm totally rewasted!

Edited 1 time(s). Last edit at 09/15/2016 09:49AM by Paul Wanamaker.

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!
Re: Interest in saving effort by sharing gcode?
September 15, 2016 11:09AM
Changing gcode after it has been sliced once doesn't seem rational to me, unless your machine has very special needs. Why not just slice the 3d model instead? Portable gcode won't make either stls or slicers go away...

Most people own 0.4 mm and/or 0.5 mm nozzles, so I think you under-estimate the potential portability of tool paths.


blog
Re: Interest in saving effort by sharing gcode?
September 15, 2016 12:37PM
A portable slicer is fine, helpfull so you dont need to install an app, a g-code viewer /interpreter might be something handy? But surely a gcode file is pretty portable probably fit quite a few on a stick(i get it wont be machine agnostic), its bad enough dl'ing models someone else has made, with zero input, then to want a magic gcode file ontop or instead of sounds plain lazy. One of the main reasons I got into 3D printing was to eventually learn/use some gcode cnc stuff.

Edited 2 time(s). Last edit at 09/15/2016 01:25PM by MechaBits.
Re: Interest in saving effort by sharing gcode?
September 15, 2016 02:00PM
Yup, portable gcode would be for the lazy and those designers with detailed fabrication instructions. winking smiley

I kind of envy designer that get to assume full STEP-NC support. Also the programmers that get to work on STEP-NC support in slicers and firmware are quite lucky. I have a Master's in engineering physics, specialized on scientific computing in C and some experience with firmware hacking for my Hangprinter. I'd love to serve the lazy and the nitpick-designers if there is interest here?


blog
Re: Interest in saving effort by sharing gcode?
September 15, 2016 02:18PM
What's really needed is *neither* gcode nor stl.

We need the same kind of thing to happen in 3D printing... a top-level language to describe an object in 3D, including colour, texture, shape, materials, etc. And another language to describe how to print that object.

Gcode after all was designed for CNC machines, and nowadays doesn't meet the requirements of 3D printing very well. Similarly, STL is designed to represent single-colour meshes and isn't ideal for 3D printing.

It's like the "Good Old Days" (TM) of the 1980s, when documents were represented as ASCII text with embedded formatting commands. And you had another, somewhat similar, language (remember HP PCL anyone?) to talk to your Laserjet. Sure, you could do non-monospaced fonts, and word-wrapping worked, and tables were possible. But, it was tricky and unreliable. Embedding images in the document was a black art and kludges. As things evolved, the data model resembled reality less and less. MSWord fixed that, and became the de facto standard.
Re: Interest in saving effort by sharing gcode?
September 15, 2016 03:21PM
Quote
frankvdh
...Gcode after all was designed for CNC machines, and nowadays doesn't meet the requirements of 3D printing very well...

How exactly does gcode not serve 3d printing well? I cannot think of a single limitation.
Re: Interest in saving effort by sharing gcode?
September 15, 2016 05:06PM
Agree about need for good top-level languages for objects and how to manufacture them. I'm suggesting improved (but still sub-optimal) gcode as a compromise to save in on required work hours. If lots of interest build up around changing stl and gcode for something better entirely then count me in on that project =)

Gcode has some fundamental limitations. Gcode files are ASCII-encoded, and therefore big (ASCII is transparent and handy, but sometimes you just need a smaller file). Gcode doesn't allow one to express allowed tolerances (marking important parts would let us speed up the rest). Gcode files are also large because curves need to be chopped into line segments. A better format would let us express curved paths as splines or Bezier curves, or maybe even as functions from t to (x, y). cool smiley

Still, I think the worst thing with gcode (or the way RepRaps use gcode) is that it is mildly machine specific. This means designers can't use it to specify how their object is intended to be manufactured, and we who like slicing can not let others leverage on our slicing work.

Edited 1 time(s). Last edit at 09/15/2016 05:07PM by tobben.

blog
Re: Interest in saving effort by sharing gcode?
September 15, 2016 06:57PM
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.
Re: Interest in saving effort by sharing gcode?
September 16, 2016 02:14AM
Cool Cable printer...results are a little ropeywinking smiley though, & slow, I've seen some very fast cablebots,
I understand your idea for a suite of tools & an OS pre installed to a thumbdrive to function as class or off the shelf production factory,
I kinda did the same with my BeatSkool (10 years ago) I stopped short of a VM because it can be slow. and getting graphics card to work on the pass through is not an easy thing to do, but didn't take it quite as far as to write a thesis I dont have that formal training, so I can see your not the lazy type, and have a good reason for wanting another solution, I dont have programming skills so wouldnt say it cant be done, those clever people can do almost anything they set their mind to, the above suggestion sounds like a good idea, something new might be needed.

Perhaps if the Printers where more intelligent, they could skim through the commands they understand, a lookup table for the nozzle/filament size, ((bed placement/dim's) ignoring all the other code for alternate nozzles & paths, that didnt fit with the printers own config file
(or scale things on the fly, it's all relative).
But it sounds like the file would be huge, imagine it set for 100 permutations and you only need1% of the code...
If you wanted to encourage the spread of the VM Disc or Thumb, you could make it one of the first things they should do with the stick
Receive / Copy, that way you could have maybe 2 startups on the VM one which cant be changed and one that can, that way they could tailor things to their machines or way of doing it

"Shit just happens sometimes and when it happens we better know how to produce our stuff ourselves."

Did this line make it into the thesissmiling smiley

Edited 4 time(s). Last edit at 09/16/2016 11:27AM by MechaBits.
Sorry, only registered users may post in this forum.

Click here to login