Serial Communication using DPO7000, TekVisa and Labview 8

[roottwo]

I recently got a DPO7054 computer/oscilloscope. This replaced my old PC that I used with Labview 8 to communicate via RS232/serial line. I now want to be able to use the same VIs I made to work on the 7054.

I can get the 7054 to write the serial data I want just fine. However, I cant get the 7054 to accurately interpret the data being sent back on the recieve end of the serial bus. I probed the send and recieve line and I verified that the data being transferred is what I intend. However, either labview or the hardware is corrupting the data.

Message Returned to 7054 on serial line (Correct):

40F1 A1C0 0000 0008 D0AD 

Some sample messages returned on-screen through Labview:

00F1 A1C0 0000 0000 D0AD

40F1 A1C0 0000 0008 00AD

00F1 A1C0 0000 0000 002D

00F1 21C0 0000 0008 00AD

I also verified that the data being sent back over the serial line does not change - ever. Something I do with Labview or TekVisa is messing this up.

Here are some settings:

- 19200 baud rate

- No Parity

- No Flow control

- 1 stop bit

- 8 data bits

- No termination characters

The VIs I use to communicate are almost the same as the examples included with Labview. Does TekVisa handle serial operations differently? TekVisa struggles to recognize a serial port is present, but I dont know if this is a problem.

I also recorded this using Call Monitor. I frequently got framing errors using my old PC, but never had problems displaying the data. Any help would be greatly appreciated.

7/27/2007 1:41 PM 22.0809   0.0030s    viParseRsrc(0x26be1e0, "ASRL1::INSTR", 0x6a8fe48(111738444), 0x634b438(118631656))  
7/27/2007 1:41 PM 23.0420   0.6046s    viOpen(0x26be1e0, "ASRL1::INSTR", 4, 0, 0x2694470)  
7/27/2007 1:41 PM 23.0420   0.0000s    viGetAttribute(0x2694470, VI_ATTR_RSRC_NAME, 0x6a8fba4("ASRL1::INSTR"))  
7/27/2007 1:41 PM 23.0430   0.0000s    viGetAttribute(0x2694470, VI_ATTR_INTF_TYPE, 0x6a8fde0(4))  
7/27/2007 1:41 PM 23.0430   0.0001s    viSetAttribute(0x2694470, VI_ATTR_TMO_VALUE, 1000)  
7/27/2007 1:41 PM 23.0430   0.0001s    viSetAttribute(0x2694470, VI_ATTR_ASRL_BAUD, 19200)  
7/27/2007 1:41 PM 23.0430   0.0001s    viSetAttribute(0x2694470, VI_ATTR_ASRL_DATA_BITS, 😎  
7/27/2007 1:41 PM 23.0440   0.0001s    viSetAttribute(0x2694470, VI_ATTR_ASRL_STOP_BITS, 10)  
7/27/2007 1:41 PM 23.0440   0.0001s    viSetAttribute(0x2694470, VI_ATTR_ASRL_PARITY, 0)  
7/27/2007 1:41 PM 23.0440   0.0000s    viSetAttribute(0x2694470, VI_ATTR_TERMCHAR_EN, 0)  
7/27/2007 1:41 PM 23.0450   0.0000s    viSetAttribute(0x2694470, VI_ATTR_TERMCHAR, 10)  
7/27/2007 1:41 PM 23.0450   0.0001s    viSetAttribute(0x2694470, VI_ATTR_ASRL_FLOW_CNTRL, 0)  
7/27/2007 1:41 PM 23.0450   0.0000s    viSetAttribute(0x2694470, VI_ATTR_ASRL_END_IN, 0)  
7/27/2007 1:41 PM 23.0450   0.0002s    viSetBuf(0x2694470, 0x30, 4096)  
7/27/2007 1:41 PM 23.0460   0.0001s    viSetAttribute(0x2694470, VI_ATTR_ASRL_RTS_STATE, 1)  
7/27/2007 1:41 PM 23.0460   0.0001s    viSetAttribute(0x2694470, VI_ATTR_ASRL_RTS_STATE, 1)  
7/27/2007 1:41 PM 23.0460   0.0002s    viWrite(0x2694470, "@..@Y$", 6, 0x6a8fed0(6))  
7/27/2007 1:41 PM 23.0470   0.0001s    viSetAttribute(0x2694470, VI_ATTR_ASRL_RTS_STATE, 0)  
7/27/2007 1:41 PM 23.0470   0.0001s    viRead(0x2694470, ".", 14, 0x7182500(1)) - (0xbfff006b) "Error - A framing error occurred during transfer"
  
7/27/2007 1:41 PM 23.0560   0.0062s    viClose(0x2694470)  

[Chad B]

You might try using Portmon, a free Windows utility that monitors traffic on the serial port.  You can run this, and then investigate the log to see if you can identify the problem there.

Also, you might try a different serial device to see if you can communicate with that.

[roottwo]

I am able to use the 7054 to program microcontroller devices over the serial bus with another program. I can take the image on the microcontroller and read it back. There are no discrepancies between the image I read over the serial bus and the original version. It seems that just labview is giving me grief with reading functions.

I used the portmon application at your suggestion. There is a difference in the method of reading between Tekvisa and NI Visa. It appears that Tekvisa reads each byte one at a time, whereas NI Visa reads all 10 bytes at once. Ive included the logs of the same VI being used on a regular PC and the DPO7054.

I monitored the read function with the other application I mentioned. The call to read the serial buffer looks the same, so I see no reason that Labview cannot work properly.

I am really at a loss here....

[Meghan R]

Hello,

If you use the example "Basic Serial Write and Read" from the example finder (found in the folder Hardware Input and Output>>Serial), does that change what you see?  If you do a simple loopback test, do you see the correct information read back?  Loopback Test for Serial Port  Can you post a portion of your code that you're having this issue with? 

Thanks,

Meghan
Applications Engineer

[roottwo]

I wont be able to do a loopback test for a few days as I had to send the machine for repair already... However, I posted some code that I have used. The code I used is very similar to the samples that you mentioned. I simplified them by making the controls constants to fit my application as well as a method of controlling the RTS line after sending my message.

The VISA resource names might be mixed up for between the two VI instances, but under normal use I have the proper resource being called.

[Chad B]

The code seems to look OK right now... let me know what you find out when you try the serial loopback test.  Thanks!

[roottwo]

I finally have been able to try the loopback test. It works as expected. I shorted back the xmt/rcv pins with my code and I got the same response back.

When I communicate with the device, I still get the same jumbled response. The message sent from the device is correct, but the hardware/labview misinterprets it. The only explanation I can offer is that the information from the device I am communicating does not actually use 19.2kbps. When measured, it appears more like 18.8kbps. Does this cause an issue with missing bits and misreading data?

[Albert.Geven]

The short answer is YES

the baudrate should be equal.

but maybe it is not the baudrate but just one bit less (7 bits instead of 😎

[Chad B]

I'm a bit confused by your response--did the loopback test work correctly or not?  It sounds like you're still seeing jumbled data.  You can also to a loopback test in HyperTerminal.  I'd suggest you try that.  Once you set up a connection with no hardware flow control, you should be able to type letters and have them appear on the screen.  If that doesn't work, there might be a hardware problem.