The CSV file would contain the following columns:
Name | Entity | Component | Property
The idea is that, knowing the names of 3D model objects (entities/components) and the tag names from the PLC program, the user could quickly create all required bindings by importing a single CSV file.
This would:
-
Eliminate repetitive manual clicking and configuration
-
Significantly speed up project setup for larger models
-
Reduce human errors when mapping PLC variables to 3D model properties
-
Improve workflow for automation engineers working with complex digital twins
Thanks for the suggestion. This sounds like a useful feature.
The only issue is that entity names don’t need to be unique. Additionally, you can have more than one component of the same type attached to a single entity. For example, you can have multiple Motor components attached to the same entity. This creates an ambiguity. In such cases, we’d need to skip over the binding and display an error in the console.
I’ll try to get this feature implemented within the next few days.
That would be great 
also CSV bindings export could give some more flexibility.
Components but also part names might be ambiguous
as different parts could have same names
but this is for the user to take care of.
1 Like
An update has been published that adds a button to the bindings table for importing and exporting the bindings from/to CSV.
The columns required (in any order) are:
- Server: The name of the Tag Server
- Tag: The identifier for the tag (format depends on protocol)
- Entity: The hierarchical path for the entity, or just an entity name.
- Component: The component type name (may be disambiguated using the component name)
- Property: The signal name
- Direction: ReadFromServer or WriteToServer
For the tag identifier, use exactly what is displayed in the name column for the tag. For Beckhoff ADS and other tag-based protocols, this is just the qualified variable path (e.g. ProgramName.VariableName). For address-based protocols, such as Siemens S7, this is the address specified in the usual format (e.g. %I0.0).
To help disambiguate entities, you can specify the full hierarchy path. For example, “Robot/Link 6/Gripper” as opposed to just “Gripper”. However, if your entities are uniquely named, you can just specify the entity name.
To help disambiguate components, you can rename a component and specify the name of the component in parenthesis after the type name. For example, instead of just “Motor”, you can specify “Motor (Pusher)”, where “Pusher” is the name assigned to the motor component.
When importing, any errors will be detected and printed to the console. This includes cases where the entity or component are ambiguous.
Would you also like to be able to import/export the tags from/to CSV?
Tags from CSV would be nice as well specially for those PLC brands that don’t have simulators. Then it’s possible to prepare everything offline before having online PLC on your desk.
Another place where import/export might be useful is Entity component configuration
if components like TRANSPORT SURFACE, MOTOR etc could be imported the workflow with having for example dozens of conveyors objects, PLC tags prepared externally in Excel would be complete.
But this is probably more complex to introduce in some hierarchy json or xml…
For exporting with checkboxes which Entetities, components should be included in exported csv. Then this could be imported into any other new model that we want to start from scratch giving us some kind of a template feature.
Another small improvement :
In bindings it is possible to select different Entity for given Tag but sometimes it might be useful given EntityComponetProperty assign to different Tag which now is not freely selectable.
PS. I don’t know what time zone you’re in but it seems like you never sleep just coding/publishing new features
I will add importing/exporting tags from CSV.
You can import one model into another. This will import all the entities and components. We also plan to add the possibility to copy and paste components from one set of entities to another set of entities. This would be useful if you have several conveyors that are all configured the same. It would allow you to configure one conveyor and then copy/paste the components to all the other conveyors.
I think it would be quite difficult to configure components outside of the editor. Technically, it can be done already, but it’s quite complex. The model configuration, including all entities and components, are stored in a single json file. The ptm format is just a zip, which contains the project.json file along with various assets. However, I wouldn’t recommend editing by hand. The chance of breaking something in the model is very high.
I know that some users create separate models for all their pieces of equipment, and then just import all these models into another model when they want to create a larger system. I think we can better support this workflow by additionally importing tags and bindings when importing models, which we don’t currently do. We also plan to add the ability to procedurally generate meshes. This will allow us to create things like a parametric conveyor component, for quickly creating large systems.
Can you clarify the last suggestion? Do you want to transfer the configured entity/component/property to a different tag? For example, to drag and drop the configuration to a different tag?
That’s good to know and interesting to see how everything is structured inside. For sure not easy to change anything externally but at least it’s possible
Do you want to transfer the configured entity/component/property to a different tag?
yes, with a dropdown menu or dragging to a different tag as you mentioned.
