Experimental Physics and Industrial Control System
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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
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.
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).
Thanks a lot, and
Greetings Dennis
- Replies:
- Re: Commands with synchronous answers from python Érico Nogueira Rolim via Tech-talk
- Navigate by Date:
- Prev:
Re: GPIB connection problem with EPICS 7 Miroslaw Dach via Tech-talk
- Next:
Generating metrics for IOC applications Ralph Lange via Tech-talk
- 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>
- Navigate by Thread:
- Prev:
Re: GPIB connection problem with EPICS 7 Miroslaw Dach via Tech-talk
- Next:
Re: Commands with synchronous answers from python Érico Nogueira Rolim via Tech-talk
- 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>