Welcome to the SeeMeCNC Community

theverant wrote:

daftscience wrote: In arduino click "Tools -> Board -> Arduino Mega 2560"

I just changed from that to UNO and I got the same DIO34_WPORT error.

Derp. That's what I get for using Arduino for other things besides upload firmware to my Max.

haha np, I can't even count how many hours I've spent trying to "fix" that issue. I guess I'm learning.


Tom

MAX_FEEDRATE (X, Y, Z) is set to 200mm/s. Has anybody tried higher speeds yet?
Has anybody calculated the theoretical no-load speed with the EE in the center?

aehM_Key wrote:MAX_FEEDRATE (X, Y, Z) is set to 200mm/s. Has anybody tried higher speeds yet?
Has anybody calculated the theoretical no-load speed with the EE in the center?

You need to be very careful increasing max speeds and accelerations, the reason is that repetier only constrains the linear head motion and the real limits are on the none linear carriage speeds. So you can end up with settings that appear to work on small tests but fail as the print moves to the outside of the bed.

That is totally clear to me, that's why I had added "in the center".

I think even the current values are not reachable at the extreme outer positions, because the opposite rod is already quite parallel with the bed. So the carriage would need infinite acceleration at one point. So I believe the firmware already handles this case and it would be no problem to increase the speed in the center. But I haven't looked in the code yet.

I'm having trouble getting the movement correct. I've changed the settings to match my configuration: These are the correct settings for my rostock, which is a newer model. The settings worked in Marlin firmware. The AXIS_STEPS_PER_MM in repetier work out to 80.0 as well. But when I instruct the board to move 1mm, it moves ~3.15, or possibly PI. But the only instance of Pi in the configuration lies within the "elif DELTA_DRIVE_TYPE == 1" macro, and should be completely ignored. Are there other configuration settings I'm missing?

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?

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.)

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.

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.

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.

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.

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.

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

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?

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!

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

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

Flateric wrote: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.

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!

626Pilot wrote: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.

Polygonhell wrote: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.

626Pilot wrote:

Polygonhell wrote: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.

Cleveralias wrote: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.

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.

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