Difference: NevisLabsELogJune2021 (1 vs. 11)

Revision 112021-06-28 - LaurelCarpenter

Line: 1 to 1
 
META TOPICPARENT name="NevisLabsELog"

June 2021 eLog

2021-06-28

Author: Colin

  • Tested remotely:
Changed:
<
<
>
>
 
    • It works now? Don't really understand why this wasn't working last Thursday, but w/e
Added:
>
>
Author: Laurel
  • Encountered same problem as Colin on 2021-06-14, with double PSU (/dev/ttyACM1) this time
    • confusing, because we added the following line to /etc/udev/rules.d/serial-ports.rules on Thursday, which should have resolved this?
      • KERNEL=="ttyACM0", MODE="0666"
    • I tried restarting again, and then it worked... maybe multiple restarts is for some reason necessary to actually update serial-ports.rules? weird
  • I'm wondering if maybe it would be best to assign the mode based on symlink as opposed to kernel, in the case that the PSU's are connected to different kernels (i.e. different usb ports), like so:
    • ATTRS{idProduct}=="049c", MODE="0666", SYMLINK+="psu1"
    • ATTRS{idProduct}=="0460", MODE="0666", SYMLINK+="psu2"
    • but for now this doesn't seem necessary
 

2021-06-24

Author: Colin, Laurel

Line: 18 to 27
 
    • > rm.list_resources()
  • The small PSU is currently on ASRL/dev/ttyACM0::INSTR
    • Which is apparently shortened to: /dev/ttyACM0
Changed:
<
<
  • Following directions at this link: https://msadowski.github.io/linux-static-port/
>
>
  • Following directions at this link: https://msadowski.github.io/linux-static-port/
 
  • We ran
    • SINGLE PSU: udevadm info --name /dev/ttyACM0 --attribute-walk
      • ATTRS{idProduct}=049c (under the second parent device)
    • DOUBLE PSU: udevadm info --name /dev/ttyACM1 --attribute-walk
      • ATTRS{idProduct}=0460 (under the second parent device)
Changed:
<
<
  • Then, like with solution from 6/14/2021 eLog, we added to /etc/udev/rules.d/serial-ports.rules
>
>
  • Then, like with solution from 6/14/2021 eLog, we added to /etc/udev/rules.d/serial-ports.rules
 
    • ATTRS{idProduct}=="049c", SYMLINK+="psu1"
    • ATTRS{idProduct}=="0460", SYMLINK+="psu2"
  • After a restart, these showed up when we ran "ls /dev/psu*"
Line: 54 to 63
 Jun 22 16:59:13 ctalab-Precision-3630-Tower upsmon[14298]: Communications with UPS nevis-ctalab-ups@localhost established
      • Unclear what any of this means
    • Maybe this helps:
Changed:
<
<
      • (Fix, but seems to assume a serial connection) https://www.truenas.com/community/threads/ups-repeatedly-gaining-and-losing-connection-with-server.40532/
>
>
      • (Fix, but seems to assume a serial connection) https://www.truenas.com/community/threads/ups-repeatedly-gaining-and-losing-connection-with-server.40532/
 
      • There's also some documentation of the issue here, potentially as it relates to upssched:
Changed:
<
<
        • https://github.com/networkupstools/nut/issues/219
>
>
        • https://github.com/networkupstools/nut/issues/219
 
        • Unclear if there's actually a resolution here as much as an acknowledgment of the issue.
      • Similar ideas here to make changes to timing things in conf files
Changed:
<
<
        • https://www.truenas.com/community/threads/data-for-ups-is-stale.20898/
        • https://forum.openmediavault.org/index.php?thread/4131-solved-ups-communication-instable/
>
>
        • https://www.truenas.com/community/threads/data-for-ups-is-stale.20898/
        • https://forum.openmediavault.org/index.php?thread/4131-solved-ups-communication-instable/
 
    • Advice from Bill
      • To suppress these messages, you want to edit the file:
        /etc/nut/upsmon.conf
        Do a search on NOTIFYFLAG. You probably want to remove the WALL option from something like:
        NOTIFYFLAG COMMBAD SYSLOG+WALL+EXEC
        Then restart upsmon:
        systemctl restart nut-monitor 
      • Nothing was set by default for NOTIFYFLAG in upsmon.conf
Line: 109 to 118
  File "/home/ctalab/anaconda3/envs/cta/lib/python3.8/site-packages/serial/serialposix.py", line 268, in open raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg)) serial.serialutil.SerialException: [Errno 13] could not open port /dev/ttyACM0: [Errno 13] Permission denied: '/dev/ttyACM0'
Changed:
<
<
    • Going to try and use the second option from this answer on stack overflow: https://stackoverflow.com/a/27886201
>
>
    • Going to try and use the second option from this answer on stack overflow: https://stackoverflow.com/a/27886201
 
      • Added it in at: /etc/udev/rules.d/serial-ports.rules
      • This seems to have resolved the problem
  • Starting to build up the base of the gui at /home/ctalab/software/control_guis/psu_gui.py
Line: 133 to 142
 
  • Replaced U6 with new ADP3338; the power supply immediately reaches compliance, lowering voltage from input 5V to 2V roughly. Also, ADP338 immediately starts heating up, there is still a short somewhere. Check capacitors FC05/6?

Changed:
<
<
-- Massimo Capasso - 2021-06-08
>
>
-- Massimo Capasso - 2021-06-08
 

Comments

Deleted:
<
<
<--/commentPlugin-->
 \ No newline at end of file
Added:
>
>

<--/commentPlugin-->

Revision 102021-06-28 - ColinAdams

Line: 1 to 1
 
META TOPICPARENT name="NevisLabsELog"

June 2021 eLog

Added:
>
>

2021-06-28

Author: Colin

  • Tested remotely:
    • self.aim = AimTTiEL302P('ASRL/dev/psu1::INSTR')
    • It works now? Don't really understand why this wasn't working last Thursday, but w/e
 

2021-06-24

Author: Colin, Laurel

Revision 92021-06-24 - ColinAdams

Line: 1 to 1
 
META TOPICPARENT name="NevisLabsELog"

June 2021 eLog

Added:
>
>

2021-06-24

Author: Colin, Laurel

  • We are assigning a static port for each of the PSUs
  • Using python to figure out the ports that each device is connected to
    • python
    • > import visa
    • > rm = visa.ResourceManager()
    • > rm.list_resources()
  • The small PSU is currently on ASRL/dev/ttyACM0::INSTR
    • Which is apparently shortened to: /dev/ttyACM0
  • Following directions at this link: https://msadowski.github.io/linux-static-port/
  • We ran
    • SINGLE PSU: udevadm info --name /dev/ttyACM0 --attribute-walk
      • ATTRS{idProduct}=049c (under the second parent device)
    • DOUBLE PSU: udevadm info --name /dev/ttyACM1 --attribute-walk
      • ATTRS{idProduct}=0460 (under the second parent device)
  • Then, like with solution from 6/14/2021 eLog, we added to /etc/udev/rules.d/serial-ports.rules
    • ATTRS{idProduct}=="049c", SYMLINK+="psu1"
    • ATTRS{idProduct}=="0460", SYMLINK+="psu2"
  • After a restart, these showed up when we ran "ls /dev/psu*"
  • However, there's something about using the specific ASRL*::INSTR names from the VISA manager library thing that means this isn't the full solution.. So need to think about this some more.
 

2021-06-22

Author: Colin

Line: 105 to 127
 
  • Replaced U6 with new ADP3338; the power supply immediately reaches compliance, lowering voltage from input 5V to 2V roughly. Also, ADP338 immediately starts heating up, there is still a short somewhere. Check capacitors FC05/6?

Changed:
<
<
-- Massimo Capasso - 2021-06-08
>
>
-- Massimo Capasso - 2021-06-08
 

Comments

Revision 82021-06-23 - ColinAdams

Line: 1 to 1
 
META TOPICPARENT name="NevisLabsELog"

June 2021 eLog

2021-06-22

Author: Colin

Changed:
<
<
  • When logging into odo remotely, getting these warnings about nut ad infinatum
