VISA serial speed problem

[AndyN]

I am having trouble communicating faster than 12Hz with my servodrive. Below the details.

Host side: NI PXI RT 9.01 2.0GHz Or Windows LV 2009 4x2.4GHz - RS232 on both tested all the ports.

Servo: Kollmorgen CD series CB 06560- That does not matter much but I tried to give details

Serial config: 19.2Kbaud 1 start bit, 8 data bits, 1 stop bit, no parity, no SW/HW handshake.

NO USB to COM- it is pure RS232

Assumptions/calculations: 19200bauds/10= 1920 bytes/s

That would mean I can send 20bytes back and forth up to 96Hz.

Well I am sending 4 bytes out and receiving up to 14 bytes back dependind on servo setting of the echo/prompt. It cannot do more that 10-12 Hz properly.

After increasing the send rate it starts lagging and eventually I get a message from the servo that it does not understand the command which tells me that the servo buffer is getting overflown and the messages are being truncated. I send the same command over and over - 3 characters plus CR. At highier speeds after I stop sending the commands it keeps sending me replies. I get the reply with CR and LF.

I tried Windows machine, both ports on the LV RT machine, made sure that cables are proper, decreased the data I am getting back, flushing the COM port; it did not matter.

Here is the real question: How does LV sends data OUT? Is it on demand/ ie every time I ask for it or is it a buch of commands sent at once?

It is either the servo not being capable to process the data, LB overflowing it with data where is should do on demand or me missinf something in programming.

Lets leave the servo alone and consider LB or me code, whcih is below.

[AKA_TG]

Just a shot in the dark here

Try increasing buffer size to 64K  or 128k bits

The other one I think is the receiver buffer flush.

Count how many times it flushes and see if the time is lagging there.

Also I thought visa enable and discard event should be be in the bottom loop but maybe its the LV version.

Anyway Im sure others will chime in with some thoughts.

[AndyN]

I will try to increase the buffer. The thing is LV does not show any errors- it is the other side. It is complaining (servodrive) about the commands being "undefined" when the frequency gets higher.

You meant the VISA Eanble/ Disable Events?

My understanding is you turn it on just once and shut it down once so I kept the enable at the front  and the disable after the loop assuming that the reference is the same on both loops. I might be somewhat wrong here though. The VISA events seem to work alright.

Thanks for the input.

[Mark_Yedinak]

First, as a general comment you should cleanup your code. Take at look at the LabVIEW style guide. You have wires running backwards, under other objects, overuse of local variables as well as several other things that make your code difficult to read.

With respect to your performance you have several things that might be contributing. Even though you have parallel loops the VISA read and write functions are blocking. When you are waiting on the read your write will be blocked and vise versa. So, even though it appears you are running in parallel you probably aren't. A state machine can effectively switch you between the read and the write. This really looks like a command response protocol so there is no need to place them in parallel loops. Is the device streaming data? Even with the wait for VISA event you can potentially have one loop block the other because of the VISA read and write.

I would remove any updates to the front panel as well as the data processing of the recevied data from your loop (process) that is actually reading the data. Post the data to a queue and let another task process the data. This will allow you to read faster. Your Wait for Next Multiple call is rather useless in the receive loop. You have a Wait for VISA Event which will control the flow of the data. Is there a reason you flush the Read buffer if there are exactly 786 bytes available? This seems like an odd thing to do.

Your String initialization in the beginning is not necessary. You do not have to initialize the size of a string. LabVIEW will manage that for you automatically. All you need to do is initialize the array of 4 empty strings.

Without digging into this further I am not sure if you have more issues going on. I would start with these suggestions and see how they work.

One last thought, are you sure the instrument you are talking to is capable of responding to commands as quickly as you would like?

[JÞB]

I think Mark hit it right on the head! or close-

"Even with the wait for VISA event you can potentially have one loop block the other because of the VISA read and write"

Should read "The VISA wait for event.vi Will block the resource until the event is seen or the timeout is reached!"

the state machine implementation he suggests seems highly likely to work.

[AndyN]

---

@Mark Yedinak wrote:

First, as a general comment you should cleanup your code. Take at look at the LabVIEW style guide. You have wires running backwards, under other objects, overuse of local variables as well as several other things that make your code difficult to read.

I can assure you that I looked at the guide and I will clean up the code a bit a post a cleaner version. However this is in the debug stage so the things that are present in the code but not necessary in the final version are there because it does not work properly in the first place.

