What a mess ! - well the mess I am living in :)
I am very frustrated, because I am not able to follow you guys. I have all sorts of things to do, and I have not a working machine platform yet ! So from an operators standpoint, I am not there yet, and can't test the bugs and steps you do, nor kind I do much code writing etc., because I have not a stable and running platform yet.
So, in the following, when I say "I" - then some of this is hypothetical - a bit into the future. I am also just taking this from the top of my head, - not using time to check the facts.
Operators panel:
------------
Long time ago, we discussed this - and one thing I said, was that I had installed encoder wheel on an operators panel. I would not be without one. ( Jon said also that this was something he would like )
Then you have the keys, buttons, switches, lights, numeric input you would like.
Keyboard codes: you have 3 sets.
In fact there is 3 different key codes modes: scan code set:
1 , 2, 3
By default, our machine platform will initialize to command
scan code set 2.
This is probably the worst set to use for EMC gui.
Each SCM ( my abbreviation - Scan Code Map ) - is a "make" and "break"
value, and this
is different in each set.
Example: Space bar - ascii 0x20 ?
SCM1 ||
SCM2 ||
SCM3
-----------------------------------------------
Make | break || make | break
|| make | break
-----------------------------------------------
0x39 | 0xB9 || 0x29 | 0xF0,0x29 || 0x29 | nn
The nn is a typematic repeat of delay and make
The SCM, typematic rate, if it should be on or of, resend of
code under transmission errors, overun on the keyboard internal
buffer,
( you have also a buffer on the computer end ) and there is also
more
options, like change the prefix on break codes in SCM2, etc.
Consol:
In unix/linux you may have several consol terminals,
( changed by the ctrl-alt-F1, etc ) - and you have these standard
in, out and error.
You may also have some different effect in runlevels, and each user
process
will have it's own buffer, etc.
Terminals:
You may have external terminals, and also the X server is
a kind of terminal.
In sum:
The SCM is different when using a terminal, ( I wonder if it uses SCM3 ) than the keyboard. All SCMs will behave different according to mode.
What Linux will program the keyboard as, I don't know for sure.
Then you also have national language codes, that change the keyboard
setup.
But I think it would use SCM-2, but in fact it would have been better to run it in our case as SCM-3, and program the keyboard to only use make codes, without any repeat function. (IMO)
If you wanted to have a customized operator panel wired to the keyboard channel on the PC, then all this has to be thought of.
As I said, I would have used SCM-3, and then I may include a handwheel and other functions. Maybe also switch between SCMs - in order to implement some stuff.
I would like to make my own operator panel, using a special micro
controller, and implement some analog dials as well.
PROBLEMS:
---------
I will use the words "Front_Input" and "Back_Input" in the following, to describe these things:
I will call the keyboard and normal linux to be Front_Inputs, and
call
Parallel port and STG boards as Back_Inputs.
Several events, like a E-Stop is wired as a Back_Input. This is synchronous to the real time tasks. If you would like a handwheel encoder on a STG board, then this will be a Back_Input. But if you should want to change this to a different axis,- let say by a switch, - then you would get trouble if this came from the Front_Input. So in many cases, I would say that an operator panel should be wired as a Back_Input device.
If not, you have to pay attention to each detail, as you will have a lot of processes that you need to map, and be sure how it will synchronize with the program. But on the other hand, running a G-code program, is a Front_Input device, so to synchronize with this, you would be better off using a Front_Input device as input.
Confused ?
Then, the system should be able to use NML messages over network.
So you have some "mess" here :)
To be honest, I think I would change everything to RS232,as the input port, and forget about keyboard. I would also insert a RT_module to bring some communication semaphores between Back_Input and Front_Input devices. Use RS232 as a NML channel.
It would be easy to develop programs to accept RS232 inputs, and to make a dedicated operators panel. You would free yourself from any SCM changes that may be modified under Linux, outside your control. To make it a NML would comply with EMC standards and should be easy and clean to manage.
I think it should be possible to synchronize things a bit better
under G-codes,
have retrace, single steps, etc.
So, one should put a little thought on this, because I think the keyboard as the future Operators Panel, may rise several conflicts and you may have changes in different Linux versions. Just the national keyboard mappings can introduce problems that is not so easy to predict.
In Closing:
-----------
I just typed this, without much detailed thought, but would like to raise the questions.
//ARNE