Machsupport Forum

Mach Discussion => General Mach Discussion => Topic started by: simpson36 on April 09, 2009, 10:05:18 AM

Title: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 09, 2009, 10:05:18 AM

I have a stepper powered 4th axis (shown in the show and tell section) that I am considering converting to servo power so that it can be used on the mill as a pseudo lathe.

Currently I have a 10:1 reduction and a 10,000 RPM DC motor to use which would net a max 1,000 RPM which is adequate for my purpose. I can install the encoder wither on the motor or on the belt drive idler.

First, I wonder if anyone is doing something similar and if it is considered viable.

Second, if I put a 200 step encoder on the motor, there would be a max of 2,000,000 pulses per minute. What kernel speed would be needed for that and in general what is the relationship between the encoder steps and kernel speed?
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 09, 2009, 10:16:20 AM
A 200 line encoder would be 800 pulses per encoder rev so at 10,000 rpm that would be  8,000,000 pulses per min . Divide that by 60 and it is 133,333.3333333 pulses per second or 133.33333333 KHz kernel you would need. Only way would be with a SmoothStepper or some other external motion controller.
Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: vmax549 on April 09, 2009, 11:01:02 AM
BUT if you mounted the encoder on the spindle shaft it only turns a MAX of 1000 RPM

SAY 13khz or so (;-) DOABLE

(;-) TP
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 09, 2009, 11:03:33 AM
BUT if you mounted the encoder on the spindle shaft it only turns a MAX of 1000 RPM

SAY 13khz or so (;-) DOABLE

(;-) TP

Depends on backlash, motor might not be too happy if there is even just a little
Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 10, 2009, 05:17:46 PM
Timing belt drive with idler, so no backlash, but i can see the idea needs more thinking through.

A 200 line sensor puts out 800 pulses . .  interesting . . quadrature?  The formula seems pretty straightforward, thanks!

Putting a sensor on the axis is not practical, but I could either use an encoder with less steps . . say 50, and put the encoder on the motor, or run off a larger idler and gear down to the encoder. I have seen huge machine tools that wof that way with the encoder driven off the lead screws with tiny timing belts.

From the speculative responses so far, I take it that a servo driven 4th axis/pseudo lathe is not common?
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: vmax549 on April 10, 2009, 09:42:27 PM
THe other problem will be that the 4th axis "as is" cannot continously spin like a lathe . You will have to swapaxis with the spindle in order to make it work (;-)

(;-) TP
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 10, 2009, 11:58:36 PM
There are a couple of ways around the continuous spin issue. As I recall, though, one method got broken in .043 and is probably still broken since the rev number has not changed.

Basically, you just imput an outrageous number of degrees to rotate and then reset to zero for the next cut. There is likely some maximum number of degrees you can command, but I didn't fool with it long enough to discover that and other details.

Perhaps Mach will add a 'run continuously' type of command to the program or smooth stepper migt accomplish the same thing. It is a common function in machining centers, so the capability exists, just not in Mach at the moment, I suppse.
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 11, 2009, 04:54:15 AM
Commanding a large number I suspect wouldnt work , if for example you said G1 A1000000000000000000X2Z3 your X and Z moves would be extremely slow and not complete until the spindle had reached its position.
 Swap axis should be easy enough to accomplish although at this point in time I have never tried it I will be using it for rigid tapping if I ever get the mill completed.
Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 11, 2009, 11:21:25 AM
The moves would happen simultaneously, unless I am missing something. It seems to me that for turning, feed per rev is the way to go, so it would be a simple calc.

