Serial write takes unexpectedly long when more than 7 bytes are written

Question

Hi,
My vi is attached. 
As you see, it's very simple.
- output buffer fifo is set to 128 bytes, which is generously higher than my needs.
- my baudrate is 2.5 mpbs.
- I write string of 9 bytes such as 012345678, and the execution time of the vi is around 40 us. 
  I thought it's because of the blocking structure of the synchronous write, and I decided to switch to asynchronous
  write, since I need to go above 20 kHz.
- when I switch to asynchronous write, it even gets worse, and I get ~58 us. it seems like asynchronous doesn't work at all.
so far, I explained my problem. I also did some simple experiments to debug the problem.
- when my string is shorter than 8 bytes, everything is beautiful, asynchronous write takes nearly 15 us.
  when I enter an 8 bytes or longer string, it jumps up to 58 us again.
what am I doing wrong? I'm stuck here.
Gorkem Secer.
Attachments:
serialWrite_niForum_pic.png ‏19 KB

Answer 1

The driver might for a lot of reasons not want to or even can't fill up the 8 byte hardware FIFO buffer entirely. This could be for instance since it has to work around some bugs in certain hardware. It might not be necessary for the specific hardware revision in your system but that driver has to work for many different hardware systems.
The magnitude of timing control you try to achieve is simply beyond a software system if you require reliable and hard timings. It may be possible to achieve on a simpler but still powerful embedded system with custom made software drivers and RT OS but not on a more general purpose RT OS even if the hardware is pretty powerful. But such more custom made solutions would be more than a few magnitudes more expensive to develop.
You can keep barking up this tree but it is unlikely that NI can do much about it without redesigning parts of the RT system, which is pretty much out of question as they simply license it from Ardence/IntervalZero and only adapt it where it is strictly necessary to work with their hardware. Most likely their license doesn't even allow them to customize it at will in any other way than is strictly necessary to get it to work on their own hardware.
Your options are as far as I can see, to either rethink the timing requirements or adapt the software in such a way that the bigger delay won't be a problem or to go with a hardware solution based on an FPGA board or similar.
As to the difference of asynchronous write and synchronous that is mostly about what VISA API is called underneath. The LabVIEW function remains blocking for as long as is necessary to pass the data to the OS driver. In synchonous mode the LABVIEW VI calls the synchronous VISA API once and that simply waits until VISA returns from the function. For the asynchronous case LabVIEW calls the asynchonous VISA function and then keeps looping inside its own cooperative multithreading layer until VISA indicates that the asynchonous function has been performed. This is mostly for historical reasons when LabVIEW didn't have OS supported multithreading and all the multithreading happened in the cooperative LabVIEW code scheduler. Nowadays asynchonous VISA mode has almost no benefits anymore but genearlly will cause significantly more CPU load.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions