Re:EHP External Hardware Proposal

Thanks to everyone that has responded to the subject of "External
Hardware Proposal"

I have set up a folder for this thread and it would make my email filter
work better if we had a common title in the Subject line how about
EHP for External Hardware Proposal

so any email on this subject would have a subject line

[CAD_CAM_EDM_DRO]Re: EHP whatever the current subject is on the subject
of EHP

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

There are lots of good suggestions, and I'd like to just condense my
response to

Matt Shaver
Bertho Boman
Fred Smith
Ron Ginger
Carlos Guillermo
Peter
and anyone else ..

in one email, If I don't respond to every suggestion it does not mean I
don't like it, it's just a matter of time. Just bring the subject up
again.

Begin-----------------
It would seem there is a lot of interest for external hardware and PC
program load sharing.
I think everyone has understood my dislike for any program that require
a special OS to run it.
RS-232 ( and soon USB ) is available and more importantly is easy to
write code for, on about every computer system I know of.

The proposal of using something like CANBus is fine, but I have not seen
any large selection of low priced CANBus cards for the PC, and is not as
ubiquitous as RS-232 is.

There is a general consensus that RS232 does in fact that the bandwidth
required for at least 4 Axis ( I think more ) , this is also backed up
by the commercial hardware that is available, and is already using a
similar idea.

I don't know about "peeking" in on the FlashCut connection ( No problem
to do that, but...) I would prefer if FlashCut would offer the protocol
and perhaps they will get more customers that way, after all they have a
head start and there will always be people that would prefer to buy it
rather then build it. Knowledge hoarding is a thing of the past, and
thanks to Internet, it is dying very quickly. But, some companies will
never learn...

Reliable RS-232 data transfer .
If the protocol for transfer of command and data were binary, It would
almost be as quick to simply echo back and let the PC confirm by using
the RTS/CTS handshake. At first glance it would appear this requires two
sets of handshake lines, from my Serial7(7 RS-232 multiplexer)
experience this work fine..

Pseudo code:-

PC send command and data

Microntroller(uP) receives command and data,
Puts it on the command and data stack, sets the Confirmed bit to 0
echo's back to the PC. ( should explain here, the RTS/CTS line at the
uP is connected to a portB pin, which is looking for interrupt on
change)

The PC receives the command and data,
compares with what was sent, and

1) if correct Sets the RTS/CTS line to inform the uP "use it"

2) if not correct, resend the same command and data.

The uP will do the following in:-

response to 1) the uP will "see" the RTS/CTS line from the PC and flag
the last command and data as usable, and increment the command/data
stack pointer ready for the next command.

response to 2) the uP will simply do it's normal thing

uP receives command and data,
Puts it on the command and data stack, sets the Confirmed bit to 0
echo's back to the PC.

As the command/data stack pointer has not been incremented, this command
simply replace the failed command, and continues to do so until the PC
and the uP agree...

So what does this accomplish.
1) the PC will know the uP has good data and can continue with
interpreting the next g-code step.
2) the uP has good data stacked in a command/data stack ready for use
when the current command is finished.

If we use a 2 byte command structure then there will be space for 65536
unique commands.

Any suggestions about this, could 256 unique command be enough ?

Anyway, if there is a need to inform the uP that the current command
need to be executed regardless of what the uP happens to be doing, it
would simply be
one of the unique commands followed by whatever command/data was needed
for it... I can described this in more detail.. if needed..
The idea here is to have a priority scheme.

The RTS/CTS can still be used for emergency stops, as the interrupt
handle in the uP would "know" that there are no current command to
confirm and this RTS/CTS must mean something important , like STOP all
MOTORS or whatever is decided it would represent.

Quick explanation of the RTS/CTS and DTR/DTS ..
The PC has control over setting/clearing the RTS line and it would be
connected at the uP end to a pin that can cause interrupts.
The PC can be set to respond to the DSR line which would be Set/cleared
by at the uP end.
----------------------
DSP
Well I have no problem with that, and agree it may be an over kill for
this application.

The DSP's are cheap, in the 1000 pcs price... I buy PIC's at the 100pcs
price and that's about 10-150% less than the catalog prices.

There are a few other things to consider....
1) if this is going to be a thing developed by members of this forum,
does anyone have the development hardware for any DSP'S...
2) I expect many people have assemblers, compilers, programmers, ICE's
(In Circuit Emulators ) for the PIC series... ( I have all of them )

-----------------------
The actual protocols.
Open to discussion, make it byte for command and the combination using
ASCII can still be AA through ZZ (676 commands if my math is correct )
which may be better for debugging purposes, but would still not be human
readable commands.

I think data should be binary, after all sending 97456 in ascii takes 5
bytes in binary it's done in two...

Data.
A command could have N bytes of related data and ( as in from my Serial7
work) the commands can have that number for the number of attached data
bytes embedded in it.

It would require a two byte command structure... here's an adapted
version of what I know works...

Command Byte description shown in nibble format
Byte #1 Byte #2
XXXX yyyy yyyy yyyy
MSnibble LSnibble

Where the lower three nibbles are dedicated to being commands and the
upper nibble would indicate how many Bytes of data are attached to this
command.

Example:-
30 02 (Hex) command 2 with 3 bytes of data

so the actual transmission from the PC would look like this

30 02 01 02 03 where the last 3 bytes (01 02 03) are the related
data.

This would facilitate up to 15 bytes of data being attached to any one
command ( 0 would mean zero bytes of data )

Would 16 byte of data be enough ? if not lets use it the upper 5 bits of
the two byte command and then there could be 31 bytes attached...

I use a much more complicated protocol in my Serial7 command structure.
but then it has to do much more...

This scheme works very well ...
-----------------------------

That's about all I have time for today, I will read more messages later
and reply to many of the issues that have been raised.

If I'm jumping the gun or on the wrong track, please let me know...

At the moment, it would-be best to hash out what is needed, and then
start the actual hardware/software implementation later. At the moment
I'm in the middle of a 4096 channel spectrum analyzer project and an 8
device Cholesterol Meter control project... these are the bread and
butter projects that supply the nickel and dimes needed for hobby stuff
like CNC projects....
I expect to start on this external hardware idea later this year... If
anyone else can do it before then, that's fine.... I'll still be doing
my thing anyway, and hopefully based of the results of this thread....

Comment please, don't be shy, I can take it.. flames and all...

regards
Hans Wedemeyer