Say you want to program a 1" length of cut at .003" per rev. You simply program 1/.003 turns for the move.

  Set depth of cut increment

  Call sub

  G1 A120240 (334 turns x 360 degrees)  X1

  Back out of the material a bit

  G0 X-1

  Reset A to zero (I don't recall the code off hand).

  Return from sub.


Note: it's been a while, but I seem to recall that rev .043 is broken and A will not reset to zero. I posted that info, but I don't know if this is fixed yet.

Threading is similarly simple, you simply set the 'feed' to the desired pitch.  I've already done that . . . just didn't have enough power with a 600oz-in Stepper to drive the 4th axis, hence the need for a servo motor.


Just to add one more thought: a servo driven 4th axis would (theoretically) solve the threading problems Mach seems to be having using a single pulse per rev indexer. 
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 11, 2009, 11:56:54 AM
Yes that is doable and is what I will be doing to get rigid tapping if the SS doesnt support it when I eventually get the mill finished. It would however be a lot of working out and coding. The easiest option would be to set up two profiles, one a mill and the other a Turn and when you wanted to do lathe work just start up the Turn profile, the A axis would be set as a spindle in it.
Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 11, 2009, 12:03:30 PM
Oh and as for the servo driven spindle, that wouldnt help unless you set it as an A Axis because Mach can still only use a single index pulse rather than full encoder. The threading is a mystery but it all seems to boil down to either computer stability or spindle power at the moment, I have never had an issue with threading on the lathe, previously it had an induction motor and now it has a servo. With the servo the spindle speed in mach is rock steady  and even when I had the incuction motor is was as well (as far as I can remember) I have also had two different mobos in this. I am sure Art will get the better of it at some point in time.
Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 11, 2009, 01:31:21 PM
I'm not a fan of the single point threading scheme used by Mach and it does not surprise me that it is and has been problematic. I have been following the discussion on threading and frankly I don't see how threading will ever be reliable when trying to compensate for spindle speed deviations using a single pulse per rev when the variable speed controllers also have built in compensation that Mach is unaware of, but that's another topic altogether.

I considered your solution of two Mach setups using one to turn and one to index, but that will not suit my purposes. YOu would understand if I explain what I want to accomplish.

The part I have in mind has numerous steps requiring several setups and several programs. One of the problems is (speak of the devil) threading, but that's easy to resolve. The unresolvable problem come sin turing down stock from 3/4" to .4" for about .6" from one end and then cutting flats 90 degrees apart on the OD at the end.

With a turning tool, a drill bit and a tap setup in a plate attached to the mill head, I can turn down the OD, bevel te end, drill a hole and tap the end. Then, with the same setup and thesame program, continue on to index and cut the flats with an end mill in the mill spindle.

There is one last operation that I could also do with the setup, which is cut a slight crown on the other end using a cut-off tool, but I know I will n ot have enough power or rigidity to do that. BUt I'll settle for doing the other stuff in one swoop. It now takes several setups and several programs and manual tapping of the hole. 

This is a hobby for me, but I like a challenge and making a 'mini machining center' of sorts would certainly serve that purpose  :o

Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: vmax549 on April 12, 2009, 10:27:10 AM
YOU can do what you want with what you have with the 4th as is.

The problem you will have with code is once you start the a to rotate NO other moves can start until the A completes its move.(;-)

But you can program it as one move but it is not conventional in any manner of code.

Yoou can also run the spindle and rotate the A to mill the shaft down to .6 same as cutting with a singlepoint tool. Then to do a finish cut and change to a 60deg v bit  thread in the same manner.

It is the way you have to code that will be very different but possible.

(;-) TP
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 13, 2009, 01:49:51 AM
I'll try cutting the barrel down with the end mill next time I get the rig set up. That's an interesting idea. In this case, the threads are internal, but your idea about the v tool in also interesting.

What I am confused about are the comments that the A axis has to complete before any other moves. That's not how it works for me. When I program G1 A360 X.1 for example, BOTH moves happen simultaneously.

That's how I single pointed these (external) threads on the rig:

(http://www.thecubestudio.com/pictures/CNCmillConversion/GrindingCupHolderWEB.jpg)

Originally, I built the rig only to be an indexer, and in that capacity, it works perfectly. Driven by a 900 oz-in stepper, it  just does not have enough power or speed to do other tasks like threading (it stalls easily) and turning (not fast enough), hence the idea of repowering it with a servo motor.

This is how the drive is arranged except that I have since installed a wider belt:

(http://www.thecubestudio.com/pictures/CNCmillConversion/4thAxisBeltWEB.jpg)

Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Dan13 on April 14, 2009, 05:39:39 AM
Terry,

How do you use that SwapAxis approach for rigid tapping? I have now a servo motor on my lathe's spindle and I would like to try this approach. I have pins 7 and 8 set as the spindle's step and direction signals respectively.

I tried to set the same pins for the A axis and thought I could program either the A axis to move or the spindle to rotate. But the SS doesn't support setting twice the same pin.

I also tried setting different pins for A (14 and 16) and connecting them to the servo drive as well (in addition to the 7 and 8), but didn't work neither.

Thanks,
Daniel
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 14, 2009, 09:56:10 AM
I'm not sure who Terry is, but I'll take a crack at an answer.

The idea, I believe is to have multiple Mach setups and use the one appropriate for what you ware doing.

For example you would have one setup where pin 7 and 8 are the spindle and a second setup where 7 and 8 are the 'A' axis.

I'm not sure how to accomplish starting Mach with different configurations. It may involve starting the program with an argument, renaming the configuration file prior to launching Mach, or simply having two installs of Mach.

Incidentally, I have now probed Mach's limits (software only) with 'A' as a spindle. The 'A" axis went to around 40 MILLION before I stopped it. Should be plenty for any normal work, I should think.

Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Dan13 on April 14, 2009, 11:35:53 AM
I remember Terry once said on another thread here that he had used this approach successfully, that's why I referred to him.

What you suggest is using different profiles, one for rigid tapping with A axis and one for turning operations. I don't think that was what Terry was using, as this is not very practical. I remember he said he was using SwapAxis, but how particularly?

Daniel
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 14, 2009, 12:01:49 PM
Yes that is doable and is what I will be doing to get rigid tapping if the SS doesnt support it when I eventually get the mill finished. It would however be a lot of working out and coding. The easiest option would be to set up two profiles, one a mill and the other a Turn and when you wanted to do lathe work just start up the Turn profile, the A axis would be set as a spindle in it.
Hood

Again, I don't know who Terri is, but I was remebering the above comment from earlier in this thread from 'Hood'

Two profiles seems like a viable solution to me. What would make that solution impractical in your opinion?

As to the axis swap, I have written one program that does this sucessfully, but it was a real mind bender to get it right. Up is down, left is up, right no longer exists, that type of thing . . LOL!

Art is hard at work modifying the threading code for Machturn, so maybe the objective can be met more easily with whatever new capabilities he manages to stuff in there.




Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Dan13 on April 14, 2009, 12:24:08 PM
Different profiles approach is not practical since my goal is not just to rigid tap, but rather do the rigid tapping as part of the gcode program to produce a finished part. I want to turn, drill and tap with the same gcode.

Here is the link to the thread where Terry mentioned he had used this approach successfully:

http://www.machsupport.com/forum/index.php/topic,9582.0.html

Daniel
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 14, 2009, 01:31:43 PM
SwapAxis is, as far as I know not implemented in the SmoothStepper.
Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Dan13 on April 14, 2009, 01:41:23 PM
SwapAxis, as for itself does work with SS - I can swap Z and X axes for instance, and it behaves as if I swapped their pins under ports&pins.

The problem is, I can't connect both A axis pins (14,16) and Spindle pins (7,8) to same input on the AC driver. It is like if I interconnected those pins between themselves. So what is the idea of SwapAxis?

The easiest way would be to just assign same pins to both A and Spindle, since I'm not going to use them both at the same time, but it doesn't work this way - only the A axis works, but the spindle doesn't rotate...

Daniel
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 14, 2009, 04:03:23 PM
SwapAxis, as for itself does work with SS - I can swap Z and X axes for instance, and it behaves as if I swapped their pins under ports&pins.
Quote

I was meaning for spindle specifically, but again I am not sure I just seem to remember Greg, Art or Brian mentioning it.


The problem is, I can't connect both A axis pins (14,16) and Spindle pins (7,8) to same input on the AC driver. It is like if I interconnected those pins between themselves.

Ccan you explain further?
Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Dan13 on April 15, 2009, 02:20:50 AM
Hood,

You were right, the SwapAxis doesn't work at all with the SS. I must have tested it with PP before, when I thought it was working. I've just tried to SwapAxis X and Z, and it didn't work. Changed to PP and all was working.

And I was stupid... you don't have to connect both A axis pins and Spindle pins to the drive input. You only have to connect the spindle pins and once you use the SwapAxis, the spindle pins become the A pins. It does work with the PP. I need to find a way to do this with SS though...

Daniel
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 15, 2009, 03:17:03 AM
You will have to wait until Greg implements it I think, however I am guessing that what we really need is the getting  the axis movement sync'd to spindle encoder, Greg has said he will be trying to do this at some point in time, just time is not a commodity that Greg has a lot of ;D
 I suspect you might be better looking at getting/making a floating holder if you are requiring tapping any time soon.

Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Dan13 on April 15, 2009, 03:46:30 AM
Yes, I need the tapping soon... I have a job in delrin and I wanted to test this approach. A floating holder is an option, but don't think it's good for my tiny Emco.... remember my tool turret? It has 10mm bores for ID tools. I think a floating holder will be too big for my turret.

As it looks now, Greg is not going to implement rigid tapping any soon :(

I think there might be simple work around - if I define the same pins to both A and Spindle, then I can use one at a time. Problem is, SS seems to be blocking this kind of setting. If setting so, I can move the A axis, but the Spindle won't rotate. I think it might be an easy fix for Greg...

For now, I'll have to use this same approach of defining same pins for A and Spindle, and disable the A under Ports&Pins each time I need the spindle, enabling it just when needed. It is a pain to do - will have to split the gcode.

But first let's see if I can use this approach of commanding Z and A move to accomplish rigid tapping. I need to tap M6 in delrin.... hope my spindle has enough power for M6 without being synched to the Z. The spindle does lag a bit under load, before it catches up... hope the load will be just small enough and won't affect the tapping. I only have a 4-flute hand tap, I wonder whether to do the tapping in pecks or whole the way down as you would do with a spiral tap.

Daniel
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Dan13 on April 15, 2009, 05:50:33 AM
OK... Just tried it and it worked perfect. I set the A axis so that one unit is one revolution, and programmed as follows:

G1 Z-20 A20 F150
G1 Z0 A0

Got what seems to be perfect threads. The spindle motor hardly felt any load at all with the M6 tap in delrin. I probably could even go faster than 150mm/min, but didn't have the courage to try ;)

Now I have to find a more intelligent way of doing this, instead of disabling and enabling the A axis under Port&Pins each time.

Daniel
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 15, 2009, 05:53:17 AM
Not sure if it works for all motion but there are oembuttons to inhibit axis, never tried but might be what you are looking for, ie write a macro to do the button and have the number of the macro in your code.

Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Dan13 on April 15, 2009, 06:00:16 AM
Yes, I know, it's OEMbutton 253 to disable A axis. It does disable the axis but the spindle still won't work - you must go to Ports&Pins and disable it from there.

Any other ideas? Another OEMbutton?

Daniel
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 15, 2009, 09:31:40 AM

Now, here is a new idea that occurred to me for a possible 'swap' method:

My spindle irection is changed by a Mach controlled relay on the DC power to the motor and it workes fine. I don't see why a similar setup could not switch the source of the power as well. Position 1 to the VFD (controlled by Mach) and then Position 2 to the  A axis output from the servo drive?

With this scheme, You would need only one Mach setup and could even switch the motor's power source with a Mach controlled relay. You would have speed control for turing and and indexing for single point threading when you run as a spindle and then switch the motor to A axis power for the other functions.

In my case, the servo drive yould be a Geckodrive 320 that is limited to 80v 20A which is probably not nearly enough for Hood's big motor, but for appropriate servo motors, unless there is something I'm missing, this seems like a workable solution.

Note that the above is for a lathe. For my purpose, I need both the mill spindle and 4th axis active at the same time.



Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Dan13 on April 15, 2009, 12:14:12 PM
You're right, I could use a hardware relay to switch from A axis to Spindle, but I don't want to do this at this point. I want to find a software solution to this. The problem is that the software guys keep saying they are just about to fix the problem, causing us not to want to do any fancy hardware changes. If someone of them were to tell us it isn't going to happen, I'm sure everyone were looking for other solutions.

Daniel
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 15, 2009, 12:51:25 PM
You mentioned you were in a hurry.

In a hurry + waiting on software guys = how old are you now . .  you may not live long enough . . . ;)

If you did rig a DPDT switch, you could prove the theory, get your immediate need satisfied, and it would not interfere with any miracles that come down the road from the programers.

Just a thought . . .
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Dan13 on April 15, 2009, 02:26:37 PM
You are right, but arranging a hardware solution would also take time...

As I said, I think it should be an easy fix for Greg to enable setting same pins for two axes. I will see first how it goes with this software fix...

Daniel
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 15, 2009, 03:45:39 PM
I'm a new kid on the block, so I'm afraid I don't know all the players around here, but I think I recall the name Greg being associated with the smooth stepper.

Just so I have this straight in my mind (I'm easily confused  :'()  . . .

The hold up is with implimenting something in smooth stepper, not in MACH, and the operation at issue here is hard tapping on a lathe. Is that correct?

If so , could someone elaborate on this a little for those of us who are newbies?

Thanks.
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 15, 2009, 04:16:12 PM
Yes Greg is Mr SmoothStepper :)

SwapAxis is not at this time supported with the SmoothStepper (possibly will soon but no promises, depends on complexity)

The SmoothStepper protects you from assigning the same pins for different axis but that is what Daniel is wanting as he can do a workaround to use the spindle as an A axis by doing that.

Yes rigid tapping or even indexing of the spindle is the goal.

Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 15, 2009, 04:47:02 PM
Thanks, Hood, that's a bit clearer.

I've done a fair amount of programming in my younger days (back when you HAD to because there weren't numerous apps for every possible need as there is today), and just this morning, I got a chance to watch some of the MACH tutorial vids and got a peek at the scripting.

My goal is to add a fully capable 'A' axis spindle to my little mill. Since machining centers have long had a similar arrangement, it stands to reason that I won't exactly have to re-invent the wheel to get that working.  I just need to do some more homework on the subject and build something to test.

Based on what I have learned so far, I'm inclined to go forward with my intention to abandon the current single pulse indexed variable speed spindle scheme altogether and just move forward with a full servo driven A axis and just work out the programming. When I have more time to research MACH's scripting and Brain capabilities, I'll have a better idea of how automated that process can be.

I may be mistaken on this as I only had a moment to peruse the videos, but it appears you can replace at least some of the MACH G-code interpreter with scripts. Certainly you can make up totally new commands via the scripting facility.

All that is missing is a command for continuous spinning of the 'A' axis for general turning . . and  . . . (famous last words) . . that looks doable to me at the moment.

Bottom line is that all of the pieces already exist to build a functional soultion for my purposes. It is only a question of how automated the G-code 'conversion' can be made.





Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 15, 2009, 05:35:20 PM
Are you using the SmoothStepper?
Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 16, 2009, 05:31:43 AM
Not using smooth stepper at this point. I'm not seeing an advantage to it in my specific situation. Note that I am not experienced in CNC so that should not be interpreted as a negative comment.  

I looked more into the (original topic of this thread) issue of speed and find that even my old  850mghz dual P3 server gets an 'excellent' rating at 65k. My newer computers handle 100k no sweat.

Also turns out the Gecko driver I was planing to use (320) has an optional multiplier (340) that mutiplies the pulse rate and is specifically designed for high count encoders to be used with slow kernel speeds.  

Something else that has come to light from my research into this is that Mach does not read the encoder. I'm not sure yet how much of a limitation this is, but at a minimum, it prevents the software from doing anything about cutting problems in real time.

More homework is needed on that and I don't have a lot of time to spend on this, but if that limitation turns out to be a critcal in terms on servo function, that may be reason to investigate alternatives to MACH for control software.

I've been reading quit a lot on servo vs stepper and I'm pretty much sold on servo advantages at this point. I am noticing that the negatives for servos come from users and/or manuf who have already chosen steppers, long ago in most cases. I'm old and have been around forums since before the web so I am very ware of the 'emporer's new clothes' syndrome and also that if advice gets repeated enough times, it morphs into 'common knowledge' and continues to get repeated long after it is no longer valid, if indeed it ever was.

IN my reading so far, the major argument agains servos has been cost, and I have to assume that this was true at some point, but as a newbee, I have no predudices or pre-conceived notions, so I look at the current available choices. What I observe relative to appropriate alternatives in my case is this:

Nema 23 stepper $50 + Gecko 203v $150 = $200 per axis.

Nema 23 servo $70 + encoder $30 + Gecko 320 $115 = 215 per axis


That difference is insignificant, so I consider that cost argument to be outdated and invalid.

Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 16, 2009, 06:52:14 AM
Ok so if you are not using the SS then the easiest option for you I would think  is to use Swap Axis.

Mach can read encoders, just it can not be used to correct in real time, they are basically for monitoring purposes. Plugin or macro could be used to read the endcoders and fault if they differ by a set amount but by that time it may be too late.

If you use servos then Mach does not need to read the encoders as that is what the servo drives do, it is them that close the loop. If a drive faults for any reason then you can have Mach halt motion by sending a signal from the drive to Mach but that should only be in extreme cases as your drives should get a motion signal from Mach and should get the motor to that position by monitoring it and making sure they get there at the correct time, if they cant then they will fault. If they fault except from in abnormal conditions then your tuning or sizing will most likely be the cause of the problem.The industrial controls that keep track of position use "dumb" amplifiers to move the motor with an analogue signal so because of that the control needs to close the loop.
 

I am not a fan of electronic gearing as it can produce cogging but that will depend on how much you gear and the setup you have. Previous to the SS I was forced to use 1:2 electronic gearing in my drives to get even a semi decent rapid (3400mm/min) but I needed twice that to get to the machines original rapids and on very slow moves I would notice cogging when watching a clock (dti)
 Having said that it will all depend on your aplication and encoder count, some people swear by it, just I am not one.

Servo/stepper may be similar now I am not sure as the servos I use are certainly not that kind of price (new anyway ;) ) One thing to make sure is that you are looking at similar kw/torque motors when comparing prices.

Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 16, 2009, 08:34:50 AM
Hood, thanks for the replies. You always have good insight that gets me thinking.

My sense is that you have big machines, outside the capabilities of steppers. Beyond a certain point, steppers fall off the possibilities list and servos get stupidly expensive. I'm aware of this, but my focus is on my little baby mill, and at that level, (which seems to represents a very large percentage of MACH users), the pricing is very comperable. That's not my opinion, that's a contemprary fact.

I don't want to get into a servo/stepper debate , but I will say that in my opinion, it is not really reasonable to compare steppers and servos on a power basis as their characteristics are so vastly different. They really each have their own place. I think a lot of the criticism of steppers is the result of people not acknowledging (or not knowing) their limitations and using them in situations that really call for servos.

While I am a newbee to home grown CNC, I am quite familiar with industrial closed loop control schemes and one of your comments  has me a little confused.

I am aware of how the Gecko servo drivers take step and direction pulses from MACH and keep track internally of the desired position and fault if 'x' deviation occurs.

My understanding at the moment is that MACH only sees the fault condition and has no awareness of the real time performance of the axis. i.e. the axis may be on the ragged edge for a long time and not fault, but MACH would be as unaware of this as it would be of missed steps in a stepper.

The differnece being the servo would catch up and not require rehoming.

The similarity being an out-of-tollerance ruined part.

Commercial/Industrial systems, from what I can gather so far, first off are all servo driven, and the system computers read the encoders directly and control the motors, so there is no 'translator' like the Geckjo 320/340 or eqiv.  preventing the control system from knowing exactly what strain is on the system, if the axis are keeping pace, and if there needs to be some corrective aciton taken, even if that action is simply an operator warning.

While the significance of the effect is certainly debatable, the limitation in MACH either exists or it does not.

If I have it wrong, please explain where I've gone off the mark.

If I have it right, then it doesn't mean MACH is no good, it simply means that the system designer (including a rank ameteur like myself) should consider if this limitation would compromise the intended function of the machine. In my case, from what I have learned thus far, I would not consider it critcal and I would find the MACH/GECKO/SERO scheme adequate for my puposes. But that would be an informed decision.


Southern California machining center operator warning:

"Dude, we're bogus on Zed by 6, time to cruise the program, man. . . . hold it, chill . . .  awesome, we're righteous again .. . . party on, Dude!!" 
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 16, 2009, 09:22:00 AM
I couldnt agree more with you regards Servos and Steppers, I put steppers on the coil winder I made even though the guy I made if for was willing to pay for industrial type AC servo system. I managed to convince him that it was just a total waste of time/money as a properly sized stepper would be , more than adequate for that application.


Now the servo and closed loop thing.

I do not have a great deal of knowledge on the industrial controls but from what I understand if the control  sees that the motor (from encoder or resolver/tach feedback) )is lagging it will send an analogue signal to the amplifier to boost the motor, if its going too fast it will reduce. If the Control cant get the motor to where it wants then it will fault with a following error or the drive may fault with an overcurrent situation.

 I dont know anything about the Geckos etc but I do know my "intelligent" servo drives do the same thing as the control does, ie if it gets a command from Mach to move to a position in a certain time it will move it there, reading the encoder for position and speed and vary the current and voltage accordingly to get the motor there. Again as with above if it physically cant do it it will fault with a following error or overcurrent error.




Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 16, 2009, 11:07:18 AM
I see your point, but I think I need to clarify.

