extreme concave delta printer

On my scaled up delta printer I am working on no matter how much I change the delta radius I cant get the printer to move linearly. I have disabled all min and max limits, I've tried with or without. I have spent a whole day just tinkering with things, and in vein. with all the variables set at what they are measured at, it moves the correct distance, but with a really extreme concave parabola. I added my config file, thanks for the help in advance.

Do you have a delta radius parameter stored in eeprom that is overriding the value in your config file?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Do you use G0 for travel or G1 ? - should be using G1, as G0 is uncoordinated.....

Quote
Sir_Death
Do you use G0 for travel or G1 ? - should be using G1, as G0 is uncoordinated.....

Can't believe that one...
G0 is often used in Gcodes. This would lead to crashed nozzles or kicked off parts everytime. Marlin developers are not that stupid
-Olaf

Quote
Sir_Death
Do you use G0 for travel or G1 ? - should be using G1, as G0 is uncoordinated.....

From the RepRapWiki:

G0 & G1: Move
G0 : Rapid linear Move
G1 : Linear Move

I don't know what an "uncoordinated" move would be. "Relative" (to last position) and "absolute" (relative to origin) are toggled via G91 and G90, respectively.

Edited 1 time(s). Last edit at 11/23/2015 09:44AM by grat.

An uncoordinated move is one where each axis is moved at top speed to the position required. This means, on a cartesian, that the Z will move much slower, and the x/y either the same, or at different speeds depending on the moving bed situation.

On a delta (and likely other motion systems) this causes each axis to move without regard for where the nozzle should travel through during its move. Instead of each carriage slowing down or speeding up to accommodate the required motion, the mechanics just head straight for the end positions.

In Marlin and Repetier, I'm pretty sure the moves are uncoordinated with g0, but I'm not positive. On RRF, at least in the dc42 fork, this is not the case and both commands initiate the same sequence.

I am just jog-ing the axis in pronterface. If I change the delta radius it makes the printer head move the incorrect distance, the effect it has on the parabola is negligible. I'll try using G1 tommorrow.


EDIT: ok, It still moves in the parbola shape if I use G1. Maybe I got osmthing messed up in the firmware, should I switch to repetier?

Edited 2 time(s). Last edit at 11/24/2015 10:26AM by teslalab2.

Quote
teslalab2
I am just jog-ing the axis in pronterface. If I change the delta radius it makes the printer head move the incorrect distance, the effect it has on the parabola is negligible. I'll try using G1 tommorrow.


EDIT: ok, It still moves in the parbola shape if I use G1. Maybe I got osmthing messed up in the firmware, should I switch to repetier?

Did you ever check dc42's suggestion?

You wrote that you scaled the delta up ( by yourself I assume ).
Did you build the rods all the same length and do they run parallel from carrier to effector?
-Olaf

Sorry I didn't update this sooner. I get the herp derp award of the year. what happened is: I set it to home to minimum and then inverted the motors so that it moves the direction you would expect. effectively making the theoretical printer shape as shown below. By simply assigning the max endstops to the min endstop pin It solved the problem. Thank you for the help. All of the diagonal rods and the top and bottom of the printer have been machine down to the thousands of an inch. It seems to be working quite well now, Thanks for all you help!