New experimental firmware: all kinematics in host

Hi Kevin,
I really like your concept of printer firmware and congratulations on your work.
Do you have plans of porting to Beaglebone Black?
I have a BBB with Replicape that uses Redeem firmware and I would like to use your firmware.
The Replicape and Beaglebone Black I think is a good combination and your firmware I think will improve it even more.

Quote
crow
Hi Kevin,
I really like your concept of printer firmware and congratulations on your work.
Do you have plans of porting to Beaglebone Black?
I have a BBB with Replicape that uses Redeem firmware and I would like to use your firmware.
The Replicape and Beaglebone Black I think is a good combination and your firmware I think will improve it even more.

Thanks! I would like to see Klipper ported to the Beaglebone. The PRU has a lot of differences between it and a more standard micro-controller; that means it will take some work to port to it. If no one beats me to it I may tackle it, but that's not something likely in the next several weeks.

Quote
crow
Do you have plans of implementing a autocal least squares probing routine for Delta printers?

That would be a good feature to have. It should just take some python code in the host part of Klipper. (Which is nice, because we can then use standard least squares library implementations.) I don't have an immediate time frame to add the feature though.

If you (or anyone else) is willing to run tests, send me a PM or email. It will help a lot to have testers with different types of hardware. A lot of hardware is straight forward to add support for, so even if Klipper doesn't currently support it, it often isn't difficult to add. (The BBB PRU is a bit of an exception.)

-Kevin

Hi Kevin

Great work in developing this firmware.

I had a couple of queries

