PRINTER_RADIUS, EEPROM bug, insanity

[theverant]

Hey all,

I'm using SMCNC's Repetier firmware and I'm trying to calibrate my printer, but changes I make to PRINTER_RADIUS don't seem to make a difference unless I turn off EEPROM. When I turn off EEPROM, however, the Z0 is about 25mm above the print bed. Reenabling it seems to give inconsistant results with the changes to PRINTER_RADIUS.

Anyone having issues with this step of calibration? I'm about to lose my mind over this.

Cheers,
Nathan

[bvandiepenbos]

yes, I am aware of a bug in firmware related to EEPROM.
Our issue is accel/jerk settings getting changed and/or not staying at what you want... causing shifts in print.
John is working on it. right John?

[foshon]

Have you tried sending M500 after making changes to the EEProm?

[theverant]

yes, I am aware of a bug in firmware related to EEPROM.
Our issue is accel/jerk settings getting changed and/or not staying at what you want... causing shifts in print.
John is working on it. right John?

Thanks for the quick reply.

So how can I calibrate my printer if I can't properly adjust PRINTER_RADIUS - should I use polygonhell's firmware until John sorts out the problems with SMCNC's?

Have you tried sending M500 after making changes to the EEProm?

I'm trying to change the firmware, but nothing happens when I adjust PRINTER_RADIUS. I'm not sure that M500 will do anything since that value isn't part of the EEPROM. Or have I missed something? In any case, I will try it on Monday when I have access to the printer again. Thanks for the idea.

Cheers,
Nathan

[foshon]

Whenever I update my firmware my Repetier host/printer acts goofy. For whatever reason M500 seems to get everything jiving again.

[Polygonhell]

First I assume that there I no entry for printer radius in the EEPROM settings in whatever version of repetier John is currently using?
If there is change it there.
Second when you say no effect how are you measuring it, and how much doming do you have that you are trying to remove?

[Eaglezsoar]

First I assume that there I no entry for printer radius in the EEPROM settings in whatever version of repetier John is currently using?
If there is change it there.
Second when you say no effect how are you measuring it, and how much doming do you have that you are trying to remove?

If I were to use your version of Repetier, what would I need to change to remove your personal modifications that would prevent its use
for the average user?

[foshon]

Ah, I see. I misunderstood. I thought you were losing eeprom settings after firmware changes. If you are going to roll with out the eeprom you would need to change your firmware with the settings you were using in the eeprom, no?

[Polygonhell]

If I were to use your version of Repetier, what would I need to change to remove your personal modifications that would prevent its use
for the average user?

Mostly just the thermistor selection, but it's set up for the original Shipping kits with the early RAMBO board, and metal pulleys. If you don't have those, you need to adjust all the steps per etc, and probably the digipots values.
I recommend using Johns, because it's set up for what are now the bulk of the shipped printers and I don't actively update mine unless there is something I see that I think actually adds value to the release.

[theverant]

Ah, I see. I misunderstood. I thought you were losing eeprom settings after firmware changes. If you are going to roll with out the eeprom you would need to change your firmware with the settings you were using in the eeprom, no?

Yeah, you are correct there. A lightbulb came on and I was trying to do that after i posted. Just manually trying to find things that are in the eeprom which correlate to the config in firmware. I still wasn't all the way there. One thing I did notice is that the Max was way quieter without the eeprom settings. Maybe it was slightly slower? But, it wasn't drastically slower. Would be nice to have a rostock - repetier guide, will have to find some docs.

[geneb]

I've got over 160 hours on Orange Menace and it uses the "RepeteirMAX" firmware from github. The chances that the firmware is at fault is very, very small.

There is no PRINTER_RADIUS setting available in firmware. If there was, I would have mentioned it in the docs. (now watch - someone has added it and not told me...)

The instructions on setting the PRINTER_RADIUS were inverted - please see the current rev of the docs - v1.10, page 157.

g.

[theverant]

