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> 2025 | 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> 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Commands with synchronous answers from python |
From: | Érico Nogueira Rolim via Tech-talk <tech-talk at aps.anl.gov> |
To: | "Neidherr, Dennis Dr." <D.Neidherr at gsi.de>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Mon, 26 Feb 2024 19:37:36 +0000 |
Hi! Response is inline
This Message Is From an External SenderThis message came from outside your organization.Dear all, right now I am making the first steps to migrate our old control system to a combination of EPICS and python. And because of the workload I have to do the migration stepwise and at some points I am forced to use specific interfaces / solutions which are already existing.
Hello and welcome!
One of this solution, is that it seems I need a method to trigger the processing of a StreamDevice device in a python code, wait until the processing is done, and continue with the answer (and all that should be an atomic process, so no-one should interrupt the device in the meantime). Since this is a very basic process I would like to show you my solution and I would like to ask if you may have a better one (especially because I think my solution might have a "problem"). So the following python code shows how it might work: import asyncio from aioca import caget, caput, run async def do_stuff(): await caput('Variable.PROC', 1, wait=True, timeout=10) await asyncio.sleep(0.001) test = await caget('Variable.VAL') print(str(test)) run(do_stuff(), forever=True) I tested this code and it already fulfills several requirements: - the process on the (Stream-)device side is an atomic action. If a second sender tries to trigger a process, he has to wait and he does not get the result of the first one. - it can be set up quite easy, only one EPICS record necessary for the whole process (because I start the trigger through the PROC field). But there might be a drawback: - it was only working since I included the "await asyncio.sleep(0.001)" in the code above. Otherwise I do not get a correct answer, I simply get the value from one cmd before. The reason might be that the "wait=True" in the caput-cmd waits only until the processing on the device side is finished and not until the result is already published. My problem is now: I am not sure, but this value might depend on the network and even 1ms might not be enough in all situations. So as I already wrote: Does anyone have an idea how to solve this problem? Or should I go for a completely different solution (I am an EPICS beginner, so there might be a much smoother way I do not see yet).
To be sure the record has been processed once you use `caget`, you could check some timestamp field from the AugmentedValue return value. Comparing it to your last known timestamp can tell you whether the PV has been processed since you last checked.
However, since busy looping on that is not a good pattern, you should probably use the `camonitor` interface from aioca instead; the library itself will let you know when there is an event for the record. I don't know if this keeps your "atomic" property (though I don't believe the original was atomic either). Can you explain why you need this to be atomic? What sort of actions does the record perform? I don't think that's a common pattern, especially when controlling records from outside of the IOC (I am welcome to corrections on that).
Thanks a lot, and Greetings Dennis
Cheers
Érico
Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual consulta ao remetente antes de copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem por engano, por favor avise o remetente e apague-a imediatamente.
Disclaimer: This email and its attachments may contain confidential and/or privileged information. Observe its content carefully and consider possible querying to the sender before copying, disclosing or distributing it. If you have received this email by mistake, please notify the sender and delete it immediately.