The output queue stores up responses to queries from the controller. A query is any command ending in a question mark. Some plain-language examples of queries are : “What’s your identification?”, or “What’s the channel 1 scale factor?” or “What’s the value of measurement 3?” or “Are you done yet?”. When the controller asks the scope a question, the scope puts its response into the output queue until the controller can read it back, which is a separate operation. There’s one situation when using the output queue that you need to be careful of: The scope will delete an old response from the queue if it gets a new query before the old response is read back. For instance, the controller sends a query, then before reading back the answer, it sends another query. The answer to the first query will be deleted. This will foul up your program, because one of the answers will be missing, so it’s best to send a query then read the answer right away, before sending any other queries or commands. The exception to this is when all the queries are in a single GPIB transaction, separated by semi-colons, but you’ll be better off if you avoid the problem. The output queue is read by using generic Read functions or Vi found in most common programming language libraries.
The event queue stores up error messages in the scope. It’s 33 messages tall. Every time the scope has a new error, it will add one message to this queue. If the queue grows to the point where it begins to overflow, the last message will be “Queue overflow” and no more messages will be added to it. There’s a trick to this queue, just like the output queue. Sometimes I think the software engineers like to over-complicate things just for fun! Anyway, the trick is that you can’t read any messages from the event queue until a *ESR? command is sent. This command asks “What’s the value of the Standard Event Status Register (SESR)?”, clears the SESR register and floods the event queue with all the pending messages. We’ll talk about the specific registers later, but the important point here is that there won’t be anything in the event queue unless you send the *ESR? command first! The scope will have an error, you’ll need to know what the error is, but it won’t tell you everything until you do the *ESR? You can’t even clear the error unless you do this. So if you don’t send the *ESR?, the error remains and will probably mess up your program.
FAQ ID : 55076View all FAQs »