EMC+closed loop?

[grebator]

Hi,guys!

Does EMC has got closed loops?
Can i make closed loops with stepper motors?

EMC+C10-bidirectional breakout board+step drivers+step motors with encoders

[flash319]

I am no expert with EMC2 and am just starting out myself but it looks like that is what it was designed to do. Your problem will be interfacing. I think it was designed to use a servo control board to act as a buffer for the drives. You are using steppers and there is no buffer in the drives so I don't know if your computer can keep up with live encoder updating to drive in closed loop. You will need a stand alone card to control the motors that does the updating for you, dedicated. I may be wrong....anyone???????

[unterhaus]

there is actually a theoretical problem using step/direction with encoders which has nothing to do with EMC. I ran into this problem years ago with a totally different stepper based system. It came with encoders, but they weren't used. I called the company that made the system and asked them how to make it closed loop with the encoders and they told me it wasn't going to work and go open loop, so I did. I just read the position from the encoders, but they aren't in the control.

Most people find that a properly set up open loop stepper system works fine. There was a configuration in the EMC1 that would do closed loop steppers, and I really doubt anyone uses it. EMC2 is flexible that you probably could set it up.

[skullworks]

Use a Pico systems USC - it generates its own step/dir output pulses and is not limited by paraport speed.

It can also read encoders on steppers.

http://pico-systems.com/univstep.html

[HelicalCut]

What do you mean by closed loop with steppers? reading off a shaft encoder is pointless unless it is to determine a step error and issue a fault (how the fault is handled is another matter) On the other hand if you have axis encoders and use them to close the loop which is what I call closed loop, steppers can be used, if the stepper has not missed a step and the axis position does not equal the desired position then take corrective action. It can be quite tricky as the acceleration ramp of the stepper needs to be incorporated into the desired position.

Also you really need a quadrature decoder board to take this load off the system, axis position encoders can have very high pulse rates, best handled by hardware.

[ironchops]

HelicalCut,

Sounds like you have a working understanding of the issues around closed loop servo systems. Do have all the hardware worked out for interfacing with the linear encoders? I don't quite understand why anyone would put up with the accumulated ball screw errors when a DRO style scale is a possibility. Perhaps the unpredictable travel is an issue. A dead reckoning is made for the travel, the ramp up and ramp down takes place and you are left somewhere in the general vicinity of your intended destination. If that is too far, the metal is already gone if this event was a cut so no taking it back. The software/hardware will have to be smart enough to finish the travel somewhere towards the end of the move in order linear position readings to mean something.

What have you done to make all this work out?

Thanks,
John Mc

[Seb]

EMC2 can read quadrature encoders in software. Overall performance depends on how fast the computer is, how many lines the encoder has, and how fast you're spinning the motor.

