An Electronic Lead Screw controller using a Teensy 4.1

[WobblyHand]

This is true but the math conversion uses the micron value for displacement measurements, converting to inch at the UI. There is a bobble in the display but it will be limited to +/- 2.5 microns or .0001" in the reported position for the 5 micron scales.

My mill has 5 micron scales and reads accurately within +/-.0001" over a 6" distance, my calibration distance.

I think actually the error is +/- 0.0005" between the true distance and the rounded to 4 places value. I get a max error of +0.496 tenths and a min error of -0.496 tenths in the interval between 0 and 5.9998" inclusive. That's pretty good.

For the absolute geeks on HM, here is the python3 code I used. I cheated and used numpy because it uses array methods like matlab. More compact code.

#!/usr/bin/env python3
"""
Find the minimum and maximum error in tenths due to display rounding of metric
scale.
"""

from numpy import arange, around, amax, amin

scalediv = 5      # scale native resolution in um
aa = (scalediv * 0.001)/25.4   # 5um scale resolution converted to inch
rndidx = 4        # will round to this number of places

x = arange(30480) # 30480 = 6*25.4/0.005. x is an array of integers, eg. 0,1,2,... 30479

truedist = aa * x # true distance discrete values from 0 to 6 inches
rnddist = around( truedist, rndidx)  # round every element of truedist to rndidx places

maxerr = amax( truedist-rnddist )*1e4 # find max error in tenths
minerr = amin( truedist-rnddist )*1e4 # find min error in tenths

print("Native scale division = ", scalediv, "um")
print("maximum error is = ", maxerr, "tenths")
print("minimum error is = ", minerr, "tenths")

Output of code is:

In [42]: run scale_rounding_error.py
Native scale division =  5 um
maximum error is =  0.4960629921324511 tenths
minimum error is =  -0.4960629921259632 tenths

 

[dkemppai]

My display could show 4 places (or more if I choose) and round or it could truncate, my choice. On this lathe, having the extra decimal reading in tenths would be swell. No matter what scale you choose, there always is this problem of apparent non-linearity when you switch from the non-native setting.

5um scale, converted to inches, rounding to 4 places

[0.    , 0.0002, 0.0004, 0.0006, 0.0008, 0.001 , 0.0012, 0.0014,
       0.0016, 0.0018, 0.002 , 0.0022, 0.0024, 0.0026, 0.0028, 0.003 ,
       0.0031, 0.0033, 0.0035, 0.0037, 0.0039, 0.0041, 0.0043, 0.0045,
       0.0047, 0.0049, 0.0051, 0.0053, 0.0055, 0.0057, 0.0059, 0.0061,
       0.0063, 0.0065, 0.0067, 0.0069, 0.0071, 0.0073, 0.0075, 0.0077,
       0.0079, 0.0081, 0.0083, 0.0085, 0.0087, 0.0089, 0.0091, 0.0093,
       0.0094, 0.0096, 0.0098, 0.01  , 0.0102, 0.0104, 0.0106, 0.0108,
       0.011 , 0.0112, 0.0114, 0.0116, 0.0118, 0.012 , 0.0122, 0.0124,
       0.0126, 0.0128, 0.013 , 0.0132, 0.0134, 0.0136, 0.0138, 0.014 ,
       0.0142, 0.0144, 0.0146, 0.0148, 0.015 , 0.0152, 0.0154, 0.0156,
       0.0157, 0.0159, 0.0161, 0.0163, 0.0165, 0.0167, 0.0169, 0.0171,
       0.0173, 0.0175, 0.0177, 0.0179, 0.0181, 0.0183, 0.0185, 0.0187,
       0.0189, 0.0191, 0.0193, 0.0195, 0.0197]

They all look kind poor, if you ask me. Non native scales will always look bad in the other measurement system. If I could reliably hit within 3/10ths, that would be pretty good.

Actually, if you study the numbers between 1um converted to inches and displayed at 4dp, every increment in the display is a single digit of .0001". There may be three or four of them in a row, but what the user sees is a change of a single digit.

The problem with 5uM converted to inches and displayed in tenths, is numbers jump 2 most of the time. You don't think that's a problem, until the rounding error catches up and and the jump is a single digit (.0030 to .0031 above). As a user having the display switch between even and odd numbers is a problem. It's just painful to watch while dialing in a value. I don't know why, but it slows things down, and is very disconcerting to look at on the screen. Spend some time behind a cheap Chinese DRO display, and you'll know exactly what I mean.

