Re: Re: Linux EMC RS232?
Posted by
Ray Henry
on 2003-11-05 08:11:02 UTC
On Wednesday 05 November 2003 1:54 pm, CAD_CAM_EDM_DRO@yahoogroups.com
wrote:
pass up a lead in like dat, eh.
Yes, serial communication can be used to sync multiple motors. Nyquist
does it all the time with firewire and some statistical theory. We've
got paper mills in these parts where serial communication is used to sync
the surface speed of different diameter rollers with constantly changing
diameter rollers and re-rollers. They do it for a 1000' long machine and
make 40 ton rolls without streching tissue paper.
You are right, Don, it can not be easily done using operating systems,
other software, and ports that are essentially asynchronous or free
wheeling. It is easy to imagine getting out of sync with descrete serial
links to several motor drivers when your operating system decides to go
off and "pick it's nose" for a while in the middle of a write or read.
Some, but not all of these problems can be handled with buffers. Buffers
get you into a whole other set of problems.
The emc developers are in the midst of this very issue with the RTAPI and
hardware abstraction (HAL) stuff. There was a good discussion recently
between us and the MatPLC folk that focused on kernel side real-time v
user space real-time. Trolling in those waters might snag some good
stuff. Reading some of the code in the emc project at sourceforge's CVS
repository would also hint at where we are going with this. I can supply
links off line if it helps.
Ray Henry
BTW for the casual reader. Neither of these real-time systems has
anything to do with the hype about real time in business communication.
wrote:
> Message: 10Ho! Wah! (modestly obscene and sacreligious youpperism) How could a body
> Date: Tue, 04 Nov 2003 22:22:06 -0800
> From: Don Rogers <Don@...>
> Subject: Re: serial vs parallel port
>
> >Dear group can EMC use the RS232 port (serial) instead of the printer
> >port?
>
> This bring us a question I have had for a few months now. How can you
> truly synchronize multiple axis when driving them individually via a
> serial interface, IE from an indexer card vs a step/direction approach
> from a parallel port. The serial approach indicates giving one axis it
> instructions and the going to the next axis and giving it it's
> instructions.
>
> It seems to me that the indexer approach of sending serial commands to
> a single axis, however fast that can happen would lead to a bunch of
> individual movements not necessarily related to the goal at hand..
>
> Having looked at this for a while, I ended up stripping the indexer
> cards from my drivers to go to a step direction from a single port
> approach in the hopes that a single Command structure would be better
> than a discriminate command structure..
>
> Any discussion on this???
pass up a lead in like dat, eh.
Yes, serial communication can be used to sync multiple motors. Nyquist
does it all the time with firewire and some statistical theory. We've
got paper mills in these parts where serial communication is used to sync
the surface speed of different diameter rollers with constantly changing
diameter rollers and re-rollers. They do it for a 1000' long machine and
make 40 ton rolls without streching tissue paper.
You are right, Don, it can not be easily done using operating systems,
other software, and ports that are essentially asynchronous or free
wheeling. It is easy to imagine getting out of sync with descrete serial
links to several motor drivers when your operating system decides to go
off and "pick it's nose" for a while in the middle of a write or read.
Some, but not all of these problems can be handled with buffers. Buffers
get you into a whole other set of problems.
The emc developers are in the midst of this very issue with the RTAPI and
hardware abstraction (HAL) stuff. There was a good discussion recently
between us and the MatPLC folk that focused on kernel side real-time v
user space real-time. Trolling in those waters might snag some good
stuff. Reading some of the code in the emc project at sourceforge's CVS
repository would also hint at where we are going with this. I can supply
links off line if it helps.
Ray Henry
BTW for the casual reader. Neither of these real-time systems has
anything to do with the hype about real time in business communication.
Discussion Thread
paragon032003
2003-11-04 17:24:44 UTC
Linux EMC RS232?
Jon Elson
2003-11-04 22:21:47 UTC
Re: [CAD_CAM_EDM_DRO] Linux EMC RS232?
Ray Henry
2003-11-05 07:23:56 UTC
Re: Re: Linux EMC RS232?
Ejay Hire
2003-11-05 07:43:27 UTC
RE: [CAD_CAM_EDM_DRO] Linux EMC RS232?
Ray Henry
2003-11-05 08:11:02 UTC
Re: Re: Linux EMC RS232?
Jon Elson
2003-11-05 08:58:54 UTC
Re: [CAD_CAM_EDM_DRO] Re: Re: Linux EMC RS232?