[Mariss Freimanis]

"Closed-loop" seems to have developed a squishy definition. Going from least effective to most effective:

1) Encoder monitoring an open-loop step motor. The monitor gives an error output if steps taken don't match steps sent.

2) Encoder terminal correction. An open-loop step motor is commanded to move from A to B. If the number of steps taken don't match the number sent, the correction circuit sends steps equal to the difference at the end of the move to null the error.

3) Encoder following error correction. The motor operates open-loop. If it's following error approaches +/-1.8 degrees, the drive goes closed-loop until the following error is reduced to below the limits.

4) Tightly coupled closed-loop. The loop position error output (PID filtered) makes continuous motor corrections on a step-by-step basis while the motor is running or stopped. This is what most people think of as being closed-loop. DC servomotors cannot be run any other way.

5) Adaptive closed-loop. Just like (4) except the loop circuitry also generates a feedback command to the motion controller telling it to slow down if the motor begins to develop a continuously increasing following error. The controller slows down until the motor can "reel-in" the following error.

Let's stick with definition (4). Loop bandwidth determines how quickly the motor can respond in correcting an error. The G320 and G320X use analog circuits that have a 2.5kHz bandwidth. If it were done digitally, the equivalent sampling rate (number of corrections per second) has to be 5,000 per second (200uS update period).

Mach3 is not designed to operate closed-loop, meaning Mach3 cannot read the encoder feedback, compare it against a commanded position, PID filter the difference and output step pulses to null the difference to zero. That is the reason why the loop is closed locally in the G320 and G320X. The result is the same as in a distributed servo loop (PID controller in the PC and a torque command signal to a remote motor amplifier) except that fault or error signals back to the PC are harder to implement.

The performance of such a distributed system depends largely on the loop bandwidth. A 100Hz bandwidth system will be far more sluggish than a 3kHz system.

Mariss

[pete from TN]

is either too slow to be able to make the necessary computations to reel the data back in to the correct position or it is simply not designed to do that. I get that I think but is EMC capable or more capable of doing this same thing? What is your preferred operating system? What do you use and prefer? Does the Linux based setup have more capability at the expense of less easily useable interface( I say that having never used it btw) I assume that a windows based system is more intuitive to most people due to the popularity of windows based systems. If it were you and you were to start along the cnc road would you use the Mach3 system and live with it's drawbacks or go with the Linux or turbocnc or somthing of the sort?

I appreciate your response on this as it makes things clearer. Which of the five options you posted would the Pico systems be? I do not fully understand their setup since it uses geckos and thier boards. I suppose what I am asking is with your obvious knowledge of these things and your personal experiences of machines what path would you choose? I have much to learn young jedi I know but I do not want to waste time with one thing when there is a better or more capable alternative elsewhere.... know what I mean? peace

[Mariss Freimanis]

pete from TN,

I honestly don't know the answers to your questions. I design drives but I don't personally use ours or anyone else's for that matter.

Mariss

[SCzEngrgGroup]

is either too slow to be able to make the necessary computations to reel the data back in to the correct position or it is simply not designed to do that. I get that I think but is EMC capable or more capable of doing this same thing? What is your preferred operating system? What do you use and prefer? Does the Linux based setup have more capability at the expense of less easily useable interface( I say that having never used it btw) I assume that a windows based system is more intuitive to most people due to the popularity of windows based systems. If it were you and you were to start along the cnc road would you use the Mach3 system and live with it's drawbacks or go with the Linux or turbocnc or somthing of the sort?

I appreciate your response on this as it makes things clearer. Which of the five options you posted would the Pico systems be? I do not fully understand their setup since it uses geckos and thier boards. I suppose what I am asking is with your obvious knowledge of these things and your personal experiences of machines what path would you choose? I have much to learn young jedi I know but I do not want to waste time with one thing when there is a better or more capable alternative elsewhere.... know what I mean? peace

Pete,

