Unfortunately I haven’t had the chance to implement the Marlin side of things yet.
And like I said in a previous post above I have been tinkering with the original code to suit what I wanted so it’s entirely possible that this issue is something I’ve caused. The only reason I mentioned my filtering is because it sounded like Alec was having a similar issue.
Just don’t want you to follow me down my own rabbit hole if it is something on my end lol.
I’m happy to try and improve the code any way I can, I’m actually still holding out hoping for you to post your branch up on github lol.
Hey if it works who cares if it’s the most elegant!
I had tried doing something similar (lazier, is that a word?) but like I had mentioned I rewrote the code so the variables probably don’t transfer exactly. For reference it was something along the lines of this:
if (CalculatedRPM > LastRPM*1.2) {
CalculatedRPM = LastRPM;
}
But that seemed to be too broad of a filter because it would do sometimes get stuck when starting up.
Yours seems like a good solution though, I will give it a shot when I get a chance.
To chime into this, your description in your above posts are pretty much identical to the issues I’ve had, with it suddenly getting a super “fast” reading and then the PID causing the router to dip down and climb back up again–very jerky response.
I think I also mentioned above that I was concerned it might be an issue with interrupts screwing up the calculations so I rewrote the code using hardware timer counters to do the frequency measurement (i.e. no external interrupt to disrupt the calculation) and the behavior was identical. So I think I’m a pretty firm believer that it’s actually noise in the hardware, but I’ve been wrong many times before so who knows.
Maybe consider using the target rpm (though I don’t believe this is calculated in the current code) instead of lastrpm.
Okay, here’s my work in progress. Anyone who wants to use it will have to make hardware changes to their setup if they are currently using the vanilla version. It requires 2 push buttons, a potentiometer, and a 20x4 LCD screen. There are some pins set to supply 5v or ground for the buttons and POT in this code which you can comment out if you so desire. They are there to make my perfboard easier to make (or because I’m lazy).
I have not tried the Marlin input mode yet as I have not tackled getting a pwm signal to the board from my SKR 1.3. So if anyone does try this out, do let me know if there are any issues.
I have not tried the Marlin input mode yet as I have not tackled getting a pwm signal to the board from my SKR 1.3. So if anyone does try this out, do let me know if there are any issues.
I used the servo pin for pwm and the th1 (bottom of the board next to the aux-1 connector) pin for enable, the relevant define lines are:
#define SPINDLE_LASER_ENA_PIN P0_25
#define SPINDLE_LASER_PWM_PIN P2_00
I believe that goes inConfiguration_adv.h (i’m using a slightly modified build so it might belong in your relevant pins file).
the MAX_PWM_INPUT_US will be wrong, thats what my pr is for, it adds an autodetect.
Awesome. When I get the chance to tinker with it again I will try this! Thanks
Still just a wee bit beyond me right now, but I’m also still reading and trying to learn. Thanks everyone!
Primo convinced me to read through all of this again. I think that’s 4 times now, and I’m pretty sure I thought this was more complex than I think now. Well, the minimum route, anyway.
Can anyone tell me if I have this correct, at least for one potential solution?
Aquire kit from Ryan, printed parts, nano, and a breadboard or similar. Power cord from wall to ac dimmer board then to dewalt. Wires from nano to sensor on dewalt. 5v from control board to nano. Two buttons, an lcd, and a pot to the nano. Tyler’s work (thanks dude, that looks great!).
If that’s really all it is, I think I can handle it.
I think you missed the 5V, GND, and PWM signal from Nano to Dimmer board.
When you get this all together and working, i’ll PM you my shipping address. 
Tough call on all of this. It works, it actually works great. Adding a RPM “wobble” would help with some chatter, but something like the makita rt700 has a real decent speed control built in. I love the 660 but this sort of seems like there are other ways to approach the problem.
So I would say pursue this for the fun of it, but not necessarily the utility of it.
If only I had gotten the makita instead of the 611! Dang it for wanting the lowrider first, lol!
I think for my use case on this, I won’t be pushing it so hard that chatter will be the issue. I just want to be able to set the rpms and have it be reasonably close without too much deviation. This one will be all wood and foam. I’m certain that my 611 isn’t closer than a couple 1000rpm from where I want it because I hardly ever tach it anymore. The reflective tape keeps flying off and it’s a pita.
If I find myself needing better speed control, maybe at that point just start looking for spindles that include it or even the super pid. It apparently works very well with the 660, although it’s not clear to me why that would work better than this.
Thanks, though, for all the hard work and for tempering my expectations.
The 611 speed control is really good as well, as long as you are not running it full speed, and clock it under load. Stable.
High speed spindles and the speed control under light loads is not as exacting in it’s needs compared to extremely low RPM and high load commercial machines.
Not sure exactly why you need it so exact but my code and electronics work perfectly as is and are very cheap, all this new stuff you guys are talking about I am not sure. I use mine as is just fine, speed control through gcode. As best as I can tell very accurate. I just stopped using it as much because I can dial it in by ear and eye just as good while it is running with a speed control.
That’s actually what I’m saying, I don’t think i will. I set the 611 close enough and I’m happy. My motivation is using the 660 on my new primo build because you recommend it so highly and because it’s laying around. Upside, it let’s me have a palm router(my second 611) in the toolbox instead of the machine. I’ll probably throw the 611 in it anyway, so I can muck around with the 660 on the bench.
The only reason I want the control is that I’m not really good at judging what’s happening by ear. I think I’m doing good then BAM smoked a mill. I calculate my feeds from the chip load and adjust those based on how the job comes out and the MRR. Stuff I can write down is good for me. Stuff I have to remember or decide on the fly not so much. I can do it, but my consistency is no good.
I’ll look again for how you have everything connected without Tyler’s mods. I’m great with that, too. I just had the impression that it would easier/simpler to set up the controller to be dumb, just needing input from me before starting the job.
And let’s not forget: it’s pretty amazing to me that I’m even trying to follow along here. 40 years old and I’d never even SEEN an arduino before I got started with the MPCNC. Just trying to figure out where I’ve overcomplicated things in my head. Really, if I get the stuff and put it in front of me, it’ll probably be obvious.
Take your time, this is a very complex add on. Simple…yet complicated.
Using it is nice but you have to decide on a RPM either way, I do it in Gcode/estlcam with the screen you can change or set it (note really sure).
You have to be careful with cut calculators. I am not finding any that give me really good settings. I rely solely on test cuts. once you have a decent cut write down all your settings…then you have to deal with things like dull cutters on the fly.
I tried the gwizard but I couldn’t even figure out what it was telling me, lol.
I calculate everything in a spreadsheet for myself.
i found this AC dimmer for cheap, handles at least 6 A (triac is rated to 15A) PWM controlled, seems to be comparable to the one that you sell, just curious if anyone sees any issues with it.
That might work but not with the code I wrote, I am not sure what you would do with the zero crossing pin. From what I understand from the description you are offloading the work to the arduino, where the one I use is all on the dimmer board (attiny). Meaning we feed it a desired speed my board knows when to change it, that one relies on the arduino to read it and then change it. Not sure what else might be a down side of that maybe total speed, wire length/interference?