Initial commit of source code.

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

.gitignore

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

.travis.yml

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

COPYING

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

Makefile

@@ -1,8 +1,8 @@
-# Klipper build system
+# XXX build system
 #
-# Copyright (C) 2016-2019  Kevin O'Connor <kevin@koconnor.net>
+# Copyright (C) 2014  Kevin O'Connor <kevin@koconnor.net>
 #
-# This file may be distributed under the terms of the GNU GPLv3 license.
+# This file may be distributed under the terms of the GNU LGPLv3 license.
 
 # Output directory
 OUT=out/
@@ -15,6 +15,9 @@ 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
@@ -22,31 +25,32 @@ OBJCOPY=$(CROSS_PREFIX)objcopy
 OBJDUMP=$(CROSS_PREFIX)objdump
 STRIP=$(CROSS_PREFIX)strip
 CPP=cpp
-PYTHON=python2
+PYTHON=python
 
 # Source files
-src-y =
+src-y=sched.c command.c
-dirs-y = src
+src-$(CONFIG_MACH_AVR) += avr/main.c avr/timer.c
+src-$(CONFIG_MACH_SIMU) += simulator/main.c
+src-$(CONFIG_AVR_WATCHDOG) += avr/watchdog.c
+src-$(CONFIG_AVR_SERIAL) += avr/serial.c
+DIRS=src src/avr src/simulator
 
 # Default compiler flags
 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 := -I$(OUT) -Isrc -I$(OUT)board-generic/ -std=gnu11 -O2 -MD -g \
+CFLAGS-y := -I$(OUT) -Isrc -Os -MD -g \
     -Wall -Wold-style-definition $(call cc-option,$(CC),-Wtype-limits,) \
     -ffunction-sections -fdata-sections
-CFLAGS += -flto -fwhole-program -fno-use-linker-plugin
+CFLAGS-y += -flto -fwhole-program
+CFLAGS-$(CONFIG_MACH_AVR) += -mmcu=$(CONFIG_AVR_MCU) -DF_CPU=$(CONFIG_AVR_FREQ)
+CFLAGS := $(CFLAGS-y)
 
-OBJS_klipper.elf = $(patsubst %.c, $(OUT)src/%.o,$(src-y))
+LDFLAGS-$(CONFIG_MACH_AVR) := -Wl,--gc-sections -Wl,--relax
-OBJS_klipper.elf += $(OUT)compile_time_request.o
+LDFLAGS-$(CONFIG_MACH_AVR) += -Wl,-u,vfprintf -lprintf_min -lm
-CFLAGS_klipper.elf = $(CFLAGS) -Wl,--gc-sections
+LDFLAGS := $(LDFLAGS-y)
 
-CPPFLAGS = -I$(OUT) -P -MD -MT $@
+CPPFLAGS = -P -MD -MT $@
-
-# Default targets
-target-y := $(OUT)klipper.elf
-
-all:
 
 # Run with "make V=1" to see the actual compile commands
 ifdef V
@@ -56,51 +60,42 @@ Q=@
 MAKEFLAGS += --no-print-directory
 endif
 
-# Include board specific makefile
+# Default targets
-include src/Makefile
+target-y := $(OUT)klipper.elf
--include src/$(patsubst "%",%,$(CONFIG_BOARD_DIRECTORY))/Makefile
+
+all: $(target-y)
 
 ################ Common build rules
 
-$(OUT)%.o: %.c $(OUT)autoconf.h $(OUT)board-link
+$(OUT)%.o: %.c $(OUT)autoconf.h $(OUT)board
 	@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-link: $(KCONFIG_CONFIG)
+$(OUT)board: $(KCONFIG_CONFIG)
-	@echo "  Creating symbolic link $(OUT)board"
+	@echo "  Creating symbolic link $@"
-	$(Q)mkdir -p $(addprefix $(OUT), $(dirs-y))
+	$(Q)rm -f $@
-	$(Q)touch $@
+	$(Q)ln -sf $(PWD)/src/$(CONFIG_BOARD_DIRECTORY) $@
-	$(Q)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)%.o.ctr: $(OUT)%.o
+$(OUT)declfunc.lds: src/declfunc.lds.S
-	$(Q)$(OBJCOPY) -j '.compile_time_request' -O binary $^ $@
+	@echo "  Precompiling $@"
+	$(Q)$(CPP) $(CPPFLAGS) -D__ASSEMBLY__ $< -o $@
 
