From 18426d1c0e36b2b26d9dfc53eaac64b857e941c8 Mon Sep 17 00:00:00 2001 From: Gerhard Sittig Date: Sat, 22 May 2021 15:19:05 +0200 Subject: [PATCH] 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. --- src/hardware/scpi-dmm/api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/hardware/scpi-dmm/api.c b/src/hardware/scpi-dmm/api.c index 73a046ff..a823196d 100644 --- a/src/hardware/scpi-dmm/api.c +++ b/src/hardware/scpi-dmm/api.c @@ -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, }, { -- 2.30.2