Install guide

General Microscope control paradigm

In most cases, Iris controls hardware using National Instruments digital and analog connections. Even though some devices, such as the ThorLabs B-scope, come with a control unit that accepts serial port commands, we avoid using these in order to maximise cross-compatibility between rigs and minimise the need to have custom code for each rig. For example, in the case of the B-Scope, we have opened up the ECU and patched connections directly into the PMT control boards, galvo control board, and resonant scanner control board.

Iris is designed around a resonant x-axis scanner. Unlike conventional galvos, the position of the resonant scanner cannot be defined. Instead, we define the amplitude at which the scanner resonates. The frequency is fixed for the unit, with 8 kHz and 12 kHz being commonly available frequencies. The resonant scanner control board sends a sync signal that indicates when the mirror changes direction. We call this signal the "line trigger." The line trigger is fed into the NI digitizer (e.g. the NI-5772). Note that typically, the line trigger goes low-to-high as the mirror moves forward, and goes back from high-to-low as the mirror moves back. The line trigger thus goes low-to-high (or vice versa) only once for every pair of forward and backward scan lines. For bidirectional scanning, both the rising and the falling edge of the line trigger should be detected in order to update the position of Y-mirror for every scanned line. In labview, trigger configurations are limited to detect only one of the two types of transitions. Therefore, both rising and falling edge detection is achieved in software (within the vi that runs on the FPGA) and a new trigger OUT is created that goes low-to-high (and back) for every scan line. We call this the "Y-trigger". The Y-trigger frequency has twice the frequency of the line trigger. The Y-trigger is written onto one the PFI lines and can be read out as an output from the digitizer and used as the source clock for the Y-mirror. Note that for unidirectional scanning, the line trigger itself can be used to clock the Y-mirror.
The exact wiring of the line trigger signal will depend on the the code. You should look both at the VI running on the FPGA and at the VI which runs on your machine. e.g. D_FPGA_5772_2ch.vi. In a common configuration, for instance, the line trigger is seen by the FPGA via the trigger IN port on the digitizer. The Y-trigger is read out from the auxiliary I/O connector on the digitizer and further connected to the source clock terminal of the analog output channel that controls the Y-mirror position. We found that directly routing the line-trigger from the resonant scanner to the digitizer may sometimes fail due to the low input impedance of the FPGA. In such a situation, the line trigger is may be amplified by sending it first to a PFI line (say PFI0) on the PCI card and internally routing it to another PFI line (say PFI1). If you're using the DFPGA_5772_2ch.vi, you'll see this link being defined in software just before execution of the main loop. The amplified line trigger can then be routed from PFI1 of the PCI card to the digitizer. This configuration is just an example. You should follow the code to check.

The INI file

Iris is designed to be modular. The idea is that a core of programs, such as the main GUI window, remain unchanged across rigs. However, different rigs have different components. e.g. some may have a Pockels cell and others may have a half-wave plate on a rotation mount. In order to cope with these differences, each rig has an INI file associated with it. Iris knows which INI file to use based upon the hostname of the machine. In the INI file are a series of keys that define different "drivers." You can add and remove drivers from Iris by modifying the "driver.list" key. You can change the values of drivers to match your hardware. Setting up a new INI file for a new install of Iris goes something like this:

• Install a version control client, such as Tortoise SVN.
• Create a directory called C:/Code
• Checkout the SVN repository and place into this directory
• Navigate to directory.
• If you don't have write access to the repository, go to Variables directory and add VariablesMain.ini to your SVN ignore list. This is important if you don't have write access to the repository as will ensure that when you check out new updates they won't wipe your modifications. This file is used to link the name of your computer to an INI file that has your system-specific settings.
• Go to the Windows command line and run "hostname". The output of this command is your computer's network name. Use this create a new line in VariablesMain.ini e.g. JohnSmiths_Computer.domain.com = "JS_Rig01.ini" Note you need to enter the full domain name of your machine. So if you're at the FMI, it's myMachineName.fmi.ch
• Copy one of the existing INI files and rename it so that it has the name used in the VariablesMain.ini
• Modify your INI file for you hardware.
• Open the appropriate project for your digitizer (Iris-5761.lvproj or Iris-5772.lvproj) This will launch LabVIEW and configure things correctly for your hardware.
• In the Project Explorer, expand the Code directory and double-click on ScanMicroscope_GUI to start.
• Likely something will go wrong at this point if this is a new install... :)

PMTs

Different PMTs may have controllers that accept control voltages over different ranges of values. In order to cope with this, we define the type of PMT using the key "pmt.1.driver" in the INI file. e.g. The GaAsP type H7422 has an input control voltage that varies between 0 and 0.9V. On the other hand, units such as the R6357 go between 0 and 5. In all cases, however, actual sensitivity is not a linear function of control voltage.

Save path

You need to define a valid save path for data in the .INI file, or Iris will generate errors
on startup.

Pockels Cell

We have a Pockels cell control VI, but currently no turn-around blanking. This is planned. If you need it or have coded it, please contact us via the Discussion forum.

Obtaining an image

• Go to "Scan geometry". Start the resonant scanner (if not already started). To start it, set the amplitude value. If you can't hear the scanner, it's not running (or your hearing is bad). You will likely need to issue a value change for Iris to pick up the value.
• You should hear the Y mirror scan if all is good. If you only hear the resonant scanner, then you likely have a triggering problem.
• Ensure that the the "auto" checkboxes on the CH1 and CH2 ranges in the main window are ticked. You should at least see noise on the channel windows. If not, try setting Piezo nbr layers in scan geometry to 2 and then back to 1. Same thing with the number of Z layers. We are aware that changes are needed to the Scan Geometry dialog, as it is confusing.
• Set PMT gains and turn on. PMTs may disable if too much light is detected (not all models do this). If so, reduce gain and cycle enable/disable button for PMTs.
• The scanning is bidirectional. The "start delay" number controls the alignment of the outward and return lines. The value required here needs to be very precise or your image will look a mess (small pixel shifts can be easily corrected post hoc). It may be very far out. The value depends on the amplitude of the resonant scan.
• If the image is clipping it will look odd: you will see color scale inversions. Decrease PMT gain until you no longer see these.