Repetier for RostockMax and RAMBO

[Polygonhell]

What values for the steps per do you see in the EPROM window in Repetier Host?
Dis you home the printer before attempting the move.
I assume the move was in Z?

[dsnettleton]

Thank you so much! I knew I had to be missing something. So it looks like the steps per mm info is stored in EEPROM, but not set when flashing the firmware. I changed the settings, and that seems to have done the trick. It looks like there are some other settings I should adjust as well (maximum feedrate, etc.)

[prufrock]

I just got my printer built and decided to switch to the Repetier Firmware before getting everything calibrated. My apologies if I have little to no idea what I'm doing...

I downloaded Polygonhell's fork of the firmware, changed the MICRO_STEP config to 16, then compiled and uploaded fine.

When I open Repetier Host and home the printer everything moves to the top as expected, but the manual control panel reports the current position as X: 280, Y: -280, Z: 0, which is very incorrect. My best guess is that what ever is controlling to homing logic doesn't realize it's a delta printer. I've confirmed that DRIVE_SYSTEM is set to 3 in Configuration.h, any help would be greatly appreciated.

Thanks in advance.

[mhackney]

Type M114 and press return in the G-Code field. This will tell you where the firmware thinks the position is. You most likely do not have the printer setup in the Printer dialog correctly. RH uses what's here to display. Here is my config:

Also, you have to change the steps-per-mm for the extruder to reflect 16 microsteps too. It should be 584 mm/s and can be found further down in Configuration.h in the extruder section.

[Polygonhell]

The readout in the host software is bogus, it's based on commanded moves not actual moves, and with relative moves (jogging) it accumulates error.
M114 or the LCD display are the only accurate ways to know head position (assuming you aren't missing steps).

I'm always surprised the host software doesn't just send M114 after every Jog.

[prufrock]

mhackney- I'm an idiot and you're awesome. Thank you very much.

I'm now having a another issue: it seems the movement on my stepper motors are off, the printer is reporting its Z height as 90mm when the hot end is almost to the build plate. It might be something in the EEPROM, but the Repetier Host crashes whenever I try to edit the EEPROM configuration.

Thank you once again.

[mhackney]

host crash is bad!

Can you make a screen shot and post it of the EEPROM window?

You can also disable the EEPROM in the firmware Configuration.h file. Then you set the values there.

[prufrock]

Screen shots aren't really that useful, so I downloaded the source and fired up visual studios. The host is crashing to some invalid EEPROM values. Its seems arbitrary space and/or line breaks are getting inserted at random. After messing around with resetting the EEPROM values for a while (I could never get save and load correctly), I gave up and just disabled EEPROM.

For anyone having movement issues with newer machines, make sure you change PULLEY_TEETH to 20

[mhackney]

Thanks, I wasn't suggesting using screen shots to debug your crashing issue. I wanted them to see what values you have in the EEPROM that would affect your Z height. You get crashing 100% of the time?

[Cleveralias]

I'm having an issue with the Repetier firmware that I can't figure out.

When leveling I end up with a height of 363.2 at each of the columns, but at the center it takes 368.2 to reach the bed. I didn't have this issue with the Marlin firmware and as far as I can tell I have the critical parameters matching. I'm sure I'm overlooking something but I'm stumped. It takes a Delta Radius of +20.5 to correct.

Any suggestions on where I might be running into trouble? Any guidance would be greatly appreciated!

Edit: I have a Rambo 1.1 and updating pot values to 200 across the board seems to have corrected the issue!

[Polygonhell]

Since John is now maintaining a version of Repetier Firmware I would suggest that users use that version available from here http://download.seemecnc.com I believe.
I've just pushed an update to my version, it has the delta acceleration fix published last week in it.

Since I'm currently not using the SeeMeCNC Hotend, or their extruder if you want to continue using my version you need to be careful with configuration.h.

The ESteps/mm will be wrong for a SeeMeCNC extruder, I have turned down the extruder digi-pot value because my extruder uses a different stepper.
I am also experimenting with various hotends, so the thermistor is currently set as an epcos 100K thermistor rather then the one use in the current SeeMeCNC hoten

[Flateric]

Does this mean you have uploaded yours now that includes the fixes?

[Polygonhell]

Does this mean you have uploaded yours now that includes the fixes?

Yes the fix is integrated, plus some configuration changes that will likely not be applicable to your system.
I'm currently using an epcos thermistor and a direct drive extruder with a different stepper than the ones SeeMeCNC provides so I needed to turn down the digipot value for the extruder.

[626Pilot]

Having a weird issue with EEPROM.

When I flash the RAMBo (version 1.0) with Repetier, I get gibberish on the terminal, as though the baud rate is wrong. I tried 115200, 28800, 14400, and 9600 in Configuration.h. Nothing worked, until I disabled the EEPROM. THEN it opened the port at 115200.

I think what's happening is that Repetier thinks it's reading the baud rate out of EEPROM, but what it's actually reading is whatever binary data the previous Marlin firmware put there (if any at all - it's highly unlikely that they would both just happen to store baud rate in the same exact EEPROM location.) So, instead of a valid baud rate, it's reading... whatever random stuff happens to be there.

