On 8/4/22 10:58 AM, Marco A. Barra
Montevechi Filho via Tech-talk wrote:
Wait, i think im still having
difficulties with the transform record:
i have a record defined as:
record(transform, "${BL}:${H}:${EQ}:StatusSeparator"){
field(DESC, "PV to process status bitmask")
field(COPT, "Always")
field(SCAN, "1 second")
field(INPA, "${BL}:${H}:${EQ}:StatusBitmask")
field(CLCA, "A&1")
field(OUTA, "${BL}:${H}:${EQ}:EnableStatus")
}
And it behaves as expected: dbpf StatusBitmask 1 makes
StatusSeparator.A field go to 1. Any other value in
StatusBitmask that i tried makes StatusSeparator go to 0.
Now if i add field(CLCB, "A&1") to the record, dbpf
StatusBitmask 1 makes both StatusSeparator.A and
StatusSeparator.B go to 1. Ok, makes sense.
Now if i change CLCB to "A&2", then dbpf StatusBitmask 1
makes dbgf StatusSeparator.A return 1 and dbgf StatusSeparator.B
return 0. Makes sense: bitwise AND between 1 and 2 is 0.
The curious thing now: dbpf StatusBitmask 2 makes dbgf
StatusSeparator.A return 0 (makes sense: 1&2=0) and dbgf
StatusSeparator.B return 0. This doesnt make sense to me since
2&2=2.
Am i doing something wrong?
If I understand it correctly, the result of CLCA gets written back
to the A field, overwriting the 2 that was read in with 0, so the
CLCB _expression_ is now 0&2 which is 0.
Don't set CLCA at all, start with CLCB, or use a different INP
field for the status input bits. You probably don't need to set
COPT at all if you do that.
- Andrew
Thanks, Tim! Thats exactly what was missing, the record works
as expected now.
Apparently i was looking at another documentation page which
does not have the COPT field specification:
https://epics.anl.gov/bcda/synApps/calc/R2-4/transformRecord.html
This page has it:
https://epics.anl.gov/bcda/synApps/calc/transformRecord.html
Best regards,
Marco
Versions earlier than 5.8 did not have the COPT
field. Release notes Versions earlier than 5.7
did not post fields with the DBE_LOG attribute.
Versions earlier than 5.6 expected sCalcPostfix
to allocate the postfix-_expression_ array.
sCalcPostfix no longer does this, and the
transform record changed as a consequence.
epics.anl.gov
|
Hi Marco,
I think you need to look at the transform record's COPT
field. To serve the original purpose of the record, CLCA is
not performed if A has changed since the last time the
record was processed. The non-default behavior you want
requires that you set COPT to "Always"
Good morning, all!
Im trying to implement the transform field in an IOC but
im not getting the expected result:
i have an analog in record reading a
bitmask value from a modbus register. Since the bitmask
has 16 bits, i want to perform 16 bitwise operations to
transform each bit in a
binary in record thus transforming each 0 or
1 into a different string.
Since i dont want to need to create 16 calcout
records, i thought i could use the
transform record to perform all bitwise
operations and push each one of them into a different
binary in record. So after reading the
documentation i tried to perform a calculation with
transform just for testing:
record(ai,
"${BL}:${H}:${EQ}:BitmaskGetter")
{
field(DESC,
"Bitmask
used by other pvs.")
field(DTYP,"asynInt32")
field(INP,"@asyn(SIP_EMODBUS_1_1_Rd_Status,0,1000)MODBUS_DATA")
field(SCAN, "I/O
Intr")
field(FLNK,
"${BL}:${H}:${EQ}:StatusSeparator")
}
record(transform,
"${BL}:${H}:${EQ}:StatusSeparator"){
field(DESC,
"PV to
process status bitmask")
field(INPA,
"${BL}:${H}:${EQ}:StatusBitmask")
field(CLCA,
"A+1")
field(OUTA,
"${BL}:${H}:${EQ}:EnableStatus")
field(SCAN,
"Passive")
}
record(bi,
"${BL}:${H}:${EQ}:EnableStatus"){
field(DESC,
"Power
supply status")
field(ZNAM,
"Stopped")
field(ONAM,
"Started")
}
So i expected that while caget in BitmaskGetter returns 0,
caget into StatusSeparator.A would return 1 and
EnableStatus would return "Started". It is not what
happens: StatusSeparator returns 0 and EnableStatus
returns "Stopped".
To test if the calculation is right, i tried substituting
the transform record to a
calc one:
record(ai,
"${BL}:${H}:${EQ}:BitmaskGetter")
{
field(DESC,
"Bitmask
used by other pvs.")
field(DTYP,"asynInt32")
field(INP,"@asyn(SIP_EMODBUS_1_1_Rd_Status,0,1000)MODBUS_DATA")
field(SCAN, "I/O
Intr")
field(FLNK,
"test_calc")
}
record(calcout,
"${BL}:${H}:${EQ}:StatusSeparator""){
field(DESC,
"PV to
process status bitmask")
field(INPA,
"${BL}:${H}:${EQ}:StatusBitmask")
field(CALC,
"A+1")
field(OUT,
"${BL}:${H}:${EQ}:EnableStatus")
}
record(bi,
"${BL}:${H}:${EQ}:EnableStatus"){
field(DESC,
"Power
supply status")
field(ZNAM,
"Stopped")
field(ONAM,
"Started")
}
And now caget into StatusSeparator returns 1,
StatusSeparator.A returns 0, BitmaskGetter returns 0 and
EnableStatus returns "Started", as expected.
So i figure field OUTA from the transform
record pushes the value in field A (which is zero) to the
EnableStatus link. If this is the case, is there any way
at all to push the result from CLCA to the EnableStatus
link? Also,in which field is the result from CLCA field
stored, if any?
Thanks in advance,
Marco
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.
--
Complexity comes for free, Simplicity you have to work for.
- Replies:
- Re: Implementing transform field Marco A. Barra Montevechi Filho via Tech-talk
- References:
- Implementing transform field Marco A. Barra Montevechi Filho via Tech-talk
- Re: Implementing transform field Mooney, Tim M. via Tech-talk
- Re: Implementing transform field Marco A. Barra Montevechi Filho via Tech-talk
- Re: Implementing transform field Marco A. Barra Montevechi Filho via Tech-talk
- Navigate by Date:
- Prev:
Re: Implementing transform field Mooney, Tim M. via Tech-talk
- Next:
Re: Implementing transform field Rolf Keitel 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: Implementing transform field Marco A. Barra Montevechi Filho via Tech-talk
- Next:
Re: Implementing transform field Marco A. Barra Montevechi Filho 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
|