Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
Use of Nodemanager.createNodeBuilder
July 28, 2015
5:09, EEST
Avatar
hbrackel
Member
Members
Forum Posts: 144
Member Since:
February 21, 2014
sp_UserOfflineSmall Offline

Good morning,

I created a nodeset with a custom deviceType (MyDeviceType) being a subType of the Opc.Ua.Di DeviceType. After generating the interfaces and classes from the custom nodeset, loading the Opc.Ua.Di nodeset, registering and loading the custom deviceType nodeSet and its classes, I want to create an instance of the new MyDeviceType.

MyDeviceTypeNode myDevice = myDeviceNodeManager.createNodeBuilder(MyDeviceTypeNode.class)
.setName(“My Device”)
.build();

The latter results in a ClassCastException:

com.prosysopc.ua.server.nodes.UaObjectNode cannot be cast to […].MyDeviceTypeNode
The same call works for the vanilla “DeviceType”.

Any hint on what I’m doing wrong is much appreciated.

Thanks,
Hans-Uwe

July 28, 2015
7:36, EEST
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 1026
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Hi,

Did you do the following for both nodeset files/models? (first both to opc.ua.di and after that for your model)
– Load the nodeset XML, which creates the type nodes to address space
– Register the CodegenModel which is in the InformationModel class (generated), which links a Java class to an UA type

You can do both at the same time with UaServer.registerAndLoadModel. Alternatively NodeManagerTable.loadModel and UaServer.registerModel.

Because ClassCastException happens, I believe you have not registered the CodegenModel of your type. The reason why ClassCastException happens is because the node builder only uses the types in the address space, i.e. it should work also for non-generated types; it instantiates whatever has been registered for the type, falling back to more general nodeclass based ones if nothing has been registered. The build() casts the result expecting it to work (since the class should be registered, it should be also the one returned).

– Bjarne

July 28, 2015
15:51, EEST
Avatar
hbrackel
Member
Members
Forum Posts: 144
Member Since:
February 21, 2014
sp_UserOfflineSmall Offline

Hi,
Both models (DI as well as the derived types) have been registered and loaded with no (obvious) errors. All instances and types are visible in the addressSpace (to confirm the loading part) and DI nodes can be instantiated (to confirm the registration at least for the DI part) – although DI classes are pre-registered and only need to be loaded as I could verify.

– Hans-Uwe

Bjarne Boström said

Hi,

Did you do the following for both nodeset files/models? (first both to opc.ua.di and after that for your model)
– Load the nodeset XML, which creates the type nodes to address space
– Register the CodegenModel which is in the InformationModel class (generated), which links a Java class to an UA type

You can do both at the same time with UaServer.registerAndLoadModel. Alternatively NodeManagerTable.loadModel and UaServer.registerModel.

Because ClassCastException happens, I believe you have not registered the CodegenModel of your type. The reason why ClassCastException happens is because the node builder only uses the types in the address space, i.e. it should work also for non-generated types; it instantiates whatever has been registered for the type, falling back to more general nodeclass based ones if nothing has been registered. The build() casts the result expecting it to work (since the class should be registered, it should be also the one returned).

– Bjarne

July 29, 2015
21:02, EEST
Avatar
hbrackel
Member
Members
Forum Posts: 144
Member Since:
February 21, 2014
sp_UserOfflineSmall Offline

Problem solved —

as I registered and loaded multiple models, the IDE autocompleted the packages for the Information.MODELs. The information.MODEL registered for my custom DI derived types actually pointed to the original DI types. After adding the full package name, the custom types can now be instantiated correctly.

Thanks,
Hans-Uwe

July 30, 2015
7:17, EEST
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 1026
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Great!

Hmm need to think if this could be improved somehow.

– Bjarne

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 1919

Currently Online:
12 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: 738

Moderators: 7

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1524

Posts: 6451

Newest Members:

jonathonmcintyre, fannielima, kristiewinkle8, rust, christamcdowall, redaahern07571, nigelbdhmp, travistimmons, AnnelCib, dalenegettinger

Moderators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1026, Jimmy Ni: 26, Matti Siponen: 346, Lusetti: 0

Administrators: admin: 1