This FAQ is compiled by the Gilles Detillieux of the SCRC, based on
questions posed at various times, mostly via e-mail, or sometimes in
anticipation of questions likely to come up.
The most recent version is available at
Questions (and answers!) are greatly appreciated.
Please send questions and/or answers to the SCRC Software support
mailing list at <email@example.com>.
You can subscribe to this mailing list here:
Software Support Mailing List.
You currently have two options for bug-reporting.
You can either mail the mailing list at
or e-mail Gilles directly.
Either way, he will see it and look into the problem.
We may at some point add a bug reporting form and tracking system to
our site, but for now e-mail is the preferred means.
Please try to include as much information as possible, including the version
of the package you are running (see question 2.1),
the operating system you have on your computer, the program that failed,
any error messages you saw displayed,
and anything else that might be helpful in reproducing the problem.
Great! Development of this software continues through suggestions
and improvements from users. If you have an idea (or even better,
a tip or script to contribute), please send it to the mailing list so others
can use it.
If you'd like to make a feature request, you can do so through the
mailing list as well.
While Gilles does his level best to answer all his e-mail, especially from
users of the neuro package, he is often swamped, so messages may at times
slip through the cracks.
If you don't get a reply within 2 or 3 days, try sending a reminder.
You may also find it preferable to send your questions to the mailing list,
as you may be able to get help from other users more promptly.
Note that when posting a followup to a message on the mailing list,
you should use the "reply to all" or "group reply"
feature of your mail program, to make sure the mailing list
address is included in the reply, rather than replying only
to the author of the message.
See also question 1.6 and the
As for mail directly to Gilles, you may not always get a reply right away.
Other users may also be to busy to respond, or may not be able to answer,
and will just leave the question for someone else on the list.
If you don't get a response after 2 or 3 days, then a reminder may help.
See also question 1.4 above.
The neuro mailing list
exists for dealing with questions about the software, techniques for using
it effectively, and dealing with problems with it.
E-mailing the developer, or any one particular user, circumvents this forum
and everyone else on it.
It also bypasses the
mailing list archives
which may help others with similar questions.
Finally, it puts the onus on an individual to answer, even if that individual
is not the best or most qualified person to answer.
Some users have found ways of using the software that Gilles never envisioned,
and may be able to provide answers to others more effectively than Gilles could.
Note also that when you reply to a message on the list, you should
make sure the reply gets on the list as well, provided your reply is
See question 1.7 below.
The simple answer is that, unlike some mailing lists, the
lists on the SCRC server don't force replies back on the list.
This is actually a good thing, because you can reply to the sender
directly if you want to, or you can use your mail program's
"reply to all" capability (sometimes called "group reply")
to reply to the mailing list as well. It does mean you have to
think before you post a reply, but some would argue that this
is a good thing too.
There are some compelling reasons to try to
keep on-topic discussions on the list, though (see questions
1.6 and 1.4 above).
The technical answer is our "mailman" mailing list manager software
is wisely configured by default not to do what's known as
If you want to find out more, you can read
SourceForge's policy on Reply-To: munging, where you'll
find all the gory details about the pros and cons of the two
common ways of setting up a mailing list, and why SourceForge
turns off Reply-To munging. It so happens that Gilles agrees with
this rationale, and doesn't plan to turn this feature on.
Before you go anywhere else, think of other ways of phrasing your question.
You have questions that are very similar to other questions answered here.
While we try to phrase the entries in the FAQ closely to
the most common questions, we can't get them all!
The next place to check is the
In particular, take a look at the list of
You should also try a
search of our
web site, which will include the contents of our online documentation,
help files, and mailing list archives.
Finally, if you've exhausted all the online documentation, there's the
neuro mailing list.
There is a good chance that someone on the list has had a similar problem
before or can suggest a solution.
release is 20151201 for Linux, Windows (Cygwin),
20150520 for Mac OS X 10.2-10.4,
Mac OS X 10.7 and up.
Any supported system can be updated to the latest release on request.
The version number is in fact just the date the source code was packaged
together before building into binary packages for installation.
You can find out about the latest version we're running here by reading the
What's New pages.
The change log in particular will have the most recent changes.
To find out what version you're running, it's usually just a matter of
running the "rpm" command on Red Hat Linux to query the "neuro" or
The neuro-cap package is installed on data capture and analysis systems,
while the neuro package is for analysis-only installations.
The command "rpm -q neuro neuro-cap" will tell you what is
For non-Red Hat systems, you can just look at the date of the ChangeLog
file that comes with the package, e.g.:
"ls -l /usr/neuro/doc/ChangeLog"
as this is the last file updated before the package is built.
If you don't have a ChangeLog file, then your installation is from
July 2000 or earlier.
The date of /usr/neuro/bin/analysis should give you a rough idea of
the release date.
The cost of the full SCRC Data Capture and Analysis Software package is
$7000 (Canadian). For the analysis-only package, it is $5000 (Canadian).
Researchers who have already obtained one such license for the full
capture and analysis package or the analysis-only package, at full price,
can then purchase additional sub-licenses for each additional analysis-only
workstation they set up at their site, at a cost of $500 (Canadian) per
for more information about the software.
Please e-mail us if you require a quotation for a software purchase.
While a number of systems have supported this software in the past, we
currently recommend Intel Pentium or compatible PCs running Red Hat Linux,
for data capture as well as analysis.
fact sheet and
page for more information about supported hardware and operating system
Until the summer of 2009, the answer was no.
Because the software was written to run on UNIX-compatible operating
systems, like QNX, Linux and Mac OS X (for the analysis portion),
porting it to run directly on a Microsoft Windows system would have been
But an emulation environment called
makes that task considerably easier,
and has gotten to be reliable enough that we now support it.
So, now the analysis portion of the software can run under Windows XP, Vista or 7.
Additionally, using some form of
technique, you can run a Linux system as a virtual machine right on your
Finally, because the software runs on the X Window System on Linux or
UNIX compatible systems, it is possible to run the software remotely
on any of these systems on the network, while displaying on any other
system that supports the X Window System for display. As software is
available for Microsoft Windows to turn a Windows PC into an X Window
System terminal, you can run the software over the network from any
Windows-based PC, using
If you already have a Linux system running our capture and analysis
software at your site, then this may be the preferable way of running
analysis from your Windows desktops, as it keeps your data centralized
on your Linux server system.
The documentation for the most recent release we have installed is always
posted at www.scrc.umanitoba.ca/doc.
In all releases, much of the documentation is included in the
/usr/neuro/doc subdirectory of the source distribution,
so you have access to the documentation for your installed version.
On Red Hat Linux installations, the RPM package will also install the
manual pages in the appropriate directories so they can be accessed
with the man command, e.g.: "man appendrun".
There are two ways to determine the answer to this question.
The first, and likely most helpful one, is to have a look at the listing
of SCRC Data
Capture and Analysis Manual Pages on our web site, to see what's
normally available in the current release. This will tell you not only
what the comamnds are, but what they do, and will link to documentation
for all of these commands.
The second way is to get a definitive list of all the commands
installed on your system right now. You can do this by looking in the
/usr/neuro/bin directory on any system on which the
software is installed, e.g.:
"ls -l /usr/neuro/bin".
If the command you're looking for isn't listed there, chances are it's
an add-on command or script as described below.
analysis script archives
on our web site are a collection of locally developed or user-contributed
analysis scripts, which can be freely downloaded and installed on your system.
In some cases, scripts on our web site are already included in
the package, but in those cases the version on our site may be a
newer version with added features. If in doubt, look in the
/usr/neuro/bin directory, as described above, to
see which commands are included in the analysis software package
on your system. If the script you're looking for isn't listed there,
or the size is different from that listed in the analysis script archive
then you should probably download and install the needed script.
To download a script from our web site, you can view the list at
then right-click on the link to the script you want and choose
"Save Link As..." or some equivalent selection from the pop-up menu,
or you can left-click the link to view the script, and then
do a "File->Save As..." to save a copy of the script.
Note that on some systems, the web browser may add a .txt
extension to the script file name, in which case you will then need to
rename the file to remove the extension.
Then, the script should be installed in /usr/local/bin or /usr/neuro/bin
on your analysis system, and made executable with the command
"chmod +x filename", where filename is the
full pathname of the installed script, e.g.
This will enable the script to be run as a command on your system.
You will need to be logged in as "root", or raise yourself to administrator
status with the "su" command, in order to install scripts in either of
these two directories. The choice is yours which of the two you prefer to
use, but you should probably be consistent to avoid losing track of what
While it might be a bit of a bother to have to install your own add-on
commands, it allows for quicker updates than what you can get strictly
from the packages of distributed software. Having access to our script
archive gives you updates to the latest features and user contributions
as they happen, without having to wait for them to be packaged in the
next analysis software release.
This is largely dictated by the hardware you are running, and which operating
system version, as well as a number of capture parameter settings.
There are no hard and fast limits on the number, apart from the fact that
the only supported A/D cards until recently have been 16 channel cards, and the
software had a limit of 16 traces and 16 waveforms for a given run file.
For the Linux-based data capture systems, we have tried to preserve reliable
performance capturing 16 channels at 20 KHz per channel.
Until recently, the only supported A/D cards have also been 12 bit cards.
Support for 16 bit cards has been developed, as has support for cards with
up to 64 channels.
This is currently in beta test, but has been working quite reliably in one
of our labs for just over a year.
See our item on
Expanded Channel Capability for details.
In addition to our long-standing support for UEI PowerDAQ A/D boards under
Linux, we have added a few new options to the mix:
Instruments PCI-6251 or other NI M-series multifunction boards
(supported under Linux using the Comedi driver package),
or NI USB-6210
or other NI USB-based multifunction DAQ devices
(supported under Windows using the NI DAQmx driver package).
Other combinations, which we have not yet tested, but which should also work
with the software as it stands now, are the following:
any multifunction DAQ board supported by the
Comedi drivers under Linux,
or any National Instruments DAQ board or USB device under Windows.
If you're still learning the software, the best way to learn various analysis
techniques is to look at the
on our web site. In time, we will be expanding these to include more
techniques. We will also be describing specific analysis techniques briefly
below, as the need arises, for techniques not covered by the tutorials.
For techniques not in the tutorials or the FAQ below,
we recommend you browse through the
Analysis User's Manual,
or the list of
in the analysis help facility, to find something close to what you need.
Then, explore the analysis parameters for that method, to see if you can get
it to produce the type of graph you want.
Finally, you can always ask the mailing list.
See also question 1.8.
What we often refer to as "integrating" in electrophysiology is really
not integration at all, but simply rectifying and filtering, in order to
obtain the linear envelope of a signal. True numerical integration is the
reverse of differentiation, in which successive samples are summed up.
This summing up continues over the whole duration of the signal, such
that at any point in time, the value of the integrated signal is the
area under the curve of the non-integrated signal from time 0 up to
the current point in time. This technique, in and of itself, is not
generally used in processing raw ENG or EMG signals.
A variant of this numerical integration is to perform it on time slices
of the signal, where you integrate for some short amount of time, after
which you zero out the sum and start over integrating the next time
slice. This technique, which can be performed in software or hardware,
is sometimes used in electrophysiology, as it produces a signal that
can approximate the envelope of the signal being integrated.
The more common technique, and the one which we use in our labs, involves
full-wave rectification of the signal followed by low-pass filtering.
It is often referred to as integration, even though that term isn't
exactly correct, because it somewhat approximates the time-sliced
integration technique. This is because the low-pass filter accumulates
charge from the signal (like summing it up) and slowly bleeds it off (like
resetting the sum, only gradually rather than at fixed time increments).
Again, this technique can be performed in hardware or software, and
we use both methods in our labs. Some labs are equipped with hardware
"integrators" (rectifier/filter units) which can process the raw ENGs
into signals that give the ENG envelope, which can then be captured
at a lower sampling rate than raw ENGs. More commonly, we will capture
the raw ENGs and rectify and filter them in the analysis program.
The trick to this approach is to find the appropriate cutoff frequency
for the filter, which will vary depending on the source of your signal.
The cutoff frequency must be low enough to filter out individual
spikes, but not so low as to attenuate the pattern of bursts of spikes.
Our analysis program's Maint/Filter section can perform the rectification
and filtering in one operation.
Tutorials 13 and
14 on our web site
give some pointers on how we do this in the analysis software.
Unfortunately, the term "raster" suffers from overload, and means
different things in different contexts, which leads to confusion.
Even in electrophysiology it has two different meanings:
a) a "waterfall" plot of triggered sweeps of data, plotted front to back
with an offset and optional hidden line removal; and
b) a graph of action potential positions, with each line in the graph
representing a different cycle, and with each dot marked on the line
indicating the action potential position within that cycle.
program in our software suite produces the first type of
raster plot, not the second. You can produce the second
type within the analysis program, using the graph of
action potential position vs cycle
(or the sorted version of this).
For this analysis, it helps to turn off the
option, and turn on the
Display cycle activity
option, so you can see the varying cycle lengths and how the spikes line up
You can also produce a waterfall plot of waveform spikes, rather than just
spike positions, by converting the waveform to triggered sweeps, which
can then be displayed in the
You do this by setting up a
cycle triggered average,
with a single
per cycle but with a
duration as long as the longest cycle,
so that you can get each full cycle as a triggered sweep.
This cycle-triggered reframing technique is described in a little more detail
in question 4.5 below.
You then set the
Preview average data
option and Bins-save the preview (raw) data.
Tutorial 9 for an introduction to reframing and the raster program.
In the general case, a polar plot is essentially just an X-Y graph
wrapped around in a circle, with the X coordinate representing the angle
and the Y coordinate representing the radial distance from the centre.
So, when you say you want a polar plot of your data, the question becomes
what are the data for the X and Y axes of this graph? What these data are
will determine the best approach to producing the graph, as there are
essentially 3 different approaches to making polar plots in the SCRC
software, and one of them can be applied to any cyclical graph in the
Most of the polar plots made with the SCRC analysis
software are generated by the
script from our
This script can plot the times of onset of activity on one waveform
(usually a rectified and filtered ENG) on a cycle defined by the activity
on another, or spike (action potential) onset times on a cycle.
You will need to install this script on your system (see question
2.8), then follow
for the procedure to use for making these polar plots, including the work
you need to do to prepare the data for analysis (e.g. rectifying and filtering
raw ENGs and marking up cycles).
also explains the procedure for marking up cycles, if you need to go into more
detail on the ins and outs of that technique, and the 5th and 6th sections of
show how you can put the resulting HPGL plot files into final figures.
There are also some polar plotting capabilities right in the analysis
program, as well as in our genplot program. A search for
on our web site should find all the relevant documentation.
The analysis program can turn any normalized cycle graph into a polar plot
by setting the
Cycles on graph and
program can plot data from an ASCII text file into a cartesian or polar graph,
and is the engine under the hood of our gensspp script.
The Maint/Reframe operation only uses a spike trigger, so you have to use a
somewhat roundabout technique to reframe using a cycle trigger.
You do this by setting up a
cycle triggered average,
with a single
You will need to set the
duration to an appropriate length.
For example you can set it to be as long as the longest cycle
so that you can get each full cycle as a triggered sweep.
You then set the
Preview average data
option and when you perform a Bins-save operation, you can tell the analysis
program to save the preview (raw) data.
The end result is similar to reframing, but the resulting run file will only
have the frame (trace) data, and no copies of the waveforms, like when you
reframe with the "Without-W.F." selection.
A peri-stimulus time histogram, or PSTH, is also known as a cross-correlation.
That latter term is what the analysis program uses. It can be performed using
the W.F. spike cross-correlation histogram analysis.
The process is described in detail in
on our web site.
That depends a lot on what part of a signal you want to measure, and whether
you want a relative or absolute amplitude.
Though many analysis methods involve the measure of amplitude, one of the
most versatile for measuring waveform amplitude is the
W.F. amplitude vs step cycle.
With step cycles set, you can use this method to overlay all cycles to
calculate an averaged curve representing the cycle.
The top titles of this analysis will include a number reported as
"Amplitude", which is the peak-to-peak amplitude in the averaged waveform,
i.e., the difference between the minimum and the maximum average data
points calculated in all bins in the graph.
As it's a difference, this number represents a relative amplitude, independent
of the absolute displacement (or DC shift) of the waveform.
Note that as you reduce the
bins- graph parameter for this analysis, the amplitude reported at the top
of the graph will tend to decrease as well, as the peak & trough of the
cycle get smoothed out and reduced by averaging.
It's important to choose a number of bins that will still accurately represent
a typical cycle's shape in order to get a meaningful amplitude measurement in
When this analysis is carried out on an intracellular recording of a motoneuron
(which is DC-coupled, i.e. not high-pass filtered) the reported amplitude is
known as the locomotor drive potential or L.D.P.
If you wish to obtain a single absolute mean amplitude for a region of the
waveform, rather than a peak-to-peak or relative amplitude, you can use this
same analysis and set the
bins- graph parameter to 1,
and set the
Start of run
and End of run
to the range you wish to measure.
Set Cycle W.F. #
to -1 to treat the entire range to be analysed as a single cycle.
This will plot a single point on the graph, representing the mean amplitude
as an absolute level.
You can then use Bins-save to output the numerical value for that level.
Of course, any amplitude measurements are only as accurate as the calibration
for the channel from which the signal was recorded, so be sure to properly
calibrate the channel before recording, or correct the calibration for the
With any averaged graph in the analysis program, you can set the
Show areas under curves
option to get this area calculated and shown at the top of the display.
This is most commonly used, and most useful, with the
Averaged W.F. amplitude vs step cycle
Note that because the calculation is done on the displayed graph, the scaling
of the graph matters - particularly the lower bound of the Y axis.
So it is important to turn off
and explicitly set the Y-axis lower bound in order to get consistent results.
The analysis program calculates for each bin the area from the mean value
to the graph's baseline, whatever that baseline appears as on the displayed
graph, and it sums these up for all bins.
If you'd rather get areas for each burst in a run, you may be better off using
scripts from our
manual page for more information on this script, and run "burstareaplot --help"
to get more information on the latter script.
While this graph can't be produced directly in the analysis program, there are
a couple ways it can be done. One way is to use the
W.F. activity burst duration vs cycle duration
analysis method, and set it up to output burst durations as start to start,
and to output burst positions on the X axis. With the Cycle W.F. # set to -1 to
get the whole run as a single cycle, and Normalization turned off,
you'll get the start time of each burst on the X axis. You can then Bins-save
the data and import it into a spreadsheet, where you can invert the Y values to
get frequencies, then plot the frequency vs time.
An easier method might be to use the
script from our
to output burst start times and cycle durations. You can then convert the times
from ms to seconds, and invert the cycle durations (while also converting from
ms to s, or KHz to Hz), using a handy UNIX tool called "awk". Here is an
example of a command that will do both of these steps:
The redirect at the end of that command will save the output in a .csv file.
The awk command above does the conversion from ms to s by
dividing ms by 1000 in the first column,
and does the frequency conversion by dividing into
1000 (equivalent to 1 / (time in s)) in the second column.
Finally, you can plot that file using genplot:
There are a number of different methods of exporting data from the analysis
Tutorial 11 for an introduction to exporting data.
Also, you can get a raw dump of an entire waveform file, as A/D levels,
script from our
or you can use the new
script to dump several waveforms as a CSV file of millivolt values,
downsampled to a frequency of your choice.
You can use either
to convert an ABF format file, or atf2run to convert an ATF
The usage of atf2run is the same as that of axon2run, except for the expected
input file format.
As Axon Instruments has changed its ABF file format since axon2run was written
File Support Pack for DOS),
this program may have difficulties converting newer files from their software,
as detailed in question 5.3 below.
program was written with Axon Instruments' older DOS-based
file support pack,
which handled the ABF (Axon binary file) format in use in Axotape and other
programs as of the mid-nineties.
They have since changed the ABF file format, so axon2run has problems with
some newer files that make use of the extensions to their file format.
One important point to note is that there are now two types of ABF files:
Binary Integer and Binary Floating Point.
Pre-May 17, 2007 versions of axon2run could not convert Binary Floating Point
Be sure to save your files using Binary Integer, as Binary Floating Point
will not work in old versions of axon2run.
Files which have been analyzed in pCLAMP are saved in floating point by default.
If you are experiencing problems with ABF floating point data files, you
may wish to upgrade your software to the latest (May 17, 2007 or later) beta release,
or just update the axon2run program on your Linux system (RH6.2 or later)
by running the following command as root:
However, there does appear to be some newer Binary Integer ABF files which
also pose problems for axon2run.
In those cases, you should convert them to ATF by opening them in Axoscope or
whatever program you used, and saving them in the Axon Text File format.
You can then convert the text files with atf2run.
Note also that in Axoscope and Clampex version 10, they have changed to a
new ABF2 file format which is completely incompatible with the File Support
Pack we've used, so even the latest axon2run will not recognize these files.
If you use version 10, you must save your files in version 9 format.
These version 9 format files will be ABF floating point data, which the
newest axon2run can convert directly.
For older versions of axon2run, you'll need to reopen the version 9 file
in Axoscope 9, and save as binary integer.
In version 10.1 and later of Axoscope, you can directly "Save As" or
"Export" to the older version binary integer ABF file type: for Save As,
select ABF 1.8 (integer), and for Export, select pCLAMP9 ABF (integer).
Finally, the pCLAMP 9.0 manual also has this to say, which is relevant for
axon2run and likely as well for any other third-party program that can
read ABF files:
"In order for Clampex 9 binary integer data files to be recognized by
software packages compatible with pCLAMP 6 binary data files, it may be
necessary to record the data with the Clampex Program Option configured to
'Ensure data files and protocols are compatible with pCLAMP 6', and to
change the data file's extension from 'abf' to 'dat'."
Older versions of axon2run did require the .dat extension, but current
versions allow either.
However, check to see if this option has been set.
Note: this option also exists in Axoscope 9's Program Options,
so you should set it there too, if using Axoscope to capture data.
However, this option has no effect in Axoscope or Clampex version 10.
In addition to the
program mentioned above, we have a number of other programs for importing
data from other sources.
The bin2run and dat2run programs were written to deal with lagacy data files
at the SCRC, but could be used as the starting point for other conversion
They both deal with averaged triggered sweeps, which go into a
.frm file, so this is the sort of data for which they'd
best be adapted.
You can find the source files for these under the
directory on any system on which the software is installed.
Also in that directory is a script called pp2run, which had been used at
one point for importing data from Peak Performance software.
also have a few more recent scripts,
which convert data from custom formats we've had to deal with.
These scripts make use of the
program, to convert interleaved 16-bit binary numbers into our run file format.
These could be adapted to other similar formats, by changing the code that
parses the custom header.
For dealing with programs that have an ASCII export capability, you may have
better luck with the
We've used it for importing data from the GENESIS neural simulation, but it
is flexible and generic enough to be suitable for many ASCII export formats.
Finally, you can download and use Synaptosoft Inc.'s
to convert other file formats, such as CED's Spike2 exported binary files, or
Igor Text or Binary files, into ABF files.
These can then be converted by
The ABF Utility can be downloaded separately, or as part of demo of their
Mini Analysis program.
This utility runs on Windows systems, so you'll then need to transfer the
ABF files to your analysis system via FTP or some other means before running
axon2run on them.
There are a few wrikles to printing support on the Mac,
depending on which version of Mac OS X you're running.
It's set up by default for a PostScript printer, and should print
to the user's currently selected default printer.
For OS X 10.2, printing to non-PostScript printers is a bit tricky,
as you then have to use selectlp to pick a different printer type
from the very limited set of printers the software supports directly.
Effectively, only PostScript and PCL printers are supported by the software,
as the other printer drivers are for more specialized or obsolete devices.
We haven't expanded this list because a) we tend to use PostScript printers
almost exclusively now, and b) on Linux systems (at least Red Hat ones),
and newer OS X releases,
the printing system emulates PostScript for any non-PostScript printer,
so from the analysis software's perspective it's almost always printing to a
For OS X 10.3 and up, the printing system should emulate a PostScript
printer when printing to non-PS printers, as most current Linux systems do.
We've had reports that every so often, printing on
10.3 simply stops working until you restart the system.
We haven't been able to reproduce this problem on 10.2,
nor isolate the cause on 10.3.
If you are unable to print directly from the analysis software to your
printer, we recommend plotting to files, and then using hpgl2pdf to convert
to PDF files, which you should then be able to open and print in the Preview
application on the Mac, or in Acrobat Reader on any other system.
For hpgl2pdf to work on OS X 10.2, you need to install the ghostscript
package on your Mac. It's available from a number of
but probably the easiest way is to download the "ESP Ghostscript" (espgs) package from
site, then edit your .profile file to add /usr/local/bin to your PATH
environment variable (e.g.: export PATH="$PATH:/usr/local/bin" ).
Any of the analysis methods that produce a graph (selected using
Analysis/Graph/...) can export the coordinates of their plotted data using
the Bins-save operation from the main menu of analysis.
By default, it will export just the Y axis coordinates, but that can be
changed using the
Number list format
parameter (Set/Disp-opt/Num-format), and set it to
Then when you use Bins-save to save the data, the coordinate pairs will
be output as comma-separated values, one per line.
This is described in more detail in the help for the
Number list format
parameter and the
Analysis documentation on Bins-save
(scroll down to the part with the heading
"Saving ASCII data values in a graph").
Note that the output file will also contain a few header and footer lines,
which won't usually pose a problem for programs that import .csv files,
but if they do you can edit them out.
There are a few possible causes of that warning message, all stemming
from the fact that one of the analysis parameters in the xxx.prm file
is actually the full pathname to the corresponding run file. This was
done to allow flexibility in saving multiple parameter files for a given
run. Rather than only allowing a single parameter file, with the same
name as the run file, the parameter file stores the run file name as
one of the parameters. Unfortunately, that flexibility has given rise
to situations where the parameter and run file names get out of sync
with each other, or with what the user would expect the correspondence
to be between the two, so that warning was added to alert the user of
this and allow an opportunity to clear up the ambiguity.
Most commonly, the warning results from copying the data files
from one directory to another, and then analyzing the data in the
new directory. Normally, you can put files in another directory, and
analysis will find the run file anyway. It looks first in the original
directory, then in the directory where the parameter file is. However,
if you have two copies of the data on your system, one in the original
location, and one in a new location, the parameter file copied to the
new location still points to the run file in the original location -
in this case, analysis gives the warning because it will use the run
file in the original location instead of the new copy in the same new
location as the parameter file you just told it to use.
To make that clearer, here is an example: Let's say you have a file called
cell1.frm, in /home/exp/aug9, and you analyze it. Your parameters will
be saved in /home/exp/aug9/cell1.prm. One of the parameters in cell1.prm
is the run file name, /home/exp/aug9/cell1.
Now, if you copy all of the aug9 directory to /data/2011/aug9, and then
you run analysis /data/2011/aug9/cell1, one of two things can happen:
if the original copy in /home/exp/aug9 is gone, then analysis will
look there first, see the file isn't there, and will look instead in
/data/2011/aug9, where the parameter file is, and use the run file there
without any warnings.
if the original copy is still there in /home/exp/aug9/cell1.frm,
then analysis will look there, find it, and use that run file, even
though you're using a parameter file in /od/aug9 - this is because the
run file parameter in that .prm file still contains the full name of
the original location.
In this second case, you get a warning, because this is a situation that
can confuse the user - while you're tempted to think you're looking at
the data in the new location, you're actually looking at data in the old
location, but only using analysis parameters in the new location. In fact,
if you modify waveform parameters at this point, they will be saved in the
old location, not the new one! Only the analysis parameters are in the new
location. This fix is to do a Set/File operation, and update the path name
for the run file location to give the new location - or just remove the
directory names from the run file name if it's in the current directory.
Another case where you'll get that warning is if you run something like:
analysis cell1, and then Set/File to cell2. In this case it gives the
warning because you will be making cell1.prm point to cell2.frm, rather than cell1.frm. Set/File changes the "Run file" analysis parameter, but if you do that in a way that causes an ambiguity, such that the parameter file name would imply it should refer to a different run file name than the parameter is actually set to, then you get the warning. This warning will happen whenever the ambiguity is detected in a Load, Keep or Set/File operation. In the case of Set/File, the problem usually stems from using this operation for the wrong reason: if you want to switch from analyzing one file to another, usually you should do this with the Load operation, rather than the Set/File. Set/File is for transferring a set of analysis parameters from one run file to another, but then you should be careful to do a Keep operation to save the new parameters and new run file name into a new parameter file, rather than the parameter file for the previous run. E.g. rather than having cell1.prm saved with the "Run file" pointing to cell2.frm, make sure you save the new parameters as cell2.prm. If you want multiple parameter files for a single run file, make sure none of the parameter file names conflict with existing run file names, e.g. cell3-ar.prm, cell3-atf.prm and cell3-agwvr.prm can all refer to cell3.frm without triggering the warning.
Finally, another case where this problem happens is if you change file
using the Load operation, and analysis detects that you have unsaved
parameters and asks you if you want to save the modified parameters, but
when it asks for the name of the parameter file to Keep, you instead type
the name of the parameters (or run) that you want to Load. Again in this
situation, the "Run file" parameter will point to a different run than the
parameter file name implies it should, because you're telling the analysis
program, inadvertently, that it should clobber the parameter file you
want to load with the parameters you wanted to save for the previous run.
In all these cases, the fix is the same: pay close attention to which
parameter file you're currently using, and which run file it really ought
to be using as its "Run file" analysis parameter. Then use Set/File to
correct the run file name and path, then Keep the updated parameters. If
you do that, it should fix things so you don't get the warning any more.
To avoid this warning causing problems with shell scripts that run analysis,
and might run into parameter files where the "Run file" parameter is out of
sync in this way, there is a simple fix to dismiss the warning without analysis
falsely dropping keystrokes from the input sequence in the script.
Just put a space right at the start of the input to analysis, to clear away
the warning before any commands are read. If there's no warning, the extra
space will have no effect.