New behaviour in CSS 3.2.11 unwanted loc://XXX has null value

74 views
Skip to first unread message

Peter Milne

unread,
Nov 8, 2013, 8:17:33 AM11/8/13
to css...@googlegroups.com
My GUI has a central "launcher" where a pushbuttons will write to a dedicated loc://XXX variable, and this is the trigger for a script that launches another OPI with custom parameters.

This works fine in older CSS eg 3.1.7, but on upgrading to 3.2.11, the behaviour changes, and I'm hoping you can advise.

What happens now is:
- all the pushbuttons have a dashed pink border
- hover text says "loc://XXX has null value".

- push the button once, and the errors above disappear [now the PV _is_ initialized], but nothing more happens
- push a second time, NOW the .opi is launched correctly.

So it's not a big problem, provided you know to push the button twice, but obviously not ideal.

Are we expected to pre-initialise all used loc://XXX variables?. That would be really tedious, because there isn't a global collection of variables, they're simply added with each new button. Checking "Execute anyway even if some PV's are disconnected" for the script didn't help (and wouldn't be expected to, the error is reported before button press).

Thanks


Peter.



Chen, Xihui

unread,
Nov 8, 2013, 8:50:09 AM11/8/13
to css...@googlegroups.com, cs-stud...@lists.sourceforge.net

Hi Peter,

 

This was a new feature of PVManager, which is the new default PV connection layer. In 3.2.11, if a local PV has no initial value, it will be initialized with null value, which results in the pink border. In the latest CSS code repository on GitHub, it will be initialized with 0 if no initial value was given, but it will print a warning message in the console.  If you are not able to build your CSS from the latest code on Github, you can temporarily avoid this problem by switching back to the old utility pv connection layer: go to Menu Edit>Preferences>BOY>OPI Runtime>PV Connection layer, set it to “utility_pv”.

 

Thanks,
Xihui

 

 

 

--
You received this message because you are subscribed to the Google Groups "CSS BOY" group.
To unsubscribe from this group and stop receiving emails from it, send an email to css-boy+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Peter Milne

unread,
Nov 8, 2013, 9:36:10 AM11/8/13
to css...@googlegroups.com, cs-stud...@lists.sourceforge.net
Hi Xihui

Your recommended change of "Edit|Preferences..|CSS Applications |Display|BOY | OPI Runtime | PV connection layer" to "utility_pv" corrects the behaviour.  Thank you!

I look forward to the next release with the default initialize to zero behaviour, thank you. But perhaps consider adding a preference checkbox "warn unitialised PV's", it will reduce noise on the log. Forcing users to initialize explicitly seems like a bad idea .. especially when in this new version, the PV's _are_ actually initialized (to zero).



Best regards


Peter.


--
You received this message because you are subscribed to a topic in the Google Groups "CSS BOY" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/css-boy/L1hFNPMTR5E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to css-boy+u...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.



--
Peter Milne www.d-tacq.com

Kasemir, Kay

unread,
Nov 8, 2013, 9:48:06 AM11/8/13
to Peter Milne, css...@googlegroups.com, cs-stud...@lists.sourceforge.net
Hello Peter:

I share your concerns.

CS-Studio developers had heated discussions on this issue:
Should local PVs behave as in EDM (start out with 0, or be initialized by whatever initialization happens first),
or should they follow strict rules (start out with null unless initialized, and all initializations must use the same value).
Some found the former most practical, and I think many users will be in that camp, but the majority of developers considered the latter as the only correct implementation.
More in the cs-studio-code email archive or tickets like https://github.com/ControlSystemStudio/cs-studio/issues/59
We finally agreed on a compatibility option, https://github.com/ControlSystemStudio/cs-studio/issues/97 : Init. as 0, but with warnings.
So that's what you now have.

Sorry,
Kay

Carcassi, Gabriele

unread,
Nov 8, 2013, 9:56:51 AM11/8/13
to Peter Milne, css...@googlegroups.com, cs-stud...@lists.sourceforge.net

Hi Peter,

 

> Forcing users to initialize explicitly seems like a bad idea

