Update on Repetier going idle

[daftscience]

So over at github there is a new update that is supposed to fix the issue where repetier will go idle mid print.

https://github.com/repetier/Repetier-Fi ... t-28572379

I have just compiled and uploaded it. I just thought I would post this here for those not following the repository.

[626Pilot]

I tried it yesterday and it worked on a piece that was stalling before. Pretty cool to see this fixed.

[daftscience]

Agreed. 626Pilot, you may know more about this. All of the pins on the Rambo board should be the same for every version right? Why is it that pins.h needs to be configured if we are setting the board type to 301? I'm wondering if that needs to be changed in the GIT version. And maybe add a setup for our uiconfig.h as well?

I really am unfamiliar with how github really works, and other Rambo setups.

[626Pilot]

I would look at pins.h and uiconfig.h in the RepetierMAX distribution and see how they stack up to the main repository. I used to do this by hand but now I use a graphical diff program. Makes it WAY easier.

What I don't get is why the Rostock's RAMBo would need a different pin configuration than any other RAMBo. Why would they have different pinouts? Yet I'm told this is the case.

[Eaglezsoar]

I would look at pins.h and uiconfig.h in the RepetierMAX distribution and see how they stack up to the main repository. I used to do this by hand but now I use a graphical diff program. Makes it WAY easier.

What I don't get is why the Rostock's RAMBo would need a different pin configuration than any other RAMBo. Why would they have different pinouts? Yet I'm told this is the case.

May I ask what the graphical diff program is?

[626Pilot]

May I ask what the graphical diff program is?

It's called Meld. Runs in Linux. There are similar programs on other platforms.

[dpmacri]

A good one (but expensive) that I use for work is called Araxis Merge (http://www.araxis.com/merge/index.en. WinMerge is good (and free ) if you're on Windows. KDiff3 (http://kdiff3.sourceforge.net) is decent and also free and cross-platform.

[daftscience]

I would look at pins.h and uiconfig.h in the RepetierMAX distribution and see how they stack up to the main repository. I used to do this by hand but now I use a graphical diff program. Makes it WAY easier.

What I don't get is why the Rostock's RAMBo would need a different pin configuration than any other RAMBo. Why would they have different pinouts? Yet I'm told this is the case.

That last part was pretty much what I was wondering. I've basically just keep those files seperate and compile using symlinks to the cloned git. I still wonder why ours is different.

[geneb]

The only differences in pin assignment is going to related the LCD interface. Everything else is basically cast in stone because of the board design.

g.

[dpmacri]

The only differences in pin assignment is going to related the LCD interface. Everything else is basically cast in stone because of the board design.

g.

Isn't the LCD a pretty common one? Seems like Roland should just incorporate it and have a #define for choosing the LCD similar to choosing the motherboard.

[geneb]

I agree that it should be a pre-defined kind of thing, but the LCD pin configuration would really only apply to the RAMBo. Other controllers could use the same LCD, but a different pinout.
g.