This is a collection of user notes on GXSM2, regarding installation, hardware and software operation etc.
Installation of GXSM on Ubuntu 10.04
1) Install necessary libraries
$ sudo apt-get install cvs checkinstall gnome-common libglib2.0-dev libgtk2.0-dev libgnomeui-dev libgtkglext1-dev libfftw3-dev libnetcdf-dev freeglut3-dev libquicktime-dev libncurses5-dev libgtkdatabox-dev linux-headers-generic automake1.9 netcdf-bin libesd0-dev
2) Getting source trees by cvs
$ cvs -z3 -d:pserver:anonymous@gxsm.cvs.sourceforge.net:/cvsroot/gxsm co -P Gxsm-2.0
$ cvs -z3 -d:pserver:anonymous@sranger.cvs.sourceforge.net:/cvsroot/sranger co -P SRanger
3) Compile GXSM
$ cd
$ cd Gxsm-2.0
$ ./autogen.sh
$ make
$ sudo make install prefix=/usr/local/stow/Gxsm_Jan_23_2012 (Use the date of the compilation)
$ cd /usr/local/stow
$ sudo xstow -D {previous version's folder name, e.g. ./Gxsm_Nov_18_updated}
$ sudo xstow {new version's folder name, e.g. ./Gxsm_Jan_23_2012}
this makes gxsm2 a link pointing to the files in stow
fimadmin@mantis:~/Gxsm-2.0$ which gxsm2
/usr/local/bin/gxsm2
fimadmin@mantis:~/Gxsm-2.0$ ls -l /usr/local/bin/gxsm2
lrwxrwxrwx 1 root root 37 2011-11-18 11:34 /usr/local/bin/gxsm2 -> ../stow/Gxsm_Nov_18_updated/bin/gxsm2
4) Compile SRanger related tools
$ cd
$ cd SRanger
$ ./autogen.sh
$ make
$ sudo make install prefix=/usr/local/stow/SRanger_Jan23_2012 (Use the date of the compilation)
$ cd /usr/local/stow
$ sudo xstow -D {previous version's folder name, e.g. ./SRanger_Nov_18}
$ sudo xstow {new version's folder name, e.g. ./SRanger_Jan23_2012}
5) Compile and install kernel module
$ cd
$ cd SRanger/modules-mk2-2.6.x
$ sudo make
$ sudo make install
$ sudo make load
6) Programming DSP and FPGA
From a Windows machine, start SR3_MiniDebugger.exe. Use SR2_NG in the pull-down menu for the SR2 "New Generation"
The two files required are:
The SR firmware tools (includes SR3_MiniDebugger.exe) can be found at
http://www.softdb.com/dsp-products-SR-MK2.php
see the section on SR2_NG
As of Nov 7, 2011, this is the most recent version:
http://www.softdb.com/scanning-probe-microscopy/mk2-a810/
7) If GXSM does not work
To activate the hardware
$ cd ~/SRanger/TiCC-project-files/MK2-A810_FB_spmcontrol/python_scripts
$ ./mk2_spm_control.py
Then
$ gxsm2 --force-configure
Specify the correct hardware type, "SRangerMK2:SPM" and the device file "/dev/sranger_mk2_0".
False Approaches
A common occurrence with STM operation is that the z-piezo retraction signal or the z-motor pulse waveform couples to the tunneling current which can cause auto-approach to stop since the detected current exceeds the desired tunneling current setpoint. The following settings seemed to be reliable in avoiding false approaches:
Overshoot and Feedback Settings
The following settings were used to approach a PtIr tip to a HOPG sample
This results in a step every ~4s (see top half of the figure below), and very minimal overshoot of the tunneling current (see bottom half).
Drift correction
External Offset/Scan adding
Drift correction is applied on the x/y offset channels
The tip position is updated on Pan View.
Offsets are not settable while drift correction is enabled. When drift correction is disabled and an offset is changed, or re-entered, the tip goes to the requested position in the non-drift-corrected coordinate system.
The SR analog outputs have a lot of high frequency noise. When measured with Tektronix TDS2004B:
4.4 mV RMS - 60 MHz bandwidth
1.8 mV RMS - 20 MHz bandwidth (limited on the scope)
0.6 mV RMS - using 10kHz anti-aliasing filter (has intrinsic noise of 0.4mV RMS)
External Offset/Scan adding
Slope correction is applied on the z offset channel.
Problem with zero-crossing when using slope correction
There is a noticeable Z piezo compensation when crossing zero which is only problematic when slope correction is enabled.
Raw data and line average subtracted topographic data on HOPG:
Averaging down the columns shows a clear step at the middle point of the image (pixel # 250), corresponding to a height of ~0.5A, where feedback kicks in to adjust the pizo (forward scan).
NOTE! it's quite possible the z scale is off by a factor of ~5 ... the z piezo calibration is not implemented in the ascii output file!
Work-around solution to zero crossing problem: use a finite Z-offset
Figured out that the z calibration factor which should be applied to both ASCII exports and the NetCDF is stored in the following field: ncread('K:\fimadmin120-M-Xp-Topo.nc','dz')
still not sure if scan should be flipped left-right or not yet...
In the following image (fimadmin106-M-Xp-Topo.nc), the slope compensation was set to -0.0032. The Z0 was adjusted by 0.2A, then again by 0.2A (down scan)
The zero-crossing offset glitch moves by ~47 pixels in a 250 pixel scan with size 52A : 52A*47/250=9.8A
This corresponds to a "slope" of 9.8A/0.4A = 0.041 (not sure how this is supposed to relate to -0.0032).
Notes on how the software works
Comments
In order for comments to be saved with updated contents of the text box, the mouse cursor must be moved out of the text box!
If a filename exists, IT WILL BE OVERWRITTEN! Make sure the offset number is correct, especially after GXSM crashes and re-starts.
Values in the following panels are saved when GXSM is exited (not when it crashes):
Values in the following panels are not saved when GXSM is exited:
To set bounds on the numeric entry box and its associated slider, right click and select "Configure" at the bottom of the menu.
Select the channels you want to acquire (left-most check box). Check the axis on which you would like it to be plotted (other check boxes). If nothing is checked, nothing will save!
Note: Zmon is a quantized version of the Z signal (for whatever reason). ZS is smoother, and should be checked for Z spectroscopy
The GLock checkbox is on each spectroscopy tab and will save your graph choices! But to set/change them follow these steps, or it may not work:
In any case, always check the saved file to see what's been saved.
In the SR DSP Control window > Advanced tab, the raster probe can be enabled.
There are two boxes used to set up this mode:
Raster : The spacing between raster probes (seems to be pixels)
Wait : 0 - scanning will not stop (make sure time of raster probe < time between raster probes)
1 - scanning stops between raster probe events.
Example of Raster Probe indentation array
It's a good idea to freshly restart GXSM since it has been noted to do weird things in auto probe after being open/running for days. For instance in Z spectroscopy it approaches the tip, retracts, then approaches...
The spacing between image pixels is somehow limited. At a VX / VY gain of 6.4x, we can enter up to 27.5nm in the "Steps XY" box. To make a 5x5 array, it's best to set up the Scan Parameter panel to Calculate "Range".
I(V) spectroscopy settings that I had to check on a 'scope or in data files:
Crash Report 1
Graphs Settings:
ADC0-I (Y)
Umon (X)
STS Settings:
IV-Sections = 1
IV-Start-End [-0.5 0.5]V; points = 1000
IV-dz = 0; #DZ = 0; #IV = 0
IV-Slope = 1; Slope-Ramp = 1
Line-dXY = 50; 0; 0; #Pts 1
IV-Line-Slope 100A/s; Final-Delay 1
Final Delay 0.01s; Recover-Del. 0.3s
Seems to be an issue with Autoplot. Can Execute, plot, etc by hand several (many) times. Using Autoplot crashes GXSM after 3 STS curves. Same behaviour for Z spectro. See report here
https://sourceforge.net/tracker/?func=detail&aid=3402699&group_id=12992&atid=112992
Z signal is output on Zs (not on Zo) when configured for external offset adding.
There are some useful hints about the lockin tab in the manual. I would suggest finding all those tidbits and reading them (see p 209 for mk2 hardware, 231 for first-gen hardware).
It is useful to realize that whatever frequency you ask for will be ignored and set to one of the following discrete frequencies: 585.9 Hz, 1171.9 Hz, 2343.7 Hz, 4687.5 Hz (this is the list for mk2 hardware which runs at 75000Hz native, or something like that).
The output modulation (on the bias channel) of the lock-in will only be activated when running a type of spectroscopy for which one of the LockIn1stA, LockIn1stB, LockIn2ndA, LockIn2ndB signals have been chosen in the Graphs tab. If they haven't been selected for recording/plotting and the acquisition is not running, the modulation won't be there!
On the lock-in tab, one should perform a phase sweep to get the initial phase for lockin outputs A and B. Select LockIn1stA and LockIn1stB on Y axis and PHI on X axis. Start by setting phase A to 0 and phase B to 90 degrees - other values make the plotted results start at weird phases > 360 degrees.
With the tip retracted, there should be no in-phase current being detected - only out-of-phase capacitive coupling (i.e. output B should be at a maximum and output A should be zero).
For the FIM system STM, the minimum in LockIn1stA output happens at about 140 degrees (and a corresponding maximum in LockIn1stB).
After setting the phase of A to 140 and B to 140+90=230, the response of A looks like a sine and B like a cosine. Note that the X-axis shows some f*d up phase angle starting at -1856 deg...
The output sensitivity seems to change with the setting of AC-avg-Cycles. This is due to the normalization of the correlation sum, I assume, which is not performed. However, the manual states that "All Lock-In data is raw summed in 32bit integer variables by the DSP, they are not normalized at this time and moved to GXSM via FIFO. GXSM applies the normalization before plotting." I don't think that GXSM is normalizing it either. So for the moment, doubling AC-avg-Cycles results in a doubling of the output LockIn1stA signal.
Applying a 1V amplitude bias modulation at 585.9Hz results in a ~125mV (=0.125nA) capacitive signal, estimated on the oscilloscope (incidentally this gives a capacitive coupling of C=0.125nA/(2*pi*585.9Hz*1V)= 0.034 pF). Applying a 0.1V bias modulation, we measure the output of the lock-in signal at AC-avg-Cycles = 1 to be about 6.4, at AC-avg-Cycles = 2 it is about 12.8. Roughly speaking, the number on the output corresponds roughly to the amplitude / 2 in mV of the value read on the oscilloscope.
Implementation of LockIn in STS
Getting started
I'm not sure if this is only in the newer versions (ver 3.x and up?), but Pyremote is easily utilized by opening the Pyremote Console in Tools -> Pyremote Console
You can execute single lines of code, or open and run full scripts very easily.
The most useful commands I've found are:
gxsm.action(" ... ") # ... can be just about ANY action name, where the action name is easily found # by holding the mouse over the button and reading the tooltip
# e.g. DSP_VP_LM_EXECUTE executes the VP operation in the LM tab
gxsm.sleep(int) #int is in seconds*10, so 100 = 10 seconds
gxsm.set("ScanX",string) #string is a number in string form in nanometers
gxsm.set("ScanY",string)
Deprecated instructions? :
As are most things with GXSM, the usage of Pyremote is far from obvious
I tried using
$ sudo apt-get install cvs checkinstall python-dev
to get the python-dev package mentioned here:
http://sourceforge.net/projects/gxsm/forums/forum/164771/topic/1626352
running ./configure in ~/Gxsm-2.0 directory gives this positive sounding result
checking for main in -lpython2.6... yes
checking python2.6/Python.h usability... yes
checking python2.6/Python.h presence... yes
checking for python2.6/Python.h... yes
when debugging things, it's useful to start gxsm2 from a terminal window so we can see what's going on:
Traceback (most recent call last):
File "/home/fimadmin/Gxsm-2.0/script/pyremote.py", line 3, in <module>
import Numeric
ImportError: No module named Numeric
Failed to execute Module.
it turns out that the directory in which GXSM is looking for the .py script is the one in which you start it from: so this means navigate to whatever directory you want, then run gxsm2.
Programming .py scripts
An example of an array of STS:
http://sourceforge.net/projects/gxsm/forums/forum/302195/topic/5163982
Also news from March 1, 2012:
http://sourceforge.net/news/?group_id=12992
A list of the fields in the GXSM NetCDF file is here: NetCDF fields
Field values can easily be pulled out using Matlab's ncread function, for example:
ncread(myFilename,'rangex')
ncread(myFilename,'sranger_mk2_hwi_mix0_current_set_point')
ncread(myFilename,'sranger_mk2_hwi_slope_x')
The following is also useful:
ncdisp(
myFilename)
Finding files
In order to find a particular file number / Direction / Channel and extract a field from it (in this case the units field), the following Matlab code snippet is a good start:
myImageNumber = 189;
myDirection = 'Xp'; % Xp=forward Xm=backward
myChannel = 'Topo'; % Topo, ADC0, ADC4
mySearchString = ['fimadmin' num2str(myImageNumber,'%03d')...
'*' myDirection '*' myChannel '*.nc'];
myFile = dir(mySearchString)
ncread(myFile.name,'dz')
Units
The units of the 'FloatField' are ADC/DAC bits. To convert to real units, look at the 'dz' field.
Topo: For the case of a Topo scan, dz relates Angstroms to DAC bits (0.064299023697809 Angstrom/bit in my case).
ADC0: dz relates nA or Volts to DAC bits (not sure exactly since my calibration value is 1 nA/Volt) (3.051850947599719e-004 V/bit).
ADC4: dz relates Volts to DAC bits (3.051850947599719e-004 V/bit).
A parser for vpdata text files can be found at http://www.physics.mcgill.ca/~paulw/gxsm/vpread/
Example vpdata files have been 'acquired' to test various features of GXSM and the robustness of the parser.
See demoVPstructure.m for a tour of the vpdata structure.
Raster Probe -- note that when this is enabled, the Appendix isn't saved to the vpdata file (as it usually is). Shit.
Did you delete a panel (aka windows taskbar)? I did once, this is how it's recovered:
gconftool-2 --shutdown
rm -rf ~/.gconf/apps/panel
pkill gnome-panel