Presently, I'm working in a Jupyter notebook, Python 3.9. I have the library import and pstat definition in a separate cell to avoid re-running them. Starting with a fresh kernel, I get the following error:
File c:\Users\rlesuer\OneDrive - SUNY - The College at Brockport\Documents\GitHub\pstat.venv\lib\site-packages\potentiostat\potentiostat.py:306, in Potentiostat.set_param(self, testname, param)
295 """Sets the parameters for the specified voltammetric test.
296297 Args:
(...)
303304 """
305 cmd_dict = {CommandKey: SetParamCmd, TestKey: testname, ParamKey: param}
--> 306 msg_dict = self.send_cmd(cmd_dict)
307 return msg_dict[ResponseKey][ParamKey]
File c:\Users\rlesuer\OneDrive - SUNY - The College at Brockport\Documents\GitHub\pstat.venv\lib\site-packages\potentiostat\potentiostat.py:1065, in Potentiostat.send_cmd(self, cmd_dict, rsp)
1063 msg_json = self.readline()
...
354 except StopIteration as err:
--> 355 raise JSONDecodeError("Expecting value", s, err.value) from None
356 return obj, end
JSONDecodeError: Expecting value: line 1 column 1 (char 0)
Setting t1 and t2 to 1000 does not throw this error. Without refreshing the kernel, if I change t1 and t2 to 10000, the error is thrown. If I run the same cell again, without changing t1 and t2, odict now reports the correct times and voltages for the multistep. However, there seems to be a communication problem, because trying to run the test with t, v, i = pstat.run_test('multiStep') throws this error:
OSError Traceback (most recent call last)
Cell In[7], line 1
----> 1 t, v, i = pstat.run_test('multiStep')
File c:\Users\rlesuer\OneDrive - SUNY - The College at Brockport\Documents\GitHub\pstat.venv\lib\site-packages\potentiostat\potentiostat.py:929, in Potentiostat.run_test(self, testname, param, filename, on_data, display, timeunit, max_decode_err)
927 channel_list = [0]
928 if self.firmware_version >= MinimumFirmwareVersionForMux:
--> 929 mux_enabled = self.get_mux_enabled()
930 if mux_enabled:
931 channel_list = self.get_enabled_mux_channels()
File c:\Users\rlesuer\OneDrive - SUNY - The College at Brockport\Documents\GitHub\pstat.venv\lib\site-packages\potentiostat\potentiostat.py:743, in Potentiostat.get_mux_enabled(self)
736 """Get multiplexer expansion hardware enabled state
737738 Returns:
739 bool: enable state of mux hardware (from device), True/Fasle
740741 """
742 cmd_dict = {CommandKey: GetMuxEnabledCmd}
--> 743 msg_dict = self.send_cmd(cmd_dict)
744 return msg_dict[ResponseKey][MuxEnabledKey]
File c:\Users\rlesuer\OneDrive - SUNY - The College at Brockport\Documents\GitHub\pstat.venv\lib\site-packages\potentiostat\potentiostat.py:1066, in Potentiostat.send_cmd(self, cmd_dict, rsp)
1064 msg_json = msg_json.strip()
...
1118 cmd_recv = msg_dict[ResponseKey][CommandKey]
1119 if cmd_recv != cmd_sent:
-> 1120 raise IOError('command sent, {0}, not same as received, {1}'.format(cmd_sent, cmd_recv))
OSError: command sent, getMuxEnabled, not same as received, setParam
It is also clear that something in the communication with the potentiostat has become un-synced since I have to restart the kernel, try to communicate with the potentiostat only to have it fail, then restart the kernel again to be able to connect to the potentiostat. This behavior also happens for larger quiet times in the square wave test.
The code I would like to run is this:
Presently, I'm working in a Jupyter notebook, Python 3.9. I have the library import and pstat definition in a separate cell to avoid re-running them. Starting with a fresh kernel, I get the following error:
Setting t1 and t2 to 1000 does not throw this error. Without refreshing the kernel, if I change t1 and t2 to 10000, the error is thrown. If I run the same cell again, without changing t1 and t2,
odict
now reports the correct times and voltages for the multistep. However, there seems to be a communication problem, because trying to run the test witht, v, i = pstat.run_test('multiStep')
throws this error:It is also clear that something in the communication with the potentiostat has become un-synced since I have to restart the kernel, try to communicate with the potentiostat only to have it fail, then restart the kernel again to be able to connect to the potentiostat. This behavior also happens for larger quiet times in the square wave test.