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

Include a mechanism to avoid PpsInp-Sel and PpsInp1-Sel to be set at the same time #160

Open
gabrielfedel opened this issue Jun 13, 2024 · 7 comments

Comments

@gabrielfedel
Copy link
Contributor

gabrielfedel commented Jun 13, 2024

Currently is possible to set the PpsInp-Sel and PpsInp1-Sel records to different of None, and this way have 2 sources of PPS.
It would be good to have a mechanism on DB layer to avoid this. A simple idea would be to set the other Sel to None if the current one is != None (e.g. if PpsInp1 is UnivInp11, PpsInp is set to None automatically)

@hongran
Copy link
Contributor

hongran commented Jun 13, 2024

Currently the source selection for triggered events also has the same issue. I just made another PR for database support of the VME-300 cards. For the VME cards, I need 3 selection records for dBus, trigEvt and Pps. I implemented a mechanism to avoid double or triple selection. I think my method is expandable.

Question to Insomnia: does your solution work if we have 3 selection records (for example, PpsInp-Sel, PpsInp1-Sel and PpsInp2-Sel)?

@Insomnia1437
Copy link
Contributor

@hongran if there are 3 PpsInp sources, then my PR doesn't work. I am checking your PR now

@Insomnia1437
Copy link
Contributor

@hongran I add a dfanout record in my PR, now it works with 3 or more selection records

@gabrielfedel
Copy link
Contributor Author

@hongran could you take a look on that PR to check if looks fine ? #161

@hongran
Copy link
Contributor

hongran commented Jun 14, 2024

@gabrielfedel @Insomnia1437 I just tested the code in PR#161 and it does not work. This issue is that after the old selection is set to 0, the corresponding mbbi record is not processed, so the old selection remains active.

I have tested my solution in PR#164 and it doesn't have this issue. @Insomnia1437 is concerning about the transient period in my solution. It can be avoided in a small change. I will do this soon and update that PR.

@Insomnia1437
Copy link
Contributor

@hongran you are correct, I forget this logic

@hongran
Copy link
Contributor

hongran commented Jun 14, 2024

I updated PR#164. I tested that it works as expected. To ensure that the mbbi record is processed later than setting other selections, I need to introduce another seq record. The fanout record does not wait until entire chain out OUTA is done before processing OUTB.

I only implemented this to the Pps selection. Let me know if it is necessary to implement this transient prevention in the TrigEvent selection and DBus selection.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment