Switching to Latest Repetier Firmware

[dsnettleton]

This weekend, I plan on switching to repetier-firmware 0.90, which I see some other guys around the forum are using. I've found the development branch here https://github.com/repetier/Repetier-Fi ... evelopment, and I've gone ahead and cloned it. I am a software developer, so I'm well aware of the caveats of using unstable branches. That being said, is there anything I should be aware of in switching firmwares? Any new settings or desired configurations? I have the LCD screen, so I expect I'll be able to change (most) of my settings in the EEPROM quite comfortably (i.e., without having to plug in to my computer). But it will be helpful to know ahead of time if anyone here has had difficulties or bad experiences with the firmware, and what I can do to fix it. Thanks.

[karlo]

I can't remember any particular gotchas when upgrading.

- Karl

[Jimustanguitar]

If you've got an easy way to compare the text between the main Git and the download.seemecnc.com branch, I'd be very curious to know what's different.

I'm about to upgrade as well and haven't decided which Git to commit to.

[geneb]

There is one "gotcha". .90 introduces "usable max z", which is about 20mm less than the mechanical max Z.

This will bite you if you don't reset your max Z after uploading the new firmware. Do a G0 Z50 G3500 and then closely approach the bed. When you're at the "paper" level, do an M251 S2 to reset the max Z.

g.

[edward]

Gene, have you found the M251 S2 command to work in 0.90alpha? Based on the current code it seems to have the same bug that I patched in v0.83.

[geneb]

I haven't run .90 for a few days because of the free-air extrusion issue I hit earlier.

I've gotten into the habit of just manually fixing X and Y via EEPROM. Have you sent a push request for the RepetierMAX branch?

g.

[edward]

RepetierMAX? No. Someone else can submit to that repo if they like, but I want the changes to make it fully upstream. Plus, there doesn't seem to be much going on in that repo (or -playground, or -Dev).

I have a pull request in for the development branch of the main Repetier-Firmware now. There haven't been any commits since Sept 6, so maybe Roland is busy elsewhere? The first patch I sent was accepted within 12 hours...

[geneb]

Ok.

I think that instead of having a separate repo for RepetierMAX, it might make more sense to just have Rostock MAX configured "reference" copies of Configuration.h, pins.h and uiconfig.h. That way someone can grab the "home" branch of Repetier and the customized files that match that release version (one set for .8x and one for .9x). It might make life easier in the long run for everyone.

The same should probably be done for those that want to use Marlin.

g.

[lordbinky]

That sounds like a great plan. I think that was the worst part of swapping versions, going through line by line those three files to make sure you got the changes you needed from .8 to .9 firmwares. It was really just tedious because some of the new variables, name changes, options, etc. that are in there.

[edward]

Ok.

I think that instead of having a separate repo for RepetierMAX, it might make more sense to just have Rostock MAX configured "reference" copies of Configuration.h, pins.h and uiconfig.h. That way someone can grab the "home" branch of Repetier and the customized files that match that release version (one set for .8x and one for .9x). It might make life easier in the long run for everyone.

The same should probably be done for those that want to use Marlin.

g.

Well put. I don't see a point in fragmentation for the sake of branding.

[geneb]

I emailed John about it. We can probably make this happen.

g.

[edward]

Great. To clarify, I don't think there's a problem in maintaining a separate repo for his own development purposes; obviously that's the purpose of Github. But, users should probably be directed to the main version and given the necessary files that you mentioned in order to customize the firmware for the MAX.

[Jimustanguitar]

it might make more sense to just have Rostock MAX configured "reference" copies of Configuration.h, pins.h and uiconfig.h.

I've always kept a document with the changes that I personally make to RepetierMax. So far it's only been delta radius, thermistor calibration, steps per mm, and things like that; but doing a list for everything that's different between base repetier and the max branch is a great idea. I like it!

I'm surprised that GitHub doesn't already work this way... I don't know a lot about GitHub, but it seems silly that a place used for development would branch out and not be backwards compatible with updates...

[geneb]

Jimustanguitar, I'm not suggesting making a list of the changes.

The intention is to store a set of "reference" files that when applied to a current release of the firmware, will allow the user to make a few small changes in Configuration.h for their machine and go. Configuration.h is the only file that would change from machine to machine. pins.h and uiconfig.h would be the same across all un-customized Rostock MAX printers.

g.

[Jimustanguitar]

I think we're saying the same thing, but I'm not smart enough to use the right words

What you're describing is exactly what I think would be great. You're describing the difference between manually making a hundred changes vs dropping in a page or two that are specific to the Rostock Max in the Repetier sketch, right?

[edward]

I'm surprised that GitHub doesn't already work this way... I don't know a lot about GitHub, but it seems silly that a place used for development would branch out and not be backwards compatible with updates...

Github does work that way...if I understand what you're trying to say. And branching is exactly the word used when you create a new section for development. And yes, often it isn't compatible. It is up to the developer to ensure that things stay compatible, if that is what you want. You know...you seem to know more than you realize

I've always kept a document with the changes that I personally make to RepetierMax. So far it's only been delta radius, thermistor calibration, steps per mm, and things like that; but doing a list for everything that's different between base repetier and the max branch is a great idea. I like it!

