Quotemdm63 In mean time I decided to take a whack at the "user friendliness" of the PID_TUNE. I was thinking just using ConfigParser.set() to write the values to the printer.cfg. Would it be preferred that the software auto restarts (or just a reload of printer.cfg?) to utilize the new pid values or should we prompt user to do a manual restart? Unfortunately, writing printer.cfg using the Configby KevinOConnor - Firmware - experimental, borrowed, and future
Quotemdm63 I am having issues with the PID tuning. If I give the command PID_TUNE E0 S200 or PID_TUNE E1 S200, it just sits there printing temperatures, but does not heat the hot ends. Unfortunately, a recent code change broke the M303 command in Klipper. I've uploaded a fix to the master git branch. (You should no longer need to use the multiextrude branch as all the key commits on that branby KevinOConnor - Firmware - experimental, borrowed, and future
Quotemdm63 Well got my first dual extruder prints today. I have still some calibrating, setting fiddling to do, but the firmware seems to work good. My temperatures are all over the place tough and the printer stops quite often to wait for the printhead to get to the temperature. At least that's what I think is happening. I suspect that my temperature pid values are crap. I have to try tuning theby KevinOConnor - Firmware - experimental, borrowed, and future
Quotekdodman Got a couple successfull prints, however, I'm getting this error now "Firmware shutdown: Rescheduled timer in the past" The only thing I changed was to dial in my extruder by setting step_distance: .00091666 EDIT: Looks like the code cant handle an extruder at 1/32, I set it to 0.0018 (for 1/16) and it works ok In order to report an issue, please attach (not cut-and-paste) the /tmpby KevinOConnor - Firmware - experimental, borrowed, and future
Quotekdodman pi@octopi:~/klipper $ sudo service klipper stop pi@octopi:~/klipper $ make flash FLASH_DEVICE=/dev/ttyACM0 ... Alas, nothing looks unusual. I can confirm that the Klipper pullup and endstop support is working on a number of boards. I don't have a good explanation for the discrepancy on your board. If it was my board, I'd do some low-level debugging: sudo service klipper stopby KevinOConnor - Firmware - experimental, borrowed, and future
Quotekdodman I just flashed to the latest marlin and end stops are working, other stuff isnt at the moment tho lol I don't see anything in the config that looks unusual. Can you cut-and-paste the output from "make flash": sudo service klipper stop make flash FLASH_DEVICE=/dev/ttyACM0 sudo service klipper start (FYI, your previous log shows a temperature out of range error, but I'm guessing thby KevinOConnor - Firmware - experimental, borrowed, and future
Quotekdodman 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 coby KevinOConnor - Firmware - experimental, borrowed, and future
Quoteeggert ... 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. -Kevinby KevinOConnor - Firmware - experimental, borrowed, and future
Quotemdm63 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 extrby KevinOConnor - Firmware - experimental, borrowed, and future
Quoteeggert 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\x07by KevinOConnor - Firmware - experimental, borrowed, and future
Quotepjk22 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 wby KevinOConnor - Firmware - experimental, borrowed, and future
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 inby KevinOConnor - Firmware - experimental, borrowed, and future
QuoteKeemanaan 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 spby KevinOConnor - Firmware - experimental, borrowed, and future
Quotecrow 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. Do you have plans of implementing aby KevinOConnor - Firmware - experimental, borrowed, and future
Quotecrow 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 likby KevinOConnor - Firmware - experimental, borrowed, and future
Quoteobelisk79 Is the Raspberry Pi Zero powerful enough to run Klipper without issue? I'm thinking about pairing this up with the new Zero W and my RAMPS 1.4 As I understand it, the Zero has the same processor as the RPi1 (though, clocked a little faster). That processor is powerful enough to run Klipper, but I found it wasn't sufficient for Octoprint. I found that some prints with lots of tinby KevinOConnor - Firmware - experimental, borrowed, and future
Quotezungmann pressure_advance is 0.07 and lookahead_time 10ms here you go the log. Thanks. My guess is that a pressure_advance of 0.07 is a bit high for a direct drive extruder with a nozzle diameter of 0.6mm. Pressure advance does two useful things - it reduces blobbing during cornering and it reduces ooze during non-extrude moves. What's changed since the last time you tested is that I addby KevinOConnor - Firmware - experimental, borrowed, and future
QuoteSwift Great project Kevin, I'd love to test it as well, seems a great way forward. Would it be difficult to add support for thermocouples? (e.g AD595, À la Marlin "TEMP_SENSOR -1") It's not difficult to add. If you have the hardware and are willing to run tests, I'll code it up. Send me a PM or email and I'll send directions for running a test version of the code. -Kevinby KevinOConnor - Firmware - experimental, borrowed, and future
Quotezungmann Hi Kevin, I tested the pressure.advance feature. It was jittering a lot, especially on beginning of print. There were in many ocassions during print. I think or guess it happens on low speed printing. Thanks. What did you set the pressure_advance to? Can you send me the log of a print? -Kevinby KevinOConnor - Firmware - experimental, borrowed, and future
Quotezungmann Hi Kevin, Glad to hear new features, would love to test it again. One question: is there a way to limit the 'power' of the bed heater? My current setup for bed is 12V and using 24V so my config limit the current to say 1/4 of pull power (255). Great! There wasn't a way to limit power, but I just added the feature. Grab the latest code and look at "max_power" in the heater sectiby KevinOConnor - Firmware - experimental, borrowed, and future
QuoteSwift Thanks Kevin, looks fantastic! Would like to be one of your testers. Running over the config files now: Seeking confirmation: Is it correct that Klipper supports only one hard end-stop per axis (@ XYZ min), and for (XYZ max) it uses a soft end stop? Cheers. Great! For homing, one may specify either a max endstop or a min endstop on each axis, but not both. It's possible to add ruby KevinOConnor - Firmware - experimental, borrowed, and future
Quotechromedome1964 Very interesting project. I'd love to test it out. Any idea when corexy might be implemented? Implementing corexy should not be very difficult. If you or someone else has the hardware and is willing to run tests, I'll code it up. If interested, send me an email or PM. -Kevinby KevinOConnor - Firmware - experimental, borrowed, and future
Quotezungmann After got several fixes I finally managed to print my fave test: Swan with Klipper using my Prusa Steel. Overall looks pretty good, some small blobs at sharp edges but not all layers which I did not get using other firmware (the same gcode). Thanks for testing! I can't see the blobs in the picture, but if you're seeing more blobs at sharp edges on klipper (vs other firmwares) thenby KevinOConnor - Firmware - experimental, borrowed, and future
Quotedc42 There is no disadvantage to using double, quad etc. stepping provided that they only kick in at high enough step rates. Stepper drivers use a chopper frequency of about 40kHz and the step pulse rate needs to be several times lower than that for the motors to notice the timing of individual microsteps. Interesting. Thanks. I'm curious why you say "several times lower". I agree that iby KevinOConnor - Firmware - experimental, borrowed, and future
This is an announcement for the Klipper v0.3.0 release. There have been many improvements since the initial release. For highlights see: https://github.com/KevinOConnor/klipper/blob/master/docs/Features.md and: https://github.com/KevinOConnor/klipper/blob/master/docs/Releases.md The biggest news in this release is support for printers with delta kinematics! Klipper works by using a host processoby KevinOConnor - Firmware - experimental, borrowed, and future
Quoteobelisk79 Kevin, I have to say, reading the thread and understanding at least some of the planning, consideration and work that has gone into this I'm both impressed and gracious. I intend try this out on my RAMPS/MEGA setup some time in the next couple of weeks. Seeing this inexpensive hardware being pushed to higher levels of performance is both impressive and good for the community at laby KevinOConnor - Firmware - experimental, borrowed, and future
Quotezungmann Thanks. Manually restarting the microcontroller works and helps alot since whenever hit an 'unhandled communication error' in the OctoPrint, the connection to the host is terminated. Reconnect does not help, the problem remains there until restarting the microcontroller and restart the klippy host. I find this quite annoying. You can instruct OctoPrint to not disconnect on error byby KevinOConnor - Firmware - experimental, borrowed, and future
Quotezungmann Hi, I am playing around with klipper I can upload the firmware to my RAMPS, run klippy host and connect with OctoPrint. I get the temperature readings for my hotend and bed. I also get position reading with M114. I checked endstop with M119 and got all triggered. So I think need to invert the endstops config. My endsops are all mechanical, so pull-up must be enabled, which correctlyby KevinOConnor - Firmware - experimental, borrowed, and future
Quotekeedley Hello, Kevin! Thanks for your efforts. Could you tell me - is there any doc or clue how to connect arduino part to drivers and thermisors? for example, i've got an old machine with ramps & mega sandvich, prusa style (double Z motors), 2 thermistors, heaters for extruder and the bed, running Marlin. what could my steps look like to make this machine run using Klipper? pins declby KevinOConnor - Firmware - experimental, borrowed, and future
QuoteTraumflug One additional thing: these number given by the compiler don't take stack memory into account, so one can't even use 100%. The amount of RAM needed for stacks isn't clearly defined, it depends on the program flow. Sticking below 90% RAM with that compiler number should be safe. FYI, as part of developing Klipper, I wrote a script to analyze the stack usage of the AVR assembler thaby KevinOConnor - Firmware - experimental, borrowed, and future