-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new :DATASET
pv to capture records and pass the name to the client
#118
Conversation
4e50c88
to
eebe278
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #118 +/- ##
==========================================
- Coverage 90.97% 90.94% -0.04%
==========================================
Files 8 8
Lines 1285 1358 +73
Branches 206 213 +7
==========================================
+ Hits 1169 1235 +66
- Misses 78 83 +5
- Partials 38 40 +2 ☔ View full report in Codecov by Sentry. |
5b0bba8
to
0de3dc1
Compare
src/pandablocks_ioc/ioc.py
Outdated
on_update=lambda new_capture_mode: ( | ||
self._dataset_name_cache.update_cache( | ||
record_name, | ||
record_dict[dataset_record_name].record.get(), | ||
labels[new_capture_mode], | ||
) | ||
), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This overrides the on_update
with something that updates the cache, but we still need the old behaviour of actually sending the capture value to the PandA. Maybe
PandABlocks-ioc/src/pandablocks_ioc/ioc.py
Lines 664 to 676 in 8e25d64
if ( | |
"on_update" not in kwargs | |
and "on_update_name" not in kwargs | |
and record_creation_func in OUT_RECORD_FUNCTIONS | |
): | |
record_updater = _RecordUpdater( | |
record_info, | |
self._record_prefix, | |
self._client, | |
self._all_values_dict, | |
labels if labels else None, | |
) | |
extra_kwargs["on_update"] = record_updater.update |
on_update
and sends the value to PandA? I haven't checked where else we call _create_record_info
though...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Inside _create_record_info
there is a check for whether on_update
has been passed in as a kwarg. Looking at the diff viewer there definitely is a on_update
currently checked in for the capture_record_name
record.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be fine, _create_record_info
is only in ioc.py anyway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Inside
_create_record_info
there is a check for whetheron_update
has been passed in as a kwarg. Looking at the diff viewer there definitely is aon_update
currently checked in for thecapture_record_name
record.
I'm confused, I can't see any mention of on_update
in main:
PandABlocks-ioc/src/pandablocks_ioc/ioc.py
Lines 865 to 877 in 8e25d64
capture_record_name = EpicsName(record_name + ":CAPTURE") | |
labels, capture_index = self._process_labels( | |
field_info.capture_labels, values[capture_record_name] | |
) | |
record_dict[capture_record_name] = self._create_record_info( | |
capture_record_name, | |
"Capture options", | |
builder.mbbOut, | |
int, | |
PviGroup.CAPTURE, | |
labels=labels, | |
initial_value=capture_index, | |
) |
so that means it will prod the record_updater
on caput
which I assume pushes a value to PandA?
In the change here then a different on_update
is supplied so no record_updater
ever is made so no value is pushed to the PandA?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did a quick fix by creating the record updater in _make_pos_out
_make_ext_out
- the alternatives would leave me with annoying errors.
I made a new issue for solving the problem more generally #121
4cb1372
to
09f9806
Compare
09f9806
to
eb5f694
Compare
ae9a460
to
2aa4d46
Compare
2b4dd20
to
6840e76
Compare
Closes #117
The ioc side of PandABlocks/PandABlocks-client#91