10/30/2006 6:47 PM | |
Posts: 1275 Rating: (123)
|
[quote user="dwilder"]So what we are seeing on the Client system with these tags (@CurrentUser and @LocalMachineName is: 1) Using WinCC Explorer we are seeing the correct expected values as shownin the reply above. 2) The graphic screen is showing the same on the client and server screens with the server log in information. That is the @UserName and @LocalMachineName from the server machine and not from the client. The client does not have its own pdl screens,it is using the server pdl screens. 3) The Client side Global VB scripts in the Project Module are showing blank for the @CurrentUser and @LocalMachineName tags. The other thing that we are hoping to do is to be able to use this information to determine the "Operator-Control Enable" setting for various buttons and control devices. If we were using a client without its own project we would be able to use an internal tag with "Computer-local update" selected for this purpose. However this will not work with clients with their own projects. So, we are hoping that we would be able to use scripts and the @CurrentUser and @LocalMachineName to get around this problem. Thanks, Dan Hi Dan, When you say the scripts are showing blank you mean when you transfer @CurrentName to a Computer-local update tag you get nothing or haven't you tried that yet? Also... in this thread /tf/WW/en/Posts/5541 an user detected that when you trigger an action with @CurrentName, that tag doesn't receive the new user's name right away, it takes a while for that to happen. If the action triggered by @CurrentName upon change transfered the name to another tag with no delay, the other tag would be empty. Best regards, Danielle |
10/30/2006 8:00 PM | |
Posts: 58 Rating: (4) |
[quote user="Danielle"] Hi Dan, When you say the scripts are showing blank you mean when you transfer @CurrentName to a Computer-local update tag you get nothing or haven't you tried that yet? Also... in this thread /tf/WW/en/Posts/5541 an user detected that when you trigger an action with @CurrentName, that tag doesn't receive the new user's name right away, it takes a while for that to happen. If the action triggered by @CurrentName upon change transfered the name to another tag with no delay, the other tag would be empty. Best regards, Danielle Danielle, For now I have just tried displaying the CurrentUser and LocalMachineName in a trace message. As to transferring them to a Computer-local update tag, I do not think that is an option as we are using a client with its own project (required due to redundancy). With clients with their own project the Computer-local update tags are not supported. I had already looked at that thread you referenced with respect to the delay, and it is not relevant to us at this point. Any other ideas? Thanks, Dan |
10/30/2006 9:35 PM | |
Posts: 1275 Rating: (123)
|
Not right now.... [:(] anyone? I'm gonna do some research, and I'll post if I come up with something! |
This contribution was helpful to1 thankful Users |
10/31/2006 9:30 AM | |
Joined: 9/27/2005 Last visit: 11/27/2007 Posts: 1398 Rating: (151)
|
Firstly have you set the standard server on the client as detailed in this FAQ? I think you need to do this. I don't have time to test but these are my current thoughts :-do remember that if you are displaying a PDL from the server then it will have a server prefix which is applied to all tags. So all tagson the picture arecalled from the server. This is not what you want but it is what is configured. If you want local tags such as @CurrentUser displayed then try using @local::@CurrentUser instead. The @local:: prefix tells WinCC to use the local copy of the tag and not the servers copy. This is more a PCS7 thing so maybe one you PCS7 guys can confirm the exact syntax if I have it wrong. I am tied up most of this week (dared to take a holiday and know dealing with the work backlog [:(] ) but we should be able to get this one bottomed out soon. |
This contribution was helpful to2 thankful Users |
11/1/2006 8:18 PM | |
Posts: 1275 Rating: (123)
|
I didn't know this configuration, Dan. Thanks for sharing it with us! Are things working as expected? |
Follow us on