EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: slugrustle on February 03, 2024, 08:02:05 pm
-
I'm trying to automate synchronized measurements with two Rigol DM3068 DMMs and external triggering. In particular, both DMMs are set to 2 NPLC integration time, auto zero on, auto trigger delay, external trigger, positive slope. I've got a signal generator outputting a 10Hz 5V square wave to the external trigger input on both meters. They don't seem to miss triggers with this configuration.
I want to get the most recent measurement from both meters after each trigger over SCPI, but there does not seem to be a way to do this reliably because the Rigol SCPI system makes no sense. Has anyone else run into these problems, and are there workarounds?
I want to send SCPI commands to figure out when the DMMs have triggered and read the most recent measurement. This should be possible because the USB bus turnaround time (~3ms) is shorter than the trigger period (100ms) and integration time (67ms with autozero). I could run the trigger slower if needed.
My problem is that there does not seem to be a way to reliably determine when a new trigger has occurred and then read the last measured value.
- The Rigol command set MEAS? command returns TRUE when new data has come in that has not been read out. However, there is no way to read the previously measured value and reset the result of the MEAS? command to FALSE. FUNC2:VAL1? and MEAS:VOLT:DC? in the rigol command set only give you the measurement result after the next trigger. VAL1? in the fluke command set reads the previously measured value but it does not reset the result of MEAS? to false. This implementation is completely braindead.
- I could send MEAS:VOLT:DC? commands to both meters with sufficiently long timeout, wait for results, and then immediately send new MEAS:VOLT:DC? commands as quickly as possible. My concern here is with race conditions. If the two MEAS:VOLT:DC? commands go out at slightly different times near an external trigger edge, one of the meters might miss a trigger. I suppose I could check for this by timing when results come back and ignore data samples on missed triggers.
- I could also use the Agilent command set to initiate the collection of a group of samples (<=512), wait for the time that takes, and then FETCh? the results. There would be a processing delay between groups of measurements, but I think I'm ok with that. I can run statistics on each group of 512 samples or whatever. My concern here, again, is a race condition. One of the meters might miss the first trigger, and then all of the samples would be staggered between the two meters by one trigger period. I suppose I could try controlling the sig gen as well, send INIT to both meters, wait, then enable the sig gen output for triggering.
Is there another or better way to do this? Other than buying Keysight or Tek meters, that is. I'm starting to save money for that. These meters work ok, but some of the implementation is just stupid, and it's pissing me off.
Another fun one with the DM3068 is it can save up to 512 readings in its internal buffer, but this is only accessible in the Agilent command set. And it lets you set SAMP:COUN to greater than 512, but it just completely hangs the SCPI subsystem if you do that. Very fun. This is also not mentioned in the datasheet or in the SAMP:COUN or INIT or FETC commands in the programming manual. You have to check the DATA:FEED RDG_STORE command in the programming manual.
-
Using SCPI the proper way and checking for command ready might be tricky. There are standard SCPI registers and bits, for status and errors, and command ready to tell when a command was completed, and if successful or with error. Then, some instruments will have additional instrument specific status registers and error registers. Sometimes a simple chain of commands sent all at once (in the same line) may achieve what the same commands sent one by one might not work. The higher protocol on top of SCPI might help, too, try VXI11 or VISA.
Mentioning all these because you didn't say what you are using for automation, which makes me guess you are sending over USB-TMC only raw SCPI text listed in the programming manual (without handling the status or the error registers). The SCPI manual usually doesn't tell how to handle errors and status registers, which are usually handled in higher level protocols by the protocol drivers (not the USB drivers).
I don't have a DM3058, so no idea if it is possible or not to collect the measurements at the needed rate.
-
I'm doing SCPI strings over USB with Rohde & Schwarz' VISA library. I could add extra commands to check the status registers for errors and things. The status register that might help the most is the one that either says "waiting for trigger" or "measuring" I suppose I could use that if I spammed it at high enough rate.
What looks very promising right now is setting the DMMs to measure 100 samples (or so), sending the INIT command to both of them, waiting 10ms for that command to go through (I could also check *OPC) and then triggering my signal generator (Siglent SDG1032X) over SCPI in NCYCLE burst mode to output the desired number of trigger pulses to both DMMs (the one output channel is wired to the external trigger inputs on both DMMs with a BNC T junction). Then I can use the DATA:POINts? command on the meters to figure out when they're done and call FETC? to get the data.
This basic setup is working with front panel operation and the DMMs set to turn statistics on. Every time I trigger a burst from the signal generator, the number of samples in statistics mode goes up by exactly that amount.
This way I don't need to send or receive SCPI commands at high rate or with special timing. All of the synchronization is down to the trigger signal itself.
-
Oh, I think I get what you're saying. I can send a raw SCPI command, *OPC?, that will return 1 once the last operation is complete.
The fun thing about the Rigol command set, mentioned in the post you replied to, is that the MEAS:VOLT:DC? command returns a value only after the next trigger. So I can't send *OPC? following MEAS:VOLT:DC?, because MEAS:VOLT:DC? won't return until the next measurement anyway. And once it returns a value, it's complete. Hence my remark in the post you replied to about measuring the timing with which these measurement commands return to check for missed triggers.
-
I haven't used Rigol DMMs, but did you study the status registers in the manual? Generally there will be a master status register (*STB?) which then references other, more fine-grained, status registers. And you can sometimes configure to what you want status bits to respond. If you INITIATE the measurement, then you should be able to poll the "message available" bit in the status register for the measurement to be complete. The manual should document all status registers and how to set them up.
-
Ah, thanks, and sorry to both alm and RoGeorge for being slow on the uptake here. I checked the R&S VISA library API manual, and it does look like I can register callback handlers on events such as triggers or service requests. I had erroneously assumed that interrupt or event style mechanisms weren't present on the USB bus because it's a serial bus... This must be handled at the protocol level like RoGeorge said.
It looks like I can set up the enable registers so that a message available event causes a service request. If I use the MEAS:VOLT:DC? query that only returns after the next measurement, then I'd probably have to write that query, use an event callback to find out when there's a message available, then do an SCPI read to get the message. It's not awfully different from multithreading the program, doing reads right away, and waiting for them to return, although it could likely avoid multithreading depending on how the read timing works out.
Or I could poll the meters with *STB? queries like alm said. That probably only works with INIT AND FETCh? since MEAS:VOLT:DC? is itself a query...
So thanks to both of you. It's good to know about these options.
What ended up working well enough was:
- Set the signal generator for a burst of 100 square waves at 10Hz, "manually" triggered.
- Set both DMMs with TRIG:COUNt = 100, SAMP:COUNt = 1, 2 NPLC integration time, autozero on, TRIG:SOURce EXT, TRIG:SLOPe POS, auto trigger delay.
- INIT both DMMs
- Trigger the signal generator over USB to send the burst of 100 triggers.
- Poll DATA:POINts? on both meters until they both have stored 100 points or until this times out (in case of a missed trigger).
- FETCh? the data from both meters and use it.
- Go back to step 3, world without end.