Magnetic Encoders

[Faceting Frank]

Been experimenting with the consistency of the lights coming on with my encoder setup, using my dial gauge as a test. The dial gauge lever is as long as practical on my machine and is 65mm from the quill pivot shaft to the gauge plunger. Very sensitive to flutter, but great for slow lap speed depth of cut setting.
Using a stationary lap and adjusting the mast height to move the gauge. The lights would come on to an accuracy of about 0.005mm on the gauge, that surprised me. Thinking more about it though, the point the encoder changes from say 5967 to 5968 would always be in the same place, even though that is a 0.018 deg movement.
Have managed to keep the lap flutter on my 600 and 1200 laps down to about 0.03mm on the dial gauge. Not counting side to side variations.
If I change the loop millis delay to 10 and add 10 encoder readings together, divide by 10 and process the result ever 100ms. It should eliminate any variations caused by lap flutter.
I think I have to have a measurable delay MB for any averaging to work.

[Nerb]

Only problem with no delay is no use having 0.01 resolution since the minor digit is a blur even with averaging slightly slowing the readings. Which is why the minor digit was deleted for the moment in my code. I'm running a device that has little load so response is instant and slight movements are displayed. Thus the need to do something to slow the reading down to an acceptable level. But at the same time not have drastic differences between so it does not go 50.32 , 53.54 etc instead counts up to that reading. If I use the millis() function I get jumps. I'm figuring somewhere in there is an acceptable balance between amount of averages and millis()  and buffer that will hold the hundredths and tenths  scale movement down and still allow acceptable rates of changes. I tried slowing display refresh down and that has the exact same effect as millis() as far as effect on the counter with the added annoyance of visible refresh.

[MakkyBrown]

I have some flutter on mine but I use it by cutting to the point of no flutter/a stable reading first occurring. I think this is a very accurate stop.Averaging might be making it less accurate. I am also displaying an extra digit(xx.xxx) as my encoder steps are 0.018 and I would not round them as the accuracy is needed imo.
MB

[Faceting Frank]

I don’t have a TFT screen, so digital flutter is not a problem as the text is so small, hence the lights as stops.
IF I had a TFT screen, I would be thinking of having a sliding bar or dial to show me my progress towards the target angle and keep the digital display on a 100ms or more millis delay.

[MakkyBrown]

i'm using one of these on my current box but would not buy anymore of them as the tft's are far better value.https://www.ebay.com.au/itm/356539232312?_skw=128x64+screen+lcd&itmmeta=01JKTAAWXSF8RR2KG7RVFH1ZMF&hash=item530364f038:g:FOgAAeSwa-dnpCRM&itmprp=enc%3AAQAKAAAA0FkggFvd1GGDu0w3yXCmi1co73%2FBhQmYjHFoE4qD2Od%2BsD1yo9AZDV3oEL1bYkokDES1zjA75%2FQO1bnebSmbk5%2BJkCcBpH%2FQ7%2BULfgLzkGfCm0J6eZaDESwjhs%2BmlBX%2FfACvsmBiWn2%2FuW%2FWX%2FuHEVX0QOnAhf5Oe30K9tav%2FkYwwcjhasGvM3jmkM%2Fdcs%2FaMvWVB3D0j%2BTPz6DSn5tg0l5a7hR5KDtGU79wnvYOF5LaFUmLG7gDR0TSyI0NRf75kBJ5U%2FpIrxJpB8LMEmjNr5I%3D%7Ctkp%3ABk9SR4jPq8qeZQ

[Nerb]

One of the big differences between the encoder you are using and mine is the magnet position varies the X and Y readings. A magnet not perfectly centered over the chips sensor region will not give the expected next step reading as the magnet rotates if it is not perfectly centered. Which is why I planned on doing multiple averages to account for the magnet being off slightly center during rotation.

Instead I will spend the time to make certain the magnet is as close to on center as possible. And the housing holding the encoder chip placed is exactly over it.
So the 3d parts I originally planned on using to hold the magnet during gluing and the housing for the circuit board probably will not work. I do not own a SLA printer so I'll have a friend print parts and see if they are any better. If not time to send them to a machine shop.

The ones in my test protractor are very close to center but I can see the unexpected changes as it rotates. I may still need to do the 10 readings but will see. My change last night to the pgm was 5 readings 10 milisec apart averaged and send to the buffer which now holds 10 readings. The buffer is now averaged and displays constantly. That way it smooths out rapid changes and 10 milisec apart with buffer averaging  is not choppy. Still testing and may change that.

