Allow for partial array pragmas

[ZLLentz]

Sometimes, we have an array of structs that is allocated to a large, fixed size in the PLC (perhaps inside a library), but the PLC instance only uses a subset of the array, so the IOC doesn't have to know about most of the array. It'd be nice to have a way in a pragma to say "for this instance, only make records 1 to 3" to save on unused PV overhead. Not quite sure the best interface for this or how to implement it.

[klauer]

Most recent example is https://github.com/pcdshub/lcls-plc-kfe-motion/pull/58, where a library-level array of DUT_PositionState was resized due to increased requirements from an unrelated project.

Need to prioritize this feature. The IOC startup time can become long enough to be considered problematic.

Exact pragma API needs to be determined, with the vague goal of being flexible enough to work in the above test case.

[ZLLentz]

The above test case just needs something simple like:

{attribute 'pytmc' := '
    pv: MY:ARRAY
    io: i
    len: 4
'}
arrStuff : ARRAY [0..20] of BIG_DATA

Where "len 4" means "do only the first 4 elements of the array"

But I suspect what we really want to support is more like:

{attribute 'pytmc' := '
    pv: MY:ARRAY
    io: i
    elems: [0..3]
'}
arrStuff : ARRAY [0..20] of BIG_DATA

Where we mimic the beckhoff element assignment syntax to pick exactly what we want to include.

[ZLLentz]

This also needs to be addressable from outside a function block that nests sub-arrays so we can customize which elements to include from an array that sits inside a general use-case function block. E.g. I need to be able to do:

{attribute 'pytmc' := '
    pv: MY:FB
    elems: [0..3]
'}
fbMyfb : FB_MYFB

With the the elems tag (or whatever equivalent we end up going with) only applying to the array subitems.

[klauer]

Agreed on both points (len and elems).

It may be wise to make only one "right" way of doing things here, and the elems approach would be flexible enough to support all cases. The interpretation of that string could be somewhat flexible, where I'd lean toward removing the [], despite the syntactic similarity to the code:

• elems: 0..3
• elems: 0,1,2,3,7,8 (for whatever bizarre reason)

[ZLLentz]

I'm all for removing redundant syntactical constructs. I do agree that we should support ranges and individual elements (even though that seems bizarre), and maybe multiple ranges on the same array? E.g. 0..3,5..7 to exclude element 4 (why?)

TwinCAT does support multidimensional arrays, but I don't think pytmc needs to since there isn't a good mapping in EPICS channel access.

[klauer]

240 is flawed even more than I had planned - the slice() usage was dumb, as it breaks when the lower range doesn't start at 0.

Redoing/fixing the above as part of closing this issue - definitely before a tag.