Welcome to the SeeMeCNC Community

aehM_Key wrote:I mentioned this problem earlier and solved it by adding 3 screws at positions A, B and C:

Is your bed actually flat, or have you just warped it to match your printer's movement?
I'd be curious how flat your bed is compared to a true straight edge.



This thread is reassuring to me because it prioves that I'm not as crazy as I thought I was

I think it's warped now. I was missing 3DOF at the calibration variables, so I added them in hardware
Probably not the most elegant solution but it's working...

Woolf wrote:Brian, can you post your Marlin Firmware? I will test it on my Max.

sure, I will just have to dig it up!

Jimustanguitar wrote:I'll bring my machine on Thursday, yep.

I've got a dial indicator, but I've never rigged up a way to mount it, so bring that setup if you have one.

Sounds like a fun project, it'll be good to work on it with the experts!

that what I designed this for... http://www.tricklaser.com/Pen-Tool-hold ... RM-PTH.htm
I will bring one to the meeting.

Brian's tool holder works like a charm!

http://youtu.be/VHUWbldICeA

I'm going to start tweaking settings scientifically now. I've already learned a little bit about what the Alpha and Delta ABC settings do. I hope to have a logical write up of my findings as soon as I've made sense of them for myself. Stay tuned for more details coming soon.

One thing I can tell already, without using a real measurement tool like this, there's no way to positively quantify or visualize the changes that I'm playing with. Especially compared to trying to eyeball it or use a piece of paper as a feeler gauge.

Jimustanguitar wrote:Brian's tool holder works like a charm!

http://youtu.be/VHUWbldICeA

I'm going to start tweaking settings scientifically now. I've already learned a little bit about what the Alpha and Delta ABC settings do. I hope to have a logical write up of my findings as soon as I've made sense of them for myself. Stay tuned for more details coming soon.

One thing I can tell already, without using a real measurement tool like this, there's no way to positively quantify or visualize the changes that I'm playing with. Especially compared to trying to eyeball it or use a piece of paper as a feeler gauge.

I wish you the best of luck. I spent hours taking measurements and putting them into a spreadsheet, hoping that when I put all the data in one place, something would leap out at me. It didn't. If you don't see any patterns, you may have to read up on the inverse kinematics of a delta printer to understand the difference between moving the effector close to a tower, and moving the effector far from any. This might be a good place to start. I'll read it myself to see if I can come up with any theories.

Edit: Already paying off - see page 17. Look familiar?

whoa. That's a pretty interesting document right there.

If I'm reading it correctly, the tl;dr is that the kinematics of the delta printer have larger inherent errors in certain areas of the bed, with the size and location of those error zones determined by the geometry of the arms and the separation of the towers.

So this paper suggests that the problem isn't that the bed is warped. The problem is that if you get too close to the perimeter of the build plate, especially between two towers, the machine just isn't accurate.

large is a bit relative in this case, the red in that diagram is 0.0119 mm of error vs the pink which is 0.01mm of error

Agreed. I think we first need to determine what an acceptable error is.
.1mm? .05mm? Obviously perfection is impossible.

By blindly massaging my alpha and delta values, I was able to achieve variation as low as .2mm. Without a deeper understanding of what each value changes, I think that's pretty decent. Not perfect, but definitely an improvement from where I started.

Great find, BTW 626!

It's a "small" error, but on a simulated machine that starts with zero misalignments, and a carriage Z error of only .01mm. That is an error of about half a step. Consider how many degrees of freedom have to be managed as you "align" a Rostock MAX. Each tower can move left/right, in/out from center, and up/down. Multiply this by two, since the phenomenon exists on both the top and bottom. Right there is 18 degrees of freedom, all of which must be managed simultaneously. There is also the vertical screw that tightens the tower top to the top plate, which can be tightened "more" or "less"... add three DOF for that. If one of them is tigtened "too much" it may warp the top plate, causing distortion for all 3 towers. Using belt clamps on the top and bottom, I was able to get the towers aligned to within about half a degree, I think (measured with a table saw angle gauge). Deviation before using the gauge was 1 degree or more. One begins to see the advantage of designs in which the towers are braced with a formed plastic or metal piece. Every single one of these errors makes the delta calculations that much less accurate.

