AnsweredAssumed Answered

DSO-X 3014: Switching from Remote to normal control

Question asked by rudolfsprik on Aug 28, 2012
Latest reply on Aug 30, 2012 by algoss

Like • Show 0 Likes0
Comment • 3

When controlling a DSO-X 3014a through e.g. USB it sometimes remains in the remote control mode and
all buttons on the front of the instrument are not responsive.
This can happen due to e.g. an error in the control software during development.

Is there a way to force the instrument from remote to normal control without having to switch it on and off ?

No one else has this question

Outcomes

3 Replies

algoss Aug 28, 2012 5:06 AM
Mark Correct
Correct Answer
The short answer is, "Probably not."

The scope shouldn't lock up like this. The front panel should always be active, even while under remote control, unless you have sent a ":SYS:LOCK ON" command. If you use that command, the front panel is locked until you unlock it with ":SYS:LOCK OFF", or reboot the scope. If yu send that command, then lose control of the scope, the power button is the only solution.

If you are sending some other commend sequence that is locking the scope up, then it might help Agilent if you could identify that command sequence and pass it on to us.

Also, please make sure that your scope has the latest firmware, V 2.12.

Al
Like • Show 0 Likes0
Actions
- rudolfsprik @ algoss on Aug 29, 2012 8:17 AM
  Mark Correct
  Correct Answer
  Al,
  Thanks for the fast response.
  
  The firmware version on the DSO-X is 2.12.
  So should be ok.
  My instruments includes WAVEGEN and DVM modules.
  
  The error and lock-up occurs using Labview 2011 SP1 and the NI issued driver/software for the DSO-X 2000 and 3000 series.
  Communication through Test and Measurment interface and also some simple init and exit (see enclosed vi showing the firmware and driver details) works.
  The standard examples that come with the drivers such as e.g. the Acquire Waveform vi hang up and lockout the scope.
  E.g. a time out in the acquisition because of trigger conditions terminates the vi, but leaves the scope in an unaccessible mode.
  
  I guess this is more an issue for the Labview driver developers, but nevertheless hanging the instrument and having to reboot is awkward ...
  Overruling this with e.g. the back-button on the front of the instrument could be very useful.
  
  Best,
  Rudolf Sprik
  Attachments
  - testdsox.vi13.1 KB
  Like • Show 0 Likes0
  Actions
  - algoss @ rudolfsprik on Aug 30, 2012 4:52 AM
    Mark Correct
    Correct Answer
    > The standard examples that come with the drivers such as e.g. the Acquire Waveform vi hang up and lockout the scope.
    > E.g. a time out in the acquisition because of trigger conditions terminates the vi, but leaves the scope in an unaccessible mode.
    >
    > I guess this is more an issue for the Labview driver developers, but nevertheless hanging the instrument and having to reboot is awkward ...
    I agree that scope should not hang, but then it may not be hung, just not reacting to the front panel. The only thing I can think of is that they are locking the front panel, either accidentally, or on purpose, then they have a failure of some sort, leaving it locked. Without looking at the commands that are sent to the scope, there's just no way to know.
    Many development environments have a way to set up a command log, so you can see what commands are being sent to the device. I might suggest turning that on, if possible, or stepping through the code to see what it's doing. You should also be in touch with the NI people.
    
    > Overruling this with e.g. the back-button on the front of the instrument could be very useful.
    If this is really caused by the SW turning off the front panel, then having an override would defeat the purpose of doing that. If it's a scope problem, then what you are talking about would be some sort of NMI. To be sure it would always work, it would probably have to have the same effect as turning the scope off and back on.
    
    Al
    Like • Show 0 Likes0
    Actions

DSO-X 3014: Switching from Remote to normal control

Outcomes

Attachments

Related Content

Recommended Content