Show all posts by user
Page 4 of 4
Pages: 1234
Results 91 — 107 of 107
QuoteJamesK
I find this approach very appealing. How is the project coming along - would you rate it as usable now, or still at the proof of concept stage?
Thanks. I'd say it's in an "experimenting stage". I've been using it regularly on my printer. However, the host software can be finicky at times and its error reporting needs to be improved. Testers are welcome, but expect some bumps.
Qu
by
KevinOConnor
-
Firmware - experimental, borrowed, and future
Quoteshadowjack
Do you really need to convert some geometry + acceleration profile - > steps - > quadratic (cubic) functions of t - > steps?
The main gain of converting to steps and then compressing those steps is that it naturally enables compression across gcode moves. On prints with curves the gcode slicer will emit lots of tiny moves, but after lookahead those moves generally becom
by
KevinOConnor
-
Firmware - experimental, borrowed, and future
Quoteshadowjack
Please consider using not quadratic, but cubic curves - to implement real jerk limiting/S-shape acceleration profile.
Great project, I was thinking about doing similar myself.
Also with this architecture it's easy to use FPGA as controller - it can achive tenth of millions of steps per second if there is need for such speeds.
Thanks.
The step timing via quadratic functions is us
by
KevinOConnor
-
Firmware - experimental, borrowed, and future
QuotePaul Wanamaker
Kevin,
This is very good work!
As I have just written in another place, I've been thinking of a scenario for this kind of thing - for a robotics project with a great number of motors.
QuotePaul W
Instead of interpreting gcode and sending step pulses, a multi-core master controller (like a Pi 3) could send "motion frames" to slave controllers (like 1GHZ Pi Zeros running bare
by
KevinOConnor
-
Firmware - experimental, borrowed, and future
Klipper is an experimental firmware - it is designed to run on both a micro-controller and a low cost host computer such as a Raspberry Pi.
Two new features were recently added to Klipper:
* Endstop accuracy improvement with stepper motor phase. This feature utilizes the phase of the stepper motor driver (eg, a stepper driver with 16 microsteps has 64 distinct phases) along with the endstop tr
by
KevinOConnor
-
Firmware - experimental, borrowed, and future
FYI, I have made some recent updates to Klipper:
* The code has been ported to the Arduino Due ARM based platform. On the Due, Klipper can obtain up to 380K steps per second. Although the ARM and AVR platforms have significant differences, only a small amount of Klipper code needed to be updated to run on this platform.
* Some additional optimizations were made on the Atmega AVR micro-controller
by
KevinOConnor
-
Firmware - experimental, borrowed, and future
QuoteWZ9V
This sort of architecture sounds perfect for a BeagleBone assuming you could adapt the stepper/endstop/thermistor code to run on its two PRU's.
Yes - I think it should be possible to compile the Klipper micro-controller C code for the PRU using the PRU gcc port. With that, the ARM cores in the BeagleBone would be considered the host and one of the PRU cores would be considered the micr
by
KevinOConnor
-
Firmware - experimental, borrowed, and future
Quotefrankvdh
QuoteKevinOConnor
So, the commands are received (and queued) well in advance of the actual stepper movement. On my atmega2560 based RAMBo printer, the "move queue" can hold up to 646 of these stepper sequences in ram. In practice this means the command stream is almost always several seconds ahead of the actual stepper events. (Should some severe communication issue cause a queue un
by
KevinOConnor
-
Firmware - experimental, borrowed, and future
QuoteTraumflug
Had a look at the firmware code now. Nice work! Quite readable once one groks this DECL_... mechanism.
Thank you for reviewing the code.
QuoteTraumflug
Of course I'm curious how klipper manages to about double the maximum step rate compared to Teacup. After reading sources I think it's because there is no stepper motor synchronisation. At least I can find none. Each movement comm
by
KevinOConnor
-
Firmware - experimental, borrowed, and future
Quotedc42
So I think the idea of calculating the kinematics on a host PC been overtaken by the availability of low-cost 32-bit processors, which now cost less than high pin count 8-bit processors such as the atmega2560.
I understand that 32bit micro-controllers are significantly more powerful than 8bit micro-controllers. However, I still think 32bit micro-controllers are vastly under-powered.
by
KevinOConnor
-
Firmware - experimental, borrowed, and future
Quotefrankvdh
Is there any reason not to download the Klipper data to a file on the SD card on the printer, and then print from there? That would allow stand-alone printing. Although that wouldn't be a big deal for someone printing from a RPi, it would mean that a desktop machine could be turned off once the file had been transferred. Someone without a connection between their desktop & print
by
KevinOConnor
-
Firmware - experimental, borrowed, and future
Quotefrankvdh
I'm curious about the 64-bit timing... I suspect that timing information could be left out of the protocol, and just steps sent to the AVR. The AVR should be able to work out the accelerations and therefore pulse timings itself, knowing the max acceleration and speed of each stepper.
The 64bit timing is done in the host. The commands sent to the micro-controller are sent relative
by
KevinOConnor
-
Firmware - experimental, borrowed, and future
QuoteDust
A forth hand is also mumbling that 8 bit arduino is dead and your flogging a dead horse. But there is nothing stopping this working on 32 bit machines
Right - I tried to keep the AVR code to a minimum and to make sure hardware details are isolated from the high-level logic, so I think Klipper should be portable to a variety of micro-controllers.
by
KevinOConnor
-
Firmware - experimental, borrowed, and future
Klipper is a new experimental firmware! It is designed to run on both a micro-controller and a low cost host computer such as a Raspberry Pi. The host does all the work of determining how and when to move each stepper motor, it compresses that information, and sends it to the micro-controller. The micro-controller then uncompresses the given schedule and executes it at the specified times. The s
by
KevinOConnor
-
Firmware - experimental, borrowed, and future
QuoteTraumflug
Nice idea, but are you aware you have to achieve something like 40'000 steps in a single second? That's at least 100 times more than what you can send over a serial line.
Thank you for your reply.
At those high step rates the tool head is going to be traveling at a
near constant velocity though. So, in my thinking, that's still just
one command (per axis). So, to move the X at
by
KevinOConnor
-
Firmware - experimental, borrowed, and future
QuoteRobertKuhlmann
One general question regarding Scara-printers and printer-firmware:
The actual processing interprets GCode-entries e.g. to fill up a buffer with fundamental microcontroller tasks. If the buffer is full, interpretation stops until enough entries in the buffer were processed and deleted. So for simple GCode-Commands the interpretation is ahead of the execution, but for complex
by
KevinOConnor
-
Firmware - experimental, borrowed, and future
Have you considered combining the standard plastruder with a SpoolHead tool? That is, mounting the SpoolHead tool at an angle and pointing it at the plastruder nozzle such that the wire came out at the same place the molten plastic comes out.
The idea would be for the spoolhead tool to emit wire on to the object, and have the plastruder then cover it up with plastic to bond it to the object.
by
KevinOConnor
-
Wire and Thread Embedded Extrusion
Page 4 of 4
Pages: 1234