RE: EHP External Hardware Proposal

Hans -

I've got a pretty basic question. Are we talking about offloading
interpolation duties to external hardware? As in sending an arc-move
command to the external micro and then letting it execute the coordinated
motion? Or, are we talking about merely updating a count register for each
axis' "commanded position" and letting the external micro handle the servo
loop, PID gains and all? Or, are we just talking about blind stepper pulse
train generation...? I think I've heard a little of each from the various
people interested in this system architecture, and was just wondering what
the external micro's duties would be.

Carlos Guillermo

> -----Original Message-----
> From: hansw [mailto:hansw@...]
> Sent: Tuesday, February 01, 2000 1:31 PM
> To: cad
> Subject: [CAD_CAM_EDM_DRO]Re:EHP External Hardware Proposal
>
>
> From: hansw <hansw@...>
>
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --------------------------- ONElist Sponsor ----------------------------
>
> GET A NEXTCARD VISA, in 30 seconds. Get rates as low as 0.0 percent
> Intro APR and no hidden fees. Apply NOW.
> <a href=" http://clickme.onelist.com/ad/NextcardCreative7SR
> ">Click Here</a>
>
> ------------------------------------------------------------------------
>
> Welcome to CAD_CAM_EDM_DRO@...,an unmoderated list for
> the discussion of shop built systems in the above catagories.
> To Unsubscribe, read archives, change to or from digest.
> Go to: http://www.onelist.com/isregistered.cgi
> Log on, and you will go to Member Center, and you can make changes there.
> For the FAQ, go to http://www.ktmarketing.com/faq.html
> bill,
> List Manager
>
>