Repository navigation
PVA link can't be "nested" #59
Description
A PVA link in a "calc" link fails with DBLINK* corrupt on being unable to locate the associated record field in order to determine a native field type for the lset.
pva2pva/pdbApp/pvalink_lset.cpp
Lines 28 to 32 in 3b9990e
record(ai, "MTEST-JSON:A1") {
field(VAL, 1)
field(PINI, 1)
}
record(ai, "MTEST-JSON:inp_json_calc") {
field(INP,
{
"calc": {
"expr": "A|B|C",
"args": [
{
"const": 0
},
0,
{
"pva": {
"pv": "MTEST-JSON:A1",
"proc": "CP"
}
}
]
}
}
)
}
Activity
mdavidsaver commentedon Aug 17, 2023
This logic is failing as the calc link type has its own link "fields". It is not immediately clear to me how a native field type could be inferred.
At present, the only use for this type is to identify
DBF_INLINK.pva2pva/pdbApp/pvalink_channel.cpp
Lines 387 to 395 in 3b9990e
@anjohnson I would appreciate your thoughts on this situation.
anjohnson commentedon Aug 17, 2023
Could the pvalink not wait to decide whether to enable monitors through the PVA channel until the first call to either
pvaGetValue()orpvaPutValue()? If it waits it will also discover what data type and how many elements the caller is looking for (e.g. has the user pointed an ai or subroutine input link at a large array so they only want the value of the first element).Oh, and just because the ultimate record link field (
INPabove) is an input, that doesn't mean that the pvalink will always be used as an input, it might be configured for the calc link'soutfield — I think that's allowed, so it can't really know until it gets called.