- would it possible to adapt it to work with Astroprint instead of Octoprint
- would the Python portion be able to run on Micropython (am thinking of porting it to an ESP8266.

Quote
Keemanaan
Hi Kevin

Great work in developing this firmware.

I had a couple of queries

- would it possible to adapt it to work with Astroprint instead of Octoprint
- would the Python portion be able to run on Micropython (am thinking of porting it to an ESP8266.

Thanks!

There isn't anything specific to Octoprint in Klipper. I haven't tried Astroprint, so I'm not sure about that one specifically.

I think one could port the micro-controller code to the ESP8266 without too much difficulty. (The Klipper micro-controller code only needs a handful of architecture specific functions to run on a new device.)

I'm unsure about Micropython, but I doubt it would work well running on an ESP8266. The host code is intended to run on a general purpose application processor. Even the low-cost Raspberry Pi has multiple orders of magnitude more processing power and memory than AVR, ARM Cortex-M, ESP, etc chips.

-Kevin

This is an announcement for the Klipper v0.4.0 release. Highlights of this release:
* 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)
* Improved installation on Raspberry Pi machines. Most of the install is now scripted.
* Support for automatic micro-controller resets. Also supports resets via toggling USB power on Raspberry Pi.
* The pressure advance algorithm now works with look-ahead to reduce pressure changes during cornering. (See Kinematics for more info.)
* Support for limiting the top speed of short zigzag moves. (See Kinematics for more info.)
* Support for AD595 temperature sensors
* Several bug fixes and code cleanups

At this point, I view Klipper as in a "beta" stage and no longer in an "experimental" stage. Additional users and developers are welcome!

For further information on Klipper's features see:
https://github.com/KevinOConnor/klipper/blob/master/docs/Features.md
To get started with Klipper see:
https://github.com/KevinOConnor/klipper/blob/master/docs/Installation.md
The Klipper source code is available on github:
https://github.com/KevinOConnor/klipper

Hi Kevin
I am also impressed with your work. I have always thought that preprocessing moves before sending to firmware was a sensible option. Are you planing to support options like grid bed leveling which Marlin has been incorporating

Quote
pjk22
Hi Kevin
I am also impressed with your work. I have always thought that preprocessing moves before sending to firmware was a sensible option. Are you planing to support options like grid bed leveling which Marlin has been incorporating

Thanks!

I would like to see automatic bed leveling included in Klipper. However, I don't have any immediate plans to work on it. Contributions are welcome!

-Kevin

Hi Kevin,
I feel a bit stupid... I wanted to try to add some stuff for auto levelling, but failed so early. I compiled the AVR version and tried to connect to it:

eggert@egnb:~/git/klipper$ klippy-env/bin/python ./klippy/console.py /dev/ttyUSB0 250000
INFO:roottarting serial connect
DEBUG:roottarting stk500v2 leave programmer sequence
DEBUG:root:Got '\x1b\x01\x00\x02\x0e\x11\x00\x07' from stk500v2
WARNING:root:Timeout on serial connect
DEBUG:roottarting stk500v2 leave programmer sequence
DEBUG:root:Got '\x1b\x01\x00\x02\x0e\x11\x00\x07' from stk500v2
WARNING:root:Timeout on serial connect

Seems I miss something quite basic, I think. This is a mega 2560 and I tried a 328p before. Flashing went fine:

eggert@egnb:~/git/klipper$ make flash FLASH_DEVICE=/dev/ttyUSB0 
  Flashing /dev/ttyUSB0 via avrdude

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9801 (probably m2560)
avrdude: reading input file "out/klipper.elf.hex"
avrdude: writing flash (14484 bytes):

Writing | ################################################## | 100% 2.26s

avrdude: 14484 bytes of flash written
avrdude: verifying flash memory against out/klipper.elf.hex:
avrdude: load data flash data from input file out/klipper.elf.hex:
avrdude: input file out/klipper.elf.hex contains 14484 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.75s

avrdude: verifying ...
avrdude: 14484 bytes of flash verified

avrdude: safemode: Fuses OK (E:FD, H8, L:FF)

avrdude done.  Thank you.

Any hints?

Greetings

Thorsten

Hello everybody. I like the idea of the firmware and I am willing to help out how ever I can.
I have a modified Tevo Tarantula (prusa style Cartesian printer) with MKS Base v1.4 (RAMPS 1.3 compatible mb), two E3D v6 (clone) hot ends, two bowden extruders, LJ18A3-8-Z/BX NPN NO inductive proximity sensor. The whole thing is controlled from Raspberry Pi 2, with the official (crappy) touch screen, running Octoprint, TouchUI and Klipper.

I already promised to Kevin in github that I would test the dual extruder branch, but I hit some non firmware related issues, that should now be solved. (Had broken wiring in X limit switch, broke Y limit switch, bad voltage divider circuitry in my inductive sensor, my inductive sensor did not pick up my table etc.)

I did not see any options for second hot end and extruder in Octoprint, maybe I messed up compiling of the firmware? I did change the branch to "work-multiextrude-20170429" and did "git fetch" before compiling, but I am not so familiar with git, especially on different branches, so maybe I missed a step?

I am quite busy for couple of next days, but I am back at my "workshop" on Tuesday. In couple of weeks my summer vacations starts and I am enable to commit more time to this project. I am also very interested with the automatic bed levelling and might just take a try implementing it, but don't take this as promise, yet. I have some skills in coding, but I am not that familiar with python. I definitely can promise to be a beta tester, as this firmware seems to be just the thing I have been looking for. A faster, better way to utilize my Raspberry with the 7" touchscreen to control the printer.

@eggert
I see your printer is connected to ttyUSB0, have you modified your "serial: /dev/ttyACM0" to "serial: /dev/ttyUSB0" in your printer.cfg to reflect that?

Edited 3 time(s). Last edit at 05/27/2017 03:50PM by mdm63.

Quote
eggert
Hi Kevin,
I feel a bit stupid... I wanted to try to add some stuff for auto levelling, but failed so early. I compiled the AVR version and tried to connect to it:

eggert@egnb:~/git/klipper$ klippy-env/bin/python ./klippy/console.py /dev/ttyUSB0 250000
INFO:roottarting serial connect
DEBUG:roottarting stk500v2 leave programmer sequence
DEBUG:root:Got '\x1b\x01\x00\x02\x0e\x11\x00\x07' from stk500v2
WARNING:root:Timeout on serial connect
DEBUG:roottarting stk500v2 leave programmer sequence
DEBUG:root:Got '\x1b\x01\x00\x02\x0e\x11\x00\x07' from stk500v2
WARNING:root:Timeout on serial connect

It looks like you have the correct format for the console.py debugging tool. Some questions - what version of the software are you using (git describe --tags --long --dirty), have you had success connecting using the regular klippy.py software (as described in docs/Installation.md), and what does your .config file look like?

Feel free to email me directly with the debugging info: kevin@koconnor.net

-Kevin

Quote
mdm63
I did not see any options for second hot end and extruder in Octoprint, maybe I messed up compiling of the firmware? I did change the branch to "work-multiextrude-20170429" and did "git fetch" before compiling, but I am not so familiar with git, especially on different branches, so maybe I missed a step?

I don't think you need to configure anything specific in Octoprint for dual extruders. The config is mostly in the slicer and in the Klipper printer.cfg file. It is not necessary to recompile or flash the microcontroller code for dual extrusion - the Klipper multi-extruder code is implemented entirely in the host code. If something isn't working well, please post the Klipper /tmp/klippy.log file (either here, on github, or you can email it to me).

Thanks,
-Kevin

Quote
mdm63
@eggert
I see your printer is connected to ttyUSB0, have you modified your "serial: /dev/ttyACM0" to "serial: /dev/ttyUSB0" in your printer.cfg to reflect that?

Good point, I did not. But now I did and it made no difference.

Quote
KevinOConnor
It looks like you have the correct format for the console.py debugging tool. Some questions - what version of the software are you using (git describe --tags --long --dirty), have you had success connecting using the regular klippy.py software (as described in docs/Installation.md), and what does your .config file look like?

eggert@egnb:~/git/klipper$ git describe --tags --long --dirty
v0.4.0-25-gf91a49c
eggert@egnb:~/git/klipper$ cat .config
#
# Automatically generated file; DO NOT EDIT.
# Klipper Firmware Configuration
#
CONFIG_MACH_AVR=y
# CONFIG_MACH_SAM3X8E is not set
# CONFIG_MACH_PRU is not set
# CONFIG_MACH_SIMU is not set
CONFIG_AVR_SELECT=y
CONFIG_BOARD_DIRECTORY="avr"
# CONFIG_MACH_atmega168 is not set
# CONFIG_MACH_atmega644p is not set
# CONFIG_MACH_at90usb1286 is not set
# CONFIG_MACH_atmega1280 is not set
CONFIG_MACH_atmega2560=y
CONFIG_MCU="atmega2560"
CONFIG_AVR_FREQ_8000000=y
# CONFIG_AVR_FREQ_16000000 is not set
# CONFIG_AVR_FREQ_20000000 is not set
CONFIG_CLOCK_FREQ=8000000
CONFIG_CLEAR_PRESCALER=y
CONFIG_AVR_CLKPR=0
CONFIG_AVR_STACK_SIZE=256
CONFIG_AVR_WATCHDOG=y
CONFIG_AVR_SERIAL=y
CONFIG_SERIAL_BAUD=250000
CONFIG_SERIAL_BAUD_U2X=y
CONFIG_HAVE_GPIO_ADC=y
CONFIG_HAVE_GPIO_SPI=y
CONFIG_HAVE_GPIO_HARD_PWM=y
CONFIG_NO_UNSTEP_DELAY=y
CONFIG_INLINE_STEPPER_HACK=y
eggert@egnb:~/git/klipper$

I did not try the regular klippy.py, I'll try tomorrow.


Thorsten

Quote
eggert
...

CONFIG_MCU="atmega2560"
CONFIG_AVR_FREQ_8000000=y

...

You almost certainly want a clock frequency of 16Mhz (instead of 8Mhz). On AVR, the serial baud rate is tied to the clock frequency selection, so that likely caused comms to fail. I'll look to see if I can change the Kconfig default for the atmega2560 so that this is less likely to occur in the future.

-Kevin

You are right, the frequency was the problem, thanks a lot.

Thorsten

Hello Kevin,

Before rebuilding my 3D-Printer, I did a small research on firmwares.
Your work seems to fit to my ideas nearly perfect.

(The other compared projects had been: Franklin, Pacemaker and ddprint)

I like to give you my own wishlist and may be you like to add one or more of my ideas.
... so I don't have to implement them by myself


1) Connect the Raspberry Pi and MC by I2C
The I2C slaves only pull down the I2C pins of the Raspberry Pi, so it will be easy to mix 3.3V and 5V logic.
The 5V MC only needs to interpret 3.3V as a HIGH signal, and as much I know the AVR MC will do.
Optional 2 resistors and 3.6V Z-diodes can be used to protect the Raspberry Pi from the 5V MC if it is miss configurated.

