050604-0946 EST USA
I see a lot of discussion on various sites where the user is using 2 stop bits for RS232 communication.
I see no need for using 2 stop bits vs 1 stop bit, and 2 stops bits reduces your thruput to about 90% of that for 1 stop bit ( based on about 10 bits in the asynchronous word ). The only exception would be if the destination had a fixed setting of 2 stop bits and you could not change this. Note, a stop bit is the same as the asynchronous rest state.
The criteria that must be met on stop bits is: the receiver must be set to less than or equal to the number of transmitter stop bits. So a transmitter could be set to 1 or more stop bits ( like 2 ) and the receiver to 1 stop bit with no problem. Normal UARTs only provide for 1 or 2 stop bits.
Most systems do not allow independent setting of stop bits. Thus, you must set both ends of the RS232 link to exactly the same number of stop bits, and I suggest that this should be 1.
On parity:
Parity is a means of detecting certain types of errors on a per asynchronous word basis.
XMODEM is a different animal. This is a block of words error detection and correction method. Parity will be set to none in the usual use of XMODEM. The following assumes we are not using XMODEM.
In standard UARTs for serial communication the option is available for adding a 1 bit parity check to the transmitted word. The 1 bit parity check will detect any odd number of bits in error in the word containing the parity bit. If a single bit in the word is in error ( 0 changed to 1, or 1 changed to 0), then this will cause a parity error.
With a single bit parity check --- if 2 bits in a word are reversed or any other even number of bits, then no error is detected. If more bits are added for parity check, then better error detection can be achieved. However, normal UARTs are only built with the capability for single parity bit operation.
Whatever parity selection is used ( none, even, odd ) this nust be identical at both transmit and receive ends.
I suggest that using either parity is better than none because the destination will respond to that error immeadiately. Thus, you won't run or save a program with an error that can be detected by the parity check.
There is more to why a single bit parity check is pretty good, but you are probably better off with XMODEM, especially in large DNCed programs.
When you can fully load a program into CNC memory, then a very good error detection method is to dump the program back to the computer and do a file comparison with the original file sent.
www.beta-a2.com
.