Experimental Physics and
Industrial Control System

"Kasemir, Kay" <[email protected]> · Mon, 27 Feb 2012 09:51:23 -0500

On 2/26/12 22:25 , "[email protected]" <[email protected]> wrote:
>With BOY, when you are access a PV from a JavaScript, you have to pass
>the PVs to the script and access it by pvs[0] etc. Is there a way of
>accessing pvs if you know the names? Because it is not always possible to
>pass pvs to a script, eg: when you configure an action of a widget.

Hi:

You can, but that means you'll have to do all the connection handling.

Let's step back.

Ideally, you can use the many BOY widgets and their numerous properties:
Gauge widget, set PV name, use "Limits From PV", "Alarm Sensitive" border
or "Alarm Sensitive" background color or "Alarm Sensitive" foreground
color or ...
That way, BOY will connect to the PVs, read their meta data and value etc.

That case is best for long-term maintainability.
Whoever looks at your display file will see:
Aha, the limits come from the PV, and the border is alarm-sensitive.
This also means that in 15 years you will be able to write a tool
that translates your BOY displays onto the chip that runs
directly in the users' brains, or whatever's next, because
the BOY display configuration describes the meaning of the display:
Border is alarm-sensitive.

Sometimes you cannot any of the "Alarm Sensitive" options, so then you
could try a Rule. The rule has clearly defined inputs (PVs) and an output
(the property that it influences).
Again this is somewhat maintainable, because you see that a rule reads
some PV and updates something, but it will be harder to figure out
if that was done to reflect alarm state, highlight a certain value range,
or do some useless graphical gimmickry.

If you revert to scripts, you can do anything, but it becomes harder to
maintain. People have to read and understand your script.
"Alarm Sensitive" foreground color is pretty obvious,

but a script that reads a couple PVs, does some computation and then
sets a couple of widget properties requires a lot more analysis
if you later want to update it or port it to another system.
Still, scripts done that way handle the PV life cycle:
BOY will connect to the PVs, subscribe to value updates,
trigger execution of your script when selected "trigger" PVs change.
I think you can use macro names in those script-input-Pvs,
so maybe that handles your PV name issue?

If you want to connect to PVs with a script, that's what you'll
have to do:
Connect to the PVs within the script, wait for the values to arrive,
then handle the values.
First that means that you need to start a separate thread from your
script, because otherwise BOY will invoke your script, and then your
script blocks everything waiting for values.
The latest BOY sources contain an example BOY
Examples/5_6_UseThreadInScript.opi
that shows how to start a thread from a script.
As for how to connect to PVs and handle values, you'll have to read for
example the
javadoc for org.csstudio.utility.pv.

Overall, however, using the existing widgets and their properties is best
for long-term maintainability because your OPI files describe the meaning
of the display. It's easier to read, maintain, translate.
The further you go into scripts, the harder it gets to maintain because
it's
no longer that obvious what you're trying to do.

Thanks,
Kay

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System