 Thu Jan 23 15:15:45 2020, Dinko Ferencek, Software, Trimming Vcal value changed from 35 to 40
|
Trimming Vcal value changed from 35 to 40 in the testParameters.dat files stored in
/home/l_tester/L1_SW/pxar/data/tbm10d_procv3/
/home/l_tester/L1_SW/pxar/data/tbm10d_procv3_test/
/home/l_tester/L1_SW/pxar/data/tbm10d_procv4/
/home/l_tester/L1_SW/pxar/data/tbm10d_procv4_test/
This is the value we will use for the FullQualification. |
|
Thu Jan 23 14:54:45 2020, Dinko Ferencek, Cold box tests, Keithley exchanged
|
Yesterday during an attempt to run the FullQualification, elComandante would lose control over Keithley after performing the IV curve measurements and would go in the subsequent Fulltest with HV off. This happened both between the two sets of tests at -20 C and between the tests at -20 C and +10 C. Today we exchanged the old Keithley with a new one and we observe that the communication with this new Keithley is much smoother without any error codes and warning sounds produced by Keithley.
In order to properly communicate with the new Keithley, it was necessary to set its communication mode to RS-232 and BAUD rate to 57600 (https://youtu.be/-5RmguqC7xA). Everything else was left unchanged:
BITS = 8
PARITY = NONE
TERMINATOR = <CR+LF>
FLOW-CRTL = XON-XOFF |
|
Wed Jan 22 11:50:20 2020, Dinko Ferencek, Software, Module configuration files for interactive tests
|
There are two module configuration folders set up for elComandante
/home/l_tester/L1_SW/pxar/data/tbm10d_procv3/
/home/l_tester/L1_SW/pxar/data/tbm10d_procv4/
These folder can also be used for interactive tests with pXar. However, in that case these folders get filled with pxar.log and pxar.root files. For some reason, elComandante when copying the module configuration files also copies all pxar.log files. To prevent unnecessary duplication of junk files, two new module configuration folders were set up for interactive tests with pXar
/home/l_tester/L1_SW/pxar/data/tbm10d_procv3_pxar/
/home/l_tester/L1_SW/pxar/data/tbm10d_procv4_pxar/
The configurations are identical to those used by elComandante. However, one needs to remember to keep the tests folders in sync with the elComandante folders once they get updated. This can be done as follows
rsync -avPSh /home/l_tester/L1_SW/pxar/data/tbm10d_procv3/ /home/l_tester/L1_SW/pxar/data/tbm10d_procv3_pxar/
rsync -avPSh /home/l_tester/L1_SW/pxar/data/tbm10d_procv4/ /home/l_tester/L1_SW/pxar/data/tbm10d_procv4_pxar/
To check if there are any extraneous pXar files present in the configuration folders, run
find /home/l_tester/L1_SW/pxar/data/tbm10d_procv?/ -type f \( -name 'pxar*.log' -o -name 'pxar*.root' \)
If any, they can be deleted by running
find /home/l_tester/L1_SW/pxar/data/tbm10d_procv?/ -type f -name \( -name 'pxar*.log' -o -name 'pxar*.root' \) -delete |
|
Wed Jan 22 11:39:48 2020, Dinko Ferencek, Software, BB2 configuration
|
| When attempting to run the FullQualification this morning, pXar crashed while running the BB2 test. After some investigation, we realized the source of the problem was the BB2 configuration missing from testParameters.dat. The configuration is available in moreTestParameters.dat but by default the mkConfig script does not put it in testParameters.dat. Since we run BB2 in the FullQualification, the configuration needs to be copied by hand every time the configuration files are regenerated. |
Mon Jan 20 21:33:20 2020, Dinko Ferencek, Cold box tests, Latest tests of PH optimization 
|
We did some tests by running the latest version of pXar on modules M1521, M1529, M1534 and M1536, specifically trimming and PH optimization. Of the 4 modules tested, the PH optimization converged only for M1521. We plan to further investigate with Urs' help possible reasons for failed PH optimization.
We also noticed a change in the threshold distribution plot of the latest trim bit test compared to the previous version of the test (see attached plots). |
 Tue Jan 21 12:19:08 2020, Dinko Ferencek, Cold box tests, Latest tests of PH optimization
|
| Dinko Ferencek wrote: | We did some tests by running the latest version of pXar on modules M1521, M1529, M1534 and M1536, specifically trimming and PH optimization. Of the 4 modules tested, the PH optimization converged only for M1521. We plan to further investigate with Urs' help possible reasons for failed PH optimization.
We also noticed a change in the threshold distribution plot of the latest trim bit test compared to the previous version of the test (see attached plots). |
The problem was traced down to a wrong value of the vcallow parameter in the PH optimization configuration. The value was 10 instead of 50 expected by the test. It turned out that the optimization converged for M1521 because this is a PROC600V3 module for which the configuration files were regenerated for another reason and vcallow was consequently set to the right value of 50. The other 3 modules are PROC600V4 modules and for them old configuration files with a wrong vcallow value were used. |
|
Mon Jan 20 18:09:50 2020, Matej Roguljic, General, Activities 20.-31.01.2020.
|
20.01.
Expanded the HDI testing setup to be able to mount wire-bonded HDIs to HDI handles. Tested 12 HDIs (v7.2), all of them passed the tests. HDIs were given to Silvan and are located in the storage box in the assembly lab. They will be used for module production.
21.01.
Tested 4 HDIs, version 7.1. All passed the electrical tests.
Tested 16 v7.2 HDIs. All but one passed the electrical tests.
Glued a protection cap on a pre-production module (M1535).
22.01.
Investigated problems with full qualification setup, narrowed it down to communication between PC and Keithley.
23.01.
Tested 23 HDIs. One failed the test, rest of them passed.
24.01.
Tested 15 HDIs. All of them passed the tests.
Investigated problems with threshold/trim tests in full qualification when going to -20. Suspecting wrong DACs used in the test.
27.01.
Continuing to investigate problems with threshold in trimming procedures. The problem seems to be in the DAC 'ctrlreg' which was set to 17. Setting it to 9 removed the problem for M1529.
28.01.
Confirmed that 'ctrlreg' works also at room +20 degrees. Did reception test on modules 1529, 1536, 1537 and 1538. After this, caps were glued to modules 1537 and 1538. Did fulltest@-20, IV@-20, fullltest@+10 and IV@+10 for modules 1534, 1532, 1529 and 1536.
29.01.
Ran reeption on moules 1539 and 1540. Ran full qualification on modules 1536, 1537, 1538, 1540. Module 1539 turned out to have broken wirebonds on one TBM, reported this to Silvan and he re-bonded it. Assembled a second cap-gluing station. |
|
Wed Nov 27 18:25:08 2019, Dinko Ferencek, Software, pXar code updated
|
pXar code in /home/l_tester/L1_SW/pxar/ on the lab PC was updated on Monday, Nov. 25 from https://github.com/psi46/pxar/tree/e17df08c7bbeb8472e8f56ccd2b9d69a113ccdc3 to https://github.com/psi46/pxar/tree/9c3b81791738e1b8ec7dd9f0d1b68f8800f8416c which pulled in the latest updates to the pulse height optimization test. Today a few remaining updates were pulled in by going to the current HEAD of the master branch https://github.com/psi46/pxar/tree/5d358c5ebbf095a7d118cdde9e1e509c41ccc615.
The sequence of commands to update the code was the following:
cd /home/l_tester/L1_SW/pxar/
git pull origin master
cd build
cmake ..
make -j6 install
|
|
Thu Nov 28 18:34:00 2019, Dinko Ferencek, Software, pXar code updated
|
pXar code updated to the current HEAD of the master branch https://github.com/psi46/pxar/tree/9eb0f3844e9c7f98d7701629c5af339632c5d84a to pick up the latest update that allows running of the fullTest() method of each of the tests from the command line and consequently also from elComandante. |
|
Mon Jan 20 13:47:33 2020, Dinko Ferencek, Software, pXar code updated
|
pXar code updated to the current HEAD of the master branch https://github.com/psi46/pxar/tree/f6e42c17c0bb3a44bdb3fa13d8f8afb6cae62a81 to pick up the latest PH optimization updates. |
|
Mon Dec 2 17:29:06 2019, Andrey Starodumov, Full test, 4 modules FT
|
FullQualification of four modules M1526, M1529, M1521 and M1534 has been done. Full time of the test is about 5.5hrs.
Test included: FT@-20C, IV@-20, 3Cycles from -20C up to +10C, FT@10C and IV@10C.
Only M1521 passed the test (Grade B). Several issues observed in other modules:
1) 2-6 ROCs with TrimBit test failure for many pixels
2) Trimming id bad for some ROCs
3) test at +10C often better than at -20C
4) some ROCs hav issues with Thr and Gain distributions (out of specifications)
To be understood before the mass production! |
|
Tue Dec 3 12:15:54 2019, Andrey Starodumov, Full test, 4 modules FT
|
| Andrey Starodumov wrote: | FullQualification of four modules M1526, M1529, M1521 and M1534 has been done. Full time of the test is about 5.5hrs.
Test included: FT@-20C, IV@-20, 3Cycles from -20C up to +10C, FT@10C and IV@10C.
Only M1521 passed the test (Grade B). Several issues observed in other modules:
1) 2-6 ROCs with TrimBit test failure for many pixels
2) Trimming id bad for some ROCs
3) test at +10C often better than at -20C
4) some ROCs have issues with Thr and Gain distributions (out of specifications)
To be understood before the mass production! |
We have run with Urs TrimBit test for M1526 at room T (without turning ON coldbox)
and results are confirmed yesterday observations of TrimBit test failure of several ROCs.
Urs will take a look and try to understand the issue.
To illustrate the problem below two summary tables of M1526 at -20C and +10C are shown. |
|
Fri Nov 29 17:06:26 2019, Dinko Ferencek, General, Dropbox folder on CERNBox set up
|
A dropbox folder for elComandante tar files was set up in my CERNBox and synchronized with the following local folder on the lab PC
/media/disk1/DATA/L1_DATA_Backup/CERNBox_Dropbox/
Note that the following link in the home folder
/home/l_tester/DATA
points to
/media/disk1/DATA/
so an alternative path is
/home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
The CERNBox client was installed on the lab PC following instructions for Ubuntu at https://cernbox.cern.ch/cernbox/doc/linux.html |
|
Thu Nov 28 18:58:30 2019, Dinko Ferencek, Software, Updated Fulltest configuration
|
The Fulltest definition used on the lab PC and stored in /home/l_tester/L1_SW/elComandante/config/tests/Fulltest had the following content
pretest
FullTest
bb2
exit
where FullTest is defined in https://github.com/psi46/pxar/blob/9eb0f3844e9c7f98d7701629c5af339632c5d84a/tests/PixTestFullTest.cc#L82-L121. For added flexibility, we would like to have individual tests specified in the definition file. However, by default this implies calling the doTest() method for each of the tests while FullTest actually calls the fullTest() method. For Scurves and GainPedestal the two methods are distinct. After the latest updates from Urs to the pXar code, we are now able to change the definition to
pretest
readback
alive
bb
bb2
scurves:fulltest
trim
ph
gainpedestal:fulltest
exit
Note that readback was placed first because in the past it was observed that pXar had a tendency to crash when this test was run last. |
|
Wed Nov 27 21:50:02 2019, Dinko Ferencek, Software, Reorganized pXar configuration files for pixel modules
|
Due to different DAC settings needed for PROC V3 and V4, a single folder containing module configuration files cannot cover both ROC types. To address this problem, the existing folder 'tbm10d' in /home/l_tester/L1_SW/pxar/data/ containing configuration for PROC V4 was renamed to 'tbm10d_procv4' and a new folder for PROC V3, 'tbm10d_procv3', was created. For backward compatibility, a symbolic link 'tbm10d' was created that points to 'tbm10d_procv4'.
The difference in the configurations is in the CtrlReg DAC value which is 9 for V3 and 17 for V4.
The following lines were also added in the [defaultParameters] section in /home/l_tester/L1_SW/elComandante/config/elComandante.conf
tbm10d_procv3: tbm10d_procv3
tbm10d_procv4: tbm10d_procv4 |
|
Thu Nov 28 18:23:31 2019, Dinko Ferencek, Software, Reorganized pXar configuration files for pixel modules
|
| Dinko Ferencek wrote: | Due to different DAC settings needed for PROC V3 and V4, a single folder containing module configuration files cannot cover both ROC types. To address this problem, the existing folder 'tbm10d' in /home/l_tester/L1_SW/pxar/data/ containing configuration for PROC V4 was renamed to 'tbm10d_procv4' and a new folder for PROC V3, 'tbm10d_procv3', was created. For backward compatibility, a symbolic link 'tbm10d' was created that points to 'tbm10d_procv4'.
The difference in the configurations is in the CtrlReg DAC value which is 9 for V3 and 17 for V4.
The following lines were also added in the [defaultParameters] section in /home/l_tester/L1_SW/elComandante/config/elComandante.conf
tbm10d_procv3: tbm10d_procv3
tbm10d_procv4: tbm10d_procv4 |
Since the new PH optimization code was added under the already existing PH test, the old configuration files would have to be updated to have the correct parameter values set for the expanded PH test. For this purpose, the old configuration folders were renamed
tbm10d_procv3 --> tbm10d_procv3_old
tbm10d_procv4 --> tbm10d_procv4_old
and new configuration files were re-generated from scratch
./mkConfig -d ../data/tbm10d_procv3 -t TBM10D -r proc600v3 -m
./mkConfig -d ../data/tbm10d_procv4 -t TBM10D -r proc600v4 -m
In addition, in both sets of configurations files, the configuration for the BB2 tab in the pXar GUI was moved from moreTestParameters.dat to testParameters.dat to have the BB2 tab available by default when starting pXar using these configuration files. |
|
Thu Nov 28 15:58:20 2019, Matej Roguljic, General, Activities 26.-29.11.2019.
|
26.11.
Prepared the tools for RD53A digital module assembly in the assembly lab
Investigated if the latest pXar commit solved the issue with PhOptimization, now called Ph, and it runs successfully.
Investigated the bump bonding issue in which pXar reports bad bumps, but we suspected that was not the case. And indeed, putting a source on top of the chip reported to have bad bumps and taking data shows that there are no bad bumps as reported by pXar. Our conclusion was that the BB test developed by PSI is not applicable for bumps bonded by Helsinki. BB2 seems to be appropriate.
27.11.
Assembled a Phase 2 digital module using good ROCs - 1A48, 1A47, 1A43, 1A42; being ROC 0,1,2 and 3, respectively.
Used X-ray box to confirm our BB findings yesterday and the results agree that there are no defective bumps (as reported by pXar) on M1534.
28.11.
Took a look at the assembled module and it seems that one corner of the HDI was not properly glued. There are also solder marks on a couple of pads so we decided not to wire-bond it.
Measured the alignment of the two assembled module (one module was assembled during my last visit) using the microscope. The discrepancies in the distance between HDI wire-bond pads and ROC wire-bond pads are around 200 microns. If we take the length of the module to be 4cm, this is less than half a degree of tilt.
Worked on presentation reporting these activities for the tracker week. |
|
Wed Nov 27 08:39:24 2019, Matej Roguljic, Cold box tests, Bump bonding test investigation
|
| The BB test on M1534 shows a lot of dead bunmps on C10 and some on C1 and C0 as well. Putting a source on top of the module shows that the pixels for which the test showed dead bumps are still able to read hits from the source. Therefore, it looks like the bumps are working, but the test is reporting them as defective. It turns out that the bumps used by Helsinki are different than the bumps used at PSI so a different test needs to be used. After trying all 4 BB tets in pXar, it was concluded that BB2 is the appropriate test to use. |
|
Wed Nov 20 16:53:50 2019, Andrey , Full test, M1533 and M1534 FullQualification
|
FullQualification of two modules M1533 and M1534 has been done. Full time of the test is about 7hrs.
Test included: FT@-10C, IV@-10, 2Cycles from -10C up to +10C, FT@-10C, IV@-10C, Ft@1-C and IV@10C.
No issues observed.
To be understood:
1) why SCurves results (noise) empty?
2) why the number of ROCs with defects always -1?
|
|
Tue Nov 19 14:10:10 2019, Andrey , Cold box tests, new modules M1533 and M1534
|
Yesterday Silvan wire bonded two new modules M1533 and M1534 that are both grade C due to high leakage current and a few ROCs with large number of defective bump bonds.
Today I run Reception1st test with IV at +10C for both modules and above features are confirmed.
The IV curves present on a MoreWeb webpage but the values of a leakage current in the table under the curve is 0A (?). May be it relates to the fact that it should be current at -150V shown,
while the voltage scan stops at -130V since one of the modules draw 98umA current at this voltage. If it so, the MoreWeb script should be corrected: the current taken at -150V or if voltage
is lower then it is taken at the last (highest) value.
Tomorrow a FullQualification will be run on both modules. |
|
Thu Oct 31 10:41:12 2019, Matej Roguljic, Cold box tests, Issue with DTB_WWVASW
|
On 29th of October, an issue with DTB_WWVASW was noticed when trying to run FullQualification on 4 modules at the same time. On a tested, working module, setting Vana works but taking tornado plots (setvthrcomp) doesn't as well as other tests. Curiously enough, after switching the DTB with the one used for HDI testing (DTB_WRN13L) the problem was still there. This lead us to believe that the problem was with cables or ground. All cables and the adapter were tested and shown to be working fine. This is when we took a third DTB, put it in the same plae as previously WWVASW and WRN13L, connected all the cables and then the tests worked.
Conclusion of the tests is that DTB_WWVASW and DTB_WRN13L are suffering from the same failure mode. It was not noticed before on the WRN13L because it does not affect the HDI tests. This leaves us with 3 working DTBs for the FUllQualification tests. |
|
Mon Oct 28 17:01:05 2019, Matej Roguljic, Software, Investigating the bug with the Keithley client
|
We took module 1529 and tried recreating the issue observed in the beginning of October. To do this in a reasonable amount of time, a "shorttest" procedure was defined which consists only of pretest and pixelalive. Three runs were taken
Run number 1: Shorttest@10,IV@10
Run number 2: Shorttest@10, IV@10,Cycle(n=1, between 10 and -10), Shorttest@10, IV@10
Run number 3: Shorttest@10, IV@10, Cycle(n=5, between 10 and -10), Shorttest@10, IV@10
In runs 1 and 2, IV was done from -5 to -155 in steps of 10
In run 3, IV was done from -5 to -405 in steps of 10
No issues were observed during the tests themselves.
Running MoReWeb shows the Temperature, Humidity and Sum of Currents plots while individual tests show only Pixel Alive map. IV plot is missing in the MoReWeb output, however, it is present in the ivCurve.log file. Tried investigating why IV is not shown, but couldn't get to the bottom of it.
Tomorrow we'll use M1529 and M1530 in a FullTest to check if the problem would appear. |
|
Tue Oct 29 16:38:32 2019, Matej Roguljic, Software, Investigating the bug with the Keithley client
|
| Matej Roguljic wrote: | We took module 1529 and tried recreating the issue observed in the beginning of October. To do this in a reasonable amount of time, a "shorttest" procedure was defined which consists only of pretest and pixelalive. Three runs were taken
Run number 1: Shorttest@10,IV@10
Run number 2: Shorttest@10, IV@10,Cycle(n=1, between 10 and -10), Shorttest@10, IV@10
Run number 3: Shorttest@10, IV@10, Cycle(n=5, between 10 and -10), Shorttest@10, IV@10
In runs 1 and 2, IV was done from -5 to -155 in steps of 10
In run 3, IV was done from -5 to -405 in steps of 10
No issues were observed during the tests themselves.
Running MoReWeb shows the Temperature, Humidity and Sum of Currents plots while individual tests show only Pixel Alive map. IV plot is missing in the MoReWeb output, however, it is present in the ivCurve.log file. Tried investigating why IV is not shown, but couldn't get to the bottom of it.
Tomorrow we'll use M1529 and M1530 in a FullTest to check if the problem would appear. |
M1530 was put in the coldbox and qualification was started, but the pxar output was full of deserializer errors. The continuous stream of errors made the log file pretty large and slowed down the execution of the qualification so it was aborted. Later it was noticed that there are green depositions on the module like it was on the HDIs irradiated at 60Co facility in Zagreb which is probably why there were so many errors.
M1521 was used instead of M1530 along with M1529. Full qualification was launched around 11:00. |
|
Wed Oct 30 16:54:58 2019, Matej Roguljic, Software, Investigating the bug with the Keithley client
|
| Matej Roguljic wrote: |
| Matej Roguljic wrote: | We took module 1529 and tried recreating the issue observed in the beginning of October. To do this in a reasonable amount of time, a "shorttest" procedure was defined which consists only of pretest and pixelalive. Three runs were taken
Run number 1: Shorttest@10,IV@10
Run number 2: Shorttest@10, IV@10,Cycle(n=1, between 10 and -10), Shorttest@10, IV@10
Run number 3: Shorttest@10, IV@10, Cycle(n=5, between 10 and -10), Shorttest@10, IV@10
In runs 1 and 2, IV was done from -5 to -155 in steps of 10
In run 3, IV was done from -5 to -405 in steps of 10
No issues were observed during the tests themselves.
Running MoReWeb shows the Temperature, Humidity and Sum of Currents plots while individual tests show only Pixel Alive map. IV plot is missing in the MoReWeb output, however, it is present in the ivCurve.log file. Tried investigating why IV is not shown, but couldn't get to the bottom of it.
Tomorrow we'll use M1529 and M1530 in a FullTest to check if the problem would appear. |
M1530 was put in the coldbox and qualification was started, but the pxar output was full of deserializer errors. The continuous stream of errors made the log file pretty large and slowed down the execution of the qualification so it was aborted. Later it was noticed that there are green depositions on the module like it was on the HDIs irradiated at 60Co facility in Zagreb which is probably why there were so many errors.
M1521 was used instead of M1530 along with M1529. Full qualification was launched around 11:00. It ended around 6:30 without any issues. |
Running full qualification on 30.10. in the morning on modules 1510, 1529, 1521. Fourth module was not included since there was an issue with the 4th DTB which will be investigated late. Like the previous day, the qualification ended around 17:00 without issues. In conclusion, the issue is not present in the qualification setup at the moment. |
|
Wed Oct 30 10:38:04 2019, Matej Roguljic, General, Activities 28.-31.10.2019.
|
28.10. - Investigated a problem with the FullQualification setup, described more in this note
29.10. - Further investigated the aforementioned problem and worked on preparing the jigs for Phase2 dummy module building.
30.10. - Confirmed that the reported issue is not present at the moment on the qualification system. Glued dummy sensor to four phase2 ROCs. Built a FC7 nanoCrate. |
|
Tue Oct 29 16:36:23 2019, Matej Roguljic, Module assembly, Assembly lab cap gluing jigs
|
There are two jigs for cap gluing in the assembly lab, circled in red and blue on the photo in the attachment. The one closer to the door (red) we used to build glue Phase 2 HDI to a dummy sensor and four Phase2 ROCs. Before changing the head, the numbers of the alignment screws were noted.
The jig closer to the doors (red): Top two pins - 5.75; Left pin - 5.5
The jig further from the doors (blue): Top two pins - 5.71, Left pin - 3.25 |
|
Wed Oct 2 12:50:52 2019, Dinko Ferencek, Software, Problem with elComandante Keithley client during full qualification
|
Full qualification was attempted for M1532 on Oct. 1. After the second Fulltest at -20 C finished, the Keitley client crashed with the following error
File "/home/l_tester/L1_SW/elComandante/keithleyClient/keithleyInterface.py", line 147, in check_busy
self.check_busy(data[1:])
File "/home/l_tester/L1_SW/elComandante/keithleyClient/keithleyInterface.py", line 147, in check_busy
self.check_busy(data[1:])
File "/home/l_tester/L1_SW/elComandante/keithleyClient/keithleyInterface.py", line 147, in check_busy
self.check_busy(data[1:])
File "/home/l_tester/L1_SW/elComandante/keithleyClient/keithleyInterface.py", line 147, in check_busy
self.check_busy(data[1:])
File "/home/l_tester/L1_SW/elComandante/keithleyClient/keithleyInterface.py", line 147, in check_busy
self.check_busy(data[1:])
File "/home/l_tester/L1_SW/elComandante/keithleyClient/keithleyInterface.py", line 147, in check_busy
self.check_busy(data[1:])
File "/home/l_tester/L1_SW/elComandante/keithleyClient/keithleyInterface.py", line 139, in check_busy
if data[0] == '\x11': # XON
RuntimeError: maximum recursion depth exceeded in cmp
Because of this, the IV measurement never started (the main elComandante process was simply hanging and waiting for the Keithley client to report it's ready) and the main elComandante process had to be interrupted. |
|
Sat Oct 5 22:59:58 2019, Dinko Ferencek, Software, Problem with elComandante Keithley client during full qualification
|
| A new attempt to run the full qualification for M1532 was made on Friday, Oct. 4, but the Keithely client crashed with the same error message. This time we managed to see from log files that the crash happened after the first IV measurement at -20 C was complete and Keithley was reset to -150 V. Unfortunately, the log files were now saved for the test on Tuesday so we couldn't confirm that the crash occurred at the same point. |
|