As far as I can tell (and I may be wrong on this) ANY servo controller/driver that is connected to MACH does what you describe, however the point I am making is that MACH, as the 'intelligence' does not have access to the 'knowledge' that the axis is falling behind, and can take no action until it gets a fault, at which point it is too late and everything stops.

If the computer software (MACH in our example) was DIRECTLY watching the encoders, it would know how closely the axis was keeping pace and could make and automatic or programmed pre-programmed decision as to what action to take. Bringing everything to a screeching halt via a fault could certainly be one of those actions.

I can speculate that abandoning the current part and continuing with the next part could be one action. Changing to a new sharp tool could be one. Lowering the feed rate could be one. Warning the operator that 'X" error is present at 'X" part of the code.

In other words, MACH is isolated from the 'action' by a 'translator' that accepts step and direction commands to control a servo motor. It is a way og getting things done, but it does prevent MAC from doing more sophisticated functions because it simply does not have the available data to monitor what's goint on . .  even on a servo driven machine tool.

Maybe someone with more detailed experience migt chime in here and flesh this out more, but really I have what I need for now.

My decision is this:

I have just purchased a NEMA 23 servo with matching 300 line encoder and a Gecko 320 all from Keling. If I can get that all working with my 4th axis as I think I can, then I will consider gettng a larger motor and building a proper 4th axis head with tapered roller bearings, etc. What I will have is a working prototype to play with and work out the programming details. 

