If discover shows UNKNOWN_* objects, missing semantic kinds, or wrong type classification for your CODESYS version, fork, or vendor package, please report them here.
Useful data:
- CODESYS version and fork/vendor
- script version
- object name, detected kind, and GUID
- parent/context in the project tree
- how the object should behave: text, native XML, export-only, or skipped
- a short discover/log snippet or screenshot
Example:
|-- MyObject (UNKNOWN_abcd1234 | abcd1234-1111-2222-3333-444455556666 | ScriptObject)
The type system is profile-driven, so many of these cases can be handled through profile JSON rather than runtime hardcoding.
I want to keep the runtime and profiles/default.json conservative, because I cannot validate every fork, vendor package, or object model variation myself. For that reason, broadly safe and verified mappings may go into the default profile, while fork-specific or vendor-specific mappings are better kept as separate opt-in profile JSON files.
If there is enough community input, we can also discuss the best way to share such profiles:
- keep contributed profiles in this repository
- keep them in a separate profile repository
- or keep company-specific profiles private and outside the main repo
For now, this thread can be used both to report missing mappings and to discuss how shared profile JSON files should be organized.
If discover shows UNKNOWN_* objects, missing semantic kinds, or wrong type classification for your CODESYS version, fork, or vendor package, please report them here.
Useful data:
Example:
|-- MyObject (UNKNOWN_abcd1234 | abcd1234-1111-2222-3333-444455556666 | ScriptObject)
The type system is profile-driven, so many of these cases can be handled through profile JSON rather than runtime hardcoding.
I want to keep the runtime and profiles/default.json conservative, because I cannot validate every fork, vendor package, or object model variation myself. For that reason, broadly safe and verified mappings may go into the default profile, while fork-specific or vendor-specific mappings are better kept as separate opt-in profile JSON files.
If there is enough community input, we can also discuss the best way to share such profiles:
For now, this thread can be used both to report missing mappings and to discuss how shared profile JSON files should be organized.