opinions/ideas for using pstoedit gcode?

Hi all,

I'm still in the land of 2D - using some of the repRap gcode routines to drive art drawing + painting machines. I'm trying to get my content generation tool chain more worked out, so I will end up with gcode that the repRap parser will read - whether coming from .ps, .svg, dxf etc. I've been testing pstoedit - and it seems very full featured but it's gcode conversion format (at least from eye balling it) is not readable by the repRap parser. It uses variables for scale factors rather than precomputing everything.

 G01 X[#1003*345.287] Y[#1004*222.486]
 G01 X[#1003*343.693] Y[#1004*210.76]
 G01 X[#1003*341.091] Y[#1004*199.36]

I'm thinking this issue/question of using pstoedit has likely come up before so I'm wondering what you all think of it. I've looked at the pstoedit src and can see maybe editing it to export hard numbers. Or writing a new gcode parser for my project that can handle that format Or maybe I've got the whole thing wrong?

Anyone been down this road before?

--Roy

Hi Roy,

... i've programmed some format converters in past, what's pretty easy when you have ASCII sources.

Actually i have several tool-chains with the correct output for my CNC or for CAD/CAM programs for optimizing, so no need for tweaking ... but it wouldn't be a problem to switch a parser or optimizer inbetween ...

Best way will be a script reading an entire line or defined line-sequence until a delimiter or buffer-counter, then calculate the values and output linewise the correct G-code ... here you can add some routines for adjusting 'standard coordinates' to your special machine or tools too ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]