I'm listing the current 600 oz-in NEMA 34 stepper and the Gecko 203v in the for sale section in the forum. If nobody here want them, I'll throw them on Ebay later.

Time for a new thread on this project! Thanks very much to everyone for the help, knowledge and advice!!
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 16, 2009, 05:53:36 PM
I see your point, but I think I need to clarify.

As far as I can tell (and I may be wrong on this) ANY servo controller/driver that is connected to MACH does what you describe, however the point I am making is that MACH, as the 'intelligence' does not have access to the 'knowledge' that the axis is falling behind, and can take no action until it gets a fault, at which point it is too late and everything stops.


 I think we may have to just agree to disagree but will try one last time as I am a stuborn bas%43d :)
With my servo drive (others may not be the same) Mach does not need to know what is happening for my machine to be closed loop. My drive knows where the axis is and it knows where Mach told it to go to and the timescale it had to get there. The drive will compensate as best it can to do that and if properly tuned that is exactly what it will do unless there is some abnormal condition such as a crash.
 If it was Mach rather than the drive doing the compensating then exactly the same would happen, no difference at all except that you could use "dumb" amplifiers.
  If Mach was doing the watching and altering then it would still require the tuning to be correct and motors correctly sized or it would still fault and nothing you could do to stop it.
 I am not sure what the Geckos following error is like, if I recall it may be fixed so that could be one downfall. On my drives I can set the following error to whatever I wish, mine are set to 20 counts and I have 8000 per rev and one rev is 5mm, so if my drives dont keep my axis within 0.0125mm then my drive will fault, this will disable the other drives and inform Mach that they have faulted and Mach will halt the code running and go into reset. I have never had a following error fault yet other than when I crashed during beta testing of some hardware.
Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 17, 2009, 03:53:30 AM
Hood,