For example, a 256-line encoder produces 1,024 quadrature transitions per revolution. If you're spinning this motor at 1,000 rpm, that's about 17 revolutions per second, or about 17,000 quadrature transitions per second. You need to sample at more than twice that frequency to capture the input waveform properly, call it 35 KHz. So the encoder reader thread needs a period of 28 microseconds or faster to do its job. (If your motor is connected to a .200" pitch lead screw, that's 5 revolutions/inch, so 1,000 rpm is 200 inches/minute or 3 inches per second...)

You can use the realtime latency checker to see what kind of realtime latency your computer is capable of. That time is slightly shorter than the shortest possible sampling period.

Here's the general formula:

• Let L be the number on lines on your encoder.
• Let R be the maximum number of revolutions/minute.
• Then F, the sampling frequency in Hz, needs to be at least 2 * (4 * L) * (R / 60) or (0.1333 * L * R)

Alternatively, if you've determined how fast you can run your encoder-reader thread, you can solve for the max supported rpm using the formula R = (7.5 * F / L)


That's my understanding, at least.

[ironchops]

I was suggesting using the linear scale of the DRO variety rather than doing shaft encoding.

I was hoping that resolution could be improved by using table position encoder rather than a shaft encoder and thereby allow the use of looser tolerances on the ball screws.

Are there systems out there that use such a method?

By the way, I am new to CNC but not new to science. Fact is, this stuff is pretty simple in nature but lacking experience, I have to fumble around to find out what other people are doing to implement systems.

So far I have the feeling that servos with very accurate ball screws with an encoder on the ball screw shaft is good, provided you have a really good ball screw and bearing. Steppers are burdened with resolution issues but that depends on the stepper and the screw pitch.

No sense in getting too worked up over a few tenths if you don't need to cut super tight parts but my interest in what works best is more of an exercise in specsmanship and curiosity.

[Mariss Freimanis]

I wasted 2 years trying to run a step motor PID closed-loop with only the encoder and step / direction available before concluding it's not possible. Arriving at that conclusion also suggested a different approach that does in fact work.

Mariss

[Seb]

I was suggesting using the linear scale of the DRO variety rather than doing shaft encoding.

I was hoping that resolution could be improved by using table position encoder rather than a shaft encoder and thereby allow the use of looser tolerances on the ball screws.

Are there systems out there that use such a method?

I'm a noob at this too, but I think most closed-loop motors controllers get their feedback from the drive axle (ie an encoder on the lead screw) rather than from the driven object (the table or the quill, on a mill). When I first started thinking about CNC mills I also imagined getting the feedback from the table, but some study of the state of the art has indicated that this is not the way things are usually done.

Proper control of the table position is extremely difficult if there is backlash in the drive train, or other loose tolerances in the positioning hardware (ie loose gibs). Backlash is often dependent on where in its travel the axis is, and of course it changes over time, so it's difficult to compensate for accurately. CNC machines are engineered to minimize positional slop, and the less positional slop there is the less incentive there is to get the feedback from the table rather than the leadscrew.

That's my understanding.

[CarbideBob]

Using encoders with steppers on a machine tool is worthless. Lets say you try to close the loop with and encoder. Once there is an error what do you do? If you try to pump more steps into a running motor that is losing counts it will just stall and sing at you. If you wait till the end of the move and add extra steps you've already cut the part wrong. Say you've programmed a 45 degree line and lost some steps in X. Now you've got a 50 degree line with a straight correction move at the end.
Steppers are made to be used as open loop devices. Unless of course you drive them like a brushless servo which is what I believe Mariss is working on.

On the subject of using linear scales yes this can be done with servo motors but its very tricky and usually works worse than using the encoders on the motor. The problem here is related to backlash, stiction, mechanical response speed, and abbe errors. The errors add up to a phase shift in the control loop that make the loop unstable. You try to correct for the error and nothing happens so you add more correction and so on. Eventually you remove the backlash and suddenly you have too much correction. So you correct in the opposite direction and now you find yourself in oscillation.
To make the thing run you end up "softening" the servo loop so much that your running error is much larger than with a conventional system. Your ending position will be right on but you'll have larger errors while cutting. It's important to remember that a servo system is always in error when moving, it is the error that make them move. Thats why servos typically have higher resolutions than stepper systems Normally you design a servo for at least 5 to 10 counts to your desired running resolution.

Not to say it can't be done and this system works quite well in point to point machines that don't care about errors while moving (machine vision measuring machines for example). Some very, very high end machine tools will use laser interferometers as a linear scale for feed back. But you need a deep understanding of control theory and servo systems to make it work.
Galil has a tutorial on their web site about this, using the "dual loop" feature of their controls to accomplish this task. I've set this up a number of times but have always ended up going back to the conventional method using just an encoder on the motor.

I would never consider trying to read a high resolution encoder in software. If you stop right on a line you may get very high frequency up/down counts as the encoder settles and the software will miss counts. I've never seen a software system that doesn't lose counts and the circuitry for hardware quadrature decoding is so simple.
Bob

[skullworks]

I once saw a FADAL with glass scales fitted in ADDITION to the normal axis encoders.

It could call a macro that would do a series of moves to compare the stored screw pitch error map to what was being reported NOW, and updated a temporary pitch error map which corrected for thermal expansion issues at that moment.

The glass scales were never read while in actual motion.