GithubHelp home page GithubHelp logo

klipper3d / klipper Goto Github PK

View Code? Open in Web Editor NEW
8.7K 355.0 5.1K 168.56 MB

Klipper is a 3d-printer firmware

License: GNU General Public License v3.0

Makefile 0.02% Python 1.01% C 98.83% Shell 0.02% C++ 0.09% Assembly 0.03% Dockerfile 0.01% G-code 0.01% CMake 0.01%

klipper's Introduction

Welcome to the Klipper project!

Klipper

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 for more information on why you should use Klipper.

To begin using Klipper start by installing it.

Klipper is Free Software. See the license or read the documentation. We depend on the generous support from our sponsors.

klipper's People

Contributors

adelyser avatar arksine avatar ayufan avatar bigtreetech avatar cirromulus avatar cruwaller avatar d4sk avatar dalegaard avatar delsian avatar dingyifei avatar dmbutyugin avatar eamaclean avatar fessyfoo avatar fheilmann avatar grigorig avatar jamesh1978 avatar jschuh avatar kevinoconnor avatar ld3300 avatar leptun avatar master92 avatar mattaw avatar matthewlloyd avatar mattthebaker avatar mcmatrix avatar meteyou avatar pedrolamas avatar test3210-d avatar wizhippo avatar wulfsta avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

klipper's Issues

"ADC module not enabled" on BeagleBone Black with CRAMPs and a couple other errors

I just setup my BBB with clipper and when I got to the check area after setting up OctoPrint I get the following three errors.

After boot:
"MCU 'mcu' shutdown: ADC module not enabled"

After doing recommended "FIRMWARE_RESTART" I still get that in the log but the outputted error in OctoPrint is:
ecv: // MCU 'mcu' shutdown: Rescheduled timer in the past
Recv: // This generally occurs when the micro-controller has been
Recv: // requested to step at a rate higher than it is capable of
Recv: // obtaining.

Not sure where to go from those two errors.

Here is my log:
klippy.log.gz

[AT90USB1286] Printer extremely slow

Hello,

As the title suggests, the stepper motors move extremely slow, when homing, endstop trigger sequence switching from axis x to y is also slow, takes about 5 seconds to switch, sending m105 temperature report is slow aswell (3 seconds).
I'm guessing this has to do with clock/tick frequency?

===== Config file =====
[stepper_x]
step_pin = PA0
dir_pin = !PA1
enable_pin = !PE7
step_distance = 0.0015782
endstop_pin = ^PE3
position_min = -0.25
position_endstop = 0
position_max = 100

[stepper_y]
step_pin = PA2
dir_pin = PA3
enable_pin = !PE6
step_distance = 0.0015782
endstop_pin = ^PB0
position_min = -0.25
position_endstop = 0
position_max = 100

[stepper_z]
step_pin = PA4
dir_pin = !PA5
enable_pin = !PC7
step_distance = 0.0000440001408005
endstop_pin = ^PE4
position_min = 0.1
position_endstop = 0.5
position_max = 200

[extruder]
step_pin = PA6
dir_pin = PA7
enable_pin = !PC3
step_distance = 0.000203388451604
nozzle_diameter = 0.400
filament_diameter = 1.750
heater_pin = PC5
filament_diameter = 1.750                                                                                                                   [0/1935]
heater_pin = PC5
max_power = 1.0
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 = 110

[fan]
pin = PC6

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

[printer]
kinematics = cartesian
max_velocity = 500
max_accel = 3000
max_z_velocity = 25
max_z_accel = 30

=======================

I may record a video if necessary.

i2c support and multiple mcu's

Hey

Would it be posible to use i2c for data transfer between python code and mcu?
And maybe then and support for more mcu's on one bus. Ex an mcu for z and y steppers, then an mcu for x and e stepper + heater/temp.
Then we only have to use 6 wires for all data/power on a 3d printer.
12-24v+, gnd, sda, scl, 3.3/5v+ and lowlevel gnd.

Nice work by the way :-) really like to idea to move things to a powerfull armv7

Jesper

Cartesian Z Probe/ Z EndStop

