Welcome! Log In Create A New Profile

Advanced

Software axis orthogonality compensation in Marlin?

Posted by icefire 
Software axis orthogonality compensation in Marlin?
September 19, 2017 04:08AM
So I have been thinking that a lot of 3D printers have a problem with orthogonality. If the X and Y axis are not perfectly perpendicular it is impossible to print perfect circles, which could be a problem for functional parts. Same thing happens if the Z axis is not normal to the XY plane.

There are numerous ways to determine the error in orthogonality (print different test parts and measure sides, diagonals, diameters, etc.) but there is no easy way to get the error corrected (at least not to my knowledge). One way to go would be to physically move the axis but this is (if at all possible) very difficult to achieve... For example: How do you suppose one should reliably move an entire axis by 0,235mm to the right and then tighten it without getting it wrong again...

So I was thinking if there is a way to do this in the printer firmware. One permanent correction coefficient. For example, the prusa i3 mk2 measures the error with the inductive sensor flying over the conductive points on the otherwise non-conductive heatbed and calculates the correction coefficients. I would like to do it much simpler - find out with some test prints what the deviation is and then just feed the correction values to the firmware...

Any way to do this in Marlin?


Self-sourced Mendelmax 2.0-based Reprap Machine -- Ramps 1.4 & Mega 2560 -- DRV8825 ([email protected], [email protected], [email protected], [email protected]) -- genuine E3D v6 direct setup -- 350W custom silicone heated bed -- ABS 1,75mm -- Marlin 1.1.0-RC7 -- Cura 15.04.6
VDX
Re: Software axis orthogonality compensation in Marlin?
September 19, 2017 05:36AM
... I'm doing this sort of "recalibration" with external programs (or plugins), which reads the G-code lines, split/separate into the specific X/Y/Z/E-coordinates, calculates all sorts of calibration, scaling, rotating and other geometrical or numerical (or processing like speed or pulses per mm) changes ... and last export and reimport this as a new G-code-file into the program to print it.

For this I've modified Pronterface and added other functions too, like "camera assisted teaching" and different format-converters for HPGL-, Gerber- and CNC-files ... so not a trivial task eye rolling smiley


Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]
Re: Software axis orthogonality compensation in Marlin?
September 19, 2017 07:21AM
Were the plugins published somewhere?
I suppose that this calibration procedure could be implemented practically everywhere - in the firmware, in the slicer or externally via G-Code modification... but is there any sort of tool which already exists?


Self-sourced Mendelmax 2.0-based Reprap Machine -- Ramps 1.4 & Mega 2560 -- DRV8825 ([email protected], [email protected], [email protected], [email protected]) -- genuine E3D v6 direct setup -- 350W custom silicone heated bed -- ABS 1,75mm -- Marlin 1.1.0-RC7 -- Cura 15.04.6
Re: Software axis orthogonality compensation in Marlin?
September 19, 2017 07:28PM
RRF duet has this built in with a gcode for axis compensation. If you're sticking with marlin, you could make a request for implementation to marlin team via github.com. Prusa are already doing it with the i3 mk2 so there should be some code knocking about already.

Edited 1 time(s). Last edit at 09/19/2017 07:29PM by DjDemonD.


Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions
Re: Software axis orthogonality compensation in Marlin?
September 19, 2017 08:16PM
Sounds great, but isn't it easier to just make a square printer to begin with? This is a similar argument to bed levelling, but that I understand as it removes the need for a calibration step that users don't want. Orthoganility should just be a thing from the start and never need to be corrected.
Re: Software axis orthogonality compensation in Marlin?
September 20, 2017 04:29AM
Quote
DjDemonD
RRF duet has this built in with a gcode for axis compensation. If you're sticking with marlin, you could make a request for implementation to marlin team via github.com. Prusa are already doing it with the i3 mk2 so there should be some code knocking about already.

