Draft: Add PythonSoftIOC record creation directly from PandA #28
Conversation
…inside this module. The _ioc.py file will not live here forever, it's just easier to run and debug it from outside of the module structure, as it avoids some name clashing errors.
…s, and values. Also contains the start of an attempted mapping from (type, subtype) -> function to create record.
…e mechanism. Note this doesn't work at the moment - the second GetChanges call (in update()) hangs indefinitely. I don't know why...
Codecov ReportBase: 96.24% // Head: 96.43% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #28 +/- ##
==========================================
+ Coverage 96.24% 96.43% +0.18%
==========================================
Files 11 15 +4
Lines 932 2019 +1087
==========================================
+ Hits 897 1947 +1050
- Misses 35 72 +37
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
Note that the update() method will basically always throw exceptions as there are no records created for the fields that most commonly change.
…implementation still doesn't let me call Get() successfully.
…n't saved anywhere yet.
…fy a command saving data into FieldInfo It revolves around the _FieldCommandMapping class, which links together a command and the attribute in a FieldInfo class. It also handes converting the strings from PandA into more useful Python types. The FieldInfo class and GetFieldInfo command are being slowly expanded with new attributes for various field types. At some point in the future they'll need to be broken apart.
This results in a very bloated FieldInfo structure - I'll probably sub-class it for each Type to trim it down. Also add some notes to _ioc.py.
… already captured in the `labels` field (which is the logic pymalcolm uses)
…butes. Clear out commented out code and attributes.
Also a lot of other miscellaneous refactoring and comments
Additional comment on from_instance method.
…s that in _ioc.py.
NOTE: Something is causing pytest to hang indefinitely after finishing tests, which is causing all kinds of problems. Investigating now...
…es a new event loop that never gets terminated
Fix associated tests. Start work on test_get_fields_parameterized_type to test every type permutation.
Doing this after discussion with Tom, who said that there was a historical reason that these two CAPTURE attributes were treated differently in pymalcolm (which this code is based on), but that difference will be disappearing soon and so they should be treated the same.
Add missing cases to GetFieldInfo's dictionary lookup. Note there's a bug somewhere in _make_scalar - PythonSoftIOC complains that the initial_value's type is wrong when it creates the main record, hence it's commented out at the moment.
Also identified problems with the `update` method - we can't use a string type to set most of these records. We have to know what type to set, and in the case of mbbi/mbbo records we have to set the index...
AlexanderWells-diamond
force-pushed
the
pythonsoftioc
branch
from
15ac183 to
f5e5b70
Compare
This should have been done as part of commit 9609161
When a record is updated, it Puts the value to PandA, which then returns the value back to us on our next *CHANGES? call. We must stop the value from being re-set on the record if that value was just Put. This required a lot of rearchitecture. The RecordInfo structure is the only structure that is available in the *CHANGES handler, and so I refactored so that it is available in the RecordUpdater. This presented some circular dependency issues - the RecordUpdater must be created before the record, so the RecordInfo must be created before that, but then the record itself needs to live in the RecordInfo so must be put in at a later time.
This reduces the number of warnings due to overlong enum labels during startup. We cannot so easily do this for mbbOut records as they can be set through EPICS, and so need to conform to the expected enums.
I must have misunderstood what was causing me the problem originally: It wasn't the
Implemented in adf2713. This required a fair chunk of re-architecting, to allow access to the
I changed the read-only enum (for param-read ) with a string record. All other record types are |
Also add test for setting errors on records. At this point there's only one or two lines of functional code that isn't tested - the rest is exception logging
When the PandA updates the size of its tables, the DRVH value of the INDEX record will be set to the maximum allowed value Note that this does not happen immediately when data is added from the EPICS side - we rely on the data being pushed to the PandA, and then it being reported back from a *CHANGES request?
When a channel connection is broken, aioca will issue an exception. By cleaning the cache at all opportunities we suppress the errors.
This is a more sensible place for the data, which still has to be instantiated at runtime, due to needing a reference to the class instance, but makes more sense than creating it inline
|
@coretl I think I've now addressed all the points in your review. There's still a couple of conversations I've left unresolved where I'm waiting for additional feedback/discussion. I decided not to refactor the I also implemented several old TODOs, which added minor functions like the DRVH of a table's INDEX record is now updated dynamically. |
This is up from 1Hz. Fixed tests to accomodate this.
The value of the Action field is immaterial, all that matters is that it was set
The PandA may update bit_out values much faster than our polling period. To represent this, we will toggle the record's value, and reset it on the next loop of update()
This removes the need to clamp the values to the max of a 32-bit integer Instead we have the full value of a float64 to represent the value, which allows us to represent the full range of PandA values
AlexanderWells-diamond
force-pushed
the
pythonsoftioc
branch
from
3e88374 to
6a30ec7
Compare
|
@coretl Think I'm done with review comments again. |
This means the relevant command line options will only appear if the required extra modules have been installed. Without this, it was possible to run the hdf5 command line but it would just produce an ImportError
By providing the functions as hidden, they won't appear in any help output but will run if directly executed. This'll print a more helpful error for users who may be following a guide and not realizing they need to specifically install the extras. Alternative mechanisms like using `logging` don't work well as it means it'll either always or never print the message.
This uses the poorly-documented interpolation feature of config parsing: https://docs.python.org/3/library/configparser.html#interpolation-of-values
AlexanderWells-diamond
force-pushed
the
pythonsoftioc
branch
from
929e792 to
c4d05da
Compare
|
This has migrated to PandABlocks-ioc |
Note this is very much a work in progress, and it currently isn't functional.