Call to script functions of Keithley 2602 using viScanf results sporadic to timeout

[FJ]

Hi,

we use NI-VISA to communicate with Keithley-SMU's 2602 in a multithreaded environment.
Up to 4 threads communicate with their dedicated instuments. All access  via GPIB are encapsulated by a critical section.
Communication performs well except sporadic failures when calling script functions (stored in Keithley SMU's).

Here is the simplified sourcecode:

   EnterCriticalSection();
   // write function call to Keithley 2602
   ViStatus viStatErr = viWrite(m_viSession, (unsigned char*)szData, nLenIn, &nLenOut);
   LeaveCriticalSection();
   // allow other threads to communicate with their instruments
   SwitchToThread();
   EnterCriticalSection();
   // read return value of function call
   viStat = viScanf(m_viSession, "%t", buf);
   LeaveCriticalSection();

viScanf returns sporadic with failure

 "query interrupted" or "timeout expired before operation completed".
In this cases the receive buffer (buf) contains always only the first character of the expeced instrument reply.

We found a workarround but this slows down the system: if we do not allow other threads to access GPIB between the function call (viWrite) and the reading of the functions response (viScanf), communication runs stable.

Software used:
NI-VISA 3.2
NI-VXI 3.3.1
NI-488 2.4
WinXP
MS VS 6.0

Additional note:
If in the upper code viWrite would be replaced by viPrintf, the following call to viScanf would all times return a n error.
What makes viPrintf behave other than viWrite in this circumstance?

Appreciate any hint to this subject.
Thanks in advance,

Fritz

[Jochen]

Sorry for the brief answer but first of all I'd like to know if  you have already seen the tutorial in the NI developer zone about multithreaded applications with NI-488.2.
Developing Multithreaded GPIB Applications using NI-488.2

Best regards,

Jochen Klier
National Instruments Germany

[FJ]

Thanks Jochen for your reply,

I just read through the document you mentioned.

A comment first. I am experienced with multithreaded techniques in general, but not so much with the bits and bytes of GPIB.

The document suggests to use the 488.2 device functions ibdev, ibwrt, ibrd, ibonl, ThreadIbsta, ThreadIberr, ThreadIbcnt...

By contrast in our application we use the VISA operations viOpen, viWrite, viScanf, viClose. All GPIB accesses are wrapped by entering and leaving a global critical section.

This mechanism works fine with a hardware variant where we use Keithley SMU 2400, which are interfaced using SCPI-Commands.

But with the new SMU 2602 instruments we experience the descibed sporadic problems. This new instruments are capable of scripting.

So we call such script functions stored in the instruments over GPIB and read back the return values of the functions via GPIB.

At this stage we have two Systems running in production and it appears that only with one of these the error occures may by every 1000-th GPIB access.

Do you recommend to use the 488.2 functions instead of the VISA operations in our case?

Best regards

Fritz

[Makoto]

In the code fragment you gave, there are two encapsulation of the critix - one is for viWrite, other is for viScanf.  Do the viWrite and viScanf calls work as a query-and-read pair?  If so, both viWrite/viScanf must be encapsulated in a critical-section, otherwise other threads may interfere the viWrite/viScanf pair.  Normally a SCPI instrument requires an explicit query command before you reading the response message.  If attempting to read from the instrument without sending any query command before, Query UNTERMINATED error will be generated.  If attempting to send a command to the instrument without reading previous query's response, Query INTERRUPTED error will be generated. 

As for difference between viPrintf and viWrite, viPrintf is buffered I/O that may or may not send the given GPIB command immediately.  Normally viPrintf requires explicit LF ("\n") termination to enforce to send the command at every function call.  Also, viPrintf implementation in VISA normally uses vsprintf library function to accept printf-style syntax.  I believe VISA32.DLL uses thread-safe C runtime library therefore its library use is not concerning the threading problem.

このメッセージは　02-21-2006 02:24 AMに Makoto が編集しています。

[FJ]

Thanks Makoto for answering.

In the case questioned no SCPI-Command is called, but a stored user script function with is executed by the GPIB-instrument before returning some sting. What we are trying to do to increase performance is to split up writing the function call to the instrument and reading of the function result. If this writing and reading is done noninterruptable (crit section encloses both operations) we don't have any problem but performance is slow.

Termination character is not the problem. Called functions are executed by the instruments (write operations succeeded), but sporadic the  read operations returns sporadic errorrouse having only the first char of the return string in the receive buffer.

Best regards,

Fritz