User:Steven J. Koch/Notebook/Kochlab/2009/07/09/Feedback 96, Piezo debugging

From OpenWetWare
< User:Steven J. Koch‎ | Notebook‎ | Kochlab‎ | 2009‎ | 07‎ | 09
Jump to navigationJump to search

Steve Koch 14:57, 9 July 2009 (EDT): Checked again, and "Hold and Take Data" appears to work OK. Loop time remains constant (about 300-350 microseconds) during multiple runs. I do note, however, that the overall step time sometimes has a hickup--this would indicate a problem with the bit rollover or counter reading. So, this provides two clues to the problem with piezo loop time:

  • counter issue
  • improper use of DAQ task (similar to the previous problem)

http://kochlab.org/files/data/Kochlab-daq1/koch.steve/Testing%2096/090709

  • data file 28 corrupt
data file 29
  • Solved it! "wait us" was stupidly fixed and I didn't wire out the Daqmx cluster. data file 29 shows three data sets which are consistent. There is a strange jump in loop time in each data set. I wonder if this corresponds to when the piezo control voltage goes out of range? I think that's likely.
    • Yup, that was it. I slowed down the piezo by a factor of 10, and still took 10,000 data points, and the loops time was constant at the slow rate. Interesting to note that it slows down when there's an error like being out of range.

Learning (remembering) piezo stuff

Steve Koch 15:57, 9 July 2009 (EDT): For massive legacy reasons, there is all kinds of conversion of real-life position units (microns) to MHz (AOD frequency) and bits (AOD frequency control bitfield). I definitely could clean all this up, but I'm worried about breaking data analysis (just like I was back in the heyday). There may be an intermediate thing I could do where I just hide MHz and bits from the user, but even that may take some time more than just dealing with it for now. I looked up the feedback sequence in my old "Daq08-koch-Popping_VC_BsoBI.ini" (http://kochlab.org/files/data/Koch_Data/Popping_VC_BsoBI)data. A lot of factoids came back to me from looking at it:

  • I set 35 MHz (AOD center frequency) defined to 0 Volts (Piezo is unipolar, so this is the minimum position)
  • Piezo moved 12 microns per 10 volts (1.2 microns/volt). Now, I believe this is 30 microns/10 volts
  • I set the piezo to 38 MHz at the end of experiments (and thus the beginning of the next experiment). In effect, 38 MHz became the Piezo center frequency.
  • Then, at the beginning of experiment, I'd jump to 35 MHz, which put the beam out of the tether. Here, I would acquire the Create Offset Array. Then I'd jumpt back to 38 MHz and proceed with Piezo Find Tether Center.
    • What the hell is 38 MHz in microns? 1.410 microns / MHz, of course! (Looked up in old feedback program.) So, 3 MHz is 4.23 microns, or somewhere around 3.5 Volts.
  • So, what would we like our center frequency to be? 38 MHz worked well in the past, and I think it would be good for us now. The main consideration is we need enough room on the minus side so that we can complete "Find Tether Center." In any case, this is a soft-limit encoded in the feedback step array, so it's not a big programming decision now (compared with big decision of whether to ditch MHz or somehow get rid of it). I do need to confirm the 3 microns / volt conversion factor first, though.

Uh-oh, LV exception

Steve Koch 15:59, 9 July 2009 (EDT): While looking into the above Piezo stuff, Feedback 96_mx spontaneously crashed. I believe the software was in the non-acquisition side of things. So, not sure which DLL would have been being accessed?

Power Spectrum

This is the error I get: "Error -10401 occurred at AI Group Config

Possible reason(s):

NI-DAQ LV: The specified device is not a National Instruments product, the driver does not support the device (for example, the driver was released before the device was supported), or the device has not been configured using the Measurement & Automation Explorer."