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.
--
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.
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:
>
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
Hi Peter,
A non-relative question: why don't you directly execute the script from action button?
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.
For more options, visit https://groups.google.com/groups/opt_out.
Good point! That’s why I’m thinking about adding an “input PVs” property to execute script action.
Cheers,
Xihui
Good point! That’s why I’m thinking about adding an “input PVs” property to execute script action.
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