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

Ion chamber timeout #313

Merged
merged 4 commits into from
Nov 26, 2024
Merged

Ion chamber timeout #313

merged 4 commits into from
Nov 26, 2024

Conversation

canismarko
Copy link
Contributor

This PR adds a proper timeout calculation to the IonChamber.trigger() method. Previously, the default timeout was used regardless of the settings on the scaler. Now, the new method IonChamber.default_timeout() is used to determine the best timeout based on the scaler configuration.

Things to do before merging:

  • add tests
  • write docs
  • update iconfig_testing.toml
  • flake8, black, and isort

@canismarko canismarko added the device support Issues that allow support for certain kinds of hardware label Nov 23, 2024
@canismarko
Copy link
Contributor Author

Fixes #304

return count_time + DEFAULT_TIMEOUT
else:
max_count = 2**self._clock_register_width / clock_freq
return max_count + DEFAULT_TIMEOUT
Copy link
Collaborator

Choose a reason for hiding this comment

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

What is our clock_frequency? Is it a constant value depending on the scaler hardware? Or a dynamic value? When is the value changed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good question.

What is our clock_frequency?

It's the value circled in red in the image below. There's a dedicated clock that the scaler uses to know how much time has passed. In the below example, the clock is set to 9.6e6 Hz. When we ask the scaler to count to 300 seconds, then it uses this clock and will count for 300 * 9.6e6 = 2880000000 clock cycles, by making this the preset value for channel 1 on the scaler.

image

Is it a constant value depending on the scaler hardware? Or a dynamic value?

Whether it's changeable depends on where it comes from. The Struck 3820 VME scaler has an internal clock that is always 50 MHz. The scaler's internal registers are 32 bits wide, so the biggest number that it can keep track of is 2**32 == 4294967296. This means that if the clock is 50 MHz, the longest the scaler can count for is 2**32 / 5e7 = 85.9 seconds. This is too short for us and since we can't change the internal registers then we need a slower clock.

When is the value changed?

We're moving towards the MCS counter to get away from VME, and these scalers don't have an internal clock. Instead they have 4 frequency generators whose frequency can be set in EPICS, and so use one of these as an external clock. We can set it to as low a frequency as needed to count for the length of time we need.

It's probably not changed very often, but it can be changed when needed for long scans. Eventually I envision Haven's IonChamber device being able to set the clock frequency dynamically based on the preset time requested for the measurement.

@canismarko canismarko merged commit c2697e9 into main Nov 26, 2024
1 check passed
@canismarko canismarko deleted the ion_chamber_timeout branch November 26, 2024 21:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
device support Issues that allow support for certain kinds of hardware
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants