docs: Update release notes for v0.8.0 release

Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

.gitignore

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

.travis.yml

@@ -0,0 +1,26 @@
+# 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

COPYING

@@ -0,0 +1,674 @@
+                    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>.

Makefile

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

README.md

@@ -0,0 +1,16 @@
+Welcome to the Klipper project!
+
+[![Klipper](docs/img/klipper-logo-small.png)](https://www.klipper3d.org/)
+
+https://www.klipper3d.org/
+
+Klipper is a 3d-Printer firmware. It combines the power of a general
+purpose computer with one or more micro-controllers. See the
+[features document](https://www.klipper3d.org/Features.html) for more
+information on why you should use Klipper.
+
+To begin using Klipper start by
+[installing](https://www.klipper3d.org/Installation.html) it.
+
+Klipper is Free Software. See the [license](COPYING) or read the
+[documentation](https://www.klipper3d.org/Overview.html).

config/avrsim.cfg

@@ -0,0 +1,78 @@
+# 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

config/example-corexy.cfg

@@ -0,0 +1,81 @@
+# 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

config/example-delta.cfg

@@ -0,0 +1,125 @@
+# 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.

config/example-menu.cfg

@@ -0,0 +1,205 @@
+# 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]
+#type: input
+#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 mode, on exit from edit mode
+#   or in edit mode this will be triggered after click button long press (>0.8sec).
+#longpress_gcode:
+#   In edit mode this will be triggered after click button long press (>0.8sec).
+#   The default is empty. This parameter is optional.
+#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 > 0.8s 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.
+#content:
+#   It allows quickly define single card decks by adding content directly to deck.
+#   You have to remove deck item attribute and use named items in content.
+#   The menu functionality will then internally create one card item for this deck.
+#   This is optional.
+
+#[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.
+#   It's possible directly use menu item names in content by leaving items attribute out or empty
+#   and use menu items names directly in content as {msg,xpos|ypos}. The menu functionality will then
+#   internally build a item list and replace names with indexes in content.
+#   This is optional.
+#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.
+#use_cursor:
+#   This attribute accepts static boolean value.
+#   When enabled the menu system uses a cursor instead of blinking to visualize item selection
+#   and edit mode for this card. Cursor and placeholder is always added as item name prefix.
+#   The default is False. This parameter is optional.

config/example-multi-mcu.cfg

@@ -0,0 +1,87 @@
+# 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

config/example-polar.cfg

@@ -0,0 +1,84 @@
+# This file serves as documentation for config parameters of "polar"
+# style printers. One may copy and edit this file to configure a new
+# polar printer.
+
+# POLAR KINEMATICS ARE A WORK IN PROGRESS. Moves around the 0,0
+# position are known to not work properly.
+
+# Only parameters unique to polar printers are described here - see
+# the "example.cfg" file for description of common config parameters.
+
+# The stepper_bed section is used to describe the stepper controlling
+# the bed.
+[stepper_bed]
+step_pin: ar54
+dir_pin: ar55
+enable_pin: !ar38
+step_distance: 0.001963495
+#   On a polar printer the step_distance is the amount each step pulse
+#   moves the bed in radians (for example, a 1.8 degree stepper with
+#   16 micro-steps would be 2 * pi * (1.8 / 360) / 16 == 0.001963495).
+#   This parameter must be provided.
+
+# The stepper_arm section is used to describe the stepper controlling
+# the carriage on the arm.
+[stepper_arm]
+step_pin: ar60
+dir_pin: ar61
+enable_pin: !ar56
+step_distance: .01
+endstop_pin: ^ar14
+position_endstop: 300
+position_max: 300
+homing_speed: 50
+
+# The stepper_z section is used to describe the stepper controlling
+# the Z axis.
+[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: polar
+#   This option must be "polar" for polar printers.
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 25
+max_z_accel: 30

config/example-winch.cfg

@@ -0,0 +1,96 @@
+# This file serves as documentation for config parameters of cable
+# winch style printers. One may copy and edit this file to configure a
+# new cable winch printer.
+
+# CABLE WINCH SUPPORT IS EXPERIMENTAL - PROCEED WITH CAUTION!
+
+# Homing is not implemented on cable winch kinematics. In order to
+# home the printer, manually send movement commands until the toolhead
+# is at 0,0,0 and then issue a G28 command.
+
+# Only parameters unique to cable winch printers are described here -
+# see the "example.cfg" file for description of common config
+# parameters.
+
+# The stepper_a section describes the stepper connected to the first
+# cable winch. A minimum of 3 and a maximum of 26 cable winches may be
+# defined (stepper_a to stepper_z) though it is common to define 4.
+[stepper_a]
+step_pin: ar54
+dir_pin: ar55
+enable_pin: !ar38
+step_distance: .01
+#   The step_distance is the nominal distance (in mm) the toolhead
+#   moves towards the cable winch on each step pulse. This parameter
+#   must be provided.
+anchor_x: 0
+anchor_y: -2000
+anchor_z: -100
+#   The x, y, and z position of the cable winch in cartesian space.
+#   These parameters must be provided.
+
+[stepper_b]
+step_pin: ar60
+dir_pin: ar61
+enable_pin: !ar56
+step_distance: .01
+anchor_x: 2000
+anchor_y: 1000
+anchor_z: -100
+
+[stepper_c]
+step_pin: ar46
+dir_pin: ar48
+enable_pin: !ar62
+step_distance: .01
+anchor_x: -2000
+anchor_y: 1000
+anchor_z: -100
+
+[stepper_d]
+step_pin: ar36
+dir_pin: ar34
+enable_pin: !ar30
+step_distance: .01
+anchor_x: 0
+anchor_y: 0
+anchor_z: 3000
+
+[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: winch
+#   This option must be "winch" for cable winch printers.
+max_velocity: 300
+max_accel: 3000

config/example.cfg

@@ -0,0 +1,337 @@
+# 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. If the micro-controller supports
+# pull-down resistors then an input pin may alternatively be preceded
+# by a '~'.
+
+
+# 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). Alternatively, this may be a comma separated list of pins to
+#   enable. 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.
+#inline_resistor: 0
+#   The resistance (in ohms) of an extra (not heat varying) resistor
+#   that is placed inline with the thermistor. It is rare to set this.
+#   This parameter is only valid when the sensor is a thermistor. The
+#   default is 0 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. Most fans
+#   do not work well with hardware PWM, so it is not recommended to
+#   enable this unless there is an electrical requirement to switch at
+#   very high speeds. When using hardware PWM the actual cycle time is
+#   constrained by the implementation and may be significantly
+#   different than the requested cycle_time. 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.
+#off_below: 0.0
+#   The minimum input speed which will power the fan (expressed as a
+#   value from 0.0 to 1.0). When a speed lower than off_below is
+#   requested the fan will instead be turned off. This setting may be
+#   used to prevent fan stalls and to ensure kick starts are
+#   effective. The default is 0.0.
+#
+#   This setting should be recalibrated whenever max_power is adjusted.
+#   To calibrate this setting, start with off_below set to 0.0 and the
+#   fan spinning. Gradually lower the fan speed to determine the lowest
+#   input speed which reliably drives the fan without stalls. Set
+#   off_below to the duty cycle corresponding to this value (for
+#   example, 12% -> 0.12) or slightly higher.
+
+# 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.

config/generic-azteeg-x5-mini-v3.cfg

@@ -0,0 +1,90 @@
+# This file contains common pin mappings for the Azteeg X5 Mini v3. To use
+# this config, the firmware should be compiled for the LPC1769.
+
+# 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
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: P2.2
+dir_pin: P0.20
+enable_pin: !P0.19
+step_distance: .0125
+endstop_pin: ^P1.26
+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: .0125
+endstop_pin: ^P1.28
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[extruder]
+step_pin: P2.0
+dir_pin: P0.5
+enable_pin: !P0.4
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: P2.5
+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
+
+[heater_bed]
+heater_pin: P2.7
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: P0.23
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: P0.26
+
+[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
+
+[mcp4451 stepper_digipot1]
+i2c_address: 44
+# Scale the config so that wiper values can be specified in amps.
+scale: 2
+# 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
+
+# Mini Viki2 LCD - this board does not work with Reprap LCDs
+#[display]
+#lcd_type: uc1701
+#cs_pin: P0.16
+#a0_pin: P2.6
+#encoder_pins: ^!P3.25, ^P3.26
+#click_pin: ^!P2.11

config/generic-bigtreetech-skr-mini-e3.cfg

@@ -0,0 +1,129 @@
+# This file contains common pin mappings for the BIGTREETECH SKR mini
+# E3. To use this config, the firmware should be compiled for the
+# STM32F103 with a "28KiB bootloader". Also, select "Enable extra
+# low-level configuration options" and configure "GPIO pins to set at
+# micro-controller startup" to "!PC13".
+
+# The "make flash" command does not work on the SKR mini E3. 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 SKR
+# mini E3 with that SD card.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PB13
+dir_pin: !PB12
+enable_pin: !PB14
+step_distance: .0125
+endstop_pin: ^PC0
+position_endstop: 0
+position_max: 235
+homing_speed: 50
+
+[tmc2209 stepper_x]
+uart_pin: PC11
+tx_pin: PC10
+uart_address: 0
+microsteps: 16
+run_current: 0.580
+hold_current: 0.500
+stealthchop_threshold: 250
+
+[stepper_y]
+step_pin: PB10
+dir_pin: !PB2
+enable_pin: !PB11
+step_distance: .0125
+endstop_pin: ^PC1
+position_endstop: 0
+position_max: 235
+homing_speed: 50
+
+[tmc2209 stepper_y]
+uart_pin: PC11
+tx_pin: PC10
+uart_address: 1
+microsteps: 16
+run_current: 0.580
+hold_current: 0.500
+stealthchop_threshold: 250
+
+[stepper_z]
+step_pin: PB0
+dir_pin: PC5
+enable_pin: !PB1
+step_distance: .0025
+endstop_pin: ^PC2
+position_endstop: 0.0
+position_max: 250
+
+[tmc2209 stepper_z]
+uart_pin: PC11
+tx_pin: PC10
+uart_address: 2
+microsteps: 16
+run_current: 0.580
+hold_current: 0.500
+stealthchop_threshold: 5
+
+[extruder]
+step_pin: PB3
+dir_pin: !PB4
+enable_pin: !PD2
+step_distance: 0.010526
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PC8
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PA0
+control: pid
+pid_Kp: 21.527
+pid_Ki: 1.063
+pid_Kd: 108.982
+min_temp: 0
+max_temp: 250
+
+[tmc2209 extruder]
+uart_pin: PC11
+tx_pin: PC10
+uart_address: 3
+microsteps: 16
+run_current: 0.650
+hold_current: 0.500
+stealthchop_threshold: 5
+
+[heater_bed]
+heater_pin: PC9
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: PC3
+control: pid
+pid_Kp: 54.027
+pid_Ki: 0.770
+pid_Kd: 948.182
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PA8
+
+[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 usb_pullup_enable]
+pins: !PC13
+
+[board_pins]
+aliases:
+    # EXP1 header
+    EXP1_1=PB5, EXP1_3=PA9,   EXP1_5=PA10, EXP1_7=PB8, EXP1_9=<GND>,
+    EXP1_2=PB6, EXP1_4=<RST>, EXP1_6=PB9,  EXP1_8=PB7, EXP1_10=<5V>
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.

config/generic-bigtreetech-skr-mini.cfg

@@ -0,0 +1,88 @@
+# This file contains common pin mappings for the BIGTREETECH SKR
+# MINI. To use this config, the firmware should be compiled for the
+# STM32F103 with a "28KiB bootloader".
+
+# The "make flash" command does not work on the SKR mini. 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 SKR
+# mini with that SD card.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PC6
+dir_pin: PC7
+enable_pin: !PB15
+step_distance: .0025
+endstop_pin: PC2 # X+ is PA2
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: PB13
+dir_pin: PB14
+enable_pin: !PB12
+step_distance: .0025
+endstop_pin: PC1 # Y+ is PA1
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: PB10
+dir_pin: PB11
+enable_pin: !PB2
+step_distance: .0125
+endstop_pin: PC0 # Z+ is PC3
+position_endstop: 0.5
+position_max: 200
+
+[extruder]
+step_pin: PC5
+dir_pin: PB0
+enable_pin: !PC4
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PA8
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PA0
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+#[heater_bed]
+#heater_pin: PC9
+#sensor_type: ATC Semitec 104GT-2
+#sensor_pin: PB1
+#control: watermark
+#min_temp: 0
+#max_temp: 130
+
+[fan]
+pin: PC8
+
+[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
+
+[board_pins]
+aliases:
+    # EXP1 header
+    EXP1_1=PC10, EXP1_3=PB6,  EXP1_5=PC13, EXP1_7=PC15, EXP1_9=<GND>,
+    EXP1_2=PC11, EXP1_4=PC12, EXP1_6=PB7,  EXP1_8=PC14, EXP1_10=<5V>,
+    # EXP2 header
+    EXP2_1=PB4, EXP2_3=PD2,  EXP2_5=PB8, EXP2_7=PB9,   EXP2_9=<GND>,
+    EXP2_2=PB3, EXP2_4=PA15, EXP2_6=PB5, EXP2_8=<RST>, EXP2_10=<NC>
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.

config/generic-bigtreetech-skr-pro.cfg

@@ -0,0 +1,222 @@
+# This file contains common pin mappings for the BigTreeTech SKR PRO.
+# To use this config, the firmware should be compiled for the
+# STM32F407 with a "32KiB bootloader".
+
+# The "make flash" command does not work on the SKR PRO. 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 SKR PRO
+# with that SD card.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PE9
+dir_pin: PF1
+enable_pin: !PF2
+step_distance: .0025
+endstop_pin: PB10
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: PE11
+dir_pin: PE8
+enable_pin: !PD7
+step_distance: .0025
+endstop_pin: PE12
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: PE13
+dir_pin: PC2
+enable_pin: !PC0
+step_distance: .0125
+endstop_pin: PG8
+position_endstop: 0.5
+position_max: 200
+
+[extruder]
+step_pin: PE14
+dir_pin: PA0
+enable_pin: !PC3
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PB1 # Heat0
+sensor_pin: PF3 # T0 Header
+sensor_type: EPCOS 100K B57560G104F
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+#[extruder1]
+#step_pin: PD15
+#dir_pin: PE7
+#enable_pin: !PA3
+#heater_pin: PD14 # Heat1
+#sensor_pin: PF4 # T1
+#...
+
+#[extruder2]
+#step_pin: PD13
+#dir_pin: PG9
+#enable_pin: !PF0
+#heater_pin: PB0 # Heat2
+#sensor_pin: PF5 # T2
+#...
+
+[heater_bed]
+heater_pin: PD12
+sensor_pin: PF6 # T3
+sensor_type: ATC Semitec 104GT-2
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PC8
+
+[heater_fan fan1]
+pin: PE5
+
+#[heater_fan fan2]
+#pin: PE6
+
+[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
+
+
+########################################
+# TMC2208 configuration
+########################################
+
+#[tmc2208 stepper_x]
+#uart_pin: PC13
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2208 stepper_y]
+#uart_pin: PE3
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2208 stepper_z]
+#uart_pin: PE1
+#microsteps: 16
+#run_current: 0.650
+#hold_current: 0.450
+#stealthchop_threshold: 30
+
+#[tmc2208 extruder]
+#uart_pin: PD4
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+#[tmc2208 extruder1]
+#uart_pin: PD1
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+#[tmc2208 extruder2]
+#uart_pin: PD6
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+
+########################################
+# TMC2130 configuration
+########################################
+
+#[tmc2130 stepper_x]
+#cs_pin: PA15
+#spi_bus: spi3a
+##diag1_pin: PB10
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2130 stepper_y]
+#cs_pin: PB8
+#spi_bus: spi3a
+##diag1_pin: PE12
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2130 stepper_z]
+#cs_pin: PB9
+#spi_bus: spi3a
+##diag1_pin: PG8
+#microsteps: 16
+#run_current: 0.650
+#hold_current: 0.450
+#stealthchop_threshold: 30
+
+#[tmc2130 extruder]
+#cs_pin: PB3
+#spi_bus: spi3a
+##diag1_pin: PE15
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+#[tmc2130 extruder1]
+#cs_pin: PG15
+#spi_bus: spi3a
+##diag1_pin: PE10
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+#[tmc2130 extruder2]
+#cs_pin: PG12
+#spi_bus: spi3a
+##diag1_pin: PG5
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+
+########################################
+# EXP1 / EXP2 (display) pins
+########################################
+
+[board_pins]
+aliases:
+    # EXP1 header
+    EXP1_1=PG4, EXP1_3=PD11, EXP1_5=PG2, EXP1_7=PG6, EXP1_9=<GND>,
+    EXP1_2=PA8, EXP1_4=PD10, EXP1_6=PG3, EXP1_8=PG7, EXP1_10=<5V>,
+    # EXP2 header
+    EXP2_1=PB14, EXP2_3=PG10, EXP2_5=PF11, EXP2_7=PF12,  EXP2_9=<GND>,
+    EXP2_2=PB13, EXP2_4=PB12, EXP2_6=PB15, EXP2_8=<RST>, EXP2_10=PF13
+    # Pins EXP2_1, EXP2_6, EXP2_2 are also MISO, MOSI, SCK of bus "spi2"
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.

config/generic-bigtreetech-skr-v1.1.cfg

@@ -0,0 +1,91 @@
+# This file contains common pin mappings for the BIGTREETECH SKR V1.1
+# board. To use this config, the firmware should be compiled for the
+# LPC1768.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: P0.4
+dir_pin: !P0.5
+enable_pin: !P4.28
+step_distance: .0025
+endstop_pin: P1.29
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: P2.1
+dir_pin: P2.2
+enable_pin: !P2.0
+step_distance: .0025
+endstop_pin: P1.27
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: P0.20
+dir_pin: P0.21
+enable_pin: !P0.19
+step_distance: .0125
+endstop_pin: !P1.25
+position_endstop: 0.5
+position_max: 200
+
+#[stepper_z1]
+#step_pin: P0.1
+#dir_pin: P0.0
+#enable_pin: !P0.10
+#position_endstop: 0.5
+#position_max: 200
+
+[extruder]
+step_pin: P0.11
+dir_pin: P2.13
+enable_pin: !P2.12
+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
+
+[heater_bed]
+heater_pin: P2.5
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: P0.23
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: P2.3
+
+[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
+
+[board_pins]
+aliases:
+    # EXP1 header
+    EXP1_1=P1.30, EXP1_3=P0.18, EXP1_5=P0.15, EXP1_7=<NC>, EXP1_9=<GND>,
+    EXP1_2=P2.11, EXP1_4=P0.16, EXP1_6=<NC>,  EXP1_8=<NC>, EXP1_10=<5V>,
+    # EXP2 header
+    EXP2_1=P0.17, EXP2_3=P3.26, EXP2_5=P3.25, EXP2_7=P1.31, EXP2_9=<GND>,
+    EXP2_2=P0.15, EXP2_4=P1.23, EXP2_6=P0.18, EXP2_8=<RST>, EXP2_10=<NC>
+    # Pins EXP2_1, EXP2_6, EXP2_2 are also MISO, MOSI, SCK of bus "ssp0"
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.

config/generic-bigtreetech-skr-v1.3.cfg

@@ -0,0 +1,205 @@
+# This file contains common pin mappings for the BIGTREETECH SKR V1.3
+# board. To use this config, the firmware should be compiled for the
+# LPC1768.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: P2.2
+dir_pin: !P2.6
+enable_pin: !P2.1
+step_distance: .0125
+endstop_pin: P1.29  # P1.28 for X-max
+position_endstop: 0
+position_max: 320
+homing_speed: 50
+
+[stepper_y]
+step_pin: P0.19
+dir_pin: !P0.20
+enable_pin: !P2.8
+step_distance: .0125
+endstop_pin: P1.27  # P1.26 for Y-max
+position_endstop: 0
+position_max: 300
+homing_speed: 50
+
+[stepper_z]
+step_pin: P0.22
+dir_pin: P2.11
+enable_pin: !P0.21
+step_distance: .0025
+endstop_pin: P1.25  # P1.24 for Z-max
+position_endstop: 0.5
+position_max: 400
+
+[extruder]
+step_pin: P2.13
+dir_pin: !P0.11
+enable_pin: !P2.12
+step_distance: .010526
+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: 260
+
+#[extruder1]
+#step_pin: P0.1
+#dir_pin: P0.0
+#enable_pin: !P0.10
+#heater_pin: P2.4
+#sensor_pin: P0.25
+#...
+
+[heater_bed]
+heater_pin: P2.5
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: P0.23
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: P2.3
+
+[mcu]
+serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
+
+[printer]
+kinematics: cartesian
+max_velocity: 200
+max_accel: 2000
+max_z_velocity: 25
+max_z_accel: 100
+
+
+########################################
+# TMC2208 configuration
+########################################
+
+# For TMC2208 UART
+#   1) Remove all of the jumpers below the stepper drivers
+#   2) Place jumpers on the red pin headers labeled XUART (XUART, YUART etc.)
+
+#[tmc2208 stepper_x]
+#uart_pin: P1.17
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2208 stepper_y]
+#uart_pin: P1.15
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2208 stepper_z]
+#uart_pin: P1.10
+#microsteps: 16
+#run_current: 0.650
+#hold_current: 0.450
+#stealthchop_threshold: 30
+
+#[tmc2208 extruder]
+#uart_pin: P1.8
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+#[tmc2208 extruder1]
+#uart_pin: P1.1
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+
+########################################
+# TMC2130 configuration
+########################################
+
+# For TMC SPI
+#   1) Place jumpers on all the red pin headers under the stepper drivers
+#   2) Remove jumpers from the red pin headers labeled XUART (XUART, YUART etc.)
+
+#[tmc2130 stepper_x]
+#cs_pin: P1.17
+#spi_software_miso_pin: P0.5
+#spi_software_mosi_pin: P4.28
+#spi_software_sclk_pin: P0.4
+##diag1_pin: P1.29
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2130 stepper_y]
+#cs_pin: P1.15
+#spi_software_miso_pin: P0.5
+#spi_software_mosi_pin: P4.28
+#spi_software_sclk_pin: P0.4
+##diag1_pin: P1.27
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2130 stepper_z]
+#cs_pin: P1.10
+#spi_software_miso_pin: P0.5
+#spi_software_mosi_pin: P4.28
+#spi_software_sclk_pin: P0.4
+##diag1_pin: P1.25
+#microsteps: 16
+#run_current: 0.650
+#hold_current: 0.450
+#stealthchop_threshold: 30
+
+#[tmc2130 extruder]
+#cs_pin: P1.8
+#spi_software_miso_pin: P0.5
+#spi_software_mosi_pin: P4.28
+#spi_software_sclk_pin: P0.4
+##diag1_pin: P1.28
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+#[tmc2130 extruder1]
+#cs_pin: P1.1
+#spi_software_miso_pin: P0.5
+#spi_software_mosi_pin: P4.28
+#spi_software_sclk_pin: P0.4
+##diag1_pin: P1.26
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+
+########################################
+# EXP1 / EXP2 (display) pins
+########################################
+
+[board_pins]
+aliases:
+    # EXP1 header
+    EXP1_1=P1.30, EXP1_3=P1.18, EXP1_5=P1.20, EXP1_7=P1.22, EXP1_9=<GND>,
+    EXP1_2=P0.28, EXP1_4=P1.19, EXP1_6=P1.21, EXP1_8=P1.23, EXP1_10=<5V>,
+    # EXP2 header
+    EXP2_1=P0.17, EXP2_3=P3.26, EXP2_5=P3.25, EXP2_7=P1.31, EXP2_9=<GND>,
+    EXP2_2=P0.15, EXP2_4=P0.16, EXP2_6=P0.18, EXP2_8=<RST>, EXP2_10=<NC>
+    # Pins EXP2_1, EXP2_6, EXP2_2 are also MISO, MOSI, SCK of bus "ssp0"
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.

config/generic-cramps.cfg

@@ -0,0 +1,89 @@
+# 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

config/generic-duet2-duex.cfg

@@ -0,0 +1,371 @@
+# This file contains common pin mappings for Duet2 Eth/Wifi boards
+# that have the Duex expansion board. 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    |  PC0     |  PD27     |  PA17*       |  PB14       |
+# 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]
+#i2c_address: 62
+#
+## 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
+# 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, tmc2660_stepper_x:virtual_enable
+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: usart1 # All TMC2660 drivers are connected to USART1
+microsteps: 16
+interpolate: True # 1/16 micro-steps interpolated to 1/256
+run_current: 1.000
+sense_resistor: 0.051
+idle_current_percent: 20
+
+[stepper_y]
+step_pin: PD7
+dir_pin: !PD12
+enable_pin: !PC6, tmc2660_stepper_y:virtual_enable
+step_distance: .0125
+endstop_pin: ^PA2
+position_endstop: 0
+position_max: 210
+
+[tmc2660 stepper_y]
+cs_pin: PC9
+spi_bus: usart1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+sense_resistor: 0.051
+idle_current_percent: 20
+
+[stepper_z]
+step_pin: PD8
+dir_pin: PD13
+enable_pin: !PC6, tmc2660_stepper_z:virtual_enable
+step_distance: .0025
+endstop_pin: ^PD29
+position_endstop: 0.5
+position_max: 200
+
+[tmc2660 stepper_z]
+cs_pin: PC10
+spi_bus: usart1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+sense_resistor: 0.051
+
+#On drive E4
+[stepper_z1]
+step_pin: PD0
+dir_pin: PD16
+enable_pin: !PC6, tmc2660_stepper_z1:virtual_enable
+step_distance: .0025
+
+[tmc2660 stepper_z1]
+cs_pin: PD25
+spi_bus: usart1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+sense_resistor: 0.051
+
+#On drive E5
+[stepper_z2]
+step_pin: PD3
+dir_pin: !PD17
+enable_pin: !PC6, tmc2660_stepper_z2:virtual_enable
+step_distance: .0025
+
+[tmc2660 stepper_z2]
+cs_pin: PD26
+spi_bus: usart1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+sense_resistor: 0.051
+
+#On drive E6
+[stepper_z3]
+step_pin: PD27
+dir_pin: !PC0
+enable_pin: !PC6, tmc2660_stepper_z3:virtual_enable
+step_distance: .0025
+
+[tmc2660 stepper_z3]
+cs_pin: PB14
+spi_bus: usart1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+sense_resistor: 0.051
+
+#On drive E0
+[extruder0]
+step_pin: PD5
+dir_pin: PA1
+enable_pin: !PC6, tmc2660_extruder0:virtual_enable
+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: usart1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+sense_resistor: 0.051
+
+#On drive E1
+[extruder1]
+step_pin: PD4
+dir_pin: PD9
+enable_pin: !PC6, tmc2660_extruder1:virtual_enable
+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: usart1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+sense_resistor: 0.051
+
+# On drive E2
+[extruder2]
+step_pin: PD2
+dir_pin: !PD28
+enable_pin: !PC6, tmc2660_extruder2:virtual_enable
+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: usart1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+sense_resistor: 0.051
+
+# On drive E3
+[extruder3]
+step_pin: PD1
+dir_pin: !PD22
+enable_pin: !PC6, tmc2660_extruder3:virtual_enable
+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: usart1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+sense_resistor: 0.051
+
+[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/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
+
+[sx1509 duex]
+i2c_address: 62 # 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

config/generic-duet2-maestro.cfg

@@ -0,0 +1,148 @@
+# This file contains common pin mappings for the Duet2 Maestro. To use
+# this config, the firmware should be compiled for the sam4s8c.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PC20
+dir_pin: PC18
+enable_pin: !PA1, tmc2208_stepper_x:virtual_enable
+step_distance: .0125
+endstop_pin: ^PA24
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[tmc2208 stepper_x]
+uart_pin: PA9
+tx_pin: PA10
+select_pins: !PC14, !PC16, !PC17
+sense_resistor: 0.075
+microsteps: 16
+run_current: 0.800
+stealthchop_threshold: 250
+
+[stepper_y]
+step_pin: PC2
+dir_pin: PA8
+enable_pin: !PA1, tmc2208_stepper_y:virtual_enable
+step_distance: .0125
+endstop_pin: ^PB6
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[tmc2208 stepper_y]
+uart_pin: PA9
+tx_pin: PA10
+select_pins: PC14, !PC16, !PC17
+sense_resistor: 0.075
+microsteps: 16
+run_current: 0.800
+stealthchop_threshold: 250
+
+[stepper_z]
+step_pin: PC28
+dir_pin: PB4
+enable_pin: !PA1, tmc2208_stepper_z:virtual_enable
+step_distance: .0025
+endstop_pin: ^PC10
+position_endstop: 0.5
+position_max: 200
+
+[tmc2208 stepper_z]
+uart_pin: PA9
+tx_pin: PA10
+select_pins: !PC14, PC16, !PC17
+sense_resistor: 0.075
+microsteps: 16
+run_current: 0.800
+stealthchop_threshold: 30
+
+[extruder]
+step_pin: PC4
+dir_pin: PB7
+enable_pin: !PA1, tmc2208_extruder:virtual_enable
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: !PC1
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PB0
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[tmc2208 extruder]
+uart_pin: PA9
+tx_pin: PA10
+select_pins: PC14, PC16, !PC17
+sense_resistor: 0.075
+microsteps: 16
+run_current: 0.800
+stealthchop_threshold: 5
+
+#[extruder1]
+#step_pin: PC5
+#dir_pin: PC6
+#enable_pin: !PA1
+#heater_pin: !PA16
+#sensor_pin: PC30
+#...
+#[tmc2208 extruder1]
+#select_pins: !PC14, !PC16, PC17
+#sense_resistor: 0.075
+#...
+
+# External steppers
+# e2: step_pin=PC31 dir_pin=PA18 enable_pin=PC27 select_pins=PC14,!PC16,PC17
+# e3: step_pin=PC21 dir_pin=PC24 enable_pin=PC25 select_pins=!PC14,PC16,PC17
+# e0_stop: endstop_pin=PA25
+# e1_stop: endstop_pin=PC7
+# c_temp: sensor_pin=PB1
+
+[heater_bed]
+heater_pin: !PC0
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PA20
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PC23  # FAN0
+
+#[heater_fan nozzle_cooling_fan]
+#pin: PC22  # FAN1
+
+#[heater_fan board_cooling_fan]
+#pin: PC29  # FAN2
+
+[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 led]
+pins: !PC26
+
+# EXP1 / EXP2 (display) pins
+[board_pins]
+aliases:
+    # EXP1 header
+    EXP1_1=PA15, EXP1_3=PA6, EXP1_5=PA2,  EXP1_7=<NC>, EXP1_9=<GND>,
+    EXP1_2=PA7,  EXP1_4=PC9, EXP1_6=<NC>, EXP1_8=<NC>, EXP1_10=<5V>,
+    # EXP2 header
+    EXP2_1=PA5, EXP2_3=PC3,  EXP2_5=PB5, EXP2_7=<NC>,  EXP2_9=<GND>,
+    EXP2_2=PA2, EXP2_4=PB13, EXP2_6=PA6, EXP2_8=<RST>, EXP2_10=<NC>
+    # Pins EXP2_1, EXP2_6, EXP2_2 are also MISO, MOSI, SCK of bus "usart0"
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.

config/generic-duet2.cfg

@@ -0,0 +1,118 @@
+# This file contains common pin mappings for Duet2 Eth/Wifi boards. To
+# use this config, the firmware should be compiled for the SAM4E8E.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PD6
+dir_pin: PD11
+enable_pin: !PC6, tmc2660_stepper_x:virtual_enable
+step_distance: .0125
+endstop_pin: ^PC14
+position_endstop: 0
+position_max: 250
+
+[tmc2660 stepper_x]
+cs_pin: PD14
+spi_bus: usart1
+microsteps: 16
+run_current: 1.000
+sense_resistor: 0.051
+
+[stepper_y]
+step_pin: PD7
+dir_pin: !PD12
+enable_pin: !PC6, tmc2660_stepper_y:virtual_enable
+step_distance: .0125
+endstop_pin: ^PA2
+position_endstop: 0
+position_max: 210
+
+[tmc2660 stepper_y]
+cs_pin: PC9
+spi_bus: usart1
+microsteps: 16
+run_current: 1.000
+sense_resistor: 0.051
+
+[stepper_z]
+step_pin: PD8
+dir_pin: PD13
+enable_pin: !PC6, tmc2660_stepper_z:virtual_enable
+step_distance: .0025
+endstop_pin: ^PD29
+#endstop_pin: PD10  # E0 endstop
+#endstop_pin: PC16  # E1 endstop
+position_endstop: 0.5
+position_max: 200
+
+[tmc2660 stepper_z]
+cs_pin: PC10
+spi_bus: usart1
+microsteps: 16
+run_current: 1.000
+sense_resistor: 0.051
+
+[extruder]
+step_pin: PD5
+dir_pin: PA1
+enable_pin: !PC6, tmc2660_extruder:virtual_enable
+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 extruder]
+cs_pin: PC17
+spi_bus: usart1
+microsteps: 16
+run_current: 1.000
+sense_resistor: 0.051
+
+#[extruder1]
+#step_pin: PD4
+#dir_pin: PD9
+#enable_pin: !PC6, tmc2660_extruder1:virtual_enable
+#heater_pin: !PA16
+#sensor_pin: PC12
+#...
+#[tmc2660 extruder1]
+#cs_pin: PC25
+#spi_bus: usart1
+#sense_resistor: 0.051
+#...
+
+[heater_bed]
+heater_pin: !PA19
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC13
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PC23  # FAN0
+
+#[heater_fan nozzle_cooling_fan]
+#pin: PC26  # FAN1
+
+#[heater_fan board_cooling_fan]
+#pin: PA0  # FAN2
+
+[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

config/generic-einsy-rambo.cfg

@@ -0,0 +1,106 @@
+# 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

config/generic-fysetc-cheetah-v1.1.cfg

@@ -0,0 +1,125 @@
+# This file contains common pin mappings for the Fysetc Cheetah v1.1
+# board. To use this config, the firmware should be compiled for the
+# STM32F103 with "No bootloader" and with "Use USB for communication"
+# disabled.
+
+# The "make flash" command does not work on the Cheetah. Instead,
+# after running "make", run the following command to flash the board:
+#  stm32flash -w out/klipper.bin -v -i rts,-dtr,dtr /dev/ttyUSB0
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PB8
+dir_pin: !PB9
+enable_pin: !PA8
+step_distance: .0125
+endstop_pin: ^PA1
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[tmc2209 stepper_x]
+uart_pin: PA3
+tx_pin: PA2
+uart_address: 0
+microsteps: 16
+run_current: 0.800
+hold_current: 0.500
+stealthchop_threshold: 250
+
+[stepper_y]
+step_pin: PB2
+dir_pin: !PB3
+enable_pin: !PB1
+step_distance: .0125
+endstop_pin: ^PB4
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[tmc2209 stepper_y]
+uart_pin: PA3
+tx_pin: PA2
+uart_address: 1
+microsteps: 16
+run_current: 0.800
+hold_current: 0.500
+stealthchop_threshold: 250
+
+[stepper_z]
+step_pin: PC0
+dir_pin: PC1
+enable_pin: !PC2
+step_distance: .0025
+endstop_pin: ^PA15
+position_endstop: 0
+position_max: 200
+
+[tmc2209 stepper_z]
+uart_pin: PA3
+tx_pin: PA2
+uart_address: 2
+microsteps: 16
+run_current: 0.800
+hold_current: 0.500
+stealthchop_threshold: 5
+
+[extruder]
+step_pin: PC15
+dir_pin: !PC14
+enable_pin: !PC13
+step_distance: 0.010526
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PC6
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC4
+control: pid
+pid_kp: 21.527
+pid_ki: 1.063
+pid_kd: 108.982
+min_temp: 0
+max_temp: 250
+
+[tmc2209 extruder]
+uart_pin: PA3
+tx_pin: PA2
+uart_address: 3
+microsteps: 16
+run_current: 1.0
+hold_current: 0.500
+stealthchop_threshold: 5
+
+[heater_bed]
+heater_pin: PC7
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC5
+control: pid
+pid_kp: 54.027
+pid_ki: 0.770
+pid_kd: 948.182
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PC8
+
+[mcu]
+serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[board_pins]
+aliases:
+    # EXP1 header
+    EXP1_1=PC9,  EXP1_3=PC11, EXP1_5=PC10, EXP1_7=PB12, EXP1_9=<GND>,
+    EXP1_2=PC12, EXP1_4=PB14, EXP1_6=PB13, EXP1_8=PB15, EXP1_10=<5V>
+    # Pins EXP1_4, EXP1_8, EXP1_6 are also MISO, MOSI, SCK of bus "spi2"
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.

config/generic-fysetc-cheetah-v1.2.cfg

@@ -0,0 +1,121 @@
+# This file contains common pin mappings for the Fysetc Cheetah v1.2b
+# board. To use this config, the firmware should be compiled for the
+# STM32F103 with "No bootloader" and with "Use USB for communication"
+# disabled.
+
+# The "make flash" command does not work on the Cheetah. Instead,
+# after running "make", run the following command to flash the board:
+#  stm32flash -w out/klipper.bin -v -i rts,-dtr,dtr /dev/ttyUSB0
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PB8
+dir_pin: !PB9
+enable_pin: !PA8
+step_distance: .0125
+endstop_pin: ^PA1
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[tmc2208 stepper_x]
+uart_pin: PA12
+tx_pin: PA11
+microsteps: 16
+run_current: 0.800
+hold_current: 0.500
+stealthchop_threshold: 250
+
+[stepper_y]
+step_pin: PB2
+dir_pin: !PB3
+enable_pin: !PB1
+step_distance: .0125
+endstop_pin: ^PB4
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[tmc2208 stepper_y]
+uart_pin: PB7
+tx_pin: PB6
+microsteps: 16
+run_current: 0.800
+hold_current: 0.500
+stealthchop_threshold: 250
+
+[stepper_z]
+step_pin: PC0
+dir_pin: PC1
+enable_pin: !PC2
+step_distance: .0025
+endstop_pin: ^PA15
+position_endstop: 0
+position_max: 200
+
+[tmc2208 stepper_z]
+uart_pin: PB11
+tx_pin: PB10
+microsteps: 16
+run_current: 0.800
+hold_current: 0.500
+stealthchop_threshold: 5
+
+[extruder]
+step_pin: PC15
+dir_pin: !PC14
+enable_pin: !PC13
+step_distance: 0.010526
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PC6
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC4
+control: pid
+pid_kp: 21.527
+pid_ki: 1.063
+pid_kd: 108.982
+min_temp: 0
+max_temp: 250
+
+[tmc2208 extruder]
+uart_pin: PA3
+tx_pin: PA2
+microsteps: 16
+run_current: 1.0
+hold_current: 0.500
+stealthchop_threshold: 5
+
+[heater_bed]
+heater_pin: PC7
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC5
+control: pid
+pid_kp: 54.027
+pid_ki: 0.770
+pid_kd: 948.182
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PC8
+
+[mcu]
+serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[board_pins]
+aliases:
+    # EXP1 header
+    EXP1_1=PC9,  EXP1_3=PC11, EXP1_5=PC10, EXP1_7=PB12, EXP1_9=<GND>,
+    EXP1_2=PC12, EXP1_4=PB14, EXP1_6=PB13, EXP1_8=PB15, EXP1_10=<5V>
+    # Pins EXP1_4, EXP1_8, EXP1_6 are also MISO, MOSI, SCK of bus "spi2"
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.

config/generic-fysetc-f6.cfg

@@ -0,0 +1,306 @@
+# This file contains common pin mappings for a Fysetc F6 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_x]
+step_pin: PF0
+dir_pin: PF1
+enable_pin: !PD7
+step_distance: .0125
+endstop_pin: PK1  # PK2 for X-max
+position_endstop: 0
+position_max: 200
+
+[stepper_y]
+step_pin: PF6
+dir_pin: PF7
+enable_pin: !PF2
+step_distance: .0125
+endstop_pin: PJ1  # PJ0 for Y-max
+position_endstop: 0
+position_max: 200
+
+[stepper_z]
+step_pin: PL6
+dir_pin: PL1
+enable_pin: !PF4
+step_distance: .0025
+endstop_pin: PB6  # PE4 for Z-max
+position_endstop: 0
+position_max: 400
+
+[extruder]
+step_pin: PA4
+dir_pin: !PA6
+enable_pin: !PA2
+step_distance: .01
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PE3
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PK4
+control: pid
+pid_Kp: 22
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 260
+
+#[extruder1]
+#step_pin: PC1
+#dir_pin: !PC3
+#enable_pin: !PC7
+#heater_pin: PH3
+#sensor_pin: PK5
+
+#[extruder2]
+#step_pin: PF5
+#dir_pin: !PF3
+#enable_pin: !PG1
+#heater_pin: PH4
+#sensor_pin: PK6
+
+[heater_bed]
+heater_pin: PH5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PK7
+control: watermark
+min_temp: 0
+max_temp: 130
+
+#fan for printed model FAN0
+[fan]
+pin: PL5
+
+#fan for hotend FAN1
+#[heater_fan my_nozzle_fan]
+#pin: PL4
+#shutdown_speed: 1
+
+#fan for control board FAN2
+#[heater_fan my_control_fan]
+#pin: PL3
+
+[mcu]
+serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+#Prevents communication issues with SPI drivers
+[static_digital_output disable_sdcard]
+pins: PB0
+
+########################################
+# TMC UART configuration
+########################################
+
+# For TMC UART
+#   1) Remove all jumpers below the stepper drivers.
+#   2) Place jumper on the left and middle pin of the three pin header.
+
+#[tmc2208 stepper_x]
+#uart_pin: PG3
+#tx_pin: PJ2
+#microsteps: 16
+#run_current: 0.8
+#hold_current: 0.5
+#stealthchop_threshold: 250
+
+#[tmc2208 stepper_y]
+#uart_pin: PJ3
+#tx_pin: PJ4
+#microsteps: 16
+#run_current: 0.8
+#hold_current: 0.5
+#stealthchop_threshold: 250
+
+#[tmc2208 stepper_z]
+#uart_pin: PE2
+#tx_pin: PE6
+#microsteps: 16
+#run_current: 0.8
+#hold_current: 0.5
+#stealthchop_threshold: 100
+
+#[tmc2208 extruder]
+#uart_pin: PJ5
+#tx_pin: PJ6
+#microsteps: 16
+#run_current: 0.8
+#hold_current: 0.5
+#stealthchop_threshold: 250
+
+#[tmc2208 extruder1]
+#uart_pin: PE7
+#tx_pin: PD4
+#microsteps: 16
+#run_current: 0.8
+#hold_current: 0.5
+#stealthchop_threshold: 250
+
+#[tmc2208 extruder2]
+#uart_pin: PA1
+#tx_pin: PD5
+#microsteps: 16
+#run_current: 0.8
+#hold_current: 0.5
+#stealthchop_threshold: 250
+
+########################################
+# TMC SPI configuration
+########################################
+
+# For TMC SPI
+#   1) Remove all jumpers below the stepper drivers.
+#   2) Place jumper on the middle and right pin of the small three pin header.
+#   3) Place jumpers on the four small two pin headers.
+
+# For TMC Sensorless homing / DIAG1
+#   1) Place jumper on the small two pin header near the endstop.
+
+#[tmc2130 stepper_x]
+#cs_pin: PG4
+#diag1_pin: PK1
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2130 stepper_y]
+#cs_pin: PG2
+#diag1_pin: PJ1
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2130 stepper_z]
+#cs_pin: PJ6
+#diag1_pin: PB6
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2130 extruder]
+#cs_pin: PL2
+#diag1_pin: PE4
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2130 extruder1]
+#cs_pin: PC5
+#diag1_pin: PJ0
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2130 extruder2]
+#cs_pin: PL7
+#diag1_pin: PK2
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+########################################
+# EXP1 / EXP2 (display) pins
+########################################
+
+# These must be turned 180° when compared to the default RAMPS layout.
+# The aliases below are 180° turned from what Fysetc considers pin 1,
+# but visually correspond to the plugs on the board.
+
+[board_pins]
+aliases:
+    # EXP1 header
+    EXP1_1=PC0, EXP1_2=PC2,
+    EXP1_3=PH0, EXP1_4=PH1,
+    EXP1_5=PA1, EXP1_6=PA3,    # Slot in the socket on this side
+    EXP1_7=PA5, EXP1_8=PA7,
+    EXP1_9=<GND>, EXP1_10=<5V>,
+
+    # EXP2 header
+    EXP2_1=PB3, EXP2_2=PB1,
+    EXP2_3=PC6, EXP2_4=PB0,
+    EXP2_5=PC4, EXP2_6=PB2,    # Slot in the socket on this side
+    EXP2_7=PL0, EXP2_8=<RST>,
+    EXP2_9=<GND>, EXP2_10=<5V> # or PG0 via jumper
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.
+
+########################################
+# Servos
+########################################
+
+# See the example-extras.cfg file for more information.
+# All Servo pins support hardware PWM.
+
+#[servo my_servo1]
+#pin: PB7
+
+#[servo my_servo2]
+#pin: PB5
+
+#[servo my_servo3]
+#pin: PB4
+
+#[servo my_servo4]
+#pin: PG5
+
+########################################
+# RGB header
+########################################
+
+# See the example-extras.cfg file for more information.
+# All RGB pins support hardware PWM.
+
+#[output_pin blue]
+#pin: PH6
+
+#[output_pin red]
+#pin: PE5
+
+#[output_pin green]
+#pin: PG5
+
+########################################
+# AUX-1 header
+########################################
+
+# Various analog and digital pins
+# PK0 (analog), PK3 (analog), <GND>, <5V>
+# PE0 (RXD0)  , PE1 (TXD0)  , <GND>, <5V>
+
+########################################
+# SD header
+########################################
+
+# Various digital / SPI pins
+# PL0 , PB2, PB0, RST
+# <5V>, PB3, PB1, <GND>
+
+########################################
+# UART header
+########################################
+
+# Various digital / UART pins
+# <5V>
+# <GND>
+# PD2
+# PD3
+
+########################################
+# I2C header
+########################################
+
+# SCL, SDA, <5V>, <GND>

