Re: Commands with synchronous answers from python

[Matthew Newville via Tech-talk <tech-talk at aps.anl.gov>]

I could be misunderstanding the goal, but it seems slightly odd to explicitly use async and await, but then want things to be synchronized. Have you considered something like (using pyepics: `pip install pyepics​`): from epics import caget,

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

 

ZjQcmQRYFpfptBannerEnd

I could be misunderstanding the goal, but it seems slightly odd to explicitly use async and await, but then want things to be synchronized.

Have you considered something  like (using pyepics: `pip install pyepics​`):

    from epics import caget, caput

    def do_stuff(): 

        caput('Variable.PROC', 1, wait=True, timeout=10)

        test = caget('Variable.VAL') 

        print(str(test)) 

   while True:

       do_stuff()

       # may want to add some delay or other step here, 

       # unless the goal is to push PROC as often as possible.

That should wait for the put() to complete and fully process the record before going on to the next statement.  

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Érico Nogueira Rolim via Tech-talk <tech-talk at aps.anl.gov>
Sent: Monday, February 26, 2024 1:37 PM
To: Neidherr, Dennis Dr. <D.Neidherr at gsi.de>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: Commands with synchronous answers from python

 

This Message Is From an External Sender

This message came from outside your organization.

 

Hi! Response is inline

On 26/02/2024 06:51, Neidherr, Dennis Dr. via Tech-talk wrote:

This Message Is From an External Sender

This 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.