Unsolved Mystery. Weird Z0 behavior around build perimeter.

Having a problem? Post it here and someone will be along shortly to help
Post Reply
User avatar
626Pilot
ULTIMATE 3D JEDDI
Posts: 1719
Joined: Tue May 14, 2013 12:52 pm

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by 626Pilot » Mon Jun 23, 2014 6:48 pm

Flateric wrote:I am no expert in this area but I have a feeling that this is not going to be a possibility for the smoothie based boards.

The only time that the board reads the firmware config is at first boot and not after again.

Although I admit I have no idea how the repetier arduino based offerings do their firmware setup, or why they can allow for "hot" changes to the firmware even during the printing process.

Repetier writes values to variables that are "live" (kept in RAM) on the controller. The EEPROM only "remembers" the variables when the power is off - they can be rewritten at any time. It would work the same for Smoothie, except the data would be stored on the SD card instead of in EEPROM (which the SD card actually is... it's just not called that.) It would be a matter of rewriting the config file, which is trivial. I think if someone at the project cared to make it work, it would be feasible.

jjjohnson
SeeMeCNC Staff
Posts: 36
Joined: Sat Jun 02, 2012 9:31 am
Location: Goshen, Indiana

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by jjjohnson » Wed Jun 25, 2014 3:49 pm

So we've been looking at this Z0 issue from all angles trying to determine a cause and solution and we stumbled upon a change that needs to be made in the firmware. Making the change has been yielding some great results for the printer on my desk at work and at home. The current firmware has the Carriage Offset value at 35 while in all actuality the value needs to be more like 37.5

We have uploaded the updated firmware on a Rostock Max V2 here in the shop and then did a somewhat extensive calibration of the z height at the center and base of each tower using a dial indicator mounted to the platform. The result is a repeatable accuracy of within .004" at 6 points equidistant around the perimeter. I then reattached the hotend to the platform and attempted a print near the outer extremes of the build plate with great success. All areas stuck well, and there were no areas of squished filament.

I created a video of the calibration readings and the resulting print. Check it out at: https://www.youtube.com/watch?v=E-92PSNINO0&feature=youtu.be

Try the firmware change and recalibrate and let me know what you think.


Here is the calibration code I used:
G28
G1 Z10 F15000
G1 Z0 F3500
G4 S1.5
G1 Z10
G1 X0.000 Y115.000
G1 Z0
G4 S1.5
G1 Z10
G1 X-99.593 Y57.500
G1 Z0
G4 S1.5
G1 Z10
G1 X-99.593 Y-57.500
G1 Z0
G4 S1.5
G1 Z10
G1 X0.000 Y-115.000
G1 Z0
G4 S1.5
G1 Z10
G1 X99.593 Y-57.500
G1 Z0
G4 S1.5
G1 Z10
G1 99.593 Y57.500
G1 Z0
G4 S1.5
G1 Z10
G1 X0.000 Y115.000
G1 Z0
G4 S1.5
G1 Z10
G28
JJ

User avatar
guanu
SeeMeCNC Staff
Posts: 397
Joined: Mon Mar 26, 2012 1:54 pm

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by guanu » Wed Jun 25, 2014 4:35 pm

just want to touch on what JJ said for thoes who arent so firmware savvy... when you load the firmware in arduino, go to the configuration.h tab, and go down to line # 752 (the bottom left of the arduino software says what line the cursor is at) and that should be #define CARRIAGE_HORIZONTAL_OFFSET 35.0 change the 35 to 37.5
upload the firmware and recalibrate the machine...

Guanu

User avatar
apostoly
Printmaster!
Posts: 142
Joined: Fri Mar 07, 2014 6:01 pm
Location: Sydney Australia

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by apostoly » Wed Jun 25, 2014 6:32 pm

Cant wait to test this out tonight!!

Thanks for the info guys!!

User avatar
bvandiepenbos
Printmaster!
Posts: 927
Joined: Thu Apr 05, 2012 11:25 pm
Location: Goshen, IN
Contact:

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by bvandiepenbos » Wed Jun 25, 2014 7:04 pm

very interesting find JJ.
But I thought Repetier no longer uses those values for "Carriage Offset" and "Smooth Rod Offest" ???
~*Brian V.

RostockMAX v2 (Stock)
MAX METAL "ShortyMAX"
MAX METAL Rostock MAX Printer Frame
NEMESIS Air Delta v1 & v2 -Aluminum delta printers
Rostock MAX "KITT" - Tri-Force Frame
GRABER i3 "Slim"

Polygonhell
ULTIMATE 3D JEDDI
Posts: 2430
Joined: Mon Mar 26, 2012 1:44 pm
Location: Redmond WA

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Polygonhell » Wed Jun 25, 2014 7:14 pm

Changing the Carriage Offset, or indeed any of the other related values should be identical to changing the printer radius, they are all just used as a convenience to compute DELTA_RADIUS.
From the source code. AFAIK this is the only place it's used.

#define DELTA_RADIUS (PRINTER_RADIUS-END_EFFECTOR_HORIZONTAL_OFFSET-CARRIAGE_HORIZONTAL_OFFSET)

User avatar
bvandiepenbos
Printmaster!
Posts: 927
Joined: Thu Apr 05, 2012 11:25 pm
Location: Goshen, IN
Contact:

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by bvandiepenbos » Wed Jun 25, 2014 11:14 pm

Polygonhell wrote:Changing the Carriage Offset, or indeed any of the other related values should be identical to changing the printer radius, they are all just used as a convenience to compute DELTA_RADIUS.
From the source code. AFAIK this is the only place it's used.

#define DELTA_RADIUS (PRINTER_RADIUS-END_EFFECTOR_HORIZONTAL_OFFSET-CARRIAGE_HORIZONTAL_OFFSET)


That's how I understand it also.
Could that calculation in firmware be conflicting with what is in EEPROM via rep host ?
~*Brian V.

RostockMAX v2 (Stock)
MAX METAL "ShortyMAX"
MAX METAL Rostock MAX Printer Frame
NEMESIS Air Delta v1 & v2 -Aluminum delta printers
Rostock MAX "KITT" - Tri-Force Frame
GRABER i3 "Slim"

User avatar
guanu
SeeMeCNC Staff
Posts: 397
Joined: Mon Mar 26, 2012 1:54 pm

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by guanu » Thu Jun 26, 2014 7:16 am

thats what we thought, but its not, without changing the eeprom (horizontal radius is now there, so changing that number in the firmware SHOULDNT change movement) changing that number actually did change the results while keeping the radius the same, so it is used somewhere else for the movement calculations... we spent a good day tweaking and dialing it in and running tests...

so you can change that number to dial in the 6-point, and still adjust horizontal radius in the eeprom to adjust the bowl effect...
Guanu

bdjohns1
Printmaster!
Posts: 238
Joined: Sat Jan 25, 2014 9:50 pm
Location: Madison, WI

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by bdjohns1 » Thu Jun 26, 2014 8:17 am

Polygonhell wrote:Changing the Carriage Offset, or indeed any of the other related values should be identical to changing the printer radius, they are all just used as a convenience to compute DELTA_RADIUS.
From the source code. AFAIK this is the only place it's used.

#define DELTA_RADIUS (PRINTER_RADIUS-END_EFFECTOR_HORIZONTAL_OFFSET-CARRIAGE_HORIZONTAL_OFFSET)


That is weird - about 6 weeks ago when I switched from the stock arms and effector to a magnetic arm set and effector (not the same as xnaron's effector), all I had to do to get good results was change the Horizontal Radius and the Arm Length parameters in Repetier-Host in order to get a working calibration (I just did the 4-point method in the manual, but I checked between the towers and the drag force on the sheet of paper was pretty much the same).

I know that my offsets weren't the same as the stock arms either - my carriage offsets should have been +3mm or so from stock, arms +3 mm, and my end effector offset should have actually been almost -5mm with my "stilts" design.

Polygonhell
ULTIMATE 3D JEDDI
Posts: 2430
Joined: Mon Mar 26, 2012 1:44 pm
Location: Redmond WA

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Polygonhell » Thu Jun 26, 2014 2:30 pm

guanu wrote:thats what we thought, but its not, without changing the eeprom (horizontal radius is now there, so changing that number in the firmware SHOULDNT change movement) changing that number actually did change the results while keeping the radius the same, so it is used somewhere else for the movement calculations... we spent a good day tweaking and dialing it in and running tests...

so you can change that number to dial in the 6-point, and still adjust horizontal radius in the eeprom to adjust the bowl effect...
Guanu


I grep-ed the source code for it before I posted, the above line is the only place it's used.

Code: Select all

(git)-[master]
~/git/Repetier-Firmware/src/ArduinoAVR/Repetier : grep -i -r CARRIAGE_HORIZONTAL_OFFSET *
Configuration.h:            |                        |___| CARRIAGE_HORIZONTAL_OFFSET
Configuration.h:#define CARRIAGE_HORIZONTAL_OFFSET 18
Configuration.h:#define DELTA_RADIUS (PRINTER_RADIUS-END_EFFECTOR_HORIZONTAL_OFFSET-CARRIAGE_HORIZONTAL_OFFSET)

User avatar
Jimustanguitar
ULTIMATE 3D JEDDI
Posts: 2631
Joined: Sun Mar 31, 2013 1:35 am
Location: Notre Dame area
Contact:

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Jimustanguitar » Thu Jun 26, 2014 9:36 pm

Hey JJ, how far off was your machine before the firmware change? The carriage offset change in the new firmware didn't help my machine, I'm still off by about 19 thousandths.

New file from the GitHub, cleared EEPROM, loaded new firmware, recalibrated... What am I missing? Has this been the silver bullet for anyone else's machine?

Here are my results:


Mac The Knife
ULTIMATE 3D JEDDI
Posts: 1370
Joined: Sun May 11, 2014 6:18 pm

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Mac The Knife » Sat Jun 28, 2014 8:55 pm

Before I wipe my firmware settings out again, How do I retrieve them from the printer, then reupload them after I make the change?
R-Max V2
Eris
Folger Tech FT-5 R2

Mac The Knife
ULTIMATE 3D JEDDI
Posts: 1370
Joined: Sun May 11, 2014 6:18 pm

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Mac The Knife » Sun Jun 29, 2014 8:52 am

Looking at the firmware I downloaded last night from github, Line 752 has the carriage offset at 38.4, not 35. I assume someone updated this setting on github? I also ASSume, that I can't simply take a peek at my current firmware settings, and make a few tweaks.
R-Max V2
Eris
Folger Tech FT-5 R2

Mac The Knife
ULTIMATE 3D JEDDI
Posts: 1370
Joined: Sun May 11, 2014 6:18 pm

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Mac The Knife » Sun Jun 29, 2014 11:14 am

What I finally ended up doing. I opened Repetier, connected to the printer and exported the EEPROM settings. Shut down Repetier, and fired up Arduino IDE. Wiped the EEPROM on the printer, and installed the latest firmware from Github. Shut that down, reopened Repetier,, connected to the printer, and imported the EEPROM settings I had exported earlier. Now I'll check and reset the calibrations.
R-Max V2
Eris
Folger Tech FT-5 R2

RegB
Printmaster!
Posts: 294
Joined: Fri Jun 27, 2014 7:45 pm

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by RegB » Mon Jul 07, 2014 7:49 am

Mac The Knife wrote:Looking at the firmware I downloaded last night from github, Line 752 has the carriage offset at 38.4, not 35. I assume someone updated this setting on github? I also ASSume, that I can't simply take a peek at my current firmware settings, and make a few tweaks.


The article on the SeeMeCNC home page seems to think it should be 37.5

Mac The Knife
ULTIMATE 3D JEDDI
Posts: 1370
Joined: Sun May 11, 2014 6:18 pm

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Mac The Knife » Mon Jul 07, 2014 12:22 pm

The firmware they uploaded after their announcement was 38.4. Who knows?
R-Max V2
Eris
Folger Tech FT-5 R2

RegB
Printmaster!
Posts: 294
Joined: Fri Jun 27, 2014 7:45 pm

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by RegB » Mon Jul 07, 2014 3:42 pm

Mac The Knife wrote:The firmware they uploaded after their announcement was 38.4. Who knows?


I have this and SO MANY OTHER things to check when I do my build.
I will do my build when I get my kit, HOPEFULLY two days and a few hours from now.
I will try to contribute SOMETHING when I get to these settings.

The wait is the hard part, the wretched WAIT (-:

User avatar
bvandiepenbos
Printmaster!
Posts: 927
Joined: Thu Apr 05, 2012 11:25 pm
Location: Goshen, IN
Contact:

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by bvandiepenbos » Wed Jul 09, 2014 12:52 pm

Jimustanguitar wrote:Hey JJ, how far off was your machine before the firmware change? The carriage offset change in the new firmware didn't help my machine, I'm still off by about 19 thousandths.

New file from the GitHub, cleared EEPROM, loaded new firmware, recalibrated... What am I missing? Has this been the silver bullet for anyone else's machine?

Here are my results:



Jim, so did the firmware change fix your printer like SeeMe thought it would?
Anybody else had a measurable improvement with this fw change?
~*Brian V.

RostockMAX v2 (Stock)
MAX METAL "ShortyMAX"
MAX METAL Rostock MAX Printer Frame
NEMESIS Air Delta v1 & v2 -Aluminum delta printers
Rostock MAX "KITT" - Tri-Force Frame
GRABER i3 "Slim"

Polygonhell
ULTIMATE 3D JEDDI
Posts: 2430
Joined: Mon Mar 26, 2012 1:44 pm
Location: Redmond WA

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Polygonhell » Fri Jul 18, 2014 7:01 pm

I assume what you are seeing is basically this

Geometry error.jpg


I took the matlab model from here http://wp.boim.com/?p=67 and tried to reproduce the error you were seeing.
It's a combination of RodLength set incorrectly, then compensating for the error with DeltaRadius. In the image above I introduced a 1mm error in the RodLength, then tweaked DeltaRadius by 0.3mm to more or less compensate.
The issue is that both introduce doming errors, but because the errors aren't the same degree of function, if you compensate for one with the other you get the high order harmonics you can see in the graph above.

As to fixng it, I would start by trying to get an accurate measurement of the RodLength

User avatar
Jimustanguitar
ULTIMATE 3D JEDDI
Posts: 2631
Joined: Sun Mar 31, 2013 1:35 am
Location: Notre Dame area
Contact:

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Jimustanguitar » Mon Jul 21, 2014 8:44 pm

Polygonhell wrote:I assume what you are seeing is basically this


Pretty much, yep. For some reason, the proposed firmware fix didn't have an effect on my machine. Still waiting to hear from others.

Polygonhell
ULTIMATE 3D JEDDI
Posts: 2430
Joined: Mon Mar 26, 2012 1:44 pm
Location: Redmond WA

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Polygonhell » Mon Jul 21, 2014 10:54 pm

The firmware fix, would have just changed the printer radius, that may well be necessary, but the crux of the issue is it's two errors interacting. The first thing you need to do is accurately measure the the length of your arms, center of pivot to center of pivot. Once you have that accurate and in the firmware, it should just be a question of getting the delta radius correct.
Unfortunately I can't think of a good way to get both values correct iteratively.

snoman002
Prints-a-lot
Posts: 30
Joined: Thu May 01, 2014 11:19 pm

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by snoman002 » Mon Jul 21, 2014 10:56 pm

The firmware fix didn't have an effect because the parameters in the software for your machine don't match the actual measurements of the machine. Polygonhell showed something I mentioned previously.

On the same note, improper tower rotation will cause the low points between towers to be higher or lower than each other.

Tweaking rod length and radius should allow one to get to the point where the area between towers averages zero, from there tower radius could be tweaked to get close to a true zero.

Calibration using a large radius and small radius 6 point star, plus center, should give and indication of which direction to make changes (longer or shorter rod length).

RegB
Printmaster!
Posts: 294
Joined: Fri Jun 27, 2014 7:45 pm

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by RegB » Wed Jul 30, 2014 2:08 pm

Polygonhell wrote:I assume what you are seeing is basically this

Geometry error.jpg


I took the matlab model from here http://wp.boim.com/?p=67 and tried to reproduce the error you were seeing.
It's a combination of RodLength set incorrectly, then compensating for the error with DeltaRadius. In the image above I introduced a 1mm error in the RodLength, then tweaked DeltaRadius by 0.3mm to more or less compensate.
The issue is that both introduce doming errors, but because the errors aren't the same degree of function, if you compensate for one with the other you get the high order harmonics you can see in the graph above.

As to fixng it, I would start by trying to get an accurate measurement of the RodLength


How "accurate" would that need to be ?
I am thinking;
Take the rods off, U-joints and axles too.
Assemble pairs of arms, U-joints and axles with approximate spacing.
Lay them on the bed and heat to maybe 32C (measure above a running bed to know EXACTLY what temp).
Measure outside of axle to outside of axle, subtract axle diameter.
Maybe average it for the three pairs ?, maybe that would be UBER fussy ? (-:

User avatar
Jimustanguitar
ULTIMATE 3D JEDDI
Posts: 2631
Joined: Sun Mar 31, 2013 1:35 am
Location: Notre Dame area
Contact:

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Jimustanguitar » Wed Jul 30, 2014 2:15 pm

Delta radius is really the only variable out of the two. The arms are manufactured quite precisely. As a test, I picked up a set of the v2 clip style arms, and I can confidently report that this issue is happening regardless of which arms are used. V1, V2, and Trick Laser carbon arms all behave similarly.


Another note... I replaced my belts and pulleys and motors last night, so I'll know later today if any of those parts could have been out of tolerance.

Polygonhell
ULTIMATE 3D JEDDI
Posts: 2430
Joined: Mon Mar 26, 2012 1:44 pm
Location: Redmond WA

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Polygonhell » Wed Jul 30, 2014 3:21 pm

RegB wrote:
Polygonhell wrote:I assume what you are seeing is basically this

Geometry error.jpg


I took the matlab model from here http://wp.boim.com/?p=67 and tried to reproduce the error you were seeing.
It's a combination of RodLength set incorrectly, then compensating for the error with DeltaRadius. In the image above I introduced a 1mm error in the RodLength, then tweaked DeltaRadius by 0.3mm to more or less compensate.
The issue is that both introduce doming errors, but because the errors aren't the same degree of function, if you compensate for one with the other you get the high order harmonics you can see in the graph above.

As to fixng it, I would start by trying to get an accurate measurement of the RodLength


How "accurate" would that need to be ?
I am thinking;
Take the rods off, U-joints and axles too.
Assemble pairs of arms, U-joints and axles with approximate spacing.
Lay them on the bed and heat to maybe 32C (measure above a running bed to know EXACTLY what temp).
Measure outside of axle to outside of axle, subtract axle diameter.
Maybe average it for the three pairs ?, maybe that would be UBER fussy ? (-:


It needs to be accurate to 1/10th's of a mm
The easiest way would be to put pins through the arm ends, use a caliper to measure the distance and subtract off the diameter of one pin.
I'd do it, but I don't have a caliper big enough.

Post Reply

Return to “Troubleshooting”