Re: Re: emc help

> From: "Greg" <gkretro@...>
> Subject: Re: emc help
>
> HEllo,
> I personally dont use the stg board i like galil boards much
> better,better specs,bullet proof design,and overnight repair
> capability if needed.

OK. I don't mind Galil but they are in no way similar to the STG. Whole
different world! Galil does a lot of accel and PID computation and
closing of the motion loop on the card. They pass data to the PC using a
rather high level language. The STG is pure dumb (not it's makers, just
the board) in that it passes raw position and stuff to the PC and takes
raw binary data that it uses for analog and I/O. It's up to the PC to do
all of the motion computation.

> I have talked to the engineers of stg and they only recomended the
> board to around 2 MHZ ( i should qualify this as that is in an
> industrial enviroment).

Well OK. But 2MHz is still much higher than you were speaking of in your
post. Accepting this value "in an industrial environment:" would still
give you several times the axis velocities suggested in your response to
the post by Jon E.

> This is what forced my trend towards galil
>
> I have a lot of these boards in the field and have only had one go
> bad (power supply overvolted)even when they are in some really bad
> enviroments.
>
> But apples and oranges it doesnt matter your encoder max freq is
> going to be the limited either way ,unless you are using a laser.
> Which is too costly for all but the most expensive machines.
>
> As to the mazak spec ,I havent worked on a lot of them and it would
> depend on if it had a fanuc or mazatrol control.

Uh. I don't think that's a good answer because it moves what you said was
an encoder max ppr problem off to some other device. If an encoder can't
get past 300K how you gonna improve that by changing the device that you
connect it to.

> But if i rember right they have both abosulute encoders and count
> interpolation giving the much higher density (full qudratic)
> Thus the big differences in the statements pulses per rev and counts
> per rev.

Absolute encoders are an option for some of these machines. None of the
ones I service have this feature. This leaves me with the thought that
somehow they are sending quadrature rather quicker than you suggested
that they can. I also don't think that multiplying by four at the
receiver would explain the high encoder counts listed on the encoder
nameplate.

> I would doubt that they reach a millioncounts a rev would be over
> kill.

I was surprised when I first encountered a 1M+ one. The company that
owned the machine that used it was also surprised when they got the bill
for a new one.

> 40000 ct/rev with a +/-2 lock factor would give you a .0001
> resoulution,not counting the fact that you have a multiplication you
> get from the ball screw ,which would reduce your needed encoder
> resoulution even more
> 10000 ct/rev * 4 turns per inch =40000 ct rev
> 4 turns per inch *6.66 inch per sec or 400 ipm = 1440 rpm
> all said and done leave you with an enocder freq of 240k

Interesting design numbers and more than adequate for a home brew or
modest shop machine.

> Being a japanese machine the ballscrews would be metric and the
> smallest increment would most likely be .001 mm thusly changing these
> number some.

The screws and setup I was thinking of is a 25mm pitch, 750 ipm rapid, and
0.0001 accuracy. They are metric screws but the machine is made in
Florence, KY. The encoder is used for both position and velocity so the
design folk used many more pulses than would be required for a 0.0001
accuracy -- I'm remembering something like 128K ppr. Since 750 IPM is
about 762 RPM or 12.7 RPS we would get 1,625,600 PPS. Well that's easily
within your judgment of the STG read speed but well above what you think
is possible from a common incremental encoder.

My last wonder is why would a company like STG build a card and report
that it will read 10MHz if they knew that there were no pulse coders out
there that could come even close to that speed?

> My comment about the parallel was not against jon and his pico system
> but in reference to step and dirrection signals,where you are max freq
> limited.
> With pico system the parallel port is just a communictaion port
> passing the desired speed,position,etc to controller/drive.

We agree on that.

Let's try to put this encoder issue back into some sort of perspective.
First thank you for pointing out that the pulse rate of encoders is in
fact limited -- as are the input counters of encoder reader boards.
Clearly we'd better read the spec sheets before we apply a device that
doesn't work like we might imagine it should.

If we are using a common parallel port for step and direction signals,
let's say we are limited to something like 50K. Now one way that we
(EMC) would use an encoder with common step and direction signals from a
parport is with the KM DRO card. As long as the number of pulses per
rotation of the encoder is not more than 10 or so times the number of
pulses required for a rotation of the stepper it should be copacetic.
And reading the pulse rate should be no problem because the chips used on
that card say that they can also go out to 10MHz.

A second way of using common step and direction signals and encoders would
be a Gecko 3xx or Rutex drive and a servo motor. Here again a parport
will be the limiting factor unless you are using a +10 multiplier and/or
a very high count encoder. Since the absolute max pulse input for a
Gecko is 250K (25K at the +10 multiple) we should still be within the
limits that you want to impose on encoders. It would be rather easier to
violate your max encoder stuff if we were using Jon's step generator
card.

In point of fact, the only place where higher pulse rates than your ~300K
might be commonly encountered would be a true servo driven system. It is
in these applications IMO that a proper understanding of specs becomes
critical. There are many servo motors out there that run 4-6K RPM. An
inexpensive 2500 count encoder like those from automationdirect.com might
easily run past it's max pulse count if directly connected to one of
these motors.

Ray