config/generic-gt2560.cfg

@@ -0,0 +1,88 @@
+# This file contains common pin mappings for the Geeetech GT2560
+# board. GT2560 board uses a firmware 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_endstop: 0
+position_max: 200
+homing_speed: 30
+
+[stepper_y]
+step_pin: ar31
+dir_pin: ar33
+enable_pin: !ar29
+step_distance: .0125
+endstop_pin: ^ar26
+position_endstop: 0
+position_max: 200
+homing_speed: 30
+
+[stepper_z]
+step_pin: ar37
+dir_pin: !ar39
+enable_pin: !ar35
+step_distance: .0025
+endstop_pin: ^ar30
+position_endstop: 0
+position_max: 200
+position_min: 0.0
+
+[extruder]
+step_pin: ar43
+dir_pin: ar45
+enable_pin: !ar41
+step_distance: .0104789
+nozzle_diameter: 0.4
+filament_diameter: 1.750
+heater_pin: ar2
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: analog8
+min_temp: 0
+max_temp: 250
+control: pid
+pid_kp: 29.800
+pid_ki: 1.774
+pid_kd: 125.159
+
+[heater_bed]
+heater_pin: ar4
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: analog10
+min_temp: 0
+max_temp: 120
+control: pid
+pid_kp: 63.041
+pid_ki: 2.898
+pid_kd: 342.787
+
+[fan]
+pin: ar7
+
+[mcu]
+serial: /dev/ttyUSB0
+pin_map: arduino
+
+[printer]
+kinematics: cartesian
+max_velocity: 200
+max_accel: 1500
+max_z_velocity: 20
+max_z_accel: 500
+
+[display]
+lcd_type: hd44780
+rs_pin: ar20
+e_pin: ar17
+d4_pin: ar16
+d5_pin: ar21
+d6_pin: ar5
+d7_pin: ar6
+encoder_pins: ^ar42, ^ar40
+click_pin: ^!ar19