Here is why initializing all pvs to 0 is a bad idea: not all pvs are numbers. Some are Strings, some are Enums, some are tables, some are arrays, and so on. Having _all_ pvs initialized to zero means that now _every_ widget and _every_ script that handles non-numeric pvs must be able to handle them in some way. Also: some pvs will store values that are output of scripts. How can you distinguish the 0 output of a script and the 0 initialization? You don’t. So, yes: if all your local pvs are numeric, it’s a pain that you have to initialize them. But that does not work in the general case.

 

The long term the behavior will be null initialization because it works for all types.

 

Gabriele

Peter Milne

unread,
Nov 8, 2013, 10:34:00 AM11/8/13
to Carcassi, Gabriele, css...@googlegroups.com, cs-stud...@lists.sourceforge.net
Kay, Gabriele

Actually, I'd agree with the Developers that having a "strict" mode where you have to initialize everything explicitly is actually a good idea... We could take it a step further and use a compiler with type checking :-).

What is really catching me out here, is that, in my example there's no question of using loc://PV _before_ it's initialized.

The sequence is
Button press -> Action : set PV -> PV triggers Script.
In other words, The Action sets the PV, then it triggers the Script.

Except with this new "nanny state" behaviour, some software is evidently trying to validate the PV's in advance of pressing the button; and, even when the button is pressed, the new behaviour warns me of a problem (that is about to be solved as the Action takes place!).

OK, so the decision is we have to have the strict behaviour. No problem.
Other than, actually how exactly does one do this?.

eg: in perl, flow is top to bottom:

use strict;
$foo = "initial";
frob ($foo);

in css? ... note that it's all call backs, there's no top to bottom flow.
- perhaps hang a bunch of actions on the top level screen, in the hope that the a screen action happens before the validation on the scripts on the widgets inside the screen.


Thanks


Peter

--
Peter Milne www.d-tacq.com

Chen, Xihui

unread,
Nov 8, 2013, 10:42:00 AM11/8/13
to css...@googlegroups.com
Hi Peter,

A non-relative question: why don't you directly execute the script from action button?

Thanks,
Xihui
________________________________________
From: css...@googlegroups.com [css...@googlegroups.com] On Behalf Of Peter Milne [pgm...@gmail.com]
Sent: Friday, November 08, 2013 10:34 AM
To: Carcassi, Gabriele
Cc: css...@googlegroups.com; cs-stud...@lists.sourceforge.net
Subject: Re: [Cs-studio-core] New behaviour in CSS 3.2.11 unwanted loc://XXX has null value

Kay, Gabriele

Actually, I'd agree with the Developers that having a "strict" mode where you have to initialize everything explicitly is actually a good idea... We could take it a step further and use a compiler with type checking :-).

What is really catching me out here, is that, in my example there's no question of using loc://PV _before_ it's initialized.

The sequence is
Button press -> Action : set PV -> PV triggers Script.
In other words, The Action sets the PV, then it triggers the Script.

Except with this new "nanny state" behaviour, some software is evidently trying to validate the PV's in advance of pressing the button; and, even when the button is pressed, the new behaviour warns me of a problem (that is about to be solved as the Action takes place!).

OK, so the decision is we have to have the strict behaviour. No problem.
Other than, actually how exactly does one do this?.

eg: in perl, flow is top to bottom:

use strict;
$foo = "initial";
frob ($foo);

in css? ... note that it's all call backs, there's no top to bottom flow.
- perhaps hang a bunch of actions on the top level screen, in the hope that the a screen action happens before the validation on the scripts on the widgets inside the screen.


Thanks


Peter



On Fri, Nov 8, 2013 at 2:56 PM, Carcassi, Gabriele <carc...@bnl.gov<mailto:carc...@bnl.gov>> wrote:
Hi Peter,

> Forcing users to initialize explicitly seems like a bad idea
Here is why initializing all pvs to 0 is a bad idea: not all pvs are numbers. Some are Strings, some are Enums, some are tables, some are arrays, and so on. Having _all_ pvs initialized to zero means that now _every_ widget and _every_ script that handles non-numeric pvs must be able to handle them in some way. Also: some pvs will store values that are output of scripts. How can you distinguish the 0 output of a script and the 0 initialization? You don’t. So, yes: if all your local pvs are numeric, it’s a pain that you have to initialize them. But that does not work in the general case.

