smart box command set was RE: Re: interp and algorithms of mult axes
Posted by
ballendo@y...
on 2000-12-10 17:34:17 UTC
Carlos wrote:
To get around any legal action. Think like phoenix and the IBM bios
(they were the ones who "cracked" the ibm bios chipset and made the
term "IBM compatible" possible). That is, one person looks at the
source, and describes its' function completely. A second person, who
MUST NEVER have seen the source, works only from the given
description, to create a compatible functionality.
The clearest and briefest set I've seen is the InStep motion library
by Microkinetics. It would be VERY easy to 'personalise' this set
since each command starts with 'IS' as in ISARC (for an arc command).
The Canonical commands of EMC do not include (yet) all we would want,
but they ARE readily available, designed for the application, and
fairly succinct. And well documented.
I personally would cast a vote against using the IndexerLPT command
set. Although fairly extensive, I believe it is overly verbose. Also,
It would not surprise me if Art V pursued legal action against its'
use by us.
And then there are MANY motion control companies who have developed a
set of commands for their proprietary systems. Galil, AB, etc.
Next.
I think the ACTUAL commands sent (over the link to the box) should be
as short as possible, balanced with an understandable communication.
I wouldn't go so far as NASA in 1969 (looking through the book to see
what error 212 was while we were trying to land on the moon) , but
I'd surely like to see ARCP, rather than ARC_TO_POINT (followed by
numerical params). The serial link does have an additional point in
its favor(if used in a std. way); It will be easy to see what
the 'desktop' is sending to the 'black box'.(using a terminal
program) Both for S/W development and troubleshooting user
installations.
I think we should send parameters as steps to the box, rather than
units. Keeping with the idea of doing as much in the desktop as
practical.
Hope this helps.
Ballendo
>I feel this way too!! Maybe that's why I feel so strongly that toOkay, here are some suggestions.
>make this whole black box project succeed, we should just pick a
>currently published and useable command set to "emulate", so that
>the software guys can start doing their thing real soon, as
>opposed to spending another year in discussions to (re-)invent a
>"new" command set.
To get around any legal action. Think like phoenix and the IBM bios
(they were the ones who "cracked" the ibm bios chipset and made the
term "IBM compatible" possible). That is, one person looks at the
source, and describes its' function completely. A second person, who
MUST NEVER have seen the source, works only from the given
description, to create a compatible functionality.
The clearest and briefest set I've seen is the InStep motion library
by Microkinetics. It would be VERY easy to 'personalise' this set
since each command starts with 'IS' as in ISARC (for an arc command).
The Canonical commands of EMC do not include (yet) all we would want,
but they ARE readily available, designed for the application, and
fairly succinct. And well documented.
I personally would cast a vote against using the IndexerLPT command
set. Although fairly extensive, I believe it is overly verbose. Also,
It would not surprise me if Art V pursued legal action against its'
use by us.
And then there are MANY motion control companies who have developed a
set of commands for their proprietary systems. Galil, AB, etc.
Next.
I think the ACTUAL commands sent (over the link to the box) should be
as short as possible, balanced with an understandable communication.
I wouldn't go so far as NASA in 1969 (looking through the book to see
what error 212 was while we were trying to land on the moon) , but
I'd surely like to see ARCP, rather than ARC_TO_POINT (followed by
numerical params). The serial link does have an additional point in
its favor(if used in a std. way); It will be easy to see what
the 'desktop' is sending to the 'black box'.(using a terminal
program) Both for S/W development and troubleshooting user
installations.
I think we should send parameters as steps to the box, rather than
units. Keeping with the idea of doing as much in the desktop as
practical.
Hope this helps.
Ballendo
Discussion Thread
ballendo@y...
2000-12-10 17:34:17 UTC
smart box command set was RE: Re: interp and algorithms of mult axes
Wally K
2000-12-10 18:37:57 UTC
smart box command set was RE: Re: interp and algorithms of mult axes