Welcome! Log In Create A New Profile

Advanced

New experimental firmware: all kinematics in host

Posted by KevinOConnor 
Re: New experimental firmware: all kinematics in host
March 21, 2017 04:45PM
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.
Re: New experimental firmware: all kinematics in host
March 23, 2017 09:10AM
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
Re: New experimental firmware: all kinematics in host
April 10, 2017 07:06AM
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.
Re: New experimental firmware: all kinematics in host
April 10, 2017 07:57AM
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
Klipper v0.4.0 release
May 03, 2017 11:51AM
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
Re: New experimental firmware: all kinematics in host
May 22, 2017 08:03PM
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
Re: New experimental firmware: all kinematics in host
May 23, 2017 02:37PM
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
Re: New experimental firmware: all kinematics in host
May 27, 2017 12:06AM
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:rootconfused smileytarting serial connect
DEBUG:rootconfused smileytarting stk500v2 leave programmer sequence
DEBUG:root:Got '\x1b\x01\x00\x02\x0e\x11\x00\x07' from stk500v2
WARNING:root:Timeout on serial connect
DEBUG:rootconfused smileytarting 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, Hgrinning smiley8, L:FF)

avrdude done.  Thank you.


Any hints?

Greetings

Thorsten
Re: New experimental firmware: all kinematics in host
May 27, 2017 12:43PM
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 12:50PM by mdm63.
Re: New experimental firmware: all kinematics in host
May 27, 2017 01:33PM
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:rootconfused smileytarting serial connect
DEBUG:rootconfused smileytarting stk500v2 leave programmer sequence
DEBUG:root:Got '\x1b\x01\x00\x02\x0e\x11\x00\x07' from stk500v2
WARNING:root:Timeout on serial connect
DEBUG:rootconfused smileytarting 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
Re: New experimental firmware: all kinematics in host
May 27, 2017 01:55PM
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
Re: New experimental firmware: all kinematics in host
May 27, 2017 02:01PM
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
Re: New experimental firmware: all kinematics in host
May 27, 2017 02:29PM
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
Re: New experimental firmware: all kinematics in host
May 28, 2017 12:18AM
You are right, the frequency was the problem, thanks a lot.

Thorsten
Sorry, only registered users may post in this forum.

Click here to login