Issue with VISA Wait on Event errors?

[RnDMonkey]

Hi folks,

Sorry in advance for the wall of text, I just want to give as much information as I think is warranted.

I've been struggling with a custom serial communication scheme for a while now, and I'm ready to ask for help and advice. I believe the client device is not responding to commands every now and then (which I believe I've satisfactorily proven using a polling of bytes at port), but the VISA Wait on Event vi is throwing errors that I cannot explain. I have it configured to wait for Serial Character events analogous to the "Detect Serial Break Event" example VI, with my event type enabled and flushed on startup, then VISA Wait on Event called with a 1000 ms timeout in a read loop until the program ends. 

The gist of the communication interface is to write a few bytes to the client device and wait for a response packet using VISA Wait on Event. As soon as the event is detected, a single byte is read which contains a payload byte count. That number of bytes is then read and passed out for processing through a user event queue. All seems to work pretty well most of the time, even with the device periodically forgetting to respond, but VISA Wait on Event is, according to NI I/O Trace, throwing timeout expired events much faster than once per second, but intermittently. Looking at the details of the calls in NI I/O Trace, it appears to sometimes be called with a 0 ms timeout, resulting in a flood of timeout errors (as one might expect). These error calls also show 2 additional input parameters: outEventType=NULL and outContext=NULL. I am only calling this VI in one place, and the timeout is wired with a 1000 ms constant. Is there some weird internal behavior in this VI? How can it ever be called with a 0 ms timeout if I don't code it that way? Is this somehow related to receiving multiple bytes between wait on event instances?

I've attached an nitrace log so you can see traffic and errors. Note that when I first start the trace, I can get up to a few hundred of these wait errors before it seems to "hook into" the traffic properly. Perhaps the errors are entirely fictitious? I noted that the 0 ms timeout errors don't show up in the Desktop Execution Trace Toolkit, while the 1000 ms timeouts do. Thank you in advance for your time.

[RavensFan]

Do you NEED to use the Wait on Events?  While in theory it seems like a good idea for an event driven architecture, I've never needed to use it in a real applications.  I would just rely on trying to read the 1 byte and handle any regular timeout errors as they occur.  I set the VISA timeout to be much quicker than the default, perhaps as low as 1 or 2 seconds.

[RnDMonkey]

I believe my COM link is half duplex, and my writes and reads are both completely asynchronous with access being controlled by a semaphore. I can't therefore have the VISA read sitting there waiting after the semaphore lock, as this blocks all writes. At the same time, my communication packets may occur occasionally or in rapid succession, so I don't want to constantly poll bytes at port with no throttling mechanism (not even 1 ms is tolerable for my 900 kBaud interface) because of the CPU thrashing that results.

As to why I believe my COM link is half duplex, I was receiving write errors when VISA writes coincided with VISA read operations and my connection would get all out of sync due to comm packets getting interrupted.

So to answer your question: I think I need it to give me low-latency communication.

[RavensFan]

What is your COM link?

Are you dealing with RS-232, 422, 485?  What is the serial hardware in your PC?  What device are you communicating with?

The only half duplex stuff I have worked with is 2-wire RS-485, and I've never seen problems with a VISA read interfering with the hardware while it is doing a VISA write.  (But I'm not trying to to 900,000 baud rate either, which is still about 9 times faster than the highest speed baud rates I've seen.)

You mentioned Asynchronous.  VISA Writes and Reads have a right click options called Synchronous I/O control that is Asynchronous by default, you could try switching them to Synchronous.  Not sure that is the solution, but you might want to investigate.

[keroba]

Hi there,

Have you seen this article? This could be of your help,

Regards

[RnDMonkey]

Keroba,

I will investigate this (I hadn't seen that article), thank you.

Ravensfan,

I don't know what the heck happened to my reply to you. It was a long one! Anyway, the summary is that the COM interface is a USB-to-serial adapter implemented in software on the mbed chip on the LPC1768 mbed kit. It uses one of the UART channels of the LPC1768 to talk over RS-232 protocol I suspect, and doesn't wire up any of the hardware handshaking lines that it seems would have been trivial to include. The emulated serial port is thus very spare on functionality.

[RnDMonkey]

keroba,

I put in the VISA close as suggested in the article you linked, and if possible, it makes this even more odd. I'm attaching another NI I/O Trace log, that shows that sometimes after a normal timeout, there appears to be a rash of internal errors in the Wait on Event VI. In my case, you can see in the log it's reporting a full 649 error occurences in 1.004 seconds, BEFORE the Visa Close VI is called, despite the fact that it is wired immediately after the wait on event VI with the error wire running through it. It looks like time to make NI work for their SSP dollars.

[StarSarina]

Ryan,

I know that you mentioned previously that your code was similar to the Detect Serial Break Event, can you maybe post your code on the forum that way we are all able to see what the difference are between that and the example VI are. Also if you were just to use the example VI are you still seeing those errors.

I took a look at the NI I/O trace and saw that you were getting the error BFFF0015. This error could occur for multiple different reasons, one of the reasons could be that you are not reading the correct number of bytes or reading anything at all. You can see how many bytes at serial port by going to the Instrument I/O -> Serial Palette -> Bytes at Serial Port.

The other thing I would try is to try a serial baud rate that is supported by NI-VISA, the following link is the baud rates that are supported: http://digital.ni.com/public.nsf/allkb/D37754FFA24F7C3F86256706005B9BE7.

Also does your instrument require a termination character and if so, are you sending it a termination character? A way to do this would be to have a VISA write to send it a termination character.

The other thing that I would try is to determine when the wait event logs get logged in the trace. So I would run highlight execution on your VI and then compare that to the NI I/O trace.

Please let us know the results of these options.

[RnDMonkey]

Sarina,

I've contrived an example that is fairly representative of the essence of our code, based on the serial break example. Unless you have an mbed development board with our firmware, though, it's not going to do you much good since the comm channel will be dead. You can see the general flow, though. It's all asynchronous, with dynamic event registrations responsible for catching the received response after the request packet is sent.

[RnDMonkey]

Sarina,

Sorry I didn't address your specific questions. 

The timeout error is due to the device not responding sometimes. A known issue, but seems like something that shouldn't cause the Wait on Event to be called hundreds of times with a timeout value of 0, considering I have a constant 1000 wired to it.

My baud rate is 921600, one of the standard rates.

We do not use a terminating character because our data is binary and we didn't want to add the overhead of escape masks, especially since our data packets are variable in length both outgoing and incoming. Our protocol is to check for serial characters, then when one is present, read that character which will contain the payload count. The value of that byte tells the VISA read how many bytes to read, at which point the communication is complete and the bytes are sent off for handling.

I worry that running highlight execution will not yield any useful information as it slows down execution by a factor of 10,000 or so.