How do you check the error queue/status bits on a device?

[Jeramy_Soucy]

I am using VB .NET with Measurement Studio 7.1 (GPIB interface). I'd like to check the error queue after each command from the user is written to the connected device just to make sure the user didn't make a syntactical error. I've tried using GetCurrentStatus() to check for an error then attemping to use SYST:ERR? to get the error string into the output buffer. I'll deliberately enter a bad command, the device will beep and show an error, but my application does nothing. I threw in a couple breakpoints to check what is going on. The if check evaluates to false though there is an error. Here is the conditional:

If (m_Multimeter.GetCurrentStatus = GpibStatusFlags.Error)
...
End If

I've also tried using the equals() method in place of the boolean = operator. I have a feeling I am not using the GetCurrentStatus call correctly because when I attempted to check for "Message Available" (16 - or the Attention code) that did not work either. That bit should be on when the output buffer of the device contains a message. I would send a valid command and the status was never changed to reflect that bit 4 was now on. Is there some setup I must perform to be able to use GetCurrentStatus()?

[Jeramy_Soucy]

OK -
Well, I figured out on my own that the error enumeration means a status error not that the status is that the device is currently in error (it is a large negative value, not a positive power of two...I should've seen that earlier).

I am still completely confused on how to check for an error via my application code. I can read errors using SYST:ERR? - which works great...the problem is that I cannot seem to detect (within my VB code) that there is an error waiting in the error queue. Does anyone know how to do this? GetCurrentStatus has no way of checking if there is anything in the error queue.

[Glenn Burnside]

JS,
If you're looking just for a way to determine if there any errors present, could you not parse the results of calling "SYST:ERR?" - doesn't it return "0, No Error" or something to that effect when there is no error?

An alternate approach would be to use the *SRE command to enable the appropriate bits in the status byte register to cause a service request, then do a serial poll whenever you want to check for error to see if a service request has been issued. If there was a service request, you could query for the value of the status byte to determine the kind of service request, and if there was an error on the instrument, retrieve the error with the SYST:ERR then.

I'm not sure exactly what your application is trying to do, but maybe it would be more effective in the long run if the user of the application didn't send messages directly to the device, but instead your app could build up the appropriate commands based on the user's input and send it, thus guaranteeing that the commands would be in the proper syntax.

[Jeramy_Soucy]

Hey Glenn,

The reason I cannot use "SYST:ERR?" to check for an error is because it interrupts the previous command if one exists. If the user types in "MEAS:RES?" then I send "SYST:ERR?", the resistance measurement output is interrupted. This method works fine for when you enter an invalid command but not a valid one. I suppose I can store the user's command, send it, then send the SYST:ERR? command, check the result and if it's clean send the original command again but that seems redundant.

With using the "*SRE" command I revert back to the problem that you helped me with the other day (the 550 error code ... see post - http://forums.ni.com/ni/board/message?board.id=232&message.id=1177) Thanks by the way 🙂
If I use *SRE 1 or *SRE 0 in the initialization of my program (putting it just before the SetRemoteEnableLine call) my device will not enter remote mode. Not sure why. If I put it after, all calls to serialpoll result in an empty byte.

The application I am working on is essentially to help me learn measurement studio. I am trying to learn everything I can by attempting various tasks. Eventually I will be developing an application for a client, in which case I will not allow the user to type in his/her own text commands. I was trying to find a way to check for an error on the fly without interrupting the device's I/O. I figured that there must be some bit somewhere to show whether there is currently any errors in the error queue, but it's looking more and more like this bit is not directly accessible.

Any thoughts or suggestions?

Thanks for reading my posts and helping me out, Glenn. It is most appreciated.
~ Jeramy

[Glenn Burnside]

JS,

[Glenn Burnside]

JS,

[Glenn Burnside]

JS,
Sorry, I'm typing too fast and accidently posting! I checked the manual for the 34401A DMM, which I believe is the device you're using. You can get it online here. Page 135 has a map of the status registers that control when SRQ's are asserted. From that map, you can see that "*SRE 1" is going to have no effect, because bit 1 of the Service Request Enable register does nothing. Your original intent was to get an indicator that a bad command was sent. So, that's going to be *SRE 32 to enable service requests from the Standard Event Register. Then, *ESE 32 to enable the Standard Event Register to register Command Errors. After that, if you send an invalid command, a serial poll should show that a service request occurred. you should then be able to query the status byte with *STB?, check whether the request came because of the standard event register, then query the standard event register with *ESR? to determine if the event was a command error event.

Also, I believe someone noted in another thread that you can configure your GPIB board to always assert REN when it is the controller, so you wouldn't have to call that on a board instance in your code.

[Jeramy_Soucy]

Glenn,
I see now how the status byte and standard event byte work. Thanks for that link. I still haven't gotten my program to work as I wanted, but I am much closer. I use "*SRE 0" and "*ESE 0" to clear the enable registers then "*SRE 32" and "*ESE 32" to enable the ESR(standard event register) byte and the command error bit in the ESR. I use the following chunk of code after a command is entered. This is supposed to check to see if the command caused an error, and if it did to write the command to put the error into the output buffer.

Dim StatusByte(0) as Byte
If (m_Multimeter.SerialPoll = SerialPollFlags.EventStatusRegister) Then
'm_Multimeter.Write("*ESR?")
'StatusByte = m_Multimeter.ReadByteArray(1)
'If (StatusByte(0) And 32) Then
m_Multimeter.Write("SYST:ERR?")
'End If
End If

Right now I have commented out the *ESR? section since the only bit in the register I have enabled is for command errors, and this makes things more simple to work with for the time being. However the following are my results:

- When entering a command for the first time as a user of the application I do not get passed the conditional (the Event Status Register Bit in the Summary Register is not toggled for some reason). Entering an invalid command only sets the flag if I enter a valid one first. Strange.

- If I enter a valid command first, it will detect an invalid command afterwards just fine and I catch the error message from the output buffer. After this I cannot enter valid commands without them getting interrupted because execution gets passed the conditional again. I have tried using the *CLS command to clear out the ESR as the manual claims, and then I can enter a valid command followed by an invalid command and then as many valid commands as I want, but as soon as I enter another invalid command I do NOT get passed the conditional (the ESR bit in the Status Byte is not toggled on).

It seems like the Status Byte and ESR are being cleared by *CLS but then are not working again afterwards, invalid commands no longer turn on the command error bit and then the ESR bit (in the Status Byte). I've tried reissuing the *SRE 32 and *ESE 32 commands to make sure they are on but this makes no difference (the enable bits are not cleared by *CLS or *ESR? anyway...was just taking a shot in the dark). I have also tried calling the clear method on both the board and device, and calling reset on both...and many combinations of all of these things in various orders. Nothing seems to be allowing the ESR bits and the ESR bit in the status byte to be retoggle-able. *CLS is supposed to clear both the Status Byte and the ESR; it does so, but then the bits never get turned on again when they should. Does anyone know what I need to do to reset the status byte and ESR so that their bits will be toggled on appropriately after a *CLS command?

[Jeramy_Soucy]

Also...any idea why initially entering a bad command would not toggle the bits, but initially entering a valid command and then an invalid will work???

[Jeramy_Soucy]

Ok...I've been tinkering with my code. I've changed around the body of the conditional statement so it now reads like so:

If (m_Multimeter.SerialPoll = SerialPollFlags.EventStatusRegister) Then
Dim EventStatus(256) As Byte
m_Multimeter.Write("*ESR?")
EventStatus = m_Multimeter.ReadByteArray(256)
' if it was a command error then put it in the output buffer
If (EventStatus(0) And CByte(32)) Then
m_Multimeter.Write("SYST:ERR?")
End If
End If

When I run my program normally this provides the same results as my previous code, although now I am checking the actual value stored in the ESR to make sure that the command error I am looking for is actually flagged.

The extremely interesting thing is that when I set a breakpoint at the first If statement I can step through my program and it works perfectly! Every time I enter an invalid command (whether it is first command entered or not) I get into the conditional and I retrieve the error code as I should. Whenever I enter a valid command I do not get into the conditional and everything is fine.

Any ideas why stepping through my code statement by statement would work, while flat-out running the program causes the unexpected results described in my previous post? Could it be that the program is being executed too quickly while the device is still attempting to process the bit queries thus giving me an inaccurate status? I've tried using m_Multimeter.Wait(GpibStatusFlags.IOComplete) to wait for the results of commands and queries but this did not make a difference.