config/generic-melzi.cfg

@@ -0,0 +1,79 @@
+# 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

config/generic-mini-rambo.cfg

@@ -0,0 +1,109 @@
+# 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

config/generic-minitronics1.cfg

@@ -0,0 +1,80 @@
+# This file contains common pin mappings for Minitronics v1.0
+# boards. To use this config, the firmware should be compiled for the
+# AVR atmega1280.
+
+# The "make flash" command does not work on the Minitronics v1.0
+# because the board actually has an atmega1281 chip. Use the following
+# command to flash the board:
+#  avrdude -carduino -patmega1281 -P/dev/ttyUSB0 -b57600 -D -Uout/klipper.elf.hex
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PF2
+dir_pin: PF1
+enable_pin: !PF3
+step_distance: .0125
+endstop_pin: ^!PE3
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: PA1
+dir_pin: PA2
+enable_pin: !PA0
+step_distance: .0125
+endstop_pin: ^!PE4
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: PA4
+dir_pin: !PA5
+enable_pin: !PA3
+step_distance: .0025
+endstop_pin: ^!PB4
+position_endstop: 0.5
+position_max: 200
+
+[extruder]
+step_pin: PA7
+dir_pin: PA6
+enable_pin: !PG2
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PB5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PF7
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: PE5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PF6
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PB7
+
+[mcu]
+serial: /dev/ttyUSB0
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[static_digital_output yellow_led]
+pins: PF0

config/generic-printrboard-g2.cfg

@@ -0,0 +1,117 @@
+# This file contains common pin mappings for Printrboard G2 boards.
+# To use this config, the firmware should be compiled for the SAM3x8c.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PB15
+dir_pin: !PA16
+enable_pin: !PB16
+step_distance: .0125
+endstop_pin: ^PA11
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: PA29
+dir_pin: !PB1
+enable_pin: !PB0
+step_distance: .0125
+endstop_pin: ^PB26
+position_endstop: 150
+position_max: 150
+homing_speed: 50
+
+[stepper_z]
+step_pin: PA21
+dir_pin: PA26
+enable_pin: !PA25
+step_distance: .0025
+endstop_pin: ^!PA10
+position_endstop: 0
+position_min: -2
+position_max: 200
+
+[output_pin motor_x_pwm]
+pin: PB17
+pwm: True
+hardware_pwm: True
+scale: 2.25
+cycle_time: .000004
+value: 0.8
+
+[output_pin motor_y_pwm]
+pin: PB19
+pwm: True
+hardware_pwm: True
+scale: 2.25
+cycle_time: .000004
+value: 0.8
+
+[output_pin motor_z_pwm]
+pin: PB18
+pwm: True
+hardware_pwm: True
+scale: 2.25
+cycle_time: .000004
+value: 0.8
+
+[output_pin motor_e_pwm]
+pin: PA2
+pwm: True
+hardware_pwm: True
+scale: 2.25
+cycle_time: .000004
+value: 0.5
+
+[output_pin heater_enable]
+pin: PA7
+pwm: True
+cycle_time: 0.050
+value: 0.1
+
+[thermistor G2]
+temperature1: 20
+resistance1: 140000
+temperature2: 195
+resistance2: 593
+temperature3: 255
+resistance3: 189
+
+[extruder]
+step_pin: PB14
+dir_pin: PB23
+enable_pin: !PB22
+step_distance: .008
+nozzle_diameter: 0.300
+filament_diameter: 1.750
+heater_pin: PA5
+sensor_pin: PA23
+sensor_type: G2
+inline_resistor: 4700
+control: pid
+pid_kp: 29.852
+pid_ki: 2.843
+pid_kd: 78
+min_temp: 0
+max_temp: 290
+
+[fan]
+pin: PB27
+
+[heater_fan nozzle_cooling_fan]
+pin: PA6
+
+[mcu]
+serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
+
+[printer]
+kinematics: cartesian
+max_velocity: 400
+max_accel: 2500
+max_z_velocity: 15
+max_z_accel: 300
+
+[static_digital_output step_config]
+pins: PA19, PB20, PA27, PB10

config/generic-printrboard.cfg

@@ -0,0 +1,84 @@
+# 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
+
+# Use the following on a Printrboard RevF to control stepper current.
+#[mcp4728 stepper_current_dac]
+#scale: 2.327
+#channel_a: 1.2 # Extruder
+#channel_b: 1.2 # stepper_z
+#channel_c: 1.0 # stepper_y
+#channel_d: 1.0 # stepper_x

config/generic-radds.cfg

@@ -0,0 +1,111 @@
+# 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
+#encoder_pins: ^ar52, ^ar50
+#click_pin: ^!ar48
+
+# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
+#[display]
+#lcd_type: st7920
+#cs_pin: ar42
+#sclk_pin: ar44
+#sid_pin: ar43

config/generic-rambo.cfg

@@ -0,0 +1,122 @@
+# 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
+
+# Common EXP1 / EXP2 (display) pins
+[board_pins]
+aliases:
+    # Common EXP1/EXP2 headers found on RAMBo v1.4
+    EXP1_1=PE6, EXP1_3=PG3, EXP1_5=PJ2, EXP1_7=PJ7, EXP1_9=<GND>,
+    EXP1_2=PE2, EXP1_4=PG4, EXP1_6=PJ3, EXP1_8=PJ4, EXP1_10=<5V>,
+    # EXP2 header
+    EXP2_1=PB3, EXP2_3=PJ5, EXP2_5=PJ6, EXP2_7=PD4, EXP2_9=<GND>,
+    EXP2_2=PB1, EXP2_4=PB0, EXP2_6=PB2, EXP2_8=PE7, EXP2_10=PH2
+    # Pins EXP2_1, EXP2_6, EXP2_2 are also MISO, MOSI, SCK of bus "spi"
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.

config/generic-ramps.cfg

@@ -0,0 +1,98 @@
+# 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
+
+# Common EXP1 / EXP2 (display) pins
+[board_pins]
+aliases:
+    # Common EXP1 header found on many "all-in-one" ramps clones
+    EXP1_1=ar37, EXP1_3=ar17, EXP1_5=ar23, EXP1_7=ar27, EXP1_9=<GND>,
+    EXP1_2=ar35, EXP1_4=ar16, EXP1_6=ar25, EXP1_8=ar29, EXP1_10=<5V>,
+    # EXP2 header
+    EXP2_1=ar50, EXP2_3=ar31, EXP2_5=ar33, EXP2_7=ar49, EXP2_9=<GND>,
+    EXP2_2=ar52, EXP2_4=ar53, EXP2_6=ar51, EXP2_8=ar41, EXP2_10=<RST>
+    # Pins EXP2_1, EXP2_6, EXP2_2 are also MISO, MOSI, SCK of bus "spi"
+    # Note, some boards wire: EXP2_8=<RST>, EXP2_10=ar41
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.

config/generic-re-arm.cfg

@@ -0,0 +1,101 @@
+# This file contains common pin mappings for Re-Arm. To use this
+# config, the firmware should be compiled for the LPC1768.
+
+# 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

config/generic-replicape.cfg

@@ -0,0 +1,136 @@
+# 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.
+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
+
+# The alternative servo pins channels on the endstops x2 and y2 can be used
+# via the special relicape pins servo0 (P9_14) and servo1 (P9_16).
+#[servo servo_x2]
+#pin: replicape:servo0
+#   PWM output pin controlling the servo. This parameter must be
+#   provided.
+#...

config/generic-rumba.cfg

@@ -0,0 +1,115 @@
+# 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: ar25
+#enable_pin: !ar27
+#heater_pin: ar3
+#sensor_pin: analog14
+#...
+
+#[extruder2]
+#step_pin: ar29
+#dir_pin: ar28
+#enable_pin: !ar39
+#heater_pin: ar6
+#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

config/generic-smoothieboard.cfg

@@ -0,0 +1,110 @@
+# This file contains common pin mappings for Smoothieboard. To use
+# this config, the firmware should be compiled for the LPC176x.
+
+# 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: 44
+# 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: 45
+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

config/kit-voron2-250mm.cfg

@@ -0,0 +1,299 @@
+# VORON2 250mm config
+
+# This is a base printer.cfg file for the VORON2 printer and matches the manual/build guide exactly
+# for controllers used (dual RAMPS) and pin layout for all connected components.
+# Created by "Boff" with help from the VORON community.
+
+# For other build sizes, controllers, or non-standard pin connections, please see
+# https://github.com/mzbotreprap/VORON/tree/master/Firmware/Klipper/Voron_2.1/Klipper/Configurations
+# for other example Klipper configs created by the VORON community.
+
+# 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 Klipper parameters.
+
+# AND PLEASE READ THROUGH THE KLIPPER DOCUMENTATION FIRST!
+# https://github.com/KevinOConnor/klipper/tree/master/docs
+
+# *** THINGS TO CHANGE/CHECK: ***
+# Arduino paths                         [mcu] section
+# Thermistor types                      [extruder] and [heater_bed] sections - See 'sensor types' list at end of file
+# FSR switch (z endstop) location       [homing_override] section
+# FSR switch (z endstop) offset for Z0  [stepper_z] section
+# Probe points                          [quad_gantry_level] section
+# Min & Max gantry corner postions      [quad_gantry_level] section
+# PID tune                              [extruder] and [heater_bed] sections
+# Fine tune E steps                     [extruder] section
+
+[mcu]
+# Mcu for X/Y/E steppers
+serial: /dev/serial/by-id/**INSERT_YOUR_ARDUINO_DEFINITION_HERE**
+#   Obtain definition by "ls -l /dev/serial/by-id/"
+pin_map: arduino
+restart_method: arduino
+
+[mcu z]
+# Mcu for Z steppers
+serial: /dev/serial/by-id/**INSERT_YOUR_ARDUINO_DEFINITION_HERE**
+#   Obtain definition by "ls -l /dev/serial/by-id/"
+pin_map: arduino
+restart_method: arduino
+
+[printer]
+kinematics: corexy
+max_velocity: 350
+max_accel: 3000
+max_z_velocity: 50
+max_z_accel: 350
+
+[stepper_x]
+# B Stepper
+step_pin: ar54
+dir_pin: !ar55
+enable_pin: !ar38
+#   X on mcu_xye
+step_distance: 0.0125
+#   80 steps per mm - 1.8 deg - 1/16 microstepping
+endstop_pin: ^ar2
+#   X_MAX on mcu_xye
+position_min: 0
+position_endstop: 250
+position_max: 250
+homing_speed: 100
+homing_retract_dist: 5
+
+[stepper_y]
+# A Stepper
+step_pin: ar60
+dir_pin: !ar61
+enable_pin: !ar56
+#   Y on mcu_xye
+step_distance: 0.0125
+#   80 steps per mm - 1.8 deg - 1/16 microstepping
+endstop_pin: ^ar15
+#   Y_MAX on mcu_xye
+position_min: 0
+position_endstop: 250
+position_max: 250
+homing_speed: 100
+homing_retract_dist: 5
+
+[stepper_z]
+# Z0 Stepper - Front Left
+step_pin: z:ar54
+dir_pin: !z:ar55
+enable_pin: !z:ar38
+#   X on mcu_z
+step_distance: 0.00250
+#   400 steps per mm - 1.8 deg - 1/16 microstepping
+endstop_pin: ^!z:ar18
+#   Z_MIN on mcu_z
+position_endstop: -0.2
+#   Offset (in mm) for nozzle to bed off z switch
+position_max: 250
+position_min: -2
+#   Set to -2 to allow room for squaring gantry with quad_gantry_level
+homing_speed: 15.0
+second_homing_speed: 3.0
+homing_retract_dist: 3.0
+
+[stepper_z1]
+# Z1 Stepper - Rear Left
+step_pin: z:ar60
+dir_pin: z:ar61
+enable_pin: !z:ar56
+#   Y on mcu_z
+step_distance: 0.00250
+#   400 steps per mm - 1.8 deg - 1/16 microstepping
+
+[stepper_z2]
+# Z2 Stepper - Rear Right
+step_pin: z:ar46
+dir_pin: !z:ar48
+enable_pin: !z:ar62
+#   Z on mcu_z
+step_distance: 0.00250
+#   400 steps per mm - 1.8 deg - 1/16 microstepping
+
+[stepper_z3]
+# Z3 Stepper - Front Right
+step_pin: z:ar26
+dir_pin: z:ar28
+enable_pin: !z:ar24
+#   E0 on mcu_z
+step_distance: 0.00250
+#   400 steps per mm - 1.8 deg - 1/16 microstepping
+
+[extruder]
+step_pin: ar26
+dir_pin: ar28
+enable_pin: !ar24
+#   E0 on mcu_xye
+step_distance: 0.00180180
+#   555 steps per mm - 1.8 deg - 1/16 microstepping (Mobius2)
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+max_extrude_only_distance: 780.0
+#   This is set high to allow the load/unload filament macros to run
+heater_pin: ar10
+#   D10 on mcu_xye
+max_power: 1.0
+sensor_type: NTC 100K beta 3950
+sensor_pin: analog13
+#   T0 on mcu_xye
+smooth_time: 3.0
+control: pid
+pid_Kp: 16.430
+pid_Ki: 0.755
+pid_Kd: 89.337
+min_extrude_temp: 170
+min_temp: 0
+max_temp: 270
+
+[probe]
+# Inductive Probe
+pin: ^z:ar19
+#   Z_MAX on mcu_z
+x_offset: 0.0
+y_offset: 25.0
+z_offset: 0.00
+speed: 2.0
+samples: 4
+#   Number of times to probe a point
+sample_retract_dist: 6.0
+#   How far to retract (in mm) from the probe point for multi-probe samples
+
+[fan]
+# Print cooling fan
+pin: ar9
+#   D9 on mcu_xye
+kick_start_time: 0.500
+
+[heater_fan hotend_fan]
+# Hotend fan
+pin: z:ar9
+#   D9 on mcu_z
+kick_start_time: 0.500
+heater: extruder
+heater_temp: 50.0
+
+[heater_fan controller_fan]
+# Controller fan
+pin: z:ar10
+#   D10 on mcu_z
+kick_start_time: 0.500
+heater: heater_bed
+heater_temp: 45.0
+
+[heater_fan exhaust_fan]
+# Exhaust fan
+pin: z:ar8
+#   D8 on mcu_z
+kick_start_time: 0.500
+heater: heater_bed
+heater_temp: 60.0
+
+[heater_bed]
+heater_pin: z:ar11
+#   D11 (servo) on mcu_z
+sensor_type: NTC 100K MGB18-104F39050L32
+sensor_pin: z:analog15
+#   T2 on mcu_z
+smooth_time: 3.0
+max_power: 0.75
+control: pid
+pid_Kp: 47.690
+pid_Ki: 1.556
+pid_Kd: 365.338
+min_temp: 0
+max_temp: 110
+
+[homing_override]
+axes: z
+set_position_z: 0
+gcode:
+   G90
+   G0 Z5 F600
+   G28 X Y
+   G0 X179 Y249.5 F3600
+#   XY Location of the FSR Switch
+   G28 Z
+   G0 Z10 F1800
+   G0 X125 Y125 Z20 F3600
+
+[quad_gantry_level]
+#   Use QUAD_GANTRY_LEVEL to level a gantry.
+gantry_corners:
+   -55,-7
+   305, 320
+#   Min & Max gantry corners - measure from nozzle at MIN (0,0) and MAX (250,250) to respective belt positions
+points:
+   25,0
+   25,200
+   225,200
+   225,0
+#   Probe points
+speed: 200
+horizontal_move_z: 6
+
+[display]
+# RepRapDiscount 128x64 Full Graphic Smart Controller
+lcd_type: st7920
+cs_pin: z:ar16
+sclk_pin: z:ar23
+sid_pin: z:ar17
+#   LCD connector on mcu_z
+menu_timeout: 40
+encoder_pins: ^z:ar33, ^z:ar31
+click_pin: ^!z:ar35
+kill_pin: ^!z:ar41
+
+
+###   Macros   ###
+
+[gcode_macro G32]
+gcode:
+    G28
+    QUAD_GANTRY_LEVEL
+    QUAD_GANTRY_LEVEL
+    G0 X125 Y125 Z20 F6000
+
+[gcode_macro PRINT_START]
+#   Use PRINT_START for the slicer starting script - PLEASE CUSTOMISE THE SCRIPT FOR YOUR SLICER OF CHOICE
+gcode:
+    M117 Homing...                 ; display message
+    G28                            ; home all axes
+    G1 Z20 F3000                   ; move nozzle away from bed
+    M117 Preheat (Print)           ; display message
+    M104 S0                        ; turn off hotend while waiting for bed to get to temp
+
+[gcode_macro PRINT_END]
+#   Use PRINT_END for the slicer ending script - PLEASE CUSTOMISE THE SCRIPT FOR YOUR SLICER OF CHOICE
+gcode:
+    M400                           ; wait for buffer to clear
+    G92 E0                         ; zero the extruder
+    G1 E-4.0 F3600                 ; retract
+    G91                            ; relative positioning
+    G0 Z1.00 X20.0 Y20.0 F20000    ; move nozzle to remove stringing
+    M104 S0                        ; turn off hotend
+    M140 S0                        ; turn off bed
+    M106 S0                        ; turn off fan
+    G1 Z20 F3000                   ; move nozzle up 20mm
+    G90                            ; absolute positioning
+    G0  X125 Y245 F3600            ; park nozzle at rear
+    M117 Finished!                 ; display message
+
+[gcode_macro UNLOAD_FILAMENT]
+gcode:
+    M83
+    G1 E10 F300
+    G1 E-780 F1800
+    M82
+
+[gcode_macro LOAD_FILAMENT]
+gcode:
+    M83
+    G1 E750 F1800
+    G1 E30 F300
+    G1 E15 F150
+    M82

config/kit-zav3d-2019.cfg

@@ -0,0 +1,151 @@
+# ZAV3D MAX config. To use this config, the firmware should be
+# compiled for the AVR atmega2560.
+
+# This is a base printer.cfg file for the ZAV3D Max printer and
+# matches the manual/build guide exactly for controllers used (MKS
+# MINI-B V1.0) and pin layout for all connected components.
+# Created by "Nurmukhamed Artykaly"
+
+# 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 Klipper parameters.
+
+# AND PLEASE READ THROUGH THE KLIPPER DOCUMENTATION FIRST!
+# https://www.klipper3d.org/Overview.html
+
+# *** THINGS TO CHANGE/CHECK: ***
+# Arduino paths                         [mcu] section
+# Thermistor types                      [extruder] and [heater_bed] sections - See 'sensor types' list at end of file
+# FSR switch (z endstop) location       [homing_override] section
+# FSR switch (z endstop) offset for Z0  [stepper_z] section
+# Probe points                          [quad_gantry_level] section
+# Min & Max gantry corner postions      [quad_gantry_level] section
+# PID tune                              [extruder] and [heater_bed] sections
+# Fine tune E steps                     [extruder] section
+
+
+[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
+
+## Configuration with Z Endstop, without Probe tool like BLTOUCH or others.
+#[stepper_z]
+#step_pin: ar46
+#dir_pin: ar48
+#enable_pin: !ar62
+#step_distance: .0025
+## I used Z_MAX_ENDSTOP
+#endstop_pin: ^ar19
+## More about z-calibration is here https://vk.com/topic-107680682_34101598
+#position_endstop: 235
+#position_max: 235
+#homing_positive_dir: true
+
+## Configuration for Bltouch probe tool.
+## Read more about BLTOUCH here https://www.klipper3d.org/BLTouch.html
+[stepper_z]
+step_pin: ar46
+dir_pin: ar48
+enable_pin: !ar62
+step_distance: .0025
+position_min: -3
+position_max: 230
+endstop_pin: probe:z_virtual_endstop
+
+## Configuration with PID Calibration.
+## Read more here https://www.klipper3d.org/Config_checks.html
+[extruder]
+step_pin: ar26
+dir_pin: !ar28
+enable_pin: !ar24
+step_distance: .004242
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: ar10
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog13
+min_temp: 0
+max_temp: 250
+control: pid
+pid_kp: 26.596
+pid_ki: 1.166
+pid_kd: 151.598
+
+## Configuration with PID Calibration.
+## Read more here https://www.klipper3d.org/Config_checks.html
+[heater_bed]
+heater_pin: ar8
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog14
+min_temp: 0
+max_temp: 130
+control: pid
+pid_kp: 73.517
+pid_ki: 1.822
+pid_kd: 741.600
+
+[fan]
+pin: ar9
+
+[mcu]
+serial: /dev/ttyACM0
+pin_map: arduino
+
+[printer]
+kinematics: corexy
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 25
+max_z_accel: 30
+
+[bltouch]
+sensor_pin: ^ar18
+control_pin: ar7
+x_offset: 39
+y_offset: 11
+z_offset: 0.9
+pin_up_touch_mode_reports_triggered: false
+samples: 2
+sample_retract_dist: 3.0
+
+[bed_mesh]
+speed: 100
+horizontal_move_z: 5
+min_point: 30,30
+max_point: 150,150
+probe_count: 3,3
+
+[homing_override]
+set_position_z: 6
+axes: z
+gcode:
+        G90
+        G1 Z10 F6000
+        G28 X Y
+        G1 X100 Y100 F6000
+        G28 Z0
+        G1 X100 Y100 Z10a
+
+[gcode_macro G29]
+gcode:
+        G28
+        G1 Z10 F600
+        BED_MESH_CALIBRATE

config/printer-adimlab-2018.cfg

@@ -0,0 +1,120 @@
+# 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

config/printer-anet-a8-2017.cfg

@@ -0,0 +1,98 @@
+# 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
+up_pin: PA1
+analog_range_up_pin: 9000, 13000
+down_pin: PA1
+analog_range_down_pin: 800, 1300
+click_pin: PA1
+analog_range_click_pin: 2000, 2500
+back_pin: PA1
+analog_range_back_pin: 4500, 5000
+#kill_pin: PA1
+#analog_range_kill_pin: 400, 600

config/printer-anet-e10-2018.cfg

@@ -0,0 +1,88 @@
+# 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

config/printer-anycubic-4max-2018.cfg

@@ -0,0 +1,127 @@
+# Klipper firmware config file for Anycubic 4Max. 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: -2
+position_endstop: -2
+position_max: 205
+homing_speed: 60.0
+
+[stepper_y]
+step_pin: ar60
+dir_pin: ar61
+enable_pin: !ar56
+step_distance: .0125
+endstop_pin: ^!ar14
+position_endstop: 0
+position_max: 215
+homing_speed: 60.0
+
+[stepper_z]
+step_pin: ar46
+dir_pin: ar48
+enable_pin: !ar62
+step_distance: .0025
+endstop_pin: ^!ar18
+position_endstop: 0.5
+position_max: 305
+homing_speed: 8.0
+
+[extruder]
+step_pin: ar26
+dir_pin: ar28
+enable_pin: !ar24
+step_distance: 0.010354
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+max_extrude_only_distance: 2000
+heater_pin: ar10
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: analog13
+control: pid
+pid_kp: 27.725
+pid_ki: 1.224
+pid_kd: 156.991
+min_temp: 0
+max_temp: 300
+
+[heater_bed]
+heater_pin: ar8
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog14
+control: pid
+pid_kp: 73.735
+pid_ki: 1.437
+pid_kd: 945.653
+min_temp: 0
+max_temp: 110
+
+[fan]
+pin: ar9
+kick_start_time: 1.0
+
+[mcu]
+serial: /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
+pin_map: arduino
+
+[printer]
+kinematics: cartesian
+max_velocity: 1200
+max_accel: 1500
+max_z_velocity: 40
+max_z_accel: 60
+
+[heater_fan extruder_fan]
+pin: ar44
+
+[heater_fan stepstick_fan]
+pin: ar7
+kick_start_time: 1.0
+
+[display]
+lcd_type: st7920
+cs_pin: ar16
+sclk_pin: ar23
+sid_pin: ar17
+encoder_pins: ^ar31, ^ar33
+click_pin: ^!ar35
+kill_pin: ^!ar41
+
+[filament_switch_sensor e0_sensor]
+switch_pin: ar19
+
+[gcode_macro START_PRINT]
+gcode:
+    M117 Starting...
+    G90 ; absolute positioning
+    M107 ; start with the fan off
+    G28 ; Home
+    G0 X5 Y5 F4500 ; Go to front
+    G0 Z0.3 ; Drop to bed
+    G92 E0 ; zero the extruded length
+    G1 Y40 E15 F500 ; Extrude 15mm of filament in a 4cm line
+    G92 E0 ; zero the extruded length
+    G1 Y80 F4000 ; Quickly wipe away from the filament line
+    G1 Z1 ; Raise and begin printing.
+    M117 Printing...
+
+[gcode_macro END_PRINT]
+gcode:
+    M117 End printing.
+    G91 ; relative positioning
+    G1 E-1 F300 ;retract the filament a bit before lifting the nozzle to release some of the pressure
+    G1 Z+5 E-2 F1000 ;move Z up a bit and extract a bit more
+    G90 ; absolute positioning
+    G1 X0 F2000 ; move X to min endstops so the head is out of the way
+    G1 Y200 F2000 ; Move Y to the back
+    m104 S0 ; turn hotend heating off
+    M140 S0 ; turn bed heating off
+    M107 ; turn fan off
+    M84 ; steppers off

config/printer-anycubic-i3-mega-2017.cfg

@@ -0,0 +1,93 @@
+# 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

config/printer-anycubic-kossel-2016.cfg

@@ -0,0 +1,109 @@
+# 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

config/printer-anycubic-kossel-plus-2017.cfg

@@ -0,0 +1,109 @@
+# 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

config/printer-creality-cr10-2017.cfg

@@ -0,0 +1,90 @@
+# 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: ATC Semitec 104GT-2
+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

config/printer-creality-cr10mini-2017.cfg

@@ -0,0 +1,90 @@
+# 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: ATC Semitec 104GT-2
+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

config/printer-creality-cr10s-2017.cfg

@@ -0,0 +1,83 @@
+# 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
+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: ATC Semitec 104GT-2
+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

config/printer-creality-cr20-2018.cfg

@@ -0,0 +1,81 @@
+# 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
+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

config/printer-creality-ender2-2017.cfg

@@ -0,0 +1,93 @@
+# 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

config/printer-creality-ender3-2018.cfg

@@ -0,0 +1,93 @@
+# 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

config/printer-creality-ender5-2019.cfg

@@ -0,0 +1,93 @@
+# This file contains common pin mappings for the 2019 Creality
+# Ender 5. 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: 30
+
+[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: 30
+
+[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]
+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/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
+
+[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

config/printer-lulzbot-taz6-2017.cfg

@@ -0,0 +1,116 @@
+# 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

config/printer-makergear-m2-2012.cfg

@@ -0,0 +1,114 @@
+# 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

config/printer-micromake-d1-2016.cfg

@@ -0,0 +1,79 @@
+# 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

config/printer-seemecnc-rostock-max-v2-2015.cfg

@@ -0,0 +1,94 @@
+# 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

config/printer-tevo-flash-2018.cfg

@@ -0,0 +1,124 @@
+# Support for Tevo Flash. To use this config, the firmware should be
+# compiled for the AVR atmega2560.
+
+# Note, this config has only been tested on a modified Tevo Flash
+# (using a Bondtech BMG extruder). If using a stock printer it may be
+# necessary to update the extruder step_distance parameter.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: ar54
+dir_pin: !ar55
+enable_pin: !ar38
+step_distance: .012491
+endstop_pin: !ar3
+position_endstop: -13
+position_min: -13
+position_max: 235
+homing_speed: 50
+
+[stepper_y]
+step_pin: ar60
+dir_pin: ar61
+enable_pin: !ar56
+step_distance: .012441
+endstop_pin: !ar14
+position_endstop: -3
+position_min: -3
+position_max: 235
+homing_speed: 50
+
+[stepper_z]
+step_pin: ar46
+dir_pin: ar48
+enable_pin: !ar62
+step_distance: .002520
+position_max: 250
+endstop_pin: probe:z_virtual_endstop
+position_min: -2
+
+[stepper_z1]
+step_pin: ar36
+dir_pin: ar34
+enable_pin: !ar30
+step_distance: .002520
+
+[extruder]
+step_pin: ar26
+dir_pin: ar28
+enable_pin: !ar24
+step_distance: .002401
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: ar10
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog13
+control: pid
+pid_Kp: 18.547
+pid_Ki: 0.788
+pid_Kd: 109.193
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: ar8
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog14
+control: pid
+pid_Kp: 38.824
+pid_Ki: 0.539
+pid_Kd: 698.838
+min_temp: 0
+max_temp: 70
+
+[heater_fan my_nozzle_fan]
+pin: ar7
+
+[fan]
+pin: ar9
+
+[mcu]
+serial: /dev/ttyUSB0
+pin_map: arduino
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 1000
+max_z_velocity: 5
+max_z_accel: 100
+
+[display]
+lcd_type: uc1701
+cs_pin: ar25
+a0_pin: ar27
+encoder_pins: ^!ar31, ^!ar33
+click_pin: ^!ar35
+kill_pin: ar64
+
+[bltouch]
+sensor_pin: ar18
+control_pin: ar11
+x_offset: 0
+y_offset: 18
+z_offset: 1.64
+samples: 3
+sample_retract_dist: 5
+
+# The homing_override section modifies the default G28 behavior
+[homing_override]
+set_position_z: 0
+axes: z
+gcode:
+    G90
+    G1 Z5 F600
+    G28 X0 Y0
+    G1 X118 Y118 F3600
+    G28 Z0
+
+# Mesh Bed Leveling.
+[bed_mesh]
+min_point: 5,0
+max_point: 230,210
+probe_count: 9,9

config/printer-tronxy-x5s-2018.cfg

@@ -0,0 +1,92 @@
+# 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
+encoder_pins: ^PD2, ^PD3
+click_pin: ^!PA5

config/printer-tronxy-x8-2018.cfg

@@ -0,0 +1,91 @@
+# 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

config/printer-velleman-k8200-2013.cfg

@@ -0,0 +1,95 @@
+# 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

config/printer-wanhao-duplicator-6-2016.cfg

@@ -0,0 +1,107 @@
+# 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
+
+[display]
+lcd_type: ssd1306
+reset_pin: PE3
+encoder_pins: ^PG1, ^PG0
+click_pin: ^!PD2

config/printer-wanhao-duplicator-i3-plus-2017.cfg

@@ -0,0 +1,78 @@
+# 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

config/printer-wanhao-duplicator-i3-plus-mark2-2019.cfg

@@ -0,0 +1,81 @@
+# This file contains pin mappings for the Wanhao Duplicator i3 Plus
+# Mark II. 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: 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: !PE4
+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: probe:z_virtual_endstop
+position_max: 180
+position_min: -0.5
+
+[extruder]
+step_pin: PF4
+dir_pin: PF5
+enable_pin: !PF3
+step_distance: 0.010417
+nozzle_diameter: 0.300
+filament_diameter: 1.750
+heater_pin: PG5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PF1
+control: pid
+pid_Kp: 20.982
+pid_Ki: 0.725
+pid_Kd: 151.861
+min_temp: 0
+max_temp: 260
+
+[heater_bed]
+heater_pin: PE5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PK6
+control: watermark
+min_temp: 0
+max_temp: 110
+
+[fan]
+pin: PE3
+
+[probe]
+pin: !PH3
+z_offset: 1.0
+
+[mcu]
+serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 800
+max_z_velocity: 5
+max_z_accel: 100
+
+[bed_mesh]
+min_point: 20,20
+max_point: 190,130
+probe_count: 4,4

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

@@ -0,0 +1,169 @@
+# 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

config/sample-lcd.cfg

@@ -0,0 +1,143 @@
+# This file provides example configuration for common "RepRap" style
+# LCD displays that use EXP1/EXP2 plugs.
+
+# To configure a display from this file, make sure the main
+# printer.cfg file has a [board_pins] config section defining pin
+# aliases for the EXP1/EXP2 plugs, find the appropriate LCD type in
+# this file, and then copy-and-paste that section into printer.cfg.
+
+# See the "example-extras.cfg" file for description of config parameters.
+
+
+######################################################################
+# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
+######################################################################
+
+[display]
+lcd_type: st7920
+cs_pin: EXP1_4
+sclk_pin: EXP1_5
+sid_pin: EXP1_3
+encoder_pins: ^EXP2_3, ^EXP2_5
+click_pin: ^!EXP1_2
+#kill_pin: ^!EXP2_8
+
+[output_pin beeper]
+pin: EXP1_1
+
+
+######################################################################
+# "RepRapDiscount 2004 Smart Controller" type displays
+######################################################################
+
+[display]
+lcd_type: hd44780
+rs_pin: EXP1_4
+e_pin: EXP1_3
+d4_pin: EXP1_5
+d5_pin: EXP1_6
+d6_pin: EXP1_7
+d7_pin: EXP1_8
+encoder_pins: ^EXP2_3, ^EXP2_5
+click_pin: ^!EXP1_2
+#kill_pin: ^!EXP2_8
+
+[output_pin beeper]
+pin: EXP1_1
+
+
+######################################################################
+# 128x64 Full Graphic Creality CR10 / ENDER 3 stockdisplay
+######################################################################
+
+[display]
+lcd_type: st7920
+cs_pin: EXP1_7
+sclk_pin: EXP1_6
+sid_pin: EXP1_8
+encoder_pins: ^EXP1_5, ^EXP1_3
+click_pin: ^!EXP1_2
+
+[output_pin beeper]
+pin: EXP1_1
+
+
+######################################################################
+# MKS Mini 12864 LCD
+######################################################################
+
+# Make sure that the EXP1 and EXP2 are rotated correctly on the
+# display board. The cutouts on the connectors should be towards the
+# center of the PCB. See:
+#   https://reprap.org/wiki/MKS_MINI_12864#Physical_Interface
+# If they are wrong, the connector housing can be pried off carefully
+# with a small screwdriver and relocated the correct way.
+
+[display]
+lcd_type: uc1701
+cs_pin: EXP1_6
+a0_pin: EXP1_7
+contrast: 40
+encoder_pins: ^EXP2_3, ^EXP2_5
+click_pin: ^!EXP1_2
+## Some micro-controller boards may require an spi bus to be specified:
+#spi_bus: spi
+## Alternatively, some micro-controller boards may work with software spi:
+#spi_software_miso_pin: EXP2_1
+#spi_software_mosi_pin: EXP2_6
+#spi_software_sclk_pin: EXP2_2
+
+[output_pin beeper]
+pin: EXP1_1
+
+
+######################################################################
+# Fysetc Mini 12864Panel v2.1 (with neopixel backlight leds)
+######################################################################
+
+[display]
+lcd_type: st7567
+cs_pin: EXP1_3
+a0_pin: EXP1_4
+rs_pin: EXP1_5
+contrast: 63
+encoder_pins: ^EXP2_3, ^EXP2_5
+click_pin: ^!EXP1_2
+## Some micro-controller boards may require an spi bus to be specified:
+#spi_bus: spi
+## Alternatively, some micro-controller boards may work with software spi:
+#spi_software_miso_pin: EXP2_1
+#spi_software_mosi_pin: EXP2_6
+#spi_software_sclk_pin: EXP2_2
+
+[output_pin beeper]
+pin: EXP1_1
+
+[neopixel fysetc_mini12864]
+pin: EXP1_6
+chain_count: 3
+color_order_GRB: False
+initial_RED: 0.4
+initial_GREEN: 0.4
+initial_BLUE: 0.4
+
+
+######################################################################
+# Plug pin locations
+######################################################################
+
+# Some micro-controller boards and displays use inconsistent labeling
+# for the EXP1 and EXP2 headers. The following diagram shows the
+# correct location of pin 1 along with ground and power pins on the
+# EXP1 and EXP2 plugs:
+#
+#          EXP1:                        EXP2:
+#   +-----------------+          +-----------------+
+#   |  o  o  o  o  5V |          |  o  o  o  o  o  |
+#   |  1  o  o  o GND |          |  1  o  o  o GND |
+#   +------     ------+          +------     ------+
+#
+# Some boards may have the cutout in the wrong location. If so, it may
+# be possible to carefully pry the plastic header off of the pins with
+# a small screwdriver, then correct the orientation and reapply the
+# plastic header.

config/sample-macros.cfg

@@ -0,0 +1,117 @@
+# This file provides examples of Klipper G-Code macros.  The snippets
+# in this file may be copied into the main printer.cfg file and
+# customized.
+#
+# See the "example.cfg" file for description of common config parameters.
+
+
+######################################################################
+# Start Print and End Print
+######################################################################
+
+# Replace the slicer's custom start and end g-code scripts with
+# START_PRINT and END_PRINT.
+
+[gcode_macro START_PRINT]
+default_parameter_BED_TEMP: 60
+default_parameter_EXTRUDER_TEMP: 190
+gcode:
+    # Start bed heating
+    M140 S{BED_TEMP}
+    # Use absolute coordinates
+    G90
+    # Reset the G-Code Z offset (adjust Z offset if needed)
+    SET_GCODE_OFFSET Z=0.0
+    # Home the printer
+    G28
+    # Move the nozzle near the bed
+    G1 Z5 F3000
+    # Move the nozzle very close to the bed
+    G1 Z0.15 F300
+    # Wait for bed to reach temperature
+    M190 S{BED_TEMP}
+    # Set and wait for nozzle to reach temperature
+    M109 S{EXTRUDER_TEMP}
+
+[gcode_macro END_PRINT]
+gcode:
+    # Turn off bed, extruder, and fan
+    M140 S0
+    M104 S0
+    M106 S0
+    # Move nozzle away from print while retracting
+    G91
+    G1 X-2 Y-2 E-3 F300
+    # Raise nozzle by 10mm
+    G1 Z10 F3000
+    G90
+    # Disable steppers
+    M84
+
+
+######################################################################
+# Beeper
+######################################################################
+
+# 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.
+# 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
+#   Use a default 1kHz tone if S is omitted.
+default_parameter_P: 100
+#   Use a 10ms duration is P is omitted.
+gcode:
+    SET_PIN PIN=BEEPER_pin VALUE={S}
+    G4 P{P}
+    SET_PIN PIN=BEEPER_pin VALUE=0
+
+
+######################################################################
+# Filament Change
+######################################################################
+
+# M600: Filament Change. This macro will pause the printer, move the
+# tool to the change position, and retract the filament 50mm. Adjust
+# the retraction settings for your own extruder. After filament has
+# been changed, the print can be resumed from its previous position
+# with the "RESUME" gcode.
+
+[pause_resume]
+
+[gcode_macro M600]
+default_parameter_X: 50
+default_parameter_Y: 0
+default_parameter_Z: 10
+gcode:
+    SAVE_GCODE_STATE NAME=M600_state
+    PAUSE
+    G91
+    G1 E-.8 F2700
+    G1 Z{Z}
+    G90
+    G1 X{X} Y{Y} F3000
+    G91
+    G1 E-50 F1000
+    RESTORE_GCODE_STATE NAME=M600_state

config/sample-probe-as-z-endstop.cfg

@@ -0,0 +1,51 @@
+# 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: 0
+axes: z
+gcode:
+    G90
+    ; G1 Z2 F600 ; Uncomment to blindly lift the Z 2mm at start
+    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

docs/BLTouch.md

@@ -0,0 +1,134 @@
+Connecting BL-Touch
+===================
+
+A **warning** before you start: Avoid touching the BL-Touch pin with
+your bare fingers, since it is quite sensitive to finger grease. And
+if you do touch it, be very gentle, in order to not bend or push
+anything.
+
+Hook up the BL-Touch "servo" connector to a `control_pin` according to
+the BL-Touch documentation or your MCU documentation. Using the
+original wiring, the yellow wire from the triple is the `control_pin`
+and the white wire from the pair is the `sensor_pin`. You need to
+configure these pins according to your wiring. For example:
+
+```
+[bltouch]
+sensor_pin: P1.24
+control_pin: P1.26
+```
+
+If the BL-Touch will be used to home the Z axis then set `endstop_pin:
+probe:z_virtual_endstop` in the `[stepper_z]` config section and add a
+`[homing_override]` config section to raise the z-axis, home the
+x/y-axis, move to the center of the bed, and home the z-axis. For
+example:
+
+```
+[homing_override]
+gcode:
+    G90 ; Use absolute position mode
+    G1 Z10 ; Move up 10mm
+    G28 X Y
+    G1 X166 Y120 F6000 ; Change the X and Y coordinates to the center of your print bed
+    G28 Z
+set_position_z: 0.0
+```
+
+It's important that the initial Z upwards movement in the
+homing_override is high enough that the probe doesn't hit anything
+even if the probe pin happens to be in its lowest state.
+
+Initial tests
+=============
+
+Before moving on, verify that the BL-Touch is mounted at the correct
+height, the pin should be roughly 2 mm above the nozzle when retracted
+
+When you turn on the printer, the BL-Touch probe should perform a
+self-test and move the pin up and down a couple of times. Once the
+self-test is completed, the pin should be retracted and the red LED on
+the probe should be lit. If there are any errors, for example the
+probe is flashing red or the pin is down instead of up, please turn
+off the printer and check the wiring and configuration.
+
+If the above is looking good, it's time to test that the probe
+responds to commands from the firmware. First run `BLTOUCH_DEBUG
+COMMAND=pin_down` in your printer terminal. Verify that the pin moves
+down, and that the red LED on the probe turns off. If not, check your
+wiring and configuration again. Next issue a `BLTOUCH_DEBUG
+COMMAND=pin_up`, verify that the pin moves up, and that the red light
+turns on again. If it's flashing then there's some problem.
+
+Now, it's time to test homing with a twist. Instead of letting the
+probe pin touch the print bed, let it touch the nail on your
+finger. So issue a `G28`, wait until it starts to move down, and stop
+the movement by very gently touching the pin with your nail. You
+probably have to do it twice, since the default configuration makes it
+probe twice. But be prepared to turn off the printer, to avoid damage,
+if it doesn't stop when you touch the pin.
+
+If that was successful, do another `G28` but this time let it touch
+the bed as it should.
+
+Calibrating the BL-Touch offsets
+================================
+
+Follow the directions in the [Probe Calibrate](Probe_Calibrate.md)
+guide to set the x_offset, y_offset, and z_offset config parameters.
+
+It's a good idea to verify that the Z offset is close to 1mm. If not,
+then you probably want to move the probe up or down to fix this. You
+want it to trigger well before the nozzle hits the bed, so that
+possible stuck filament or a warped bed doesn't affect any probing
+action. But at the same time, you want the retracted position to be as
+far above the nozzle as possible to avoid it touching printed parts.
+If an adjustment is made to the probe position, then rerun the probe
+calibration steps.
+
+BL-Touch gone bad
+=================
+
+Once the BL-Touch is in inconsistent state, it starts blinking
+red. You can force it to leave that state by issuing:
+
+ BLTOUCH_DEBUG COMMAND=reset
+
+This may happen if its calibration is interrupted by the probe being
+blocked from being extracted.
+
+However, the BL-Touch may also not be able to calibrate itself
+anymore. This happens if the screw on its top is in the wrong position
+or the magnetic core inside the probe pin has moved. If it has moved
+up so that it sticks to the screw, it may not be able to lower its pin
+anymore. With this behavior you need to open the screw and use a
+ball-point pen to push it gently back into place. Re-Insert the pin
+into the BL-Touch so that it falls into the extracted
+position. Carefully readjust the headless screw into place. You need
+to find the right position so it is able to lower and raise the pin
+and the red light turns on and of. Use the `reset`, `pin_up` and
+`pin_down` commands to achieve this.
+
+Troubleshooting
+===============
+
+* If you are sure the wiring of the BL-Touch is correct and every
+  attempt to probe with the BL-Touch reports "BLTouch failed to verify
+  sensor state" then it may be necessary to add
+  `pin_up_touch_mode_reports_triggered: False` to the bltouch config
+  section. The BL-Touch v3 and many clones require this setting.
+
+* A BL-Touch v3 may not work correctly when its signal wire is
+  connected to the Z end-stop pin on some printer boards. The symptoms
+  of this problem are: the BL-Touch probe deploys, the printer
+  descends, the probe contacts a surface, the BL-Touch raises the
+  probe, the BL-Touch does not successfully notify the
+  micro-controller, and the printer continues to descend. The Z
+  end-stop pin on some printer boards have a capacitor to filter the
+  signal which the BL-Touch v3 may not support. The simplest solution
+  is to connect the BL-Touch v3 sensor wire to an available pin on the
+  printer board that is not associated with an end-stop (and thus is
+  unlikely to have a capacitor). An alternative solution is to
+  physically alter the printer board to disable the given end-stop
+  capacitor or to add a hardware "pull up resistor" to the BL-Touch v3
+  sensor wire.

docs/Bed_Level.md

@@ -0,0 +1,215 @@
+Bed leveling (sometimes also referred to as "bed tramming") is
+critical to getting high quality prints. If a bed is not properly
+"leveled" it can lead to poor bed adhesion, "warping", and subtle
+problems throughout the print. This document serves as a guide to
+performing bed leveling in Klipper.
+
+It's important to understand the goal of bed leveling. If the printer
+is commanded to a position `X0 Y0 Z10` during a print, then the goal
+is for the printer's nozzle to be exactly 10mm from the printer's
+bed. Further, should the printer then be commanded to a position of
+`X50 Z10` the goal is for the nozzle to maintain an exact distance of
+10mm from the bed during that entire horizontal move.
+
+In order to get good quality prints the printer should be calibrated
+so that Z distances are accurate to within about 25 microns (.025mm).
+This is a small distance - significantly smaller than the width of a
+typical human hair. This scale can not be measured "by eye". Subtle
+effects (such as heat expansion) impact measurements at this scale.
+The secret to getting high accuracy is to use a repeatable process and
+to use a leveling method that leverages the high accuracy of the
+printer's own motion system.
+
+# Choose the appropriate calibration mechanism
+
+Different types of printers use different methods for performing bed
+leveling. All of them ultimately depend on the "paper test" (described
+below). However, the actual process for a particular type of printer
+is described in other documents.
+
+Prior to running any of these calibration tools, be sure to run the
+checks described in the [config check document](Config_checks.md). It
+is necessary to verify basic printer motion before performing bed
+leveling.
+
+For printers with an "automatic Z probe" be sure to calibrate the
+probe following the directions in the
+[Probe Calibrate](Probe_Calibrate.md) document. For delta printers,
+see the [Delta Calibrate](Delta_Calibrate.md) document. For printers
+with bed screws and traditional Z endstops, see the
+[Manual Level](Manual_Level.md) document.
+
+During calibration it may be necessary to set the printer's Z
+`position_min` to a negative number (eg, `position_min = -2`). The
+printer enforces boundary checks even during calibration
+routines. Setting a negative number allows the printer to move below
+the nominal position of the bed, which may help when trying to
+determine the actual bed position.
+
+# The "paper test"
+
+The primary bed calibration mechanism is the "paper test". It involves
+placing a regular piece of "copy machine paper" between the printer's
+bed and nozzle, and then commanding the nozzle to different Z heights
+until one feels a small amount of friction when pushing the paper back
+and forth.
+
+It is important to understand the "paper test" even if one has an
+"automatic Z probe". The probe itself often needs to be calibrated to
+get good results. That probe calibration is done using this "paper
+test".
+
+In order to perform the paper test, cut a small rectangular piece of
+paper using a pair of scissors (eg, 5x3 cm). The paper generally has a
+width of around 100 microns (0.100mm). (The exact width of the paper
+isn't crucial.)
+
+The first step of the paper test is to inspect the printer's nozzle
+and bed. Make sure there is no plastic (or other debris) on the nozzle
+or bed.
+
+**Inspect the nozzle and bed to ensure no plastic is present!**
+
+If one always prints on a particular tape or printing surface then one
+may perform the paper test with that tape/surface in place. However,
+note that tape itself has a width and different tapes (or any other
+printing surface) will impact Z measurements. Be sure to rerun the
+paper test to measure each type of surface that is in use.
+
+If there is plastic on the nozzle then heat up the extruder and use a
+metal tweezers to remove that plastic. Wait for the extruder to fully
+cool to room temperature before continuing with the paper test. While
+the nozzle is cooling, use the metal tweezers to remove any plastic
+that may ooze out.
+
+**Always perform the paper test when both nozzle and bed are at room
+temperature!**
+
+When the nozzle is heated, its position (relative to the bed) changes
+due to thermal expansion. This thermal expansion is typically around a
+100 microns, which is about the same width as a typical piece of
+printer paper. The exact amount of thermal expansion isn't crucial,
+just as the exact width of the paper isn't crucial. Start with the
+assumption that the two are equal (see below for a method of
+determining the difference between the two widths).
+
+It may seem odd to calibrate the distance at room temperature when the
+goal is to have a consistent distance when heated. However, if one
+calibrates when the nozzle is heated, it tends to impart small amounts
+of molten plastic on to the paper, which changes the amount of
+friction felt. That makes it harder to get a good calibration.
+Calibrating while the bed/nozzle is hot also greatly increases the
+risk of burning oneself. The amount of thermal expansion is stable, so
+it is easily accounted for later in the calibration process.
+
+**Use an automated tool to determine precise Z heights!**
+
+Klipper has several helper scripts available (eg, MANUAL_PROBE,
+Z_ENDSTOP_CALIBRATE, PROBE_CALIBRATE, DELTA_CALIBRATE). See the
+documents
+[described above](#choose-the-appropriate-calibration-mechanism) to
+choose one of them.
+
+Run the appropriate command in the OctoPrint terminal window. The
+script will prompt for user interaction in the OctoPrint terminal
+output. It will look something like:
+```
+Recv: // Starting manual Z probe. Use TESTZ to adjust position.
+Recv: // Finish with ACCEPT or ABORT command.
+Recv: // Z position: ?????? --> 5.000 <-- ??????
+```
+
+The current height of the nozzle (as the printer currently understands
+it) is shown between the "--> <--". The number to the right is the
+height of the last probe attempt just greater than the current height,
+and to the left is the last probe attempt less than the current height
+(or ?????? if no attempt has been made).
+
+Place the paper between the nozzle and bed. It can be useful to fold a
+corner of the paper so that it is easier to grab. (Try not to push
+down on the bed when moving the paper back and forth.)
+
+![paper-test](img/paper-test.jpg)
+
+Use the TESTZ command to request the nozzle to move closer to the
+paper. For example:
+```
+TESTZ Z=-.1
+```
+
+The TESTZ command will move the nozzle a relative distance from the
+nozzle's current position. (So, `Z=-.1` requests the nozzle to move
+closer to the bed by .1mm.) After the nozzle stops moving, push the
+paper back and forth to check if the nozzle is in contact with the
+paper and to feel the amount of friction. Continue issuing TESTZ
+commands until one feels a small amount of friction when testing with
+the paper.
+
+If too much friction is found then one can use a positive Z value to
+move the nozzle up. It is also possible to use `TESTZ Z=+` or `TESTZ
+Z=-` to "bisect" the last position - that is to move to a position
+half way between two positions. For example, if one received the
+following prompt from a TESTZ command:
+```
+Recv: // Z position: 0.130 --> 0.230 <-- 0.280
+```
+Then a `TESTZ Z=-` would move the nozzle to a Z position of 0.180
+(half way between 0.130 and 0.230). One can use this feature to help
+rapidly narrow down to a consistent friction. It is also possible to
+use `Z=++` and `Z=--` to return directly to a past measurement - for
+example, after the above prompt a `TESTZ Z=--` command would move the
+nozzle to a Z position of 0.130.
+
+After finding a small amount of friction run the ACCEPT command:
+```
+ACCEPT
+```
+This will accept the given Z height and proceed with the given
+calibration tool.
+
+The exact amount of friction felt isn't crucial, just as the amount of
+thermal expansion and exact width of the paper isn't crucial. Just try
+to obtain the same amount of friction each time one runs the test.
+
+If something goes wrong during the test, one can use the `ABORT`
+command to exit the calibration tool.
+
+# Determining Thermal Expansion
+
+After successfully performing bed leveling, one may go on to calculate
+a more precise value for the combined impact of "thermal expansion",
+"width of the paper", and "amount of friction felt during the paper
+test".
+
+This type of calculation is generally not needed as most users find
+the simple "paper test" provides good results.
+
+The easiest way to make this calculation is to print a test object
+that has straight walls on all sides. The large hollow square found in
+[docs/prints/square.stl](prints/square.stl) can be used for this.
+When slicing the object, make sure the slicer uses the same layer
+height and extrusion widths for the first level that it does for all
+subsequent layers. Use a coarse layer height (the layer height should
+be around 75% of the nozzle diameter) and do not use a brim or raft.
+
+Print the test object, wait for it to cool, and remove it from the
+bed. Inspect the lowest layer of the object. (It may also be useful to
+run a finger or nail along the bottom edge.) If one finds the bottom
+layer bulges out slightly along all sides of the object then it
+indicates the nozzle was slightly closer to the bed then it should
+be. One can issue a `SET_GCODE_OFFSET Z=+.010` command to increase the
+height. In subsequent prints one can inspect for this behavior and
+make further adjustment as needed. Adjustments of this type are
+typically in 10s of microns (.010mm).
+
+If the bottom layer consistently appears narrower than subsequent
+layers then one can use the SET_GCODE_OFFSET command to make a
+negative Z adjustment. If one is unsure, then one can decrease the Z
+adjustment until the bottom layer of prints exhibit a small bulge, and
+then back-off until it disappears.
+
+The easiest way to apply the desired Z adjustment is to create a
+START_PRINT g-code macro, arrange for the slicer to call that macro
+during the start of each print, and add a SET_GCODE_OFFSET command to
+that macro. See the [slicers](Slicers.md) document for further
+details.

docs/Benchmarks.md

@@ -0,0 +1,404 @@
+This document describes Klipper benchmarks.
+
+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 in
+[Debugging.md](Debugging.md)). 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.)}
+```
+
+Benchmarks may be run with the micro-controller code compiled using a
+"step pulse duration" of zero (the tables below report this as "no
+delay"). This configuration is believed to be valid in real-world
+usage when one is solely using Trinamic stepper drivers. The results
+of these benchmarks are not reported in the Features.md document.
+
+### 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 `01d2183f` with gcc version `avr-gcc
+(GCC) 5.4.0`. 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).
+
+| avr              | ticks |
+| ---------------- | ----- |
+| 1 stepper        | 104   |
+| 2 stepper        | 296   |
+| 3 stepper        | 472   |
+
+### 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 `8d4a5c16` with gcc version
+`arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0`.
+
+| sam3x8e              | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 388   |
+| 2 stepper            | 405   |
+| 3 stepper            | 576   |
+| 1 stepper (no delay) | 77    |
+| 3 stepper (no delay) | 299   |
+
+### Duet Maestro step rate benchmark ###
+
+The following configuration sequence is used on the Duet Maestro:
+```
+allocate_oids count=3
+config_stepper oid=0 step_pin=PC26 dir_pin=PC18 min_stop_interval=0 invert_step=0
+config_stepper oid=1 step_pin=PC26 dir_pin=PA8 min_stop_interval=0 invert_step=0
+config_stepper oid=2 step_pin=PC26 dir_pin=PB4 min_stop_interval=0 invert_step=0
+finalize_config crc=0
+```
+
+The test was last run on commit `8d4a5c16` with gcc version
+`arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0`.
+
+| sam4s8c              | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 527   |
+| 2 stepper            | 535   |
+| 3 stepper            | 638   |
+| 1 stepper (no delay) | 70    |
+| 3 stepper (no delay) | 254   |
+
+### Duet Wifi step rate benchmark ###
+
+The following configuration sequence is used on the Duet Wifi:
+```
+allocate_oids count=4
+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
+config_stepper oid=3 step_pin=PD5 dir_pin=PA1 min_stop_interval=0 invert_step=0
+finalize_config crc=0
+
+```
+
+The test was last run on commit `59a60d68` with gcc version
+`arm-none-eabi-gcc 7.3.1 20180622 (release)
+[ARM/embedded-7-branch revision 261907]`.
+
+| sam4e8e          | ticks |
+| ---------------- | ----- |
+| 1 stepper        | 519   |
+| 2 stepper        | 520   |
+| 3 stepper        | 525   |
+| 4 stepper        | 703   |
+
+### 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)`.
+
+| pru              | ticks |
+| ---------------- | ----- |
+| 1 stepper        | 861   |
+| 2 stepper        | 853   |
+| 3 stepper        | 883   |
+
+### STM32F042 step rate benchmark ###
+
+The following configuration sequence is used on the STM32F042:
+```
+allocate_oids count=3
+config_stepper oid=0 step_pin=PA0 dir_pin=PA1 min_stop_interval=0 invert_step=0
+config_stepper oid=1 step_pin=PA2 dir_pin=PA3 min_stop_interval=0 invert_step=0
+config_stepper oid=2 step_pin=PA6 dir_pin=PA7 min_stop_interval=0 invert_step=0
+finalize_config crc=0
+```
+
+The test was last run on commit `c105adc8` with gcc version
+`arm-none-eabi-gcc (GNU Tools 7-2018-q3-update) 7.3.1`.
+
+| stm32f042        | ticks |
+| ---------------- | ----- |
+| 1 stepper        | 308   |
+| 2 stepper        | 638   |
+| 3 stepper        | 1021  |
+
+### 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 `8d4a5c16` with gcc version
+`arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0`.
+
+| stm32f103            | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 347   |
+| 2 stepper            | 372   |
+| 3 stepper            | 600   |
+| 1 stepper (no delay) | 71    |
+| 3 stepper (no delay) | 288   |
+
+### STM32F4 step rate benchmark ###
+
+The following configuration sequence is used on the STM32F4:
+```
+allocate_oids count=4
+config_stepper oid=0 step_pin=PA5 dir_pin=PB5 min_stop_interval=0 invert_step=0
+config_stepper oid=1 step_pin=PB2 dir_pin=PB6 min_stop_interval=0 invert_step=0
+config_stepper oid=2 step_pin=PB3 dir_pin=PB7 min_stop_interval=0 invert_step=0
+config_stepper oid=3 step_pin=PB3 dir_pin=PB8 min_stop_interval=0 invert_step=0
+finalize_config crc=0
+```
+
+The test was last run on commit `8d4a5c16` with gcc version
+`arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0`. The STM32F407 results
+were obtained by running an STM32F407 binary on an STM32F446 (and thus
+using a 168Mhz clock).
+
+| stm32f446            | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 757   |
+| 2 stepper            | 761   |
+| 3 stepper            | 757   |
+| 4 stepper            | 767   |
+| 1 stepper (no delay) | 51    |
+| 3 stepper (no delay) | 226   |
+
+| stm32f407            | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 709   |
+| 2 stepper            | 714   |
+| 3 stepper            | 709   |
+| 4 stepper            | 729   |
+| 1 stepper (no delay) | 52    |
+| 3 stepper (no delay) | 226   |
+
+### 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 `8d4a5c16` with gcc version
+`arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0`. The 120Mhz LPC1769
+results were obtained by overclocking an LPC1768 to 120Mhz.
+
+| lpc1768              | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 448   |
+| 2 stepper            | 450   |
+| 3 stepper            | 523   |
+| 1 stepper (no delay) | 56    |
+| 3 stepper (no delay) | 240   |
+
+| lpc1769              | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 525   |
+| 2 stepper            | 526   |
+| 3 stepper            | 545   |
+| 1 stepper (no delay) | 56    |
+| 3 stepper (no delay) | 240   |
+
+### 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 `8d4a5c16` with gcc version
+`arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0` on a SAMD21G18
+micro-controller.
+
+| samd21               | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 277   |
+| 2 stepper            | 410   |
+| 3 stepper            | 664   |
+| 1 stepper (no delay) | 83    |
+| 3 stepper (no delay) | 321   |
+
+### SAMD51 step rate benchmark ###
+
+The following configuration sequence is used on the SAMD51:
+```
+allocate_oids count=4
+config_stepper oid=0 step_pin=PA22 dir_pin=PA20 min_stop_interval=0 invert_step=0
+config_stepper oid=1 step_pin=PA22 dir_pin=PA21 min_stop_interval=0 invert_step=0
+config_stepper oid=2 step_pin=PA22 dir_pin=PA19 min_stop_interval=0 invert_step=0
+config_stepper oid=3 step_pin=PA22 dir_pin=PA18 min_stop_interval=0 invert_step=0
+finalize_config crc=0
+```
+
+The test was last run on commit `8d4a5c16` with gcc version
+`arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0` on a SAMD51G19A
+micro-controller.
+
+| samd51               | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 516   |
+| 2 stepper            | 520   |
+| 3 stepper            | 519   |
+| 4 stepper            | 655   |
+| 1 stepper (no delay) | 41    |
+| 3 stepper (no delay) | 197   |
+
+## 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 in [Debugging.md](Debugging.md)). The following is
+cut-and-paste into the console.py terminal window:
+```
+DELAY {clock + 2*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`.
+
+Note that this test may saturate the USB/CPU capacity of a Raspberry
+Pi. The benchmarks below are with console.py running on a desktop
+class machine with the device connected via a high-speed hub.
+
+| MCU                 | Rate | Build    | Build compiler      |
+| ------------------- | ---- | -------- | ------------------- |
+| pru (shared memory) |   5K | b161a69e | pru-gcc (GCC) 8.0.0 20170530 (experimental) |
+| stm32f042 (CAN)     |  18K | c105adc8 | arm-none-eabi-gcc (GNU Tools 7-2018-q3-update) 7.3.1 |
+| atmega2560 (serial) |  23K | b161a69e | avr-gcc (GCC) 4.8.1 |
+| sam3x8e (serial)    |  23K | b161a69e | arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0 |
+| at90usb1286 (USB)   |  75K | 01d2183f | avr-gcc (GCC) 5.4.0 |
+| samd21 (USB)        | 223K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
+| stm32f103 (USB)     | 355K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
+| sam3x8e (USB)       | 418K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
+| lpc1768 (USB)       | 534K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
+| lpc1769 (USB)       | 628K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
+| sam4s8c (USB)       | 650K | 8d4a5c16 | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
+| samd51 (USB)        | 864K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
+| stm32f446 (USB)     | 870K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
+
+Host Benchmarks
+===============
+
+It is possible to run timing tests on the host software using the
+"batch mode" processing mechanism (described in
+[Debugging.md](Debugging.md)). 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
+```

docs/Bootloaders.md

@@ -0,0 +1,440 @@
+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](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](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](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](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, one can use a
+[Raspberry Pi with OpenOCD](#running-openocd-on-the-raspberry-pi).
+
+To flash a bootloader with OpenOCD use a chip config similar to:
+```
+set CHIPNAME at91samd21g18
+source [find target/at91samdXX.cfg]
+```
+Obtain a bootloader - for example:
+```
+wget 'https://github.com/arduino/ArduinoCore-samd/raw/1.8.3/bootloaders/zero/samd21_sam_ba.bin'
+```
+Flash with OpenOCD commands similar to:
+```
+at91samd bootloader 0
+program samd21_sam_ba.bin verify
+```
+
+The most common bootloader on the SAMD21 is the one found on the
+"Arduino Zero". It uses an 8KiB bootloader (the application must be
+compiled with a start address of 8KiB). One can enter this bootloader
+by double clicking the reset button. To flash an application use
+something like:
+```
+bossac -U -p /dev/ttyACM0 --offset=0x2000 -w out/klipper.bin -v -b -R
+```
+
+In contrast, the "Arduino M0" uses a 16KiB bootloader (the application
+must be compiled with a start address of 16KiB). To flash an
+application on this bootloader, 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
+```
+
+SAMD51 micro-controllers (Adafruit Metro-M4 and similar)
+========================================================
+
+Like the SAMD21, the SAMD51 bootloader is flashed via the ARM Serial
+Wire Debug (SWD) interface. To flash a bootloader with
+[OpenOCD on a Raspberry Pi](#running-openocd-on-the-raspberry-pi) use
+a chip config similar to:
+```
+set CHIPNAME at91samd51g19
+source [find target/atsame5x.cfg]
+```
+Obtain a bootloader - several bootloaders are available from
+[https://github.com/adafruit/uf2-samdx1/releases/latest](https://github.com/adafruit/uf2-samdx1/releases/latest). For example:
+```
+wget 'https://github.com/adafruit/uf2-samdx1/releases/download/v3.7.0/bootloader-itsybitsy_m4-v3.7.0.bin'
+```
+Flash with OpenOCD commands similar to:
+```
+at91samd bootloader 0
+program bootloader-itsybitsy_m4-v3.7.0.bin verify
+at91samd bootloader 16384
+```
+
+The SAMD51 uses a 16KiB bootloader (the application must be compiled
+with a start address of 16KiB). To flash an application use something
+like:
+```
+bossac -U -p /dev/ttyACM0 --offset=0x4000 -w out/klipper.bin -v -b -R
+```
+
+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](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](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](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](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.
+
+Running OpenOCD on the Raspberry PI
+===================================
+
+OpenOCD is a software package that can perform low-level chip flashing
+and debugging. It can use the GPIO pins on a Raspberry Pi to
+communicate with a variety of ARM chips.
+
+This section describes how one can install and launch OpenOCD. It is
+derived from the instructions at:
+[https://learn.adafruit.com/programming-microcontrollers-using-openocd-on-raspberry-pi](https://learn.adafruit.com/programming-microcontrollers-using-openocd-on-raspberry-pi)
+
+Begin by downloading and compiling the software (each step may take
+several minutes and the "make" step may take 30+ minutes):
+
+```
+sudo apt-get update
+sudo apt-get install autoconf libtool telnet
+mkdir ~/openocd
+cd ~/openocd/
+git clone http://openocd.zylin.com/openocd
+cd openocd
+./bootstrap
+./configure --enable-sysfsgpio --enable-bcm2835gpio --prefix=/home/pi/openocd/install
+make
+make install
+```
+
+## Configure OpenOCD
+
+Create an OpenOCD config file:
+
+```
+nano ~/openocd/openocd.cfg
+```
+
+Use a config similar to the following:
+
+```
+# Uses RPi pins: GPIO25 for SWDCLK, GPIO24 for SWDIO, GPIO18 for nRST
+source [find interface/raspberrypi2-native.cfg]
+bcm2835gpio_swd_nums 25 24
+bcm2835gpio_srst_num 18
+transport select swd
+
+# Set the chip (at91samd51j19 in this example)
+set CHIPNAME at91samd51j19
+source [find target/atsame5x.cfg]
+
+# Set the adapter speed
+adapter_khz 40
+adapter_nsrst_delay 100
+adapter_nsrst_assert_width 100
+
+init
+targets
+reset halt
+```
+
+## Wire the Raspberry Pi to the target chip
+
+Poweroff both the the Raspberry Pi and the target chip before wiring!
+Verify the target chip uses 3.3V prior to connecting to a Raspberry
+Pi!
+
+Connect GND, SWDCLK, SWDIO, and RST on the target chip to GND, GPIO25,
+GPIO24, and GPIO18 respectively on the Raspberry Pi.
+
+Then power up the Raspberry Pi and provide power to the target chip.
+
+## Run OpenOCD
+
+Run OpenOCD:
+
+```
+cd ~/openocd/
+sudo ~/openocd/install/bin/openocd -f ~/openocd/openocd.cfg
+```
+
+The above should cause OpenOCD to emit some text messages and then
+wait (it should not immediately return to the Unix shell prompt). If
+OpenOCD exits on its own or if it continues to emit text messages then
+double check the wiring.
+
+Once OpenOCD is running and is stable, one can send it commands via
+telnet. Open another ssh session and run the following:
+
+```
+telnet 127.0.0.1 4444
+```
+
+(One can exit telnet by pressing ctrl+] and then running the "quit"
+command.)
+
+## OpenOCD and gdb
+
+It is possible to use OpenOCD with gdb to debug Klipper. The following
+commands assume one is running gdb on a desktop class machine.
+
+Add the following to the OpenOCD config file:
+
+```
+bindto 0.0.0.0
+gdb_port 44444
+```
+
+Restart OpenOCD on the Raspberry Pi and then run the following Unix
+command on the desktop machine:
+
+```
+cd /path/to/klipper/
+gdb out/klipper.elf
+```
+
+Within gdb run:
+
+```
+target remote octopi:44444
+```
+
+(Replace "octopi" with the host name of the Raspberry Pi.) Once gdb is
+running it is possible to set breakpoints and to inspect registers.

docs/CNAME

@@ -0,0 +1 @@
+www.klipper3d.org

docs/CONTRIBUTING.md

@@ -0,0 +1,38 @@
+# 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.

docs/Code_Overview.md

@@ -0,0 +1,463 @@
+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/**, **src/sam3/**, **src/samd21/**,
+**src/lpc176x/**, **src/stm32f1/**, **src/pru/**, and **src/linux/**
+directories contain architecture specific micro-controller code. 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
+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.
+* Register event handlers using the `printer.register_event_handler()`
+  method if the code needs to be called during "events" raised by
+  other printer objects. Each event name is a string, and by
+  convention it is the name of the main source module that raises the
+  event along with a short name for the action that is occurring (eg,
+  "klippy:connect"). The parameters passed to each event handler are
+  specific to the given event (as are exception handling and execution
+  context). Two common startup events are:
+  * klippy:connect - This event is generated after all printer objects
+    are instantiated. It is commonly used to lookup other printer
+    objects, to verify config settings, and to perform an initial
+    "handshake" with printer hardware.
+  * klippy:ready - This event is generated after all connect handlers
+    have completed successfully. It indicates the printer is
+    transitioning to a state ready to handle normal operations. Do not
+    raise an error in this callback.
+* If there is an error in the user's config, be sure to raise it
+  during the `load_config()` or "connect event" 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 register a "klippy:disconnect"
+  event handler and close them from that 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 calculate 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.

docs/Command_Templates.md

@@ -0,0 +1,249 @@
+This document provides information on implementing G-Code command
+sequences in gcode_macro (and similar) config sections.
+
+### Formatting of G-Code in the config
+
+Indentation is important when defining a macro in the config file. To
+specify a multi-line G-Code sequence it is important for each line to
+have proper indentation. For example:
+
+```
+[gcode_macro blink_led]
+gcode:
+  SET_PIN PIN=my_led VALUE=1
+  G4 P2000
+  SET_PIN PIN=my_led VALUE=0
+```
+
+Note how the `gcode:` config option always starts at the beginning of
+the line and subsequent lines in the G-Code macro never start at the
+beginning.
+
+### Save/Restore state for G-Code moves
+
+Unfortunately, the G-Code command language can be challenging to use.
+The standard mechanism to move the toolhead is via the `G1` command
+(the `G0` command is an alias for `G1` and it can be used
+interchangeably with it). However, this command relies on the "G-Code
+parsing state" setup by `M82`, `M83`, `G90`, `G91`, `G92`, and
+previous `G1` commands.  When creating a G-Code macro it is a good
+idea to always explicitly set the G-Code parsing state prior to
+issuing a `G1` command. (Otherwise, there is a risk the `G1` command
+will make an undesirable request.)
+
+A common way to accomplish that is to wrap the `G1` moves in
+`SAVE_GCODE_STATE`, `G91`, and `RESTORE_GCODE_STATE`. For example:
+
+```
+[gcode_macro MOVE_UP]
+gcode:
+  SAVE_GCODE_STATE NAME=my_move_up_state
+  G91
+  G1 Z10 F300
+  RESTORE_GCODE_STATE NAME=my_move_up_state
+```
+
+The `G91` command places the G-Code parsing state into "relative move
+mode" and the `RESTORE_GCODE_STATE` command restores the state to what
+it was prior to entering the macro. Be sure to specify an explicit
+speed (via the `F` parameter) on the first `G1` command.
+
+### Template expansion
+<!-- {% raw %} -->
+
+The gcode_macro `gcode:` config section is evaluated using the Jinja2
+template language. One can evaluate expressions at run-time by
+wrapping them in `{ }` characters or use conditional statements
+wrapped in `{% %}`. See the
+[Jinja2 documentation](http://jinja.pocoo.org/docs/2.10/templates/)
+for further information on the syntax.
+
+This is most often used to inspect parameters passed to the macro when
+it is called. These parameters are available via the `params`
+pseudo-variable. For example, if the macro:
+
+```
+[gcode_macro SET_PERCENT]
+gcode:
+  M117 Now at { params.VALUE|float * 100 }%
+```
+
+were invoked as `SET_PERCENT VALUE=.2` it would evaluate to `M117 Now
+at 20%`. Note that parameter names are always in upper-case when
+evaluated in the macro and are always passed as strings. If performing
+math then they must be explicitly converted to integers or floats.
+
+An example of a complex macro:
+```
+[gcode_macro clean_nozzle]
+gcode:
+  SAVE_GCODE_STATE NAME=clean_nozzle_state
+  G90
+  G0 Z15 F300
+  {% for wipe in range(8) %}
+    {% for coordinate in [(275,4),(235,4)] %}
+      G0 X{coordinate[0]} Y{coordinate[1] + 0.25 * wipe} Z9.7 F12000
+    {% endfor %}
+  {% endfor %}
+  RESTORE_GCODE_STATE NAME=clean_nozzle_state
+```
+<!-- {% endraw %} -->
+
+#### The "printer" Variable
+
+It is possible to inspect (and alter) the current state of the printer
+via the `printer` pseudo-variable. For example:
+
+```
+[gcode_macro slow_fan]
+gcode:
+  M106 S{ printer.fan.speed * 0.9 * 255}
+```
+
+Important! Macros are first evaluated in entirety and only then are
+the resulting commands executed. If a macro issues a command that
+alters the state of the printer, the results of that state change will
+not be visible during the evaluation of the macro. This can also
+result in subtle behavior when a macro generates commands that call
+other macros, as the called macro is evaluated when it is invoked
+(which is after the entire evaluation of the calling macro).
+
+By convention, the name immediately following `printer` is the name of
+a config section. So, for example, `printer.fan` refers to the fan
+object created by the `[fan]` config section. There are some
+exceptions to this rule - notably the `gcode` and `toolhead` objects.
+If the config section contains spaces in it, then one can access it
+via the `[ ]` accessor - for example:
+`printer["generic_heater my_chamber_heater"].temperature`.
+
+Some printer objects allow one to alter the state of the printer. By
+convention, these objects use an `action_` prefix. For example,
+`printer.gcode.action_emergency_stop()` would cause the printer to go
+into a shutdown state. These actions are taken at the time that the
+macro is evaluated, which may be a significant amount of time before
+the generated commands are executed.
+
+The following are common printer attributes:
+- `printer.fan.speed`: The fan speed as a float between 0.0 and 1.0.
+- `printer.gcode.action_respond_info(msg)`: Write the given `msg` to
+  the /tmp/printer pseudo-terminal. Each line of `msg` will be sent
+  with a "// " prefix.
+- `printer.gcode.action_respond_error(msg)`: Write the given `msg` to
+  the /tmp/printer pseudo-terminal. The first line of `msg` will be
+  sent with a "!! " prefix and subsequent lines will have a "// "
+  prefix.
+- `printer.gcode.action_emergency_stop(msg)`: Transition the printer
+  to a shutdown state. The `msg` parameter is optional, it may be
+  useful to describe the reason for the shutdown.
+- `printer.gcode.gcode_position`: The current position of the toolhead
+  relative to the current G-Code origin. It is possible to access the
+  x, y, z, and e components of this position (eg,
+  `printer.gcode.gcode_position.x`).
+- `printer["gcode_macro <macro_name>"].<variable>`: The current value
+  of a gcode_macro variable.
+- `printer.<heater>.temperature`: The last reported temperature (in
+  Celsius as a float) for the given heater. Available heaters are:
+  `heater_bed` and `heater_generic <config_name>`.
+- `printer.<heater>.target`: The current target temperature (in
+  Celsius as a float) for the given heater.
+- `printer.pause_resume.is_paused`: Returns true if a PAUSE command
+  has been executed without a corresponding RESUME.
+- `printer.toolhead.position`: The last commanded position of the
+  toolhead relative to the coordinate system specified in the config
+  file. It is possible to access the x, y, z, and e components of this
+  position (eg, `printer.toolhead.position.x`).
+
+The above list is subject to change - if using an attribute be sure to
+review the [Config Changes document](Config_Changes.md) when upgrading
+the Klipper software. The above list is not exhaustive.  Other
+attributes may be available (via `get_status()` methods defined in the
+software). However, undocumented attributes may change without notice
+in future Klipper releases.
+
+### Variables
+
+The SET_GCODE_VARIABLE command may be useful for saving state between
+macro calls. For example:
+
+```
+[gcode_macro start_probe]
+variable_bed_temp: 0
+gcode:
+  # Save target temperature to bed_temp variable
+  SET_GCODE_VARIABLE MACRO=start_probe VARIABLE=bed_temp VALUE={printer.heater_bed.target}
+  # Disable bed heater
+  M140
+  # Perform probe
+  PROBE
+  # Call finish_probe macro at completion of probe
+  finish_probe
+
+[gcode_macro finish_probe]
+gcode:
+  # Restore temperature
+  M140 S{printer["gcode_macro start_probe"].bed_temp}
+```
+
+Be sure to take the timing of macro evaluation and command execution
+into account when using SET_GCODE_VARIABLE.
+
+### Delayed Gcodes
+
+The [delayed_gcode] configuration option can be used to execute a delayed
+gcode sequence:
+
+```
+[delayed_gcode clear_display]
+gcode:
+  M117
+
+[gcode_macro load_filament]
+gcode:
+ G91
+ G1 E50
+ G90
+ M400
+ M117 Load Complete!
+ UPDATE_DELAYED_GCODE ID=clear_display DURATION=10
+```
+
+When the `load_filament` macro above executes, it will display a
+"Load Complete!" message after the extrusion is finished.  The
+last line of gcode enables the "clear_display" delayed_gcode, set
+to execute in 10 seconds.
+
+The `initial_duration` config option can be set to execute the
+delayed_gcode on printer startup.  The countdown begins when the
+printer enters the "ready" state.  For example, the below delayed_gcode
+will execute 5 seconds after the printer is ready, initializing
+the display with a "Welcome!" message:
+
+```
+[delayed_gcode welcome]
+initial_duration: 5.
+gcode:
+  M117 Welcome!
+```
+
+Its possible for a delayed gcode to repeat by updating itself in
+the gcode option:
+
+```
+[delayed_gcode report_temp]
+initial_duration: 2.
+gcode:
+  {printer.gcode.action_respond_info(
+    "Extruder Temp: %.1f" %
+    (printer.extruder0.temperature))}
+  UPDATE_DELAYED_GCODE ID=report_temp DURATION=2
+
+```
+
+The above delayed_gcode will send "// Extruder Temp: [ex0_temp]" to
+Octoprint every 2 seconds.  This can be canceled with the following
+gcode:
+
+
+```
+UPDATE_DELAYED_GCODE ID=report_temp DURATION=0
+```

docs/Config_Changes.md

@@ -0,0 +1,96 @@
+This document covers recent software changes to the config file that
+are not backwards compatible. It is a good idea to review this
+document when upgrading the Klipper software.
+
+All dates in this document are approximate.
+
+# Changes
+
+20191003: The move_to_previous option in [safe_z_homing] now defaults
+to False.  (It was effectively False prior to 20190918.)
+
+20190918: The zhop option in [safe_z_homing] is always re-applied
+after Z axis homing completed. This might need users to update custom
+scripts based on this module.
+
+20190806: The SET_NEOPIXEL command has been renamed to SET_LED.
+
+20190726: The mcp4728 digital-to-analog code has changed. The default
+i2c_address is now 0x60 and the voltage reference is now relative to
+the mcp4728's internal 2.048 volt reference.
+
+20190710: The z_hop option was removed from the [firmware_retract]
+config section. The z_hop support was incomplete and could cause
+incorrect behavior with several common slicers.
+
+20190710: The optional parameters of the PROBE_ACCURACY command have
+changed. It may be necessary to update any macros or scripts that use
+that command.
+
+20190628: All configuration options have been removed from the
+[skew_correction] section.  Configuration for skew_correction
+is now done via the SET_SKEW gcode.  See skew_correction.md
+for recommended usage.
+
+20190607: The "variable_X" parameters of gcode_macro (along with the
+VALUE parameter of SET_GCODE_VARIABLE) are now parsed as Python
+literals. If a value needs to be assigned a string then wrap the value
+in quotes so that it is evaluated as a string.
+
+20190606: The "samples", "samples_result", and "sample_retract_dist"
+config options have been moved to the "probe" config section. These
+options are no longer supported in the "delta_calibrate", "bed_tilt",
+"bed_mesh", "screws_tilt_adjust", "z_tilt", or "quad_gantry_level"
+config sections.
+
+20190528: The magic "status" variable in gcode_macro template
+evaluation has been renamed to "printer".
+
+20190520: The SET_GCODE_OFFSET command has changed; update any g-code
+macros accordingly. The command will no longer apply the requested
+offset to the next G1 command. The old behavior may be approximated by
+using the new "MOVE=1" parameter.
+
+20190404: The Python host software packages were updated. Users will
+need to rerun the ~/klipper/scripts/install-octopi.sh script (or
+otherwise upgrade the python dependencies if not using a standard
+OctoPi installation).
+
+20190404: The i2c_bus and spi_bus parameters (in various config
+sections) now take a bus name instead of a number.
+
+20190404: The sx1509 config parameters have changed. The 'address'
+parameter is now 'i2c_address' and it must be specified as a decimal
+number. Where 0x3E was previously used, specify 62.
+
+20190328: The min_speed value in [temperature_fan] config
+will now be respected and the fan will always run at this
+speed or higher in PID mode.
+
+20190322: The default value for "driver_HEND" in [tmc2660] config
+sections was changed from 6 to 3. The "driver_VSENSE" field was
+removed (it is now automatically calculated from run_current).
+
+20190310: The [controller_fan] config section now always takes a name
+(such as [controller_fan my_controller_fan]).
+
+20190308: The "driver_BLANK_TIME_SELECT" field in [tmc2130] and
+[tmc2208] config sections has been renamed to "driver_TBL".
+
+20190308: The [tmc2660] config section has changed. A new
+sense_resistor config parameter must now be provided. The meaning of
+several of the driver_XXX parameters has changed.
+
+20190228: Users of SPI or I2C on SAMD21 boards must now specify the
+bus pins via a [samd_sercom] config section.
+
+20190224: The bed_shape option has been removed from bed_mesh.  The
+radius option has been renamed to bed_radius.  Users with round beds
+should supply the bed_radius and round_probe_count options.
+
+20190107: The i2c_address parameter in the mcp4451 config section
+changed. This is a common setting on Smoothieboards. The new value is
+half the old value (88 should be changed to 44, and 90 should be
+changed to 45).
+
+20181220: Klipper v0.7.0 released

docs/Config_checks.md

@@ -0,0 +1,164 @@
+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. Be sure to read the
+[bed leveling](Bed_Level.md) guide. Also see the [Slicers](Slicers.md)
+document for information on configuring a slicer with Klipper.
+
+After one has verified that basic printing works, it is a good idea to
+consider calibrating [pressure advance](Pressure_Advance.md).
+
+It may be necessary to perform other types of detailed printer
+calibration - a number of guides are available online to help with
+this (for example, do a web search for "3d printer calibration").

docs/Contact.md

@@ -0,0 +1,57 @@
+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.

docs/Debugging.md

@@ -0,0 +1,197 @@
+This document describes some of the Klipper debugging tools.
+
+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 -o loadgraph.png
+```
+
+One can then view the resulting **loadgraph.png** file.
+
+Different graphs can be produced. For more information run:
+`~/klipper/scripts/graphstats.py --help`
+
+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.
+
+Running the regression tests
+============================
+
+The main Klipper GitHub repository uses TravisCI to run a series of
+regression tests. It can be useful to run some of these tests locally.
+
+The source code "whitespace check" can be run with:
+```
+./scripts/check_whitespace.sh
+```
+
+The Klippy regression test suite requires "data dictionaries" from
+many platforms. The easiest way to obtain them is to
+[download them from github](https://github.com/KevinOConnor/klipper/issues/1438).
+Once the data dictionaries are downloaded, use the following to run
+the regression suite:
+```
+tar xfz klipper-dict-20??????.tar.gz
+~/klippy-env/bin/python ~/klipper/scripts/test_klippy.py -d dict/ ~/klipper/test/klippy/*.test
+```

docs/Delta_Calibrate.md

@@ -0,0 +1,230 @@
+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.
+
+Ultimately, the delta calibration is dependent on the precision of the
+tower endstop switches. If one is using Trinamic stepper motor drivers
+then consider enabling [endstop phase](Endstop_Phase.md) detection to
+improve the accuracy of those switches.
+
+Automatic vs manual probing
+===========================
+
+Klipper supports calibrating the delta parameters via a manual probing
+method or via an automatic Z probe.
+
+A number of delta printer kits come with automatic Z probes that are
+not sufficiently accurate (specifically, small differences in arm
+length can cause effector tilt which can skew an automatic probe). If
+using an automatic probe then first
+[calibrate the probe](Probe_Calibrate.md) and then check for a
+[probe location bias](Probe_Calibrate.md#location-bias-check). If the
+automatic probe has a bias of more than 25 microns (.025mm) then use
+manual probing instead. Manual probing only takes a few minutes and it
+eliminates error introduced by the probe.
+
+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
+(`DELTA_CALIBRATE METHOD=manual`) and automatic probing
+(`DELTA_CALIBRATE`). The manual probing method will move the head near
+the bed and then wait for the user to follow the steps described at
+["the paper test"](Bed_Level.md#the-paper-test) to determine the
+actual distance between the nozzle and bed at the given location.
+
+To perform the basic probe, make sure the config has a
+[delta_calibrate] section defined and then run the tool:
+```
+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.

docs/Endstop_Phase.md

@@ -0,0 +1,125 @@
+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).

docs/FAQ.md

@@ -0,0 +1,503 @@
+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. [Can I run multiple instances of Klipper on the same host machine?](#can-i-run-multiple-instances-of-klipper-on-the-same-host-machine)
+9. [Do I have to use OctoPrint?](#do-i-have-to-use-octoprint)
+10. [Why can't I move the stepper before homing the printer?](#why-cant-i-move-the-stepper-before-homing-the-printer)
+11. [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)
+12. [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)
+13. [My TMC motor driver turns off in the middle of a print](#my-tmc-motor-driver-turns-off-in-the-middle-of-a-print)
+14. [I keep getting random "Lost communication with MCU" errors](#i-keep-getting-random-lost-communication-with-mcu-errors)
+15. [My Raspberry Pi keeps rebooting during prints](#my-raspberry-pi-keeps-rebooting-during-prints)
+16. [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)
+17. [Will the heaters be left on if the Raspberry Pi crashes?](#will-the-heaters-be-left-on-if-the-raspberry-pi-crashes)
+18. [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)
+19. [How do I cancel an M109/M190 "wait for temperature" request?](#how-do-i-cancel-an-m109m190-wait-for-temperature-request)
+20. [How do I upgrade to the latest software?](#how-do-i-upgrade-to-the-latest-software)
+21. [Can I find out whether the printer has lost steps?](#can-i-find-out-whether-the-printer-has-lost-steps)
+
+### 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.
+
+Klipper uses step_distance instead of steps_per_mm in order to use
+consistent units of measurement in the config file. (The config uses
+millimeters for all distance measurements.) It is believed that
+steps_per_mm originated as an optimization on old 8-bit
+micro-controllers (the desire to use a multiply instead of a divide in
+some low-level code). Continuing to configure this one distance in
+units of "inverse millimeters" is felt to be quirky and unnecessary.
+
+### 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](https://github.com/KevinOConnor/klipper/tree/master/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, it may be possible to manually flash the device
+using tools such as "avrdude" or "bossac" - see the
+[bootloader document](Bootloaders.md) for additional 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](https://github.com/KevinOConnor/klipper/tree/master/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](https://github.com/KevinOConnor/klipper/tree/master/scripts/install-octopi.sh)
+script for further information on the necessary Linux admin steps.
+
+### Can I run multiple instances of Klipper on the same host machine?
+
+It is possible to run multiple instances of the Klipper host software,
+but doing so requires Linux admin knowledge. The Klipper installation
+scripts ultimately cause the following Unix command to be run:
+```
+~/klippy-env/bin/python ~/klipper/klippy/klippy.py ~/printer.cfg -l /tmp/klippy.log
+```
+One can run multiple instances of the above command as long as each
+instance has its own printer config file, its own log file, and its
+own pseudo-tty. For example:
+```
+~/klippy-env/bin/python ~/klipper/klippy/klippy.py ~/printer2.cfg -l /tmp/klippy2.log -I /tmp/printer2
+```
+
+If you choose to do this, you will need to implement the necessary
+start, stop, and installation scripts (if any). The
+[install-octopi.sh](https://github.com/KevinOConnor/klipper/tree/master/scripts/install-octopi.sh)
+script and the
+[klipper-start.sh](https://github.com/KevinOConnor/klipper/tree/master/scripts/klipper-start.sh)
+script may be useful as examples.
+
+### Do I have to use OctoPrint?
+
+The Klipper software is not dependent on OctoPrint. It is possible to
+use alternative software to send commands to Klipper, but doing so
+requires Linux admin knowledge.
+
+Klipper creates a "virtual serial port" via the "/tmp/printer" file,
+and it emulates a classic 3d-printer serial interface via that file.
+In general, alternative software may work with Klipper as long as it
+can be configured to use "/tmp/printer" for the printer serial port.
+
+### 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](https://github.com/KevinOConnor/klipper/tree/master/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
+
+Short answer: Do not use the TMC2208 driver in "standalone mode" with
+Klipper! Do not use the TMC2224 driver in "stealthchop standalone
+mode" with Klipper!
+
+Long answer: Klipper implements very precise timing.
+
+![tmc2208](img/tmc2208.svg.png)
+
+In the above picture, if Klipper is requested to move along the red
+line and if each black line represents the nominal location to step a
+stepper, then in the middle of that movement Klipper will arrange to
+take a step, change the step direction, and then step back. Klipper
+can perform this step, direction change, and step back in a very small
+amount of time.
+
+It is our current understanding that the TMC2208 and TMC2224 will
+react poorly to this when they are in "stealthchop" mode. (It is not
+believed any other TMC drivers are impacted.) It is believed that when
+the driver sees the two step requests in a small time frame that it
+dramatically increases current in anticipation of high acceleration.
+That high current can trip the driver's internal "over current"
+detection which causes the driver to disable itself.
+
+This pattern of steps can occur on all stepper motors and on all
+robot kinematics.
+
+The TMC2208 and TMC2224 do work well with Klipper when run-time
+configuration mode is used (that is, when a wire is routed from the
+micro-controller to the PDN-UART pin and the printer config file has a
+corresponding [tmc2208] config section). When using run-time
+configuration, either configure the drivers to use "spreadcycle mode"
+or configure them to use "stealthchop mode" with a reasonable
+"stealthchop threshold". If one wishes to exclusively use
+"stealthchop" mode with run-time UART configuration then make sure the
+stealthchop_threshold is no more than about 10% greater than the
+maximum velocity of the given axis. It is speculated that with a
+reasonable stealthchop threshold, then if Klipper sends a "step,
+direction change, step back" sequence, the driver will briefly
+transition from stealthchop mode, to spreadcycle mode, and back to
+stealthchop mode, which should be harmless.
+
+### 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](https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/README.md)
+  for the Raspberry Pi and use a
+  [good quality USB cable](https://www.raspberrypi.org/forums/viewtopic.php?p=589877#p589877)
+  to connect that power supply to the Pi. If you get "under voltage"
+  warnings from OctoPrint, this is related to the power supply and it
+  must be fixed.
+- 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.)
+- Verify stepper, heater, and other printer wires are not crimped or
+  frayed. (Printer movement may place stress on a faulty wire causing
+  it to lose contact, briefly short, or generate excessive noise.)
+- 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.)
+
+### My Raspberry Pi keeps rebooting during prints
+
+This is most likely do to voltage fluctuations. Follow the same
+troubleshooting steps for a
+["Lost communication with MCU"](#i-keep-getting-random-lost-communication-with-mcu-errors)
+error.
+
+### 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 - see [Bootloaders](Bootloaders.md) for further details.
+
+### 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](https://github.com/KevinOConnor/klipper/tree/master/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](https://github.com/KevinOConnor/klipper/tree/master/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 cancel an M109/M190 "wait for temperature" request?
+
+Navigate to the OctoPrint terminal tab and issue an M112 command in
+the terminal box. The M112 command will cause Klipper to enter into a
+"shutdown" state, and it will cause OctoPrint to disconnect from
+Klipper. Navigate to the OctoPrint connection area and click on
+"Connect" to cause OctoPrint to reconnect. Navigate back to the
+terminal tab and issue a FIRMWARE_RESTART command to clear the Klipper
+error state.  After completing this sequence, the previous heating
+request will be canceled and a new print may be started.
+
+### 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.
+
+When upgrading the software, be sure to check the
+[config changes](Config_Changes.md) document for information on
+software changes that may require updates to your printer.cfg file.
+
+### Can I find out whether the printer has lost steps?
+
+In a way, yes. Home the printer, issue a `GET_POSITION` command, run
+your print, home again and issue another `GET_POSITION`. Then compare
+the values in the `mcu:` line.
+
+This might be helpful to tune settings like stepper motor currents,
+accelerations and speeds without needing to actually print something
+and waste filament: just run some high-speed moves in between the
+`GET_POSITION` commands.
+
+Note that endstop switches themselves tend to trigger at slightly
+different positions, so a difference of a couple of microsteps is
+likely the result of endstop inaccuracies. A stepper motor itself can
+only lose steps in increments of 4 full steps. (So, if one is using 16
+microsteps, then a lost step on the stepper would result in the "mcu:"
+step counter being off by a multiple of 64 microsteps.)

docs/Features.md

@@ -0,0 +1,153 @@
+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, AD849x, 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,
+  TMC2209, TMC2660, and TMC5160 stepper motor drivers. There is also
+  support for current control of traditional stepper drivers via
+  AD5206, MCP4451, MCP4728, MCP4018, and PWM pins.
+
+* 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](https://github.com/KevinOConnor/klipper/tree/master/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                       | 154K              | 102K              |
+| 20Mhz AVR                       | 192K              | 127K              |
+| Arduino Zero (SAMD21)           | 234K              | 217K              |
+| "Blue Pill" (STM32F103)         | 387K              | 360K              |
+| Arduino Due (SAM3X8E)           | 438K              | 438K              |
+| Duet2 Maestro (SAM4S8C)         | 564K              | 564K              |
+| Smoothieboard (LPC1768)         | 574K              | 574K              |
+| Smoothieboard (LPC1769)         | 661K              | 661K              |
+| Beaglebone PRU                  | 680K              | 680K              |
+| Duet2 Wifi/Eth (SAM4E8E)        | 686K              | 686K              |
+| Adafruit Metro M4 (SAMD51)      | 733K              | 694K              |
+| BigTreeTech SKR Pro (STM32F407) | 922K              | 711K              |
+
+On AVR platforms, the highest achievable step rate is with just one
+stepper stepping. On the SAMD21 and STM32F103 the highest step rate is
+with two simultaneous steppers stepping. On the SAM3X8E, SAM4S8C,
+SAM4E8E, LPC176x, and PRU the highest step rate is with three
+simultaneous steppers. On the SAMD51 and STM32F4 the highest step rate
+is with four simultaneous steppers. (Further details on the benchmarks
+are available in the [Benchmarks document](Benchmarks.md).)

docs/G-Codes.md

@@ -0,0 +1,532 @@
+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](https://github.com/KevinOConnor/klipper/tree/master/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>]
+  [MOVE=1 [MOVE_SPEED=<speed>]]`: 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). If "MOVE=1" is specified then a toolhead move will be
+  issued to apply the given offset (otherwise the offset will take
+  effect on the next absolute G-Code move that specifies the given
+  axis). If "MOVE_SPEED" is specified then the toolhead move will be
+  performed with the given speed (in mm/s); otherwise the toolhead
+  move will use the last specified G-Code speed.
+- `SAVE_GCODE_STATE [NAME=<state_name>]`: Save the current
+  g-code coordinate parsing state. Saving and restoring the g-code
+  state is useful in scripts and macros. This command saves the
+  current g-code absolute coordinate mode (G90/G91), absolute extrude
+  mode (M82/M83), origin (G92), offset (SET_GCODE_OFFSET), speed
+  override (M220), extruder override (M221), move speed, current XYZ
+  position, and relative extruder "E" position. If NAME is provided it
+  allows one to name the saved state to the given string. If NAME is
+  not provided it defaults to "default".
+- `RESTORE_GCODE_STATE [NAME=<state_name>]
+  [MOVE=1 [MOVE_SPEED=<speed>]]`: Restore a state previously saved via
+  SAVE_GCODE_STATE. If "MOVE=1" is specified then a toolhead move will
+  be issued to move back to the previous XYZ position. If "MOVE_SPEED"
+  is specified then the toolhead move will be performed with the given
+  speed (in mm/s); otherwise the toolhead move will use the restored
+  g-code speed.
+- `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_HEATER_TEMPERATURE HEATER=<heater_name> [TARGET=<target_temperature>]`:
+  Sets the target temperature for a heater. If a target temperature is
+  not supplied, the target is 0.
+- `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.
+- `MANUAL_PROBE [SPEED=<speed>]`: Run a helper script useful for
+  measuring the height of the nozzle at a given location. If SPEED is
+  specified, it sets the speed of TESTZ commands (the default is
+  5mm/s). During a manual probe, the following additional commands are
+  available:
+  - `ACCEPT`: This command accepts the current Z position and
+  concludes the manual probing tool.
+  - `ABORT`: This command terminates the manual probing tool.
+  - `TESTZ Z=<value>`: This command moves the nozzle up or down by the
+    amount specified in "value". For example, `TESTZ Z=-.1` would move
+    the nozzle down .1mm while `TESTZ Z=.1` would move the nozzle up
+    .1mm. The value may also be `+`, `-`, `++`, or `--` to move the
+    nozzle up or down an amount relative to previous attempts.
+- `Z_ENDSTOP_CALIBRATE [SPEED=<speed>]`: Run a helper script useful
+  for calibrating a Z position_endstop config setting. See the
+  MANUAL_PROBE command for details on the parameters and the
+  additional commands available while the tool is active.
+- `TUNING_TOWER COMMAND=<command> PARAMETER=<name> START=<value>
+  FACTOR=<value> [BAND=<value>]`: A tool for tuning a parameter on
+  each Z height during a print. The tool will run the given COMMAND
+  with the given PARAMETER assigned to the value using the formula
+  `value = start + factor * z_height`. If BAND is provided then the
+  adjustment will only be made every BAND millimeters of z height - in
+  that case the formula used is `value = start + factor *
+  ((floor(z_height / band) + .5) * band)`.
+- `SET_IDLE_TIMEOUT [TIMEOUT=<timeout>]`:  Allows the user to set the
+  idle timeout (in seconds).
+- `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.
+
+## G-Code Macro Commands
+
+The following command is available when a "gcode_macro" config section
+is enabled:
+- `SET_GCODE_VARIABLE MACRO=<macro_name> VARIABLE=<name>
+  VALUE=<value>`: This command allows one to change the value of a
+  gcode_macro variable at run-time. The provided VALUE is parsed as a
+  Python literal.
+
+## Custom Pin Commands
+
+The following command is available when an "output_pin" config section
+is enabled:
+- `SET_PIN PIN=config_name VALUE=<value>`
+
+## Neopixel and Dotstar Commands
+
+The following command is available when "neopixel" or "dotstar" config
+sections are enabled:
+- `SET_LED LED=<config_name> INDEX=<index> RED=<value> GREEN=<value>
+  BLUE=<value>`: This sets the LED output. Each color <value> must be
+  between 0.0 and 1.0. If multiple LED chips are daisy-chained then
+  one may specify INDEX to alter the color of just the given chip (1
+  for the first chip, 2 for the second, etc.). If INDEX is not
+  provided then all LEDs in the daisy-chain will be set to the
+  provided color.
+
+## 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>]`
+
+## Manual stepper Commands
+
+The following command is available when a "manual_stepper" config
+section is enabled:
+- `MANUAL_STEPPER STEPPER=config_name [ENABLE=[0|1]]
+  [SET_POSITION=<pos>] [SPEED=<speed>] [ACCEL=<accel>]
+  [MOVE=<pos> [STOP_ON_ENDSTOP=1]]`: This command will alter the state
+  of the stepper. Use the ENABLE parameter to enable/disable the
+  stepper. Use the SET_POSITION parameter to force the stepper to
+  think it is at the given position. Use the MOVE parameter to request
+  a movement to the given position. If SPEED and/or ACCEL is specified
+  then the given values will be used instead of the defaults specified
+  in the config file. If an ACCEL of zero is specified then no
+  acceleration will be preformed. If STOP_ON_ENDSTOP is specified then
+  the move will end early should the endstop report as triggered (use
+  STOP_ON_ENDSTOP=-1 to stop early should the endstop report not
+  triggered).
+
+## Probe
+
+The following commands are available when a "probe" config section is
+enabled:
+- `PROBE [PROBE_SPEED=<mm/s>] [SAMPLES=<count>]
+  [SAMPLE_RETRACT_DIST=<mm>] [SAMPLES_TOLERANCE=<mm>]
+  [SAMPLES_TOLERANCE_RETRIES=<count>]
+  [SAMPLES_RESULT=median|average]`: Move the nozzle downwards until
+  the probe triggers. If any of the optional parameters are provided
+  they override their equivalent setting in the probe config section
+  (see
+  [example-extras.cfg](https://github.com/KevinOConnor/klipper/tree/master/config/example-extras.cfg)
+  for details).
+- `QUERY_PROBE`: Report the current status of the probe ("triggered"
+  or "open").
+- `PROBE_ACCURACY [PROBE_SPEED=<mm/s>] [SAMPLES=<count>]
+  [SAMPLE_RETRACT_DIST=<mm>]`: Calculate the maximum, minimum,
+  average, median, and standard deviation of multiple probe
+  samples. By default, 10 SAMPLES are taken. Otherwise the optional
+  parameters default to their equivalent setting in the probe config
+  section.
+- `PROBE_CALIBRATE [SPEED=<speed>] [<probe_parameter>=<value>]`: Run a
+  helper script useful for calibrating the probe's z_offset. See the
+  PROBE command for details on the optional probe parameters. See the
+  MANUAL_PROBE command for details on the SPEED parameter and the
+  additional commands available while the tool is active.
+
+## 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.
+
+See [Working with the BL-Touch](BLTouch.md) for more details.
+
+## Delta Calibration
+
+The following commands are available when the "delta_calibrate" config
+section is enabled:
+- `DELTA_CALIBRATE [METHOD=manual] [<probe_parameter>=<value>]`: This
+  command will probe seven points on the bed and recommend updated
+  endstop positions, tower angles, and radius. See the PROBE command
+  for details on the optional probe parameters. If METHOD=manual is
+  specified then the manual probing tool is activated - see the
+  MANUAL_PROBE command above for details on the additional commands
+  available while this tool is active.
+- `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] [<probe_parameter>=<value>]`:
+  This command will probe the points specified in the config and then
+  recommend updated x and y tilt adjustments. See the PROBE command
+  for details on the optional probe parameters. If METHOD=manual is
+  specified then the manual probing tool is activated - see the
+  MANUAL_PROBE command above for details on the additional commands
+  available while this tool is active.
+
+## Mesh Bed Leveling
+
+The following commands are available when the "bed_mesh" config
+section is enabled:
+- `BED_MESH_CALIBRATE [METHOD=manual] [<probe_parameter>=<value>]`:
+  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. See the PROBE command
+  for details on the optional probe parameters. If METHOD=manual is
+  specified then the manual probing tool is activated - see the
+  MANUAL_PROBE command above for details on the additional commands
+  available while this tool is active.
+- `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.
+
+## Bed Screws Helper
+
+The following commands are available when the "bed_screws" config
+section is enabled:
+- `BED_SCREWS_ADJUST`: This command will invoke the bed screws
+  adjustment tool. It will command the nozzle to different locations
+  (as defined in the config file) and allow one to make adjustments to
+  the bed screws so that the bed is a constant distance from the
+  nozzle.
+
+## Bed Screws Tilt adjust Helper
+
+The following commands are available when the "screws_tilt_adjust"
+config section is enabled:
+- `SCREWS_TILT_CALCULATE [<probe_parameter>=<value>]`: This command
+  will invoke the bed screws adjustment tool. It will command the
+  nozzle to different locations (as defined in the config file)
+  probing the z height and calculate the number of knob turns to
+  adjust the bed level. See the PROBE command for details on the
+  optional probe parameters.
+  IMPORTANT: You MUST always do a G28 before using this command.
+
+## Z Tilt
+
+The following commands are available when the "z_tilt" config section
+is enabled:
+- `Z_TILT_ADJUST [<probe_parameter>=<value>]`: This command will probe
+  the points specified in the config and then make independent
+  adjustments to each Z stepper to compensate for tilt. See the PROBE
+  command for details on the optional probe parameters.
+
+## 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, TMC2660, TMC2208, TMC2209 and TMC5160
+
+The following commands are available when any of the "tmcXXXX" config sections is enabled:
+- `DUMP_TMC STEPPER=<name>`: This command will read the TMC driver
+  registers and report their values.
+- `INIT_TMC STEPPER=<name>`: This command will intitialize the TMC
+  registers. Needed to re-enable the driver if power to the chip is
+  turned off then back on.
+- `SET_TMC_CURRENT STEPPER=<name> CURRENT=<amps> HOLDCURRENT=<amps>`:
+  This will adjust the run and hold currents of the TMC driver.
+  HOLDCURRENT is applicable only to the tmc2130, tmc2208, tmc2209 and tmc5160.
+- `SET_TMC_FIELD STEPPER=<name> FIELD=<field> VALUE=<value>`: This will
+  alter the value of the specified register field of the TMC driver.
+  This command is intended for low-level diagnostics and debugging only because
+  changing the fields during run-time can lead to undesired and potentially
+  dangerous behavior of your printer. Permanent changes should be made using
+  the printer configuration file instead. No sanity checks are performed for the
+  given 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>
+  [ACCEL=<value>]`: This command will forcibly move the given stepper
+  the given distance (in mm) at the given constant velocity (in
+  mm/s). If ACCEL is specified and is greater than zero, then the
+  given acceleration (in mm/s^2) will be used; otherwise 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.
+
+## Send message (respond) to host
+
+The following commands are availabe when the "respond" config section is
+enabled.
+  - `M118 <message>`: echo the message prepended with the configured default
+    prefix (or `echo: ` if no prefix is configured).
+  - `RESPOND MSG="<message>"`: echo the message prepended with the configured default
+    prefix (or `echo: ` if no prefix is configured).
+  - `RESPOND TYPE=echo MSG="<message>"`: echo the message prepended with `echo: `.
+  - `RESPOND TYPE=command MSG="<message>"`: echo the message prepended with `// `.
+    Octopint can be configured to respond to these messages (e.g.
+    `RESPOND TYPE=command MSG=action:pause`).
+  - `RESPOND TYPE=error MSG="<message>"`: echo the message prepended with `!! `.
+  - `RESPOND PREFIX=<prefix> MSG="<message>"`: echo the message prepended with `<prefix>`
+    (The `PREFIX` parameter will take priority over the `TYPE` parameter)
+
+## Pause Resume
+
+The following commands are available when the "pause_resume" config section
+is enabled:
+  - `PAUSE`:  Pauses the current print.  The current position is captured for
+  restoration upon resume.
+  - `RESUME [VELOCITY=<value>]`: Resumes the print from a pause, first restoring
+  the previously captured position.  The VELOCITY parameter determines the speed
+  at which the tool should return to the original captured position.
+  - `CLEAR_PAUSE`:  Clears the current paused state without resuming the print.
+  This is useful if one decides to cancel a print after a PAUSE.  It is recommended
+  to add this to your start gcode to make sure the paused state is fresh for each
+  print.
+
+## Filament Sensor
+
+The following command is available when the "filament_switch_sensor" config
+section is enabled.
+ - `QUERY_FILAMENT_SENSOR SENSOR=<sensor_name>`: Queries the current status of
+  the filament sensor.  The data displayed on the terminal will depend on the
+  sensor type defined in the confguration.
+ - `SET_FILAMENT_SENSOR SENSOR=<sensor_name> ENABLE=[0|1]`:  Sets the
+   filament sensor on/off.  If ENABLE is set to 0, the filament sensor will
+   be disabled, if set to 1 it is enabled.
+
+## Firmware Retraction
+
+The following commands are available when the "firmware_retraction"
+config section is enabled.  These commands allow you to utilise the
+firmware retraction feature available in many slicers, to reduce
+stringing during non-extrusion moves from one part of the print to
+another.  Appropriately configuring pressure advance reduces the length
+of retraction required.
+ - `SET_RETRACTION [RETRACT_LENGTH=<mm>] [RETRACT_SPEED=<mm/s>]
+   [UNRETRACT_EXTRA_LENGTH=<mm>] [UNRETRACT_SPEED=<mm/s>]`: Adjust the
+   parameters used by firmware retraction. RETRACT_LENGTH determines
+   the length of filament to retract and unretract. The speed of
+   retraction is adjusted via RETRACT_SPEED, and is typically set
+   relatively high. The speed of unretraction is adjusted via
+   UNRETRACT_SPEED, and is not particularly critical, although often
+   lower than RETRACT_SPEED. In some cases it is useful to add a small
+   amount of additional length on unretraction, and this is set via
+   UNRETRACT_EXTRA_LENGTH. SET_RETRACTION is commonly set as part of
+   slicer per-filament configuration, as different filaments require
+   different parameter settings.
+ - `GET_RETRACTION`: Queries the current parameters used by firmware
+   retraction and displays them on the terminal.
+ - `G10`: Retracts the extruder using the currently configured
+   parameters.
+ - `G11`: Unretracts the extruder using the currently configured
+   parameters.
+
+## Skew Correction
+
+The following commands are available when the "skew_correction" config
+section is enabled.
+  - `SET_SKEW [XY=<ac_length,bd_length,ad_length>] [XZ=<ac,bd,ad>]
+    [YZ=<ac,bd,ad>] [CLEAR=<0|1>]`:  Configures the [skew_correction] module
+    with measurements (in mm) taken from a calibration print.  One may
+    enter measurements for any combination of planes, planes not entered will
+    retain their current value.  If `CLEAR=1` is entered then all skew
+    correction will be disabled.
+  - `GET_CURRENT_SKEW`: Reports the current printer skew for each plane in
+    both radians and degrees.  The skew is calculated based on parameters
+    provided via the `SET_SKEW` gcode.
+  - `CALC_MEASURED_SKEW [AC=<ac_length>] [BD=<bd_length>] [AD=<ad_length>]`:
+    Calculates and reports the skew (in radians and degrees) based on a
+    measured print.  This can be useful for determining the printer's current
+    skew after correction has been applied.  It may also be useful before
+    correction is applied to determine if skew correction is necessary.   See
+    skew_correction.md for details on skew calibration objects and
+    measurements.
+  - `SKEW_PROFILE [LOAD=<name>] [SAVE=<name>] [REMOVE=<name>]`: Profile
+    management for skew_correction.  LOAD will restore skew state from the
+    profile matching the supplied name. SAVE will save the current skew 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.
+
+## Delayed GCode
+
+The following command is enabled if a [delayed_gcode] config section has
+been enabled:
+  - `UPDATE_DELAYED_GCODE [ID=<name>] [DURATION=<seconds>]`:  Updates the
+    delay duration for the identified [delayed_gcode] and starts the timer
+    for gcode execution.  A value of 0 will cancel a pending delayed gcode
+    from executing.

docs/Installation.md

@@ -0,0 +1,193 @@
+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 a number of Atmel ATmega based
+micro-controllers,
+[ARM based micro-controllers](Features.md#step-benchmarks), 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.16.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.11 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. Once configured, run:
+
+```
+make
+```
+
+It is necessary to determine the serial port connected to the
+micro-controller. For micro-controllers that connect via USB, run the
+following:
+
+```
+ls /dev/serial/by-id/*
+```
+
+It should report something similar to the following:
+
+```
+/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
+```
+
+It's common for each printer to have its own unique serial port name.
+This unique name will be used when flashing the micro-controller. It's
+possible there may be multiple lines in the above output - if so,
+choose the line corresponding to the micro-controller (see the
+[FAQ](FAQ.md#wheres-my-serial-port) for more information).
+
+For common micro-controllers, the code can be flashed with something
+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
+```
+
+Be sure to update the FLASH_DEVICE with the printer's unique serial
+port name.
+
+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").
+
+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 then configure the following items:
+
+Navigate to the Settings tab (the wrench icon at the top of the
+page). 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".
+
+In the Settings tab, 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](https://github.com/KevinOConnor/klipper/tree/master/config/). The
+[example.cfg](https://github.com/KevinOConnor/klipper/tree/master/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.
+
+It's common for each printer to have its own unique name for the
+micro-controller. The name may change after flashing Klipper, so rerun
+the `ls /dev/serial/by-id/*` command and then update the config file
+with the unique name. For example, update the `[mcu]` section to look
+something similar to:
+
+```
+[mcu]
+serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
+```
+
+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.

docs/Kinematics.md

@@ -0,0 +1,302 @@
+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.

docs/MCU_Commands.md

@@ -0,0 +1,302 @@
+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". Note that
+parameters that are considered "enumerations" (see the above protocol
+document) take a string value which is automatically converted to an
+integer value for the micro-controller. This is common with parameters
+named "pin" (or that have a suffix of "_pin").
+
+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.
+
+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_endstop 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
+  endstop_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 endstop_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 on_ticks=%u` : 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.
+
+* `endstop_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_endstop' 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.

docs/Manual_Level.md

@@ -0,0 +1,185 @@
+This document describes tools for calibrating a Z endstop and for
+performing adjustments to bed leveling screws.
+
+# Calibrating a Z endstop
+
+An accurate Z endstop position is critical to obtaining high quality
+prints.
+
+Note, though, the accuracy of the Z endstop switch itself can be a
+limiting factor. If one is using Trinamic stepper motor drivers then
+consider enabling [endstop phase](Endstop_Phase.md) detection to
+improve the accuracy of the switch.
+
+To perform a Z endstop calibration, home the printer, move the head to
+a position near the center of the bed, navigate to the OctoPrint
+terminal tab, and run:
+```
+Z_ENDSTOP_CALIBRATE
+```
+Then follow the steps described at
+["the paper test"](Bed_Level.md#the-paper-test) to determine the
+actual distance between the nozzle and bed at the given location. Once
+those steps are complete one can `ACCEPT` the position and save the
+results to the config file with:
+```
+SAVE_CONFIG
+```
+
+It's preferable to use a Z endstop switch on the opposite end of the Z
+axis from the bed. (Homing away from the bed is more robust as then it
+is generally always safe to home the Z.) However, if one must home
+towards the bed it is recommended to adjust the endstop so that it
+triggers a small distance (eg, .5mm) above the bed. Almost all endstop
+switches can safely be depressed a small distance beyond their trigger
+point. When this is done, one should find that the
+`Z_ENDSTOP_CALIBRATE` command reports a small positive value (eg,
+.5mm) for the Z position_endstop. Triggering the endstop while it is
+still some distance from the bed reduces the risk of inadvertent bed
+crashes.
+
+Some printers have the ability to manually adjust the location of the
+physical endstop switch. However, it's recommended to perform Z
+endstop positioning in software with Klipper - once the physical
+location of the endstop is in a convenient location, one can make any
+further adjustments by running Z_ENDSTOP_CALIBRATE or by manually
+updating the Z position_endstop in the configuration file.
+
+# Adjusting bed leveling screws
+
+The secret to getting good bed leveling with bed leveling screws is to
+utilize the printer's high precision motion system during the bed
+leveling process itself. This is done by commanding the nozzle to a
+position near each bed screw and then adjusting that screw until the
+bed is a set distance from the nozzle. Klipper has a tool to assist
+with this. In order to use the tool it is necessary to specify each
+screw XY location.
+
+This is done by creating a `[bed_screws]` config section. For example,
+it might look something similar to:
+```
+[bed_screws]
+screw1: 100,50
+screw2: 100,150
+screw3: 150,100
+```
+
+If a bed screw is under the bed, then specify the XY position directly
+above the screw. If the screw is outside the bed then specify an XY
+position closest to the screw that is still within the range of the
+bed.
+
+Once the config file is ready, run `RESTART` to load that config, and
+then one can start the tool by running:
+```
+BED_SCREWS_ADJUST
+```
+
+This tool will move the printer's nozzle to each screw XY location and
+then move the nozzle to a Z=0 height. At this point one can use the
+"paper test" to adjust the bed screw directly under the nozzle. See
+the information described in
+["the paper test"](Bed_Level.md#the-paper-test), but adjust the bed
+screw instead of commanding the nozzle to different heights. Adjust
+the bed screw until there is a small amount of friction when pushing
+the paper back and forth.
+
+Once the screw is adjusted so that a small amount of friction is felt,
+run either the `ACCEPT` or `ADJUSTED` command. Use the `ADJUSTED`
+command if the bed screw needed an adjustment (typically anything more
+than about 1/8th of a turn of the screw). Use the `ACCEPT` command if
+no significant adjustment is necessary. Both commands will cause the
+tool to proceed to the next screw. (When an `ADJUSTED` command is
+used, the tool will schedule an additional cycle of bed screw
+adjustments; the tool completes successfully when all bed screws are
+verified to not require any significant adjustments.) One can use the
+`ABORT` command to exit the tool early.
+
+This system works best when the printer has a flat printing surface
+(such as glass) and has straight rails. Upon successful completion of
+the bed leveling tool the bed should be ready for printing.
+
+## Fine grained bed screw adjustments
+
+If the printer uses three bed screws and all three screws are under
+the bed, then it may be possible to perform a second "high precision"
+bed leveling step. This is done by commanding the nozzle to locations
+where the bed moves a larger distance with each bed screw adjustment.
+
+For example, consider a bed with screws at locations A, B, and C:
+
+![bed_screws](img/bed_screws.svg.png)
+
+For each adjustment made to the bed screw at location C, the bed will
+swing along a pendulum defined by the remaining two bed screws (shown
+here as a green line). In this situation, each adjustment to the bed
+screw at C will move the bed at position D a further amount than
+directly at C. It is thus possible to make an improved C screw
+adjustment when the nozzle is at position D.
+
+To enable this feature, one would determine the additional nozzle
+coordinates and add them to the config file. For example, it might
+look like:
+```
+[bed_screws]
+screw1: 100,50
+screw1_fine_adjust: 0,0
+screw2: 100,150
+screw2_fine_adjust: 300,300
+screw3: 150,100
+screw3_fine_adjust: 0,100
+```
+
+When this feature is enabled, the `BED_SCREWS_ADJUST` tool will first
+prompt for coarse adjustments directly above each screw position, and
+once those are accepted, it will prompt for fine adjustments at the
+additional locations. Continue to use `ACCEPT` and `ADJUSTED` at each
+position.
+
+# Adjusting bed leveling screws using the bed probe
+
+This is another way to calibrate the bed level using the bed probe. To
+use it you must have a Z probe (BL Touch, Inductive sensor, etc).
+
+To enable this feature, one would determine the nozzle coordinates
+near the screws and add them to the config file. For example, it might
+look like:
+
+```
+[screws_tilt_adjust]
+screw1: -5,30
+screw1_name: front left screw
+screw2: 155,30
+screw2_name: front right screw
+screw3: 155,190
+screw3_name: rear right screw
+screw4: -5,190
+screw4_name: rear left screw
+horizontal_move_z: 10.
+speed: 50.
+screw_thread: CW-M3
+```
+
+The screw1 is always the reference point for the others, so the system
+assumes that screw1 is in the correct height. Always run `G28` first
+and then run `SCREWS_TILT_CALCULATE` - it should produce output
+similar to:
+```
+Send: G28
+Recv: ok
+Send: SCREWS_TILT_CALCULATE
+Recv: // front left screw (Base): X -5.0, Y 30.0, Z 2.48750
+Recv: // front right screw : X 155.0, Y 30.0, Z 2.36000 : Adjust -> CW 01:15
+Recv: // rear right screw : X 155.0, Y 190.0, Z 2.71500 : Adjust -> CCW 00:50
+Recv: // read left screw : X -5.0, Y 190.0, Z 2.47250 : Adjust -> CW 00:02
+Recv: ok
+```
+This means that:
+
+    - front left screw is the reference point you must not change it.
+    - front right screw must be turned clockwise 1 full turn and a quarter turn
+    - rear right screw must be turned counter-clockwise 50 minutes
+    - read left screw must be turned clockwise 2 minutes (not need it's ok)
+
+Repeat the process several times until you get a good level bed -
+normally when all adjustments are below 6 minutes.

docs/Overview.md

@@ -0,0 +1,71 @@
+Welcome to the Klipper documentation. If new to Klipper, start with
+the [features](Features.md) and [installation](Installation.md)
+documents.
+
+# Overview information
+
+- [Features](Features.md): A high-level list of features in Klipper.
+- [FAQ](FAQ.md): Frequently asked questions.
+- [Releases](Releases.md): The history of Klipper releases.
+- [Config changes](Config_Changes.md): Recent software changes that
+may require users to update their printer config file.
+- [Contact](Contact.md): Information on bug reporting and general
+communication with the Klipper developers.
+
+# Configuration and Tuning Guides
+
+- [Installation](Installation.md): Guide to installing Klipper.
+  - [config/example.cfg](https://github.com/KevinOConnor/klipper/tree/master/config/example.cfg)
+    a reference for the config file.
+- [Config checks](Config_checks.md): Verify basic pin settings in the
+  config file.
+- [Bed level](Bed_Level.md): Information on "bed leveling" in Klipper.
+  - [Delta calibrate](Delta_Calibrate.md): Calibration of delta
+    kinematics.
+  - [Probe calibrate](Probe_Calibrate.md): Calibration of automatic Z
+    probes.
+  - [BL-Touch](BLTouch.md): Configure a "BL-Touch" Z probe.
+  - [Manual level](Manual_Level.md): Calibration of Z endstops (and
+    similar).
+  - [Endstop phase](Endstop_Phase.md): Stepper assisted Z endstop
+    positioning.
+- [Pressure advance](Pressure_Advance.md): Calibrate extruder
+  pressure.
+- [Slicers](Slicers.md): Configure "slicer" software for Klipper.
+- [Command Templates](Command_Templates.md): G-Code macros and
+  conditional evaluation.
+- [Sensorless homing](Sensorless_Homing.md): Configuring tmc2130
+  sensorless homing.
+- [Skew correction](skew_correction.md): Adjustments for axes not
+  perfectly square.
+- [G-Codes](G-Codes.md): Information on commands supported by Klipper.
+
+# Developer Documentation
+
+- [Code overview](Code_Overview.md): Developers should read this
+  first.
+- [Kinematics](Kinematics.md): Technical details on how Klipper
+  implements motion.
+- [Protocol](Protocol.md): Information on the low-level messaging
+  protocol between host and micro-controller.
+- [MCU commands](MCU_Commands.md): A description of low-level commands
+  implemented in the micro-controller software.
+- [Debugging](Debugging.md): Information on how to test and debug
+  Klipper.
+- [Benchmarks](Benchmarks.md): Information on the Klipper benchmark
+  method.
+- [Contributing](CONTRIBUTING.md): Information on how to submit
+  improvements to Klipper.
+- [Packaging](Packaging.md): Information on building OS packages.
+
+# Device Specific Documents
+
+- [Bootloaders](Bootloaders.md): Developer information on
+  micro-controller flashing.
+- [stm32f1](stm32f1.md): Information on the STM32F1 micro-controller
+  port.
+- [Beaglebone](beaglebone.md): Details for running Klipper on the
+  Beaglebone PRU.
+- [stm32f0](stm32f0_CAN.md): Information on the STM32F0 micro-controller
+  port.
+- [TSL1401CL filament width sensor](TSL1401CL_Filament_Width_Sensor.md)

docs/Packaging.md

@@ -0,0 +1,31 @@
+# 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.

docs/Pressure_Advance.md

@@ -0,0 +1,143 @@
+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.

docs/Probe_Calibrate.md

@@ -0,0 +1,185 @@
+This document describes the method for calibrating the x, y, and z
+offsets of an "automatic z probe" in Klipper. This is useful for users
+that have a `[probe]` or `[bltouch]` section in their config file.
+
+# Calibrating probe X and Y offsets
+
+To calibrate the X and Y offset, navigate to the OctoPrint "Control"
+tab, home the printer, and then use the OctoPrint jogging buttons to
+move the head to a position near the center of the bed.
+
+Place a piece of blue painters tape (or similar) on the bed underneath
+the probe. Navigate to the OctoPrint "Terminal" tab and issue a PROBE
+command:
+```
+PROBE
+```
+Place a mark on the tape directly under where the probe is (or use a
+similar method to note the location on the bed).
+
+Issue a `GET_POSITION` command and record the toolhead XY location
+reported by that command. For example if one sees:
+```
+Recv: // toolhead: X:46.500000 Y:27.000000 Z:15.000000 E:0.000000
+```
+then one would record a probe X position of 46.5 and probe Y position
+of 27.
+
+After recording the probe position, issue a series of G1 commands
+until the nozzle is directly above the mark on the bed. For example,
+one might issue:
+```
+G1 F300 X57 Y30 Z15
+```
+to move the nozzle to an X position of 57 and Y of 30. Once one finds
+the position directly above the mark, use the `GET_POSITION` command
+to report that position. This is the nozzle position.
+
+The x_offset is then the `nozzle_x_position - probe_x_position` and
+y_offset is similarly the `nozzle_y_position - probe_y_position`.
+Update the printer.cfg file with the given values, remove the
+tape/marks from the bed, and then issue a `RESTART` command so that
+the new values take effect.
+
+# Calibrating probe Z offset
+
+Providing an accurate probe z_offset is critical to obtaining high
+quality prints. The z_offset is the distance between the nozzle and
+bed when the probe triggers. The Klipper `PROBE_CALIBRATE` tool can be
+used to obtain this value - it will run an automatic probe to measure
+the probe's Z trigger position and then start a manual probe to obtain
+the nozzle Z height. The probe z_offset will then be calculated from
+these measurements.
+
+Start by homing the printer and then move the head to a position near
+the center of the bed. Navigate to the OctoPrint terminal tab and run
+the `PROBE_CALIBRATE` command to start the tool.
+
+This tool will perform an automatic probe, then lift the head, move
+the nozzle over the location of the probe point, and start the manual
+probe tool. If the nozzle does not move to a position above the
+automatic probe point, then `ABORT` the manual probe tool and perform
+the XY probe offset calibration described above.
+
+Once the manual probe tool starts, follow the steps described at
+["the paper test"](Bed_Level.md#the-paper-test)) to determine the
+actual distance between the nozzle and bed at the given location. Once
+those steps are complete one can `ACCEPT` the position and save the
+results to the config file with:
+```
+SAVE_CONFIG
+```
+
+# Repeatability check
+
+After calibrating the probe X, Y, and Z offsets it is a good idea to
+verify that the probe provides repeatable results. Start by homing the
+printer and then move the head to a position near the center of the
+bed. Navigate to the OctoPrint terminal tab and run the
+`PROBE_ACCURACY` command.
+
+This command will run the probe ten times and produce output similar
+to the following:
+```
+Recv: // probe accuracy: at X:0.000 Y:0.000 Z:10.000
+Recv: // and read 10 times with speed of 5 mm/s
+Recv: // probe at -0.003,0.005 is z=2.506948
+Recv: // probe at -0.003,0.005 is z=2.519448
+Recv: // probe at -0.003,0.005 is z=2.519448
+Recv: // probe at -0.003,0.005 is z=2.506948
+Recv: // probe at -0.003,0.005 is z=2.519448
+Recv: // probe at -0.003,0.005 is z=2.519448
+Recv: // probe at -0.003,0.005 is z=2.506948
+Recv: // probe at -0.003,0.005 is z=2.506948
+Recv: // probe at -0.003,0.005 is z=2.519448
+Recv: // probe at -0.003,0.005 is z=2.506948
+Recv: // probe accuracy results: maximum 2.519448, minimum 2.506948, range 0.012500, average 2.513198, median 2.513198, standard deviation 0.006250
+```
+
+Ideally the tool will report an identical maximum and minimum value.
+(That is, ideally the probe obtains an identical result on all ten
+probes.) However, it's normal for the minimum and maximum values
+to differ by one Z step_distance or up to 5 microns (.005mm).
+The distance between the minimum and the maximum value is called the
+range. So, in the above example, since the printer uses a
+Z step_distance of .0125, a range of 0.012500 would be considered normal.
+
+If the results of the test show a range value that is greater than
+25 microns (.025mm) then the probe does not have sufficient accuracy
+for typical bed leveling procedures. It may be possible to tune the
+probe speed and/or probe start height to improve the repeatability
+of the probe. The `PROBE_ACCURACY` command allows one to run tests
+with different parameters to see their impact - see
+the [G-Codes document](G-Codes.md) for further details. If the probe
+generally obtains repeatable results but has an occasional outlier,
+then it may be possible to account for that by using multiple samples
+on each probe - read the description of the probe `samples` config
+parameters in the
+[example-extras.cfg](https://github.com/KevinOConnor/klipper/tree/master/config/example-extras.cfg)
+file for more details.
+
+If new probe speed, samples count, or other settings are needed, then
+update the printer.cfg file and issue a `RESTART` command. If so, it
+is a good idea to
+[calibrate the z_offset](#calibrating-probe-z-offset) again. If
+repeatable results can not be obtained then don't use the probe for
+bed leveling. Klipper has several manual probing tools that can be
+used instead - see the [Bed Level document](Bed_Level.md) for further
+details.
+
+# Location Bias Check
+
+Some probes can have a systemic bias that corrupts the results of the
+probe at certain toolhead locations. For example, if the probe mount
+tilts slightly when moving along the Y axis then it could result in
+the probe reporting biased results at different Y positions.
+
+This is a common issue with probes on delta printers, however it can
+occur on all printers.
+
+One can check for a location bias by using the `PROBE_CALIBRATE`
+command to measuring the probe z_offset at various X and Y
+locations. Ideally, the probe z_offset would be a constant value at
+every printer location.
+
+For delta printers, try measuring the z_offset at a position near the
+A tower, at a position near the B tower, and at a position near the C
+tower. For cartesian, corexy, and similar printers, try measuring the
+z_offset at positions near the four corners of the bed.
+
+Before starting this test, first calibrate the probe X, Y, and Z
+offsets as described at the beginning of this document. Then home the
+printer and navigate to the first XY position. Follow the steps at
+[calibrating probe Z offset](#calibrating-probe-z-offset) to run the
+`PROBE_CALIBRATE` command, `TESTZ` commands, and `ACCEPT` command, but
+do not run `SAVE_CONFIG`. Note the reported z_offset found. Then
+navigate to the other XY positions, repeat these `PROBE_CALIBRATE`
+steps, and note the reported z_offset.
+
+If the difference between the minimum reported z_offset and the
+maximum reported z_offset is greater than 25 microns (.025mm) then the
+probe is not suitable for typical bed leveling procedures. See the
+[Bed Level document](Bed_Level.md) for manual probe alternatives.
+
+# Temperature Bias
+
+Many probes have a systemic bias when probing at different
+temperatures. For example, the probe may consistently trigger at a
+lower height when the probe is at a higher temperature.
+
+It is recommended to run the bed leveling tools at a consistent
+temperature to account for this bias. For example, either always run
+the tools when the printer is at room temperature, or always run the
+tools after the printer has obtained a consistent print temperature.
+In either case, it is a good idea to wait several minutes after the
+desired temperature is reached, so that the printer apparatus is
+consistently at the desired temperature.
+
+To check for a temperature bias, start with the printer at room
+temperature and then home the printer, move the head to a position
+near the center of the bed, and run the `PROBE_ACCURACY` command. Note
+the results. Then, without homing or disabling the stepper motors,
+heat the printer nozzle and bed to printing temperature, and run the
+`PROBE_ACCURACY` command again. Ideally, the command will report
+identical results. As above, if the probe does have a temperature bias
+then be careful to always use the probe at a consistent temperature.

docs/Protocol.md

@@ -0,0 +1,358 @@
+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=PA3 value=1
+set_digital_out pin=PA7 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_update_digital_out, "update_digital_out oid=%c value=%c");
+```
+
+The above declares a command named "update_digital_out". This allows
+the host to "invoke" this command which would cause the
+command_update_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_update_digital_out() C code is
+executed, it will be passed an array containing these two integers -
+the first corresponding to the 'oid' 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, "update_digital_out oid=7 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 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 enumerations
+----------------------
+
+Enumerations allow the host code to use string identifiers for
+parameters that the micro-controller handles as integers. They are
+declared in the micro-controller code - for example:
+
+```
+DECL_ENUMERATION("spi_bus", "spi", 0);
+
+DECL_ENUMERATION_RANGE("pin", "PC0", 16, 8);
+```
+
+If the first example, the DECL_ENUMERATION() macro defines an
+enumeration for any command/response message with a parameter name of
+"spi_bus" or parameter name with a suffix of "_spi_bus". For those
+parameters the string "spi" is a valid value and it will be
+transmitted with an integer value of zero.
+
+It's also possible to declare an enumeration range. In the second
+example, a "pin" parameter (or any parameter with a suffix of "_pin")
+would accept PC0, PC1, PC2, ..., PC7 as valid values. The strings will
+be transmitted with integers 16, 17, 18, ..., 23.
+
+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. It is also possible to declare
+a constant that is a string - for example:
+
+```
+DECL_CONSTANT_STR("MCU", "pru");
+```
+
+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:
+
+```
+update_digital_out oid=6 value=1
+update_digital_out oid=5 value=0
+get_config
+get_clock
+```
+
+and encoded into the following eight VLQ integers:
+
+```
+<id_update_digital_out><6><1><id_update_digital_out><5><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_update_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,
+"update_digital_out oid=%c 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, enumerations (as
+defined by DECL_ENUMERATION), and constants (as defined by
+DECL_CONSTANT).
+
+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.

docs/README.md

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

docs/Releases.md

@@ -0,0 +1,184 @@
+History of Klipper releases. Please see
+[installation](Installation.md) for information on installing Klipper.
+
+Klipper 0.8.0
+=============
+
+Available on 20191021. Major changes in this release:
+* New G-Code command template support. G-Code in the config file is
+  now evaluated with the Jinja2 template language.
+* Improvements to Trinamic stepper drivers:
+  * New support for TMC2209 and TMC5160 drivers.
+  * Improved DUMP_TMC, SET_TMC_CURRENT, and INIT_TMC G-Code commands.
+  * Improved support for TMC UART handling with an analog mux.
+* Improved homing, probing, and bed leveling support:
+  * New manual_probe, bed_screws, screws_tilt_adjust, skew_correction,
+    safe_z_home modules added.
+  * Enhanced multi-sample probing with median, average, and retry
+    logic.
+  * Improved documentation for BL-Touch, probe calibration, endstop
+    calibration, delta calibration, sensorless homing, and endstop
+    phase calibration.
+  * Improved homing support on a large Z axis.
+* Many Klipper micro-controller improvements:
+  * Klipper ported to: SAM3X8C, SAM4S8C, SAMD51, STM32F042, STM32F4
+  * New USB CDC driver implementations on SAM3X, SAM4, STM32F4.
+  * Enhanced support for flashing Klipper over USB.
+  * Software SPI support.
+  * Greatly improved temperature filtering on the LPC176x.
+  * Early output pin settings can be configured in the
+    micro-controller.
+* New website with the Klipper documentation: http://klipper3d.org/
+  * Klipper now has a logo.
+* Experimental support for polar and "cable winch" kinematics.
+* The config file can now include other config files.
+* Many additional modules added: board_pins, controller_fan,
+  delayed_gcode, dotstar, filament_switch_sensor, firmware_retraction,
+  gcode_arcs, gcode_button, heater_generic, manual_stepper, mcp4018,
+  mcp4728, neopixel, pause_resume, respond, temperature_sensor
+  tsl1401cl_filament_width_sensor, tuning_tower
+* Many additional commands added: RESTORE_GCODE_STATE,
+  SAVE_GCODE_STATE, SET_GCODE_VARIABLE, SET_HEATER_TEMPERATURE,
+  SET_IDLE_TIMEOUT, SET_TEMPERATURE_FAN_TARGET
+* Several bug fixes and code cleanups.
+
+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