Repetier Firmware

[kwixson]

So the SeeMeCNC team came up last night and two of us got new firmware for our bots. The other Kevin had a problem where we originally thought we could set the steps/mm setting in the EEPROM, but it turns out that doesn't work and causes the effector to move in a bowl shaped area when it's supposed to move along a flat plane. My bot didn't reveal this errant behavior until I got it home. So, I wasn't paying attention when they fixed the other Kevin's machine.

John: What did you do to fix the other Kevin's machine? I tried finding the steps/mm setting in Configuration.h and changed the default 106.66 in XY and Z to 80.0 for my 20-tooth pulleys, but it didn't work.

[Flateric]

This is exactly the same question I came in search of answers to myself today. If I stay near the center of the build area all is good. But out at the edges of it my nozzle seems to pull up slightly. Enough to cause adhesion problems with long narrow parts at the end.

I believe it's something to do with the delta values but I only know enough to be dangerous not helpful, so I will wait for your answer as well as keep researching before changing anything first.

[Polygonhell]

This is exactly the same question I came in search of answers to myself today. If I stay near the center of the build area all is good. But out at the edges of it my nozzle seems to pull up slightly. Enough to cause adhesion problems with long narrow parts at the end.

I believe it's something to do with the delta values but I only know enough to be dangerous not helpful, so I will wait for your answer as well as keep researching before changing anything first.

You need to adjust the DELTA_RADIUS setting in the firmware, this can't be done from EEPROM.
I usually just change it by 0.5 mm and see if it's better or worse then do a binary search for the correct value.

[Flateric]

I found this diagram that really helped me understand all the values and what they apply to more clearly.

https://plus.google.com/photos/11099771 ... 3794147394

[kwixson]

I discovered the main culprit in my case was related to this section here at about line 96 of configuration.h

#if DELTA_DRIVE_TYPE == 0
#define BELT_PITCH 2 // Pitch in mm of drive belt. GT2 = 2mm T2.5=2.5 etc...
#define PULLEY_TEETH 20 // how many teeth on the timing pulley
#define PULLEY_CIRCUMFERENCE (BELT_PITCH * PULLEY_TEETH)

The PULLY_TEETH setting is 20 for the newest machines. I'll have to investigate the delta radius issue and see if that's something I should mess with.

[theverant]

The PULLY_TEETH setting is 20 for the newest machines. I'll have to investigate the delta radius issue and see if that's something I should mess with.

w-w-wha? Pully teeth need to be adjusted? Any way to know what the value should be without actually pulling apart the machine and counting the teeth?

[Polygonhell]

The PULLY_TEETH setting is 20 for the newest machines. I'll have to investigate the delta radius issue and see if that's something I should mess with.

w-w-wha? Pully teeth need to be adjusted? Any way to know what the value should be without actually pulling apart the machine and counting the teeth?

If the pulley is metal it's 15 if not it's 20.
But if you command it to move 10mm and it does then it's correct.

[johnoly99]

Hey all.

So yeah, we were up in Kalamazoo last night, and I threw repetier firmware on these guys machines. Kwixson has 20 tooth pulleys, and i set his firmware up for that, with the pulley teeth set to 20, worked pretty great

Now, here's the weird part. The other machine had our 15 tooth pulleys on it. I flashed it with the 20 tooth steps/per/mm, but we went in and changed it in eeprom from repetier. HOWEVER, we were chasing a massive delta radius issue, that took almost 25mm to get it planing flat!!! That didn't seem right, so i started digging. Turns out, and I havn't confirmed it yet, that you HAVE to have your pulleys defined properly in the firmware, as it uses that value somewhere else in the firmware for delta calculations. When we changed his firmware define to 15 tooth pulleys instead of 20 (even though the eeprom had the correct steps_per_mm), the delta radius was back to normal?

Polygon, ever heard of that issue before? I'll keep diggin, but initial thoughts are that the delta calcs grab that figure as well, not just for driving form gcode

[Polygonhell]

Hey all.

So yeah, we were up in Kalamazoo last night, and I threw repetier firmware on these guys machines. Kwixson has 20 tooth pulleys, and i set his firmware up for that, with the pulley teeth set to 20, worked pretty great

Now, here's the weird part. The other machine had our 15 tooth pulleys on it. I flashed it with the 20 tooth steps/per/mm, but we went in and changed it in eeprom from repetier. HOWEVER, we were chasing a massive delta radius issue, that took almost 25mm to get it planing flat!!! That didn't seem right, so i started digging. Turns out, and I havn't confirmed it yet, that you HAVE to have your pulleys defined properly in the firmware, as it uses that value somewhere else in the firmware for delta calculations. When we changed his firmware define to 15 tooth pulleys instead of 20 (even though the eeprom had the correct steps_per_mm), the delta radius was back to normal?

Polygon, ever heard of that issue before? I'll keep diggin, but initial thoughts are that the delta calcs grab that figure as well, not just for driving form gcode

