ACQUISITION_START_TIME

[GE-HCS]

Hello,

I'm trying to define ACQUISITION_START_TIME to Tektronix DPO3034 through USB interface with CVI.
I managed to install the driver and can communicate with the oscilloscope.
When I write the delay value (3.5334E-005) this is what i get from the Spy:

1.  IviScope_SetAttributeViReal64 (DPOScope, NULL, ACQUISITION_START_TIME, 3.5334E-005)
Process ID: 0x00001534         Thread ID: 0x00000874
Start Time: 17:29:42.456       Call Duration 00:00:00.015
Status: 0 (VI_SUCCESS)

That means that the right command was passed.

But... the delay in the scope comes with 0.4us resolution. That means that i can get ACQUISITION_START_TIME values of only 3.56E-005, 3.6E-005 etc.

This is what I get in the spy with GetAttribute command imeddiatley after the above SetAttribute command:

4.  IviScope_GetAttributeViReal64 (DPOScope, NULL, ACQUISITION_START_TIME, 3.56E-005)
Process ID: 0x00001534         Thread ID: 0x00000874
Start Time: 17:34:11.995       Call Duration 00:00:00.016
Status: 0 (VI_SUCCESS)

(The actual delay on the scope screen is also 3.56E-005...)

Thank you for your assistent!

[STASHkal]

Does the scope support the delays you want?  Do you know that the scope can be programed by other means to accept that value?  

[GE-HCS]

Yes, the scope supports the delays I want when I define them manualy or with stand alone program based on LabView (don't have access to the code...)

Just to mention that the CVI program does what I need on 3 other scope models.

[STASHkal]

Can you compare the NI-SPY logs for the what is sent using the LabVIEW (successful) and CVI (unsuccessful) drivers?  are the two drivers writing to the same atributes?  

I also wonder if there is precision setting for the delay that must be set prior to specifying that delay.  You may want to look several commands back in the NI-SPY logs to try and find such a precision setting.  The idea of a precision setting is pure speculation on my part. 

just to confirm; The labview driver for DPO3034 functions well but the C driver for the same instrument is demonstrating the undesireable behaviour? 

As a work around you could call the labview code from C.  

[GE-HCS · Accepted solution]

This was a rounding to 400ns in the driver from NI that came after a comment that this is due to change in the firmware. I chaged the rounding back to 4ns and everything is fine.