custom nodesets #56
Replies: 8 comments 11 replies
-
|
Depends on what you want to create, we currently require BSD files if you want custom OPC-UA types. The problem is that there is information that simply isn't present in NodeSet2 files that we require. It may be possible to support NodeSet2 files in the future, and error out if we hit any of those cases. As for dependencies, you have to plumb that yourself, it's not really that hard to do. The code gen config takes a list of targets, you need to generate each file independently, then modify the As for the XSD file, you only need that if your NodeSet2 file has XML versions of any of the types it defines. Doesn't look like AutoID has that. Codegen based on NodeSet2 files is a fairly large effort, so I don't know when that will happen. The current code gen is pretty tightly connected to the types we read from BSD files, and there's some fiddly logic to make everything work correctly. |
Beta Was this translation helpful? Give feedback.
-
|
@basyskom-dege It's now possible to generate types using NodeSet2 files. It's still a bit experimental, so I can't guarantee it will work for you, but it may be worth trying. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the quick follow up! I will look into it. |
Beta Was this translation helpful? Give feedback.
-
|
Hey! I tried to generate the autoID nodeset but without luck. A lot of types are not found, Nodeid names are doubled (I think because they are inherited from DI but with other Nodeids). Here is my YAML content. Am I missing something? Auto Id has no XSD file... |
Beta Was this translation helpful? Give feedback.
-
|
I'll look into it... It doesn't really surprise me that there are issues. You will need to generate the types for |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! DI worked fine. I included the generated stuff from DI. The errors occur on types from AutoID though |
Beta Was this translation helpful? Give feedback.
-
|
So, I had a look. There's an error caused by a It also seems like the schema is entirely missing the The solution to the node ID problem is probably to allow generating types without relying on the node ID enums at all, which is now possible. It's a bit of work, however. This wasn't as bad as I thought, there's not really that much work necessary to make something that works for this as well. It might take some time before I get to it. |
Beta Was this translation helpful? Give feedback.
-
|
@basyskom-dege I've put together a PR now (#65) which I managed to get to work with AutoID. Before we make a new release I'll document things a bit better, but to make this work you need to do the following:
#[derive(Default, Debug, Clone, PartialEq)]
pub struct CodeTypeDataType(pub UAString);
impl_encoded_as!(
CodeTypeDataType,
|v| Ok(CodeTypeDataType(v)),
|s: &CodeTypeDataType| Ok::<UAString, Error>(s.0.clone()),
|s: &CodeTypeDataType| s.0.byte_len()
);
impl UaNullable for CodeTypeDataType {
fn is_ua_null(&self) -> bool {
self.0.is_null()
}
}
#[cfg(feature = "xml")]
impl opcua::types::xml::XmlType for CodeTypeDataType {
const TAG: &'static str = "CodeTypeDataType";
}though if you don't care about lists of XML items, you can also just define them as type aliases: type LocationName = UAString;Either way you need to add them to the codegen target for where With that I got it to compile, at least. I didn't end up panicking for the missing JSON encoding IDs, just fall back on the data type ID, which technically is legal. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for this! Do you mind sharing the YAML for AutoID? I cant get it to work. |
Beta Was this translation helpful? Give feedback.
-
targets:
- type: types
file: Opc.Ua.AutoID.NodeSet2.xml
output_dir: src/generated/types/autoid
enums_single_file: true
structs_single_file: true
node_ids_from_nodeset: true
extra_header: |
#![allow(non_camel_case_types)]
#![allow(clippy::upper_case_acronyms)]
types_import_map:
CodeTypeDataType:
path: "crate::types"
has_default: true
NmeaCoordinateString:
path: "crate::types"
has_default: true
LocationName:
path: "crate::types"
has_default: true
- type: types
file: Opc.Ua.Di.NodeSet2.xml
output_dir: src/generated/types/di
enums_single_file: true
structs_single_file: true
id_path: crate::di_node_ids
extra_header: |
#![allow(non_camel_case_types)]
#![allow(clippy::upper_case_acronyms)]
- type: nodes
file: Opc.Ua.AutoID.NodeSet2.xml
output_dir: src/generated/node_set_auto_id
max_nodes_per_file: 100
types:
- file: Opc.Ua.Di.Types.xsd
root_path: crate::generated::types::di
- file: Opc.Ua.Types.xsd
root_path: opcua::types
own_namespaces:
- "http://opcfoundation.org/UA/AutoID/"
imported_namespaces:
- "http://opcfoundation.org/UA/DI/"
- "http://opcfoundation.org/UA/"
name: AutoIDNameSpace
events:
output_dir: src/generated/events
dependent_nodesets:
- file: Opc.Ua.NodeSet2.xml
import_path: "opcua::core_namespace::events::"
extra_header: |
#[allow(unused)]
mod types {
pub use crate::generated::types::*;
pub use ::opcua::types::*;
}
- type: ids
file_path: schema/Opc.Ua.Di.NodeIds.csv
output_file: src/generated/di_node_ids.rs
sources:
- schema
- ../opcua/schemas/1.05/Opc.Ua.Types.xsd
- ../opcua/schemas/1.05/Opc.Ua.NodeSet2.xmlIt's pretty close to what you posted above. As you can see I no longer generate IDs for |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! But i still cant get it to compile. I get a lot of errors like How do I make use of the generated code? The custom-codegen example just uses the generated nodeset, events and types but how do I use di AND autoid? Do I need to generate both and then use them both in the main.rs? |
Beta Was this translation helpful? Give feedback.
-
|
I managed to get the above to compile... Are you getting errors about missing There's a generated type in the root of each target which is the main entrypoint. If you want to deserialize messages containing DI/AutoID types on your server or client, you need to add the generated type loader to your server/client implementation. There are methods to do so on the client and on the server builder. See https://github.com/FreeOpcUa/async-opcua/blob/master/samples/custom-codegen/src/main.rs and https://github.com/FreeOpcUa/async-opcua/blob/master/samples/custom-structures-client/src/bin/native_client.rs. It depends on what you want to do with these types. As for the generated nodeset, that's used in a |
Beta Was this translation helpful? Give feedback.
-
|
Yes I'm aware on how to use this with the NodeManager. I got it to compile now as well. But it panics right after start: It works fine for DI but i guess i will come back to this later when this is merged in a new release. But I'm glad you it works without BSD and XSD files! Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
I am curious if others have managed to generate anything re EUROMAP specs using this library Previously/currently, I am using Previously, einar helped by making some changes/fixes to the existing codegen in the repository I wanted to try reaching out to the community before I bug them again Related repository that I made for the issue It's been some time since I created that issue, and I've been busy working around other problems in the original repository Currently I'm just trying to get EUROMAP83 compiling, as that is the standard with the general types Wanted to make sure I post about my struggles here before I forget in case others have additional input Happy to provide additiona information as needed, but I wanted to be succinct/not totally bomb the thread to start. |
Beta Was this translation helpful? Give feedback.
-
|
I'd recommend you make a new issue if you're still having trouble. I recall that I managed to get this stuff to compile at least, and we've made some quite major improvements to codegen since then. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @einarmo I think I got things back into a compiling state Codegen Configuration
|
Beta Was this translation helpful? Give feedback.
-
|
Alright. So, you're in luck on several of these points. In order: Technically I believe nodesets are required to implement all encodings, but yes, you would have to stub them. Currently, the only way to have the codegen do that automatically is to set We do generate default implementations whenever possible, but sometimes:
When this is the case, we just don't have a way to know what the default should be. BSD files are no longer needed for codegen! You can just use a We don't really implement serialize at all... I suppose we could consider a |
Beta Was this translation helpful? Give feedback.
-
|
As for the issue you had with object IDs and such, it's now possible to set |
Beta Was this translation helpful? Give feedback.
-
|
I do want to get around to properly documenting all this stuff. You should look at the codegen.yml file in the repo for an example of how you use nodeset files now. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello!
I came across this fork and i am happy to see it being in active development. Regarding the nodeset compiler: is it possible to compile nodesets that depend on other nodesets? The example only did the PROFINET nodeset. I wanted to generate the AutoID nodeset but i did not succeed since there is no BSD and XSD file present.
Are there any plans to work on this? I think its necessary to support nodesets with dependencies and without BSD files. Thank you!
Beta Was this translation helpful? Give feedback.
All reactions