Instrument Control (GPIB, Serial, VISA, IVI)
Serial VISA 'Write' -why is it slow to return even with large buffer?
Hi, I can quickly show the low-level part as a png. It's a sub-vi for transferring file segments. Some things like the thin 'in-line' VI with (s) as the icon were added to help me look at were the hold-up is. I cropped the image to make it more readable, the cut-off left and right side is just the input and output clusters.
In a nut-shell, the VISA Write takes as much time to 'return' as it would take to transfer x bytes over y baud rate. In other words, even though there is suppused to be a (software or hardware) write and read buffer on the com port, the VISA write function seems to block until the message has physically left the port (OR it writes TO the buffer at the same speed the buffer writes out of the port). This is very unexpected to me, and what prompted me to ask about what the point is of the write buffer in the first place? -The observations are on a 9014 RT target built in serial port. Not sure if the same is observed on other targets or other OS's. [edit: and the observation holds even if transmitting block-sizes of say 4096 with a buffer size of 4096 or 2*4096 or 10 * 4096 etc. I also tried smaller block sizes and larger block sizes with larger still buffers. I was able to verify that the buffer re-size function does error out if I give it an insane input buffer size request, so I'm taking that to mean that when I assign e.g. a 4MiB buffer space with no error, the write buffer actually IS 4MiB, but I have not found a property to read back what the HW buffer is, so all I have to base that on is the lack of an error during buffer size setting.) [\edit\]
The rest of the code is somewhat irrelelvant to this discussion, however, to better understand it, the idea is that the remote side of the connection will request various things, including a file. The remote side can request a file as a stream of messages each of size 'Block Size (bytes)', or it can request a particular block (for handling e.g. re-transmission if file MD5 checksum does not match). The other main reason for doing block transfers is that VISA Write hogs a substantial ammount of CPU, so if you were to attempt to write e.g. a 4MiB file out the serial port, assuming your VISA time-out is sufficiently long for that size transfer, the write would succeed, but you would see ~50% CPU from this one thread alone and (depending on baud rates) it could remain at that level for a verrry long time. So, by transferring smaller segments at a time, I can arbitrarily insert delays between segments to let the CPU sleep (at the expense of longer transfer times). The first inner case shown that opens the file only runs for new transfers, the open file ref is kept on a shift register in the calling VI. The 'get file offset' function after the read was just something I was looking at during (continued) development, and not required for the functionality that I'm describing.
