Why big g-code files for replicated items?  

RE: Why big g-code files for replicated items?

Because gcode isn't a programmatic language: gcode is a linear set of instructions a machine follows.

Think of it another way: gcode does not allow variables.

RE: Why big g-code files for replicated items?

@tim-m30 has got it. Most 3D printers (our beloved Mk3 included) are profoundly stupid. The name "gcode" is a bit misleading. Gcode does not provide  conditionals, branching or variables. Any and all actual calculation is done in your slicer. It literally has to tell the printer explicitly how to make every move or setting. 

RE: Why big g-code files for replicated items?

Expanding on the topic a bit: gcode was developed as a common control language for CNC and similar machines, using simple interfaces like RS-232 serial.  At the time, compute horsepower was hard to come by. Motor controllers were extremely simple. And the calculations to control the location of a fixed tool in free space was expensive in time and compute horsepower.  An FDM printer isn't a robotic arm, but gcode is used for both. Moving a tool around a three dimensional part that has protrusions is complex, and the cpu in our printers can't handle that type of math in real time, nor can cpus in most CNC machines. So the work is left to devices that have the capability and not done in real time.  

RE: Why big g-code files for replicated items?

decades ago i  worked on automated PCB drilling systems and wire-wrapping systems , both used G code without any computing system at the machine at all , just up-down counters and comparators that drove stepper motors till x and y matched then triggered a z cycle

RE: Why big g-code files for replicated items?

Decades ago, I worked on telephones, where an operator had to answer a winking eyeball by sticking a plug on a cord into an associated hole, and ask the caller where they wanted to be connected to...    Now phones have more computational power than the computer that took man to the moon!

RE: Why big g-code files for replicated items?

Mind you, a Raspberry Pi, probably has more computational power than a Nasa Space probe used to have

Joan

RE: Why big g-code files for replicated items?

Thanks for the explanations.

G92, set current position, could be used to effectively relocate the x,y axes to the desired new center, and code previously used to print an object could then be rerun to print the next one.  That solves the passing arguments problem in this case, but it doesn't solve the subroutine call/return issue.  grrr.

Anyway, thanks for the explanations.

RE: Why big g-code files for replicated items?

Posted by: @gary-a2

G92, set current position, could be used to effectively relocate the x,y axes to the desired new center, and code previously used to print an object could then be rerun to print the next one.  That solves the passing arguments problem in this case, but it doesn't solve the subroutine call/return issue.  grrr.

Theoretically, you could slice a part using all relative moves, then run a script on a host computer to reposition and send that same gcode, but it's probably not worth the effort for the results and so far as the printer is concerned, there's no real difference.

I did once write a "minification" script to remove comments from gcode and it made quite a difference in file size. I didn't notice any print time or effect improvement. There's a packed binary gcode format, but from what I've found with quick searching, Marlin can't use it.

In this age where "small" files seem to be 100MB+, I supposed it's just not a big priority.

RE: Why big g-code files for replicated items?

32GB == three hundred twenty (320) 100MB files, right?   If each file take 8 hours to print, that's a few days of printing.

ps: the vise base I am printing is only 55MB, and requires 29 hours, so my estimate may be a bit optimistic... lol.

RE: Why big g-code files for replicated items?

Posted by: @tim-m30

32GB == three hundred twenty (320) 100MB files, right?   If each file take 8 hours to print, that's a few days of printing.

ps: the vise base I am printing is only 55MB, and requires 29 hours, so my estimate may be a bit optimistic... lol.

Nice looking vise.  What size nozzle are you using?  If 0.4mm, have you tried speeding that up with a bigger nozzle?  It looks like the x,y detail isn't that fine, and it would save a lot of time.  I had to go from a 0.4 to 0.25mm nozzle for the fiber tips I'm making now because of x,y detail (tiny holes, 2mm radius curves, etc), and it doubled the print time.  Layer height went from 0.2 to 0.15 as well, only because there isn't a pre-configured 0.25 nozzle config with a 0.2mm layer height.  The layer height decrease would account for some of the change, but only about a third of it.

RE: Why big g-code files for replicated items?

Thanks - someone else's design, Yet_ANOTHER_Machine_Vise on Thingy

Slowness is the infill selected: 35% hexagonal.  The gear mesh seems a bit loose and seemed to have a tendency to skip as I was assembling this first one, so I doubt I needed to make the base that strong. 0.15 layers needed to get the screws right.  And my best reason for 0.4 mm nozzles: I am lazy and hate changing things unless absolutely necessary.  The old 'don't fix what isn't broken' mantra.

RE: Why big g-code files for replicated items?

Posted by: @tim-m30

32GB == three hundred twenty (320) 100MB files, right?   If each file take 8 hours to print, that's a few days of printing.

ps: the vise base I am printing is only 55MB, and requires 29 hours, so my estimate may be a bit optimistic... lol.

Hey, who told you about that model?!? It was supposed to be a secret!!! ... Oh... That was me on another thread... wasn't it... oops... 😉

Nice looking print. I like your color choices. One of the best things about that model (IMHO), especially for those of us who are a little green in laying out mechanical items for FFF printing is the YouTube video linked in the model's description over on Thingiverse. The designer goes through the decision made for avoiding the strength pit-falls of FFF printing. Definitely a well done tutorial.