Experimental Physics and
Industrial Control System

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: CS-Studio (Phoebus) Dynamic Population of PVs in GUI
From:	"Pearson, Matthew R. via Tech-talk" <tech-talk at aps.anl.gov>
To:	"Manoussakis, Adamandios" <manoussakis1 at llnl.gov>
Cc:	"tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date:	Wed, 20 Jan 2021 20:37:55 +0000

Hi,

I haven’t actually implemented what I suggested (constructing a PV name from separate records), but it should be possible using the sCalcout record and using the PRINTF in the CALC field. And there’s probably a few other ways to do it (aSub record function, IOC side scripting in Python). However the end result would be a PV name string for the specific waveform that you’re interested in. Then you can write that to a subarray using a ‘CA’ link attribute. And that part I have done before, by using hard coded PV name strings in sseq records. For example, here’s a subArray record:

record(subArray, "$(S):Det:Array") {

field(INP, "$(S):Det:S1:Array1:ArrayData CP MS")

field(FTVL, "LONG")

field(MALM, "$(MAX_SIZE)")

field(NELM, "$(MAX_SIZE)")

field(INDX, "0")

}

Which is initially pointing to "$(S):Det:S1:Array1:ArrayData (a waveform). MALM has to be set to the largest size of waveform that you might point to. Then I can change the INP (and NELM) in a sseq record like:

record(sseq, "$(S):Det:SetA2") {

field(WAIT1, "Wait")

field(WAIT2, "Wait")

field(STR1, "$(S):Det:A2:Array2:ArrayData CP MS")

field(LNK1, "$(S):Det:Array.INP CA")

field(DOL2, "$(A2SIZE)")

field(LNK2, "$(S):Det:Array.NELM CA")

}

In practice I have a mbbo as a top level user menu, to select between different waveforms. The users (or an automated scan) can process that mbbo, which triggers the sseq, which changes the link. There’s also other records involved to provide additional information on the waveform X and Y size, so that CS-Studio can use rules to modify some properties in the display widget.

I found the above method a good way to display different waveform data to users, without having to open different screens or have all the waveforms displayed on the same screen.

Cheers,

Matt

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Manoussakis, Adamandios via Tech-talk
Sent: Tuesday, January 19, 2021 2:04 PM
To: EPICS tech-talk <tech-talk at aps.anl.gov>
Subject: [EXTERNAL] RE: CS-Studio (Phoebus) Dynamic Population of PVs in GUI

Thanks Everyone for the options

@Tynan that looks pretty cool I will definitely check it out.

@Michael Is the only way to change macro values through button actions or can you setup drop down menus (or some other more condensed form to select from)

@Matt I was trying to understand your second idea of having the PV name constructed on the IOC DB side, how would I have the GUI pass down those selections I guess to the input array to select the proper PV to display?

@Everyone Are using Rules an option since you can change the PV property through them? Or does that get me stuck back into custom scripting.

From: Tynan Ford <TFord at lbl.gov>
Sent: Friday, January 15, 2021 9:39 AM
To: Michael Davidsaver <mdavidsaver at gmail.com>
Cc: Manoussakis, Adamandios <manoussakis1 at llnl.gov>; EPICS tech-talk <tech-talk at aps.anl.gov>
Subject: Re: CS-Studio (Phoebus) Dynamic Population of PVs in GUI

So in regards to Phoebus screen generation. I haven't advertised this yet since I haven't gotten the time to make it more complete, but maybe this could help you. Or be a chance to get some collaborators :)

https://github.com/tynanford/phoebusgen

It's a python module that lets you skip worrying about the XML and do something like this. There are 8 widgets supported so far but it shouldn't take me too long to add more.

>>> import phoebusgen.widget as w

>>> text_update_widget = w.TextUpdate('test widget', 'TEST:PV', 10, 20, 20, 50)

>>> text_update_widget.predefined_foreground_color('OK')

>>> print(text_update_widget)

<?xml version="1.0" ?>

<widget type="textupdate" version="2.0.0">

  <name>test widget</name>

  <x>10</x>

  <y>20</y>

  <width>20</width>

  <height>50</height>

  <pv_name>TEST:PV</pv_name>

  <foreground_color>

    <color red="0" green="255" blue="0" alpha="255" name="OK"/>

  </foreground_color>

</widget>

On Fri, Jan 15, 2021 at 9:16 AM Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> wrote:

On 1/14/21 2:28 PM, Manoussakis, Adamandios via Tech-talk wrote:
> Hello All,
>
>
>
> I was curious what the best way to go about populating our GUIs in CS Studio when we are dealing with multiple PVs that share a common attributes. Such as
>
>
>
> Device1:Subdevice1:Signal1
>
> Device1:Subdevice1:Signal2
>
>
>
> Device1:Subdevice2:Signal1
>
> Device1:Subdevice2:Signal2
>
>
>
> And so forth for N devices M Subdevices Z Signals
>
>
>
> I was thinking to use macros that pull from drop down menus which would then populate the correct PVs for say specific waveforms.
>
>
>
> Dropdown menu to select Device #, Dropdown menu to select subdevice # and then populate the PV waveforms for the correct subset I selected.
>
>
>
> I only just started to use CS Studio and I think this seems possible but wasn’t completely sure. I also saw that I could write some python scripting and have it run in CS Studio to parse out and place the correct PVs depending on drop down selections but wanted to check in first and see how people have been using it.

You might want to start by looking at ways to accomplish this with macros.

For example, it is possible to use an Action Button to replace an OPI with the
same OPI file and different macros values. So I can have a row of buttons,
or one button with a menu, to select between different device instances.

I think it may also be possible for an embedded script to change macro values,
though cleverness with client side scripting is generally recommended as a last
resort.

wrt. generation screens. So far I've only done this sort of thing offline.
eg. with python scripts to generate OPI screen files (variously .bob, .opi,
or .edl). Usually with the idea of quickly generating tabular "expert"
screens for devices with a large number of scalar settings.

For cs-studio, this is mostly an exercise in xml.etree.ElementTree with
some logic to manage incrementing Y position for successive Embedded Display
widgets.

References:: CS-Studio (Phoebus) Dynamic Population of PVs in GUI Manoussakis, Adamandios via Tech-talk; Re: CS-Studio (Phoebus) Dynamic Population of PVs in GUI Michael Davidsaver via Tech-talk; Re: CS-Studio (Phoebus) Dynamic Population of PVs in GUI Tynan Ford via Tech-talk; RE: CS-Studio (Phoebus) Dynamic Population of PVs in GUI Manoussakis, Adamandios via Tech-talk

Navigate by Date:: Prev: Re: PicoHarp 300 Michael Davidsaver via Tech-talk; Next: Re: PicoHarp 300 Abbott, Michael (DLSLtd, RAL, LSCI) via Tech-talk; 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
Navigate by Thread:: Prev: RE: CS-Studio (Phoebus) Dynamic Population of PVs in GUI Manoussakis, Adamandios via Tech-talk; Next: PVXS release 0.1.1 Michael Davidsaver via Tech-talk; 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

ANJ, 21 Jan 2021

· Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System