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

[gorkem.secer]

Thanks for your valuable comments.

Considering your posts, a possible workaround occured to me.
As you see from my first post, execution time does not linearly increase with the number of bytes. It grows exponentially rather. How about writing two blocks of data as four and five bytes sequentially. Do you think that I can achieve better execution time?

[RavensFan]

When I drop a VISA Write onto the diagram, by default it is set for Asynchronous mode.

Are you saying I should be changing those all over to Synchronous?  If so, why isn't that the default for VISA Write?

[smithd]

Don't know for sure but my guess (from the KB) is that you're trading a small amount of call overhead in exchange for freeing up one of the execution threads. So I'd say no, most of the time async is probably the better overall option. On the other hand I could swear I read somewhere that those options behave differently on RT, but I can't find that anymore.

Also I'd imagine you would see different behavior in a timed loop. Obviously if synchronous locks the thread then its probably putting that timed loop to sleep until the write completes, while async mode sounds like it would be causing you to swap back and forth between standard labview threads and the timed loop, repeatedly, until the write completes. ^^this is all conjecture, I don't know for sure.

[smithd]

---

@gorkem.secer wrote:
Thanks for your valuable comments.

Considering your posts, a possible workaround occured to me.
As you see from my first post, execution time does not linearly increase with the number of bytes. It grows exponentially rather. How about writing two blocks of data as four and five bytes sequentially. Do you think that I can achieve better execution time?

---

I may have missed this, but what is your desired rate? Based on the image you are still well within your budget. Is that not sufficient?

Edit: Oh I see, 20 kHz. Thats not a ton of headroom then. Out of curiousity what are you doing that has these requirements? Seems like an awful high rate for sending out a few bytes of data, maybe there is a better technology for what you want to accomplish?

[gorkem.secer]

---

@smithd wrote:

---

@gorkem.secer wrote:
Thanks for your valuable comments.

Considering your posts, a possible workaround occured to me.
As you see from my first post, execution time does not linearly increase with the number of bytes. It grows exponentially rather. How about writing two blocks of data as four and five bytes sequentially. Do you think that I can achieve better execution time?

---

I may have missed this, but what is your desired rate? Based on the image you are still well within your budget. Is that not sufficient?

Edit: Oh I see, 20 kHz. Thats not a ton of headroom then. Out of curiousity what are you doing that has these requirements? Seems like an awful high rate for sending out a few bytes of data, maybe there is a better technology for what you want to accomplish?

---

I'm communicating with a custom servo torque controller.

The torque controller on the board runs at 40 kHz and my controller loops on the PXI side run at 20 kHz and sends torque commands to the driver at this rate.

I might consider decreasing my sampling rate but that's the last solution I want to go for.

[jsaindon]

I know this is old but there wasn't a solution posted so I will add mine.

I recently ran into this problem while running at 1000000 baud. Any time I would send more than 7 characters/bytes it would fail to send and only send 1 byte. I think this is a limitation in Labview VISA driver when using non-standard baud rates higher than the standard ones. To resolve this I just broke down the string into 7 byte chunks and sent that way. I had to add a small delay between the chunks also. This sub-VI works for me and I am able to send whatever I want now at 1 million baud. 

[GRCK5000]

Hi Jsaindon,

Thanks a lot for sharing!