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?
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.
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'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!)
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/maste...
I don't see a reference to the term on your website and when I looked it up on Google this post was the top hit. I also found this paper [1], is this what you're talking about? https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=883...
Is your 5th-order model derived from something like that? Or was it more of a "everything is really smooth if we have bounded crackle" kind of situation? Either way I'm really happy to see higher-order motion control coming to open-source firmware like this that doesn't require a host like Klipper does.
Edit: yes, apparently it is :D
After that it goes drop, lock, slam, thump
Klipper and Marlin do support circular arcs if they are added to the g-code by the user, but these are not quite as good as our corners as they have infinite axial jerk at the point where the arc meets a straight line, as shown in the below images:
Circular corner blending: https://prunt3d.com/images/circle_corner/
Ours: https://prunt3d.com/images/prunt_corner/
I should also note before someone else does that technically infinite pop makes our corners physically impossible too, however at the 6th derivative of position it really ceases to matter in practice.
Changing velocity too much has its own impacts on surface quality, that can be larger than moving off the toolpath by a small distance.
G-code / RS-274 is an industry standard far beyond 3d printing and this behavior is pretty standard for controllers/implementers at this point.
There is an "exact stop" mode G61 in RS-274, but it's not often used, instead of the G64 "path blending" mode. There are also extensions that I think are pseudo-standard, like G64 Px.xx lets you set a tolerance value in many controllers.
If your machine is physically accurate to X under perfect, slow conditions, you don't lose anything by telling it to blend paths to a tolerance of 2X during periods of high acceleration.
1. GCC has built-in dimensional analysis, which has saved me from errors that would have otherwise taken hours to track down or may have just gone unnoticed multiple times. As an example of this, there's a transcription error in the below code:
https://prunt3d.com/images/hn_dimensional_analysis_1.png
This line caused a compiler error that made it trivial to track down:
https://prunt3d.com/images/hn_dimensional_analysis_2.png
https://prunt3d.com/images/hn_dimensional_analysis_3.png
2. Intertask communication in Ada is nicer to work with than any other language I am familiar with, making it easy to make both the host and MCU software multithreaded: https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Devel...
3. On the firmware side on things, Ada supports preemptive multitasking and exceptions with full tracebacks on small MCUs, which made firmware development much easier. Having preconditions that throw exceptions on procedures for controlling peripherals prevents a few hard to debug issues.
4. Someone already ported Adacore's embedded runtime to the MCU we use, so that was less work for me: https://github.com/JCGobbi/Nucleo-STM32G474RE
5. Ada supports defining the exact layout of types rather than having to rely on something like protobuf to get messages between the host and the MCU. I can just set the fields in these records and stream the bytes over a UART without any extra (de)serialisation: https://github.com/Prunt3D/prunt_board_2_software/blob/maste...
> Access denied > The owner of this website (prunt3d.com) does not allow hotlinking to that resource (/images/hn_dimensional_analysis_2.png).
(use-package ada-mode)
(add-hook 'ada-mode-hook #'lsp! 'append)
(setq-default ada-xref-backend 'eglot)
(setq-default ada-diagnostics-backend 'eglot)
(add-hook 'ada-mode-hook (lambda () (set (make-local-variable 'comment-start) "-- ")))
(custom-set-variables
'(ada-fill-comment-prefix #("-- " 0 2 (syntax-table (11))))
'(wisi-size-threshold 2))
((ada-mode . ((eglot-workspace-configuration . (:ada
(:projectFile "AAA.gpr")))
(tab-width . 3)
(fill-column . 119)
(indent-tabs-mode . nil))))link rel="canonical" href="https://600f3559.prunt-docs.pages.dev/" itemprop="url"