Tektronix and Keithley

Posted: **January 4th, 2018, 3:48 pm**

I'm talking to an MDO3012 scope with pyVISA. I have a strange coordination issue. After I make a change to the voltage scale, for instance, I query the number of acquisitions (start_ac = query(':ACQ:NUMAC?')) and then sit in a while loop until the number of acquisitions equals or exceeds start_ac + num_averages.

Here's the (simplified) code:

Code: Select all

start_ac = int(self.query(':ACQ:NUMAC?'))
ac = start_ac
while ac < start_ac + n_av:
    ac = int(self.query(':ACQ:NUMAC?'))
    time.sleep(config.scope_intermeasure_delay)
    log.debug('PyScopeTek: n_av is {}, start_ac is {}, ac is {}'.format(n_av, start_ac, ac))

This logs:
04:27:28 PM- DEBUG - PyScopeTek: start_ac is 91
04:27:28 PM- DEBUG - viWrite(2L, ':ACQ:NUMAC?\r\n', 13, 'c_ulong(13L)') -> 0
04:27:28 PM- DEBUG - TCPIP0::10.1.0.31::inst0::INSTR - reading 20480 bytes (last status <StatusCode.success_max_count_read: 1073676294>)
04:27:28 PM- DEBUG - viRead(2L, <ctypes.c_char_Array_20480 object at 0x000000001D40ABC8>, 20480, 'c_ulong(3L)') -> 0
04:27:28 PM- DEBUG - PyScopeTek: n_av is 1, start_ac is 91, ac is 91
04:27:28 PM- DEBUG - viWrite(2L, ':ACQ:NUMAC?\r\n', 13, 'c_ulong(13L)') -> 0
04:27:28 PM- DEBUG - TCPIP0::10.1.0.31::inst0::INSTR - reading 20480 bytes (last status <StatusCode.success_max_count_read: 1073676294>)
04:27:28 PM- DEBUG - viRead(2L, <ctypes.c_char_Array_20480 object at 0x000000001D40A048>, 20480, 'c_ulong(3L)') -> 0
04:27:28 PM- DEBUG - PyScopeTek: n_av is 1, start_ac is 91, ac is 91
04:27:28 PM- DEBUG - viWrite(2L, ':ACQ:NUMAC?\r\n', 13, 'c_ulong(13L)') -> 0
04:27:28 PM- DEBUG - TCPIP0::10.1.0.31::inst0::INSTR - reading 20480 bytes (last status <StatusCode.success_max_count_read: 1073676294>)
04:27:28 PM- DEBUG - viRead(2L, <ctypes.c_char_Array_20480 object at 0x000000001D40ABC8>, 20480, 'c_ulong(3L)') -> 0
04:27:28 PM- DEBUG - PyScopeTek: n_av is 1, start_ac is 91, ac is 91
04:27:28 PM- DEBUG - viWrite(2L, ':ACQ:NUMAC?\r\n', 13, 'c_ulong(13L)') -> 0
04:27:28 PM- DEBUG - TCPIP0::10.1.0.31::inst0::INSTR - reading 20480 bytes (last status <StatusCode.success_max_count_read: 1073676294>)
04:27:28 PM- DEBUG - viRead(2L, <ctypes.c_char_Array_20480 object at 0x000000001D40A048>, 20480, 'c_ulong(3L)') -> 0
04:27:28 PM- DEBUG - PyScopeTek: n_av is 1, start_ac is 91, ac is 91
04:27:28 PM- DEBUG - viWrite(2L, ':ACQ:NUMAC?\r\n', 13, 'c_ulong(13L)') -> 0
04:27:28 PM- DEBUG - TCPIP0::10.1.0.31::inst0::INSTR - reading 20480 bytes (last status <StatusCode.success_max_count_read: 1073676294>)
04:27:28 PM- DEBUG - viRead(2L, <ctypes.c_char_Array_20480 object at 0x000000001D40ABC8>, 20480, 'c_ulong(2L)') -> 0
04:27:28 PM- DEBUG - PyScopeTek: n_av is 1, start_ac is 91, ac is 1
04:27:28 PM- DEBUG - viWrite(2L, ':ACQ:NUMAC?\r\n', 13, 'c_ulong(13L)') -> 0
04:27:28 PM- DEBUG - TCPIP0::10.1.0.31::inst0::INSTR - reading 20480 bytes (last status <StatusCode.success_max_count_read: 1073676294>)
04:27:28 PM- DEBUG - viRead(2L, <ctypes.c_char_Array_20480 object at 0x000000001D40A048>, 20480, 'c_ulong(2L)') -> 0
04:27:28 PM- DEBUG - PyScopeTek: n_av is 1, start_ac is 91, ac is 2
04:27:28 PM- DEBUG - viWrite(2L, ':ACQ:NUMAC?\r\n', 13, 'c_ulong(13L)') -> 0
04:27:28 PM- DEBUG - TCPIP0::10.1.0.31::inst0::INSTR - reading 20480 bytes (last status <StatusCode.success_max_count_read: 1073676294>)
04:27:28 PM- DEBUG - viRead(2L, <ctypes.c_char_Array_20480 object at 0x000000001D40ABC8>, 20480, 'c_ulong(2L)') -> 0
04:27:28 PM- DEBUG - PyScopeTek: n_av is 1, start_ac is 91, ac is 4
04:27:28 PM- DEBUG - viWrite(2L, ':ACQ:NUMAC?\r\n', 13, 'c_ulong(13L)') -> 0
04:27:28 PM- DEBUG - TCPIP0::10.1.0.31::inst0::INSTR - reading 20480 bytes (last status <StatusCode.success_max_count_read: 1073676294>)
04:27:28 PM- DEBUG - viRead(2L, <ctypes.c_char_Array_20480 object at 0x000000001D40A048>, 20480, 'c_ulong(2L)') -> 0
04:27:28 PM- DEBUG - PyScopeTek: n_av is 1, start_ac is 91, ac is 6

