06-16-2007 01:53 PM
06-18-2007 03:04 AM
06-19-2007 05:13 AM
06-21-2007 10:12 PM
06-23-2007 11:13 AM
06-23-2007 03:17 PM
06-25-2007 04:36 AM - edited 06-25-2007 04:36 AM
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 が編集しています。