Stanislav Sotnikov

Just curious, is there any reasoning why autozero-ing takes up half of the sampling rate when `nplc >= 5`?

I would think from looking at the data that when `nplc < 5`, autozeroing causes small periodic gaps in timing. These timing gaps can be clearly seen on the attached plot (nplc is 1). the behavior at other `nplc < 5` values is consistently similar, and the actual sample timing is near the expected value. But when nplc is 5 and above autozero-ing suddenly takes over half of the sampling rate?

 

Setting the NPLC value to 5 or greater on either DMM6500 or DMM7510 results in the effective sampling period to be twice the expected value. The effective sampling period is inferred from the relative timestamps in the DMM buffer. I looked at data collected with various NPLC settings, and here is what I got (power line frequency is 60Hz):
 

NPLC	Sampling period (ms)	Sampling frequency (Hz)
0.1	0.167	600
1	16.67	60
2	33.33	30
4	66.67	15
5	166.67 ?	6 ?
10	333.33 ?	3 ?

Just submitted another ticket after being reached out by email and received confirmation. Thanks for investigating this.

I have submitted two tickets with technical support and received no response (not even a confirmation email).

DMM7510 does not react to the external trigger event caused by receiving "*trg" via SCPI interface over LAN.  Consider the following trigger model to reproduce the issue:

```lua
trigger.model.setblock(1, trigger.BLOCK_BUFFER_CLEAR, measure_buffer)
trigger.model.setblock(2, trigger.BLOCK_MEASURE_DIGITIZE, measure_buffer, trigger.COUNT_INFINITE)
trigger.model.setblock(3, trigger.BLOCK_WAIT, trigger.EVENT_COMMAND)
trigger.model.setblock(4, trigger.BLOCK_MEASURE_DIGITIZE, measure_buffer, trigger.COUNT_STOP)
```

Where `measure_buffer` is a buffer initialized prior loading the trigger model as
```lua
measure_buffer = buffer.make(12)
measure_buffer.fillmode = buffer.FILL_CONTINUOUS
```

During step 3 of the trigger model presented above, the host computer sends a "*trg" command, which is ignored by the instrument, that is the instrument does not transition to step 4, which contradicts the behavior described on page 13-337 of the reference manual (DMM7510-901-01 Rev. C / September 2019).

Despite ignoring the trigger event, the instrument stays responsive to the host queries. This way we can verify the the instrument is indeed stuck at step 3 of the trigger model by polling the active state.

```lua
print(trigger.model.state())
```

When the trigger event is ignored, the instrument does not display any warning messages (on the front panel screen). Furthermore, the instrument continues providing valid measurements, which can be extracted with

```lua
printbuffer(1, measure_buffer.n, measure_buffer.readings, measure_buffer.relativetimestamps)
```

Note, that the relative timestamps polled form the instrument, even after multiple consecutively ignored trigger events, keep increasing.


Also note that this issue is not present when running the same script on DMM6500, in which case the instrument properly reacts to the trigger event.

Both DMM6500 and DMM7510 discussed above are running v1.7.7b firmware versions.