The term "split transaction" used in USBTMC spec documents is for Control Endpoint (EP0) operation splitting into INITIATE_XXX and iteration of CHECK_XXX_STATUS. This is applied to device clear, abort bulk-in, and abort bulk-out only, and not applied to BULK transfer itself.
Actually, when you send kilobytes data through the BULK-OUT endpoint, it can be physically splitted into [N x 64bytes] and a short (or zero-length) packet. This is the USB way, but this case the 1st 64-byte packet only has the USBTMC BULKOUT header that indicates entire length in TransferSize field. However, this splitted transfer is out of control at your application side. This splitted transaction is handled in the lower stack of the USB device driver in the kernel mode. So your app cant manage this.
Other way is, if your instrument supports intermitted transfer which correctly identifies the EOM flag (equivalent with EOI signale of GPIB), you may be able to send kilobytes data splitting into smaller size, by iterating multiple viWrite() calls with disabling VI_ATTR_SEND_END_EN and a final viWrite() call with enabling VI_ATTR_SEND_END_EN. In this case, each splitted call of viWrite() does have USBTMC header (with EOM=0 for all, but EOM=1 at final). But it requires that your instrument correctly understands this approach.
