Page 5 of 21

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Mon Jun 23, 2014 6:48 pm
by 626Pilot
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.

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Wed Jun 25, 2014 3:49 pm
by jjjohnson
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-92PSN ... e=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

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Wed Jun 25, 2014 4:35 pm
by guanu
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

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Wed Jun 25, 2014 6:32 pm
by apostoly
Cant wait to test this out tonight!!

Thanks for the info guys!!

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Wed Jun 25, 2014 7:04 pm
by bvandiepenbos
very interesting find JJ.
But I thought Repetier no longer uses those values for "Carriage Offset" and "Smooth Rod Offest" ???

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Wed Jun 25, 2014 7:14 pm
by Polygonhell
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)

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Wed Jun 25, 2014 11:14 pm
by bvandiepenbos
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 ?

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Thu Jun 26, 2014 7:16 am
by guanu
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

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Thu Jun 26, 2014 8:17 am
by bdjohns1
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.

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Thu Jun 26, 2014 2:30 pm
by Polygonhell
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)

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Thu Jun 26, 2014 9:36 pm
by Jimustanguitar
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:

[youtube]http://www.youtube.com/watch?v=ej_n71nQ5-k[/youtube]

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Sat Jun 28, 2014 8:55 pm
by Mac The Knife
Before I wipe my firmware settings out again, How do I retrieve them from the printer, then reupload them after I make the change?

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Sun Jun 29, 2014 8:52 am
by Mac The Knife
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.

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Sun Jun 29, 2014 11:14 am
by Mac The Knife
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.

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Mon Jul 07, 2014 7:49 am
by RegB
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

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Mon Jul 07, 2014 12:22 pm
by Mac The Knife
The firmware they uploaded after their announcement was 38.4. Who knows?

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Mon Jul 07, 2014 3:42 pm
by RegB
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 (-:

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Wed Jul 09, 2014 12:52 pm
by bvandiepenbos
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:

[youtube]http://www.youtube.com/watch?v=ej_n71nQ5-k[/youtube]
Jim, so did the firmware change fix your printer like SeeMe thought it would?
Anybody else had a measurable improvement with this fw change?

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Fri Jul 18, 2014 7:01 pm
by Polygonhell
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" onclick="window.open(this.href);return false; 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

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Mon Jul 21, 2014 8:44 pm
by Jimustanguitar
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.

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Mon Jul 21, 2014 10:54 pm
by Polygonhell
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.

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Mon Jul 21, 2014 10:56 pm
by snoman002
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).

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Wed Jul 30, 2014 2:08 pm
by RegB
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" onclick="window.open(this.href);return false; 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 ? (-:

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Wed Jul 30, 2014 2:15 pm
by Jimustanguitar
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.

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Posted: Wed Jul 30, 2014 3:21 pm
by Polygonhell
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" onclick="window.open(this.href);return false; 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.