accuracy issues?

[JFettig]

Does anyone have any complaints about the corexy system? From what I have evaluated it should be an awesome drive system. I have my printer design nearly done. I am a little annoyed with my delta and the weird accuracy issues I'm having.

The corexy printer will be run on machine kit or a smoothieboard

[Chris Hax]

Busy building my CoreXY but so far I have owned a Da Vinci 1.0, Printrbot Simple Metal and a Mini Kossel with Azteeg X5 controller running smoothieware. So far the Mini Kossel has been the most accurate with the Simple Metal coming in a close second. My biggest gripe about the Kossel is flex with OpenBeam extrusion/v rollers vs linear rails and consistency. The Kossel just always needs to be recalibrated and I'm never 100% happy.

I'm hoping a CoreXY built with 20x40 extrusion will be sturdy enough while offering at least 50mm/sec print speeds and as good or better quality then my Kossel. I'm planning to have at least a 300mm build area as well!

[Ryan Carlyle]

Accuracy of a CoreXY will be the same as or better than a Cartesian bot of equivalent construction.

[Alex Borro]

Why Ryan?  I mean, why a CoreXY bot would have better accuracy than a regular cartesian bot running same motors, pulleys, belts, etc?

Em 28/03/2015 22:17, "Ryan Carlyle" <temp...@gmail.com> escreveu:

Accuracy of a CoreXY will be the same as or better than a Cartesian bot of equivalent construction.

--
You received this message because you are subscribed to the Google Groups "H-bot and CoreXY 3d printers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to h-bot-and-corexy-3d-...@googlegroups.com.
Visit this group at http://groups.google.com/group/h-bot-and-corexy-3d-printers.

[adam paul]

I am fairly new to this, and far from anything remotely resembling an engineer.

Why does the shape affect accuracy? Wouldn't that really be determined from the choice of motors/drivers/hardware.

The printer is just a playback machine, does it matter if one stepper controls one axis, our two.

[Ryan Carlyle]

• Less moving mass in the gantry means reduced ringing / corner overshoot. 
  
• It's a zero-backlash design if you get the belt system right. 
  
• The belt arrangement makes squaring the gantry exceptionally easy via belt tensioning. 
  
• The 45 degree kinematic transform helps reduce mechanical resonance and stabilize gantry motions because the axis of stepper rotor oscillation is out of alignment with the axis of gantry rod flex.
  

On Sunday, March 29, 2015 at 11:54:01 AM UTC-5, Alex Borro wrote:

Why Ryan?  I mean, why a CoreXY bot would have better accuracy than a regular cartesian bot running same motors, pulleys, belts, etc?

Em 28/03/2015 22:17, "Ryan Carlyle" <temp...@gmail.com> escreveu:

Accuracy of a CoreXY will be the same as or better than a Cartesian bot of equivalent construction.

--
You received this message because you are subscribed to the Google Groups "H-bot and CoreXY 3d printers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to h-bot-and-corexy-3d-printers+unsub...@googlegroups.com.

[whosawhatsis]

Plus it effectively has sqrt(2)/2 times the X/Y resolution of a similarly-built discrete cartesian bot. On the downside, the complexity of the belt path does create some additional failure modes, and probably allows one loose belt to have a bigger (and harder to identify) impact on print quality.

To unsubscribe from this group and stop receiving emails from it, send an email to h-bot-and-corexy-3d-...@googlegroups.com.

[Ryan Carlyle]

The resolution difference actually washes out. The diagonal AB resolution is sqrt(2) finer than the nominal steps/mm, and the resulting virtual XY resolution is sqrt(2)/2 less fine than the diagonal AB resolution. Sqrt(2)/2*sqrt(2)=1. So the final resolution is identical to a Cartesian bot using the same belts/pulleys. 

For my CoreXY with 18t GT2 pulleys, 200 steps/rev, and 1/16 microstepping:

This, of course, assumes you're using CoreXY firmware that does a proper kinematic rotation transform to get back to Cartesian build table coordinates rather than just printing rotated. If you print rotated using simple Cartesian firmware, you pick up a ~40% resolution boost. That's not necessarily good though -- depends on how limited you are on step generation.

[whosawhatsis]

