Re: SNL question to the community

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

Hi Érico,

Correct, the waveform(s) have to be hosted in an IOC. It is a small procedure, true, but if you have OACTree available, it only requires one "script" (or tree? I still do not know how to call them properly). 

I think Ralph can give an update on the status of making the code public. I know that it is in the publication queue but not the exact status.

Timo

On 2025-03-10, 16:21, "Érico Nogueira Rolim" <erico.rolim at lnls.br <mailto:erico.rolim at lnls.br>> wrote:


Hi Timo,


It feels like a small procedure, so I hadn't thought of OACTree as 
another way to implement it. I'm glad to know it works well too. I 
imagine it requires a separate IOC hosting the waveforms, correct? Since 
OACTree is a client side application.


Do you know the status of the process of making the source available 
publically? Or should I reach out to Walter to inquire about getting 
access to it?


Cheers,
Érico


On 10/03/2025 11:07, Timo Korhonen wrote:
> [You don't often get email from timo.korhonen at ess.eu <mailto:timo.korhonen at ess.eu>. Learn why this is important at https://urldefense.us/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!G_uCfscf7eWS!fVGv65y1thebbkzWim_5nl6QxjYVc_Esk6XwHIxtPilAA-PxWT0Rixx3okz4-sQbx-ObBSNAPBt_txNbYw5H42pklIj0$  <https://urldefense.us/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!G_uCfscf7eWS!fVGv65y1thebbkzWim_5nl6QxjYVc_Esk6XwHIxtPilAA-PxWT0Rixx3okz4-sQbx-ObBSNAPBt_txNbYw5H42pklIj0$ > ]
>
> 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> <mailto: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> <mailto: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$> <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$> <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.
>
>
>