If I disable EEPROM, it will boot up fine and I can see it sending legible characters over USB. I can't change the baud rate setting in EEPROM in the Repetier host, because of course EEPROM support is disabled!

Is there a workaround for this that doesn't involve spending two hours trying to figure out the firmware? I can do it, but I am working 18 hours a day as it is. Thanks!

[Polygonhell]

Having a weird issue with EEPROM.

When I flash the RAMBo (version 1.0) with Repetier, I get gibberish on the terminal, as though the baud rate is wrong. I tried 115200, 28800, 14400, and 9600 in Configuration.h. Nothing worked, until I disabled the EEPROM. THEN it opened the port at 115200.

I think what's happening is that Repetier thinks it's reading the baud rate out of EEPROM, but what it's actually reading is whatever binary data the previous Marlin firmware put there (if any at all - it's highly unlikely that they would both just happen to store baud rate in the same exact EEPROM location.) So, instead of a valid baud rate, it's reading... whatever random stuff happens to be there.

If I disable EEPROM, it will boot up fine and I can see it sending legible characters over USB. I can't change the baud rate setting in EEPROM in the Repetier host, because of course EEPROM support is disabled!

Is there a workaround for this that doesn't involve spending two hours trying to figure out the firmware? I can do it, but I am working 18 hours a day as it is. Thanks!

It does read baud rate out of EEPROM, but I doubt it would read the marlin values, the EEPROM enabled value in configuration.h is used as a sort of version number, so the first time it's loaded it should have wiped it. You can always just increase the value and download again.

My guess is it defaulted to 250000 baud, you should get less errors at that speed than at 115200 because it's an exact division of the ATMega clock.

[626Pilot]

the EEPROM enabled value in configuration.h is used as a sort of version number, so the first time it's loaded it should have wiped it. You can always just increase the value and download again.

Interesting. When I do something that stores data in EEPROM I usually write the first two bytes to unlikely numbers, so it has a unique signature and can tell whether it needs to write all the default values or trust what's there. I will try setting the number to something weird.

By the way, I have a RAMBo 1.0 and was wondering if it's worth it to get a 1.1 board. It seems to have twice the microstep density. Does that mean it produces more accurate prints? I want to get my Rostock tuned to be as accurate as possible.

[Polygonhell]

the EEPROM enabled value in configuration.h is used as a sort of version number, so the first time it's loaded it should have wiped it. You can always just increase the value and download again.

Interesting. When I do something that stores data in EEPROM I usually write the first two bytes to unlikely numbers, so it has a unique signature and can tell whether it needs to write all the default values or trust what's there. I will try setting the number to something weird.

By the way, I have a RAMBo 1.0 and was wondering if it's worth it to get a 1.1 board. It seems to have twice the microstep density. Does that mean it produces more accurate prints? I want to get my Rostock tuned to be as accurate as possible.

I haven't looked that closely at what Repetier does with the EEPROM, but the comment in configuration.h states the version number thing.
I also have a 1.0, doubling the uStep resolution won't make a lot of difference, it's not the same as doubling the resolution because uSteps charge two adjacent coils which doesn't give a repeatable position like an actual step, the real intent of uSteps is to smooth motion, but they do improve resolution to some extent.

[lgrijalvah]

I'm having an issue with the Repetier firmware that I can't figure out.

When leveling I end up with a height of 363.2 at each of the columns, but at the center it takes 368.2 to reach the bed. I didn't have this issue with the Marlin firmware and as far as I can tell I have the critical parameters matching. I'm sure I'm overlooking something but I'm stumped. It takes a Delta Radius of +20.5 to correct.

Any suggestions on where I might be running into trouble? Any guidance would be greatly appreciated!

Edit: I have a Rambo 1.1 and updating pot values to 200 across the board seems to have corrected the issue!

Have the same issue over here, but rambo 1.1B; what do you mean with "pot values", it is that delta radius must be set to 200 mm?

Thanks in advance

Luis G.

[Polygonhell]

If you have a very large discrepancy in heights at the center and edge of the build surface, multiple mm's.
The odds are you have differing steps per mm set for X Y and Z in the firmware and the EEPROM, the settings MUST match.
If the disparity is small and they match then a small adjustment to DELTA RADIUS is probably required.
The pot values he refers to are the current limiting pots on the stepper drivers, they are set in the firmware, too low and the steppers miss steps, too high and the drivers over heat and the steppers miss steps.

