On Fri, Nov 08, 2013 at 09:53:14PM +0100, Mathias Grimmberger wrote: > > > I see you've been using the SCPI "*OPC" command to try to get the scope > > to complete each command before issuing the next. Has this gotten you > > anywhere? > > Can't say, I have never seen a command not having completed by the time > I checked the OPC bit, it's mostly just paranoia on my part. But > commands may execute a bit slower if more load is put on the processor, > maybe when FFT or protocol decoding is enabled?
Ah, sorry, I had just glanced at a bit of the code with *OPC, and thought it was just something you'd tacked on to try to block until completion, hence my comments about the meaning of that command. I missed that actually you were reading back the SR elsewhere. > There is a difference between Agilent and Rigol regarding this. For > "*OPC" they agree, for "*OPC?" Agilent docs claim it will block the > caller until the operation completed and will always return 1, Rigol > says it will return either 0 or 1 and apparently won't block. The two usages are not inconsistent with each other, if a 1 from the Rigol reliably indicates that it has already completed the operation. I'm guessing the standard says something to the effect of "returns 1 if the operation is complete or 0 if the operation is not yet complete". If so both approaches are compliant, with the Agilent one "cheating" and just waiting before returning either, such that it can always return 1. In general, the business of correctly handling command completion seems like something it would be good to move out into the common SCPI implementation that Damir Jelić has been developing (see https://github.com/poljar/libsigrok/blob/hameg/hardware/common/scpi.c - when his code is completed and merged I would like to change the Rigol driver to use it also). > Got some interesting results too, e.g. that trying to enable the > promising sounding "Trigger" bit in the State Byte Register gives an > error. I recall that Simon Richter encountered something possibly related to this on the DS1xx2, when he was prototyping direct use of the device over USB using the USBTMC specification. If I recall correctly, the USBTMC spec is supposed to include the use of a USB interrupt channel to signal when event bits in the status register change. On the DS1xx2, it was possible to set this up but the expected events would never show up on the interrupt channel. This made the device not actually compliant with USBTMC as far as we could see. Perhaps they resolved this non-compliance in the next version by simply not allowing this to be set up in the first place? :) > It goes to SINGLE for a short time (not sure it even reaches waiting for > trigger), then jumps back to STOP. The screen is then empty, no waveform > has been captured. Instead of the configured sample memory depth only > 1400 samples are available for download, probably containing trash > (didn't check). > > I suspect either a race condition or the processor in the scope get's > overloaded a bit sometimes. > > Maybe it's the latter, since immediately issuing a ":SING" will usually > fail again, but waiting a bit makes it work. Hmm. If waiting a bit makes it work, have you checked the status register before and after waiting, to see if there is some change? Martin ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