Whether you're rotating or not, unless you're doubling steps (emulating a non-CoreXY system, with each X or Y step generating both and A step and a B step) so that it can only stop on half of the positions, you still have a 2x increase in the number of positions where you can stop within the space, which means that the distance moved per motor step increases by sqrt(2), which means that the precision with which you can locate the toolhead to any arbitrary position increases by the same factor.

It doesn't matter that the direction of the steps is 45 degrees to the logical axes. The difference only washes out if you can't reach those extra positions.

To unsubscribe from this group and stop receiving emails from it, send an email to h-bot-and-corexy-3d-...@googlegroups.com.

[Ryan Carlyle]

That depends on when and how the coordinate transform is done. For example, if you convert to integer step space before the coordinate rotate transform (as Sailfish does because of the x3g conversion) all of the "intermediate" step positions would represent fractional positions and thus are inaccessible due to integer casting of the coordinate system. I can't comment on how other CoreXY-capable firmwares do it.

Higher resolution than ~50 microsteps/mm is pretty pointless for this application, to be honest. 

[adam paul]

Wow, so I had to read that a few times, but I think it actually makes sense. Makes me wish I payed more attention in math class, instead of thinking of new things to cook for my GF,

[whosawhatsis]

I don't do sailfish (or anything that runs on MBI-designed hardware, anymore), but I know that Marlin keeps its positions in floating point pretty far into the process (possibly longer than it should). If it keeps it in floating point up to the point of converting to step counts (which, as I understand it, is how Marlin does it), then there is a resolution increase. I think Smoothie works similarly. Sounds like it would be next to impossible to implement a delta or SCARA bot in sailfish...

To unsubscribe from this group and stop receiving emails from it, send an email to h-bot-and-corexy-3d-...@googlegroups.com.

[Ryan Carlyle]

Don't get me started on Marlin. It's a pathological example of half the ways open source can go bad. I wouldn't run a Marlin machine in my house if you paid me. Too unsafe, too low-performance. I haven't kept up with the Marlin Delta code recently, but last time I looked, it was implemented wrong and the dynamics were completely screwed up because acceleration was being done on the carriages rather than the effector.

Sailfish has surprisingly superior performance to Marlin, considering that they're running on the same processor and derived from the same GRBL background. Makerbot's independent testing said Sailfish has 5-6x faster motion planner execution than Marlin. Why? The x3g pre-processor conversion is part of it, some decent GRBL bug fixes add a little, and the use of optimized variable casting and lower-cost integer math is most of the rest. Marlin's use of floating point math far into the motion planner is a huge unnecessary drag on clock cycles.

No one has wanted Delta kinematics on Sailfish enough to bother implementing it. I'd personally like Delta support, and have considered writing the algorithms, but almost no one ever asks for it, and Dan doesn't seem to think the Atmega is fast enough for Delta control (up to his standards for speed and quality). What you would have to do is reconstruct the gcode coordinates from the x3g step-space coordinates, then do the kinematics, then convert back to step space. It's not hard. It's just extra math that nullifies a lot of the advantage that the x3g file format gives you to start with.

I hope you're joking about SCARA, it's a remarkably shitty architecture for 3DP. The C stands for "compliant" for heaven's sake.

[Ryan Carlyle]

All that to say... Marlin may gain resolution from CoreXY, but only because it's so serially anti-optimized and under-powered that in the end you don't WANT the higher step rate required for higher resolution. The best Marlin machines I've seen use around 50-60 steps/mm to get it to perform well. Going much higher is bad. Either the added stepper interrupt tick frequency drags down the processor, or you hit a double/quad-stepping breakpoint and effectively lose more motion smoothness than there was ever any benefit from the higher resolution to begin with.

Smoothie probably DOES benefit from the higher CoreXY resolution associated with carrying floating point math farther into the motion control code, because it has some overhead to spare.

[JFettig]

Thanks for all the replies, I kinda figured as much, when it comes to deltas there are all kinds of minor things that effect accuracy in a negative way, I'm hoping this is pretty simple and straight forward. My printer design is coming along nicely, I have most of my linear motion stuff already, need belts and pulleys then order components for the frame.

[Ryan Carlyle]

Great, post pics when it's shaping up :-)