Experimental Physics and
Industrial Control System

Hi! Response is inline

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.

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.

Replies:

Re: Commands with synchronous answers from python Matthew Newville via Tech-talk

References:

Commands with synchronous answers from python Neidherr, Dennis Dr. via Tech-talk

Navigate by Date:

Prev: Re: devAsynFloat64::processCallbackInput process read error Mark Rivers via Tech-talk

Next: Re: Commands with synchronous answers from python Matthew Newville 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: Commands with synchronous answers from python Neidherr, Dennis Dr. via Tech-talk

Next: Re: Commands with synchronous answers from python Matthew Newville 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>