EMC runs under a variant of Linux that is modified to have a "real-time" kernel. Real-time, in operating system terms, means that each task is *guaranteed* to be serviced (i.e. - get some minimum number of CPU cycles) with some maximum worst-case latency. This is a major part of what allows EMC to do closed loop control. Windows is not a "real-time" operating system. What Art did to enable it to service the parallel ports at the rate he does is impressive, but it's all done underneath the operating system, even below driver leverl, and is no subsititute for a proper real-time OS. EMC is guaranteed to always get enough CPU bandwidth, at a regular enough interval, to be able to reliably service the PID loops. Windows, on the other hand, can "lock out" an application for completely arbitrary and unpredictable periods of time, while is services the network, USB hubs, disk drives, etc. That's why Mach is so fussy about the kind of PC you have the graphics board you're using, what drivers you have running, etc, etc. This makes doing time-critical processing, like a handling a PID loop, all but impossible to do reliably at the kind of update rates required by a CNC machine.

Regards,
Ray L.

[samco]

a few people have set emc's stepgens to velocity mode. This way it acts similar to a servo setup. emc outputs a velocity which the stepgen outputs a step rate related to that. Emc reads back the encoder for acutal position.

the mesa cards stepgen can do this as the software stepgen within emc. I don't know enough about JonE's cards to say if that is how the gecko interface boards work. I am sure he will chime in.

sam

[SCzEngrgGroup]

is either too slow to be able to make the necessary computations to reel the data back in to the correct position or it is simply not designed to do that. I get that I think but is EMC capable or more capable of doing this same thing? What is your preferred operating system? What do you use and prefer? Does the Linux based setup have more capability at the expense of less easily useable interface( I say that having never used it btw) I assume that a windows based system is more intuitive to most people due to the popularity of windows based systems. If it were you and you were to start along the cnc road would you use the Mach3 system and live with it's drawbacks or go with the Linux or turbocnc or somthing of the sort?

I appreciate your response on this as it makes things clearer. Which of the five options you posted would the Pico systems be? I do not fully understand their setup since it uses geckos and thier boards. I suppose what I am asking is with your obvious knowledge of these things and your personal experiences of machines what path would you choose? I have much to learn young jedi I know but I do not want to waste time with one thing when there is a better or more capable alternative elsewhere.... know what I mean? peace

Pete,

I spent some time looking at the Pico Systems offerings in some detail. To use their product, you'd need their Universal Stepper Controller, plus the Gecko Servo Interface (if you're using servos rather than steppers), and the Geckos (either stepper or servo).

As far as motion control, the Universal Stepper Controller is little more than a hardware step pulse generator (similar to, but simpler than the SmoothStepper), and counters to accumulate position, based on either the step pulses issued (if you're using steppers, and don't have encoders), or encoder counts (if you're using servos, or have encoders on a stepper system. I assume it also has hardware acceleration ramping, from the sound of it. All the "smarts" are on the PC, which simply periodically issues commands to the USC giving it, I assume, a new target velocity and/or position. The PID loop is implemented entirely in software on the PC, so without the PC, you have little more than a piece of high-tech artwork. If you're using steppers, it does give you true closed-loop control.

The Gecko Servo Interface is needed really only so both the Gecko *and* the USC can "see" the encoder signals. This allows the USC and the PID loop to always know the true machine position, even when the Geckos are powered off due to a fault. This setups amounts to Mariss' #5 configuration, assuming the PC software is smart enough. It is, at least, a #4. The difference being an extra level of monitoring and control that takes note of an increasing following error, and uses that as a "hint" that the machine is being pushed too hard, and is likely to fault shortly if the speed and/or acceleration are not ratcheted down a notch. I would guess the EMC PID loop *does* do this, for both steppers with encoders, and servos, but don't know that for certain. The Gecko Servo Interface also monitors all the Gecko ERR/RES outputs, and E-Stops the system if ANY Gecko faults.

Seems to me, the most useful part of all this is the constant power to the encoders, and the passing of the position data back to the PC, so that even after a fault, the PC will *know* the true position, and can take any necessary remedial action without having to re-reference the machine. This functionality could be provided even with Mach3 with the USC and GSI, or even something a lot simpler, and some suitable macro code to re-set the DROs and fixture offsets following an E-Stop.

Regards,
Ray L.