Hello from Spain,
I'm very interested in your firmware because you are improving the kinematics. I installed Klipper but I could not find how setup the z-profe for homing, Probe is working like a Z endstop but I dont know how set it to home in the center of the bed.
I`m availabe as beta tester as I can have your firmware installed permanently. Also I would like to donate if you accept donations.
Kind regards,
Marcos Lemos.

Temp readings off about 50% and no movement or switch signals CRAMPS 2.1

Hotend and bed thermistors are reading about 7deg C when they should be reading about 22.
The Hotend: ATC Semitec 104GT-2
The Bed: EPCOS 100K B57560G104F

screenshot from 2017-10-19 23-08-49

When I trigger M119 the XY list untriggered and Z lists triggered. Whether switches are triggered or even plugged in.

With movement, it send the movement signal, but I am not getting any movement or enabling of the motors.

I'm using the CRAMPS 2.1 and the schematic matches up to the pinout listed in the config.

RTOS for MCU?

Have you evaluated jitter and timings with the current embedded controller?

I'm wondering if moving to a RTOS would make things more deterministic. Before finding klipper I was playing around with using ChibiOS as an MCU OS and using it as just an IO for Python scripts.

Printer Instability

Hello,

I had frequent print crashes lately, I'm not sure whether this had to do with wireless communication or klippy/baudrate config.
After crash I get the following message:
Recv: // Firmware shutdown: Timer too close
Thank you.

Unable to parse move

Happens on longer g-code files with the multistepper branch, tried two different gcode base files. Log

Temperature dependant fan2

Hello,
I configured my printer now. So far everything is pretty straightforward. I love editing the textfile and then just type restart 👍

My Printer has a second fan. This fan cools the heatsink of the hotend (the part with the cold filament). It is automatically switched on at 50°C (Marlin). Is there an option to configure this?

Otherwise it would be ok to switch the second fan together with the first one. Do you have an option for that?

Physical UI support?

Do you plan to add support for LCD + encoder? Or will control always be done through octoprint?

Python 3

Hi,

This looks very interesting! Is python3 support planned?

Thanks,
Jeremy

Compiling fails on Arch-Linux

Hello,
I can't compile on my Arch Linux host. When I ssh into the PI, I can compile there. Here is my Terminal output:

[johannes@Johannes-Desktop klipper]$ gcc --version
gcc (GCC) 7.1.1 20170621
Copyright (C) 2017 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.

[johannes@Johannes-Desktop klipper]$ make
Building out/compile_time_request.o
Traceback (most recent call last):
File "./scripts/buildcommands.py", line 374, in
main()
File "./scripts/buildcommands.py", line 291, in main
for req in data.split('\0'):
TypeError: a bytes-like object is required, not 'str'
make: *** [Makefile:83: out/compile_time_request.o] Fehler 1
[johannes@Johannes-Desktop klipper]$

Klipper hangs on print

Hello, I will describe the symptom in order:

  1. Klipper connects to mcu
  2. Octoprint connects to Kliper without issues
    3.Manual control, temperature control works perfectly.
    4.Load a gcode, printer heatbed heatsup aswell as hotend, axis home
    5.Printer does not respond on the first G0 gcode command, does not move etc.
    6.After couple of minutes i get the following:

Recv: // Lost communication with MCU 'mcu'
Recv: // Once the underlying issue is corrected, use the "RESTART"
Recv: // command to reload the config and restart the host software.
Recv: !! Printer is halted
7.Printer keeps stepper on, and heatcontrol is still working till I halt by power.

I tried changing USB cables, I might try external usb serial adapter if it is any related (once its shipped)

Hardware specs:
Arduino Mega 2560 (taurino clone, reprapdiscount)
RAMPS1.4

Thanks alot, looking forward to use klipper as a daily driver on all of my printers.

klippy.log.gz
FilamentGuideABS.gcode.gz

Use an alternative UART on the RAMPS stack?

Is it possible to configure the klipper firmware touse a different UART on the RAMPS stack?

I would very much prefer not to use the sloppy USB interfaces but rather go directly uart-to-uart between the raspi and atmega.

menuconfig didn't reveal it as a configurable parameter, should I look elsewhere?

If it is not implemented, this might be seen as a feature request/suggestion.

Can't configure needed step_distance for my printer

Found this project today and wanted to try it out immedietly. I have configured X, Y, Extruder, Heating, Bed

But it seems like your implementation can't handle my step_distance for Z

My step_distance for Z should be somewhere around: .000155
When I set I get this immidietly when trying any move on Z:
// Firmware shutdown: Timer too close

If I set it to 0.00155 (10x higher) it works correctly, except that a raise of 100mm gives me 10mm :P

Delta Autocalibration

Hi,
I didn't find anything for G33 Delta Autocalibration. Is there a way to implement it?

Best Regards
Johannes

S-Curve acceleration?

klipper uses standard trapezoid acceleration as far I know. I never seen a firmware with s-curve like acceleration and I think it would work better for printers
Some video from https://www.youtube.com/watch?v=qYJpl7SNoww

Since klipper has enough processing power and the code is well organized I think it should be easy to implement.

Homing after print

I actually have a log file this time!
I've seen this before, but this is the first time i've caught it in the act...

Sometimes after a print, only the X/Y (front towers) home on the G28 that ends the G-Code. The rear tower stays still, typically resulting in a print head hanging out in front of the printer.
I have a feeling it has something to do with the relative movement stuff again, but I haven't been able to spot the common factor.

klippy.zip

Klipper timeout after AVR restart.

AVR controller has its own power supply.
If turn off and turn on AVR power then Klipper is no longer connected to AVR.
Restart service solves the problem.
Example in log
Timeout with MCU 'mcu' (eventtime=3040.583039)
Timeout with MCU 'mcu' (eventtime=3041.584679)

Trying to start Klipper in Ubuntu 12.04

I want to run a Klipper on an old laptop.
Octoprint works without problems.
Klipper hangs at startup and does not write an error.
Here is the log
Starting Klippy...
Args: ['/home/khseal/klipper/klippy/klippy.py', '/home/khseal/printer.cfg', '-l', '/tmp/klippy.log']
Git version: ''
CPU: 1 core Intel(R) Pentium(R) M processor 1.10GHz
Python: '2.7.3 (default, Oct 26 2016, 21:04:23) \n[GCC 4.6.3]'
Starting Klippy...
Args: ['/home/khseal/klipper/klippy/klippy.py', '/home/khseal/printer.cfg', '-l', '/tmp/klippy.log']
Git version: ''
CPU: 1 core Intel(R) Pentium(R) M processor 1.10GHz
Python: '2.7.3 (default, Oct 26 2016, 21:04:23) \n[GCC 4.6.3]'
What could be the problem?
In Ubuntu 16.04 everything works without problems.

Printer crashing

CoreXY + RPI3 + Arduino Mega 16Mhz

Printing at 80mm/s extrude and 120mm/s travel. All steppers are at 1/64 microstep. By my calculation these are both below 100 kHz total stepping.

Log attached. There seems to be some quantity of retransmit happening. I don'k know if the quantity is significant or if non-zero is normal?

klippy.zip

MCU 'mcu' shutdown: Timer too close
clocksync state: mcu_freq=16000000 last_clock=2156399423790 clock_est=(137464.852 2154315356768 16007119.785) min_half_rtt=0.000338 min_rtt_time=136511.884 time_avg=137464.852(17432.689) clock_avg=2154315356768.808(279047141457.125) pred_variance=38847647.776

Dumping serial stats: bytes_write=9379689 bytes_read=15863752 bytes_retransmit=118402 bytes_invalid=0 send_seq=281926 receive_seq=281920 retransmit_seq=281924 srtt=0.007 rttvar=0.005 rto=0.874 ready_bytes=1397 stalled_bytes=3929
Dumping send queue 100 messages

travel speed / tooth pitch / teeth per rotation / steps per rotation / microsteps
(80mm/s)/(2mm*16/200/64) = 32 kHz * 2 for corexy = 64 kHz

I can travel at 120mm/s safely which is 96 kHz, just under the 100 kHz you quote.

extuder:

flow rate = 0.4mm0.2mm80mm/s = 6.4 mm^3/s
Extruder frequency = flow rate / filament area / step size
6.4 mm^3/s / (PI*(1.75mm)^2/4)) / 0.0015985mm = 1.66 kHz

so roughly I estimate 66 kHz stepping required for 80mm/s extrustion, yet I get crashing. Is it a calculation issue, communication issue, or a misunderstanding on my part? My goal would be to be able to print at 100 mm/s given this configuration.

[AT90USB1286] pin mapping error

Hello,

It seems that I have skipped the log before trying the serial option in the other issue ticket.
I'm getting the following error:

=======================
Starting serial connect
Stats 15614.4: gcodein=0 print_time=0.000 buffer_time=0.000 print_stall=0  mcu_task_avg=0.000000 mcu_task_stddev=0.000000
Loaded 51 commands (?-20170608_234759-tmash-nuc)
MCU config: ADC_MAX=1023 PWM_MAX=255 CLOCK_FREQ=16000000 SOFT_PWM_MAX=256 MCU=at90usb1286 STATS_SUMSQ_BASE=256
Stats 15615.4: gcodein=0 print_time=0.000 buffer_time=0.000 print_stall=0 bytes_write=345 bytes_read=1961 bytes_retransmit=9 bytes_invalid=0 send_seq=46 receive_seq=46 retransmit_seq=2 srtt=0.001 r
ttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 est_clock=0.000 last_ack_time=15615.132 last_ack_clock=116493520 mcu_task_avg=0.000000 mcu_task_stddev=0.000000
Config error
Traceback (most recent call last):
  File "/home/tmash/Downloads/klipper-work-at90-serial-20170605/klippy/klippy.py", line 202, in connect
    self.mcu.connect()
  File "/home/tmash/Downloads/klipper-work-at90-serial-20170605/klippy/mcu.py", line 465, in connect
    self._build_config()
  File "/home/tmash/Downloads/klipper-work-at90-serial-20170605/klippy/mcu.py", line 553, in _build_config
    cmd,))
Error: Unable to translate pin name: config_soft_pwm_out oid=0 pin=ar21 cycle_ticks=TICKS(0.100000) default_value=0 max_duration=TICKS(5.000000)

I have tried changing the pin number, removing 'ar', and playing with other settings (enabling fan hardware pwm etc), but the error is persistent. N.b: Took from the serial branch but compiled with USB instead of serial to test first. I don't see how that would be an issue though.

Thanks!
printer.txt

UPDATE: Just tested with master, same result. another note; flashed firmware with dfu-programmer from out/klipper.elf.hex on Printrboard.

Delta Angle Corrections Support

Diving into the kinematics code isn't on my to-do list, but it looks like the tower angles are hard-coded in one spot only. Am I correct in thinking that's the only place an adjustment would need to be made for a tower angle correction? (and if so, that adding that as a config setting would be super-trivial?)

I moved away from klipper for awhile because calibration was becoming a pain on this new machine... since then I've been working on my own rewrite of an OpenDACT-eque application that uses the Escher3D code for delta calibration. Using that I have my settings (tentatively) flawless with Repetier. All the adjustments of which I think I can copy over to klipper except the delta angle corrections...

Exception in flush handler

Hi, I've been trying klipper on my delta printer but it often stops halfway through a print. I have attached the relevant part of the log.
log.txt

Improvement: Material Dependence of Pressure Advance

Hi Kevin,
I have been running your firmware for several months and am very happy. One thing I think we could easily improve is to acknowledge and mitigate the fact that the pressure advance constant needs to change depending upon what type of plastic you are using in the machine.
The solution consists of two parts:
1 - Create a table or guide to allow a quick change of advance constant based on material.
I see this table as having a list of average advance constants. You can use the relative difference between materials on this table to offset your own constant.
To achieve this table, I recommend that people conduct tests on their own printers and report the constants that they use. We can then aggregate this value and come up with a guide.
2- Allow the constant to be changed via g-code or other online command.
This is only a nice-to-have. Presently, you must edit the printer.cfg and restart Klipper. It would be ideal if you could simple put a custom G-code in your program that would set the advance that you desire. This would allow the printer settings to remain the same while still allowing the user to quickly print with different materials. This would also be extremely useful in the case of multiple extruders.
Let me know what you think. I can supply you with my constants for around 10 different materials.

Thanks,
Saul

Add support for Melzi boards

Hi,
I am super excited about your solution, and have exactly the hardware and requirements for it - with one exception. I have a Melzi with an ATMEGA1284P chip.
I tried to build and load the solution with the ATMEGA1280 settings, but this didn't work. I am having troubles getting the RPi to communicate with the board after the firmware is loaded and OctoPi is communicating with the klipper service. Basically the serial communication times out. Klippy.log:

Timeout on serial connect

I am at least marginally able to work with Python, and am actually a CNC engineer, so I'd be happy to work on getting the board running myself if you could point me in the right direction. Once that happens, I'd be interested in seeing what I could contribute to improving kinematics, etc.

Thanks!

Virtual serial issues

I've noticed problems with some command sequences not registering when sent in succession,
Octoprint, for example, sends every jog move like so:
G91
G0 X5
G90
I.E. relative

However, klipper often doesn't always register the switch back to absolute so a subsequent move fails.
Along the same lines, sending a sequence like this:
g0 x0 y0 z5
m400
probe
m400
m114

will (most of the time) fail. The location request might fire before the probe (though as probe isn't a standard command, I don't know if that's a special case)
Maybe i'm misunderstanding the protocol, but I would assume some sort of command queue would be handling this

Core X/Y Support

Hello Kevin,

I'd like to give Klipper a try on my core xy build but I have trouble understanding the movement code which I would need to adapt on the python side.

Is there any chance I could get a quick example to get me on the right track?

Thank you,
Razvan

Fan support

I'm very excited by this project - it makes perfect sense to me. I just finished working my way through the first pass of configuration. I may be missing something, but I don't see much in the way of fan support. I found the "Extruder print fan" - is this referring to the part-cooling fan or the extruder transition fan? In either case - is the other supported?
I attempted to manually enable an always-on fan at startup using the custom command support, but apparently no matter what I do I can't get the formatting correct there... not sure what exactly it's expecting.

float division by zero when adc reads 1.0

When no thermistor is connected:
Traceback (most recent call last): File "/opt/klipper/klippy/serialhdl.py", line 51, in _bg_thread hdl(params) File "/opt/klipper/klippy/mcu.py", line 404, in _handle_analog_in_state self._callback(last_read_time, last_value) File "/opt/klipper/klippy/heater.py", line 157, in adc_callback temp = self.sensor.calc_temp(read_value) File "/opt/klipper/klippy/heater.py", line 39, in calc_temp r = self.pullup * adc / (1.0 - adc) ZeroDivisionError: float division by zero

I know no thermistor connected is an "hardware error" but this schould produce an error "float division by zero". Maybe returning a negative value?

Atmega328 PINs

Hello!
Firstly, I could not use arduino pins names, for example ar2, analog1 .. But it's not scary, atmega names like PC1, PC0 work fine, except for two. These are the ADC6 and ADC7 pins, they do not have gpio, they are only connected to the ADC. I use them for connecting thermistors, changing the board will be difficult. I watched klipper / klippy / pins.py and saw

  Arduino_analog_standard = [
     "PC0", "PC1", "PC2", "PC3", "PC4", "PC5", "PE0", "PE1",
]

I tried PE0 and PE1, but it also did not work, "Unable to translate pin name".
  For Teacup Firmware, these pins worked well.

BLTouch support?

I know that Z-probe isn't really finished but I am trying to get bltouch working as normal endstop. With diffing it as servo I can control it, with command SET_SERVO SERVO=bltouch ANGLE=10 I can deploy bltouch. The problem is when homing after touching the bed bltouch locks up and I am getting:
"!! Endstop z still triggered after retract"
Bltouch locking is a complete normal thing, we just need reset and deploy it again before doing retract.
And I can not find a good way to do it with would be "hackish".

Single Nozzle / Multi Extruder

Hi There,

I see that there is a thread for multiple extruders being tested, I wonder if it would be possible to have multiple extruders with a single nozzle? Similar to the e3d cyclops.

Thanks!

handling of multiple MCUs

I am testing with two boards, a Mega2560+RAMPS and a TronXY board that is a Melzi derivate.

The avr currently flashes with -cwiring, but the TronXY needs -carduino.
I don't know if this applies to all Melzi boards.

I also wonder how we should handle .config for multiple MCUs?

I would like to use different output directories OUT=... and different .config files for different MCUs.
Currently, I configure each MCU and copy the .config to a named file outside the git-repo.
I use a script to compile the firmware for both MCUs:

#!/bin/zsh

sudo service klipper stop

cp config-RAMPS klipper/.config
pushd klipper
make flash FLASH_DEVICE=/dev/ttyACM0 PROGRAMMER=wiring OUT=out-RAMPS/
popd

cp config-tronxy klipper/.config
pushd klipper
make flash FLASH_DEVICE=/dev/ttyUSB0 PROGRAMMER=arduino OUT=out-tronxy/
popd

sudo service klipper start

To make this work, I had to use another variable PROGRAMMER=....

I changed the Makefile for avr like this:

PROGRAMMER=wiring
...
flash: $(OUT)klipper.elf.hex
	@echo "  Flashing $(FLASH_DEVICE) via avrdude"
	$(Q)if [ -z $(FLASH_DEVICE) ]; then echo "Please specify FLASH_DEVICE"; exit 1; fi
	$(Q)avrdude -p$(CONFIG_MCU) -c$(PROGRAMMER) -P"$(FLASH_DEVICE)" -D -U"flash:w:$(OUT)klipper.elf.hex:i"

I also thought, it would be more logical to add those variables FLASH_DEVICE and PROGRAMMER (if not configured via menuconfig) to printer.cfg and automatically compile all MCUs that change in printer.cfg when FIRMWARE_RESTART is invoked.

Configuration via make menuconfig could then be invoked by something like:
make MCU=RAMPS1 menuconfig
generating a .config-$(MCU).
Output directory woud be out-$(MCU).

Odd CPU usage at idle

Hello,

I have noticed that whenever klippy is idle disconnected or connected and not printing or doing anything (e.g if I set the extruder temp cpu goes down to 1%, when temperature is reach, spikes 100 again and alters between 100 and 1 in slow frequency, if i turn it off, its back at 100% all the time), cpu spikes to 100% on one cpu thread:
screenshot_20170614_225151

Also CPU spikes immediatly after repeating pattern of the 'no serial found' message:
image

Would be great to hear feedback from other users to isolate whether its an issue with my config/environment or klippy bug. Running on desktop, python version: Python 2.7.12

tmash@tmash-nuc:~$ pip freeze
beautifulsoup4==4.4.1
chardet==2.3.0
cycler==0.9.0
html5lib==0.999
iotop==0.6
lxml==3.5.0
matplotlib==1.5.1
numpy==1.11.0
Pillow==3.1.2
Pivy==0.5.0
ply==3.7
pycollada==0.4
pygobject==3.20.0
PyOpenGL==3.0.2
pyparsing==2.0.3
pyserial==3.0.1
python-dateutil==2.4.2
pytz==2014.10
six==1.10.0
smbus==1.1
vboxapi==1.0
virtualenv==15.0.1
wxPython==3.0.2.0
wxPython-common==3.0.2.0
youtube-dl==2016.2.22

EDIT1: To add, just tried the python3 branch, same issue.

Setup issues

Sorry for being a total newb, but im coming from marlin and i'm trying to understand how to figure out step distance for x,y,z, and e0. I'm using htd3 belts and 12 teeth pulleys for x/y and 3/8-12 acme screws on z. I'm using a direct drive mk8 drive gear on my extruder with an e3d hotend. I know that they are not very commonly used parts but its what i had laying around from another project. The install guide doesn't clarify how to calculate step distance. Would it be somewhat similar to marlin or is there a formula that i can use?By the way, great work! I'm looking foward on getting my setup working.

reconnect after printer hard reset

When I do a hard reset on the printer (power off & on), the port of the printer changes from /dev/ttyUSB0 to /dev/ttyUSB1.
Of course I then get a timeout while connecting. So I have to edit the config file and do a restart. Could it be a good idea to implement some kind of probing for another port on a timeout?

Error: Move exceeds maximum extrusion cross section

I installed Klipper on my D Bot, with Ramps 1.4 and Raspi 3.

I'm attaching my configuration file, and the base one from Marlin I was using before (for comparison).
dbot-std-corexy.txt

Configuration.txt

I tried to print a cube, and I noticed while mostly ok, the printer does make some weird moves. Example, when it is printing the skirt (3 lines), I'd expect it to go in a circular movement 3x times, but for some reason, the head moves back and forth on 2 sides, and not exactly on the skirt path. You can see it here:

https://www.youtube.com/watch?v=41V2Z4cEV5A&feature=youtu.be

I tested the basic core xy moves, and everything moves in the correct direction, and homing all the axis is also working properly.

After I left it running for a few more seconds, I got this error:

Send: N4314 G1 X137.543 Y156.776 E0.0181*107
Recv: ok
Send: N4315 G1 X125.022 Y144.255 E0.5300*98
Recv: ok
Send: N4316 G1 X125.156 Y144.137 E0.0054*99
Recv: ok
Send: N4317 G1 X125.235 Y144.089 E0.0028*107
Recv: ok
Send: N4318 G1 X125.345 Y144.043 E0.0036*107
Recv: ok
Send: N4319 G1 X125.369 Y144.036 E0.0007*100
Recv: ok
Send: N4320 G1 X138.147 Y156.815 E0.5409*105
Recv: ok
Send: N4321 M105*19
Recv: ok T0:205.0 /205.0 B:69.1 /70.0
Send: N4322 G1 X138.752 Y156.854 E0.0181*108
Recv: ok
Send: N4323 G1 X125.872 Y143.974 E0.5452*101
Recv: ok
Send: N4324 G1 X126.403 Y143.940 E0.0159*103
Recv: ok
Send: N4325 G1 X139.356 Y156.892 E0.5483*98
Recv: ok
Send: N4326 G1 X139.961 Y156.931 E0.0181*101
Recv: !! Move exceeds maximum extrusion cross section: 139.356 156.892 0.680 [138.590]
Changing monitoring state from 'Printing' to 'Error:  Move exceeds maximum extrusion cross section: 139.356 156.892 0.680 [138.590]\x0a'

Also here is the klippy.log

Starting Klippy...
Args: ['/home/pi/klipper/klippy/klippy.py', '/home/pi/printer.cfg', '-l', '/tmp/klippy.log']
Git version: 'v0.4.0-157-g026b9c3-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]'
Start printer at Sat Sep  2 02:17:05 2017 (1504318625.9 10.6)


Starting serial connect
Stats 4905.4: gcodein=0 print_time=0.000 buffer_time=0.000 print_stall=0  mcu_awake=0.000 mcu_task_avg=0.000000 mcu_task_stddev=0.000000
Loaded 51 commands (v0.4.0-157-g026b9c3-20170902_024250-octopi)
MCU config: ADC_MAX=1023 PWM_MAX=255 CLOCK_FREQ=16000000 SOFT_PWM_MAX=256 SERIAL_BAUD=250000 MCU=atmega2560 STATS_SUMSQ_BASE=256
Sending printer configuration...
Configured (640 moves)
Stats 4906.4: gcodein=0 print_time=0.000 buffer_time=0.000 print_stall=0 bytes_write=638 bytes_read=2244 bytes_retransmit=0 bytes_invalid=0 send_seq=80 receive_seq=80 retransmit_seq=0 srtt=0.004 rttvar=0.001 rto=0.025 ready_bytes=0 stal$
High clock drift! Now 15926943:16001600 was 15998400:16001600
Stats 4907.4: gcodein=0 print_time=0.000 buffer_time=0.000 print_stall=0 bytes_write=644 bytes_read=2312 bytes_retransmit=0 bytes_invalid=0 send_seq=81 receive_seq=81 retransmit_seq=0 srtt=0.004 rttvar=0.001 rto=0.025 ready_bytes=0 stal$
High clock drift! Now 15926191:16001600 was 15926943:16001600
Stats 4908.4: gcodein=41 print_time=0.000 buffer_time=0.000 print_stall=0 bytes_write=650 bytes_read=2406 bytes_retransmit=0 bytes_invalid=0 send_seq=82 receive_seq=82 retransmit_seq=0 srtt=0.004 rttvar=0.001 rto=0.025 ready_bytes=0 sta$
Stats 4909.4: gcodein=46 print_time=0.000 buffer_time=0.000 print_stall=0 bytes_write=656 bytes_read=2526 bytes_retransmit=0 bytes_invalid=0 send_seq=83 receive_seq=83 retransmit_seq=0 srtt=0.004 rttvar=0.001 rto=0.025 ready_bytes=0 sta$
High clock drift! Now 15871886:16001600 was 15926191:16001600

Any ideas? :)

Z Offset question

Hello!
I'm currently using Marlin 1.1.6 with a RAMPS 1.4.2 and ABL Z Probe.
Is klipper currently able to set a Z Offset for the sensor (i've got no Endstop for the Z axis and if i can set an offset it would be possible to level the bed manually an try the firmware)?
I really would like to klipper but i haven't found any information about that.
Can clipper run on x86_64 hardware, for my Ocotprint host i'm running a Gigabyte Brix with an Intel Core i3.
Regards

homing order configuration option

On my corexy, Y must be homed before X, otherwise it won't hit the stop.

Obviously I can use G28 Y G28 X G28 Z, but it would be nice if G28 or G28 XYZ would function safely as well, in case a misconfigured slicer was used.

It looks like this will be a simple change, if you agree it's worthwhile I'll open a PR.

Possible E1 pins backwards in generic-rambo.cfg

Before trying this firmware on my Makerfarm 10" Prusa i3v with Rambo Electronics, titan extruder & e3d Lite6, I was looking at the definitions of these pins.

I came across this page, http://reprap.org/wiki/Rambo_development that described these pins & the pins for the E1 extruder seem like they may be backwards since the other pairs of pins go in order of Microstep1 & then Microstep2. This is line 106 of the file generic-rambo.cfg. I am not using a 2nd extruder, so it is not a problem for me.

52 PG1 ( RD ) Digital pin 40 X Microstep1
51 PG0 ( WR ) Digital pin 41 X Microstep2

82 PK7 ( ADC15/PCINT23 ) Analog pin 15 Y Microstep1
70 PG2 ( ALE ) Digital pin 39 Y Microstep2

83 PK6 ( ADC14/PCINT22 ) Analog pin 14 Z Microstep1
84 PK5 ( ADC13/PCINT21 ) Analog pin 13 Z Microstep2

86 PK3 ( ADC11/PCINT19 ) Analog pin 11 E0 Microstep1
85 PK4 ( ADC12/PCINT20 ) Analog pin 12 E0 Microstep2

87 PK2 ( ADC10/PCINT18 ) Analog pin 10 E1 Microstep2
88 PK1 ( ADC9/PCINT17 ) Analog pin 9 E1 Microstep1

26 PB7 ( OC0A/OC1C/PCINT7 ) Digital pin 13 (PWM) LED, PWM-Ext 3

Does klipper support dual Z ?

Hi,
I'm just understood this approach to firmware is the future. I have three printers, Prusa , K8400, HyperCube Evo. I want to try klipper in one. So, I have some questions before decide which one.

  1. Does klipper support dual Z? I mean dual Z motor with two min end stops, each motor move separately, like Repetier does.
  2. Does it support min, max end stops?
  3. Does it support tmc2130 and SPI ?

sorry for dummy questions. I think it is last time ;)

"restart_method: command" - deadlocks

Configured restart_method: command in the [mcu] section in printer.cfg

But when I do a FIRMWARE_RESTART the atmega just enters a crazy deadlock where it blinks forever.

Even hitting the reset button doesn't help, it just continue blinking when I release the button again.
Flashing new firmware is impossible too.

Only thing to clear the mishap is a power cycle.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.