Serial on Controller vs. Card

[Troy_Larson]

I remember hearing something from NI that the serial connection on the PXI controller does not work in RT, and the solution is to buy a serial card instead. Is this true?...is there any difference between using the serial on the controller vs. a card in the RT environment?

[Chris_Rake]

The built-in com port is supported with the RT serial driver. That said, benefits of using a plug-in card include larger FIFOs, the additional COM ports themselves, and RS-485 (for the applications that require it).

[Bob_Preis]

Built-in (ISA-based) serial and PCI-based serial work in RT. You just can't use COM1, COM2, etc.

In Windows, COM1 and COM2 are assigned as aliases to the devices ASRL1::INSTR and ASRL2::INSTR. LabVIEW Real-Time does not associate COM1 and COM2 with ASRL1::INSTR and ASRL2::INSTR. Therefore, you cannot reference COM1 and COM2 as the Resource Name for the VISA Configure Serial Port function. Instead use the strings "ASRL1::INSTR" and "ASRL2::INSTR" as the Resource Name for the function.

[Bob_Preis]

Clarification: You can't use the *strings* COM1, COM2, etc.

The strings COM1, COM2, etc are not understood. The hardware COM1, and COM2 will work but must be addressed by their formal VISA nomeclature (i.e. ASRL1:INSTR).

[Troy_Larson]

How large is the serial buffer on the PXI Controller in comparison to the PXI Serial Card? Does the serial port on the PXI Controller share its memory from RAM or does it have its own FIFO?

[Chris_Rake]

I believe the controller's FIFO is 16 bytes (dedicated) and the plug-in cards are 64 bytes (dedicated). The driver has additional buffers allocated in RAM.

[Troy_Larson]

According to NI online serial manuals, when data is received into the Receive buffer, an interrupt is generated and the processor retrieves the data from the serial buffer. How does this work for RT...there won't be an interrupt to generate, so I'm assuming the buffer will continue to fill until a LVRT subVI goes and reads it, or the buffer gets full, at which point it will overwrite data at the beginning of the buffer?

[Chris_Rake]

The RT serial driver doesn't poll for received data - rather it is called by a hardware interrupt and retrieves whatever data is curently residing in the FIFO. This data is then placed into a buffer in RAM where it waits to be accessed by the application.

[Troy_Larson]

How can a hardware device interrupt LabVIEW RT? Isn't that the purpose of having a RT OS?...so that the software controls execution flow, not the hardware? Or is the tranfer of data from the UART buffer to controller RAM happen in one of those threads operating in the 'background'?

[Chris_Rake]

Hardware drivers must pay close attention to how interrupts are handled so that unexceptable jitter is not introduced. It is sometimes a delicate act to balance performance (in this case not overflowing the UART FIFOs) and jitter (deviation from real-time performance).

In order to improve jitter performance some drivers may get an interrupt, silence the interrupt, then signal a high-priority thread that work needs to be done.