2) Then we use two MC. One for the steppers and the other one for thermistors, heaters, fans, ...
The firmware can be the same, only commands and configuration needs to be send to diffrent I2C-slaves.
Like this, the stepper can stay fast and it will be easy to add much more.
e.g. fast and secure temperature control on the second MC.

3) One interrupt pin on the MC should be pulled down by other MC to stop it.
Like this, all MC can act as a watchdog for the other one, even when the Raspberry Pi or I2C fails.
This pin is pulled up by the Raspberry Pi to 3.3V and switched as an input on all MC.
On an Error or after a timeout this pin is switched to output and pulled down by the MC or Raspberry Pi.
All other boards will detect it and the steppers are disabled, heaters are switched off, ...
The config should have a "default value" for each pin, when the system fails, it is set.

4) One pin should be pulled up to 3.3V by the Raspberry Pi and pulled down by the MC as long the MC is Busy.
And as long this pin is pulled down by the Raspberry Pi the MC should not continue.
Like this the Raspberry Pi can wait until all jobs on the MC are done, then the Raspberry Pi will pull down this pin,
feed the MC with new jobs via I2C and on the rising edge of this pin, all MC will start working nearly synchronous.
With a common clock signal it may be real synchronous, but I don't know any cheap hardware for this.

5) Why building a dual or triple core 3d Printer when you can have a quadro core?
May be an extra MC can execute all the poorly developt custom commands.
Or it can be used to get the real position of the print-head.

6) Between printing two layers, the Status information can be send to an I2C display.
It should be easy, when we allready use I2C.

7) At last, please don't mix Python and C/C++ code.
When you need to compile parts of the software from C/C++, then you can compile everything.
Your Project is too advanced to use a scripting language.
A Python fanboy will be able to use an executable like a PHP fanboy, like a Java fanboy and the RAW C/C++ coders will be happy, too.
To use Python limits your amount of fanboys to the Linux community.
You get hardcore fans, but not so many!


I hope i have inspired you to support a multi core system via I2C in the future, instead of just another trivial dual core system

Marko

Hello Marko,

I'm the main developer of Pacemaker. The I2C Protocol is already specified in Pacemaker. The Idea of having more than 2 systems (Host- RaspberryPi and Client-AVR or whatever) and splitting the work between several client is also already part of the Pacemaker Idea.

If you want to use Klipper that is fine with me. I also use Kevins firmware on one of my printers. But I would be interested in your reasons for not going with Pacemaker. Maybe that can help me make Pacemaker even better.

From what I know neither Klipper nor Pacemaker will be feature complete for what you are planning. So expect to implement some of the features.

For the programming language discussion: Python can also be used on M$ Windows and on MacOs. I agree with your Idea of using a real programming language instead of scripting language, but even the RaspberyPi has enough performance so that this does not cause issues. And writing code should be easier in scripting languages(they say).

Pacemaker uses Java on the Host (to get the platform independence Windows/Linux/MacOs) and C on the client side.

I invite everybody to join the Pacemaker development. I'm happy for all the help I can an get.

Quote
JustAnotherOne
I invite everybody to join the Pacemaker development. I'm happy for all the help I can an get.

I'm curious... it's a concept I have been wanting to try for a couple of years. For people who, like me, have never heard of Pacemaker, here's some links:

Host
Client
Minnow seems defunct? (last updated 2014)

But where can I find discussion about Pacemaker? Is there a mailing list/website/forum/FB page/whatever to see how it works, what it's capable of, follow progress, and contribute ideas without first having to read 10,000 lines of code?

For example

• Can I install the client on my Delta (Arduino Mega2560, I think), install the host on my Pi3, and start printing stuff?
• Does it print better or faster than my existing Repetier firmware?
• Does it do fancy stuff like heated bed temperature control, bed detection, bed levelling, LCD display, multiple extruders?

Hello AnotherOne

We don't need a Python vs Java vs C/C++ discussion,
or a Pacemaker vs Klipper discussion.

Only the KISS-Principle.

"Keep it simple stupid", as more simple a software is, as more likely it will be reused by other.

For the MC we need C as the programming language.
So the KISS-Principle do not allow anything else then C/C++ for the host software.

But there is no pure C/C++ software for the host, so Python may be the next best choice
because it seems to be pre installed on all linux distributions.

Only the usage of Python and the DECL_CTR is something i don't like in Klippy, but there is always something to complain about.





Pacemaker is written in Java, so the main target should be an android app.

- Create an android app with the Pacemaker code inside.
- Choose a name you can't google yet, like "pmngv2" "Pacemaker next generation v2"
- Support old versions of android, because no one will use his current mobile phone for a 6 hour print.
- Create a simple GUI to select the G-code file, or just copy the Marlin GUI
- Rewrite the Peacemaker-client code for Ramps 1.4 hardware and offer precompiled files.
With USB-OTG you can connect Ramps 1.4 directly with the mobile phone.
- Ramps 1.4 should be able to forward commands to the next MC via I2C.
And the android app should have an empty function called from main-loop for custom commands.

Like this Pacemaker can be something like (OctoPrint + Klippy) or (AstroPrint + Klippy).
You can't be as professional as AstroPrint, but you can focus on the DIY community.

You will still break the KISS-Principle by mixing C and Java, but it will be easy to step in.
The end user only has to install the app, reflash Ramps 1.4 and can use Pacemaker.

Then the co-developer will connect his custom MC via I2C and add his custom commands in the empty function of the java code.
The co-developer don't need to understand your code, if he only wants to add some extra mosfet.

The co-developer must learn how to compile android apps, but he will be able to distribute forks of the Pacemaker code very easy and it all goes a kind of viral.
The end user only has to install a secound app, connect the co-developers MC to the ramps 1.4 board and can start using it.
If he don't like it, he unplug the co-developers MC and reuse the original Pacemaker app. No reflash will be needed.

Marko

@frankvdh there is some documentation

For discussion we can have that here (probably better in a new Thread) or in github Issues or you can private mail me.

What Pacemaker needs right now is developers.(See "not yet" below) So a bit of reading the code can not be avoided.

Quote
frankvdh
Can I install the client on my Delta (Arduino Mega2560, I think), install the host on my Pi3, and start printing stuff?

Delta printers are not supported yet. But the host can run on a Pi3 just fine. Minnow and pmc can both run on a Atmega2560.

Quote
frankvdh
Does it print better or faster than my existing Repetier firmware?

I did not do comparisons like this. Right now the movement planning (on the host) is also not yet optimized for speed.

Quote
frankvdh
Does it do fancy stuff like heated bed temperature control, bed detection, bed levelling, LCD display, multiple extruders?

Quote
frankvdh
heated bed temperature control,

yes

Quote
frankvdh
bed detection,

What should that be ?

Quote
frankvdh
bed levelling,

not yet.

Quote
frankvdh
LCD display,

As with klipper/klippy having a display on the client does not make much sense. But you can attach a LCD (HDMI) to the RaspberryPi. That will then be much fancier than those displays usually connected to an Arduino2560,...

Quote
frankvdh
multiple extruders?

not yet implemented, but would be a host only extension.



@markodorsch I don't understand your reasoning behind this:

Quote
markodorsch
So the KISS-Principle do not allow anything else then C/C++ for the host software.

I would think that compiling source code only once and then having a binary that runs on all hosts is easier than needing different compilers for each host and needing to compile for each host is more complicated. Can you explain?

Quote
markodorsch
But there is no pure C/C++ software for the host, so Python may be the next best choice

