586,102 active members*
2,704 visitors online*
Register for free
Login
Results 1 to 5 of 5
  1. #1
    Join Date
    Mar 2005
    Posts
    1498

    Stop Bits, Parity

    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

    .

  2. #2
    Join Date
    Mar 2003
    Posts
    4826
    Interesting. If you add a parity bit, does this require more processing time at the cnc to do the parity check? I'm all for whatever is good in reliable communication. I've always used 2 stop bits and Parity "none", just because I thought that was some kind of time proven combo that was established long ago.
    First you get good, then you get fast. Then grouchiness sets in.

    (Note: The opinions expressed in this post are my own and are not necessarily those of CNCzone and its management)

  3. #3
    Join Date
    Dec 2003
    Posts
    24221
    I know at one time the protocol was programed by addressing the firmware of the UART, this is the IC that takes care of the hardware port of RS232, adding parity check should not affect processing time , just that the UART would normally just set an alarm bit on the UART on parity error.
    The original standard was EIA which has been pretty much replaced by ISO (ASCII) communication on CNC, the EIA I believe used a parity bit in the 5th bit, but was 8 bits wide.
    Al.
    CNC, Mechatronics Integration and Custom Machine Design

    “Logic will get you from A to B. Imagination will take you everywhere.”
    Albert E.

  4. #4
    Join Date
    Mar 2005
    Posts
    1498
    050604-1237 EST USA

    Hu:

    Al is correct that the processing of the parity bit is in the UART and takes no additional processing time in the CPU other than testing the UART parity bit and this is negligble.

    As I previously indicated using parity adds 1 bit to the asynchronous word, thus approximately 10% to transmission time. This is a small price to pay for error detection.

    But still remember that XMODEM is better for error detection because it effectively includes correction up to a point.

    You are far better off with parity enabled as I previously discussed.

    There is a lot of information presented on various web sites that is not based on basic fundamentals.

    For example, it is very hard to find a source that gives the precise relationship between inches and centimeters. The answer for the exact relationship is 1 inch = 2.54 cm with as many zeroes to the right as you want. Whereas 39.37 in = 1 meter is only an approximation.

    .

  5. #5
    Join Date
    Mar 2005
    Posts
    1498
    050604-1348 EST USA

    Some more comments:

    RS232 communication as normally used, with or without parity, is an open loop system (no feedback).

    In such an open loop system you must have an extremely low error rate, and that requires a very high "signal-to-noise" ratio. To send a 10 million byte file to a CNC without error you must have zero errors in 100 million bits. And really it means the error rate must be much less than 1 bit per 100 million.

    XMODEM or similar programs send a block of data, for example 128 bytes, with included check data. At the destination the received block of data is tested for errors. If one or more errors exist the sender is asked to resend the block. This will be repeated some number of times until the system gives up. The lower the "signal-to-noise" ratio the greater the number of retransmissions. This is a feedback system that can provide error detection and correction up to some point.

    This will take some time in the CNC CPU, but not much.

    The feedback system can operate at a much lower "signal-to-noise" ratio than the open loop system and provide error free operation.

    .

Similar Threads

  1. uploading from machine
    By miljnor in forum Haas Mills
    Replies: 21
    Last Post: 06-15-2005, 04:02 PM
  2. Show me the bits
    By darth442 in forum MetalWork Discussion
    Replies: 0
    Last Post: 05-18-2005, 07:34 AM
  3. Reading 12 bits // encoder - Lead & Lag
    By dehclau in forum CNC Machine Related Electronics
    Replies: 9
    Last Post: 10-27-2004, 08:03 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •