Re: XYgraph pv_name

["Kasemir, Kay" <kasemirk@ornl.gov>]

Hi:

>I have a list of 40 Harps and each Harp has 48 current channels (waveform).

>In our current CSS we physically create a 'tabbed' control with all the 40 harps (one harp per tab). Each tab has a xygraph control.

> So when a user selects a specific harp from the group control, we just make that tab visible etc..

>What I want is only 1 xygraph control that gets the PV name from the 'group' control selected..

I like what you have in mind.

An actual Tabbed Container with 40 tabs, each containing an XYGraph would be a great waste of CPU and memory because all the tab's content is to some degree active, connected to PVs etc.

Better to have 40 selectors which somehow update just one XYGraph.

What you can try is having that XYGraph in an embedded display (Linking Container).

That embedded display somehow receives one of the 40 sets of PVs as macros.

http://ics-web.sns.ornl.gov/kasemir/switch.zip has a related example. Two buttons that write some local 'select' PV, and embedded display (Linking Container) which reacts to that PV by updating the macros of the embedded display with a script:

# Attached to to embedded display (Linking Container)
# pvs[0] PV 0, 1, ... that selects which macros to use
from org.csstudio.opibuilder.scriptUtil import PVUtil
value = PVUtil.getLong(pvs[0])
macros = widget.getPropertyValue("macros").getCopy()
if value == 0:
    macros.put("PV", "sim://sine")
else:
    macros.put("PV", "sim://ramp")
widget.setPropertyValue("macros", macros)
widget.setPropertyValue("opi_file", "")
widget.setPropertyValue("opi_file", "embedded.opi")

That example has 2 cases instead of 40, and it only sets one "PV" macro, but you can easily add more.
Note that after changing the macros, it needs to change the "opi_file" to trigger an update of the embedded display (Linking Container).

For what it's worth, the Display Builder, i.e. the update to BOY, has a "Navigation Tabs" widget.
It looks like the Tab widget (which is also available), but each Tab is configured with the name of a display to embed and macros.
At runtime, when you select a tab it loads the display file and macros for that tab, basically what the switch.zip example does.
Compared to the original Tab widget, changing tabs takes a tiny bit longer because it loads the file for that tab, creates the widgets, connects to PVs etc., but on the other hand only the content for one tab is active at a time. Other tabs use zero CPU and memory, which tends to be an overall win.

Thanks,
Kay