Skip to content
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

Safety workaround for hardware interlock design #44

Merged
merged 4 commits into from
Aug 24, 2020

Conversation

ryan-summers
Copy link
Member

This PR fixes #3 by adding a check during channel enable to ensure that the interlock thresholds are properly set before enabling the channel.

This ensures that any over-power condition properly trips the interlock.

I've also renamed the input_overdrive to reflected_overdrive in the status structure so that it's clear this is not the input signal, but rather the reflected output signal.

Copy link
Member

@jordens jordens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that this should be in finalize_enable() and not in start_enable().
With #45 this should probably not be a fixed value but the measurement of the current power. OK for now.

@ryan-summers ryan-summers merged commit 95907ef into develop Aug 24, 2020
@ryan-summers ryan-summers deleted the rs/issue-3/interlock-support branch August 24, 2020 05:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement safety-critical interlock support
2 participants