Unexpected behavior when setting waveform PVs

[Érico Nogueira Rolim via Tech-talk <tech-talk at aps.anl.gov>]

​Hi!

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

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.

Thank you,
É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.