EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: motor record DLY and STOP problem
From: "Pearson, Matthew R." <[email protected]>
To: Torsten Bögershausen <[email protected]>
Cc: "[email protected] list" <[email protected]>
Date: Wed, 11 Nov 2015 16:14:38 +0000
Hi Torsten,

It should work with any motor record. Here’s a bash script that should do it:

#/bin/bash
# Assume we are starting from 0 position
PV=BL99:Mot:Sim1
caput -c ${PV}.DLY 5
caput -c ${PV}.VELO 1
caput -c ${PV}.ACCL 1
sleep 1
# Do a move that lasts about 2 seconds
caput ${PV} 1
# Wait for the move to finish so we are in DLY wait
sleep 4
caput ${PV}.STOP 1


The main thing is to wait for MOVN to go to 0, then do a STOP before DMOV goes to 1. Although, you may have problems reproducing it if you have noisy encoders, or the settling time of the motor is long. Try the simulation driver in that case. Here is how I set the simulation driver up in the IOC startup script:

motorSimCreateController("sim1", 6, 0, 0)
motorSimConfigAxis("sim1", 0, 10000000, -10000000, 0, 0)

and here’s the record:

record(motor,"BL99:Mot:Sim1")
{
        field(DESC,"sim")
        field(DTYP,"asynMotor")
        field(DIR,"0")
        field(VELO,"1")
        field(VBAS,"0")
        field(ACCL,"0.1")
        field(BDST,"0")
        field(BVEL,"0")
        field(BACC,"0")
        field(OUT,"@asyn(sim1,0)")
        field(MRES,"0.001")
        field(PREC,"3")
        field(EGU,"mm")
        field(DHLM,"50000")
        field(DLLM,"-50000")
        field(INIT,"")
        field(RTRY,"0")
        field(DLY,"0")   
        field(HVEL,"1")
        field(SREV, "200")
        field(RRES, "0")
        field(TWV, "1.0")
        field(ERES, "0")
        field(JAR, "0")
        field(UEIP, "0")
        field(URIP, "0")        
        field(RDBL, "")         
        field(VMAX, "5")
        field(OFF, "0")
        field(RDBD, "0")
        field(FOFF, "0")
        field(ADEL, "0.5")
        field(MDEL, "0")
        field(NTM, "YES")
        field(HLSV, "MINOR")
        field(SDIS, "BL99:Mot:Sim1:SDIS.VAL") 
        info(autosaveFields_pass0, "DVAL OFF MRES ERES")
        info(autosaveFields, "DIR DHLM DLLM TWV VBAS VELO ACCL BDST BVEL BACC RDBD EGU RTRY UEIP URIP DLY PREC DISA DISP FOFF OFF FRAC OMSL JVEL JAR ADEL MDEL HVEL DESC")
        info(archive, "Monitor, 00:00:01, VAL OFF RBV DMOV MISS MSTA STAT LVIO HLS LLS")
}



Cheers,
Matt


> On Nov 11, 2015, at 10:28 AM, Torsten bögershaus <[email protected]> wrote:
> 
> Hej Matt,
> you say, that the problem could be easy re-produced.
> Is there any chance to send a recipt here ?
> 
> A database ?
> And a shell script which sets all the values...
> (At least DLY is used, what more ?)
> A shell script, or similar, to reproduce ?
> 
> BR
> /Torsten
> 
> 
> Am 11.11.2015 um 16:18 schrieb Pearson, Matthew R. <[email protected]>:
> 
>> 
>> Hi,
>> 
>> There seems to be a problem with issuing a motor record STOP while we are waiting for a DLY settling time to expire. I can lock up the motor record if I issue a STOP after MOVN has gone to zero and before DMOV goes to 1. This only seems to be a problem if there are no further updates from the driver (so we have already stopped moving). It’s easy to reproduce using a simulation driver.
>> 
>> The problem can be cleared by either doing a SPMG cycle (stop, then go), or by setting any field that would cause a driver callback, which causes record processing, like changing CNEN. At the moment, the DLY seems to be repeated after the problem is cleared. So if I have a 5s DLY, I issue a STOP 4s into it, then I clear it by changing CNEN, then DMOV goes to 1 after a further 5s.
>> 
>> I suspect the desired behavior would be to cancel the delayed callbackRequest that implements the DLY, and not wait for it to expire, at least in this case, since we have already stopped moving then the DLY is probably too long anyway. And probably in other cases I suspect we want a put_callback to complete as soon as we issue a STOP, which is what happens when a STOP is done during a normal move. I can have a go at fixing this if that sounds like reasonable behaviour.
>> 
>> This is motor record version 6-8-1.
>> 
>> Cheers,
>> Matt
>> 
>> 
>> Data Acquisition and Control Engineer
>> Spallation Neutron Source
>> Oak Ridge National Lab
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 



References:
motor record DLY and STOP problem Pearson, Matthew R.
Re: motor record DLY and STOP problem Torsten bögershaus

Navigate by Date:
Prev: Re: motor record DLY and STOP problem Torsten bögershaus
Next: Re: CSS editor [email protected]
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: motor record DLY and STOP problem Torsten bögershaus
Next: Re: motor record DLY and STOP problem Torsten Bögershausen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·