Having an intermediate file between slicing and building

Zach has proposed, and I think it's a good idea, that we have the Java STL slice code write a RepRap-machine control file (probably in G-codes). We then have a short separate program to read that and send it to the machine. We also allow it to be read into the simulator, so we can see what it will do.

Advantages:

If the slice code throws a wobbly, it doesn't ruin the build.

No time delays while slices are computed.

Puts an extra level of indirection in the system. This allows other software to intervene, or to generate etc.

Thoughts and comments?

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

I like this idea. You'd basically be compiling the model into machine code before building it.

I'd expect that, in addition to the above advantages, you'd also be able to run the actual build on a much simpler machine. For example, you could have a fairly hefty desktop machine compile a set of models to machine code, then distribute the compiled code to one or more smaller machines (e.g. sub-notebooks or microcontrollers) which in turn control RepRaps. Since the compilation would take much less time than the build, this would free up the desktop machine for other purposes.

it also lends itself to cool things such as a RepRap print queue, etc.

Definitely gets my vote

---

Ian
[www.bitsfrombytes.com]

Yes, I can't see any disadvantages unless you went to a process where feedback from the object under construction affected the machines actions.

I would also recode the S&D part in C++ as that is still platform independent but fast. GUI could stay in Java to take advantage of the platform independent GUI ability.

---

[www.hydraraptor.blogspot.com]

... i'd like the ability to use my CNC-mill for paste-extruding, so i'll have the same hardware for subtractive or additive fabbing ...

Viktor

An idea about the RepRap print queue. I am currently attempting to design an arduino-driven mini computer that would read .txt files from a flash drive. This way, you print to gcode, and the plug in a flash drive with the gcode information stored on a .txt, and viola, you begin printing.

I was thinking that there could be a marker at the beginning of the text files that would essenitally be a 'print' or 'no-print' and then maybe even an iteration counter. This way, one would be able to have a flash drive that contained all of the prints needed for reproducing a reprap, without any need for all of the fiddling around with muggy computers.

Just a thought

---

Jay

I agree that an intermediate file is a good idea and that is how Export Slices at:
[members.axion.net]

works. It is a Art of Illusion script that can slice and dice all the Darwin parts and turn them into gcode. It takes roughly ten hours to slice and dice all the Darwin parts and that time will increase a bit as I add more features to the script

To use it, put the file into the Art of Illusion tools folder in the scripts folder. Then turn your shape into a triangle mesh, select it and choose Export Slices from the Scripts menu in the Tools folder.

Below is an excerpt of gcode for the minimug including all the gcode commands that Export Slices outputs.

Cheers,
Enrique


( Extruder Initialization )
M100 P210
M103
M104 P145.0
M105
M106
G21
G90
G28
( Extruder Movement )
( Extruder paths for layer 0 of Minimug )
G1 X9.195 Y-6.592 Z0.4 F600.0
M101
G1 X5.972 Y-9.609 Z0.4 F600.0
..
( about a thousand lines of movement )
..
G1 X8.602 Y-9.077 Z19.6 F600.0
M103
( Extruder Shut Down )
M103
M104 P0
M107

I like this idea because it'll allow a driver to be written for the OLPC, and we want RepRaps to follow OLPCs around the world.

The OLPC can't run Java. It runs python though. A simplified interface would then be able to show the plot, or at least spool the file to a RepRap.

Also, there is something seductive about having a RepRap that can stream build instructions directly off an SD card!

Vik :v)

Hi

Certainly gets my vote

---

Regards

Ian

Hi

If there is an intermediate file I presume the programme that spools the data to the machine will still use the preferences file or something similar. I assume it will also have a means of homing.

Can I suggest that the Z home uses the other switch as far away from the table as possible and the actual table surface to home distance is stored in the preferences as an offset from the switch. I find the current method counter intuitive. When I run my machine as a CNC I home at the top.

I would like to jog the extruder down to the Z0 position hit a key (optionally select extruder number) and have the current position stored in the preferences as the offset. Very quick, easy to use multiple extruders with maybe different lengths and easy to accommodate different thickness of base plates.