...etc...

I highlighted the strange line. For some reason, the number of acquisitions reset to 1. Is this a synchronization issue? Prior to this loop, I set the scale (viWrite(2L, ':CH1:SCA 2.00e-01\r\n', 19, 'c_ulong(19L)') -> 0) and queried the acquisition mode (viWrite(2L, ':ACQ:MODE?\r\n', 12, 'c_ulong(12L)') -> 0). Neither of these commands would appear to trigger the *OPC? wait.

Posted: **January 5th, 2018, 8:32 am**

Adding some more info:
From python, I tried the following 10 times, with 's' being the scope object.

Code: Select all

print s.query(':ACQ:NUMAC?')
start_time = timeit.default_timer()
s.write(':CH{0}:SCA {1:.2e}'.format(1, 0.05))
elapsed = timeit.default_timer() - start_time
print 'Entering loop at ' + str(elapsed)

for i in np.arange(0,10):
    print s.query(':ACQ:NUMAC?')
    elapsed = timeit.default_timer() - start_time
    print 'query {} at time {}'.format(i, elapsed)

Over 10 tests (I changed the new voltage scale each time), the time to reset NUMAC after the change in voltage scale was 0.071 +/- 0.004 s. (Each python loop iteration took about 0.01 s.)

Unless someone has a better idea, I'm going to just add a 0.08s pause after changing the voltage before I query NUMAC for the baseline value.

Posted: **January 5th, 2018, 11:57 am**

Hi ellen,

What's your end goal in this case?

Therecould be a number of things (including synchronization problem) that could be at play here, but it is worth noting that polling the instrument whilst running isn't best practice. I'd recommend single shot acquiring however many acq's you'd like to help ensure sync.

Posted: **January 8th, 2018, 8:26 am**

I guess I could use single acquisitions to ensure synchronization but it complicates my application a bit as I typically do a fair amount of adjustment on the scope manually, then run an acquisition sequence from the computer. I could have the code take over control and do a series of single acquisitions.

Isn't supplying incorrect data strange behavior? I have no problem if the scope was put into a wait state and I used OPC? or WAI to synchronize, but I don't expect for it to return things that are so out of synch.

Posted: **January 8th, 2018, 11:03 am**

Many commands don't affect *OPC? and there are many of the scopes systems run asynchronously, which leaves us with cases like this one where the only sure way to synchronize is to use single shot acquisitions.

Tektronix and Keithley

:ACQ:NUMAC? resetting unexpectedly

:ACQ:NUMAC? resetting unexpectedly

Re: :ACQ:NUMAC? resetting unexpectedly

Re: :ACQ:NUMAC? resetting unexpectedly

Re: :ACQ:NUMAC? resetting unexpectedly

Re: :ACQ:NUMAC? resetting unexpectedly