Re: Signal gen Interface
Posted by
ballendo@y...
on 2000-12-09 17:05:43 UTC
John,
You may want to re-read the post(s) to Mariss re the pulse generator
AS USED WITH THE PC INTERRUPT / TIMING ARCHITECTURE. Not yelling,
just want to emphasise :-)
As I have repeatedly said, You can easily create an application
specific, motion control 'computer' and talk to it over a serial
link. It works well and is commercially viable. It is NOT usually a
PC (in the IBM PC sense of the word).
Old drafting plotters used a Z80 and a CTC chip for 2.5 axis. What we
want to do is harder, both because of the additional axis/ axes and
the much more variable feeds and loads...
ANY time you obtain feedrates by division of a master clock (as done
in the pc) you will NOT get evenly spaced rates. The math prohibits
it... IF the MASTER clock is fast enough, and your needed rates low
enough, you CAN 'get by'. And that's what the CNC S/W based controls
(using interrupts) have been doing.
Counting cycles (timing loops) to get your feed rates is MUCH better
(as long as the system is dedicated to doing a defined set of tasks
so that the loops are a GIVEN). This is simple when the 'black box'
is a known entity. In pc s/w development, there are SO many
variables...
Using a pc104 is either going to cost a bundle to get something fast
enough, or will be like trading in a yacht for a dinghy, IMO. That
is, IF you think of the pc104 the way you think of your desktop pc!
I agree with you that EMC is overly complicated (but I think much of
this could be corrected by a concerted effort, and goals determined
by a marketplace rather than a govt. project whose goals sre not
necessarily in line WITH the marketplace, or at least OUR part of it)
So what I'm saying is, this has all been done before... We are
really just discussing price in different terms.
If you want to write a pc104 pulse generator, you can. I'd suggest
using timing loops rather than relying on the hardware timers. If you
want to put a whole motion control system on a pc104, I'd suggest you
just use the desktop, as it's likely to have a better price/
performance.
I'll say again we seem to have two directions here. One, a cheaper
(and open) way of doing what the Engraving world has done for many
years. And two, a new way of 'partitioning the problem' to take
advantage of the pc speed and availability, while minimising its'
weaknesses for 'real time'.
Hope this helps.
Ballendo
You may want to re-read the post(s) to Mariss re the pulse generator
AS USED WITH THE PC INTERRUPT / TIMING ARCHITECTURE. Not yelling,
just want to emphasise :-)
As I have repeatedly said, You can easily create an application
specific, motion control 'computer' and talk to it over a serial
link. It works well and is commercially viable. It is NOT usually a
PC (in the IBM PC sense of the word).
Old drafting plotters used a Z80 and a CTC chip for 2.5 axis. What we
want to do is harder, both because of the additional axis/ axes and
the much more variable feeds and loads...
ANY time you obtain feedrates by division of a master clock (as done
in the pc) you will NOT get evenly spaced rates. The math prohibits
it... IF the MASTER clock is fast enough, and your needed rates low
enough, you CAN 'get by'. And that's what the CNC S/W based controls
(using interrupts) have been doing.
Counting cycles (timing loops) to get your feed rates is MUCH better
(as long as the system is dedicated to doing a defined set of tasks
so that the loops are a GIVEN). This is simple when the 'black box'
is a known entity. In pc s/w development, there are SO many
variables...
Using a pc104 is either going to cost a bundle to get something fast
enough, or will be like trading in a yacht for a dinghy, IMO. That
is, IF you think of the pc104 the way you think of your desktop pc!
I agree with you that EMC is overly complicated (but I think much of
this could be corrected by a concerted effort, and goals determined
by a marketplace rather than a govt. project whose goals sre not
necessarily in line WITH the marketplace, or at least OUR part of it)
So what I'm saying is, this has all been done before... We are
really just discussing price in different terms.
If you want to write a pc104 pulse generator, you can. I'd suggest
using timing loops rather than relying on the hardware timers. If you
want to put a whole motion control system on a pc104, I'd suggest you
just use the desktop, as it's likely to have a better price/
performance.
I'll say again we seem to have two directions here. One, a cheaper
(and open) way of doing what the Engraving world has done for many
years. And two, a new way of 'partitioning the problem' to take
advantage of the pc speed and availability, while minimising its'
weaknesses for 'real time'.
Hope this helps.
Ballendo
>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.
>
>In my opinion EMC is still way two complicated for the average HSM to
>set up and make use of.
>
>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 think the key is making sure that the processor only has a very
>limited number of things it must do.
>John G
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