-
Notifications
You must be signed in to change notification settings - Fork 49
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
user/dial limits: change when motor/encoder resolution changes #191
Comments
I prefer the second of the two proposed options, as I expect it would result in fewer potential problems. I also think a cleaner approach would be to add raw limit fields, analogous to the raw position fields, that would allow appropriately-scaled limits to be sent to the driver without keeping track of the previous MRES. |
Specifially, RHLM and RLLM fields could be added, with the following relationships to DHLM and DLLM:
The raw limits would update and be consistent with the dial limits. If the raw limits are changed, the dial limits would be recalulcated using the current MRES. If the MRES is changed, the dial limits would be recalculated based on the the raw limits, along with the velocities. |
yes, that seems a better solution. I think I prefer that as it follows what we currently do with scaled velo etc. |
as a (very) rough proof of concept this seems to work... https://github.com/ISISComputingGroup/EPICS-motor/compare/rawlims?expand=1 as this is the first time i've looked at the motor record i'm not super confident! will test some more and make a PR when happy |
If I may join the discussion: However, synching of Raw/Dial/User limits seems incomplete. |
many thanks for having a look and giving feedback! RLLM/RHLM being read-only to the outside world is fine I think. Have just committed a change to make them read-only, hopefully it's correct. edit: think i needed to add SPC_NOMOD in the dbd as well? MRES < 0 currently applies looks like dhlm and dllm are not affected by DIR, only llm and hlm are - i think it makes sense for RLLM and HLLM to also not be affected? |
This is correct.
This is also correct. |
@tboegi, I don't understand. How would the syncing be incomplete? |
My first impression, after reading all the changes, was that RLLM and RHLM are writable. However, I wonder, if a simple |
@rerpha I think that this patch may solve your issue ? |
i think so - its just whether we want to update on the controller or update values on our end instead? |
What is our end ? |
DHLM/DLLM/HLM/LLM being updated instead of new limit being pushed to controller |
I think the former now works on my branch, with raw lims read-only? just needs some tidying up |
I see: I did the wrong solution. |
have made #193 , feedback welcomed! |
Add raw limits so that soft limits are synced with motor resolution change. Fixes #191
Currently the motor record does nothing with dial/user limits when a motor encoder resolution changes.
this is potentially problematic if a device stores soft limits on the controller (in our case at ISIS/STFC a Galil) which are not scaled (ie in steps), as the motor record does not re-scale these values by calling set_dial_highlimit etc.
I propose that, when changing the motor/encoder resolution, either:
The former feels like it would require caching the old mres so we can compare against it when trying to rescale the limits.
I think the latter would just be a case of calling set_dial_{high, low}limit() and then set_user_limits from motorRecord.cc
The text was updated successfully, but these errors were encountered: