Re: Signal gen Interface
Posted by
Carlos Guillermo
on 2000-12-08 10:26:29 UTC
Jeff, Ron, and John -
I, too, think I'm on the same page as you, but somewhere on the
margin.
I agree with Ron's post about letting the PC calculate the next
coordinate, and letting the box manage the rest. This would mean
using a command set similar to SimpleStep, Pic Servo, or
IndexerLPT.
I also agree with John's idea of using a single-board computer or
equivalent (such as a not-as-small-but just-as-handy...old PC).
If this computer is limited to pulse generation duties, it should
have no problem producing 50kHz + output.
Now here's the part I see this all coming back to:
We're going to need a CNC control that can produce the appropriate
data for the "box" to receive and convert into coordinated motion.
Ron's CPNC would be one good candidate. The "box" can be an old
486. And then we need the s/w to load into the "box" to produce
the step/dir output. We already have several of these programs
available (as mentioned above; IndexerLPT being my choice). It
seems the big objection to this route is paying a couple hundred
bucks for IndexerLPT or the equivalent. We're talking here of
having to write an equivalent program anyway, so why not just
emulate IndexerLPT, including its command set??? Am I missing
something?
Carlos Guillermo
VERVE Engineering & Design
-----Original Message-----
From: John D. Guenther [mailto:jguenther@...]
Sent: Friday, December 08, 2000 10:42 AM
To: CAD_CAM_EDM_DRO@egroups.com
Subject: [CAD_CAM_EDM_DRO] Re: Signal gen Interface
Jeff / Ron,
I am on the same page you two are. I have been looking at
something
like a PC104 single board computer which has both serial and
parallel
ports. Do the g-code stuff, trajectory planning and what ever
else on
the PC, when gets to the point of being ready to make a move, send
a
simple move command to the SBC which would calculate the number
of
steps, create the pulses and maybe even monitor encoders for
position
feedback. If you were thinking about EMC, that would be like
putting
the emcio and emcmot functions on the SBC and keeping the
remainder of
the functions on the PC.
In my opinion EMC is still way two complicated for the average HSM
to
set up and make use of. EMC is a nice product that does a lot,
maybe
two much for the average home shop, but it requires a great deal
ok
knowledge that I am not sure most HSM's posses.
Using something like a small single board computer should allow
rather
easy development of an open architecture pulse generator that
could
work with both steppers and servos, function in either open or
closed
loop environments and overcome many of the current limitations
seen
with Windows and real time applicatons. I had plans to write a
CNC
program for the SimpleStep controllers, but I feel that is to
limiting. I plan on starting to explore the above described
solution
very soon. I might be a little nieve here, but I don't see any
reason
why this type of solution can't work. Sure, the cost will be more
than $20.00 per axis for the "pulse generator" but then if it wil
work
with a single board computer for the pulse generator, then it
would
also work with an old PC for the pulse generator. I think the key
is
making sure that the processor only has a very limited number of
things it must do. You should be able to get a reasonable pulse
stream out of almost any processor if the only thing it has to do
is
generate the pulses and maybe monitor the encoders for position.
John Guenther
I, too, think I'm on the same page as you, but somewhere on the
margin.
I agree with Ron's post about letting the PC calculate the next
coordinate, and letting the box manage the rest. This would mean
using a command set similar to SimpleStep, Pic Servo, or
IndexerLPT.
I also agree with John's idea of using a single-board computer or
equivalent (such as a not-as-small-but just-as-handy...old PC).
If this computer is limited to pulse generation duties, it should
have no problem producing 50kHz + output.
Now here's the part I see this all coming back to:
We're going to need a CNC control that can produce the appropriate
data for the "box" to receive and convert into coordinated motion.
Ron's CPNC would be one good candidate. The "box" can be an old
486. And then we need the s/w to load into the "box" to produce
the step/dir output. We already have several of these programs
available (as mentioned above; IndexerLPT being my choice). It
seems the big objection to this route is paying a couple hundred
bucks for IndexerLPT or the equivalent. We're talking here of
having to write an equivalent program anyway, so why not just
emulate IndexerLPT, including its command set??? Am I missing
something?
Carlos Guillermo
VERVE Engineering & Design
-----Original Message-----
From: John D. Guenther [mailto:jguenther@...]
Sent: Friday, December 08, 2000 10:42 AM
To: CAD_CAM_EDM_DRO@egroups.com
Subject: [CAD_CAM_EDM_DRO] Re: Signal gen Interface
Jeff / Ron,
I am on the same page you two are. I have been looking at
something
like a PC104 single board computer which has both serial and
parallel
ports. Do the g-code stuff, trajectory planning and what ever
else on
the PC, when gets to the point of being ready to make a move, send
a
simple move command to the SBC which would calculate the number
of
steps, create the pulses and maybe even monitor encoders for
position
feedback. If you were thinking about EMC, that would be like
putting
the emcio and emcmot functions on the SBC and keeping the
remainder of
the functions on the PC.
In my opinion EMC is still way two complicated for the average HSM
to
set up and make use of. EMC is a nice product that does a lot,
maybe
two much for the average home shop, but it requires a great deal
ok
knowledge that I am not sure most HSM's posses.
Using something like a small single board computer should allow
rather
easy development of an open architecture pulse generator that
could
work with both steppers and servos, function in either open or
closed
loop environments and overcome many of the current limitations
seen
with Windows and real time applicatons. I had plans to write a
CNC
program for the SimpleStep controllers, but I feel that is to
limiting. I plan on starting to explore the above described
solution
very soon. I might be a little nieve here, but I don't see any
reason
why this type of solution can't work. Sure, the cost will be more
than $20.00 per axis for the "pulse generator" but then if it wil
work
with a single board computer for the pulse generator, then it
would
also work with an old PC for the pulse generator. I think the key
is
making sure that the processor only has a very limited number of
things it must do. You should be able to get a reasonable pulse
stream out of almost any processor if the only thing it has to do
is
generate the pulses and maybe monitor the encoders for position.
John Guenther
--- In CAD_CAM_EDM_DRO@egroups.com, Jeff Barlow <jeff@b...> wrote:
> Ron,
>
> I'm not sure any two of us are on the same page here! I think
you
and I
> have at roughly similar ideas, though.
>
> With this many ideas flying around we're bound to stumble over a
few
> good ones.
>
> Jeff
>
>
> On Thu, 07 Dec 2000 22:58:49 -0500, you wrote:
>
> >I am not sure we are all talking about the same kind of box
here.
In my
> >view there are no interrupts between the box and the PC. My
view is
like
> >the command set of the Simple Step or Pic Servo, or even
INDEXER.LPT.
> >
> >The PC would calculate the next coordinate, and the box would
handle all
> >the timing, sending back some kind of ACK when that move had
occurred,
> >and ready for the next move. The moves can all be in just step
units,
> >let the PC figure out how many steps to move and do the inches
or
MM
> >stuff.
> >
> >This discussion of frequency generators and interrupts is still
in
the
> >domain of someting that requires a device driver. I think a
parrallel
> >port or serial- or even a USB would be fine. I know USB has
some
timing
> >issues, but remember Im thinking that the commnads to the box
will
be
> >for entire moves not for single steps.
> >
> >Are we all on the same page here?
> >
> >ron ginger
Discussion Thread
ron ginger
2000-12-07 19:00:26 UTC
Signal gen Interface
Jeff Barlow
2000-12-07 19:12:15 UTC
Re: [CAD_CAM_EDM_DRO] Signal gen Interface
Wally K
2000-12-07 19:54:28 UTC
Re: Signal gen Interface
Jeff Barlow
2000-12-07 20:16:42 UTC
Re: [CAD_CAM_EDM_DRO] Re: Signal gen Interface
John D. Guenther
2000-12-08 07:42:13 UTC
Re: Signal gen Interface
Carlos Guillermo
2000-12-08 10:26:29 UTC
Re: Signal gen Interface
Greg Nuspel
2000-12-08 10:40:29 UTC
Re: [CAD_CAM_EDM_DRO] Re: Signal gen Interface
PhilC
2000-12-08 10:51:28 UTC
Re: [CAD_CAM_EDM_DRO] Re: Signal gen Interface
Carlos Guillermo
2000-12-08 12:10:55 UTC
RE: [CAD_CAM_EDM_DRO] Re: Signal gen Interface
PhilC
2000-12-08 12:47:55 UTC
Re: [CAD_CAM_EDM_DRO] Re: Signal gen Interface
Carlos Guillermo
2000-12-08 13:18:23 UTC
RE: [CAD_CAM_EDM_DRO] Re: Signal gen Interface
Jeff Barlow
2000-12-08 14:21:30 UTC
Re: Signal gen Interface
Jeff Barlow
2000-12-08 14:26:13 UTC
Re: [CAD_CAM_EDM_DRO] Re: Signal gen Interface
Greg Nuspel
2000-12-08 14:38:56 UTC
Re: [CAD_CAM_EDM_DRO] Re: Signal gen Interface
Jeff Barlow
2000-12-08 15:01:08 UTC
Re: [CAD_CAM_EDM_DRO] Re: Signal gen Interface
Jon Elson
2000-12-08 16:03:51 UTC
Re: [CAD_CAM_EDM_DRO] Re: Signal gen Interface
Brian Pitt
2000-12-08 22:03:25 UTC
Re: [CAD_CAM_EDM_DRO] Re: Signal gen Interface
ballendo@y...
2000-12-09 17:05:43 UTC
Re: Signal gen Interface
ballendo@y...
2000-12-09 18:05:42 UTC
Re: Signal gen Interface
ballendo@y...
2000-12-09 18:22:55 UTC
Re: Re: Signal gen Interface
PhilC
2000-12-09 18:29:43 UTC
Re: [CAD_CAM_EDM_DRO] Re: Re: Signal gen Interface
JanRwl@A...
2000-12-09 19:07:43 UTC
Re: [CAD_CAM_EDM_DRO] Re: Re: Signal gen Interface
ballendo@y...
2000-12-09 23:06:35 UTC
Re: Re: Re: Signal gen Interface