Re: Same sscan record step size for all positioners not possible?

["J. Lewis Muir via Tech-talk" <tech-talk at aps.anl.gov>]

On 09/24, J. Lewis Muir wrote:
> On 09/24, J. Lewis Muir wrote:
> > For example, attached is a screenshot showing this behavior.  I have
> > positioners 1-3 configured as follows:
> > 
> >   START: 0.0
> >   CENTER: -0.7
> >   END: -1.4
> >   STEP: -0.05
> >   WIDTH: -1.4
> >   ABS/REL: RELATIVE
> > 
> > But only one positioner can apparently have STEP set to -0.05.  In this
> > case, positioner 1 has STEP set to -0.05.  The STEP for positioner 2 and
> > 3 is -0.052.  If I change STEP of positioner 2 to be -0.05, then STEP of
> > positioner 1 and 3 becomes -0.052.
> 
> Looking at the R2-11-6 sscanRecord.c source code
> 
>   github.com/epics-modules/sscan/blob/f03da19eb11a5aa648d63cf1f26d95acd6172e28/sscanApp/src/sscanRecord.c#L4644
> 
> , I see this in the SPC_SC_I (step increment changed) case of the
> adjLinParms function:
> 
>   4643 } else {
>   4644   pParms->p_si = (pParms->p_ep - pParms->p_sp) / MAX(1,(psscan->npts - 1));
>   4645   POST(&pParms->p_si);
>   4646 }
> 
> pParms->p_si is Step Increment, pParms->p_ep is End Position,
> pParms->p_sp is Start Position, and psscan->npts is Number of Points.
> So in my example above, I think this will evaluate as follows (but I
> haven't actually confirmed this with a debugger or print statement):
> 
>   pParms->p_si = (-1.4 - 0.0) / MAX(1,(28 - 1))
>                = -1.4 / 27
>                = -0.052
> 
> If that's what's happening, then this would explain where the -0.052
> is coming from.  Don't know why it subtracts 1 from the number of
> points, though.

I realized that I was wrong in thinking that the number of points should
be 28.  Yes, -1.4 divided by -0.05 is 28, and yes, that's what NPTS
(number of points) was automatically set to by the sscan record when I
changed STEP of positioner 1, but data needs to be read at the first
positioner point, so that adds one more point, so the number of points
should actually be 29.  I think that's the real problem: when I set STEP
of positioner 1 to -0.05, NTPS gets set to 28, but I think it should
instead get set to 29.  If I set NPTS to 29, then STEP of positioner
2 and 3 gets set to -0.05, which is correct, and STEP of positioner 1
remains set to -0.05, which is correct, and if I then run the scan, all
positioners get stepped exactly -1.4 from where they were, so it works.

The thing that causes me to doubt my conclusion, though, is that it's
hard to believe that I'm the first person to run into this for a record
that's been around for over thirty years.  Am I right that this is a
bug?

BTW, I tried sscan R2-12, and it exhibits the same behavior.

Lewis