The long term the behavior will be null initialization because it works for all types.

Gabriele

From: Peter Milne [mailto:pgm...@gmail.com<mailto:pgm...@gmail.com>]
Sent: Friday, November 08, 2013 9:36 AM
To: css...@googlegroups.com<mailto:css...@googlegroups.com>
Cc: cs-stud...@lists.sourceforge.net<mailto:cs-stud...@lists.sourceforge.net>
Subject: Re: [Cs-studio-core] New behaviour in CSS 3.2.11 unwanted loc://XXX has null value

Hi Xihui
Your recommended change of "Edit|Preferences..|CSS Applications |Display|BOY | OPI Runtime | PV connection layer" to "utility_pv" corrects the behaviour. Thank you!
I look forward to the next release with the default initialize to zero behaviour, thank you. But perhaps consider adding a preference checkbox "warn unitialised PV's", it will reduce noise on the log. Forcing users to initialize explicitly seems like a bad idea .. especially when in this new version, the PV's _are_ actually initialized (to zero).


Best regards

Peter.

On Fri, Nov 8, 2013 at 1:50 PM, Chen, Xihui <che...@ornl.gov<mailto:che...@ornl.gov>> wrote:
Hi Peter,

This was a new feature of PVManager, which is the new default PV connection layer. In 3.2.11, if a local PV has no initial value, it will be initialized with null value, which results in the pink border. In the latest CSS code repository on GitHub, it will be initialized with 0 if no initial value was given, but it will print a warning message in the console. If you are not able to build your CSS from the latest code on Github, you can temporarily avoid this problem by switching back to the old utility pv connection layer: go to Menu Edit>Preferences>BOY>OPI Runtime>PV Connection layer, set it to “utility_pv”.

Thanks,
Xihui



From: css...@googlegroups.com<mailto:css...@googlegroups.com> [mailto:css...@googlegroups.com<mailto:css...@googlegroups.com>] On Behalf Of Peter Milne
Sent: Friday, November 08, 2013 8:18 AM
To: css...@googlegroups.com<mailto:css...@googlegroups.com>
Subject: New behaviour in CSS 3.2.11 unwanted loc://XXX has null value

My GUI has a central "launcher" where a pushbuttons will write to a dedicated loc://XXX variable, and this is the trigger for a script that launches another OPI with custom parameters.

This works fine in older CSS eg 3.1.7, but on upgrading to 3.2.11, the behaviour changes, and I'm hoping you can advise.

What happens now is:
- all the pushbuttons have a dashed pink border
- hover text says "loc://XXX has null value".

- push the button once, and the errors above disappear [now the PV _is_ initialized], but nothing more happens
- push a second time, NOW the .opi is launched correctly.

So it's not a big problem, provided you know to push the button twice, but obviously not ideal.

Are we expected to pre-initialise all used loc://XXX variables?. That would be really tedious, because there isn't a global collection of variables, they're simply added with each new button. Checking "Execute anyway even if some PV's are disconnected" for the script didn't help (and wouldn't be expected to, the error is reported before button press).

Thanks


Peter.

--
You received this message because you are subscribed to the Google Groups "CSS BOY" group.
To unsubscribe from this group and stop receiving emails from it, send an email to css-boy+u...@googlegroups.com<mailto:css-boy+u...@googlegroups.com>.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to a topic in the Google Groups "CSS BOY" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/css-boy/L1hFNPMTR5E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to css-boy+u...@googlegroups.com<mailto:css-boy%2Bunsu...@googlegroups.com>.
For more options, visit https://groups.google.com/groups/opt_out.



--
Peter Milne www.d-tacq.com<http://www.d-tacq.com>



--
Peter Milne www.d-tacq.com<http://www.d-tacq.com>


--
You received this message because you are subscribed to the Google Groups "CSS BOY" group.
To unsubscribe from this group and stop receiving emails from it, send an email to css-boy+u...@googlegroups.com.
To post to this group, send email to css...@googlegroups.com.
Visit this group at http://groups.google.com/group/css-boy.

