sscan 2-7
- saveData is not ready for 64-bit architectures. It writes 1D files
correctly, but not 2D or higher.
sscan 2-6-6
- On Linux, Solaris, and probably other non-real-time operating systems,
saveData can write corrupted data files for 2D and higher scans, because
monitored DATA fields from sscan records can be received out of order.
This bug affects 2.6.6 and all earlier releases of the sscan module.
- scans with any fly-mode positioners and no detector triggers fail to
launch fly-mode positioners to the end point.
- saveData is not ready for 64-bit architectures
sscan 2-6-4
- saveData did not check all chids before using them, leading to the
task crashing when PV's did not connect.
sscan 2-6-3
saveData crashed under tornado 2.2
- .
sscan 2-6-2
- saveData occassionally writes garbage to the file-version number (the first
four bytes of an .mda file).
sscan 2-6-1
- Callback counters are susceptible to a race condition that leads the sscan
record to think detector values have been received over channel access when
they might not have been received, and to hang waiting for values that have,
in fact, been received.
- The sscan record renews positioner links unnecessarily during multidimensional
scans.
sscan 2-6
- Callback counters are susceptible to a race condition that leads the sscan
record to think detector values have been received over channel access when
they might not have been received, and to hang waiting for values that have,
in fact, been received.
- The sscan record renews positioner links unnecessarily during multidimensional
scans.
sscan 2-5-7
- Callback counters are susceptible to a race condition that leads the sscan
record to think detector values have been received over channel access when
they might not have been received, and to hang waiting for values that have,
in fact, been received.
- The sscan record renews positioner links unnecessarily during multidimensional
scans.
- The sscan record doesn't correctly handle writes to PnPA (the arrays
used for table scans).
- saveData aborts its initialization when its initialization file lacks a
[basename] section, and fails to connect to sscan records.
sscan 2-5-6
- Callback counters are susceptible to a race condition that leads the sscan
record to think detector values have been received over channel access when
they might not have been received, and to hang waiting for values that have,
in fact, been received.
- The sscan record renews positioner links unnecessarily during multidimensional
scans.
- saveData's init file cannot usefully specify PV names containing several
characters that are legal for a PV name.
sscan 2-5-5
- saveData was writing scan dimensions to the wrong offset in the data file
header, under some circumstances, corrupting the header so that some readers
could not understand the file.
- Prefix length was inconsistently enforced, with the result that the maximum
number of characters (exclusing the trailing null) was actually eight, instead
of nine.
sscan 2-5-5
- saveData was writing scan dimensions to the wrong offset in the data file
header, under some circumstances, corrupting the header so that some readers
could not understand the file.
- Prefix length was inconsistently enforced, with the result that the maximum
number of characters (exclusing the trailing null) was actually eight, instead
of nine.
sscan 2-5-4
- scanSee (a display program not included in the sscan module) gets confused
because saveData's messages to users have been reformatted.
- the sscan record does not behave correctly if autosave restores an
illegal value for NPTS.
sscan 2-5-3
- Scans hang if the data-file fails.
sscan 2-5-2
- Scans can hang because of a race condition in doPuts() and a
call to recDynLinkPutCallback() that failed for a reason other
than notifyInProgress.
sscan 2-4
- The before-scan link (.BSPV, .BSCD) is broken.
- If a PV link is changed while the previous value is still
connecting, the software will hang.