11–14 of 14 posts
Author should check out http://camotics.org/ It's an Opens-Source 3-axis CNC simulator that runs on Mac, Windows and Linux. It not only shows you a visualization of the tool paths but also the resulting cut workpiece. Disclaimer, I'm the author of CAMotics.
On the topic of safe languages on embedded systems, I'm very excited for the future of Rust on micros. Having just recently spent probably in excess of 100 hours on an embedded systems project at university, I'm starting to get a bit annoyed with using embedded C. I'm sure good software engineering practices would eliminate a lot of my problems, but being the only computer scientist in a group of electrical engineer…
You many want to reconsider your career path, then. Because I've been working on embedded systems for a long time now and it's always been embedded C. And it's looking like it's going to be that way for a long time to come. If you're using a kernel like Linux or FreeRTOS, even moreso.
The entire project is just a massive mess of cascading makefiles and #defines, and is amazingly poorly documented.
Again, welcome to embedded systems engineering. Enjoy your stay.
Some questions come to mind: - Can it not accelerate smoothly? The graph on the page seems to imply that. - Also on that graph, the relation between distance and speed on accelerated parts appears to be linear, but, if this is supposed to approximate constant acceleration, the relation between distance and speed squared would be linear (v^2=v0^2+2ad). - Why did they need to develop that GUI, when there's existing sof…
- The software architecture is inspired by GRBL. The split of motion blocks into segments is more manageable for the software, and if you choose a segments size small enough, the acceleration will be very smooth.
- I do not try to approximate constant acceleration.
- The GUI is a way for me to test the Gcode and stepper algorithms (the code is the same in the GUI and in the embedded controller).
Please also comment directly on the post.