RE: CS-Studio (Phoebus) Dynamic Population of PVs in GUI

["Pearson, Matthew R. via Tech-talk" <tech-talk at aps.anl.gov>]

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.