1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 <2020> 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 <2020> 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: support for CryoStream 800? (Jemian, Pete R.) |
From: | David Vine via Tech-talk <tech-talk at aps.anl.gov> |
To: | tech-talk at aps.anl.gov |
Date: | Mon, 23 Mar 2020 11:06:28 -0700 |
Send Tech-talk mailing list submissions to
tech-talk at aps.anl.gov
To subscribe or unsubscribe via the World Wide Web, visit
https://mailman.aps.anl.gov/mailman/listinfo/tech-talk
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..."
Today's Topics:
1. RE: database "diff" (Mercado, Ronaldo (DLSLtd,RAL,LSCI))
2. support for CryoStream 800? (Jemian, Pete R.)
3. detecting remote PV disconnect (asyn) (Hinko Kocevar)
4. Re: detecting remote PV disconnect (asyn) (Mark Rivers)
5. Re: detecting remote PV disconnect (asyn) (Hinko Kocevar)
---------- Forwarded message ----------
From: "Mercado, Ronaldo (DLSLtd,RAL,LSCI)" <ronaldo.mercado at diamond.ac.uk>
To: "'DiMonte, Nicholas'" <npd at anl.gov>, Paul Sichta <psichta at pppl.gov>
Cc: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Bcc:
Date: Mon, 23 Mar 2020 09:52:03 +0000
Subject: RE: database "diff"
Hi.
I don’t use VDCT or GDCT, only epics databases.
I built a linux tool (attached) to compare databases using the parser from epics base.
I hope it’s useful.
I found that it only works for old versions of epics (3.14.12.x) because the dbStaticHost library is no longer built in epics base.
(Why not?)
To build, edit the makefile to point to epics base also edit ‘scompare.conf’ to point to your paths,dbd files and db files.
The ‘path’ line accepts colon separated folders. I generally use it like that, listing the dbd and db folder for my iocs.
Regards,
Ronaldo
From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of DiMonte, Nicholas via Tech-talk
Sent: 20 March 2020 22:35
To: Paul Sichta <psichta at pppl.gov>; tech-talk at aps.anl.gov
Subject: Re: database "diff"
Paul,
At the APS we had GDCT modified to add convert function to VDCT. The conversion maintained the graphical layout which was really nice. We only have a Solaris build if my memory serves me right.
Andrew Johnson might be able to help you get a copy of this version.
Regards,
Nicholas D.
On 3/20/20 1:44 PM, Paul Sichta via Tech-talk wrote:
We're converting our (~200) databases from gdct to vdct. After we drag around the records in vdct to visually arrange the linked records, we want to perform a final check to compare the original and the vdct records. We plan to write a text processing program/script to do this, but...
Has anyone made a tool to compare the records and their fields in two database files? Is there a utility (in the IOC) to dump a database report that we can compare (before/after)? Does the old dbreport extension provide reports that list a record's field information that we can compare?
We're doing this because gdct doesn't run on Linux (right?).
Thanks,
-ps
--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
---------- Forwarded message ----------
From: "Jemian, Pete R." <jemian at anl.gov>
To: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Cc:
Bcc:
Date: Mon, 23 Mar 2020 15:11:42 +0000
Subject: support for CryoStream 800?
Anyone have support for the CryoStream 800? Ethernet-based. Thanks!
----------------------------------------------------------
Pete R. Jemian, Ph.D. <jemian at anl.gov>
Beam line Controls and Data Acquisition
Advanced Photon Source, Argonne National Laboratory
Argonne, IL 60439 630 - 252 - 3189
-----------------------------------------------------------
Education is the one thing for which people
are willing to pay yet not receive.
-----------------------------------------------------------
---------- Forwarded message ----------
From: Hinko Kocevar <Hinko.Kocevar at ess.eu>
To: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Cc:
Bcc:
Date: Mon, 23 Mar 2020 16:11:44 +0000
Subject: detecting remote PV disconnect (asyn)
Hi,
I have an EVR PV that delivers timestamp to my asyn based DAQ IOC. I want to know if and when that PV is inaccessible - i.e. EVR IOC not running / died.
I have this DB construct:
# get timestamp from EVR event PV
# i.e. set TSEL: LAB-EVR-004:EvtECnt-I.TIME CP MS
record(stringin, "$(P)$(R)TimestampIn") {
field(DTYP, "Soft Timestamp")
# use dummy placeholder PV, change EVR prefix to a desired EVR IOC
field(TSEL, "LAB-EVR-000:EvtECnt-I.TIME CP MS")
field(INP, "@%s.%f")
field(FLNK, "$(P)$(R)Timestamp.PROC PP MS")
info(autosaveFields, "TSEL")
}
# holds TS value in 'sec.nsec' format
record(stringout, "$(P)$(R)Timestamp")
{
field(DOL, "$(P)$(R)TimestampIn")
field(OMSL, "closed_loop")
field(DTYP, "asynOctetWrite")
field(OUT, "@asyn($(PORT),$(ADDR=0),$(TIMEOUT=1))SIS8300.EVR.TIMESTAMP")
}
Works as expected. The $(P)$(R)Timestamp is refreshed upon each update of the LAB-EVR-000:EvtECnt-I PV, feeding the value to the asyn based IOC code.
Upon killing the EVR IOC the $(P)$(R)TimestampIn and $(P)$(R)Timestamp show no apparent state change that the LAB-EVR-000:EvtECnt-I went away. At least looking that the "dbpr ... 4" output for the above mentioned PVs.
I was expecting the alarm fields to be set to something like "not connected". Is there a way, in asyn based IOC, to detect this situation?
Thanks,
Hinko
---------- Forwarded message ----------
From: Mark Rivers <rivers at cars.uchicago.edu>
To: Hinko Kocevar <Hinko.Kocevar at ess.eu>
Cc: tech-talk <tech-talk at aps.anl.gov>
Bcc:
Date: Mon, 23 Mar 2020 16:37:19 +0000
Subject: Re: detecting remote PV disconnect (asyn)
Hi Hinko,
I'm not sure of the configuration. Is this correct:
- Both $(P)$(R)TimestampIn and $(P)$(R)Timestamp are in the same IOC. That is not the IOC you are killing.
- The TSEL link is talking to another IOC (the EVR IOC), PV="LAB-EVR-000:EvtECnt-I.TIME CP MS"
- Is the OUT link is talking to a local driver? What does this driver do? "@asyn($(PORT),$(ADDR=0),$(TIMEOUT=1))SIS8300.EVR.TIMESTAMP")
Does TimeStampIn record ever go into alarm state when the EVR IOC shuts down? It may take the time that the OS requires to detect that a socket is closed, which can be many minutes.
It seems to me that the record that should first detect the problem is not using asyn, it is the TimestampIn record. So this is really not an asyn question, it is the behavior of EPICS base in general for CP links.
Mark
________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Hinko Kocevar via Tech-talk <tech-talk at aps.anl.gov>
Sent: Monday, March 23, 2020 11:11 AM
To: tech-talk at aps.anl.gov
Subject: detecting remote PV disconnect (asyn)
Hi,
I have an EVR PV that delivers timestamp to my asyn based DAQ IOC. I want to know if and when that PV is inaccessible - i.e. EVR IOC not running / died.
I have this DB construct:
# get timestamp from EVR event PV
# i.e. set TSEL: LAB-EVR-004:EvtECnt-I.TIME CP MS
record(stringin, "$(P)$(R)TimestampIn") {
field(DTYP, "Soft Timestamp")
# use dummy placeholder PV, change EVR prefix to a desired EVR IOC
field(TSEL, "LAB-EVR-000:EvtECnt-I.TIME CP MS")
field(INP, "@%s.%f")
field(FLNK, "$(P)$(R)Timestamp.PROC PP MS")
info(autosaveFields, "TSEL")
}
# holds TS value in 'sec.nsec' format
record(stringout, "$(P)$(R)Timestamp")
{
field(DOL, "$(P)$(R)TimestampIn")
field(OMSL, "closed_loop")
field(DTYP, "asynOctetWrite")
field(OUT, "@asyn($(PORT),$(ADDR=0),$(TIMEOUT=1))SIS8300.EVR.TIMESTAMP")
}
Works as expected. The $(P)$(R)Timestamp is refreshed upon each update of the LAB-EVR-000:EvtECnt-I PV, feeding the value to the asyn based IOC code.
Upon killing the EVR IOC the $(P)$(R)TimestampIn and $(P)$(R)Timestamp show no apparent state change that the LAB-EVR-000:EvtECnt-I went away. At least looking that the "dbpr ... 4" output for the above mentioned PVs.
I was expecting the alarm fields to be set to something like "not connected". Is there a way, in asyn based IOC, to detect this situation?
Thanks,
Hinko
---------- Forwarded message ----------
From: Hinko Kocevar <Hinko.Kocevar at ess.eu>
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: tech-talk <tech-talk at aps.anl.gov>
Bcc:
Date: Mon, 23 Mar 2020 16:55:41 +0000
Subject: Re: detecting remote PV disconnect (asyn)
Hi Mark,
> - Both $(P)$(R)TimestampIn and $(P)$(R)Timestamp are in the same IOC. That is not the IOC you are killing.
These live in the DAQ IOC, not EVR IOC (which I'm killing).
> - The TSEL link is talking to another IOC (the EVR IOC), PV="LAB-
EVR-000:EvtECnt-I.TIME CP MS"
Yes LAB-
EVR-000:EvtECnt-I.TIME is on EVR IOC. Using MS flag there makes me think that alarm severity would be propagated to the record holding TSEL (I have never done this before so I might be wrong on this assumption).
> - Is the OUT link is talking to a local driver? What does this driver do? "@asyn($(PORT),$(ADDR=0),$(TIMEOUT=1))SIS8300.EVR.TIMESTAMP")
Yes, OUT is local to an asyn driver (DAQ driver). Asyn code for DAQ driver takes the value obtained from EVR IOC PV and writes it to the firmware on top of which the DAQ IOC sits.
> Does TimeStampIn record ever go into alarm state when the EVR IOC shuts down? It may take the time that the OS requires to detect that a socket is closed, which can be many minutes.
I do not think so. I've been looking at the "dbpr TimeStampIn 4" and none of the fields change value when comparing alive EVR PV vs dead EVR PV.
> It seems to me that the record that should first detect the problem is not using asyn, it is the TimestampIn record. So this is really not an asyn question, it is the behavior of EPICS base in general for CP links.
True. The first record is no using asyn.
Is there a way to check that the EVR PV disappeared?
//hinko
Mark
________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Hinko Kocevar via Tech-talk <tech-talk at aps.anl.gov>
Sent: Monday, March 23, 2020 11:11 AM
To: tech-talk at aps.anl.gov
Subject: detecting remote PV disconnect (asyn)
Hi,
I have an EVR PV that delivers timestamp to my asyn based DAQ IOC. I want to know if and when that PV is inaccessible - i.e. EVR IOC not running / died.
I have this DB construct:
# get timestamp from EVR event PV
# i.e. set TSEL: LAB-EVR-004:EvtECnt-I.TIME CP MS
record(stringin, "$(P)$(R)TimestampIn") {
field(DTYP, "Soft Timestamp")
# use dummy placeholder PV, change EVR prefix to a desired EVR IOC
field(TSEL, "LAB-EVR-000:EvtECnt-I.TIME CP MS")
field(INP, "@%s.%f")
field(FLNK, "$(P)$(R)Timestamp.PROC PP MS")
info(autosaveFields, "TSEL")
}
# holds TS value in 'sec.nsec' format
record(stringout, "$(P)$(R)Timestamp")
{
field(DOL, "$(P)$(R)TimestampIn")
field(OMSL, "closed_loop")
field(DTYP, "asynOctetWrite")
field(OUT, "@asyn($(PORT),$(ADDR=0),$(TIMEOUT=1))SIS8300.EVR.TIMESTAMP")
}
Works as expected. The $(P)$(R)Timestamp is refreshed upon each update of the LAB-EVR-000:EvtECnt-I PV, feeding the value to the asyn based IOC code.
Upon killing the EVR IOC the $(P)$(R)TimestampIn and $(P)$(R)Timestamp show no apparent state change that the LAB-EVR-000:EvtECnt-I went away. At least looking that the "dbpr ... 4" output for the above mentioned PVs.
I was expecting the alarm fields to be set to something like "not connected". Is there a way, in asyn based IOC, to detect this situation?
Thanks,
Hinko
_______________________________________________
Tech-talk mailing list Tech-talk at aps.anl.gov
https://mailman.aps.anl.gov/mailman/listinfo/tech-talk
Attachment:
oxcryo.proto
Description: Binary data
Attachment:
oxcryo.iocsh
Description: Binary data
Attachment:
oxcryo.adl
Description: Binary data