The settings for frame start & end detection have to match the protocol & frame construction of your message.  If you do not have explicit start and end sequences for your frame, the default settings assume that a frame starts with the first character of a burst of characters on the communications line, and ends if a specified time elapses without any new characters being received.   The time delay is in character transmit times: for 9600 bps and the default of 288 bit times, this means a end-of-frame timeout = 288 / 9600 = 30 ms.   To turn this into a send frequency from the partner CPU, calculate the transmission time of your data frame = (number of bytes in frame) * 11 bits per character / 9600.  For 32 bytes of data, this would be 32 * 11 / 9600 = 37 ms.   Add the end-of-frame delay of 30 ms, and the minimum period between sends should be 37 + 30 = 67 ms.

You can adjust the end-of-frame time to detect shorter breaks.  You cannot send data faster than your configured baud rate, so long frames will take longer to send, and if you try to send another frame before your first frame has completed, the result will be a long stream of data with no end-of-frame breaks.

Other settings I would consider changing:

• I usually do not set "Prevent overwriting".  The reason for this is that if my receive code falls behind or gets turned off for a while, I don't want the receive buffer filling up with old data.  I usually am only interested in new frames that arrive while I am watching for them.  Whether this setting is right for your application depends on the needs of your application.
• I am a fan of setting "Clear receive buffer on startup", discarding any data received while the PLC is not in RUN mode.  This prevents you from having a buffer full of old data confusing things when the program starts.
• The transmission rate, parity, data bits, parity, and stop bits must match on both communication partners.  Note that some devices do not support 11-bit character frames: for them if you want 8 data bits, you must choose "no parity".  I am not a fan of "Any" parity, as it adds an extra bit to the character frame without actually doing parity checking.  FYI: 8 data + 1 start + 1 stop + 1 parity = 11 bits/character
• Unless your protocol requires it, I would not use XON/XOFF flow control.  The issue here is that if the sender sees an XOFF character, it will stop sending until it receives an XON character.  If you are sending binary data, a byte of data may have the same value as the XOFF character, causing you to accidently stopping the partner from sending its next data frame.  For initial testing using a direct cable, I would set Data flow control to "None".  If you are using modems or other devices that introduce latency, then "Hardware RTS always switched" is probably the right choice, but it depends on your cable.

mmckay

The settings for frame start & end detection have to match the protocol & frame construction of your message.  If you do not have explicit start and end sequences for your frame, the default settings assume that a frame starts with the first character of a burst of characters on the communications line, and ends if a specified time elapses without any new characters being received.   The time delay is in character transmit times: for 9600 bps and the default of 288 bit times, this means a end-of-frame timeout = 288 / 9600 = 30 ms.   To turn this into a send frequency from the partner CPU, calculate the transmission time of your data frame = (number of bytes in frame) * 11 bits per character / 9600.  For 32 bytes of data, this would be 32 * 11 / 9600 = 37 ms.   Add the end-of-frame delay of 30 ms, and the minimum period between sends should be 37 + 30 = 67 ms.

You can adjust the end-of-frame time to detect shorter breaks.  You cannot send data faster than your configured baud rate, so long frames will take longer to send, and if you try to send another frame before your first frame has completed, the result will be a long stream of data with no end-of-frame breaks.

Other settings I would consider changing:

• I usually do not set "Prevent overwriting".  The reason for this is that if my receive code falls behind or gets turned off for a while, I don't want the receive buffer filling up with old data.  I usually am only interested in new frames that arrive while I am watching for them.  Whether this setting is right for your application depends on the needs of your application.
• I am a fan of setting "Clear receive buffer on startup", discarding any data received while the PLC is not in RUN mode.  This prevents you from having a buffer full of old data confusing things when the program starts.
• The transmission rate, parity, data bits, parity, and stop bits must match on both communication partners.  Note that some devices do not support 11-bit character frames: for them if you want 8 data bits, you must choose "no parity".  I am not a fan of "Any" parity, as it adds an extra bit to the character frame without actually doing parity checking.  FYI: 8 data + 1 start + 1 stop + 1 parity = 11 bits/character
• Unless your protocol requires it, I would not use XON/XOFF flow control.  The issue here is that if the sender sees an XOFF character, it will stop sending until it receives an XON character.  If you are sending binary data, a byte of data may have the same value as the XOFF character, causing you to accidently stopping the partner from sending its next data frame.  For initial testing using a direct cable, I would set Data flow control to "None".  If you are using modems or other devices that introduce latency, then "Hardware RTS always switched" is probably the right choice, but it depends on your cable.

 Thanks again for the help!

I managed to get it working by following the settings you suggested.

One thing that I found is when I tried to implement them into my program it didn't work at first, which led me to create a new program solely to test the comms from scratch, and having the settings you suggested above, it sent and received between both PLCs perfectly.

My guess is that the problem was that it wasn't identifying when to stop sending and start receiving, which the settings you suggested fixed.

I appreciate your help and thanks again!