Re: Homebrew STG card - CRAZY-7

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

On Tue, 07 Mar 2000, you wrote:
>At 07:56 AM 3/6/2000 -0500, Arne wrote:
>
>
>Okay - I've got several 286 boat anchors out there.  Let me see if I caught
>your drift.  You work up a mini os and servo or stepper *mot that downloads
>onto the 286 and it attaches to the steppers or an stg or homebrew isa card
>and communicates with shared memory in the pc that is running the most of emc.
>
>Think you could pull off the software?
>
>Ray

If I had enough time,  maybe :)    

I did have a working realtime library running under DOS and I have made a
different IO boards and systems,  so in theory - yes.  But I when it comes to
doing it - no.

[
  I am not a good programmer,  and to be honest,  a little confused on a
  Linux box -  and it would take forever to just understand EMC enough to port
  it if I didn't get some good help :)
]

But if  Fred, et al.  found any interest in such a thing,  and help us line up
some of the things,  then it could work out.  

To say a few words about what I think:

1. First it has to be clear how this could best be done:

a)  use EMC as it is - but make a "wrapper" for the io
b)  port " emcmot"  or stuff to the other hardware.

This is either a or b,  or some mix.   Fred is running the "inverse kinetics" 
and stuff in rt-kernel space on a linux box.  It could still do this, but talk
to io on the other box.  That is some sort of a hardware "wrapper" .

On the other hand,  if this code could run fast enough on the other machine,
then it could run on that, - the other box would be the rt-kernel space.  
But it could run continuously on the other box.

How intensive the calculations etc. would be,  will decide if this is possible.

This would be something they would have to say a few words about,  as I don't
really know.  But in fact,  a lot of controllers use a lot less cpu power and
performs well.  ( You may also use computers with more power than 286 )  

If you had some data on - how long time intervals EMC uses in Rt-kernel space,
and calculate a little on what speed this could run at on a single box, - then
you should have some estimate. 

2.  Memory usage:

You have less memory,  so this is another key figure.  If you just used a
"wrapper"  scheme,  then I can't see any reason why it should not work.  If you
extend it a bit,  doing more work on this other machine,  then you have to know
how much memory is needed.  

3.  Porting:

I don't think this should be any problem, - that is to compile the code for a
286.  There may be a few things that would need to be "tuned" a bit,  but I
don't think this should be a problem. ( that is compiling the code )

But, -  you could get a few other problems:

I don't know how the "mode" would interact.  A 386 should not have problems, 
a 286 has a few other options.  "Protected" mode etc.  It could be that you
would have to use it in "standard" mode, and then the question is how they uses
segments. (  code, data, stack - etc )   This could give a few problems.   It
should work okay for a "wrapper"  scheme,  but I am not sure about porting
"modules" .   Here you would need to know about sizes,  and stuff.


4.  Downloading:

The idea would be to download the binary image into memory of this subsystem. 
I would like a direct DMA connection,  but that would mean some hardware had
to be made ( there may be something available - I just don't know )   But the
ethernet channel should be cheap and easy enough.  

5. Communication:

Here is some of the main issues.   Packet size, NML and  API.  Say you
exchanged some fixed size  buffers.  You needed to decide where they should be
located on the other subsystem,  and the internal data structures.  This is
more ore less the same as how it works today.  

Here we would need to - take one of Paul's cards.  Read and write from IOport
to this buffer,  so you would need to decide some kind of API.    


6.  In closing:

Sure,  this could be done.  Fred, et al.  have the knowledge to say if this is
silly or workable.  There is also a change that they would not support any such
attempt, - they have done their job,  and may not at all like the idea of
devoting any time to a bunch of "home brewers".

On the other hand,  it could be a little interesting - because this could be a
great learning exercise for us.  That is - the more we understand of the code,
the more independent we would be.  At the moment we rely heavy on them, because
we know so little about the code.  If we could work things out ourselves,  then
this software may live on without the need that they have to do everything.

So this is a big question.  But as a start,  it would have been nice if they
could just say a few words as if this is "silly"  or not.

In my opinion,  it could at least be a lot easier for us to experiment with
hardware and development.

My suggestion:
----------

Do it as simple as possible,  maybe just as a test.  Using some kind of
"wrapping".   If needed,  let us start with dos and tcp/ip and some simple NML
code.  Set up a small communication API and use the parport with a step motor
on.   If this is degrading performance,  so let it.   Taken a bit further, -
we may set this up as a test bench for developing hardware and drivers.  Okay
if we "zap"  this subsystem because we did something stupid,  then we would
not ruin any valuable hardware.  When debugged and working, we could port it
to a Linux-EMC box.

Taking this subsystem further,  you may end up with a system that could work
nice,  and give some added benefits.  You could for example upgrade it to a
more modern computer,  using the NIST realtime library, NML - and everything, 
and maybe even run it from a Windows box.  But a key figure would be that we
could get a chance to be on the ride - learning how to use a lot of the NIST
libraries and software.  Put it in other words, - a "class room"  project.    

At the moment,  I think a lot depend on a working system.  Some use it for
"work"  - and  they just will not mess with it.   Here we could get our hands
dirty - and keep the working machines running.  

Well,  I don't know - we do need someone from NIST to say a few words about it.

( At your opening question:  "Think you could pull off the software?" - yes,
but it would not be EMC compliant, and that would be the objective.  So I would
have to say no. )

//ARNE