Repetier for RostockMax and RAMBO

[kometen]

thanks, however I have switched the eeprom funktion off for the moment. it is more convenient.
/poul

[jesse]

Version 0.83 of Repetier-Host supports circular build areas.

[img]http://i.imgur.com/jGVmHFF.png[/img]

[barnett]

From the Changelog.txt file on github, this seems to be true for 0.83:

Code: Select all

Version 0.83 22-01-2013
  Slic3r 0.9.8 included
  New translation: Latvian from www.ajmotion.lv
  Rostock shape (circular)
  Searches slic3r also in PATH environment.
  Search python/pypy in PATH if not defined.
  Show printer name in status bar if connected.
  Switch ETA between duration/end time if clicked in status bar.
  Fixed some multi-extruder issues.
  Recheck port list on every call of printer settings.
  Some small bug fixes.

but not yet for 0.52 for MacOS:

Code: Select all

Version 0.52 under development
  Slic3r 0.9.8
  Remove comments for M/G Codes > 255.
  Emergency kill now sends reset signal and M112.
  More baud rates.
  Select extruder from manual control.
  Show multiple temperatures for Repetier-Firmware 0.80 or higher.
  Switch ETA between time left and end time.
  Fixed possible dead lock.

[kometen]

Can I use these setting to adjust the level instead of the 3 screws at the end stops?

/Poul

It's my understanding that yes that works and it's how the auto bed leveling works from the LCD controller. Having said that I haven't tried it and I haven't looked at the source code in enough details to verify, if it does work, please let me know.

No... It didnt work. You cannot use these 3 variables to adjust the 3 towers. Still have to use the screws or metallic tape as I do.
/Poul

[Eaglezsoar]

The development version of Repetier has a lot of Delta support and generally seems better than the current Marlin Delta support.
I've been having a couple of problems with the current Marlin build which I believe are related to the way the Delta code interacts with the planner, notably, it's not always respecting the speed requested, this is most visible when a skirt is being used or a raft is being used, where the extruder motion is notably jerky.

I spent some time yesterday setting up Repetier, it requires a lot of changes in configuration.h, and a bug fix in pins.h, but the result is IMO much better than the current Marlin support, you can literally hear the difference, motion is much smoother.

You can download it from here
https://github.com/polygonhell/Repetier ... evelopment