What you need is Git Obviously there's a bit of a learning curve, but I use it for even the most mundane things. I do exactly as you described, but I let git handle the documentation log for me. I have a local repository and a branch of the firmware I'm using (currently Marlin, but I've done the same for Repetier), and anytime I make a significant change I create a commit with a message describing the change. I can go back to any commit any time I want/need to.

The changes described by geneb essentially comprise a git diff, or the difference between two versions of a the "same" file. When applied as a patch, any changes overwrite the source file, which, in this case would be the Configuration.h from the main Repetier repository. Since none of the other code should be different, it could actually be easier in that all a MAX user would need to do is download the modified Configuration.h from SeeMe's website and overwrite the one in the main sketch directory. Bam! Ready to go...

The same would work anytime the main repository issues a version update. For users that need help, SeeMe could make any necessary changes to the Configuration.h file and issue the new version. At that point it would be up to the users to make sure any of their custom changes were then copied to the new one and there is some nice software available to help you do that. I suppose that is exactly what needs to be done now when a new version is released, hence the topic of this thread, so this part wouldn't change much.

[dsnettleton]

Has anyone else been having problems with their LCD screen on the new firmware. I've installed it, and that seems to be the only thing not working for me right now.

Edit: Figured it out. There were some UI_DISPLAY pin values that were different in uiconfig.h.

[626Pilot]

Ok.

I think that instead of having a separate repo for RepetierMAX, it might make more sense to just have Rostock MAX configured "reference" copies of Configuration.h, pins.h and uiconfig.h. That way someone can grab the "home" branch of Repetier and the customized files that match that release version (one set for .8x and one for .9x). It might make life easier in the long run for everyone.

The same should probably be done for those that want to use Marlin.

g.

I think as much of that as possible (pins.h, uiconfig.h) should be rolled into the main branch and controlled with #defines, e.g. #define USING_RAMBO, #define USING_RAMBO_LCD, etc. I haven't spent much time looking at the code but I would bet there is something like that already, since the software runs on different controllers. Those files shouldn't change between versions, or if they do, not in a way that end users would need to adjust to their specific machines. Configuration.h would have to be maintained by hand, but that would be it.

[geneb]

Not practical. There's already a broad "board type" define (301 in this case), but a RAMBo in a cartesian machine is going to use completely different pins.h settings than a delta is. The same goes for different types of LCD adapters (Viki, etc).

g.

[cope413]

Other than the auto-leveling ability, what does .90 offer over .80?

[edward]

I think the big new feature is the DELTA_RADIUS is in EEPROM. And yes, auto-level, but it's quite basic compared to what you may have seem from Marlin.

[dsnettleton]

I think the big new feature is the DELTA_RADIUS is in EEPROM.

Spot on.

[PurpleDrank]

I've been trying for the last bit here to upgrade from 0.80 to either 0.81 or 0.90 and I can't get it to compile after I drop in my uiconfig.h, pins.h and change the configuration.h values. I keep getting "DIO76_DDR isn't declared in this scope" and this:

"uiconfig.h:304: error: 'DIO76_DDR' was not declared in this scope
uiconfig.h:304: error: 'DIO76_PIN' was not declared in this scope
uiconfig.h:304: error: 'DIO76_WPORT' was not declared in this scope"

It repeats that same message for DIO70 through to DIO78. I don't know enough about debugging in the arduino environment to figure out the problem. I looked into the fastio.h where all those variables are listed but I didn't see anything out of the ordinary.

I suspect it might have something to do with the SD support functions. I know I'm missing something I just can't figure what.

Any suggestions?

[Flateric]

I think the big new feature is the DELTA_RADIUS is in EEPROM.

Spot on.

You guys try adjusting this during the print with something large and flat yet?

This is such a truly great way to get the concave and convex sweep to be so amazingly right.....just do not make large adjustments to the value of it or you'll slam the head right into the bed. Nothing bigger than say 0.5 + or - at a time. Changes are not applied until you submit.

[Eaglezsoar]

Reading this thread makes me feel like I am in a 50 foot hole and you guys are in the clouds.
In other words you are talking way over the heads of most. I'm glad that you guys are around
because you understand all of this programming stuff but for the average user do you recommend
that they just grab the firmware posted by SeeMeCNC or is there a later stable version that you
would recommend? There have been so many reports of hung print jobs and other miscellaneous
problems that I and probably other average users are unsure of what they should be using.
Then to throw another variable into the soup is the so called auto level. Does anyone know if
progress is being made with that or is that something that has been placed on the back burner
to slowly simmer? I ask these questions not only for myself but there has to be many confused
users who look to guys like you to know what they should be using. The quandry is that we want
to keep up to date on the latest features but there is no place to go to find out what the features
are and can they can be implemented on the Rostock Max. It would be nice if the average Rostock Max
user could go to a sub-forum and see what firmware changes have been made, what flavors of
firmware contains these changes and what benefits they would see if they implemented the firmware.
Or is it that the changes are taking place so slowly that such a sub-forum would rarely get updated.
I get frustrated when I read what is being done with other deltas and none of it is being ported to the
Rostock Max. What I fear is that a year from now a Rostock Max II will appear that offers many new
features and none of it will be compatible with the present Rostock Max.