Page 4 of 21
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Wed Jun 04, 2014 8:30 pm
by bdjohns1
I think the 6-point idea makes sense, based on the shape of those error plots linked/discussed upthread.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Thu Jun 05, 2014 9:07 am
by Jimustanguitar
Check out page 1 of this thread. A 6 point test is where this all started.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Thu Jun 05, 2014 6:05 pm
by snoman002
Jimustanguitar wrote:Check out page 1 of this thread. A 6 point test is where this all started.
It sure did, but that's beside the point. We are recommending that the previously mentioned adjustment routine be implemented with a 6 point star instead of a quadrant point check.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Fri Jun 06, 2014 8:12 am
by Jimustanguitar
snoman002 wrote:We are recommending that the previously mentioned adjustment routine be implemented with a 6 point star instead of a quadrant point check.
I'd be very curious if Guanu did this on the Orions if he'd catch any red handed machines and be able to help us track it down. Check out the GCode that I posted earlier in this thread. That would be a good starting point.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Sat Jun 07, 2014 8:51 am
by kirbymills
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Sat Jun 07, 2014 5:18 pm
by snoman002
See, to me that makes me think the radius of the upper circle is off.
The error is roughly consistent between towers, it is always the same direction, and happens in the same spots.
Is there two radius to define? There should be one for the effector and one for the cheepskates, unless a single point was used for the effector and a mock radius used for the upper pivots.
Kirbymills, I'm going to suggest one thing. Change the length of your arms in firmware, then tweak the radius until its level between center and in front of one of the towers. See how the error between towers changes. If it gets worse then tweak the length of the arms the other way in firmware, if its better (or went the right direction but too far) then you went the right way and just need to add or subtract from your tweak to dial it in.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Sat Jun 07, 2014 5:36 pm
by snoman002
OK, before I loose my thought here.
The firmware likely considers the effector a single point, and the radius is the radius of the pivots on the cheapskates. It then uses geometry to determine where the cheapskates need to be to put the print head in a certain position.
Arm length and radius can be define in such a way where center and DIRECTLY IN FRONT OF A TOWER are the same, but if this is not reality then the error would show up between towers where only two sets of arms really determine z height.
If the error exactly between towers is the same at all three points but high or low compared to directly in front of a tower then its the radius/arm length that's off.
If the error between towers is all in one direction but different then the arm length/radius needs to be tweaked AND the rotation of the towers.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Sat Jun 07, 2014 10:50 pm
by 626Pilot
JohnStack wrote:626Pilot, of course; however, a two minute check is worth trying the reflash.
I have an Azteeg X3 Pro that I just finished soldering together, so I will try that exact thing when I get around to installing it.
snoman002 wrote:The previously mentioned alignment method sounds interesting, but wow what a time consuming process.
It's an ordeal, but it saves SO much time compared to trying different ad-hoc things. It's a few hours as opposed to days/weeks of trying different tweaks.
Ultimately if it is proven to be an alignment problem someone (someone smarter than myself) could program a routine that measures variance and calculates the optimal settings for calibration. Ultimately it could all be implemented in firmware. Touch center and a 6 point star, input values, firmware calculates the changes needed, run again and input values, firmware calculates the change and adjusts again (radius, rotation etc), run a third time... 4 iterations should get you DANG close to perfect. Unfortunately I only know the fuzzy edges of the math needed
There are some touch probes (one of them is in my sig) but so far Repetier hasn't demonstrated an ability to do a proper calibration with them.
I see in the YT comments you are thinking about getting a V2 upgrade kit. Don't. Another guy has this same problem, and when he installed the upgrade, he still had the same problem.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Sat Jun 07, 2014 11:00 pm
by snoman002
Not sure if a touch probe or a dial indicator is more work/cost. I was thinking that a gcode of the 6 point star (plus center) could be run with a dial indicator and the values entered, the software compares the values and adjusts the settings. Do this 2 or 3 times and the errors should be taken care of.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Sun Jun 08, 2014 12:22 pm
by Polygonhell
snoman002 wrote:Not sure if a touch probe or a dial indicator is more work/cost. I was thinking that a gcode of the 6 point star (plus center) could be run with a dial indicator and the values entered, the software compares the values and adjusts the settings. Do this 2 or 3 times and the errors should be taken care of.
There is a branch of Marlin that does this, though it uses more than 6 samples, as discussed a couple of pages back the difficulty is attributing the error to the actual cause. It could be bad tower placement or a combination of errors in arm length and radius.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Sun Jun 08, 2014 5:39 pm
by snoman002
Polygonhell wrote:snoman002 wrote:Not sure if a touch probe or a dial indicator is more work/cost. I was thinking that a gcode of the 6 point star (plus center) could be run with a dial indicator and the values entered, the software compares the values and adjusts the settings. Do this 2 or 3 times and the errors should be taken care of.
There is a branch of Marlin that does this, though it uses more than 6 samples, as discussed a couple of pages back the difficulty is attributing the error to the actual cause. It could be bad tower placement or a combination of errors in arm length and radius.
Sure, and I've read the auto calibration bounty thread, last I saw though it was still derailed trying to invent a simple touch probe system.
I understand the difficulty in determining where exactly the error lays. I know that with certain points being measured and compared the errors should be visable. Have the points that should be measured been identified? I would imagine a 6 point star and center should tell radius, arm length and tower rotation. Three more points halfway between a tower and center might be valuable as well.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Sun Jun 08, 2014 8:00 pm
by Flateric
I did the 626pilot magnetic touch probe with my x5 last night using the new automatic bed leveling and automatic radius features and they work really well. The firmware essentially continues to probe, test, adjust, re-test and repeat it's internal settings until a difference in z height between all sampled points is equal to or less than 0.03mm.
It takes some time and I actually repeated the process 2 times due to some bed changes I made after the first auto-calibration. 1st time around I would guess it ran through the whole sequence around 8 times atleast.
Second time around it did the sequence more than this but I walked away and just left it.
At the end you just do a M500 to write the volitile values out to the firmware and your down.
It's a completely hands off process other than the M500. Really a nice relief for sure. Start it walk away and write it out when you come back.
I did make really sure my geometry values were smack on target before hand however and have taken extreme pains to ensure my mag arms are all exactly the same length and effector is the same spacing as carriages for each pair of arms.
I'm also using linear guides for the carriages to travel on.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Wed Jun 11, 2014 12:31 am
by 626Pilot
Flateric wrote:I did the 626pilot magnetic touch probe with my x5 last night using the new automatic bed leveling and automatic radius features and they work really well. The firmware essentially continues to probe, test, adjust, re-test and repeat it's internal settings until a difference in z height between all sampled points is equal to or less than 0.03mm.
What is an x5 and where did you get the firmware? I tried using Repetier's bed leveling last year, same touch probe, and found it always produced a weird slant (high to the left, digging into the glass to the right) that was worse than a hand-tuned calibration. I opened a ticket but it never went anywhere.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Wed Jun 11, 2014 5:05 am
by TFMike
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Wed Jun 11, 2014 11:11 am
by Flateric
626Pilot wrote:Flateric wrote:I did the 626pilot magnetic touch probe with my x5 last night using the new automatic bed leveling and automatic radius features and they work really well. The firmware essentially continues to probe, test, adjust, re-test and repeat it's internal settings until a difference in z height between all sampled points is equal to or less than 0.03mm.
What is an x5 and where did you get the firmware? I tried using Repetier's bed leveling last year, same touch probe, and found it always produced a weird slant (high to the left, digging into the glass to the right) that was worse than a hand-tuned calibration. I opened a ticket but it never went anywhere.
X5 is the Azteeg X5, it's based of the same hardware as the smoothieware offering, ARM based. Running smoothie firmware. Nice probe mount for the Hall-o BTW.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Wed Jun 11, 2014 2:34 pm
by TFMike
I'd take a gander at this post, too:
http://forum.seemecnc.com/viewtopic.php ... 274#p12274
Bill Havins and mrbi11 seem to be on the cutting edge of printing on the edge.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Mon Jun 16, 2014 11:16 pm
by 626Pilot
Flateric wrote:I did the 626pilot magnetic touch probe with my x5 last night using the new automatic bed leveling and automatic radius features and they work really well. The firmware essentially continues to probe, test, adjust, re-test and repeat it's internal settings until a difference in z height between all sampled points is equal to or less than 0.03mm.
I just ordered an X5 over the weekend. I HAVE to see this. It's amazing that it costs LESS than the Arduino-based controllers! I guess Atmel hasn't figured out that they need to charge less for their early 1980s technology.
I'm also using linear guides for the carriages to travel on.
What's that?
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Tue Jun 17, 2014 4:35 am
by Flateric
Rather than using a DIY assembled carriage rail solution I am using NSK linear rails, or correctly called linear guides due to their shape being not a round rail but an extruded profile that the bearings travel on.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Tue Jun 17, 2014 11:43 pm
by 626Pilot
Ah, so you haven't tried the X5 on a Rostock MAX? I hope its logic is good enough to fix mine.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Wed Jun 18, 2014 6:45 am
by Flateric
Not the X5, but I do use a smoothieware board on my max exclusively. Works great there too. Same code and firmware.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Wed Jun 18, 2014 11:20 pm
by 626Pilot
Mine came in today. Do you have any advice for a first time setup? Does Repetier have the ability to modify EEPROM stuff directly or am I forced to edit an SD card?
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Thu Jun 19, 2014 5:24 am
by Flateric
My tips for this board are to be sure to use the "download as zip" function from github when getting any kind of update regarding the smoothie or else you will find that the saved text based config file may lock up your smoothie and prevent it from booting.
No repetier cannot modify any of the firmware values and you are required to edit the text file on the sd card. Which is not that big a hassel since it re-reads the config upon every boot so there is no real "reflashing" procedure really.
Just reboot your boardc and your new config is read, but be sure to disconnect repetier from the board before rebooting it or you'll be required to reboot it again to allow repetier to reconnect.
I also have a cooling fan blowing across the board to keep it nice and cool, although probably not required since the smoothie X5 comes with such a nice aluminium cooler stock.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Fri Jun 20, 2014 3:10 am
by 626Pilot
Do you know if there's any kind of effort to allow Repetier to edit the config file values? I'm going to miss being able to do that.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Sun Jun 22, 2014 12:31 am
by Flateric
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.
Re: Unsolved Mystery. Weird Z0 behavior around build perimet
Posted: Sun Jun 22, 2014 10:08 am
by Eaglezsoar
Flateric wrote:I did the 626pilot magnetic touch probe with my x5 last night using the new automatic bed leveling and automatic radius features and they work really well. The firmware essentially continues to probe, test, adjust, re-test and repeat it's internal settings until a difference in z height between all sampled points is equal to or less than 0.03mm.
It takes some time and I actually repeated the process 2 times due to some bed changes I made after the first auto-calibration. 1st time around I would guess it ran through the whole sequence around 8 times atleast.
Second time around it did the sequence more than this but I walked away and just left it.
At the end you just do a M500 to write the volitile values out to the firmware and your down.
It's a completely hands off process other than the M500. Really a nice relief for sure. Start it walk away and write it out when you come back.
I did make really sure my geometry values were smack on target before hand however and have taken extreme pains to ensure my mag arms are all exactly the same length and effector is the same spacing as carriages for each pair of arms.
I'm also using linear guides for the carriages to travel on.
Is the the new automatic bed leveling and automatic radius features built into the firmware for the X5?