Original author @triffid about these files:
"The idea was to be able to program another board from your
electronics without PC intervention, but reprap never seemed
to go down that road."
Should solve Issue #115.
As they're all converted, they're no longer of any use. Still
they were kept up to this commit to allow comparisons between
old and new config.h system.
Likely users don't care too much about the name of the saved file,
so they likely use the default ones. If they mess up, they also
likely want to return to the original, but, d'oh, it's overwritten.
Don't let this happen, enforce a non-original file name for user
saves.
In other words: don't let users shoot themselfs into their foot.
It was certainly a good idea, but also always a suspect of
malfunctions and as such, almost never used. Newer code
organisation moves most of the code behind it to dda_clock()
anyways, so it also became mostly obsolete.
Rest In Peace, STEP_INTERRUPT_INTERRUPTIBLE, you were matter
of quite a number of interesting discussions and investigations.
Changes for Configtool by jbernardis <jeff.bernardis@gmail.com>
This should convert all files checked into the repository to
LF line endings, with exception of pictures and PDFs. Trying
to commit CRLF text on Unix will issue a warning when doing
"git add" or "git commit -a".
Users prefering CRLF (Windows) can set their local copy of the
repository to convert files on the fly at checkout with
git config --local core.autocrlf = true
Note: Git acts pretty stubborn on files which don't match the
.gitattributes rules, but are already committed. This can
happen after every change to .gitattributes. Git doesn't want
to keep these files as-is in the repository and insists on
conversion as soon as they're touched somehow. The only way to
deal with this is to either edit .gitattributes again (in case
these enforced conversions don't match the intention) or to
commit the enforced changes immediately.
To put a bit more oil into the fire, Git doesn't recognize all
misalignments immediately, but trusts its cache. Accordingly
it's a good idea to clear this cache after any change to
.gitattributes:
rm .git/index
Having this done, all further proceedings will show all
misaligments immerdiately.
For further instructions and descriptions see
http://schacon.github.io/git/gitattributes.htmlhttp://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/http://git.661346.n2.nabble.com/possible-gitattributes-eol-bug-with-new-eol-crlf-lf-support-td5516458.htmlhttps://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings
As we can always only move towards one end of an axis, one common
variable to count debouncing is sufficient.
Binary size 12 bytes smaller (and faster).
Previously, when backing off of X_MIN, X_MAX was also checked,
which of course was already open, so it signals endstop release
even while X_MIN is still closed. The issue exposed only when
endstops on both ends of an axis were defined, a more rare situation.
Essentially the fix simply makes a distinct endstop check case
for each side of each axis.
This even makes binary size 40 bytes smaller for the standard case.
Offending code were lines like these from Repetier Host:
N8965 M117 ETE 29m 10s *86
When firmware received not-G command (M-command or T-command) with X, Y,
Z, E or F coordinate, it will "change" this command to G1.
Now, firmware do change only if received line is not either G- or M-
or T-command.
Examples:
X10 - is changed to G1 X10
E20 F300 - is changed to G1 E20 F300
M117 E1 - is NOT changed to G1 E1
This commit costs 6 bytes binary size.
Markus Hitter
jbernardis
konoppo