> Sometimes the presence of first-class hardware results in other hardware being treated as "second-class"
The firmware is entirely open source so it should be easy for other companies to port it to their own hardware. The MCU we use is also supported by Klipper and Marlin, so there will not have to be a decision between designing hardware for Prunt or other options. That being said, there is no existing hardware that our firmware can be ported to directly as we make extensive use of hardware timers rather than doing pulse generation/counting in software and 3D printer hardware is not generally designed with this in mind.
It should be reasonably simple to do everything in software if anyone were inclined to do so to support existing boards. Prunt itself is actually a library with a very high level API intended to make it easy to support all sorts of odd hardware: https://github.com/Prunt3D/prunt/blob/6a9dbd0a8d5edd890e4b72...
> especially since it sounds like the first-class hardware will eventually be much more than $100
The BOM cost is over $100, so this will be the case, however I would like to try and keep the price well under $200 for something similar to the current hardware.
> Adjustable acceleration is already an option on most systems, does editing jerk/snap/crackle actually improve my print quality or just give me more parameters to fiddle with?
In my testing I have seen less resonance artefacts with higher order limits as opposed to just limiting acceleration, however I have not done extensive comparisons to other options such as input shaping.
> Safter/faster homing seems like a niche issue- I have never had any homing issues, and how much time do I actually save if I crank the speed up? A few seconds per print?
The main issue we're solving here is guaranteeing that the switch will never move out of its allowable range when other parameters such as acceleration are changed. For most people the benefit here is likely just never having to think about what number they should put in for homing velocity.
Could you elaborate on the hardware timers? How are these different from the timers that exist in the microcontroller, and what design changes are required in hardware?
Or is your point that the outputs from these timers can't be muxed to the pins that current hardware wires up?
> Or is your point that the outputs from these timers can't be muxed to the pins that current hardware wires up?
This. As far as I'm aware, other boards are just designed in the way that makes the layout easiest. The timers we're using are also fixed to specific pins with no muxxing (HRTIM on the STM32G474 specifically).
I was both excited and disappointed reading the list of hardware features. I, admittedly, have spent the last 6 years working in (not-human-rated) aerospace. Excited because the points you make on the site are definitely things that I've been disappointed to see missing on most existing hardware, and disappointed because... I wish that that list of features wasn't special at all and everyone made more robust hardware like that :)
I'm very curious about the Ada firmware and am hoping I'll have some time around Christmas break to have a dig into it. Last time I did anything with Ada was in grad school about 15 years ago and I loved it; I'm really excited to see what the bridge between Ada and a microcontroller looks like (see above... aerospace!)
The firmware is entirely open source so it should be easy for other companies to port it to their own hardware. The MCU we use is also supported by Klipper and Marlin, so there will not have to be a decision between designing hardware for Prunt or other options. That being said, there is no existing hardware that our firmware can be ported to directly as we make extensive use of hardware timers rather than doing pulse generation/counting in software and 3D printer hardware is not generally designed with this in mind.
It should be reasonably simple to do everything in software if anyone were inclined to do so to support existing boards. Prunt itself is actually a library with a very high level API intended to make it easy to support all sorts of odd hardware: https://github.com/Prunt3D/prunt/blob/6a9dbd0a8d5edd890e4b72...
There is also an example of a very trivial implementation here that just dumps commanded positions to stdout which can be used as a starting point: https://github.com/Prunt3D/prunt_simulator/blob/master/src/p...
> especially since it sounds like the first-class hardware will eventually be much more than $100
The BOM cost is over $100, so this will be the case, however I would like to try and keep the price well under $200 for something similar to the current hardware.
> Adjustable acceleration is already an option on most systems, does editing jerk/snap/crackle actually improve my print quality or just give me more parameters to fiddle with?
In my testing I have seen less resonance artefacts with higher order limits as opposed to just limiting acceleration, however I have not done extensive comparisons to other options such as input shaping.
> Safter/faster homing seems like a niche issue- I have never had any homing issues, and how much time do I actually save if I crank the speed up? A few seconds per print?
The main issue we're solving here is guaranteeing that the switch will never move out of its allowable range when other parameters such as acceleration are changed. For most people the benefit here is likely just never having to think about what number they should put in for homing velocity.