Re: New experimental firmware: all kinematics in host December 30, 2017 06:58PM |
Registered: 7 years ago Posts: 270 |
Quote
pamalofeev
He got it here.Quote
hg42
you still did not answer from where you got the number 25.
Quote
FEATURES
Klipper touts several “compelling features”:
Each stepper event is scheduled with a precision of 25 microseconds or better. The software does not use kinematic estimations (such as the Bresenham algorithm). It calculates precise step times based on the physics of acceleration and the physics of the machine kinematics. More precise stepper movement translates to quieter and more stable printer operation.
When I needed help with a teacup, the Traumflug refused me. When I needed help with the klipper, Kevin completely helped me. Maybe that's why the klipper is better than "others firmwares"?
Re: New experimental firmware: all kinematics in host January 01, 2018 08:36PM |
Registered: 11 years ago Posts: 10 |
send a request for a timestamp (taking some time to go through the communication channel), receive the timestamp, take the half between the times of the request and reception of the timestamp, compare that to the timestamp.
Re: New experimental firmware: all kinematics in host January 01, 2018 08:47PM |
Registered: 11 years ago Posts: 10 |
Quote
newbob
I like that large part of Klipper (including configuration) is on Rpi and can be modified almost on the fly, no recomplile/flash needed.
Quote
newbob
EDIT: klipper can run in VirtualAVR as well and also has a graphing script (graphstats) that parses logs.
Re: New experimental firmware: all kinematics in host January 02, 2018 03:36AM |
Registered: 10 years ago Posts: 14,684 |
Quote
hg42
Quote
newbob
I like that large part of Klipper (including configuration) is on Rpi and can be modified almost on the fly, no recomplile/flash needed.
I agree, it's another level of flexibility.
On Smoothieware you can edit the configuration and restart.
On Klipper you can edit just about every aspect that matters and restart.
Re: New experimental firmware: all kinematics in host January 02, 2018 10:37AM |
Registered: 11 years ago Posts: 10 |
Re: New experimental firmware: all kinematics in host January 03, 2018 09:56PM |
Registered: 8 years ago Posts: 91 |
Re: New experimental firmware: all kinematics in host January 10, 2018 01:00PM |
Registered: 11 years ago Posts: 118 |
Quote
KevinOConnor
Quote
pamalofeev
Hello, Kevin!
I really liked the klipper and I want to use it. And I had to solve one more problem, layers shift, you can see in the photo. I do not use stepper motors in my 3D printer, I use collector motors with a step / dir interface instead. You can read about my printer here, I hope GoogleTranslit will help you. It seems klipper did not give my drivers enough width for step-pulse, because here's such a dirty hack fixed the layer shift:
The Klipper stepping code is designed to provide at least a 2 micro-second step pulse. That time is sufficient for all commonly available stepper motor drivers. If I understand your article correctly, you've built your own motor driver (impressive!) that needs a longer step time.
Do you know how long of a step pulse time you need? The code you posted seems to produce a 4 micro-second step pulse time.
If your driver can handle a 3 micro-second step time then you could change:
gpio_out_toggle(s->step_pin); if (s->flags & SF_HAVE_ADD) s->interval += s->add;to:
s->interval += s->add; gpio_out_toggle(s->step_pin);
It should not be necessary to add a delay on the second gpio_out_toggle() as that code path is already slow.
Increasing the step pulse time decreases the maximum stepping rate of the firmware. So I don't think it makes sense to change the main Klipper code.
-Kevin
Re: New experimental firmware: all kinematics in host January 10, 2018 09:09PM |
Registered: 14 years ago Posts: 107 |
Quote
mrc
Hey Kevin, your Firmware is one awesome piece of Software, congrats!
I want to go all in with Klipper on my CoreXY with Ultratronics board.
The only thing holding me back are the timings of my External Stepper.
Im using Leadshine DM422C, they are great but pretty Slow.
The Timings are really well described but a bit weird in comparison with other Drivers:
b) t2: DIR must be ahead of PUL effective edge by 5ms to ensure correct direction;
c) t3: Pulse width not less than 7.5ms;
d) t4: Low level width not less than 7.5ms.
Im using Repetier Firmware currently and set it like that:
#define STEPPER_HIGH_DELAY 8
#define DIRECTION_DELAY 3
Pamalofeev had a similar Issue on Page 7, although i bet you described it very well im too much of a Programming noob to understand and change it to my needs.
Maybe you could help me out with this Issue
#define UNSTEP_TIME timer_from_us(2)to
#define UNSTEP_TIME timer_from_us(8)You'll then need to recompile and flash the micro-controller code. I don't think the direction pin timing is an issue as Klipper typically loads that way in advance of its first step.
Re: New experimental firmware: all kinematics in host January 12, 2018 12:22PM |
Registered: 11 years ago Posts: 118 |
# This file serves as documentation for config parameters of corexy # style printers. One may copy and edit this file to configure a new # corexy printer. Only parameters unique to corexy printers are # described here - see the "example.cfg" file for description of # common config parameters. # DO NOT COPY THIS FILE WITHOUT CAREFULLY READING AND UPDATING IT # FIRST. Incorrectly configured parameters may cause damage. # The stepper_x section is used to describe the X axis as well as the # stepper controlling the X+Y movement. [stepper_x] step_pin: ar35 dir_pin: ar34 enable_pin: ar37 step_distance: .001869 endstop_pin: ^!ar31 position_endstop: 0 position_max: 240 homing_speed: 10 # The stepper_y section is used to describe the Y axis as well as the # stepper controlling the X-Y movement. [stepper_y] step_pin: ar22 dir_pin: ar23 enable_pin: ar33 step_distance: .001869 endstop_pin: ^!ar12 position_endstop: 0 position_max: 280 homing_speed: 10 [stepper_z] step_pin: ar25 dir_pin: ar26 enable_pin: ar24 step_distance: .000245 endstop_pin: ^ar29 position_endstop: 0.2 position_max: 180 [extruder] step_pin: ar46 dir_pin: ar47 enable_pin: ar48 step_distance: .001205 nozzle_diameter: 0.300 filament_diameter: 1.750 heater_pin: ar3 sensor_type: ATC Semitec 104GT-2 sensor_pin: analog0 control: pid pid_Kp: 13.5700 pid_Ki: 0.9000 pid_Kd: 50.9100 min_temp: 0 max_temp: 280 [heater_bed] heater_pin: ar2 sensor_type: ATC Semitec 104GT-2 sensor_pin: analog1 control: watermark min_temp: 0 max_temp: 130 [fan] pin: ar6 [mcu] serial: /dev/ttyACM0 pin_map: arduino [printer] kinematics: corexy # This option must be "corexy" for corexy printers. max_velocity: 300 max_accel: 3000 max_z_velocity: 15 max_z_accel: 10
// Ultratronics Board (experimental, use with care probably even not working!) // [www.reprapworld.com] #if MOTHERBOARD == 409 #ifndef __SAM3X8E__ #error Oops! Make sure you have 'Arduino Due' selected from the 'Tools -> Boards' menu. #endif #define KNOWN_BOARD #define CPU_ARCH ARCH_ARM #define ORIG_X_STEP_PIN 35 #define ORIG_X_DIR_PIN 34 #define ORIG_X_MIN_PIN 31 #define ORIG_X_MAX_PIN 30 #define ORIG_X_ENABLE_PIN 37 #define ORIG_Y_STEP_PIN 22 #define ORIG_Y_DIR_PIN 23 #define ORIG_Y_MIN_PIN 12 #define ORIG_Y_MAX_PIN 11 #define ORIG_Y_ENABLE_PIN 33 #define ORIG_Z_STEP_PIN 25 #define ORIG_Z_DIR_PIN 26 #define ORIG_Z_MIN_PIN 29 #define ORIG_Z_MAX_PIN 28 #define ORIG_Z_ENABLE_PIN 24 // Note that on the Due pin A0 on the board is channel 2 on the ARM chip #define HEATER_0_PIN 3 // Due analog pin A0 = channel 7 #define TEMP_0_PIN 7 #define HEATER_1_PIN 2 // Due analog pin A1 = channel 6 #define TEMP_1_PIN 6 // Due analog pin #58 #define HEATER_2_PIN 8 // Due analog pin A2 = channel 5 #define TEMP_2_PIN 5 #define HEATER_3_PIN 6 // Due analog pin A3 = channel 4 #define TEMP_3_PIN 4 #define HEATER_4_PIN 9 // Due analog pin A4 = channel 3 #define TEMP_4_PIN 3 // Dua analog pin #59 = A5 -> AD 2 #define THERMOCOUPLE_0_PIN 65 #define THERMOCOUPLE_1_PIN 52 #define THERMOCOUPLE_2_PIN 51 #define THERMOCOUPLE_3_PIN 50 #define ORIG_E0_STEP_PIN 47 #define ORIG_E0_DIR_PIN 46 #define ORIG_E0_ENABLE_PIN 48 #define ORIG_E1_STEP_PIN 44 #define ORIG_E1_DIR_PIN 36 #define ORIG_E1_ENABLE_PIN 45 #define ORIG_E2_STEP_PIN 42 #define ORIG_E2_DIR_PIN 41 #define ORIG_E2_ENABLE_PIN 43 #define ORIG_E3_STEP_PIN 39 #define ORIG_E3_DIR_PIN 38 #define ORIG_E3_ENABLE_PIN 40 #define SDSUPPORT -1 #define SDPOWER -1 // 4,10,52 if using HW SPI. #define SDSS 59 //#define NONSTANDARD_SDSS #define MOSI_PIN 75 #define MISO_PIN 74 #define SCK_PIN 76 #define ORIG_SDCARDDETECT 60 #define SDCARDDETECTINVERTED 0 #define LED_PIN 13 #define ORIG_FAN_PIN 6 #define ORIG_FAN2_PIN 5 #define ORIG_PS_ON_PIN -1 #define KILL_PIN -1 #define SUICIDE_PIN -1 //PIN that has to be turned on right after start, to keep power flowing. #define ENC424_SS 61
Re: New experimental firmware: all kinematics in host January 12, 2018 01:45PM |
Registered: 7 years ago Posts: 270 |
Re: New experimental firmware: all kinematics in host January 12, 2018 06:51PM |
Registered: 14 years ago Posts: 107 |
Quote
mrc
Thanks a lot for your fast help!
The Installation worked flawless thanks to the very well done Documentation.
Endstops, Thermistors and Heater are working so far.
But my Stepper are making Problems, till now only one Stepper is working (Y).
X isn´t moving at all, the motor is only stalling.
Z responses to Homing but it´s only wiggling, not really noisy so i don´t think its losing steps.
I double checked the Pin Settings but i can´t find the solution, i got the feeling that im missing something important.
Quote
PS: is there a possibility to move the motors without Homing? It´s a nice safety feature but its not that great for debugging.
Re: New experimental firmware: all kinematics in host January 12, 2018 07:07PM |
Registered: 14 years ago Posts: 107 |
Quote
newbob
I've been reading the docs and wondering how acceleration and deceleration portions of the trapezoidal motion is synchronized between the axes. Is acceleration/decel slope shared among axes?
Re: New experimental firmware: all kinematics in host January 13, 2018 01:42PM |
Registered: 7 years ago Posts: 270 |
Quote
KevinOConnor
Quote
newbob
I've been reading the docs and wondering how acceleration and deceleration portions of the trapezoidal motion is synchronized between the axes. Is acceleration/decel slope shared among axes?
I'm not sure I understand your question. The Klipper host software determines the ideal time to step each stepper motor based on the formulas for acceleration and printer kinematics. Those times are then compressed, sent to the micro-controller, and the micro-controller executes that schedule of step times. So, acceleration is synchronized between stepper motors by virtue of each stepper stepping near their ideal time.
Klipper does not use "speed ramps" or similar kinematic estimation algorithms. These systems introduce inaccuracies into the motion of the printer - they are justified by the reduced micro-controller overhead they provide. Klipper doesn't need to estimate the kinematics as the kinematics are calculated on a general purpose computer (eg, a low-cost Raspberry Pi).
-Kevin
Re: New experimental firmware: all kinematics in host January 13, 2018 03:00PM |
Registered: 14 years ago Posts: 107 |
Quote
newbob
I have another question, consider toolhead going from point A[0,0] to B[1,1]. You could do x+1 and then y+1 (you end up at the right point but path is not the shortest, not a line) I guess that's what one would call approximation. If you synchronize movement of both axes you'll get from A to B in the shortest possible way, drawing a line. However what if you have to move from A[0,0] to B[0,3]. Do you go x+1 and x+1 y+1 together? It seems to me due to step size and inability to control how fast step takes, in some cases, path has to be approximated. Am I right?
Re: New experimental firmware: all kinematics in host January 14, 2018 01:37PM |
Registered: 11 years ago Posts: 118 |
Re: New experimental firmware: all kinematics in host January 15, 2018 06:28AM |
Registered: 6 years ago Posts: 2 |
Re: New experimental firmware: all kinematics in host January 15, 2018 09:35AM |
Registered: 14 years ago Posts: 107 |
Quote
mrc
i attached the the Log file, you can download the Klipper directory from my drive:
[drive.google.com]
EDIT: i missed to change the delay (8) in this log, nevertheless it behaved exactly the same as with the delay (only Y running).
Re: New experimental firmware: all kinematics in host January 15, 2018 09:37AM |
Registered: 14 years ago Posts: 107 |
Re: New experimental firmware: all kinematics in host January 15, 2018 10:19AM |
Registered: 6 years ago Posts: 2 |
Re: New experimental firmware: all kinematics in host January 15, 2018 02:27PM |
Registered: 11 years ago Posts: 118 |
Quote
KevinOConnor
Quote
mrc
i attached the the Log file, you can download the Klipper directory from my drive:
[drive.google.com]
EDIT: i missed to change the delay (8) in this log, nevertheless it behaved exactly the same as with the delay (only Y running).
Neither the log nor the "Klipper directory" link you sent show the code change. In order to help I'd need to see the log from after the change as well as the output from the command "cd ~/klipper ; git diff" run after the change on the Raspberry Pi. Again, it would require changing src/stepper.c to use 8 microseconds and then the micro-controller needs to be reflashed.
-Kevin
Re: New experimental firmware: all kinematics in host January 20, 2018 05:31PM |
Registered: 6 years ago Posts: 12 |
Quote
hg42
It is scalable and flexible like hell...
you can have a dedicated controller for each axis and each heater etc. (e.g. take 2-5EUR Arduino Nanos).
Re: New experimental firmware: all kinematics in host January 21, 2018 03:41PM |
Registered: 11 years ago Posts: 10 |
Quote
teikjoon
am I correct to assume that I would need to wire up a stepper driver to each Arduino Nano, load up the firmware with them (configuring its alias) and then connect all of them to the main Raspberry Pi through a USB hub?
Re: New experimental firmware: all kinematics in host January 22, 2018 07:39AM |
Registered: 11 years ago Posts: 10 |
Quote
teikjoon
Poked around in the klipper documentation to see how I could do thisQuote
hg42
It is scalable and flexible like hell...
you can have a dedicated controller for each axis and each heater etc. (e.g. take 2-5EUR Arduino Nanos).
Re: New experimental firmware: all kinematics in host January 22, 2018 11:25PM |
Registered: 6 years ago Posts: 68 |
Re: New experimental firmware: all kinematics in host January 23, 2018 01:34PM |
Registered: 14 years ago Posts: 107 |
Quote
kapperi
I have just installed Klipper to rpi2 and it works with Sav mk1 just fine.
Only thing that is problematic is the "restart" command, it seems that it doesnt work. It gives me "Automated restart of mcu.... Etcetc" Is there any way to get this working?
Quote
And the other thing is that z-axis studders, it moves a couple of millimeters and then just studdering...
Re: New experimental firmware: all kinematics in host January 24, 2018 12:34AM |
Registered: 6 years ago Posts: 68 |
Quote
KevinOConnor
Quote
kapperi
I have just installed Klipper to rpi2 and it works with Sav mk1 just fine.
Only thing that is problematic is the "restart" command, it seems that it doesnt work. It gives me "Automated restart of mcu.... Etcetc" Is there any way to get this working?
If you're having an issue, please follow the directions at https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md to report it. In particular, we need the klippy.log file in order to assist.
Quote
And the other thing is that z-axis studders, it moves a couple of millimeters and then just studdering...
Please also be sure to read about that item in the FAQ.
Re: New experimental firmware: all kinematics in host January 24, 2018 12:53AM |
Registered: 6 years ago Posts: 12 |
Quote
hg42
A simple mega2560/RAMPS combination will easily do the whole MCU job, because all complex things like calculating delta kinematics or precise step times run on the host (PI or PC).
So Klipper kind of "upgrades" your printer electronics by outsourcing the heavier jobs.
.
Re: New experimental firmware: all kinematics in host January 25, 2018 07:05AM |
Registered: 11 years ago Posts: 150 |
Re: New experimental firmware: all kinematics in host January 25, 2018 11:02AM |
Registered: 14 years ago Posts: 107 |
Quote
M_Xeno
Hi Kevin !
I'm a big fan of your work, which seems strategic to me: this approach could change a lot of things in 3D FDM printing.
Quote
Have you considered this path of evolution, in the future, for Klipper: to do without the G-Code?
Re: New experimental firmware: all kinematics in host January 27, 2018 12:22PM |
Registered: 6 years ago Posts: 68 |
Quote
kapperi
Quote
kapperi
I have just installed Klipper to rpi2 and it works with Sav mk1 just fine.
I´m going to try the github way with the reset problem, I looked the log file but I couldn´t found any problem from there, just the same message "Automated reset of mcu...." First I´m going to check if theres something else wrong.