Reading and writing on 2 different threads with clsernat

[andor-barry]

Hi

I have a NI PCIe-1433 card and I'm attempting to communicate over the serial port, using clsernat.dll, on two different application threads, one for reading and one for writing. It appears that while the read thread is in the clSerialRead function, the write thread gets held up in the clSerialWrite function until the read is complete. I expected these two functions to be independent of each other.

The read and write are on separate threads because the camera I am communicating with can send asynchronous messages down the serial port. I use the read thread to monitor these messages and set a relatively long timeout (300ms) to minimize polling on the PC and maximize response time to the events. Meanwhile the write thread is used to send control messages to the camera. The effect is that the control thread is locked out for 300ms at each command which slows down the control sequence.

Is there any way to allow the two functions to operate independently?

Thanks

Barry

[BlueCheese]

Hi Barry,

I haven't dug into it, but I suspect this is an internal architecture limitation. Generally the model for CameraLink communication is command->response based and I doubt there was much consideration for this asynchronous use case.

My suggestion would be use clSerialRead() with a 1ms timeout. This would be slow enough interval to not use very much CPU at all (probably ~0%) but you would still break through immediately when data is available. On the transmit side you would add some delay (up to 1ms) but assuming you are waiting for a response back the latency is likely going to be significantly longer than that anyway due to UART transmission speed and interrupt/DPC latency.

If you instead wanted to favor minimizing latency on the transmit side you could have a 1ms polling loop of clGetNumBytesAvail() instead.

Eric

[andor-barry]

Hi Eric

Thanks for the reply.

Ultimately we are looking for low latency on the receive side and high throughput on the transmit side. Our baud rate is 115k and we burst out in packets of 10 bytes so even a 1ms delay does have a fairly significant impact. It looks like we will have to make a compromise somewhere. This is working well on a another manufacturers card which was what caused the surprise when it didnt work with NI.

Do you think this could receive attention for a future IMAQ software release, assuming it is not a hardware limitation?

Barry

[BlueCheese]

Hi Barry,

I have created internal CAR 420990 to track this issue. While it would certainly be possible to add this functionality, currently the mechanism exclusively locks the serial port to a single thread at a time (based on the assumption of command/response usage).

An alternative you could possibly consider is the 1473R. This makes use of direct FPGA control of the camera and you can access the serial port with hardware latency. I'm nearly 100% positive that the interface to clallserial does allow concurrent reading and writing. Keep in mind that this board does not use the same IMAQ driver or API though.

Eric