I don't think that's true, but I may have missed it in the firmware.
There are literally only 3 values that matter, steps per, delta radius and whatever repetier calls arm length. There are a lot of other values that go into delta radius, but it's the only vaue used in the calculation, the other values as far as I can tell are used directly.

EDIT: John is correct, it is in fact the case, The Steps per mm must be correct in the firmware and match the values in the EEPROM for the delta code to work. I have filed an issue on the repetier github.

[kwixson]

When I went in and looked it was set up for 15 tooth pulleys by default. I had to change it to 20 to make it work. It's been working great today, though I would like to hear more about this delta radius correction. My Onyx does seem to bow up in the middle, and I've read that's not unusual. It changes shape when heated, I hear. Also looking to get very accurate results. Today a 20x20 calibration cube came out 19.6x19.6. Good consistency, but still a bit off.

So, I guess my followup question is what all are the things I need to do in firmware to make this big bad printer its most badass self?

[Flateric]

I don't feel you should adjust your values to correct for Onyx bow. This bow will be different for different temperatures and will change over the age of the machine and also be affected by ambiant tempuratures.

Rather I think you should try to correct the bowing issue through the use of an aluminium plate or glass and do everything you can to adjust for a flat surface and calibrate assuming the surface is flat.

Trying to calibrate to the bow of the Onyx will be un-realistic for the reasons I list above and make you crazy going in and out of the firmware endlessly trying to compansate for something that will never stay the same from day to day or even print to print for that matter.

This is my thinking anyways. Correct the bow rather than try to work with it.

[Polygonhell]

I don't think that's true, but I may have missed it in the firmware.
There are literally only 3 values that matter, steps per, delta radius and whatever repetier calls arm length. There are a lot of other values that go into delta radius, but it's the only vaue used in the calculation, the other values as far as I can tell are used directly.

I take this back.
I looked at the code this morning and AXIS_STEPS_PER_MM is used directly (rather than the stored EEPROM value) to calculate a constant used in the delta motion.
That means that it MUST be correct in the firmware, not just the EEPROM.
This is probably the issue people seeing odd motion at the edge of travel are seeing.

[Polygonhell]

I don't feel you should adjust your values to correct for Onyx bow. This bow will be different for different temperatures and will change over the age of the machine and also be affected by ambiant tempuratures.

Rather I think you should try to correct the bowing issue through the use of an aluminium plate or glass and do everything you can to adjust for a flat surface and calibrate assuming the surface is flat.

Trying to calibrate to the bow of the Onyx will be un-realistic for the reasons I list above and make you crazy going in and out of the firmware endlessly trying to compansate for something that will never stay the same from day to day or even print to print for that matter.

This is my thinking anyways. Correct the bow rather than try to work with it.

DELTA RADIUS is not designed to correct for bow in the onyx. You should have a glass sheet or similar flat surface to calibrate against.
It 's to correct for manufacturing variances, if it is not exactly right the head will move in an arc over the build plate rather than horizontally.
Mine has a correction of 0.6mm in it, but it's likely everyones is slightly different.

[x95braat]

The 'other' Kevin here (Kevin Wixom started the thread). John had adjusted the firmware as mentioned. We could not alter just the delta values to fix the issue. We were seeing an excessive amount of convex motion before the new firmware and the adjustments. I now have the build platform leveled out and all is good. I spent some time with the extruder adjustments on Sunday and should be ready to further my test prints this evening.

I was going to review the code to better familiarize myself with what is going on to create the issue once I had the rest of the settings worked out.

Kevin - maybe we should get together again with the machines side by side and compare the firmware and Repetier settings.

[cambo3d]

there seems to be a lot of discrepancies in comparing johnoly's repetier firmware that's having trouble, compared to polygonhells repetier firmware that works.

using winmerge, I found several mistakes. is john starting from scratch here? other than the pulley thing, there's a lot of mismatch.

[Polygonhell]

there seems to be a lot of discrepancies in comparing johnoly's repetier firmware that's having trouble, compared to polygonhells repetier firmware that works.

using winmerge, I found several mistakes. is john starting from scratch here? other than the pulley thing, there's a lot of mismatch.

He might be pulling from the current release I haven't merged the 0.82 changes in (I couldn't see anything worth the effort when I looked at the changes), I also manually configure the LCD, since there was no direct support for the rostock LCD when I first set it up. I think there is now.

The having to have the steps match in the Firmware and in the EEPROM is an issue for both builds, I filed a bug on git hub this morning, he's going to try and fix it for the 0.90 release.

[Flateric]

Poly, you don't get this enough, Thanks!

I appreciate your puttig up with my endless stupid questions and cannot say eough how much you have helped me through all this as you have others too.

Seriously your effort make a huge difference in this community.

I have no clue what you do in real life but I figure you for some kinda genius type tech guy, lol.

[Eaglezsoar]

Poly, you don't get this enough, Thanks!

I appreciate your puttig up with my endless stupid questions and cannot say eough how much you have helped me through all this as you have others too.

Seriously your effort make a huge difference in this community.

I have no clue what you do in real life but I figure you for some kinda genius type tech guy, lol.

I'll second that.