[bunkerman]

can some one can show me, what are the bes configuration for rostock max whit rambo board 1.1b and onix?

i tried a lot of things an i make work, but i can print well

i have configured the microstep to 16 an steps per mm to 80 in all 3 axis, steps per mm in extruder is 254, etc

help, it starting to disturb me

[lgrijalvah]

If you have a very large discrepancy in heights at the center and edge of the build surface, multiple mm's.
The odds are you have differing steps per mm set for X Y and Z in the firmware and the EEPROM, the settings MUST match.
If the disparity is small and they match then a small adjustment to DELTA RADIUS is probably required.
The pot values he refers to are the current limiting pots on the stepper drivers, they are set in the firmware, too low and the steppers miss steps, too high and the drivers over heat and the steppers miss steps.

Thanks for your answer, i will double check those settings values and see if works.

Luis G.

[aehM_Key]

Repetier 0.83 seem's to be available.
"fixes clacks after z changes" ..whatever this means

[September]

Yes Repetier-Firmware original is at v0.83 but the SeeMECNC RostockMAX fork of the Repetier firmware is still at v0.80. (unless the version numbers are no longer the same)

I'm not certain this is a direct fork of the repetier firmware, I couldn't find the sha where it was forked from (at least one where there was little change) and it looks like it was directly uploaded so the forked links aren't on github.

Anyway I'm sure the original firmware contains everything for the RostockMAX... just probably requires a lot of configuration changes to Configuration.h that come pre defaulted in the RostockMAX version and I'm hoping the code is good minus some fixes that might not have made it back to the original firmware as yet.

I'm pretty sure that any code fixes done to the RostockMAX would eventually make their way back to the Repetier firmware and vice versa just a matter of time, merges are a nightmare. I have seen some changes accepted back.



This is something I've been meaning to question, what are the actual differences between the two firmwares. Is the primary purpose to have the Configuration.h pre-defaulted to meet the requirements of the RostockMAX to make it easier for people? With the occasionally code fixes (which as I said before, I'd imagine these would make it back to the original Repetier Firmware).


One of the reasons I'm considering using the Repetier Firmware, is that I'm currently unable to use the EEPROM to make changes, I have to do everything in the firmware. Repetier-Host (Windows) crashes most times and when it doesn't crash it doesn't read all the values correctly... I'm currently assuming something has changed between versions... I have tried back dating Repetier-Host as far back as v0.80 and still crashes and/or does't read the values correctly. Anyway if the EEPROM isn't being read correctly by Repetier-Host, I wonder what else isn't being read/written by the Repetier-Host correctly hence my main curiosity of trying the current Repetier firmware... Maybe I am using a too new version of Repetier-Host for the current release of the SeeMECNC Repetier firmware. All of which assuming the problem is in the firmware and not in the Repetier-Host.


Has anyone tried the original firmware? I'm assuming most would stick with the SeeMECNC version of the firmware as it's what they would likely support (officially)

If you have tried it did you just update the Configuration.h with the correct values for the RostockMAX?


PS No I haven't checked with SeeMECNC about the EEPROM thing as yet, it probably isn't something I'll end up using anyway and I'll use SCM to track my configuration changes... (and yes with the stock SeeMECNC firmware it crashes, it's not due to some Configuration.h change on my behalf, I didn't even look at the firmware until I found I couldn't make changes through the EEPROM).

[Jimustanguitar]

Anyway I'm sure the original firmware contains everything for the RostockMAX... just probably requires a lot of configuration changes to Configuration.h that come pre defaulted in the RostockMAX version and I'm hoping the code is good minus some fixes that might not have made it back to the original firmware as yet.

I hope that's the case. Ideally, each release of Repetier would be modified by John and posted on the download.seemecnc.com website instead of updating an old fork every time. PolygonHell may have some insight on this process as well, because he's quite the firmware ninja

I was looking at this the other day (new repetier host, new slicer, new arduino software, and new firmware are all available) and it appears that the current seemecnc version is 3 or 4 days older than the most recent commit from Repetier. The notes sound similar though, so I suspect that both versions fixed the same thing.

[Polygonhell]

I don't know what Johns policy is on this, I usually only update when there is a change that will have a significant win, there is active development in the branch, and while it's usually pretty stable, I'm reticent to tray and stay bleeding edge.
There always seems to be something subtle that causes issues in configuration.h when I merge, usually one of the defaults that happened to be correct is changed.

You can branch it yourself on Github, and make the configuration changes, it's IMO not the easiest firmware to configure but it's not that difficult if you have some familiarity with software, it took me several hours of messing about to get everything working when I first did it. It's a little easier now because there is direct support for the LCD.