Why is this data sometimes being sent to my COM port on a VISA write?

[BuckleyPhysics]

I am trying to talk to a simple RS232 serial device. When the character "F" is sent to it, it responds with a reading. I tested this with a terminal (Termite) and the VISA Test Panel successfully. I then wrote some VIs to do the same, and was sometimes getting lots of errors back from my device ("INVALID COMMAND" type things). I'm running LabView 2012 32bit on Windows.

To try to understand what was happening, I took the hardware completely out. I set up a virtual COM port (with VSPE), connected with my terminal so I could pretend to be the instrument, and ran my program.

Every few times I tried to send the command, a very large amount of gibberish would be sent by Labview. In amongst the binary data were a few ASCII strings, some of which looked like a stack trace of some sort. All this stuff being sent to my instrument was obviously not doing much good!

I have attached a simplified version of the program I wrote, "DoTest.vi". I have also attached "Capture.nitrace" which is the NI I/O trace I took when running that VI. Finally I have attached "term.log" which is the log file from Termite --- that is, what the instrument would have received.

Can anyone tell me why this might be happening? It seems extraordinarily strange to me.

Thanks very much.

[johnsold]

TobinJones,

I think you are making this much more complicated than is necessary. And you are not using the complications to your advantage.

You really do not need the VISA events. Since your device transmits a termination character, all you need to do is read in the loop. If you get a timeout error, then any data present (probably none) is discarded. If no timeout error, then the read terminated on a line feed or the maximum number of characters specified.

If you want to use the Filter Error Codes VI to only allow reads when no timeout has occurred, put it immediately after VISA Wait on Event and use the Error Filtered? boolean output as the selector on a case structure so the Read only occurs when no errors are present.

Lynn

[BuckleyPhysics]

Hi Lynn,

Thank you very much for your response. I rewrote my example to not use events, and it seems to work reliably.

I'd be very interested to know why I got my previous error, though... There's obviously something I don't understand about the code there.

This code was originally part of a much larger actor framework-based program. In my original program, I had an actor core for this device, which sat waiting for data on the serial port. When a message came, it parsed it and acted on it (e.g. by sending a message to update the UI). When my actor received a message like "Trigger Reading" it sent a control character to the instrument (VISA Write).

There are two reasons I found the VISA events useful:

1. As far as I understand, it's not possible to concurrently read and write to the serial port. Therefore if I had a VISA read sitting waiting for a timeout as you described, then I wouldn't be able to write the message until the read timed out. By the event, the serial port was free to be written to, even though I was simultaneously waiting to receive data. After your advice, I rewrote this using a tight loop around a "Bytes at serial port", which then triggers a read when data is available.
   
   
2. "Wait on Event" throws an error if the event has been discarded. This is a handy way to signal a break from waiting on the serial port. So, when my actor received a shutdown, I could just destroy the event, and know that my read loop would immediately break. A nice quick shutdown. I rewrote this with an alternative signalling method.

So that's why I initially used events. It made for quite a simple implementation because it got rid of a loop and a signalling method. Having everything event-based just seemed more elegant, too, though that's less important.

So my questions are:

• This KB Article seems to suggest VISA events are a reasonable solution for this sort of thing. Am I doing something that's actually discouraged?  How/Why?
• Why would Labview ever send all that crazy data over the serial port? Is that a bug? Should it be reported as such somewhere?

Anyway, thanks again.

Tobin

[johnsold]

Tobin,

I have not worked with LVOOP much yet, so am not familiar with the actor framework.

1. If the hardware is capable of full duplex operation, you should be able to read and write in parallel.  If the remote device cannot respond to a new command while it is still processing the previous one, then it may not make sense to read and write at the same time.  Your DoTest.vi could read and write simultaneously, although there is no way to force it to do so unless you can hit the trigger button while the remote device is sending.

You do not need and should not use Bytes at Port when using termination characters. It does not add anythig useful and makes parsing the results much more complicated.  See below for comments about Waits.

