serial port handshaking issue in RT

[abanica]

I am using Labview RT 8.5 on a PXI embedded target running under the PXI 8186 controller. I am communicating trough a serial port with a GPS receiver that is streaming messages at a rate of 115,200 baud. Every so often there is a burst of data which can overflow the receive buffer in the PXI serial port and the obvious solution would be to enable handshaking to control that flow. I have done so a number of times, using both XON/XOFF and RTS/CTS handshaking and on different ports to no avail. No matter what I tried, the RT target does not send out the XOFF character or deaserts the CTS line and the buffer overflows just as before.

Does anyone have any suggestions as to why the flow control does not seem to respond to the input FIFO crossing the threshold set for this? I have used a serial port on the controller (COM1) which has a 16 byte FIFO with the threshold set at 8 as well as a separate serial board com port (COM3) which has 128 byte FIFO with a threshold set at 64. Both showed the same behaviour with the exception that the small FIFO overflowed a lot more oftern. One quirky thing to point out is that the FIFO threshold is not settable in MAX, that whole Advanced Serial Port setting page is viewable but greyed out...

Adrian

[Raj_V]

Hi abanica,

How exactly are you confirming that the CTS line does not deassert or the XOFF character is not sent? Are you monitoring the line with a scope? In this scenario, with a baud rate of 115,200 you are essentially going to fill up that 16 byte buffer in under 1.4ms. You can definitely overcome the buffer overflow by turning on flow control within LabVIEW and avoiding the use of timed loops.

Are you unable to see the Advanced Serial Port Settings page on both cards or only the one within the controller?

[abanica]

Hi Raj, I am checking the lines (CTS or the TX line in the XOFF case) using a scope. I am enabling the flow control using the VISA Cofigure Serial Port vi within the application. However, the data is read from the receive buffer using a timed loop running at 100ms rate at this point. Is this causing an issue (I am infering from your question)? I have attached a screen capture of the initialization portion of the vi and the timed loop that does the reading. And finally, I can not access the Advanced Serial Port Settings for both the serial ports on the controller or the 4-port serial card.

[Raj_V]

Hi Abanica,

The timed loop may be the cause of the problem. Is it possible for you to remove the timed loop and replace it with just a normal while loop for testing purposes to see if that still throws the same buffer overflow error?

Also, What is the exact 4-port card you are using, so that I can simulate the device on my end to see if we can figure out whether the lack of advanced options is expected behavior.

[JasonSmith]

Adrian-

This depends greatly on the port and the version of the driver that you are using.

In versions of NI-Serial prior to 3.5, flow control was performed in the driver. This meant that it would effectively prevent the software buffer from overrunning, but would be unlikely to prevent overrunning of the hardware FIFOs, if for some reason your system was unable to respond to an interrupt to empty the FIFO.

With NI-Serial 3.5 and later, this behavior is changed, so that we utilize the resources available in the hardware to perform flow control, allowing us to prevent overruns in the FIFO. Please note that the NI-Serial 3.5.1 package on ni.com still includes NI-Serial 3.3.4 for LabVIEW RT, so you should upgrade to NI-Serial 3.6 for LabVIEW RT to gain this functionality.

Now comes the issue of the port. If you are using the built-in port on the controller, there is no capability in the hardware to perform flow control, so it is the same as the older driver. If you are using a PXI-843x board, all flow control is performed in hardware. For PXI-842x boards, only RTS/CTS is performed in hardware.

Also, Raj is correct that your timed loop may be the utilmate cause of the problem. Under normal circumstances it should be pretty difficult to cause an overrun at 115200 baud. By default, the FIFOs are serviced at below timed-loop priority, in order to reduce the jitter in your time-critical loops. Since you are using the serial port from inside the timed loop, this causes some interesting artifacts since the port is actually serviced at a lower priority. This can cause very poor serial performance and high CPU usage if you are using asynchronous reads and writes inside of a timed loop. You can alleviate this problem by either moving your serial I/O outside of the timed loop, to a priority which is below Time Critical. If you must leave the serial I/O in your timed loop, you should switch to Synchronous reads and writes. Please note that when usng synchronous I/O in a timed loop, you will be effectively elevating the actual serial port servicing to timed loop priority, which may induce some jitter in the runnning of other timed loops in the system.

