Ideas for reducing number of symbols read about ads-ioc

[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.

[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.

[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.

[ZLLentz]

Thanks, that clears up my confusion/knowledge gap