handwheels was Linux USB

["William Scalione" <wscalione-at-nc.rr.com>]

Ray and Paul
I combined both of your messages here

As far as me doing anything in C or C++ I don't think I would
be much help as it would take me a few hours to come up with
a "hello world" program but I have been looking at the TkEmc
code and could probably figure that out given some time.

The Kluga/Mauch card has it's own counter in it so tell me
if this sounds reasonable. Every X milliseconds poll the
card and see if there is a value other than zero. If yes, then
convert the amount of pusles to required distance (depending
on your ini parameters), output that distance to the motion
module(?) and reset the dro card to zero. As you say, real time
is not really required for a handwheel, and some missed steps
would not really matter much.

If you think that is reasonable, I'll do some reading on TclTk and
give it a try.

Bill

Ray wrote

>If you have separate I/O paths, not two keyboard signals in the same
>path, we can write a simple process to run in the background that will
>watch inputs and communicate with the running EMC.  There are examples of
>processes somewhat like this under the scripts menu in tkemc.  IO_Show.tcl
>starts a separate instance of a program that connects the EMC's internal
>communication system (NML) to most any I/O port.  Software processes like
>these do not connect to a hardware counter, unless the device you are using
>has one, so you can't simply watch how many times a switch has closed.
They
>are loops that are executed every so often and look to see what state the
>pin is in.

>HTH

>Ray

Paul Wrote
>
>
> Hi Bill
>
> This has been discussed quite recently - Looking at the source code
closely,
> I've been trying to work out how to do the same thing myself, although
with an
> STG card. As it stands, there are several issues that need to be
resolved...
>
> a) The motion control modules initialise each encoder input channel and a
> coresponding motion output channel. - Need to be able to specify
additional
> inputs without outputs.
>
> b) What is the best strategy and place for the code - In the motion
feedback
> loop or at the GUI level ?
>
> Scattered throughout the motion control sources, there is a reference to
> MAX_AXIS. The sections that deal exclusively with the encoders will need a
> higher number than the motors. Would probably need an additional ini
parameter
> to accompany the extra inputs.
>
> As for where to place the feedback loop, for a handwheel, I would go for
the
> GUI level. Missed counts due to the nonrealtime nature of the GUI are not
an
> issue here - Unless the nonrealtime processes were really sluggish.
>
> I have been bouncing a few ideas around off list, and have the crude
beginings
> built in to tkemc. An extra command has been added to emcsh that utilises
a
> butchered PS/2 mouse (serial is a little erratic but still functions) - In
> time, I will get STG and DRO extensions done for the extra inputs.
>
> The ultimate goal is to have spindle feedback so that threading can be
> supported, hence a requirement for at least two extra encoder inputs.
>
> A side project from perusing the souces, is collecting all the comments in
to
> one searchable document - A sort of API programming reference for the
handbook.
>
> How are you with this C and C++ stuff ?
>
> Regards, Paul.
>
>
> On Tue, 21 Aug 2001, William Scalione wrote:
> > I moved this message from CAD CAM EDM DRO to emc-at-nist.gov
> > to give the non EMC'ers a break.
> >
> > How hard would it be to change the motion modules to watch a
> > kluga/mauch encoder board for an encoder input. Now that would
> > nice, to select an axis and spin a panel encoder wheel while in
> > manual mode to move the axis's. And possibly put a command in
> > to switch from 1X, 10X, 100X. so using a 1000 line encoder in
> > 1X you can get very fine movements and in 100X you can get
> > some speed out of it. I think jon elson was thinking of that for
> > his boards.
> >
> > Bill