I've got over 160 hours on Orange Menace and it uses the "RepeteirMAX" firmware from github. The chances that the firmware is at fault is very, very small.

There is no PRINTER_RADIUS setting available in firmware. If there was, I would have mentioned it in the docs. (now watch - someone has added it and not told me...)

The instructions on setting the PRINTER_RADIUS were inverted - please see the current rev of the docs - v1.10, page 157.

g.

First, thanks for chiming in on this, the more info I can get the faster I'll figure this out.

I'm fully willing to take responsibility for screwing something up - I'm not trying to blame anyone, but figure out what I'm doing wrong.

But, I am confused that you say there is no PRINTER_RADIUS in the firmware - your (fantastic) manual describes using PRINTER_RADIUS in the configuration.h of Repetier firmware to change the concave/convex-edness on page 158. This is what I was trying to do, but changes to that value produced no predictable lowering of the print head (it was too high in the centre after levelling the edges). A couple people in #reprap told me there was a bug with EEPROM being on and certain firmware values not taking hold as they should, which is why I started playing with that. Playing with toggling EEPROM off, power cycling, toggling it back on did produce some results, but nothing reproducible or predictable.

As a side note, the SMCNC's "downloads" section of their web page points to an older version of the doc (1.09) which I had been using. Some hunting brought me to the current version, though I'm not sure they are different for my purposes.

As a second side note, there is a slight typo last paragraph, pg 158 the bolded PRINTER_RADIUS is spelled PRINTER_RAIDUS

I'll poke it more tomorrow and see if I can't get a proper result.

Cheers,
Nathan

[theverant]

It might also be helpful to note that I am using Repetier Host in Mac OSX - v. 0.56. I don't know if this version lags behind the Windows/Linux version, but the version number certainly does. Perhaps this is introducing an extra layer of complication?

Are the people responding having not seen any weirdness using Windows or Linux?

Cheers,
N

[Polygonhell]

The host software has no impact on the move,end, it just commands positions.
I run on a Mac, the reason the version number lags is it's a very different piece of software, originally the Mac version was just the PC/Linux version, running on Mono, but Mono is a bit shit on Macs, so he wrote a native app which is maintained independently.

[geneb]

My apologies. I wrote "firmware" when I should have written "EEPROM". There's no way to adjust PRINTER_RADIUS from the EEPROM table. (But I certainly wish there was!)

The spelling and other errors should be corrected in the 1.10 version of the manual.

I could understand a possible EEPROM bug if PRINTER_RADIUS was something you could manipulate via the EEPROM table, but it's not. It's a compile-time adjustment and AFAIK, cannot be adjusted outside of that.

I'm not quite sure what you've got going on, but I'd recommend starting from scratch and fresh firmware. Tweak only _one_ thing at a time.

g.

[theverant]

My apologies. I wrote "firmware" when I should have written "EEPROM". There's no way to adjust PRINTER_RADIUS from the EEPROM table. (But I certainly wish there was!)

The spelling and other errors should be corrected in the 1.10 version of the manual.

I could understand a possible EEPROM bug if PRINTER_RADIUS was something you could manipulate via the EEPROM table, but it's not. It's a compile-time adjustment and AFAIK, cannot be adjusted outside of that.

I'm not quite sure what you've got going on, but I'd recommend starting from scratch and fresh firmware. Tweak only _one_ thing at a time.

g.

Typos are a fact of life

I did start over, just calibrating the towers right now. They were quite a lower than the centre - by ~ 5mm consistently. Any idea what would make them be so far off? My print surface seems to be quite flat, certainly not off by that much.

[theverant]

Yeah, I've redone the towers, they were all consistently low, and now and that they are done the print head is ~ 6.5mm above. Is this something horribly wrong mechanically? The towers weren't hard to get nailed down, and they seem to be very close as far as the amount of screw adjustment. Is this too much to compensate for in the firmware?

[geneb]

