Post processing G code for experimental X-Y setup?

Having recently built my first repstrap based on a Prusa Mendel i2, I am now keen to explore an alternative arrangement for X and Y axes that will hopefully offer some advantages over the original. This experiment will involve radically different equations for the X and Y movement.

One approach I am considering is to retain my entire existing reprap and just mount the alternative bed on top of it's bed. I will loose some Z capacity but it will be fine to test the concept. Doing it this way, I would only need to buy two more steppers and simply swap the connections on the RAMPS for X and Y to do the testing (possibly using 4 way switches). It would avoid the need to duplicate the rest of the hardware and I could readily revert to the original configuration as needed.

My question is - what is the best approach for coding?: customising the firmware or post processing the G-code? My new X-Y scheme will be computationally intensive so it may be a stretch to process it on Arduino in firmware. I haven't even looked at what would be involved in changing the firmware so forgive me if this sounds daft. Post processing the G-Code would allow me to revert to the PM i2 without having to also revert the firmware. I am leaning towards post processing G code so that the firmware can remain unchanged. Any thoughts and guidance would be appreciated.

Neil

Edited 1 time(s). Last edit at 01/22/2014 04:05AM by n.glasson.

If its going to be computational, then I agree it should not run on the arduino (the firmware actually runs on the arduino, not on the RAMPS ).

Anything run on the arduino is done in real time as you are printing. G code post processing is done ahead of time. If you have a choice of which way to go, I'd lot for the latter.

Depends on how much. Delta bot translation has been done on RAMPS, it involves one trigonometric functions and segmenting a G1 into hundreds of line segments, so you get the idea.
You could as well find all the #define DELTA and swap out the functions.

Or get one of the ARM based controllers, then it will be no problem to do the transformations in the firmware. My APrinter firmware runs on quite a few ARM based boards (Arduino Due, 4pi, Teensy 3), and it supports custom transforms.