With respect to your performance you have several things that might be contributing. Even though you have parallel loops the VISA read and write functions are blocking. When you are waiting on the read your write will be blocked and vise versa. So, even though it appears you are running in parallel you probably aren't. A state machine can effectively switch you between the read and the write. This really looks like a command response protocol so there is no need to place them in parallel loops. Is the device streaming data? Even with the wait for VISA event you can potentially have one loop block the other because of the VISA read and write.

Well, since I use VISA events and check for the size of data in the buffer, the amount of time it blocks is to read the COM buffer? The Write will block for the amount of time needed for sending. The  receiver side can send me error messages asynchronously (if the error happens) and I want to catch them. Question: How does the blocking delay of read/write relates to 2.0 GHz single core CPU or 4x 2.4GHz multicore systems with respect to 12 Hz of sending 20 bytes?

I would remove any updates to the front panel as well as the data processing of the recevied data from your loop (process) that is actually reading the data. Post the data to a queue and let another task process the data. This will allow you to read faster. Your Wait for Next Multiple call is rather useless in the receive loop. You have a Wait for VISA Event which will control the flow of the data. Is there a reason you flush the Read buffer if there are exactly 786 bytes available? This seems like an odd thing to do.

I does not seem that I have problems with reading data.  Wait for Next Multiple is useless but does not change a bit  neither, the 786 comes from debugging and is useless as well. It all comes from trying to figure out what the problem is.

Your String initialization in the beginning is not necessary. You do not have to initialize the size of a string. LabVIEW will manage that for you automatically. All you need to do is initialize the array of 4 empty strings.

Well, this is the old discussion of dynamic memory allocating vs static. Lets not go into this direction

Without digging into this further I am not sure if you have more issues going on. I would start with these suggestions and see how they work.

Thanks for the input, I really apreciate it but the style, overuse of local variables  (like 20 of them)  does not seem to be related to VISA communication, since I put it there beacuse it was not working propely in the first place.  I will consider it though. As I said, I will try to clean it up and post it again but I already know it wont do any good. What I could use is some details behind VISA COM issues. 

One last thought, are you sure the instrument you are talking to is capable of responding to commands as quickly as you would like?

The answer is simple. No, I am not 100% sure. Its says it can do 19.2k bauds or roughly 1 character per 500 micro seconds. I talk to the tech support on their side too.

thanks a lot!

---

[AndyN]

---

@Jeff Bohrer wrote:

I think Mark hit it right on the head! or close-

"Even with the wait for VISA event you can potentially have one loop block the other because of the VISA read and write"

Should read "The VISA wait for event.vi Will block the resource until the event is seen or the timeout is reached!"

the state machine implementation he suggests seems highly likely to work.

---

Could you exand on it a bit? I think I answered it already but not sure if undestood it correctly. thanks

[Mark_Yedinak]

Since you can get a an asynchronous error message have your state machine see if there are any bytes available at the port. Do this check at some reasonable rate. When you want to send a command and get specific data back then invoke your write state. This state can include the read of the data or you could have a separate state specifically for reading the response data. It would probably be the most flexible to implement each command and its response in its own state. The check for error can be be your default state when you aren't actually sending anything (and waiting for a response) to the device. This check can do a simple check to see if data is there, if not wait some timeout (100 to 250 ms which should be fast enough to see the asynchronous errors) or send the command whenever requested or required. You could always check to see if an error message is there just before sending the command just in case one occurred between the last time you checked and the request for the command.

As for the comment about this simply being debug code and a work in progress all I can say is that it helps quite a bit to keep your code clean at all times. Once you establish good habits it isn't that difficult to keep doing it. Once it becomes second nature it doesn't really take any longer and the benefit is that your code will always look clean and be easy to read. As for locals I very rarely use them. Instead of using locals variable for debugging try using probes.

I haven't played with the VISA events much but based on Jeff's comments I would say that any VISA call will be blocking. So, if you have VISA calls for the same resource in parallel loops they will block each other. One will be waiting for whatever it is supposed to do (wait for event) and the other will not be allowed to execute until the other completes.

Also, just because the device states it supports 19.2k BAUD does not mean that it can process and respond to commands that quickly. Depending on the instrument you may not be able to collect data as quickly as you want regardless of the BAUD rate. That does not have any bearing on the processing speed of the device itself. It onlys relates to how fats bits can fly over the serial cable. The two are unrelated.

[AndyN]

A clenaer file is here.

[Mark_Yedinak]

The code is cleaner but I think you will still run into issues with blocking VISA calls. In addition, you still are processing the data and updating the UI in the same task you are reading the data. For slow data this will work fine. If you are looking at reading data very quickly this can potentially be a problem and impact your performance. I think you may be better off using a single state machine as I suggested earlier.