Add support for Aim-TTi EL302P power supply

[dieselburner]

This PR adds support for the Aim-TTi EL302P power supply:

• Add a class which supports all instrument commands
• Implement test suite
• Update documentation

[dieselburner]

Side note - this particular instrument communication is very unstable. I'm not sure whether this is just my unit, or it's some sort of generic issue, but during my tests I often see some garbage being prefixed to the data coming from the unit, which leads to following:

$ ./el302p-test 
Traceback (most recent call last):
  File "/home/xxx/temp/ik/./el302p-test", line 7, in <module>
    print(psu.name)
  File "/home/xxx/ik/src/instruments/aimtti/aimttiel302p.py", line 166, in name
    idn_string = self.query("*IDN?")
  File "/home/xxx/ik/src/instruments/abstract_instruments/instrument.py", line 132, in query
    value = self._file.query(cmd, size)
  File "/home/xxx/ik/src/instruments/abstract_instruments/comm/abstract_comm.py", line 232, in query
    resp = self._query(msg, size)
  File "/home/xxx/ik/src/instruments/abstract_instruments/comm/serial_communicator.py", line 207, in _query
    return self.read(size)
  File "/home/xxx/ik/src/instruments/abstract_instruments/comm/abstract_comm.py", line 199, in read
    return self.read_raw(size).decode(encoding)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xfe in position 0: invalid start byte

I get this error in about 70% of all executions of this script:

#!/usr/bin/env python3

import instruments as ik

psu = ik.aimtti.AimTTiEL302P.open_serial("/dev/ttyUSB1")

print(psu.name)
print(psu.current)
print(psu.voltage)
print(psu.output)

Otherwise, I have tested this unit and apart from communication issue described above I haven't noticed anything else.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.19%. Comparing base (de3c700) to head (6a6317e).
⚠️ Report is 16 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #447   +/-   ##
=======================================
  Coverage   99.19%   99.19%           
=======================================
  Files          94       95    +1     
  Lines        9561     9596   +35     
=======================================
+ Hits         9484     9519   +35     
  Misses         77       77           

Flag	Coverage Δ
unittests	99.19% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[trappitsch]

Cool!

I get this error in about 70% of all executions of this script:

Two ideas that might be interesting to test - I had a quick look at what I hope is the manual for the device here:

• The manual states:

  After a command has been sent the controller must wait at least 10ms from the command
  terminator before the next command (or query) is started, to allow the instrument to clear the
  input buffer

  This seems really long to me, but could maybe actually explain your behavior. Maybe put some sleeps into your test script and see what happens?

• Instrumentkit sets the terminator for serial comms by default to "\n", see here. However, according to the manual for your device (well, I hope it's the right one...) the terminator should be "\r\n". Might be worth trying to see if it gets any better.

Edit: Actually reading the manual closer, it seems like the commands to send should be terminated with "\n" and the received ones with "\r\n", which seems strange. I would try both terminators to see what happens. Manuals are notoriously full of errors...

[dieselburner]

This seems really long to me, but could maybe actually explain your behavior. Maybe put some sleeps into your test script and see what happens?

The same issue happens even if I add a 1 second delay between queries.

Actually reading the manual closer, it seems like the commands to send should be terminated with "\n" and the received ones with "\r\n", which seems strange. I would try both terminators to see what happens. Manuals are notoriously full of errors...

EL302P accepts both \r\n and \n endings on its input. I left default input terminator \n as per datasheet. But yes, the unit replies with \r\n termination.

[dieselburner]

I did some additional communication tests and I'm sure it's the faulty unit. Or serial adapter misbehaving with 9600 baud, since it works just fine with other device on 115200. Or maybe some grounding issue. Or maybe all of this.

This is the test I did on a command line without python involved at all:

Console 1:

$ stty -F /dev/ttyUSB1 9600 raw
$ cat /dev/ttyUSB1 | xxd -c 1

Console 2:

$ watch -n1 "echo 'V?' > /dev/ttyUSB1"

Console 1 output shows there's garbage every now and then in first byte of a reply coming from the unit:

00000000: 5f  _ # NOT OK
00000001: 20   
00000002: 32  2
00000003: 34  4
00000004: 2e  .
00000005: 30  0
00000006: 30  0
00000007: 0d  .
00000008: 0a  .
00000009: 56  V # OK
0000000a: 20   
0000000b: 32  2
0000000c: 34  4
0000000d: 2e  .
0000000e: 30  0
0000000f: 30  0
00000010: 0d  .
00000011: 0a  .
00000012: 56  V # OK
00000013: 20   
00000014: 32  2
00000015: 34  4
00000016: 2e  .
00000017: 30  0
00000018: 30  0
00000019: 0d  .
0000001a: 0a  .
0000001b: 56  V # OK
0000001c: 20   
0000001d: 32  2
0000001e: 34  4
0000001f: 2e  .
00000020: 30  0
00000021: 30  0
00000022: 0d  .
00000023: 0a  .
00000024: 56  V # OK
00000025: 20   
00000026: 32  2
00000027: 34  4
00000028: 2e  .
00000029: 30  0
0000002a: 30  0
0000002b: 0d  .
0000002c: 0a  .
0000002d: 57  W # NOT OK
0000002e: 20   
0000002f: 32  2
00000030: 34  4
00000031: 2e  .
00000032: 30  0
00000033: 30  0
00000034: 0d  .
00000035: 0a  .

That said, I think this MR is fine, but my unit (or setup) is not.

[scasagrande]

looks great! I'm sure there is some minor things that will need to be tweaked, but lets get this moving

sorry for the delay