3 ms·

Some thoughts: 1. It looks like you're selling hardware to go along with the firmware, which seems like it has nice features but also seems like it will be exp

by parsimo2010 2y ago

Some thoughts: 1. It looks like you're selling hardware to go along with the firmware, which seems like it has nice features but also seems like it will be expensive. Sometimes the presence of first-class hardware results in other hardware being treated as "second-class" and results in limited adoption, especially since it sounds like the first-class hardware will eventually be much more than $100. (another hobbyist community, the FPV drone community, has shown this with FETtec brand having their own KISS firmware which is basically only used by them, and almost everyone else uses another alternative). You should care about limited adoption because that means a smaller number of outside contributors to your project. 2. You list that Prunt has features not available on other systems, which is nice, but it is not obvious how this will affect print quality/speed/accuracy, which I think are the primary concerns of most users. a. 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? I say this because Klipper is fairly impressive, and it would be nice to see some examples of how much extra motion terms improves a print. b. Editing pinouts is a one-time thing and not an issue on common boards, so this is a limited benefit when you already need to be technically savvy to be building or modifying a 3D printer. c. 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? I guess I should add- good luck! The 3D printing community will certainly benefit from more ideas and development effort.

LiamPowell 2y ago
> 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/6a9dbd0a8d5edd890e4b726935c308f9a0ff8060/src/prunt-controller.ads#L37-L157 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/prunt_simulator.adb 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.
- axoltl 2y ago
  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?
  - LiamPowell 2y ago
    > 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).
    - tonyarkles 2y ago
      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!)
      - LiamPowell 2y ago
        > what the bridge between Ada and a microcontroller looks like At a high level, we're just putting records with representation clauses directly on to a UART: https://github.com/Prunt3D/prunt_board_2_software/blob/master/shared/src/messages.ads https://github.com/Prunt3D/prunt_board_2_software/blob/maste...

LiamPowell 2y ago

> 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/6a9dbd0a8d5edd890e4b726935c308f9a0ff8060/src/prunt-controller.ads#L37-L157 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/prunt_simulator.adb 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.

axoltl 2y ago
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?
- LiamPowell 2y ago
  > 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).
  - tonyarkles 2y ago
    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!)
    - LiamPowell 2y ago
      > what the bridge between Ada and a microcontroller looks like At a high level, we're just putting records with representation clauses directly on to a UART: https://github.com/Prunt3D/prunt_board_2_software/blob/master/shared/src/messages.ads https://github.com/Prunt3D/prunt_board_2_software/blob/maste...