Re: Jogging problem (revisited)

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

I've always maintained that the keyboard code and it's underlying 
communication structure was never intended to allow for two buttons at 
the same time.  The keyboard ideas came from tty's of the day and typists 
didn't intensionally do this.  When shift, control, and meta came along 
they were treated as special cases to allow two or more to be pressed at 
the same time.   IMHO after reading bit of about the ibm keyboard world 
and it's error correction problems, the second press can often trash the 
release reference to the first pressed key.

However, now that you mention this problem again, the second keypress 
changes the activeAxis variable in tkemc.  It would be possible to issue 
the emc_jog_stop command for all axes whenever a jog button was released. 

The way it works is something like this.  A KeyRelease binding like that 
shown below

bind ManualBindings <KeyRelease-minus> minusUp

controls the end of a jog behavior.  In this case the line points to a 
command named minusUp.  Now search for a line that begins 

proc minusUp 

and you will find 

proc minusUp {} {
    global debounceTime
    after cancel minusDone
    after $debounceTime minusDone
}

This one points you to minusDone which says.

proc minusDone {} {
    jogStop
    bind ManualBindings <KeyPress-minus> minusDown
}

You can ignore the bind commands in here.  They are used to prevent 
repeats of the jog command while a key is being held down. (Another 
keyboard communication problem) Now the command is jogStop which says

# stops the active axis
proc jogStop {} {
    global activeAxis jogType

    # only stop continuous jogs; let incremental jogs finish
    if {$jogType == "continuous"} {
        emc_jog_stop $activeAxis
    }
}

The critical line here is the emc_jog_stop $activeAxis.  Therein lies the 
rub.  We want to stop all of the axes rather than just the one that 
happens to be active.

You could do that with a manual edit of emc/plat/linux*/bin/tkemc where 
you will find the above line about 683.  If you replace this line with a 
line for each of your axes (here they are named 0,1,2) it will do the job 
for you.  So jogStop might look like

# stops axis x, y, z
proc jogStop {} {
    global activeAxis jogType

    # only stop continuous jogs; let incremental jogs finish
    if {$jogType == "continuous"} {
        emc_jog_stop $activeAxis
        emc_jog_stop 0
        emc_jog_stop 1
        emc_jog_stop 2
    }
}

You would raise an error if you commanded an axis to stop and that axis 
did not exist.  For that reason it is not possible to include all six 
possible stop commands in a generic tkemc.  

I left in the reference to the value of activeAxis otherwise this code 
WILL NOT STOP the 4th axis machine on a four + axis machine.  I wouldn't 
use it with hard references on my mill 'cause I try all kinds of goofy 
combinations but it will work for you.  Just remember that you've done it 
in case you make changes later or add a different machine.

It might be possible to replace the list of axes with a foreach loop and 
use the variable axiscoordmap in something like

# stops axis x, y, z
proc jogStop {} {
    global activeAxis jogType

    # only stop continuous jogs; let incremental jogs finish
    if {$jogType == "continuous"} {
        foreach axisnumber $axiscoordmap {
            emc_jog_stop $axisnumber
        }
    }
}

but I am not certain how well the routines work that set up axiscoordmap 
in tkemc.  If it worked, it would work for most any setup.

Hope this helps

Ray


On Monday 09 September 2002 10:20 pm, you wrote:
> Back in April of 2002 Markus Meyer submitted a bug fix (tkemcJog.tcl). 
> It was for the bug that kept an axis jogging after its keyboard button
> was released.  This happens in tkemc if two or more buttons are pressed
> together.
> His fix stopped the "selected axis" as well as the "active axis".  It
> worked for me because I was using Tkemcex and could see where the file
> should be placed, but with Tkemc and the latest cvs, this problem still
> exists.
>
> Anyone able to correct this?
>
> Kurtis