Welcome to the SeeMeCNC Community

Hi all,

We're in the final stages of our Rostock Max build and have been going though the calibration and are stalled on the concave/convex calibration.

Let me preface our dilemma with answers to most anticipated basic questions:

1. Yes we've looked through the forum postings and while there are a number of threads related to this, none of the fixes have helped so far
2. We have been following the 2nd edition assembly guide V1.07 June 18th 2013
3. Assembly has gone without any surprises other than a split gear which SeeMeCNC promptly replaced with a new set of all aluminum gears.
4. Motion control and heaters are all working
5. We are working with the latest Repetier firmware download
6. We are working with Aduino 1.0.5
7. Firmware has compiled and downloaded normally
8. EEPROM XYZ steps match the Configuration.h settings
9. Basic height calibration went OK and EEPROM and printer shape settings match
10. End stop calibration went OK and all end stop heights match
11. we have the 300mm borosilicate glass plate clamped to the Onyx - all screws and solder pads flat and level
12. the only deviation from the normal build is we installed the TrickLaser carbon fiber arms. We built an alignment jig for assembling these which set them all to 269mm center to center and have the "zero lash straps" installed

when we started to do the flatness calibration across the plate we set the center height at 1mm and swept the effector out to 100mm radius in all directions and at 100mm radius the effector is at 3mm off the plate. I think this is defined as concavity with respect to the effector as describer on page 152 of the assembly guide. OK so far as this is apparently not unexpected.

We have edited the PRINTER_RADIUS in the Configuration.h file, initially in 0.5 steps and later in larger and larger increments (ultimately in both directions)without any effect on the concavity. At any setting from 25 - 500 the concavity is still 3mm on the periphery and 1mm in the center.

Yes, we disconnected the Repetier host while compiling and updating the firmware.

Going by the definitions of the components making up the DELTA_RADIUS definition the Rostock Max looks to have the following measurements
END_EFFECTOR_HORIZONTAL_OFFSET of about 31mm
CARRIAGE_HORIZONTAL_OFFSET of about 25mm
DELTA_RADIUS of about 127mm

Backing out PRINTER_RADIUS would be about 183mm - so we started there again and went in small increments and still no effect on concavity.

I'm open to suggestions of where to go from here. I'm confused as to why changing the PRINTER_RADIUS or DELTA_RADIUS directly has no effect on the concavity.

We are all EE's and I am also a fairly skilled machinist and have built CNC hardware before. I am also willing to believe I have overlooked something simple or missed a post about this problem if it is well known. Won't be the first time or the last.

Funny, I put a new head on this pm and I'm having the same difficulty. I went up to 201.50 with no effect. I saw a post about going the other way so I'm trying that.

Tower extrusions are square to the center of the bed then? Was that the flatness test?

Mine are - can't believe it after more than a few hours printing...but San Diego has fairly constant temps/humidity...

Do you get any messages in the arduino upload dialog box at the bottom?

I had a similar issue where nothing I was doing changed anything and it turned out the firmware wasn't actually being installed to the RAMBo.

I am also having a similar issue. I suspect that the changes I am making to the firmware are not being uploaded to the RAMBo, however when I redo the calibrations for each individual axis there are slight changes except for the final calibration the hot end tip still ends up being 5mm or so off the build platform. I have changed the #DEFINE from around 197 to about 185 with no noticeable difference in height Any insight would be greatly appreciated.

I make changes to my max Z in the EEProm, IIRC they override any input into the firmware anyhow.

Thanks for all the feedback!

Towers are square. We checked that a couple of times. Usually it is dry as a bone here in Lubbock but we did have some rain the last couple of days which raised the humidity substantially so we checked them again just in case.

I don't recall seeing any error messages in the Arduino dialog box except one time when we had hit the upload twice. My helper watching the screen seemed to believe it was getting updated by the screen behavior but I haven't verified that yet.

We know the updates to the EEPROM through Repetier are working since the Z height calibration did change things. Seems like such an important value would also be in the EEPROM. Do I recall correctly that there is a newer firmware version in the works that does this?

We'll do a little more investigation on whether the firmware is actually getting updated.

1. I'll do a quick comparison of the binary files to make sure the compiler is actually picking up changes
2. I may change a display element temporarily just to make sure the firmware is being changed.

Keep that rain to yourself if it's going to become hail by the time it gets to Carlsbad.

foshon wrote:I make changes to my max Z in the EEProm, IIRC they override any input into the firmware anyhow.

I was never clear about Repetier Host / EEProm settings updates. It's a very nice to have feature; however, it's tedious to switch back and forth - when a single field in the host can save loads of time - or not - when it doesn't update.

I vote for all or none...

We did a couple of quick tests.

1. We compared two different versions of the compiled firmware hex files with different PRINTER_RADIUS numbers (198.0, 200.0).
The files are different so the compiler is generating unique code for each.

