re:Re: Black box

Ron G wrote:

>First, maybe we ought to use slightly less offensive terms
>than 'smart' and 'dumb', although I do agree they are a good
>description.

I think we all understand it's the BOX that is smart or dumb, not the
person behind it. After all, to make a smart box takes a smart
person, and to get a dumb box to do real work ALSO takes a smart
person :-)

>I am on the smart box side. If we can get one good implementation of
>the 'messy motion stuff' in the box, then it won't have to be re-
>written a thousand times by everyone else.

Agreed. As long as we agree on what 'good implementation' is!

<snip>If I have to send commands to change the rate to handle the

>rampup, then the PC is still in a time critical loop, and I don't
>see how this hardware has helped much.

Yes, the PC is still in a time critical loop. But since we have
added 'time-capable' hardware to the PC, it can more easily handle
the task(s).

>Someone please explain the programming from the start point that I
>know I want to make a move and I have a count of X and Y values to
>move. On the smart box all I'd do is output a string like "move xxx
>yyy" and it would happen.
>ron g

I'm glad you asked this! I have also wondered if the 'dumb box' idea
was really worth it! From Mariss' response, it appears we are 'servo-
ing', whether it's a stepper or not. That is, current position
is 'derived' rather than implicitly commanded. He didn't give a 2
axis answer. I think that means the same calcs are done for each axis
and all the bytes go out at the same time? Still haven't seen where
the direction bit(s) come in?

And I'm still waiting for an answer to my earlier post asking if a
circle will consist of 1024 'rate changes' per second?...

Hope this helps.

Ballendo

P.S. Anyone have the source for/from an HPGL plotter? Not the ROM
image, but the actual algorithms... And I'm aware of the HPGL
emulations (like luberth and several other europeans) which run on
the PC. What I'm interested in is the OLD code...