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

FMC250M_4CH support #39

Merged
merged 24 commits into from
Sep 20, 2024
Merged

FMC250M_4CH support #39

merged 24 commits into from
Sep 20, 2024

Conversation

ericonr
Copy link
Member

@ericonr ericonr commented Jul 11, 2024

No description provided.

This module needs to be instantiated before the eventual AD9510 module,
so the fmc_active_clk constructor runs first and stops resetting the IC,
allowing its startup routine to run.
Should MMCMRst be connected in some way to PllStatus?
This module should have the ASYN_CANBLOCK flag, since its implementation
library blocks when accessing the device. This is not critical, however,
since the main time when it receives write requests is during iocInit.

We need to handle read_startup_regs() specially, since some AFC BPM
boards don't have both FMCs installed, so we can't throw an exception
and abort the IOC in case initializing the missing device fails. This
doesn't cover the case when the core never stops being busy, where
initialization simply stops, but it at least allows the IOC to startup
when that doesn't happen.
It was necessary to add an alias for INFOClkFreq, because the old IOC
had a mechanism to enable ADCSi57xFreq to follow the value of
INFOClkFreq. Since this mechanism isn't necessary for us, we can simply
omit it, and just make both PVs available for legacy clients, which
depend on the value of INFOClkFreq.
This module should have the ASYN_CANBLOCK flag, since its implementation
library blocks when accessing the device.
Use a bpm_single.req file for all discrete modules, instead of having
them directly in bpm_common.req.
Though these modules are related to features of the FMC250M_4CH
hardware, the actual fmc250m_4ch core isn't included at the moment,
since we don't use any of its exposed features.
Also add the autosave .req files.
These records document the ratios between the available acquisition
rates. They must be configured after the IOC is brought up, in order to
have the right value for the hardware the IOC is connected to.
Using a CP link with the last input to be updated is a valid strategy,
because once it generates a callback we know for sure that the new
values have already been copied to the other records, even if they
haven't finished processing [1].

[1] https://epics.anl.gov/tech-talk/2024/msg00837.php
This polynomial correction is reponsible for applying the non-linear
correction to the beam's X, Y, Sum and Q values. Differently from the
correction applied in bpm-epics-ioc, which requires that the polynomial
coefficients include the gains in order to reach the correct magnitude,
we use dimensionless coefficients, and apply the gain and offset as a
last step.
@ericonr ericonr force-pushed the fmc250 branch 2 times, most recently from a698db3 to 006f0f1 Compare September 19, 2024 20:50
The polynomial correction has been verified with the beam, for now.

It was necessary to add initialization of prec so all pointers were
null, since the function now takes more parameters.
The autosave file was missing most channels.
The flags were switched. tapfiles should use -j to run tests in
parallel, test-results should use -s so only the actual test results
show up on screen.
This package is no longer necessary.
@ericonr ericonr merged commit 7266ca4 into master Sep 20, 2024
1 check passed
@ericonr ericonr deleted the fmc250 branch September 20, 2024 13:44
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.

1 participant