Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PVA link can't be "nested" #59

Open
mdavidsaver opened this issue Aug 17, 2023 · 2 comments
Open

PVA link can't be "nested" #59

mdavidsaver opened this issue Aug 17, 2023 · 2 comments

Comments

@mdavidsaver
Copy link
Member

mdavidsaver commented Aug 17, 2023

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.

for(long status = dbFirstField(&iter.ent, 0); !status; status = dbNextField(&iter.ent, 0)) {
if(iter.ent.pfield==plink)
return iter.ent.pflddes->field_type;
}
throw std::logic_error("DBLINK* corrupt");

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"
                        }
                    }
                ]
            }
        }
    )
}

fyi. https://bugs.launchpad.net/epics-base/+bug/2031563

@mdavidsaver
Copy link
Member Author

mdavidsaver commented 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.

// only scan on monitor update for input links
if(link->type!=DBF_INLINK)
continue;
// NPP and none/Default don't scan
// PP, CP, and CPP do scan
// PP and CPP only if SCAN=Passive
if(link->pp != pvaLink::PP && link->pp != pvaLink::CPP && link->pp != pvaLink::CP)
continue;

@anjohnson I would appreciate your thoughts on this situation.

@anjohnson
Copy link
Member

Could the pvalink not wait to decide whether to enable monitors through the PVA channel until the first call to either pvaGetValue() or pvaPutValue()? 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 (INP above) 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's out field — I think that's allowed, so it can't really know until it gets called.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants