First 3D Printer Build

[aerouta]

Do you still have the same pattern of thin by the Y tower?

yes I do.


Why bother with checking the z height at (0,0,0). It does not seem like this value is independent of the x,y,z rails? Or am I missing something.

Because there are 2 parts to calibration, the first ensures that any circle around the center of the bed is colinear with the bed, the second involves changing the DELTA_RADIUS value in the firmware to remove any doming of the motion. The doming can be quite significant.

Quick question when you calibrate do you always visit the 3 corner positions in the same order, if you visit them in the opposite order do you get the same values?

Well, I have not kept track of the order. But I'm sure I have done both.

Someone mentioned the glass plate. I rotated the glass plate and got the same results, i.e. glass seems fine.

Polygonhell, if you could explain what you are saying further it would be helpful. Also, you mentioned collinear but is the issue here not coplanarity? But here is what I understand, and I could be wrong. 3 points make a plane, 4 points is overdetermined or over constrained. The calibration steps say to adjust the z_home and screws for (0,0). And then it says to go to the 3 towers and adjust it's respective screw to match the results at (0,0). But in reality, making adjustments to any screw changes the height at (0,0). It may be small but it changes. The change becomes more significant if you need to adjust more than one tower in the same direction. If this is the case, would it not make more sense to first adjust the 3 towers and then verify at (0,0).

You mentioned doming and DELTA_RADIUS. This is the first time I am hearing of both of these terms. Can you unpack these concepts some more?

[Polygonhell]

Sorry I meant coplanar not colinear, obviously I was very 2D last night.
Basically on a Rostock like design motion is not linear, since move requests are linear the firmware corrects for this, but it depends on having an accurate model of the geometry. The only dimensions that actually matter are the length of the arms and planar distance between the pivot points when the platform is in the middle, the later is referred to in the firmware as DELTA_RADIUS, if it's off even by fractions of a millimeter it introduces doming into the motion (either up or down). Given the manufacturing and assembly tolerances, any effective calibration has to modify it.

I would recommend following this setup guide, rather than the one in the manual http://minow.blogspot.com.au/ there is some discussion on the board and a more or less equivalent calibration guide here http://forum.seemecnc.com/viewtopic.php ... DIUS#p5692 .

Initially setting Z at 0,0,0 at irrelevant, since you have to set it a the very end anyway, all it does is get you in the ballpark.

[aerouta]

Sorry I meant coplanar not colinear, obviously I was very 2D last night.
Basically on a Rostock like design motion is not linear, since move requests are linear the firmware corrects for this, but it depends on having an accurate model of the geometry. The only dimensions that actually matter are the length of the arms and planar distance between the pivot points when the platform is in the middle, the later is referred to in the firmware as DELTA_RADIUS, if it's off even by fractions of a millimeter it introduces doming into the motion (either up or down). Given the manufacturing and assembly tolerances, any effective calibration has to modify it.

I would recommend following this setup guide, rather than the one in the manual http://minow.blogspot.com.au/ there is some discussion on the board and a more or less equivalent calibration guide here http://forum.seemecnc.com/viewtopic.php ... DIUS#p5692 .

Initially setting Z at 0,0,0 at irrelevant, since you have to set it a the very end anyway, all it does is get you in the ballpark.

Thanks for the info!!! Following the procedures in the link now.

[aerouta]

So I have noticed that ever so often when I home in my axis I get this pulsation in all the axis. It seems to follow any high speed commands. But it is not very repeatable. I have included a video that captures this.

http://youtu.be/9tU5tS7eo2k

Any clue what this is?

[Polygonhell]

Assuming you don't hear the steppers missing when it happens and assuming you are probably running Marlin firmware though mine never did it that badly (usually only one or 2 pauses when homing) it's a side effect of Johan's hack to get the rostock geometry working in Marlin.

What I think it is and it's hard to know for sure..
When you give a linear move to the firmware, that translates to a quadratic move by the carriages, the firmware doesn't handle this natively and there is a hack on the frontend where it breaks the motion down into a large number of linear segments this floods the planning buffer and I think under some fairly repeatable conditions the motion interrupts interplay with the large number of small segments being pushed into the planner causes the motion to run faster than the planner or the motion buffer to starve resulting in the pauses you see.
The 16MHz ATMega on the RAMBO board isn't exactly the fastest uController in the world.
Repetier will also do it, but much less frequently and I've neer seen it while homing

[aerouta]

That makes sense, and I guess since I am running on 115200 baudrate it doesn't help.

Bed leveling is getting better. I really think my x rail is slipping or something but not sure how to show it or nail it down.

[aerouta]

did a quick reprint. did not make any changes just homed the axis and printed
Checking for consistence.

Printed another that looked just like this.

As anyone printed something like this before to check the flatness of the bed. I am interested in seeing some other results.

[Polygonhell]

Honestly that last one doesn't look very far off o me, I'd say in general your 0 is a little high, possibly a little higher on the outside than the inside but I don't notice any gross errors.
If you're having issues with repeatability of the endstops, move the switches so that the screw head hits closer to the button.

[aerouta]

Took a break from the neverending leveling process and removed the delta arms for some sanding. While the arms were off I decided it would be a good time to install some LCD lights and the LCD. I installed some lights in the base as well but I forgot to take a picture of those.

[aerouta]

Ok back to leveling. Yesterday I was experiencing an issue with changing the XYZ tower heights in the config file and eeprom. I wanted to avoid using to screws for now since I now have the LCD installed and it allows for 0.01 increments. However, the printer seemed to be ignoring changes made to “X,Y,Z_MAX_LENGTH”.

I would go down to the print bed to determine the offset value, say... 1.5mm. Make the needed changes to the parameter (adjust by 1.5mm) and recompile.
Then recheck the height at the column and the same offset value is shown (1.5mm). I repeated this several times and no changes where reflected in the printer. I tried this both by recompling with eeprom off and making the changes using M206. When I used M206 commands I would check the value with M205 to ensure to eeprom of have been changed but I would still get the same results.

If I tried to adjust the bed with screws things seem to be working normally. However, I am not really sure what MAX LENGTH is being used since changes dont seem to have an effect. I know eeprom issues have been discussed in great length but I did not find any solutions.

[Polygonhell]

Ok back to leveling. Yesterday I was experiencing an issue with changing the XYZ tower heights in the config file and eeprom. I wanted to avoid using to screws for now since I now have the LCD installed and it allows for 0.01 increments. However, the printer seemed to be ignoring changes made to “X,Y,Z_MAX_LENGTH”.

I would go down to the print bed to determine the offset value, say... 1.5mm. Make the needed changes to the parameter (adjust by 1.5mm) and recompile.
Then recheck the height at the column and the same offset value is shown (1.5mm). I repeated this several times and no changes where reflected in the printer. I tried this both by recompling with eeprom off and making the changes using M206. When I used M206 commands I would check the value with M205 to ensure to eeprom of have been changed but I would still get the same results.

If I tried to adjust the bed with screws things seem to be working normally. However, I am not really sure what MAX LENGTH is being used.

The only thing controlled in the firmware is the Z offset and the DELTA_RADIUS, it ignores the X and Y values for delta printers.
You have to use the screws to level the motion of the head relative to the bed.

[aerouta]

Great thanks, I knew that was true for Marlin and don't know why I thought differently for yours.

THanks!

[aerouta]

.

Quick question when you calibrate do you always visit the 3 corner positions in the same order, if you visit them in the opposite order do you get the same values?

Polygonhell, You asked this question a well back and I blew it off. It turns out I am having this issue. At least on the Y towerx-77.94 y-45. Checking the height after a G28 yeilds the accurate height.( i.e. paper catches at 0.03mm). If I G28, then go to the X tower(x-77.94 y-45) then go back to the Y tower the paper catches at 0.21mm.

I just repositioned the endstops to ensure that they have the most deflection.
I am hoping you have an easy solution to this......


Just checked the other towers, the zheight on the towers seem to depend on the path to the calibration points. (x-77.94 y-45),(x77.94 y-45),(x- y90)

[Polygonhell]

.

Quick question when you calibrate do you always visit the 3 corner positions in the same order, if you visit them in the opposite order do you get the same values?

Polygonhell, You asked this question a well back and I blew it off. It turns out I am having this issue. At least on the Y towerx-77.94 y-45. Checking the height after a G28 yeilds the accurate height.( i.e. paper catches at 0.03mm). If I G28, then go to the X tower(x-77.94 y-45) then go back to the Y tower the paper catches at 0.21mm.

I just repositioned the endstops to ensure that they have the most deflection.
I am hoping you have an easy solution to this......


Just checked the other towers, the zheight on the towers seem to depend on the path to the calibration points. (x-77.94 y-45),(x77.94 y-45),(x- y90)

The reason I asked the question is that if that's the case you have a mechanical issue or you're hitting the bed during calibration and the stepper is skipping causing all subsequent positions to be incorrect. Probably the former.
I would check your belts for damage to start with.

[aerouta]

Just checked the belts, no sign of damage.

[aerouta]

All my towers are acting the same way. I have them calibrated. They all grab a piece of paper at ~0.03mm after a G28 move. However, if I perform a G28, then a, X0 Y0 Z2, then go the towers calibration points they all grab at ~0.23mm.

[Polygonhell]

Just checking you are using M114 to get the actual position.
If all the towers show an offset it's likely an issue with repeatability on the home switches, a single tower can also show this.
If you home again without changing anything is it the same or different?
If you see this move the limit switches so that the screw hits as close as possible to the button on the switch using as little of the lever as possible, you should get be able to get <0.05mm variance when homing.
You can also try slowing down the homing speed in either the firmware or EEPROM if you are using repetier.

But if you get CONSISTENTLY different results moving clockwise around the plate vs anticlockwise, you have a "backlash" (and I use the term loosely) issue, which is either belts (damaged, too lose or too tight), arm joints (too tight or excessive slop), Cheap skates (excessive slop or not moving smoothly). Usually the issue is not all 3 axis and if you move the carriages by hand (gently) you can feel one that's different.

[aerouta]

Just checking you are using M114 to get the actual position.
If all the towers show an offset it's likely an issue with repeatability on the home switches, a single tower can also show this.
If you home again without changing anything is it the same or different?
If you see this move the limit switches so that the screw hits as close as possible to the button on the switch using as little of the lever as possible, you should get be able to get <0.05mm variance when homing.
You can also try slowing down the homing speed in either the firmware or EEPROM if you are using repetier.

But if you get CONSISTENTLY different results moving clockwise around the plate vs anticlockwise, you have a "backlash" (and I use the term loosely) issue, which is either belts (damaged, too lose or too tight), arm joints (too tight or excessive slop), Cheap skates (excessive slop or not moving smoothly). Usually the issue is not all 3 axis and if you move the carriages by hand (gently) you can feel one that's different.

I do not think its the home switch because they dont come into play when the offset shows. I can home then go straight to the calibration point several times and I get the same results. The offset comes only after I leave the calibration point to some other location, like the center, and then return to the calibration point. As soon as I home and go straight to the calibration point the offset goes away. So yes I can home again without anything changing and I get consistent results.

I have not tried clockwise verses anticlockwise, I have just moved to (0,0) and returned and i get the same offset ~0.22mm across the towers.

I have sanded my arms smooth, so I dont think its that. I can check the smoothness of my carriages. It sounds like I should ensure they all require a similar "none excessive" amount of force to move?

Michael, how are those ball joints coming??

[mhackney]

Very perplexing issue. So, I want to make sure I understand and that you've collected all the data:

You do a G28 to home the axes.

Have you then performed a G0 X0 Y0 Z0 F2500 - to go to 0,0,0? And if so, you should have a slightly "grippy" paper test, correct?

Then, move to one of the calibration points with a GO X-77.94 Y-45? And what does the paper test indicate?

Then, move back to 0,0,0 G0 X0 Y0 Z0 - what do you get?

Do this sequence with all 3 towers and back to center?

Thanks,
Michael

[Polygonhell]

I suspect that your DELTA_RADIUS is slightly off and you are hitting the platform on the return to center and dragging the nozzle resulting lost steps.
If you do the following do you see the same offset?

HOME
Move to Calibration point offset - verify height
Move up 5mm
Move to X0 Y0
Move to Calibration point XY (not Z = 0)
Move to Z0 - verify height

The idea is to be clear of the bed moving to and from the center, the Z moves are symmetric, so should have no effect on the final positioning.
The way the Firmware works is it tracks the position in steps, so how you get there makes no difference, the only things that introduce error, are lost steps, and mechanical issues.

[aerouta]

Very perplexing issue. So, I want to make sure I understand and that you've collected all the data:

You do a G28 to home the axes.

Have you then performed a G0 X0 Y0 Z0 F2500 - to go to 0,0,0? And if so, you should have a slightly "grippy" paper test, correct?

Then, move to one of the calibration points with a GO X-77.94 Y-45? And what does the paper test indicate?

Then, move back to 0,0,0 G0 X0 Y0 Z0 - what do you get?

Do this sequence with all 3 towers and back to center?

Thanks,
Michael

I have not performed the grip test at (0,0). I set the z height to get me in the ballpark then started on the towers. I figured I would correct (0,0) with delta radius after I was done with the towers.

So I calibrated all the towers, which each check immediately following a G28 (never moving across the plate). Everything checks out fine. I can do this repeatedly.

The issue comes when I move to (0,0).

Here are some sequences and results. I don't check height at (0,0). I figured I need to nail down the towers first.

Polygon, Notice I command an increase of 5mm between the center and tower commands to ensure I am not dragging.

G28
X-tower - 0.03
G28
Y-tower - 0.03
G28
Z-tower - 0.03

G28
center (0,0,5)
X-tower - 0.20mm

G28
X-tower - 0.03mm
center (0,0,5)
X-tower - 0.20mm

[mhackney]

Ok, it seems you have backlash somewhere. If you repeat the sequence to the x tower to center and back 10 times, do you get variation in the measured height? How are you measuring the height?

[aerouta]

Here is a picture of a print I just made. I think it may confirm you backlash issue. I have not repeated it up 10 times to see if I get to same results. I will do that next.

Not sure how to interpret this.

[mhackney]

Either it is a simple belt tensioning issue or something else!

The good news is, that is so bad it should be easy to find the source.

The big sidestep is indicative of skipping a tooth on the belt. Do you hear it, a thunk?

[Polygonhell]

Looks much more like missing steps than backlash to me.
I can't tell is the print vertical before the obvious shift?