My machine and/or indicator seems repeatable to +/-.001" (sorry, I'm muddying the water with the in>mm conversion). If I run the same leveling script over and over, about 2 thousandths is the variance I observe.

This leveling script assumes that your dial indicator lifts somewhere between 0 and 6 mm off the bed, hits the center of the bed twice (in case you need to zero your indicator), and hits the point directly beneath each tower at a 125mm radius for you to tweak your stop screws. It's what I've been using to get my bed 'level' and my horizontal radius set. https://docs.google.com/document/d/1JBY ... sp=sharing

After getting things level and flat with the first script, I run this one: https://docs.google.com/document/d/1q2M ... sp=sharing It takes a measurement at all 6 points (XYZ and ABC) at a 125mm radius, 80mm radius, and 40 mm radius. It starts and ends with X0Y0Z0 to check if anything slipped during the routine.

Currently, the difference between my highest and lowest reading is 26 thousandths of an inch. This is my control, with delta and alpha values unaltered. While blindly tweaking settings (i.e. not knowing what effect they'd have) I got this to less than 10 thou yesterday. Hopefully I can get this even more dialed in over the next week or so as I work to understand the variables at play.

so will this new onyx help at all?

http://seemecnc.com/collections/parts-a ... d-bed-rev3

for the sake of clarity, and not trying to pick a fight with Jimustanguitar, 26 thousandths of an inch = 0.026" = 0.66 mm. So if your first layer height is set to 0.3 mm, an error of 26 thousandths is more than twice the height of the first layer, which would be more than enough to explain the 1st layer problems that people have been describing.

I am struggling with the paper's description of virtual columns. If I take a sloppy tape measure to my Max, my tower spacing is about 320 mm, the radius of the circle the cheapskates sit on is about 190 mm, and the delta arms are about 265mm. All of these measurements are off from the base measurements used to generate the error maps at the end of the paper.

smiley wrote:for the sake of clarity, and not trying to pick a fight with Jimustanguitar, 26 thousandths of an inch = 0.026" = 0.66 mm. So if your first layer height is set to 0.3 mm, an error of 26 thousandths is more than twice the height of the first layer, which would be more than enough to explain the 1st layer problems that people have been describing.

No offense taken, you're exactly right. That is precisely what we're trying to pin down.

smiley wrote:I am struggling with the paper's description of virtual columns. If I take a sloppy tape measure to my Max, my tower spacing is about 320 mm, the radius of the circle the cheapskates sit on is about 190 mm, and the delta arms are about 265mm. All of these measurements are off from the base measurements used to generate the error maps at the end of the paper.

The "virtual columns" are a way to simplify the math involved. Since the arm pivot points on a carriage are always parallel to the corresponding points on the platform, you can subtract the platform and carriage offsets from the model because they don't change the angles involved. This is why the distance between the virtual columns is less than the towers in the previous diagram.

Then, if the arms are always parallel, which they are, they can be represented as a single line instead of a double because they're always the same length too.

Because we removed the platform offset, all 3 arms meet at a single center point instead of the edge of the platform.


It's just a simplified representation of what's mathematically happening. The dimensions are different than your machine because the dimensions in the technical writing are from a different machine, but the principals should remain the same.

Ok, I think I understand now, thanks.

what I'm getting at is that the paper says something to the effect that the error magnitude should scale with the ratio of arm length to effective column radius, but I haven't done the math to figure out how that works. I do know the ratio given the measurements I took last night is ~30% off from the ratios I calculated from the diagrams in the paper, but I am not familiar enough with the equations to understand whether that means that the error on our machines is 30% larger than the paper, or 30% smaller, or if there is some other scaling factor involved.

Great work here Jim. I love the way you are systematically measuring and adjusting along with working to understand the math and what the firmware variables really do. Valuable work.
Getting it down to .25 mm is good progress.

The conversion factor for mm to inches is 25.4
mm/25.4 = inches
inches * 25.4 = mm

Interesting. I've been monkeying around with using the Traxxas balls that flateric found as part of a new effector design.

I had already cut my rods, and I was trying to decide if I needed to shorten them since the pivot points move farther away from the column and effector. Looks like based on the error plots that if you don't mind losing some z-height, you're better off having longer rods - in the 350mm rod plot, the errors inside the "build triangle" are only in the first 3 color bands (with the extreme errors confined to the area well off the round heated bed), where smaller arms will give you more variation within the conventional "build volume".

So, making big flat parts, longer rods = better, it seems.

bdjohns1 wrote:Interesting. I've been monkeying around with using the Traxxas balls that flateric found as part of a new effector design.

I had already cut my rods, and I was trying to decide if I needed to shorten them since the pivot points move farther away from the column and effector. Looks like based on the error plots that if you don't mind losing some z-height, you're better off having longer rods - in the 350mm rod plot, the errors inside the "build triangle" are only in the first 3 color bands (with the extreme errors confined to the area well off the round heated bed), where smaller arms will give you more variation within the conventional "build volume".

So, making big flat parts, longer rods = better, it seems.

I think that's theoretically true, yes.

In practice, I don't know of anyone that's done it.
Let us know what you find out, it definitely sounds like it's worth trying!
Take measurements of the "before" setup so that it's a conclusive comparison.

Jimustanguitar wrote:

bdjohns1 wrote:Interesting.
So, making big flat parts, longer rods = better, it seems.

I think that's theoretically true, yes.

This seems intuitive to me. I've been thinking about this and in simple terms, the error arises because when you have one arm close to parallel to the build plate, relatively small steps on the cheapskate end result in relatively larger moves on the effector end. I won't try to derive the equations here but I'm sure this is what the trigonometry in the paper shows.

So, anything you can do to keep the effector arms from approaching parallel to the build plate should reduce effective error. Longer arms is one solution, smaller build plate (relative to the column radius) is the other solution. So the videos discussed earlier in this thread, where the guy has a much larger column radius, would be expected to have less error (so long as he also has correspondingly longer delta arms). But column radius alone won't do the job- you probably need to keep the ratio of arm length to column ratio above a certain value.

Given a known column radius, known build plate radius, and a desired minimum Z error at the edge of the plate, it should be possible to calculate the necessary minimum arm length. I haven't done it, mind you... maybe tonight once the kids are asleep

I have emailed with SMC

The SMC support thinks it comes from the TrickLaser Arms.

What have you guys for an arms?

I've had SeeMeCNC arms (both the old and the new ones) and the TrickLaser arms. The problem is not specific to TL arms. I have the new arms installed now and they will readily produce the same error.

The problem reminds me of affine texture mapping: view a texture from a perpendicular angle and it's correct, but the closer you get to horizontal with the texture, the more distorted it becomes. This is because the calculation for perspective-correct textures is much more CPU intensive. Affine was used in games like Doom in the '90s (for walls) but abandoned as CPUs grew faster and GPUs came into play. It may be that the "perspective correct" delta calculation is more elaborate than what is there now.

Consider this error "shape:"
[img]http://forum.seemecnc.com/download/file ... &mode=view[/img]

You have a triangle with points at each tower. Inside the triangle, positioning is perfect, but outside the triangle it shows errors. Based on this shape, it could be possible to band-aid Repetier with some code that takes the following into account for each carriage/arm assembly. For each tower:
This code is naive and doesn't keep track of error, but it should give a general idea. A more elaborate model would calculate the pose relative to the center every frame, so it wouldn't accumulate error (as the above code would.)

Woolf wrote:I have emailed with SMC

The SMC support thinks it comes from the TrickLaser Arms.

What have you guys for an arms?

This is not true. I checked for myself again that the Traxxas joints do indeed have enough articulation angle to accommodate maximum travel of the MAX, so it is not caused by the Trick Laser arms.
Thank you for confirming this also 626pilot.

626Pilot wrote:I've had SeeMeCNC arms (both the old and the new ones) and the TrickLaser arms. The problem is not specific to TL arms. I have the new arms installed now and they will readily produce the same error.

The problem reminds me of affine texture mapping: view a texture from a perpendicular angle and it's correct, but the closer you get to horizontal with the texture, the more distorted it becomes. This is because the calculation for perspective-correct textures is much more CPU intensive. Affine was used in games like Doom in the '90s (for walls) but abandoned as CPUs grew faster and GPUs came into play. It may be that the "perspective correct" delta calculation is more elaborate than what is there now.

Consider this error "shape:"
[img]http://forum.seemecnc.com/download/file ... &mode=view[/img]

You have a triangle with points at each tower. Inside the triangle, positioning is perfect, but outside the triangle it shows errors. Based on this shape, it could be possible to band-aid Repetier with some code that takes the following into account for each carriage/arm assembly. For each tower:

Code: Select all

// i = which tower we're on
// armAngleAboveHorizontal[i] contains the degrees the current arm is over horizontal
// effectorDistanceToTower[i] contains the horizontal distance from the effector to the tower
// degreesFromTowerCenterline[i] contains the angle between the effector and a perpendicular line projected from the side of the tower through the center of the build envelope
// All these numbers are guesses!
float criticalArmAngle = 45; // Angle below which the error begins to occur
float criticalDistance = 115; // Millimeters away from the tower beyond which the error occurs
float criticalDegreesFromCenterline = 30; // Error occurs when the effector is within this many degrees of the tower's perpendicular centerline
float distanceCorrectionFactor = -1.002; // This would cause ever so slightly fewer steps, to correct a tendency to dig into the build surface. A positive number would correct lifting.
float angleCorrectionFactor = 1.01; // This corresponds to how much the deviation from tower centerline impacts positioning error

// Are we inside the envelope of positions that require correction?
if(abs(degreesFromTowerCenterline[i]) <= criticalDegreesFromCenterline && (armAngleAboveHorizontal[i] < criticalArmAngle || effectorDistanceToTower[i] > criticalDistance))
{
    // Correct for deviation caused by distance from tower
    correctionFactor = pow(effectorDistanceToTower[i] - criticalDistance), distanceCorrectionFactor);

    // Correct for deviation caused by degrees of yaw from centerline
    correctionFactor *= sin(degreesFromTowerCenterline[i]) * angleCorrectionFactor;
    steps *= correctionFactor;
}

This code is naive and doesn't keep track of error, but it should give a general idea. A more elaborate model would calculate the pose relative to the center every frame, so it wouldn't accumulate error (as the above code would.)

I think you are on the right track, however do you think the Arduio can handle even more calculations in the firmware? it is already pushed to it's limits.

bvandiepenbos wrote: I think you are on the right track, however do you think the Arduio can handle even more calculations in the firmware? it is already pushed to it's limits.

It has some wiggle room, but not a huge amount. It might be possible. Personally, I think Arduino is outdated and will soon run out of momentum. Teensy 3.0 boards are over $5 cheaper, run at 72MHz, have 256K flash and 64K RAM, and can produce hardware PWM on 9 pins - and they can be programmed in the Arduino IDE. Raspberry Pis are better still, for not much more money ($30-35), can run Linux and X-windows, but only have two channels of hardware PWM output. For immediate porting, the Teensy is better. For expanded capability in the future, the Pi is better, but as it can only generate two channels of PWM a slightly more complicated external board is needed. (They all need external support, at least for the Pololu stepper drivers.)