05-23-2014 02:16 PM
To be sure, it seems he's a bit overzealous about *opc? even after queries, but I don't think it does any harm beyond adding an extra command. 😉
05-23-2014 02:45 PM
@billko wrote:
To be sure, it seems he's a bit overzealous about *opc? even after queries, but I don't think it does any harm beyond adding an extra command. 😉
Yes I had also notice his over use also.
But with my Tek Scope, it did do harm. My scope did not like it when I sent it "*IDN?;*OPC?\n"
I could send it "*IDN?;". Read in the reply. Then send it an "*OPC?\n" OK, but not as one command string.
The problem is that USB is single duplex and as soon as my scope sees the semicolon (;) at the end of the *IDN? it starts replying back at the same time I am still sending the '*OPC?' causing a clash.
I have some Agilent intruments that in the manual they warn about sending more than one request command (?) in the same command string when using serial communication (RS232). It's not a problem with GPIB as you control when the instrument talks.
05-23-2014 02:47 PM
@Omar_II wrote:
@billko wrote:
To be sure, it seems he's a bit overzealous about *opc? even after queries, but I don't think it does any harm beyond adding an extra command. 😉
Yes I had also notice his over use also.
But with my Tek Scope, it did do harm. My scope did not like it when I sent it "*IDN?;*OPC?\n"
I could send it "*IDN?;". Read in the reply. Then send it an "*OPC?\n" OK, but not as one command string.
The problem is that USB is single duplex and as soon as my scope sees the semicolon (;) at the end of the *IDN? it starts replying back at the same time I am still sending the '*OPC?' causing a clash.
I have some Agilent intruments that in the manual they warn about sending more than one request command (?) in the same command string when using serial communication (RS232). It's not a problem with GPIB as you control when the instrument talks.
Hey, that IS interesting. I never actually tried that combo before; it never occured to me to do so.
05-23-2014 02:53 PM
I should add that it might be a problem even with GPIB instruments.
Some GPIB instruments do not like it if you send it a query (?) and then send it a 2nd query (?) without first requesting the reply from the first. They will return an error when when you finally get around to telling them to "talk"
05-23-2014 04:07 PM
05-23-2014 04:12 PM
05-23-2014 04:23 PM
05-23-2014 04:56 PM
@matt.baker wrote:
Another example of a command which requires a long timeout (30 seconds to minutes) is the *TST? Self test. This is a good example of why I break up my timeouts into smaller chunks.
So how do you handle this case? I mean, I can certainly see adjusting the timeout for this command, then shortening it back down for other commands. I wouldn't use the looping thing, though.
05-23-2014 05:38 PM
05-23-2014 05:46 PM