EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
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  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 
<== Date ==> <== Thread ==>
Subject: Re: Unexpected behavior when setting waveform PVs
From: Andrew Johnson via Tech-talk <tech-talk at aps.anl.gov>
To: Érico Nogueira Rolim <erico.rolim at lnls.br>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Fri, 8 Jul 2022 10:30:35 -0500
Hi Érico,

On 7/8/22 8:13 AM, Érico Nogueira Rolim via Tech-talk wrote:
I am trying to construct a waveform record whose elements are strings, and in testing this, it seems the behavior for dealing with waveform elements, both from the caput utility and via DB links, has a few issues. Given a record like this:

record(waveform, "Labels"){
    field(DESC, "Labels")
    field(FTVL, "STRING")
    field(NELM, "4")
}

while caget behaves mostly as expected ("caget Labels.VAL[x]" with x from 0 to 3 picks the correct element from the PV), caput behaves in a very confusing way, without even pointing out errors:

caput Labels hi

inserts hi into Labels.VAL[0] and overwrites all other elements

caput Labels.VAL[0] hi

inserts hi into Labels.VAL[0] and overwrites all other elements

caput Labels.VAL[1] hi

*also* inserts hi into Labels.VAL[0] instead of Labels.VAL[1] and overwrites all other elements
The channel syntax 'record.field[n]' uses the Array channel filter on the IOC, which only supports get and monitor operations, not puts. The filter is completely ignored during a put, so it's equivalent to removing the filter part completely from the channel name. That should help to explain the behavior of this and your later examples.

caput -a Labels.VAL[1] 4 hi1 hi2 hi3 hi4

correctly inserts each hiX into each element, but having to specify the value for each element isn't very practical

The issue with writing into Labels.Val[1] (or any index) hitting the first element instead of the selected one can also be seen when using DB links, like in the following record:

record(stringout, "Labels-Set"){
    field(DESC, "Set first label")
    field(PINI, "YES")
    field(VAL, "hi1")
    field(OUT, "Labels.VAL[0]")
}

The first such record seems to work, but when an additional one, which touches Labels.VAL[1], is added, it instead overwrites Labels.VAL[0]. Interestingly, up to 3 such records still "work", in that they overwrite the first element of the waveform, but a fourth record leads to an error when the record is read during IOC startup:


Can't set "Labels.VAL" to "hi4"

and also unsets Labels.VAL[0] entirely.

>From some testing with a waveform holding LONG instead, the results seem to be consistent, so the issue is unlikely to be due to usage of STRING.

I am on Epics base 3.15.6, but have confirmed this behavior with 3.15.9. As I understand it, Epics base 7 supports an INP field, and it would be enough for my use case, but that's not currently an option for me.
Ben Franksen worked on implementing a filter for writing array ranges 1-2 years ago. This pull request represents his latest code but hasn't been merged yet. Until it is you will have to assemble your labels into an array either on a CA client (e.g. a SNL sequence program) or using something like an aSub record. The acalc (array calculation) record from the synapps collection should also be able to do it, but that could be quite a memory sink unless you configure it carefully.

Alternatively, don't store your labels in an array. Having separate records for each element does take a bit more RAM, but the asymmetry of the get/put support is why I probably wouldn't do that myself.

HTH,

- Andrew

-- 
Complexity comes for free, Simplicity you have to work for.
References:
Unexpected behavior when setting waveform PVs Érico Nogueira Rolim via Tech-talk
Navigate by Date:
Prev: RE: How to safely implement an asynPortDriver with SCAN records Mark Rivers via Tech-talk
Next: Re: How to safely implement an asynPortDriver with SCAN records É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 
Navigate by Thread:
Prev: Unexpected behavior when setting waveform PVs Érico Nogueira Rolim via Tech-talk
Next: How to safely implement an asynPortDriver with SCAN records É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 
ANJ, 14 Sep 2022 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·