[EXTERNAL] This email originated from outside of FRIB
Send Tech-talk mailing list submissions to
tech-talk at aps.anl.gov
To subscribe or unsubscribe via the World Wide Web, visit
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fmailman.aps.anl.gov%2fmailman%2flistinfo%2ftech-talk&c=E,1,o1zIEGLZd_XkNiwCLSrwLvTON9eEjm31GY2VH8fbITrNBs_F_znmv4m3qWNAADTuvaD_I3baSDvcKiHeJSGc0xbPbKF_PaPy36amImnTT5LNQ5ZZXuxQJQ,,&typo=1
or, via email, send a message with subject or body 'help' to
tech-talk-request at aps.anl.gov
You can reach the person managing the list at
tech-talk-owner at aps.anl.gov
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Tech-talk digest..."
[EXTERNAL] This email originated from outside of FRIB
Today's Topics:
1. Re: Diagnosing and overcoming GigE camera freezes
(Henrique F. Simoes)
2. Re: AreaDetector Monthly Collaboration Meetings and project
owners (Henrique F. Simoes)
3. RE: Diagnosing and overcoming GigE camera freezes (Abdalla Ahmad)
4. Epics Driver for Hamamatsu X-ray Source (Dariush Hampai)
5. Re: Communicating with Bechoff I/O through EPICS
(Sandstr?m Anders Eric)
From:
"Henrique F. Simoes" <henrique.simoes at lnls.br>
Subject:
Re: Diagnosing and overcoming GigE camera freezes
Date:
May 28, 2025 at 2:50:44 PM EDT
To:
Abdalla Ahmad <Abdalla.Ahmad at sesame.org.jo>
Cc:
Eduardo Pereira Coelho <eduardo.coelho at lnls.br>, "christopher.gregory at stfc.ac.uk" <christopher.gregory at stfc.ac.uk>, "tech-talk at aps.anl.gov" <Tech-talk at aps.anl.gov>
[EXTERNAL] This email originated from outside of FRIB
On Monday, May 26, 2025 3:44 AM, Abdalla Ahmad <Abdalla.Ahmad at sesame.org.jo> wrote:
I would like to share our experience with Basler GigE cameras
(acA1300). We use them to visualize the beam from the injector to the
storage-ring, we use them at some beamlines but controlled via Pylon
Viewer. Right now, they are controlled with ADPylon. The issue was
there was a lot of disconnection with the cameras, it was a network
setup issue:
* Jumbo frames were enabled (especially on intermediate switches)
That's a bit surprising for me. I've seen jumbo frames help the IOC keep
up with the high input traffic on a modest machine, but I've never
considered that it could cause occasional disconnections.
Our intermediate switches do have them enabled, while most IOC hosts
don't.
* A certain camera was moved to newer network switch for testing.
Right now, on this camera, we can achieve between 1.5M and 2M frames
continuously at 10 Hz frame rate with much less disconnection.
Have you ever disabled jumbo frames on the intermediate switches in the
first setup, and validated that this was the only difference in both
scenarios?
We used the ace2 model for some period and it used to freeze due to
overheating, we removed the camera so we never got the chance to
troubleshoot.
Do you recall what temperature approximately the camera would reach
before freezing?
Best Regards,
Abdalla Al-Dalleh
Control Engineer
SESAME
Thanks for sharing your experiences, Abdalla!
--
Henrique F. Simões
Control Software Group (SwC)
Brazilian Synchrotron Light Laboratory (LNLS)
Brazilian Center for Research in Energy and Materials (CNPEM)
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.
From:
"Henrique F. Simoes" <henrique.simoes at lnls.br>
Subject:
Re: AreaDetector Monthly Collaboration Meetings and project owners
Date:
May 28, 2025 at 4:15:34 PM EDT
To:
Mark Rivers <rivers at cars.uchicago.edu>
Cc:
Guilherme Rodrigues de Lima <guilherme.lima at lnls.br>, EPICS Tech-Talk <tech-talk at aps.anl.gov>
[EXTERNAL] This email originated from outside of FRIB
Hi, Mark Rivers.
On Sunday, May 25, 2025 4:22 PM, Mark Rivers via Tech-talk <tech-talk at aps.anl.gov> wrote:
Some of the entries have question marks for the maintainer and/or
status. I would appreciate feedback on these, i.e. whether someone
else should be the maintainer and whether a detector driver is still
actively being used or can be archived.
We actively use specsAnalyser driver, based on a fork [1] with both
pending PRs in the repository [2, 3] applied. In case Stuart Wilkins
isn't available to maintain it, I'd name Guilherme Lima for this role.
Guilherme first worked on this two years ago, and implemented support
for a more recent feature we rely on [3]. Those changes have yet to be
reviewed or merged.
Regarding ffmpegServer, I recall it being part of a discussion in a
previous Area Detector meeting whose topic was video compression over
CA/PVA, motivated by a PR in ADCore [4]. If I'm not mistaken, the
conclusion was that ffmpegServer was the only reliable option to have a
stream of data using video compression algorithms. Does this make it an
active project?
[1] github.com/cnpem/specsAnalyser
[2] github.com/areaDetector/specsAnalyser/pull/8
[3] github.com/areaDetector/specsAnalyser/pull/9
[4] github.com/areaDetector/ADCore/pull/499
--
Henrique F. Simões
Control Software Group (SwC)
Brazilian Synchrotron Light Laboratory (LNLS)
Brazilian Center for Research in Energy and Materials (CNPEM)
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.
From:
Abdalla Ahmad <Abdalla.Ahmad at sesame.org.jo>
Subject:
RE: Diagnosing and overcoming GigE camera freezes
Date:
May 29, 2025 at 3:46:56 AM EDT
To:
"Henrique F. Simoes" <henrique.simoes at lnls.br>
Cc:
Eduardo Pereira Coelho <eduardo.coelho at lnls.br>, "christopher.gregory at stfc.ac.uk" <christopher.gregory at stfc.ac.uk>, "tech-talk at aps.anl.gov" <Tech-talk at aps.anl.gov>
[EXTERNAL] This email originated from outside of FRIB
Hi Henrique
"That's a bit surprising for me. I've seen jumbo frames help the IOC keep up with the high input traffic on a modest machine, but I've never considered that it could cause occasional disconnections."
Sorry I may have used the wrong term here because I got confused with another camera, what I meant was very frequent freezes of acquisition, the camera just stops acquiring frames. Unfortunately, I could not remember if the IOC had any error messages.
"Have you ever disabled jumbo frames on the intermediate switches in the first setup, and validated that this was the only difference in both scenarios?"
The cameras were working without jumbo frames, they would just freeze very frequently. When enabling jumbo frames, acquisition improved but with some freezes from time to time. The solution was to connect the camera to a much better switch.
"Do you recall what temperature approximately the camera would reach before freezing?"
I remember the camera would reach a temperature of around 55 C in normal operation, but it would not last much time before shutdown. I tried looking up any info on thermal shutdown but could not find it.
I don't know if anyone would agree with this or not, but I think the best solution would be to isolate the cameras completely in their separate network, we proposed a setup were the cameras are connected to their own gigabit and PoE switch and a separate workstation
running the IOC with two NICs one for the cameras and one for the main network. We did not proceed because the aforementioned solution is working for us right now.
Best Regards,
Abdalla Al-Dalleh
Control Engineer
SESAME
-----Original Message-----
From: Henrique F. Simoes <henrique.simoes at lnls.br>
Sent: Wednesday, May 28, 2025 9:51 PM
To: Abdalla Ahmad <Abdalla.Ahmad at sesame.org.jo>
Cc: Eduardo Pereira Coelho <eduardo.coelho at lnls.br>; christopher.gregory at stfc.ac.uk; tech-talk at aps.anl.gov
Subject: Re: Diagnosing and overcoming GigE camera freezes
On Monday, May 26, 2025 3:44 AM, Abdalla Ahmad <Abdalla.Ahmad at sesame.org.jo> wrote:
I would like to share our experience with Basler GigE cameras
(acA1300). We use them to visualize the beam from the injector to the
storage-ring, we use them at some beamlines but controlled via Pylon
Viewer. Right now, they are controlled with ADPylon. The issue was
there was a lot of disconnection with the cameras, it was a network
setup issue:
* Jumbo frames were enabled (especially on intermediate switches)
That's a bit surprising for me. I've seen jumbo frames help the IOC keep up with the high input traffic on a modest machine, but I've never considered that it could cause occasional disconnections.
Our intermediate switches do have them enabled, while most IOC hosts don't.
* A certain camera was moved to newer network switch for testing.
Right now, on this camera, we can achieve between 1.5M and 2M frames
continuously at 10 Hz frame rate with much less disconnection.
Have you ever disabled jumbo frames on the intermediate switches in the first setup, and validated that this was the only difference in both scenarios?
We used the ace2 model for some period and it used to freeze due to
overheating, we removed the camera so we never got the chance to
troubleshoot.
Do you recall what temperature approximately the camera would reach before freezing?
Best Regards,
Abdalla Al-Dalleh
Control Engineer
SESAME
Thanks for sharing your experiences, Abdalla!
--
Henrique F. Simões
Control Software Group (SwC)
Brazilian Synchrotron Light Laboratory (LNLS) Brazilian Center for Research in Energy and Materials (CNPEM)
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.
From:
Dariush Hampai <dariush.hampai at lnf.infn.it>
Subject:
Epics Driver for Hamamatsu X-ray Source
Date:
May 29, 2025 at 5:24:20 AM EDT
To:
<tech-talk at aps.anl.gov>
[EXTERNAL] This email originated from outside of FRIB
Dear all,
I developped a driver for the X-ray source by Hamamatsu (mod. L9421-02) and I would like to share it with the community.
In the following link you can find the driver.
https://urldefense.us/v3/__https://github.com/Teclis77/Hamamatsu_L9421_02__;!!G_uCfscf7eWS!dXCiJg9Ta7ZNE9DtQLvhb7CO1hx_yzEOnrUcsoGET010LeAWwlJi8IiPNQaMbOo8YkMtxXXwX2BqbByY0hRMv9fy-7o8FZGUTg$
Dariush
--
************************************
Dr. Dariush Hampai, PhD
INFN - LNF
X-Lab Frascati
Via E. Fermi, 54 (ex 40)
I-00044 Frascati (RM)
Italy
Mail Address:
XLab-Frascati
LNF-INFN
Casella Postale 13
Frascati (RM)
Italy
Room:
+39.06.9403.5248
Lab.:
+39.06.9403.2286
Mob.:
+39.06.9403.8025
Fax.:
+39.06.9403.2597
************************************
From:
Sandström Anders Eric <anders.sandstroem at psi.ch>
Subject:
Re: Communicating with Bechoff I/O through EPICS
Date:
May 29, 2025 at 5:43:43 AM EDT
To:
Timo Korhonen <Timo.Korhonen at ess.eu>
Cc:
Sibylle Ducroizé <sducroize at lpsc.in2p3.fr>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
[EXTERNAL] This email originated from outside of FRIB
Hello Sibylle, Timo and All,
I'm happy to support with ecmc related questions (if I can).
At PSI we use Debian 12 for ecmc, works well.
Some information on how to configure an ecmc ioc with ecmccfg can be found here:
https://urldefense.us/v3/__https://paulscherrerinstitute.github.io/ecmccfg/manual/__;!!G_uCfscf7eWS!fZGOeipZ1VFVvsCQ8h4J1AOC4vBmTbYxHhGPB_-TLeGjAxkz3S0TanJW9e-h2sNHHv4Od4wCdSLLxKN92hyRObKYovNlyQuf$
and example iocs:
https://urldefense.us/v3/__https://github.com/paulscherrerinstitute/ecmccfg/tree/master/examples/PSI/best_practice__;!!G_uCfscf7eWS!fZGOeipZ1VFVvsCQ8h4J1AOC4vBmTbYxHhGPB_-TLeGjAxkz3S0TanJW9e-h2sNHHv4Od4wCdSLLxKN92hyRObKYorvnALvT$
BTW, there's no need for any twincat related project or files when configuring an ecmc-ioc.
Best Regards
Anders
On 28 May 2025, at 15:53, Timo Korhonen <Timo.Korhonen at ess.eu> wrote:
Hello Sibylle and all,
Like Jörn replied, there should be no issues to build e3 on Ubuntu. If you have the prerequisites installed, it should build pretty much out of the box.
For ecmc, I think it would be good to contact Anders Sandström at PSI (in cc, as I am not sure if Anders follows tech-talk). I know they are using it to operate a lot of motors, also with EPICS.
I have not built or used it myself recently, but I can really recommend it, it is an excellent package. There has been a lot of substantial improvements in the last years, and depending on your application I think it could have some substantial advantages over
other solutions, event TwinCAT.
Best regards,
Timo (ESS)
On 2025-05-28, 15:10, "Tech-talk on behalf of Jörn Dreyer 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:
Hello Sibylle,
I have successfully used e3 on an Ubuntu 24.04 host. I guess that your failure comes from missing prerequisites.
I have installed the following packages before using e3:
- patch
- m4
- gcc
- g++
- tclx
- python3-dev
- libtirpc-dev
- re2c
- patchelf
- libusb-dev
- libsnmp-dev
- libxml2-dev
- libreadline-dev
- libopencv-dev
- libudev-dev
- libboost-all-dev
- libgsl-dev
- git
- libglib2.0-dev
- libx11-dev
- libxext-dev
- libzip-dev
- libfreetype-dev
- liblcms2-dev
- make
I tested it on a VM with a fresh installed Ubuntu desktop and also OpenSuSE Tumbleweed without problems.
Regarding your questions:
1) It depends on the type of devices you want to talk to. For motors, I would recommend to give the ess ethercatMC a try If you have a Beckhoff PLC in your system
There is also a BechhoffADS driver that talks directly via the etherlab driver to the devices, but it is limited to certain devices.
2) If your device is not supported you might need to implement it for the BeckhoffADS driver.
I don't know ecmc by hart, but if I remember correctly it is quite fancy but hard to set up as it takes a project file from TwinCAT and gives you access to each and every register of you devices.
This could be dangerouse for a novice as you can possibly destroy your device by misconfiguration.
Hope this helps you a bit,
Jörn
Am Mittwoch, 28. Mai 2025, 13:23:34 Mitteleuropäische Sommerzeit schrieb Sibylle Ducroizé via Tech-talk:
Hello,
I have just started working on an update of the control system software
for an accelerator.
I am still trying out different configurations and learning how to use
EPICS. I followed the tutorial of the EPICS documentation so I know
basic information about IOCs and have common support modules installed
(asyn, calc, streamDevice,...)
I would like to communicate with Beckhoff I/O terminals, both as a way
to learn EPICS and to try out configurations for the final project. I
have tried following this advice
<https://epics.anl.gov/tech-talk/2018/msg00279.php > <https://epics.anl.gov/tech-talk/2018/msg00279.php > > from a previous
tech-talk question from 2018.
So far I have installed etherlab's ethercat master
<https://urldefense.us/v3/__https://gitlab.com/etherlab.org/ethercat__;!!G_uCfscf7eWS!e7dazAbiiIaQgW2B8trCKUmDQiA1qqxV5LI23pHrrWfr0BtoCOobFERw9NiJhtJAc2dQlUH666hIKgU87BJ95yX-AITXpQ$ <https://urldefense.us/v3/__https://gitlab.com/etherlab.org/ethercat__;!!G_uCfscf7eWS!e7dazAbiiIaQgW2B8trCKUmDQiA1qqxV5LI23pHrrWfr0BtoCOobFERw9NiJhtJAc2dQlUH666hIKgU87BJ95yX-AITXpQ$>
> and I've tried installing
PSI's ecmc <https://urldefense.us/v3/__https://github.com/epics-modules/ecmc__;!!G_uCfscf7eWS!e7dazAbiiIaQgW2B8trCKUmDQiA1qqxV5LI23pHrrWfr0BtoCOobFERw9NiJhtJAc2dQlUH666hIKgU87BJ95yXNbSPhcQ$ <https://urldefense.us/v3/__https://github.com/epics-modules/ecmc__;!!G_uCfscf7eWS!e7dazAbiiIaQgW2B8trCKUmDQiA1qqxV5LI23pHrrWfr0BtoCOobFERw9NiJhtJAc2dQlUH666hIKgU87BJ95yXNbSPhcQ$>
>which needs e3
<https://urldefense.us/v3/__https://gitlab.esss.lu.se/e3/e3__;!!G_uCfscf7eWS!e7dazAbiiIaQgW2B8trCKUmDQiA1qqxV5LI23pHrrWfr0BtoCOobFERw9NiJhtJAc2dQlUH666hIKgU87BJ95yWHPmVh9Q$ <https://urldefense.us/v3/__https://gitlab.esss.lu.se/e3/e3__;!!G_uCfscf7eWS!e7dazAbiiIaQgW2B8trCKUmDQiA1qqxV5LI23pHrrWfr0BtoCOobFERw9NiJhtJAc2dQlUH666hIKgU87BJ95yWHPmVh9Q$>
> to build. Unfortunately, e3-build
fails to install epics base so I didn't get very far...I am on ubuntu
which might be the problem.
My questions :
1. Are there maintained EPICS drivers for communicating with Beckhoff I/O ?
1.a. If so, is ecmc a good option ? (As it depends on e3, meant to
run on centOS which is obsolete)
1.b. Are there other similar alternatives ?
2. Should I basically write my own drivers ?
1.a. An advice / general approach for me to follow as I am new to
EPICS ?
Thanks,
Sibylle
[EXTERNAL] This email originated from outside of FRIB
_______________________________________________
Tech-talk mailing list Tech-talk at aps.anl.gov
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fmailman.aps.anl.gov%2fmailman%2flistinfo%2ftech-talk&c=E,1,1L2Eq7I6pm67itY7FkXQ4_O6P9lqIGJniCd-scMmLIrfPkfxs-EHVBlQUy0f4yg61pFOC3pkHhlN7w1VGSV-FslOFohs-hz8yL4Q1UJxT0gO1Drq_up70yo,&typo=1
