feat:add frontend xbpm and slit motors to device config #86
Reference in New Issue
Block a user
Delete Branch "feat/add_xbpm_counter"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The aim is to add the motors and xbpm monitor signals to the frontend device config file. So far we managed the physical motors for the XBPM1 and the FE slits (sl1). Please do not merge yet
assigned to @appel_c
@appel_c this is set to automerge, we are a bit concerned now... Shall we set it to you merging?
marked this merge request as draft
If you click the button, then it would merge. I typically create a merge request, but I check the checkbox for _mark as draft _, please check screenshot.
added 1 commit
a4aa1da5- add xbpm1 current monitors and fix X12SA-UIND in idgapCompare with previous version
marked this merge request as ready
@appel_c We are ready to merge this now. Today we tested that the xbpm1x moved (it was close to a limit on Friday) and it moved well. Then we corrected the X12SA-UIND channel name for the idgap. Finally we added counters for the XBPM1 in the frontend and we checked that the counts are read correctly. We further tested a scan moving the XBPM1 and monitoring the current values. We are very happy.
marked this merge request as draft
added 1 commit
53d1798c- feat: added xbpm device and added in configCompare with previous version
added 1 commit
44a4dfc8- add comments to mark devices as deprecatedCompare with previous version
marked this merge request as ready
Probably good to use SignalRO
protected name sum, maybe use a different name
@wakonig_k just 2 minor comments
requested changes
assigned to @wakonig_k
no, your linter is just fooling you. sum as a class attribute is not protected. But if you have a suggestion for a better name, I don't object ;)
doesn't make a difference... The write access is anyway set to false. But we can try it next time we are at the beamline. I will not push it now without validation at the beamline.
fu linter :)
I see, missed that in the initial!
should we merge this? @diaz
requested review from @menzel and @diaz
Oh I reallized now that there were some errors in the checks, I cannot comment on that...
resolved all threads
approved this merge request