So, to summarize, I would recommend the following:

1. Either move your serial I/O to an untimed loop, or switch to synchronous reads/writes instead of asynchronous.

If that does not resolve the problem, the following steps should improve the reliability of flow control on your system.

2. Update to NI-Serial for LabVIEW Real-Time 3.6.

3. Use a PXI board instead of the built-in serial port.

4. If using a PXI-842x board, use RTS/CTS flow control.

5. If using a PXI-843x board, use either RTS/CTS, DTR/DSR, or XON/XOFF flow control.

I hope that helps!

Jason S.

[abanica]

Thanks for the feedback. I am using thw PXI-8430 card but running NI Serial 8.4. I am upgrading to 8.6 next and will let you know the outcome. Under the old serial driver, it did not help to move the serial port read outside the timed loop, still overflowing but 8.6 might make a big difference.

[abanica]

I have upgraded to NI Serial 8.6 on the RT target but nfortunatelly it did not seem to do anything to improve the overflow rate (which happens once every 1-3 seconds or so). Initially I had changed the timed loop that was reading the serial stream and performing a whole bunch of processing to a while loop but to make it even simpler, I moved the VISA port read VI out of this loop and into a while loop by itself (together with the available bytes property node). Overflow behaviour was the same again.

The one thing I should point out since we have been talking about timed loops, is that the overall application does have other timed loops (there are I think a total of 6 timed loops performing various other functions not related to the GPS). The fastest loop is running every 685 microseconds and takes about 200 microseconds to complete but the rest are pretty low overhead and rate (500 to 1000 ms). The total processor utilization runs at about 45%, so not excessive. The reason I bring this up is that when I run the GPS related VI's by themselves (with or without the timed loop) I get no overflow issues. It is only when the whole application is running that it exhibits these problems. I had spent a lot of time in the past trying to figure out which specific loop might be a culprit and all I can say from that experience is that it looked like the bigger issue was the memory manager (this would make sense as the memory manager would likely be used to transfer from the FIFO to memory and if it is busy then it won't do it). But irrespective of this, the handshaking should stop the flow and that is what seems to be the problem (the handshake just does not seem to get enabled).

So then to specifically answer Jason's questions:

1. Either move your serial I/O to an untimed loop, or switch to synchronous reads/writes instead of asynchronous.

Done both and it did not solve the issue, even with 3.6 below

2. Update to NI-Serial for LabVIEW Real-Time 3.6.

Done

3. Use a PXI board instead of the built-in serial port.

I am using the PXI-8430.

5. If using a PXI-843x board, use either RTS/CTS, DTR/DSR, or XON/XOFF flow control.

I have tried both RTS and XON and monitored the lines with a scope which showed no activation of these two protocols by the 8430.

Not sure where to go next... MAX still does not allow me to change the Advanced Serial Port Settings for either the 8430 ports of the built in ones. Might that be a clue to the problem?

Thank you again for helping with this problem.

Adrian

[JasonSmith]

On Windows Vista or Windows 7, you will have to right-click on the Measurement & Automation Explorer and choose to run as administrator in order to access the advanced settings.

Are you actually receiving error messages from VISA? With NI-Serial 3.6 and flow control I would not expect you to continue to receive overflow errors, unless your instrument has very poorly behaved flow control. The flow control settings used on a PXI-8430 board will allow the port to receive 16 bytes after flow control is engaged, which should be sufficient to work with most devices.

Have you tried to confirm that the RTS line is being asserted when using flow control, after you have updated the driver? You may also want to confirm that flow control has been properly enabled on your instrument.

Once you have access to the advanced settings, you can try changing the RX Trigger to something lower, to see if that changes things.

-Jason S.