Measurement Studio for VB6

cancel
Showing results for 
Search instead for 
Did you mean: 

CWGPIB control - Incomplete message passed when writing to instrument

I'm having a major issue with communications with a piece of spectrum analyzer. The communications problem is somewhat random in occurrence, and I thought I had it corrected. The fix I tried was to invoke the CWGPIB.Wait  cwGPIBCMPL command, but it doesn't actually seem to work. I feel it is an issue with the card sending the information. After setting the error messages to verbose on the spectrum analyzer, I am getting messages like this:
 
"Suffix not allowed, SENS:SWE: POIN 8SENS<Err>:BAND:RES:AUTO OFF"
 
In my code I had the following writes:
"SENS:SWE: POIN 8000"
"SENS:BAND:RES:AUTO OFF"
 
This is during a settings change on the analyzer.
 
The actual code for one of the routines used for this, specifically SetSweepPoints, looks like this:
 
Public Sub SetSweepPoints(intSweepPoints As Integer)
    Dim strSweepPoints As String
    If mintSweepPoints = intSweepPoints Then Exit Sub ' already set
   
    If intSweepPoints < 0 Or intSweepPoints > 8000 Then
        MsgBox "Invalid value passed to E4402B class SetSweepPointsRoutine. Valid values from 0 to 8000." _
        & vbNewLine & "No setting will be sent to E4402B at this time.", vbOKOnly + vbCritical, "Program Error"
        Exit Sub
    End If
    mGPIBControl.Wait cwGPIBCMPL
    mGPIBControl.Write _
        "SENS:SWE: POIN " & CStr(intSweepPoints)
   
    mintSweepPoints = intSweepPoints
End Sub
 
Since the message is getting cut off to the spec an, I don't see where polling the configuration register for status will help. What do I need to do? I've considered using the SRQ line, but have not used it before. Would the spec an send a command once it's processed the command sent by the GPIB card? What do I need to do to enable this feature?
 
Thanks,
Tom
 
Note: I had to add a space after the ":" prior to the "P" or I would get the smiley face with tongue : P 😛  The code does not have this space in it.

Message Edited by tbihn on 08-12-2005 06:21 AM

0 Kudos
Message 1 of 4
(6,411 Views)

Hi Tom!
One thing you can try is to find your GPIB device in Measurement and Automation Explorer (MAX), scan for instruments, and try to communicate with the instrument directly.  This will bypass the software, so if your card is truly having trouble sending the information as you suspect, you should see communication problems here too.  If it does communicate through MAX, then there is a conflict with the software or code you are using.  If it doesn't work, this does not Did this code ever work before or is it a new program?  From the message you have pasted, it looks like it is cutting off the "000" on the 8000.  I am not sure how your instruments works, but it may be looking for a "0" as an end of line/string, so it cuts off the rest of the command.  Does the SENS:SWE... command work with another number that does not include "0"?  Another thing you can try is to open NI Spy before you open and start your program.  It sometimes displays the EOS/EOI that is expected, so you can check it here.  You may also try your commands using the Interactive Control.  Click on the link for more information.  If you are still having difficulty, just let me know and I will look into it further.  I saw your other post and will respond to it with some additional information for you soon.  Best of luck to you and again, let me know if you have any more questions!

Chris R.
Applications Engineer
National Instruments

 

Chris R.
Applications Engineer
National Instruments
0 Kudos
Message 2 of 4
(6,387 Views)
Thanks for the information. After posting this, I went back and tried some different things, including updating the drivers. It looks like you were on to something when you pointed at the "0" as a possible EOS character. EOS had been enabled and was set to "0", although, I would've expected this to be a null and not ASCII 48. I also disabled the Assert EOS with EOI... Basically, I took the card settings back to default and it seems to be humming along again. I'm not quite sure why it worked well until know, as I had not messed too much with the settings.
 
Other than that, do you have any recommendations for getting the fastest reliable communications with instrumentation connected to the PCIGPIB card? In our code, we create a control array, assigning a seperate GPIB control (mainly for the primary and secondary address differences) for each instrument. I've added CWGPIB.Wait cwGPIBCMPL just before any write to or read from the instrument. I've also added a CWGPIB.Wait cwGPIBEND after reads where the instrument asserts EOI. Is there anything else I can do to actively wait for instrumentation to complete operations (without adding fixed time-delays)?
 
My instrumentation in the current system I'm working on is : Two Agilent E4402B Spec An.'s (could grow to 4), 4 Agilent 66103A power supplies in a 661000 mainfraim, an Agilent 34970A.
 
Thanks again.
 
Tom
0 Kudos
Message 3 of 4
(6,385 Views)

Hi Tom,
You should be able to use polling, which is already built into the driver.  The card will receive a notification that something is ready to receive/send data and it will poll each instrument to find out which one it is.  There is no wait needed.  I found a a few KnowledgeBases and Tutorials on polling that may help you: Service Request and Serial Polling, Serial Polling and SRQ Servicing, and Serial, GPIB, and Serial Communication.  I searched for "poll" within the documents and found some information on polling.  I hope this helps, but if not, please let me know and I will look into it further for you.  Best of luck and have a great day!

Chris R.
Applications Engineer
National Instruments

Chris R.
Applications Engineer
National Instruments
0 Kudos
Message 4 of 4
(6,357 Views)