AnsweredAssumed Answered

89601B VSA Not responding to SCPI Commands

Question asked by mtanco on Sep 2, 2011
Latest reply on Oct 21, 2013 by dufresne

Like • Show 0 Likes0
Comment • 7

Hello,

I am currently trying to remotely control the VSA 89601B V14.0 (installed in a N9020A MXA) through SCPI commands and LAN.
In my control PC I am using my own VB .NET application to communicate with the box (i.e, not using a local 89601B software).

I have been able to successfully connect to it: I can open Port 5024 and retrieve the software ID string through the *IDN? command.
However there is not much that I can do afterwards. When I send the SCPI command SYST:VSA:STAR, there is a screen appearing in the N9020A stating the following:

This instrument is in use by the Agilent 89601 Vector Signal Analyzer running on host A-N9020A-10271.
To unlock the front panel and allow you to resume local operation, either shut down that application, or disconnect it from this instrument using the
Control->Disconnect menu item.

Additionally, to the right of the screen a label with "Remote VSA" appears as well as a disabled button with the label "Local VSA".

At that point the instrument does not do anything; it does not react to any further SCPI commands, and the VSA software never appears on the screen.

Is there any other thing I need to do in order to use the VSA software remotely? What I am doing wrong? Is there any SCPI command, or list of commands, that I have to send prior to the "SYST:VSA:STAR"? I have checked one example in C# in the Agilent help directory am I have not able to find anything different to what I do.

Your prompt reply would be highly appreciated,
Thanks and best regards
Mario

No one else has this question

Outcomes

tabbott

Sep 2, 2011 12:39 PM

Hi Mario -

This description indicates that the 89600 VSA software is responding to the SCPI commands that are being sent. Please see one of the example proprams provided for an example that makes the VSA software visible.

Regards -

Actions

mtanco Sep 7, 2011 10:20 PM

Hi again,

I finally found what the problem was. It seems that the VSA screen is not visible by default and this has to be explicitly enabled through the corresponding SCPI command. I did it and now it works fine.
Thanks anyway.
Mario

Actions

Sparky Jan 27, 2012 10:37 AM

Is there a known issue with the Translator Framework and 89601B version 14.xx on XSA's using firmware 8.54? I had my labview SCPI commands working and now when ever the program runs TM crashes, also looks like the application is no longer visible, but perhaps the TF has crashed before it processed :DISPlay:ENAB 1. This means I have to log into the MXA, kill the VSA instance, and exit the XSA launcher, selecting local does not revert control. then relaunch the XSA program, run the 89601B select enable SCPI then close the 89601B, restoring the MXA to the ready state for automated scripts.

Here's the error report for the Translator Framework
EventType : clr20r3     P1 : agilent.translator.exe     P2 : 2.0.4164.19642
P3 : 4ddff396     P4 : agilent.cdf.api     P5 : 3.7.14704.10008
P6 : 4d703acd     P7 : 1eb     P8 : 1c3     P9 : system.nullreferenceexception

Also this reveals that we really need away to re launch the TM without having to start the 89601B software, which once launched has to be closed to allow remote control. It'd be great if this were a service with some sort of auto keep alive. Automated scripts will not be able to keep the MXA/89601B software in service when it crashes or locks up (poor error handling).

Actions

Sparky Feb 1, 2012 12:23 PM

I did figure out what was going on:
When sending VSA start command the application would launch but then the scripts would plow on with sending SCPI commands, this would overload something as the application wasn't running yet.
Looping a check of VSA Start query didn't help since VSA start query returns a 1 if the VSA application has been requested to start, regardless of whether or not its ready for SCPI commands.
I had to run a system error query after the launch request and test for the response vsa started but not ready, I.E. error returns anything but 0, loop has a wait of 30 seconds and allows for up to 5 minutes for VSA to get ready for SCPI commands (launched).
I added a check at the start of the vi, a VSA start? query if it returns 1 all other checks are bypassed, but I see that I need to add an error query to insure that the VSA is actually ready for [more] SCPI commands.

If anyone is interested in seeing the 'open VSA' vi let me know I can post it or something (its in LabView 2010 though).

Actions

ww1 @ Sparky on Sep 27, 2012 5:23 PM

Hi
Can you provide the openVSA.vi please? Does it open the software itself?

Thanks.

Actions

Sparky @ ww1 on Oct 18, 2012 4:02 PM

High I just saw your request, I was logging into check on another new issue. I'm not sure if you will want my openvsa.vi.

I've been having lots of trouble keeping our scripts working. Problems using the term character attribute for the vi session, kills read back.

Also I have been experimenting with a method for being able to collect and display the commands being sent to the instruments and unit under test. Thus the two functional globals Full transcript and instrument transcript. Some commands are contrived because they use labview 'intrinsics' like open, clear, close. Actually those might be it.

BTW this is in Labview 2010 service pack 1

Edited by: Sparky on Oct 18, 2012 11:01 PM

Attachments

Actions

dufresne Oct 21, 2013 10:17 AM

I have utliized the ActiveX method in the past, but this is not longer supported on later 89601 SW versions. I have tried to implement SCPI commands using a TCPIP socket, but it fails to be able to read back anything. I am running version 16.0 of 89601B and am able to issue/read back data using the "Interactive IO" tool. When I open a connection using Labview, it fails to be able to read anything back from the instrument. In short, issues are:

1) Do I use a TCPIP open/write/read method, or do I open it as a VISA instrument? I have tried both (neither work)

