What a mess 6

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

Hi all,

I going to write a few things, and it is just a free speech, not very accurate
to the subject of EMC, etc.


Joystick/Game port:
 
My idea is this:  Fred has some code for a joystick/game adapter.  I do
understand that he would be concerned as to release any of the code regarding
EMC. ( A bunch of problems could arise, - how to support it, etc. )  My idea
was if he shared this "as is".  The thing is that I look upon this as a nice
way to experiment. It has it's own address space, not currently supported, etc.
I would like to do some changes to EMC, - but I would not like to "mess" with
the real code. Not for now.  But maybe insert a less dependent module, and
experiment with it, is very appealing.  It is sort of his paper and examples on
the shared memory stuff.

It may never actually be implemented into EMC, but stay as an "experimental"
device address space.  So I am not really asking Fred to support a joystick
input or any other stuff at this point. 

-------------------------------------------------------------

Okay - my free speech:


If I should write the code for a package like EMC,  here is what I would do:

Just think of the RS274 interpreter as a macro language expander.
One block of code ( one line )  expands to all the individual step motor
commands, etc.  One RS274 is thus expanded to a number of commands, in the form
of  current step -> next step.

So - I would think that this would be placed in a NML buffer.  I would have
made this a linked list, together with a block entry tag, that would point back
to the RS274 line.

You may divide the screen, say having the RS274 code on the left side, and the
intermediate expansions on the right side.  The current position could be
marked by highlighting the code lines. ( This is more for an explanation, than
any actual program )

If you want to step, or jog a RS274 line, - then this is a "front-end entry" -
all the expanded commands in the right pane, would be executed.

But the game port adapter, a stg board, a Dro -- would be a "back-end device" -
it would step the expanded lines of code.

Let us say I had 4 switches:  (halt)-(single step fwd)-(retrace)-(run)

- if I hit (halt), then this would stop the execution of the expanded commands,
dead in it's track.  This would be a mode change of the whole system, and could
if you want, fire up this right hand side window pane. Now you would run this
linked list.  

- if I hit (single step fwd) - then I would output the next line. 

- if I hit ( retrace ) - I would execute the previous line.

- if I hit ( halt ) again, or toggle it - I would leave this mode, insert a
dwell, or pause command.

-if I hit ( run )  again,  it will start running in normal mode from the
current RS274 block or line.

All this is the "back-end" function,  not the jog commands of the "front-end"

---------------------------------------------------------
Other stuff:

A Dial with an encoder,  could  operate at several different levels, or ways,
according to the current mode of operation, or state.

Let us say you have 3 states:  ( not active ) -( manual)-(program run)  

One could be that the (x)-(y)-(z) switches in a the ( not active state)
would couple the encoders together.  By turning the dial, you would inc/dec the
current position.  

Say you engage the (x) switch:
- save current position  
- couple in the hand wheel
( now the axis will move, with the full loop gain, not as a command, but as
feedback )

You release the (x) switch:
- save new position
- remove coupling between hand-wheel and axis encoder)
- make new position a relative offset
- calculate new global position ( or what you would need )

Other stuff for this, would be to have a store function: 

Let say you would like to make a little subroutine for a tool changer.  You can
move to the locations, and make it tune into a spot, then hit a store button.
Move to the entry place on the table, and store.  These stored positions, could
then be opened in a new subroutine window pane, where you could edit it, and
make this little piece.


------------------------------------------------------------
I think I would like another state/mode in this machine as well: 

Dry Run:
------

You may have a .ini file to set this up.  Let us imagine a mill.  What it does,
is to disengage the Z-axis, retrace it.  You can run through your RS-274 code,
( you could have a laser pen shine down from the tool :)  - the use of it is
just to make sure that no clamps or other stuff would be in the path of the
tool.  You may even use it,  with the above encoder hand-wheel, just to correct
the relative position and work piece.

------------------------------------------------------------

All of this depend upon a "back-end-input"  device.  That is why I have said
that this is useful - you can not do any of these things from a keyboard or
other input device.  It has to be able to send real time semaphores, in the
real-time space, and change a state-machine modus of the machine. 

As for a pendant - I would want these functions. And again, there is no way to
do it,  in a "front-end"  kind of approach.  I think the game adapter would be
a good experimental vehicle, for such development.  Later this could be put
into code that would use the STG board, or what ever.

If I had the machines to play with, I would be writing code for it now, - at
least I would have like to try it.  But I still have a long way to go.

//ARNE