Alan, addressed the underlining issue above, think it was Benny that changed it and dont think its a profile issue.
 As for the cost issue, I am in the same boat as you, ie cant afford or dont want to afford. I got my lathe without drives so did a lot of experimenting and ended up with 88lb/in AC Servos and digital drives. I got them from eBay and are probably about 10yrs old. They are Giddings and lewis or Allen Bradley or Electrocraft (all the same but with different badges ) In the UK Allen Bradley doesnt seem to sell well so there are bargains to be picked up on eBay and quite often you will see new ones for not a lot of money, although I always seem to be too late for them

Hood

There are no underlines on my Mac...but I don't know if that helps.  Seems the HTML would be the same.

Hello,
Digital servo amps are GREAT You can do cool things like use Fiber optics... Yes that has been done in the past! There is an Unbuffered encoder line that comes out of the drive and this is used to monitor he following error of the drive... So in the end a good servo system should monitor the error of the machine and fault if there is anything that goes wrong.  Now about steppers.... well they have there place and I like to have encoders on the steppers that I run I am not a big fan of lost position! If you were to see the mill that I have here for testing you would say "Why the HECK to have motors like THAT!" ... I run AC brushless servo motors on my test mill here.... I can rapid my knee mill at 500 IPM and has 1.3 Hp per axis (I love that thing) But just the motors and drives cost me 5000.00 ! On the small bench top test mill that I have is all stepper and it works but at 100IPM it is nice But the price for the machine and drive box with motors was only 2500! That is a deal...  On a machine like the one that you have I would not use anything but servos because I would want to have the fast movement and so on.

As for  the windows and linux thing... that is all up to you... EMC is great software and I will never take that from them BUT the fact that you have to know linux is a bit more then most can take. The Linux windows thing is like saying that my car is better then yours... I don't see the point... I have a friend that may turn off his lathe 4 times a year with Mach and win 2000. He has only mach3 and notepad on the computer. I know linux would work just as well as that if it only had that little bit of software running on it But then there are people on the other end like me ... I have Skype running (talking to people allover the world) as well as my E-mail and a few web pages open at the same time I am cutting a part on my laptop... This is not the best thing to do but I have never crashed out when doing it So the more you do the risk you have and I think that is the same for Linux and windows.

Hope all that helps
Brian

PS what the heck is up with the underlineing! (ON a linux server!!!)

as a complete thread derail, I only see the underlining happen in IE7 - in Firefox everything appears correctly, and i haven't tried IE6 yet..

that is all, i now return you to your normally scheduled thread...

scott

(edit:  I found out what the problem is, I hope to work with Benny and have it fixed soon...)

I must have missed your post, Hood, on the underlining thing.... Sorry.  I'll go back and look later in the day.

You all have very compelling arguments.  I don't know that I will ever be comfortable with Windows running a substantial machine, but I do see that Mach has some big advantages too.  As the hardware variation is getting smaller all the time, my inclination is to do a two pronged approach... Develop a Mach solution first.  Even if this works great, I will probably look at an EMC afterwards (but hey, this is a hobby, so that could be a long ways away!).  If I do the software correctly, it should be fairly transportable.

There are several reasons why I am taking this position.  First, my previously mentioned concerns of Windows.  Second, I program professionally and have always felt a bit of a "hole" in my Linux... An EMC integration will help force a filling of that hole.  Kind of killing 2 birds, type of thing.

Next stop is to download the demo of Mach again, and do more research on the app, itegration to it, emulator functionality, etc, etc.

I would like to express my sincere thanks to you all...  It is a pleasure talking with you.  I love learning and am willing to acknowledge that there is a great deal I do not know.  Your patience and comments are veyr much appreciated.

Regards,
Alan

I have a question that keeps nagging me regarding the open loop concept.  The control outputs steps to a Pixie (for instance) that then transforms this to analog for a pseudo-closed loop.  That is great for monitoring errors, but the part I do not get is how chaining is done reliably, aka look-ahead. 

As an example take an external right angle... Unless you are at the terminus of the first line, you don't want to start the second.  If you did, you'd end up with a fillet, which obviously is not good.  By the same token, if the control assumes it takes 1 minute to go to the terminus of line 1 and it only takes 45 seconds, then there is a 15 second dwell time; needless to say, that is not good either. 

The real pickle is that the time for the cut of the line can vary a bit as a result of loading, so I am at a loss to figure out how any open loop system can reliably make something as simple as a right angle *without* dwell marks resulting from an artificially long delay between successive commands.  If someone can explain that to me, I think it will go a long way to making me feel more comfortable wiith the whole approach taken with Mach.  I must be missing some fundamental, and simple, piece of the puzzle.

