What a mess! -2

["Arne Chr. Jorgensen" <instel-at-online.no>]

Hi - 

I have had some trouble with my ISP lately.  I have had problems to receive and
send email.  You may have received this before, I just don't know. 
And I don't know if any had any comments on this ? 

So, I mail it again, to see if I will get it past my ISP (This time I use KDE )
 By the way, - there is more to be said about this subject.  I am trying to get
some more clarity about what the different consols will actually do. 

Here goes:
     
------------------------------------------------------
Hi, 

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