>
>
  • When logging into odo remotely, getting these warnings about nut ad infinitum
 
    • Broadcast message from nut@ctalab-Precision-3630-Tower (somewhere) (Tue Jun 22
      
      Communications with UPS nevis-ctalab-ups@localhost lost
Line: 26 to 26
 Jun 22 16:59:13 ctalab-Precision-3630-Tower upsmon[14298]: Communications with UPS nevis-ctalab-ups@localhost established
      • Unclear what any of this means
    • Maybe this helps:
Changed:
<
<
>
>
      • (Fix, but seems to assume a serial connection) https://www.truenas.com/community/threads/ups-repeatedly-gaining-and-losing-connection-with-server.40532/
      • There's also some documentation of the issue here, potentially as it relates to upssched:
        • https://github.com/networkupstools/nut/issues/219
        • Unclear if there's actually a resolution here as much as an acknowledgment of the issue.
      • Similar ideas here to make changes to timing things in conf files
        • https://www.truenas.com/community/threads/data-for-ups-is-stale.20898/
        • https://forum.openmediavault.org/index.php?thread/4131-solved-ups-communication-instable/
    • Advice from Bill
      • To suppress these messages, you want to edit the file:
        /etc/nut/upsmon.conf
        Do a search on NOTIFYFLAG. You probably want to remove the WALL option from something like:
        NOTIFYFLAG COMMBAD SYSLOG+WALL+EXEC
        Then restart upsmon:
        systemctl restart nut-monitor 
      • Nothing was set by default for NOTIFYFLAG in upsmon.conf
        • However, it says that the default behavior is that
          • "upsmon sends walls (global messages to all logged in users) and writes to the syslog when things happen. You can change this."
        • So I modified the file to say:
          • NOTIFYFLAG COMMBAD SYSLOG
        • The syslog appears to be located at /var/log/syslog
      • I restarted nut-monitor
      • Now am keeping an eye on /var/log/syslog with tail -f
        • It hasn't reported any stale data or lost connections yet, so I'm not thinking I should have seen anything in the "WALL" yet, but at the very least no notifications have shown up at the wall for the time being.
        • Looks like this was part of the way successful, got rid of the connection lost notification, but not the connection established ones
        • Modified /etc/nut/upsmon.conf now to include the line:
          • NOTIFYFLAG COMMOK SYSLOG
        • this looks like it fixed it entirely
 

2021-06-14

Line: 85 to 105
 
  • Replaced U6 with new ADP3338; the power supply immediately reaches compliance, lowering voltage from input 5V to 2V roughly. Also, ADP338 immediately starts heating up, there is still a short somewhere. Check capacitors FC05/6?

Changed:
<
<
-- Massimo Capasso - 2021-06-08
>
>
-- Massimo Capasso - 2021-06-08
 

Comments

Revision 72021-06-23 - ColinAdams

Line: 1 to 1
 
META TOPICPARENT name="NevisLabsELog"

June 2021 eLog

2021-06-22

Line: 25 to 25
 Jun 22 16:59:08 ctalab-Precision-3630-Tower upsmon[14298]: Communications with UPS nevis-ctalab-ups@localhost lost Jun 22 16:59:13 ctalab-Precision-3630-Tower upsmon[14298]: Communications with UPS nevis-ctalab-ups@localhost established
      • Unclear what any of this means
Added:
>
>
 

2021-06-14

Revision 62021-06-22 - ColinAdams

Line: 1 to 1
 
META TOPICPARENT name="NevisLabsELog"

June 2021 eLog

Added:
>
>

2021-06-22

Author: Colin

  • When logging into odo remotely, getting these warnings about nut ad infinatum
    • Broadcast message from nut@ctalab-Precision-3630-Tower (somewhere) (Tue Jun 22
      
      Communications with UPS nevis-ctalab-ups@localhost lost
      
      
      Broadcast message from nut@ctalab-Precision-3630-Tower (somewhere) (Tue Jun 22
      
      Communications with UPS nevis-ctalab-ups@localhost established
    • When I run 'systemctl status nut-monitor.service', I get back:
      • Jun 22 16:57:18 ctalab-Precision-3630-Tower upsmon[14298]: Poll UPS [nevis-ctalab-ups@localhost] failed - Data stale
        Jun 22 16:57:23 ctalab-Precision-3630-Tower upsmon[14298]: Communications with UPS nevis-ctalab-ups@localhost established
        Jun 22 16:58:03 ctalab-Precision-3630-Tower upsmon[14298]: Poll UPS [nevis-ctalab-ups@localhost] failed - Data stale
        Jun 22 16:58:03 ctalab-Precision-3630-Tower upsmon[14298]: Communications with UPS nevis-ctalab-ups@localhost lost
        Jun 22 16:58:08 ctalab-Precision-3630-Tower upsmon[14298]: Poll UPS [nevis-ctalab-ups@localhost] failed - Data stale
        Jun 22 16:58:13 ctalab-Precision-3630-Tower upsmon[14298]: Poll UPS [nevis-ctalab-ups@localhost] failed - Data stale
        Jun 22 16:58:18 ctalab-Precision-3630-Tower upsmon[14298]: Communications with UPS nevis-ctalab-ups@localhost established
        Jun 22 16:59:08 ctalab-Precision-3630-Tower upsmon[14298]: Poll UPS [nevis-ctalab-ups@localhost] failed - Data stale
        Jun 22 16:59:08 ctalab-Precision-3630-Tower upsmon[14298]: Communications with UPS nevis-ctalab-ups@localhost lost
        Jun 22 16:59:13 ctalab-Precision-3630-Tower upsmon[14298]: Communications with UPS nevis-ctalab-ups@localhost established
      • Unclear what any of this means
 

2021-06-14

Author: Colin

Line: 33 to 59
  File "/home/ctalab/anaconda3/envs/cta/lib/python3.8/site-packages/serial/serialposix.py", line 268, in open raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg)) serial.serialutil.SerialException: [Errno 13] could not open port /dev/ttyACM0: [Errno 13] Permission denied: '/dev/ttyACM0'
Changed:
<
<
>
>
    • Going to try and use the second option from this answer on stack overflow: https://stackoverflow.com/a/27886201
 
      • Added it in at: /etc/udev/rules.d/serial-ports.rules
      • This seems to have resolved the problem
  • Starting to build up the base of the gui at /home/ctalab/software/control_guis/psu_gui.py
Line: 57 to 83
 
  • Replaced U6 with new ADP3338; the power supply immediately reaches compliance, lowering voltage from input 5V to 2V roughly. Also, ADP338 immediately starts heating up, there is still a short somewhere. Check capacitors FC05/6?

Changed:
<
<
-- Massimo Capasso - 2021-06-08
>
>
-- Massimo Capasso - 2021-06-08
 

Comments

Revision 52021-06-22 - ColinAdams

Line: 1 to 1
 
META TOPICPARENT name="NevisLabsELog"

June 2021 eLog

2021-06-14

Line: 36 to 36
 
    • Going to try and use the second option from this answer on stack overflow: https://stackoverflow.com/a/27886201
      • Added it in at: /etc/udev/rules.d/serial-ports.rules
      • This seems to have resolved the problem
Changed:
<
<
  • Starting to build up the base of the gui at /home/ctalab/software/control_guis/obj_flasher_gui.py
>
>
  • Starting to build up the base of the gui at /home/ctalab/software/control_guis/psu_gui.py
 

2021-06-10

Author: Massimo

Revision 42021-06-14 - ColinAdams

Line: 1 to 1
 
META TOPICPARENT name="NevisLabsELog"

June 2021 eLog

Added:
>
>

2021-06-14

Author: Colin

  • Encountering once again the same issues from the 2021-01-20 eLog.
    • Traceback (most recent call last):
        File "/home/ctalab/anaconda3/envs/cta/lib/python3.8/site-packages/serial/serialposix.py", line 265, in open
          self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
      PermissionError: [Errno 13] Permission denied: '/dev/ttyACM0'
      
      During handling of the above exception, another exception occurred:
      
      Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
        File "/home/ctalab/anaconda3/envs/cta/lib/python3.8/site-packages/dcps/SCPI.py", line 69, in open
          self._inst = self._rm.open_resource(self._resource,
        File "/home/ctalab/anaconda3/envs/cta/lib/python3.8/site-packages/pyvisa/highlevel.py", line 1771, in open_resource
          res.open(access_mode, open_timeout)
        File "/home/ctalab/anaconda3/envs/cta/lib/python3.8/site-packages/pyvisa/resources/resource.py", line 218, in open
          self.session, status = self._resource_manager.open_bare_resource(self._resource_name, access_mode, open_timeout)
        File "/home/ctalab/anaconda3/envs/cta/lib/python3.8/site-packages/pyvisa/highlevel.py", line 1725, in open_bare_resource
          return self.visalib.open(self.session, resource_name, access_mode, open_timeout)
        File "/home/ctalab/anaconda3/envs/cta/lib/python3.8/site-packages/pyvisa-py/highlevel.py", line 194, in open
          sess = cls(session, resource_name, parsed, open_timeout)
        File "/home/ctalab/anaconda3/envs/cta/lib/python3.8/site-packages/pyvisa-py/sessions.py", line 218, in __init__
          self.after_parsing()
        File "/home/ctalab/anaconda3/envs/cta/lib/python3.8/site-packages/pyvisa-py/serial.py", line 65, in after_parsing
          self.interface = cls(port=self.parsed.board, timeout=self.timeout, write_timeout=self.timeout)
        File "/home/ctalab/anaconda3/envs/cta/lib/python3.8/site-packages/serial/serialutil.py", line 240, in __init__
          self.open()
        File "/home/ctalab/anaconda3/envs/cta/lib/python3.8/site-packages/serial/serialposix.py", line 268, in open
          raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg))
      serial.serialutil.SerialException: [Errno 13] could not open port /dev/ttyACM0: [Errno 13] Permission denied: '/dev/ttyACM0'
    • Going to try and use the second option from this answer on stack overflow: https://stackoverflow.com/a/27886201
      • Added it in at: /etc/udev/rules.d/serial-ports.rules
      • This seems to have resolved the problem
  • Starting to build up the base of the gui at /home/ctalab/software/control_guis/obj_flasher_gui.py
 