You would be much better off rounding the 5um scale to 5 tenths, like micrometers do. The perceived jumps are then uniform in spacing again, and much easier to work with. 1um rounding to 10ths is just fine too. In native scale resolutions, use as many digits as you like.

My $0.02

 

[Karl_T]

Say, non programmer here.

Is this project any where near being able to sell parts to me and have a running unit? Do not mind a lot of mechanical installation.

 

[dkemppai]

You would be much better off rounding the 5um scale to 5 tenths, like micrometers do. The perceived jumps are then uniform in spacing again, and much easier to work with. 1um rounding to 10ths is just fine too. In native scale resolutions, use as many digits as you like.

My $0.02

Looking at some numbers, I'll update my recommendation. If you mround() the value to .0002" for a 5um scale, I would prefer that much better than .0001". Every increment is exactly .0002", and error is still only half of the displayed value maximum.

 

[WobblyHand]

Say, non programmer here.

Is this project any where near being able to sell parts to me and have a running unit? Do not mind a lot of mechanical installation.

A good question. I have no doubt that the existing setup would work. I do have spare parts, to make up more controller boards. However, I have not established a cost model for either hardware, software or service. In my opinion, the value is in the software, rather than the hardware. The hardware I have is pretty simple and easy to duplicate. But it's tough to get people to cough up cash for software. And software is hard to protect from theft. Think I spent all together, maybe two weeks on hardware, about fifteen weeks on software, and three to four weeks on fabricating and mounting parts. Beats me how to make either a main or side gig out of this.

That being said, I might be up for practically giving one away, perhaps as an early adopter. Gives me feedback on what if anything needs to be changed.

I have to think about it. There are still some things that I'd like to fix. Some are not related to function, but they would make for a better user experience. Others would help mitigate user assembly errors. And some additional features. The latter two would require a re-spin of my board.

 

[Karl_T]

Keep me in mind when you are ready. I am not a cheap skate and do not expect you to work for free.

 

[WobblyHand]

Keep me in mind when you are ready. I am not a cheap skate and do not expect you to work for free.

Thanks Karl. I never wished to imply you or anyone else is a cheap skate. Honestly don't know how to value this. I'd like to be fair, and make some pin money to be able to do a few more things like this. I will let you know when this is "releasable".

What kind of setup are you thinking of? Just a controller, or a kit, or a shopping list or? How much in the way of instructions do you need? It would be helpful to know, so I have a better idea of what kinds of documentation to produce. We all have different backgrounds, so it is hard to gauge what is necessary and helpful.

 

[Karl_T]

My thinking - similar to buying a DRO.

Its all ready to go, but will need user supplied custom brackets, pulleys etc to mount the servo motor and other items. The wiring all just plugs in.

Then software parameter setup for the specific installation. Again, just like the DRO packages do it. Will need a good online manual for this part.

 

[WobblyHand]

My thinking - similar to buying a DRO.

Its all ready to go, but will need user supplied custom brackets, pulleys etc to mount the servo motor and other items. The wiring all just plugs in.

Then software parameter setup for the specific installation. Again, just like the DRO packages do it. Will need a good online manual for this part.

Thanks for your perspective. It is valuable input.

 

[WobblyHand]

More work... Seems to never end. Put in a filter on the RPM so it wouldn't jump around as much. (A simple alpha filter, since it is cheap and easy to implement.) That helps. Will get rid of the decimal point, as there's really no value in knowing the RPM to a tenth. Changed a few colors to be a little better (at least to me). Increased the DRO font size and color to make it stand out more. Added the axis labels before each axis. I might brighten the background to highlight the DRO output. Touching the Left Hand button turns it orange, and makes the Right Hand button go grey. Still need to to a little more de-bouncing.

Been thinking about adding feed to stop and thread to stop. I can't add it to the main menu, simply because of the limited display size, but I can make a new page for this advanced feature. At least that way, there will be room for the required controls and settings. For a microsecond I thought about adding push buttons to the board, but decided a new page is better. Then I can have quite a few soft buttons on the page.

This is Unit #2 running. Unit #1 is attached to the lathe. I can debug display stuff upstairs on Unit #2 where it is a little more comfortable. I have remote access to Unit #1, so I can update it from upstairs.