Ideas for reducing number of symbols read

[klauer]

A few ideas that could be implemented after @ZLLentz started a discussion about reducing PV count for lcls-twincat-motion. Largely focusing on read-only data for verbose status information:

1. For read-only data (i.e., readbacks only or a bunch of _RBV s), we could have a single array variable on the PLC that fans out to multiple values in EPICS (GVL.abStatus[10] -> [PV1_RBV, PV2_RBV, ... PV10_RBV]
2. For read-only data, we could similarly make JSON on the PLC side and expand/pick it apart it on the EPICS side
3. The ADS library could be extended to read structures using knowledge from the tmc file. This (of course) requires the tmc file to be in sync with the PLC's copy - but that requirement is effectively unchanged. This would also pave the way for structured PVAccess data that could represent entire function block instances.

(1) and (2) would require pytmc and PLC project adjustments
(3) could be implemented without large pytmc changes - I think the startup script would only need to know the tmc file location and it could decode entire structures from there. m-epics-twincat-ads would, of course, require changes.

[ZLLentz]

The ioc currently only reads one special structure as a single symbol, which is the axis status struct. This one is defined explicitly in the module here: https://github.com/pcdshub/ethercatmc/blob/19c14537cf33f244a4b30a461a0d4f753d0053fe/EthercatMCApp/src/EthercatMC.h#L75

If it was possible to do this more dynamically using information from pytmc, it would cut down on the number of symbols a lot, which could speed up the startup.

As an aside: it's not clear to me what the overhead is in creating each of these records. My understanding was that ads-ioc ends up doing a bulk read anyway, so I don't know why each PV has so much overhead when none of them get data without the greater context from the bulk read.

[klauer]

As an aside: it's not clear to me what the overhead is in creating each of these records. My understanding was that ads-ioc ends up doing a bulk read anyway, so I don't know why each PV has so much overhead when none of them get data without the greater context from the bulk read.

I think the initial lookup of a symbol to get a "handle" (connection-specific integer identifier) is where the startup bottleneck is. The bulk reads don't appear to add much overhead on the PLC side (and certainly next to none on the IOC side): a single IOC sum-up-read request yields thousands of values in a big array.

[ZLLentz]

Thanks, that clears up my confusion/knowledge gap

[klauer]

One day, I'd like to prototype (3) in Python land to see about its viability with a simple check: using knowledge from the tmc file, see that we can read back a structure and properly unpack it into its individual elements.

If so, it opens up a lot of possibilities. At the least, we should be able to drastically increase the startup performance of our IOCs and reduce the burden of piecemeal symbol transfers from the PLC.