I don't know the answer but suggest two things to consider:

1. Sending all four lines in one write() may burst data faster than the receiver can actually handle.
2. You might check on the newlines in the string sent by the write(), they could be different from what you type manually to HyperTerm.

My first guess would be [1] based on the varying error pattern.

I've sent the data line at a time, and even character at a time, so I don't think 1 is the issue. (what do you mean by burst data?)

I'll try changing the newlines, but I've also used triple quoted line breaks, which is exactly the same as would be sent by hyperterminal.

Thanks anyway.

That's cool. I didn't even know there was a PySerial module.

First, the error messages are confusing. Are those the result of the print motor.read(motor.InWaiting()) command?

Second, just to back up Bear's point:

Since the motor is known good, and since hyperterminal works, it therefore follows that PySerial isn't sending the data in the same manner as hyperterminal.

One possibility ("burst data") is that the motor needs to pause, even if a millisecond, after each line. In that case, manually entering into hyperterminal might provide that slight pause that the automated process in Python does not.

The solution there would be to read the motor after each line to make sure that you are getting a 'ready' status.

The other possibility is that the sequence of characters is different. A common culprit is the newline. On some systems, return is 0x0A ('\n'). On others, return is TWO characters 0x0A 0x0D ('\n\r')

So it could be that PySerial is sending a different kind of newline from hyperterminal.

Without knowing more about your motor (and PySerial), I couldn't say how to test for those problems exactly, but those are the problems I would test for.

Jeff

Ok thanks.

The error messages are sent by the motor, which normally should return every byte sent (which it does, but sometimes with an error in a random spot).

I'll play around with pauses, and I'll try the other kind of newline.

I managed to fix the problem.

By re-reading the manual, I found out that a carriage return (\r) was required to delimit a command. Using this fixed the problem.

Thanks for your help.

Mark as solved and give Bear of NH props.

Jeff

... and thank sb3700 for closing the loop here. Six months from now somebody else will have the identical problem and with a bit of googling will see the solution, thus reducing global aggravation.

Just a note, the RS232 serial port is quickly disappearing on most newer computers. Has anyone worked with a USB port?

I was using a 4-port USB to RS232 converter (4 RS-232's for one USB port that is).

They work fine