[on edit] In thinking about this more, I am coming to the belief that this is all about tuning... Obviously there is an acceleration and deceleration programmed into the control.  I am assuming that the control assumes the servo is "caught up" when the control ceases to output additonal pulses.  This makes sense, I suppose, if the tuning is such that the servo isn't trying to catch up.  So.... Is that the piece of the puzzle I was missing?

Alan

P.S.  Lines went away magically.... Ahhhh   

Alan said -> The real pickle is that the time for the cut of the line can vary a bit as a result of loading,

Well, sort of, but no.  In an 'open loop' (for our purposes a stepper system), the stepper is pulsed at a rate in accordance with the velocity commanded by the program.  Until you reach the point of overloading the stepper its velocity will be synchronous to the command pulses, that's how they work (one pulse = a fixed angular displacement).  The control (Mach III) knows how far it is from point A to Point B, and how many steps it will take to get there, the time taken will always be the same, based on your programmed feed rate.  Open loop stepper systems are always detuned to ensure that there is adequate torque for any expected situation.

With an open loop motor system, varying load will increase/decrease travel time.  Closed loop systems, be they steppers or servos, do have feedback.  In the case of (servo) motors the feedback is essential, otherwise the control would have no idea how far/fast the motor had traveled.   (A servo after all is just a motor with feedback.)  With this feedback (encoders and/or resolvers) the (servo) control can constantly monitor the angular velocity and rotation of the motor and tweak the commanded voltage to the servo drive to keep it motor going the correct velocity and/or distance.  The commanded velocity is still a function of the feed rate set in your program and at a given feed rate, the time from Point A to Point B will always be the same, despite load.  If the drive is not capable of the required speed/torque then the (servo or stepper) control will raise an error as the commanded and actual position will be too far apart.

Brian Said -> For the people that are hard core and need to have it all one one board because it makes them feel better there is the Galil BUT you need to know that there is a limitation of the accel needing to be the same AND that I have not coded in the probing Sad One thing that it will do VERY well is homing to an index pulse Smiley If there are people out there that think they can do better... I have the plugin code and if you think you can handle the code I would be willing to work with you... You need to have VS2003..

The other consideration is the total number and type of I/O needed in the system and the resulting cost/complexity of the possible ways of getting the required I/O.  In the case of the Bridegport VMC I'm converting, the cost difference between going with a G-Rex or one/two LPT's with a PLC to handle the rest of the I/O was only around $500.  The system complexity is significantly lower though.

Hi Jeff,
I had just added some more information to my post and when I refreshed I saw yours.  It seems like my assumptions are correct.  This really gets down to a tuing thing.  The assumption is made that, due to tuning, when Mach3 terminates sending pulses, the servo motor can stop rotation (and be within the tolerance of the following error).  If additional rotation is required, then I believe my original concern is still valid.  If Mach starts pulsing the second axis, then the result will be a kind of chamfer, not a theoretically sharp point.

Alan

"" I am assuming that the control assumes the servo is "caught up" when the control ceases to output additonal pulses."""

Alan, I don't think the control "knows" much of anything about the servo loop except that it has or has not reported an error.
If the loop is doing it's job, it cannot continue if it hasn't positionally responded correctly to the step input, so the axis will "have" to be in position for that next set of streaming steps or the loop would have already faulted out.  It can't just take the next series of steps and "forget" it didn't make position on the first stream.
If the servo is "catching up" by applying more power at the moment the change of direction comes, I have to presume (this is over my head), that the drive has a buffer and the servo will continue to catch up...or fail.
It will continue to attempt to make the first position, not just "give up" and start taking new steps.
I think it is fractions of a second we are talking about here.  The drive will fault before that buffer is overfilled and steps lost.

Sean

With Mach, servos and Pixies (or other S/D to analog converters).  The Pixie translates each step (pulse) from Mach into a distance that the servo should move (the relationship has to do with #of encoder lines and the gearing of the drive).  So when Mach is done driving an axis the axis is done moving, period.  If the servo can't keep up a following error is generated (that can/should shut Mach down).  The drive and Mach are always in sync, else and error is generated.  Remember servos don't freewheel, when they are powered are held in position unless commanded to move from that position.

The situation you are talking about (rounded corners) has more to do with physics.  Since the table has mass it cannot immediately stop/start.  It accelerates from one point and decelerates as it gets to the next point.  If you want a nice sharp corner then turn of CV mode (run in exact stop) in Mach and it will come to a dead stop at each corner before proceeding.  With CV mode some rounding will occur but you get a  faster and smoother operation of the machine.  ALL machines /controls do this.