Java can be compiled to pure C++ by gcj. gcj is part of the Gnu Compiler Collection(gcc). You can think of Java a as a subset of C++.

Quote
markodorsch
Only the usage of Python and the DECL_CTR is something i don't like in Klippy, but there is always something to complain about.

I don't like the complete lack of Error handling in Klippy/Klipper and doing stuff like PID on the host. But you are right, "there is always something to complain about."


I again don't get the reason for this statement:

Quote
markodorsch
Pacemaker is written in Java, so the main target should be an android app.

If someone wants to reuse their old phone or tablet in a printer then they can do what you suggest. But that is not my plan. Again Developers and pull-request are welcome.

Pacemaker also does not want to replace Octoprint. The pacemaker host, as Klipper, accepts G-Code.

In a December 2014 survey, readers of Linux Journal voted for the best programming language.

30.2% for Python
17.8% for C++
16.7% for C (=> 34.5% for C/C++)
7.1% for Perl
6.9% for Java

But may be 95% of all Android developers will vote for Java.

You target the wrong mashine or only 6.9% of the linux developers.

New Pacemaker thread started here.

Quote
mdm63
I did not see any options for second hot end and extruder in Octoprint

Configuring Octoprint for multiple extruders is possible, not required, but I would recommend it. The main advantage is being able to montor the temperature's of your different extruders - Octoprint will then parse the dual temperature readings from Klipper.
You also will be able to control both extruders independently from the "Control" page.

To configure Octoprint for multiple extruders:
1) Settings -> Printer Profiles

2) Under the "Action" label you will see a pencil icon you can click to edit the profile, or you can add a new profile.

3) Go to the last tab "Hotend and Extruder" and change the number of extruders.

Cheers,

Julz.

I've been having issues with the end stops. Same problem as previously posted, however, I've tried everything, endstop_pin: ^!ar2 they just show open all the time, I can not get their status to change. I've checked the switchs with a multi meter, they work just fine. There is continuity when not toggled, and no continuity when toggled.

I've changed the config, power cycled, reset, even reflashed the mega, also tried a new mega, still Recv: x: open y: open z: open

Ramps 1.4 with a Mega, corexy default config.

Edited 1 time(s). Last edit at 06/07/2017 09:43AM by kdodman.

Have you run QUERY_ENDSTOPS while manually toggling the switches? Any change?

If you connect a multimeter directly to pin ar2 on the board, (as close to the MCU as you can get) then manually toggle the endstop switch, do you see a change in voltage on the pin?

Note: If you are using an atMega2560 then Arduino Pin 2 === Physical Pin 6

Thanks for the tips Swift, no luck tho, running query_endstops while manually toggling shows no change, tho I do see a 0.003 V reading when manually toggled, a 0.0v reading when not toggled. That is with the configuration at ^!ar2

No worries, you are on the right track. Those results would imply you need to check the wiring - you should be seeing +5v

As you are using ^!ar2, then you want to be seeing 5v on the pin normally, and 0v when the switch is depressed. (for Normally Open switches)

At a guess, when you are seeing 0.003v, this would likely be Floating, i.e not connected to either Vcc or ground, thus picking up environmental EMR.

--

P.S The "^" means to enable the internal pullup resistor in the atMega, connecting it to +5v internally - so with nothing connected to the pin, other than a multimeter, you should be seeing 5v on that pin....

The following link may be useful:
[www.baldengineer.com]

I dont think its a wiring issue, as it worked previously on marlin. I've also tripple checked everything.

I just measured the voltage on pin 3, which should be X max (not configured for anything in printer.cfg), and that reads 5v, but if I switch my endstop_pin to ^!ar3 it drops that voltage down to 0.003. Really seams to be a configuration issue, I've got something wrong in the config, or the firmware on the mega is not configuring the pins properly.

Quote
kdodman
I dont think its a wiring issue, as it worked previously on marlin. I've also tripple checked everything.

I just measured the voltage on pin 3, which should be X max (not configured for anything in printer.cfg), and that reads 5v, but if I switch my endstop_pin to ^!ar3 it drops that voltage down to 0.003. Really seams to be a configuration issue, I've got something wrong in the config, or the firmware on the mega is not configuring the pins properly.

Please attach the /tmp/klippy.log file and I'll take a look.

-Kevin

I just flashed to the latest marlin and end stops are working, other stuff isnt at the moment tho lol

==== Config file =====
[stepper_x]
step_pin = ar54
dir_pin = ar55
enable_pin = !ar38
step_distance = .01
endstop_pin = ^!ar2
homing_speed = 50.0
position_min = 0
position_endstop = 0
position_max = 200

[stepper_y]
step_pin = ar60
dir_pin = ar61
enable_pin = !ar56
step_distance = .01
endstop_pin = ^!ar16
homing_speed = 50.0
position_min = 0
position_endstop = 0
position_max = 200

[stepper_z]
step_pin = ar46
dir_pin = ar48
enable_pin = !ar62
step_distance = .01
endstop_pin = ^!ar19
position_min = 0.1
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 = watermarksensor_pin = analog14
control = watermark
min_temp = 0
max_temp = 130

