McDermott-Group / servers

Public repo that stores LabRAD servers and other non-measurement related code
0 stars 2 forks source link

SIM921 AC Bridge server sometimes fricks out when the GPIB bus is being refreshed #81

Open patzinak opened 7 years ago

patzinak commented 7 years ago

Below is the LabRAD node log:

2016-09-11 00:55:44-0500 [-] SIM900 mcd-adr3 GPIB Bus - GPIB0::2::INSTR::SIM900::4 device name: 'STANFORD_RESEARCH_SYSTEMS'
2016-09-11 00:55:44 - labrad.gpib_device_manager: 2016-09-11 00:55:44-0500 [-] SIM900 mcd-adr3 GPIB Bus - GPIB0::2::INSTR::SIM900::5 'ID?' response: 'Stanford_Research_Systems,SIM928,s/n016863,ver2.2'

2016-09-11 00:55:44-0500 [-] SIM900 mcd-adr3 GPIB Bus - GPIB0::2::INSTR::SIM900::5 device name: 'STANFORD_RESEARCH_SYSTEMS'
2016-09-11 00:55:44 - labrad.gpib_device_manager: 2016-09-11 00:55:44-0500 [-] SIM900 mcd-adr3 GPIB Bus - GPIB0::2::INSTR::SIM900::3 'OI' response: 'Stanford_Research_Systems,SIM922,s/n012870,ver2.70'

2016-09-11 00:55:44-0500 [-] SIM900 mcd-adr3 GPIB Bus - GPIB0::2::INSTR::SIM900::3 device name: 'Stanford_Research_Systems,SIM922,s/n012870,ver2.70'
2016-09-11 00:55:45 - labrad.mcd_adr3_gpib_bus: 2016-09-11 00:55:45-0500 [-] No response from GPIB0::2::INSTR to 'OI'
2016-09-11 00:55:45 - labrad.ac_bridge_with_multiplexer: 2016-09-11 00:55:45-0500 [-] Unhandled error in Deferred:

2016-09-11 00:55:45-0500 [-] Unhandled Error

    Traceback (most recent call last):

    Failure: labrad.types.Error: (0) [SIM921] Remote Traceback (most recent call last):

      File "C:\Python27\lib\site-packages\twisted\internet\defer.py", line 1128, in _inlineCallbacks

        result = g.send(result)

      File "sim_921_ac_bridge.py", line 56, in getRuoxTemperature

        dev = self.selectedDevice(c)

      File "C:\Python27\lib\site-packages\labrad\gpib.py", line 333, in selectedDevice

        raise errors.NoDevicesAvailableError()

    labrad.errors.NoDevicesAvailableError: (0) No devices are available. [payload=None]

     [payload=None]
2016-09-11 00:56:38 - labrad.gpib_device_manager: 2016-09-11 00:56:38-0500 [-] Device Disconnect: mcd-adr3 GPIB Bus GPIB0::2::INSTR

2016-09-11 00:56:38-0500 [-] Sending message: 7 (7L, 0L) [(21436587L, ('STANFORD RESEARCH SYSTEMS SIM900', 'mcd-adr3 GPIB Bus', 'GPIB0::2::INSTR', False))]

2016-09-11 00:56:38-0500 [-] Device Disconnect: mcd-adr3 GPIB Bus GPIB0::5::INSTR

2016-09-11 00:56:38-0500 [-] Sending message: 8 (8L, 0L) [(21436587L, ('HEWLETT-PACKARD 6641A', 'mcd-adr3 GPIB Bus', 'GPIB0::5::INSTR', False))]

2016-09-11 00:56:38-0500 [-] Device Disconnect: SIM900 mcd-adr3 GPIB Bus - GPIB0::2::INSTR::SIM900::3
roboguy222 commented 7 years ago

This seems like an error with the GPIB Device Manager to me.

patzinak commented 7 years ago

Could be... Actually, let me try to explain why I keep running into some errors. Here is a very typical scenario.

  1. Let's assume that ADR3 GUI is up and running normally, no issues, everything looks good and feels responsive. And let's say I'm magging down.
  2. Now, assume I have to use a network analyzer that hasn't been yet plugged to the GPIB bus. So, I connect the network analyzer to the GPIB bus with a cable and turn the analyzer on.
  3. What should I do next? The safest way of doing this that I am aware of is the following. (a) Stop magging up. (b) Close the GUI, the LabRAD manager and all servers. (c) Restart the ADR3 GUI. If any GPIB device statuses are not green, repeat (a)-(c) until everything works. (d) Start the network analyzer server.

Somehow, I'm not that successful, if I don't stop the magging down (once saw a pretty scary back EMF), if I try to restart the GPIB bus server/manager with the node, or press "Refresh Devices",

If the "safest" solution above is indeed what we should be doing, I fine with it. We just have to document it explicitly in ./adr/readme.md.

roboguy222 commented 7 years ago

I'll check this out, but the refresh devices button should work ok.

The larger problem that falls under this same title, is that every once in a while the FAA and GGG temperatures stop being monitored when we are running scans, and the temperatures just get stuck. I found out today that this is due to the AC bridge returning a non-parsable temperature string. Unfortunately, I think it keeps giving that string from then on, and the only way I have found to fix it is to power cycle the device. Not sure how we should address this problem or what is causing it.