On Thursday 23 March 2017 16:47:39 Gene Heskett wrote: > Greetings guys; > > Chucking up that pulley to start making the taper boring, I found TLM > wouldn't run, throwing errors about a non-existant Y axis > > I had not run it since before the joints merge. > > 3 hours worth of checking and editing later, I can make it run but the > axis's are all weird. Pressing a left-right key runs X, and the in-out > keys run Z. > > Watching the leds on the bob, it is actually driving the wrong axis. > > But, the DRO is showing the axis thats moving as the correct axis for > the one thats actually moving. Me confused. Bumfuzzled even. Configs > attached. Hopefully enough to run it. > > What did I miss? > > Thanks all; > > Cheers, Gene Heskett
No reply? Further info: I have it working except the keyboard jog key assignment is wrong. I read in the devel docs that there is in the [DISPLAY] section a JOG_AXES = XZmore_axis_characters configuration option. Looking that up in the online docs. it says this is the order of the jog key assignment, starting with the left-right arrows being assigned to the first (X) and Z is then assigned to the in-out arrows. This jog_order is reported in the terminal window its launched from, note: jog_order='XZ' note: jog_invert=set(['X']) and if I change that string from XZ to ZX, it is reversed in the jog_order reported. note: jog_order='ZX' note: jog_invert=set(['X']) But the actual keyboard assignment does not change, X stays on the left-right keys, and z stays on the in-out keys. Changing the trivkins coordinates=XZ to trivkins coordinates=ZX apparently swaps the axis<->joint assignments, and I can't make that run because the MAX|MIN limits don't match then. So how do I restore the we're used to it for a decade or more keyboard response? I've just now installed a new version. linuxcnc (1:2.8.0~pre1.2926.g4564804) to 1:2.8.0~pre1.2939.g7f30fa2 so lets see if this problem persists. Yes: >From the terminal: note: jog_order='ZX' note: jog_invert=set(['X']) But the actual keyboard assigns are left-X-right, and up-Z-down. I have no clue if real gcode is similarly scrambled as well because it won't home (or run an MDI command to see which axis moves) in this condition. To me, this is a bug, but in that case the big lathe should be similarly afflicted, but is not. But the linuxcnc versions there are not tracking the x86 versions either. That machine has: linuxcnc-uspace/stable,now 1:2.8.0~pre1.2771.gdc2ff49 armhf [installed] Which I read as being behind quite a bit. What can I do? I need this to make the taperlock parts for the bigger Sheldon lathe's spindle drive. Which is all apart ATM. Thanks everybody. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
