2014_07_15 < Subaru/PFS

These notes refer to the 3rd set of 9/27 positioners.

Started the day by analyzing results of 07_14_14_21_47_40_TargetRun which ran overnight

These used the same maps as the previous two tests but with no updating (which was turned on for the previous test 07_14_14_08_25_24_TargetRun).
Motor maps were verified the same for all three tests. The performance was different for the test with updates on but not in an obviously meaningful way.

There was some confusion as to why the timestamps on the binary databse files used by MSIM had been changed to more recent ones than matched the xml which was believed to be loaded in there. Talking to Hrand and Charlie it sounds like this was the result of reloading and resaving the same xml during some debug. The MSIM databases were dumped and motor maps spot checked to ensure they were the same and they were.

070914_set3_allmaps_adj4 was loaded into MSIM and saved and then MSIM was restarted. 

Motors were connected and the target script 2014_07_09_TargetsEMSetC_no7 was rerun to get a third test with the above map to directly compare with the test 07_11_14_19_29_30_TargetRun. When this finished, the results did not match as expected. Specifically PIDs 5, 6, and 8 did worse in the new run. The rest were very similar to the original test a few days prior.
<img src="%ATTACHURLPATH%/convComparison.png" alt="convComparison.png" width='1200'/>

---++PID8 Debug
Closed MSIM and Opened up pathway software. Moved several motors to figure out which ones was PID8 theta. Then went to axis properties and recorded the current drive frequency to be 59.524kHz. Opened up the sweep window and did several sweeps only to see flat curves. Realized that this was because the sweep window settings were incorrect, not sure why. Consulted the NST delivery documentation and used their sweep settings for this motor and achieved a similar result to the documentation, 62.81kHz. *Not sure why we swept different frequencies to begin with from NST had in their documentation*. 

Kept PID8 with it's 59.524kHz since that is what all our current calibration has been done with.

---++PID7 Debug
Reran all of the ontime scripts to get ontime for PID7.

Manually figured out the ontimes just by looking at the images for PID7. 

Imported the current best XML file, 070914_set3_allmaps_adj4, into Matlab and modified it to have the new ontimes for PID7. Checked that the center of PID7 was fairly close to what's seen in the image to make sure that the next scripts aren't tripped up by that.

Created a new centers script, 2014_07_15_Centers01, with updated ontimes for PID7. Ran it once with just 1 loop on each stage to check the image.
There was a 5second wait each iteration (20 total) and the exposure time was 40sec. This was based on the previous centers script 2014_06_25_Centers01, so not sure how that ever worked. That file was also timestamped 7/4/14. Looked in its history on dropbox and saw that around 7/2 it was changed to have the longer wait time.
Changed the wait time to 2 seconds since some of the moves are longer than 1. This will still add up to more than 40 seconds but should get enough centroids to get a circle fit hopefully. Played around with step counts for PID7 a bit in order to get good spread of centroids for circle fits. 

Noticed that PID5 was not making it all around in the centers for &phi;. Looked at the ontime in the current XML and it is 0.06 ms. Looked at the images just taken for ontimes in 07_15_14_16_00_38_onTimeTuning and confirmed that 0.06 ms doesn't make it past a sticky spot but 0.07 ms does. Looked back at the previous ontime testing done here in 07_02_14_16_16_55_onTimeTuning and found that 0.06 ms did make it past the sticky spot then. So the motor has changed a bit. *Updated the xml ontime for PID5 to be 0.07 ms so that testing can continue now with it* Checked the reverse ontime for PID5 phi and that looked good based on the latest ontime images. The new XML was saved as pid7_5_OnTimesUpdated. Images of this are shown below with todays result on the left and the original test shown on the right.
<img src="%ATTACHURLPATH%/pid5changed.PNG" alt="pid5changed.PNG" width='1000' />

PID9 &theta; (known to have flex interference issues) was also found to have very large spacing between the dots and the step count had to be reduced. This hinted that ontime behavior might be different so the comparison was made between the latest ontime testing and the previous. It was discovered that there was quite a difference. The left image is from previous testing in 07_04_14_16_07_06_onTimeTuning and the right is from today's in 07_15_14_15_36_35_onTimeTuning.

<img src="%ATTACHURLPATH%/pid9comparison.PNG" alt="pid9comparison.PNG" width='1000' />
Attachments
Topic attachments
I	Attachment	History	Action	Size	Date	Who
png	convComparison.png	r1	manage	31.9 K	2014-07-15 - 23:07	UnknownUser
PNG	pid5changed.PNG	r1	manage	330.9 K	2014-07-16 - 16:23	UnknownUser
PNG	pid9comparison.PNG	r1	manage	493.9 K	2014-07-16 - 00:24	UnknownUser
This topic: Subaru/PFS > WebHome > POSitionerEM > POSEM_AL > 2014_07_15
Topic revision: r4 - 2014-07-16 - PeterMao