- New batch file management module
- New oscillator module - Bug fixes SKIPPED: psi/buffer.c psi/el734hp.c psi/el737hpdriv.c psi/make_gen psi/nextrics.c psi/nxamor.c psi/pimotor.c psi/polterwrite.c psi/psi.c psi/swmotor2.c psi/tasscan.c psi/tricssupport.c psi/tricssupport.h psi/tecs/make_gen psi/utils/ecb_load_new/ecb_load.c psi/utils/ecb_load_new/ecb_load.h psi/utils/ecb_load_new/ecbdriv_els.c psi/utils/ecb_load_new/gpib_els.c psi/utils/ecb_load_new/makefile psi/utils/ecb_load_new/makefile_EGPIB psi/utils/ecb_load_new/makefile_GPIB
This commit is contained in:
cvs
@ -12,6 +12,9 @@ initialisation file. Such special commands are described here.
|
||||
<DL>
|
||||
<DT>MakeRuenBuffer
|
||||
<DD>MakeRuenBuffer makes the RünBuffer system available.
|
||||
<dt>MakeBatchManager [name]
|
||||
<DD>Installs the new batch buffer management system. If no name is
|
||||
given, the default will be exe.
|
||||
<DT>MakeDrive
|
||||
<DD>MakeDrive craetes the drive command.
|
||||
<DT>MakeScanCommand name countername headfile recoverfil
|
||||
|
||||
176
doc/master.tex
176
doc/master.tex
@ -28,25 +28,33 @@ Author: Mark K\"onnecke
|
||||
This document gives an overview about all the hardware and software systems
|
||||
involved in SINQ instrument control. It describes the relationships between
|
||||
the various pieces and points to additional documentation, if available.
|
||||
A copy of all documents referred in this paper is stored at: /data/lnslib/distribution/sics/doclib. If they exist in electronic form, this is. The SICS user
|
||||
and manager information is available on the WWW starting from http://lns00.psi.ch/.
|
||||
A copy of all documents referred in this paper is stored at:
|
||||
/afs/psi.ch/project/sinq/commmon/share/sicsdoc.
|
||||
If they exist in electronic form, this is. The SICS user
|
||||
and manager information is available on the WWW starting from
|
||||
http://lns00.psi.ch/.
|
||||
|
||||
|
||||
\section{Hardware Overview}
|
||||
For each SINQ instrument the following computing hardware is available:
|
||||
\begin{itemize}
|
||||
\item A dedicated instrument workstation. Most of them are Compaq Alpha stations
|
||||
running True64Unix. One workstation is still running OpenVMS. Two instruments,
|
||||
POLDI and RITA--2, are controlled through Intel--PC's running Linux.
|
||||
\item A dedicated instrument workstation. Most of them are Intel x86
|
||||
machines running Linux. Three instruments use alpha workstations
|
||||
running Tru64Unix.
|
||||
\item A TCP/IP terminal server providing access to serial ports.
|
||||
\item Optionally, there are 1-3 histogram memory computers installed for those
|
||||
instruments which have area detectors. These histogram memory computers are
|
||||
Motorolla 6800 VME board processors running the vxWorks realtime
|
||||
operating system.
|
||||
operating system. Two types of boards are in use: the older Motorolla
|
||||
MVME1603 boards with 16 MB of memory and MEN-A12 boards with 512MB
|
||||
memory.
|
||||
\item Optionally there are National Instruments ENET-100 GPIB/TCPIP
|
||||
converters in use in order to access GPIB devices, especially those
|
||||
which came with the Risoe instruments.
|
||||
\end{itemize}
|
||||
Most instrument hardware is accessed through RS--232 interfaces and the terminal
|
||||
server. Histogram memories are accessed through the TCP/IP network. Generally
|
||||
ethernet is used as the main instrument bus.
|
||||
Most instrument hardware is accessed through RS--232 interfaces and
|
||||
the terminal server. Histogram memories are accessed through the
|
||||
TCP/IP network . Generally ethernet is used as the main instrument bus.
|
||||
|
||||
In addition to the computers at the instrument the following systems are
|
||||
available:
|
||||
@ -54,8 +62,9 @@ In addition to the computers at the instrument the following systems are
|
||||
\item A True64Unix laboratory server (lnsa15) for data management and
|
||||
primary data anlalysis.
|
||||
\item True64Unix PSI server systems for data processing.
|
||||
\item A dual processor linux science server (lnsl15).
|
||||
\item The PSI Linux Login cluster (llc)
|
||||
\item A WWW--server currently installed on lns00.
|
||||
\item pss123 is a Sun workstation holding the vxWorks development environment.
|
||||
\end{itemize}
|
||||
|
||||
\section{Software Overview}
|
||||
@ -75,7 +84,8 @@ The main software component at the instrument is the Sinq Instrument Control
|
||||
debugging. Clients to this SerPortServer such as the SICS server communicate
|
||||
with the server through a special ASCII protocoll transported through TCP/IP.
|
||||
The only documentation
|
||||
for both the SerPortServer and the ASCII protocoll is the source code.
|
||||
for both the SerPortServer and the ASCII protocoll is the source
|
||||
code. And David Maden.
|
||||
|
||||
There exists another support program, the FileSync server, on any instrument
|
||||
computer. This is a little Java server which listens at a UDP port for a
|
||||
@ -88,8 +98,8 @@ Then there is the TecsServer. This is a server which maintains and configures
|
||||
Lakeshore temperature controllers used as standard temperature controllers
|
||||
at SINQ. The only documentation for this program is Markus Zolliker.
|
||||
|
||||
On many instruments there are histogram memory computers. These usually run the
|
||||
following programs:
|
||||
On many instruments there are histogram memory computers. These
|
||||
usually run the following programs:
|
||||
\begin{description}
|
||||
\item[bootUtil] a utility running when the histogram memory is booted which
|
||||
starts all the other tasks and configures the histogram memory from its
|
||||
@ -114,30 +124,22 @@ The SICS software is described in a variety of documentation:
|
||||
described in the "SICS Manager Manual".
|
||||
\item The programming concepts of SICS are discussed in the "SICS Programmers
|
||||
Reference".
|
||||
\item An 90\% complete description of SICS source code modules is available
|
||||
\item An 97\% complete description of SICS source code modules is available
|
||||
as "SICS Reference Manual".
|
||||
\end{itemize}
|
||||
|
||||
|
||||
One instrument, TASP, is run with the TASMAD software from ILL which runs
|
||||
on VMS systems. A user documentation for this system is available at: \newline
|
||||
\centerline{http://sinq.web.psi.ch/sinq/doc/tasmad.html}
|
||||
Some configuration issues are explained in this docuement as well. Further
|
||||
documentation exists only in form of David Maden and an analysis of the
|
||||
source code.
|
||||
|
||||
The RITA--2 instrument from Ris\o{ } runs the TASCOM software.
|
||||
This software is quite well documented in various documents which can be
|
||||
obtained at WHGA/247 or directly from the Ris\o{ } team and Per Skarup.
|
||||
obtained at WHGA/112 or directly from the Ris\o{ } team and Per Skarup.
|
||||
|
||||
\subsection{Facilities at the Laboratory Server(LNSA15)}
|
||||
\subsection{Central Facilities}
|
||||
\subsubsection{Central Data Repository}
|
||||
Under the /data/lnslib/data directory there exists a central storage area for
|
||||
Under the /afs/psi.ch/project/sinqdata directory there exists a
|
||||
central storage area for
|
||||
data files measured at the instruments. Newly measured data files are
|
||||
automatically mirrored to this area once a measurement has finished.
|
||||
Not surprisingly there is a subdirectory for each instrument at SINQ.
|
||||
These instrument directories contain further subdirectories for each year
|
||||
of SINQ operation which hold the actual data files.
|
||||
There are directories for each year of SINQ operation. These contain
|
||||
subdirectories for the various instruments.
|
||||
|
||||
\subsubsection{The SINQ File Database}
|
||||
Right early on it was decided to separate the file archival function from the
|
||||
@ -155,20 +157,15 @@ which is part of the source distribution for the system. Here only an
|
||||
|
||||
The SINQ File Database consists of the following components:
|
||||
\begin{itemize}
|
||||
\item The database itself. This is the SQL database system mSQL from
|
||||
Hughes Technology.
|
||||
\item Any night the unix utility cron starts a shell script which is
|
||||
responsible for updating the database. This is done with two special
|
||||
utility programs:
|
||||
\begin{itemize}
|
||||
\item nx\_dbupdate scans a given directory for new files which are not
|
||||
yet in the database. If such a file is found, the data fields for the
|
||||
database are extracted and entered into the database.
|
||||
\item The Java program ScanScan does the same job as nx\_dbupdate for
|
||||
ASCII files.
|
||||
\end{itemize}
|
||||
\item The database itself. The database is installed on the central
|
||||
database server PSIP0 provided by central computing. The database
|
||||
software is oracle.
|
||||
\item Any night a database update program is started as a cron
|
||||
job. This programs runs on the linux server lnsl15. The program
|
||||
itself is a tcl script which uses oratcl for accessing the Oracle
|
||||
database server and nxinter for accessing NeXus files.
|
||||
\item A querying system. Curently the only query interface is a WWW--interface
|
||||
installed at the WWW--server.
|
||||
installed at the WWW--server lns00.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
@ -189,28 +186,19 @@ This document also explains how to get hold the source code for most
|
||||
of the software used at SINQ.
|
||||
|
||||
\subsubsection{Backup}
|
||||
The laboratory server is also the central backup server for SINQ. Backups are
|
||||
performed with the Legato networker software onto a tape jukebox holding
|
||||
5 tapes with 20GB capacity each. Currently only the /home (holding
|
||||
user home directories) and the /lnsarchive hierarchy are backed up.
|
||||
This backup system is a protection against a major harddisk failure. It is no
|
||||
archive system. Though backup tapes are held as long as possible it
|
||||
cannot be guaranteed that files older then half a year can be recovered.
|
||||
The backup software is described in the documentation coming with the
|
||||
system. No further documentation exists, but the setup can be viewed
|
||||
through the nwadmin application.
|
||||
Most user files and the raw data is stored within the AFS network file
|
||||
system. These files are backed up by central computing. Data files of
|
||||
older years are additionally archived in the PSI archive system.
|
||||
|
||||
The instrument accounts on the instrument computers must be backed up
|
||||
as well because they sometimes contain valuable scripts. Unfortunately
|
||||
there are not enough Networker licenses to go round and there is no
|
||||
reliable linux client software for our version of Legato Networker.
|
||||
Therefore the data in the instrument accounts is copied nightly to a
|
||||
special account on lnsa15 which is subjected to the normal
|
||||
backup. More details:
|
||||
The instrument and guest accounts on the instrument computers should
|
||||
be backed up
|
||||
too because they sometimes contain valuable scripts. These are local
|
||||
accounts, thus they are not covered through the AFS backup. Data from
|
||||
these accounts is synchronized nightly onto a special account on the
|
||||
linux server lnsl15.
|
||||
\begin{itemize}
|
||||
\item There is a script which does the copying. It is {\bf backupinst}
|
||||
in either /data/lnslib/bin or
|
||||
/afs/.psi.ch/project/sinq/linux/bin. This script is called with {\bf
|
||||
in /afs/.psi.ch/project/sinq/linux/bin. This script is called with {\bf
|
||||
backupinst INST} where INST must be replaced by the instrument name in
|
||||
capitals. This script essentially calls rsync with appropriate
|
||||
arguments to synchronize the instrument account minus the data
|
||||
@ -221,8 +209,8 @@ instrument computer must have an entry in crontab reading like:
|
||||
0 3 * * * /data/lnslib/bin/backupinst TOPSI >/tmp/topsi.log 2>&1
|
||||
\end{verbatim}
|
||||
Please replace paths and instrument names to match the instrument.
|
||||
\item The backup account on lnsa15 is named SINQINST, password:
|
||||
333SINQINST555. It contains a directory for each supported
|
||||
\item The backup account on lnsl15 is named SINQINST, password:
|
||||
SINQINSTLNS. It contains a directory for each supported
|
||||
instruments. For backupinst to work properly there must be a line in
|
||||
the .rhosts file of this account for each instrument computer which
|
||||
reads:
|
||||
@ -237,16 +225,12 @@ linux instrument computers, not the DNS alias.
|
||||
At SINQ the PSI EL--734 motor controllers are used. These motor controllers
|
||||
hold a set of parameters for each motor. As a safeguard against instrument
|
||||
scientists gone wild or a loss of parameters due some electronic or
|
||||
electrical incident these motor parameters are saved weekly. This happens
|
||||
on wednesdays mornings. The unix utility crom triggers the process and
|
||||
starts the script savemot which in turn does all necessary things. The
|
||||
actual saving of the motor parameters is accomplished with David Maden's
|
||||
el734 program. The saved parameters end up in the /data/lnslib/motors
|
||||
hierarchy. There exists a directory for each backup date which in turn
|
||||
holds a subdirectory for each instrument which holds the files with
|
||||
the saved parameters. All necessary shell scripts and programs can be
|
||||
found in the /data/lnslib/motors/bin directory.
|
||||
|
||||
electrical incident these motor parameters should be saved
|
||||
regularly. To this purpose there exits motor subdirectories in each
|
||||
instrument account. Motors are either saved into this directory
|
||||
through a script in this directory or from SICS (TASP,
|
||||
MORPHEUS). Motor parameter backup is a responsability of the
|
||||
instrument scientists and must be triggered manually.
|
||||
|
||||
\subsubsection{License Server}
|
||||
Unfortunately some people use the proprietary IDL programming system. This
|
||||
@ -275,19 +259,18 @@ Unfortunately some people use the proprietary IDL programming system. This
|
||||
|
||||
|
||||
\subsection{Software at the WWW--server}
|
||||
The WWW--server running at lns00 does not provide static information only but also
|
||||
active content calculated at runtime. The following services are
|
||||
implemented:
|
||||
The WWW--server running at lns00 does not provide static information
|
||||
only but also active content calculated at runtime. The following
|
||||
services are implemented:
|
||||
\begin{itemize}
|
||||
\item Keyword search in the SICS documentation.
|
||||
\item Searching the SINQ file database for files matching various criteria.
|
||||
\item Display of the current instrument status for a couple of instruments.
|
||||
\item Display of the current instrument status for most instruments.
|
||||
\item An experimental WWW control system for powder diffractometers.
|
||||
\end{itemize}
|
||||
Most of these services are provided through java servlets. In order to do this
|
||||
a servlet engine was needed. The combination Apache WWW-server and Apache
|
||||
JServ was choosen. However, it is planned to exchange the latter component
|
||||
by the Jakarta engine in the near future.
|
||||
Jakarta Tomcat was choosen.
|
||||
|
||||
The database search servlets are described in more detail in the document:
|
||||
\newline \centerline{The SINQ File Database}
|
||||
@ -299,8 +282,7 @@ The SICS documentation searching system is built on top of the program SWISH-E w
|
||||
from http://sunsite.berkeley.edu/SWISH-E.
|
||||
The actual search is performed through a TCL--cgi script which calls the swishe
|
||||
application with appropriate parameters. This script can be found as
|
||||
swishsearch.cgi together with a batch file to start it properly
|
||||
(swishsearch.bat) in the cgi-bin directory of the WWW hierarchy on lns00.
|
||||
swishsearch.cgi in the cgi-bin directory of the WWW hierarchy on lns00.
|
||||
Prerequisite for such a search is the existence of an index file. This must
|
||||
be created offline after any major change to the documentation. In order to
|
||||
create this index, cd into the sics directory of the WWW hierarchy and run:
|
||||
@ -321,12 +303,12 @@ In order to understand the system better it is useful to look at the flow
|
||||
\begin{enumerate}
|
||||
\item Data Files are generated by the instrument control programs at the
|
||||
instrument computer.
|
||||
\item Data Files are automatically mirrored to the central repository
|
||||
on the laboratory server lnsa15. This happens through the FileSync server,
|
||||
a shell script and last not least the unix rsync utility. All this is installed
|
||||
at the instrument computer.
|
||||
\item Data Files are automatically mirrored to the central AFS
|
||||
repository. This happens through the FileSync server,
|
||||
a shell script and last not least the unix rsync utility. All this is
|
||||
installed at the instrument computer.
|
||||
\item Nightly new files are scanned for relevant information and their
|
||||
characteristics are entered into the database system on lnsa15.
|
||||
characteristics are entered into the database system from lnsl15.
|
||||
\end{enumerate}
|
||||
|
||||
|
||||
@ -341,7 +323,7 @@ The SICS Java clients access the SICS servers on the selected instruments
|
||||
laboratory server lnsa15.
|
||||
\subsection{WWW Services}
|
||||
The file search service on the WWW--server lns00 accesses the database
|
||||
server running on the laboratory server lnsa15.
|
||||
server PSIP0.
|
||||
|
||||
The instrument status display servlets on the WWW--server lns00 access the
|
||||
SICS instrument control servers on the appropriate instrument computers
|
||||
@ -349,9 +331,6 @@ The instrument status display servlets on the WWW--server lns00 access the
|
||||
|
||||
\section{Maintainance Tasks}
|
||||
\subsection{Yearly Maintainance}
|
||||
The only maintainance task at SINQ shutdown is to disable the cron job on
|
||||
lnsa15 which performs the motor parameter backup.
|
||||
|
||||
|
||||
Whith each new year a couple of things must be done in order to keep the
|
||||
system ship shape:
|
||||
@ -369,13 +348,10 @@ Whith each new year a couple of things must be done in order to keep the
|
||||
\end{itemize}
|
||||
\item On the laboratory server lnsa15:
|
||||
\begin{itemize}
|
||||
\item Reenable the motor parameter backup cron job.
|
||||
\item Create new subdirectories for the new year in the data hierarchy.
|
||||
\item In /data/lnslib/lib/nxdb create new configuration files for the new
|
||||
year. Edit them to point to the new years subdirectory. Edit the
|
||||
updatenxdb shell script to use the newly created configuration files.
|
||||
Keep the old ones as they may come in handy if the whole database may
|
||||
require an update.
|
||||
\item Create a new year hierarchy for the new year.
|
||||
\item Store the old years data into the PSI archive.
|
||||
\item Move the old years data into the non backed up AFS area.
|
||||
\item Make the new year the backed up data on AFS.
|
||||
\end{itemize}
|
||||
\item On the WWW--server lns00:
|
||||
\begin{itemize}
|
||||
@ -391,10 +367,14 @@ Do these things quite early on in the year. People start measuring background
|
||||
In order to keep up with ageing 1-2 computers have to be exchanged any year.
|
||||
A instrument computer change requires the following adaptions:
|
||||
\begin{enumerate}
|
||||
\item Start with a PC with the PSI Linux distribution installed.
|
||||
\item Create two local user accounts: INST and instlnsg.
|
||||
\item Copy the SICS software to the instrument computer.
|
||||
\item Edit the instrument configuration file and change all occurences of
|
||||
the old computers name to the new name.
|
||||
\item On lnsa15 as user lnslib: enter the new computer name into the
|
||||
.rhosts file. This is required for the mirroring to work.
|
||||
\item Install the cron job for backing up the local instrument
|
||||
accounts.
|
||||
\item Make an entry in the .rhosts file of the SINQINST account on lnsl15.
|
||||
\item For the Java clients edit lnet/SINQConfig.java to point to the
|
||||
new computer and rebuild all clients. Redistribute them as well.
|
||||
\item For the WWW status, adapt the sics.conf file on lns00 and restart
|
||||
|
||||
59
doc/user/exeman.html
Normal file
59
doc/user/exeman.html
Normal file
@ -0,0 +1,59 @@
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>The Batch Buffer Manager</TITLE>
|
||||
</HEAD>
|
||||
<BODY>
|
||||
<H1>The Batch Buffer Manager</H1>
|
||||
<P>
|
||||
The batch buffer manager handles the execution of batch files. It can
|
||||
execute batch files directly. Additionally, batch files can be added
|
||||
into a queue for later processing. The batch buffer manager supports
|
||||
the following command described below. Please note, that the examples
|
||||
assume that the batch manager has been configured into SICS under the
|
||||
name of exe.
|
||||
<dl>
|
||||
<dt>exe buffername
|
||||
<dd>directly load the buffer stored in the file buffername and execute
|
||||
it. The file is searched in the batch buffer search path.
|
||||
<dt>exe batchpath [newpath]
|
||||
<dd>Without an argument, this command lists the directories which are
|
||||
searched for batch files. With an argument, a new search path is
|
||||
set. It is possible to specify multiple directories by separating them
|
||||
with colons.
|
||||
<dt>exe syspath [newpath]
|
||||
<dd>Without an argument, this command lists the system directories which are
|
||||
searched for batch files. With an argument, a new system search path is
|
||||
set. It is possible to specify multiple directories by separating them
|
||||
with colons.
|
||||
<dt>exe info
|
||||
<dd>prints the name of the currently executing batch buffer
|
||||
<dt>exe info stack
|
||||
<dd>prints the stack of nested batch files (i.e. batch files calling
|
||||
each other).
|
||||
<dt>exe info range [name]
|
||||
<dd>Without an argument prints the range of code currently being
|
||||
executed. With a parameter, prints the range of code executing in
|
||||
named buffer within the stack of nested buffers. The reply looks like:
|
||||
number of start character = number of end character = line number.
|
||||
<dt>exe info text [name]
|
||||
<dd>Without an argument prints the code text currently being
|
||||
executed. With a parameter, prints the range of code text executing in the
|
||||
named buffer within the stack of nested buffers.
|
||||
<dt>exe enqueue buffername
|
||||
<dd>Appends buffername to the queue of batch buffers to execute.
|
||||
<dt>exe clear
|
||||
<dt>Clears the queue of batch buffers
|
||||
<dt>exe queue
|
||||
<dd>Prints the content of the batch buffer queue.
|
||||
<dt>exe run
|
||||
<dd>Starts executing the batch buffers in the queue.
|
||||
<dt>exe print buffername
|
||||
<dd>Prints the content of the batch buffer buffername to the screen.
|
||||
<dt>exe interest
|
||||
<dd>Switches on automatic notification about starting batch files,
|
||||
executing a new bit of code or for finishing a batch file. This is
|
||||
most useful for SICS clients watching the progress of the experiment.
|
||||
</dl>
|
||||
</P>
|
||||
</BODY>
|
||||
</HTML>
|
||||
@ -14,23 +14,7 @@ to be solved are:
|
||||
<li>Measure a couple of reflections.
|
||||
<li>Furthermore there are some specialities.
|
||||
</ul>
|
||||
There are two ways to achieve all this:
|
||||
The older way uses some built in SICS functionality plus some external
|
||||
programs inherited from the ILL. This is called the ILL operation.
|
||||
Then a complete
|
||||
four circle package called DIFRAC from P. White and Eric Gabe was
|
||||
integrated into SICS.
|
||||
This is The Difrac way of operation.
|
||||
</p>
|
||||
<h2>DIFRAC</h2>
|
||||
<p>
|
||||
The DIFRAC commands are accessed by prepending the difrac commands
|
||||
with <b>dif</b>. For example: "dif td" calls the difrac td
|
||||
command. For more information on DIFRAC commands see the separate
|
||||
<a href="diftrics.htm">DIFRAC manual</a>.
|
||||
</p>
|
||||
|
||||
<h2>ILL operation</h2>
|
||||
<h3>Locate Reflections</h3>
|
||||
<p>
|
||||
If you know x-ray single crystal diffractometers you'll expect sophisticated
|
||||
|
||||
@ -26,7 +26,23 @@ Two special commands have been defined for TRICS with a PSD:
|
||||
<dd>reads reflection HKL values from file filename and performs
|
||||
tricsscans for each reflection. These will be done eith step width
|
||||
step, the number of steps np with counting mode mode and a preset of
|
||||
preset. These parameters have the same meaning as described above.
|
||||
preset. These parameters have the same meaning as described above. If the
|
||||
{\bf hkl nb 1} command has been given before the invocation of this scan,
|
||||
reflections will be searched in normal beam geometry. psdrefscan, however,
|
||||
will only print the normal four circle angles, though.
|
||||
<dt>detscan start step np mode preset
|
||||
<dd>Detscan performs a scan in two theta. This may be useful for detector
|
||||
calibrations. Arguments as described above.
|
||||
<dt>phscan start step np mode preset
|
||||
<dd>Phscan performs a scan in phi. This can be usefule for orienting a
|
||||
crystal. Arguments as described above.
|
||||
<dt>o2tscan2d start step np mode preset
|
||||
<dd>O2tscan2d performs a omega - two-theta scan with the PSD.
|
||||
Arguments as described above.
|
||||
<dt>hklscan2d
|
||||
<dd> For a scan in reciprocal space with the PSD, see the
|
||||
documentation for <a href="hklscan.htm">hklscan</a>. Please note that
|
||||
for a PSD HKL scan, all commans have to start with hklscan2d.
|
||||
</dl>
|
||||
</P>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user