Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Tektronix RS232 communication error

I have received a strange behaviour while communicationg with Tektronix TDS 1002 oscilloscope via RS232 interface (through ni-Visa) by original pnp drivers for LabVIEW. System Win2000, LabView 7.0, Visa 3.0.

Sometimes the Getting Started.vi working correctly and colect all 2500 points from the oscilloscope.
But after several acquisitions LabView reads not full waveform but only some part from it and further running of this vi provides errors in TDS Initialize.vi

LabVIEW: (Hex 0xBFFC0011) Identification query failed.
VISA: (Hex 0xBFFF006B) A framing error occurred during transfer.
or VISA: (Hex 0xBFFF006A) A parity error occurred during transfer.


These errors occurs not simultaneously but in different sequen
ce in subsequent running of acquisition.

RS232 port and Tektronix seems to be correcty configured to work through rs232 as described in readme that comes with driver.

Also it may be important that one strange rule appears:
acquisition of low level signal from oscilloscope does not provide this error. But only if the ADC code is large than 10 the error appears practically always.

Thank in advance!
Ivan
0 Kudos
Message 1 of 11
(6,648 Views)
sound like a disturbed rs232 communication to me.
to solve this:
-check you rs232 connection for ground loops
-try another shielding strategie
-Try a lower baud rate
-try optical isolation of your connection
Greetings from Germany
Henrik

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'


0 Kudos
Message 2 of 11
(6,648 Views)
I agree with Henrik; all these error together point to some tricky communications issues that are causing a bit or two to be lost for some reason or another. Shielding, RF, and cable type can all be causes for this. Generally, RS 232 serial is pretty resilient but can run into problems over long without shielding or in noisy environments.

Let us know if you solve this or have more information after checking some of these things.

Scott B.
Applications Engineering
National Instruments
0 Kudos
Message 3 of 11
(6,648 Views)
Thank you for you help!

I am using standard computer com-com cable about 1m to connect Tektronix to standard COM port. The cable has a pair of 9 and 25 pin connectors on each side (maybe this is a problem).

Another interesting is thing that Wavestar software that comes with Tektronics seem to be operaing good.

It is not possible for me now to check shielding strategie and optical isolation. I have no such knowledge and experience :)))

I will try to check baud rate settings and possible to check or replace cable.
0 Kudos
Message 4 of 11
(6,648 Views)
I am experiencing the same sort of trouble with my RS-232 I would be interested to know if those recommendations solved your problem.
0 Kudos
Message 5 of 11
(6,648 Views)
We have just solved this problem. The main trouble was with the incorrect drivers for TDS1002 based on VISA.
The issue is follows:

When the serial device is communicated in pure ASCII mode there are no errors. But our tektronix oscilloscope have the binary data transfer for faster communication. But in this case the problems arise because serial communication have an possibility to stop the transfer when the so called terminal character is ancountered in the read stream. Term char can be LF/CR/LF+CR or none. It is clear that with LF, CR or LF+CR it is possible to encounter this term char in the binary read stream represented by ASCII characters (depends on data which are readed from device) and erronerous stop of tramsfer can occur which in turn leads to t
he termination of read and some garbage in the buffer.
So, consecutive read of any things from buffer fails.

The correct way to handle this issue is to set the term char to NONE before binary transfer and restore it back after transfer. The only one problem that can arise in this case - one should know precisely the data length and request only this number of bytes.
0 Kudos
Message 6 of 11
(6,648 Views)
After we have fixed this problem implementing a simple program in VC++ working with VISA we make a quite simple change of the TDS drivers and now all is working perfectly.

By the way we have encountered another one bug in this driver pack which is about rescale and shifting of digitized data to real voltage value.
0 Kudos
Message 7 of 11
(6,648 Views)
I am experiencing the exact same problem under
exact same circumstances. I have tried several solutions based on the suggested. Using the Visa
resource instrument-type property node, I have
tried setting the "Term Char En" (termination character
enable) to false prior to binary transfer. Nothing
changed. In looking in the Tektronix programming
manual and in fiddling with the scope itself, I do
not see the option to have no termination character.
It's a CR or LF or CR-LF or LF-CR only as far as I
can tell. SO, I am wondering how you did this.
I am also wondering if NI wil fix this & offer new
set of TDS vis.
0 Kudos
Message 8 of 11
(6,648 Views)
Anyone know how the tds drivers were modified to work properly...I'm having the same exact issues as described by others.
 
Thanks
0 Kudos
Message 9 of 11
(5,946 Views)

It sounds like disabling the termination character (with a VISA property node) around the reading of waveform data (and then enabling afterward) solved one of the issues.  This is handled properly in the newer Tektronix 200 1000 2000 Series project-style driver:

http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=047216EC20B66FABE0440003BA7CCD...

There are other posts in these forums discussing serial communication issues with these scopes:

http://forums.ni.com/ni/board/message?board.id=140&message.id=21771&query.id=121156#M21771

Hopefully this helps...

Message 10 of 11
(5,929 Views)