Make sure you are pulling the development branch.
Repetier host will let you set most of the important settings in the EEPROM
The X/Y/Z max lengths (X_MAX_LENGTH etc in configuration.h if you don't just change it in the EEPROM) should be set to your Z height.
If you're not familiar with firmwares that use EEPROM values they override any changes you make in configuration.h, so if you are making changes there you have to send M502 to reset to the configuration.h values and M500 to store those in the EEPROM.

The thermistor is reading low, by about 10 degrees at about 220C, currently I'm just setting temperatures hotter, at some point I'll mess with the Beta value to improve the accuracy.
I had to disable the LCD screen, I don't have one to test yet, it caused issues when I tried it enabled, it may work if you do have one, and it has some nice Delta specific features, most notably the ability to level the bed without touching the endstop screws.

Disclaimer - I've printed all of 2 parts with this so YMMV.

I am building the Rostock Max very soon and I am considering using the repetier firmware and host, especially because of your recommendations. Have you had a chance to correct the firmware to work properly with the smartlcd
display? Hopefully you will let us know via this thread when everything is working. I want to personally thank you for your hard work and I'm sure that there are a lot of unknown users reading this and are looking forward to a
repetier that works with the printer and the Lcd. I also appreciate all of your other postings on this forum, I've learned a lot from you and others by reading the contents of what was written. My plans are also to use Ramps 1.4,
I'm not in favor of these all in one boards that cost a fortune because of one driver failing.

[Polygonhell]

I'm traveling on business until the end of this week, I have an LCD waiting at home, I'll probably be hideously jet lagged this weekend, so it may be next weekend before I get to it.

[v8tony]

For what it's worth I upgraded to the new version of Repetier (with the round build space) and the LCD enabled version of the firmware and all is well... I haven't had much time to print much, but, I did do a 3 hour print overnight last night with no issues...

FYI

Tony

[Eaglezsoar]

For what it's worth I upgraded to the new version of Repetier (with the round build space) and the LCD enabled version of the firmware and all is well... I haven't had much time to print much, but, I did do a 3 hour print overnight last night with no issues...

FYI

Tony

Did you get the LCD to work and if so is there anything special that needs to be done?
Which version of Repetier and possibly a link to it? Thanks!

[halopend]

Did you get the LCD to work and if so is there anything special that needs to be done?
Which version of Repetier and possibly a link to it? Thanks!

He probably means the one I posted earlier here

[v8tony]

Yes, it's the firmware referenced above and the 0.83 version of Repetier

http://www.repetier.com/download/

I didn't do anything special. I did have it working with the Marlin firmware already, but, it stopped working when I first switched over to the Repetier firmware until the latest changes...

The menu's are a little different, but, it's the same basic thing... I haven't tried printing from an SD card since I changed everything over, but, no reason to believe that wouldn't work...

Tony

[Highcooley]

After a weekend with Repetier firmware, which I like a lot, I found the following issues:

- Somehow, RAMBO looses the correct extruder motor current setting and Repetier is not able to reset it properly or the firmware messes the setting up. Anyways, I have to reload Marlin and back to Repetier about every second time, I change something in the EEPROM settings or abort a print. I don't know why, but the other motor currents always work. The result is that the extruder motor doesn't move or it moves but without enough power, so I can stop it by touching it.
- Uploading a file to the SD card doesn't work. Instead, the printer starts printing from the host software (with Marlin, it works).
- Somebody reported aborted prints. This happened to me twice now. Once after about 3 and once after about 5 hours, the printer reported idle and repetier host also didn't report any error. The movement of the printer just stopped mid print and the hot-end kept temperature. This never happened with marlin so far. Somehow I can't believe that this is only a USB issue. At least, the host should report a connection error.


- In addition, I figured out, that uploading a 60 MB file over USB with marlin takes forever. Is this normal or does it have to do with a bad signal over the long ribbon cable to the SD card? Unfortunately, I don't have any other possibility to upload to the SDHC card, as somehow my card reader doesn't recognize the card properly.

[mhackney]

I'm only using Repetier firmware and RAMBo and have not experienced any issues with stepper motor current. For the most part, I have disabled eeprom (although I have enabled it for tuning purposes for a few runs and have not observed this problem). Have you tried this with Repetier (disabling eeprom)?

I have not setup my LCD/SD card reader yet so no help there.

cheers,
Michael

[Eaglezsoar]

After a weekend with Repetier firmware, which I like a lot, I found the following issues:

- Somehow, RAMBO looses the correct extruder motor current setting and Repetier is not able to reset it properly or the firmware messes the setting up. Anyways, I have to reload Marlin and back to Repetier about every second time, I change something in the EEPROM settings or abort a print. I don't know why, but the other motor currents always work. The result is that the extruder motor doesn't move or it moves but without enough power, so I can stop it by touching it.
- Uploading a file to the SD card doesn't work. Instead, the printer starts printing from the host software (with Marlin, it works).
- Somebody reported aborted prints. This happened to me twice now. Once after about 3 and once after about 5 hours, the printer reported idle and repetier host also didn't report any error. The movement of the printer just stopped mid print and the hot-end kept temperature. This never happened with marlin so far. Somehow I can't believe that this is only a USB issue. At least, the host should report a connection error.


- In addition, I figured out, that uploading a 60 MB file over USB with marlin takes forever. Is this normal or does it have to do with a bad signal over the long ribbon cable to the SD card? Unfortunately, I don't have any other possibility to upload to the SDHC card, as somehow my card reader doesn't recognize the card properly.

After reading this I may reconsider and keep Marlin.

[Highcooley]

I'm only using Repetier firmware and RAMBo and have not experienced any issues with stepper motor current. For the most part, I have disabled eeprom (although I have enabled it for tuning purposes for a few runs and have not observed this problem). Have you tried this with Repetier (disabling eeprom)?

I have not setup my LCD/SD card reader yet so no help there.

cheers,
Michael

Nope, I haven't disabled the EEPROM function yet, as it is quite convenient. But I probably give it a try. However, I don't like to waste 5 hours of time and filament to see the printer stop again

[Polygonhell]

- Somehow, RAMBO looses the correct extruder motor current setting and Repetier is not able to reset it properly or the firmware messes the setting up. Anyways, I have to reload Marlin and back to Repetier about every second time, I change something in the EEPROM settings or abort a print. I don't know why, but the other motor currents always work. The result is that the extruder motor doesn't move or it moves but without enough power, so I can stop it by touching it.

How are you determining this? when I looked at the code as far as I can tell it does exactly the same thing as Marlin, the current is only set during initialization of the firmware.

- Uploading a file to the SD card doesn't work. Instead, the printer starts printing from the host software (with Marlin, it works).

If you're using my version, I disabled SD card, because I didn't have one connected and couldn't verify the pin mapping for the enable pin.

- Somebody reported aborted prints. This happened to me twice now. Once after about 3 and once after about 5 hours, the printer reported idle and repetier host also didn't report any error. The movement of the printer just stopped mid print and the hot-end kept temperature. This never happened with marlin so far. Somehow I can't believe that this is only a USB issue. At least, the host should report a connection error.

This is possible I guess, I've run a number of long prints without issue, my experience with aborted prints is it's usually not the firmware, but an issue with the USB connection, usually noise from something else, or the PC doing something odd like resetting the connection.

- In addition, I figured out, that uploading a 60 MB file over USB with marlin takes forever. Is this normal or does it have to do with a bad signal over the long ribbon cable to the SD card? Unfortunately, I don't have any other possibility to upload to the SDHC card, as somehow my card reader doesn't recognize the card properly.

Unfortunately this is normal, I suspect the issue is the upload is done in tiny pieces, and USB latency kills the performance, but I honestly haven't investigated. I've heard others claim it's to do with the SPI interface, but my math says that ought to be much faster than I've observed. Copy the files to the card on the PC and just move the card by hand.

I'll spare you my rant on why USB is a horrible interface to use for this sort of connection, Ethernet would have been so much better.

[halopend]

- Uploading a file to the SD card doesn't work. Instead, the printer starts printing from the host software (with Marlin, it works).
- Somebody reported aborted prints. This happened to me twice now. Once after about 3 and once after about 5 hours, the printer reported idle and repetier host also didn't report any error. The movement of the printer just stopped mid print and the hot-end kept temperature. This never happened with marlin so far. Somehow I can't believe that this is only a USB issue. At least, the host should report a connection error.

Doh, I forgot to even enable SD Card support!! I fixed it now and uploaded the changes to Here
You'll get proper mount/unmount detection now as well.

For your second problem, I was getting issues where mine would go idle a certain amount of time after startup and then start acting strange. The arms would still move but it would immediately turn the motors off at the end of every move. When using the LCD encoder to control movement it was really noticeable because it was basically switching the motors off several times per second!!! I figured this was a bug from me messing with the stepper idle time in the LCD menu so I just turned it off altogether by setting the stepper idle timer to zero in the EEPROM. Probably not good if you leave your printer on all the time but it was a quick fix and worked.

Anyway, from the behaviour I was experiencing it looks like the stepper inactivity timer doesn't properly reset whenever there is movement like it's supposed to and so it effectively just starts counting from boot time till the timer is up and goes idle. Maybe thats what happened to your prints and the difference in failure time was caused by how long each machine was running before you started to print.

[Highcooley]

- Somebody reported aborted prints. This happened to me twice now. Once after about 3 and once after about 5 hours, the printer reported idle and repetier host also didn't report any error. The movement of the printer just stopped mid print and the hot-end kept temperature. This never happened with marlin so far. Somehow I can't believe that this is only a USB issue. At least, the host should report a connection error.

For your second problem, I was getting issues where mine would go idle a certain amount of time after startup and then start acting strange. The arms would still move but it would immediately turn the motors off at the end of every move. When using the LCD encoder to control movement it was really noticeable because it was basically switching the motors off several times per second!!! I figured this was a bug from me messing with the stepper idle time in the LCD menu so I just turned it off altogether by setting the stepper idle timer to zero in the EEPROM. Probably not good if you leave your printer on all the time but it was a quick fix and worked.

Anyway, from the behaviour I was experiencing it looks like the stepper inactivity timer doesn't properly reset whenever there is movement like it's supposed to and so it effectively just starts counting from boot time till the timer is up and goes idle. Maybe thats what happened to your prints and the difference in failure time was caused by how long each machine was running before you started to print.

THX for enabling SD support. Gonna update my firmware tonight.

About the other issue with the aborted prints: I don't think it was due to the stepper inactivity timer. The print should have taken another couple of hours when the printer turned idle.

The way I see it, there could be two explanations. One: Neither the firmware nor the host reports any error if the USB connection gets lost. Both just reconnect and the host quits the print job. Two: Somehow the firmware starts running through the G-Code without executing it at max speed, until the host sent the last line. Then both, the firmware and the host consider the job as done. I think I'm gonna check with repetier on github.

[Highcooley]

Now, the SD card thing comes clear
Concerning SD upload...I expected the slow transfer speed having to do with Arduino's transfer protocol. I would definitely prefer to upload files directly to the card. However, as mentioned, my card reader, USB driver or Win 7 doesn't want to recognise the card. The card reader's LED turns on, but I don't see the card anywhere.

- Somehow, RAMBO looses the correct extruder motor current setting and Repetier is not able to reset it properly or the firmware messes the setting up. Anyways, I have to reload Marlin and back to Repetier about every second time, I change something in the EEPROM settings or abort a print. I don't know why, but the other motor currents always work. The result is that the extruder motor doesn't move or it moves but without enough power, so I can stop it by touching it.

How are you determining this? when I looked at the code as far as I can tell it does exactly the same thing as Marlin, the current is only set during initialization of the firmware.

I had this problem several times now. Sometimes, the extruder motor doesn't move at all anymore. But sometimes, it works but with very little torque. Resetting the firmware never helped. Only with the described reload of Marlin, the motor behaved like it should again. That's why I assume, that it has something to do with the motor current being erased from RAMBO's memory. However, I don't even know, if RAMBO has a solid state memory for the motor currents or if they have to be set on every boot up.

- Somebody reported aborted prints. This happened to me twice now. Once after about 3 and once after about 5 hours, the printer reported idle and repetier host also didn't report any error. The movement of the printer just stopped mid print and the hot-end kept temperature. This never happened with marlin so far. Somehow I can't believe that this is only a USB issue. At least, the host should report a connection error.

This is possible I guess, I've run a number of long prints without issue, my experience with aborted prints is it's usually not the firmware, but an issue with the USB connection, usually noise from something else, or the PC doing something odd like resetting the connection.

Yea, it might be the USB connection. However, I ran prints for hours with marlin and the standard transfer protocol without any flaws. And if it is the USB connection causing this, at least the host or the firmware should report an error in my opinion.

[Polygonhell]

It's worth noting that my build has the LCD and SD card disabled because with it enabled I had issues with the initialization code not always correctly setting the pins as inputs/outputs, or rather I think the LCD initialization code was causing issues after the fact.
I honestly haven't looked at that code, once I bother wiring my LCD up, I'll take a look at it.

I assume that the working LCD rostock version of Repetier was based on my configuration, I also have a change in pins.h (which was not moved back to the main repetier developer branch) to enable the digipots, hopefully that made it across as well, otherwise the digipot values are not set at all.

Repetier does use a binary protocol between the host and firmware, and the serial code is a little different than Marlin, though most seem to find it more reliable.
Unfortunately USB is not very error tolerant, and you can get into a situation where both sides of the connection just sit and wait for data, you can handle this in a protocol on top, though it's not always possible to recover, but I doubt repetier host/firmware do anything this complicated.

[Highcooley]

All right

So this issue witht the LCD code messing up IO could maybe cause the extruder motor problem.

Anyways, I was not succesfull in enabling the SD card as Arduino 0022 and 0023 tell me that the SD part needs to be comiled by an Arduinio IDE 1.0 or higher. On the other side both, Arduino 1.0.0 and 1.0.3 compile but stop midst upload if I enable SD support in the firmware. I have both pins_arduino.h for 0022/0023 respectively .c for 1.0.1 and 1.0.3 copied in the suggested directories. Dunno why this won't work but gonna live without SD for the moment.

Another thought about the printer interruption problems: I wonder how Repetier host handles access to GCODE files. One difference in between other long prints I did and the two with repetier who aborted was, that I was printing relatively slow. I have set my energy settings for the harddrive to 20 minutes. So, in case the harddrive would somehow go to sleep because the host was not accessing the file for a longer time (still enough data in the memory), this might cause a data interruption for about 5 seconds until the host has new data from the file. On the other hand, Repetier fills over 1 GB of RAM at the moment...this should include the GCODE file.

THX for your inputs!

[halopend]

It's worth noting that my build has the LCD and SD card disabled because with it enabled I had issues with the initialization code not always correctly setting the pins as inputs/outputs, or rather I think the LCD initialization code was causing issues after the fact.
I honestly haven't looked at that code, once I bother wiring my LCD up, I'll take a look at it.

I assume that the working LCD rostock version of Repetier was based on my configuration, I also have a change in pins.h (which was not moved back to the main repetier developer branch) to enable the digipots, hopefully that made it across as well, otherwise the digipot values are not set at all.

Repetier does use a binary protocol between the host and firmware, and the serial code is a little different than Marlin, though most seem to find it more reliable.
Unfortunately USB is not very error tolerant, and you can get into a situation where both sides of the connection just sit and wait for data, you can handle this in a protocol on top, though it's not always possible to recover, but I doubt repetier host/firmware do anything this complicated.

I branched off of your repository directly so I have all the changes you implemented. It look like the main repository has actually does have digipots enabled now too.

Anyways, I was not succesfull in enabling the SD card as Arduino 0022 and 0023 tell me that the SD part needs to be comiled by an Arduinio IDE 1.0 or higher. On the other side both, Arduino 1.0.0 and 1.0.3 compile but stop midst upload if I enable SD support in the firmware. I have both pins_arduino.h for 0022/0023 respectively .c for 1.0.1 and 1.0.3 copied in the suggested directories. Dunno why this won't work but gonna live without SD for the moment.!

If you attepmted to make the changes from here manually to enable SD support, pay special attention to line 1016. You have to delete that line and enable it from line 1019 so it looks like

#define EEPROM_MODE 1
/** Set to false to disable SD support: */
#ifndef SDSUPPORT // Some boards have sd support on board. These define the values already in pins.h
#define SDSUPPORT true
/** If set to false all files with longer names then 8.3 or having a tilde in the name will be hidden */
#define SD_ALLOW_LONG_NAMES false
// Uncomment to enable or changed card detection pin. With card detection the card is mounted on insertion.
//#define SDCARDDETECT -1
// Change to true if you get a inserted message on removal.
#define SDCARDDETECTINVERTED false
#endif

The reason is that #ifndef SDSUPPORT basically means only do what I say in the next section below if SDSUPPORT hasn't been defined yet. If you leave in line 1016 , it'll skip that whole section and now you have a problem where SDCARDDETECTINVERTED never gets defined which is what buggers compiling. I think Polygonshell added "#define SDSUPPORT false" to line 1016 to disable SD support instead of changing line 1019 from "#define SDSUPPORT true" to "#define SDSUPPORT false" which is why its confusing.

Anyway, I'm guessing thats your problem cause it's exactly what happened to me when I tried to enable SD support the first time around.

[Polygonhell]

I think Polygonshell added "#define SDSUPPORT false" to line 1016 to disable SD support instead of changing line 1019 from "#define SDSUPPORT true" to "#define SDSUPPORT false" which is why its confusing.

Indeed that is what I did, well at least according to the diff on github.

[Highcooley]

Hey guys

Thank you for your help. I "WinMerged" my firmware with halopend's version. It is now based on a combination of halopend's version which is based on Polygonhell's as well as repetier's original 0.81, which I merged earlier on.
I was able to successfully upload it with Arduino 1.0.3 and the SD support as well as the correct extruder motor current setting work now (file upload is actually about twice as fast as with Marlin, but still takes ages). The error somehow was not the mentioned line 1061 but I was not able to determine what exactly caused the problem. It was probably a combination of several minor changes from 0.80 to 0.81 which I merged incorrectly.

@halopend: I saw that you enabled the hot-end cooler function. I highly recommend doing these changes:https://github.com/repetier/Repetier-Fi ... 16fc29ec56
I requested Repetier to implement a check on firmware boot up, if the hot-end temperature exceeds 50°C in order to switch on the fan immediatelly. Otherwise, if you reconnect your host or reset your printer otherwise during cooldown, the fan switches off and you have to send a heating command first.

[Polygonhell]

FWIW I just added LCD/SD Card support to my version.
About the only difference to Haloped's version is the kill switch works.
I changed the repetier behavior for the kill switch, the standard version turns everything off and hangs the firmware, which requires resetting the arduino to continue.
My version turns everything off then just resets the arduino.
There is code in repetier to soft level a rostock, when I get a chance I'll add it to a menu option to test it.

[mhackney]

Tell me about the kill! Are you talking about the big Emergency Stop button at the upper right of the Repetier Host? I'm using Haloped;s version and that works on my system.

cheers,
Michael