Electronic Indexers – How Is Cumulative Error Avoided?

[Neil WyattModerator @neilwyatt]

Posted by SillyOldDuffer on 01/06/2019 19:12:54:

Bresenham efficiency pays off when massive numbers of points have to be calculated as fast as possible. Spinning CAD models on a graphics screen requires huge numbers of calculations compared with a rotary table.

That was my point – Bressenham doesn't need fast processors and with floating point artithmetic units, it's idea for slow ones doing integer arithmetic.

Bressenham is optimal. it is inherent that it always rounds to the nearest point, but bear in mind if two points are equidistant different algorithms may choose different ones.

What can you precalculate with Duncan's method?

Neil

[duncan webster 1Participant @duncanwebster1]

I wasn't aware of the integer Bresenham, all the discussion last time this was aired seemed to assume floating point. I think the code for a dividing head cutting a number of teeth might be

dx = teeth;

dy = stepsPerRev;

D = 2*dy - dx;

loop()

{

wait_for_start_button();

if(D > 0)

{
step();
D = D – 2*dx;
}

D = D + 2*dy

}

I've tried this on a spreadsheet and it works, not as well as mine as it always rounds down the number of steps, but not a lot of difference. To make the sum less longwinded I took stepsPerRev = 500 (Neil's Y) teeth = 127 (Neil's X). In an ideal world, it would proceed in 3.937 step increments. This little bit of code above goes, 3, 4, 4, 4, 4, 4, 4, then back to 3. It was nearly a whole step out on the first step, and then caught up. I think mine would have started out on 4s and continued until it was just over half a step in front, then slipped in a 3. All a bit academic as in a real situation the 500 figure will be a lot higher and so there will be a lot more steps per tooth

The question is, is doing 1500 off if() and 1500 off D = D – 2*dx; quicker than doing one division. (1500 taken from my original example. Mind you as SOD points out there's plenty of time!

 

 

 

 

Edited By duncan webster on 02/06/2019 00:17:55

[Neil WyattModerator @neilwyatt]

Posted by duncan webster on 02/06/2019 00:15:59:

The question is, is doing 1500 off if() and 1500 off D = D – 2*dx; quicker than doing one division. (1500 taken from my original example. Mind you as SOD points out there's plenty of time!

No, but… If you do the division once and treat it as a constant how do you avoid cumulative error? (I'm assuming that you do an integer division).

+ Interesting that the 3 appears first, but as long as the same number of 3s appear the end result will be the same.

[Joseph Noci 1Participant @josephnoci1]

Sorry for this post in that is goes a little of-topic, but the posters have goaded me into it..Just because we are used to old-style processor, assembly programming, and squeezing the last electron out of that 8MHz Arduino module, does not mean we should not embrace the later, CHEAP ( and INEXPENSIVE) processors available. Some of us may be 'old' as well ( me a little too – post 60's…), but that does not mean we cannot apply our minds to modern thinking. I understand the challenge of getting the almost impossible to work on a small, slow, integer machine, but it has to be different strokes for folks – It does not mean that one applies a 'lazy' mind when using more capable hardware, and doing the job with 'brute force' – you will find Bressenhams just as intriguing and interesting as fighting integer arithmetic!

At any rate, It all depends what you are trying to do. As Dave said:

In the rotary table application the performance of long integers versus floats happens to be almost irrelevant because the calculation is only done once per-step and the computer spends an eternity waiting for the motor to turn the table and has plenty of spare time for sums!

So even a steam driven processor would work just fine in a basic indexing application.

However, try use that rotary table as the gear blank drive in a gear hobbing process on your mill, or as an ELS system, cutting 3mm pitch thread at 300RPM. I can hear most shouting that is silly anyway, but a half decent ELS system can easily do that! The benifit is a very clean, quality thread and if using a VFD on the lathe, you can let the ELS stop the spindle dead at the end of the thread, making threading to a shoulder a doddle..

BUT, all that takes a bit more than steam drive…

Hobbing a 10mm diameter MOD 0.8 gear :

Assume the hob turns at 400RPM, with a 1000PPR encoder on the spindle. The gear blank turns at 40RPM. Assume a 40:1 ration between stepper and blank ( the rotary able ratio..) – and Stepper drive set to 800steps/rev. For blank @ 40RPM, the stepper RPM-1600, so stepper pulse rate = 21KHz, ie, approx every 47us. The encoder pulse rate ( 1pulse gives 4 edges, to get good resolution in gear blank positioning) @ 400RPM = 2.666KHz = 375us between edges. So do whatever pulse rate generation calculations you need , receiving encoder interrupts every 47us, sending stepper pulses every 375us, and whatever housekeeping needs doing, and see how far a stem processor goes…Of course, cutting a 127tooth MOD 0.8 gear, everything slows down a lot…

Likewise for an ELS ;

Assume a 1000PPR encoder on the spindle, a 3mm Leadscrew pitch, threading @ 300RPM, and cutting a 3mm pitch ( just cause the sums are easier in the head if leadscrew pitch = pitch of thread to cut..) Also a 2:1 ratio between stepper and leadscrew, with stepper set to 800steps/s.

In this case we have 50uS between encoder edges, the stepper turns twice for one thread pitch = 1600 stepper pulses, giving a step pulse rate of 8KHz, ie, a pulse very 125us.

And you can do all this because… MIPS are cheap, FLOATING POINT is cheap, and you can spend the effort in adding useful features ( spindle stop at thread end..) rather than chasing the lost instruction pointer that was destroyed by the last POP of the STACK because memory is low, or you could not keep up with interrupt rates so the STACK overflowed, etc…

 

Duncan said:

Bressenham is all very well for clever people who have blindingly fast processors which can do floating point arithmetic quickly. Mere mortals like me just start at zero steps, work out how many steps it should have taken from zero to the next position as an integer, subtract the actual number of steps to the present position (it keeps track), subtract one from the other and move by that number of steps.

Duncan, I warrant that if you understand what you have done, you will just as easily understand Bressenhams!

 

My rant done…

Joe

Edited By Joseph Noci 1 on 02/06/2019 08:50:11

[SillyOldDufferModerator @sillyoldduffer]

Posted by Neil Wyatt on 01/06/2019 22:49:23:

Posted by SillyOldDuffer on 01/06/2019 19:12:54:

…

…

What can you precalculate with Duncan's method?

Neil

The calculation is:

nextSteps = ( (long)(divisionStepCount+1) * motorSteps + (long)rstatus.divisionSteps/2 ) / (long)rstatus.divisionSteps;

Elsewhere in the program, 'motorSteps' is calculated early on from the base step of the motor (200), the controllers microstep setting (16) and the worm ratio (90) – it never changes, and thus can be calculated once at compile time. Thereafter the compiler 'knows' it's a fixed value and might be able to exploit that to short-cut calculations later on. Likewise, although 'divisionSteps' can be changed by the user before pressing the 'Go' button, it is thereafter constant giving the compiler has another opportunity to reduce work. There are other 'speed tricks' as well; for sure the division by two is done by shifting a register (very fast), not division (comparatively slow), and 'divisionStepCount+1' is most likely done by incrementing a register rather than arithmetic.

I suggested compiler optimisation as an explanation for my observation that – in this program – Duncan's calculation executes in much the same time irrespective of whether float and long integers are used. It's an unexpected result on an Arduino. Normally integer calculations are significantly faster than floating point unless the computer has a hardware floating point accelerator, and the chips used in Arduinos don't have them.

Might have a look later at the Arduino IDE's compiler settings and the assembly it generates for this calculation. But I'd like to get the simulator working properly first so we can compare the results side-by-side.

Dave

[duncan webster 1Participant @duncanwebster1]

Posted by Neil Wyatt on 02/06/2019 08:32:29:

Posted by duncan webster on 02/06/2019 00:15:59:

….

No, but… If you do the division once and treat it as a constant how do you avoid cumulative error? (I'm assuming that you do an integer division).

 

….

You do the division once per tooth. Avoiding code and tricks to round to nearest it is

nextSteps = (stepsPerRev * toothNumber)/teeth.

then subtract the previous nextSteps and you know how many steps to take to the next tooth. stepsPerRev is for one rev of the dividing head and so is a big number, as is the number of steps between each tooth.

this is however getting a bit arcane. I've sort of understood integer Bresenham, it carries forward the error between steps. I just do it in a different way. From memory I think I'm only ever half a motor step out whereas Bresenham can be nearly a whole step out, but that is so small at the dividing head spindle I'm not going to get worked up about it. Clearly both methods work, so let's live and let live

I also take Joe's point, why not just use a processor with some clout? I'm currently trying to resist buying one as I'd have to learn a new IDE set up. Arduinos do everything I want, are easy to use, and have a huge library of things other people have done on the web so you can crib it. As has been pointed out, they do have their limits.

Edited By duncan webster on 02/06/2019 11:24:09

[SillyOldDufferModerator @sillyoldduffer]

Posted by Joseph Noci 1 on 02/06/2019 08:48:40:

Sorry for this post in that is goes a little of-topic, but the posters have goaded me into it

…

At any rate, It all depends what you are trying to do. …

So even a steam driven processor would work just fine in a basic indexing application.

However, try use that rotary table as the gear blank drive in a gear hobbing process on your mill, or as an ELS system, cutting 3mm pitch thread at 300RPM. I can hear most shouting that is silly anyway, but a half decent ELS system can easily do that! The benifit is a very clean, quality thread and if using a VFD on the lathe, you can let the ELS stop the spindle dead at the end of the thread, making threading to a shoulder a doddle..

BUT, all that takes a bit more than steam drive…

My rant done…

Joe

Not a rant at all Joe, I think this is another example of chaps having a violent agreement!

The main reason I write and play with Arduinos is because they are exceptionally well supported from the hobbyists point of view. Parts are easy to buy, the IDE is easy to set-up, and it's easy to up-load programs from PC to microcontroller. Though far from perfect, Arduino do a good job hiding many of the complicated details that might banjax a beginner! On the downside it limits the options, the processors are dated, the boards fixed, and the IDE probably hides too much stuff an advanced user might want to use. There's a point at which Arduinos stop being a good choice.

Coincidently last week Duncan pointed me at a couple of Electronic Lead-screw projects on Youtube. One of them explains that Arduinos aren't powerful enough, the other is happily running on an Arduino Mega. I'm trying to unpick why, but the first chap is calculating for a 4096 position rotary converter at 2400 rpm, whereas the other chap has 1024 positions up to 1400rpm. Not proved it yet but I suspect that the first chap has confused 2400rpm with 2400rps: it's the sort of mistake I make!

Even so, it's obvious an Electronic Lead-screw is a far more demanding microcontroller application than a Rotary Table. Squeezing one on to an Arduino will be hard work compared with one of the powerful alternatives.

Chap A recommends a Texas Instruments Launch XL development board; a powerful chip with two built-in rotary converter inputs in hardware. Nothing's ever easy! Unless I'm missing something, access to development information isn't straightforward: perhaps it comes with the IDE. Also, TI don't make it easy to buy development boards in the UK either. (TI's website made me jump through a few hoops before admitting there's a UK distributor!

Engineering is all about balancing compromises. Horses for courses…

Dave

 

Edited By SillyOldDuffer on 02/06/2019 11:25:18

[Neil WyattModerator @neilwyatt]

Posted by duncan webster on 02/06/2019 11:11:32:

Posted by Neil Wyatt on 02/06/2019 08:32:29:

Posted by duncan webster on 02/06/2019 00:15:59:

….

No, but… If you do the division once and treat it as a constant how do you avoid cumulative error? (I'm assuming that you do an integer division).

….

You do the division once per tooth. Avoiding code and tricks to round to nearest it is

:

:

I also take Joe's point, why not just use a processor with some clout? I'm currently trying to resist buying one as I'd have to learn a new IDE set up. Arduinos do everything I want, are easy to use, and have a huge library of things other people have done on the web so you can crib it. As has been pointed out, they do have their limits.

Edited By duncan webster on 02/06/2019 11:24:09

That's what I thought, from SOD's post I implied you only need to do division once.

Joe is quite right, but I like the 'eight bit assembler challenge' because just like when I was pushing BBC computer to the edge of the envelope I get the same (or greater) satisfaction from finding a solution as I would from solving a cryptic crossword. If I wanted easy I'd buy a solution

Neil

[Joseph Noci 1Participant @josephnoci1]

Joe is quite right, but I like the 'eight bit assembler challenge' because just like when I was pushing BBC computer to the edge of the envelope I get the same (or greater) satisfaction from finding a solution as I would from solving a cryptic crossword. If I wanted easy I'd buy a solution

Neil

True, but surely after a while the challenge is overcome – A cryptic crossword is tossed in the bin when done, unlike an indexer project…

If your challenge is purely of intellectual academic nature, then any means of meeting the challenge satisfactorily is the right one..However, I would say that your intellect would still be challenged maybe in new dimensions, by a faster tool..

If all you wish to do is play Tic-Tac-To, with the fewest assembly code instructions, limiting yourself only to AND and XOR operations ( I did this on an 8bit, 8pin PIC processor running at 50hz..) and not using more than 100 bytes, then that is a great challenge. It had me going for months. But when it was 'done' the point was lost – Tic-Tac-To is quite boring, so the culmination of the exercise was of little value – all it was was a mind challenge.

And if you used a 140MHz 32bit Nucleo Arduino lookalike, you could have done the same exercise, but maybe had 500 Tic-Tac-To games running together, and maybe add a random number generator to ensure no two game have the same strategy at any point in time…Challenges are what the mind makes of them!

This forum topic is supposed to result in a functional indexer for the fellow asking about it!

He may also be happy to 'buy a solution' if the concept and price is right!

Rant, rant..

Joe

[Joseph Noci 1Participant @josephnoci1]

Daves Post:

The main reason I write and play with Arduinos is because they are exceptionally well supported from the hobbyists point of view.

Dave, the Nucleo is also fairly well supported. It has a free, very good IDE, free compilers, lots of libraries with all the usual stuff, and since it is the STMF4 series processor, there are hoards of applications/source code, etc out there. It can directly interface to small video cameras that give the industry standard 14bit digital o/p, and there is a lot of software for processing that image – nice for machine vision and CNC tool positioning, etc. The Nucleo range is also easy to get, and very inexpensive. around US$15.oo to US&22.oo, depending where. I realise the baby Nano is a few dollars, and my do the indexer only justice…

……..

Coincidently last week Duncan pointed me at a couple of Electronic Lead-screw projects on Youtube. One of them explains that Arduinos aren't powerful enough, the other is happily running on an Arduino Mega. I'm trying to unpick why, but the first chap is calculating for a 4096 position rotary converter at 2400 rpm, whereas the other chap has 1024 positions up to 1400rpm.

Your Example: a 4096 pulse Rot Encoder at 2400rpm gives 40 RPS = 164KHz pulse rate = approx 6us between pulses. A Nano at 8MHz will execute around 50 instructions in that time. And you have to calculate all you need, send stepper pulses to the leadscrew drive, accelerate said stepper on startup, etc..all in 50 instructions before the next pulse. You can reduce the encoder resolution, but you get to a point where threads start to suffer..

Not proved it yet but I suspect that the first chap has confused 2400rpm with 2400rps: it's the sort of mistake I make!

Even so, it's obvious an Electronic Lead-screw is a far more demanding microcontroller application than a Rotary Table. Squeezing one on to an Arduino will be hard work compared with one of the powerful alternatives.

In the end, you do what you are comfortable with, but I was never happy staying in a comfort zone for long..

Joe

[SillyOldDufferModerator @sillyoldduffer]

Posted by Joseph Noci 1 on 02/06/2019 11:56:52:

Joe is quite right, but I like the 'eight bit assembler challenge' because just like when I was pushing BBC computer to the edge of the envelope I get the same (or greater) satisfaction from finding a solution as I would from solving a cryptic crossword. If I wanted easy I'd buy a solution

Neil

True, but surely after a while the challenge is overcome – A cryptic crossword is tossed in the bin when done, unlike an indexer project…

…

Joe

Not sure it's that simple, though I do see the world in complicated shades of grey!

By doing cryptic crosswords Neil exercises his brain, and – like muscles – brains improve when they're stretched. Although the solution ends up in the bin, the way the crossword was solved is retained in Neil's head and will be reused later. He practices converting data into information and converting information into knowledge, which process has general application.

I imagine Neil assembling a magazine is a form of puzzle solving. Most engineering is a form of puzzle solving. Solving tic-tac-toe on a tiny computer is worthwhile because the techniques used can be made into patterns and applied to real problems.

Finding the best way of stretching one's brain is difficult. Not everyone enjoys academic challenges like cryptic crosswords, maths, science, programming or accounting! Others stretch their brains by doing practical work, which challenges another part of our bone-heads. I enjoy messing about in my workshop slightly more than I enjoy playing computers, but on close examination the two activities have a great deal in common. It's why I enjoy reading about Clive's Bees as much as Joe's Nucleos.

Dave

[SillyOldDufferModerator @sillyoldduffer]

Posted by Joseph Noci 1 on 02/06/2019 12:11:47:

Daves Post:

…

In the end, you do what you are comfortable with, but I was never happy staying in a comfort zone for long..

Joe

Oh all right, you've persuaded me. I can get a F401RE with no problem, and it looks like I can use a no-charge Web based online compiler to program it. (This appeals because I prefer Linux to Windows, though that's not essential.)

Is that a reasonable way of making a start? I don't have a particular project in mind, the goal is getting to grips with the environment.

Ta,

Dave

[Joseph Noci 1Participant @josephnoci1]

Hi Dave.

I agree totally re Brain Exercise. I firmly believe it is one of the best defences against Alzheimer's.

I suppose all I am trying to say is, find new ways of exercising that muscle, rather than staying stuck in Ye Olde Wold…

I find its more interesting to place my own limits on how I might perform a task, rather than let the hardware limit me from the start..And that is no less taxing on the brain!

Dave, the Nucleo stuff is MBED compatible, so your compiler choice is great. We use a free compiler that is just a compiler, as we code from the ground up, ie, not in the MBED world and we do not use an IDE , which allows us greater freedom, but that does tax a newbie's patience when learning..

You choice of Nucleo is Ok, although if you can, try for the F446RE – has has lot more capability, more memory, more uarts, Video capability, blah, blah…In other words, unlikely that you would overtax the board ever..

As RS components UK the '446 is half a pound more than the '401 at farnell, also, the '401 at RS is half a pound less than the '401 at Farnell..( Farnell does not seem to have the '446 in stock).

The programmer is part of the Nucleo board, and you just download and install ST-LINK ( the latest one) from the STM web site. Use a USB cable to your PC and program..

Having TOTALLY stolen the thread that started all this, I crawl off into my corner and apply 40 lashes. I did EXACTLY what I have ranted about others should not do – divert a thread into oblivion…

apologies..

Joe

[SillyOldDufferModerator @sillyoldduffer]

Apologies from me too. If it helps soften any annoyance, Williams' question has caused me to spend £13.64 and plunged me into another bout of new technology misery!

Thanks Joe for the hint about not using an IDE; that's how I prefer to work. Digging a little deeper looks like Nucleo is supported by gcc, which is my usual choice. When the board arrives I'll look closer into ways and means.

Cheers,

Dave

[Joseph Noci 1Participant @josephnoci1]

Dave, I will ask my good Wife to dig out the roots of the compiler we use – also a free download, and let you have that info as well. I believe I still have your email so will continue discussion via that route, when required..

Joe

[Neil WyattModerator @neilwyatt]

Posted by Joseph Noci 1 on 02/06/2019 14:22:36:

I suppose all I am trying to say is, find new ways of exercising that muscle, rather than staying stuck in Ye Olde Wold…

I bet you use C. C does all the interesting bits for you.

You miss the point though, a bit like telling a cyclist he's be better off using a motorbike, because he can travel faster and not break into a sweat.

There's a joy to working in 8-bit assembler and it lets you develop a skill set that's simply not applicable to more sophisticated processors whose capabilitities effectively demand that you use more sophisticated tools.

There's also huge satisfaction from achieving things that appear to be beyond the capabilities of the hardware.

I am inspired by stories like this one – I have an original copy of Speech! and it fascinated meback in the 80s, it was great to discover the story behind it.

bbc.nvg.org/doc/Speech.html

Neil

Edited By Neil Wyatt on 02/06/2019 17:26:14

[duncan webster 1Participant @duncanwebster1]

as this has drifted well away from the original the mods might want to start a new thread, if so be my guest. I put this forward in total ignorance hoping someone will help me to understand

First:
I can see that if you are driving a stepper motor from pulses generated by the spindle you want more spindle pulse than stepper pulses. If I'm trying to cut a 3mm pitch with my 3mm leadscrew the ratio is 1:1. Again postulating a 200 step motor doing 1/8 steps (ie 1600 pulses per rev) and a 2:1 belt drive just to pick figures out of the air, one rev of the leadscrew is 3200 pulses, so 4096 pulses from the spindle sounds reasonable. However my understanding of Mach3 (very limited indeed) says that it has one pulse per spindle rev. Does this mean it is doing time interpolation?

Second:
I'm not likely to screwcut at more than say 200 rpm, but I don't need to synchronse the leadscrew to the spindle closely for doing plain turning. Does it make any sense to have a second pulse generator (magnet on the drive pulley) for high speed, then use this to derive spindle speed and just drive the stepper based on time? Joe will just say use a fast processor and get on with it no doubt.

Third:
Joe I hope you realise what frustration you have released in the Webster household as I contemplate trying to get to grips with these new boards! I don't actually have a need, but the challenge is there. I just about coped with PICS where turning a pin on involved mantras using logical OR statements, but setting the thing up involved wading through 200 page manuals, and I'm not getting any younger!

[John HaineParticipant @johnhaine32865]

Mach 3, when it gets an index pulse at a known position, just starts accelerating to a velocity that it calculates from the index pulse frequency (from which it has computed the spindle revs), will cut the required thread when it hits the material. When it has moved the Z axis the requisite distance it pulls the tool out, stops feeding, and returns to the known position. If the spindle slows down when cutting starts, it's too bad! LinuxCNC has the index sensor giving 1 pulse per rev and also an encoder with much higher resolution, and continuously matches cutting speed to spindle speed.

[Joseph Noci 1Participant @josephnoci1]

I am still in pain from my 40 lashes, so am wary of leading up to another 40….

However my understanding of Mach3 (very limited indeed) says that it has one pulse per spindle rev. Does this mean it is doing time interpolation?

You are perfectly correct Duncan. Mach assumes the spindle speed is constant from thread pitch to pitch, which works most of the time. Generally the machines inertia helps that be so, but where problems arise are at the start of threading. The single index fixes the start of the thread, and that must remain fixed in time and axis space, else you cut threads with mutliple helixes. Consider the threading process:

Setup the tool near the workpiece, set DOC, spindle speed, etc, and turn on the spindle. Now, if yor machine has no VFD, and the motor speeds the spindle up very rapidly, the stepper has to keep pace with the spindle on the next thread, ie, the stepper acceleration must ensure the tool arrives at thread start co-incident with the spindle index pulse. The stepper has to accelerate the carriage, and all its inertia, carriage and leadscrew nut friction, etc, sufficiently fast to ensure the spindle speed and carriage position remain coupled, as though they were 'geared'.

Should the stepper not keep up, and lose steps, you have to insert an acceleration curve into the stepper pulse rate ramp to prevent said problem. However… you know have no way of knowing where you are in relation to the SINGLE index pulse from the spindle…and so you lose sync and cut multiple threads..

The problem is made worse with an increase in spindle RPM and/or thread pitch. Mostly, with the sort of hobby threading we do, especially at rpm below say 200, and pitches around 'maybe' 15TPI min, we can get away with one index pulse, on most of the smaller machines. Machine with powerful motors get up to speed quicker, and the problem appears sooner..If you have a VFD you can all but eliminate the issue by accelerating the spindle more slowly. But, the type of implementaion as in Mach, has a problem with that – since it computes spindle RPM from index pulse period, and since it has to start the stepper pulse synced to the index pulse, Mach has no real way of knowing when the spindle is at speed, especially if the spindle accelerates more slowly. It cannot wait a while till the spindle is at speed before sending step pulses, as Mach would have to then accelerate the stepper to speed almost instantly , or at least within one spindle rotation. A very dodgy implementation..

What I did in my ELS implementation was – use a spindle encoder with 4096 edges per ev for inter pitch interpolation to generate stepper pulses. Use the single spindle index pulse to determine thread start and keep that cast in concrete for that thread cutting session. Then at thread start I count encoder pulses while generating accelerating step pulses to get the carriage up to speed. But, because the carriage is lagging behind in position ( due to stepper accelaration) , I will not get to the thread start point , in time. So, we accelerate the stepper faster, beyond the speed needed to cut the current pitch, to recover the lost pulses, and hence the lost time spent accelerating. The pulse count to the stepper, and the pulse count form the encoder both feed a software up/down counter. When the Spindle RPM has reached constant speed, we then look at our up/down counter, decrementing the stepper pulse rate, until the counters are equal ( delta is zero) , and we know we are at the correct thread start point.

All this requires that we start the spindle for threading, with the tool at least two thread pitches away from the work piece, for the acceleration catchup. I am able to thread at 1500 RPM for a 0.5mm pitch thread , and at 400RPM for a 5mm pitch..The latter being rather scary…carriage moving at 33mm/s. Obviously those are insane and undesired speeds – I regularly cut 1mm pitch threads at 500RPM though, with nice clean threads in Stainless.

I have added a feature that allows me to set the start of thread and the end of thread (right or left handed) and when thread endpoint is reached, the ELS stops the VFD 'dead' ( withing a turn or so..). This allows distracted (!) threading with no crashes…even up to a shoulder. But this is only practical at lower spindle RPM ( sub 2 or 300RPM) since the resulting mechanical stress at high inertial speeds worries me..DONT DO THIS WITH SCREW ON CHUCKS!!

That fear resulted in adding another feature , letting the spindle continue running (akin to snapping the half-nut open at thread end), but stopping the leadscrew drive stepper. Press rewind to get the tool back to thread start, and press thread to continue. And it is precisely here where we need the stepper acceleration process explained above, as the spindle is already at cutting RPM, and the stepper would have to accelerate instantly to get the tool in place at the start of thread, synced to the spindle single index pulse…

Linux CNC 'tries' to implement this same process, but the clan missed the boat.. It has warts and can bite you in the backside if not careful. I did raise the issue with the devs, who said thanks , we will look into it, but the latest but one release still has the issue…It works ok, 99.9% of the time, but you can crash a machine..

What a long story…

Well Duncan, if Ye seek sympathy from me for you New-Tech Adventure……Have Fun!

I too just get older, but all that does is make me try even more new stuff every day – Technology development has been exponential while the years left to me to play with that tech are still only linear, and I have a LOT to learn, do and experience.

regards

Joe

 

Edited By Joseph Noci 1 on 02/06/2019 21:24:49

[Joseph Noci 1Participant @josephnoci1]

Sorry, I did not respond to your second issue…

Second:
I'm not likely to screwcut at more than say 200 rpm, but I don't need to synchronse the leadscrew to the spindle closely for doing plain turning. Does it make any sense to have a second pulse generator (magnet on the drive pulley) for high speed, then use this to derive spindle speed and just drive the stepper based on time? Joe will just say use a fast processor and get on with it no doubt.

I presume you mean when surfacing with carriage feed applied.This is in effect threading, but the constraints are hugely relaxed – Thread start has no meaning, and all you really want is a constant feed for good finish. I ditched the concept of syncing the carriage to spindle rate, and all I do is have a POT that sets feed rate, ie, stepper pulse frequency, from 0 to 5mm/s. That feed can work with spindle on or off, so reversing the carriage under feed to cut one direction only is possible. Also, changing feed rate while cutting to see if an improved finish can be got is easy. The spindle encoder pulses are not used.

If you sync the two rates, then to change feed speed you have to stop the machine, and change what is effectively a thread pitch…the same as you would do if you had to fiddle with changes gears or the Norton Box..This way it's just a turn of a knob..

Joe

[Anonymous]

Posted by SillyOldDuffer on 02/06/2019 11:25:06:

Engineering is all about balancing compromises.

Actually engineering is all about money, in the sense of what will a feature cost and will the market be prepared to pay for it?

Andrew

[duncan webster 1Participant @duncanwebster1]

Thanks Joe, I've sent you a pm

[John HaineParticipant @johnhaine32865]

Mach 3 doesn't work quite like that, in that the spindle is running continuously throughout. You start with the tool at some known position say 1 mm clear of the end of the work, adjusted for the right doc for the first pass. Then it accelerates at a known rate to the threading speed to give the desired pitch, started by receiving an index pulse. Af the end of the thread, the spindle keeps running, the tool withdraws while still being fed at the thread rate over usually a quarter revolution, then the feed is s topped though the spindle continues. The tool then runs back to the start position, and waits for the next index pulse to start again. It depends on the initial acceleration being fast enough to get to the right speed before reaching the work and always following the same profile so the tool is always starting the cut at the same point. This means using an acceleration which is well within the maximum capability of the Z drive and allowing sufficient lead-in. It also needs enough inertia in the spindle drive and a constant speed motor, or a closed-loop speed control with tight regulation, so the spindle keeps going at a constant rate.

People are sniffy about Mach3 threading, and I've had a couple of disasters with it, but once you understand its peculiarities it works pretty well.

Not a good photo, but the er16 chuck for my Acute grinder was threaded for its nut using Mach, without a hitch, on my cnc'd Super 7.

[Joseph Noci 1Participant @josephnoci1]

John Haine said:

Mach 3 doesn't work quite like that…………….

…………. It depends on the initial acceleration being fast enough to get to the right speed before reaching the work and always following the same profile so the tool is always starting the cut at the same point. This means using an acceleration which is well within the maximum capability of the Z drive and allowing sufficient lead-in

In essence wot I said…!

Joe

[SillyOldDufferModerator @sillyoldduffer]

Posted by Andrew Johnston on 02/06/2019 23:38:44:

Posted by SillyOldDuffer on 02/06/2019 11:25:06:

Engineering is all about balancing compromises.

Actually engineering is all about money, in the sense of what will a feature cost and will the market be prepared to pay for it?

Andrew

Very much so! At root money decides whether things worth making or not, but it's not rock solid in that innovations have to be sold to a public who might reject it out of hand or go mad for it. Risk is part of the game too.

Nonetheless, cost is usually by far the most important issue facing professional engineers. For example if a new railway is proposed, engineers play a key role in cost estimating so that the huge amount of money needed can be borrowed and repaid without busting the whole operation. Then, unlike politicians who promise results without knowing how they'll be delivered, engineers have the skills needed to manage the project and deliver a practical solution.

But I was thinking of compromise during technical design and development, where the engineer balances availability of skills, tooling, space, and materials to get results, often trading-off as necessary. Here professional and amateur engineers often follow the same disciplines. However, the drivers and goals of amateur and professional engineers are likely to be different especially when it comes to time and money. If Andrew were daft enough to employ me, he'd find I work very slowly, wander off, make mistakes, am untidy, and would care nothing about Andrew's urgent need to balance his books. In short, I'm indulging an interest in engineering, not doing it to make a living.

Dave

[Author]

Posts