---

Regards

Ian

Ian

The way I see it, the current dual arduino setup with Gcode applied would have more than enough room to store the preferences for the printer heads. The switch/homing stuff I cannot help you with, except for maybe just simply plugging in the opto switches into the wrong side, and/or (some combination) running the stage in reverse.

---

Jay

I think we might go for G-code instructions and a preferences file plus anything else that's needed wrapped up in XML and compressed. The preferences file is slightly problematic as it's individual to a machine; maybe have one with fewer entries in that need to overwrite the machine's local defaults?

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

Makes sense. This is the approach that most CNC machines take, almost always using different programs and generally different computers as well to generate the "compiled" G-code vs actually executing it. This is a proven and modular approach. I like it.

How much would the target machine's attributes affect the slicing process? For example, two nearly identical target machines have extrusion diameter of 0.6mm and 0.5mm. Wouldn't the compiled file for the first one contain fewer slices?

degroof Wrote:
-------------------------------------------------------
> How much would the target machine's attributes
> affect the slicing process? For example, two
> nearly identical target machines have extrusion
> diameter of 0.6mm and 0.5mm. Wouldn't the compiled
> file for the first one contain fewer slices?


Of course, the easiest approach is to standardize all machines, and that's what I would recommend for Darwin V1. Just say "Each extruder shalt have a filament diameter of .5mm, and .5mm shalt be the diameter of the filament extruded (amen)." Do a similar thing for support material. If someone wants to make a super-precise .05mm-filament extruding machine with mega-accuracy, that's great, but it's not supported by the official project and they'll have to hack their own host software. While this is not optimal, I also don't think it's practical to try to foresee what options people will be looking for in their machines this early in the game.

However, again drawing from the CNC milling model, which I think is a good one, there could be some basic "tools" that you can define in the program that are then available for use. For example, you describe a particular endmill to your CAM program with its diameter, feed rate, whether it can plunge cut or not, etc. I don't think it would be too difficult to do a similar sort of thing with the RepRap project - set a preference file for the extrusion diameter, material, layer height and optimal extrusion speed for each available printhead, and let the host software figure out what to do with them. Like I said before though, this is something I would definitely wait on attempting until at least 2.0.

Steve wrote:
"How much would the target machine's attributes affect the slicing process? For example, two nearly identical target machines have extrusion diameter of 0.6mm and 0.5mm. Wouldn't the compiled file for the first one contain fewer slices?"

Yup, the compiled file for the 0.6mm machine has fewer slices than for the 0.5mm machine and it takes less time to generate. On my 4000 bogomips system, the time to slice and gcode file size for the minimug at different diameters follows:

It took 420 seconds to slice and dice Minimug with a layer thickness of 0.8 mm.
The size of the gcode file is 52 KB.
The size of the zipped gcode file is 9 K.
There are 1,814 lines in the gcode file.

It took 2,680 seconds to slice and dice Minimug with a layer thickness of 0.6 mm.
The size of the gcode file is 216 KB.
The size of the zipped gcode file is 41 K.
There are 7,268 lines in the gcode file.

It took 4,562 seconds to slice and dice Minimug with a layer thickness of 0.5 mm.
The size of the gcode file is 295 KB.
The size of the zipped gcode file is 54 K.
There are 9,536 lines in the gcode file.

There is a big change when going from 0.8mm to 0.6mm, because when the extrusion diameter is 0.6mm; Threadforge at:
[members.axion.net]

the script formerly known as Export Slices, can shove in a filament between the inner and outer surfaces of the hollow cyclinder part of the Minimug. Adding in just one thread means you have to draw all the fill for that layer.

Slicing all of Darwin takes roughly one hundred times longer than for the minimug.

Kyle wrote:
"For example, you describe a particular endmill to your CAM program with its diameter, feed rate, whether it can plunge cut or not, etc."

The threadforge script has default settings for layer thickness, infill ratio, etc.., which you can change and which are saved to threadforge_preferences_client.csv in your home directory.

Cheers,
Enrique