2-axes delta style +1 axis cartesian style repstrap---need help with firmware

Hi everyone , i'm new in the RepRap community and after some "voyeurism" would like to actively take part in it, so i've decided to start working on my own project .I apologise if the following post will be too long so leave now if you have not patience or time .
Being without a work i couldn't really afford a premade kit and still buying online all the different parts would be too much expensive for me so i'm going to use the things i can buy on the territory trying to get the best of what i find, and inspiring to all the beautiful projects most of you guys ideated and using some of my engineering student knowledge i tried to take the features of every project which had the best result over price ratio.
So i tried to remove all the expensive parts switching them to something good enough to do the work but not as-like expensive.
The resulting project was a blend between a delta setup (in x-z plane) and a cartesian printer (in y plane). I attached a render of the project for a more clear understanding.
This should have a square aluminum extrusions frame linked by plastic 2/3-ways 90° joints that can be easilly found in bricolage stores as the bearing drawers slides that it should use as linear slides (i must say this is actually only an idea, will have to verify the possibility to use these). Motion of the extruder in the x-z plane would be provided by aluminum round extrusion with flat eyelet screws on both ends (so without the need of traxxas) while motion on the y plane would be provided by the moving bottom sled . All the moving parts would be driven using spectra lines and the usual Nema-17 + Ramps 1.4+Arduino.
All these cuts should lower the price around 200-300 Euros (maybe less) using clone electronics and chinese motors found on Aliexpress.
Here comes the problem and why i wrote this post in the Firmware section: actually all the firmwares i have seen (Marlin as first) support Delta or Cartesian setups but there isn't a way to easily configure them to work with my setup without changing some code ,which unfortunately i'm not able to do, i'm barely able to understand some of the code but wouldn't know how to put the hands to make a coordinates change like that would be needed to do.
So if someone is able and willing to help i would be grateful and since my project looks cheaper than many other (but still i don't know if it can be as good) i think some other low-budget repraps lover would do the same

Excellent idea!

I think there's no way around substantial firmware hacking, though.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hey! Nice to see such experiments!

I'm the developer of my APrinter firmware, and I've recently added experimental delta support. Well, that may not seem useful to you, but really it is! That's because my firmware is designed for arbitrary coordinate transforms, and it is almost trivial to define your own coordinate transform by making a custom transform class and defining some functions!

See the existing DeltaTransform and IdentityTransform classes. The latter is just a dummy for testing the implementation when you don't actually have a delta, like me.

If you're unsure of how to implement your transform here, I'd be happy to adapt the DeltaTransform to your custom coordinate system. Note however that I don't think AVR based boards are fast enough for my firmware; I have to recommend Arduino Due with RAMPS-FD or RADDS if you use a coordinate transform with APrinter.

Edited 1 time(s). Last edit at 01/05/2014 10:26AM by ambrop7.

Thanks for your answer! Your firmware would be exactly what i'm searching for and easily supporting coordinate transforms in external classes would really be a time saver for all the non classic setups.
From what i read on github your firmware has been tested on atmega2560+ramps 1.4, which would be exactly the configuration my printer would run on; is it having problems with them?

Zazza, my firmware does indeed work on atmega2560+ramps1.4, but the coordinate transform requires additional processing (transforming coordinates and splitting segments). It might be too much on AVR. But I'll test soon and maybe try some optimizations, who knows, it might just work all right.

Edited 1 time(s). Last edit at 01/05/2014 03:57PM by ambrop7.

It would also be of some benefit if you had a setup with an SD card (SD-RAMPS). Not only is printing from SD card more efficient than printing from serial as is (in different ways, less processing and no waiting for "ok"), but I've also recently implemented a custom gcode packing format which speeds up calculations by an additional 15%. It might just make the difference in your case See: [forums.reprap.org]

Zazza, I suppose you're aiming for a single extruder? If that's the case, it makes a world of difference, and I haven't really taught about it before because I only deal with my double extruder printer It uses less RAM and needs less computation, and then because it uses less RAM we can increase the buffer sizes to make planning more efficient as well as allow more lookahead. When dealing with nonlinear transformations a large lookahead is essential, if there isn't enough, speed will be artificially limited. Note that in my firmware, lookahead only costs RAM not CPU time, on average, and atmega2560 is a bit lacking in that respect.

Edited 2 time(s). Last edit at 01/05/2014 05:30PM by ambrop7.

Yes this will be a cheap project, so will only have one extruder. About the coordinate transforms, if it works with mega+ramps on any delta it should most prolly work in this setup since the transforms are pretty much the same (or easier) on two axis and linear on the third.
It u call "u" and "v" the coordinates of the two vertical slides of the printer from bottom to top and "w" the horizontal one and call "x","y","z" the absolute input coordinates of the center of the extruder support, the transformation formulas should be these (if i made my homeworks right ) :

u=z+sqrt(a^2-(x-(b/2))^2)
v=z+sqrt(a^2-(c-x-(b/2))^2)
w=y
, where "a" is the lenght of a pushrod from hole to hole , "b" is the extruder support lenght (aka the distance from one pushrod joint to the opposite one) and "c" is the distance from a vertical slide to the other.

So I've implemented this in APrinter, see: [github.com]

Yes, I believe your equations are right, I did the same.

I was "testing" this on my cartesian printer, it does make funny curves. Concerning performance, I've measured that the calculations with this half-delta with single extruder are about 28% slower than my current cartesian setup with dual extruders. So I believe this is still useful, and I may be able to cut it down a bit.

> About the coordinate transforms, if it works with mega+ramps on any delta it should most prolly work in this setup since the transforms are pretty much the same (or easier) on two axis and linear on the third.
My firmware is a bit less efficient than Marlin and others due a different internal design. This is basically two things. First, it steps all axes independently instead of restricting step signals of other axes to happening at the same time as the fastest moving axis. Second, it uses twice as much memory for lookahead to ensure that a consistent plan is followed even in case of underflow. In particular, planning builds a new plan and then tries to atomically swap it with the old plan in the live buffer.

Edited 1 time(s). Last edit at 01/05/2014 08:25PM by ambrop7.

Awesome! I will try it as soon as my setup is ready, in the meantime i will keep an eye on your github for further optimizations .