Intermittant GPIB Errors "type mismatch"

[JerryCG2000]

The VB6 application I'm writing to control an Anritsu MP1570A Sonet Analyzer is now working moderately well, but I intermittently get the GPIB error,


"Unable to talk to GPIB device.||Type mismatch."


I find that this error does not occur if the program is single stepped. I have tried adding delays after each GPIB command and have played around with the duration. Delays seem to improve the situation but not entirely and not consistently. I'm not certain, but it seems like the problem may be less pronounced when the application is running standalone, i.e., not in the development environment. NI Spy reports no errors, by the way.


Has anyone seen anything similar or have an idea what the fix might be?


Thanks to all
in advance,
JG"

[nd]

Hi Jerry,
I don't know of a specific reason why this may happen..but the first step would be to try and narrow this down...
Do you have any casts in your code ?
Especially from string to double? (from data you are getting back perhaps ?)
Its possible that if there is a timing issue, then sometimes you may get invalid , or unexpected data back, so if you have a cast such as dblValue = Cdbl(strText) * 2 it may work most of the times, but fail, if strText is not a number in the unexpected case...
The other case could be that, it is a Gpib Write or a Gpib Command thats failing with the type mismatch error(The command itself will not take place if there is a type mismatch error - so NI-Spy will look fine...). This could be true in the case, where data you send out is
not a string literal, and something that you calculate in your code..
The Read should always work, since it returns a variant..
So those are two places you could look at for potential problems...i.e. (1) the GPIB Writes,especially those where the command is not a literal string and (2) any casts, or a combination of the two...
Hope this helps some...

[JerryCG2000]

Thanks for your suggestions, ND. As a matter of fact I'm doing both of these things. I've had the Cdbl function cause an error when it encountered a nul and the compiler notified me by stopping execution, but there may be other troubles that I don't know about. I'll have to look to see what I might be affecting with casts. What makes this especially difficult is that the NI errors give you no place to turn. They evidently occur within the NI code, and since that's hidden there's no way to directly know what happened; what variables to check.

Until your message I had nearly convinced myself that I have a timing issue, and was getting ready to try to implement some of the asynchronous program controls. The documentation looks a little out of date and a
bit sketchy, though, so I'm happy to have a couple of additional things to check before I take that step.

JG

[Ray K]

If Spy reports no error then it is likely not a problem with GPIB I/O. How is the "Unable to talk to GPIB device" error message passes to you? Do you read if from the bus? Is the type mismatch in the same error message as the "Unable..." message? Have you been able to track down where in your program and with what function these errors are being generated?

[JerryCG2000]

Ray,

This is the heart of the problem. The message appears to be generated by an NI module and appears as a modal message box. If I click OK or stop the program with , I'm left with a screen that reveals no clue as to where the error might be generated. If I hit F8 to single step, I'm back into whatever hidden routine generates the error.

The appraoch I've decided to take is to rewrite the module with a slightly different approach to the control structure. Hopefully I will avoid the unknown combination of events that causes this.

Thanks,
JG