Re: Jog wheel (with code attached)

[Ray Henry <rehenry-at-up.net>]

Brian

I had no idea one of these existed much less was being used.  I see that the 
code uses 0x201 for the address of the joystick.  Is this always the location 
of those signals in a pc?  I do see something there when I look at that 
address with IO_Exercise.

I tried to compile handwheel.c on my BDI 2.14 pc and got a whole stack of 
errors.  Since I am mostly c illiterate I'll send these on in the hopes that 
someone can make sense of them.

Script started on Mon Jun  3 15:03:03 2002
[root-at-mygriz src]# cat /proc/version 
Linux version 2.2.18-rtl3.0 (root-at-Virlan) (gcc version egcs-2.91.66
 19990314/Linux (egcs-1.1.2 release)) #1 Wed Jun 20 09:35:03 BST 2001 
[root-at-mygriz src]# gcc handwheel.c 
handwheel.c:58: parse error before `if' 
handwheel.c:63: conflicting types for `last_handwheel' 
handwheel.c:50: previous declaration of `last_handwheel' 
handwheel.c:63: initializer element is not constant 
handwheel.c:63: warning: data definition has no type or storage class 
handwheel.c:64: parse error before `}' 
handwheel.c:68: conflicting types for `joystatus' 
handwheel.c:50: previous declaration of `joystatus' 
handwheel.c:68: initializer element is not constant 
handwheel.c:68: warning: data definition has no type or storage class 
handwheel.c:69: parse error before `if' 
handwheel.c:74: conflicting types for `axis_btn' 
handwheel.c:50: previous declaration of `axis_btn' 
handwheel.c:75: initializer element is not constant 
handwheel.c:75: parse error before `incr_btn' 
handwheel.c:137: redefinition of `last_handwheel' 
handwheel.c:63: `last_handwheel' previously defined here 
handwheel.c:137: initializer element is not constant 
handwheel.c:137: warning: data definition has no type or storage class 
handwheel.c:140: parse error before `.' 
[root-at-mygriz src]# exit 
exit 

Script done on Mon Jun  3 15:03:49 2002

If you plan to launch this code into the public domain or GPL, am I correct 
that this file should go into the emc/src/emcio directory and that we should 
add a line to the makefile there so that it is compiled with the rest of the 
EMC?

When we get this working, the script to start it should only take a very few 
lines.  Handwheel already tests for manual mode and uses reported axis, 
increment, and jogspeed so IMHO the script can just be an on/off toggle and a 
loop.

Ray



On Sunday 02 June 2002 15:47, you wrote:
> starting about a year ago I did some collaboration with Alan Marconett on
> the CCED list on the handwheel interface ,hammering out the best ways to
> get the input into the control and looking into what problems might come up
>
> the result was the pendant Alan made from junk box parts shown here
> check the pendant 1 and 2 jpegs
> http://photos.groups.yahoo.com/group/cad_cam_edm_dro/lst?.dir=/Driver-PS+%2
>6+Pendant compare Alan's pendant with the $300-$500 versions
> http://www.maxmar.com/mpg.htm
> http://www.sumtak.com/contents/product/handLGB601/indexLGB601.htm
> http://www.cui.com/encoders/encd_tools.htm
> functionally they are pretty much the same
>
> for the encoder I would use one of the optical panel mount encoders
> like the CUI RE20 shown here
> http://www.cui.com/encoders/encd_paneloptic.htm
> available as  Digi-Key Part Number 102-1012-ND
> *********IMPORTANT NOTE***********************
> check the data sheet before trying to get the detented versions
> of the the RE20s
> the detented version has 25 lines (100 quad transitions) with only
> 25 detents (4 transitions per detent) lined up with the A&B high phase
> this is not what we you want
> instead get the non-detented encoder and build the detents into
> the knob using an index plate with 100 dimples and a spring pin under
> the handwheel knob
> ***************************************************
>
> the code I've attached is a rough port to Linux/EMC of
> the code Alan came up with for his pendant mixed with some
> of the code from the jog sections of Xemc or Keystick
>
> it uses the 4 button inputs of the game port only and handles the
> encoder and two push buttons to set the axis and jog increment
> and sends the same messages to EMC as the GUI would
>
> I've tested parts of it and the encoder bit works fine with no
> extra external logic on the encoder lines using a home built
> encoder setup I hacked together just keep it simple and run
> the A and B lines right into the game port
>
> the idea is to build this as a standalone task module that can be
> loaded alongside ANY of the existing user interfaces without
> having to rewrite all of them to include this feature
> all of the current interfaces are already set to display the selected axis
> and increment on each refresh so it dosent matter if the message
> came from the UI itself or another module
> making it into a loadable module is the bit I'm still having trouble with
>
> task timing
> the handwheel task should only be active while in jog mode
> and should be scheduled to run just fast enough to keep up
> with the average Joe spinning the knob at a controlled rate
> so maybe one hundred times per second max if the axis can even keep up
> at this ( max_jog_speed * max_jog_increment) combination
> (the real world is SOOO much slower than the CPU world)
>
> spinning the knob faster than this will cause some incremental jog commands
> to be skipped over ,the axis will still move as fast as it can as long as
> you are spinning but will stop on a multiple of the increment without
> overshooting as soon as you quit turning the wheel
>
> this would give it a nice ,predictable and fairly safe behavior
>
> Brian