Re: SNL question to the community

[Timo Korhonen via Tech-talk <tech-talk at aps.anl.gov>]

Hi,

>SNL was also a good fit for building the "Slow Orbit" vectors. Our BPMs
>are synchronized and output new slow orbit readings at ~10Hz, which are
>published as EPICS PVs. An application attempting to construct an orbit
>snapshot must take this into account, accepting a maximum skew between
>samples and discarding ones which don't fit the sample window. SNL
>worked great for implementing this.


For what it is worth, I have done this kind of things using the OACTree, by ITER ; on a small scale but it was straightforward to do and works quite well. 
Using pvAccess, of course __, but CA should work equally well.
(OACTree was presented in the EPICS collaboration meeting at ORNL last September, in case the name is not familiar.)

Cheers,

Timo


On 2025-03-10, 14:44, "Tech-talk on behalf of Érico Nogueira Rolim via Tech-talk" <tech-talk-bounces at aps.anl.gov <mailto:tech-talk-bounces at aps.anl.gov> on behalf of tech-talk at aps.anl.gov <mailto:tech-talk at aps.anl.gov>> wrote:


On 08/03/2025 07:23, Ralph Lange via Tech-talk wrote:
> Hi Pierrick,




Hi Ralph,




>
> This has been discussed in the past... on Tech-Talk and at meetings.
> Ben, the current author/maintainer of SNL/SNC, has stated on tech-talk
> that he doesn't see an easy straightforward way to integrate SNL with
> PVA without fundamentally changing the concepts of SNL.
>
> But. SNL/SNC is the best-tested and best-documented EPICS module.
> (Most of that is Ben's work. Kudos!) It is in use at almost every
> installation and nothing could replace it any time soon. It will not
> go away.
>
> I see the sequencer's strength in implementing small state machines,
> close to the device, running on an IOC. Ramps, switch-on/switch-off
> procedures, slow feedback-type applications, that genre.
> Complicated procedure sequencers, driving whole sub-systems using
> 1000s of PVs across many IOCs - that's the scope for high-level
> operations sequencers like oac-tree. For these applications, SNL/SNC
> doesn't scale well enough and has conceptual limitations.
>
> With Channel Access slowly being sunset, the current SNL/SNC as a pure
> CA client will not be maintainable forever.
> The more I think about it, the more I like Michael Davidsaver's idea:
> Make SNC/SNL directly work with the EPICS process database, with no
> Channel Access involved. That would cut down the code base,
> significantly reduce complexity, and put the sequencer exactly where
> it belongs - inside the IOC, complementing the process database as a
> local tool to implement finite state machines. If state machines need
> access to resources outside the IOC, local proxy records can do the
> remote connection - using standard PVA or CA provided by Base for
> cross-IOC links.




Would working directly with the database enable better integration with
alarms, i.e. being able to set alarms in a PV with a single function?
That might be an advantage :) Using proxy records would also make it
necessary to change how the connection status is monitored in programs,
though.




And at what sort of scale do you see proxy records working? We have a
few IOCs at SIRIUS which use state machines to aggregate data from our
storage ring BPMs [1] and FOFB power supplies [2] into vectors, lowering
the load on other applications (which are mainly implemented in Python,
using PyEPICS). One of them is connected to over 2000 PVs, for example.




For some of these applications, it's simply impossible to connect to all
individual PVs, because they need to monitor data at ~10Hz, which
overwhelms the application and starts causing CA timeouts (it's not even
a CPU limitation, the CPU usage hovers around 60% of a CPU; it seems to
have something to do with the Python interface). It is possible to work
around that by forking multiple processes to connect to a subset of PVs
and gather the results in the parent process, but that's not very
practical and still uses up a lot of CPU power and memory. On the other
hand, the IOCs using sequencer use something like 6% of a single CPU,
have fewer to none timeouts, and their resulting vector can be used by
other applications with minimal load.




SNL was also a good fit for building the "Slow Orbit" vectors. Our BPMs
are synchronized and output new slow orbit readings at ~10Hz, which are
published as EPICS PVs. An application attempting to construct an orbit
snapshot must take this into account, accepting a maximum skew between
samples and discarding ones which don't fit the sample window. SNL
worked great for implementing this.




If proxy records wouldn't be recommended for that sort of application,
what would be? I suppose implementing similar logic using PVXS in an
asynPortDriver would work, but it would be unfortunate to require that
move. I understand that if we want to be able to move to TLS or support
IPv6 (when fully implemented), we will need to transition to PVA, so in
the long term it is likely that Sequencer as-is won't be enough.




[1] https://urldefense.us/v3/__https://github.com/lnls-dig/sofb-mon__;!!G_uCfscf7eWS!fBqYLK2j7qMtW1WIsE_Eu3RxubN4-fdgyVZXGikhVdH79_c0zr33kN58t2NqTV6lcmGmTGGW0Her4JfTJLhU216aIZg$ <https://urldefense.us/v3/__https://github.com/lnls-dig/sofb-mon__;!!G_uCfscf7eWS!fBqYLK2j7qMtW1WIsE_Eu3RxubN4-fdgyVZXGikhVdH79_c0zr33kN58t2NqTV6lcmGmTGGW0Her4JfTJLhU216aIZg$> 


[2] https://urldefense.us/v3/__https://github.com/lnls-dig/fofb-mon__;!!G_uCfscf7eWS!fBqYLK2j7qMtW1WIsE_Eu3RxubN4-fdgyVZXGikhVdH79_c0zr33kN58t2NqTV6lcmGmTGGW0Her4JfTJLhU1kcJLpQ$ <https://urldefense.us/v3/__https://github.com/lnls-dig/fofb-mon__;!!G_uCfscf7eWS!fBqYLK2j7qMtW1WIsE_Eu3RxubN4-fdgyVZXGikhVdH79_c0zr33kN58t2NqTV6lcmGmTGGW0Her4JfTJLhU1kcJLpQ$> 




Cheers,


Érico




>
> Cheers,
> ~Ralph
>




Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual consulta ao remetente antes de copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem por engano, por favor avise o remetente e apague-a imediatamente.


Disclaimer: This email and its attachments may contain confidential and/or privileged information. Observe its content carefully and consider possible querying to the sender before copying, disclosing or distributing it. If you have received this email by mistake, please notify the sender and delete it immediately.