My Compass CNC can now measure the Z axis itself
It is still possible to set Z yourself and confirm with the encoder, but if L+R is held down on the same screen, it automatically moves to the material and uses StallGuard to detect when the tool touches the material. I wouldnât do this with sensitive milling cutters.
The right button or the encoder can be used to set the 0 position, or the right button can be used to return to manual zeroing.
So far, it works very well with the dummy router bit.
I need to test it with real material.
I still have a few ideas on my to-do list, but before I can tackle them, we/I need to standardize the GUI. Unfortunately, TcMenu is too powerful, and GEM doesnât really fit with a round screen. Weâll probably have to build something ourselves.
I created a draft PR, because it is only LAB tested
I made it with Uart. No change to wiring required.
I had two problems, reading between the steps was too slow, I control the stepper motor with an interrupt timer for the reference run.
And the examples on the web are almost all wrong. The TMC2209 needs stealthchop to make stallguard work.
Woooo that looks great!! Canât wait to pull that branch and try it. I love the way you incorporate the LR buttons to allow for manual Z probing as well.
Interestinggg. I have been considering moving the steppers to interrupts for standard runtime as well (for the same reason to make steps faster), but I have very little experience with interrupts. Do you see any immediate problems with using this same implementation alongside sensing and controls? I know grblHAL and some other gCode interpreters put the steppers on interrupts, but they also donât necessarily have feedback in between the planning and actuation stages.
I totally agree. The current GUI is very barebones and the result of me doing the minimum viable product to get it working. As such the architecture is pretty unintuitive and not very well organized. Iâd be happy to do a little brainstorm session to get something better going.
Iâm not really an expert when it comes to interrupts either. The stepper is just super slow when I read the registers via UART because the process causes the motor to pause. With an interrupt, that doesnât happen.
In principle, the stepper motors should run much more accurately because the timing is better, but I have no idea how that might affect the sensing. It doesnât matter for the touch.
I would be super interested in integrating that. I looked into it briefly a while ago, but it wasnât a high enough priority to implement at that time. It seems like a pretty solid library
I stumbled on this thread a while ago while exploring different stepper libraries. The author made a nice little comparison table of different libraries:
Seems like fastAccelStepper could be a nice option too. The one thing about TeensyStep4 is that it doesnât seem very well documented/tested
Writing low level code for timers is also generally not very difficult - it could be trivial to create an interrupt-driven step generator without any additional library, and would give you a lot of flexibility in how the planning/ action get meshed together.
As I mentioned elsewhere Iâm playing with an esp32 port, leaving a high level API here would be useful (something like âstep Z N stepsâ) rather than something closer to the hardware which might be more âswitch direction pin 4, load timer 6 with Nâ, or queuing a request to do that if the timer is already stepping
Super valid. Thatâs pretty essential. I would hate my life trying to code something like âswitch direction pin 4, load timer 6 with Nâ as well I love high level stuff
We should decide on one microcontroller. We need quasi real-time, the current code looks like nothing, especially with the use of the various libs, but I am sure that the current results are only achieved at all thanks to the extremely fast CPU and the serial buffer of the Teensy. AccelStepper delivers fast results, runs on almost everything, but unfortunately it is not a clean control. The same applies to the PWM3360 Lib, where the burst could also be transferred to the Teensy via DMA.
Of course you can also create a good level of abstraction for interupt and DMA-based controls, but at the lowest level you should get everything out of the microcontroller that it can do and not just use what they all have in common and only let the CPU doeing it stuff.
Agreed, it would be great to decide on a more long-term microcontroller. I originally went with the Teensy because I have used it before and I wanted to make sure Iâd have adequate speed and memory. That allowed me to admittedly be more crass with some of the code on first pass.
@matei is exploring STM32 integration. Iâm also a bit partial towards ESP32 since Iâve worked with them before, they have integrated WiFi, and are being used on quite a few notable CNC projects (V1 obviously, then also FluidNC, Maslow, etc). Any particular bias @IceOnly ?
Also I mentioned this somewhere else, but it seems worthwhile to re-state: it might make sense to integrate into grblHAL with a plugin or fork at some point. This would probably be more long term, but I think itâs a good thing to keep in mind before putting a significant amount of time towards polishing the Compass firmware when a lot of the features have already been developed very well elsewhere. Not locked into that, though, just something to consider. Iâd be curious to hear thoughts on that
Wait, couldnât we use this for edge finding as well?
Move the compass to just over the edge of the material, then have it gently plunge the bit (stop if it detects if there is material underneath), and have it gently move to the edge and when sensing motor stall note that position. Then do that 2 more times for the other edges and you should have a plane where you can do absolute positioning on right?
I love high level stuff