2. For sake of completeness we also generated 2 copies of the hex files with the same number and it does generate the same code for the same numbers each time.
Not always a given in our experience!

3. we made a simple change in the uilang.h file to change the "Printer Ready" message to "Printer Updated" and it does change the message when the firmware is uploaded to the board.

From this I can conclude that the compiler is generating different code for different numbers and the code with changes is getting uploaded to the board successfully each time.

Is this perhaps something unique to the carbon fiber arms? We don't see any binding or limits in movement over the range we are working.

I don't see anything in the current EEPROM that might be over-riding anything in firmware that would affect this parameter.

We are moving on to the extruder calibration today to get it done so we will be ready to print when we get this part resolved.

This post does a fair job explaining the different measurements for each value in the firmware.

Just thinking on this and wanted to double check a couple of things,

When you move 100mm out, that's what you measured it moved and what you told it to move, correct?

I haven't dug into the code deeply to see for sure, but I'll throw it out anyways, does changing your END_EFFECTOR_HORIZONTAL_OFFSET and DELTA_DIAGONAL_ROD help?

To me, it makes sense to turn off the Eprom until the printer is fully and completely calibrated. All the changes could be written to the firmware and you would not need to be concerned if the update took place.
Once that point is reached where the printer is printing fine and changes to the firmware are not anticipated the Eprom can be turned on.
This would eliminate all the confusion of what to update which is what appears to be happening in this thread. Just my opinion.

ok.... color me confused but not terribly surprised.....

We deleted the entire Repetier firmware directory, downloaded a fresh copy and compiled the fresh copy without any changes.

Measuring cold at the moment, center 1.5mm periphery 1.75 mm

decreased default PRINTER_RADIUS by 0.5 to 197.75 and now 1.75mm center / 1.75mm periphery

.........damn..........

Time to heat things up and re-check Z height calibrations and go back to our paper tension tests to fine tune things and move on

Thanks for all the suggestions and input. I'll let you know how things go.

So by limiting the print space you changed the geometry of the printer? Wouldn't this only be possible if at the larger radius you had reached a physical limit causing lift of some kind?

foshon wrote:So by limiting the print space you changed the geometry of the printer? Wouldn't this only be possible if at the larger radius you had reached a physical limit causing lift of some kind?

I'm not sure I understand your question. We fell back to square 1 with a fresh copy of the firmware and things started to work correctly. We haven't changed anything at this point other than the normal tweak to the PRINTER_RADIUS of lowering it by 0.5 with the new firmware copy.

The upshot is something appeared to be corrupted in the downloaded and unzipped firmware. A fresh copy and things seem to be working. I would add this now to the troubleshooting list of last resort. The only thing we had changed in the original file set was the PRINTER_RADIUS which comes default at 198.25.

Good news!!!!

Well if I understand it right (which is a loaded statement, code and I get along only so much), you could have done the same thing with the addition of "-0.5" to the end of the next statement. Historically, that value is changed to correct the exact issue you are having. Why start with altering the radius instead of the final value?

I say you're best bet is to get Witch Doctor Billy to banish the your printer gremlins.

foshon wrote:Well if I understand it right (which is a loaded statement, code and I get along only so much), you could have done the same thing with the addition of "-0.5" to the end of the next statement. Historically, that value is changed to correct the exact issue you are having. Why start with altering the radius instead of the final value?

Ah! I understand your comment now.

Yes, I think it probably makes more sense to adjust the offset constant in the DELTA_RADIUS equation but "I was just following orders" per the manual page 152 where the instructions say change the PRINTER_RADIUS value.

What would make even more sense is to put this offset value in the EEPROM where it can be adjusted on the fly without having to fire up the Arduino compiler and the defines remain unmolested in the code.

In any event we just pulled our first bridge calibration cube off the printer in white ABS. After a couple of aborted attempts with the ABS peeling up we laid down some Kapton on the glass, spritzed it with some Krylon Matte finish sealer and cranked the bed temp up to 95C (glass surface temp about 20C lower)

Other than the fact the first layer looked a little squished out (I think raising the bed and extruder temps closed our first layer Z gap more then estimated) it stuck and printed very cleanly and to scale.

Onwards and upwards,

I am also having huge problems with the delta radius adjustment. I can get the thing to move flat but only if I add 25-30 to the delta radius adjustment. Unfortunately after doing this it dramatically affected the size of my prints. Everything became really really tiny. But yes, the carriage was moving prefectly flat.

So for completeness I reflashed Malin.....And believe it or not my issues completely went away. My prints are the correct size and I am not having the concave/convex issues I was having in repetier. The thing is I had this machine PERFECTLY tuned in repetier in every possible way. Then suddenly I could not get repetier to behave after many many hours of fighting it.

I prefer reptier, when it works, unfortunately at this time I cannot get it to calibrate properly. Same values in Marlin and everything is just fine. No LCD panel for me though, a minor thing however.