EcoStruxure Geo SCADA Expert Forum
Schneider Electric support forum about installation, configuration, integration and troubleshooting of EcoStruxure Geo SCADA Expert (ClearSCADA, ViewX, WebX).
Link copied. Please paste this link to share this article on your social media post.
Posted: 2020-12-21 01:56 PM . Last Modified: 2023-05-03 12:06 AM
In the past, when using the registry in older ClearSCADA versions, we would open up the local Windows Registry Editor to review the current keys and values that have been configured on client machine in question.
Moving to the integrated registry in Geo SCADA 2019 and 2020, we have found it difficult to manage and review the keys and values during development. The 'view status' on the CDBUser object allows review of the total registry keys, but I feel that it would be very advantageous to be able to review all available and configured keys for a client.
And a clarification... the 2019 release notes mention:
To facilitate Virtual ViewX, for which multiple instances may be executing on the same host, we have moved these settings from the registry to the database and associated them with the logged in user, dynamically saved to the database.Therefore,the local PC registry will no longer be read by ViewX, and a user will share these 'registry' settings on sessions when logged in to different devices.This affects both Virtual ViewX and ViewX.
In my basic tests (GS 2020 December 2020 release), I have found that the registry keys are shared per client, not per user. Connecting to a remote Geo SCADA server, my local ViewX client reported the same value for registry key x for two different users - whereas the ViewX on the server (localhost) had a different registry value for key x. Is this expected? Just wanted to make sure I'm not crazy.
I'd also like to confirm that the registry values are stored on the Main server.
Thanks!
Link copied. Please paste this link to share this article on your social media post.
Link copied. Please paste this link to share this article on your social media post.
Posted: 2020-12-22 03:43 AM
Hi Aaron,
the 'registry' had to move for good reasons, and the user account was the best place to put it. However, there are some gaps to be examined.
a) It's no longer possible to have workstation-specific data, so a user with two sessions on one server from different PCs share the same settings. Adding a workstation name function would allow some separation.
b) No way to inspect and set values from an API
I don't understand how you get per client settings, unless your client is communicating with older servers?
Link copied. Please paste this link to share this article on your social media post.
Link copied. Please paste this link to share this article on your social media post.
Posted: 2020-12-24 05:07 PM
I've used this Registry functionality quite a bit recently.
There's obviously the potential to have confusion here in regards to the term 'user'.
The "old" Registry behaviour considered a 'user' to be a Windows User (and depending on the Windows settings this may or may not have been replicated across logical computers.. Windows default domain behaviour is that the LOCAL_USER HKEY is not replicated, and so different logical computers would have had different registry settings, in addition to different users on the same logical computer).
The "new" Registry behaviour is very much per GeoSCADA user. I've tested this and can confirm that the Registry settings are shared for the same GeoSCADA user across logical computers, and across Windows user accounts (just as the GeoSCADA help documentation suggests).
As noted by Steve: to get 'per logical computer' settings, or 'per Windows user' settings, you would need to add something extra to the Registry key being used, and that will get "difficult". Whilst VBscript has some ability to access the local machine name, and the local user name, animation expressions do NOT have such a capability, so you would typically need to try to get this information migrating from the script environment into an animation expression... and that seems like a hill I would not want to climb.
Given that ClearSCADA already had the capability to write to the local Windows Registry, it may be worth considering adding another set of methods etc to essentially keep the old behaviour still.
i.e. where the "new" functionality is via SetRegistry / GetRegistry / REGISTRY() items... perhaps there could be another group like SetLocalRegistry() / GetLocalRegistry() / LOCALREGISTRY().. which were just renamed versions of the "old" ClearSCADA functionality.
Link copied. Please paste this link to share this article on your social media post.
Create your free account or log in to subscribe to the board - and gain access to more than 10,000+ support articles along with insights from experts and peers.