I wouldn't change the electronics just to get RRF. If I build a new machine from scratch it would be a different story. There are already quite a number of feature requests but it doesn't seem to be implemented yet. The most interesting discussion is probably this one: [github.com]

Quote
Origamib
Sounds great, but isn't it easier to just make a square printer to begin with? This is a similar argument to bed levelling, but that I understand as it removes the need for a calibration step that users don't want. Orthoganility should just be a thing from the start and never need to be corrected.
I agree, it would be best if the machine were flawless from the beginning but this is completely impossible, especially with larger cartesian printers. It also depends on the construction of the printer itself. If the Y axis for example is fixed 0,2mm to the left on the one side and 0,2mm to the right on the other side this would already mean that a printer with a 400mm long axis will never be able to print perfect circles. This is why I am looking for a software solution...

Edited 1 time(s). Last edit at 09/20/2017 05:31AM by icefire.


Self-sourced Mendelmax 2.0-based Reprap Machine -- Ramps 1.4 & Mega 2560 -- DRV8825 ([email protected], [email protected], [email protected], [email protected]) -- genuine E3D v6 direct setup -- 350W custom silicone heated bed -- ABS 1,75mm -- Marlin 1.1.0-RC7 -- Cura 15.04.6
Re: Software axis orthogonality compensation in Marlin?
September 20, 2017 07:43AM
An error of 0.4mm in 400mm is equivalent to a 1 mm error at 1m. That translates to an error of 0.057 degrees. There are going to be other errors, such as play in bearings, flex in guide rails, flex in printer frame, behavior of molten plastic, print artifacts like ringing, shrinkage of plastic, variation in filament diameter, and limitation of your ability to measure things accurately that will bury that small error. It's like you said, how are you supposed to accurately move the end of an axis 0.4 mm? It's not so hard to move the axis a little, it's hard to know you're moved it the right amount.

This may sound a bit out of character for me, but you have to keep things in perspective. You're squirting molten plastic out of a nozzle, in discrete layers, along a path generated from a polygonal approximation of a CAD design. You can get close, but you can't get perfection. Even if you could reproduce the STL file perfectly, it won't be the same as the CAD design.

I agree that keeping the Z axis perpendicular to the XY plane is probably the biggest problem in 3D printers, primarily because of the dual motor Z axis design flaw that so many build into the machines, secondarily because of poor frame construction. This is a human problem, not a technical problem. Users don't want to hear that the design of the printer is flawed, and they definitely don't want to pay for better quality (at least not in the US). They want to hear that there's some magic in the firmware that will correct all the stupid errors that the designer made. Oops, let me correct that. They want to hear that there's some magic in the firmware, period.

So maybe you're barking up the right tree after all. Put some more magic in the firmware. It doesn't have to do anything meaningful in the real world. It just has to exist. The marketing department will take care of the rest.


Son of MegaMax 3D printer: [www.instructables.com]
Ultra MegaMax Dominator 3D printer: [drmrehorst.blogspot.com]
Re: Software axis orthogonality compensation in Marlin?
September 20, 2017 09:39AM
Quote
the_digital_dentist
An error of 0.4mm in 400mm is equivalent to a 1 mm error at 1m. That translates to an error of 0.057 degrees. There are going to be other errors, such as play in bearings, flex in guide rails, flex in printer frame, behavior of molten plastic, print artifacts like ringing, shrinkage of plastic, variation in filament diameter, and limitation of your ability to measure things accurately that will bury that small error. It's like you said, how are you supposed to accurately move the end of an axis 0.4 mm? It's not so hard to move the axis a little, it's hard to know you're moved it the right amount.

This may sound a bit out of character for me, but you have to keep things in perspective. You're squirting molten plastic out of a nozzle, in discrete layers, along a path generated from a polygonal approximation of a CAD design. You can get close, but you can't get perfection. Even if you could reproduce the STL file perfectly, it won't be the same as the CAD design.