We don't disagree on how the systems operate. I completely understand how your system (and actually any servo system using Mach3) functions and as I said, I consider it acceptable as a practical matter for my purposes.

What makes an interesting debate is your comment: "Mach does not need to know what is happening for my machine to be closed loop."

What we may agree to disagree on is simply a question of symantics in what constitutes 'Closed loop'. One way to think about it is that in the case of Mach3 and servo motors, the loop is only 'closed' back to the servo drives (amplifiers?), and not all the way back to Mach.  That arrangement precludes certain functions to take place. Whether those functions are usefull or neccessary is another legitimate debate, but the fact that the 'loop' does not reach all the way back to Mach is not debatable, unless one was to argue that a simple fault constitutes a 'control loop'.

I will agree with Webster's definition of 'closed loop'
Main Entry: closed loop
Function: noun
Date: 1951
: an automatic control system in which an operation, process, or mechanism is regulated by feedback



I made no implication that proper sizing or tuning of the motors had anything to do with defining what constitutes feedback.

Speaking of tuning, I do not own a scope nor do I know anyone who owns a scope, but Gecko has a method of tuning that uses a volt meter. NOt as good as a scops, they say, but adequate. They ship my new drive and motor today so it won't be long till I can resume frying electronic components again . .  ::)

Incidentally, my understanding is that the Geckodrive is fixed at 128 steps befor faulting. Your setup is obviously quite a bit tighter . .   and tight is good  ;D







Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 17, 2009, 04:21:20 AM
 From what I hear most people have tuned the Geckos without the use of a scope, for my drives the config software has a built in scope. On the axis motors I just tuned them by ear and have since looked at the software scope and they are good. The spindle motor was a different story, it was extremely hard to tune and I needed to use the scope in the software to get it right, the reason was probably due to the size of the motor combined with the backlash in the gearing in the headstock and 30Kg of chuck being spun but now its tuned it works well :)

