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: Show alarms, events and measurements from DSP in CS-Studio and generate files with this data |
From: | "Kasemir, Kay" <[email protected]> |
To: | Carlos Gómez Martinez <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
Date: | Mon, 14 Mar 2016 13:30:37 +0000 |
Hi:
No matter if you use CSS or edm or medm or alh or StripTool or one of the Qt-based user displays for EPICS, or if you use the records that you interface to your DSP as inputs of additional EPICS IOC record or sequencer logic, you should create
records with proper EPICS alarms, i.e. records that send out alarm updates.
For example, this analog record will create a MINOR alarm when its value reaches 100:
record(ai, “demo”)
{
field(DTYP, “..modbus..”)
field(INP, “..whatever you need here..”)
field(HIGH, “10”)
field(HSV, “MINOR”)
}
I understand that your DSP is already checking the value and creating alarms, but you need to get that information into the “demo” record. Assume that your DSP is also comparing the value against some threshold, and that threshold may change.
Then add another record which reads that alarm threshold from the DSP and puts it into the HIGH field of the above record:
record(ai, “demo_threshold”)
{
field(DTYP, “..modbus..”)
field(INP, “..whatever you need here..”)
field(FLNK, “ demo_threshold_update”)
}
record(ao, “demo_threshold_update”)
{
field(DOL, “demo_threshold”)
field(OMSL, “closed_loop”)
field(OUT, “demo.HIGH”)
}
Yes, this means that both your DSP and the “demo” record will perform the threshold check.
Yes, this means you need additional records to read the threshold from the DSP and update the HIGH field of the demo record. You might be able to package that into a database template for re-use.
With CSS, you might be tempted to hack around this by using rules/scripts to change the background color of a widget based on the alarm info read from the DSP via additional PVs, but this is a bad idea for several reasons:
You will likely need several rules/scripts. They’re not trivial, they will slow your display down, and they will need to be adjusted with upcoming updates of CSS. You need additional PVs anyway to read the alarm state from the DSP, so you might
as well add a few more records to update the HIGH of analog records etc. to create proper alarms.
More important, you really want proper PVs that create alarms so that you can use them in any Channel Access client (archive, alarm, other IOCs, ..).
Thanks,
Kay
|