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.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.
Unsolved Mystery. Weird Z0 behavior around build perimeter.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Questions? Ask in a thread - PMs are off.
AI Calibration | Dimensional Accuracy Calibration | Hand-Tune your PID | OctoPi + Touchscreen setup | My E3D hot end mount, Z probe, fan ducts, LED ring mount, filament spool holder, etc.
AI Calibration | Dimensional Accuracy Calibration | Hand-Tune your PID | OctoPi + Touchscreen setup | My E3D hot end mount, Z probe, fan ducts, LED ring mount, filament spool holder, etc.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
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
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
JJ
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
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
upload the firmware and recalibrate the machine...
Guanu
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Cant wait to test this out tonight!!
Thanks for the info guys!!
Thanks for the info guys!!
- 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
very interesting find JJ.
But I thought Repetier no longer uses those values for "Carriage Offset" and "Smooth Rod Offest" ???
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"
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"
-
- ULTIMATE 3D JEDI
- Posts: 2430
- Joined: Mon Mar 26, 2012 1:44 pm
- Location: Redmond WA
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
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)
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)
Printer blog http://3dprinterhell.blogspot.com/
- 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
That's how I understand it also.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)
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"
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"
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
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
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
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).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)
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.
-
- ULTIMATE 3D JEDI
- Posts: 2430
- Joined: Mon Mar 26, 2012 1:44 pm
- Location: Redmond WA
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
I grep-ed the source code for it before I posted, the above line is the only place it's used.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
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)
Printer blog http://3dprinterhell.blogspot.com/
- Jimustanguitar
- ULTIMATE 3D JEDI
- Posts: 2631
- Joined: Sun Mar 31, 2013 1:35 am
- Location: Notre Dame area
- Contact:
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
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]
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]
-
- ULTIMATE 3D JEDI
- Posts: 1409
- Joined: Sun May 11, 2014 6:18 pm
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
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
Eris
Folger Tech FT-5 R2
-
- ULTIMATE 3D JEDI
- Posts: 1409
- Joined: Sun May 11, 2014 6:18 pm
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
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
Eris
Folger Tech FT-5 R2
-
- ULTIMATE 3D JEDI
- Posts: 1409
- Joined: Sun May 11, 2014 6:18 pm
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
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
Eris
Folger Tech FT-5 R2
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
The article on the SeeMeCNC home page seems to think it should be 37.5Mac 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.
-
- ULTIMATE 3D JEDI
- Posts: 1409
- Joined: Sun May 11, 2014 6:18 pm
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
The firmware they uploaded after their announcement was 38.4. Who knows?
R-Max V2
Eris
Folger Tech FT-5 R2
Eris
Folger Tech FT-5 R2
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
I have this and SO MANY OTHER things to check when I do my build.Mac The Knife wrote:The firmware they uploaded after their announcement was 38.4. Who knows?
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 (-:
- 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
Jim, so did the firmware change fix your printer like SeeMe thought it would?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]
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"
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"
-
- ULTIMATE 3D JEDI
- Posts: 2430
- Joined: Mon Mar 26, 2012 1:44 pm
- Location: Redmond WA
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
I assume what you are seeing is basically this
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
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
Printer blog http://3dprinterhell.blogspot.com/
- Jimustanguitar
- ULTIMATE 3D JEDI
- Posts: 2631
- Joined: Sun Mar 31, 2013 1:35 am
- Location: Notre Dame area
- Contact:
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
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 wrote:I assume what you are seeing is basically this
-
- ULTIMATE 3D JEDI
- Posts: 2430
- Joined: Mon Mar 26, 2012 1:44 pm
- Location: Redmond WA
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
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.
Unfortunately I can't think of a good way to get both values correct iteratively.
Printer blog http://3dprinterhell.blogspot.com/
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
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).
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
How "accurate" would that need to be ?Polygonhell wrote:I assume what you are seeing is basically this
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
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 ? (-:
- Jimustanguitar
- ULTIMATE 3D JEDI
- Posts: 2631
- Joined: Sun Mar 31, 2013 1:35 am
- Location: Notre Dame area
- Contact:
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
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.
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.
-
- ULTIMATE 3D JEDI
- Posts: 2430
- Joined: Mon Mar 26, 2012 1:44 pm
- Location: Redmond WA
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
It needs to be accurate to 1/10th's of a mmRegB wrote:How "accurate" would that need to be ?Polygonhell wrote:I assume what you are seeing is basically this
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
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 ? (-:
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.
Printer blog http://3dprinterhell.blogspot.com/