Tektronix Technical Forums are maintained by community involvement. Feel free to post questions or respond to questions by other members. Should you require a time-sensitive answer, please contact your local Tektronix support center here.
I have some issues with the buffering function on a 2700 device. While my application is sometimes running for hours without issues it also happens sometimes that the device is caused to freeze after even some minutes. I attached a log of the serial communication between the PC and the instrument. The log shows the complete initialization as well as 4 buffering sequences with a sample count of 100 per cycle and then terminated properly.
As stated, my code works in most cases. But sometimes it happens that the instrument complains when querying the buffering status (->"*SRE?") and/or when querying the register status (->"STAT:MEAS:COND?") during the time the instrument is acquiring data into its internal memory. In case of errors, the instrument beeps but neither I'm able to retrieve the error code nor I'm able to resume the device from this trap without restarting the instrument as the device no longer responds on any command. Additional information: my application has been written with LabWindowsCVI (Ansi C) and uses the low level SCPI commands sent via RS232 using NI VISA library routines. Communication parameters:19200Bd,8,N,1,XonXoff,CRLF
Any idea what I can do?
- (20.38 KiB) Downloaded 986 times
thanx for your reply. I already tried reducing the baudrate. Originally I also worked without SW handshaking, hence no XonXoff. Introducing XonXoff was my first approach trying to improve the situation, but it did not help. The only thing that slightly helped was logging the data traffic as this slightly reduced the application performance. This brings me to the assumption that I possibly overrun the device, something that normally should not be possible due to the SW handshaking.
I don't know if this became obvious from my log, I normally initialize the device for buffering (and some other stuff, depending on the configuration caused by the user interface, multichannel scanning, functions, ranges....) and then query the buffer/register status every 2s using a timer to see where we are. I also tried to reduce the polling frequency but that did not help that much either (anyway it makes no sense to poll that often if my sample count is >1000 or so, especially in case of multichannel configs, I therefore scale it according to the sample count...). But I recognized that often already the 1st query caused the trouble.
Thanx for further hints
- Keithley Applications
- Posts: 1263
- Joined: October 15th, 2010, 10:35 am
- Country: United States
I'd get an NIO Trace on the VISA session traffic. That might yield a pattern.
A google search on "RS-232 Freeze" will return many hits related to the use of VISA and locked up communication requiring a reboot especially when using one of those USB to RS-232 dongles.
Maybe try interrogating the MAV bit in status subsytem or using *OPC? and then conditionally attempting VISA reads might help (per one of those search results).
How do you get your computer's serial port? Is it one of those USB to RS-232 dongles? Try one with different chip set.
I also tend to the assumption that it is probably more interface related than instrument related. There are computers/interfaces that are more sensitive to causing the issue than others. While we have PCs where my application runs for hours without complaints, we have others where it mostly pops up very soon. But sooner or later it pops up on all PCs, no matter using USB/RS232 dongles of different chipsets (Oxford, Prolific, Silabs, FTDI..) or a native serial port from a PCI card or a laptop docking station.
In the meantime I found out that indeed closing/reopening the COM port on the PC helps getting out of the freeze as the Keithley instrument then reacts on a *RST;*IDN? sequence without its power being toggled before. I will therefore try to design a "bootstrap strategy" to reestablish the data acquisition task to have at least a workaround. We have 1000h tests where we cannot afford having to restart - monitoring that often.
The only interesting thing (where I'm still curious) is the fact that my issue ALWAYS occurs when querying the buffer/register status but nowhere else although interface traffic is much higher elsewhere (e.g. for transferring the buffer contents to the PC)??
When not using the buffering mode, I can run 1000h tests using same application, same testing environment without any complaints even on very complex channel/function lists...
Who is online
Users browsing this forum: No registered users and 2 guests