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
Re: New experimental firmware: all kinematics in host
May 29, 2017 01:15AM
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 winking smiley


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 winking smiley

Marko
Re: New experimental firmware: all kinematics in host
May 29, 2017 08:42AM
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.
Re: New experimental firmware: all kinematics in host
May 29, 2017 07:10PM
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?
Re: New experimental firmware: all kinematics in host
May 30, 2017 03:01AM
Hello AnotherOne smiling smiley

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 winking smiley
- 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
Re: New experimental firmware: all kinematics in host
May 30, 2017 04:24AM
@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.
Sorry, only registered users may post in this forum.

Click here to login