PDA

View Full Version : Serial or Parallel port drive



Max
05-28-2003, 09:11 AM
I'd like to know some thoughts on whether it's better to build using Software and Driver boards made for the Serial Port or the Parallel Port.

I guess it's one of those questions like Stepper v. Servo

Also, I've seen where there is some software that is able to use the usb port

marting
05-28-2003, 04:10 PM
Hi Max,
I think your best bet is to go for the parallel port, naturally if you have only one which might be used by the printer then you'll be needing to buy another one. That's what I've on mine. Most software use this port.
Regards
Martin

balsaman
05-28-2003, 04:35 PM
What Martin said. 99% of the (inexpensive) software uses the parallel port.

Eric

Bill C
05-28-2003, 05:15 PM
So Balsaman,

What are you saying? I understand the 'inexpensive software' part but are you inferring that 'good' or 'better' (expensive)software uses the serial port? The question was good and I have read some on this but you seem to have an answer there somewhere. Which and why? Do you mean that there is only 1% of the software (inexpensive) that uses the serial port or, that 'expensive' software uses the serial port as a rule?

Bill C.

bcromwell
05-29-2003, 01:41 PM
On the techie side of things, Serial is slower, and has less I/O than the parallel port. So I don't see why you would want to use serial.
.002$

c_nut
10-29-2004, 12:28 AM
The only real difference between serial and parallel and USB is the hardware connector and the software driver. They all do the same job - get data out of the computer. Parallel has a wider path, ie. eight bits however serial does the same eight bits one at a time and with the speed or non speed of CNC it doesn't make a hoot of a difference. No matter how fast your CNC goes the serial port will stay ahead of it.
The only noticable difference would be with over 4 axises would require a second parallel cable while serial could handle more than four axises with one cable. It has always been my creed and I preached it to all of my customers. Buy the software you need to do your job then get the hardware required by that software. You never ask what size tires would be best on a car?
c_nut
In the swamps north of I10 mile post 223.

d.miller
10-29-2004, 12:52 AM
To control a motor from the PC you basically need to be able to tell it which direction to rotate, and when to rotate a given amount. When you're controlling stepper motors this comes down to a pin for direction and a pin for stepping. The vast majority of stepper motor controllers require these 2 inputs, a step and a direction.

This makes the parallel port a great way to communicate with motor controllers. You can manipulate the bits in the various registers (and therefore the voltages on the pins of the ports) very easily. And with the parallel port you can do this for 6, 8, even 12 output pins at the same time.

Also, the parallel port has been around for a long time, and is pretty much the same from OS to OS, and there are a lot of readily available tools to get your software to communicate with the parallel port.

With the serial port you can only manipulate the signals on one pin basically, so you move the timing and movement logic from the PC to the controller, requiring a microcontroller or some other device. This means there has to be some set of commands to communicate the movements, and without a standard communication language each set of software would have to have its own controller that spoke its language.

Same type of issues with USB, I would think. And USB seems like it would be more subject to the timing issues in Windows than the serial or parallel port.

Of course, as I write all this I'm developing a serial port stepper motor controller. Man, looking back over this I've written some pretty obvious stuff. I apologize. It's late.

Daniel
Salem Controls Inc.
http://www.salemcontrols.com/

imserv
10-29-2004, 09:10 AM
I'd like to know some thoughts on whether it's better to build using Software and Driver boards made for the Serial Port or the Parallel Port.


In MS Windows the priorities are controlled by the operating system. Until about 3 years ago, there were no applications that could achieve more than a couple thousand steps per second.

Since that time, parallel port controllers have been released that achieve up to about 45000 steps per second. (There are also a few bus based controllers for windows, but the price is considerable higher)

There is now a Serial port controller that will achieve 128,000 steps per second.

A serial port controller uses a higher level communications protocal to communicate with an external dedicated microcontroller. In this manner many bits passed through the parallel port are reduced to a simple line or arc command. The dedicated microcontroller easily processes the motion commands into discrete step and direction signals for multiple axes.

Parallel port controllers usually require a breakout board to manage the electrical interface from the computer parallel port, to the motor driver electronics, limit switches, relays, etc. of the cnc machine. The external controller board provides this functionality with the serial port systems.

With Windows, the cost of parallel port software and a breakout board is about the same as a serial port controller board and software.

Fred Smith - IMService
http://www.cadcamcadcam.com

Ryobiguy
11-02-2004, 01:20 AM
Parallel can be better for simple high speed/critical timing applications, like pulsing a motor driver to hold a controlled velocity. You can turn a pin on or off in one operation, so it's quick. Since the pins are hardwired to specific control circuitry, it's very fast saying to what thing you're changing the binary value.
Serial (on a stock PC) is great if you have things that you want your PC to talk to on a slower pace. The data you send/receive can be simple (like a data byte) or quite complex like a string of characters. Things like: a simple DRO, a tachometer, or a keypad would probably be good applications for serial, as long as it's not too performance critical.
Serial has to clock in (pulse a clock signal after setting the data line on or off,) some minimum number of bits to do anything really useful, so you have to wait for at least 8 clock cycles (115k/second [or higher]) to write out a byte. Since it took some thought to explain that, you can understand that the complexity is a lot more than parallel. (USB is even more complicated.)

So, it depends what you're doing. Motor drivers call out for parallel - cheap, fast, easy.