scpi-dmm: add short measurement delay for 34465A
With Keysight 34465A the VOLT:AC and FREQ functions keep suffering from USB timeouts and pipe errors. Add a 10ms delay between initiating the acquisition and checking for completion before fetching the result. The weird thing is that when successful responses are seen after temporary failure, enlarging the delay does not make them go away. Instead the USB errors keep moving to a different spot. Measurements do arrive though, so this is just annyoing but not a blocker. sr: [00:00.134038] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'. sr: [00:00.136043] scpi: Got response: '"FREQ +3.00000000E+00,+3.00000000E-06"', length 38. sr: [00:00.136119] scpi-dmm: dev_acquisition_start: Precision: '"FREQ +3.00000000E+00,+3.00000000E-06"' sr: [00:00.136251] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'. sr: [00:00.184211] scpi: Got response: '1', length 1. sr: [00:00.184481] scpi_usbtmc: Successfully sent SCPI command: 'INIT'. sr: [00:00.234800] session: bus: Received SR_DF_HEADER packet. cli: Received SR_DF_HEADER. sr: [00:00.245597] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'. sr: [00:01.246050] scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT. sr: [00:01.256495] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'. sr: [00:01.291871] scpi_usbtmc: USBTMC invalid bulk in header. sr: [00:01.302392] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'. sr: [00:01.401959] scpi: Got response: '1', length 1. sr: [00:01.402135] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'. sr: [00:01.403392] scpi: Got response: '1', length 1. sr: [00:01.403566] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'. sr: [00:01.405769] scpi: Got response: '"FREQ +3.00000000E+00,+3.00000000E-06"', length 38. sr: [00:01.406020] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'. sr: [00:01.407500] scpi: Got response: '1', length 1. sr: [00:01.407674] scpi_usbtmc: Successfully sent SCPI command: 'FETCH?'. sr: [00:01.409107] scpi: Got response: '+9.00555531E+01', length 15. Experimentation suggests that 200ms timeouts reduce the probability of these USB communication errors. But if functions tend to respond that differently, are delay time specs per MQ required? The implementation of the driver currently assumes a single delay spec.
This commit is contained in:
parent
e90551c3f8
commit
18426d1c0e
|
@ -261,7 +261,7 @@ SR_PRIV const struct scpi_dmm_model models[] = {
|
|||
1, 6, cmdset_agilent, ARRAY_AND_SIZE(mqopts_agilent_34405a),
|
||||
scpi_dmm_get_meas_agilent,
|
||||
ARRAY_AND_SIZE(devopts_generic_range),
|
||||
0, 0, 0, 0, FALSE,
|
||||
0, 0, 10 * 1000, 0, FALSE,
|
||||
scpi_dmm_get_range_text, scpi_dmm_set_range_from_text, NULL,
|
||||
},
|
||||
{
|
||||
|
|
Loading…
Reference in New Issue