Re: emc help

Hello,
Great we got some of the dissagreements out of the way.

When I mentioned the galil board,I was just using it for comparison
of capabilty and input freq .
My present idea is to apply emc and some hardware to low cost
retrofits.
For 2 reason one to reduce cost and complexity and B to get some
money back into the emc development effort and hopefully get things
moving.( think about it emc has been around for longer than some
controls life cycle and it just now starting to get know and popular)

But your right why build a board to handle 2,10 ,12 mhz for encoders
and not have an encoder that was even close.

As to running 700+ipm with a .0001 resolution use a scale or mount
the encoder in such a way that it sees less rpms.
High counts make for a tight control loop but lets not over do it.
Most high speed machines uses scales,by high speed I mean over 400ipm
cutting speed.
Want to be scared cut aluminum at 1600ipm on a new program,We
calculated that if you hit the estop that it would take 6 inchs for
the machine to stop.
Delta V rocket monilithic ring 4"x 4" x2" deep pocket 6 sec

The absoulte encoders have several more channel than a standard
incremental encoder so they would be able to have a lot more counts
per sec .

I happen to like the step/dir system even though it is speed limited,
A 40amp rutex drive and a 2hp servo motor and away you go.
I have talk to him about a bigger one but there still in the design
stage.

I almost afraid to ask what a million count per rev encoder would
cost,the 18000 count i just bought was over 3k$.

Also if you want to go 700ipm i would watch your max ball screw
speed,as i have been warned by several mechanical engineers not to
exceed 1000 rpm.

Regards,
Greg
--- In CAD_CAM_EDM_DRO@yahoogroups.com, Ray Henry <rehenry@u...>
wrote:

>
> > From: "Greg" <gkretro@e...>
> > 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