Re: Index and Encoders

"Arne Chr. Jorgensen" wrote:

> Jon Elson: index and encoder chips.
> -------------------------
>
> Yes, you are right. I didn't describe what I meant good enough. I
> can't recall it at the moment, but someplace I came across a chip
> that could do several things.

Right, some other motion control chips have a more flexible way of
holding the index position.

> It had some internal registers, that
> was possible to get to work like this: an index pulse, would copy
> the count registers to another "index" register bank. Not the read
> out latch you use for reading the counter.

<snip>

> On the stg board, you have to make a function like this in software,
> but that is giving some problems. By the time your software would
> read the counter, it would have changed. The way you said, - it
> could be set up to latch the counter register - poses another
> difficulty. If different processes should read this, - the motion
> controller *will* read it, and this would ruin any other separate
> process that should just monitor the surface probing,.

Right, I see what you are trying to do.

> There is something else, - the RT "kernel" and the Linux "kernel".
> I think the RT part, is just polling the io, - and not using
> hardware interrupts.

An interrupt from the real time clock (not an I/O board) is what gets
the RT scheduler to activate the RT module that does the servo loop.

<snip>

> Come to think of something, - if you don't use all the axis, maybe
> preload a spare chip with the contents of one other position
> counter, - and have them wired in parallel. Do as You said, let the
> index pulse latch the output register on this spare counter, and
> have another kernel module read this spare counter instead. This way
> it would not interfere with the EMC module.

But, you really don't have to do all this, either. Even though the user
interface (xemc) only handles 3 axes right now, the motion control software
can handle up to 6. So, you could easily activate a 4th axis for the
motion control routines, and they'd handle all of this for you.
Then (I think) you could make another program that had access to
the shared memory area, and it could read out the position of the
4th axis, and do whatever you want in another window.
For CMM type work, you could have EMC working slowly along
an X-Y grid, and the probe program could read the X and Y coords,
and take the probe position, too.

Now, you probably want to have the Z move down until the probe
reads within some limits, and then take the numbers.
Probably, the best way to do this is to replace xemc with a program
that does this, scanning in X and Y, and then moving the Z axis to
keep the probe within its range. I don't think this would be too hard.
the user interface can completely control the machine by passing
'nml' commands to the motion control system. It can move to
a coordinate, or jog until it sees some signal (like probe within
a range of values) then stop the jog, wait for everything to settle,
and record the data point.

You might ask Fred Proctor for some detailed guidance on what
needs to be done. Keep us informed, as at least I am very interested
in having this function.

I also have something similar in mind for sinker EDM work. The
only differrence is that the EDM current is what controls the Z axis
movement. The STG card has a multichannel A/D converter, which
could be used for this purpose.

Jon