Welcome to LinuxCNC.org

Hi JR1050,

I haven't forgotten you, just been thinking.

The crux of the problem is that the arduino board and the basic PoKeys, have little in common except the USB connection.
The arduino could be programmed to do what the PoKeys board does but not vice versa.

Since the PoKeys board is a HID (human interface device) it is recognised as such by the system.
That really is the start of the problems, it emulates a keyboard and joystick devices and is indistinguishable from them
This means that the keystroke codes generated are automatically passed to the program which has keyboard focus at the time.
You can't write a hal component to receive and action keyboard commands from the PoKey, because the key codes will go to Axis (caveat below).

Some PoKeys boards, the 55 and 56 at least, have a TCP comms layer which can send other commands via a port
This could be programmed, since the userspace module could connect to that port and directly receive commands and data
There seems to be a documented comms protocol etc, but I don't have a board to test and don't even know which one you have.

Mach deals with the HID device element of this by having lots of user defined hot keys, enabling the key codes to be allocated to different actions.
There are also some .dll s from the makers specifically for Mach
This is why all these pendants etc that basically emulate keyboards work with Mach.

Axis does not have the same facility in any easily usable way.

The standard programming approach when we want to filter keyboard strokes and divert some for our own purposes, is to hook into the the keyboard handler
and basically peek at each keystroke, pulling in and acting upon particular key combinations and letting everything else pass through the handler as normal.
This is how programs which sit in the background and activate when you use hot keys work.

One could use this as the basis of a PoKeys handler, but it is probably looking in the wrong direction.
There is also a major potential problem with non-realtime reaction to keyboard commands, when the hook is sat in userspace waiting for some processor time
and you are pressing [Escape] because the tool is about to crash into the work piece!!

Perhaps what is really needed, which would be to the greatest general benefit, are usable user defined hot-keys for Axis.

I am looking at that, can't promise anything.
(Might try finding out about exactly what the PoKeys generates and maybe program an arduino to do the same)

regards

it is possible to assign hot keys in AXIS with it's axisrc file:
www.linuxcnc.org/docs/2.5/html/gui/axis.html#_axisrc

Hi Chris

I am aware of the ability to make key bindings in .axisrc thanks, I have my jog keys set up in it, as well as some other bits.

The problem is that this is a programmers afterthought, rather than anything generally usable.

There are 75 hard-coded root_window.bind calls in Axis. A large proportion of them I for one, never, ever use.

I was looking a the feasibility of a menu based GUI, which allowed assignment and re-assignment of key combinations.
Some would probably need to be reserved, but a lot are up for grabs.

There is then the problem with how to implement it,
If you completely re-write Axis, substituting key combos for assignable aliases which are read from a separate table or similar,
the developers won't adopt it because they won't be able to see anything wrong with their original code.

I am leaning towards a GUI that then writes an .axisrc file, doing all the key assignments there.
This has the advantage of the developers probably being happy with it and some chance of it being included in the distribution.
The only thing that concerns me is the ".....The details of what may be written in the axisrc are subject to change during the development cycle...."
bit in the docs and exactly what that means.

Now that the code for creating extra tabs in Axis has been moved into the project, there is little else in that file and you can always offer the ability to replace or append to the existing file if it has some esoteric shit in it.

Even better, I won't have to write it in python! Took me 2 hours yesterday to work out how to do something I could have achieved in 10 minutes in Qt.

regards

yes those developers are pretty sticky about changes to AXIS - though they have been better of late if you supply a patch.
".....The details of what may be written in the axisrc are subject to change during the development cycle...."
What that means is that they cannot guarantee that the next bug/feature fix will not change something so your additions won't work.
So having a separate program that builds a .axisrc script is not likely to be included in the distribution.
But I will keep your idea in the back of my mind when if I add key bindings to gscreen...
ahh It would take me two hours to do something in QT... what bindings of QT?
In AXIS i don't think python is the problem - AXIS is a combination of python C++ and TCL/TK oh and openGL.
It works great but wow hard to follow what it does. but then again try to follow what emcTK does ..TCL loses me

Don't feel bad it takes two hours for QT to load on my computer... Glade3 seems so much faster now that I understand the basics.

John

Hi

Someone had problems with the spurious characters the forum sometimes puts into code when it looks like HTML tags or escape chars.

So attached is a zip of the 2 pieces of code and a compiled version of serialcon module to be copied to /usr/bin if you don't compile your own (10.04 only)

regards This attachment is hidden for guests. Please log in or register to see it.