h3n3/klipper
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Compare commits

base: h3n3:v0.7.0
Branches Tags
h3n3:master h3n3:gh-pages h3n3:umo1 h3n3:umo2 h3n3:work-thflush-20250811 h3n3:work-closestale-20250202 h3n3:work-heaters-20240804
h3n3:v0.13.0 h3n3:v0.12.0 h3n3:v0.11.0 h3n3:v0.10.0 h3n3:v0.9.1 h3n3:v0.9.0 h3n3:v0.8.0 h3n3:v0.7.0 h3n3:v0.6.0 h3n3:v0.5.0 h3n3:v0.4.0 h3n3:v0.3.0 h3n3:v0.2.0 h3n3:v0.1.0
..
compare: h3n3:v0.1.0
Branches Tags
h3n3:gh-pages h3n3:master h3n3:umo1 h3n3:umo2 h3n3:work-thflush-20250811 h3n3:work-closestale-20250202 h3n3:work-heaters-20240804
h3n3:v0.13.0 h3n3:v0.12.0 h3n3:v0.11.0 h3n3:v0.10.0 h3n3:v0.9.1 h3n3:v0.9.0 h3n3:v0.8.0 h3n3:v0.7.0 h3n3:v0.6.0 h3n3:v0.5.0 h3n3:v0.4.0 h3n3:v0.3.0 h3n3:v0.2.0 h3n3:v0.1.0

1 Commits
v0.7.0 ... v0.1.0

Author SHA1 Message Date
Kevin O'Connor
30595b5cd7 Initial commit of source code. 
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
 2014-08-23 22:43:19 -04:00
932 changed files with 837 additions and 426606 deletions
Expand all files Collapse all files

6
.gitignore vendored
View File

@@ -1,6 +0,0 @@
out
*.so
*.pyc
.config
.config.old
klippy/.version

26
.travis.yml
View File

@@ -1,26 +0,0 @@
# This is a travis-ci.org continuous integration configuration file.
language: c
addons:
apt:
packages:
# AVR GCC packages
- gcc-avr
- avr-libc
# PRU GCC build packages
- pv
- libmpfr-dev
- libgmp-dev
- libmpc-dev
- texinfo
- libncurses5-dev
- bison
- flex
cache:
directories:
- travis_cache
install: ./scripts/travis-install.sh
script: ./scripts/travis-build.sh

674
COPYING
View File

@@ -1,674 +0,0 @@
GNU GENERAL PUBLIC LICENSE
Version 3, 29 June 2007
Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The GNU General Public License is a free, copyleft license for
software and other kinds of works.
The licenses for most software and other practical works are designed
to take away your freedom to share and change the works. By contrast,
the GNU General Public License is intended to guarantee your freedom to
share and change all versions of a program--to make sure it remains free
software for all its users. We, the Free Software Foundation, use the
GNU General Public License for most of our software; it applies also to
any other work released this way by its authors. You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
them if you wish), that you receive source code or can get it if you
want it, that you can change the software or use pieces of it in new
free programs, and that you know you can do these things.
To protect your rights, we need to prevent others from denying you
these rights or asking you to surrender the rights. Therefore, you have
certain responsibilities if you distribute copies of the software, or if
you modify it: responsibilities to respect the freedom of others.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must pass on to the recipients the same
freedoms that you received. You must make sure that they, too, receive
or can get the source code. And you must show them these terms so they
know their rights.
Developers that use the GNU GPL protect your rights with two steps:
(1) assert copyright on the software, and (2) offer you this License
giving you legal permission to copy, distribute and/or modify it.
For the developers' and authors' protection, the GPL clearly explains
that there is no warranty for this free software. For both users' and
authors' sake, the GPL requires that modified versions be marked as
changed, so that their problems will not be attributed erroneously to
authors of previous versions.
Some devices are designed to deny users access to install or run
modified versions of the software inside them, although the manufacturer
can do so. This is fundamentally incompatible with the aim of
protecting users' freedom to change the software. The systematic
pattern of such abuse occurs in the area of products for individuals to
use, which is precisely where it is most unacceptable. Therefore, we
have designed this version of the GPL to prohibit the practice for those
products. If such problems arise substantially in other domains, we
stand ready to extend this provision to those domains in future versions
of the GPL, as needed to protect the freedom of users.
Finally, every program is threatened constantly by software patents.
States should not allow patents to restrict development and use of
software on general-purpose computers, but in those that do, we wish to
avoid the special danger that patents applied to a free program could
make it effectively proprietary. To prevent this, the GPL assures that
patents cannot be used to render the program non-free.
The precise terms and conditions for copying, distribution and
modification follow.
TERMS AND CONDITIONS
0. Definitions.
"This License" refers to version 3 of the GNU General Public License.
"Copyright" also means copyright-like laws that apply to other kinds of
works, such as semiconductor masks.
"The Program" refers to any copyrightable work licensed under this
License. Each licensee is addressed as "you". "Licensees" and
"recipients" may be individuals or organizations.
To "modify" a work means to copy from or adapt all or part of the work
in a fashion requiring copyright permission, other than the making of an
exact copy. The resulting work is called a "modified version" of the
earlier work or a work "based on" the earlier work.
A "covered work" means either the unmodified Program or a work based
on the Program.
To "propagate" a work means to do anything with it that, without
permission, would make you directly or secondarily liable for
infringement under applicable copyright law, except executing it on a
computer or modifying a private copy. Propagation includes copying,
distribution (with or without modification), making available to the
public, and in some countries other activities as well.
To "convey" a work means any kind of propagation that enables other
parties to make or receive copies. Mere interaction with a user through
a computer network, with no transfer of a copy, is not conveying.
An interactive user interface displays "Appropriate Legal Notices"
to the extent that it includes a convenient and prominently visible
feature that (1) displays an appropriate copyright notice, and (2)
tells the user that there is no warranty for the work (except to the
extent that warranties are provided), that licensees may convey the
work under this License, and how to view a copy of this License. If
the interface presents a list of user commands or options, such as a
menu, a prominent item in the list meets this criterion.
1. Source Code.
The "source code" for a work means the preferred form of the work
for making modifications to it. "Object code" means any non-source
form of a work.
A "Standard Interface" means an interface that either is an official
standard defined by a recognized standards body, or, in the case of
interfaces specified for a particular programming language, one that
is widely used among developers working in that language.
The "System Libraries" of an executable work include anything, other
than the work as a whole, that (a) is included in the normal form of
packaging a Major Component, but which is not part of that Major
Component, and (b) serves only to enable use of the work with that
Major Component, or to implement a Standard Interface for which an
implementation is available to the public in source code form. A
"Major Component", in this context, means a major essential component
(kernel, window system, and so on) of the specific operating system
(if any) on which the executable work runs, or a compiler used to
produce the work, or an object code interpreter used to run it.
The "Corresponding Source" for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities. However, it does not include the work's
System Libraries, or general-purpose tools or generally available free
programs which are used unmodified in performing those activities but
which are not part of the work. For example, Corresponding Source
includes interface definition files associated with source files for
the work, and the source code for shared libraries and dynamically
linked subprograms that the work is specifically designed to require,
such as by intimate data communication or control flow between those
subprograms and other parts of the work.
The Corresponding Source need not include anything that users
can regenerate automatically from other parts of the Corresponding
Source.
The Corresponding Source for a work in source code form is that
same work.
2. Basic Permissions.
All rights granted under this License are granted for the term of
copyright on the Program, and are irrevocable provided the stated
conditions are met. This License explicitly affirms your unlimited
permission to run the unmodified Program. The output from running a
covered work is covered by this License only if the output, given its
content, constitutes a covered work. This License acknowledges your
rights of fair use or other equivalent, as provided by copyright law.
You may make, run and propagate covered works that you do not
convey, without conditions so long as your license otherwise remains
in force. You may convey covered works to others for the sole purpose
of having them make modifications exclusively for you, or provide you
with facilities for running those works, provided that you comply with
the terms of this License in conveying all material for which you do
not control copyright. Those thus making or running the covered works
for you must do so exclusively on your behalf, under your direction
and control, on terms that prohibit them from making any copies of
your copyrighted material outside their relationship with you.
Conveying under any other circumstances is permitted solely under
the conditions stated below. Sublicensing is not allowed; section 10
makes it unnecessary.
3. Protecting Users' Legal Rights From Anti-Circumvention Law.
No covered work shall be deemed part of an effective technological
measure under any applicable law fulfilling obligations under article
11 of the WIPO copyright treaty adopted on 20 December 1996, or
similar laws prohibiting or restricting circumvention of such
measures.
When you convey a covered work, you waive any legal power to forbid
circumvention of technological measures to the extent such circumvention
is effected by exercising rights under this License with respect to
the covered work, and you disclaim any intention to limit operation or
modification of the work as a means of enforcing, against the work's
users, your or third parties' legal rights to forbid circumvention of
technological measures.
4. Conveying Verbatim Copies.
You may convey verbatim copies of the Program's source code as you
receive it, in any medium, provided that you conspicuously and
appropriately publish on each copy an appropriate copyright notice;
keep intact all notices stating that this License and any
non-permissive terms added in accord with section 7 apply to the code;
keep intact all notices of the absence of any warranty; and give all
recipients a copy of this License along with the Program.
You may charge any price or no price for each copy that you convey,
and you may offer support or warranty protection for a fee.
5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified
it, and giving a relevant date.
b) The work must carry prominent notices stating that it is
released under this License and any conditions added under section
7. This requirement modifies the requirement in section 4 to
"keep intact all notices".
c) You must license the entire work, as a whole, under this
License to anyone who comes into possession of a copy. This
License will therefore apply, along with any applicable section 7
additional terms, to the whole of the work, and all its parts,
regardless of how they are packaged. This License gives no
permission to license the work in any other way, but it does not
invalidate such permission if you have separately received it.
d) If the work has interactive user interfaces, each must display
Appropriate Legal Notices; however, if the Program has interactive
interfaces that do not display Appropriate Legal Notices, your
work need not make them do so.
A compilation of a covered work with other separate and independent
works, which are not by their nature extensions of the covered work,
and which are not combined with it such as to form a larger program,
in or on a volume of a storage or distribution medium, is called an
"aggregate" if the compilation and its resulting copyright are not
used to limit the access or legal rights of the compilation's users
beyond what the individual works permit. Inclusion of a covered work
in an aggregate does not cause this License to apply to the other
parts of the aggregate.
6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms
of sections 4 and 5, provided that you also convey the
machine-readable Corresponding Source under the terms of this License,
in one of these ways:
a) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by the
Corresponding Source fixed on a durable physical medium
customarily used for software interchange.
b) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by a
written offer, valid for at least three years and valid for as
long as you offer spare parts or customer support for that product
model, to give anyone who possesses the object code either (1) a
copy of the Corresponding Source for all the software in the
product that is covered by this License, on a durable physical
medium customarily used for software interchange, for a price no
more than your reasonable cost of physically performing this
conveying of source, or (2) access to copy the
Corresponding Source from a network server at no charge.
c) Convey individual copies of the object code with a copy of the
written offer to provide the Corresponding Source. This
alternative is allowed only occasionally and noncommercially, and
only if you received the object code with such an offer, in accord
with subsection 6b.
d) Convey the object code by offering access from a designated
place (gratis or for a charge), and offer equivalent access to the
Corresponding Source in the same way through the same place at no
further charge. You need not require recipients to copy the
Corresponding Source along with the object code. If the place to
copy the object code is a network server, the Corresponding Source
may be on a different server (operated by you or a third party)
that supports equivalent copying facilities, provided you maintain
clear directions next to the object code saying where to find the
Corresponding Source. Regardless of what server hosts the
Corresponding Source, you remain obligated to ensure that it is
available for as long as needed to satisfy these requirements.
e) Convey the object code using peer-to-peer transmission, provided
you inform other peers where the object code and Corresponding
Source of the work are being offered to the general public at no
charge under subsection 6d.
A separable portion of the object code, whose source code is excluded
from the Corresponding Source as a System Library, need not be
included in conveying the object code work.
A "User Product" is either (1) a "consumer product", which means any
tangible personal property which is normally used for personal, family,
or household purposes, or (2) anything designed or sold for incorporation
into a dwelling. In determining whether a product is a consumer product,
doubtful cases shall be resolved in favor of coverage. For a particular
product received by a particular user, "normally used" refers to a
typical or common use of that class of product, regardless of the status
of the particular user or of the way in which the particular user
actually uses, or expects or is expected to use, the product. A product
is a consumer product regardless of whether the product has substantial
commercial, industrial or non-consumer uses, unless such uses represent
the only significant mode of use of the product.
"Installation Information" for a User Product means any methods,
procedures, authorization keys, or other information required to install
and execute modified versions of a covered work in that User Product from
a modified version of its Corresponding Source. The information must
suffice to ensure that the continued functioning of the modified object
code is in no case prevented or interfered with solely because
modification has been made.
If you convey an object code work under this section in, or with, or
specifically for use in, a User Product, and the conveying occurs as
part of a transaction in which the right of possession and use of the
User Product is transferred to the recipient in perpetuity or for a
fixed term (regardless of how the transaction is characterized), the
Corresponding Source conveyed under this section must be accompanied
by the Installation Information. But this requirement does not apply
if neither you nor any third party retains the ability to install
modified object code on the User Product (for example, the work has
been installed in ROM).
The requirement to provide Installation Information does not include a
requirement to continue to provide support service, warranty, or updates
for a work that has been modified or installed by the recipient, or for
the User Product in which it has been modified or installed. Access to a
network may be denied when the modification itself materially and
adversely affects the operation of the network or violates the rules and
protocols for communication across the network.
Corresponding Source conveyed, and Installation Information provided,
in accord with this section must be in a format that is publicly
documented (and with an implementation available to the public in
source code form), and must require no special password or key for
unpacking, reading or copying.
7. Additional Terms.
"Additional permissions" are terms that supplement the terms of this
License by making exceptions from one or more of its conditions.
Additional permissions that are applicable to the entire Program shall
be treated as though they were included in this License, to the extent
that they are valid under applicable law. If additional permissions
apply only to part of the Program, that part may be used separately
under those permissions, but the entire Program remains governed by
this License without regard to the additional permissions.
When you convey a copy of a covered work, you may at your option
remove any additional permissions from that copy, or from any part of
it. (Additional permissions may be written to require their own
removal in certain cases when you modify the work.) You may place
additional permissions on material, added by you to a covered work,
for which you have or can give appropriate copyright permission.
Notwithstanding any other provision of this License, for material you
add to a covered work, you may (if authorized by the copyright holders of
that material) supplement the terms of this License with terms:
a) Disclaiming warranty or limiting liability differently from the
terms of sections 15 and 16 of this License; or
b) Requiring preservation of specified reasonable legal notices or
author attributions in that material or in the Appropriate Legal
Notices displayed by works containing it; or
c) Prohibiting misrepresentation of the origin of that material, or
requiring that modified versions of such material be marked in
reasonable ways as different from the original version; or
d) Limiting the use for publicity purposes of names of licensors or
authors of the material; or
e) Declining to grant rights under trademark law for use of some
trade names, trademarks, or service marks; or
f) Requiring indemnification of licensors and authors of that
material by anyone who conveys the material (or modified versions of
it) with contractual assumptions of liability to the recipient, for
any liability that these contractual assumptions directly impose on
those licensors and authors.
All other non-permissive additional terms are considered "further
restrictions" within the meaning of section 10. If the Program as you
received it, or any part of it, contains a notice stating that it is
governed by this License along with a term that is a further
restriction, you may remove that term. If a license document contains
a further restriction but permits relicensing or conveying under this
License, you may add to a covered work material governed by the terms
of that license document, provided that the further restriction does
not survive such relicensing or conveying.
If you add terms to a covered work in accord with this section, you
must place, in the relevant source files, a statement of the
additional terms that apply to those files, or a notice indicating
where to find the applicable terms.
Additional terms, permissive or non-permissive, may be stated in the
form of a separately written license, or stated as exceptions;
the above requirements apply either way.
8. Termination.
You may not propagate or modify a covered work except as expressly
provided under this License. Any attempt otherwise to propagate or
modify it is void, and will automatically terminate your rights under
this License (including any patent licenses granted under the third
paragraph of section 11).
However, if you cease all violation of this License, then your
license from a particular copyright holder is reinstated (a)
provisionally, unless and until the copyright holder explicitly and
finally terminates your license, and (b) permanently, if the copyright
holder fails to notify you of the violation by some reasonable means
prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is
reinstated permanently if the copyright holder notifies you of the
violation by some reasonable means, this is the first time you have
received notice of violation of this License (for any work) from that
copyright holder, and you cure the violation prior to 30 days after
your receipt of the notice.
Termination of your rights under this section does not terminate the
licenses of parties who have received copies or rights from you under
this License. If your rights have been terminated and not permanently
reinstated, you do not qualify to receive new licenses for the same
material under section 10.
9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or
run a copy of the Program. Ancillary propagation of a covered work
occurring solely as a consequence of using peer-to-peer transmission
to receive a copy likewise does not require acceptance. However,
nothing other than this License grants you permission to propagate or
modify any covered work. These actions infringe copyright if you do
not accept this License. Therefore, by modifying or propagating a
covered work, you indicate your acceptance of this License to do so.
10. Automatic Licensing of Downstream Recipients.
Each time you convey a covered work, the recipient automatically
receives a license from the original licensors, to run, modify and
propagate that work, subject to this License. You are not responsible
for enforcing compliance by third parties with this License.
An "entity transaction" is a transaction transferring control of an
organization, or substantially all assets of one, or subdividing an
organization, or merging organizations. If propagation of a covered
work results from an entity transaction, each party to that
transaction who receives a copy of the work also receives whatever
licenses to the work the party's predecessor in interest had or could
give under the previous paragraph, plus a right to possession of the
Corresponding Source of the work from the predecessor in interest, if
the predecessor has it or can get it with reasonable efforts.
You may not impose any further restrictions on the exercise of the
rights granted or affirmed under this License. For example, you may
not impose a license fee, royalty, or other charge for exercise of
rights granted under this License, and you may not initiate litigation
(including a cross-claim or counterclaim in a lawsuit) alleging that
any patent claim is infringed by making, using, selling, offering for
sale, or importing the Program or any portion of it.
11. Patents.
A "contributor" is a copyright holder who authorizes use under this
License of the Program or a work on which the Program is based. The
work thus licensed is called the contributor's "contributor version".
A contributor's "essential patent claims" are all patent claims
owned or controlled by the contributor, whether already acquired or
hereafter acquired, that would be infringed by some manner, permitted
by this License, of making, using, or selling its contributor version,
but do not include claims that would be infringed only as a
consequence of further modification of the contributor version. For
purposes of this definition, "control" includes the right to grant
patent sublicenses in a manner consistent with the requirements of
this License.
Each contributor grants you a non-exclusive, worldwide, royalty-free
patent license under the contributor's essential patent claims, to
make, use, sell, offer for sale, import and otherwise run, modify and
propagate the contents of its contributor version.
In the following three paragraphs, a "patent license" is any express
agreement or commitment, however denominated, not to enforce a patent
(such as an express permission to practice a patent or covenant not to
sue for patent infringement). To "grant" such a patent license to a
party means to make such an agreement or commitment not to enforce a
patent against the party.
If you convey a covered work, knowingly relying on a patent license,
and the Corresponding Source of the work is not available for anyone
to copy, free of charge and under the terms of this License, through a
publicly available network server or other readily accessible means,
then you must either (1) cause the Corresponding Source to be so
available, or (2) arrange to deprive yourself of the benefit of the
patent license for this particular work, or (3) arrange, in a manner
consistent with the requirements of this License, to extend the patent
license to downstream recipients. "Knowingly relying" means you have
actual knowledge that, but for the patent license, your conveying the
covered work in a country, or your recipient's use of the covered work
in a country, would infringe one or more identifiable patents in that
country that you have reason to believe are valid.
If, pursuant to or in connection with a single transaction or
arrangement, you convey, or propagate by procuring conveyance of, a
covered work, and grant a patent license to some of the parties
receiving the covered work authorizing them to use, propagate, modify
or convey a specific copy of the covered work, then the patent license
you grant is automatically extended to all recipients of the covered
work and works based on it.
A patent license is "discriminatory" if it does not include within
the scope of its coverage, prohibits the exercise of, or is
conditioned on the non-exercise of one or more of the rights that are
specifically granted under this License. You may not convey a covered
work if you are a party to an arrangement with a third party that is
in the business of distributing software, under which you make payment
to the third party based on the extent of your activity of conveying
the work, and under which the third party grants, to any of the
parties who would receive the covered work from you, a discriminatory
patent license (a) in connection with copies of the covered work
conveyed by you (or copies made from those copies), or (b) primarily
for and in connection with specific products or compilations that
contain the covered work, unless you entered into that arrangement,
or that patent license was granted, prior to 28 March 2007.
Nothing in this License shall be construed as excluding or limiting
any implied license or other defenses to infringement that may
otherwise be available to you under applicable patent law.
12. No Surrender of Others' Freedom.
If conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot convey a
covered work so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you may
not convey it at all. For example, if you agree to terms that obligate you
to collect a royalty for further conveying from those to whom you convey
the Program, the only way you could satisfy both those terms and this
License would be to refrain entirely from conveying the Program.
13. Use with the GNU Affero General Public License.
Notwithstanding any other provision of this License, you have
permission to link or combine any covered work with a work licensed
under version 3 of the GNU Affero General Public License into a single
combined work, and to convey the resulting work. The terms of this
License will continue to apply to the part which is the covered work,
but the special requirements of the GNU Affero General Public License,
section 13, concerning interaction through a network will apply to the
combination as such.
14. Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions of
the GNU General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the
Program specifies that a certain numbered version of the GNU General
Public License "or any later version" applies to it, you have the
option of following the terms and conditions either of that numbered
version or of any later version published by the Free Software
Foundation. If the Program does not specify a version number of the
GNU General Public License, you may choose any version ever published
by the Free Software Foundation.
If the Program specifies that a proxy can decide which future
versions of the GNU General Public License can be used, that proxy's
public statement of acceptance of a version permanently authorizes you
to choose that version for the Program.
Later license versions may give you additional or different
permissions. However, no additional obligations are imposed on any
author or copyright holder as a result of your choosing to follow a
later version.
15. Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
17. Interpretation of Sections 15 and 16.
If the disclaimer of warranty and limitation of liability provided
above cannot be given local legal effect according to their terms,
reviewing courts shall apply local law that most closely approximates
an absolute waiver of all civil liability in connection with the
Program, unless a warranty or assumption of liability accompanies a
copy of the Program in return for a fee.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
state the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
Also add information on how to contact you by electronic and paper mail.
If the program does terminal interaction, make it output a short
notice like this when it starts in an interactive mode:
<program> Copyright (C) <year> <name of author>
This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, your program's commands
might be different; for a GUI interface, you would use an "about box".
You should also get your employer (if you work as a programmer) or school,
if any, to sign a "copyright disclaimer" for the program, if necessary.
For more information on this, and how to apply and follow the GNU GPL, see
<http://www.gnu.org/licenses/>.
The GNU General Public License does not permit incorporating your program
into proprietary programs. If your program is a subroutine library, you
may consider it more useful to permit linking proprietary applications with
the library. If this is what you want to do, use the GNU Lesser General
Public License instead of this License. But first, please read
<http://www.gnu.org/philosophy/why-not-lgpl.html>.

80
Makefile
View File

@@ -1,8 +1,8 @@
# Klipper build system # XXX build system
# #
# Copyright (C) 2016,2017 Kevin O'Connor <kevin@koconnor.net> # Copyright (C) 2014 Kevin O'Connor <kevin@koconnor.net>
# #
# This file may be distributed under the terms of the GNU GPLv3 license. # This file may be distributed under the terms of the GNU LGPLv3 license.
# Output directory # Output directory
OUT=out/ OUT=out/
@@ -15,6 +15,9 @@ export KCONFIG_CONFIG := $(CURDIR)/.config
-include $(KCONFIG_CONFIG) -include $(KCONFIG_CONFIG)
# Common command definitions # Common command definitions
ifeq ($(CONFIG_MACH_AVR),y)
CROSS_PREFIX=avr-
endif
CC=$(CROSS_PREFIX)gcc CC=$(CROSS_PREFIX)gcc
AS=$(CROSS_PREFIX)as AS=$(CROSS_PREFIX)as
LD=$(CROSS_PREFIX)ld LD=$(CROSS_PREFIX)ld
@@ -22,29 +25,32 @@ OBJCOPY=$(CROSS_PREFIX)objcopy
OBJDUMP=$(CROSS_PREFIX)objdump OBJDUMP=$(CROSS_PREFIX)objdump
STRIP=$(CROSS_PREFIX)strip STRIP=$(CROSS_PREFIX)strip
CPP=cpp CPP=cpp
PYTHON=python2 PYTHON=python
# Source files # Source files
src-y = src-y=sched.c command.c
dirs-y = src src-$(CONFIG_MACH_AVR) += avr/main.c avr/timer.c
src-$(CONFIG_MACH_SIMU) += simulator/main.c
src-$(CONFIG_AVR_WATCHDOG) += avr/watchdog.c
src-$(CONFIG_AVR_SERIAL) += avr/serial.c
DIRS=src src/avr src/simulator
# Default compiler flags # Default compiler flags
cc-option=$(shell if test -z "`$(1) $(2) -S -o /dev/null -xc /dev/null 2>&1`" \ cc-option=$(shell if test -z "`$(1) $(2) -S -o /dev/null -xc /dev/null 2>&1`" \
; then echo "$(2)"; else echo "$(3)"; fi ;) ; then echo "$(2)"; else echo "$(3)"; fi ;)
CFLAGS := -I$(OUT) -Isrc -I$(OUT)board-generic/ -std=gnu11 -O2 -MD -g \ CFLAGS-y := -I$(OUT) -Isrc -Os -MD -g \
-Wall -Wold-style-definition $(call cc-option,$(CC),-Wtype-limits,) \ -Wall -Wold-style-definition $(call cc-option,$(CC),-Wtype-limits,) \
-ffunction-sections -fdata-sections -ffunction-sections -fdata-sections
CFLAGS += -flto -fwhole-program -fno-use-linker-plugin CFLAGS-y += -flto -fwhole-program
CFLAGS-$(CONFIG_MACH_AVR) += -mmcu=$(CONFIG_AVR_MCU) -DF_CPU=$(CONFIG_AVR_FREQ)
CFLAGS := $(CFLAGS-y)
CFLAGS_klipper.elf = $(CFLAGS) -Wl,--gc-sections LDFLAGS-$(CONFIG_MACH_AVR) := -Wl,--gc-sections -Wl,--relax
LDFLAGS-$(CONFIG_MACH_AVR) += -Wl,-u,vfprintf -lprintf_min -lm
LDFLAGS := $(LDFLAGS-y)
CPPFLAGS = -I$(OUT) -P -MD -MT $@ CPPFLAGS = -P -MD -MT $@
# Default targets
target-y := $(OUT)klipper.elf
all:
# Run with "make V=1" to see the actual compile commands # Run with "make V=1" to see the actual compile commands
ifdef V ifdef V
@@ -54,44 +60,42 @@ Q=@
MAKEFLAGS += --no-print-directory MAKEFLAGS += --no-print-directory
endif endif
# Include board specific makefile # Default targets
include src/Makefile target-y := $(OUT)klipper.elf
-include src/$(patsubst "%",%,$(CONFIG_BOARD_DIRECTORY))/Makefile
all: $(target-y)
################ Common build rules ################ Common build rules
$(OUT)%.o: %.c $(OUT)autoconf.h $(OUT)board-link $(OUT)%.o: %.c $(OUT)autoconf.h $(OUT)board
@echo " Compiling $@" @echo " Compiling $@"
$(Q)$(CC) $(CFLAGS) -c $< -o $@ $(Q)$(CC) $(CFLAGS) -c $< -o $@
################ Main build rules ################ Main build rules
$(OUT)board-link: $(KCONFIG_CONFIG) $(OUT)board: $(KCONFIG_CONFIG)
@echo " Creating symbolic link $(OUT)board" @echo " Creating symbolic link $@"
$(Q)mkdir -p $(addprefix $(OUT), $(dirs-y)) $(Q)rm -f $@
$(Q)touch $@ $(Q)ln -sf $(PWD)/src/$(CONFIG_BOARD_DIRECTORY) $@
$(Q)ln -Tsf $(PWD)/src/$(CONFIG_BOARD_DIRECTORY) $(OUT)board
$(Q)mkdir -p $(OUT)board-generic
$(Q)ln -Tsf $(PWD)/src/generic $(OUT)board-generic/board
$(OUT)%.o.ctr: $(OUT)%.o $(OUT)declfunc.lds: src/declfunc.lds.S
$(Q)$(OBJCOPY) -j '.compile_time_request' -O binary $^ $@ @echo " Precompiling $@"
$(Q)$(CPP) $(CPPFLAGS) -D__ASSEMBLY__ $< -o $@
$(OUT)compile_time_request.o: $(patsubst %.c, $(OUT)src/%.o.ctr,$(src-y)) ./scripts/buildcommands.py $(OUT)klipper.o: $(patsubst %.c, $(OUT)src/%.o,$(src-y)) $(OUT)declfunc.lds
@echo " Building $@"
$(Q)cat $(patsubst %.c, $(OUT)src/%.o.ctr,$(src-y)) > $(OUT)klipper.compile_time_request
$(Q)$(PYTHON) ./scripts/buildcommands.py -d $(OUT)klipper.dict -t "$(CC);$(AS);$(LD);$(OBJCOPY);$(OBJDUMP);$(STRIP)" $(OUT)klipper.compile_time_request $(OUT)compile_time_request.c
$(Q)$(CC) $(CFLAGS) -c $(OUT)compile_time_request.c -o $@
$(OUT)klipper.elf: $(patsubst %.c, $(OUT)src/%.o,$(src-y)) $(OUT)compile_time_request.o
@echo " Linking $@" @echo " Linking $@"
$(Q)$(CC) $^ $(CFLAGS_klipper.elf) -o $@ $(Q)$(CC) $(CFLAGS) -Wl,-r -Wl,-T,$(OUT)declfunc.lds -nostdlib $(patsubst %.c, $(OUT)src/%.o,$(src-y)) -o $@
$(OUT)klipper.elf: $(OUT)klipper.o
@echo " Linking $@"
$(Q)$(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@
################ Kconfig rules ################ Kconfig rules
define do-kconfig define do-kconfig
$(Q)mkdir -p $(OUT)/scripts/kconfig/lxdialog $(Q)mkdir -p $(OUT)/scripts/kconfig/lxdialog
$(Q)mkdir -p $(OUT)/include/config $(Q)mkdir -p $(OUT)/include/config
$(Q)mkdir -p $(addprefix $(OUT), $(DIRS))
$(Q)$(MAKE) -C $(OUT) -f $(CURDIR)/scripts/kconfig/Makefile srctree=$(CURDIR) src=scripts/kconfig obj=scripts/kconfig Q=$(Q) Kconfig=$(CURDIR)/src/Kconfig $1 $(Q)$(MAKE) -C $(OUT) -f $(CURDIR)/scripts/kconfig/Makefile srctree=$(CURDIR) src=scripts/kconfig obj=scripts/kconfig Q=$(Q) Kconfig=$(CURDIR)/src/Kconfig $1
endef endef
@@ -107,12 +111,10 @@ help: ; $(call do-kconfig, $@)
.PHONY : all clean distclean FORCE .PHONY : all clean distclean FORCE
.DELETE_ON_ERROR: .DELETE_ON_ERROR:
all: $(target-y)
clean: clean:
$(Q)rm -rf $(OUT) $(Q)rm -rf $(OUT)
distclean: clean distclean: clean
$(Q)rm -f .config .config.old $(Q)rm -f .config .config.old
-include $(OUT)*.d $(patsubst %,$(OUT)%/*.d,$(dirs-y)) -include $(patsubst %,$(OUT)%/*.d,$(DIRS))

29
README.md
View File

@@ -1,29 +0,0 @@
Welcome to the Klipper project!
This project implements a 3d-printer firmware. There are two parts to
this firmware - code that runs on a micro-controller and code that
runs on a host machine. The host software does the work to build a
schedule of events, while the micro-controller software does the work
to execute the provided schedule at the specified times.
See the [features](docs/Features.md) document to find out why you
should use Klipper. To begin using Klipper start by
[installing](docs/Installation.md) it.
There is also [developer documentation](docs/Overview.md) available.
License
=======
Klipper is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
Klipper is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with Klipper. If not, see <http://www.gnu.org/licenses/>.

78
config/avrsim.cfg
View File

@@ -1,78 +0,0 @@
# Support for internal testing with the "simulavr" program. To use
# this config, compile the firmware for an AVR atmega644p, disable the
# AVR watchdog timer, set the MCU frequency to 20000000, and set the
# serial baud rate to 250000.
[stepper_x]
# Pins: PA5, PA4, PA1
step_pin: ar29
dir_pin: ar28
enable_pin: ar25
step_distance: .0225
endstop_pin: ^ar0
position_min: -0.25
position_endstop: 0
position_max: 200
[stepper_y]
# Pins: PA3, PA2
step_pin: ar27
dir_pin: ar26
enable_pin: ar25
step_distance: .0225
endstop_pin: ^ar1
position_min: -0.25
position_endstop: 0
position_max: 200
[stepper_z]
# Pins: PC7, PC6
step_pin: ar23
dir_pin: ar22
enable_pin: ar25
step_distance: .005
endstop_pin: ^ar2
position_min: 0.1
position_endstop: 0.5
position_max: 200
[extruder]
# Pins: PC3, PC2
step_pin: ar19
dir_pin: ar18
enable_pin: ar25
step_distance: .004242
nozzle_diameter: 0.500
filament_diameter: 3.500
heater_pin: ar4
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog7
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
min_extrude_temp: 0
max_temp: 210
[heater_bed]
heater_pin: ar3
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog0
control: watermark
min_temp: 0
max_temp: 110
[fan]
pin: ar14
[mcu]
serial: /tmp/pseudoserial
pin_map: arduino
[printer]
kinematics: cartesian
max_velocity: 500
max_accel: 3000
max_z_velocity: 250
max_z_accel: 30

81
config/example-corexy.cfg
View File

@@ -1,81 +0,0 @@
# This file serves as documentation for config parameters of corexy
# style printers. One may copy and edit this file to configure a new
# corexy printer. Only parameters unique to corexy printers are
# described here - see the "example.cfg" file for description of
# common config parameters.
# DO NOT COPY THIS FILE WITHOUT CAREFULLY READING AND UPDATING IT
# FIRST. Incorrectly configured parameters may cause damage.
# The stepper_x section is used to describe the X axis as well as the
# stepper controlling the X+Y movement.
[stepper_x]
step_pin: ar54
dir_pin: ar55
enable_pin: !ar38
step_distance: .01
endstop_pin: ^ar3
position_endstop: 0
position_max: 200
homing_speed: 50
# The stepper_y section is used to describe the Y axis as well as the
# stepper controlling the X-Y movement.
[stepper_y]
step_pin: ar60
dir_pin: ar61
enable_pin: !ar56
step_distance: .01
endstop_pin: ^ar14
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_z]
step_pin: ar46
dir_pin: ar48
enable_pin: !ar62
step_distance: .0025
endstop_pin: ^ar18
position_endstop: 0.5
position_max: 200
[extruder]
step_pin: ar26
dir_pin: ar28
enable_pin: !ar24
step_distance: .0022
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: ar10
sensor_type: ATC Semitec 104GT-2
sensor_pin: analog13
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
[heater_bed]
heater_pin: ar8
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog14
control: watermark
min_temp: 0
max_temp: 130
[fan]
pin: ar9
[mcu]
serial: /dev/ttyACM0
pin_map: arduino
[printer]
kinematics: corexy
# This option must be "corexy" for corexy printers.
max_velocity: 300
max_accel: 3000
max_z_velocity: 25
max_z_accel: 30

131
config/example-delta.cfg
View File

@@ -1,131 +0,0 @@
# This file serves as documentation for config parameters of delta
# style printers. One may copy and edit this file to configure a new
# delta printer. Only parameters unique to delta printers are
# described here - see the "example.cfg" file for description of
# common config parameters.
# DO NOT COPY THIS FILE WITHOUT CAREFULLY READING AND UPDATING IT
# FIRST. Incorrectly configured parameters may cause damage.
# The stepper_a section describes the stepper controlling the front
# left tower (at 210 degrees). This section also controls the homing
# parameters (homing_speed, homing_retract_dist) for all towers.
[stepper_a]
step_pin: ar54
dir_pin: ar55
enable_pin: !ar38
step_distance: .01
endstop_pin: ^ar2
homing_speed: 50
position_endstop: 297.05
# Distance (in mm) between the nozzle and the bed when the nozzle is
# in the center of the build area and the endstop triggers. This
# parameter must be provided for stepper_a; for stepper_b and
# stepper_c this parameter defaults to the value specified for
# stepper_a.
arm_length: 333.0
# Length (in mm) of the diagonal rod that connects this tower to the
# print head. This parameter must be provided for stepper_a; for
# stepper_b and stepper_c this parameter defaults to the value
# specified for stepper_a.
#angle:
# This option specifies the angle (in degrees) that the tower is
# at. The default is 210 for stepper_a, 330 for stepper_b, and 90
# for stepper_c.
# The stepper_b section describes the stepper controlling the front
# right tower (at 330 degrees).
[stepper_b]
step_pin: ar60
dir_pin: ar61
enable_pin: !ar56
step_distance: .01
endstop_pin: ^ar15
# The stepper_c section describes the stepper controlling the rear
# tower (at 90 degrees).
[stepper_c]
step_pin: ar46
dir_pin: ar48
enable_pin: !ar62
step_distance: .01
endstop_pin: ^ar19
[extruder]
step_pin: ar26
dir_pin: ar28
enable_pin: !ar24
step_distance: .0022
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: ar10
sensor_type: ATC Semitec 104GT-2
sensor_pin: analog13
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
[heater_bed]
heater_pin: ar8
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog14
control: watermark
min_temp: 0
max_temp: 130
# Print cooling fan (omit section if fan not present).
#[fan]
#pin: ar9
[mcu]
serial: /dev/ttyACM0
pin_map: arduino
[printer]
kinematics: delta
# This option must be "delta" for linear delta printers.
max_velocity: 300
# Maximum velocity (in mm/s) of the toolhead relative to the
# print. This parameter must be specified.
max_accel: 3000
# Maximum acceleration (in mm/s^2) of the toolhead relative to the
# print. This parameter must be specified.
max_z_velocity: 150
# For delta printers this limits the maximum velocity (in mm/s) of
# moves with z axis movement. This setting can be used to reduce the
# maximum speed of up/down moves (which require a higher step rate
# than other moves on a delta printer). The default is to use
# max_velocity for max_z_velocity.
#minimum_z_position: 0
# The minimum Z position that the user may command the head to move
# to. The default is 0.
delta_radius: 174.75
# Radius (in mm) of the horizontal circle formed by the three linear
# axis towers. This parameter may also be calculated as:
# delta_radius = smooth_rod_offset - effector_offset - carriage_offset
# This parameter must be provided.
# The delta_calibrate section enables a DELTA_CALIBRATE extended
# g-code command that can calibrate the tower endstop positions and
# angles.
[delta_calibrate]
radius: 50
# Radius (in mm) of the area that may be probed. This is the radius
# of nozzle coordinates to be probed; if using an automatic probe
# with an XY offset then choose a radius small enough so that the
# probe always fits over the bed. This parameter must be provided.
#speed: 50
# The speed (in mm/s) of non-probing moves during the calibration.
# The default is 50.
#horizontal_move_z: 5
# The height (in mm) that the head should be commanded to move to
# just prior to starting a probe operation. The default is 5.
#samples: 1
# The number of times to probe each point. The probed z-values will
# be averaged. The default is to probe 1 time.
#sample_retract_dist: 2.0
# The distance (in mm) to retract between each sample if sampling
# more than once. The default is 2mm.

1053
config/example-extras.cfg
View File

File diff suppressed because it is too large Load Diff

186
config/example-menu.cfg
View File

@@ -1,186 +0,0 @@
# This file serves as documentation for config parameters. One may
# copy and edit this file to configure a new menu layout.
# The snippets in this file may be copied into the main printer.cfg file.
# See the "example.cfg" file for description of common config parameters.
# Available menu elements:
# item - purely visual element
# command - same like 'item' but with gcode trigger
# input - same like 'command' but has value changing capabilities
# list - menu element container, with entry and exit gcode triggers
# vsdcard - same as 'list' but will append files from virtual sdcard
# deck - special container for custom screens (cards) has entry and exit gcode triggers.
# card - special content card for custom screens. Can only be used in 'deck'!
#[menu item1]
#type: item
# Type will determine menu item properties and behaviours:
#name:
# This is mandatory attribute for every menu element.
# You can use Python output formatting for parameter and transform values.
# Quotes can be used in the beginning and end of name.
#cursor:
# It allows to change cursor character for selected menu element.
# The default is >
# This parameter is optional.
#width:
# This attribute accepts integer value. Element name is cut to this width.
# This parameter is optional.
#scroll:
# This attribute accepts static boolean value. You can use it together with 'width'.
# When this is enabled then names longer than width are scrolled back and forth.
# The default is disabled. This parameter is optional.
#enable:
# This attribute accepts static boolean values and parameters (converted to boolean).
# It accepts multiple logical expressions. Values separated by comma will return True if all elements are true.
# Values on different lines will return True if any element is true.
# You can use logical negation by using character ! as parameter prefix.
#parameter:
# This attribute accepts float values or special variables. Multiple values are delimited by comma.
# All available parameter variables can be listed by 'MENU DO=dump' gcode, menu itself must be running.
# This value is available for output formatting as {0}..{n} Where n is count of parameters.
#transform:
# This attribute allows to transform parameters value to something else.
# More than one transformation can be added. Each transformation must be on separate line.
# These transformed values are available for output formatting as {n+1}..{x}
# Where n is count of parameters and x is count of transformations.
# In order to transform the value of a particular parameter, you must add
# an parameter index as prefix. Like this "transform: 1.choose('OFF','ON')"
# If the index is not set then the default index 0 is used.
#
# map(fromLow,fromHigh,toLow,toHigh) - interpolate re-maps a parameter value from one range to another.
# Output value type is taken from toHigh. It can be int or float.
#
# choose(e1,e2) - boolean chooser, converts the value of the parameter to the boolean type (0 and 1),
# and selects the corresponding value by the index from the list.
#
# choose(e1,e2,...) - int chooser, converts the value of the parameter to the int type
# and selects the corresponding value by the index from the list.
#
# choose({key:value,..}) - special dictionary chooser, parameter value cast type by first key type.
# Selects the corresponding value by the key from the dictionary.
#
# int(), float(), bool(), str(), abs(), bin(), hex(), oct(), days(), hours(), minutes(), seconds()
# These will convert parameter value to the special form.
# int,float,bool,str,abs,bin,hex and oct are python functions.
# days,hours,minutes,seconds will convert parameter value (it's taken as seconds) to time specific value
#
# scale(xx) - Multiplies parameter value by this xx. Pure interger or float value is excpected.
#[menu command1]
#type:command
#name:
#cursor:
#width:
#scroll:
#enable:
#parameter:
#transform:
#gcode:
# When menu element is clicked then gcodes on this attribute will be executed.
# Can have multiline gcode script and supports output formatting for parameter and transform values.
#action:
# Special action can be executed. Supports [back, exit] menu commands
# and [respond response_info] command. Respond command will send '// response_info' to host.
#[menu input1]
#name:
#cursor:
#width:
#enable:
#transform:
#parameter:
# Value from parameter (always index 0) is taken as input value when in edit mode.
#gcode:
# This will be triggered in realtime or on exit from edit mode.
#reverse:
# This attribute accepts static boolean value.
# When enabled it will reverse increment and decrement directions for input.
# The default is False. This parameter is optional.
#readonly:
# This attribute accepts same logical expression as 'enable'.
# When true then input element is readonly like 'item' and cannot enter to edit mode.
# The default is False. This parameter is optional.
#realtime:
# This attribute accepts static boolean value.
# When enabled it will execute gcode after each value change.
# The default is False. This parameter is optional.
#input_min:
# It accepts integer or float value. Will set minimal bound for edit value.
# The default is 2.2250738585072014e-308. This parameter is optional.
#input_max:
# It accepts integer or float value. Will set maximal bound for edit value.
# The default is 1.7976931348623157e+308. This parameter is optional.
#input_step:
# This is mandatory attribute for input.
# It accepts positive integer or float value. Will determine increment
# and decrement steps for edit value.
#input_step2:
# This is optional attribute for input.
# It accepts positive integer or float value. Will determine fast rate
# increment and decrement steps for edit value.
# The default is 0 (input_step will be used instead)
#[menu list1]
#type:list or vsdcard
#name:
#cursor:
#width:
#scroll:
#enable:
#enter_gcode:
# Will trigger gcode script when entering to this menu container.
# This parameter is optional.
#leave_gcode:
# Will trigger gcode script when leaving from this menu container.
# This parameter is optional.
#show_back:
# This attribute accepts static boolean value.
# Show back [..] as first element.
# The default is True. This parameter is optional.
#show_title:
# This attribute accepts static boolean value.
# Show container name next to back [..] element.
# The default is True. This parameter is optional.
#items:
# Menu elements listed in this container.
# Each element must be on separate line.
# Elements can be grouped on same line by separating them with comma
#
# When element name stars with . then menu system will add parent
# container config name as prefix to element name (delimited by space)
#[menu infodeck]
#type: deck
#name:
#cursor:
#width:
#scroll:
#enable:
#enter_gcode
#leave_gcode
#longpress_menu:
# Entry point to menu container. When this attribute is set then
# long press > 1s will initiate this menu container if not in edit mode.
# The default is disabled. This parameter is optional.
#items:
# It accepts only 'card' elements. You are able to switch between different card screens
# by using encoder or up/down buttons.
#[menu card1]
#type: card
#name:
#content:
# Card screen content. Each line represents display line.
# Quotes can be used in the beginning and end of line.
# Rendered elements are available for output formatting as {0}..{x}. It's always string type.
#items:
# List of elements in card. Each line represents a single index for content formatting.
# It's possible to show multiple elements in one place by separating them with comma on single line.
# If first element is integer then timed cycle is used (integer value is cycle time in seconds)
# If no integer element then first enabled element is shown.
# In cycler multiple elements can be grouped into one postition by separating them with |
# This way only simple menu items can be grouped.
# Example: 5,prt_time, prt_progress - elements prt_time and prt_progress are switched after 5s
# Example: msg,xpos|ypos - elements xpos and ypos are grouped and showed together when msg is disabled.

87
config/example-multi-mcu.cfg
View File

@@ -1,87 +0,0 @@
# This file contains an example configuration with three
# micro-controllers simultaneously controlling a single printer.
# See both the example.cfg and example-extras.cfg file for a
# description of available parameters.
# The main micro-controller is used as the timing source for all the
# micro-controllers on the printer. Typically, both the X and Y axes
# are connected to the main micro-controller.
[mcu]
serial: /dev/serial/by-path/platform-3f980000.usb-usb-0:1.2:1.0-port0
pin_map: arduino
# The "zboard" micro-controller will be used to control the Z axis.
[mcu zboard]
serial: /dev/serial/by-path/platform-3f980000.usb-usb-0:1.3:1.0-port0
pin_map: arduino
# The "auxboard" micro-controller will be used to control the heaters.
[mcu auxboard]
serial: /dev/serial/by-path/platform-3f980000.usb-usb-0:1.4:1.0-port0
pin_map: arduino
[stepper_x]
step_pin: ar54
dir_pin: ar55
enable_pin: !ar38
step_distance: .0125
endstop_pin: ^ar3
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_y]
step_pin: ar60
dir_pin: !ar61
enable_pin: !ar56
step_distance: .0125
endstop_pin: ^ar14
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_z]
step_pin: zboard:ar46
dir_pin: zboard:ar48
enable_pin: !zboard:ar62
step_distance: .0025
endstop_pin: ^zboard:ar18
position_endstop: 0.5
position_max: 200
[extruder]
step_pin: auxboard:ar26
dir_pin: auxboard:ar28
enable_pin: !auxboard:ar24
step_distance: .002
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: auxboard:ar10
sensor_type: EPCOS 100K B57560G104F
sensor_pin: auxboard:analog13
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
[heater_bed]
heater_pin: auxboard:ar8
sensor_type: EPCOS 100K B57560G104F
sensor_pin: auxboard:analog14
control: watermark
min_temp: 0
max_temp: 130
[fan]
pin: auxboard:ar9
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100

312
config/example.cfg
View File

@@ -1,312 +0,0 @@
# This file serves as documentation for config parameters. One may
# copy and edit this file to configure a new cartesian style
# printer. For delta style printers, see the "example-delta.cfg"
# file. For corexy/h-bot style printers, see the "example-corexy.cfg"
# file. Only common config sections are described here - see the
# "example-extras.cfg" file for configuring less common devices.
# DO NOT COPY THIS FILE WITHOUT CAREFULLY READING AND UPDATING IT
# FIRST. Incorrectly configured parameters may cause damage.
# A note on pin names: pins may be configured with a hardware name
# (such as "PA4") or with an Arduino alias name (such as "ar29" or
# "analog3"). In order to use Arduino names, the pin_map variable in
# the mcu section must be present and have a value of "arduino".
# Pin names may be preceded by an '!' to indicate that a reverse
# polarity should be used (eg, trigger on low instead of high). Input
# pins may be preceded by a '^' to indicate that a hardware pull-up
# resistor should be enabled for the pin.
# The stepper_x section is used to describe the stepper controlling
# the X axis in a cartesian robot.
[stepper_x]
step_pin: ar54
# Step GPIO pin (triggered high). This parameter must be provided.
dir_pin: ar55
# Direction GPIO pin (high indicates positive direction). This
# parameter must be provided.
enable_pin: !ar38
# Enable pin (default is enable high; use ! to indicate enable
# low). If this parameter is not provided then the stepper motor
# driver must always be enabled.
step_distance: .0225
# Distance in mm that each step causes the axis to travel. This
# parameter must be provided.
endstop_pin: ^ar3
# Endstop switch detection pin. This parameter must be provided for
# the X, Y, and Z steppers on cartesian style printers.
#position_min: 0
# Minimum valid distance (in mm) the user may command the stepper to
# move to. The default is 0mm.
position_endstop: 0
# Location of the endstop (in mm). This parameter must be provided
# for the X, Y, and Z steppers on cartesian style printers.
position_max: 200
# Maximum valid distance (in mm) the user may command the stepper to
# move to. This parameter must be provided for the X, Y, and Z
# steppers on cartesian style printers.
#homing_speed: 5.0
# Maximum velocity (in mm/s) of the stepper when homing. The default
# is 5mm/s.
#homing_retract_dist: 5.0
# Distance to backoff (in mm) before homing a second time during
# homing. Set this to zero to disable the second home. The default
# is 5mm.
#second_homing_speed:
# Velocity (in mm/s) of the stepper when performing the second home.
# The default is homing_speed/2.
#homing_positive_dir:
# If true, homing will cause the stepper to move in a positive
# direction (away from zero); if false, home towards zero. The
# default is true if position_endstop is near position_max and false
# if near position_min.
# The stepper_y section is used to describe the stepper controlling
# the Y axis in a cartesian robot. It has the same settings as the
# stepper_x section.
[stepper_y]
step_pin: ar60
dir_pin: !ar61
enable_pin: !ar56
step_distance: .0225
endstop_pin: ^ar14
position_endstop: 0
position_max: 200
# The stepper_z section is used to describe the stepper controlling
# the Z axis in a cartesian robot. It has the same settings as the
# stepper_x section.
[stepper_z]
step_pin: ar46
dir_pin: ar48
enable_pin: !ar62
step_distance: .005
endstop_pin: ^ar18
position_endstop: 0.5
position_max: 200
# The extruder section is used to describe both the stepper
# controlling the printer extruder and the heater parameters for the
# nozzle. The stepper configuration has the same settings as the
# stepper_x section and the heater configuration has the same settings
# as the heater_bed section (described below).
[extruder]
step_pin: ar26
dir_pin: ar28
enable_pin: !ar24
step_distance: .004242
nozzle_diameter: 0.500
# Diameter of the nozzle orifice (in mm). This parameter must be
# provided.
filament_diameter: 3.500
# The nominal diameter of the raw filament (in mm) as it enters the
# extruder. This parameter must be provided.
#max_extrude_cross_section:
# Maximum area (in mm^2) of an extrusion cross section (eg,
# extrusion width multiplied by layer height). This setting prevents
# excessive amounts of extrusion during relatively small XY moves.
# If a move requests an extrusion rate that would exceed this value
# it will cause an error to be returned. The default is: 4.0 *
# nozzle_diameter^2
#max_extrude_only_distance: 50.0
# Maximum length (in mm of raw filament) that a retraction or
# extrude-only move may have. If a retraction or extrude-only move
# requests a distance greater than this value it will cause an error
# to be returned. The default is 50mm.
#max_extrude_only_velocity:
#max_extrude_only_accel:
# Maximum velocity (in mm/s) and acceleration (in mm/s^2) of the
# extruder motor for retractions and extrude-only moves. These
# settings do not place any limit on normal printing moves. If not
# specified then they are calculated to match the limit an XY
# printing move with a cross section of 4.0*nozzle_diameter^2 would
# have.
#pressure_advance: 0.0
# The amount of raw filament to push into the extruder during
# extruder acceleration. An equal amount of filament is retracted
# during deceleration. It is measured in millimeters per
# millimeter/second. The default is 0, which disables pressure
# advance.
#pressure_advance_lookahead_time: 0.010
# A time (in seconds) to "look ahead" at future extrusion moves when
# calculating pressure advance. This is used to reduce the
# application of pressure advance during cornering moves that would
# otherwise cause retraction followed immediately by pressure
# buildup. This setting only applies if pressure_advance is
# non-zero. The default is 0.010 (10 milliseconds).
#
# The remaining variables describe the extruder heater.
heater_pin: ar10
# PWM output pin controlling the heater. This parameter must be
# provided.
#max_power: 1.0
# The maximum power (expressed as a value from 0.0 to 1.0) that the
# heater_pin may be set to. The value 1.0 allows the pin to be set
# fully enabled for extended periods, while a value of 0.5 would
# allow the pin to be enabled for no more than half the time. This
# setting may be used to limit the total power output (over extended
# periods) to the heater. The default is 1.0.
sensor_type: EPCOS 100K B57560G104F
# Type of sensor - this may be "EPCOS 100K B57560G104F", "ATC
# Semitec 104GT-2", "NTC 100K beta 3950", "Honeywell 100K
# 135-104LAG-J01", "NTC 100K MGB18-104F39050L32", "AD595", "PT100
# INA826", "MAX6675", "MAX31855", "MAX31856", or "MAX31865".
# Additional sensor types may be available - see the
# example-extras.cfg file for details. This parameter must be
# provided.
sensor_pin: analog13
# Analog input pin connected to the sensor. This parameter must be
# provided.
#pullup_resistor: 4700
# The resistance (in ohms) of the pullup attached to the
# thermistor. This parameter is only valid when the sensor is a
# thermistor. The default is 4700 ohms.
#adc_voltage: 5.0
# The ADC comparison voltage. This parameter is only valid when the
# sensor is an AD595 or "PT100 INA826". The default is 5 volts.
#smooth_time: 2.0
# A time value (in seconds) over which temperature measurements will
# be smoothed to reduce the impact of measurement noise. The default
# is 2 seconds.
control: pid
# Control algorithm (either pid or watermark). This parameter must
# be provided.
pid_Kp: 22.2
# Kp is the "proportional" constant for the pid. This parameter must
# be provided for PID heaters.
pid_Ki: 1.08
# Ki is the "integral" constant for the pid. This parameter must be
# provided for PID heaters.
pid_Kd: 114
# Kd is the "derivative" constant for the pid. This parameter must
# be provided for PID heaters.
#pid_integral_max:
# The maximum "windup" the integral term may accumulate. The default
# is to use the same value as max_power.
#pwm_cycle_time: 0.100
# Time in seconds for each software PWM cycle of the heater. It is
# not recommended to set this unless there is an electrical
# requirement to switch the heater faster than 10 times a second.
# The default is 0.100 seconds.
#min_extrude_temp: 170
# The minimum temperature (in Celsius) at which extruder move
# commands may be issued. The default is 170 Celsius.
min_temp: 0
max_temp: 210
# The maximum range of valid temperatures (in Celsius) that the
# heater must remain within. This controls a safety feature
# implemented in the micro-controller code - should the measured
# temperature ever fall outside this range then the micro-controller
# will go into a shutdown state. This check can help detect some
# heater and sensor hardware failures. Set this range just wide
# enough so that reasonable temperatures do not result in an
# error. These parameters must be provided.
# The heater_bed section describes a heated bed (if present - omit
# section if not present).
[heater_bed]
heater_pin: ar8
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog14
control: watermark
#max_delta: 2.0
# On 'watermark' controlled heaters this is the number of degrees in
# Celsius above the target temperature before disabling the heater
# as well as the number of degrees below the target before
# re-enabling the heater. The default is 2 degrees Celsius.
min_temp: 0
max_temp: 110
# Print cooling fan (omit section if fan not present).
[fan]
pin: ar9
# PWM output pin controlling the fan. This parameter must be
# provided.
#max_power: 1.0
# The maximum power (expressed as a value from 0.0 to 1.0) that the
# pin may be set to. The value 1.0 allows the pin to be set fully
# enabled for extended periods, while a value of 0.5 would allow the
# pin to be enabled for no more than half the time. This setting may
# be used to limit the total power output (over extended periods) to
# the fan. If this value is less than 1.0 then fan speed requests
# will be scaled between zero and max_power (for example, if
# max_power is .9 and a fan speed of 80% is requested then the fan
# power will be set to 72%). The default is 1.0.
#shutdown_speed: 0
# The desired fan speed (expressed as a value from 0.0 to 1.0) if
# the micro-controller software enters an error state. The default
# is 0.
#cycle_time: 0.010
# The amount of time (in seconds) for each PWM power cycle to the
# fan. It is recommended this be 10 milliseconds or greater when
# using software based PWM. The default is 0.010 seconds.
#hardware_pwm: False
# Enable this to use hardware PWM instead of software PWM. The
# default is False.
#kick_start_time: 0.100
# Time (in seconds) to run the fan at full speed when first enabling
# it (helps get the fan spinning). The default is 0.100 seconds.
# Micro-controller information.
[mcu]
serial: /dev/ttyACM0
# The serial port to connect to the MCU. If unsure (or if it
# changes) see the "Where's my serial port?" section of the FAQ. The
# default is /dev/ttyS0
#baud: 250000
# The baud rate to use. The default is 250000.
pin_map: arduino
# This option may be used to enable Arduino pin name aliases. The
# default is to not enable the aliases.
#restart_method:
# This controls the mechanism the host will use to reset the
# micro-controller. The choices are 'arduino', 'rpi_usb', and
# 'command'. The 'arduino' method (toggle DTR) is common on Arduino
# boards and clones. The 'rpi_usb' method is useful on Raspberry Pi
# boards with micro-controllers powered over USB - it briefly
# disables power to all USB ports to accomplish a micro-controller
# reset. The 'command' method involves sending a Klipper command to
# the micro-controller so that it can reset itself. The default is
# 'arduino' if the micro-controller communicates over a serial port,
# 'command' otherwise.
# The printer section controls high level printer settings.
[printer]
kinematics: cartesian
# This option must be "cartesian" for cartesian printers.
max_velocity: 500
# Maximum velocity (in mm/s) of the toolhead (relative to the
# print). This parameter must be specified.
max_accel: 3000
# Maximum acceleration (in mm/s^2) of the toolhead (relative to the
# print). This parameter must be specified.
#max_accel_to_decel:
# A pseudo acceleration (in mm/s^2) controlling how fast the
# toolhead may go from acceleration to deceleration. It is used to
# reduce the top speed of short zig-zag moves (and thus reduce
# printer vibration from these moves). The default is half of
# max_accel.
max_z_velocity: 25
# For cartesian printers this sets the maximum velocity (in mm/s) of
# movement along the z axis. This setting can be used to restrict
# the maximum speed of the z stepper motor on cartesian
# printers. The default is to use max_velocity for max_z_velocity.
max_z_accel: 30
# For cartesian printers this sets the maximum acceleration (in
# mm/s^2) of movement along the z axis. It limits the acceleration
# of the z stepper motor on cartesian printers. The default is to
# use max_accel for max_z_accel.
#square_corner_velocity: 5.0
# The maximum velocity (in mm/s) that the toolhead may travel a 90
# degree corner at. A non-zero value can reduce changes in extruder
# flow rates by enabling instantaneous velocity changes of the
# toolhead during cornering. This value configures the internal
# centripetal velocity cornering algorithm; corners with angles
# larger than 90 degrees will have a higher cornering velocity while
# corners with angles less than 90 degrees will have a lower
# cornering velocity. If this is set to zero then the toolhead will
# decelerate to zero at each corner. The default is 5mm/s.
# Looking for more options? Check the example-extras.cfg file.

89
config/generic-cramps.cfg
View File

@@ -1,89 +0,0 @@
# This file contains an example configuration for a Beaglebone PRU
# micro-controller attached to a CRAMPS board.
# THIS FILE HAS NOT BEEN TESTED - PROCEED WITH CAUTION!
# NOTE: Klipper does not alter the input/output state of the
# Beaglebone pins and it does not control their pull-up resistors. In
# order to set the pin state one must use a "device tree overlay" or
# use the config-pin program.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: P8_13
dir_pin: P8_12
enable_pin: !P9_14
step_distance: .0125
endstop_pin: ^P8_8
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_y]
step_pin: P8_15
dir_pin: P8_14
enable_pin: !P9_14
step_distance: .0125
endstop_pin: ^P8_10
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_z]
step_pin: P8_19
dir_pin: P8_18
enable_pin: !P9_14
step_distance: .0025
endstop_pin: ^P9_13
position_endstop: 0
position_max: 200
[extruder]
step_pin: P9_16
dir_pin: P9_12
enable_pin: !P9_14
step_distance: .002
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: P9_15
sensor_type: EPCOS 100K B57560G104F
pullup_resistor: 2000
sensor_pin: host:analog5
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
[heater_bed]
heater_pin: P8_11
sensor_type: EPCOS 100K B57560G104F
pullup_resistor: 2000
sensor_pin: host:analog4
control: watermark
min_temp: 0
max_temp: 130
[fan]
pin: P9_41
[mcu]
serial: /dev/rpmsg_pru30
pin_map: beaglebone
[mcu host]
serial: /tmp/klipper_host_mcu
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100
[output_pin machine_enable]
pin: P9_23
value: 1
shutdown_value: 0

362
config/generic-duet2.cfg
View File

@@ -1,362 +0,0 @@
# This file contains common pin mappings for Duet2 boards. To use
# this config, the firmware should be compiled for the SAM4E8E.
# See the example.cfg file for a description of available parameters.
## Drivers
# Here are the pins for the 10 stepper drivers supported by a Duet2 board
# | Drive | DIR pin | STEP pin | ENDSTOP pin | SPI EN pin |
# |-------|----------|-----------|--------------|-------------|
# | X | PD11 | PD6 | PC14 | PD14 |
# | Y | PD12 | PD7 | PA2 | PC9 |
# | Z | PD13 | PD8 | PD29 | PC10 |
# | E0 | PA1 | PD5 | PD10 | PC17 |
# | E1 | PD9 | PD4 | PC16 | PC25 |
# | E2 | PD28 | PD2 | PE0* | PD23 |
# | E3 | PD22 | PD1 | PE1* | PD24 |
# | E4 | PD16 | PD0 | PE2* | PD25 |
# | E5 | PD17 | PD3 | PE3* | PD26 |
# | E6 | PA25 | PD21 | PA17* | PC28 |
# Pins marked with asterisks (*) are only assigned to these functions
# if no duex is connected. If a duex is connected, these endstops are
# remapped to the SX1509 on the Duex (unfortunately they can't be used
# as endstops in klipper, however one may use them as digital outs or
# PWM outs). The SPI EN pins are required for the TMC2660 drivers (use
# the SPI EN pin as 'cs_pin' in the respective config block). The
# **enable pin for all steppers** is TMC_EN = !PC6.
#
## Fans
# | FAN | PIN |
# |------|-----------------------|
# | FAN0 | PC23 |
# | FAN1 | PC26 |
# | FAN2 | PA0 |
# | FAN3 | sx1509_duex:PIN_12* |
# | FAN4 | sx1509_duex:PIN_7* |
# | FAN5 | sx1509_duex:PIN_6* |
# | FAN6 | sx1509_duex:PIN_5* |
# | FAN7 | sx1509_duex:PIN_4* |
# | FAN8 | sx1509_duex:PIN_15* |
# Pins marked with (*) assume the following sx1509 config section:
#[sx1509 duex]
#address: 0x3E
#
## Heaters and Thermistors
# | Extruder Drive | HEAT pin | TEMP pin |
# |----------------|-----------|-----------|
# | BED | PA19 | PC13 |
# | E0 | PA20 | PC15 |
# | E1 | PA16 | PC12 |
# | E2 | PC3 | PC29 |
# | E3 | PC5 | PC30 |
# | E4 | PC8 | PC31 |
# | E5 | PC11 | PC27 |
# | E6 | PA15 | PA18 |
#
## Misc pins
# | Name | Pin |
# |-------------|---------|
# | ZProbe_IN | PC1 |
# | PS_ON | PD15 |
# | LED_ONBOARD | PC2 |
# | SPI0_CS0 | PC24 |
# | SPI0_CS1 | PB2 |
# | SPI0_CS2 | PC18 |
# | SPI0_CS3 | PC19 |
# | SPI0_CS4 | PC20 |
# | SPI0_CS5 | PA24 |
# | SPI0_CS6 | PE1* |
# | SPI0_CS7 | PE2* |
# | SPI0_CS8 | PE3* |
# | SX1509_IRQ | PA17* |
# | SG_TST | PE0* |
# | ENC_SW | PA7 |
# | ENC_A | PA8 |
# | ENC_B | PC7 |
# | LCD_DB7 | PD18 |
# | LCD_DB6 | PD19 |
# | LCD_DB5 | PD20 |
# | LCD_DB4 | PD21** |
# | LCD_RS | PC28** |
# | LCD_E | PA25** |
# Pins marked with one asterisk (*) replace E2_STOP-E6_STOP if a duex is present
# Pins marked with two asterisks (**) share pins with drive E6.
# For the remaining pins check the schematics provided here: https://github.com/T3P3/Duet
[stepper_x]
step_pin: PD6
dir_pin: PD11
enable_pin: !PC6 # shared between all steppers
step_distance: .0125
endstop_pin: ^PC14
position_endstop: 0
position_max: 250
[tmc2660 stepper_x]
cs_pin: PD14 # X_SPI_EN Required for communication
spi_bus: 1 # All TMC2660 drivers are connected to USART1, which is bus 1 on the sam4e port
microsteps: 16
interpolate: True # 1/16 micro-steps interpolated to 1/256
run_current: 1.000
idle_current_percent: 20
[stepper_y]
step_pin: PD7
dir_pin: !PD12
enable_pin: !PC6
step_distance: .0125
endstop_pin: ^PA2
position_endstop: 0
position_max: 210
[tmc2660 stepper_y]
cs_pin: PC9
spi_bus: 1
microsteps: 16
interpolate: True
run_current: 1.000
idle_current_percent: 20
[stepper_z]
step_pin: PD8
dir_pin: PD13
enable_pin: !PC6
step_distance: .0025
endstop_pin: ^PD29
position_endstop: 0.5
position_max: 200
[tmc2660 stepper_z]
cs_pin: PC10
spi_bus: 1
microsteps: 16
interpolate: True
run_current: 1.000
#On drive E4
[stepper_z1]
step_pin: PD0
dir_pin: PD16
enable_pin: !PC6
step_distance: .0025
[tmc2660 stepper_z1]
cs_pin: PD25
spi_bus: 1
microsteps: 16
interpolate: True
run_current: 1.000
#On drive E5
[stepper_z2]
step_pin: PD3
dir_pin: !PD17
enable_pin: !PC6
step_distance: .0025
[tmc2660 stepper_z2]
cs_pin: PD26
spi_bus: 1
microsteps: 16
interpolate: True
run_current: 1.000
#On drive E6
[stepper_z3]
step_pin: PD21
dir_pin: !PA25
enable_pin: !PC6
step_distance: .0025
[tmc2660 stepper_z3]
cs_pin: PC28
spi_bus: 1
microsteps: 16
interpolate: True
run_current: 1.000
#On drive E0
[extruder0]
step_pin: PD5
dir_pin: PA1
enable_pin: !PC6
step_distance: .002
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PA20
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PC15
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
[tmc2660 extruder0]
cs_pin: PC17
spi_bus: 1
microsteps: 16
interpolate: True
run_current: 1.000
#On drive E1
[extruder1]
step_pin: PD4
dir_pin: PD9
enable_pin: !PC6
step_distance: .002
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PA16
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PC12
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
[tmc2660 extruder1]
cs_pin: PC25
spi_bus: 1
microsteps: 16
interpolate: True
run_current: 1.000
# On drive E2
[extruder2]
step_pin: PD2
dir_pin: !PD28
enable_pin: !PC6
step_distance: .002
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PC3
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PC29
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
[tmc2660 extruder2]
cs_pin: PD23
spi_bus: 1
microsteps: 16
interpolate: True
run_current: 1.000
# On drive E3
[extruder3]
step_pin: PD1
dir_pin: !PD22
enable_pin: !PC6
step_distance: .002
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PC5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PC30
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
[tmc2660 extruder3]
cs_pin: PD24
spi_bus: 1
microsteps: 16
interpolate: True
run_current: 1.000
[heater_bed]
heater_pin: PA19
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PC13
control: watermark
min_temp: 0
max_temp: 130
# Fan0
[fan]
pin: PC23
# Fan1 controlled by extruder0
[heater_fan nozzle_cooling_fan]
pin: PC26
heater: extruder0
heater_temp: 45
fan_speed: 1.0
# Fan2, controlled by E5_TEMP
[temperature_fan chamber_fan]
pin: PA0
max_power: 1
shutdown_speed: 1
cycle_time: 0.01
min_temp: 40
max_temp: 120
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PC27
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
[mcu]
serial: /dev/ttyACM0
restart_method: command
[sx1509 duex]
address: 0x3E # Address is fixed on duex boards
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100
[static_digital_output onboard_led]
pins: !PC2
[output_pin FAN3]
pin: !sx1509_duex:PIN_12
pwm: True
hardware_pwm: True # Only hardware PWM fans are supported
[output_pin FAN4]
pin: !sx1509_duex:PIN_7
pwm: True
hardware_pwm: True
[output_pin FAN5]
pin: !sx1509_duex:PIN_6
pwm: True
hardware_pwm: True
[output_pin FAN6]
pin: !sx1509_duex:PIN_5
pwm: True
hardware_pwm: True
[output_pin FAN7]
pin: !sx1509_duex:PIN_4
pwm: True
hardware_pwm: True
[output_pin FAN8]
pin: !sx1509_duex:PIN_15
pwm: True
hardware_pwm: True
[output_pin GPIO1] # General purpose pin broken out on the duex
pin: sx1509_duex:PIN_11
pwm: False
value: 1

106
config/generic-einsy-rambo.cfg
View File

@@ -1,106 +0,0 @@
# This file contains common pin mappings for Einsy Rambo boards. To use
# this config, the firmware should be compiled for the AVR atmega2560.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: PC0
dir_pin: PL0
enable_pin: !PA7
step_distance: .005
endstop_pin: ^PB6
#endstop_pin: tmc2130_stepper_x:virtual_endstop
position_endstop: 0
position_max: 250
[tmc2130 stepper_x]
cs_pin: PG0
microsteps: 16
run_current: .5
sense_resistor: 0.220
diag1_pin: !PK2
[stepper_y]
step_pin: PC1
dir_pin: !PL1
enable_pin: !PA6
step_distance: .005
endstop_pin: ^PB5
#endstop_pin: tmc2130_stepper_y:virtual_endstop
position_endstop: 0
position_max: 210
[tmc2130 stepper_y]
cs_pin: PG2
microsteps: 16
run_current: .5
sense_resistor: 0.220
diag1_pin: !PK7
[stepper_z]
step_pin: PC2
dir_pin: PL2
enable_pin: !PA5
step_distance: .0025
endstop_pin: ^PB4
#endstop_pin: tmc2130_stepper_z:virtual_endstop
position_endstop: 0.5
position_max: 200
[tmc2130 stepper_z]
cs_pin: PK5
microsteps: 16
run_current: .5
sense_resistor: 0.220
diag1_pin: !PK6
[extruder]
step_pin: PC3
dir_pin: PL6
enable_pin: !PA4
step_distance: .002
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PE5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PF0
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
[tmc2130 extruder]
cs_pin: PK4
microsteps: 16
run_current: .5
sense_resistor: 0.220
diag1_pin: !PK3
[heater_bed]
heater_pin: PG5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PF2
control: watermark
min_temp: 0
max_temp: 130
[fan]
pin: PH5
#[heater_fan nozzle_cooling_fan]
#pin: PH3
[mcu]
serial: /dev/ttyACM0
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100
[static_digital_output yellow_led]
pins: !PB7

79
config/generic-melzi.cfg
View File

@@ -1,79 +0,0 @@
# This file contains common pin mappings for Melzi v2.0 boards. To use
# this config, the firmware should be compiled for the AVR
# atmega1284p.
# Note, a number of Melzi boards are shipped with a bootloader that
# requires the following command to flash the board:
# avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
# If the above command does not work and "make flash" does not work
# then one may need to flash a bootloader to the board - see the
# Klipper docs/Bootloaders.md file for more information.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: PD7
dir_pin: PC5
enable_pin: !PD6
step_distance: .0125
endstop_pin: ^!PC2
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_y]
step_pin: PC6
dir_pin: PC7
enable_pin: !PD6
step_distance: .0125
endstop_pin: ^!PC3
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_z]
step_pin: PB3
dir_pin: !PB2
enable_pin: !PA5
step_distance: .0025
endstop_pin: ^!PC4
position_endstop: 0.5
position_max: 200
[extruder]
step_pin: PB1
dir_pin: PB0
enable_pin: !PD6
step_distance: .002
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PD5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PA7
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
[heater_bed]
heater_pin: PD2
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PA6
control: watermark
min_temp: 0
max_temp: 130
[fan]
pin: PB4
[mcu]
serial: /dev/ttyUSB0
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100

109
config/generic-mini-rambo.cfg
View File

@@ -1,109 +0,0 @@
# This file contains common pin mappings for Mini-RAMBo boards. To use
# this config, the firmware should be compiled for the AVR atmega2560.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: PC0
dir_pin: PL1
enable_pin: !PA7
step_distance: .005
endstop_pin: ^PB6
#endstop_pin: ^PC7
position_endstop: 0
position_max: 250
[stepper_y]
step_pin: PC1
dir_pin: !PL0
enable_pin: !PA6
step_distance: .005
endstop_pin: ^PB5
#endstop_pin: ^PA2
position_endstop: 0
position_max: 210
[stepper_z]
step_pin: PC2
dir_pin: PL2
enable_pin: !PA5
step_distance: .0025
endstop_pin: ^PB4
#endstop_pin: ^PA1
position_endstop: 0.5
position_max: 200
[extruder]
step_pin: PC3
dir_pin: PL6
enable_pin: !PA4
step_distance: .002
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PE5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PF0
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
[heater_bed]
heater_pin: PG5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PF2
control: watermark
min_temp: 0
max_temp: 130
[fan]
pin: PH5
#[heater_fan nozzle_cooling_fan]
#pin: PH3
[mcu]
serial: /dev/ttyACM0
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100
[output_pin stepper_xy_current]
pin: PL3
pwm: True
scale: 2.0
cycle_time: .000030
hardware_pwm: True
static_value: 1.3
[output_pin stepper_z_current]
pin: PL4
pwm: True
scale: 2.0
cycle_time: .000030
hardware_pwm: True
static_value: 1.3
[output_pin stepper_e_current]
pin: PL5
pwm: True
scale: 2.0
cycle_time: .000030
hardware_pwm: True
static_value: 1.25
[static_digital_output stepper_config]
pins:
PG1, PG0,
PK7, PG2,
PK6, PK5,
PK3, PK4
[static_digital_output yellow_led]
pins: !PB7

76
config/generic-printrboard.cfg
View File

@@ -1,76 +0,0 @@
# This file contains common pin mappings for Printrboard boards (rev B
# through D). To use this config the firmware should be compiled for
# the AVR at90usb1286.
# Note that the "make flash" command is unlikely to work on the
# Printrboard. See the RepRap Printrboard wiki page for instructions
# on flashing.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: PA0
dir_pin: !PA1
enable_pin: !PE7
step_distance: .0125
endstop_pin: ^PE3
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_y]
step_pin: PA2
dir_pin: PA3
enable_pin: !PE6
step_distance: .0125
endstop_pin: ^PB0
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_z]
step_pin: PA4
dir_pin: !PA5
enable_pin: !PC7
step_distance: .0025
endstop_pin: ^PE4
position_endstop: 0.5
position_max: 200
[extruder]
step_pin: PA6
dir_pin: PA7
enable_pin: !PC3
step_distance: .002
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PC5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PF1
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
[heater_bed]
heater_pin: PC4
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PF0
control: watermark
min_temp: 0
max_temp: 130
[fan]
pin: PC6
[mcu]
serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100

109
config/generic-radds.cfg
View File

@@ -1,109 +0,0 @@
# This file contains common pin mappings for RADDS (v1.5) boards. To
# use this config, the firmware should be compiled for the Arduino
# Due.
# See the example.cfg file for a description of available parameters.
# Temp sensor pins: analog0..analog4
# Mosfet Pins: ar7 (Heatbed), ar8, ar9, ar11, ar12, ar13
[stepper_x]
step_pin: ar24
dir_pin: ar23
enable_pin: ar26
step_distance: .0125
endstop_pin: ^ar28
#endstop_pin: ^ar34
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_y]
step_pin: ar17
dir_pin: !ar16
enable_pin: ar22
step_distance: .0125
endstop_pin: ^ar30
#endstop_pin: ^ar36
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_z]
step_pin: ar2
dir_pin: ar3
enable_pin: ar15
step_distance: .0025
endstop_pin: ^ar32
#endstop_pin: ^ar38
position_endstop: 0.5
position_max: 200
[extruder]
step_pin: analog7
dir_pin: analog6
enable_pin: analog8
step_distance: .002
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: ar13
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog0
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
#[extruder1]
#step_pin: analog10
#dir_pin: analog9
#enable_pin: analog11
#[extruder2]
#step_pin: ar51
#dir_pin: ar53
#enable_pin: ar49
[heater_bed]
heater_pin: ar7
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog1
control: watermark
min_temp: 0
max_temp: 130
[fan]
pin: ar9
#[heater_fan nozzle_cooling_fan]
#pin: ar8
[mcu]
serial: /dev/ttyACM0
pin_map: arduino
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100
# "RepRapDiscount 2004 Smart Controller" type displays
#[display]
#lcd_type: hd44780
#rs_pin: ar42
#e_pin: ar43
#d4_pin: ar44
#d5_pin: ar45
#d6_pin: ar46
#d7_pin: ar47
# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
#[display]
#lcd_type: st7920
#cs_pin: ar42
#sclk_pin: ar44
#sid_pin: ar43

126
config/generic-rambo.cfg
View File

@@ -1,126 +0,0 @@
# This file contains common pin mappings for RAMBo boards. To use this
# config, the firmware should be compiled for the AVR atmega2560.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: PC0
dir_pin: PL1
enable_pin: !PA7
step_distance: .0125
endstop_pin: ^PB6
#endstop_pin: ^PA2
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_y]
step_pin: PC1
dir_pin: !PL0
enable_pin: !PA6
step_distance: .0125
endstop_pin: ^PB5
#endstop_pin: ^PA1
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_z]
step_pin: PC2
dir_pin: PL2
enable_pin: !PA5
step_distance: .0025
endstop_pin: ^PB4
#endstop_pin: ^PC7
position_endstop: 0.5
position_max: 200
[extruder]
step_pin: PC3
dir_pin: PL6
enable_pin: !PA4
step_distance: .002
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PH6
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PF0
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
#[extruder1]
#step_pin: PC4
#dir_pin: PL7
#enable_pin: !PA3
#heater_pin: PH4
#sensor_pin: PF1
#...
[heater_bed]
heater_pin: PE5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PF2
control: watermark
min_temp: 0
max_temp: 130
[fan]
pin: PH5
#[heater_fan nozzle_cooling_fan]
#pin: PH3
[mcu]
serial: /dev/ttyACM0
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100
[ad5206 stepper_digipot]
enable_pin: PD7
# Scale the config so that the channel value can be specified in amps.
# (For Rambo v1.0d boards, use 1.56 instead.)
scale: 2.08
# Channel 1 is E0, 2 is E1, 3 is unused, 4 is Z, 5 is X, 6 is Y
channel_1: 1.34
channel_2: 1.0
channel_4: 1.1
channel_5: 1.1
channel_6: 1.1
# Enable 16 micro-steps on steppers X, Y, Z, E0, E1
[static_digital_output stepper_config]
pins:
PG1, PG0,
PK7, PG2,
PK6, PK5,
PK3, PK4,
PK1, PK2
[static_digital_output yellow_led]
pins: !PB7
# "RepRapDiscount 2004 Smart Controller" type displays
#[display]
#lcd_type: hd44780
#rs_pin: PG4
#e_pin: PG3
#d4_pin: PJ2
#d5_pin: PJ3
#d6_pin: PJ7
#d7_pin: PJ4
# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
#[display]
#lcd_type: st7920
#cs_pin: PG4
#sclk_pin: PJ2
#sid_pin: PG3

105
config/generic-ramps.cfg
View File

@@ -1,105 +0,0 @@
# This file contains common pin mappings for RAMPS (v1.3 and later)
# boards. RAMPS boards typically use a firmware compiled for the AVR
# atmega2560 (though other AVR chips are also possible).
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: ar54
dir_pin: ar55
enable_pin: !ar38
step_distance: .0125
endstop_pin: ^ar3
#endstop_pin: ^ar2
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_y]
step_pin: ar60
dir_pin: !ar61
enable_pin: !ar56
step_distance: .0125
endstop_pin: ^ar14
#endstop_pin: ^ar15
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_z]
step_pin: ar46
dir_pin: ar48
enable_pin: !ar62
step_distance: .0025
endstop_pin: ^ar18
#endstop_pin: ^ar19
position_endstop: 0.5
position_max: 200
[extruder]
step_pin: ar26
dir_pin: ar28
enable_pin: !ar24
step_distance: .002
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: ar10
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog13
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
#[extruder1]
#step_pin: ar36
#dir_pin: ar34
#enable_pin: !ar30
#heater_pin: ar9
#sensor_pin: analog15
#...
[heater_bed]
heater_pin: ar8
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog14
control: watermark
min_temp: 0
max_temp: 130
[fan]
pin: ar9
[mcu]
serial: /dev/ttyACM0
pin_map: arduino
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100
# "RepRapDiscount 2004 Smart Controller" type displays
#[display]
#lcd_type: hd44780
#rs_pin: ar16
#e_pin: ar17
#d4_pin: ar23
#d5_pin: ar25
#d6_pin: ar27
#d7_pin: ar29
#encoder_pins: ^ar31, ^ar33
#click_pin: ^!ar35
# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
#[display]
#lcd_type: st7920
#cs_pin: ar16
#sclk_pin: ar23
#sid_pin: ar17
#encoder_pins: ^ar31, ^ar33
#click_pin: ^!ar35

106
config/generic-re-arm.cfg
View File

@@ -1,106 +0,0 @@
# This file contains common pin mappings for Re-Arm. To use this
# config, the firmware should be compiled for the LPC176x.
# The "make flash" command does not work on the Re-Arm. Instead,
# after running "make", copy the generated "out/klipper.bin" file to a
# file named "firmware.bin" on an SD card and then restart the Re-Arm
# with that SD card.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: P2.1
dir_pin: P0.11
enable_pin: !P0.10
step_distance: .0125
endstop_pin: ^P1.24
#endstop_pin: ^P1.25
position_endstop: 0.5
position_min: 0
position_max: 200
homing_speed: 50
# The stepper_y section is used to describe the Y axis as well as the
# stepper controlling the X-Y movement.
[stepper_y]
step_pin: P2.2
dir_pin: P0.20
enable_pin: !P0.19
step_distance: .0125
endstop_pin: ^P1.26
#endstop_pin: ^P1.27
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_z]
step_pin: P2.3
dir_pin: P0.22
enable_pin: !P0.21
step_distance: .0025
endstop_pin: ^P1.29
#endstop_pin: ^P1.28
position_endstop: 0.5
position_min: 0
position_max: 200
[extruder]
step_pin: P2.0
dir_pin: P0.5
enable_pin: !P0.4
step_distance: .0011365
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: P2.5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: P0.23
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
#[extruder1]
#step_pin: P2.8
#dir_pin: P2.13
#enable_pin: !P4.29
#heater_pin: P2.4
#sensor_pin: P0.25
#...
[heater_bed]
heater_pin: P2.7
sensor_type: EPCOS 100K B57560G104F
sensor_pin: P0.24
control: watermark
min_temp: 0
max_temp: 130
[fan]
pin: P2.4
[mcu]
serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100
# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
# Re-Arm will only work with this type of display
#[display]
#lcd_type: st7920
#cs_pin: P0.16
#sclk_pin: P0.15
#sid_pin: P0.18
#encoder_pins: ^P3.25, ^P3.26
#click_pin: ^!P2.11
#kill_pin: ^!P1.22
# Ground the buzzer pin to prevent stray voltages causing an audible "whine"
#[static_digital_output buzzer]
#pins: !P1.30

134
config/generic-replicape.cfg
View File

@@ -1,134 +0,0 @@
# This file contains an example configuration for the Replicape rev B3
# board. To use this config, one must compile and install the
# micro-controller code for the "Beaglebone PRU", and then compile and
# install the micro-controller code a second time for a "Linux
# process".
# NOTE: Klipper does not alter the input/output state of the
# Beaglebone pins and it does not control their pull-up resistors.
# Typically the correct settings are automatically applied when the
# Beaglebone detects the Replicape board, but if changes are needed
# they must be specified in a "device tree overlay" or via the
# config-pin program.
# See the example.cfg file for a description of available parameters.
[mcu]
serial: /dev/rpmsg_pru30
pin_map: beaglebone
[mcu host]
serial: /tmp/klipper_host_mcu
# The "replicape" config section adds "replicape:stepper_x_enable"
# virtual stepper enable pins (for steppers x, y, z, e, and h) and
# "replicape:power_x" PWM output pins (for hotbed, e, h, fan0, fan1,
# fan2, and fan3) that may then be used elsewhere in the config file.
[replicape]
revision: B3
# The replicape hardware revision. Currently only revision "B3" is
# supported. This parameter must be provided.
#enable_pin: !P9_41
# The replicape global enable pin. The default is !P9_41.
host_mcu: host
# The name of the mcu config section that communicates with the
# Klipper "linux process" mcu instance. This parameter must be
# provided.
#standstill_power_down: False
# This parameter controls the CFG6_ENN line on all stepper
# motors. True sets the enable lines to "open". The default is
# False.
#servo0_enable: False
# This parameter controls whether end_stop_X_2 is used for endstops
# (via P9_11) or for servo_0 (via P9_14). The default is False.
#servo1_enable: False
# This parameter controls whether end_stop_Y_2 is used for endstops
# (via P9_28) or for servo_1 (via P9_16). The default is False.
stepper_x_microstep_mode: spread16
# This parameter controls the CFG1 and CFG2 pins of the given
# stepper motor driver. Available options are: disable, 1, 2,
# spread2, 4, 16, spread4, spread16, stealth4, and stealth16. The
# default is disable.
stepper_x_current: 0.5
# The configured maximum current (in Amps) of the stepper motor
# driver. This parameter must be provided if the stepper is not in a
# disable mode.
#stepper_x_chopper_off_time_high: False
# This parameter controls the CFG0 pin of the stepper motor driver
# (True sets CFG0 high, False sets it low). The default is False.
#stepper_x_chopper_hysteresis_high: False
# This parameter controls the CFG4 pin of the stepper motor driver
# (True sets CFG4 high, False sets it low). The default is False.
#stepper_x_chopper_blank_time_high: True
# This parameter controls the CFG5 pin of the stepper motor driver
# (True sets CFG5 high, False sets it low). The default is True.
stepper_y_microstep_mode: spread16
stepper_y_current: 0.5
stepper_z_microstep_mode: spread16
stepper_z_current: 0.5
stepper_e_microstep_mode: 16
stepper_e_current: 0.5
[stepper_x]
step_pin: P8_17
dir_pin: P8_26
enable_pin: replicape:stepper_x_enable
step_distance: .0125
endstop_pin: ^P9_25
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_y]
step_pin: P8_12
dir_pin: P8_19
enable_pin: replicape:stepper_y_enable
step_distance: .0125
endstop_pin: ^P9_23
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_z]
step_pin: P8_13
dir_pin: P8_14
enable_pin: replicape:stepper_z_enable
step_distance: .0025
endstop_pin: ^P9_13
position_endstop: 0
position_max: 200
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 25
max_z_accel: 30
[extruder]
step_pin: P9_12
dir_pin: P8_15
enable_pin: replicape:stepper_e_enable
step_distance: .002
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: replicape:power_e
sensor_type: EPCOS 100K B57560G104F
sensor_pin: host:analog4
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
[heater_bed]
heater_pin: replicape:power_hotbed
sensor_type: EPCOS 100K B57560G104F
sensor_pin: host:analog6
control: watermark
min_temp: 0
max_temp: 130
[fan]
pin: replicape:power_fan0

115
config/generic-rumba.cfg
View File

@@ -1,115 +0,0 @@
# This file contains common pin mappings for RUMBA boards. To use
# this config, the firmware should be compiled for the AVR atmega2560.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: ar17
dir_pin: ar16
enable_pin: !ar48
step_distance: .0125
endstop_pin: ^ar37
#endstop_pin: ^ar36
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_y]
step_pin: ar54
dir_pin: !ar47
enable_pin: !ar55
step_distance: .0125
endstop_pin: ^ar35
#endstop_pin: ^ar34
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_z]
step_pin: ar57
dir_pin: ar56
enable_pin: !ar62
step_distance: .0125
endstop_pin: ^ar33
#endstop_pin: ^ar32
position_endstop: 0.5
position_max: 200
[extruder]
step_pin: ar23
dir_pin: ar22
enable_pin: !ar24
step_distance: .002
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: ar2
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog15
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
#[extruder1]
#step_pin: ar26
#dir_pin: ar3
#enable_pin: !ar27
#heater_pin: ar9
#sensor_pin: analog14
#...
#[extruder2]
#step_pin: ar29
#dir_pin: ar6
#enable_pin: !ar39
#heater_pin: ar9
#sensor_pin: analog13
#...
[heater_bed]
heater_pin: ar9
sensor_type: NTC 100K beta 3950
sensor_pin: analog11
control: watermark
min_temp: 0
max_temp: 130
[fan]
pin: ar7
#[heater_fan fan1]
#pin: ar8
[mcu]
serial: /dev/ttyACM0
pin_map: arduino
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100
# "RepRapDiscount 2004 Smart Controller" type displays
#[display]
#lcd_type: hd44780
#rs_pin: ar19
#e_pin: ar42
#d4_pin: ar18
#d5_pin: ar38
#d6_pin: ar41
#d7_pin: ar40
#encoder_pins: ^ar11, ^ar12
#click_pin: ^!ar43
# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
#[display]
#lcd_type: st7920
#cs_pin: ar19
#sclk_pin: ar18
#sid_pin: ar42
#encoder_pins: ^ar11, ^ar12
#click_pin: ^!ar43

115
config/generic-smoothieboard.cfg
View File

@@ -1,115 +0,0 @@
# This file contains common pin mappings for Smoothieboard. To use
# this config, the firmware should be compiled for the LPC176x.
# The "make flash" command does not work on the Smoothieboard.
# Instead, after running "make", copy the generated "out/klipper.bin"
# file to a file named "firmware.bin" on an SD card and then restart
# the Smoothieboard with that SD card.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: P2.0
dir_pin: P0.5
enable_pin: !P0.4
step_distance: .0125
endstop_pin: ^P1.24
#endstop_pin: ^P1.25
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_y]
step_pin: P2.1
dir_pin: !P0.11
enable_pin: !P0.10
step_distance: .0125
endstop_pin: ^P1.26
#endstop_pin: ^P1.27
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_z]
step_pin: P2.2
dir_pin: P0.20
enable_pin: !P0.19
step_distance: .0025
endstop_pin: ^P1.28
#endstop_pin: ^P1.29
position_endstop: 0.5
position_max: 200
[extruder]
step_pin: P2.3
dir_pin: P0.22
enable_pin: !P0.21
step_distance: .002
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: P2.7
sensor_type: EPCOS 100K B57560G104F
sensor_pin: P0.24
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
#[extruder1]
#step_pin: P2.8
#dir_pin: P2.13
#enable_pin: !P4.29
#heater_pin: P2.6
#sensor_pin: P0.25
#...
[heater_bed]
heater_pin: P2.5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: P0.23
control: watermark
min_temp: 0
max_temp: 130
[fan]
pin: P2.4
[mcu]
serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100
[static_digital_output leds]
pins: P1.18, P1.19, P1.20, P1.21, P4.28
[mcp4451 stepper_digipot1]
i2c_address: 88
# Scale the config so that wiper values can be specified in amps.
scale: 2.25
# wiper 0 is X (aka alpha), 1 is Y, 2 is Z, 3 is E0
wiper_0: 1.0
wiper_1: 1.0
wiper_2: 1.0
wiper_3: 1.0
[mcp4451 stepper_digipot2]
i2c_address: 90
scale: 2.25
# wiper 0 is E1
wiper_0: 1.0
# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
#[display]
#lcd_type: st7920
#cs_pin: P0.16
#sclk_pin: P0.15
#sid_pin: P0.18
#encoder_pins: ^P3.25, ^P3.26
#click_pin: ^!P1.30

222
config/kit-voron2-2018.cfg
View File

@@ -1,222 +0,0 @@
# This file is an example configuration for the Voron 2 CoreXY printer
# running on two RAMPS boards. This file was created by "Maglin".
# X/Y/E steppers/endstops/thermisters/heaters are on one MCU/RAMPS
# board while Z steppers/mechanical switch/endstop_pin are on the
# second MCU/RAMPS labeled z.
# This file is only an example - be sure to review and update it
# according to the specifics of your printer. See the example.cfg and
# example-extras.cfg files for a description of available parameters.
[mcu]
# mcu for X/Y/E steppers main MCU
serial: /dev/serial/by-path/platform-3f980000.usb-usb-0:1.3:1.0-port0
pin_map: arduino
[mcu z]
# mcu for the Z steppers
serial: /dev/serial/by-path/platform-3f980000.usb-usb-0:1.2:1.0-port0
pin_map: arduino
[stepper_x]
# use preceding ! to invert logic and ^ to activate internal 5V pullup
# this is for all pin definitions. Not all pins have interal pullups
step_pin: ar54
dir_pin: ar55
enable_pin: !ar38
step_distance: 0.0125
endstop_pin: ^ar2
position_min: 0
position_endstop: 248
position_max: 248
homing_speed: 50
[stepper_y]
step_pin: ar60
dir_pin: ar61
enable_pin: !ar56
step_distance: 0.0125
endstop_pin: ^ar15
position_min: -5
position_endstop: 245
position_max: 245
homing_speed: 50
[stepper_z]
# X stepper pins on MCU Z
step_pin: z:ar54
dir_pin: z:ar55
enable_pin: !z:ar38
step_distance: 0.00625
# probe:z_virtual_endstop is a virtual pin definition only available if
# a probe section is defined
#endstop_pin: probe:z_virtual_endstop
# mechanical switch on mcu Z X min endstop pin
endstop_pin: ^z:ar3
position_endstop: -0.376
position_min: -5
position_max: 245
homing_speed: 12
[stepper_z1]
# Y stepper pins on MCU Z
step_pin: z:ar60
dir_pin: !z:ar61
enable_pin: !z:ar56
step_distance: 0.00625
[stepper_z2]
# Z stepper pins on MCU Z
step_pin: z:ar46
dir_pin: z:ar48
enable_pin: !z:ar62
step_distance: 0.00625
[stepper_z3]
# E0 stepper pins on MCU Z
step_pin: z:ar26
dir_pin: !z:ar28
enable_pin: !z:ar24
step_distance: 0.00625
# extended G-Code command Z_TILT_ADJUST can be used to level gantry
[z_tilt]
# belt locations from origin 0,0
z_positions:
-56,-17
-56,322
311,322
311,-17
# probing locations for gantry leveling
points:
50,50
50,195
195,195
195,50
# travel speed between probe points
speed: 150
# Move Z to this position for safe probing
horizontal_move_z: 15
# this is required for gantry leveling and replaces your G28 command
# with the gcode used here. Used to home X/Y/Z with mechanical switches
[homing_override]
set_position_z: 0
gcode:
G90
G0 Z15 F600
G28 X0 Y0
G0 X248 Y225 F3000
G28 Z
G0 Z15 F6000
# macro to level the gantry. use G32 in the terminal to call
[gcode_macro g32]
gcode:
Z_TILT_ADJUST
Z_TILT_ADJUST
Z_TILT_ADJUST
G28
G0 X125 Y125 Z125 F3600
# Use print_start for you slicer starting script
[gcode_macro print_start]
gcode:
G1 X0 Y15 Z0.3 F7000
G92 E0
G1 E14 F600
G92 E0
G1 X60.0 E9.0 F1000.0
G1 X100.0 E12.5 F1000.0
G1 E12 F1000.0
G92 E-0.5
# Use print_end for you slicer ending script
[gcode_macro print_end]
gcode:
M104 S0
M140 S0
M107
G92 E0
G91
G1 Z10 E-10 F3000
G90
G0 X125 Y245 F1000
[extruder]
# on E0 stepper pins of main MCU
step_pin: ar26
dir_pin: ar28
enable_pin: !ar24
step_distance: 0.003339
nozzle_diameter: 0.400
filament_diameter: 1.750
max_extrude_only_distance: 100.0
heater_pin: ar10
max_power: 1.0
sensor_type: ATC Semitec 104GT-2
sensor_pin: analog13
control: pid
pid_Kp: 21.759
pid_Ki: 1.107
pid_Kd: 106.889
min_temp: 0
max_temp: 300
# thermally controlled hotend fan
[heater_fan my_nozzle_fan]
# Located on Z MCU on fan D9
pin: z:ar9
[probe]
# Z_Min pins on MCU Z (must be on same MCU as steppers)
pin: ^!z:ar18
z_offset: 1.15
speed: 2.0
[heater_bed]
heater_pin: ar8
# NTC 100K MGB18-104F39050L32 is for Kenovo thermistors
sensor_type: NTC 100K MGB18-104F39050L32
sensor_pin: analog14
# pid gives you better control over bed heat
control: pid
pid_Kp: 63.832
pid_Ki: 3.404
pid_Kd: 299.213
min_temp: 0
max_temp: 130
# print cooling fan
[fan]
# On z MCU on extruder heater pin D10
pin: z:ar10
# "RepRapDiscount 2004 Smart Controller" type displays
#[display]
#lcd_type: hd44780
#rs_pin: ar16
#e_pin: ar17
#d4_pin: ar23
#d5_pin: ar25
#d6_pin: ar27
#d7_pin: ar29
# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
[display]
lcd_type: st7920
cs_pin: ar16
sclk_pin: ar23
sid_pin: ar17
[printer]
# settings below are the max and can't be commanded over in gcode
kinematics: corexy
max_velocity: 500
max_accel: 3000
max_z_velocity: 100
max_z_accel: 50
[idle_timeout]
# high motor off time so I don't have to relevel gantry often
timeout: 6000

120
config/printer-adimlab-2018.cfg
View File

@@ -1,120 +0,0 @@
# This file contains pin mappings for the ADIMLab 3d printer 2018.
# To use this config, the firmware should be compiled for the AVR atmega2560.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: ar25
dir_pin: !ar23
enable_pin: !ar27
step_distance: .0125
endstop_pin: ^!ar22
position_min: -5
position_endstop: -5
position_max: 310
homing_speed: 30.0
[stepper_y]
step_pin: ar32
dir_pin: !ar33
enable_pin: !ar31
step_distance: .0125
endstop_pin: ^!ar26
position_endstop: 0
position_max: 310
homing_speed: 30.0
[stepper_z]
step_pin: ar35
dir_pin: ar36
enable_pin: !ar34
step_distance: .0025
endstop_pin: ^!ar29
position_endstop: 0.0
position_max: 400
homing_speed: 5.0
[extruder]
step_pin: ar42
dir_pin: ar43
enable_pin: !ar37
step_distance: .010799
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: ar2
sensor_type: ATC Semitec 104GT-2
sensor_pin: analog8
control: pid
pid_Kp: 15.717
pid_Ki: 0.569
pid_Kd: 108.451
min_temp: 0
max_temp: 245
[heater_bed]
heater_pin: ar4
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog10
control: pid
pid_Kp: 74.883
pid_Ki: 1.809
pid_Kd: 775.038
min_temp: 0
max_temp: 110
[verify_heater heater_bed]
# adjust for personal bed setup, this prevents stock heated bed from issuing
# false positive heating errors due to slow temperature increase
# 1 deg per 2 minutes.
heating_gain: 1
check_gain_time: 120
[mcu]
serial: /dev/ttyUSB0
pin_map: arduino
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 10
max_z_accel: 60
[output_pin stepper_xy_current]
pin: ar44
pwm: True
scale: 2.0
cycle_time: .000030
hardware_pwm: True
static_value: 1.3
[output_pin stepper_z_current]
pin: ar45
pwm: True
scale: 2.0
cycle_time: .000030
hardware_pwm: True
static_value: 1.3
[output_pin stepper_e_current]
pin: ar46
pwm: True
scale: 2.0
cycle_time: .000030
hardware_pwm: True
static_value: 1.25
[display]
lcd_type: st7920
cs_pin: ar20
sclk_pin: ar14
sid_pin: ar15
encoder_pins: ^ar41, ^ar40
click_pin: ^!ar19
# The filament runout sensor (on pin ar24) is not currently supported
# in Klipper.
[output_pin case_light]
pin: ar7
value: 1

88
config/printer-anet-a8-2017.cfg
View File

@@ -1,88 +0,0 @@
# This file contains common pin mappings for Anet A8 printer from 2016
# and 2017. To use this config, the firmware should be compiled for
# the AVR atmega1284p.
# Note that the "make flash" command does not work with Anet boards -
# the boards are typically flashed with this command:
# avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: PD7
dir_pin: PC5
enable_pin: !PD6
step_distance: .01
endstop_pin: ^!PC2
position_endstop: -30
position_max: 220
position_min: -30
homing_speed: 50
[stepper_y]
step_pin: PC6
dir_pin: PC7
enable_pin: !PD6
step_distance: .01
endstop_pin: ^!PC3
position_endstop: -8
position_min: -8
position_max: 220
homing_speed: 50
[stepper_z]
step_pin: PB3
dir_pin: !PB2
enable_pin: !PA5
step_distance: .0025
endstop_pin: ^!PC4
position_endstop: 0.5
position_max: 240
homing_speed: 20
[extruder]
step_pin: PB1
dir_pin: PB0
enable_pin: !PD6
step_distance: .0105
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PD5
sensor_type: ATC Semitec 104GT-2
sensor_pin: PA7
control: pid
pid_Kp: 2.151492
pid_Ki: 0.633897
pid_Kd: 230.042965
min_temp: 0
max_temp: 250
[heater_bed]
heater_pin: PD4
sensor_type: ATC Semitec 104GT-2
sensor_pin: PA6
control: watermark
min_temp: 0
max_temp: 130
[fan]
pin: PB4
[mcu]
serial: /dev/ttyUSB0
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 1000
max_z_velocity: 20
max_z_accel: 100
[display]
lcd_type: hd44780
rs_pin: PA3
e_pin: PA2
d4_pin: PD2
d5_pin: PD3
d6_pin: PC0
d7_pin: PC1

88
config/printer-anet-e10-2018.cfg
View File

@@ -1,88 +0,0 @@
# This file contains common pin mappings for Anet E10 printer from
# 2018. To use this config, the firmware should be compiled for the
# AVR atmega1284p.
# Note that the "make flash" command does not work with Anet boards -
# the boards are typically flashed with this command:
# avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: PD7
dir_pin: PC5
enable_pin: !PD6
step_distance: .0125
endstop_pin: ^!PC2
position_endstop: -3
position_max: 220
position_min: -3
homing_speed: 50
[stepper_y]
step_pin: PC6
dir_pin: !PC7
enable_pin: !PD6
step_distance: .0125
endstop_pin: ^!PC3
position_endstop: -22
position_min: -22
position_max: 270
homing_speed: 50
[stepper_z]
step_pin: PB3
dir_pin: !PB2
enable_pin: !PA5
step_distance: .0025
endstop_pin: ^!PC4
position_endstop: 0.5
position_max: 300
homing_speed: 20
[extruder]
step_pin: PB1
dir_pin: !PB0
enable_pin: !PD6
step_distance: 0.01
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PD5
sensor_type: ATC Semitec 104GT-2
sensor_pin: PA7
control: pid
pid_Kp: 27.0
pid_Ki: 1.3
pid_Kd: 136.09
min_temp: 10
max_temp: 250
[heater_bed]
heater_pin: PD4
sensor_type: ATC Semitec 104GT-2
sensor_pin: PA6
control: pid
pid_Kp: 72.8
pid_Ki: 1.2
pid_Kd: 1100
min_temp: 10
max_temp: 130
[fan]
pin: PB4
[mcu]
serial: /dev/ttyUSB0
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 1000
max_z_velocity: 20
max_z_accel: 1000
[display]
lcd_type: st7920
cs_pin: PA4
sclk_pin: PA1
sid_pin:PA3

93
config/printer-anycubic-i3-mega-2017.cfg
View File

@@ -1,93 +0,0 @@
# This file contains pin mappings for the Anycubic i3 Mega with
# Ultrabase from 2017. (This config may work on an Anycubic i3 Mega v1
# prior to the Ultrabase if you comment out the definition of the
# endstop_pin in the stepper_z1 section.) To use this config, the
# firmware should be compiled for the AVR atmega2560.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: ar54
dir_pin: !ar55
enable_pin: !ar38
step_distance: .0125
endstop_pin: ^!ar3
position_min: -5
position_endstop: -5
position_max: 210
homing_speed: 30.0
[stepper_y]
step_pin: ar60
dir_pin: ar61
enable_pin: !ar56
step_distance: .0125
endstop_pin: ^!ar42
position_endstop: 0
position_max: 210
homing_speed: 30.0
[stepper_z]
step_pin: ar46
dir_pin: ar48
enable_pin: !ar62
step_distance: .0025
endstop_pin: ^!ar18
position_endstop: 0.0
position_max: 205
homing_speed: 5.0
[stepper_z1]
step_pin: ar36
dir_pin: ar34
enable_pin: !ar30
step_distance: .0025
endstop_pin: ^!ar43
[extruder]
step_pin: ar26
dir_pin: ar28
enable_pin: !ar24
step_distance: .010799
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: ar10
sensor_type: ATC Semitec 104GT-2
sensor_pin: analog13
control: pid
pid_Kp: 15.717
pid_Ki: 0.569
pid_Kd: 108.451
min_temp: 0
max_temp: 245
[heater_fan extruder_fan]
pin: ar44
[heater_bed]
heater_pin: ar8
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog14
control: pid
pid_Kp: 74.883
pid_Ki: 1.809
pid_Kd: 775.038
min_temp: 0
max_temp: 110
[fan]
pin: ar9
[mcu]
serial: /dev/ttyUSB0
pin_map: arduino
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 10
max_z_accel: 60
[heater_fan stepstick_fan]
pin: ar7

109
config/printer-anycubic-kossel-2016.cfg
View File

@@ -1,109 +0,0 @@
# This file contains a configuration for the Anycubic Kossel delta
# printer from 2016.
# The Anycubic delta printers use the TriGorilla board which is an
# AVR ATmega2560 Arduino + RAMPS compatible board.
# To use this config, the firmware should be compiled for the AVR atmega2560.
# See the example.cfg file for a description of available parameters.
[stepper_a]
step_pin: ar54
dir_pin: !ar55
enable_pin: !ar38
step_distance: .0125
endstop_pin: ^ar2
homing_speed: 60
# The next parameter needs to be adjusted for
# your printer. You may want to start with 280
# and meassure the distance from nozzle to bed.
# This value then needs to be added.
position_endstop: 273.0
arm_length: 229.4
[stepper_b]
step_pin: ar60
dir_pin: !ar61
enable_pin: !ar56
step_distance: .0125
endstop_pin: ^ar15
[stepper_c]
step_pin: ar46
dir_pin: !ar48
enable_pin: !ar62
step_distance: .0125
endstop_pin: ^ar19
[extruder]
step_pin: ar26
dir_pin: !ar28
enable_pin: !ar24
step_distance: 0.010989
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: ar10
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog13
control: pid
pid_Kp: 25.349
pid_Ki: 1.216
pid_Kd: 132.130
min_extrude_temp: 150
min_temp: 0
max_temp: 275
#[heater_bed]
#heater_pin: ar8
#sensor_type: EPCOS 100K B57560G104F
#sensor_pin: analog14
#control: watermark
#min_temp: 0
#max_temp: 130
[fan]
pin: ar9
kick_start_time: 0.200
[heater_fan extruder_cooler_fan]
pin: ar44
[mcu]
serial: /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
pin_map: arduino
[printer]
kinematics: delta
max_velocity: 500
max_accel: 3000
max_z_velocity: 200
delta_radius: 99.8
# if you want to DELTA_CALIBRATE you may need that
#minimum_z_position: -5
[idle_timeout]
timeout: 360
#[delta_calibrate]
#radius: 80
#manual_probe:
# If true, then DELTA_CALIBRATE will perform manual probing. If
# false, then a PROBE command will be run at each probe
# point. Manual probing is accomplished by manually jogging the Z
# position of the print head at each probe point and then issuing a
# NEXT extended g-code command to record the position at that
# point. The default is false if a [probe] config section is present
# and true otherwise.
# "RepRapDiscount 2004 Smart Controller" type displays
[display]
lcd_type: hd44780
rs_pin: ar16
e_pin: ar17
d4_pin: ar23
d5_pin: ar25
d6_pin: ar27
d7_pin: ar29
encoder_pins: ^ar31, ^ar33
click_pin: ^!ar35
kill_pin: ^!ar41

109
config/printer-anycubic-kossel-plus-2017.cfg
View File

@@ -1,109 +0,0 @@
# This file contains a configuration for the "Anycubic Kossel Linear
# Plus Large Printing Size", "Anycubic Kossel Pulley Plus Large
# Printing Size" and similar delta printer from 2017.
# The Anycubic delta printers use the TriGorilla board which is an
# AVR ATmega2560 Arduino + RAMPS compatible board.
# To use this config, the firmware should be compiled for the AVR atmega2560.
# See the example.cfg file for a description of available parameters.
[stepper_a]
step_pin: ar54
dir_pin: !ar55
enable_pin: !ar38
step_distance: .0125
endstop_pin: ^ar2
homing_speed: 60
# The next parameter needs to be adjusted for
# your printer. You may want to start with 280
# and meassure the distance from nozzle to bed.
# This value then needs to be added.
position_endstop: 295.6
arm_length: 271.50
[stepper_b]
step_pin: ar60
dir_pin: !ar61
enable_pin: !ar56
step_distance: .0125
endstop_pin: ^ar15
[stepper_c]
step_pin: ar46
dir_pin: !ar48
enable_pin: !ar62
step_distance: .0125
endstop_pin: ^ar19
[extruder]
step_pin: ar26
dir_pin: !ar28
enable_pin: !ar24
step_distance: 0.010989
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: ar10
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog13
control: pid
pid_Kp: 25.349
pid_Ki: 1.216
pid_Kd: 132.130
min_extrude_temp: 150
min_temp: 0
max_temp: 275
#[heater_bed]
#heater_pin: ar8
#sensor_type: EPCOS 100K B57560G104F
#sensor_pin: analog14
#control: watermark
#min_temp: 0
#max_temp: 130
[fan]
pin: ar9
kick_start_time: 0.200
[heater_fan extruder_cooler_fan]
pin: ar44
[mcu]
serial: /dev/ttyUSB0
pin_map: arduino
[printer]
kinematics: delta
max_velocity: 500
max_accel: 3000
max_z_velocity: 200
delta_radius: 115
# if you want to DELTA_CALIBRATE you may need that
#minimum_z_position: -5
[idle_timeout]
timeout: 360
#[delta_calibrate]
#radius: 115
#manual_probe:
# If true, then DELTA_CALIBRATE will perform manual probing. If
# false, then a PROBE command will be run at each probe
# point. Manual probing is accomplished by manually jogging the Z
# position of the print head at each probe point and then issuing a
# NEXT extended g-code command to record the position at that
# point. The default is false if a [probe] config section is present
# and true otherwise.
# "RepRapDiscount 2004 Smart Controller" type displays
[display]
lcd_type: hd44780
rs_pin: ar16
e_pin: ar17
d4_pin: ar23
d5_pin: ar25
d6_pin: ar27
d7_pin: ar29
encoder_pins: ^ar31, ^ar33
click_pin: ^!ar35
kill_pin: ^!ar41

90
config/printer-creality-cr10-2017.cfg
View File

@@ -1,90 +0,0 @@
# This file contains common pin mappings for the 2017 Creality
# CR-10. To use this config, the firmware should be compiled for the
# AVR atmega1284p.
# Note, a number of Melzi boards are shipped with a bootloader that
# requires the following command to flash the board:
# avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
# If the above command does not work and "make flash" does not work
# then one may need to flash a bootloader to the board - see the
# Klipper docs/Bootloaders.md file for more information.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: PD7
dir_pin: !PC5
enable_pin: !PD6
step_distance: .0125
endstop_pin: ^PC2
position_endstop: 0
position_max: 300
homing_speed: 50
[stepper_y]
step_pin: PC6
dir_pin: !PC7
enable_pin: !PD6
step_distance: .0125
endstop_pin: ^PC3
position_endstop: 0
position_max: 300
homing_speed: 50
[stepper_z]
step_pin: PB3
dir_pin: PB2
enable_pin: !PA5
step_distance: .0025
endstop_pin: ^PC4
position_endstop: 0.0
position_max: 400
[extruder]
step_pin: PB1
dir_pin: !PB0
enable_pin: !PD6
step_distance: 0.010526
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PD5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PA7
control: pid
pid_Kp: 22.57
pid_Ki: 1.72
pid_Kd: 73.96
min_temp: 0
max_temp: 250
[heater_bed]
heater_pin: PD4
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PA6
control: pid
pid_Kp: 426.68
pid_Ki: 78.92
pid_Kd: 576.71
min_temp: 0
max_temp: 130
[fan]
pin: PB4
[mcu]
serial: /dev/ttyUSB0
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100
[display]
lcd_type: st7920
cs_pin: PA3
sclk_pin: PA1
sid_pin: PC1
encoder_pins: ^PD2, ^PD3
click_pin: ^!PC0

90
config/printer-creality-cr10mini-2017.cfg
View File

@@ -1,90 +0,0 @@
# This file contains common pin mappings for the 2017 Creality CR-10
# mini. To use this config, the firmware should be compiled for the
# AVR atmega1284p.
# Note, a number of Melzi boards are shipped with a bootloader that
# requires the following command to flash the board:
# avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
# If the above command does not work and "make flash" does not work
# then one may need to flash a bootloader to the board - see the
# Klipper docs/Bootloaders.md file for more information.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: PD7
dir_pin: !PC5
enable_pin: !PD6
step_distance: .0125
endstop_pin: ^PC2
position_endstop: 0
position_max: 300
homing_speed: 50
[stepper_y]
step_pin: PC6
dir_pin: !PC7
enable_pin: !PD6
step_distance: .0125
endstop_pin: ^PC3
position_endstop: 0
position_max: 220
homing_speed: 50
[stepper_z]
step_pin: PB3
dir_pin: PB2
enable_pin: !PA5
step_distance: .0025
endstop_pin: ^PC4
position_endstop: 0.0
position_max: 300
[extruder]
step_pin: PB1
dir_pin: !PB0
enable_pin: !PD6
step_distance: 0.010526
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PD5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PA7
control: pid
pid_Kp: 22.57
pid_Ki: 1.72
pid_Kd: 73.96
min_temp: 0
max_temp: 250
[heater_bed]
heater_pin: PD4
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PA6
control: pid
pid_Kp: 426.68
pid_Ki: 78.92
pid_Kd: 576.71
min_temp: 0
max_temp: 130
[fan]
pin: PB4
[mcu]
serial: /dev/ttyUSB0
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100
[display]
lcd_type: st7920
cs_pin: PA3
sclk_pin: PA1
sid_pin: PC1
encoder_pins: ^PD2, ^PD3
click_pin: ^!PC0

83
config/printer-creality-cr10s-2017.cfg
View File

@@ -1,83 +0,0 @@
# This file contains pin mappings for the 2017 Creality CR-10S. To use
# this config, the firmware should be compiled for the AVR atmega2560.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: ar54
dir_pin: ar55
enable_pin: !ar38
step_distance: .0125
endstop_pin: ^ar3
position_endstop: 0
position_max: 300
homing_speed: 50
[stepper_y]
step_pin: ar60
dir_pin: ar61
enable_pin: !ar56
step_distance: .0125
endstop_pin: ^ar14
position_endstop: 0
position_max: 300
homing_speed: 50
[stepper_z]
step_pin: ar46
dir_pin: !ar48
enable_pin: !ar62
step_distance: .0025
endstop_pin: ^ar18
position_endstop: 0.5
position_max: 400
[extruder]
step_pin: ar26
dir_pin: ar28
enable_pin: !ar24
step_distance: .010526
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: ar10
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog13
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
[heater_bed]
heater_pin: ar8
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog14
control: pid
pid_Kp: 690.34
pid_Ki: 111.47
pid_Kd: 1068.83
min_temp: 0
max_temp: 130
[fan]
pin: ar9
[mcu]
serial: /dev/ttyUSB0
pin_map: arduino
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100
[display]
lcd_type: st7920
cs_pin: ar16
sclk_pin: ar23
sid_pin: ar17
encoder_pins: ^ar33, ^ar31
click_pin: ^!ar35

81
config/printer-creality-cr20-2018.cfg
View File

@@ -1,81 +0,0 @@
# This file contains pin mappings for the Creality CR-20. To use
# this config, the firmware should be compiled for the AVR atmega2560.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: PF0
dir_pin: PF1
enable_pin: !PD7
step_distance: .0125
endstop_pin: ^PE5
position_endstop: 0
position_max: 235
homing_speed: 50
[stepper_y]
step_pin: PF6
dir_pin: PF7
enable_pin: !PF2
step_distance: .0125
endstop_pin: ^PJ1
position_endstop: 0
position_max: 235
homing_speed: 50
[stepper_z]
step_pin: PL3
dir_pin: !PL1
enable_pin: !PK0
step_distance: .0025
endstop_pin: ^PD3
position_endstop: 0.5
position_max: 250
[extruder]
step_pin: PA4
dir_pin: PA6
enable_pin: !PA2
step_distance: .010526
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PB4
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PK5
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
[heater_bed]
heater_pin: PH5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PK6
control: pid
pid_Kp: 690.34
pid_Ki: 111.47
pid_Kd: 1068.83
min_temp: 0
max_temp: 130
[fan]
pin: PH6
[mcu]
serial: /dev/ttyUSB0
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100
[display]
lcd_type: uc1701
cs_pin: PA3
a0_pin: PA5
encoder_pins: ^PC4, ^PC6
click_pin: ^!PC2

93
config/printer-creality-ender2-2017.cfg
View File

@@ -1,93 +0,0 @@
# This file contains common pin mappings for the 2017 Creality
# Ender 2. To use this config, the firmware should be compiled for the
# AVR atmega1284p.
# Note, a number of Melzi boards are shipped with a bootloader that
# requires the following command to flash the board:
# avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
# If the above command does not work and "make flash" does not work
# then one may need to flash a bootloader to the board - see the
# Klipper docs/Bootloaders.md file for more information.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: PD7
dir_pin: !PC5
enable_pin: !PD6
step_distance: .0125
endstop_pin: ^PC2
position_endstop: 0
position_max: 165
homing_speed: 50
[stepper_y]
step_pin: PC6
dir_pin: !PC7
enable_pin: !PD6
step_distance: .0125
endstop_pin: ^PC3
position_endstop: 0
position_max: 165
homing_speed: 50
[stepper_z]
step_pin: PB3
dir_pin: PB2
enable_pin: !PA5
step_distance: .0025
endstop_pin: ^PC4
position_endstop: 0.0
position_max: 205
[extruder]
step_pin: PB1
dir_pin: !PB0
enable_pin: !PD6
step_distance: 0.010753
nozzle_diameter: 0.400
filament_diameter: 1.750
max_extrude_only_distance: 500.0
max_extrude_only_velocity: 200.0
max_extrude_only_accel: 500.0
heater_pin: PD5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PA7
control: pid
pid_Kp: 21.73
pid_Ki: 1.54
pid_Kd: 76.55
min_temp: 0
max_temp: 250
[heater_bed]
heater_pin: PD4
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PA6
control: pid
# PID Tuned for 60C
pid_Kp: 72.487
pid_Ki: 2.279
pid_Kd: 576.275
min_temp: 0
max_temp: 100
[fan]
pin: PB4
[mcu]
serial: /dev/ttyUSB0
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 1500
max_z_velocity: 5
max_z_accel: 100
[display]
lcd_type: uc1701
cs_pin: PA3
a0_pin: PA1
encoder_pins: ^PD2, ^PD3
click_pin: ^!PC0

93
config/printer-creality-ender3-2018.cfg
View File

@@ -1,93 +0,0 @@
# This file contains common pin mappings for the 2018 Creality
# Ender 3. To use this config, the firmware should be compiled for the
# AVR atmega1284p.
# Note, a number of Melzi boards are shipped with a bootloader that
# requires the following command to flash the board:
# avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
# If the above command does not work and "make flash" does not work
# then one may need to flash a bootloader to the board - see the
# Klipper docs/Bootloaders.md file for more information.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: PD7
dir_pin: !PC5
enable_pin: !PD6
step_distance: .0125
endstop_pin: ^PC2
position_endstop: 0
position_max: 235
homing_speed: 50
[stepper_y]
step_pin: PC6
dir_pin: !PC7
enable_pin: !PD6
step_distance: .0125
endstop_pin: ^PC3
position_endstop: 0
position_max: 235
homing_speed: 50
[stepper_z]
step_pin: PB3
dir_pin: PB2
enable_pin: !PA5
step_distance: .0025
endstop_pin: ^PC4
position_endstop: 0.0
position_max: 250
[extruder]
max_extrude_only_distance: 100.0
step_pin: PB1
dir_pin: !PB0
enable_pin: !PD6
step_distance: 0.010526
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PD5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PA7
control: pid
# tuned for stock hardware with 200 degree Celsius target
pid_Kp: 21.527
pid_Ki: 1.063
pid_Kd: 108.982
min_temp: 0
max_temp: 250
[heater_bed]
heater_pin: PD4
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PA6
control: pid
# tuned for stock hardware with 50 degree Celsius target
pid_Kp: 54.027
pid_Ki: 0.770
pid_Kd: 948.182
min_temp: 0
max_temp: 130
[fan]
pin: PB4
[mcu]
serial: /dev/ttyUSB0
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100
[display]
lcd_type: st7920
cs_pin: PA3
sclk_pin: PA1
sid_pin: PC1
encoder_pins: ^PD2, ^PD3
click_pin: ^!PC0

116
config/printer-lulzbot-taz6-2017.cfg
View File

@@ -1,116 +0,0 @@
# This file contains pin mappings for the Lulzbot TAZ 6 circa 2017. To
# use this config, the firmware should be compiled for the AVR
# atmega2560.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: PC0
dir_pin: PL1
enable_pin: !PA7
step_distance: .010000
endstop_pin: ^PB6
position_endstop: -20
position_min: -20
position_max: 300
homing_speed: 50
[stepper_y]
step_pin: PC1
dir_pin: !PL0
enable_pin: !PA6
step_distance: .010000
endstop_pin: ^PA1
position_endstop: 306
position_min: -20
position_max: 306
homing_speed: 50
[stepper_z]
step_pin: PC2
dir_pin: PL2
enable_pin: !PA5
step_distance: 0.000625
endstop_pin: ^!PB4
position_endstop: -0.7
position_min: -1.5
position_max: 270
homing_speed: 1
[extruder]
step_pin: PC3
dir_pin: !PL6
enable_pin: !PA4
step_distance: 0.001182
nozzle_diameter: 0.400
filament_diameter: 2.920
heater_pin: PH6
sensor_type: ATC Semitec 104GT-2
sensor_pin: PF0
control: pid
pid_Kp: 28.79
pid_Ki: 1.91
pid_Kd: 108.51
min_temp: 0
max_temp: 300
min_extrude_temp: 140
#[extruder1]
#step_pin: PC4
#dir_pin: PL7
#enable_pin: !PA3
#heater_pin: PH4
#sensor_pin: PF1
#...
[heater_bed]
heater_pin: PE5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PF2
control: watermark
min_temp: 0
max_temp: 130
[fan]
pin: PH5
[heater_fan nozzle_cooling_fan]
pin: PH3
[mcu]
serial: /dev/ttyACM0
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 2
max_z_accel: 10
[ad5206 stepper_digipot]
enable_pin: PD7
scale: 2.08
# Channel 1 is E0, 2 is E1, 3 is unused, 4 is Z, 5 is X, 6 is Y
channel_1: 1.34
channel_2: 1.0
channel_4: 1.1
channel_5: 1.1
channel_6: 1.1
# Enable 16 micro-steps on steppers X, Y, Z, E0, E1
[static_digital_output stepper_config]
pins:
PG1, PG0,
PK7, PG2,
PK6, PK5,
PK3, PK4,
PK1, PK2
[static_digital_output yellow_led]
pins: !PB7
[display]
lcd_type: st7920
cs_pin: PG4
sclk_pin: PJ2
sid_pin: PG3

114
config/printer-makergear-m2-2012.cfg
View File

@@ -1,114 +0,0 @@
# Support for Makergear M2 printers circa 2012 that have the RAMBo
# v1.0d electronics along with the V3A extruder. The electronics use
# Allegro A4984 stepper drivers with 1/8th micro-stepping. To use
# this config, the firmware should be compiled for the AVR atmega2560.
[stepper_x]
step_pin: PC0
dir_pin: !PL1
enable_pin: !PA7
step_distance: .0225
endstop_pin: ^!PB6
position_endstop: 0.0
position_max: 200
homing_speed: 50
[endstop_phase stepper_x]
phases: 32
endstop_accuracy: .200
[stepper_y]
step_pin: PC1
dir_pin: PL0
enable_pin: !PA6
step_distance: .0225
endstop_pin: ^!PB5
position_endstop: 0.0
position_max: 250
homing_speed: 50
[endstop_phase stepper_y]
phases: 32
endstop_accuracy: .200
[stepper_z]
step_pin: PC2
dir_pin: !PL2
enable_pin: !PA5
step_distance: .005
endstop_pin: ^!PB4
position_min: 0.1
position_endstop: 0.7
position_max: 200
homing_retract_dist: 2.0
[endstop_phase stepper_z]
phases: 32
endstop_accuracy: .070
[extruder]
step_pin: PC3
dir_pin: PL6
enable_pin: !PA4
step_distance: .004242
nozzle_diameter: 0.350
filament_diameter: 1.750
pressure_advance: 0.07
heater_pin: PH6
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PF0
control: pid
pid_Kp: 7.0
pid_Ki: 0.1
pid_Kd: 12
min_temp: 0
max_temp: 210
[heater_bed]
heater_pin: PE5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PF2
control: watermark
min_temp: 0
max_temp: 100
[fan]
pin: PH5
[heater_fan nozzle_fan]
pin: PH3
max_power: 0.61
cycle_time: .000030
hardware_pwm: True
[mcu]
serial: /dev/ttyACM0
[printer]
kinematics: cartesian
max_velocity: 500
max_accel: 3000
max_z_velocity: 25
max_z_accel: 30
[ad5206 stepper_digipot]
enable_pin: PD7
# Scale the config so that the channel value can be specified in amps
scale: 1.56
# Channel 1 is E0, 2 is E1, 3 is unused, 4 is Z, 5 is X, 6 is Y
channel_1: 1.0
channel_2: 0.75
channel_4: 0.82
channel_5: 0.82
channel_6: 0.82
# Enable 8 micro-steps on steppers X, Y, Z, E0
[static_digital_output stepper_config]
pins:
PG1, PG0,
PK7, PG2,
PK6, PK5,
PK3, PK4
[static_digital_output yellow_led]
pins: !PB7

79
config/printer-micromake-d1-2016.cfg
View File

@@ -1,79 +0,0 @@
# This file contains a configuration for the "Micromake D1" delta
# printer (using the Makeboard 1.3 electronics). To use this config,
# the firmware should be compiled for the AVR atmega2560.
# See the example.cfg file for a description of available parameters.
[stepper_a]
step_pin: ar54
dir_pin: !ar55
enable_pin: !ar38
step_distance: .01
endstop_pin: ^ar2
homing_speed: 100
position_endstop: 319.5
arm_length: 217.0
[stepper_b]
step_pin: ar60
dir_pin: !ar61
enable_pin: !ar56
step_distance: .01
endstop_pin: ^ar15
[stepper_c]
step_pin: ar46
dir_pin: !ar48
enable_pin: !ar62
step_distance: .01
endstop_pin: ^ar19
[extruder]
step_pin: ar26
dir_pin: ar28
enable_pin: !ar24
step_distance: 0.006271
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: ar10
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog13
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
max_extrude_only_distance: 100.0
[fan]
pin: ar9
[mcu]
serial: /dev/ttyACM0
pin_map: arduino
[printer]
kinematics: delta
max_velocity: 300
max_accel: 3000
max_z_velocity: 150
delta_radius: 95
[delta_calibrate]
radius: 80
#[probe]
#pin: ^!ar18
[display]
lcd_type: hd44780
rs_pin: ar16
e_pin: ar17
d4_pin: ar23
d5_pin: ar25
d6_pin: ar27
d7_pin: ar29
encoder_pins: ^ar31, ^ar33
click_pin: ^!ar35
kill_pin: ^!ar41

94
config/printer-seemecnc-rostock-max-v2-2015.cfg
View File

@@ -1,94 +0,0 @@
# This file constains the pin mappings for the SeeMeCNC Rostock Max
# (version 2) delta printer from 2015. To use this config, the
# firmware should be compiled for the AVR atmega2560.
# See the example.cfg file for a description of available parameters.
[stepper_a]
step_pin: PC0
dir_pin: !PL1
enable_pin: !PA7
step_distance: .0125
endstop_pin: ^PA2
homing_speed: 50
position_endstop: 380
arm_length: 290.800
[stepper_b]
step_pin: PC1
dir_pin: PL0
enable_pin: !PA6
step_distance: .0125
endstop_pin: ^PA1
[stepper_c]
step_pin: PC2
dir_pin: !PL2
enable_pin: !PA5
step_distance: .0125
endstop_pin: ^PC7
[extruder]
step_pin: PC3
dir_pin: !PL6
enable_pin: !PA4
step_distance: .010793
nozzle_diameter: 0.500
filament_diameter: 1.750
heater_pin: PH6
sensor_type: ATC Semitec 104GT-2
sensor_pin: PF0
control: pid
pid_Kp: 20.9700
pid_Ki: 1.3400
pid_Kd: 80.5600
min_temp: 0
max_temp: 300
[heater_bed]
heater_pin: PE5
sensor_type: ATC Semitec 104GT-2
sensor_pin: PF2
control: pid
pid_Kp: 46.510
pid_Ki: 1.040
pid_Kd: 500.000
min_temp: 0
max_temp: 300
[fan]
pin: PH5
[heater_fan nozzle_cooling_fan]
pin: PH4
heater: extruder
[mcu]
serial: /dev/ttyACM0
[printer]
kinematics: delta
max_velocity: 300
max_accel: 3000
max_z_velocity: 150
delta_radius: 174.75
[ad5206 stepper_digipot]
enable_pin: PD7
scale: 2.08
channel_1: 1.34
channel_2: 1.0
channel_4: 1.1
channel_5: 1.1
channel_6: 1.1
[static_digital_output stepper_config]
pins:
PG1, PG0,
PK7, PG2,
PK6, PK5,
PK3, PK4,
PK1, PK2
[static_digital_output yellow_led]
pins: !PB7

94
config/printer-tronxy-x5s-2018.cfg
View File

@@ -1,94 +0,0 @@
# This file contains pin mappings for the Tronxy X5S (circa 2017). To
# use this config, the firmware should be compiled for the AVR
# atmega1284p.
# Note, a number of Melzi boards are shipped with a bootloader that
# requires the following command to flash the board:
# avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
# If the above command does not work and "make flash" does not work
# then one may need to flash a bootloader to the board - see the
# Klipper docs/Bootloaders.md file for more information.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: PD7
dir_pin: !PC5
enable_pin: !PD6
step_distance: .0125
endstop_pin: ^!PC2
position_endstop: 0
position_max: 330
homing_speed: 50
[stepper_y]
step_pin: PC6
dir_pin: !PC7
enable_pin: !PD6
step_distance: .0125
endstop_pin: ^!PC3
position_endstop: 0
position_max: 310
homing_speed: 50
[stepper_z]
step_pin: PB3
dir_pin: PB2
enable_pin: !PD6
step_distance: .0025
endstop_pin: ^!PC4
position_endstop: 0.5
position_max: 400
[extruder]
step_pin: PB1
dir_pin: PB0
enable_pin: !PD6
step_distance: .0111
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PD5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PA7
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 275
[heater_bed]
heater_pin: PD4
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PA6
control: watermark
min_temp: 0
max_temp: 150
[verify_heater heater_bed]
# adjust for personal bed setup, this prevents stock heated bed from issuing
# false positive heating errors due to slow temperature increase
check_gain_time: 600
[fan]
pin: PB4
[mcu]
serial: /dev/ttyUSB0
[printer]
kinematics: corexy
max_velocity: 300
max_accel: 1000
max_z_velocity: 20
max_z_accel: 100
[display]
lcd_type: st7920
cs_pin: PA1
sclk_pin: PC0
sid_pin: PA3
# buttons are:
# PD2, PD3: encoder
# PA5: click

91
config/printer-tronxy-x8-2018.cfg
View File

@@ -1,91 +0,0 @@
# This file contains the configurations and pin mappings for the
# Tronxy X8 using the CXY-V2-0508 board. To use this config file, the
# firmware should be compiled for the AVR ATmega1284p, 16MHz.
# Some Tronxy printers come without a bootloader present on the
# board. In that case, use MCUDude MightyCore ATmega1284p bootloader
# with TQFP44 Sanguino pinout. The package can be found at
# (https://github.com/MCUdude/MightyCore). Follow Klipper install
# instructions but instead of "make flash FLASH_DEVICE=/dev/ttyACM0",
# use the following command:
# avrdude -p atmega1284p -c arduino -b 115200 -P /dev/ttyUSB0 -U out/klipper.elf.hex
# See the example.cfg and example-extras.cfg files for a description
# of available parameters.
[mcu]
serial: /dev/ttyUSB0
[stepper_x]
step_pin: PD7
dir_pin: PC5
enable_pin: !PD6
step_distance: 0.010
endstop_pin: ^!PC2
position_endstop: -47
position_max: 220
position_min: -47
homing_speed: 50
[stepper_y]
step_pin: PC6
dir_pin: PC7
enable_pin: !PD6
step_distance: 0.010
endstop_pin: ^!PC3
position_endstop: 0
position_max: 220
position_min: 0
homing_speed: 50
[stepper_z]
step_pin: PB3
dir_pin: !PB2
enable_pin: !PD6
step_distance: 0.0025
endstop_pin: ^!PC4
position_endstop: 0
position_max: 210
homing_speed: 10
[extruder]
step_pin: PB1
dir_pin: PB0
enable_pin: !PD6
step_distance: 0.009931
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PD5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PA7
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 275
[heater_bed]
heater_pin: PD4
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PA6
control: watermark
max_delta: 2.0
min_temp: 0
max_temp: 150
[fan]
pin: PB4
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 1000
max_z_velocity: 20
max_z_accel: 100
[display]
lcd_type: st7920
cs_pin: PA1
sclk_pin: PC0
sid_pin: PA3

95
config/printer-velleman-k8200-2013.cfg
View File

@@ -1,95 +0,0 @@
# This file contains common pin mappings for the Velleman K8200 and
# 3Drag 3D printers (circa 2013). To use this config, the firmware
# should be compiled for the AVR atmega2560.
# Based on config from Martin Malmqvist and Per Hjort.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: ar54
dir_pin: !ar55
enable_pin: !ar38
step_distance: .0125
endstop_pin: ^ar3
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_y]
step_pin: ar60
dir_pin: !ar61
enable_pin: !ar56
step_distance: .0125
endstop_pin: ^ar14
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_z]
step_pin: ar46
dir_pin: !ar48
enable_pin: !ar63
step_distance: .0025
endstop_pin: ^ar18
position_endstop: 0.5
# Set position_max to 200 if you have the original Z-axis setup.
position_max: 250
[extruder]
step_pin: ar26
# Remove the "!" from dir_pin if you have an original extruder
dir_pin: !ar28
enable_pin: !ar24
# You will have to calculate your own step_distance.
# This is for the belted extruder https://www.thingiverse.com/thing:339928
step_distance: .001333
nozzle_diameter: 0.400
filament_diameter: 2.85
heater_pin: ar10
sensor_type: ATC Semitec 104GT-2
sensor_pin: analog13
control: pid
pid_Kp: 21.503
pid_Ki: 1.103
pid_Kd: 104.825
min_temp: 0
max_temp: 250
[heater_bed]
heater_pin: ar9
sensor_type: ATC Semitec 104GT-2
sensor_pin: analog14
control: pid
pid_Kp: 75.283
pid_Ki: 0.588
pid_Kd: 2408.103
min_temp: 0
max_temp: 130
[fan]
pin: ar8
kick_start_time: 0.500
[mcu]
serial: /dev/ttyUSB0
pin_map: arduino
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 1000
max_z_velocity: 10
max_z_accel: 100
# The LCD is untested - "RepRapDiscount 2004 Smart Controller" displays
#[display]
#lcd_type: hd44780
#rs_pin: ar27
#e_pin: ar29
#d4_pin: ar37
#d5_pin: ar35
#d6_pin: ar33
#d7_pin: ar31
#encoder_pins: ^ar16, ^ar17
#click_pin: ^!ar23

104
config/printer-wanhao-duplicator-6-2016.cfg
View File

@@ -1,104 +0,0 @@
# Support for the Wanhao Duplicator 6 and its clones (eg, Monoprice
# Ultimate). To use this config, the firmware should be compiled for
# the AVR atmega2560.
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: PA3
dir_pin: !PA1
enable_pin: !PA5
step_distance: 0.0125
endstop_pin: ^!PA0
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_y]
step_pin: PC5
dir_pin: PC4
enable_pin: !PC6
step_distance: 0.0125
endstop_pin: ^!PA4
position_endstop: 0
position_max: 200
homing_speed: 50
[stepper_z]
step_pin: PC2
dir_pin: !PC1
enable_pin: !PC3
step_distance: 0.0025
endstop_pin: ^!PA7
position_endstop: 0.5
position_max: 175
homing_speed: 25
[extruder]
step_pin: PL7
dir_pin: !PL6
enable_pin: !PC0
step_distance: 0.010091
nozzle_diameter: 0.400
filament_diameter: 1.7500
heater_pin: PE4
sensor_type: PT100 INA826
sensor_pin: PK0
control: pid
pid_Kp: 26.571
pid_Ki: 0.927
pid_Kd: 190.318
min_temp: 0
max_temp: 250
[heater_bed]
heater_pin: PG5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PK2
control: pid
pid_Kp: 59.593
pid_Ki: 3.01
pid_Kd: 294.985
min_temp: 0
max_temp: 110
[fan]
pin: PH4
[mcu]
serial: /dev/ttyACM0
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100
# Software control for Stepper current
[output_pin stepper_xy_current]
pin: PL5
pwm: True
scale: 2.782
cycle_time: .000030
hardware_pwm: True
static_value: 1.2
[output_pin stepper_z_current]
pin: PL4
pwm: True
scale: 2.782
cycle_time: .000030
hardware_pwm: True
static_value: 1.2
[output_pin stepper_e_current]
pin: PL3
pwm: True
scale: 2.782
cycle_time: .000030
hardware_pwm: True
static_value: 1.0
# N.B. No support for the Display as yet. SSD1309 OLED graphical
# display connected with i2C.

78
config/printer-wanhao-duplicator-i3-plus-2017.cfg
View File

@@ -1,78 +0,0 @@
# This file contains pin mappings for the Wanhao Duplicator i3 Plus
# (circa 2017). To use this config, the firmware should be compiled
# for the AVR atmega2560.
# Pin numbers and other parameters were extracted from the
# official Marlin source available at:
# https://github.com/garychen99/Duplicator-i3-plus
# See the example.cfg file for a description of available parameters.
[stepper_x]
step_pin: PF7
dir_pin: !PK0
enable_pin: !PF6
step_distance: .0125
endstop_pin: ^!PF0
position_endstop: 0
position_max: 200
homing_speed: 30.0
[stepper_y]
step_pin: PK2
dir_pin: !PK3
enable_pin: !PK1
step_distance: .0125
endstop_pin: ^!PA2
position_endstop: 0
position_max: 200
homing_speed: 30.0
[stepper_z]
step_pin: PK5
dir_pin: PK7
enable_pin: !PK4
step_distance: .0025
endstop_pin: ^!PA1
position_endstop: 0.5
position_max: 180
[extruder]
step_pin: PF4
dir_pin: PF5
enable_pin: !PF3
step_distance: 0.010417
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PG5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PF1
control: pid
pid_Kp: 30.850721
pid_Ki: .208175
pid_Kd: 192.298728
min_temp: 0
max_temp: 260
[heater_bed]
heater_pin: PE5
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PK6
control: pid
pid_Kp: 64.095903
pid_Ki: 1.649830
pid_Kd: 622.531455
min_temp: 0
max_temp: 110
[fan]
pin: PE3
[mcu]
serial: /dev/ttyUSB0
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 800
max_z_velocity: 5
max_z_accel: 100

169
config/printer-wanhao-duplicator-i3-v2.1-2017.cfg
View File

@@ -1,169 +0,0 @@
# This file contains pin mappings and other appropriate default
# parameters for a Wanhao Duplicator i3 v2.1 and its clones (Monoprice
# Maker Select, Cocoon Create, etc.).
#
# This will probably work on older revisions (v1.0, v2.0) of the printer
# but is untested on those versions.
# Note, a number of Melzi boards are shipped with a bootloader that
# requires the following command to flash the board:
# avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
# If the above command does not work and "make flash" does not work
# then one may need to flash a bootloader to the board - see the
# Klipper docs/Bootloaders.md file for more information.
# See the example.cfg file for a description of available parameters.
# For best results with klipper and the Wanhao Duplicator i3, follow these
# guidelines:
#
# - Locate the USB serial port for your printer in /dev/serial/by-id/ format.
# See https://github.com/KevinOConnor/klipper/blob/master/docs/FAQ.md#wheres-my-serial-port
# It will be something like:
# /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_ABCD1234-if00-port0
#
# - Configure klipper to compile firmware for the AVR atmega1284p
#
# - At this point, "make flash FLASH_DEVICE=..." should successfully
# flash your printer board. Use the /dev/serial/by-id/ format for
# FLASH_DEVICE to ensure consistent results.
# See https://github.com/KevinOConnor/klipper/blob/master/docs/FAQ.md#the-make-flash-command-doesnt-work
# if you have problems.
#
# - Copy this sample file you are currently reading to ~/printer.cfg,
# and customize the following parameters:
# * [extruder] > step_distance
#
# This is the inverse of "E steps" (extruder steps per mm) from the stock
# Wanhao Repetier-based firmware.
# (See https://3dprinterwiki.info/extruder-steps/ )
#
# For example, if your E-steps are set to 107.0 steps per mm,
# then step_distance should be (1 / 107.0) ~= .009346
#
# * [extruder] > PID parameters (pid_Kp, pid_Ki, pid_Kd)
# * [heater_bed] > PID parameters (pid_Kp, pid_Ki, pid_Kd)
#
# PID values from stock Wanhao firmware (Repetier) do not
# translate directly to klipper. You will need to run klipper's
# PID autotune function for the extruder and bed. After getting the
# klipper firmware up and running, run the PID_CALIBRATE procedures
# by sending these commands via octoprint terminal (one per autotune):
#
# extruder: PID_CALIBRATE HEATER=extruder TARGET=<temp>
# heated bed: PID_CALIBRATE HEATER=heater_bed TARGET=<temp>
#
# After the autotune process completes, PID parameter results
# can be found in the Octoprint terminal tab (if you're quick)
# or in /tmp/klippy.log.
#
# Enter the PID parameters into the appropriate sections of ~/printer.cfg .
#
# * [extruder] > max_temp
# * [heater_bed] > max_temp
#
# The max temps included in this printer config are limited to 230 for extruder
# and 70 for heated bed. If your printer has been modified to handle higher temps
# (like an upgraded hot end or a separate MOSFET for your heated bed), you may
# want to increase these values.
#
# Note: Some Melzi boards were shipped with 10K pullup resistors
# instead of 4.7K. If the temperatures on your printer seem way
# off before running the PID tune, you may need to add
# "pullup_resistor: 10000" to both the extruder and the heater_bed
# config sections.
#
# * [mcu] > serial
#
# Enter the USB serial port of the printer in /dev/serial/by-id/ format
# for best results.
#
# - Power cycle the Wanhao Duplicator i3
#
# - Issue the command "RESTART" via the Octoprint terminal tab (similar to
# how you would send a manual gcode command, but send the word RESTART).
# This tells klipper to reload its config file and do an internal reset.
# You should then see a status screen appear on the printer's LCD.
#
# - Be sure to follow these instructions before attempting any prints:
# https://github.com/KevinOConnor/klipper/blob/master/docs/Config_checks.md
[stepper_x]
step_pin: PD7
dir_pin: PC5
enable_pin: !PD6
step_distance: .0125
endstop_pin: ^!PC2
position_endstop: 0
position_max: 200
homing_speed: 40
[stepper_y]
step_pin: PC6
dir_pin: PC7
enable_pin: !PD6
step_distance: .0125
endstop_pin: ^!PC3
position_endstop: 0
position_max: 200
homing_speed: 40
[stepper_z]
step_pin: PB3
dir_pin: !PB2
enable_pin: !PA5
step_distance: 0.0025
endstop_pin: ^!PC4
position_endstop: 0.5
position_max: 180
homing_speed: 2
[extruder]
step_pin: PB1
dir_pin: !PB0
enable_pin: !PD6
step_distance: .009346
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PD5
sensor_type: NTC 100K beta 3950
sensor_pin: PA7
control: pid
pid_Kp: 18.214030
pid_Ki: 0.616380
pid_Kd: 134.556146
min_temp: 0
max_temp: 230
[heater_bed]
heater_pin: PD4
sensor_type: NTC 100K beta 3950
sensor_pin: PA6
control: pid
pid_Kp: 71.321
pid_Ki: 1.989
pid_Kd: 639.210
min_temp: 0
max_temp: 70
[fan]
pin: PB4
[mcu]
serial: /dev/ttyUSB0
restart_method: command
[printer]
kinematics: cartesian
max_velocity: 200
max_accel: 1000
max_z_velocity: 2
max_z_accel: 100
[display]
lcd_type: st7920
cs_pin: PC1
sclk_pin: PD3
sid_pin: PC0
encoder_pins: ^PA2, ^PA1
click_pin: ^!PA3

36
config/sample-macros.cfg
View File

@@ -1,36 +0,0 @@
# This file provides examples of Klipper G-Code macros. The snippets
# in this file may be copied into the main printer.cfg file.
#
# See the "example.cfg" file for description of common config parameters.
# M300 : Play tone, Beeper support, as commonly found on usual LCD displays
# i.e. RepRapDiscount 2004 Smart Controller, RepRapDiscount 12864 Full Graphic
# This defines a custom I/O pin and a custom GCODE macro
# Usage: M300 [P<ms>] [S<Hz>] P is the tone duration, S the tone frequency.
# as it is based on a PWM duty cycle, the frequency won't be pitch perfect.
#
#[output_pin BEEPER_pin]
#pin: ar37
# Beeper pin. This parameter must be provided.
# ar37 is the default RAMPS/MKS pin.
#pwm: True
# A piezo beeper needs a PWM signal, a DC buzzer doesn't.
#value: 0
# Silent at power on, set to 1 if active low.
#shutdown_value: 0
# Disable at emergency shutdown (no PWM would be available anyway).
#cycle_time: 0.001
# PWM frequency : 0.001 = 1ms will give a base tone of 1kHz
#scale: 1000
# PWM parameter will be in the range of (0-1000 Hz).
# Although not pitch perfect.
#
#[gcode_macro M300]
#default_parameter_S=1000
# Allows for a default 1kHz tone if S is omitted
#default_parameter_P=100
# Allows for a default 10ms duration is P is omitted
#gcode: SET_PIN PIN=BEEPER_pin VALUE={S}
# G4 P{P}
# SET_PIN PIN=BEEPER_pin VALUE=0

51
config/sample-probe-as-z-endstop.cfg
View File

@@ -1,51 +0,0 @@
# This file provides example config file settings for use on a printer
# that uses a Z probe instead of a traditional Z endstop switch. This
# file is just a "snippet" of config sections - it must be added to a
# config file containing the configuration of the rest of the printer.
# Be sure to review and update this config with the appropriate pins
# and coordinates for your printer.
# See the "example.cfg" and "example-extras.cfg" files for a
# description of config parameters.
# Define a probe
[probe]
pin: ar30
z_offset: 2.345
# Example settings to add to stepper_z section
[stepper_z]
endstop_pin: probe:z_virtual_endstop
position_min: -2 # The Z carriage may need to travel below the Z=0
# homing point if the bed has a significant tilt.
# The homing_override section modifies the default G28 behavior
[homing_override]
set_position_z: 5
axes: z
gcode:
; G90 ; Uncomment these 2 lines to blindly lift the Z 2mm at start
; G1 Z7 F600
G28 X0 Y0
G1 X100 Y100 F3600
G28 Z0
# Example bed_tilt config section
[bed_tilt]
points:
100,100
10,10
10,100
10,190
100,10
100,190
190,10
190,100
190,190
# Example bed_mesh config section
[bed_mesh]
min_point: 20,20
max_point: 200,200
probe_count: 4,4

272
docs/Bootloaders.md
View File

@@ -1,272 +0,0 @@
This document provides information on common bootloaders found on
micro-controllers that Klipper supports.
The bootloader is 3rd-party software that runs on the micro-controller
when it is first powered on. It is typically used to flash a new
application (eg, Klipper) to the micro-controller without requiring
specialized hardware. Unfortunately, there is no industry wide
standard for flashing a micro-controller, nor is there a standard
bootloader that works across all micro-controllers. Worse, it is
common for each bootloader to require a different set of steps to
flash an application.
If one can flash a bootloader to a micro-controller then one can
generally also use that mechanism to flash an application, but care
should be taken when doing this as one may inadvertently remove the
bootloader. In contrast, a bootloader will generally only permit a
user to flash an application. It is therefore recommended to use a
bootloader to flash an application where possible.
This document attempts to describe common bootloaders, the steps
needed to flash a bootloader, and the steps needed to flash an
application. This document is not an authoritative reference; it is
intended as a collection of useful information that the Klipper
developers have accumulated.
AVR micro-controllers
=====================
In general, the Arduino project is a good reference for bootloaders
and flashing procedures on the 8-bit Atmel Atmega micro-controllers.
In particular, the "boards.txt" file:
https://github.com/arduino/Arduino/blob/1.8.5/hardware/arduino/avr/boards.txt
is a useful reference.
To flash a bootloader itself, the AVR chips require an external
hardware flashing tool (which communicates with the chip using
SPI). This tool can be purchased (for example, do a web search for
"avr isp", "arduino isp", or "usb tiny isp"). It is also possible to
use another Arduino or Raspberry Pi to flash an AVR bootloader (for
example, do a web search for "program an avr using raspberry pi"). The
examples below are written assuming an "AVR ISP Mk2" type device is in
use.
The "avrdude" program is the most common tool used to flash atmega
chips (both bootloader flashing and application flashing).
## Atmega2560 ##
This chip is typically found in the "Arduino Mega" and is very common
in 3d printer boards.
To flash the bootloader itself use something like:
```
wget 'https://github.com/arduino/Arduino/raw/1.8.5/hardware/arduino/avr/bootloaders/stk500v2/stk500boot_v2_mega2560.hex'
avrdude -cavrispv2 -patmega2560 -P/dev/ttyACM0 -b115200 -e -u -U lock:w:0x3F:m -U efuse:w:0xFD:m -U hfuse:w:0xD8:m -U lfuse:w:0xFF:m
avrdude -cavrispv2 -patmega2560 -P/dev/ttyACM0 -b115200 -U flash:w:stk500boot_v2_mega2560.hex
avrdude -cavrispv2 -patmega2560 -P/dev/ttyACM0 -b115200 -U lock:w:0x0F:m
```
To flash an application use something like:
```
avrdude -cwiring -patmega2560 -P/dev/ttyACM0 -b115200 -D -Uflash:w:out/klipper.elf.hex:i
```
## Atmega1280 ##
This chip is typically found in earlier versions of the "Arduino
Mega".
To flash the bootloader itself use something like:
```
wget 'https://github.com/arduino/Arduino/raw/1.8.5/hardware/arduino/avr/bootloaders/atmega/ATmegaBOOT_168_atmega1280.hex'
avrdude -cavrispv2 -patmega1280 -P/dev/ttyACM0 -b115200 -e -u -U lock:w:0x3F:m -U efuse:w:0xF5:m -U hfuse:w:0xDA:m -U lfuse:w:0xFF:m
avrdude -cavrispv2 -patmega1280 -P/dev/ttyACM0 -b115200 -U flash:w:ATmegaBOOT_168_atmega1280.hex
avrdude -cavrispv2 -patmega1280 -P/dev/ttyACM0 -b115200 -U lock:w:0x0F:m
```
To flash an application use something like:
```
avrdude -carduino -patmega1280 -P/dev/ttyACM0 -b57600 -D -Uflash:w:out/klipper.elf.hex:i
```
## Atmega1284p ##
This chip is commonly found in "Melzi" style 3d printer boards.
To flash the bootloader itself use something like:
```
wget 'https://github.com/Lauszus/Sanguino/raw/1.0.2/bootloaders/optiboot/optiboot_atmega1284p.hex'
avrdude -cavrispv2 -patmega1284p -P/dev/ttyACM0 -b115200 -e -u -U lock:w:0x3F:m -U efuse:w:0xFD:m -U hfuse:w:0xDE:m -U lfuse:w:0xFF:m
avrdude -cavrispv2 -patmega1284p -P/dev/ttyACM0 -b115200 -U flash:w:optiboot_atmega1284p.hex
avrdude -cavrispv2 -patmega1284p -P/dev/ttyACM0 -b115200 -U lock:w:0x0F:m
```
To flash an application use something like:
```
avrdude -carduino -patmega1284p -P/dev/ttyACM0 -b115200 -D -Uflash:w:out/klipper.elf.hex:i
```
Note that a number of "Melzi" style boards come preloaded with a
bootloader that uses a baud rate of 57600. In this case, to flash an
application use something like this instead:
```
avrdude -carduino -patmega1284p -P/dev/ttyACM0 -b57600 -D -Uflash:w:out/klipper.elf.hex:i
```
## At90usb1286 ##
This document does not cover the method to flash a bootloader to the
At90usb1286 nor does it cover general application flashing to this
device.
The Teensy++ device from pjrc.com comes with a proprietary bootloader.
It requires a custom flashing tool from
https://github.com/PaulStoffregen/teensy_loader_cli . One can flash an
application with it using something like:
```
teensy_loader_cli --mcu=at90usb1286 out/klipper.elf.hex -v
```
## Atmega168 ##
The atmega168 has limited flash space. If using a bootloader, it is
recommended to use the Optiboot bootloader. To flash that bootloader
use something like:
```
wget 'https://github.com/arduino/Arduino/raw/1.8.5/hardware/arduino/avr/bootloaders/optiboot/optiboot_atmega168.hex'
avrdude -cavrispv2 -patmega168 -P/dev/ttyACM0 -b115200 -e -u -U lock:w:0x3F:m -U efuse:w:0x04:m -U hfuse:w:0xDD:m -U lfuse:w:0xFF:m
avrdude -cavrispv2 -patmega168 -P/dev/ttyACM0 -b115200 -U flash:w:optiboot_atmega168.hex
avrdude -cavrispv2 -patmega168 -P/dev/ttyACM0 -b115200 -U lock:w:0x0F:m
```
To flash an application via the Optiboot bootloader use something
like:
```
avrdude -carduino -patmega168 -P/dev/ttyACM0 -b115200 -D -Uflash:w:out/klipper.elf.hex:i
```
SAM3 micro-controllers (Arduino Due)
====================================
It is not common to use a bootloader with the SAM3 mcu. The chip
itself has a ROM that allows the flash to be programmed from 3.3V
serial port or from USB.
To enable the ROM, the "erase" pin is held high during a reset, which
erases the flash contents, and causes the ROM to run. On an Arduino
Due, this sequence can be accomplished by setting a baud rate of 1200
on the "programming usb port" (the USB port closest to the power
supply).
The code at https://github.com/shumatech/BOSSA can be used to program
the SAM3. It is recommended to use version 1.9 or later.
To flash an application use something like:
```
bossac -U -p /dev/ttyACM0 -a -e -w out/klipper.bin -v -b
bossac -U -p /dev/ttyACM0 -R
```
SAM4 micro-controllers (Duet Wifi)
====================================
It is not common to use a bootloader with the SAM4 mcu. The chip
itself has a ROM that allows the flash to be programmed from 3.3V
serial port or from USB.
To enable the ROM, the "erase" pin is held high during a reset, which
erases the flash contents, and causes the ROM to run.
The code at https://github.com/shumatech/BOSSA can be used to program
the SAM4. It is necessary to use version `1.8.0` or higher.
To flash an application use something like:
```
bossac --port=/dev/ttyACM0 -b -U -e -w -v -R out/klipper.bin
```
SAMD21 micro-controllers (Arduino Zero)
=======================================
The SAMD21 bootloader is flashed via the ARM Serial Wire Debug (SWD)
interface. This is commonly done with a dedicated SWD hardware dongle.
Alternatively, it appears one can use a Raspberry Pi with OpenOCD as a
programmer (see:
https://learn.adafruit.com/programming-microcontrollers-using-openocd-on-raspberry-pi
).
Unfortunately, there are two common bootloaders deployed on the
SAMD21. One comes standard with the "Arduino Zero" and the other comes
standard with the "Arduino M0".
The Arduino Zero uses an 8KiB bootloader (the application must be
compiled with a start address of 8KiB). One can enter the bootloader
by double clicking the reset button. To flash an application use
something like:
```
bossac -U -p "$(FLASH_DEVICE)" --offset=0x2000 -w out/klipper.bin -v -b -R
```
The Arduino M0 uses a 16KiB bootloader (the application must be
compiled with a start address of 16KiB). To flash an application,
reset the micro-controller and run the flash command within the first
few seconds of boot - something like:
```
avrdude -c stk500v2 -p atmega2560 -P /dev/ttyACM0 -u -Uflash:w:out/klipper.elf.hex:i
```
STM32F103 micro-controllers (Blue Pill devices)
===============================================
The STM32F103 devices have a ROM that can flash a bootloader or
application via 3.3V serial. To access this ROM, one should connect
the "boot 0" pin to high and "boot 1" pin to low, and then reset the
device. The "stm32flash" package can then be used to flash the device
using something like:
```
stm32flash -w out/klipper.bin -v -g 0 /dev/ttyAMA0
```
Note that if one is using a Raspberry Pi for the 3.3V serial, the
stm32flash protocol uses a serial parity mode which the Raspberry Pi's
"miniuart" does not support. See
https://www.raspberrypi.org/documentation/configuration/uart.md for
details on enabling the full uart on the Raspberry Pi GPIO pins.
After flashing, set both "boot 0" and "boot 1" back to low so that
future resets boot from flash.
## STM32F103 with stm32duino bootloader ##
The "stm32duino" project has a USB capable bootloader - see:
https://github.com/rogerclarkmelbourne/STM32duino-bootloader
This bootloader can be flashed via 3.3V serial with something like:
```
wget 'https://github.com/rogerclarkmelbourne/STM32duino-bootloader/raw/master/binaries/generic_boot20_pc13.bin'
stm32flash -w generic_boot20_pc13.bin -v -g 0 /dev/ttyAMA0
```
This bootloader uses 8KiB of flash space (the application must be
compiled with a start address of 8KiB). Flash an application with
something like:
```
dfu-util -d 1eaf:0003 -a 2 -R -D out/klipper.bin
```
The bootloader typically runs for only a short period after boot. It
may be necessary to time the above command so that it runs while the
bootloader is still active (the bootloader will flash a board led
while it is running). Alternatively, set the "boot 0" pin to low and
"boot 1" pin to high to stay in the bootloader after a reset.
LPC176x micro-controllers (Smoothieboards)
==========================================
This document does not describe the method to flash a bootloader
itself - see: http://smoothieware.org/flashing-the-bootloader for
further information on that topic.
It is common for Smoothieboards to come with a bootloader from:
https://github.com/triffid/LPC17xx-DFU-Bootloader . When using this
bootloader the application must be compiled with a start address of
16KiB. The easiest way to flash an application with this bootloader is
to copy the application file (eg, `out/klipper.bin`) to a file named
`firmware.bin` on an SD card, and then to reboot the micro-controller
with that SD card.

38
docs/CONTRIBUTING.md
View File

@@ -1,38 +0,0 @@
# Contributing to Klipper
Thank you for contributing to Klipper! Please take a moment to read
this document.
## Creating a new issue
Please see the [contact page](Contact.md) for information on creating
an issue. In particular, **we need the klippy.log file** attached to
bug reports. Also, be sure to read the [FAQ](FAQ.md) to see if a
similar issue has already been raised.
## Submitting a pull request
Contributions of Code and documentation are managed through github
pull requests. Each commit should have a commit message formatted
similar to the following:
```
module: Capitalized, short (50 chars or less) summary
More detailed explanatory text, if necessary. Wrap it to about 75
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Further paragraphs come after blank lines..
Signed-off-by: My Name <myemail@example.org>
```
It is important to have a "Signed-off-by" line on each commit - it
certifies that you agree to the
[developer certificate of origin](developer-certificate-of-origin). It
must contain your real name (sorry, no pseudonyms or anonymous
contributions) and contain a current email address.

454
docs/Code_Overview.md
View File

@@ -1,454 +0,0 @@
This document describes the overall code layout and major code flow of
Klipper.
Directory Layout
================
The **src/** directory contains the C source for the micro-controller
code. The **src/avr/** directory contains specific code for Atmel
ATmega micro-controllers. The **src/sam3x8e/** directory contains code
specific to the Arduino Due style ARM micro-controllers. The
**src/pru/** directory contains code specific to the Beaglebone's
on-board PRU micro-controller. The **src/simulator/** contains code
stubs that allow the micro-controller to be test compiled on other
architectures. The **src/generic/** directory contains helper code
that may be useful across different host architectures. The build
arranges for includes of "board/somefile.h" to first look in the
current architecture directory (eg, src/avr/somefile.h) and then in
the generic directory (eg, src/generic/somefile.h).
The **klippy/** directory contains the host software. Most of the host
software is written in Python, however the **klippy/chelper/**
directory contains some C code helpers. The **klippy/kinematics/**
directory contains the robot kinematics code. The **klippy/extras/**
directory contains the host code extensible "modules".
The **lib/** directory contains external 3rd-party library code that
is necessary to build some targets.
The **config/** directory contains example printer configuration
files.
The **scripts/** directory contains build-time scripts useful for
compiling the micro-controller code.
The **test/** directory contains automated test cases.
During compilation, the build may create an **out/** directory. This
contains temporary build time objects. The final micro-controller
object that is built is **out/klipper.elf.hex** on AVR and
**out/klipper.bin** on ARM.
Micro-controller code flow
==========================
Execution of the micro-controller code starts in architecture specific
code (eg, **src/avr/main.c**) which ultimately calls sched_main()
located in **src/sched.c**. The sched_main() code starts by running
all functions that have been tagged with the DECL_INIT() macro. It
then goes on to repeatedly run all functions tagged with the
DECL_TASK() macro.
One of the main task functions is command_dispatch() located in
**src/command.c**. This function is called from the board specific
input/output code (eg, **src/avr/serial.c**) and it runs the command
functions associated with the commands found in the input
stream. Command functions are declared using the DECL_COMMAND() macro
(see the [protocol](Protocol.md) document for more information).
Task, init, and command functions always run with interrupts enabled
(however, they can temporarily disable interrupts if needed). These
functions should never pause, delay, or do any work that lasts more
than a few micro-seconds. These functions schedule work at specific
times by scheduling timers.
Timer functions are scheduled by calling sched_add_timer() (located in
**src/sched.c**). The scheduler code will arrange for the given
function to be called at the requested clock time. Timer interrupts
are initially handled in an architecture specific interrupt handler
(eg, **src/avr/timer.c**) which calls sched_timer_dispatch() located
in **src/sched.c**. The timer interrupt leads to execution of schedule
timer functions. Timer functions always run with interrupts
disabled. The timer functions should always complete within a few
micro-seconds. At completion of the timer event, the function may
choose to reschedule itself.
In the event an error is detected the code can invoke shutdown() (a
macro which calls sched_shutdown() located in **src/sched.c**).
Invoking shutdown() causes all functions tagged with the
DECL_SHUTDOWN() macro to be run. Shutdown functions always run with
interrupts disabled.
Much of the functionality of the micro-controller involves working
with General-Purpose Input/Output pins (GPIO). In order to abstract
the low-level architecture specific code from the high-level task
code, all GPIO events are implemented in architecture specific
wrappers (eg, **src/avr/gpio.c**). The code is compiled with gcc's
"-flto -fwhole-program" optimization which does an excellent job of
inlining functions across compilation units, so most of these tiny
gpio functions are inlined into their callers, and there is no
run-time cost to using them.
Klippy code overview
====================
The host code (Klippy) is intended to run on a low-cost computer (such
as a Raspberry Pi) paired with the micro-controller. The code is
primarily written in Python, however it does use CFFI to implement
some functionality in C code.
Initial execution starts in **klippy/klippy.py**. This reads the
command-line arguments, opens the printer config file, instantiates
the main printer objects, and starts the serial connection. The main
execution of G-code commands is in the process_commands() method in
**klippy/gcode.py**. This code translates the G-code commands into
printer object calls, which frequently translate the actions to
commands to be executed on the micro-controller (as declared via the
DECL_COMMAND macro in the micro-controller code).
There are four threads in the Klippy host code. The main thread
handles incoming gcode commands. A second thread (which resides
entirely in the **klippy/chelper/serialqueue.c** C code) handles
low-level IO with the serial port. The third thread is used to process
response messages from the micro-controller in the Python code (see
**klippy/serialhdl.py**). The fourth thread writes debug messages to
the log (see **klippy/queuelogger.py**) so that the other threads
never block on log writes.
Code flow of a move command
===========================
A typical printer movement starts when a "G1" command is sent to the
Klippy host and it completes when the corresponding step pulses are
produced on the micro-controller. This section outlines the code flow
of a typical move command. The [kinematics](Kinematics.md) document
provides further information on the mechanics of moves.
* Processing for a move command starts in gcode.py. The goal of
gcode.py is to translate G-code into internal calls. Changes in
origin (eg, G92), changes in relative vs absolute positions (eg,
G90), and unit changes (eg, F6000=100mm/s) are handled here. The
code path for a move is: `process_data() -> process_commands() ->
cmd_G1()`. Ultimately the ToolHead class is invoked to execute the
actual request: `cmd_G1() -> ToolHead.move()`
* The ToolHead class (in toolhead.py) handles "look-ahead" and tracks
the timing of printing actions. The codepath for a move is:
`ToolHead.move() -> MoveQueue.add_move() -> MoveQueue.flush() ->
Move.set_junction() -> Move.move()`.
* ToolHead.move() creates a Move() object with the parameters of the
move (in cartesian space and in units of seconds and millimeters).
* MoveQueue.add_move() places the move object on the "look-ahead"
queue.
* MoveQueue.flush() determines the start and end velocities of each
move.
* Move.set_junction() implements the "trapezoid generator" on a
move. The "trapezoid generator" breaks every move into three parts:
a constant acceleration phase, followed by a constant velocity
phase, followed by a constant deceleration phase. Every move
contains these three phases in this order, but some phases may be of
zero duration.
* When Move.move() is called, everything about the move is known -
its start location, its end location, its acceleration, its
start/cruising/end velocity, and distance traveled during
acceleration/cruising/deceleration. All the information is stored in
the Move() class and is in cartesian space in units of millimeters
and seconds.
The move is then handed off to the kinematics classes: `Move.move()
-> kin.move()`
* The goal of the kinematics classes is to translate the movement in
cartesian space to movement on each stepper. The kinematics classes
are located in the klippy/kinematics/ directory. The kinematic class
is given a chance to audit the move (`ToolHead.move() ->
kin.check_move()`) before it goes on the look-ahead queue, but once
the move arrives in *kin*.move() the kinematic class is required to
handle the move as specified. Note that the extruder is handled in
its own kinematic class. Since the Move() class specifies the exact
movement time and since step pulses are sent to the micro-controller
with specific timing, stepper movements produced by the extruder
class will be in sync with head movement even though the code is
kept separate.
* Klipper uses an
[iterative solver](https://en.wikipedia.org/wiki/Root-finding_algorithm)
to generate the step times for each stepper. For efficiency reasons,
the stepper pulse times are generated in C code. The code flow is:
`kin.move() -> MCU_Stepper.step_itersolve() ->
itersolve_gen_steps()` (in klippy/chelper/itersolve.c). The goal of
the iterative solver is to find step times given a function that
calculates a stepper position from a time. This is done by
repeatedly "guessing" various times until the stepper position
formula returns the desired position of the next step on the
stepper. The feedback produced from each guess is used to improve
future guesses so that the process rapidly converges to the desired
time. The kinematic stepper position formulas are located in the
klippy/chelper/ directory (eg, kin_cart.c, kin_corexy.c,
kin_delta.c, kin_extruder.c).
* After the iterative solver calculates the step times they are added
to an array: `itersolve_gen_steps() -> queue_append()` (in
klippy/chelper/stepcompress.c). The array (struct
stepcompress.queue) stores the corresponding micro-controller clock
counter times for every step. Here the "micro-controller clock
counter" value directly corresponds to the micro-controller's
hardware counter - it is relative to when the micro-controller was
last powered up.
* The next major step is to compress the steps: `stepcompress_flush()
-> compress_bisect_add()` (in klippy/chelper/stepcompress.c). This
code generates and encodes a series of micro-controller "queue_step"
commands that correspond to the list of stepper step times built in
the previous stage. These "queue_step" commands are then queued,
prioritized, and sent to the micro-controller (via
stepcompress.c:steppersync and serialqueue.c:serialqueue).
* Processing of the queue_step commands on the micro-controller starts
in src/command.c which parses the command and calls
`command_queue_step()`. The command_queue_step() code (in
src/stepper.c) just appends the parameters of each queue_step
command to a per stepper queue. Under normal operation the
queue_step command is parsed and queued at least 100ms before the
time of its first step. Finally, the generation of stepper events is
done in `stepper_event()`. It's called from the hardware timer
interrupt at the scheduled time of the first step. The
stepper_event() code generates a step pulse and then reschedules
itself to run at the time of the next step pulse for the given
queue_step parameters. The parameters for each queue_step command
are "interval", "count", and "add". At a high-level, stepper_event()
runs the following, 'count' times: `do_step(); next_wake_time =
last_wake_time + interval; interval += add;`
The above may seem like a lot of complexity to execute a
movement. However, the only really interesting parts are in the
ToolHead and kinematic classes. It's this part of the code which
specifies the movements and their timings. The remaining parts of the
processing is mostly just communication and plumbing.
Adding a host module
====================
The Klippy host code has a dynamic module loading capability. If a
config section named "[my_module]" is found in the printer config file
then the software will automatically attempt to load the python module
klippy/extras/my_module.py . This module system is the preferred
method for adding new functionality to Klipper.
The easiest way to add a new module is to use an existing module as a
reference - see **klippy/extras/servo.py** as an example.
The following may also be useful:
* Execution of the module starts in the module level `load_config()`
function (for config sections of the form [my_module]) or in
`load_config_prefix()` (for config sections of the form
[my_module my_name]). This function is passed a "config" object and
it must return a new "printer object" associated with the given
config section.
* During the process of instantiating a new printer object, the config
object can be used to read parameters from the given config
section. This is done using `config.get()`, `config.getfloat()`,
`config.getint()`, etc. methods. Be sure to read all values from the
config during the construction of the printer object - if the user
specifies a config parameter that is not read during this phase then
it will be assumed it is a typo in the config and an error will be
raised.
* Use the `config.get_printer()` method to obtain a reference to the
main "printer" class. This "printer" class stores references to all
the "printer objects" that have been instantiated. Use the
`printer.lookup_object()` method to find references to other printer
objects. Almost all functionality (even core kinematic modules) are
encapsulated in one of these printer objects. Note, though, that
when a new module is instantiated, not all other printer objects
will have been instantiated. The "gcode" and "pins" modules will
always be available, but for other modules it is a good idea to
defer the lookup.
* Define a `printer_state()` method if the code needs to be called
during printer setup and/or shutdown. This method is called twice
during setup (with "connect" and then "ready") and may also be
called at run-time (with "shutdown" or "disconnect"). It is common
to perform "printer object" lookup during the "connect" and "ready"
phases.
* If there is an error in the user's config, be sure to raise it
during the `load_config()` or `printer_state("connect")` phases. Use
either `raise config.error("my error")` or `raise
printer.config_error("my error")` to report the error.
* Use the "pins" module to configure a pin on a micro-controller. This
is typically done with something similar to
`printer.lookup_object("pins").setup_pin("pwm",
config.get("my_pin"))`. The returned object can then be commanded at
run-time.
* If the module needs access to system timing or external file
descriptors then use `printer.get_reactor()` to obtain access to the
global "event reactor" class. This reactor class allows one to
schedule timers, wait for input on file descriptors, and to "sleep"
the host code.
* Do not use global variables. All state should be stored in the
printer object returned from the `load_config()` function. This is
important as otherwise the RESTART command may not perform as
expected. Also, for similar reasons, if any external files (or
sockets) are opened then be sure to close them from the
`printer_state("disconnect")` callback.
* Avoid accessing the internal member variables (or calling methods
that start with an underscore) of other printer objects. Observing
this convention makes it easier to manage future changes.
* If submitting the module for inclusion in the main Klipper code, be
sure to place a copyright notice at the top of the module. See the
existing modules for the preferred format.
Adding new kinematics
=====================
This section provides some tips on adding support to Klipper for
additional types of printer kinematics. This type of activity requires
excellent understanding of the math formulas for the target
kinematics. It also requires software development skills - though one
should only need to update the host software.
Useful steps:
1. Start by studying the
"[code flow of a move](#code-flow-of-a-move-command)" section and
the [Kinematics document](Kinematics.md).
2. Review the existing kinematic classes in the klippy/kinematics/
directory. The kinematic classes are tasked with converting a move
in cartesian coordinates to the movement on each stepper. One
should be able to copy one of these files as a starting point.
3. Implement the C stepper kinematic position functions for each
stepper if they are not already available (see kin_cart.c,
kin_corexy.c, and kin_delta.c in klippy/chelper/). The function
should call `move_get_coord()` to convert a given move time (in
seconds) to a cartesian coordinate (in millimeters), and then
calculate the desired stepper position (in millimeters) from that
cartesian coordinate.
4. Implement the `calc_position()` method in the new kinematics class.
This method calculates the position of the toolhead in cartesian
coordinates from the current position of each stepper. It does not
need to be efficient as it is typically only called during homing
and probing operations.
5. Other methods. Implement the `move()`, `check_move()`, `home()`,
`motor_off()`, `set_position()`, and `get_steppers()` methods.
These functions are typically used to provide kinematic specific
checks. However, at the start of development one can use
boiler-plate code here.
6. Implement test cases. Create a g-code file with a series of moves
that can test important cases for the given kinematics. Follow the
[debugging documentation](Debugging.md) to convert this g-code file
to micro-controller commands. This is useful to exercise corner
cases and to check for regressions.
Porting to a new micro-controller
=================================
This section provides some tips on porting Klipper's micro-controller
code to a new architecture. This type of activity requires good
knowledge of embedded development and hands-on access to the target
micro-controller.
Useful steps:
1. Start by identifying any 3rd party libraries that will be used
during the port. Common examples include "CMSIS" wrappers and
manufacturer "HAL" libraries. All 3rd party code needs to be GNU
GPLv3 compatible. The 3rd party code should be committed to the
Klipper lib/ directory. Update the lib/README file with information
on where and when the library was obtained. It is preferable to
copy the code into the Klipper repository unchanged, but if any
changes are required then those changes should be listed explicitly
in the lib/README file.
2. Create a new architecture sub-directory in the src/ directory and
add initial Kconfig and Makefile support. Use the existing
architectures as a guide. The src/simulator provides a basic
example of a minimum starting point.
3. The first main coding task is to bring up communication support to
the target board. This is the most difficult step in a new port.
Once basic communication is working, the remaining steps tend to be
much easier. It is typical to use an RS-232 style serial port
during initial development as these types of hardware devices are
generally easier to enable and control. During this phase, make
liberal use of helper code from the src/generic/ directory (check
how src/simulator/Makefile includes the generic C code into the
build). It is also necessary to define timer_read_time() (which
returns the current system clock) in this phase, but it is not
necessary to fully support timer irq handling.
4. Get familiar with the the console.py tool (as described in the
[debugging document](Debugging.md)) and verify connectivity to the
micro-controller with it. This tool translates the low-level
micro-controller communication protocol to a human readable form.
5. Add support for timer dispatch from hardware interrupts. See
Klipper
[commit 970831ee](https://github.com/KevinOConnor/klipper/commit/970831ee0d3b91897196e92270d98b2a3067427f)
as an example of steps 1-5 done for the LPC176x architecture.
6. Bring up basic GPIO input and output support. See Klipper
[commit c78b9076](https://github.com/KevinOConnor/klipper/commit/c78b90767f19c9e8510c3155b89fb7ad64ca3c54)
as an example of this.
7. Bring up additional peripherals - for example see Klipper commit
[65613aed](https://github.com/KevinOConnor/klipper/commit/65613aeddfb9ef86905cb1dade9e773a02ef3c27),
[c812a40a](https://github.com/KevinOConnor/klipper/commit/c812a40a3782415e454b04bf7bd2158a6f0ec8b5),
and
[c381d03a](https://github.com/KevinOConnor/klipper/commit/c381d03aad5c3ee761169b7c7bced519cc14da29).
8. Create a sample Klipper config file in the config/ directory. Test
the micro-controller with the main klippy.py program.
9. Consider adding build test cases in the test/ directory.
Time
====
Fundamental to the operation of Klipper is the handling of clocks,
times, and timestamps. Klipper executes actions on the printer by
scheduling events to occur in the near future. For example, to turn on
a fan, the code might schedule a change to a GPIO pin in a 100ms. It
is rare for the code to attempt to take an instantaneous action. Thus,
the handling of time within Klipper is critical to correct operation.
There are three types of times tracked internally in the Klipper host
software:
* System time. The system time uses the system's monotonic clock - it
is a floating point number stored as seconds and it is (generally)
relative to when the host computer was last started. System times
have limited use in the software - they are primarily used when
interacting with the operating system. Within the host code, system
times are frequently stored in variables named *eventtime* or
*curtime*.
* Print time. The print time is synchronized to the main
micro-controller clock (the micro-controller defined in the "[mcu]"
config section). It is a floating point number stored as seconds and
is relative to when the main mcu was last restarted. It is possible
to convert from a "print time" to the main micro-controller's
hardware clock by multiplying the print time by the mcu's statically
configured frequency rate. The high-level host code uses print times
to calculates almost all physical actions (eg, head movement, heater
changes, etc.). Within the host code, print times are generally
stored in variables named *print_time* or *move_time*.
* MCU clock. This is the hardware clock counter on each
micro-controller. It is stored as an integer and its update rate is
relative to the frequency of the given micro-controller. The host
software translates its internal times to clocks before transmission
to the mcu. The mcu code only ever tracks time in clock
ticks. Within the host code, clock values are tracked as 64bit
integers, while the mcu code uses 32bit integers. Within the host
code, clocks are generally stored in variables with names containing
*clock* or *ticks*.
Conversion between the different time formats is primarily implemented
in the **klippy/clocksync.py** code.
Some things to be aware of when reviewing the code:
* 32bit and 64bit clocks: To reduce bandwidth and to improve
micro-controller efficiency, clocks on the micro-controller are
tracked as 32bit integers. When comparing two clocks in the mcu
code, the `timer_is_before()` function must always be used to ensure
integer rollovers are handled properly. The host software converts
32bit clocks to 64bit clocks by appending the high-order bits from
the last mcu timestamp it has received - no message from the mcu is
ever more than 2^31 clock ticks in the future or past so this
conversion is never ambiguous. The host converts from 64bit clocks
to 32bit clocks by simply truncating the high-order bits. To ensure
there is no ambiguity in this conversion, the
**klippy/chelper/serialqueue.c** code will buffer messages until
they are within 2^31 clock ticks of their target time.
* Multiple micro-controllers: The host software supports using
multiple micro-controllers on a single printer. In this case, the
"MCU clock" of each micro-controller is tracked separately. The
clocksync.py code handles clock drift between micro-controllers by
modifying the way it converts from "print time" to "MCU clock". On
secondary mcus, the mcu frequency that is used in this conversion is
regularly updated to account for measured drift.

167
docs/Config_checks.md
View File

@@ -1,167 +0,0 @@
This document provides a list of steps to help confirm the pin
settings in the Klipper printer.cfg file. It is a good idea to run
through these steps after following the steps in the
[installation document](Installation.md).
During this guide, it may be necessary to make changes to the Klipper
config file. Be sure to issue a RESTART command after every change to
the config file to ensure that the change takes effect (type "restart"
in the Octoprint terminal tab and then click "Send"). It's also a good
idea to issue a STATUS command after every RESTART to verify that the
config file is successfully loaded.
### Verify temperature
Start by verifying that temperatures are being properly
reported. Navigate to the Octoprint temperature tab.
![octoprint-temperature](img/octoprint-temperature.png)
Verify that the temperature of the nozzle and bed (if applicable) are
present and not increasing. If it is increasing, remove power from the
printer. If the temperatures are not accurate, review the
"sensor_type" and "sensor_pin" settings for the nozzle and/or bed.
### Verify M112
Navigate to the Octoprint terminal tab and issue an M112 command in
the terminal box. This command requests Klipper to go into a
"shutdown" state. It will cause Octoprint to disconnect from Klipper -
navigate to the Connection area and click on "Connect" to cause
Octoprint to reconnect. Then navigate to the Octoprint temperature tab
and verify that temperatures continue to update and the temperatures
are not increasing. If temperatures are increasing, remove power from
the printer.
The M112 command causes Klipper to go into a "shutdown" state. To
clear this state, issue a FIRMWARE_RESTART command in the Octoprint
terminal tab.
### Verify heaters
Navigate to the Octoprint temperature tab and type in 50 followed by
enter in the "Tool" temperature box. The extruder temperature in the
graph should start to increase (within about 30 seconds or so). Then
go to the "Tool" temperature drop-down box and select "Off". After
several minutes the temperature should start to return to its initial
room temperature value. If the temperature does not increase then
verify the "heater_pin" setting in the config.
If the printer has a heated bed then perform the above test again with
the bed.
### Verify stepper motor enable pin
Verify that all of the printer axes can manually move freely (the
stepper motors are disabled). If not, issue an M84 command to disable
the motors. If any of the axes still can not move freely, then verify
the stepper "enable_pin" configuration for the given axis. On most
commodity stepper motor drivers, the motor enable pin is "active low"
and therefore the enable pin should have a "!" before the pin (for
example, "enable_pin: !ar38").
### Verify endstops
Manually move all the printer axes so that none of them are in contact
with an endstop. Send a QUERY_ENDSTOPS command via the Octoprint
terminal tab. It should respond with the current state of all of the
configured endstops and they should all report a state of "open". For
each of the endstops, rerun the QUERY_ENDSTOPS command while manually
triggering the endstop. The QUERY_ENDSTOPS command should report the
endstop as "TRIGGERED".
If the endstop appears inverted (it reports "open" when triggered and
vice-versa) then add a "!" to the pin definition (for example,
"endstop_pin: ^!ar3"), or remove the "!" if there is already one
present.
If the endstop does not change at all then it generally indicates that
the endstop is connected to a different pin. However, it may also
require a change to the pullup setting of the pin (the '^' at the
start of the endstop_pin name - most printers will use a pullup
resistor and the '^' should be present).
### Verify stepper motors
Use the STEPPER_BUZZ command to verify the connectivity of each
stepper motor. Start by manually positioning the given axis to a
midway point and then run `STEPPER_BUZZ STEPPER=stepper_x` . The
STEPPER_BUZZ command will cause the given stepper to move one
millimeter in a positive direction and then it will return to its
starting position. (If the endstop is defined at position_endstop=0
then at the start of each movement the stepper will move away from the
endstop.) It will perform this oscillation ten times.
If the stepper does not move at all, then verify the "enable_pin" and
"step_pin" settings for the stepper. If the stepper motor moves but
does not return to its original position then verify the "dir_pin"
setting. If the stepper motor oscillates in an incorrect direction,
then it generally indicates that the "dir_pin" for the axis needs to
be inverted. This is done by adding a '!' to the "dir_pin" in the
printer config file (or removing it if one is already there). If the
motor moves significantly more or significantly less than one
millimeter then verify the "step_distance" setting.
Run the above test for each stepper motor defined in the config
file. (Set the STEPPER parameter of the STEPPER_BUZZ command to the
name of the config section that is to be tested.) If there is no
filament in the extruder then one can use STEPPER_BUZZ to verify the
extruder motor connectivity (use STEPPER=extruder). Otherwise, it's
best to test the extruder motor separately (see the next section).
After verifying all endstops and verifying all stepper motors the
homing mechanism should be tested. Issue a G28 command to home all
axes. Remove power from the printer if it does not home properly.
Rerun the endstop and stepper motor verification steps if necessary.
### Verify extruder motor
To test the extruder motor it will be necessary to heat the extruder
to a printing temperature. Navigate to the Octoprint temperature tab
and select a target temperature from the temperature drop-down box (or
manually enter an appropriate temperature). Wait for the printer to
reach the desired temperature. Then navigate to the Octoprint control
tab and click the "Extrude" button. Verify that the extruder motor
turns in the correct direction. If it does not, see the
troubleshooting tips in the previous section to confirm the
"enable_pin", "step_pin", and "dir_pin" settings for the extruder.
### Calibrate PID settings
Klipper supports
[PID control](https://en.wikipedia.org/wiki/PID_controller) for the
extruder and bed heaters. In order to use this control mechanism it is
necessary to calibrate the PID settings on each printer. (PID settings
found in other firmwares or in the example configuration files often
work poorly.)
To calibrate the extruder, navigate to the OctoPrint terminal tab and
run the PID_CALIBRATE command. For example: `PID_CALIBRATE
HEATER=extruder TARGET=170`
At the completion of the tuning test run `SAVE_CONFIG` to update the
printer.cfg file the new PID settings.
If the printer has a heated bed and it supports being driven by PWM
(Pulse Width Modulation) then it is recommended to use PID control for
the bed. (When the bed heater is controlled using the PID algorithm it
may turn on and off ten times a second, which may not be suitable for
heaters using a mechanical switch.) A typical bed PID calibration
command is: `PID_CALIBRATE HEATER=heater_bed TARGET=60`
### Next steps
This guide is intended to help with basic verification of pin settings
in the Klipper configuration file. It may be necessary to perform
detailed printer calibration - a number of guides are available online
to help with this (for example, do a web search for "3d printer
calibration").
See the [Slicers](Slicers.md) document for information on configuring
a slicer with Klipper. If one is using traditional endstop switches
with Trinamic stepper motor drivers then see the
[Endstop Phase](Endstop_Phase.md) document. If using a delta printer,
see the [Delta Calibrate](Delta_Calibrate.md) document.
After one has verified that basic printing works, it is a good idea to
consider calibrating [pressure advance](Pressure_Advance.md).

57
docs/Contact.md
View File

@@ -1,57 +0,0 @@
This page provides information on how to contact the Klipper
developers.
Issue reporting
===============
It is very important to attach the Klipper log file to all
reports. The log file has been engineered to answer common questions
the Klipper developers have about the software and its environment
(software version, hardware type, configuration, event timing, and
hundreds of other questions). **The developers need the Klipper log
file to provide any meaningful assistance**; only this log file
provides the necessary information.
On a problem report the first step is to **issue an M112 command** in
the OctoPrint terminal window immediately after the undesirable event
occurs. This causes Klipper to go into a "shutdown state" and it will
cause additional debugging information to be written to the log file.
Issue requests are submitted through Github. **All Github issues must
include the full /tmp/klippy.log log file from the session that
produced the event being reported.** An "scp" and/or "sftp" utility is
needed to acquire this log file. The "scp" utility comes standard with
Linux and MacOS desktops. There are freely available scp utilities for
other desktops (eg, WinSCP).
Use the scp utility to copy the `/tmp/klippy.log` file from the
Raspberry Pi to your desktop. It is a good idea to compress the
klippy.log file before posting it (eg, using zip or gzip). Open a new
issue at https://github.com/KevinOConnor/klipper/issues , provide a
description of the problem, and **attach the `klippy.log` file to the
issue**: ![attach-issue](img/attach-issue.png)
Mailing list
============
There is a mailing list for general discussions on Klipper. In order
to send am email to the list, one must first subscribe:
https://www.freelists.org/list/klipper . Once subscribed, emails may
be sent to `klipper@freelists.org`.
Archives of the mailing list are available at:
https://www.freelists.org/archive/klipper/
IRC
===
One may join the #klipper channel on freenode.net (
irc://chat.freenode.net:6667 ).
To communicate in this IRC channel one will need an IRC
client. Configure it to connect to chat.freenode.net on port 6667 and
join the #klipper channel (`/join #klipper`).
If asking a question on IRC, be sure to ask the question and then stay
connected to the channel to receive responses. Due to timezone
differences, it may take several hours before receiving a response.

414
docs/Debugging.md
View File

@@ -1,414 +0,0 @@
The Klippy host code has some tools to help in debugging.
Translating gcode files to micro-controller commands
====================================================
The Klippy host code can run in a batch mode to produce the low-level
micro-controller commands associated with a gcode file. Inspecting
these low-level commands is useful when trying to understand the
actions of the low-level hardware. It can also be useful to compare
the difference in micro-controller commands after a code change.
To run Klippy in this batch mode, there is a one time step necessary
to generate the micro-controller "data dictionary". This is done by
compiling the micro-controller code to obtain the **out/klipper.dict**
file:
```
make menuconfig
make
```
Once the above is done it is possible to run Klipper in batch mode
(see [installation](Installation.md) for the steps necessary to build
the python virtual environment and a printer.cfg file):
```
~/klippy-env/bin/python ./klippy/klippy.py ~/printer.cfg -i test.gcode -o test.serial -v -d out/klipper.dict
```
The above will produce a file **test.serial** with the binary serial
output. This output can be translated to readable text with:
```
~/klippy-env/bin/python ./klippy/parsedump.py out/klipper.dict test.serial > test.txt
```
The resulting file **test.txt** contains a human readable list of
micro-controller commands.
The batch mode disables certain response / request commands in order
to function. As a result, there will be some differences between
actual commands and the above output. The generated data is useful for
testing and inspection; it is not useful for sending to a real
micro-controller.
Testing with simulavr
=====================
The [simulavr](http://www.nongnu.org/simulavr/) tool enables one to
simulate an Atmel ATmega micro-controller. This section describes how
one can run test gcode files through simulavr. It is recommended to
run this on a desktop class machine (not a Raspberry Pi) as it does
require significant cpu to run efficiently.
To use simulavr, download the simulavr package and compile with python
support:
```
git clone git://git.savannah.nongnu.org/simulavr.git
cd simulavr
./bootstrap
./configure --enable-python
make
```
Note that the build system may need to have some packages (such as
swig) installed in order to build the python module. Make sure the
file **src/python/_pysimulavr.so** is present after the above
compilation.
To compile Klipper for use in simulavr, run:
```
cd /patch/to/klipper
make menuconfig
```
and compile the micro-controller software for an AVR atmega644p, set
the MCU frequency to 20Mhz, and select SIMULAVR software emulation
support. Then one can compile Klipper (run `make`) and then start the
simulation with:
```
PYTHONPATH=/path/to/simulavr/src/python/ ./scripts/avrsim.py -m atmega644 -s 20000000 -b 250000 out/klipper.elf
```
Then, with simulavr running in another window, one can run the
following to read gcode from a file (eg, "test.gcode"), process it
with Klippy, and send it to Klipper running in simulavr (see
[installation](Installation.md) for the steps necessary to build the
python virtual environment):
```
~/klippy-env/bin/python ./klippy/klippy.py config/avrsim.cfg -i test.gcode -v
```
Using simulavr with gtkwave
---------------------------
One useful feature of simulavr is its ability to create signal wave
generation files with the exact timing of events. To do this, follow
the directions above, but run avrsim.py with a command-line like the
following:
```
PYTHONPATH=/path/to/simulavr/src/python/ ./scripts/avrsim.py -m atmega644 -s 20000000 -b 250000 out/klipper.elf -t PORTA.PORT,PORTC.PORT
```
The above would create a file **avrsim.vcd** with information on each
change to the GPIOs on PORTA and PORTB. This could then be viewed
using gtkwave with:
```
gtkwave avrsim.vcd
```
Manually sending commands to the micro-controller
=================================================
Normally, the host klippy.py process would be used to translate gcode
commands to Klipper micro-controller commands. However, it's also
possible to manually send these MCU commands (functions marked with
the DECL_COMMAND() macro in the Klipper source code). To do so, run:
```
~/klippy-env/bin/python ./klippy/console.py /tmp/pseudoserial 250000
```
See the "HELP" command within the tool for more information on its
functionality.
Generating load graphs
======================
The Klippy log file (/tmp/klippy.log) stores statistics on bandwidth,
micro-controller load, and host buffer load. It can be useful to graph
these statistics after a print.
To generate a graph, a one time step is necessary to install the
"matplotlib" package:
```
sudo apt-get update
sudo apt-get install python-matplotlib
```
Then graphs can be produced with:
```
~/klipper/scripts/graphstats.py /tmp/klippy.log loadgraph.png
```
One can then view the resulting **loadgraph.png** file.
Extracting information from the klippy.log file
===============================================
The Klippy log file (/tmp/klippy.log) also contains debugging
information. There is a logextract.py script that may be useful when
analyzing a micro-controller shutdown or similar problem. It is
typically run with something like:
```
mkdir work_directory
cd work_directory
cp /tmp/klippy.log .
~/klipper/scripts/logextract.py ./klippy.log
```
The script will extract the printer config file and will extract MCU
shutdown information. The information dumps from an MCU shutdown (if
present) will be reordered by timestamp to assist in diagnosing cause
and effect scenarios.
Micro-controller Benchmarks
===========================
This section describes the mechanism used to generate the Klipper
micro-controller step rate benchmarks.
The primary goal of the benchmarks is to provide a consistent
mechanism for measuring the impact of coding changes within the
software. A secondary goal is to provide high-level metrics for
comparing the performance between chips and between software
platforms.
The step rate benchmark is designed to find the maximum stepping rate
that the hardware and software can reach. This benchmark stepping rate
is not achievable in day-to-day use as Klipper needs to perform other
tasks (eg, mcu/host communication, temperature reading, endstop
checking) in any real-world usage.
In general, the pins for the benchmark tests are chosen to flash LEDs
or other innocuous pins. **Always verify that it is safe to drive the
configured pins prior to running a benchmark.** It is not recommended
to drive an actual stepper during a benchmark.
## Step rate benchmark test ##
The test is performed using the console.py tool (described above). The
micro-controller is configured for the particular hardware platform
(see below) and then the following is cut-and-paste into the
console.py terminal window:
```
SET start_clock {clock+freq}
SET ticks 1000
reset_step_clock oid=0 clock={start_clock}
set_next_step_dir oid=0 dir=0
queue_step oid=0 interval={ticks} count=60000 add=0
set_next_step_dir oid=0 dir=1
queue_step oid=0 interval=3000 count=1 add=0
reset_step_clock oid=1 clock={start_clock}
set_next_step_dir oid=1 dir=0
queue_step oid=1 interval={ticks} count=60000 add=0
set_next_step_dir oid=1 dir=1
queue_step oid=1 interval=3000 count=1 add=0
reset_step_clock oid=2 clock={start_clock}
set_next_step_dir oid=2 dir=0
queue_step oid=2 interval={ticks} count=60000 add=0
set_next_step_dir oid=2 dir=1
queue_step oid=2 interval=3000 count=1 add=0
```
The above tests three steppers simultaneously stepping. If running the
above results in a "Rescheduled timer in the past" or "Stepper too far
in past" error then it indicates the `ticks` parameter is too low (it
results in a stepping rate that is too fast). The goal is to find the
lowest setting of the ticks parameter that reliably results in a
successful completion of the test. It should be possible to bisect the
ticks parameter until a stable value is found.
On a failure, one can copy-and-paste the following to clear the error
in preparation for the next test:
```
clear_shutdown
```
To obtain the single stepper and dual stepper benchmarks, the same
configuration sequence is used, but only the first block (for the
single stepper case) or first two blocks (for the dual stepper case)
of the above test is cut-and-paste into the console.py window.
To produce the benchmarks found in the Features.md document, the total
number of steps per second is calculated by multiplying the number of
active steppers with the nominal mcu frequency and dividing by the
final ticks parameter. The results are rounded to the nearest K. For
example, with three active steppers:
```
ECHO Test result is: {"%.0fK" % (3. * freq / ticks / 1000.)}
```
### AVR step rate benchmark ###
The following configuration sequence is used on AVR chips:
```
PINS arduino
allocate_oids count=3
config_stepper oid=0 step_pin=ar29 dir_pin=ar28 min_stop_interval=0 invert_step=0
config_stepper oid=1 step_pin=ar27 dir_pin=ar26 min_stop_interval=0 invert_step=0
config_stepper oid=2 step_pin=ar23 dir_pin=ar22 min_stop_interval=0 invert_step=0
finalize_config crc=0
```
The test was last run on commit `b161a69e` with gcc version `avr-gcc
(GCC) 4.8.1`. Both the 16Mhz and 20Mhz tests were run using simulavr
configured for an atmega644p (previous tests have confirmed simulavr
results match tests on both a 16Mhz at90usb and a 16Mhz atmega2560).
On both 16Mhz and 20Mhz the best single stepper result is `SET ticks
106`, the best dual stepper result is `SET ticks 276`, and the best
three stepper result is `SET ticks 481`.
### Arduino Due step rate benchmark ###
The following configuration sequence is used on the Due:
```
allocate_oids count=3
config_stepper oid=0 step_pin=PB27 dir_pin=PA21 min_stop_interval=0 invert_step=0
config_stepper oid=1 step_pin=PB26 dir_pin=PC30 min_stop_interval=0 invert_step=0
config_stepper oid=2 step_pin=PA21 dir_pin=PC30 min_stop_interval=0 invert_step=0
finalize_config crc=0
```
The test was last run on commit `b161a69e` with gcc version
`arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0`. The best single
stepper result is `SET ticks 207`, the best dual stepper result is
`SET ticks 205`, and the best three stepper result is `SET ticks 317`.
### Duet Wifi step rate benchmark ###
The following configuration sequence is used on the Duet Wifi:
```
allocate_oids count=3
config_stepper oid=0 step_pin=PD6 dir_pin=PD11 min_stop_interval=0 invert_step=0
config_stepper oid=1 step_pin=PD7 dir_pin=PD12 min_stop_interval=0 invert_step=0
config_stepper oid=2 step_pin=PD8 dir_pin=PD13 min_stop_interval=0 invert_step=0
finalize_config crc=0
```
The test was last run on commit `34c3cb5c` with gcc version
`arm-none-eabi-gcc (15:5.4.1+svn241155-1) 5.4.1 20160919`. The best
single stepper result is `SET ticks 295`, the best dual stepper result
is `SET ticks 264`, and the best three stepper result is `SET ticks
282`.
### Beaglebone PRU step rate benchmark ###
The following configuration sequence is used on the PRU:
```
PINS beaglebone
allocate_oids count=3
config_stepper oid=0 step_pin=P8_13 dir_pin=P8_12 min_stop_interval=0 invert_step=0
config_stepper oid=1 step_pin=P8_15 dir_pin=P8_14 min_stop_interval=0 invert_step=0
config_stepper oid=2 step_pin=P8_19 dir_pin=P8_18 min_stop_interval=0 invert_step=0
finalize_config crc=0
```
The test was last run on commit `b161a69e` with gcc version `pru-gcc
(GCC) 8.0.0 20170530 (experimental)`. The best single stepper result
is `SET ticks 861`, the best dual stepper result is `SET ticks 853`,
and the best three stepper result is `SET ticks 883`.
### STM32F103 step rate benchmark ###
The following configuration sequence is used on the STM32F103:
```
allocate_oids count=3
config_stepper oid=0 step_pin=PC13 dir_pin=PB5 min_stop_interval=0 invert_step=0
config_stepper oid=1 step_pin=PB3 dir_pin=PB6 min_stop_interval=0 invert_step=0
config_stepper oid=2 step_pin=PA4 dir_pin=PB7 min_stop_interval=0 invert_step=0
finalize_config crc=0
```
The test was last run on commit `b161a69e` with gcc version
`arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0`. The best single
stepper result is `SET ticks 41`, the best dual stepper result is `SET
ticks 48`, and the best three stepper result is `SET ticks 80`.
### LPC176x step rate benchmark ###
The following configuration sequence is used on the LPC176x:
```
allocate_oids count=3
config_stepper oid=0 step_pin=P1.20 dir_pin=P1.18 min_stop_interval=0 invert_step=0
config_stepper oid=1 step_pin=P1.21 dir_pin=P1.18 min_stop_interval=0 invert_step=0
config_stepper oid=2 step_pin=P1.23 dir_pin=P1.18 min_stop_interval=0 invert_step=0
finalize_config crc=0
```
The test was last run on commit `b161a69e` with gcc version
`arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0`. For the 100Mhz
LPC1768, the best single stepper result is `SET ticks 119`, the best
dual stepper result is `SET ticks 118`, and the best three stepper
result is `SET ticks 154`. The 120Mhz LPC1769 results were obtained by
overclocking an LPC1768 to 120Mhz - the best single stepper result is
`SET ticks 140`, the best dual stepper result is `SET ticks 137`, and
the best three stepper result is `SET ticks 154`.
### SAMD21 step rate benchmark ###
The following configuration sequence is used on the SAMD21:
```
allocate_oids count=3
config_stepper oid=0 step_pin=PA27 dir_pin=PA20 min_stop_interval=0 invert_step=0
config_stepper oid=1 step_pin=PB3 dir_pin=PA21 min_stop_interval=0 invert_step=0
config_stepper oid=2 step_pin=PA17 dir_pin=PA21 min_stop_interval=0 invert_step=0
finalize_config crc=0
```
The test was last run on commit `b161a69e` with gcc version
`arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0`. The best single
stepper result is `SET ticks 277`, the best dual stepper result is
`SET ticks 410`, and the best three stepper result is `SET ticks 664`.
## Command dispatch benchmark ##
The command dispatch benchmark tests how many "dummy" commands the
micro-controller can process. It is primarily a test of the hardware
communication mechanism. The test is run using the console.py tool
(described above). The following is cut-and-paste into the console.py
terminal window:
```
DELAY {clock+freq} get_uptime
FLOOD 100000 0.0 end_group
get_uptime
```
When the test completes, determine the difference between the clocks
reported in the two "uptime" response messages. The total number of
commands per second is then `100000 * mcu_frequency / clock_diff`.
| MCU | Rate | Build | Build compiler |
| ------------------- | ---- | -------- | ------------------- |
| atmega2560 (serial) | 23K | b161a69e | avr-gcc (GCC) 4.8.1 |
| at90usb1286 (USB) | 75K | b161a69e | avr-gcc (GCC) 4.8.1 |
| sam3x8e (serial) | 23K | b161a69e | arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0 |
| pru (shared memory) | 5K | b161a69e | pru-gcc (GCC) 8.0.0 20170530 (experimental) |
| stm32f103 (USB) | 335K | b161a69e | arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0 |
| lpc1768 (USB) | 546K | b161a69e | arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0 |
| lpc1769 (USB) | 619K | b161a69e | arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0 |
| samd21 (USB) | 238K | b161a69e | arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0 |
Host Benchmarks
===============
It is possible to run timing tests on the host software using the
"batch mode" processing mechanism described above. This is typically
done by choosing a large and complex G-Code file and timing how long
it takes for the host software to process it. For example:
```
time ~/klippy-env/bin/python ./klippy/klippy.py config/example.cfg -i something_complex.gcode -o /dev/null -d out/klipper.dict
```

213
docs/Delta_Calibrate.md
View File

@@ -1,213 +0,0 @@
This document describes Klipper's automatic calibration system for
"delta" style printers.
Delta calibration involves finding the tower endstop positions, tower
angles, delta radius, and delta arm lengths. These settings control
printer motion on a delta printer. Each one of these parameters has a
non-obvious and non-linear impact and it is difficult to calibrate
them manually. In contrast, the software calibration code can provide
excellent results with just a few minutes of time. No special probing
hardware is necessary to get good results.
Basic delta calibration
=======================
Klipper has a DELTA_CALIBRATE command that can perform basic delta
calibration. This command probes seven different points on the bed and
calculates new values for the tower angles, tower endstops, and delta
radius.
In order to perform this calibration the initial delta parameters (arm
lengths, radius, and endstop positions) must be provided and they
should have an accuracy to within a few millimeters. Most delta
printer kits will provide these parameters - configure the printer
with these initial defaults and then go on to run the DELTA_CALIBRATE
command as described below. If no defaults are available then search
online for a delta calibration guide that can provide a basic starting
point.
During the delta calibration process it may be necessary for the
printer to probe below what would otherwise be considered the plane of
the bed. It is typical to permit this during calibration by updating
the config so that the printer's `minimum_z_position=-5`. (Once
calibration completes, one can remove this setting from the config.)
There are two ways to perform the probing - manual probing and
automatic probing. Automatic probing utilizes a hardware device
capable of triggering when the toolhead is at a set distance from the
bed. Manual probing involves using the "paper test" to determine the
height at each probe point. It is recommended to use manual probing
for delta calibration. A number of common printer kits come with
probes that are not sufficiently accurate (specifically, small
differences in arm length can cause effector tilt which can skew an
automatic probe). Manual probing only takes a few minutes and it
eliminates error introduced by the probe.
To perform the basic probe, make sure the config has a
[delta_calibrate] section defined and run:
```
G28
DELTA_CALIBRATE METHOD=manual
```
After probing the seven points new delta parameters will be
calculated. Save and apply these parameters by running:
```
SAVE_CONFIG
```
The basic calibration should provide delta parameters that are
accurate enough for basic printing. If this is a new printer, this is
a good time to print some basic objects and verify general
functionality.
Enhanced delta calibration
==========================
The basic delta calibration generally does a good job of calculating
delta parameters such that the nozzle is the correct distance from the
bed. However, it does not attempt to calibrate X and Y dimensional
accuracy. It's a good idea to perform an enhanced delta calibration to
verify dimensional accuracy.
This calibration procedure requires printing a test object and
measuring parts of that test object with digital calipers.
Prior to running an enhanced delta calibration one must run the basic
delta calibration (via the DELTA_CALIBRATE command) and save the
results (via the SAVE_CONFIG command).
Use a slicer to generate G-Code from the
[docs/prints/calibrate_size.stl](prints/calibrate_size.stl) file.
Slice the object using a slow speed (eg, 40mm/s). If possible, use a
stiff plastic (such as PLA) for the object. The object has a diameter
of 140mm. If this is too large for the printer then one can scale it
down (but be sure to uniformly scale both the X and Y axes). If the
printer supports significantly larger prints then this object can also
be increased in size. A larger size can improve the measurement
accuracy, but good print adhesion is more important than a larger
print size.
Print the test object and wait for it to fully cool. The commands
described below must be run with the same printer settings used to
print the calibration object (don't run DELTA_CALIBRATE between
printing and measuring, or do something that would otherwise change
the printer configuration).
If possible, perform the measurements described below while the object
is still attached to the print bed, but don't worry if the part
detaches from the bed - just try to avoid bending the object when
performing the measurements.
Start by measuring the distance between the center pillar and the
pillar next to the "A" label (which should also be pointing towards
the "A" tower).
![delta-a-distance](img/delta-a-distance.jpg)
Then go counterclockwise and measure the distances between the center
pillar and the other pillars (distance from center to pillar across
from C label, distance from center to pillar with B label, etc.).
![delta_cal_e_step1](img/delta_cal_e_step1.png)
Enter these parameters into Klipper with a comma separated list of
floating point numbers:
```
DELTA_ANALYZE CENTER_DISTS=<a_dist>,<far_c_dist>,<b_dist>,<far_a_dist>,<c_dist>,<far_b_dist>
```
Provide the values without spaces between them.
Then measure the distance between the A pillar and the pillar across
from the C label.
![delta-ab-distance](img/delta-outer-distance.jpg)
Then go counterclockwise and measure the distance between the pillar
across from C to the B pillar, the distance between the B pillar and
the pillar across from A, and so on.
![delta_cal_e_step2](img/delta_cal_e_step2.png)
Enter these parameters into Klipper:
```
DELTA_ANALYZE OUTER_DISTS=<a_to_far_c>,<far_c_to_b>,<b_to_far_a>,<far_a_to_c>,<c_to_far_b>,<far_b_to_a>
```
At this point it is okay to remove the object from the bed. The final
measurements are of the pillars themselves. Measure the size of the
center pillar along the A spoke, then the B spoke, and then the C
spoke.
![delta-a-pillar](img/delta-a-pillar.jpg)
![delta_cal_e_step3](img/delta_cal_e_step3.png)
Enter them into Klipper:
```
DELTA_ANALYZE CENTER_PILLAR_WIDTHS=<a>,<b>,<c>
```
The final measurements are of the outer pillars. Start by measuring
the distance of the A pillar along the line from A to the pillar
across from C.
![delta-ab-pillar](img/delta-outer-pillar.jpg)
Then go counterclockwise and measure the remaining outer pillars
(pillar across from C along the line to B, B pillar along the line to
pillar across from A, etc.).
![delta_cal_e_step4](img/delta_cal_e_step4.png)
And enter them into Klipper:
```
DELTA_ANALYZE OUTER_PILLAR_WIDTHS=<a>,<far_c>,<b>,<far_a>,<c>,<far_b>
```
If the object was scaled to a smaller or larger size then provide the
scale factor that was used when slicing the object:
```
DELTA_ANALYZE SCALE=1.0
```
(A scale value of 2.0 would mean the object is twice its original
size, 0.5 would be half its original size.)
Finally, perform the enhanced delta calibration by running:
```
DELTA_ANALYZE CALIBRATE=extended
```
This command can take several minutes to complete. After completion it
will calculate updated delta parameters (delta radius, tower angles,
endstop positions, and arm lengths). Use the SAVE_CONFIG command to
save and apply the settings:
```
SAVE_CONFIG
```
The SAVE_CONFIG command will save both the updated delta parameters
and information from the distance measurements. Future DELTA_CALIBRATE
commands will also utilize this distance information. Do not attempt
to reenter the raw distance measurements after running SAVE_CONFIG, as
this command changes the printer configuration and the raw
measurements no longer apply.
Additional notes
----------------
* If the delta printer has good dimensional accuracy then the distance
between any two pillars should be around 74mm and the width of every
pillar should be around 9mm. (Specifically, the goal is for the
distance between any two pillars minus the width of one of the
pillars to be exactly 65mm.) Should there be a dimensional
inaccuracy in the part then the DELTA_ANALYZE routine will calculate
new delta parameters using both the distance measurements and the
previous height measurements from the last DELTA_CALIBRATE command.
* DELTA_ANALYZE may produce delta parameters that are surprising. For
example, it may suggest arm lengths that do not match the printer's
actual arm lengths. Despite this, testing has shown that
DELTA_ANALYZE often produces superior results. It is believed that
the calculated delta parameters are able to account for slight
errors elsewhere in the hardware. For example, small differences in
arm length may result in a tilt to the effector and some of that
tilt may be accounted for by adjusting the arm length parameters.

125
docs/Endstop_Phase.md
View File

@@ -1,125 +0,0 @@
This document describes Klipper's stepper phase adjusted endstop
system. This functionality can improve the accuracy of traditional
endstop switches. It is most useful when using a Trinamic stepper
motor driver that has run-time configuration.
A typical endstop switch has an accuracy of around 100 microns. (Each
time an axis is homed the switch may trigger slightly earlier or
slightly later.) Although this is a relatively small error, it can
result in unwanted artifacts. In particular, this positional deviation
may be noticeable when printing the first layer of an object. In
contrast, typical stepper motors can obtain significantly higher
precision.
The stepper phase adjusted endstop mechanism can use the precision of
the stepper motors to improve the precision of the endstop switches.
When a stepper motor moves it cycles through a series of phases until
in completes four "full steps". So, a stepper motor using 16
micro-steps would have 64 phases and when moving in a positive
direction it would cycle through phases: 0, 1, 2, ... 61, 62, 63, 0,
1, 2, etc. Crucially, when the stepper motor is at a particular
position on a linear rail it should always be at the same stepper
phase. Thus, when a carriage triggers the endstop switch the stepper
controlling that carriage should always be at the same stepper motor
phase. Klipper's endstop phase system combines the stepper phase with
the endstop trigger to improve the accuracy of the endstop.
In order to use this functionality it is necessary to be able to
identify the phase of the stepper motor. If one is using Trinamic
TMC2130, TMC2208, TMC2224 or TMC2660 drivers in run-time configuration
mode (ie, not stand-alone mode) then Klipper can query the stepper
phase from the driver. (It is also possible to use this system on
traditional stepper drivers if one can reliably reset the stepper
drivers - see below for details.)
Calibrating endstop phases
==========================
If using Trinamic stepper motor drivers with run-time configuration
then one can calibrate the endstop phases using the
ENDSTOP_PHASE_CALIBRATE command. Start by adding the following to the
config file:
```
[endstop_phase]
```
Then RESTART the printer and run a `G28` command followed by an
`ENDSTOP_PHASE_CALIBRATE` command. Then move the toolhead to a new
location and run `G28` again. Try moving the toolhead to several
different locations and rerun `G28` from each position. Run at least
five `G28` commands.
After performing the above, the `ENDSTOP_PHASE_CALIBRATE` command will
often report the same (or nearly the same) phase for the stepper. This
phase can be saved in the config file so that all future G28 commands
use that phase. (So, in future homing operations, Klipper will obtain
the same position even if the endstop triggers a little earlier or a
little later.)
To save the endstop phase for a particular stepper motor, run
something like the following:
```
ENDSTOP_PHASE_CALIBRATE STEPPER=stepper_z
```
Run the above for all the steppers one wishes to save. Typically, one
would use this on stepper_z for cartesian and corexy printers, and for
stepper_a, stepper_b, and stepper_c on delta printers. Finally, run
the following to update the configuration file with the data:
```
SAVE_CONFIG
```
Additional notes
----------------
* This feature is most useful on delta printers and on the Z endstop
of cartesian/corexy printers. It is possible to use this feature on
the XY endstops of cartesian printers, but that isn't particularly
useful as a minor error in X/Y endstop position is unlikely to
impact print quality. It is not valid to use this feature on the XY
endstops of corexy printers (as the XY position is not determined by
a single stepper on corexy kinematics). It is not valid to use this
feature on a printer using a "probe:z_virtual_endstop" Z endstop (as
the stepper phase is only stable if the endstop is at a static
location on a rail).
* After calibrating the endstop phase, if the endstop is later moved
or adjusted then it will be necessary to recalibrate the endstop.
Remove the calibration data from the config file and rerun the steps
above.
* In order to use this system the endstop must be accurate enough to
identify the stepper position within two "full steps". So, for
example, if a stepper is using 16 micro-steps with a step distance
of 0.005mm then the endstop must have an accuracy of at least
0.160mm. If one gets "Endstop stepper_z incorrect phase" type error
messages than in may be due to an endstop that is not sufficiently
accurate. If recalibration does not help then disable endstop phase
adjustments by removing them from the config file.
* If one is using a traditional stepper controlled Z axis (as on a
cartesian or corexy printer) along with traditional bed leveling
screws then it is also possible to use this system to arrange for
each print layer to be performed on a "full step" boundary. To
enable this feature be sure the G-Code slicer is configured with a
layer height that is a multiple of a "full step", manually enable
the endstop_align_zero option in the endstop_phase config section
(see config/example-extras.cfg for further details), and then
re-level the bed screws.
* It is possible to use this system with traditional (non-Trinamic)
stepper motor drivers. However, doing this requires making sure that
the stepper motor drivers are reset every time the micro-controller
is reset. (If the two are always reset together then Klipper can
determine the stepper phase by tracking the total number of steps it
has commanded the stepper to move.) Currently, the only way to do
this reliably is if both the micro-controller and stepper motor
drivers are powered solely from USB and that USB power is provided
from a host running on a Raspberry Pi. In this situation one can
specify an mcu config with "restart_method: rpi_usb" - that option
will arrange for the micro-controller to always be reset via a USB
power reset, which would arrange for both the micro-controller and
stepper motor drivers to be reset together. If using this mechanism,
one would then need to manually configure the "endstop_phase" config
sections (see config/example-extras.cfg for the details).

381
docs/FAQ.md
View File

@@ -1,381 +0,0 @@
Frequently asked questions
==========================
1. [How can I donate to the project?](#how-can-i-donate-to-the-project)
2. [How do I calculate the step_distance parameter in the printer config file?](#how-do-i-calculate-the-step_distance-parameter-in-the-printer-config-file)
3. [Where's my serial port?](#wheres-my-serial-port)
4. [When the micro-controller restarts the device changes to /dev/ttyUSB1](#when-the-micro-controller-restarts-the-device-changes-to-devttyusb1)
5. [The "make flash" command doesn't work](#the-make-flash-command-doesnt-work)
6. [How do I change the serial baud rate?](#how-do-i-change-the-serial-baud-rate)
7. [Can I run Klipper on something other than a Raspberry Pi 3?](#can-i-run-klipper-on-something-other-than-a-raspberry-pi-3)
8. [Why can't I move the stepper before homing the printer?](#why-cant-i-move-the-stepper-before-homing-the-printer)
9. [Why is the Z position_endstop set to 0.5 in the default configs?](#why-is-the-z-position_endstop-set-to-05-in-the-default-configs)
10. [I converted my config from Marlin and the X/Y axes work fine, but I just get a screeching noise when homing the Z axis](#i-converted-my-config-from-marlin-and-the-xy-axes-work-fine-but-i-just-get-a-screeching-noise-when-homing-the-z-axis)
11. [My TMC motor driver turns off in the middle of a print](#my-tmc-motor-driver-turns-off-in-the-middle-of-a-print)
12. [I keep getting random "Lost communication with MCU" errors](#i-keep-getting-random-lost-communication-with-mcu-errors)
13. [When I set "restart_method=command" my AVR device just hangs on a restart](#when-i-set-restart_methodcommand-my-avr-device-just-hangs-on-a-restart)
14. [Will the heaters be left on if the Raspberry Pi crashes?](#will-the-heaters-be-left-on-if-the-raspberry-pi-crashes)
15. [How do I convert a Marlin pin number to a Klipper pin name?](#how-do-i-convert-a-marlin-pin-number-to-a-klipper-pin-name)
16. [How do I upgrade to the latest software?](#how-do-i-upgrade-to-the-latest-software)
### How can I donate to the project?
Thanks. Kevin has a Patreon page at: https://www.patreon.com/koconnor
### How do I calculate the step_distance parameter in the printer config file?
If you know the steps per millimeter for the axis then use a
calculator to divide 1.0 by steps_per_mm. Then round this number to
six decimal places and place it in the config (six decimal places is
nano-meter precision).
The step_distance defines the distance that the axis will travel on
each motor driver pulse. It can also be calculated from the axis
pitch, motor step angle, and driver microstepping. If unsure, do a web
search for "calculate steps per mm" to find an online calculator.
### Where's my serial port?
The general way to find a USB serial port is to run `ls -l
/dev/serial/by-id/` from an ssh terminal on the host machine. It will
likely produce output similar to the following:
```
lrwxrwxrwx 1 root root 13 Jun 1 21:12 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB0
```
The name found in the above command is stable and it is possible to
use it in the config file and while flashing the micro-controller
code. For example, a flash command might look similar to:
```
sudo service klipper stop
make flash FLASH_DEVICE=/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
sudo service klipper start
```
and the updated config might look like:
```
[mcu]
serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
```
Be sure to copy-and-paste the name from the "ls" command that you ran
above as the name will be different for each printer.
If you are using multiple micro-controllers and they do not have
unique ids (common on boards with a CH340 USB chip) then follow the
directions above using the directory `/dev/serial/by-path/` instead.
### When the micro-controller restarts the device changes to /dev/ttyUSB1
Follow the directions in the
"[Where's my serial port?](#wheres-my-serial-port)" section to prevent
this from occurring.
### The "make flash" command doesn't work
The code attempts to flash the device using the most common method for
each platform. Unfortunately, there is a lot of variance in flashing
methods, so the "make flash" command may not work on all boards.
If you're having an intermittent failure or you do have a standard
setup, then double check that Klipper isn't running when flashing
(sudo service klipper stop), make sure OctoPrint isn't trying to
connect directly to the device (open the Connection tab in the web
page and click Disconnect if the Serial Port is set to the device),
and make sure FLASH_DEVICE is set correctly for your board (see the
[question above](#wheres-my-serial-port)).
However, if "make flash" just doesn't work for your board, then you
will need to manually flash. See if there is a config file in the
[config directory](../config) with specific instructions for flashing
the device. Also, check the board manufacturer's documentation to see
if it describes how to flash the device. Finally, on AVR devices, it
may be possible to manually flash the device using
[avrdude](http://www.nongnu.org/avrdude/) with custom command-line
parameters - see the avrdude documentation for further information.
### How do I change the serial baud rate?
The recommended baud rate for Klipper is 250000. This baud rate works
well on all micro-controller boards that Klipper supports. If you've
found an online guide recommending a different baud rate, then ignore
that part of the guide and continue with the default value of 250000.
If you want to change the baud rate anyway, then the new rate will
need to be configured in the micro-controller (during **make
menuconfig**) and that updated code will need to be compiled and
flashed to the micro-controller. The Klipper printer.cfg file will
also need to be updated to match that baud rate (see the example.cfg
file for details). For example:
```
[mcu]
baud: 250000
```
The baud rate shown on the OctoPrint web page has no impact on the
internal Klipper micro-controller baud rate. Always set the OctoPrint
baud rate to 250000 when using Klipper.
The Klipper micro-controller baud rate is not related to the baud rate
of the micro-controller's bootloader. See the
[bootloader document](Bootloaders.md) for additional information on
bootloaders.
### Can I run Klipper on something other than a Raspberry Pi 3?
The recommended hardware is a Raspberry Pi 2 or a Raspberry
Pi 3.
Klipper will run on a Raspberry Pi 1 and on the Raspberry Pi Zero, but
these boards don't have enough processing power to run OctoPrint
well. It's not uncommon for print stalls to occur on these slower
machines (the printer may move faster than OctoPrint can send movement
commands) when printing directly from OctoPrint. If you wish to run on
one one of these slower boards anyway, consider using the
"virtual_sdcard" feature (see
[config/example-extras.cfg](../config/example-extras.cfg) for details)
when printing.
For running on the Beaglebone, see the
[Beaglebone specific installation instructions](beaglebone.md).
Klipper has been run on other machines. The Klipper host software
only requires Python running on a Linux (or similar)
computer. However, if you wish to run it on a different machine you
will need Linux admin knowledge to install the system prerequisites
for that particular machine. See the
[install-octopi.sh](../scripts/install-octopi.sh) script for further
information on the necessary Linux admin steps.
### Why can't I move the stepper before homing the printer?
The code does this to reduce the chance of accidentally commanding the
head into the bed or a wall. Once the printer is homed the software
attempts to verify each move is within the position_min/max defined in
the config file. If the motors are disabled (via an M84 or M18
command) then the motors will need to be homed again prior to
movement.
If you want to move the head after canceling a print via OctoPrint,
consider changing the OctoPrint cancel sequence to do that for
you. It's configured in OctoPrint via a web browser under:
Settings->GCODE Scripts
If you want to move the head after a print finishes, consider adding
the desired movement to the "custom g-code" section of your slicer.
If the printer requires some additional movement as part of the homing
process itself (or fundamentally does not have a homing process) then
consider using a homing_override section in the config file. If you
need to move a stepper for diagnostic or debugging purposes then
consider adding a force_move section to the config file. See
[example-extras.cfg](../config/example-extras.cfg) for further details
on these options.
### Why is the Z position_endstop set to 0.5 in the default configs?
For cartesian style printers the Z position_endstop specifies how far
the nozzle is from the bed when the endstop triggers. If possible, it
is recommended to use a Z-max endstop and home away from the bed (as
this reduces the potential for bed collisions). However, if one must
home towards the bed then it is recommended to position the endstop so
it triggers when the nozzle is still a small distance away from the
bed. This way, when homing the axis, it will stop before the nozzle
touches the bed.
Almost all mechanical switches can still move a small distance
(eg, 0.5mm) after they are triggered. So, for example, if the
position_endstop is set to 0.5mm then one may still command the
printer to move to Z0.2. The position_min config setting (which
defaults to 0) is used to specify the minimum Z position one may
command the printer to move to.
Note, the Z position_endstop specifies the distance from the nozzle to
the bed when the nozzle and bed (if applicable) are hot. It is typical
for thermal expansion to cause nozzle expansion of around .1mm, which
is also the typical thickness of a sheet of printer paper. Thus, it is
common to use the "paper test" to confirm calibration of the Z
height - check that the bed and nozzle are at room temperature, check
that there is no plastic on the head or bed, home the printer, place a
piece of paper between the nozzle and bed, and repeatedly command the
head to move closer to the bed checking each time if you feel a small
amount of friction when sliding the paper between bed and nozzle - if
all is calibrated well a small amount of friction would be felt when
the height is at Z0.
### I converted my config from Marlin and the X/Y axes work fine, but I just get a screeching noise when homing the Z axis
Short answer: Try reducing the max_z_velocity setting in the printer
config. Also, if the Z stepper is moving in the wrong direction, try
inverting the dir_pin setting in the config (eg, "dir_pin: !xyz"
instead of "dir_pin: xyz").
Long answer: In practice Marlin can typically only step at a rate of
around 10000 steps per second. If it is requested to move at a speed
that would require a higher step rate then Marlin will generally just
step as fast as it can. Klipper is able to achieve much higher step
rates, but the stepper motor may not have sufficient torque to move at
a higher speed. So, for a Z axis with a very precise step_distance the
actual obtainable max_z_velocity may be smaller than what is
configured in Marlin.
### My TMC motor driver turns off in the middle of a print
There have been reports of some TMC drivers being disabled in the
middle of a print. (In particular, with the TMC2208 driver.) When this
issue occurs, the stepper associated with the driver moves freely,
while the print continues.
It is believed this may be due to "over current" detection within the
TMC driver. Trinamic has indicated that this could occur if the driver
is in "stealthChop mode" and an abrupt velocity change occurs. If you
experience this problem during homing, consider using a slower homing
speed. If you experience this problem in the middle of a print,
consider using a lower square_corner_velocity setting.
### I keep getting random "Lost communication with MCU" errors
This is commonly caused by hardware errors on the USB connection
between the host machine and the micro-controller. Things to look for:
- Use a good quality USB cable between the host machine and
micro-controller. Make sure the plugs are secure.
- If using a Raspberry Pi, use a good quality power supply for the
Raspberry Pi and use a good quality USB cable to connect that power
supply to the Pi.
- Make sure the printer's power supply is not being overloaded. (Power
fluctuations to the micro-controller's USB chip may result in resets
of that chip.)
- There have been reports of high USB noise when both the printer's
power supply and the host's 5V power supply are mixed. (If you find
that the micro-controller powers on when either the printer's power
supply is on or the USB cable is plugged in, then it indicates the
5V power supplies are being mixed.) It may help to configure the
micro-controller to use power from only one source. (Alternatively,
if the micro-controller board can not configure its power source,
one may modify a USB cable so that it does not carry 5V power
between the host and micro-controller.)
### When I set "restart_method=command" my AVR device just hangs on a restart
Some old versions of the AVR bootloader have a known bug in watchdog
event handling. This typically manifests when the printer.cfg file has
restart_method set to "command". When the bug occurs, the AVR device
will be unresponsive until power is removed and reapplied to the
device (the power or status LEDs may also blink repeatedly until the
power is removed).
The workaround is to use a restart_method other than "command" or to
flash an updated bootloader to the AVR device. Flashing a new
bootloader is a one time step that typically requires an external
programmer - search the web to find the instructions for your
particular device.
### Will the heaters be left on if the Raspberry Pi crashes?
The software has been designed to prevent that. Once the host enables
a heater, the host software needs to confirm that enablement every 5
seconds. If the micro-controller does not receive a confirmation every
5 seconds it goes into a "shutdown" state which is designed to turn
off all heaters and stepper motors.
See the "config_digital_out" command in the
[MCU commands](MCU_Commands.md) document for further details.
In addition, the micro-controller software is configured with a
minimum and maximum temperature range for each heater at startup (see
the min_temp and max_temp parameters in the
[example.cfg](../config/example.cfg) file for details). If the
micro-controller detects that the temperature is outside of that range
then it will also enter a "shutdown" state.
Separately, the host software also implements code to check that
heaters and temperature sensors are functioning correctly. See the
"verify_heater" section of the
[example-extras.cfg](../config/example-extras.cfg) for further
details.
### How do I convert a Marlin pin number to a Klipper pin name?
Short answer: In some cases one can use Klipper's `pin_map: arduino`
feature. Otherwise, for "digital" pins, one method is to search for
the requested pin in Marlin's fastio header files. The Atmega2560 and
Atmega1280 chips use
[fastio_1280.h](https://github.com/MarlinFirmware/Marlin/blob/1.1.9/Marlin/fastio_1280.h),
while the Atmega644p and Atmega1284p chips use
[fastio_644.h](https://github.com/MarlinFirmware/Marlin/blob/1.1.9/Marlin/fastio_644.h).
For example, if you are looking to translate Marlin's digital pin
number 23 on an atmega2560 then one could find the following line in
Marlin's fastio_1280.h file:
```
#define DIO23_PIN PINA1
```
The `DIO23` indicates the line is for Marlin's pin 23 and the `PINA1`
indicates the pin uses the hardware name of `PA1`. Klipper uses the
hardware names (eg, `PA1`).
Long answer: Klipper uses the standard pin names defined by the
micro-controller. On the Atmega chips these hardware pins have names
like `PA4`, `PC7`, or `PD2`.
Long ago, the Arduino project decided to avoid using the standard
hardware names in favor of their own pin names based on incrementing
numbers - these Arduino names generally look like `D23` or `A14`. This
was an unfortunate choice that has lead to a great deal of confusion.
In particular the Arduino pin numbers frequently don't translate to
the same hardware names. For example, `D21` is `PD0` on one common
Arduino board, but is `PC7` on another common Arduino board.
In order to support 3d printers based on real Arduino boards, Klipper
supports the Arduino pin aliases. This feature is enabled by adding
`pin_map: arduino` to the [mcu] section of the config file. When these
aliases are enabled, Klipper understands pin names that start with the
prefix "ar" (eg, Arduino pin `D23` is Klipper alias `ar23`) and the
prefix "analog" (eg, Arduino pin `A14` is Klipper alias `analog14`).
Klipper does not use the Arduino names directly because we feel a name
like D7 is too easily confused with the hardware name PD7.
Marlin primarily follows the Arduino pin numbering scheme. However,
Marlin supports a few chips that Arduino does not support and in some
cases it supports pins that Arduino boards do not expose. In these
cases, Marlin chose their own pin numbering scheme. Klipper does not
support these custom pin numbers - check Marlin's fastio headers (see
above) to translate these pin numbers to their standard hardware
names.
### How do I upgrade to the latest software?
The general way to upgrade is to ssh into the Raspberry Pi and run:
```
cd ~/klipper
git pull
~/klipper/scripts/install-octopi.sh
```
Then one can recompile and flash the micro-controller code. For
example:
```
make menuconfig
make clean
make
sudo service klipper stop
make flash FLASH_DEVICE=/dev/ttyACM0
sudo service klipper start
```
However, it's often the case that only the host software changes. In
this case, one can update and restart just the host software with:
```
cd ~/klipper
git pull
sudo service klipper restart
```
If after using this shortcut the software warns about needing to
reflash the micro-controller or some other unusual error occurs, then
follow the full upgrade steps outlined above. Note that the RESTART
and FIRMWARE_RESTART g-code commands do not load new software - the
above "sudo service klipper restart" and "make flash" commands are
needed for a software change to take effect.

146
docs/Features.md
View File

@@ -1,146 +0,0 @@
Klipper has several compelling features:
* High precision stepper movement. Klipper utilizes an application
processor (such as a low-cost Raspberry Pi) when calculating printer
movements. The application processor determines when to step each
stepper motor, it compresses those events, transmits them to the
micro-controller, and then the micro-controller executes each event
at the requested time. Each stepper event is scheduled with a
precision of 25 micro-seconds or better. The software does not use
kinematic estimations (such as the Bresenham algorithm) - instead it
calculates precise step times based on the physics of acceleration
and the physics of the machine kinematics. More precise stepper
movement translates to quieter and more stable printer operation.
* Best in class performance. Klipper is able to achieve high stepping
rates on both new and old micro-controllers. Even an old 8bit AVR
micro-controller can obtain rates over 175K steps per second. On
more recent micro-controllers, rates over 500K steps per second are
possible. Higher stepper rates enable higher print velocities. The
stepper event timing remains precise even at high speeds which
improves overall stability.
* Klipper supports printers with multiple micro-controllers. For
example, one micro-controller could be used to control an extruder,
while another controls the printer's heaters, while a third controls
the rest of the printer. The Klipper host software implements clock
synchronization to account for clock drift between
micro-controllers. No special code is needed to enable multiple
micro-controllers - it just requires a few extra lines in the config
file.
* Configuration via simple config file. There's no need to reflash the
micro-controller to change a setting. All of Klipper's configuration
is stored in a standard config file which can be easily edited. This
makes it easier to setup and maintain the hardware.
* Portable code. Klipper works on ARM, AVR, and PRU based
micro-controllers. Existing "reprap" style printers can run Klipper
without hardware modification - just add a Raspberry Pi. Klipper's
internal code layout makes it easier to support other
micro-controller architectures as well.
* Simpler code. Klipper uses a very high level language (Python) for
most code. The kinematics algorithms, the G-code parsing, the
heating and thermistor algorithms, etc. are all written in Python.
This makes it easier to develop new functionality.
* Klipper uses an "iterative solver" to calculate precise step times
from simple kinematic equations. This makes porting Klipper to new
types of robots easier and it keeps timing precise even with complex
kinematics (no "line segmentation" is needed).
Additional features
===================
Klipper supports many standard 3d printer features:
* Klipper implements the "pressure advance" algorithm for extruders.
When properly tuned, pressure advance reduces extruder ooze.
* Works with Octoprint. This allows the printer to be controlled using
a regular web-browser. The same Raspberry Pi that runs Klipper can
also run Octoprint.
* Standard G-Code support. Common g-code commands that are produced by
typical "slicers" are supported. One may continue to use Slic3r,
Cura, etc. with Klipper.
* Support for multiple extruders. Extruders with shared heaters and
extruders on independent carriages (IDEX) are also supported.
* Support for cartesian, delta, and corexy style printers.
* Automatic bed leveling support. Klipper can be configured for basic
bed tilt detection or full mesh bed leveling. If the bed uses
multiple Z steppers then Klipper can also level by independently
manipulating the Z steppers. Most Z height probes are supported,
including servo activated probes.
* Automatic delta calibration support. The calibration tool can
perform basic height calibration as well as an enhanced X and Y
dimension calibration. The calibration can be done with a Z height
probe or via manual probing.
* Support for common temperature sensors (eg, common thermistors,
AD595, PT100, MAX6675, MAX31855, MAX31856, MAX31865). Custom
thermistors and custom analog temperature sensors can also be
configured.
* Basic thermal heater protection enabled by default.
* Support for standard fans, nozzle fans, and temperature controlled
fans. No need to keep fans running when the printer is idle.
* Support for run-time configuration of TMC2130, TMC2208, TMC2224, and
TMC2660 stepper motor drivers. There is also support for current
control of traditional stepper drivers via AD5206 and MCP4451
digipots.
* Support for common LCD displays attached directly to the printer. A
default menu is also available.
* Constant acceleration and "look-ahead" support. All printer moves
will gradually accelerate from standstill to cruising speed and then
decelerate back to a standstill. The incoming stream of G-Code
movement commands are queued and analyzed - the acceleration between
movements in a similar direction will be optimized to reduce print
stalls and improve overall print time.
* Klipper implements a "stepper phase endstop" algorithm that can
improve the accuracy of typical endstop switches. When properly
tuned it can improve a print's first layer bed adhesion.
* Support for limiting the top speed of short "zigzag" moves to reduce
printer vibration and noise. See the [kinematics](Kinematics.md)
document for more information.
* Sample configuration files are available for many common printers.
Check the [config directory](../config/) for a list.
To get started with Klipper, read the [installation](Installation.md)
guide.
Step Benchmarks
===============
Below are the results of stepper performance tests. The numbers shown
represent total number of steps per second on the micro-controller.
| Micro-controller | Fastest step rate | 3 steppers active |
| --------------------------- | ----------------- | ----------------- |
| 16Mhz AVR | 151K | 100K |
| 20Mhz AVR | 189K | 125K |
| Arduino Zero (ARM SAMD21) | 234K | 217K |
| STM32F103 | 333K | 300K |
| Arduino Due (ARM SAM3X8E) | 410K | 397K |
| Smoothieboard (ARM LPC1768) | 487K | 487K |
| Smoothieboard (ARM LPC1769) | 584K | 584K |
| SAM4E8E ARM | 638K | 638K |
| Beaglebone PRU | 680K | 680K |
On AVR platforms, the highest achievable step rate is with just one
stepper stepping. On the STM32F103, Arduino Zero, and Due, the highest
step rate is with two simultaneous steppers stepping. On the PRU,
SAM4E8E, and LPC176x the highest step rate is with three simultaneous
steppers.

275
docs/G-Codes.md
View File

@@ -1,275 +0,0 @@
This document describes the commands that Klipper supports. These are
commands that one may enter into the OctoPrint terminal tab.
# G-Code commands
Klipper supports the following standard G-Code commands:
- Move (G0 or G1): `G1 [X<pos>] [Y<pos>] [Z<pos>] [E<pos>] [F<speed>]`
- Dwell: `G4 P<milliseconds>`
- Move to origin: `G28 [X] [Y] [Z]`
- Turn off motors: `M18` or `M84`
- Wait for current moves to finish: `M400`
- Select tool: `T<index>`
- Use absolute/relative distances for extrusion: `M82`, `M83`
- Use absolute/relative coordinates: `G90`, `G91`
- Set position: `G92 [X<pos>] [Y<pos>] [Z<pos>] [E<pos>]`
- Set speed factor override percentage: `M220 S<percent>`
- Set extrude factor override percentage: `M221 S<percent>`
- Set acceleration: `M204 S<value>`
- Get extruder temperature: `M105`
- Set extruder temperature: `M104 [T<index>] [S<temperature>]`
- Set extruder temperature and wait: `M109 [T<index>] S<temperature>`
- Note: M109 always waits for temperature to settle at requested
value
- Set bed temperature: `M140 [S<temperature>]`
- Set bed temperature and wait: `M190 S<temperature>`
- Note: M190 always waits for temperature to settle at requested
value
- Set fan speed: `M106 S<value>`
- Turn fan off: `M107`
- Emergency stop: `M112`
- Get current position: `M114`
- Get firmware version: `M115`
For further details on the above commands see the
[RepRap G-Code documentation](http://reprap.org/wiki/G-code).
Klipper's goal is to support the G-Code commands produced by common
3rd party software (eg, OctoPrint, Printrun, Slic3r, Cura, etc.) in
their standard configurations. It is not a goal to support every
possible G-Code command. Instead, Klipper prefers human readable
["extended G-Code commands"](#extended-g-code-commands).
If one requires a less common G-Code command then it may be possible
to implement it with a custom Klipper gcode_macro (see
[example-extras.cfg](../config/example-extras.cfg) for details). For
example, one might use this to implement: `G10`, `G11`, `G12`, `G29`,
`G30`, `G31`, `M42`, `M80`, `M81`, etc.
## G-Code SD card commands
Klipper also supports the following standard G-Code commands if the
"virtual_sdcard" config section is enabled:
- List SD card: `M20`
- Initialize SD card: `M21`
- Select SD file: `M23 <filename>`
- Start/resume SD print: `M24`
- Pause SD print: `M25`
- Set SD position: `M26 S<offset>`
- Report SD print status: `M27`
## G-Code display commands
The following standard G-Code commands are available if a "display"
config section is enabled:
- Display Message: `M117 <message>`
- Set build percentage: `M73 P<percent>`
## Other available G-Code commands
The following standard G-Code commands are currently available, but
using them is not recommended:
- Offset axes: `M206 [X<offset>] [Y<offset>] [Z<offset>]` (Use
SET_GCODE_OFFSET instead.)
- Get Endstop Status: `M119` (Use QUERY_ENDSTOPS instead.)
# Extended G-Code Commands
Klipper uses "extended" G-Code commands for general configuration and
status. These extended commands all follow a similar format - they
start with a command name and may be followed by one or more
parameters. For example: `SET_SERVO SERVO=myservo ANGLE=5.3`. In this
document, the commands and parameters are shown in uppercase, however
they are not case sensitive. (So, "SET_SERVO" and "set_servo" both run
the same command.)
The following standard commands are supported:
- `QUERY_ENDSTOPS`: Probe the axis endstops and report if they are
"triggered" or in an "open" state. This command is typically used to
verify that an endstop is working correctly.
- `GET_POSITION`: Return information on the current location of the
toolhead.
- `SET_GCODE_OFFSET [X=<pos>|X_ADJUST=<adjust>]
[Y=<pos>|Y_ADJUST=<adjust>] [Z=<pos>|Z_ADJUST=<adjust>]`: Set a
positional offset to apply to future G-Code commands. This is
commonly used to virtually change the Z bed offset or to set nozzle
XY offsets when switching extruders. For example, if
"SET_GCODE_OFFSET Z=0.2" is sent, then future G-Code moves will
have 0.2mm added to their Z height. If the X_ADJUST style parameters
are used, then the adjustment will be added to any existing offset
(eg, "SET_GCODE_OFFSET Z=-0.2" followed by "SET_GCODE_OFFSET
Z_ADJUST=0.3" would result in a total Z offset of 0.1).
- `PID_CALIBRATE HEATER=<config_name> TARGET=<temperature>
[WRITE_FILE=1]`: Perform a PID calibration test. The specified
heater will be enabled until the specified target temperature is
reached, and then the heater will be turned off and on for several
cycles. If the WRITE_FILE parameter is enabled, then the file
/tmp/heattest.txt will be created with a log of all temperature
samples taken during the test.
- `TURN_OFF_HEATERS`: Turn off all heaters.
- `SET_VELOCITY_LIMIT [VELOCITY=<value>] [ACCEL=<value>]
[ACCEL_TO_DECEL=<value>] [SQUARE_CORNER_VELOCITY=<value>]`: Modify
the printer's velocity limits. Note that one may only set values
less than or equal to the limits specified in the config file.
- `SET_PRESSURE_ADVANCE [EXTRUDER=<config_name>] [ADVANCE=<pressure_advance>]
[ADVANCE_LOOKAHEAD_TIME=<pressure_advance_lookahead_time>]`:
Set pressure advance parameters. If EXTRUDER is not specified, it
defaults to the active extruder.
- `STEPPER_BUZZ STEPPER=<config_name>`: Move the given stepper forward
one mm and then backward one mm, repeated 10 times. This is a
diagnostic tool to help verify stepper connectivity.
- `RESTART`: This will cause the host software to reload its config
and perform an internal reset. This command will not clear error
state from the micro-controller (see FIRMWARE_RESTART) nor will it
load new software (see
[the FAQ](FAQ.md#how-do-i-upgrade-to-the-latest-software)).
- `FIRMWARE_RESTART`: This is similar to a RESTART command, but it
also clears any error state from the micro-controller.
- `SAVE_CONFIG`: This command will overwrite the main printer config
file and restart the host software. This command is used in
conjunction with other calibration commands to store the results of
calibration tests.
- `STATUS`: Report the Klipper host software status.
- `HELP`: Report the list of available extended G-Code commands.
## Custom Pin Commands
The following command is available when an "output_pin" config section
is enabled:
- `SET_PIN PIN=config_name VALUE=<value>`
## Servo Commands
The following commands are available when a "servo" config section is
enabled:
- `SET_SERVO SERVO=config_name [WIDTH=<seconds>] [ENABLE=<0|1>]`
- `SET_SERVO SERVO=config_name [ANGLE=<degrees>] [ENABLE=<0|1>]`
## Probe
The following commands are available when a "probe" config section is
enabled:
- `PROBE`: Move the nozzle downwards until the probe triggers.
- `QUERY_PROBE`: Report the current status of the probe ("triggered"
or "open").
## BLTouch
The following command is available when a "bltouch" config section is
enabled:
- `BLTOUCH_DEBUG COMMAND=<command>`: This sends a command to the
BLTouch. It may be useful for debugging. Available commands are:
pin_down, touch_mode, pin_up, self_test, reset.
## Delta Calibration
The following commands are available when the "delta_calibrate" config
section is enabled:
- `DELTA_CALIBRATE [METHOD=manual]`: This command will probe seven
points on the bed and recommend updated endstop positions, tower
angles, and radius.
- `NEXT`: If manual bed probing is enabled, then one can use this
command to move to the next probing point during a DELTA_CALIBRATE
operation.
- `DELTA_ANALYZE`: This command is used during enhanced delta
calibration. See [Delta Calibrate](Delta_Calibrate.md) for details.
## Bed Tilt
The following commands are available when the "bed_tilt" config
section is enabled:
- `BED_TILT_CALIBRATE [METHOD=manual]`: This command will probe the
points specified in the config and then recommend updated x and y
tilt adjustments.
- `NEXT`: If manual bed probing is enabled, then one can use this
command to move to the next probing point during a
BED_TILT_CALIBRATE operation.
## Mesh Bed Leveling
The following commands are available when the "bed_mesh" config
section is enabled:
- `BED_MESH_CALIBRATE [METHOD=manual]`: This command probes the bed
using generated points specified by the parameters in the
config. After probing, a mesh is generated and z-movement is
adjusted according to the mesh.
- `NEXT`: If manual bed probing is enabled, then one can use this
command to move to the next probing point during a
BED_MESH_CALIBRATE operation.
- `BED_MESH_OUTPUT`: This command outputs the current probed z values
and current mesh values to the terminal.
- `BED_MESH_MAP`: This command probes the bed in a similar fashion
to BED_MESH_CALIBRATE, however no mesh is generated. Instead,
the probed z values are serialized to json and output to the
terminal. This allows octoprint plugins to easily capture the
data and generate maps approximating the bed's surface. Note
that although no mesh is generated, any currently stored mesh
will be cleared.
- `BED_MESH_CLEAR`: This command clears the mesh and removes all
z adjustment. It is recommended to put this in your end-gcode.
- `BED_MESH_PROFILE LOAD=<name> SAVE=<name> REMOVE=<name>`: This
command provides profile management for mesh state. LOAD will
restore the mesh state from the profile matching the supplied name.
SAVE will save the current mesh state to a profile matching the
supplied name. Remove will delete the profile matching the
supplied name from persistent memory. Note that after SAVE or
REMOVE operations have been run the SAVE_CONFIG gcode must be run
to make the changes to peristent memory permanent.
## Z Tilt
The following commands are available when the "z_tilt" config section
is enabled:
- `Z_TILT_ADJUST`: This command will probe the points specified in the
config and then make independent adjustments to each Z stepper to
compensate for tilt.
## Dual Carriages
The following command is available when the "dual_carriage" config
section is enabled:
- `SET_DUAL_CARRIAGE CARRIAGE=[0|1]`: This command will set the active
carriage. It is typically invoked from the activate_gcode and
deactivate_gcode fields in a multiple extruder configuration.
## TMC2130
The following command is available when the "tmc2130" config section
is enabled:
- `DUMP_TMC STEPPER=<name>`: This command will read the TMC2130 driver
registers and report their values.
## Endstop adjustments by stepper phase
The following commands are available when an "endstop_phase" config
section is enabled:
- `ENDSTOP_PHASE_CALIBRATE [STEPPER=<config_name>]`: If no STEPPER
parameter is provided then this command will reports statistics on
endstop stepper phases during past homing operations. When a STEPPER
parameter is provided it arranges for the given endstop phase
setting to be written to the config file (in conjunction with the
SAVE_CONFIG command).
## Force movement
The following commands are available when the "force_move" config
section is enabled:
- `FORCE_MOVE STEPPER=<config_name> DISTANCE=<value>
VELOCITY=<value>`: This command will forcibly move the given stepper
the given distance (in mm) at the given constant velocity (in
mm/s). No acceleration is performed; no boundary checks are
performed; no kinematic updates are made; other parallel steppers on
an axis will not be moved. Use caution as an incorrect command could
cause damage! Using this command will almost certainly place the
low-level kinematics in an incorrect state; issue a G28 afterwards
to reset the kinematics. This command is intended for low-level
diagnostics and debugging.
- `SET_KINEMATIC_POSITION [X=<value>] [Y=<value>] [Z=<value>]`: Force
the low-level kinematic code to believe the toolhead is at the given
cartesian position. This is a diagnostic and debugging command; use
SET_GCODE_OFFSET and/or G92 for regular axis transformations. If an
axis is not specified then it will default to the position that the
head was last commanded to. Setting an incorrect or invalid position
may lead to internal software errors. This command may invalidate
future boundary checks; issue a G28 afterwards to reset the
kinematics.

159
docs/Installation.md
View File

@@ -1,159 +0,0 @@
These instructions assume the software will run on a Raspberry Pi
computer in conjunction with OctoPrint. It is recommended that a
Raspberry Pi 2 or Raspberry Pi 3 computer be used as the host machine
(see the
[FAQ](FAQ.md#can-i-run-klipper-on-something-other-than-a-raspberry-pi-3)
for other machines).
Klipper currently supports Atmel ATmega based micro-controllers,
Arduino Due (Atmel SAM3x8e ARM micro-controller), Smoothieboard (ARM
LPC176x), and [Beaglebone PRU](beaglebone.md) based printers.
Prepping an OS image
====================
Start by installing [OctoPi](https://github.com/guysoft/OctoPi) on the
Raspberry Pi computer. Use OctoPi v0.14.0 or later - see the
[octopi releases](https://github.com/guysoft/OctoPi/releases) for
release information. One should verify that OctoPi boots and that the
OctoPrint web server works. After connecting to the OctoPrint web
page, follow the prompt to upgrade OctoPrint to v1.3.7 or later.
After installing OctoPi and upgrading OctoPrint, it will be necessary
to ssh into the target machine to run a handful of system commands. If
using a Linux or MacOS desktop, then the "ssh" software should already
be installed on the desktop. There are free ssh clients available for
other desktops (eg,
[PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/)). Use the
ssh utility to connect to the Raspberry Pi (ssh pi@octopi -- password
is "raspberry") and run the following commands:
```
git clone https://github.com/KevinOConnor/klipper
./klipper/scripts/install-octopi.sh
```
The above will download Klipper, install some system dependencies,
setup Klipper to run at system startup, and start the Klipper host
software. It will require an internet connection and it may take a few
minutes to complete.
Building and flashing the micro-controller
==========================================
To compile the micro-controller code, start by running these commands
on the Raspberry Pi:
```
cd ~/klipper/
make menuconfig
```
Select the appropriate micro-controller and review any other options
provided. For boards with serial ports, the recommended baud rate is
250000 (see the [FAQ](FAQ.md#how-do-i-change-the-serial-baud-rate)
before changing). Once configured, run:
```
make
```
Finally, for common micro-controllers, the code can be flashed with:
```
sudo service klipper stop
make flash FLASH_DEVICE=/dev/ttyACM0
sudo service klipper start
```
When flashing for the first time, make sure that OctoPrint is not
connected directly to the printer (from the OctoPrint web page, under
the "Connection" section, click "Disconnect"). The most common
communication device is **/dev/ttyACM0** - see the
[FAQ](FAQ.md#wheres-my-serial-port) for other possibilities.
Configuring OctoPrint to use Klipper
====================================
The OctoPrint web server needs to be configured to communicate with
the Klipper host software. Using a web browser, login to the OctoPrint
web page, and navigate to the Settings tab. Then configure the
following items:
Under "Serial Connection" in "Additional serial ports" add
"/tmp/printer". Then click "Save".
Enter the Settings tab again and under "Serial Connection" change the
"Serial Port" setting to "/tmp/printer". Navigate to the "Behavior"
sub-tab and select the "Cancel any ongoing prints but stay connected
to the printer" option. Click "Save".
From the main page, under the "Connection" section (at the top left of
the page) make sure the "Serial Port" is set to "/tmp/printer" and
click "Connect". (If "/tmp/printer" is not an available selection then
try reloading the page.)
Once connected, navigate to the "Terminal" tab and type "status"
(without the quotes) into the command entry box and click "Send". The
terminal window will likely report there is an error opening the
config file - that means OctoPrint is successfully communicating with
Klipper. Proceed to the next section.
Configuring Klipper
===================
The Klipper configuration is stored in a text file on the Raspberry
Pi. Take a look at the example config files in the
[config directory](../config/). The
[example.cfg](../config/example.cfg) file contains documentation on
command parameters and it can also be used as an initial config file
template. However, for most printers, one of the other config files
may be a more concise starting point.
Arguably the easiest way to update the Klipper configuration file is
to use a desktop editor that supports editing files over the "scp"
and/or "sftp" protocols. There are freely available tools that support
this (eg, Notepad++, WinSCP, and Cyberduck). Use one of the example
config files as a starting point and save it as a file named
"printer.cfg" in the home directory of the pi user (ie,
/home/pi/printer.cfg).
Alternatively, one can also copy and edit the file directly on the
Raspberry Pi via ssh - for example:
```
cp ~/klipper/config/example.cfg ~/printer.cfg
nano ~/printer.cfg
```
Make sure to review and update each setting that is appropriate for
the hardware.
After creating and editing the file it will be necessary to issue a
"restart" command in the OctoPrint web terminal to load the config. A
"status" command will report the printer is ready if the Klipper
config file is successfully read and the micro-controller is
successfully found and configured. It is not unusual to have
configuration errors during the initial setup - update the printer
config file and issue "restart" until "status" reports the printer is
ready.
Klipper reports error messages via the OctoPrint terminal tab. The
"status" command can be used to re-report error messages. The default
Klipper startup script also places a log in **/tmp/klippy.log** which
provides more detailed information.
In addition to common g-code commands, Klipper supports a few extended
commands - "status" and "restart" are examples of these commands. Use
the "help" command to get a list of other extended commands.
After Klipper reports that the printer is ready go on to the
[config check document](Config_checks.md) to perform some basic checks
on the pin definitions in the config file.
Contacting the developers
=========================
Be sure to see the [FAQ](FAQ.md) for answers to some common questions.
See the [contact page](Contact.md) to report a bug or to contact the
developers.

302
docs/Kinematics.md
View File

@@ -1,302 +0,0 @@
This document provides an overview of how Klipper implements robot
motion (its [kinematics](https://en.wikipedia.org/wiki/Kinematics)).
The contents may be of interest to both developers interested in
working on the Klipper software as well as users interested in better
understanding the mechanics of their machines.
Acceleration
============
Klipper implements a constant acceleration scheme whenever the print
head changes velocity - the velocity is gradually changed to the new
speed instead of suddenly jerking to it. Klipper always enforces
acceleration between the tool head and the print. The filament leaving
the extruder can be quite fragile - rapid jerks and/or extruder flow
changes lead to poor quality and poor bed adhesion. Even when not
extruding, if the print head is at the same level as the print then
rapid jerking of the head can cause disruption of recently deposited
filament. Limiting speed changes of the print head (relative to the
print) reduces risks of disrupting the print.
It is also important to limit acceleration so that the stepper motors
do not skip or put excessive stress on the machine. Klipper limits the
torque on each stepper by virtue of limiting the acceleration of the
print head. Enforcing acceleration at the print head naturally also
limits the torque of the steppers that move the print head (the
inverse is not always true).
Klipper implements constant acceleration. The key formula for constant
acceleration is:
```
velocity(time) = start_velocity + accel*time
```
Trapezoid generator
===================
Klipper uses a traditional "trapezoid generator" to model the motion
of each move - each move has a start speed, it accelerates to a
cruising speed at constant acceleration, it cruises at a constant
speed, and then decelerates to the end speed using constant
acceleration.
![trapezoid](img/trapezoid.svg.png)
It's called a "trapezoid generator" because a velocity diagram of the
move looks like a trapezoid.
The cruising speed is always greater than or equal to both the start
speed and the end speed. The acceleration phase may be of zero
duration (if the start speed is equal to the cruising speed), the
cruising phase may be of zero duration (if the move immediately starts
decelerating after acceleration), and/or the deceleration phase may be
of zero duration (if the end speed is equal to the cruising speed).
![trapezoids](img/trapezoids.svg.png)
Look-ahead
==========
The "look-ahead" system is used to determine cornering speeds between
moves.
Consider the following two moves contained on an XY plane:
![corner](img/corner.svg.png)
In the above situation it is possible to fully decelerate after the
first move and then fully accelerate at the start of the next move,
but that is not ideal as all that acceleration and deceleration would
greatly increase the print time and the frequent changes in extruder
flow would result in poor print quality.
To solve this, the "look-ahead" mechanism queues multiple incoming
moves and analyzes the angles between moves to determine a reasonable
speed that can be obtained during the "junction" between two moves. If
the next move is nearly in the same direction then the head need only
slow down a little (if at all).
![lookahead](img/lookahead.svg.png)
However, if the next move forms an acute angle (the head is going to
travel in nearly a reverse direction on the next move) then only a
small junction speed is permitted.
![lookahead](img/lookahead-slow.svg.png)
The junction speeds are determined using "approximated centripetal
acceleration". Best
[described by the author](https://onehossshay.wordpress.com/2011/09/24/improving_grbl_cornering_algorithm/).
However, in Klipper, junction speeds are configured by specifying the
desired speed that a 90° corner should have (the "square corner
velocity"), and the junction speeds for other angles are derived from
that.
Klipper implements look-ahead between moves that have similar extruder
flow rates. Other moves are relatively rare and implementing
look-ahead between them is unnecessary.
Key formula for look-ahead:
```
end_velocity^2 = start_velocity^2 + 2*accel*move_distance
```
Smoothed look-ahead
-------------------
Klipper also implements a mechanism for smoothing out the motions of
short "zigzag" moves. Consider the following moves:
![zigzag](img/zigzag.svg.png)
In the above, the frequent changes from acceleration to deceleration
can cause the machine to vibrate which causes stress on the machine
and increases the noise. To reduce this, Klipper tracks both regular
move acceleration as well as a virtual "acceleration to deceleration"
rate. Using this system, the top speed of these short "zigzag" moves
are limited to smooth out the printer motion:
![smoothed](img/smoothed.svg.png)
Specifically, the code calculates what the velocity of each move would
be if it were limited to this virtual "acceleration to deceleration"
rate (half the normal acceleration rate by default). In the above
picture the dashed gray lines represent this virtual acceleration rate
for the first move. If a move can not reach its full cruising speed
using this virtual acceleration rate then its top speed is reduced to
the maximum speed it could obtain at this virtual acceleration
rate. For most moves the limit will be at or above the move's existing
limits and no change in behavior is induced. For short zigzag moves,
however, this limit reduces the top speed. Note that it does not
change the actual acceleration within the move - the move continues to
use the normal acceleration scheme up to its adjusted top-speed.
Generating steps
================
Once the look-ahead process completes, the print head movement for the
given move is fully known (time, start position, end position,
velocity at each point) and it is possible to generate the step times
for the move. This process is done within "kinematic classes" in the
Klipper code. Outside of these kinematic classes, everything is
tracked in millimeters, seconds, and in cartesian coordinate space.
It's the task of the kinematic classes to convert from this generic
coordinate system to the hardware specifics of the particular printer.
Klipper uses an
[iterative solver](https://en.wikipedia.org/wiki/Root-finding_algorithm)
to generate the step times for each stepper. The code contains the
formulas to calculate the ideal cartesian coordinates of the head at
each moment in time, and it has the kinematic formulas to calculate
the ideal stepper positions based on those cartesian coordinates. With
these formulas, Klipper can determine the ideal time that the stepper
should be at each step position. The given steps are then scheduled at
these calculated times.
The key formula to determine how far a move should travel under
constant acceleration is:
```
move_distance = (start_velocity + .5 * accel * move_time) * move_time
```
and the key formula for movement with constant velocity is:
```
move_distance = cruise_velocity * move_time
```
The key formulas for determining the cartesian coordinate of a move
given a move distance is:
```
cartesian_x_position = start_x + move_distance * total_x_movement / total_movement
cartesian_y_position = start_y + move_distance * total_y_movement / total_movement
cartesian_z_position = start_z + move_distance * total_z_movement / total_movement
```
Cartesian Robots
----------------
Generating steps for cartesian printers is the simplest case. The
movement on each axis is directly related to the movement in cartesian
space.
Key formulas:
```
stepper_x_position = cartesian_x_position
stepper_y_position = cartesian_y_position
stepper_z_position = cartesian_z_position
```
CoreXY Robots
----------------
Generating steps on a CoreXY machine is only a little more complex
than basic cartesian robots. The key formulas are:
```
stepper_a_position = cartesian_x_position + cartesian_y_position
stepper_b_position = cartesian_x_position - cartesian_y_position
stepper_z_position = cartesian_z_position
```
Delta Robots
------------
Step generation on a delta robot is based on Pythagoras's theorem:
```
stepper_position = (sqrt(arm_length^2
- (cartesian_x_position - tower_x_position)^2
- (cartesian_y_position - tower_y_position)^2)
+ cartesian_z_position)
```
### Stepper motor acceleration limits ###
With delta kinematics it is possible for a move that is accelerating
in cartesian space to require an acceleration on a particular stepper
motor greater than the move's acceleration. This can occur when a
stepper arm is more horizontal than vertical and the line of movement
passes near that stepper's tower. Although these moves could require a
stepper motor acceleration greater than the printer's maximum
configured move acceleration, the effective mass moved by that stepper
would be smaller. Thus the higher stepper acceleration does not result
in significantly higher stepper torque and it is therefore considered
harmless.
However, to avoid extreme cases, Klipper enforces a maximum ceiling on
stepper acceleration of three times the printer's configured maximum
move acceleration. (Similarly, the maximum velocity of the stepper is
limited to three times the maximum move velocity.) In order to enforce
this limit, moves at the extreme edge of the build envelope (where a
stepper arm may be nearly horizontal) will have a lower maximum
acceleration and velocity.
Extruder kinematics
-------------------
Klipper implements extruder motion in its own kinematic class. Since
the timing and speed of each print head movement is fully known for
each move, it's possible to calculate the step times for the extruder
independently from the step time calculations of the print head
movement.
Basic extruder movement is simple to calculate. The step time
generation uses the same formulas that cartesian robots use:
```
stepper_position = requested_e_position
```
### Pressure advance ###
Experimentation has shown that it's possible to improve the modeling
of the extruder beyond the basic extruder formula. In the ideal case,
as an extrusion move progresses, the same volume of filament should be
deposited at each point along the move and there should be no volume
extruded after the move. Unfortunately, it's common to find that the
basic extrusion formulas cause too little filament to exit the
extruder at the start of extrusion moves and for excess filament to
extrude after extrusion ends. This is often referred to as "ooze".
![ooze](img/ooze.svg.png)
The "pressure advance" system attempts to account for this by using a
different model for the extruder. Instead of naively believing that
each mm^3 of filament fed into the extruder will result in that amount
of mm^3 immediately exiting the extruder, it uses a model based on
pressure. Pressure increases when filament is pushed into the extruder
(as in [Hooke's law](https://en.wikipedia.org/wiki/Hooke%27s_law)) and
the pressure necessary to extrude is dominated by the flow rate
through the nozzle orifice (as in
[Poiseuille's law](https://en.wikipedia.org/wiki/Poiseuille_law)). The
key idea is that the relationship between filament, pressure, and flow
rate can be modeled using a linear coefficient:
```
stepper_position = requested_e_position + pressure_advance_coefficient * nominal_extruder_velocity
```
See the [pressure advance](Pressure_Advance.md) document for
information on how to find this pressure advance coefficient.
Once configured, Klipper will push in an additional amount of filament
during acceleration. The higher the desired filament flow rate, the
more filament must be pushed in during acceleration to account for
pressure. During head deceleration the extra filament is retracted
(the extruder will have a negative velocity).
![pressure-advance](img/pressure-advance.svg.png)
One may notice that the pressure advance algorithm can cause the
extruder motor to make sudden velocity changes. This is tolerated
based on the idea that the majority of the inertia in the system is in
changing the extruder pressure. As long as the extruder pressure does
not change rapidly the sudden changes in extruder motor velocity are
tolerated.
One area where sudden velocity changes become problematic is during
small changes in head speed due to cornering.
![pressure-cornering](img/pressure-cornering.svg.png)
To prevent this, the Klipper pressure advance code utilizes the move
look-ahead queue to detect intermittent speed changes. During a
deceleration event the code finds the maximum upcoming head speed
within a configurable time window. The pressure is then only adjusted
to this found maximum. This can greatly reduce (or even completely
eliminate) pressure changes during cornering.

306
docs/MCU_Commands.md
View File

@@ -1,306 +0,0 @@
This document provides information on the low-level micro-controller
commands that are sent from the Klipper "host" software and processed
by the Klipper micro-controller software. This document is not an
authoritative reference for these commands, nor is it an exclusive
list of all available commands.
This document may be useful for developers interested in understanding
the low-level micro-controller commands.
See the [protocol](Protocol.md) document for more information on the
format of commands and their transmission. The commands here are
described using their "printf" style syntax - for those unfamiliar
with that format, just note that where a '%...' sequence is seen it
should be replaced with an actual integer. For example, a description
with "count=%c" could be replaced with the text "count=10".
Startup Commands
================
It may be necessary to take certain one-time actions to configure the
micro-controller and its peripherals. This section lists common
commands available for that purpose. Unlike most micro-controller
commands, these commands run as soon as they are received and they do
not require any particular setup.
Several of these commands will take a "pin=%u" parameter. The
low-level micro-controller software uses integer encodings of the
hardware pin numbers, but to make things more readable the host will
translate human readable pin names (eg, "PA3") to their equivalent
integer encodings. By convention, any parameter named "pin" or that
has a "_pin" suffix will use pin name translation by the
host.
Common startup commands:
* `set_digital_out pin=%u value=%c` : This command immediately
configures the given pin as a digital out GPIO and it sets it to
either a low level (value=0) or a high level (value=1). This command
may be useful for configuring the initial value of LEDs and for
configuring the initial value of stepper driver micro-stepping pins.
* `set_pwm_out pin=%u cycle_ticks=%u value=%hu` : This command will
immediately configure the given pin to use hardware based
pulse-width-modulation (PWM) with the given number of
cycle_ticks. The "cycle_ticks" is the number of MCU clock ticks each
power on and power off cycle should last. A cycle_ticks value of 1
can be used to request the fastest possible cycle time. The "value"
parameter is between 0 and 255 with 0 indicating a full off state
and 255 indicating a full on state. This command may be useful for
enabling CPU and nozzle cooling fans.
Low-level micro-controller configuration
========================================
Most commands in the micro-controller require an initial setup before
they can be successfully invoked. This section provides an overview of
the configuration process. This section and the following sections are
likely only of interest to developers interested in the internal
details of Klipper.
When the host first connects to the micro-controller it always starts
by obtaining a data dictionary (see [protocol](Protocol.md) for more
information). After the data dictionary is obtained the host will
check if the micro-controller is in a "configured" state and configure
it if not. Configuration involves the following phases:
* `get_config` : The host starts by checking if the micro-controller
is already configured. The micro-controller responds to this command
with a "config" response message. The micro-controller software
always starts in an unconfigured state at power-on. It remains in
this state until the host completes the configuration processes (by
issuing a finalize_config command). If the micro-controller is
already configured from a previous session (and is configured with
the desired settings) then no further action is needed by the host
and the configuration process ends successfully.
* `allocate_oids count=%c` : This command is issued to inform the
micro-controller of the maximum number of object-ids (oid) that the
host requires. It is only valid to issue this command once. An oid
is an integer identifier allocated to each stepper, each endstop,
and each schedulable gpio pin. The host determines in advance the
number of oids it will require to operate the hardware and passes
this to the micro-controller so that it may allocate sufficient
memory to store a mapping from oid to internal object.
* `config_XXX oid=%c ...` : By convention any command starting with
the "config_" prefix creates a new micro-controller object and
assigns the given oid to it. For example, the config_digital_out
command will configure the specified pin as a digital output GPIO
and create an internal object that the host can use to schedule
changes to the given GPIO. The oid parameter passed into the config
command is selected by the host and must be between zero and the
maximum count supplied in the allocate_oids command. The config
commands may only be run when the micro-controller is not in a
configured state (ie, prior to the host sending finalize_config) and
after the allocate_oids command has been sent.
* `finalize_config crc=%u` : The finalize_config command transitions
the micro-controller from an unconfigured state to a configured
state. The crc parameter passed to the micro-controller is stored
and provided back to the host in "config" response messages. By
convention, the host takes a 32bit CRC of the configuration it will
request and at the start of subsequent communication sessions it
checks that the CRC stored in the micro-controller exactly matches
its desired CRC. If the CRC does not match then the host knows the
micro-controller has not been configured in the state desired by the
host.
Common micro-controller objects
-------------------------------
This section lists some commonly used config commands.
* `config_digital_out oid=%c pin=%u value=%c default_value=%c
max_duration=%u` : This command creates an internal micro-controller
object for the given GPIO 'pin'. The pin will be configured in
digital output mode and set to an initial value as specified by
'value' (0 for low, 1 for high). Creating a digital_out object
allows the host to schedule GPIO updates for the given pin at
specified times (see the schedule_digital_out command described
below). Should the micro-controller software go into shutdown mode
then all configured digital_out objects will be set to
'default_value'. The 'max_duration' parameter is used to implement a
safety check - if it is non-zero then it is the maximum number of
clock ticks that the host may set the given GPIO to a non-default
value without further updates. For example, if the default_value is
zero and the max_duration is 16000 then if the host sets the gpio to
a value of one then it must schedule another update to the gpio pin
(to either zero or one) within 16000 clock ticks. This safety
feature can be used with heater pins to ensure the host does not
enable the heater and then go off-line.
* `config_pwm_out oid=%c pin=%u cycle_ticks=%u value=%hu
default_value=%hu max_duration=%u` : This command creates an
internal object for hardware based PWM pins that the host may
schedule updates for. Its usage is analogous to config_digital_out -
see the description of the 'set_pwm_out' and 'config_digital_out'
commands for parameter description.
* `config_soft_pwm_out oid=%c pin=%u cycle_ticks=%u value=%c
default_value=%c max_duration=%u` : This command creates an internal
micro-controller object for software implemented PWM. Unlike
hardware pwm pins, a software pwm object does not require any
special hardware support (other than the ability to configure the
pin as a digital output GPIO). Because the output switching is
implemented in the micro-controller software, it is recommended that
the cycle_ticks parameter correspond to a time of 10ms or
greater. See the description of the 'set_pwm_out' and
'config_digital_out' commands for parameter description.
* `config_analog_in oid=%c pin=%u` : This command is used to configure
a pin in analog input sampling mode. Once configured, the pin can be
sampled at regular interval using the query_analog_in command (see
below).
* `config_stepper oid=%c step_pin=%c dir_pin=%c min_stop_interval=%u
invert_step=%c` : This command creates an internal stepper
object. The 'step_pin' and 'dir_pin' parameters specify the step and
direction pins respectively; this command will configure them in
digital output mode. The 'invert_step' parameter specifies whether a
step occurs on a rising edge (invert_step=0) or falling edge
(invert_step=1). The 'min_stop_interval' implements a safety
feature - it is checked when the micro-controller finishes all moves
for a stepper - if it is non-zero it specifies the minimum number of
clock ticks since the last step. It is used as a check on the
maximum stepper velocity that a stepper may have before stopping.
* `config_end_stop oid=%c pin=%c pull_up=%c stepper_count=%c` : This
command creates an internal "endstop" object. It is used to specify
the endstop pins and to enable "homing" operations (see the
end_stop_home command below). The command will configure the
specified pin in digital input mode. The 'pull_up' parameter
determines whether hardware provided pullup resistors for the pin
(if available) will be enabled. The 'stepper_count' parameter
specifies the maximum number of steppers that this endstop may need
to halt during a homing operation (see end_stop_home below).
* `config_spi oid=%c bus=%u pin=%u mode=%u rate=%u shutdown_msg=%*s` :
This command creates an internal SPI object. It is used with
spi_transfer and spi_send commands (see below). The "bus"
identifies the SPI bus to use (if the micro-controller has more than
one SPI bus available). The "pin" specifies the chip select (CS) pin
for the device. The "mode" is the SPI mode (should be between 0 and
3). The "rate" parameter specifies the SPI bus rate (in cycles per
second). Finally, the "shutdown_msg" is an SPI command to send to
the given device should the micro-controller go into a shutdown
state.
* `config_spi_without_cs oid=%c bus=%u mode=%u rate=%u
shutdown_msg=%*s` : This command is similar to config_spi, but
without a CS pin definition. It is useful for SPI devices that do
not have a chip select line.
Common commands
===============
This section lists some commonly used run-time commands. It is likely
only of interest to developers looking to gain insight into Klipper.
* `schedule_digital_out oid=%c clock=%u value=%c` : This command will
schedule a change to a digital output GPIO pin at the given clock
time. To use this command a 'config_digital_out' command with the
same 'oid' parameter must have been issued during micro-controller
configuration.
* `schedule_pwm_out oid=%c clock=%u value=%hu` : Schedules a change to
a hardware PWM output pin. See the 'schedule_digital_out' and
'config_pwm_out' commands for more info.
* `schedule_soft_pwm_out oid=%c clock=%u value=%hu` : Schedules a
change to a software PWM output pin. See the 'schedule_digital_out'
and 'config_soft_pwm_out' commands for more info.
* `query_analog_in oid=%c clock=%u sample_ticks=%u sample_count=%c
rest_ticks=%u min_value=%hu max_value=%hu` : This command sets up a
recurring schedule of analog input samples. To use this command a
'config_analog_in' command with the same 'oid' parameter must have
been issued during micro-controller configuration. The samples will
start as of 'clock' time, it will report on the obtained value every
'rest_ticks' clock ticks, it will over-sample 'sample_count' number
of times, and it will pause 'sample_ticks' number of clock ticks
between over-sample samples. The 'min_value' and 'max_value'
parameters implement a safety feature - the micro-controller
software will verify the sampled value (after any oversampling) is
always between the supplied range. This is intended for use with
pins attached to thermistors controlling heaters - it can be used to
check that a heater is within a temperature range.
* `get_clock` : This command causes the micro-controller to generate a
"clock" response message. The host sends this command once a second
to obtain the value of the micro-controller clock and to estimate
the drift between host and micro-controller clocks. It enables the
host to accurately estimate the micro-controller clock.
Stepper commands
----------------
* `queue_step oid=%c interval=%u count=%hu add=%hi` : This command
schedules 'count' number of steps for the given stepper, with
'interval' number of clock ticks between each step. The first step
will be 'interval' number of clock ticks since the last scheduled
step for the given stepper. If 'add' is non-zero then the interval
will be adjusted by 'add' amount after each step. This command
appends the given interval/count/add sequence to a per-stepper
queue. There may be hundreds of these sequences queued during normal
operation. New sequence are appended to the end of the queue and as
each sequence completes its 'count' number of steps it is popped
from the front of the queue. This system allows the micro-controller
to queue potentially hundreds of thousands of steps - all with
reliable and predictable schedule times.
* `set_next_step_dir oid=%c dir=%c` : This command specifies the value
of the dir_pin that the next queue_step command will use.
* `reset_step_clock oid=%c clock=%u` : Normally, step timing is
relative to the last step for a given stepper. This command resets
the clock so that the next step is relative to the supplied 'clock'
time. The host usually only sends this command at the start of a
print.
* `stepper_get_position oid=%c` : This command causes the
micro-controller to generate a "stepper_position" response message
with the stepper's current position. The position is the total
number of steps generated with dir=1 minus the total number of steps
generated with dir=0.
* `end_stop_home oid=%c clock=%u sample_ticks=%u sample_count=%c
rest_ticks=%u pin_value=%c` : This command is used during stepper
"homing" operations. To use this command a 'config_end_stop' command
with the same 'oid' parameter must have been issued during
micro-controller configuration. When this command is invoked, the
micro-controller will sample the endstop pin every 'rest_ticks'
clock ticks and check if it has a value equal to 'pin_value'. If the
value matches (and it continues to match for 'sample_count'
additional samples spread 'sample_ticks' apart) then the movement
queue for the associated stepper will be cleared and the stepper
will come to an immediate halt. The host uses this command to
implement homing - the host instructs the endstop to sample for the
endstop trigger and then it issues a series of queue_step commands
to move a stepper towards the endstop. Once the stepper hits the
endstop, the trigger will be detected, the movement halted, and the
host notified.
### Move queue
Each queue_step command utilizes an entry in the micro-controller
"move queue". This queue is allocated when it receives the
"finalize_config" command, and it reports the number of available
queue entries in "config" response messages.
It is the responsibility of the host to ensure that there is available
space in the queue before sending a queue_step command. The host does
this by calculating when each queue_step command completes and
scheduling new queue_step commands accordingly.
SPI Commands
------------
* `spi_transfer oid=%c data=%*s` : This command causes the
micro-controller to send 'data' to the spi device specified by 'oid'
and it generates a "spi_transfer_response" response message with the
data returned during the transmission.
* `spi_send oid=%c data=%*s` : This command is similar to
"spi_transfer", but it does not generate a "spi_transfer_response"
message.

48
docs/Overview.md
View File

@@ -1,48 +0,0 @@
Welcome to the Klipper documentation. There are two parts to Klipper -
code that runs on a micro-controller and code that runs on a "host"
machine. The host code is intended to run on a low-cost
general-purpose machine such as a Raspberry Pi, while the
micro-controller code is intended to run on commodity micro-controller
chips. Read [features](Features.md) for reasons to use Klipper. See
[installation](Installation.md) to get started with Klipper. See
[config checks](Config_checks.md) for a guide to verify basic pin
settings in the config file.
The Klipper configuration is stored in a simple text file on the host
machine. The [config/example.cfg](../config/example.cfg) file serves
as a reference for the config file. See the [Slicers](Slicers.md)
document for information on configuring a slicer with Klipper. See the
[Endstop Phase](Endstop_Phase.md) document for information on
Klipper's "stepper phase adjusted endstop" system. See the
[Delta Calibrate](Delta_Calibrate.md) document for information on
calibrating delta printers. The
[Pressure Advance](Pressure_Advance.md) document contains information
on tuning the pressure advance config.
The [kinematics](Kinematics.md) document provides some technical
details on how Klipper implements motion. The [FAQ](FAQ.md) answers
some common questions. The [G-Codes](G-Codes.md) document lists
currently supported run-time commands.
The history of Klipper releases is available at
[releases](Releases.md). See [contact](Contact.md) for information on
bug reporting and general communication with the developers.
Developer Documentation
=======================
There are also several documents available for developers interested
in understanding how Klipper works. Start with the
[code overview](Code_Overview.md) document - it provides information
on the structure and layout of the Klipper code. See the
[contributing](CONTRIBUTING.md) document to submit improvements to Klipper.
See [protocol](Protocol.md) for information on the low-level messaging
protocol between host and micro-controller. See also
[MCU commands](MCU_Commands.md) for a description of low-level
commands implemented in the micro-controller software.
See [debugging](Debugging.md) for information on how to test and debug
Klipper. See [stm32f1](stm32f1.md) for information on the STM32F1
micro-controller port. See [bootloaders](Bootloaders.md) for developer
information on micro-controller flashing.

31
docs/Packaging.md
View File

@@ -1,31 +0,0 @@
# Packaging klipper
Klipper is somewhat of a packaging anomaly among python programs, as it doesn't
use setuptools to build and install. Some notes regarding how best to package it
are as follows:
## C modules
Klipper uses a C module to handle some kinematics calculations more quickly.
This module needs to be compiled at packaging time to avoid introducing a
runtime dependency on a compiler. To compile the C module, run `python2
klippy/chelper/__init__.py`.
## Compiling python code
Many distributions have a policy of compiling all python code before packaging
to improve startup time. You can do this by running `python2 -m compileall
klippy`.
## Versioning
If you are building a package of Klipper from git, it is usual practice not to
ship a .git directory, so the versioning must be handled without git. To do
this, use the script shipped in `scripts/make_version.py` which should be run as
follows: `python2 scripts/make_version.py YOURDISTRONAME > klippy/.version`.
## Sample packaging script
klipper-git is packaged for Arch Linux, and has a PKGBUILD (package build
script) available at
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=klipper-git.

143
docs/Pressure_Advance.md
View File

@@ -1,143 +0,0 @@
This document provides information on tuning the "pressure advance"
configuration variable for a particular nozzle and filament. The
pressure advance feature can be helpful in reducing ooze. For more
information on how pressure advance is implemented see the
[kinematics](Kinematics.md) document.
Tuning pressure advance
=======================
Pressure advance does two useful things - it reduces ooze during
non-extrude moves and it reduces blobbing during cornering. This guide
uses the second feature (reducing blobbing during cornering) as a
mechanism for tuning.
In order to calibrate pressure advance the printer must be configured
and operational. The tuning test involves printing objects and
inspecting the differences between objects. It is a good idea to read
this document in full prior to running the test.
Use a slicer to generate g-code for the large hollow square found in
[docs/prints/square.stl](prints/square.stl). Use a high speed (eg,
100mm/s) and a coarse layer height (the layer height should be around
75% of the nozzle diameter). It is fine to use a low infill (eg, 10%).
Prepare for the test by issuing the following G-Code commands:
`SET_VELOCITY_LIMIT SQUARE_CORNER_VELOCITY=1 ACCEL=500` and
`SET_PRESSURE_ADVANCE ADVANCE_LOOKAHEAD_TIME=0`. These commands make
the nozzle travel slower through corners and they emphasize the
effects of extruder pressure.
For the first print use a pressure advance of zero by running
`SET_PRESSURE_ADVANCE ADVANCE=0.000`. Then print at least 10 layers of
the test object. While the object is printing, make a note of which
direction the head is moving during external perimeters. What many
people see here is blobbing occurring at the corners - extra filament
at the corner in the direction the head travels followed by a possible
lack of filament on the side immediately after that corner:
![corner-blob](img/corner-blob.jpg)
This blobbing is the result of pressure in the extruder being released
as a blob when the head slows down to corner.
The next step is to increase pressure advance (start with
`SET_PRESSURE_ADVANCE ADVANCE=0.050`) and reprint the test object.
With pressure advance, the extruder will retract when the head slows
down, thus countering the pressure buildup and ideally eliminate the
blobbing.
If a test run is done with a pressure advance setting that is too
high, one typically sees a dimple in the corner followed by possible
blobbing after the corner (too much filament is retracted during slow
down and then too much filament is extruded during the following speed
up after cornering):
![corner-dimple](img/corner-dimple.jpg)
The goal is to find the smallest pressure advance value that results
in good quality corners:
![corner-good](img/corner-good.jpg)
Typical pressure advance values are between 0.050 and 1.000 (the high
end usually only with bowden extruders). If there is no significant
improvement after gradually increasing pressure advance to 1.000, then
pressure advance is unlikely to improve the quality of prints. Return
to a default configuration with pressure advance disabled.
Although this tuning exercise directly improves the quality of
corners, it's worth remembering that a good pressure advance
configuration also reduces ooze throughout the print.
At the completion of this test, update the extruder's pressure_advance
setting in the configuration file and issue a RESTART command. The
RESTART command will also return the acceleration, cornering speeds,
and look-ahead times to their normal values.
Important Notes
===============
* The pressure advance value is dependent on the extruder, the nozzle,
and the filament. It is common for filament from different
manufactures or with different pigments to require significantly
different pressure advance values. Therefore, one should calibrate
pressure advance on each printer and with each spool of filament.
* Printing temperature and extrusion rates can impact pressure
advance. Be sure to tune the extruder
[E steps](http://reprap.org/wiki/Triffid_Hunter%27s_Calibration_Guide#E_steps)
and
[nozzle temperature](http://reprap.org/wiki/Triffid_Hunter%27s_Calibration_Guide#Nozzle_Temperature)
prior to tuning pressure advance.
* It is not unusual for one corner of the test print to be
consistently different than the other three corners. This typically
occurs when the slicer arranges to always change Z height at that
corner. If this occurs, then ignore that corner and tune pressure
advance using the other three corners.
* Check for warping at the corners during the test prints (the corners
detaching from the bed and rising a small distance upwards during
the print). If one corner appears warped then ignore that corner
when tuning. If significant warping is seen throughout the test then
typical solutions are to reduce the slicer's first layer speed,
adjust the bed temperature, and/or to use the slicer's brim feature.
Pressure advance itself is unlikely to impact warping, but this
tuning test is sensitive to it.
* If a high pressure advance value (eg, over 0.200) is used then one
may find that the extruder skips when returning to the printer's
normal acceleration. The pressure advance system accounts for
pressure by pushing in extra filament during acceleration and
retracting that filament during deceleration. With a high
acceleration and high pressure advance the extruder may not have
enough torque to push the required filament. If this occurs, either
use a lower acceleration value or disable pressure advance.
* The pressure_advance_lookahead_time parameter controls how far in
advance to check if a head slow-down is immediately followed by a
speed-up - it reduces pointless pressure changes in the head. It is
recommended to follow the steps above so that it is set to zero
during tuning and to use the default (0.010) during normal prints.
It is possible to tune this setting - higher values will reduce the
amount of pressure change in the nozzle during cornering, but
setting it too high can cause blobbing during cornering. (Tuning
this value is unlikely to impact ooze.) The default of 10ms should
work well on most printers.
* Once pressure advance is tuned in Klipper, it may still be useful to
configure a small retract value in the slicer (eg, 0.75mm) and to
utilize the slicer's "wipe on retract option" if available. These
slicer settings may help counteract ooze caused by filament cohesion
(filament pulled out of the nozzle due to the stickiness of the
plastic). It is recommended to disable the slicer's "z-lift on
retract" option.
* Configuring pressure advance results in extra extruder movement
during move acceleration and deceleration. That extra movement is
not further constrained by any other other configuration parameter.
The pressure advance settings only impact extruder movement; they do
not alter toolhead XYZ movement or look-ahead calculations. A change
in pressure advance will not change the path or timing of the
toolhead nor will it change the overall printing time.

343
docs/Protocol.md
View File

@@ -1,343 +0,0 @@
The Klipper messaging protocol is used for low-level communication
between the Klipper host software and the Klipper micro-controller
software. At a high level the protocol can be thought of as a series
of command and response strings that are compressed, transmitted, and
then processed at the receiving side. An example series of commands in
uncompressed human-readable format might look like:
```
set_digital_out pin=86 value=1
set_digital_out pin=85 value=1
schedule_digital_out oid=8 clock=4000000 value=0
queue_step oid=7 interval=7458 count=10 add=331
queue_step oid=7 interval=11717 count=4 add=1281
```
See the [mcu commands](MCU_Commands.md) document for information on
available commands. See the [debugging](Debugging.md) document for
information on how to translate a G-Code file into its corresponding
human-readable micro-controller commands.
This page provides a high-level description of the Klipper messaging
protocol itself. It describes how messages are declared, encoded in
binary format (the "compression" scheme), and transmitted.
The goal of the protocol is to enable an error-free communication
channel between the host and micro-controller that is low-latency,
low-bandwidth, and low-complexity for the micro-controller.
Micro-controller Interface
==========================
The Klipper transmission protocol can be thought of as a
[RPC](https://en.wikipedia.org/wiki/Remote_procedure_call) mechanism
between micro-controller and host. The micro-controller software
declares the commands that the host may invoke along with the response
messages that it can generate. The host uses that information to
command the micro-controller to perform actions and to interpret the
results.
Declaring commands
------------------
The micro-controller software declares a "command" by using the
DECL_COMMAND() macro in the C code. For example:
```
DECL_COMMAND(command_set_digital_out, "set_digital_out pin=%u value=%c");
```
The above declares a command named "set_digital_out". This allows the
host to "invoke" this command which would cause the
command_set_digital_out() C function to be executed in the
micro-controller. The above also indicates that the command takes two
integer parameters. When the command_set_digital_out() C code is
executed, it will be passed an array containing these two integers -
the first corresponding to the 'pin' and the second corresponding to
the 'value'.
In general, the parameters are described with printf() style syntax
(eg, "%u"). The formatting directly corresponds to the human-readable
view of commands (eg, "set_digital_out pin=86 value=1"). In the above
example, "value=" is a parameter name and "%c" indicates the parameter
is an integer. Internally, the parameter name is only used as
documentation. In this example, the "%c" is also used as documentation
to indicate the expected integer is 1 byte in size (the declared
integer size does not impact the parsing or encoding).
The micro-controller build will collect all commands declared with
DECL_COMMAND(), determine their parameters, and arrange for them to be
callable.
Declaring responses
-------------------
To send information from the micro-controller to the host a "response"
is generated. These are both declared and transmitted using the
sendf() C macro. For example:
```
sendf("status clock=%u status=%c", sched_read_time(), sched_is_shutdown());
```
The above transmits a "status" response message that contains two
integer parameters ("clock" and "status"). The micro-controller build
automatically finds all sendf() calls and generates encoders for
them. The first parameter of the sendf() function describes the
response and it is in the same format as command declarations.
The host can arrange to register a callback function for each
response. So, in effect, commands allow the host to invoke C functions
in the micro-controller and responses allow the micro-controller
software to invoke code in the host.
The sendf() macro should only be invoked from command or task
handlers, and it should not be invoked from interrupts or timers. The
code does not need to issue a sendf() in response to a received
command, it is not limited in the number of times sendf() may be
invoked, and it may invoke sendf() at any time from a task handler.
### Output responses
To simplify debugging, there is also has an output() C function. For
example:
```
output("The value of %u is %s with size %u.", x, buf, buf_len);
```
The output() function is similar in usage to printf() - it is intended
to generate and format arbitrary messages for human consumption.
Declaring constants
-------------------
Constants can also be exported. For example, the following:
```
DECL_CONSTANT(SERIAL_BAUD, 250000);
```
would export a constant named "SERIAL_BAUD" with a value of 250000
from the micro-controller to the host.
Low-level message encoding
==========================
To accomplish the above RPC mechanism, each command and response is
encoded into a binary format for transmission. This section describes
the transmission system.
Message Blocks
--------------
All data sent from host to micro-controller and vice-versa are
contained in "message blocks". A message block has a two byte header
and a three byte trailer. The format of a message block is:
```
<1 byte length><1 byte sequence><n-byte content><2 byte crc><1 byte sync>
```
The length byte contains the number of bytes in the message block
including the header and trailer bytes (thus the minimum message
length is 5 bytes). The maximum message block length is currently 64
bytes. The sequence byte contains a 4 bit sequence number in the
low-order bits and the high-order bits always contain 0x10 (the
high-order bits are reserved for future use). The content bytes
contain arbitrary data and its format is described in the following
section. The crc bytes contain a 16bit CCITT
[CRC](https://en.wikipedia.org/wiki/Cyclic_redundancy_check) of the
message block including the header bytes but excluding the trailer
bytes. The sync byte is 0x7e.
The format of the message block is inspired by
[HDLC](https://en.wikipedia.org/wiki/High-Level_Data_Link_Control)
message frames. Like in HDLC, the message block may optionally contain
an additional sync character at the start of the block. Unlike in
HDLC, a sync character is not exclusive to the framing and may be
present in the message block content.
Message Block Contents
----------------------
Each message block sent from host to micro-controller contains a
series of zero or more message commands in its contents. Each command
starts with a [Variable Length Quantity](#variable-length-quantities)
(VLQ) encoded integer command-id followed by zero or more VLQ
parameters for the given command.
As an example, the following four commands might be placed in a single
message block:
```
set_digital_out pin=86 value=1
set_digital_out pin=85 value=0
get_config
get_clock
```
and encoded into the following eight VLQ integers:
```
<id_set_digital_out><86><1><id_set_digital_out><85><0><id_get_config><id_get_clock>
```
In order to encode and parse the message contents, both the host and
micro-controller must agree on the command ids and the number of
parameters each command has. So, in the above example, both the host
and micro-controller would know that "id_set_digital_out" is always
followed by two parameters, and "id_get_config" and "id_get_clock"
have zero parameters. The host and micro-controller share a "data
dictionary" that maps the command descriptions (eg, "set_digital_out
pin=%u value=%c") to their integer command-ids. When processing the
data, the parser will know to expect a specific number of VLQ encoded
parameters following a given command id.
The message contents for blocks sent from micro-controller to host
follow the same format. The identifiers in these messages are
"response ids", but they serve the same purpose and follow the same
encoding rules. In practice, message blocks sent from the
micro-controller to the host never contain more than one response in
the message block contents.
### Variable Length Quantities
See the [wikipedia article](https://en.wikipedia.org/wiki/Variable-length_quantity)
for more information on the general format of VLQ encoded
integers. Klipper uses an encoding scheme that supports both positive
and negative integers. Integers close to zero use less bytes to encode
and positive integers typically encode using less bytes than negative
integers. The following table shows the number of bytes each integer
takes to encode:
| Integer | Encoded size |
|---------------------------|--------------|
| -32 .. 95 | 1 |
| -4096 .. 12287 | 2 |
| -524288 .. 1572863 | 3 |
| -67108864 .. 201326591 | 4 |
| -2147483648 .. 4294967295 | 5 |
### Variable length strings
As an exception to the above encoding rules, if a parameter to a
command or response is a dynamic string then the parameter is not
encoded as a simple VLQ integer. Instead it is encoded by transmitting
the length as a VLQ encoded integer followed by the contents itself:
```
<VLQ encoded length><n-byte contents>
```
The command descriptions found in the data dictionary allow both the
host and micro-controller to know which command parameters use simple
VLQ encoding and which parameters use string encoding.
Data Dictionary
===============
In order for meaningful communications to be established between
micro-controller and host, both sides must agree on a "data
dictionary". This data dictionary contains the integer identifiers for
commands and responses along with their descriptions.
The micro-controller build uses the contents of DECL_COMMAND() and
sendf() macros to generate the data dictionary. The build
automatically assigns unique identifiers to each command and
response. This system allows both the host and micro-controller code
to seamlessly use descriptive human-readable names while still using
minimal bandwidth.
The host queries the data dictionary when it first connects to the
micro-controller. Once the host downloads the data dictionary from the
micro-controller, it uses that data dictionary to encode all commands
and to parse all responses from the micro-controller. The host must
therefore handle a dynamic data dictionary. However, to keep the
micro-controller software simple, the micro-controller always uses its
static (compiled in) data dictionary.
The data dictionary is queried by sending "identify" commands to the
micro-controller. The micro-controller will respond to each identify
command with an "identify_response" message. Since these two commands
are needed prior to obtaining the data dictionary, their integer ids
and parameter types are hard-coded in both the micro-controller and
the host. The "identify_response" response id is 0, the "identify"
command id is 1. Other than having hard-coded ids the identify command
and its response are declared and transmitted the same way as other
commands and responses. No other command or response is hard-coded.
The format of the transmitted data dictionary itself is a zlib
compressed JSON string. The micro-controller build process generates
the string, compresses it, and stores it in the text section of the
micro-controller flash. The data dictionary can be much larger than
the maximum message block size - the host downloads it by sending
multiple identify commands requesting progressive chunks of the data
dictionary. Once all chunks are obtained the host will assemble the
chunks, uncompress the data, and parse the contents.
In addition to information on the communication protocol, the data
dictionary also contains the software version, constants (as defined
by DECL_CONSTANT), and static strings.
Static Strings
--------------
To reduce bandwidth the data dictionary also contains a set of static
strings known to the micro-controller. This is useful when sending
messages from micro-controller to host. For example, if the
micro-controller were to run:
```
shutdown("Unable to handle command");
```
The error message would be encoded and sent using a single VLQ. The
host uses the data dictionary to resolve VLQ encoded static string ids
to their associated human-readable strings.
Message flow
============
Message commands sent from host to micro-controller are intended to be
error-free. The micro-controller will check the CRC and sequence
numbers in each message block to ensure the commands are accurate and
in-order. The micro-controller always processes message blocks
in-order - should it receive a block out-of-order it will discard it
and any other out-of-order blocks until it receives blocks with the
correct sequencing.
The low-level host code implements an automatic retransmission system
for lost and corrupt message blocks sent to the micro-controller. To
facilitate this, the micro-controller transmits an "ack message block"
after each successfully received message block. The host schedules a
timeout after sending each block and it will retransmit should the
timeout expire without receiving a corresponding "ack". In addition,
if the micro-controller detects a corrupt or out-of-order block it may
transmit a "nak message block" to facilitate fast retransmission.
An "ack" is a message block with empty content (ie, a 5 byte message
block) and a sequence number greater than the last received host
sequence number. A "nak" is a message block with empty content and a
sequence number less than the last received host sequence number.
The protocol facilitates a "window" transmission system so that the
host can have many outstanding message blocks in-flight at a
time. (This is in addition to the many commands that may be present in
a given message block.) This allows maximum bandwidth utilization even
in the event of transmission latency. The timeout, retransmit,
windowing, and ack mechanism are inspired by similar mechanisms in
[TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol).
In the other direction, message blocks sent from micro-controller to
host are designed to be error-free, but they do not have assured
transmission. (Responses should not be corrupt, but they may go
missing.) This is done to keep the implementation in the
micro-controller simple. There is no automatic retransmission system
for responses - the high-level code is expected to be capable of
handling an occasional missing response (usually by re-requesting the
content or setting up a recurring schedule of response
transmission). The sequence number field in message blocks sent to the
host is always one greater than the last received sequence number of
message blocks received from the host. It is not used to track
sequences of response message blocks.

2
docs/README.md
View File

@@ -1,2 +0,0 @@
Welcome to the Klipper documentation. The
[overview document](Overview.md) is a good starting point.

143
docs/Releases.md
View File

@@ -1,143 +0,0 @@
History of Klipper releases. Please see
[installation](Installation.md) for information on installing Klipper.
Klipper 0.7.0
=============
Available on 20181220. Major changes in this release:
* Klipper now supports "mesh" bed leveling
* New support for "enhanced" delta calibration (calibrates print x/y
dimensions on delta printers)
* Support for run-time configuration of Trinamic stepper motor drivers
(tmc2130, tmc2208, tmc2660)
* Improved temperature sensor support: MAX6675, MAX31855, MAX31856,
MAX31865, custom thermistors, common pt100 style sensors
* Several new modules: temperature_fan, sx1509, force_move, mcp4451,
z_tilt, quad_gantry_level, endstop_phase, bltouch
* Several new commands added: SAVE_CONFIG, SET_PRESSURE_ADVANCE,
SET_GCODE_OFFSET, SET_VELOCITY_LIMIT, STEPPER_BUZZ, TURN_OFF_HEATERS,
M204, custom g-code macros
* Expanded LCD display support:
* Support for run-time menus
* New display icons
* Support for "uc1701" and "ssd1306" displays
* Additional micro-controller support:
* Klipper ported to: LPC176x (Smoothieboards), SAM4E8E (Duet2),
SAMD21 (Arduino Zero), STM32F103 ("Blue pill" devices), atmega32u4
* New Generic USB CDC driver implemented on AVR, LPC176x, SAMD21, and
STM32F103
* Performance improvements on ARM processors
* The kinematics code was rewritten to use an "iterative solver"
* New automatic test cases for the Klipper host software
* Many new example config files for common off-the-shelf printers
* Documentation updates for bootloaders, benchmarking,
micro-controller porting, config checks, pin mapping, slicer
settings, packaging, and more
* Several bug fixes and code cleanups
Klipper 0.6.0
=============
Available on 20180331. Major changes in this release:
* Enhanced heater and thermistor hardware failure checks
* Support for Z probes
* Initial support for automatic parameter calibration on deltas (via a
new delta_calibrate command)
* Initial support for bed tilt compensation (via bed_tilt_calibrate
command)
* Initial support for "safe homing" and homing overrides
* Initial support for displaying status on RepRapDiscount style 2004
and 12864 displays
* New multi-extruder improvements:
* Support for shared heaters
* Initial support for dual carriages
* Support for configuring multiple steppers per axis (eg, dual Z)
* Support for custom digital and pwm output pins (with a new SET_PIN command)
* Initial support for a "virtual sdcard" that allows printing directly
from Klipper (helps on machines too slow to run OctoPrint well)
* Support for setting different arm lengths on each tower of a delta
* Support for G-Code M220/M221 commands (speed factor override /
extrude factor override)
* Several documentation updates:
* Many new example config files for common off-the-shelf printers
* New multiple MCU config example
* New bltouch sensor config example
* New FAQ, config check, and G-Code documents
* Initial support for continuous integration testing on all github commits
* Several bug fixes and code cleanups
Klipper 0.5.0
=============
Available on 20171025. Major changes in this release:
* Support for printers with multiple extruders.
* Initial support for running on the Beaglebone PRU. Initial support
for the Replicape board.
* Initial support for running the micro-controller code in a real-time
Linux process.
* Support for multiple micro-controllers. (For example, one could
control an extruder with one micro-controller and the rest of the
printer with another.) Software clock synchronization is implemented
to coordinate actions between micro-controllers.
* Stepper performance improvements (20Mhz AVRs up to 189K steps per
second).
* Support for controlling servos and support for defining nozzle
cooling fans.
* Several bug fixes and code cleanups
Klipper 0.4.0
=============
Available on 20170503. Major changes in this release:
* Improved installation on Raspberry Pi machines. Most of the install
is now scripted.
* Support for corexy kinematics
* Documentation updates: New Kinematics document, new Pressure Advance
tuning guide, new example config files, and more
* Stepper performance improvements (20Mhz AVRs over 175K steps per
second, Arduino Due over 460K)
* Support for automatic micro-controller resets. Support for resets
via toggling USB power on Raspberry Pi.
* The pressure advance algorithm now works with look-ahead to reduce
pressure changes during cornering.
* Support for limiting the top speed of short zigzag moves
* Support for AD595 sensors
* Several bug fixes and code cleanups
Klipper 0.3.0
=============
Available on 20161223. Major changes in this release:
* Improved documentation
* Support for robots with delta kinematics
* Support for Arduino Due micro-controller (ARM cortex-M3)
* Support for USB based AVR micro-controllers
* Support for "pressure advance" algorithm - it reduces ooze during
prints.
* New "stepper phased based endstop" feature - enables higher
precision on endstop homing.
* Support for "extended g-code" commands such as "help", "restart",
and "status".
* Support for reloading the Klipper config and restarting the host
software by issuing a "restart" command from the terminal.
* Stepper performance improvements (20Mhz AVRs up to 158K steps per
second).
* Improved error reporting. Most errors now shown via the terminal
along with help on how to resolve.
* Several bug fixes and code cleanups
Klipper 0.2.0
=============
Initial release of Klipper. Available on 20160525. Major features
available in the initial release include:
* Basic support for cartesian printers (steppers, extruder, heated
bed, cooling fan).
* Support for common g-code commands. Support for interfacing with
OctoPrint.
* Acceleration and lookahead handling
* Support for AVR micro-controllers via standard serial ports

71
docs/Slicers.md
View File

@@ -1,71 +0,0 @@
This document provides some tips for configuring a "slicer"
application for use with Klipper. Common slicers used with Klipper are
Slic3r, Cura, Simplify3D, etc.
# Set the G-Code flavor to Marlin
Many slicers have an option to configure the "G-Code flavor". The
default is frequently "Marlin" and that works well with Klipper. The
"Smoothieware" setting also works well with Klipper.
# Klipper gcode_macro
Slicers will often allow one to configure "Start G-Code" and "End
G-Code" sequences. It is often convenient to define custom macros in
the Klipper config file instead - such as: `[gcode_macro START_PRINT]`
and `[gcode_macro END_PRINT]`. Then one can just run START_PRINT and
END_PRINT in the slicer's configuration. Defining these actions in the
Klipper configuration may make it easier to tweak the printer's start
and end steps as changes do not require re-slicing.
See the [example-extras.cfg](../config/example-extras.cfg) file for
details on defining a gcode_macro.
# Large retraction settings may require tuning Klipper
The maximum speed and acceleration of retraction moves are controlled
in Klipper by the `max_extrude_only_velocity` and
`max_extrude_only_accel` config settings. These settings have a
default value that should work well on many printers. However, if one
has configured a large retraction in the slicer (eg, 5mm or greater)
then one may find they limit the desired speed of retractions.
If using a large retraction, consider tuning Klipper's
[pressure advance](Pressure_Advance.md) instead. Otherwise, if one
finds the toolhead seems to "pause" during retraction and priming,
then consider explicitly defining `max_extrude_only_velocity` and
`max_extrude_only_accel` in the Klipper config file.
# Do not enable "coasting"
The "coasting" feature is likely to result in poor quality prints with
Klipper. Consider using Klipper's
[pressure advance](Pressure_Advance.md) instead.
Specifically, if the slicer dramatically changes the extrusion rate
between moves then Klipper will perform deceleration and acceleration
between moves. This is likely to make blobbing worse, not better.
In contrast, it is okay (and often helpful) to use a slicer's
"retract" setting, "wipe" setting, and/or "wipe on retract" setting.
# Disable any "advanced extruder pressure" settings
Some slicers advertise an "advanced extruder pressure" capability. It
is recommended to keep these options disabled when using Klipper as
they are likely to result in poor quality prints. Consider using
Klipper's [pressure advance](Pressure_Advance.md) instead.
Specifically, these slicer settings can instruct the firmware to make
wild changes to the extrusion rate in the hope that the firmware will
approximate those requests and the printer will roughly obtain a
desirable extruder pressure. Klipper, however, utilizes precise
kinematic calculations and timing. When Klipper is commanded to make
significant changes to the extrusion rate it will plan out the
corresponding changes to velocity, acceleration, and extruder
movement - which is not the slicer's intent. The slicer may even
command excessive extrusion rates to the point that it triggers
Klipper's maximum extrusion cross-section check.
In contrast, it is okay (and often helpful) to use a slicer's
"retract" setting, "wipe" setting, and/or "wipe on retract" setting.

103
docs/beaglebone.md
View File

@@ -1,103 +0,0 @@
This document describes the process of running Klipper on a Beaglebone
PRU.
Building an OS image
====================
Start by installing the
[latest Jessie IoT](https://beagleboard.org/latest-images) image
(2017-03-19 or later). One may run the image from either a micro-SD
card or from builtin eMMC. If using the eMMC, install it to eMMC now
by following the instructions from the above link.
Then ssh into the beaglebone machine (ssh debian@beaglebone --
password is "temppwd") and install Klipper by running the following
commands:
```
git clone https://github.com/KevinOConnor/klipper
./klipper/scripts/install-beaglebone.sh
```
Install Octoprint
=================
One may then install Octoprint:
```
git clone https://github.com/foosel/OctoPrint.git
cd OctoPrint/
virtualenv venv
./venv/bin/python setup.py install
```
And setup OctoPrint to start at bootup:
```
sudo cp ~/OctoPrint/scripts/octoprint.init /etc/init.d/octoprint
sudo chmod +x /etc/init.d/octoprint
sudo cp ~/OctoPrint/scripts/octoprint.default /etc/default/octoprint
sudo update-rc.d octoprint defaults
```
It is necessary to modify OctoPrint's **/etc/default/octoprint**
configuration file. One must change the OCTOPRINT_USER user to
"debian", change NICELEVEL to 0, uncomment the BASEDIR, CONFIGFILE,
and DAEMON settings and change the references from "/home/pi/" to
"/home/debian/":
```
sudo nano /etc/default/octoprint
```
Then start the Octoprint service:
```
sudo systemctl start octoprint
```
Make sure the octoprint web server is accessible - it should be at:
[http://beaglebone:5000/](http://beaglebone:5000/)
Building the micro-controller code
==================================
To compile the Klipper micro-controller code, start by configuring it
for the "Beaglebone PRU":
```
cd ~/klipper/
make menuconfig
```
To build and install the new micro-controller code, run:
```
sudo service klipper stop
make flash
sudo service klipper start
```
It is also necessary to compile and install the micro-controller code
for a Linux host process. Run "make menuconfig" a second time and
configure it for a "Linux process":
```
make menuconfig
```
Then install this micro-controller code as well:
```
sudo service klipper stop
make flash
sudo service klipper start
```
Remaining configuration
=======================
Complete the installation by configuring Klipper and Octoprint
following the instructions in
[the main installation document](Installation.md#configuring-klipper).
Printing on the Beaglebone
==========================
Unfortunately, the Beaglebone processor can sometimes struggle to run
OctoPrint well. Print stalls have been known to occur on complex
prints (the printer may move faster than OctoPrint can send movement
commands). If this occurs, consider using the "virtual_sdcard" feature
(see [config/example-extras.cfg](../config/example-extras.cfg) for
details) to print directly from Klipper.

37
docs/developer-certificate-of-origin
View File

@@ -1,37 +0,0 @@
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.

BIN
docs/img/attach-issue.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 10 KiB

BIN
docs/img/corner-blob.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.6 KiB

BIN
docs/img/corner-dimple.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.3 KiB

BIN
docs/img/corner-good.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.3 KiB

184
docs/img/corner.svg
View File

@@ -1,184 +0,0 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="54.904114mm"
height="6.0860338mm"
viewBox="0 0 194.54213 21.564687"
id="svg3506"
version="1.1"
inkscape:version="0.91 r13725"
sodipodi:docname="corner.svg">
<defs
id="defs3508">
<marker
inkscape:stockid="DiamondL"
orient="auto"
refY="0"
refX="0"
id="DiamondL"
style="overflow:visible"
inkscape:isstock="true">
<path
id="path4399"
d="M 0,-7.0710768 -7.0710894,0 0,7.0710589 7.0710462,0 0,-7.0710768 Z"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
transform="scale(0.8,0.8)"
inkscape:connector-curvature="0" />
</marker>
<marker
inkscape:stockid="Arrow2Lend"
orient="auto"
refY="0"
refX="0"
id="Arrow2Lend"
style="overflow:visible"
inkscape:isstock="true">
<path
id="path4341"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
inkscape:connector-curvature="0" />
</marker>
<marker
inkscape:stockid="Arrow1Mend"
orient="auto"
refY="0"
refX="0"
id="marker4596"
style="overflow:visible"
inkscape:isstock="true">
<path
id="path4598"
d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
transform="matrix(-0.4,0,0,-0.4,-4,0)"
inkscape:connector-curvature="0" />
</marker>
<marker
inkscape:stockid="Arrow1Mend"
orient="auto"
refY="0"
refX="0"
id="Arrow1Mend"
style="overflow:visible"
inkscape:isstock="true">
<path
id="path4329"
d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
transform="matrix(-0.4,0,0,-0.4,-4,0)"
inkscape:connector-curvature="0" />
</marker>
<marker
inkscape:stockid="Arrow1Mend"
orient="auto"
refY="0"
refX="0"
id="Arrow1Mend-1"
style="overflow:visible"
inkscape:isstock="true">
<path
inkscape:connector-curvature="0"
id="path4329-1"
d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
transform="matrix(-0.4,0,0,-0.4,-4,0)" />
</marker>
</defs>
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="2.49"
inkscape:cx="95.030833"
inkscape:cy="-0.17370789"
inkscape:document-units="px"
inkscape:current-layer="layer1"
showgrid="true"
fit-margin-top="0"
fit-margin-left="0"
fit-margin-right="0"
fit-margin-bottom="0"
showborder="false"
inkscape:window-width="1068"
inkscape:window-height="478"
inkscape:window-x="378"
inkscape:window-y="113"
inkscape:window-maximized="0">
<inkscape:grid
type="xygrid"
id="grid6021"
spacingx="9.9999997"
spacingy="10.000001"
originx="0.89299989"
originy="-30.954583" />
</sodipodi:namedview>
<metadata
id="metadata3511">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title />
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1"
transform="translate(-253.40821,-436.43703)">
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow1Mend)"
d="m 345.38554,440.31401 96.88541,12.96764"
id="path3514"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow1Mend-1)"
d="m 253.63788,454.62572 89.78715,-13.91164"
id="path3514-5"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="189.09824"
y="482.48389"
id="text12656-9"
sodipodi:linespacing="125%"
transform="matrix(0.98759291,-0.15703579,0.15703579,0.98759291,0,0)"
inkscape:transform-center-x="1.3563414"
inkscape:transform-center-y="-5.7099754"><tspan
sodipodi:role="line"
id="tspan5552"
x="189.09824"
y="482.48389">move 1</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="427.95532"
y="379.5321"
id="text12656-9-8"
sodipodi:linespacing="125%"
transform="matrix(0.98949457,0.14457001,-0.14457001,0.98949457,0,0)"><tspan
sodipodi:role="line"
id="tspan5554"
x="427.95532"
y="379.5321">move 2</tspan></text>
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 6.7 KiB

BIN
docs/img/corner.svg.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 2.1 KiB

BIN
docs/img/delta-a-distance.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 24 KiB

BIN
docs/img/delta-a-pillar.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 31 KiB

BIN
docs/img/delta-outer-distance.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 27 KiB

BIN
docs/img/delta-outer-pillar.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 24 KiB

BIN
docs/img/delta_cal_e_step1.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 27 KiB

BIN
docs/img/delta_cal_e_step2.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 24 KiB

BIN
docs/img/delta_cal_e_step3.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 19 KiB

BIN
docs/img/delta_cal_e_step4.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 20 KiB

208
docs/img/lookahead-slow.svg
View File

@@ -1,208 +0,0 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="97.22496mm"
height="32.550285mm"
viewBox="0 0 344.49789 115.33566"
id="svg2"
version="1.1"
inkscape:version="0.91 r13725"
sodipodi:docname="lookahead-slow.svg"
inkscape:export-filename="/home/kevin/src/reprap/firmware/klipper/docs/img/lookahead-slow.svg.png"
inkscape:export-xdpi="90"
inkscape:export-ydpi="90">
<defs
id="defs4">
<marker
inkscape:stockid="Arrow1Mend"
orient="auto"
refY="0"
refX="0"
id="Arrow1Mend-1"
style="overflow:visible"
inkscape:isstock="true">
<path
inkscape:connector-curvature="0"
id="path4329-1"
d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
transform="matrix(-0.4,0,0,-0.4,-4,0)" />
</marker>
<marker
inkscape:stockid="Arrow1Mend"
orient="auto"
refY="0"
refX="0"
id="Arrow1Mend"
style="overflow:visible"
inkscape:isstock="true">
<path
id="path4329"
d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
transform="matrix(-0.4,0,0,-0.4,-4,0)"
inkscape:connector-curvature="0" />
</marker>
</defs>
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="1.15"
inkscape:cx="3.4198125"
inkscape:cy="101.26451"
inkscape:document-units="px"
inkscape:current-layer="layer1"
showgrid="false"
inkscape:window-width="1091"
inkscape:window-height="588"
inkscape:window-x="149"
inkscape:window-y="422"
inkscape:window-maximized="0"
fit-margin-top="0"
fit-margin-left="0"
fit-margin-right="0"
fit-margin-bottom="0"
showborder="false"
inkscape:snap-global="false"
showguides="false">
<inkscape:grid
type="xygrid"
id="grid3436" />
</sodipodi:namedview>
<metadata
id="metadata7">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title></dc:title>
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1"
transform="translate(-135.22429,-249.96955)">
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 150,250.23455 1.06383,102.12765 327.12765,-0.53192 -7.97871,5.85107"
id="path3347"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.5px;line-height:100%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="434.04257"
y="365.1282"
id="text3349"
sodipodi:linespacing="100%"><tspan
sodipodi:role="line"
id="tspan3351"
x="434.04257"
y="365.1282">time</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.5px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="-313.86618"
y="140.27856"
id="text3353"
sodipodi:linespacing="125%"
transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
sodipodi:role="line"
id="tspan3355"
x="-313.86618"
y="140.27856">velocity</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 150,250.23455 -5.31915,8.51063"
id="path3359"
inkscape:connector-curvature="0" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.62366331px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 179.63013,351.45141 16.05677,-60.94328 43.25999,0 16.53759,47.11348"
id="path3361"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.7558428px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 254.72406,337.27551 22.65101,-77.77178 43.89917,0 24.69858,91.73948"
id="path3361-7"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="195.45749"
y="286.52051"
id="text12656-9"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan7078"
x="195.45749"
y="286.52051">move A</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="280.5639"
y="254.60564"
id="text12656-9-3"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan7080"
x="280.5639"
y="254.60564">move B</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow1Mend)"
d="m 74.333855,283.02668 -147.83244,52.19984"
id="path3514"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow1Mend-1)"
d="m -79.633985,251.6122 154.13499,31.81455"
id="path3514-5"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="36.7374"
y="252.31848"
id="text12656-9-1"
sodipodi:linespacing="125%"
transform="matrix(0.96753827,0.25272454,-0.25272454,0.96753827,0,0)"
inkscape:transform-center-x="-0.91382951"
inkscape:transform-center-y="-4.9145266"><tspan
sodipodi:role="line"
id="tspan7074"
x="36.7374"
y="252.31848">move A</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="-126.26086"
y="304.35226"
id="text12656-9-8"
sodipodi:linespacing="125%"
transform="matrix(0.93839918,-0.34555314,0.34555314,0.93839918,0,0)"><tspan
sodipodi:role="line"
id="tspan7076"
x="-126.26086"
y="304.35226">move B</tspan></text>
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 9.2 KiB

BIN
docs/img/lookahead-slow.svg.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 7.5 KiB

136
docs/img/lookahead.svg
View File

@@ -1,136 +0,0 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="97.22496mm"
height="32.550285mm"
viewBox="0 0 344.49789 115.33566"
id="svg2"
version="1.1"
inkscape:version="0.91 r13725"
sodipodi:docname="lookahead.svg">
<defs
id="defs4" />
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="0.94"
inkscape:cx="116.54041"
inkscape:cy="45.708959"
inkscape:document-units="px"
inkscape:current-layer="layer1"
showgrid="false"
inkscape:window-width="1091"
inkscape:window-height="588"
inkscape:window-x="149"
inkscape:window-y="422"
inkscape:window-maximized="0"
fit-margin-top="0"
fit-margin-left="0"
fit-margin-right="0"
fit-margin-bottom="0"
showborder="false"
inkscape:snap-global="false"
showguides="false">
<inkscape:grid
type="xygrid"
id="grid3436" />
</sodipodi:namedview>
<metadata
id="metadata7">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title />
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1"
transform="translate(-135.22429,-249.96955)">
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 150,250.23455 1.06383,102.12765 327.12765,-0.53192 -7.97871,5.85107"
id="path3347"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.5px;line-height:100%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="434.04257"
y="365.1282"
id="text3349"
sodipodi:linespacing="100%"><tspan
sodipodi:role="line"
id="tspan3351"
x="434.04257"
y="365.1282">time</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.5px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="-313.86618"
y="140.27856"
id="text3353"
sodipodi:linespacing="125%"
transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
sodipodi:role="line"
id="tspan3355"
x="-313.86618"
y="140.27856">velocity</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 150,250.23455 -5.31915,8.51063"
id="path3359"
inkscape:connector-curvature="0" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.62366331px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 179.63013,351.45141 16.05677,-60.94328 61.3451,0 4.83546,8.81561"
id="path3361"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.7558428px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 261.70791,300.17937 13.5395,-40.67564 59.85662,0 24.69858,91.73948"
id="path3361-7"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="200.77664"
y="286.52051"
id="text12656-9"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan5532"
x="200.77664"
y="286.52051">move 1</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="280.5639"
y="255.66946"
id="text12656-9-3"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan5534"
x="280.5639"
y="255.66946">move 2</tspan></text>
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 5.8 KiB

BIN
docs/img/lookahead.svg.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.1 KiB

BIN
docs/img/octoprint-temperature.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 40 KiB

207
docs/img/ooze.svg
View File

@@ -1,207 +0,0 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="98.140816mm"
height="63.537022mm"
viewBox="0 0 347.74305 225.13119"
id="svg2"
version="1.1"
inkscape:version="0.91 r13725"
sodipodi:docname="ooze.svg"
inkscape:export-filename="/home/kevin/src/reprap/firmware/klipper/docs/img/ooze.svg.png"
inkscape:export-xdpi="90"
inkscape:export-ydpi="90">
<defs
id="defs4" />
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="0.94"
inkscape:cx="199.68782"
inkscape:cy="58.510649"
inkscape:document-units="px"
inkscape:current-layer="layer1"
showgrid="false"
inkscape:window-width="1091"
inkscape:window-height="588"
inkscape:window-x="266"
inkscape:window-y="106"
inkscape:window-maximized="0"
fit-margin-top="0"
fit-margin-left="0"
fit-margin-right="0"
fit-margin-bottom="0"
showborder="false"
inkscape:snap-global="false"
showguides="false">
<inkscape:grid
type="xygrid"
id="grid3436"
originx="-1.5695746e-05"
originy="109.79552" />
</sodipodi:namedview>
<metadata
id="metadata7">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title />
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1"
transform="translate(-135.22431,-249.96955)">
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 150,250.23455 1.06383,102.12765 327.12765,-0.53192 -7.97871,5.85107"
id="path3347"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.50000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="-346.84067"
y="139.75046"
id="text3353"
sodipodi:linespacing="125%"
transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
sodipodi:role="line"
id="tspan12733"
x="-346.84067"
y="139.75046">head velocity</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 150,250.23455 -5.31915,8.51063"
id="path3359"
inkscape:connector-curvature="0" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.00000024;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 179.63013,351.45141 16.05677,-60.94328 120.91957,-1.06383 16.53759,62.00711"
id="path3361"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.78742969px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 332.99641,351.24986 16.72764,-63.00287 133.24331,0"
id="path3361-7"
inkscape:connector-curvature="0"
sodipodi:nodetypes="ccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="200.11789"
y="284.45413"
id="text12656"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan12658"
x="200.11789"
y="284.45413">extrude move</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="356.50089"
y="283.39032"
id="text12660"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan12662"
x="356.50089"
y="283.39032">non-extrude move</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 152.72419,471.73218 1.06383,102.12766 327.12768,-0.53192 -7.97872,5.85107"
id="path3347-0"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.5px;line-height:100%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="436.76678"
y="586.62585"
id="text3349-3"
sodipodi:linespacing="100%"><tspan
sodipodi:role="line"
id="tspan3351-4"
x="436.76678"
y="586.62585">time</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.50000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="-551.11292"
y="125.37186"
id="text3353-0"
sodipodi:linespacing="125%"
transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
sodipodi:role="line"
id="tspan4197"
x="-551.11292"
y="125.37186">actual</tspan><tspan
sodipodi:role="line"
id="tspan4199"
x="-551.11292"
y="140.99686">filament</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 152.72419,471.73218 -5.31915,8.51063"
id="path3359-9"
inkscape:connector-curvature="0" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.00000024;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 182.35432,572.94905 c 17.46262,-43.80215 52.67413,-56.54375 92.65253,-60.94329 l 48.57915,-1.06383 c 24.916,55.4715 110.00504,59.23318 151.64398,62.00712"
id="path3361-1"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 150.87843,360.66993 1.06383,102.12766 327.12768,-0.53192 -7.97872,5.85107"
id="path3347-8"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.50000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="-444.27307"
y="124.17301"
id="text3353-6"
sodipodi:linespacing="125%"
transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
sodipodi:role="line"
id="tspan4193"
x="-444.27307"
y="124.17301">desired</tspan><tspan
sodipodi:role="line"
id="tspan4195"
x="-444.27307"
y="139.79802">filament</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 150.87843,360.66993 -5.31915,8.51063"
id="path3359-8"
inkscape:connector-curvature="0" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.00000024;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 180.50856,461.8868 16.05678,-60.94329 120.91958,-1.06383 16.53759,62.00712"
id="path3361-4"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 9.8 KiB

BIN
docs/img/ooze.svg.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 13 KiB

207
docs/img/pressure-advance.svg
View File

@@ -1,207 +0,0 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="102.61139mm"
height="99.266594mm"
viewBox="0 0 363.58366 351.73204"
id="svg2"
version="1.1"
inkscape:version="0.91 r13725"
sodipodi:docname="pressure-advance.svg"
inkscape:export-filename="/home/kevin/src/reprap/firmware/klipper/docs/img/pressure-advance.svg.png"
inkscape:export-xdpi="90"
inkscape:export-ydpi="90">
<defs
id="defs4" />
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="0.97968464"
inkscape:cx="147.06528"
inkscape:cy="169.55487"
inkscape:document-units="px"
inkscape:current-layer="layer1"
showgrid="false"
inkscape:window-width="1091"
inkscape:window-height="588"
inkscape:window-x="419"
inkscape:window-y="273"
inkscape:window-maximized="0"
fit-margin-top="0"
fit-margin-left="0"
fit-margin-right="0"
fit-margin-bottom="0"
showborder="false"
inkscape:snap-global="false"
showguides="false">
<inkscape:grid
type="xygrid"
id="grid3436"
originx="17.089787"
originy="126.61899" />
</sodipodi:namedview>
<metadata
id="metadata7">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title />
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1"
transform="translate(-118.13451,-140.19216)">
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 150.47693,249.82417 0.58688,123.9666 m 0,-21.42857 327.12765,-0.53192 -7.97871,5.85107"
id="path3347"
inkscape:connector-curvature="0"
sodipodi:nodetypes="ccccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.50000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="-334.86746"
y="122.91875"
id="text3353"
sodipodi:linespacing="125%"
transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
sodipodi:role="line"
id="tspan12816"
x="-334.86746"
y="122.91875">extruder</tspan><tspan
sodipodi:role="line"
id="tspan12818"
x="-334.86746"
y="138.54375">velocity</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 150,250.23455 -5.31915,8.51063"
id="path3359"
inkscape:connector-curvature="0" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.00000024;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 316.60647,311.78473 16.53759,62.00711 m -154.57776,-52.12767 16.05677,-60.94328 1.06383,29.78724 m 0,0 120.91957,-1.06383 0,22.34043"
id="path3361"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccccc" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 148.75077,140.45716 1.06383,102.12766 327.12769,-0.53192 -7.97872,5.85107"
id="path3347-6"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.50000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="-237.05733"
y="140.25932"
id="text3353-2"
sodipodi:linespacing="125%"
transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
sodipodi:role="line"
id="tspan12733-6"
x="-237.05733"
y="140.25932">head velocity</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 148.75077,140.45716 -5.31915,8.51063"
id="path3359-7"
inkscape:connector-curvature="0" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.00000024;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 178.3809,241.67403 16.05679,-60.94329 120.91958,-1.06383 16.53759,62.00712"
id="path3361-5"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.78742969px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 331.74721,241.47248 16.72764,-63.00288 133.24332,0"
id="path3361-7-6"
inkscape:connector-curvature="0"
sodipodi:nodetypes="ccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="198.86868"
y="174.67674"
id="text12656-9"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan12658-8"
x="198.86868"
y="174.67674">extrude move</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="355.25165"
y="173.61293"
id="text12660-7"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan12662-2"
x="355.25165"
y="173.61293">non-extrude move</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 151.94226,384.0742 1.06383,102.12766 327.12769,-0.53192 -7.97872,5.85107"
id="path3347-2"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.50000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="-467.65732"
y="122.73453"
id="text3353-1"
sodipodi:linespacing="125%"
transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
sodipodi:role="line"
id="tspan12868"
x="-467.65732"
y="122.73453">extruder</tspan><tspan
sodipodi:role="line"
id="tspan12870"
x="-467.65732"
y="138.35953">pressure</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 151.94226,384.0742 -5.31915,8.51063"
id="path3359-5"
inkscape:connector-curvature="0" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.00000024;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 181.57239,485.29107 16.05679,-60.94329 120.91958,-1.06383 16.53759,62.00712"
id="path3361-9"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.5px;line-height:100%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="438.03586"
y="499.53384"
id="text3349"
sodipodi:linespacing="100%"><tspan
sodipodi:role="line"
id="tspan3351"
x="438.03586"
y="499.53384">time</tspan></text>
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 9.8 KiB

BIN
docs/img/pressure-advance.svg.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 13 KiB

180
docs/img/pressure-cornering.svg
View File

@@ -1,180 +0,0 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="102.04809mm"
height="61.494076mm"
viewBox="0 0 361.58771 217.8924"
id="svg2"
version="1.1"
inkscape:version="0.91 r13725"
sodipodi:docname="pressure-cornering.svg"
inkscape:export-filename="/home/kevin/src/reprap/firmware/klipper/docs/img/pressure-cornering.svg.png"
inkscape:export-xdpi="90"
inkscape:export-ydpi="90">
<defs
id="defs4" />
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="0.98"
inkscape:cx="110.74341"
inkscape:cy="35.715236"
inkscape:document-units="px"
inkscape:current-layer="layer1"
showgrid="false"
inkscape:window-width="1091"
inkscape:window-height="588"
inkscape:window-x="656"
inkscape:window-y="0"
inkscape:window-maximized="0"
fit-margin-top="0"
fit-margin-left="0"
fit-margin-right="0"
fit-margin-bottom="0"
showborder="false"
inkscape:snap-global="false"
showguides="false">
<inkscape:grid
type="xygrid"
id="grid3436"
originx="17.089805"
originy="-7.2206491" />
</sodipodi:namedview>
<metadata
id="metadata7">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title />
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1"
transform="translate(-118.13449,-140.19216)">
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 150,250.23455 1.06383,102.12765 327.12765,-0.53192 -7.97871,5.85107"
id="path3347"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.50000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="-334.86746"
y="122.91875"
id="text3353"
sodipodi:linespacing="125%"
transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
sodipodi:role="line"
id="tspan12816"
x="-334.86746"
y="122.91875">extruder</tspan><tspan
sodipodi:role="line"
id="tspan12818"
x="-334.86746"
y="138.54375">velocity</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 150,250.23455 -5.31915,8.51063"
id="path3359"
inkscape:connector-curvature="0" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.00000024;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 178.5663,321.66417 16.05677,-60.94328 1.06383,29.78724 m 0,0 117.21969,-0.77616 5.99519,7.3871 5.9952,-6.89861 131.50541,-0.77616"
id="path3361"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccccccc" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 148.75077,140.45716 1.06383,102.12766 327.12769,-0.53192 -7.97872,5.85107"
id="path3347-6"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.50000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="-237.05733"
y="140.25932"
id="text3353-2"
sodipodi:linespacing="125%"
transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
sodipodi:role="line"
id="tspan12733-6"
x="-237.05733"
y="140.25932">head velocity</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 148.75077,140.45716 -5.31915,8.51063"
id="path3359-7"
inkscape:connector-curvature="0" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.00000024;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 178.3809,241.67403 16.05679,-60.94329 120.91958,-1.06383 4.29269,10.98671"
id="path3361-5"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 319.50231,193.5133 4.48274,-15.0437 133.24332,0"
id="path3361-7-6"
inkscape:connector-curvature="0"
sodipodi:nodetypes="ccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="198.86868"
y="174.67674"
id="text12656-9"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan12891"
x="198.86868"
y="174.67674">first extrude</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="355.25165"
y="173.61293"
id="text12660-7"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan12893"
x="355.25165"
y="173.61293">second extrude</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:4, 2, 1, 2;stroke-dashoffset:0;stroke-opacity:1"
d="m 314.05288,288.86296 0,17.34694 5.10204,17.34694 -1.02041,-48.97959 7.14286,-17.34694 0,31.63265"
id="path12895"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.5px;line-height:100%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="435.80841"
y="366.8262"
id="text3349"
sodipodi:linespacing="100%"><tspan
sodipodi:role="line"
id="tspan3351"
x="435.80841"
y="366.8262">time</tspan></text>
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 8.4 KiB

BIN
docs/img/pressure-cornering.svg.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 9.6 KiB

132
docs/img/smoothed.svg
View File

@@ -1,132 +0,0 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="97.22496mm"
height="32.550285mm"
viewBox="0 0 344.49789 115.33566"
id="svg2"
version="1.1"
inkscape:version="0.91 r13725"
sodipodi:docname="smoothed.svg">
<defs
id="defs4" />
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="1.75"
inkscape:cx="167.32577"
inkscape:cy="45.708959"
inkscape:document-units="px"
inkscape:current-layer="layer1"
showgrid="false"
inkscape:window-width="840"
inkscape:window-height="628"
inkscape:window-x="162"
inkscape:window-y="50"
inkscape:window-maximized="0"
fit-margin-top="0"
fit-margin-left="0"
fit-margin-right="0"
fit-margin-bottom="0"
showborder="false"
inkscape:snap-global="false"
showguides="false">
<inkscape:grid
type="xygrid"
id="grid3436" />
</sodipodi:namedview>
<metadata
id="metadata7">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title></dc:title>
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1"
transform="translate(-135.22429,-249.96955)">
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 150,250.23455 1.06383,102.12765 327.12765,-0.53192 -7.97871,5.85107"
id="path3347"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.5px;line-height:100%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="434.04257"
y="365.1282"
id="text3349"
sodipodi:linespacing="100%"><tspan
sodipodi:role="line"
id="tspan3351"
x="434.04257"
y="365.1282">time</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.5px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="-313.86618"
y="140.27856"
id="text3353"
sodipodi:linespacing="125%"
transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
sodipodi:role="line"
id="tspan3355"
x="-313.86618"
y="140.27856">velocity</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 150,250.23455 -5.31915,8.51063"
id="path3359"
inkscape:connector-curvature="0" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 165.50998,351.59092 15.42857,-35.42857 35.71428,0 11.71429,36.57143"
id="path3362"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1.07142997px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 227.83578,352.85633 15.76217,-47.37239 22.00135,0 5.58242,17.6933"
id="path3362-3"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1.21482575px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 271.35434,323.73296 11.15454,-30.54076 19.27119,-0.11152 8.73883,29.51288"
id="path3362-6"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1.01949775px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 311.26144,322.49329 11.63197,-21.06975 15.33656,0 13.51652,50.22357"
id="path3362-7"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccc" />
<path
style="fill:none;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1.00000012;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:2.00000012, 1.00000006, 0.50000003, 1.00000006;stroke-dashoffset:0;stroke-opacity:1"
d="m 165.50999,351.59092 33.14285,-34.28571 29.14286,34.28571"
id="path3426"
inkscape:connector-curvature="0"
sodipodi:nodetypes="ccc" />
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 5.5 KiB

BIN
docs/img/smoothed.svg.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.9 KiB

Some files were not shown because too many files have changed in this diff Show More