Log In
Register
Forum
Topic RSS
14:33, EET
June 27, 2012
Offline
I’m using a custom NodeManager, and I’m seeing some weirdness with AccessLevel.
After I first start my server, the tags that should be writable appear with AccessLevel Readable and Writable. If I click on a node in the tree that is not supposed to be Writeable I see Readable for both attributes, but every node I look at after that shows only Readable for AccessLevel.
I’m using UAExpert as a client, but I don’t think the problem is in the client – restarting the client doesn’t help, but restarting the server does.
15:16, EET
December 21, 2011
Offline
Make sure you override IoManager.getAccessLevel()/getUserAccessLevel(). It’s been a bit odd otherwise.
21:35, EET
June 27, 2012
Offline
Okay, I overrode getAccessLevel() and getUserAccessLevel(). I can see the code returning the right values, but UAExpert still shows only Readable for the R/W tag after I have looked at the read-only tag.
8:29, EET
December 21, 2011
Offline
I cannot reproduce the problem myself. I added these to MyBigIoManager:
protected EnumSet getAccessLevel(
ServiceContext serviceContext, NodeId nodeId,
UaVariable variable) throws StatusException {
DataItem d = getDataItem(nodeId);
if (d.getName().endsWith("1"))
return AccessLevel.READWRITE;
return AccessLevel.READONLY;
}
@Override
protected EnumSet getUserAccessLevel(
ServiceContext serviceContext, NodeId nodeId, UaVariable node) {
DataItem d = getDataItem(nodeId);
if (d.getName().endsWith("1"))
return AccessLevel.READWRITE;
return AccessLevel.READONLY;
}
And I get proper access levels to UaExpert with both.
DO you get the same behaviour with the Java Client (or SampleConsoleClient?)
15:19, EET
June 27, 2012
Offline
Yes, I see the same problem with the SampleConsoleClient. What’s the Java client? That would be a nice thing to have to play with when I run into issues like this.
I’m logging what getAccessLevel and getUserAccessLevel return, and you can see below that Tdint is always returning READWRITE for both. Tint returns READONLY for AccessLevel and READWRITE for userAccessLevel. Could that be the issue?
Anyway, with the sample client, I see the same issue – I browse to Tdint, read the access levels and they’re both 3. Then browse to Tint and see the access levels are both 1 – I assume the toolkit is applying the accesslevel as a mask to useraccesslevel? After that, I browse back to Tdint, and then both access levels are 1.
Looking at Tdint:
2014-01-31 10:12:07,408 [Blocking-Work-Executor-2] INFO – AccessLevel: ns=2;s=Tdint is READWRITE
2014-01-31 10:12:07,408 [Blocking-Work-Executor-2] INFO – UserAccessLevel: ns=2;s=Tdint is READWRITE
… lots of these …
2014-01-31 10:12:34,435 [Blocking-Work-Executor-1] INFO – UserAccessLevel: ns=2;s=Tdint is READWRITE
2014-01-31 10:12:34,435 [Blocking-Work-Executor-1] INFO – AccessLevel: ns=2;s=Tdint is READWRITE
Looking at Tint:
2014-01-31 10:12:36,656 [Blocking-Work-Executor-1] INFO – AccessLevel: ns=2;s=Tint is READONLY
2014-01-31 10:12:36,656 [Blocking-Work-Executor-1] INFO – UserAccessLevel: ns=2;s=Tint is READWRITE
…
2014-01-31 10:13:06,436 [Blocking-Work-Executor-1] INFO – UserAccessLevel: ns=2;s=Tint is READWRITE
2014-01-31 10:13:06,436 [Blocking-Work-Executor-1] INFO – AccessLevel: ns=2;s=Tint is READONLY
Back to Tdint:
2014-01-31 10:13:09,832 [Blocking-Work-Executor-1] INFO – AccessLevel: ns=2;s=Tdint is READWRITE
2014-01-31 10:13:09,832 [Blocking-Work-Executor-1] INFO – UserAccessLevel: ns=2;s=Tdint is READWRITE
…
2014-01-31 10:13:16,012 [Blocking-Work-Executor-2] INFO – UserAccessLevel: ns=2;s=Tdint is READWRITE
2014-01-31 10:13:16,012 [Blocking-Work-Executor-2] INFO – AccessLevel: ns=2;s=Tdint is READWRITE
16:04, EET
December 21, 2011
Offline
Yes that might explain it. The IoManager should indeed be masking the UserAccessLevel with AccessLevel, but your results do not seem like it does, indeed.
Java Client is this one.
19:46, EET
June 27, 2012
Offline
I think I wasn’t clear about the masking. The log messages above show what I’m returning – for the read-only tag, I’m returning READONLY for AccessLevel and READWRITE for UserAccessLevel. Both UserAccessLevel and AccessLevel are sent to the client as READONLY, which seems correct.
That is where the bug is, though – When I changed getUserAccessLevel to return READONLY for the read-only tag as well, the problem disappeared. There must be something weird going on in the masking code.
Thanks for the help.
20:49, EET
December 21, 2011
Offline
Sorry, Tim, I got lost again. Where do you think the bug is?
12:18, EET
June 27, 2012
Offline
I think you’ll see this problem if you change your BigIoManager test above to always return READWRITE for UserAccessLevel, and leave the AccessLevel code as above.
Look at a tag ending with 1 – it will be READWRITE. Then look at a tag ending with 2 – it will be READONLY. Go back to the tag with a 1 and you’ll see it as READONLY.
9:06, EET
December 21, 2011
Offline
OK, thanks: I finally got it! And I found the bug, which is a bit silly. The IoManager was doing this:
which modified the READWRITE “constant”, making it in effect READONLY…
You can fix this in your code, by making getUserAccessLevel to return a copy of the enum set, instead of the original:
The fix to IoManager will be in the next version.
Most Users Ever Online: 1919
Currently Online:
36 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Heikki Tahvanainen: 402
hbrackel: 144
rocket science: 88
pramanj: 86
Francesco Zambon: 83
Ibrahim: 78
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
Member Stats:
Guest Posters: 0
Members: 726
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1525
Posts: 6456
Newest Members:
forrestdilke5, ernestoportus31, martin123, rickie5305, shaylamaggard4, rickyjuarez140, jonathonmcintyre, fannielima, kristiewinkle8, rustModerators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1028, Jimmy Ni: 26, Matti Siponen: 346, Lusetti: 0
Administrators: admin: 1