RE tuning and sizing, afraid if you dont have these two done properly then you will never get it to work no matter if it is the control or the drive that the loop is closed to. Unless of course you have the CNC Brain which supposedly can do this although I have not seen anyone reporting one working for any more than basic open loop movements yet let alone the advanced compensation and double closed loop  it is meant to be capable of.

128 counts seems quite a large amount, especially with a 300 line encoder (1200 count), on my setup that would be 0.5333333......mm, not good :(  I am thinking with motors tuned/sized (yes these chicken words again ;D )  properly then it is likely you will never see that large an error. Not sure if you can in any way monitor the following error with the Geckos, with mine the drive config software can monitor it and also gives the max and min errors
Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 17, 2009, 06:33:48 AM
"RE tuning and sizing, afraid if you dont have these two done properly then you will never get it to work no matter if it is the control or the drive that the loop is closed to."

Can't argue that. I'm looking forward to playing around with this.

What is a CNC Brain?

"128 counts seems quite a large amount, especially with a 300 line encoder (1200 count), on my setup that would be 0.5333333......mm, not good"

128 seems like a lot to me also, and as far as I know it is not adjustable. Fortunately in this application, it will be driving a lathe head/indexer and I'll have 12 steps per degree . . thats enough for my purpose, and it will allow my computer to get the motor going fast enough without resorting to Gecko's multipier tricks or being forced into a smooth stepper type of device.  For my purpose, accuracy is only important for indexing and threading. For indexing, there would theoretically be no error because the spindle would be stopped. For threading or hard tapping, even the max error of 10 degrees along the thread *probably* won't bother my work because I'm not doing precision threads. If that need ever did arise, I could simply change the disk on the encoder to a higher count (US Digital sells them separately) or 'back gear' the head.

Also the reality check is that I'm using a pretty crappy little Seig Mini which is not at all accurate to start with. Sort of like trying to slice off a nice piece of .040" mahogany veneer using a chain saw  :D.

This has been a very interesting thread. Thanks again!

Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Dan13 on April 17, 2009, 07:18:25 AM
The CNC Brain is a pretty expensive motion controller, that can be interfaced with Mach3 (like the SmoothStepper), and has yet to prove itself being worth the money. It is supposed to provide double closed loop control. I think, if it proves itself, it's going to be the next thing for many CNC builders and OEMs that use Mach3.

You can check it here http://www.safeguardrobotics.com/default.aspx?tab=cncbrain

Daniel
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 17, 2009, 07:20:32 AM
CNC Brain is a hardware device (and GUI) that was supposed to be capable of turning a slack piece of junk into a high precision super machine, do a search on CNC Zone and you will find lots of info.
Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 17, 2009, 07:24:39 AM
that can be interfaced with Mach3 (like the SmoothStepper),
Daniel

Afraid thats not the case, the CNC Brain needs to use its own GUI, any plans that the guy had to have a plugin for Mach have been dropped.

Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Dan13 on April 17, 2009, 07:40:22 AM
Hood,

Thanks for the insight... and I was wondering why no one is using it with Mach3... :D

Daniel
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 17, 2009, 07:53:08 AM
Hood,

Thanks for the insight... and I was wondering why no one is using it with Mach3... :D

Daniel

Even if there was such a plugin I dont think you would see anyone using it with Mach as there doesnt even seem to be anyone using it even with the guys own GUI, well a few have basic open loop movement but thats about as much as I have seen.

Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 18, 2009, 06:10:43 AM
I did a quick perusal of the CNC brain site and I have do disagree with what's been said in this thread about it thus far.

First off, it is not exspensive. In fact, it is the opposite if one considers what is included in it's price. The CNC Brain @ $500 cost less than my 4 Gecko Drives ($600), and the CNC Brain is 6 axis. Also the 'GUI' appears to be the control software and is included. Mach is now $175. The CNC Brain also includes the functionality of the smooth stepper.

Just combining the cost of Mach and a smooth stepper together gets you a long way toward the CNC brain cost, and the functionality of both is included in the CNC Brain. I don't know at this point what kind of 'dumb' amplifiers one would need to handle the motor current, but unless they are $150 each, like a Gecko 203v, you can subtract the delta from the CNC Bain system's actual cost.

Second, it doesn't work with Mach, but there would be virtually no point to using it with Mach. IF the thing works as they claim, Mach would be a major step backward, and as I mentioned, the CNC Brain already has it's own control sofware, so it does not need Mach.

Third, there seems to be a very active forum assiciated with the device, so more than a couple of people are using it. There woud logically be little disussion about it in a dedicated Mach forum.

Lastly, anyone who can compete in the DARPA robotic challenge is cutting edge, so in my opinion, that resume' entry alone deserves respect.

I am definately going to look into this further, but from the descrition, it does exactly, precisely the kind of functions I was referring to that Mach cannot do.

Of course, there remains the question . . . does it actually work . . . but here again, in fairness, I read in the Mach forum about the relatively new smooth stepper's current limitations and what is 'planned' for the future, and nobody seems uncomfortable with that concept. This demonstrates some acknowledgement within the Mach community that new technologies need time to mature.

Obviously, I need to do a lot more homework on the CNC Brain to make an intelligent assessment, but it seems to me that the negative comments here are perhaps a rush to judgement.





Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 18, 2009, 07:17:29 AM
Please do purchase one and let us know how you are getting on with it, also there is a section on CNC Zone dedicated to the CNC Brain, you can check that out as well, here is a link.
http://www.cnczone.com/forums/forumdisplay.php?s=4a6d3e5452581e230452df2e300b2ef6&f=432

Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Overloaded on April 18, 2009, 07:46:20 AM
YES !  Please do.
   I am anxious to see your results as well.
 
Clip:

You will need TTL output encoders or linear scales to feed back the position. Newall linear scales with differential TTL output levels should plugh straight in. You can check the pinout of the encoder input on the brain from the CNC Brain control panel. Just download it and run the trial version.
If you haven't bought any steppers yet then don't. Have a look at Gecko DC servo drives before you make up your mind or Sureservo if your budget is big enough.

Keep in touch,
RC
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 19, 2009, 06:41:10 AM
Overloaded; My first DC servo and Gecko 320 arrive on Tuesday, so sayeth Brown.

CNC Brain, however is not on the menu at this point, although I do plan to follow it's progress if I have the time to do so.

As I said, I only did a quick scan of the CNC Brain site and I was not aware it used linear scales, but linear scales are nothing new. I had them on my little el-cheapo Mini mill before I converted it to CNC. I had not considered getting feedback from a linear scale, but it makes a lot of sense. Absolute is always going to be more reliable than relative positioning.

Hood; I am not interested in blazing new trails in home grown retro CNC. An engineer is, by definition conservative, skeptical, anal, and only interested in facts. The CNC Brain may not be ready for prime time, but the idea is very valid and the apporoach, if it is developed fully, would solve the issues I was pointing to, and at an entry level price point. AS I have already said several times, these capabilities we have been discussing are not new. Machining centers incorporate ths technology and have for some time.

Getting anything remotely  similar for $500 or $600 would definately be something new, as are servo motors under $100 and $30 encoders, apparently.

It appears that the CNC Brain is being developed by a very small outfit, so, like most of the other suppliers to the CNC retrofit community , including Artsoft, it takes a while to get things accomplished.


I just feel strongly that discounting new technology simply because it is not fully developed or based on the cost of a single component is not a good strategy. If one were to evaluate, for example, the Gecko 540 on price alone, it would look expensive, but it has 4 drives in it. The smooth stepper has a way to go before everything is implimented the way people (including yourself) want. The only way to look at a CNC retrofit, in my opinion, it to set your criteria and then compare the total system cost of the alternatives that meet the criteria.

One of those criteria, of course can be that certain features must be fully functional right now, today. Mach has been around for quite a while and it seems they are just now getting threading to work right. I don't know of any bug free software that is under active development. I also know of no software that does not have a wish list associated with it.

There is a saying . .  'it is what it is'.

I'll say this, if I made my living off my CNC machines, I would definately be following CNC Brain and any other promising technology, unless I had the cash to plunk down on a machining center.

Lastly, were I to purchase CNC Brain, which actually would make sense in some ways as I am very interested in new technologies and at my hobby level, I don't need to make money with the machines or have tight production dealines, so beta products are not a critical issue for me . .  hell, I've had the Windoes 7 beta runing since day one availability . .  8) but in any event, I would not be posting the progress of CNC Brain on a Mach forum . . that would make no sense.
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: Hood on April 19, 2009, 07:24:20 AM
No need to post here, I religiously follow the CNC Zone and the SR forum re the CNC Brain as I too am very interested to see if this can work.
Hood
Title: Re: Opinion and advice - explain relationship of encoder to kernel speed
Post by: simpson36 on April 20, 2009, 10:05:10 AM
Excellent!

Retrofitting this little mill was my first foray into home grown CNC and it has been a lot of fun. Some setbacks, but overall not nearly as difficult as I envisioned.

I have some other commitments that will take me away from my toys for a few months and I'm thinking about selling this little mill complete. I've pretty much taken it to it's limits. When I get time to play again, I would be doing up the larger X3 with servos. Maybe the CNC Brain, or equivalent, will be working by then.

I'll look you up when that times comes and see what you think of the progress.