So basically, you're saying that if you start from the base of one tower and transit to the base of another tower, the hot end scribes a huge arc in the air as it travels?

g.

[theverant]

So basically, you're saying that if you start from the base of one tower and transit to the base of another tower, the hot end scribes a huge arc in the air as it travels?

g.

That's exactly what happens, basically it thinks my build surface is a giant dome. Extremely frustrating.

[geneb]

I would really recommend that you start with a new configuration.h file, bump the EEPROM value to make Repetier behave and then start from scratch.

g.

[theverant]

I would really recommend that you start with a new configuration.h file, bump the EEPROM value to make Repetier behave and then start from scratch.

g.

Yeah, I did start with a new SMCNC firmware.

Changes I made so far:

#define EXT0_STEPS_PER_MM 92.4 | Set to 584 for Steve's Extruder

#define INVERT_X_DIR true | was false, motors were reversed
#define INVERT_Y_DIR true
#define INVERT_Z_DIR true

Is there a way to reset the EEPROM? Is that what you are recommending? I did restart the calibration process by remeasuring the centre, etc. I didn't remember changing anything else, but I may have when I first put together the machine a few months ago (I had it almost working then but had to leave it to do other things).

[Polygonhell]

In configuration.h there is a define for EEPROM_MODE, if it's set to 0 the EEPRPM is disabled, if it is set to any positive number other than the one it was set to the last time the EEPROM was in use it will clear the existing EEPROM settings. The comment directly above the setting states this.

When you upload the new firmware you should just increase the value by 1 and it will reset the EEPROM values to match the firmware.

[theverant]

In configuration.h there is a define for EEPROM_MODE, if it's set to 0 the EEPRPM is disabled, if it is set to any positive number other than the one it was set to the last time the EEPROM was in use it will clear the existing EEPROM settings. The comment directly above the setting states this.

When you upload the new firmware you should just increase the value by 1 and it will reset the EEPROM values to match the firmware.

Yeah, the comment says

Code: Select all

If you later want to overwrite your current eeprom settings with configuration defaults, just change EEPROM_MODE to 0 and upload, then power cycle your board.

So I guess I'll give that a shot tomorrow AM.

[Polygonhell]

There is a second comment that reads

Set the EEPROM_MODE to 0 if you always wan't to use the settings in this configuration file. If not,
set it to a value not stored in the first EEPROM-byte used. If you later want to overwrite your current
eeprom settings with configuration defaults, just select an other value. On the first call to epr_init()
it will detect a mismatch of the first byte and copys default values into EEPROM. If the first byte
matches, the stored values are used to overwrite the settings.

IMPORTANT: With mode <>0 some changes in configuration.h are not set any more, as they are
taken from the EEPROM.

I don't think just setting it to 0 is sufficient to reset all the EEPROM values, it will obviously pull from EEPROM while it is set to 0, but when it's set back to say 1 then it will read the existing values.
As I read the code 0 literally disables all EEPROM access.
What you should do is when you change configuration.h add 1 to the EEPROM_MODE, this will force it to reset the stored EEPROM values.

[theverant]

Oh wow! There is no comment in SMCNC's firmware (that I have recently downloaded) that has that info! Are you pulling from the main Repetier branch? I know you are cooking your own. Is SMCNC behind a bit?

Thanks for the info.

This is the complete info from the SMCNC firmware:

Code: Select all

/* ########################################################################################
   ##                               EEPROM and SD Card SETTINGS                          ##
   ########################################################################################  
Set the EEPROM_MODE to 0 if you always wan't to use the settings in this configuration file. If not,
set it to 1. If you later want to overwrite your current
eeprom settings with configuration defaults, just change EEPROM_MODE to 0 and upload, then power cycle your board.

IMPORTANT: With mode 1 some changes in configuration.h are not set any more, as they are 
           taken from the EEPROM.  If you have changed your firmware, and uploaded it, and the
           values havn't changed, it's prob. because you have eeprom mode 1 selected.
*/