2021-06-10

Author: Massimo

Revision 32021-06-10 - MassimoCapasso

Line: 1 to 1
 
META TOPICPARENT name="NevisLabsELog"

June 2021 eLog

Changed:
<
<

2021-06-08

>
>

2021-06-10

  Author: Massimo
Changed:
<
<
  • Replaced U6 with new ADP3338; the power supply immediately reaches compliance, lowering voltage from input 5V to 2V roughly. Also, ADP338 immediately starts heating up, there is still a short somewhere. Check capacitors FC05/6?
>
>
  • Performed a visual inspection with Nancy's microscope of all the components on the board, no apparent signs of broken pieces (cracks, burns...)
  • Talked to Leonardo, neither he nor Francesco L. have any better idea of what could have possibly failed; they'll try to find a spare board, re-program the FPGA and send it to us
 

2021-06-09

Author: Massimo with support from Ray

Line: 14 to 15
 
    • FC01
  • Nothing helped
  • Asked Francesco L. for extra ideas and otherwise for spare board
Added:
>
>

2021-06-08

Author: Massimo

  • Replaced U6 with new ADP3338; the power supply immediately reaches compliance, lowering voltage from input 5V to 2V roughly. Also, ADP338 immediately starts heating up, there is still a short somewhere. Check capacitors FC05/6?

  -- Massimo Capasso - 2021-06-08