Carcassi, Gabriele

unread,
Nov 8, 2013, 10:50:37 AM11/8/13
to Peter Milne, css...@googlegroups.com, cs-stud...@lists.sourceforge.net

Peter:

 

> Except with this new "nanny state" behaviour, some software is evidently trying
> to validate the PV's in advance of pressing the button;

It seems to me you are not complaining about the null initialization. You are complaining that you get a warning about the null initialization, correct? That’s a “temporary” warning that Kay requested to track down problems. When you build your product you can turn it off.

 

At BNL we have that disabled, because you _don’t_ have to initialize everything. Sometime you initialize with null, something writes the pv, and that’s fine. Some other time you always do want a value, and you initialize it.

 

Gabriele

 

 

From: Peter Milne [mailto:pgm...@gmail.com]

Sent: Friday, November 08, 2013 10:34 AM
To: Carcassi, Gabriele

Peter Milne

unread,
Nov 8, 2013, 12:01:33 PM11/8/13
to css...@googlegroups.com
Hi Xihui


On Fri, Nov 8, 2013 at 3:42 PM, Chen, Xihui <che...@ornl.gov> wrote:
Hi Peter,

A non-relative question: why don't you directly execute the script from action button?

That's a great idea. But it seems too easy :-(.

I need to pass data PV's as input parameters to the script.

In my current (rather indirect) method, the embedded script has a number of (non-trigger) input variables, and a single trigger PV to launch the script.

With the direct method, the trigger PV isn't needed , it's easy to execute the script with Actions|Execute js
.. but this way, there doesn't seem to be any way to attach inputs to the script, dialog options are "File Path", "Embedded" and "Description".


Thanks


Peter.



To unsubscribe from this group and all its topics, send an email to css-boy+u...@googlegroups.com.
To post to this group, send email to css...@googlegroups.com.
Visit this group at http://groups.google.com/group/css-boy.



--
Peter Milne www.d-tacq.com

Chen, Xihui

unread,
Nov 8, 2013, 12:37:42 PM11/8/13
to css...@googlegroups.com

Good point! That’s why I’m thinking about adding an “input PVs” property to execute script action.

 

Cheers,

Xihui

Peter Milne

unread,
Nov 8, 2013, 1:16:30 PM11/8/13
to css...@googlegroups.com

Hi Xihui


On Fri, Nov 8, 2013 at 5:37 PM, Chen, Xihui <che...@ornl.gov> wrote:

Good point! That’s why I’m thinking about adding an “input PVs” property to execute script action.


Yes please!

You'd need to duplicate/re-use the  "Attach Scripts" dialog.

This would be good for maintenance in my case,
 instead of
Actions: Write a trigger variable
Scripts: Specify script, variables, including trigger

we'd have it all in one place:
Actions: Specify script and variables. There's no trigger PV, the Action is the trigger.

(Different to the existing dialog, where it's mandatory to have a trigger).

In my case, sometimes the trigger variable actually carries information in its value, but this is OK because you have a chain of Actions
1. Write the value to the variable
2. Specify script and variables, including the one we just updated.
Still "all in one place". Good.

Actually, what I'm really doing with this script is launching another OPI.

There's already an "Add Open OPI" option with macros, this would be simple, but it doesn' t work because but when adding macros to the option like
UUT=loc://UUT
... the macro substitution gives the literal string "loc://UUT" rather than the value of the PV as required.  To get it to work, you'd have to invent some kind of additional syntax like *loc://UUT. It's not worth it, it's a lot more general to use a javascript glue layer to construct a string from PV values.., and if setting up the PV list and executing the script all come from the same place, it's easier to follow.

+1 for "execute script with Input PV's".





--
Peter Milne www.d-tacq.com

Chen, Xihui

unread,
Nov 8, 2013, 1:37:22 PM11/8/13
to css...@googlegroups.com

Hi Peter,

 

Thanks for the elaborating. I will try to find time to do that. It is not that easy because I want to connect to all the PVs on OPI startup and show the disconnection border as attached script. Please stay tuned by following this issue: https://github.com/ControlSystemStudio/cs-studio/issues/242

Reply all
Reply to author
Forward
0 new messages