VISA serial speed problem

[AndyN]

I am not an expert by any means and I might be wrong here and there so correct me if I that is the case. I always love to educate myself a bit more.

Lets throw some facts here.

RS232 full duplex communication. There is a device/gizmo called UART or whatever it is called in the computer or other thing. It has two own buffers for read and write and sort of own little cpu/dsp.  It is capable of transmitting the data and receiving it at the same time. When it receives something, it stores it in its own buffer and raise a flag/interrrupt /whatever for the OS to know. Its output buffer is being filled up by the BIG CPU and asked to send it out. In order to send it out, The big CPU is not necessary. It is not necessary for receiving neither. You can probably watch Youtube or  update your facebook profile while that happens. The buffers are small though so they fill up quickly and if someone does not take care of it it is all gonna crash.

Here comes the big CPU role. It does the Read/Write things. To be precise it takes the data from the local variable/RAM whatever and stores or take it it from the little buffer of the gizmo. Once the operation starts (lets say Read) it gets sort of exclusive access to the resource/gizmo. Now there are a few scenarios: There are no data/no timeout, It blocks the execution of the thread forever and the port as well; no data/timeout, it block execution, waits and releases after timeout with an error; half data/no timeout, same as first case; half data/timeout, same as second case; full data/timeout or not- transfer from gizmo buffer to local memory and done. The last case is the perfect case.

Now how do you make the last case happen? Well, there are polling techniques but this migh consume the whole CPU time. We do not want that. So we can use a function that will stop the execution without accesing the hardware or  only checks it with a timer. Select does that in Linux.

It is my understanding that this function is VISA Wait on Event in LV. It is explained here :http://digital.ni.com/public.nsf/allkb/179E61F87CF8B340862571EA0037CFA3

It does not block the resources. Just to be sure I checked it myself.

So we know we have something waiting but we need to know how much, otherwise the Read might block the port anyway. It can be done by the Property Node->Bytes at Port. So here is the happy ending, we call Read and the olny CPU time required is to copy data from the gizmo buffer to our destination and or getting the OS attention.

Dang, no blocking the cycle goes on and on.

My understanding is kind of fuzzy when it comes to a situation of multi core systems. Theoretically the Read and Write actions could be done by different cores at the same time but that probably does not happen. On my RT target I have a single CPU anyway.

When it comes to the VISA driver it can probably (I guesss) send my data on demand or as it wishes. Lests say ma data look like "D", 10ms delay, "D" 10ms delay... The driver can send it exactly that way or: delay,DDDDD, long delay, D short delay... etc.  The average would be the same but if it sends too many at the same time  it will overflow and/or truncate the message on the receiver side. This is my biggest concern.

When it comes to the servo side and its capabilities I am working with the manufacturer to figure it out. I already mentioned that in the first post and I realize that the servo CPU might no be able to process the data, however I think the 19.2k baud is the gizmo/UART feature not the cable property, so it gets there with that speed (actually way lower) but the CPU might not read its port in time.

I apologize for my gramma and thank you for the input. I will try to reply to the idea of state machine in a fast real time system scenarios later.

[Mark_Yedinak]

I haven't worked with the VISA events much so I will trust when you say they are nonblocking. I do know for a fact that the read and write are blocking. In your application you may not run into a blocking issue you you are not using any flow control and the amount of data that you read/write is pretty small. However, if you enabled hardware flow control it is quite possible that even though you are only sending a couple of bytes the receiver could indicate it is not ready to receive data and that would block your write. You have a 3 second timeout set. No the receiving device may have raised the flow control because it's read buffer have not been emptied. However, your read is blocked because the write is blocked. You now have a deadlock situation.

I have encountered problems with VISA reads/writes blocking when using TCP communications. This is MUCH faster than serial and truly full duplex. In my experience it is best to keep the reads and writes in a single state machine. At a minimum have the actions much more controlled.

And yes, I know the differences between cable/wire ratings, BAUD rates and system performance. My point was that even if the device stated it could support 115200 BAUD it is only an indication of its serial communications. The UART is has does not give you any indication of how fast the device itself can process commands.

[AndyN]

You are absolutely right when it comes to Read/Write blocking scenarios. However usually it refers to stopping the thread execution, getting exclusive acces to the resource and.... waiting, waiting then doing something. If you make sure the data are ready and know how big, it is "almost" atomic function. If you sequence it and add a delay (which I hate) it will probably take longer overall but I will try to preach more about it later:)

I agree with the  flow control scenario. The thing is, I do not have flow control.

I would love not to have to use serial ports and do it with the TCP/IP. However this is where I got suspicious about VISA drivers.  I had 2 RT systems and one Windows exchanging data at 100Hz. The basic TCPIP functions are working flawlessly on the RT clock. The VISA driver was breaking the connection constantly giving weird errors and so on.  That's why I do not trust it anymore.

BTW. I tried to play with the buffer size-no change.

[Mark_Yedinak]

The VISA drivers are stable. I, along with many others have been using them for a long time with good results.

[AndyN]

I am merely stating that in the specific situation I used them - TCPIP on RT over 20Hz it was crashing.

I do not have Ethernet on my device so I am stuck with serial communication and I would appreciate some insight with respect to VISA serial fast communication.

[Mark_Yedinak]

I'm not sure what you want then. Several suggestions have been given (remove all UI activity from your tasks, process the data in a separate task, use a single state machine, just to name a few) and so far other than cleaning up the wiring a bit you have ignored the advice given to you. You also haven't provided information qith respect to the device you are communicating with. For all you know that may be the bottle neck and nothing you do to the code will speed things up.

I have used VISA extensively over RS232 at rates up to 115200 without any issues. I have used it for both reading and writing data at this rate transmitting/receiving multiple megabytes of data at one time. The VISA functions work very well of RS232.

[AndyN]

Mark,

The question I keep repeating  was also in my first post:

"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?"

I thought I explained it in details by giving that example:

"When it comes to the VISA driver it can probably (I guesss) send my data on demand or as it wishes. Lests say ma data look like "D", 10ms delay, "D" 10ms delay... The driver can send it exactly that way or: delay,DDDDD, long delay, D short delay... etc.  The average would be the same but if it sends too many at the same time  it will overflow and/or truncate the message on the receiver side. This is my biggest concern."

As far as the the device goes I shared everything there was to: RS232 commmunication setup,  frame setup, even the device model number, what I am sending to and what I expect to get back.

I also explained that I do not exlude the possibility that my problem is because of the device.  I was intrested in the questions in bold font.

You did not attempt to answer any of those questions in bold, instead you keep suggesting things that you can use to almost EVERY topic on the forum I consider that rude and actually it is called trolling.

[Mark_Yedinak]

There is no Nagel algorithm like there is in TCP for sending data on the serial port. When you have no flow control active as is your case then the data will be sent immediately. The only buffering that will occur would be if you had flow control set.

If you send a one byte command every 10 ms and captured the serial lines on an analyzer you would see on character sent every 10 ms. The serial communications work a bit more well behaved than the TCP functions. Once LabVIEW hands the data off to the lower layer of code your application will think the data has been written when in fact it may still be buffered. I haven't seen this behavior when using the serial functions. The application actually blocks when flow control is enabled. The TCP write will almost always return immediately on an active connection even though the lower socket layer still has teh data buffered.

[AndyN]

Thank you very much.

This is the kind of answer I was expecting.