1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 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 2015 2016 2017 2018 2019 2020 2021 2022 <2023> 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Weird behaviour in wait=True when using epics.Motor.get(something,something,wait=True) |
From: | "Marco A. Barra Montevechi Filho via Tech-talk" <tech-talk at aps.anl.gov> |
To: | Matt Newville <newville at cars.uchicago.edu> |
Cc: | SWC <swc at lnls.br>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Wed, 18 Jan 2023 11:44:49 +0000 |
>Wouldn't
the idea of changing that setting mean that you expect the timing for a "put()" to be changing too?
Yes, i believe that makes sense. In any case, CNEN field was the one i detected the behavior, but it also happens with VELO and i suspect with others too. Anyway, i think Mark's explanation about how wait=True works in python code makes it clear why the return from put can take weird amounts of time to happen. In any case, its clear that wait=True wont solve for what i want. Callbacks might do the work, but i have doubts about it. > But, I would also suggest not mixing shell and Python for any timing work. Makes total sense, not very smart of my part now that i think about it. Im going to test a few things with callbacks and report any useful result. Thanks! Best regards, Marco From: Matt Newville <newville at cars.uchicago.edu>
Sent: 17 January 2023 15:57 To: Marco A. Barra Montevechi Filho <marco.filho at lnls.br> Cc: Mark Rivers <rivers at cars.uchicago.edu>; SWC <swc at lnls.br>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>; mooney at anl.gov <mooney at anl.gov> Subject: Re: Weird behaviour in wait=True when using epics.Motor.get(something,something,wait=True) Marco,
I have to admit I do not know for sure when a put to a Motor Record's CNEN field would take a lot of time. It seems odd to be changing a motor from closed- to open-loop control with any frequency
at all, especially while also moving the motor and/or expecting positions to be reported well. Wouldn't the idea of changing that setting mean that you expect the timing for a "put()" to be changing too?
That said, I would say that getting callbacks themselves should be fairly predictable. But, I would also suggest not mixing shell and Python for any timing work. That will include the startup
of Python and the initial connection of Epics PVs. Those should not be slow, but it will involve network traffic so not completely determined.
I might suggest starting with something like this:
#######
import epics
import time
def check_values(pvname, value, timestamp=0, **kwargs):
print('callback for ', pvname, value, timestamp)
motor = epics.Motor('MGN:B:E873A:DIAG:X:m1')
# get the value of the CNEN field to make sure that PV/Channel is connected
cnen_val = motor.get('CNEN')
# with that connected, add the callback
motor._pvs['CNEN'].add_callback(check_value)
SLEEP_TIME = 0.1
for i in range(10):
print('# Loop ', i)
time.sleep(SLEEP_TIME)
for cnen_val in (0, 1, 0, 1, 0, 1, 0, 1, 0, 1):
motor.put('CNEN', cnen_val, wait=False)
time.sleep(SLEEP_TIME)
print("LOOP DONE")
time.sleep(1)
#############
or some variations from that. Unless the SLEEP_TIME is way too fast for processing, I think you should get all the callbacks run. Or, you could try using `wait=True` for that put.
On Tue, Jan 17, 2023 at 12:26 PM Marco A. Barra Montevechi Filho <marco.filho at lnls.br> wrote:
--Matt Newville <newville at
cars.uchicago.edu> 630-327-7411
|