OneToOne Interface and OneToMany Interface's Setting guideance

Do we have the guidance document on “Section and Fields” settings for both OneToOne Interface and OneToMany Interface behaviors?

I can only learn a part of the knowledge by the teaching video, others are difficult to master.

So, I hope to get help. Thank you very much!

In the Help file:

  • Reference Guide > Behaviors > Interfaces or
  • Documents > Components > Behaviors
Some quick tips:
  • Flow fields are used for transferring components to and from different containers. Conveyors, for example, use flow fields to connect the inputs and outputs of their paths.
  • Hierarchy fields are used to attaching nodes to one another. Robots and grippers, for example, have a Hierarchy field. The robot flange would be the node and its role is parent. The gripper root node would be the node and its role is child. So when robot arm moves the gripper moves with it.
  • Signal fields are used to connect signals. The role of a signal is confusing, so usually the default value is fine. A gripper that uses signals to open/close its jaws, for example a schunk gripper in eCat or a component modeled using the IO/EOAT wizard, is a good example of how to use the fields.
  • RSL fields... imo they are deprecated, but you can still use them to remotely connect robots or special accessories. For example, you might want a robot in a cell of four robots to be a master and the others slaves/child. The master would subscribe to the programs of the child robots, and the child robots would publish their programs, so the master could remotely call routines. I have not seen it used in 4.x, but I did use it in 2012 and 2014 versions.
  • Processor fields are used to connect external sensors to paths. Conveyors and sensors, for example, use processor fields, and the Processors smart collection in the eCat are examples of this field. Generally, a path is a parent, and a sensor is a child. In the past, the field was for Process Point Sensors, but it seems that component path sensors can also be used with the field, at least in latest version 4.1.1.
  • Integer/Compatibility fields are mostly used for filtering and restricting connections. For example, if you know certain components should not connect to one another like different models of conveyors, use an integer field to restrict the connection to two interfaces that have a matching integer field number. Not sure where in eCat there are still examples, but try looking at some conveyors and robots if they are still using them. It is common to use an integer field with other fields.
And one important point:
  • Fields are evaluated in order from top to bottom! That is, even if two interfaces have the same fields but in a different order they are not compatible. Take a look at the interfaces of the Generic Robot. It has to support different types of EOAT connections, some that connect signals, some that just attach the tool. So the interface has different sections for those possible connections, and each section has one or more fields in a particular order. A gripper would need to have matching fields in the same order in an available section for the connection to be made. You can test on your own and become more familiar with this by modeling a simple gripper and playing around with the order of its fields and connecting it to a robot.
Try the Model a Turn Unit tutorial in academy to get some semblance of fields. And also review how a cross conveyor is modeled in eCat.
1 Like

Ok,I got that.Thank you for your answer very much.