After much Research on Google and Youtube I found a Pico Tachometer that will do the job, best part is it's in Python so I'm going to have a go at porting it to MMBasic :). I also bought some RC Speed Controllers , They will work just like any servo PWM signal, so Part 2
will be taking the Feedback from the Tachometer and developing the Logic to control the sped of the motor

another interesting project from our favourite Texan !
you may find that the IR detector simply does not work.
That was my experience of them, not
too much crosstalk between RX and Tx, swamped the signal.
suggested solution is a wodge of Bluetack between Rx and TX

That simple type work well inside an enclosure but in the open are affected by ambient light level and confused by 120Hz flicker from mains lighting.

An IR remote receiver has a wide range AGC and a narrow 38kHz filter to eliminate these problems.
Though @DaveJacko,s comment is also relevant, best performance is when there is no direct 38kHz IR from the LED to the receiver.

UPDATE :
I ALSO MADE MADE ANOTHER THING TODAY TO GO WITH THE TACHOMETER, I HAVE A BUNCH OF THESE max7218 LED grids, I figured hoe to use them in Python as Displays ! they are DAISY chain able so I can use 1 fro each Axis and Spindle speed and only use one SPI, if I format the output right :)

I kinda figured I'm gonna have to Machine a Shaft encoder Wheel and use an I/R Pair out of a Mouse and you guys have Made KNOW IT !I'm going to Print a Light cover for the Spindle end, and tomorrow I'm gonna run over to a Buddy's shop and use his big Lathe and mill to make a an encoder Wheel

@ PhenixRising That looks like a cool encoder Cheap I found a Data Sheet here and it Max's out at 5k rpm. So cutting 1/2" Brass @ 760 SFM will give us an RPM of 5810, so I'd have to Gear drive that down 4:1, But I do like that I'm thing of getting a couple they look a LOT more Robust then the Crappy Ones you get from the local Scumbags like Adafruit and Bang good like these:

When it comes to the best possible velocity control, it's all about resolution. The more the better. Gear it down if you like but there's always a huge safety margin on these devices.

The neat thing is that; the PicoMite can keep count of this stuff no sweat, using the PIO counters.

Yeah, the type you show is for panel-mount but the one from AE is intended for machinery-type applications.
Edited 2024-08-16 11:23 by PhenixRising

@ Phenix
sorry for all the Typos in last post but it's hot here and I'm not thinking well, but Yeah Gearing it down is Always a good idea. the 38S6G5-B-G24N is a much more gooder solution for Machinery Exciting News of the day, Just 5 min ago the Amazon Monkey was here with my ESCs (Electronic Speed Controllers) I Wish I knew how to use the Pio counters, I got to figure that out

example code for rotation encoder using PIO (max 4 encoders)

example code PIO quadrature decoder

Volhout
Edited 2024-08-16 16:18 by Volhout

Encoders have two channels, A & B for counting and optionally a third channel I (index) which only pulses once-per-rev.

You will need A & B for the PIO quadrature code. This quadrature-decode multiplies the line-count of the encoder X 4. So a 600-line encoder will produce 2400 counts/rev.

Apart from the 5K RPM limit, there is also the internal circuitry to consider (pulse generation). This device does not feature a line-driver output so you might not want to push it. For best reliability, I would select a low line-count model.

The Pico-PIO can handle ridiculously high frequencies so no problem there but I wouldn't unnecessarily push the encoder's output circuitry.

The PIO/state-machine code is very cool as it runs independently of your MMBasic program. It's possible to stop or even exit your program and the state-machines continue to run    

Do you intend to control the motor velocity or simply display it?

If you intend to close the velocity-loop, be aware that the counter has a 32bit limit and in this continuous-rotation application, you need to be aware of rollover possibility (not probability). It's just good practice to include some form of handling.

Say, for example, you went with the 360-line encoder (with a rotary axis, it's a good idea but not essential to have a resolution that is divisible by 360). This results in a quadrature decode of 1440 counts/rev.

5K RPM = 5000 X 1440 = 7.2 million counts/minute so it will be a while before you max-out 32bits and hit the rollover but letting it happen could be quite spectacular  

  PhenixRising said  

Encoders have two channels, A & B for counting and optionally a third channel I (index) which only pulses once-per-rev.

You will need A & B for the PIO quadrature code. This quadrature-decode multiplies the line-count of the encoder X 4. So a 600-line encoder will produce 2400 counts/rev.

Apart from the 5K RPM limit, there is also the internal circuitry to consider (pulse generation). This device does not feature a line-driver output so you might not want to push it. For best reliability, I would select a low line-count model.

The Pico-PIO can handle ridiculously high frequencies so no problem there but I wouldn't unnecessarily push the encoder's output circuitry.

The PIO/state-machine code is very cool as it runs independently of your MMBasic program. It's possible to stop or even exit your program and the state-machines continue to run    

Do you intend to control the motor velocity or simply display it?

If you intend to close the velocity-loop, be aware that the counter has a 32bit limit and in this continuous-rotation application, you need to be aware of rollover possibility (not probability). It's just good practice to include some form of handling.



Say, for example, you went with the 360-line encoder (with a rotary axis, it's a good idea but not essential to have a resolution that is divisible by 360). This results in a quadrature decode of 1440 counts/rev.

5K RPM = 5000 X 1440 = 7.2 million counts/minute so it will be a while before you max-out 32bits and hit the rollover but letting it happen could be quite spectacular  

I just want count and save for each individual lath axis cut ie (((10,000 counts for first cut, counted and saved) then next cut counted, say 200,000 counts, counted and saved) and then the next cut counted and saved) and so on until all cuts are finished.
I have the Raspberry PI Pico (2020).
Regards Allie

Yup, it's right there and furthermore, Harm (Volhout) included functions to reset the counter to zero and one to preset the counter to any value.

My encoders feature the index pulse for precise referencing. I use this to trigger a regular input interrupt and it works absolutely consistently.

Mind boggling how this piece of PIO code outperforms specialised commercial devices. 😁😎👍