2. Your code certainly works for shutdown.  I personnally do not like that method because I think it has limitations when it comes to orderly shutdown and being sure that all data sent has been received.

The KB article refers to avoidance of polling as the justification for VISA Events.  If you were using a system with no termination characters, then the events would probably be useful. The Read will wait until termination character is received, timeout occurs, or session becomes invalid.  The Wait one Event waits until termination character is received, timeout occurs, or session becomes invalid. Redundant? 

The NI Trace only shows "F\n" being sent.  I have no idea what your other program is seeing.  I have never heard anyone report a LV/VISA serial program sending anything other than what is programmed.

Lynn

[BuckleyPhysics]

Thanks so much for your input again - I'm very grateful for the time.

1. If the hardware is capable of full duplex operation, you should be able to read and write in parallel.  If the remote device cannot respond to a new command while it is still processing the previous one, then it may not make sense to read and write at the same time.  Your DoTest.vi could read and write simultaneously, although there is no way to force it to do so unless you can hit the trigger button while the remote device is sending.

Okay, so there's the "Asynchronous" I/O mode on VISA read and write, controlling whether the calling thread is locked or not while data is written or read to the serial port.  However, that's slightly different to what I'm talking about. That is, whether a VISA write can occur at the same time as a VISA read is waiting to receive data or timeout. It appears to me that it cannot. I've attached a VI that demonstrates this. It should be run on a COM port with nothing attached, so the reads just time out. When I run it, the parallel write loop only executes once every 4 seconds, not once every 400ms. like this:

Is that what you get?

The KB article refers to avoidance of polling as the justification for VISA Events.  If you were using a system with no termination characters, then the events would probably be useful. The Read will wait until termination character is received, timeout occurs, or session becomes invalid.  The Wait one Event waits until termination character is received, timeout occurs, or session becomes invalid. Redundant? 

Yes, they certainly sound the same. However, the difference that I observe is the effect on the COM port while each is waiting. While the "Read" is waiting, the COM port is locked for writes. While the "Wait one Event" is waiting, the COM port is available for writes.

2. Your code certainly works for shutdown.  I personnally do not like that method because I think it has limitations when it comes to orderly shutdown and being sure that all data sent has been received.

Thanks, that's good advice. Something to be mindful of.

The NI Trace only shows "F\n" being sent.  I have no idea what your other program is seeing.  I have never heard anyone report a LV/VISA serial program sending anything other than what is programmed.

What my other program is seeing is in "Term.log" attached to my original post. It starts with "F\n", and then is mostly binary data I can't make sense of, but includes strings like "DoTest.vi", "Mutx", and "LIviEvnt". I agree it's truly strange. And it only happens intermittently, and only when I use events like in my first example (DoTest.vi).

---

Am I still not understanding something about events? To me it seems (if I could make them work) that they solve a real problem where there are parallel read and write loops?

Thanks and regards,

Tobin

[johnsold]

Tobin,

You may be right.  I see the same results you do.  

The documentation for Read and Write certainly gives no hints of this blocking behavior.  The examples for serial communication do not show parallel activity.  The way I read the help on Synchronous/Asynchronous mode is that that should only block while data is being transferred to/from the buffer, not while the driver is waiting for data to arrive.

I have been trying to think of a case where I am certain that full duplex, simultaneous communications occurred.  I think most UARTs have the capability, but at the moment I cannot think of any equipment which really used it.  XON/XOFF handshaking requires full duplex, otherwise it could not interrupt a transmission.  Enabling XON/XOFF in your VI did not change the performance.  And XON/XOFF handshaking was available long before VISA Events.

Putting the event code in your Concurrency test allows the Writes to proceed on the timing set in the write loop.

Of course, if your device only sends data after you write the F\n command to it, a Write, then Read combination should not need to be parallel.

Sorry to have misled you.

Perhaps someone from NI with knowledge of the internal workings of the VISA Read and Write can jump in here and explain this.

Lynn