So has of now branch beta.2 support up to 2 dual drive axis with minimal performance loss.
I got the trick for this while thinking about the comment that @jeffeb3 did:
The magic behind this is quite simple. µCNC doesn’t support up to 6 stepper drivers but 8. The extra 2 are actually used as clones of the other 2 (that can be configured) to put the step signal in an extra pin. The “twin” pins can be suppressed independently while performing homing motions (multiplexing). And that’s it. For exemple in a 3 axis X2Y2Z machine you stilll only do the math for 3 stepping pins but output signal in 5 pins.
Also limit switch can be IO overlapped to each other to allow the usage of a pin for self squaring from another axis limit switch.
Yes, looks similar to how grbl ESP32 is implemented. Thanks for your work! I am waiting for a screw shield for my UNO to come in before I test this implementation, but I am very excited to try.
By the way. If the coolant pin can be sacrificed too I believe it can run a self squaring mpcnc (X2Y2Z) @ near 30khz on all 3 axis on an Uno board (still to be tested)
Version beta.2 is out. I would like to make available precompiled versions of the code for ramps and rambo boards (with self-square). Just a couple of questions. In these boards does anyone has the abort/feed hold/cycle start buttons wired? Which pwm output is being used to control the spindle speed/laser?
For the rambo and ramps boards, I believe no such pins are mapped actually. on minirambo, pin44 is mapped for the pwm for lasers. I believe normally that is the pin for the Z max or min or something.
Just an update on the project. Maybe it’s not a usefull feature for V1 machines but I think I have an (untested) version (in the 1.1.0-alpha branch) of µCNC with integrated backlash compensation and skew corretion that can still run inside an arduino UNO . This is still very green and needs to be tested but it’s doable.
I’ve dig some dirt for the last two weeks
Version 1.1.0 is out. It comes with:
Redesigned parser.
New motion planner.
Backlash and skew compensation integrated.
Dynamic Step Spread (similar to Grbl’s AMASS) to spread steps dynamically at lower step rates
Lots of bug fixes from the previous version.
An initial version of HAL for STM3210x has been also released with some limitations (no non volatile memory to store settings). There is a base configuration to run µCNC on an inexpensive 72MHz STM32 ARM Blue Pill board that uses the built in USB has a virtual com port.
There are also some available wiki pages on how to implement custom HAL for µCNC.
If any one could give it a try and find bugs and problems it would be great. Thanks.
awesome, let me see if I can try with the person I sold my grbl machine to. autosquare is a great feature missing from grbl. If I remember correctly, this will take regular grbl gcode, correct?
I don’t know how far back it goes, but the current version of grbl does support auto-squaring. I’m using an older shield that is limited to 3 axes, so I can’t use it, but instructions to set it up are the config.h file.
Yes µCNC works on the same protocol has Grbl with small differences. You can read about the differences in this wiki page. Please let me know what did you found about the firmware and any issues you have encountered. Thanks.
Ok. So this project was kind on the side until a couple of months ago. And I re-pick it up. To help me in the development of this I got my self a laser engraver. Currently I’m working on version 1.2 o µCNC and this is were I’m at now :
This was done on a peace of cardboard.
This version is more of an aproximation to LinuxCNC with kind of a configurable HAL to interconnect internal modules like digital and PWM outputs, digital and analog inputs, encoders, etc…
Lots of ideias…too little time
And it’s out. v1.2.0 has finally seen the light. This is a major revision and it has lots of improvements and new features. The main are:
the new HAL configuration file that introduces a more flexible way to modify the HAL and gives customization power bit more like LinuxCNC.
the addition off new PID and encoder modules to be used by the new HAL config, powered by an internal RTC clock.
integration of tinyUSB, a complete USB stack frame that simplifies the creation of HAL code for new MCU.
the addition of an option for a 16-bit version of the bresenham line algorithm that can improve step rate for weak 8-bit processors or for specific applications like laser engraving.
several revisions, improvements and important bug fixes in the core of µCNC to generate reliable stepping code.
This is now running smoothly on my laser engraver with consistent results.
My plans for now is to keep extending on these new features and try to get my hands on some servo motors with encoders to further explore these type of linear drivers, has well as starting development for the ATSAMD21 MCU (Arduino Zero)
Ok. I’ve been away for this project since August but I’ve pick it up in this week to get things going.
I’m happy to say that version 1.3.alpha (not released yet, it’s just a branch in the project) is running on SAMD21. So it’s possible to grab an Arduino M0 and direct replace the old Arduino UNO running µCNC (or Grbl).
There are still limitations. Non-volatile memory storing (EEPROM settings) is not implemented.
Also input interrupt driven (currently limited to soft pooling but neglectible), analog inputs (not part of the Grbl) are not implemented, and only USB communications are implemented (Serial0 not implemented, but these 2 extra pins can be used for other purposes like an extra stepper axis).
OK SAMD21 now has EEPROM emulated in Flash memory to store settings and Hardware UART is also implemented.
I’ve also developed a new feature that I thing is nice (in test). µCNC will support tool change via T word and M6 mcode (RS274NGC compliant). First implementation is coded but not yet merged.
Let me explain how this works.
You can create/define up to 16 different tools. They can either be different bits on your spindle or switch a spindle with a laser using different (or the same depends on how you implement) it IO from the board. You can customize (to a certain degree) how your tool works.
On tool change you can run custom code to shutdown your previous tool and startup the new tool (this is hardcoded of course).
It’s not super super flexible but is a start and it still runs on old Arduino UNO with little performance loss.
SAMD21 is fully integrated and developed.
It now has a new tool HAL component that allows to add several tool configurations on your board.
And the hole project was restructured so that it can be opened, build and uploaded with Arduino IDE (just like you do with Marlin), although the binaries produced this way are somewhat bigger due to Arduino IDE compilation options. Building via makefile is also still available.
Future roadmap will be to add ESP32 to the hardware options and further develop other modules that are still very raw like encoder and PID modules.
I have been poking around your github page. I have to say you have set up a very nice project. You have included the white papers for some of the equations you use, pinouts…I really hope to give this shot when I have a bit more spare time. Your project has inspired me to, at the least, be more organized and thorough with my own stuff. Oddly I do the same for my hardware projects, but software I am very sloppy and lazy, always in fear of breaking something.
So I guess that is just a long way of saying, I am impressed.
Thanks. It as been a true learning experience. Lots of technical puzzles to solve but an amazing learning experience.
And yes… I break code with some of the changes I perform. It’s dificult to test all of the changes produced by each option. Specially with preprocessor directives that when disabled/enabled can hide a piece of code that was left behind at some point. The other issue is debugging in these architectures altough I’ve made quite the progress recently.
My major problem is testing all the outcomes of all configurations. How all runs against different gcode programas, etc… By myself I can run a few tests, but I run into limitations (diversity of software, gcode programs, available hardware, etc…). The more feedback I have the further I can take this.
Modules like the encoder and the PID are still very raw and some what incomplete but the initial implementation is done. I’m already working on getting those completed. Other things like Plasma Thc like @kd2018 mentioned may be added in a near future too.
. This is still very green and needs to be tested but it’s doable.
:
with little performance loss.