2) Are there issues with "Agilent.Translator.exe"? Every time this opens up, it ties up the TCPIP port and I have to close Agilent.Translator in Task Manager in order for Labview to be able to see the 89601B SW again.

If there are some working sample codes out there to just set this link up properly, that would help significantly.

Thanks!

Actions

7 Replies

tabbott Sep 2, 2011 12:39 PM
Mark Correct
Correct Answer
Hi Mario -

This description indicates that the 89600 VSA software is responding to the SCPI commands that are being sent. Please see one of the example proprams provided for an example that makes the VSA software visible.

Regards -
Like • Show 0 Likes0
Actions
mtanco Sep 7, 2011 10:20 PM
Mark Correct
Correct Answer
Hi again,

I finally found what the problem was. It seems that the VSA screen is not visible by default and this has to be explicitly enabled through the corresponding SCPI command. I did it and now it works fine.
Thanks anyway.
Mario
Like • Show 0 Likes0
Actions
Sparky Jan 27, 2012 10:37 AM
Mark Correct
Correct Answer
Is there a known issue with the Translator Framework and 89601B version 14.xx on XSA's using firmware 8.54? I had my labview SCPI commands working and now when ever the program runs TM crashes, also looks like the application is no longer visible, but perhaps the TF has crashed before it processed :DISPlay:ENAB 1. This means I have to log into the MXA, kill the VSA instance, and exit the XSA launcher, selecting local does not revert control. then relaunch the XSA program, run the 89601B select enable SCPI then close the 89601B, restoring the MXA to the ready state for automated scripts.

Here's the error report for the Translator Framework
EventType : clr20r3     P1 : agilent.translator.exe     P2 : 2.0.4164.19642
P3 : 4ddff396     P4 : agilent.cdf.api     P5 : 3.7.14704.10008
P6 : 4d703acd     P7 : 1eb     P8 : 1c3     P9 : system.nullreferenceexception

Also this reveals that we really need away to re launch the TM without having to start the 89601B software, which once launched has to be closed to allow remote control. It'd be great if this were a service with some sort of auto keep alive. Automated scripts will not be able to keep the MXA/89601B software in service when it crashes or locks up (poor error handling).
Like • Show 0 Likes0
Actions
Sparky Feb 1, 2012 12:23 PM
Mark Correct
Correct Answer
I did figure out what was going on:
When sending VSA start command the application would launch but then the scripts would plow on with sending SCPI commands, this would overload something as the application wasn't running yet.
Looping a check of VSA Start query didn't help since VSA start query returns a 1 if the VSA application has been requested to start, regardless of whether or not its ready for SCPI commands.
I had to run a system error query after the launch request and test for the response vsa started but not ready, I.E. error returns anything but 0, loop has a wait of 30 seconds and allows for up to 5 minutes for VSA to get ready for SCPI commands (launched).
I added a check at the start of the vi, a VSA start? query if it returns 1 all other checks are bypassed, but I see that I need to add an error query to insure that the VSA is actually ready for [more] SCPI commands.

If anyone is interested in seeing the 'open VSA' vi let me know I can post it or something (its in LabView 2010 though).
Like • Show 0 Likes0
Actions
- ww1 @ Sparky on Sep 27, 2012 5:23 PM
  Mark Correct
  Correct Answer
  Hi
  Can you provide the openVSA.vi please? Does it open the software itself?
  
  Thanks.
  Like • Show 0 Likes0
  Actions
  - Sparky @ ww1 on Oct 18, 2012 4:02 PM
    Mark Correct
    Correct Answer
    High I just saw your request, I was logging into check on another new issue. I'm not sure if you will want my openvsa.vi.
    
    I've been having lots of trouble keeping our scripts working. Problems using the term character attribute for the vi session, kills read back.
    
    Also I have been experimenting with a method for being able to collect and display the commands being sent to the instruments and unit under test. Thus the two functional globals Full transcript and instrument transcript. Some commands are contrived because they use labview 'intrinsics' like open, clear, close. Actually those might be it.
    
    BTW this is in Labview 2010 service pack 1
    
    Edited by: Sparky on Oct 18, 2012 11:01 PM
    Attachments
    89601B_Error_Query.vi25.2 KB
    fg_Instrument_Transcript.vi27.1 KB
    Open_Conneciton_to_89601B.vi62.7 KB
    Read_VISA_Response.vi19.2 KB
    fg_Full_Transcript.vi27.1 KB
    Like • Show 0 Likes0
    Actions
dufresne Oct 21, 2013 10:17 AM
Mark Correct
Correct Answer
I have utliized the ActiveX method in the past, but this is not longer supported on later 89601 SW versions. I have tried to implement SCPI commands using a TCPIP socket, but it fails to be able to read back anything. I am running version 16.0 of 89601B and am able to issue/read back data using the "Interactive IO" tool. When I open a connection using Labview, it fails to be able to read anything back from the instrument. In short, issues are:

1) Do I use a TCPIP open/write/read method, or do I open it as a VISA instrument? I have tried both (neither work)

2) Are there issues with "Agilent.Translator.exe"? Every time this opens up, it ties up the TCPIP port and I have to close Agilent.Translator in Task Manager in order for Labview to be able to see the 89601B SW again.

If there are some working sample codes out there to just set this link up properly, that would help significantly.

Thanks!
Like • Show 0 Likes0
Actions

89601B VSA Not responding to SCPI Commands

Outcomes

Attachments

Related Content

Recommended Content