I am looking at angle calibration code ideas too to see if they can be applied to my application.

[Nerb]

Got an answer back from Olaf at Infineon after I tried yet another email asking what I am doing wrong.
He is sending me a magnet and told me to throw the one I have away. I bought a real chip but the company I bought from did not sell the special magnets so I ordered 5 from a company in China. He verified I have the magnet within the chips sensor so the odd readings are due to the magnet itself. It is the correct type but the field lines are not the same strength  at each pole.

So I'll wait for the magnet.

[Faceting Frank]

Thought you were using a TFT screen MB. Problem with them for a total beginner is that the You Tube tutorials on basic programming don’t use them and just use LED screens. Probably plenty of vids out there for experienced programmers on using TFT screens. I still have the TFT screen you recommended when I first started with my encoder and my current setup is all wired to the box lid. So, I could make a new setup with the TFT screen on a new lid and swap them over.
If I made that then the main visual part to watch would be a dial or sliding bar showing the progress toward the target angle, the angle shown on the screen would have it’s own millis() delay to stop flutter.

[Nerb]

If it is like mine it uses  SPI  for the display and  I2C for the touchscreen. I am familiar with both but never used both in the same pgm before. So my touch screen for now is a little button that does nothing but display it was pressed. Just to see if I could even get them to work together. My encoder chip also uses SPI so it was interesting having 2 slaves communicating with the esp32. If yours can use the Adafruit libraries  it makes coding them a lot easier. Unfortunately I could not so a lot of reinventing the wheel is going on here.

Also the method I mentioned seems to work at lowering flutter.
5 reads timed 10 milisec apart averaged then sent to the buffer where the oldest falls off.
The buffer is averaged and displayed constantly.
I might add more reads as it still has some flutter but will wait until I have it on the Facetron 
It did help slow the constant movement of the hundredth scale.

[MakkyBrown]

Been meaning use the TFT, I did get one going as part of my new machine built but that is collecting dust atm. I have a bit going on, tricky finding time. When I do I might steal RC code.

[Faceting Frank]

I only have the display showing 2 decimal places Nerd with a 100 millis() delay in the entire loop, so flutter is not a problem. I don’t bother looking at the display anyway, just the lights. After setting the target angle I lower the mast height as the facet is being cut as you normally would, with the green light coming on 0.04deg before the target angle and the red light at the target angle.

But I need to do what you’re doing with the averaging, so the lights come on at the average reading of the lap flutter.

[RoughCreations]

Been meaning use the TFT, I did get one going as part of my new machine built but that is collecting dust atm. I have a bit going on, tricky finding time. When I do I might steal RC code.

Yes, same here, my new box project stalled a bit, but I am slowly progressing. I might put my code up somewhere to share, it's nothing brilliant but I found I had to use Sprites to do everything with the display, as I would get massive flickering otherwise. The learning curve is steep if you have to start at square one with the TFT_eSPI Library.

RC

[RoughCreations]

I only have the display showing 2 decimal places Nerd with a 100 millis() delay in the entire loop, so flutter is not a problem. I don’t bother looking at the display anyway, just the lights. After setting the target angle I lower the mast height as the facet is being cut as you normally would, with the green light coming on 0.04deg before the target angle and the red light at the target angle.

But I need to do what you’re doing with the averaging, so the lights come on at the average reading of the lap flutter.

Best way I found was to use a long Array of encoder readings. Each loop you add a new reading to your Array, and drop the oldest one off. Each loop you display the Moving Average which is just the sum of your 20 array elements divided by 20 (for an array of 20 elements).
I reckon you have room down the bottom of your LCD screen for a simple progress meter there Frank..

RC

[Faceting Frank]

A progress meter is an interesting idea RC, though it's not going to be very long. The distance between my red and green light is 0.04deg, because the 0.018deg per step gets rounded up or down, that may be only 2 steps.

[RoughCreations]

Mine's not very long either, it has a max of 19 squares in a long frame of 1 pixel width, and each progress square is 6 pixels by 6 pixels from memory for the 128 x 64 dimensions of the screen. The way I use it is linear and pretty standard, each progress square represents 0.018 degrees, so when the progress bar is at a maximum there is 0.342 degrees still to go. If I did it again I would put the target angle in the middle of the bar with some sort of tick mark. Then when you are adjusting your height to a specific angle you can tell what side of the angle you are on - if you get what I mean.