Closed ZLLentz closed 3 years ago
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.
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.
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.
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)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.
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.
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.