-$(OUT)compile_time_request.o: $(patsubst %.c, $(OUT)src/%.o.ctr,$(src-y)) ./scripts/buildcommands.py
+$(OUT)klipper.o: $(patsubst %.c, $(OUT)src/%.o,$(src-y)) $(OUT)declfunc.lds
-	@echo "  Building $@"
-	$(Q)cat $(patsubst %.c, $(OUT)src/%.o.ctr,$(src-y)) | 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) $(OBJS_klipper.elf) $(CFLAGS_klipper.elf) -o $@
+	$(Q)$(CC) $(CFLAGS) -Wl,-r -Wl,-T,$(OUT)declfunc.lds -nostdlib $(patsubst %.c, $(OUT)src/%.o,$(src-y)) -o $@
-	$(Q)scripts/check-gcc.sh $@ $(OUT)compile_time_request.o
+
+$(OUT)klipper.elf: $(OUT)klipper.o
+	@echo "  Linking $@"
+	$(Q)$(CC) $(CFLAGS) $(LDFLAGS) $^ -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
 
@@ -116,12 +111,10 @@ 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 $(OUT)*.d $(patsubst %,$(OUT)%/*.d,$(dirs-y))
+-include $(patsubst %,$(OUT)%/*.d,$(DIRS))

README.md

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

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

config/example-corexy.cfg

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

config/example-delta.cfg

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

config/example-menu.cfg

@@ -1,205 +0,0 @@
-# This file serves as documentation for config parameters. One may
-# copy and edit this file to configure a new menu layout.
-# The snippets in this file may be copied into the main printer.cfg file.
-# See the "example.cfg" file for description of common config parameters.
-
-# Available menu elements:
-#   item - purely visual element
-#   command - same like 'item' but with gcode trigger
-#   input - same like 'command' but has value changing capabilities
-#   list - menu element container, with entry and exit gcode triggers
-#   vsdcard - same as 'list' but will append files from virtual sdcard
-#   deck - special container for custom screens (cards) has entry and exit gcode triggers.
-#   card - special content card for custom screens. Can only be used in 'deck'!
-
-#[menu item1]
-#type: item
-#   Type will determine menu item properties and behaviours:
-#name:
-#   This is mandatory attribute for every menu element.
-#   You can use Python output formatting for parameter and transform values.
-#   Quotes can be used in the beginning and end of name.
-#cursor:
-#   It allows to change cursor character for selected menu element.
-#   The default is >
-#   This parameter is optional.
-#width:
-#   This attribute accepts integer value. Element name is cut to this width.
-#   This parameter is optional.
-#scroll:
-#   This attribute accepts static boolean value. You can use it together with 'width'.
-#   When this is enabled then names longer than width are scrolled back and forth.
-#   The default is disabled. This parameter is optional.
-#enable:
-#   This attribute accepts static boolean values and parameters (converted to boolean).
-#   It accepts multiple logical expressions. Values separated by comma will return True if all elements are true.
-#   Values on different lines will return True if any element is true.
-#   You can use logical negation by using character ! as parameter prefix.
-#parameter:
-#   This attribute accepts float values or special variables. Multiple values are delimited by comma.
-#   All available parameter variables can be listed by 'MENU DO=dump' gcode, menu itself must be running.
-#   This value is available for output formatting as {0}..{n} Where n is count of parameters.
-#transform:
-#   This attribute allows to transform parameters value to something else.
-#   More than one transformation can be added. Each transformation must be on separate line.
-#   These transformed values are available for output formatting as {n+1}..{x}
-#   Where n is count of parameters and x is count of transformations.
-#   In order to transform the value of a particular parameter, you must add
-#   an parameter index as prefix. Like this "transform: 1.choose('OFF','ON')"
-#   If the index is not set then the default index 0 is used.
-#
-#   map(fromLow,fromHigh,toLow,toHigh) - interpolate re-maps a parameter value from one range to another.
-#   Output value type is taken from toHigh. It can be int or float.
-#
-#   choose(e1,e2) - boolean chooser, converts the value of the parameter to the boolean type (0 and 1),
-#   and selects the corresponding value by the index from the list.
-#
-#   choose(e1,e2,...) - int chooser, converts the value of the parameter to the int type
-#   and selects the corresponding value by the index from the list.
-#
-#   choose({key:value,..}) - special dictionary chooser, parameter value cast type by first key type.
-#   Selects the corresponding value by the key from the dictionary.
-#
-#   int(), float(), bool(), str(), abs(), bin(), hex(), oct(), days(), hours(), minutes(), seconds()
-#   These will convert parameter value to the special form.
-#   int,float,bool,str,abs,bin,hex and oct are python functions.
-#   days,hours,minutes,seconds will convert parameter value (it's taken as seconds) to time specific value
-#
-#   scale(xx) - Multiplies parameter value by this xx. Pure interger or float value is excpected.
-
-
-#[menu command1]
-#type:command
-#name:
-#cursor:
-#width:
-#scroll:
-#enable:
-#parameter:
-#transform:
-#gcode:
-#   When menu element is clicked then gcodes on this attribute will be executed.
-#   Can have multiline gcode script and supports output formatting for parameter and transform values.
-#action:
-#   Special action can be executed. Supports [back, exit] menu commands
-#   and [respond response_info] command. Respond command will send '// response_info' to host.
-
-#[menu input1]
-#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

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

config/example-polar.cfg

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

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

@@ -1,337 +0,0 @@
-# This file serves as documentation for config parameters. One may
-# copy and edit this file to configure a new cartesian style
-# printer. For delta style printers, see the "example-delta.cfg"
-# file. For corexy/h-bot style printers, see the "example-corexy.cfg"
-# file. Only common config sections are described here - see the
-# "example-extras.cfg" file for configuring less common devices.
-
-# DO NOT COPY THIS FILE WITHOUT CAREFULLY READING AND UPDATING IT
-# FIRST. Incorrectly configured parameters may cause damage.
-
-# A note on pin names: pins may be configured with a hardware name
-# (such as "PA4") or with an Arduino alias name (such as "ar29" or
-# "analog3"). In order to use Arduino names, the pin_map variable in
-# the mcu section must be present and have a value of "arduino". Pin
-# names may be preceded by an '!' to indicate that a reverse polarity
-# should be used (eg, trigger on low instead of high). Input pins may
-# be preceded by a '^' to indicate that a hardware pull-up resistor
-# should be enabled for the pin. 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

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

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

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

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

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

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

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

config/generic-duet2-duex.cfg

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

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

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

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

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

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

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

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

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

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

config/generic-mini-rambo.cfg

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

config/generic-minitronics1.cfg

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

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

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

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

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

@@ -1,98 +0,0 @@
-# This file contains common pin mappings for RAMPS (v1.3 and later)
-# boards. RAMPS boards typically use a firmware compiled for the AVR
-# atmega2560 (though other AVR chips are also possible).
-
-# See the example.cfg file for a description of available parameters.
-
-[stepper_x]
-step_pin: ar54
-dir_pin: ar55
-enable_pin: !ar38
-step_distance: .0125
-endstop_pin: ^ar3
-#endstop_pin: ^ar2
-position_endstop: 0
-position_max: 200
-homing_speed: 50
-
-[stepper_y]
-step_pin: ar60
-dir_pin: !ar61
-enable_pin: !ar56
-step_distance: .0125
-endstop_pin: ^ar14
-#endstop_pin: ^ar15
-position_endstop: 0
-position_max: 200
-homing_speed: 50
-
-[stepper_z]
-step_pin: ar46
-dir_pin: ar48
-enable_pin: !ar62
-step_distance: .0025
-endstop_pin: ^ar18
-#endstop_pin: ^ar19
-position_endstop: 0.5
-position_max: 200
-
-[extruder]
-step_pin: ar26
-dir_pin: ar28
-enable_pin: !ar24
-step_distance: .002
-nozzle_diameter: 0.400
-filament_diameter: 1.750
-heater_pin: ar10
-sensor_type: EPCOS 100K B57560G104F
-sensor_pin: analog13
-control: pid
-pid_Kp: 22.2
-pid_Ki: 1.08
-pid_Kd: 114
-min_temp: 0
-max_temp: 250
-
-#[extruder1]
-#step_pin: ar36
-#dir_pin: ar34
-#enable_pin: !ar30
-#heater_pin: ar9
-#sensor_pin: analog15
-#...
-
-[heater_bed]
-heater_pin: ar8
-sensor_type: EPCOS 100K B57560G104F
-sensor_pin: analog14
-control: watermark
-min_temp: 0
-max_temp: 130
-
-[fan]
-pin: ar9
-
-[mcu]
-serial: /dev/ttyACM0
-pin_map: arduino
-
-[printer]
-kinematics: cartesian
-max_velocity: 300
-max_accel: 3000
-max_z_velocity: 5
-max_z_accel: 100
-
-# 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

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

@@ -1,136 +0,0 @@
-# This file contains an example configuration for the Replicape rev B3
-# board. To use this config, one must compile and install the
-# micro-controller code for the "Beaglebone PRU", and then compile and
-# install the micro-controller code a second time for a "Linux
-# process".
-
-# NOTE: Klipper does not alter the input/output state of the
-# Beaglebone pins and it does not control their pull-up resistors.
-# Typically the correct settings are automatically applied when the
-# Beaglebone detects the Replicape board, but if changes are needed
-# they must be specified in a "device tree overlay" or via the
-# config-pin program.
-
-# See the example.cfg file for a description of available parameters.
-
-[mcu]
-serial: /dev/rpmsg_pru30
-pin_map: beaglebone
-
-[mcu host]
-serial: /tmp/klipper_host_mcu
-
-# The "replicape" config section adds "replicape:stepper_x_enable"
-# virtual stepper enable pins (for steppers x, y, z, e, and h) and
-# "replicape:power_x" PWM output pins (for hotbed, e, h, fan0, fan1,
-# fan2, and fan3) that may then be used elsewhere in the config file.
-[replicape]
-revision: B3
-#   The replicape hardware revision. Currently only revision "B3" is
-#   supported. This parameter must be provided.
-#enable_pin: !P9_41
-#   The replicape global enable pin. The default is !P9_41.
-host_mcu: host
-#   The name of the mcu config section that communicates with the
-#   Klipper "linux process" mcu instance. This parameter must be
-#   provided.
-#standstill_power_down: False
-#   This parameter controls the CFG6_ENN line on all stepper
-#   motors. True sets the enable lines to "open". The default is
-#   False.
-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

@@ -1,115 +0,0 @@
-# This file contains common pin mappings for RUMBA boards.  To use
-# this config, the firmware should be compiled for the AVR atmega2560.
-
-# See the example.cfg file for a description of available parameters.
-
-[stepper_x]
-step_pin: ar17
-dir_pin: ar16
-enable_pin: !ar48
-step_distance: .0125
-endstop_pin: ^ar37
-#endstop_pin: ^ar36
-position_endstop: 0
-position_max: 200
-homing_speed: 50
-
-[stepper_y]
-step_pin: ar54
-dir_pin: !ar47
-enable_pin: !ar55
-step_distance: .0125
-endstop_pin: ^ar35
-#endstop_pin: ^ar34
-position_endstop: 0
-position_max: 200
-homing_speed: 50
-
-[stepper_z]
-step_pin: ar57
-dir_pin: ar56
-enable_pin: !ar62
-step_distance: .0125
-endstop_pin: ^ar33
-#endstop_pin: ^ar32
-position_endstop: 0.5
-position_max: 200
-
-[extruder]
-step_pin: ar23
-dir_pin: ar22
-enable_pin: !ar24
-step_distance: .002
-nozzle_diameter: 0.400
-filament_diameter: 1.750
-heater_pin: ar2
-sensor_type: EPCOS 100K B57560G104F
-sensor_pin: analog15
-control: pid
-pid_Kp: 22.2
-pid_Ki: 1.08
-pid_Kd: 114
-min_temp: 0
-max_temp: 250
-
-#[extruder1]
-#step_pin: ar26
-#dir_pin: 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

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

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

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

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

config/printer-anet-a8-2017.cfg

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

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

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

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

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

config/printer-anycubic-kossel-2016.cfg

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

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

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

config/printer-creality-cr10-2017.cfg

@@ -1,90 +0,0 @@
-# This file contains common pin mappings for the 2017 Creality
-# CR-10. To use this config, the firmware should be compiled for the
-# AVR atmega1284p.
-
-# Note, a number of Melzi boards are shipped with a bootloader that
-# requires the following command to flash the board:
-#  avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
-# If the above command does not work and "make flash" does not work
-# then one may need to flash a bootloader to the board - see the
-# Klipper docs/Bootloaders.md file for more information.
-
-# See the example.cfg file for a description of available parameters.
-
-[stepper_x]
-step_pin: PD7
-dir_pin: !PC5
-enable_pin: !PD6
-step_distance: .0125
-endstop_pin: ^PC2
-position_endstop: 0
-position_max: 300
-homing_speed: 50
-
-[stepper_y]
-step_pin: PC6
-dir_pin: !PC7
-enable_pin: !PD6
-step_distance: .0125
-endstop_pin: ^PC3
-position_endstop: 0
-position_max: 300
-homing_speed: 50
-
-[stepper_z]
-step_pin: PB3
-dir_pin: PB2
-enable_pin: !PA5
-step_distance: .0025
-endstop_pin: ^PC4
-position_endstop: 0.0
-position_max: 400
-
-[extruder]
-step_pin: PB1
-dir_pin: !PB0
-enable_pin: !PD6
-step_distance: 0.010526
-nozzle_diameter: 0.400
-filament_diameter: 1.750
-heater_pin: PD5
-sensor_type: EPCOS 100K B57560G104F
-sensor_pin: PA7
-control: pid
-pid_Kp: 22.57
-pid_Ki: 1.72
-pid_Kd: 73.96
-min_temp: 0
-max_temp: 250
-
-[heater_bed]
-heater_pin: PD4
-sensor_type: 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

@@ -1,90 +0,0 @@
-# This file contains common pin mappings for the 2017 Creality CR-10
-# mini. To use this config, the firmware should be compiled for the
-# AVR atmega1284p.
-
-# Note, a number of Melzi boards are shipped with a bootloader that
-# requires the following command to flash the board:
-#  avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
-# If the above command does not work and "make flash" does not work
-# then one may need to flash a bootloader to the board - see the
-# Klipper docs/Bootloaders.md file for more information.
-
-# See the example.cfg file for a description of available parameters.
-
-[stepper_x]
-step_pin: PD7
-dir_pin: !PC5
-enable_pin: !PD6
-step_distance: .0125
-endstop_pin: ^PC2
-position_endstop: 0
-position_max: 300
-homing_speed: 50
-
-[stepper_y]
-step_pin: PC6
-dir_pin: !PC7
-enable_pin: !PD6
-step_distance: .0125
-endstop_pin: ^PC3
-position_endstop: 0
-position_max: 220
-homing_speed: 50
-
-[stepper_z]
-step_pin: PB3
-dir_pin: PB2
-enable_pin: !PA5
-step_distance: .0025
-endstop_pin: ^PC4
-position_endstop: 0.0
-position_max: 300
-
-[extruder]
-step_pin: PB1
-dir_pin: !PB0
-enable_pin: !PD6
-step_distance: 0.010526
-nozzle_diameter: 0.400
-filament_diameter: 1.750
-heater_pin: PD5
-sensor_type: EPCOS 100K B57560G104F
-sensor_pin: PA7
-control: pid
-pid_Kp: 22.57
-pid_Ki: 1.72
-pid_Kd: 73.96
-min_temp: 0
-max_temp: 250
-
-[heater_bed]
-heater_pin: PD4
-sensor_type: 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

@@ -1,83 +0,0 @@
-# This file contains pin mappings for the 2017 Creality CR-10S. To use
-# this config, the firmware should be compiled for the AVR atmega2560.
-
-# See the example.cfg file for a description of available parameters.
-
-[stepper_x]
-step_pin: ar54
-dir_pin: ar55
-enable_pin: !ar38
-step_distance: .0125
-endstop_pin: ^ar3
-position_endstop: 0
-position_max: 300
-homing_speed: 50
-
-[stepper_y]
-step_pin: ar60
-dir_pin: ar61
-enable_pin: !ar56
-step_distance: .0125
-endstop_pin: ^ar14
-position_endstop: 0
-position_max: 300
-homing_speed: 50
-
-[stepper_z]
-step_pin: ar46
-dir_pin: !ar48
-enable_pin: !ar62
-step_distance: .0025
-endstop_pin: ^ar18
-position_endstop: 0
-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

@@ -1,81 +0,0 @@
-# This file contains pin mappings for the Creality CR-20. To use
-# this config, the firmware should be compiled for the AVR atmega2560.
-
-# See the example.cfg file for a description of available parameters.
-
-[stepper_x]
-step_pin: PF0
-dir_pin: PF1
-enable_pin: !PD7
-step_distance: .0125
-endstop_pin: ^PE5
-position_endstop: 0
-position_max: 235
-homing_speed: 50
-
-[stepper_y]
-step_pin: PF6
-dir_pin: PF7
-enable_pin: !PF2
-step_distance: .0125
-endstop_pin: ^PJ1
-position_endstop: 0
-position_max: 235
-homing_speed: 50
-
-[stepper_z]
-step_pin: PL3
-dir_pin: !PL1
-enable_pin: !PK0
-step_distance: .0025
-endstop_pin: ^PD3
-position_endstop: 0
-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

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

config/printer-creality-ender3-2018.cfg

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

config/printer-creality-ender5-2019.cfg

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

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

config/printer-makergear-m2-2012.cfg

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

config/printer-micromake-d1-2016.cfg

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

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

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

config/printer-tevo-flash-2018.cfg

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

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

config/printer-tronxy-x8-2018.cfg

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

config/printer-velleman-k8200-2013.cfg

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

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

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

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

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

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

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

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

config/sample-lcd.cfg

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

@@ -1,117 +0,0 @@
-# This file provides examples of Klipper G-Code macros.  The snippets
-# in this file may be copied into the main printer.cfg file 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

@@ -1,51 +0,0 @@
-# This file provides example config file settings for use on a printer
-# that uses a Z probe instead of a traditional Z endstop switch. This
-# file is just a "snippet" of config sections - it must be added to a
-# config file containing the configuration of the rest of the printer.
-
-# Be sure to review and update this config with the appropriate pins
-# and coordinates for your printer.
-
-# See the "example.cfg" and "example-extras.cfg" files for a
-# description of config parameters.
-
-# Define a probe
-[probe]
-pin: ar30
-z_offset: 2.345
-
-# Example settings to add to stepper_z section
-[stepper_z]
-endstop_pin: probe:z_virtual_endstop
-position_min: -2 # The Z carriage may need to travel below the Z=0
-                 # homing point if the bed has a significant tilt.
-
-# The homing_override section modifies the default G28 behavior
-[homing_override]
-set_position_z: 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

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

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

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

@@ -1,440 +0,0 @@
-This document provides information on common bootloaders found on
-micro-controllers that Klipper supports.
-
-The bootloader is 3rd-party software that runs on the micro-controller
-when it is first powered on. It is typically used to flash a new
-application (eg, Klipper) to the micro-controller without requiring
-specialized hardware. Unfortunately, there is no industry wide
-standard for flashing a micro-controller, nor is there a standard
-bootloader that works across all micro-controllers. Worse, it is
-common for each bootloader to require a different set of steps to
-flash an application.
-
-If one can flash a bootloader to a micro-controller then one can
-generally also use that mechanism to flash an application, but care
-should be taken when doing this as one may inadvertently remove the
-bootloader. In contrast, a bootloader will generally only permit a
-user to flash an application. It is therefore recommended to use a
-bootloader to flash an application where possible.
-
-This document attempts to describe common bootloaders, the steps
-needed to flash a bootloader, and the steps needed to flash an
-application.  This document is not an authoritative reference; it is
-intended as a collection of useful information that the Klipper
-developers have accumulated.
-
-AVR micro-controllers
-=====================
-
-In general, the Arduino project is a good reference for bootloaders
-and flashing procedures on the 8-bit Atmel Atmega micro-controllers.
-In particular, the "boards.txt" file:
-[https://github.com/arduino/Arduino/blob/1.8.5/hardware/arduino/avr/boards.txt](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

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

docs/CONTRIBUTING.md

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

docs/Code_Overview.md

@@ -1,463 +0,0 @@
-This document describes the overall code layout and major code flow of
-Klipper.
-
-Directory Layout
-================
-
-The **src/** directory contains the C source for the micro-controller
-code. The **src/avr/**, **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

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

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

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

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

docs/Debugging.md

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

@@ -1,230 +0,0 @@
-This document describes Klipper's automatic calibration system for
-"delta" style printers.
-
-Delta calibration involves finding the tower endstop positions, tower
-angles, delta radius, and delta arm lengths. These settings control
-printer motion on a delta printer. Each one of these parameters has a
-non-obvious and non-linear impact and it is difficult to calibrate
-them manually. In contrast, the software calibration code can provide
-excellent results with just a few minutes of time. No special probing
-hardware is necessary.
-
-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

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

docs/FAQ.md

@@ -1,503 +0,0 @@
-Frequently asked questions
-==========================
-
-1. [How can I donate to the project?](#how-can-i-donate-to-the-project)
-2. [How do I calculate the step_distance parameter in the printer config file?](#how-do-i-calculate-the-step_distance-parameter-in-the-printer-config-file)
-3. [Where's my serial port?](#wheres-my-serial-port)
-4. [When the micro-controller restarts the device changes to /dev/ttyUSB1](#when-the-micro-controller-restarts-the-device-changes-to-devttyusb1)
-5. [The "make flash" command doesn't work](#the-make-flash-command-doesnt-work)
-6. [How do I change the serial baud rate?](#how-do-i-change-the-serial-baud-rate)
-7. [Can I run Klipper on something other than a Raspberry Pi 3?](#can-i-run-klipper-on-something-other-than-a-raspberry-pi-3)
-8. [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

@@ -1,153 +0,0 @@
-Klipper has several compelling features:
-
-* High precision stepper movement. Klipper utilizes an application
-  processor (such as a low-cost Raspberry Pi) when calculating printer
-  movements. The application processor determines when to step each
-  stepper motor, it compresses those events, transmits them to the
-  micro-controller, and then the micro-controller executes each event
-  at the requested time. Each stepper event is scheduled with a
-  precision of 25 micro-seconds or better. The software does not use
-  kinematic estimations (such as the Bresenham algorithm) - instead it
-  calculates precise step times based on the physics of acceleration
-  and the physics of the machine kinematics. More precise stepper
-  movement translates to quieter and more stable printer operation.
-
-* Best in class performance. Klipper is able to achieve high stepping
-  rates on both new and old micro-controllers. Even an old 8bit AVR
-  micro-controller can obtain rates over 175K steps per second. On
-  more recent micro-controllers, rates over 500K steps per second are
-  possible. Higher stepper rates enable higher print velocities. The
-  stepper event timing remains precise even at high speeds which
-  improves overall stability.
-
-* Klipper supports printers with multiple micro-controllers. For
-  example, one micro-controller could be used to control an extruder,
-  while another controls the printer's heaters, while a third controls
-  the rest of the printer. The Klipper host software implements clock
-  synchronization to account for clock drift between
-  micro-controllers. No special code is needed to enable multiple
-  micro-controllers - it just requires a few extra lines in the config
-  file.
-
-* Configuration via simple config file. There's no need to reflash the
-  micro-controller to change a setting. All of Klipper's configuration
-  is stored in a standard config file which can be easily edited. This
-  makes it easier to setup and maintain the hardware.
-
-* Portable code. Klipper works on ARM, AVR, and PRU based
-  micro-controllers. Existing "reprap" style printers can run Klipper
-  without hardware modification - just add a Raspberry Pi. Klipper's
-  internal code layout makes it easier to support other
-  micro-controller architectures as well.
-
-* Simpler code. Klipper uses a very high level language (Python) for
-  most code. The kinematics algorithms, the G-code parsing, the
-  heating and thermistor algorithms, etc. are all written in Python.
-  This makes it easier to develop new functionality.
-
-* Klipper uses an "iterative solver" to calculate precise step times
-  from simple kinematic equations. This makes porting Klipper to new
-  types of robots easier and it keeps timing precise even with complex
-  kinematics (no "line segmentation" is needed).
-
-Additional features
-===================
-
-Klipper supports many standard 3d printer features:
-
-* Klipper implements the "pressure advance" algorithm for extruders.
-  When properly tuned, pressure advance reduces extruder ooze.
-
-* Works with Octoprint. This allows the printer to be controlled using
-  a regular web-browser. The same Raspberry Pi that runs Klipper can
-  also run Octoprint.
-
-* Standard G-Code support. Common g-code commands that are produced by
-  typical "slicers" are supported. One may continue to use Slic3r,
-  Cura, etc. with Klipper.
-
-* Support for multiple extruders. Extruders with shared heaters and
-  extruders on independent carriages (IDEX) are also supported.
-
-* Support for cartesian, delta, and corexy style printers.
-
-* Automatic bed leveling support. Klipper can be configured for basic
-  bed tilt detection or full mesh bed leveling. If the bed uses
-  multiple Z steppers then Klipper can also level by independently
-  manipulating the Z steppers. Most Z height probes are supported,
-  including servo activated probes.
-
-* Automatic delta calibration support. The calibration tool can
-  perform basic height calibration as well as an enhanced X and Y
-  dimension calibration. The calibration can be done with a Z height
-  probe or via manual probing.
-
-* Support for common temperature sensors (eg, common thermistors,
-  AD595, 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

@@ -1,532 +0,0 @@
-This document describes the commands that Klipper supports. These are
-commands that one may enter into the OctoPrint terminal tab.
-
-# G-Code commands
-
-Klipper supports the following standard G-Code commands:
-- Move (G0 or G1): `G1 [X<pos>] [Y<pos>] [Z<pos>] [E<pos>] [F<speed>]`
-- Dwell: `G4 P<milliseconds>`
-- Move to origin: `G28 [X] [Y] [Z]`
-- Turn off motors: `M18` or `M84`
-- Wait for current moves to finish: `M400`
-- Select tool: `T<index>`
-- Use absolute/relative distances for extrusion: `M82`, `M83`
-- Use absolute/relative coordinates: `G90`, `G91`
-- Set position: `G92 [X<pos>] [Y<pos>] [Z<pos>] [E<pos>]`
-- Set speed factor override percentage: `M220 S<percent>`
-- Set extrude factor override percentage: `M221 S<percent>`
-- Set acceleration: `M204 S<value>`
-- Get extruder temperature: `M105`
-- Set extruder temperature: `M104 [T<index>] [S<temperature>]`
-- Set extruder temperature and wait: `M109 [T<index>] S<temperature>`
-  - Note: M109 always waits for temperature to settle at requested
-    value
-- Set bed temperature: `M140 [S<temperature>]`
-- Set bed temperature and wait: `M190 S<temperature>`
-  - Note: M190 always waits for temperature to settle at requested
-    value
-- Set fan speed: `M106 S<value>`
-- Turn fan off: `M107`
-- Emergency stop: `M112`
-- Get current position: `M114`
-- Get firmware version: `M115`
-
-For further details on the above commands see the
-[RepRap G-Code documentation](http://reprap.org/wiki/G-code).
-
-Klipper's goal is to support the G-Code commands produced by common
-3rd party software (eg, OctoPrint, Printrun, Slic3r, Cura, etc.) in
-their standard configurations. It is not a goal to support every
-possible G-Code command. Instead, Klipper prefers human readable
-["extended G-Code commands"](#extended-g-code-commands).
-
-If one requires a less common G-Code command then it may be possible
-to implement it with a custom Klipper gcode_macro (see
-[example-extras.cfg](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

@@ -1,193 +0,0 @@
-These instructions assume the software will run on a Raspberry Pi
-computer in conjunction with OctoPrint. It is recommended that a
-Raspberry Pi 2 or Raspberry Pi 3 computer be used as the host machine
-(see the
-[FAQ](FAQ.md#can-i-run-klipper-on-something-other-than-a-raspberry-pi-3)
-for other machines).
-
-Klipper currently supports 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

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

docs/MCU_Commands.md

@@ -1,302 +0,0 @@
-This document provides information on the low-level micro-controller
-commands that are sent from the Klipper "host" software and processed
-by the Klipper micro-controller software. This document is not an
-authoritative reference for these commands, nor is it an exclusive
-list of all available commands.
-
-This document may be useful for developers interested in understanding
-the low-level micro-controller commands.
-
-See the [protocol](Protocol.md) document for more information on the
-format of commands and their transmission. The commands here are
-described using their "printf" style syntax - for those unfamiliar
-with that format, just note that where a '%...' sequence is seen it
-should be replaced with an actual integer. For example, a description
-with "count=%c" could be replaced with the text "count=10". 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

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

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

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

docs/Pressure_Advance.md

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

docs/Probe_Calibrate.md

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

@@ -1,358 +0,0 @@
-The Klipper messaging protocol is used for low-level communication
-between the Klipper host software and the Klipper micro-controller
-software. At a high level the protocol can be thought of as a series
-of command and response strings that are compressed, transmitted, and
-then processed at the receiving side. An example series of commands in
-uncompressed human-readable format might look like:
-
-```
-set_digital_out pin=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

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

docs/Releases.md

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