Revision 22021-06-09 - MassimoCapasso

Line: 1 to 1
 
META TOPICPARENT name="NevisLabsELog"

June 2021 eLog

2021-06-08

Author: Massimo

Changed:
<
<
  • Replaced U6 with new ADP338; the power supply immediately reaches compliance, lowering voltage from input 5V to 2V roughly. Also, ADP338 immediately starts heating up. Check capacitors FC05/6?
>
>
  • Replaced U6 with new ADP3338; the power supply immediately reaches compliance, lowering voltage from input 5V to 2V roughly. Also, ADP338 immediately starts heating up, there is still a short somewhere. Check capacitors FC05/6?

2021-06-09

Author: Massimo with support from Ray

  • We replaced the ADP3338 again, but there still is a short between Vout (which should be 3.3V) and ground. We then removed the ADP3338 and checked (short still there) the first immediate components downstream of the 3.3V
    • FC06
    • U3
    • FC01
  • Nothing helped
  • Asked Francesco L. for extra ideas and otherwise for spare board
 -- Massimo Capasso - 2021-06-08

Comments

Revision 12021-06-08 - MassimoCapasso

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="NevisLabsELog"

June 2021 eLog

2021-06-08

Author: Massimo

  • Replaced U6 with new ADP338; the power supply immediately reaches compliance, lowering voltage from input 5V to 2V roughly. Also, ADP338 immediately starts heating up. Check capacitors FC05/6?
-- Massimo Capasso - 2021-06-08

Comments

<--/commentPlugin-->
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback