rs-485 stop bit not generated.

[AlanKnowler]

We are transmitting data on NI RS-485/4 cards in Labwindows 5.5 under Win2000. OpenComConfig is used to configure and open the port.

When the number of STOP bits is set to 1 NO stop bits are generated.
This behaviour has been observed on a scope. The start bit is followed by data bits, followed by the parity bit. The signal then goes tri-state.

When the number of STOP bits is set to 2, 1 stop bit is observed.


When the same code is used with an RS232 port the correct stop bits are generated.

This is seen to happen on different pieces of test kit (identical configuration).
The port configuration is: 115200 Baud, 8 data bits, odd parity. Slower baud rates have been tried and the same problem is observed.


Any ideas?

T
hanks Alan

[Randy Solomonson]

Hello-

We tried this on Windows 2000 and 98 for the same results using 4-wire mode using the example samples\rs232\CommCallback with the PCI-485/4 board. The only thing changed in the example is the COM port number and the number of stop bits for each run. The string "UU" was sent which gives a nice 01010101 for each, so you can see the stop bits between them. Attached are the captured the screenshots.

Try this example with "UU" and capture the scope shots, we can compare and see if we have common results.

What are the reasons for such a concern? Has this card not been able to communicate with a device? What voltage levels do the transceiver/UART expect on the other device? This information should be listed on the datasheets
for the device, or the manufacturer may know.

Randy Solomonson
Application Engieer
National Instruments

[AlanKnowler]

Thanks for your response Randy,

The RS-485 ports are configured as 2-wire ports by connecting pin 4 to 8 and pin 5 to 9 of the 9 pin D connector in the target test equipment.


The target test equipment is configured to use 1 stop bit. We have experienced random failures in the '485 transmission between terminals. An investigation revealed that we appear not to be sending the stop bit.

> What are the reasons for such a concern?
Our customer's requirement is to transmit 1 stop bit.


I�ve attached traces from the �485 card. They were created at 38400 baud, odd parity, 8 data bits. Traces were recorded with stop bits set to both 1 and 2 (see filename for setting).
The following data was transmitted:

Hex value 0x1
Hex value 0x5
ASCII character sequence UU


Here is my interpretation of the traces.
All references to the trace are to the top (yellow) waveform...

Description of: 0x1_384bd_odd_8data_1stop.jpg
Hex value 0x1, transmitted at 38400 baud, 8 data bits, odd parity, 1 stop bit.
The start bit is seen (1 then 0 on left-hand side).
Followed by the data; 1 0 0 0 0 0 0 0. (LSB transmitted first)
Followed by parity �0�
No stop bits seen before the signal goes to a �tri-state�

Description of: 0x1_384bd_odd_8data_2stop.jpg
As for the one stop bit version, but after the parity bit (�0�), one stop bit is seen (should be two bits)



Description of: 0x5_384bd_odd_8data_1stop.jpg
Hex value 0x5, transmitted at 38400 baud, 8 data bits, odd parity, 1 stop bit.
The start bit is seen (1 then 0 on left-hand side).
Followed by the data; 1 0 1 0 0 0 0 0. (LSB transmitted first)
Followed by parity �1�
No stop bits seen before the signal goes to a �tri-state�

Description of: 0x5_384bd_odd_8data_2stop.jpg
As for the one stop bit version, but after the parity bit (�1�), one stop bit is seen (should be two bits)



Description of: UU_384bd_odd_8data_1stop.jpg
ASCI Characters UU, transmitted at 38400 baud, 8 data bits, odd parity, 1 stop bit.
(U = 0x55 = 01010101)
The start bit is seen (1 then 0 on left-hand side).
Followed by the data; 1 0 1 0 1 0 1 0. (LSB transmitted first)
Followed by parity �1�
No stop bits seen before the signal goes to a �tri-state�.
The sequence is then transmitted a second time.

Description of: UU_384bd_odd_8data_2stop.jpg
As for the one stop bit version, but after the parity bit (�1�), one stop bit is seen (should be two bits)



Regards,


Alan Knowler

[Chris_Rake]

Hi Alan,

I'm the engineer working with Randy. I verified proper functionality with CVI 6.0 in 4-wire mode, however you're using 2-wire auto. After looking at your traces, I have a theory as to what is happening. In short, it appears that the line is being tri-stated too early, and the last stop bit is being cut-off. I have to look at the design, but I suspect that the mechanism for the TX enable may not be handling the extra length that a parity bit adds to the transmission time. I'll try to verify this on Monday.

In the meantime, there are two things that can be done to help narrow this down.

1) Can you replicate this behavior with hyperterm? If my theory is correct, it should not matter which application is being used
.
2) Can you use either of the 2-Wire DTR-controlled modes instead? This will require programatic switching of TX Enable by changing the state of DTR, but it would give you total control over when the line is tri-stated.

+Chris

[AlanKnowler]

Chris/Randy
1) Yes. This behavior is also exhibited when I transmit to the rs-485 port using Hyperterm.

2) Not quite sure how this is performed. I tried the following in CVI code:
- opened the port using the OpenComConfig function call
- set the port to 2-wire DTR control using the function call ComSetEscape (COM_Port, WIRE_2_CTRL);
- before transmitting an RS-485 character byte, used the function call ComSetEscape (COM_Port, SETDTR); to assert DTR.
- after transmitting the RS-485 character byte, used the function call ComSetEscape (COM_Port, CLRDTR); to de-assert DTR.
This did not resolve the problem - an incorrect character format was transmitted by the '485 card.
Is this the correct method o
f programatically switching DTR? I couldn't find details of how this should be achieved in CVI, do you have any example code?

Alan

[Chris_Rake]

Hi Alan,

The set/clear DTR commands are not synchronous with data, and there may be a race between the CLRDTR and the transmission of the data. The incorrect character format is mostly likely a result of this. If you place a delay equal to the transmission time of your data, does this correct the problem?

[AlanKnowler]

Yes - flushing the buffer then clearing the DTR line appears to correct the stop bit. But...

Because the RS-485 transmission and reception timing is critical, these functions have been implemented using threads. Unfortunately on random occasions, DTR (and hence TX enable) appears not to be cleared/released at the end of each transmission of data (around 200 characters).

This is probably a problem with our code and I�ll take a further look into this.

Thanks for your help.

Alan

[Chris_Rake]

Hi Alan,

After looking over the design it appears that this solution is the way to go. The Auto-wire control on some of the NI-Serial RS-485 hardware doesn't always work when additional parity or stop bits are added.

+Chris

[Leon_Black]

Afternoon,

I was reading through the 2002 data concerning stop bits. Skip ahead to 2016, we are currently using a PCIe-8431/8 and see very similar results. The data is 11 bit MODBUS at 9600 baud and the last stop bit of the message frame does not always meet the +/- 4% allowed by async communication standards.

Does this mean we need to be running the DTR mode on all 485/422 traffic?