I agree that keeping the Z axis perpendicular to the XY plane is probably the biggest problem in 3D printers, primarily because of the dual motor Z axis design flaw that so many build into the machines, secondarily because of poor frame construction. This is a human problem, not a technical problem. Users don't want to hear that the design of the printer is flawed, and they definitely don't want to pay for better quality (at least not in the US). They want to hear that there's some magic in the firmware that will correct all the stupid errors that the designer made. Oops, let me correct that. They want to hear that there's some magic in the firmware, period.

So maybe you're barking up the right tree after all. Put some more magic in the firmware. It doesn't have to do anything meaningful in the real world. It just has to exist. The marketing department will take care of the rest.

No need to be so dismissive (calling it 'magic'). Compensating for uneven bed, bent rods and alignment will not only improve prints but also allow for larger faster and cheaper, mas-produced 3d printers.

Edited 1 time(s). Last edit at 09/20/2017 10:11AM by newbob.
Re: Software axis orthogonality compensation in Marlin?
September 20, 2017 12:28PM
In industry, software calibration is generally reserved for machines that are already approaching the limits of attainable mechanical accuracy.

This is for a few reasons. The first problem is that errors on a cheap machine are unlikely to be linear. Squareness errors in a hobby printer are probably accompanied by twisting and bending, which makes it very hard to get useful calibration data via a small number of manual measurements.

You will get really weird artifacts if make incorrect assumptions about the nature of the error, so you more or less need to map the entire print volume (kind of like how bed leveling should probe a grid instead of only three points).

The second and more important problem is that cheap devices are not repeatable so the "correct" calibration will change over time.
A printer that is not rigid enough to hold alignments will shift with humidity/temp, and will probably even settle over time as it wears in and gets bumped during use. If your printer is on a wooden table (or the table is on a wooden floor) those movements will be transmitted to the printer frame as well.

Something as simple as filament pulling on the extruder could have a ~0.1mm impact on final position, so if you calibrate that out and then swap spools everything goes to shit. Generally if you plan on software calibrating a system you build it to be as rigid and repeatable as possible, which means it will be very expensive or very slow.


Machine tool alignment is a very interesting field, people were hitting <0.0001" alignments by hand thousands of years ago using simple (but sometimes time consuming) techniques. If you have a decent square, test indicator, mallet, and tape you should be able to align a well designed 3d printer to the limit of its rigidity.
Re: Software axis orthogonality compensation in Marlin?
September 20, 2017 02:43PM
Way too much emotions here.
I basically agree with the digital dentist still this doesn't eliminate the need of software compensation.

About 2 years ago when I first started building my 3D printer there were a lot of discussions here about Z probes and why we don't need them because a manually aligned print bed with a reliable endstop is all you need. Which is not untrue, I accidentally damaged my inductive sensor while doind some changes on the X carriage and have been printing without a Z probe for a few weeks now and it works just as well. However, a Z probe makes life much easier if the build surface needs to be removed or recalibrated because of other reasons. So why not a skew compensation? If the printer is reasonably backlash-free it would be a great feature saving a lot of time and allowing some margin of error while assembling the machine.


Self-sourced Mendelmax 2.0-based Reprap Machine -- Ramps 1.4 & Mega 2560 -- DRV8825 ([email protected], [email protected], [email protected], [email protected]) -- genuine E3D v6 direct setup -- 350W custom silicone heated bed -- ABS 1,75mm -- Marlin 1.1.0-RC7 -- Cura 15.04.6
Re: Software axis orthogonality compensation in Marlin?
September 20, 2017 04:34PM
I think there are too many generalisations being made in this thread.

I have a Cartesian printer (Ormerod 1) with a build volume of 200x200x200mm. It provides auto bed compensation and skew compensation. But I rarely use auto bed compensation, and although I did the skew calibration after I built the printer, I never use it. So most of the time I don't need these features. But when I do a print that is large in the XY dimensions, I use bed compensation to compensate for a slight curve of the bed and a slight sag of the X arm. If I ever do a tall print on that printer, I will probably use XZ and YZ skew compensation too.

If I was doing large prints all the time, I would rebuild the printer with a flatter bed and more rigid mechanics. But given my current usage, it isn't worth it. I'm glad that I rarely need to use either feature; but the availability of bed and skew compensation extends the useful envelope of what is a budget 3D printer.

So I agreed with digital dentist when he says that you should aim to build a printer that doesn't need bed compensation or skew compensation. And I also agree with those who argue that these features can be useful in particular situations, especially for larger 3D printers in which it's harder to get the bed completely flat or to prevent the gantry sagging by more than 10um.

Edited 2 time(s). Last edit at 09/20/2017 04:36PM by dc42.



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].
Re: Software axis orthogonality compensation in Marlin?
September 20, 2017 04:38PM
I was writing pretty much the same thing, but David beat me to it.

If you can build it right, and have the time, money and expertise to do so, then do that.
If you have to compromise on that the chances are software can help you get more out of an imperfect (either because its cheap or very large) machine.

My best printer is very accurate, expensive and took an incredible amount of time to build and tune, but I still probe the bed, use autocalibration and grid levelling, mainly just to verify everything is correct.


Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions
Re: Software axis orthogonality compensation in Marlin?
September 20, 2017 04:51PM
Quote
the_digital_dentist
how are you supposed to accurately move the end of an axis 0.4 mm? It's not so hard to move the axis a little, it's hard to know you're moved it the right amount.

This has been solved by engineers centuries ago...
A fine pitch screw (e.g. M6x0.75) attaching the axis to a rigid mount at one or both ends (like an adjustable heated bed mount).So 0.4mm movement = 192 degrees of turn. Anyone should be able get better than 60 degrees = 1/6 a turn = 0.125mm.

Quote

This is a human problem, not a technical problem. Users don't want to hear that the design of the printer is flawed, and they definitely don't want to pay for better quality (at least not in the US).

I disagree; this is a technical problem, to overcome limits in manufacturing quality of the printer and its components. It is after all impossible to make anything 100% perfect. We already put various configuration settings into firmware to correct for deficiencies in the build of the printer. I'm thinking here of the various settings available in a Delta printer to correct for tower spacing, rod length variation, etc, but the principle applies equally to Cartesian.

I do wonder whether some of these settings couldn't be built into a slicer, which would use the multicore high-speed high-precision capabilities of the desktop PC to customise the G-code to the specific target printer. I guess that @VDX's plugins are a step along this path.
Re: Software axis orthogonality compensation in Marlin?
September 20, 2017 05:12PM
Now that everyone has expressed his feelings about the subject, maybe we could go back to the original question - how to do it smiling smiley
Does someone know about any sort of slicer plugin or any insight on how it is done in RRF?


Self-sourced Mendelmax 2.0-based Reprap Machine -- Ramps 1.4 & Mega 2560 -- DRV8825 ([email protected], [email protected], [email protected], [email protected]) -- genuine E3D v6 direct setup -- 350W custom silicone heated bed -- ABS 1,75mm -- Marlin 1.1.0-RC7 -- Cura 15.04.6
Re: Software axis orthogonality compensation in Marlin?
September 20, 2017 06:35PM
go here [duet3d.com] and search for M556

But that is how to set it up not how its done. I'm sure DC can point you to the section of code on git that handles this.

Edited 1 time(s). Last edit at 09/20/2017 06:36PM by DjDemonD.


Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions
Re: Software axis orthogonality compensation in Marlin?
September 21, 2017 02:45AM
Quote
DjDemonD
go here [duet3d.com] and search for M556

But that is how to set it up not how its done. I'm sure DC can point you to the section of code on git that handles this.

It's applied in file Movement/Move.cpp, by functions AxisTransform and InverseAxisTransform.



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].
Sorry, only registered users may post in this forum.

Click here to login