Experimental Physics and
Industrial Control System

"Jemian, Pete R. via Tech-talk" <tech-talk at aps.anl.gov> · Mon, 23 Mar 2020 18:09:08 +0000

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.
-----------------------------------------------------------

________________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of David Vine via Tech-talk <tech-talk at aps.anl.gov>
Sent: Monday, March 23, 2020 1:06 PM
To: tech-talk at aps.anl.gov
Subject: Re: support for CryoStream 800? (Jemian, Pete R.)

Hey Pete,

i've attached a stream support for the 800.

Best,
David

On Mon, Mar 23, 2020 at 10:00 AM <tech-talk-request at aps.anl.gov<mailto:tech-talk-request at aps.anl.gov>> wrote:
Send Tech-talk mailing list submissions to
        tech-talk at aps.anl.gov<mailto: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<mailto:tech-talk-request at aps.anl.gov>

You can reach the person managing the list at
        tech-talk-owner at aps.anl.gov<mailto: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<mailto:ronaldo.mercado at diamond.ac.uk>>
To: "'DiMonte, Nicholas'" <npd at anl.gov<mailto:npd at anl.gov>>, Paul Sichta <psichta at pppl.gov<mailto:psichta at pppl.gov>>
Cc: "tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>" <tech-talk at aps.anl.gov<mailto: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<mailto: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<mailto:psichta at pppl.gov>>; tech-talk at aps.anl.gov<mailto: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<mailto:jemian at anl.gov>>
To: "tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>" <tech-talk at aps.anl.gov<mailto: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<mailto: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<mailto:Hinko.Kocevar at ess.eu>>
To: "tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>" <tech-talk at aps.anl.gov<mailto: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<mailto:rivers at cars.uchicago.edu>>
To: Hinko Kocevar <Hinko.Kocevar at ess.eu<mailto:Hinko.Kocevar at ess.eu>>
Cc: tech-talk <tech-talk at aps.anl.gov<mailto: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<mailto:tech-talk-bounces at aps.anl.gov>> on behalf of Hinko Kocevar via Tech-talk <tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>>
Sent: Monday, March 23, 2020 11:11 AM
To: tech-talk at aps.anl.gov<mailto: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<mailto:Hinko.Kocevar at ess.eu>>
To: Mark Rivers <rivers at cars.uchicago.edu<mailto:rivers at cars.uchicago.edu>>
Cc: tech-talk <tech-talk at aps.anl.gov<mailto: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<mailto:tech-talk-bounces at aps.anl.gov>> on behalf of Hinko Kocevar via Tech-talk <tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>>
Sent: Monday, March 23, 2020 11:11 AM
To: tech-talk at aps.anl.gov<mailto: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<mailto:Tech-talk at aps.anl.gov>
https://mailman.aps.anl.gov/mailman/listinfo/tech-talk

[https://static1.squarespace.com/static/56de1f4a2fe1318cf0aacc98/t/5d9e0fa57996446a078a8e1a/1570639781104/Logo_gmail_small.png?format=300w]

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this email. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System