# What's Paul up to?



## PaulL (Nov 6, 2022)

A bit quiet lately - the shop got shut down for three weeks for insulation and boarding.  And the results are amazing!  I have a wall full of shop cabinets that Home Depot is supposed to drop here this week, and a new bench topped with a half-sheet of 1/2" steel to replace the saw horses.  And as usual, it's way more effective to have the fabrication shop that's sourcing my slab weld up the frame for me.  At 600+ lbs I'm not trusting my crappy welds.
I also took advantage of the clearing of the space to re-orient into a better corner and to clean the lathe!  Mill is next.


----------



## Susquatch (Nov 6, 2022)

Drop dead awesome Paul!


----------



## Dan Dubeau (Nov 6, 2022)

That looks like an awesome space.  

I think that anvil has mine beat by a few pounds. Looks pretty stout.


----------



## Degen (Nov 6, 2022)

You need more machinery.


----------



## PaulL (Nov 6, 2022)

Degen said:


> You need more machinery.


Yes, yes I do.  Surface grinder anyone?


----------



## David_R8 (Nov 6, 2022)

PaulL said:


> Yes, yes I do.  Surface grinder anyone?


You would have loved my Parker Majestic SG!


----------



## jcdammeyer (Nov 6, 2022)

PaulL said:


> A bit quiet lately - the shop got shut down for three weeks for insulation and boarding.  And the results are amazing!  I have a wall full of shop cabinets that Home Depot is supposed to drop here this week, and a new bench topped with a half-sheet of 1/2" steel to replace the saw horses.  And as usual, it's way more effective to have the fabrication shop that's sourcing my slab weld up the frame for me.  At 600+ lbs I'm not trusting my crappy welds.
> I also took advantage of the clearing of the space to re-orient into a better corner and to clean the lathe!  Mill is next.
> View attachment 27680


A lot nicer than the last time I was there.  Awesome!


----------



## Tecnico (Nov 7, 2022)

Envious of the free space although with time and help from all the enablers around here I'm sure that'll change!

Looks good, I like the plywood.

D


----------



## PaulL (Nov 7, 2022)

Tecnico said:


> Envious of the free space although with time and help from all the enablers around here I'm sure that'll change!
> 
> Looks good, I like the plywood.
> 
> D


Yeah - the plywood is removing all my anxiety about bumping things against walls.
Now I need to work out my chip management/cleanup.  The shop vac does a bit, but I'd like the dog to be allowed in the shop, and chips are incompatible with paws.


----------



## Dan Dubeau (Nov 7, 2022)

Clearly the dog will just have to wear his workboots in the shop from now on.


----------



## DPittman (Nov 7, 2022)

PaulL said:


> Yeah - the plywood is removing all my anxiety about bumping things against walls.
> Now I need to work out my chip management/cleanup.  The shop vac does a bit, but I'd like the dog to be allowed in the shop, and chips are incompatible with paws.


Ya I've got a dog that eats the dang chips!  I just about have a heart attack everytime.  I'd like to have her in more often but seldom is my shop perfectly chip and swarf clean, and she can find the tiniest little bit to. I get most areas clean always but often there is something hiding behind machinery or stuff.


----------



## YotaBota (Nov 7, 2022)

So work boots _and_ a muzzle. lol


----------



## PaulL (Nov 8, 2022)

Got out back today again and made some progress on my very homebrew ELS.  Had a cheap rotary encoder on hand, so I got it mounted to ride along the drive belt.  Yes, I did just make up a crappy bushing to fit one of my change gears temporarily to travel on the belt - it's holding very well, thank you.  Another day I'll make something more reasonable.






Then I pulled out my little logic probe and a couple of pull-up resistors:




And got some pulses to count.  I put a mark on the big wheel and took ten full revolutions by hand to help reduce the "stop in the right place" error:




And the software happily counts the number of rising edges for me, and I get, awkwardly enough to re-do the experiment, 22001 pulses per 10 revolutions.  I was thinking that maybe the ratio of the gear size to the pulley size was nice and metric, but this encoder measures 360 pulses to the revolution.  So it's just a coincidence that I get 2200 pulses per spindle revolution.

Next is to see if any of my microcontrollers can handle that kind of throughput.  It's not too bad - at 1k RPM that's "only" 2,200,000 pulses per minute, or 36k per second.  That's in range of anything running at 16MHz range, I'd think.  So anyhow, looking through the pile of old boards and seeing if there's something appropriate and easy to drive the motor with.


----------



## jcdammeyer (Nov 8, 2022)

Don't forget that if you are running a stepper motor, that it needs to accelerate.  
Say you are running 1000 RPM and getting 36,000 pulses per second.  To cut a thread that is lead screw pitch the leadscrew turns at the same rpm as the spindle.  So you need 1000 RPM on the lead screw.

If it's directly coupled with a 2000 step/rev micro-stepping drive then for every 36,000 pulses per second you will output 2000 steps per second.   (BTW, stepper motors lose most of their torque by 1000 RPM).

Anyway, every 18 encoder pulses you'll send out 1 stepping pulse since it's a 26/2 ratio and you'll be counting down those 18 every 27.8uS so your code has to be tight.

Next figure out what sort of acceleration you want.  So you don't start out every 18 counts.  That's your target value to decrement and reload for each step pulse.    So your reload value starts hi and then is made smaller and smaller until it reaches the target at which point you are sending out steps at the expected ratio.

Doesn't matter what the spindle speed is.  The ratio remains the same.  Your target is 2000 steps per second.  Say you go up at 2000 steps per second per second.   That would then put the motor at full speed in one spindle rev.  Or 36000 spindle pulses.


----------



## PaulL (Nov 8, 2022)

