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: | Looking for idiomatic/maintainable pattern for ai/ao record unit conversion |
From: | Érico Nogueira Rolim via Tech-talk <tech-talk at aps.anl.gov> |
To: | tech-talk <tech-talk at aps.anl.gov> |
Date: | Tue, 27 Jun 2023 21:02:40 +0000 |
Hi!
I'm looking into using the ASLO and ROFF fields in my ai and ao records. These records are used for current and voltage values which are in ADC and DAC counts, and which I'd like to convert to amperes and volts. Our setup for current (voltage is equivalent) has the following structure (SP and RB are setpoint and readback, respectively): Current-SP (ao) -> CurrentConvSP (calcout) -> CurrentRaw-SP (longout and asynInt32) -> hardware and hardware -> CurrentRaw-RB (longin and asynInt32) -> Current-RB (ai) CurrentConvSP is necessary because, as I understood it, the calc and calcout records don't have device support. It and Current-RB use another two PVs in their calculations: CurrGain (conversion factor between amperes and ADC counts) and CurrOffset (raw current measured when current is zero). My intended structure using the ASLO and ROFF fields was: Current-SP.VAL (ao and asynInt32) -> Current-SP.RVAL -> hardware and hardware -> Current-RB.RVAL -> Current-RB.VAL (ai and asynInt32) My initial attempt at using ASLO and ROFF was with database links to CurrGain and CurrOffset, which didn't work. It seems the record only really expects numeric values there. I have worked around this so far by turning CurrGain and CurrOffset into dfanout records, but this requires that whenever I add a new record that uses some current information from the hardware, I update the dfanout outputs. It doesn`t seem scalable and feels like a mistake would be easy to miss. These values, especially CurrOffset, can be configured in the field, so it isn't enough to define a variable for them when reading the template. *Is there some alternative I`m missing for propagating the values I'd like to have in all ASLO and ROFF fields?* On top of that, my IOC has two types of users: - operators and high level scripts, who use current in amperes - experts, who use currents in amperes and in hardware units The experts require being able to control the hardware using hardware units, and I expected this to be supported by writing into the RVAL field, but it isn't (caput writes, succeeds, and the value doesn't change). I had to change my setpoint chain to the one below, to work around this: Current-SP (ao and Raw Soft Channel) -> CurrentRaw-SP (longout and asynInt32) -> hardware It is still better than the previous version, since the math and input links don't have to be copied for each new record every time and we have one fewer record, but being able to write into Current-SP.RVAL seems like it would be the ideal solution. It would even have the advantage of supporting updating VAL for the new RVAL, which would work around the issue we currently face (with the new or old scheme) of writes into raw setpoints not being propagated to normal setpoints. *Are writes into RVAL supposed to work / going to work in the future, or should I stick to the intermediary record, or is there some better way?* Cheers and thank you for the help, É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. |