[mcu]
serial = /dev/ttyACM0
pin_map = arduino
custom =

[printer]
kinematics = corexy
max_velocity = 300
max_accel = 3000
max_z_velocity = 25
max_z_accel = 30

=======================
Configured (640 moves)
Loaded 51 commands (v0.4.0-32-g3af87e1-20170607_123603-octopi)
MCU config: ADC_MAX=1023 PWM_MAX=255 CLOCK_FREQ=16000000 SOFT_PWM_MAX=256 SERIAL_BAUD=250000 MCU=atmega2$
Args: ['/home/pi/klipper/klippy/klippy.py', '/home/pi/printer.cfg', '-l', '/tmp/klippy.log']
Git version: 'v0.4.0-32-g3af87e1-dirty'
CPU: 4 core ARMv7 Processor rev 4 (v7l)
Python: '2.7.9 (default, Mar  8 2015, 00:52:26) \n[GCC 4.9.2]'
=============== Log rollover at Thu Jun  8 00:10:18 2017 ===============
shutdown: adc out of range
Clock last synchronized at 615.681388 (9850902214)
Dumping send queue 100 messages
Sent 0 15903.071632 15903.071392 6: seq: 1a, get_status
Sent 1 15904.071644 15904.071404 6: seq: 1b, get_status
Sent 2 15905.071694 15905.071454 6: seq: 1c, get_status
Sent 3 15906.071696 15906.071456 6: seq: 1d, get_status
Sent 4 15907.071693 15907.071453 6: seq: 1e, get_status
Sent 5 15908.071726 15908.071486 6: seq: 1f, get_status
Sent 6 15909.071769 15909.071529 6: seq: 10, get_status
Sent 7 15910.071795 15910.071555 6: seq: 11, get_status
Sent 8 15911.071803 15911.071563 6: seq: 12, get_status
Sent 9 15912.071826 15912.071586 6: seq: 13, get_status
Sent 10 15913.071860 15913.071620 6: seq: 14, get_status
Sent 11 15914.071901 15914.071661 6: seq: 15, get_status
Sent 12 15915.071926 15915.071686 6: seq: 16, get_status
Sent 13 15916.071938 15916.071698 6: seq: 17, get_status
Sent 14 15917.071974 15917.071734 6: seq: 18, get_status
Sent 15 15918.072022 15918.071782 6: seq: 19, get_status
Sent 16 15919.072020 15919.071780 6: seq: 1a, get_status
Sent 17 15920.072035 15920.071795 6: seq: 1b, get_status
Sent 18 15921.072053 15921.071813 6: seq: 1c, get_status
Sent 19 15922.072069 15922.071829 6: seq: 1d, get_status
Sent 20 15923.072157 15923.071917 6: seq: 1e, get_status
Sent 21 15924.072147 15924.071907 6: seq: 1f, get_status
Sent 22 15925.072137 15925.071897 6: seq: 10, get_status
Sent 23 15926.072181 15926.071941 6: seq: 11, get_status
Sent 24 15927.072217 15927.071977 6: seq: 12, get_status
Sent 25 15928.072214 15928.071974 6: seq: 13, get_status
Sent 26 15929.072235 15929.071995 6: seq: 14, get_status
Sent 27 15930.072293 15930.072053 6: seq: 15, get_status
Sent 28 15931.072406 15931.072166 6: seq: 16, get_status
Sent 29 15932.072499 15932.072259 6: seq: 17, get_status
Sent 30 15933.072463 15933.072223 6: seq: 18, get_status
Sent 31 15934.072482 15934.072242 6: seq: 19, get_status
Sent 32 15935.072515 15935.072275 6: seq: 1a, get_status
Sent 33 15936.072535 15936.072295 6: seq: 1b, get_status
Sent 34 15937.072550 15937.072310 6: seq: 1c, get_status
Sent 35 15938.072573 15938.072333 6: seq: 1d, get_status
Sent 36 15939.072631 15939.072391 6: seq: 1e, get_status
Sent 37 15940.072628 15940.072388 6: seq: 1f, get_status
Sent 38 15941.072665 15941.072425 6: seq: 10, get_status
Sent 39 15942.072675 15942.072435 6: seq: 11, get_status
Sent 40 15943.072664 15943.072424 6: seq: 12, get_status
Sent 41 15944.072688 15944.072448 6: seq: 13, get_status
Sent 42 15945.072713 15945.072473 6: seq: 14, get_status
Sent 43 15946.072704 15946.072464 6: seq: 15, get_status
Sent 44 15947.072738 15947.072498 6: seq: 16, get_status
Sent 45 15948.072767 15948.072527 6: seq: 17, get_status
Sent 46 15949.072781 15949.072541 6: seq: 18, get_status
Sent 47 15950.072831 15950.072591 6: seq: 19, get_status
Sent 48 15951.072838 15951.072598 6: seq: 1a, get_status
Sent 49 15952.072842 15952.072602 6: seq: 1b, get_status
Sent 50 15953.072875 15953.072635 6: seq: 1c, get_status
Sent 51 15954.072920 15954.072680 6: seq: 1d, get_status
Sent 52 15955.072938 15955.072698 6: seq: 1e, get_status
Sent 53 15956.072961 15956.072721 6: seq: 1f, get_status
Sent 54 15957.072967 15957.072727 6: seq: 10, get_status
Sent 55 15958.072978 15958.072738 6: seq: 11, get_status
Sent 56 15959.072998 15959.072758 6: seq: 12, get_status
Sent 57 15960.073043 15960.072803 6: seq: 13, get_status
Sent 58 15961.073057 15961.072817 6: seq: 14, get_status
Sent 59 15962.073090 15962.072850 6: seq: 15, get_status
Sent 60 15963.073127 15963.072887 6: seq: 16, get_status
Sent 61 15964.073116 15964.072876 6: seq: 17, get_status
Sent 62 15965.073161 15965.072921 6: seq: 18, get_status
Sent 63 15966.073202 15966.072962 6: seq: 19, get_status
Sent 64 15967.073198 15967.072958 6: seq: 1a, get_status
Sent 65 15968.073214 15968.072974 6: seq: 1b, get_status
Sent 66 15969.073248 15969.073008 6: seq: 1c, get_status
Sent 67 15970.073285 15970.073045 6: seq: 1d, get_status
Sent 68 15971.073406 15971.073166 6: seq: 1e, get_status
Sent 69 15972.073525 15972.073285 6: seq: 1f, get_status
Sent 70 15973.073447 15973.073207 6: seq: 10, get_status
Sent 71 15974.073502 15974.073262 6: seq: 11, get_status
Sent 72 15975.073522 15975.073282 6: seq: 12, get_status
Sent 73 15976.073547 15976.073307 6: seq: 13, get_status
Sent 74 15977.073544 15977.073304 6: seq: 14, get_status
Sent 75 15978.073594 15978.073354 6: seq: 15, get_status
Sent 76 15979.073606 15979.073366 6: seq: 16, get_status
Sent 77 15980.073653 15980.073413 6: seq: 17, get_status
Sent 78 15981.073693 15981.073453 6: seq: 18, get_status
Sent 79 15982.073703 15982.073463 6: seq: 19, get_status
Sent 80 15983.073717 15983.073477 6: seq: 1a, get_status
Sent 81 15984.073741 15984.073501 6: seq: 1b, get_status
Sent 82 15985.073754 15985.073514 6: seq: 1c, get_status
Sent 83 15986.073780 15986.073540 6: seq: 1d, get_status
Sent 84 15987.073780 15987.073540 6: seq: 1e, get_status
Sent 85 15988.073794 15988.073554 6: seq: 1f, get_status
Sent 86 15989.073833 15989.073593 6: seq: 10, get_status
Sent 87 15990.073881 15990.073641 6: seq: 11, get_status
Sent 88 15991.073901 15991.073661 6: seq: 12, get_status
Sent 89 15992.073930 15992.073690 6: seq: 13, get_status
Sent 90 15993.073948 15993.073708 6: seq: 14, get_status
Sent 91 15994.073972 15994.073732 6: seq: 15, get_status
Sent 92 15995.074006 15995.073766 6: seq: 16, get_status
Sent 93 15996.074007 15996.073767 6: seq: 17, get_status
Sent 94 15997.074014 15997.073774 6: seq: 18, get_status
Sent 95 15998.074064 15998.073824 6: seq: 19, get_status
Sent 96 15999.074080 15999.073840 6: seq: 1a, get_status
Sent 97 16000.074104 16000.073864 6: seq: 1b, get_status
Sent 98 16001.074142 16001.073902 6: seq: 1c, get_status
Sent 99 16002.074174 16002.073934 6: seq: 1d, get_status
Dumping receive queue 20 messages
Receive: 0 15999.794544 15999.074080 14: seq: 1b, analog_in_state oid=5 next_clock=3315223653 value=7854
Receive: 1 16000.056307 15999.074080 14: seq: 1b, analog_in_state oid=1 next_clock=3319383653 value=7848
Receive: 2 16000.077820 16000.074104 12: seq: 1c, status clock=3315112000 status=0
Receive: 3 16000.094316 16000.074104 14: seq: 1c, analog_in_state oid=5 next_clock=3320023653 value=7854
Receive: 4 16000.355875 16000.074104 14: seq: 1c, analog_in_state oid=1 next_clock=3324183653 value=7848
Receive: 5 16000.392364 16000.074104 14: seq: 1c, analog_in_state oid=5 next_clock=3324823653 value=7854
Receive: 6 16000.655159 16000.074104 14: seq: 1c, analog_in_state oid=1 next_clock=3328983653 value=7848
Receive: 7 16000.695408 16000.074104 14: seq: 1c, analog_in_state oid=5 next_clock=3329623653 value=7853
Receive: 8 16000.954445 16000.074104 14: seq: 1c, analog_in_state oid=1 next_clock=3333783653 value=7848
Receive: 9 16000.994687 16000.074104 14: seq: 1c, analog_in_state oid=5 next_clock=3334423653 value=7853
Receive: 10 16001.077449 16001.074142 12: seq: 1d, status clock=3331099242 status=0
Receive: 11 16001.257744 16001.074142 14: seq: 1d, analog_in_state oid=1 next_clock=3338583653 value=7848
Receive: 12 16001.294234 16001.074142 14: seq: 1d, analog_in_state oid=5 next_clock=3339223653 value=7856
Receive: 13 16001.555768 16001.074142 14: seq: 1d, analog_in_state oid=1 next_clock=3343383653 value=7848
Receive: 14 16001.597500 16001.074142 14: seq: 1d, analog_in_state oid=5 next_clock=3344023653 value=7854
Receive: 15 16001.855316 16001.074142 14: seq: 1d, analog_in_state oid=1 next_clock=3348183653 value=7848
Receive: 16 16001.895560 16001.074142 14: seq: 1d, analog_in_state oid=5 next_clock=3348823653 value=7854
Receive: 17 16002.075816 16002.074174 12: seq: 1e, status clock=3347086972 status=0
Receive: 18 16002.158820 16002.074174 14: seq: 1e, analog_in_state oid=1 next_clock=3352983653 value=7848
Receive: 19 16002.195351 16002.074174 12: seq: 1e, shutdown clock=3348972061 static_string_id=22
Dumping gcode input 50 blocks
Read 15756.522753: 'M105\n'
Read 15761.527636: 'M105\n'
Read 15766.532622: 'M105\n'
Read 15771.537731: 'M105\n'
Read 15776.546130: 'M105\n'
Read 15781.544907: 'M105\n'
Read 15786.545442: 'M105\n'
Read 15791.545950: 'M105\n'
Read 15796.552377: 'M105\n'
ReadRead 15806.565430: 'M105\n'
Read 15811.565837: 'M105\n'
Read 15816.572265: 'M105\n'
Read 15821.578709: 'M105\n'
Read 15826.587860: 'M105\n'
Read 15831.589110: 'M105\n'
Read 15836.594400: 'M105\n'
Read 15841.594838: 'M105\n'
Read 15846.595451: 'M105\n'
Read 15851.595969: 'M105\n'
Read 15856.596539: 'M105\n'
Read 15861.597110: 'M105\n'
Read 15866.597851: 'M105\n'
Read 15871.598273: 'M105\n'
Read 15876.604716: 'M105\n'
Read 15881.611357: 'M105\n'
Read 15886.620350: 'M105\n'
Read 15891.624402: 'M105\n'
Read 15896.631047: 'M105\n'
Read 15901.631510: 'M105\n'
Read 15906.637809: 'M105\n'
Read 15911.644321: 'M105\n'
Read 15916.650968: 'M105\n'
Read 15921.657488: 'M105\n'
Read 15926.664490: 'M105\n'
Read 15931.664911: 'M105\n'
Read 15936.671379: 'M105\n'
Read 15941.677948: 'M105\n'
Read 15946.678492: 'M105\n'
Read 15951.679072: 'M105\n'
Read 15956.679877: 'M105\n'
Read 15961.680310: 'M105\n'
Read 15966.686703: 'M105\n'
Read 15971.693396: 'M105\n'
Read 15976.699956: 'M105\n'
Read 15981.706662: 'M105\n'
Read 15986.713748: 'M105\n'
Read 15991.714125: 'M105\n'
Read 15996.720544: 'M105\n'
Read 16001.726945: 'M105\n'
Got error 0 in read: (0)Success
Timeout with firmware (eventtime=16009.579082 last_status=16006.079073)
Stats 16009.6: gcodein=15807 print_time=0.000 buffer_time=0.000 print_stall=0 bytes_write=95432 bytes_re$
Stats 16010.6: gcodein=15807 print_time=0.000 buffer_time=0.000 print_stall=0 bytes_write=95432 bytes_re$
Stats 16011.6: gcodein=15807 print_time=0.000 buffer_time=0.000 print_stall=0 bytes_write=95432 bytes_re$
Stats 16012.6: gcodein=15812 print_time=0.000 buffer_time=0.000 print_stall=0 bytes_write=95432 bytes_re$
Stats 16013.6: gcodein=15812 print_time=0.000 buffer_time=0.000 print_stall=0 bytes_write=95432 bytes_re$
Stats 16014.6: gcodein=15812 print_time=0.000 buffer_time=0.000 print_stall=0 bytes_write=95432 bytes_re$
Stats 16015.6: gcodein=15812 print_time=0.000 buffer_time=0.000 print_stall=0 bytes_write=95432 bytes_re$
Stats 16016.6: gcodein=15812 print_time=0.000 buffer_time=0.000 print_stall=0 bytes_write=95432 bytes_re$
Stats 16017.6: gcodein=15817 print_time=0.000 buffer_time=0.000 print_stall=0 bytes_write=95432 bytes_re$
Stats 16018.6: gcodein=15817 print_time=0.000 buffer_time=0.000 print_stall=0 bytes_write=95432 bytes_re$ 

Was your printer heating at the time? If so what was it's temperature at the time of crash?