Yeah, I've been noodling on the control loop - in particular I have effectively no experience in fitting acceleration curves to real inertia ;-). I have vague recollections from a graduate level control class I took 30 years ago, which I may say mildly, I did not excell at.
I have one of these IHSS60-36-30-31 servos (https://www.amazon.ca/gp/product/B08JG8SRNC) that I'll be hooking up with a 3:1 reduction.  Yes, that's my one-star review to point out it's not what they advertise. 
My background is in fitting *way* more compute than that in a 16mSec slice.  It's kind of refreshing/nice to be able to have 28uSec to toggle lines.  These days, that's a round trip and database lookup to a server in my datacenter...


----------



## jcdammeyer (Nov 8, 2022)

I haven't spent a lot of time with the electronic gearing approach so I can't give hints on how to do your acceleration.  I'd be concerned about 3:1.  I run 2:1 with a 280 oz-in stepper on my South Bend and I'd rather have a bigger motor and go 1:1 but my ELS internal micro-stepping driver was limited to 3A and 55V so I went with a 3A (or maybe it was 2.8A) motor and 2:1.


----------



## Susquatch (Nov 8, 2022)

PaulL said:


> Yeah, I've been noodling on the control loop - in particular I have effectively no experience in fitting acceleration curves to real inertia ;-). I have vague recollections from a graduate level control class I took 30 years ago, which I may say mildly, I did not excell at.
> I have one of these IHSS60-36-30-31 servos (https://www.amazon.ca/gp/product/B08JG8SRNC) that I'll be hooking up with a 3:1 reduction.  Yes, that's my one-star review to point out it's not what they advertise.
> My background is in fitting *way* more compute than that in a 16mSec slice.  It's kind of refreshing/nice to be able to have 28uSec to toggle lines.  These days, that's a round trip and database lookup to a server in my datacenter...



I guess that depends what you are doing the controlling with. It's a walk in the park for a dedicated controller. But it might be like asking a turtle to fly for an arduino.


----------



## jcdammeyer (Nov 8, 2022)

Actually not for electronic gearing which is the correct term for the Arduino electronic lead screws.  Look at the code for those. 
For example the Russian ELS is an electronic gearing system with with all the ratios needed to run the lead screw at a scaled rate relative to the spindle.   As long as the spindle doesn't turn the encoder faster than the processor can track it while doing floating point operations.

I've attached the document for it.


----------



## Susquatch (Nov 9, 2022)

jcdammeyer said:


> Actually not for electronic gearing which is the correct term for the Arduino electronic lead screws.



Once again I am impressed by what the little Arduino can be programmed to do! I've been having fun doing little learning projects with mine. I want to order a few breadboards to expand a bit on the organization of components for my projects. Piles of parts and wires is just an invitation for problems. I'm hoping to be ready to fly my turtles by spring. 

I guess I should have looked for something more challenging to make the point. Regardless, I'm thrilled to be able to plan my turtle flights a bit higher up! 

Thanks for that John! 

A question - do you have a rough idea of just how fast an Arduino is? In other words, what is an average execution rate for typical lines of code without comments. I know typical is a very broad term but just looking to get a sense of what is and isn't possible. 

Or is that my next project?


----------



## PaulL (Nov 9, 2022)

Your typical Arduino is *s l o w*. They run at 16MHz, so you take 62.5 nanoseconds per machine instruction (to a first order approximation ... I'll avoid those details here).  For comparison, you PC laptop likely runs at least 100 times faster (>1.6 GHz).  And these controllers have typically for only one processor core, where your bottom end laptop runs at least 4.  Heck, the phone in your hand is probably at 2GHz with 8-10 cores.

So yeah, doing the electronic gearing work in real-time is a challenge on these small, very low power parts.

But there's another class of controllers running in the 100-200 MHz range that make these things so much easier.  I have one of the TI boards that James Clough likes - total overkill, but sure leaves a lot of overhead to not worry about.

As far as "line of code" execution speed, that's a really hard call.  Some are almost free - integer addition, logic opérations (and, or, xor) - while some hide vast amounts of compute - floating point math, serial out, any library calls, really.  And what's expensive relative to what else at the low level changes significantly as your processor gets faster for increasingly arcane reasons.  At least on Arduino-class devices RAM is effectively exactly as expensive to access as an addition operation.  On your PC it's close to 1000x as costly (a boatload of caveats and optimizations apply).


----------



## jcdammeyer (Nov 9, 2022)

Both the original Arduino and the PIC18F series used in my ELS are 8 bit processors.   As @PaulL says there are now Arduino compatible processors that are a lot faster using a 32 bit processor and multiple cores.  The ESP32 for example has WiFi on one core and you can run your application on the other.    I have a box full of different Arduino type modules.  Very useful for things like my currently on hold Kiln controller.

The newer Integrated Development Environment (IDE)  for the Arduino now offers a little bit of what real IDEs for other embedded systems offer but it's still a toy.  At least now you can use break points instead of print statements to debug code.  And the library to deal with external devices is frankly amazing.

But, and it's a huge _*but*_ for embedded systems, not being able to look at the underlying generated assembler is a distinct disadvantage.  And those libraries, nice as they are, can leak memory so that 73.6 hours after starting they suddenly reset or freeze.  And you have no idea of why or how.

I ported the 8 bit C code into a PIC32 with almost no effort.  The interrupt routine that deals with checking ESTOP, runs the on board Micro-Stepping driver, does the trajectory motion changed from taking about 35uS to just over 3uS.  A 10x improvement.  



All I needed from the development board was an adapter that translated 3.3V signals to 5V signal levels and moved pins around to match the original 40 pin DIP processor.    Ignore U2 and U3 as those are the empty sockets on the board.

For testing the ICD-3 programmer/debugger let me insert break points to stop inside the interrupt routine and even single step the assembler language.

So why the assembler?  Each compiler generates and optimizes the code slightly differently.  Although Object Oriented Programming (OOP) is very useful at the source code level for programmers to have understandable code, it often creates very slow code.  Not a problem with that fast 1000x faster PC.  Deciding to make a variable a local, global or object member and looking at how it's used can cut microseconds off your interrupt routine.

So where, although it's rarely mentioned, the Arduino based electronic gearing systems are limited to about 1800 RPM for the spindle because after that the encoder used generates edges too quickly.  You can't run it with a 100 line encoder like LinuxCNC and work with 6000 RPM spindles.

The reply from the developers of the Arduino systems are no one uses a spindle above 1800.  Lack of I/O is another issue but they seem to like a couple of buttons and a knob for selecting stuff.  None of the commerical CNC systems have tiny keypads.  Now that there are 32 bit based Arduino modules that may well have changed.

OTOH, there are some pretty nice processors out there like this dual core TI unit.  I started porting my ELS to this too just to see how it would work.  Still want to try that as it has features the PIC32 doesn't.


			https://www.ti.com/product/LAUNCHXL-F28379D/part-details/LAUNCHXL-F28379D
		

Has the hardware encoder modules, CAN bus, etc. and isn't that expensive plus the built in programmer and free IDE.


----------



## jcdammeyer (Nov 9, 2022)

And for a 32 bit Arduino this is a good start and although it does have CAN bus and multiple PWM for 3 phase motor control I don't see a proper quadrature encoder input module.








						Arduino Due
					

The Arduino Due is a microcontroller board based on the Atmel SAM3X8E ARM Cortex-M3 CPU. It is the first Arduino board based on a 32-bit ARM core microcontroller. It has 54 digital input/output pins (of which 12 can be used as PWM outputs), 12 analog inputs, 4 UARTs (hardware serial ports), a 84...




					store-usa.arduino.cc
				




Still pretty nice for the money.

edit: I stand corrected.  The data sheet for the processor says:
9-channel 32-bit Timer Counter (TC) for capture, compare and PWM mode, Quadrature Decoder Logic and 2-bit
Gray Up/Down Counter for Stepper Motor


----------



## PaulL (Dec 20, 2022)

Ok, got a bit more time to poke at my setup, which was reporting slower RPM than the readout on my lathe.  So I hacked my way around the physical limitations of my
"count by hand" method.  I present you the Kludge-Omatic-RPM counter:



zer
I scabbed a momentary switch onto a PCB I had lying around and zip-tied it to the standoff that holds the cover over change gears, and the lock nuts that space it hold the zip tie well enough to have the little magnetic standoff I put on the spindle pulley very reliably hit the switch.  That signal goes to my little Saleae Logic analyzer which is also counting the pulses coming from the encoder hiding behind the gray wheel in the upper left.





The brown and pink bars are the encoder signals - here's a closeup:




The quadrature encoding is clearly visible - the two pulse trains are offset by a half wave.  And on the right the nice machine has counted up how many pink edges there are between successive rising edges of Kludge-Omatic input.  Checking a few intervals I'm at 1675 +- 3.  I'm going with 1675.


----------



## PaulL (Dec 20, 2022)

And I can see that my little gray wheel is slipping agaist the belt, quite reliably differently at different RPMs.  Which isn't surprising - it was a quick cheap hack to get the encoder hooked up.  Time to machine a real bracket and pulley.  The geometry lets me run it off the drive pulley - I rarely (as in have never) run in the high range, so I don't feel bad committing that belt groove to the task.
And for good measure, here's a shot of the business end of the rig.  The motor will eventually tuck into the back, but it's doing fine hanging off the banjo for now.


----------



## Dabbler (Dec 20, 2022)

@PaulL I'm distracted by the fact that you have FLOOR!


----------



## jcdammeyer (Dec 21, 2022)

PaulL said:


> Ok, got a bit more time to poke at my setup, which was reporting slower RPM than the readout on my lathe.  So I hacked my way around the physical limitations of my
> "count by hand" method.  I present you the Kludge-Omatic-RPM counter:
> View attachment 29138zer
> I scabbed a momentary switch onto a PCB I had lying around and zip-tied it to the standoff that holds the cover over change gears, and the lock nuts that space it hold the zip tie well enough to have the little magnetic standoff I put on the spindle pulley very reliably hit the switch.  That signal goes to my little Saleae Logic analyzer which is also counting the pulses coming from the encoder hiding behind the gray wheel in the upper left.
> ...


Doesn't the encoder also have an index out?


----------



## PaulL (Dec 21, 2022)

jcdammeyer said:


> Doesn't the encoder also have an index out?


This one doesn't - only the A and B signals.  Cheap trash.


----------



## PaulL (Dec 22, 2022)

Ok, I got a new encoder gear milled up, and moved it to rest on the spindle drive pulley, both at @jcdammeyer's recommendation:




I was able to cut the teeth with a 2mm end mill using my indexing jig and the 40-tooth changegear from my lathe on my indexing jig I made a while back:





To date, seems to be less slip, but when I adjust the encoder-to-spindle pulse count to match the lathe's displayed RPM at one speed, I get error at other speeds, indicating a non-linearity somewhere.
The RPM display on the lathe is very laggy - I don't actually trust its output.  Next step will be to fit on the opto-coupler that John gave me so I have an index signal, and can use that to get a real RPM count and know I'm measuring the spindle speeds correctly.
And maybe replace that block of orange plastic with some nice aluminium - the plastic deforms more than I like while putting even minor pressure down between the pulleys.


----------



## jcdammeyer (Dec 22, 2022)

PaulL said:


> Ok, I got a new encoder gear milled up, and moved it to rest on the spindle drive pulley, both at @jcdammeyer's recommendation:
> View attachment 29191
> I was able to cut the teeth with a 2mm end mill using my indexing jig and the 40-tooth changegear from my lathe on my indexing jig I made a while back:
> View attachment 29192
> ...


Is it possible that the X:Y multiplication in the pulley sizes is overwhelming the encoder inputs on your RPM measurement?   Say the encoder is 800 lines then in quadrature that's 3200 edges per rev.  But the encoder is being turned with say an 8" to 2" diameter pulley? (I'm guessing sizes).  So that's now 4x the edges per rev.

Unless the v belt is slipping and the teeth in your plastic pulley mesh and there isn't an anomaly in the back side of the belt somewhere then there shouldn't be any slipping.  But dropped counts are possible.

When you get the 1 PPR sensor working I can bring over an ELS to read the RPM.    And of course your scope can show period.

Edit: Changed seconds to revs.  so 12,800 edges per rev with an assumed 1:4 step up ratio.  If the spindle is turning 360 RPM then that's 6 revs per second and 76,800 edges per second or about 12uS per edge.  That's not a lot of time to count edges although that TI processor you are using could do it in hardware.


----------



## PaulL (Dec 22, 2022)

jcdammeyer said:


> Edit: Changed seconds to revs. so 12,800 edges per rev with an assumed 1:4 step up ratio. If the spindle is turning 360 RPM then that's 6 revs per second and 76,800 edges per second or about 12uS per edge. That's not a lot of time to count edges although that TI processor you are using could do it in hardware.


That's the main magic of the TI processor - it does its edge counting in hardware and can report counts since the last time it was polled.  So I trust its count.
I actually don't at all trust the RPM meter on my lathe - it takes a very long time - on the order of seconds - to stabilize.  Much longer than the acceleration of the spindle.


----------



## jcdammeyer (Dec 22, 2022)

PaulL said:


> That's the main magic of the TI processor - it does its edge counting in hardware and can report counts since the last time it was polled.  So I trust its count.
> I actually don't at all trust the RPM meter on my lathe - it takes a very long time - on the order of seconds - to stabilize.  Much longer than the acceleration of the spindle.


I think the scope will be your friend here.  The period from the 1 PPR will tell you RPM.  The frequency of the encoder output will tell you your ratio and if it's jittering or not.


----------



## Susquatch (Dec 22, 2022)

PaulL said:


> To date, seems to be less slip, but when I adjust the encoder-to-spindle pulse count to match the lathe's displayed RPM at one speed, I get error at other speeds, indicating a non-linearity somewhere.



Sounds like lost counts or count/edge deterioration . As others have said, a standalone counter that is polled to get the count is a superior way to do it. Hence my own desire to directly access the Arduino counters and bypass the Arduino interface. 

I agree with @jcdammeyer. An oscilloscope is your friend if you have one. If not, use a handheld laser tach and put a full wrap of black tape on the shaft you want to measure as well as a small piece of reflector tape. The black tape will improve signal to noise ratio.


----------



## jcdammeyer (Dec 22, 2022)

Susquatch said:


> Sounds like lost counts or count/edge deterioration . As others have said, a standalone counter that is polled to get the count is a superior way to do it. Hence my own desire to directly access the Arduino counters and bypass the Arduino interface.
> 
> I agree with @jcdammeyer. An oscilloscope is your friend if you have one. If not, use a handheld laser tach and put a full wrap of black tape on the shaft you want to measure as well as a small piece of reflector tape. The black tape will improve signal to noise ratio.


IIRC, the processor board is the TI Launchpad for the F280049C


			https://www.mouser.ca/new/texas-instruments/ti-launchxl-f280049c-launchpad/
		


It has quadrature encoder inputs.  So the software has to, on a periodic basis read the counter value.  

The key elements then are:
1. The period used to read the counter.
2. The number of periods between counts.
3. The ratio to apply to that counter value to report RPM.

After that it's just math.


----------



## Susquatch (Dec 22, 2022)

jcdammeyer said:


> IIRC, the processor board is the TI Launchpad for the F280049C
> https://www.mouser.ca/new/texas-instruments/ti-launchxl-f280049c-launchpad/



Oh my! Very sexy development system! Thanks for the link. I've bookmarked it for future reference.

Edit. - I should add that lost counts are not likely with this speedy little system unless the signal quality deteriorates. Ya, a scope will be his friend.


----------



## jcdammeyer (Dec 22, 2022)

Susquatch said:


> Oh my! Very sexy development system! Thanks for the link. I've bookmarked it for future reference.
> 
> Edit. - I should add that lost counts are not likely with this speedy little system unless the signal quality deteriorates. Ya, a scope will be his friend.


This is the LaunchPad I have:


			https://www.ti.com/tool/LAUNCHXL-F28379D
		


It has two processor cores along with floating point etc and encoder interface.  This was my second choice for updating my own ELS although using the PIC32 would be dramatically cheaper although not as powerful.

I got as far as writing code for communications between the processors but never did get around to connecting an encoder to it.  If I ever get the touch pad and probe working together on my milling machine for detecting tool length on the fly I may take this on as a Christmas break project.


----------



## Susquatch (Dec 22, 2022)

jcdammeyer said:


> I may take this on as a Christmas break project.



Which year?


----------



## jcdammeyer (Dec 22, 2022)

Susquatch said:


> Which year?


2042


----------



## jcdammeyer (Dec 22, 2022)

According to the Clough42 Electronic Gearing code documentation the RPM is updated 2x per second.
`Uint16 Encoder :: getRPM(void)
{
    if(ENCODER_REGS.QFLG.bit.UTO==1)       // If unit timeout (one 10Hz period)
    {
        Uint32 current = ENCODER_REGS.QPOSLAT;
        Uint32 count = (current > previous) ? current - previous : previous - current;

        // deal with over/underflow
        if( count > _ENCODER_MAX_COUNT/2 ) {
            count = _ENCODER_MAX_COUNT - count; // just subtract from max value
        }

        rpm = count * 60 * RPM_CALC_RATE_HZ / ENCODER_RESOLUTION;

        previous = current;
        ENCODER_REGS.QCLR.bit.UTO=1;       // Clear interrupt flag
    }

    return rpm;
}`
That parameter RPM_CALC_RATE_HZ is 2 and ENCODER_RESOLUTION is 4096 so
300 RPM would be 10,240 counts in the encoder register every 0.5 seconds.  This is 1:1 from spindle to encoder which has 1024 lines for that 4096 edges. 

Now if you had an 800 line encoder with 3200 counts per rev with 1:4 ratio to the encoder from the spindle the value for encoder resolution is 12,800 instead of 4096.

Now the code above shows testing for overflow and 32,000/2 is still larger than 12,800 but we haven't actually spun a full scaled encoder rev.  Just too fast within the time period I think.

Unless I've screwed up on the math.  I suspect the RPM measurements are overflowing.


----------



## PaulL (Dec 23, 2022)

Yeah, 


Susquatch said:


> Oh my! Very sexy development system! Thanks for the link. I've bookmarked it for future reference.
> 
> Edit. - I should add that lost counts are not likely with this speedy little system unless the signal quality deteriorates. Ya, a scope will be his friend.


i have my little logic probe living on it now.  I think some of the problem is lack of rigidity in the plastic block I have holding the encoder.  I'll finish the aluminum replacement this morning and report back.


----------



## PaulL (Dec 23, 2022)

jcdammeyer said:


> That parameter RPM_CALC_RATE_HZ is 2 and ENCODER_RESOLUTION is 4096 so
> 300 RPM would be 10,240 counts in the encoder register every 0.5 seconds. This is 1:1 from spindle to encoder which has 1024 lines for that 4096 edges.


Ok, you've convinced me to check out the overflow handling in detail - yeah, my 600 step (2400 edges ) encoder spinning at ~1700 steps (6800 edges) per rev will overflow a 16 bit counter at as low as 8rpm when sampled every 2 seconds.  The symptoms are a off though, as I'm getting within 5% over my whole speed range.


----------



## Susquatch (Dec 23, 2022)

PaulL said:


> The symptoms are a off though, as I'm getting within 5% over my whole speed range.



That does not make sense for an overflow problem. Is the get count function synced to the speed too? Or is it clock based? Or perhaps a bit of both?


----------



## PaulL (Dec 23, 2022)

Ok, dug through the manual and the source somewhat more - the code sets QPOSMAX to 0x00ffffff - 24 bits of counter.  That's 16M or so pulses per overflow, so that's not what's going on with my system.  The hardware itself can go up to 31 bits.  It looks like the choice of 24 is to match with floating point precision - more than that and you'd lose precision in the conversion to a 32 bit floating point number (23 bits of mantissa, plus the implied leading 1 bit).
So I'm on the slippage hypothesis.  Breakfast is done, I just have to brave the ice storm for the trudge out 50' to the workshop.


----------



## Susquatch (Dec 23, 2022)

PaulL said:


> Ok, dug through the manual and the source somewhat more - the code sets QPOSMAX to 0x00ffffff - 24 bits of counter.  That's 16M or so pulses per overflow, so that's not what's going on with my system.  The hardware itself can go up to 31 bits.  It looks like the choice of 24 is to match with floating point precision - more than that and you'd lose precision in the conversion to a 32 bit floating point number (23 bits of mantissa, plus the implied leading 1 bit).
> So I'm on the slippage hypothesis.  Breakfast is done, I just have to brave the ice storm for the trudge out 50' to the workshop.



Is it always high or always low. If high, consider noise. If low, consider lost counts.

Is it out by a ratio or by a more or less constant amount? If ratio, consider a correction factor. If constant, then a subroutine or preload or formula or interrupt error might be interfering. If it's a solid error, consider adding a correction formula.

You eat breakfast every day?


----------



## Susquatch (Dec 23, 2022)

PaulL said:


> So I'm on the slippage hypothesis.



Do you have a counter you can use to test that with instead?


----------



## jcdammeyer (Dec 23, 2022)

PaulL said:


> Ok, you've convinced me to check out the overflow handling in detail - yeah, my 600 step (2400 edges ) encoder spinning at ~1700 steps (6800 edges) per rev will overflow a 16 bit counter at as low as 8rpm when sampled every 2 seconds.  The symptoms are a off though, as I'm getting within 5% over my whole speed range.


I'm pretty sure it's a 32 bit counter and the variables are 32 bit.  And it's sampling the count at 2Hz or every 500mS.  However you have to factor in the large pulley diameter to small pulley diameter so the actual number of counts per spindle revolution is much larger than 2400.  

If you have taken that into account you might be out by the number of teeth you carved on the little pulley relative to the number of ribs on the back of the belt.  I think guessing slippage is headed in the wrong direction.


----------



## PaulL (Dec 23, 2022)

jcdammeyer said:


> I'm pretty sure it's a 32 bit counter and the variables are 32 bit.  And it's sampling the count at 2Hz or every 500mS.  However you have to factor in the large pulley diameter to small pulley diameter so the actual number of counts per spindle revolution is much larger than 2400.
> 
> If you have taken that into account you might be out by the number of teeth you carved on the little pulley relative to the number of ribs on the back of the belt.  I think guessing slippage is headed in the wrong direction.


It's a 32 bit counter with a programmable overflow, set to 24 bits.  The control code is all floating point, so the 24 bit limit makes sense.  
I can still slip the wheel over the belt, even with the teeth.  The nylon isn't providing much friction and my holder isn't letting me apply enough force to keep it from bouncing.  
Heading out to the shop now.


----------



## PaulL (Dec 23, 2022)

Ok, new holder in place, wheel carefully aligned.  Set the ratio at 468 RPM, and I'm off by 25% at the low end, (48 on mine vs 60 on the lathe).  But now I *really* don't trust the lathe read-out.  I can vary the pot to get single-RPM changes on my display, while the lathe doesn't update.  It would appear to be a very poor approximator of the RPM, given that it has a hall effect sensor counting 4 times per revolution.
I'm going to mount the sensor John gave me now so I can have an index and count reality.


----------



## Susquatch (Dec 23, 2022)

PaulL said:


> It would appear to be a very poor approximator of the RPM, given that it has a hall effect sensor counting 4 times per revolution.



Generally, I find Hall effect transducers to be very reliable. The wave form is especially immune to noise and miscounts. Is the gap too wide?


----------



## PaulL (Dec 23, 2022)

Susquatch said:


> Generally, I find Hall effect transducers to be very reliable. The wave form is especially immune to noise and miscounts. Is the gap too wide?


It is very slow to respond, and ramps oddly - I suspect it has a really shoddy software filter to generate the output. This is increasing my incentive to mount the new display and electronics directly in the lathe enclosure.


----------



## Susquatch (Dec 23, 2022)

PaulL said:


> It is very slow to respond, and ramps oddly - I suspect it has a really shoddy software filter to generate the output. This is increasing my incentive to mount the new display and electronics directly in the lathe enclosure.



The wave form on a hall effect is not like most other sensors. It has a very steep edge on one side (which is why it works so well), and almost a hysteresis type curve on the other. But you raise a good point, you could try reversing the wires on the sensor. If it is backwards, a trigger designed for the steep edge might go to hell in a handbasket on the other side!


----------



## PaulL (Dec 23, 2022)

The hall effect bits are all stick to the lathe.  I haven't excavated the control board to read what chips are on it, but I'm guessing it's the cheapest counter-and-lookup table they could find 15 years ago.  The RPM readout is good enough for setting cutting speed, but not accurate.


----------



## jcdammeyer (Dec 23, 2022)

Question about your quadrature setup in the software.  You said you had 600 lines for 2400 edges per rev.  What's the diameter of the driven disk and what's the diameter of the driving pulley?  Do you not also have to put that information into the software.  At least as a scale factor?
Like if it's 4:1 so you put down for the encoder 9600 edges per rev?

Or do you guess at the RPM and enter some sort of value?

Edit:  Oh and can you put the scope on the hall sensor feeding the lathe electronics?


----------



## Susquatch (Dec 23, 2022)

jcdammeyer said:


> Edit: Oh and can you put the scope on the hall sensor feeding the lathe electronics?



Yes, I'd like to see this too.


----------



## PaulL (Dec 23, 2022)

jcdammeyer said:


> You said you had 600 lines for 2400 edges per rev. What's the diameter of the driven disk and what's the diameter of the driving pulley?


I used my logic analyzer to count how many rising edges I have on the A signal in one revolution of the spindle, so that embeds the two radii.  Multiplying that figure by 4 gives the number of edges the software is expecting.
Just wiring up that opto-sensor now, which I'll be able to hold in my toolpost easily enough.  Then my scope should be able to get some RPM figures out for me.


----------



## jcdammeyer (Dec 23, 2022)

I dug into my plastic bin marked DRO and Stepper Driver.  The source code for the PIC is dated 2008.  I thought maybe the US Digital Encoder had an index output.  The part number is only S1-400-B so it's a ball bearing based unit but no Index.  I confirmed that with the scope.  The index pin is the same as the A output.  Back in 2008 I must have paid $57US for it.


----------



## jcdammeyer (Dec 23, 2022)

PaulL said:


> I used my logic analyzer to count how many rising edges I have on the A signal in one revolution of the spindle, so that embeds the two radii.  Multiplying that figure by 4 gives the number of edges the software is expecting.
> Just wiring up that opto-sensor now, which I'll be able to hold in my toolpost easily enough.  Then my scope should be able to get some RPM figures out for me.


To me the diameter of the large pulley looks to be bigger than just over 2x the smaller one.  So 600 lines on the encoder to get 1675 is 2.79.  I suppose if the small pulley is 2" the big one could be 5.58".  Hard to tell from the photo.  

Optical illusion perhaps.
John


----------



## PaulL (Dec 23, 2022)

Ok, the whole "calibration jig" is a touch Rube Goldberg, but it's working, and I trust my speed output.






I have an Allen key chucked, with the optical interruption sensor held in a quick-change tool holder, which made alignment really easy.  That snare of (too short and messy) wires go to the breadboard where there's a couple of resistors thanks to which I fried neither the sensor nor my logic analyzer.  It also has a bypass cap to reduce noise on the sensor.  The logic analyzer hooks to the breadboard, as well as power and ground coming from my controler, in case I wanted to get my encoder pulses at the same time as the index pulse.  

Logic analyzer snapshots show the thing repeatable and the displayed time is correct as far as the logic probe is concerned.

Thanks @jcdammeyer and @Susquatch for the support.

Biggest hurdle to overcome to make this work?  The brown and black wires on the sensor are reversed from the random diagram I pulled off the internet - black wanted +, brown to ground.  

On to making some test threads!


----------



## PaulL (Dec 23, 2022)

And it works! 1/2"-13 fits my test nut!




This is so much quieter than the gearbox!  And in theory I can do metric at the touch of a button.  But that's for another day.


----------



## PaulL (Dec 23, 2022)

Susquatch said:


> Yes, I'd like to see this too.


Yes, I should be able to do that.  
There's a little 8-bit Holtek HT48R30A hiding behind the panel.  10MHz job.  Lots of empty, clean space behind there, so I'm pretty sure this is where my electronics will go.





Seeing if I can find the right Molex connector to adapt some leads onto the sensor wiring.


----------



## jcdammeyer (Dec 23, 2022)

PaulL said:


> Yes, I should be able to do that.
> There's a little 8-bit Holtek HT48R30A hiding behind the panel.  10MHz job.  Lots of empty, clean space behind there, so I'm pretty sure this is where my electronics will go.
> 
> 
> ...


You realize of course that the nut you used isn't really 1/2"-13 but actually 2mm pitch.


----------



## PaulL (Dec 23, 2022)

Within 0.5% yes ;-)


----------



## PaulL (Saturday at 4:41 PM)

Lost in the Great Crash of '23, but not lost to my shop.  I got the Harold Hall grinding rest pretty much completed today, with a little holder to take my QCTP holders and orient them to the wheel appropriately:




The little block of mystery metal accepted the dovetail well, but seriously chewed up my drill bits.  One happily shattered while drilling the hole to hold the block in the slot.  That's the reason the grub screw to hold the dovetail to the holder is 3mm instead of something a bit bigger - my 13/64th (M5 tapping size) bit no longer exists.  Yay?

But it works, and I'm surprised how much better the surface finish is on my turnings with the tool sharpened a little more carefully than I had been before I had such a handy rest.

I'll probably remake it when I find a piece of mild steel large enough for the task - I'd much rather cinch the tool holder to the table from above than from below with a hex key.  And there's no hope I can get that hole drilled in this stuff!

Mystery metal for the win!  

Paul


----------



## Susquatch (Saturday at 6:48 PM)

PaulL said:


> Lost in the Great Crash of '23, but not lost to my shop.  I got the Harold Hall grinding rest pretty much completed today, with a little holder to take my QCTP holders and orient them to the wheel appropriately:
> View attachment 29278
> The little block of mystery metal accepted the dovetail well, but seriously chewed up my drill bits.  One happily shattered while drilling the hole to hold the block in the slot.  That's the reason the grub screw to hold the dovetail to the holder is 3mm instead of something a bit bigger - my 13/64th (M5 tapping size) bit no longer exists.  Yay?
> 
> ...



I LOVE THIS PAUL! 

Officially added to my future project list. Might even use aluminium for the holder block..... LOL!


----------



## 6.5 Fan (Sunday at 4:35 AM)

Oh crap, i want to add this to my future project list as well. Need to live to 150 at least to finish the list i have now.


----------



## Art M (Sunday at 8:38 AM)

Hey Paul do you have any idea how much time you have in the Harold Hall grinding rest?
It looks great. I’ve been thinking about one for some time.
Do you think the design is good as it is?
Art


----------



## Tecnico (Sunday at 9:36 AM)

Oh, great that just bumps it up on my list of 42 things I want to make, LOL!  I have the book and put it on the wanna do list a while back.  My hand grinding has improved but a "for real" accurate rest would be so much better.  

Thanks Paul 

D

PS Nice work.


----------



## PaulL (Sunday at 10:58 AM)

Art M said:


> Hey Paul do you have any idea how much time you have in the Harold Hall grinding rest?
> It looks great. I’ve been thinking about one for some time.
> Do you think the design is good as it is?
> Art


I wish I had tracked it.  It's been a side project in the shop for a couple of months.  I'd say I'm 30ish hours in?  The more recent hours have been much more productive than the first few.  If I had dimensioned my stock intelligently instead of piecemeal I'm pretty sure I could have spent 8-10 hours less.

I like the design.  I have to remake the angle iron base - I used what I had on hand and it's too flimsy, letting the whole thing vibrate.  The top plate will likely also be re-made once I know how I use it - using my QCTP holder on it, for example, doesn't fit well with Mr. Hall's jigging.  An auxiliary table could fix it, or I could just have different tables for different uses.

As a begining milling project it was just about right - few things too critical - and it's already showing its value in my shop.


----------



## Art M (Sunday at 8:51 PM)

Thanks 
Art


----------



## PaulL (Monday at 12:34 PM)

I noticed that my nice tidy lathe pictures died in the Great Crash of '22.  I happened to have the post open in another window...
And I managed that Christmas Morning shop time:










She's all tidy and her safety cover is back on.
I just have one detail to fix...When I moved the motor I changed the parity of drive - forward is now reversed! Tomorrow I'll pull the front cover, get at the programming port on the microcontroller and fix it. Until then she runs fine in forward with the drive lever set to reverse!


And since then, I pulled out the programming interface, it's awfully handy having the USB programming port hanging out somewhere accessible.







Paul


----------



## PaulL (Monday at 9:15 PM)

So I started remaking the jig to hold my QCTP holders to the sharpening jig.  And I did have some aluminium on hand, though in awkwardly large sections (4"x4"x40").  So after a long time in a saw with too fine a tooth pattern, I got it mostly squared up, when the oops fairy showed up:




The block turned itself 90 degrees up in the vise, just as I was clearing up the 4th face.  The only injury is the 1/2" end mill, which is now running somewhat out of true.  And a skipped heartbeat or two.

Aluminium is both *slippery* and *grabby*.  Both holding faces were freshly milled, flat and parallel to one another.

Any tips for holding this stuff more securely in the vise?
Paul


----------



## Degen (Monday at 9:43 PM)

PaulL said:


> Lost in the Great Crash of '23, but not lost to my shop.  I got the Harold Hall grinding rest pretty much completed today, with a little holder to take my QCTP holders and orient them to the wheel appropriately:
> View attachment 29278
> The little block of mystery metal accepted the dovetail well, but seriously chewed up my drill bits.  One happily shattered while drilling the hole to hold the block in the slot.  That's the reason the grub screw to hold the dovetail to the holder is 3mm instead of something a bit bigger - my 13/64th (M5 tapping size) bit no longer exists.  Yay?
> 
> ...


Quick guess, likely a little heavier than you expect for the size (subjective of course), appears to start to drill nice just before it eats the drill, has a nice shine to it, cuts clean when you can machine it.

Likely a chrome moly steel type.

One word Carbide.

Though nicely done, enjoy.


----------



## Susquatch (Tuesday at 3:22 AM)

PaulL said:


> The block turned itself 90 degrees up in the vise, just as I was clearing up the 4th face. The only injury is the 1/2" end mill, which is now running somewhat out of true. And a skipped heartbeat or two.
> 
> Aluminium is both *slippery* and *grabby*. Both holding faces were freshly milled, flat and parallel to one another.
> 
> Any tips for holding this stuff more securely in the vise?



Wow!  I can feel my heart pounding as if I had been there. But my only experience with that kind of thing on a mill was breaking an endmill when it grabbed. I've been more fussy about which direction I mill in ever since. It's not that I never climb mill, just that I try not to. When I do, I will often partially lock the axis I am milling in, and I always limit the size of my cut.

I am amazed at that pattern on the block. It suggests that things were bouncing pretty badly too! That doesn't happen so easily on such a big mill.

It looks to me like you were climb milling and/or milling in x without locking the Y. If so, I could see this happening more easily. Once the end mill grabbed, the vise would have had a very hard time holding on.  Especially given that your part was seated quite shallow in the Jaws. Deeper is always better. 

Last but not least, it looks like your part was originally located at one end of the Jaws. No matter how big your vise is, it will bend a bit as the pressure builds. It's not if, it's just how much. Stress causes strain - it's unavoidable. When I mount something in my vise I always try to mount it in the middle. If I can't do that for some reason, then I put something else in the vise at the other end to balance the load a bit. An equally sized part of the same material is best, but even a wood shim on a smaller metal part is better than nothing. If you don't do that, the Jaws will cant ever so slightly. Even an invisible cant in the Jaws will significantly reduce clamping ability.


----------



## Degen (Tuesday at 4:02 AM)

PaulL said:


> So I started remaking the jig to hold my QCTP holders to the sharpening jig.  And I did have some aluminium on hand, though in awkwardly large sections (4"x4"x40").  So after a long time in a saw with too fine a tooth pattern, I got it mostly squared up, when the oops fairy showed up:
> View attachment 29341
> The block turned itself 90 degrees up in the vise, just as I was clearing up the 4th face.  The only injury is the 1/2" end mill, which is now running somewhat out of true.  And a skipped heartbeat or two.
> 
> ...


Lucky it only bent the endmill, I've snapped a 1" one that way and it flies afterwards like a rocket bouncing off anything it hits luckily I wasn't in a part of the path.  I'm going to suggest the endmill is toast.  Also tram your head to ensure its still true.  You be surprised how much force you applied in those brief heart stopping couple of seconds.

I agree with @sasquatch when you held the part off center you created the ideal pivot point on the block closet to the center of the vise.  Voila!

Just remember the old saying what doesn't kill you makes you smarter and don't make that mistake again  .


----------



## jcdammeyer (Tuesday at 10:27 AM)

PaulL said:


> So I started remaking the jig to hold my QCTP holders to the sharpening jig.  And I did have some aluminium on hand, though in awkwardly large sections (4"x4"x40").  So after a long time in a saw with too fine a tooth pattern, I got it mostly squared up, when the oops fairy showed up:
> View attachment 29341
> The block turned itself 90 degrees up in the vise, just as I was clearing up the 4th face.  The only injury is the 1/2" end mill, which is now running somewhat out of true.  And a skipped heartbeat or two.
> 
> ...


What RPM were you using?  What depth of cut?  

A zoom in on the freshly milled holding surfaces suggests they are not super smooth. if the vise wasn't clamped hard enough the actual holding surface was quite small.  

Based on the markings I'm trying to figure out where it was clamped in the vise.  On the end where it is now and you started milling where the cutter is sitting?  Then the others are correct.  Your vise also flexed and you were really only pinching it on the RH corner.  Not enough to hold it well.


----------



## PaulL (Tuesday at 10:31 AM)

Degen said:


> Quick guess, likely a little heavier than you expect for the size (subjective of course), appears to start to drill nice just before it eats the drill, has a nice shine to it, cuts clean when you can machine it.
> 
> Likely a chrome moly steel type.
> 
> ...


Definitely hits the "a little heavier than expected", and the nice-until-bad.  
Still going to replace it.  Those carbide drills are spendy!


----------



## PaulL (Tuesday at 12:19 PM)

Susquatch said:


> I am amazed at that pattern on the block. It suggests that things were bouncing pretty badly too! That doesn't happen so easily on such a big mill.


It wasn't particularly bouncy - each of those streaks is one edge of the cutter grabbing and pulling!



jcdammeyer said:


> A zoom in on the freshly milled holding surfaces suggests they are not super smooth.


Yes, not super-smooth.  The end mill was a bit ratty to start.  Was running slower than I should have been (~1200rpm, vs the 6k rpm the usual charts propose for a 1/2 end mill in aluminium), and maybe feeding too fast.
I was absolutely clamped at the end, expecting to mill the end of the blank in the same setup.  And I was in too-high parallels, instead of changing them out between facing the edges vs faces.  

Lesson learned, I hope.

Paul


----------



## jcdammeyer (Tuesday at 1:09 PM)

You aren't the first or likely the last to bend a tool for one reason or another.


----------



## Susquatch (Tuesday at 1:41 PM)

PaulL said:


> It wasn't particularly bouncy - each of those streaks is one edge of the cutter grabbing and pulling!



Ah yes, zooming in, I can see that now. In fact I can see it in slow mo in my mind...... It ain't pretty! LOL! 



PaulL said:


> Was running slower than I should have been (~1200rpm, vs the 6k rpm the usual charts propose for a 1/2 end mill in aluminium), and maybe feeding too fast.
> I was absolutely clamped at the end, expecting to mill the end of the blank in the same setup. And I was in too-high parallels, instead of changing them out between facing the edges vs faces.



In my (very limited) experience, that big machine should have handled that low speed albeit obviously not optimum. 

6000 rpm? Will your machine go that fast? My factory top speed is 2750. With the VFD I installed, it will do 4500 safely but I would prolly never run that fast anyway. 

Ya, clamping at the end of the jaws without a counter load on the other side, plus climb milling is what did it. I am of the view that your finish, while not perfect, should have held. 

FWIW, I have an old set of sine blocks and a few 4x1x1/4 hardwood blocks that I keep beside my mill and drill press to use whenever I feel the need to mount something on the left or right side of my jaws. 



jcdammeyer said:


> You aren't the first or likely the last to bend a tool for one reason or another.



I have a bunch of things I've bent or broken over the years too. I keep them to remind me not to do whatever it was again.


----------



## jcdammeyer (Tuesday at 5:11 PM)

Whenever I use this tool I consider the feed rate at the high end for production rather than home hobby.


----------



## Susquatch (Tuesday at 5:22 PM)

jcdammeyer said:


> Whenever I use this tool I consider the feed rate at the high end for production rather than home hobby.



That's pretty impressive. It's prolly way more info than I'll ever use but who knows..... 

I have a chart on the wall behind my lathe with graphs for some stuff like that. I hardly ever use it either. 

Is that a Windows or a Mac program? Is there an android version?


----------



## jcdammeyer (Tuesday at 6:48 PM)

Susquatch said:


> That's pretty impressive. It's prolly way more info than I'll ever use but who knows.....
> 
> I have a chart on the wall behind my lathe with graphs for some stuff like that. I hardly ever use it either.
> 
> Is that a Windows or a Mac program? Is there an android version?


Mine came with Alibre way back.  


			Machinist Toolbox
		

I think it costs money now but I don't know how much.


----------



## YotaBota (Tuesday at 7:06 PM)

Here's a program on LMS for milling/drilling/turning speeds, it's been my goto since I came across it a couple of years ago.









						Speeds & Feeds
					

The premier source of tooling, parts, and accessories for bench top machinists.




					littlemachineshop.com


----------



## whydontu (Tuesday at 7:08 PM)

4Machining on iOS


----------



## Susquatch (Tuesday at 7:23 PM)

jcdammeyer said:


> Mine came with Alibre way back.
> 
> 
> Machinist Toolbox
> ...



I can't find it alone. Apparently it comes with other software you buy.


----------



## Susquatch (Tuesday at 7:24 PM)

YotaBota said:


> Here's a program on LMS for milling/drilling/turning speeds, it's been my goto since I came across it a couple of years ago.
> 
> 
> 
> ...



Thanks! I'll check it out.


----------



## PaulL (Yesterday at 6:20 PM)

Yesterday was a much better evening in the shop.  I got the holder holder remade:






Ditched the aluminium, found a short piece of 4140 that used to be a guillotine tool in my forge but hasn't seen use since I re-did that tooling for the power hammer.
Much easier to set up and feels properly solid.


----------



## jcdammeyer (Yesterday at 6:25 PM)

Susquatch said:


> I can't find it alone. Apparently it comes with other software you buy.


It runs alone but does appear to have been linked to Alibre.

View attachment 29377


----------



## Susquatch (Yesterday at 7:17 PM)

jcdammeyer said:


> It runs alone but does appear to have been linked to Alibre.
> 
> View attachment 29377



Link is dead John.


----------

