Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

repeated capabilities

When using the instrument IVI drivers for the Tektronix DPO7254, the driver generates error "the channel or repeated capability name is not allowed when running the tkdpo7k Fetch Waveform Measurement VI. Why do I get this error?
0 Kudos
Message 1 of 7
(5,156 Views)
Repeated capability name such as scope's channel or trace name must be one of physical names defined by the IVI driver or one of virtual names configured by IVI configuration server.
 
If your program specifies a true VISA address on <prefix>_init() or <prefix>_InitWithOptions() call, the repeated capability name must be a physical name defined by the driver.  If your program specifies a "logical name" instead of true VISA address, the repeated capability name can be a driver-designed physical name or configured virtual name. 
 
To see what physical names are defined by the driver or what virtual names are configured by IVI configuration, use NI-MAX and then find the detail info about your IVI driver, such as Logical Name, Driver Session, and Software Module, etc...
0 Kudos
Message 2 of 7
(5,139 Views)
Hello and thanks for your answer.
In fact, the repeated capability message I receive it only when I try to read a measurement (e.g. amplitude), no problem when I read the channel waveform. Using NY-Spy, I see that the error message appears before sending any GPIB instruction. It must be a software problem in tkdpo7k. I receive the same message even when I just simulate the instrument...
0 Kudos
Message 3 of 7
(5,123 Views)
I installed the tkdpo7k IVI-C driver to my pc.  It seems like accept physical names CH1, CH2, CH3, and CH4.  Therefore any driver functions that require a channel name as "repeated capabilities" will accept one of these names.  Or you can also use a user-defined virtual name, which is mapped to a correct physical name as in your Logical Name configuration entry. However, according to the driver help, tkdpo7k_ReadDelayMeasurement() and some other measurement functions may take one or two channel names such as MATH1..4 and REF1..REF4, as well as CH1..4.  But MATHx and REFx names are not found in the driver's physical name list.
 
What function are you trying and what channel name is being passed?
 
 
 
0 Kudos
Message 4 of 7
(5,094 Views)
To read measured parameters I use "Fetch Waveform Measurement" VI on CH1 or CH2. I use the tkdpo7k IVI driver, the VISA one works fine but it is very slow.
0 Kudos
Message 5 of 7
(5,078 Views)
Both the IVI and native LabVIEW drivers use VISA and they are sending the same commands for the fetch. The only difference I can tell after a quick look is that the LabVIEW driver does an error query of the instrument after getting a measurement. I'm not a big fan of drivers that do this and prefer to call the error query when and if I want to. You can try deleting the tkdpo7k Error Query.vi function in the LabVIEW driver to see how much of a difference it makes. If you are configuring the instrument a lot, then the state caching of an IVI driver may also be a factor. You can optimize your code to reduce this difference.
0 Kudos
Message 6 of 7
(5,070 Views)

I saw the impl source for tkdpo7k_FetchWaveform() but it looks like have no problem for validating repeated capability name.  It is actually validated by the following code:

viCheckParm( Ivi_CoerceChannelName (vi, channel, &channelName), 2, "Channel");

The actual validation process is embedded in IVI runtime engine and this approach is commonly used by other driver's functions, therefore CH1..CH4 must be valid as long as they are listed as in Physical Names entries.  I belive  these channel names must be acceptable by drivers any time.

As for "slow" problem, there may have two reasons.

Unlike READ operation, typically FETCH operation must be used after other READ operation or INITIATE operation, because FETCH operation in general requires the measurement has been already initiated.  FETCH operation in general does not have a side-effect to spontaneously initiate the measurement.  (Though I am not sure if your Tek scope also behaves like this.)  Likely you may need to call tkdpo7k_InitiateAcquisition() before fetch.

Other reason is, as Dennis pointed out, implicit "error query" operation after each function call may take a second.  To bypass the implicit "error query" call on IVI drivers, you can specify "QueryInstrStatus=FALSE" in the OptionString param when you call <prefix>_InitWithOptions(). 

 

 

このメッセージは 06-25-2007 07:38 PMに Makoto が編集しています。

0 Kudos
Message 7 of 7
(5,048 Views)