This page provides a detailed overview about the Device Editor.


Contents


Device Editor


The Device Editor is used to configure and manage external signalling devices that are communicating with the Robot.


Full screen point DeviceE.png


Inside the Panel


Device editor atopen.PNG


Name: User defined device name

Status: Current connection Status shown by a Green or Red indicator.

Green: Device is connected to the Robot

Red: Device not connected to the Robot


Robot IO


The Robot IO is the built in IO board that is located in the Controller. The Robot IO is a Moxa E1212 Unit, it is equiped with 8 Input and 8 Output channels.

More information on the Moxa E1212 can be found at this page, Moxa E1212.

The Default IP Address for the Robot IO is 203.0.113.129. This will only be neccessary if there is a reset done on the Moxa E1212.


Attention


The Physical Connection: The Ethernet cable must be connected to the robot’s external or internal Ethernet port. It can then be run directly to the device, or to a network switch to which the device is also connected. The most common configuration is to a dedicated switch on an isolated manufacturing network. The benefit of using a switch is that it is possible to also connect a computer to open Intera Studio.

Note: As of Intera 5.3 the internal Ethernet port can be used so long as the port is enabled in the Field Service Menu. Also, do not use the spare port on the Moxa IO device inside the robot controller cover.

Mapping: The only way to know the correct mapping of a device is to consult the user guide of the Device.


Add a Device


To Add a Device open the Device Editor Panel and click the Plus icon at the top right corner.


Device editor plusclick.png


Choose the Device Type, Modbus or TCP/IP, suited for the operation.


Device editor addDev.PNG


EtherNet/IP & Profinet


All users are recommended to first read the general documentation regarding Fieldbus Devices. This page will instruct users how to enable EtherNet/IP and PROFINET through the Field Service Menu. This is a required step before these industrial protocols can be configured in Intera.

Additional documentation such as the GSDML (PROFINET) and EDS (EtherNet/IP) can be found on the specific pages for each protocol below:


Modbus


To configure a Modbus device a user must provide the following information:

Name: User defined name of Device.

IP Address: The IP address of the connected device. For more information see IP Addressing.

Input/ Output Prefix: A prefix for inputs and a prefix for outputs. These prefixes are user defined and are there to help the user identify which signals are input signals or output signals. It is usual to align this naming scene to the connected device's.

Input/ Output Signal Range: The range of input and Output signals. This range will represent the specific channels that will be used. Once they are identified and define, the channels will be auto-populated in the Signals Panel. Unused channels do not need to be present in the Signal range.

To do this separate individual signals with a comma(,) and define ranges with a dash. See the figure below for an example Input Signal range which uses channels 1 and 3 as well as all channels from 4 to 7.


Inputs Outputs Edit example.png

 

Once all the fields are specified the device can be saved. Back in the gallery of the Device Editor the connection status of the device will be shown as Green, connected, or Red, Not connected.

For further information on Modbus Communication visit this page, Modbus Communication.


Device editor Modbus.PNG

 

Signals and Next Steps


After successfully setting up a Modbus device, the specific inputs and outputs will be available to edit in the Signals Panel. See the Signals Panel for steps on configuring specific lines and changing signal names.


TCP/IP


TCP/IP communication allows Sawyer to communicate with many other types of devices and allows the reading and writing of many different types of data. This feature was introduced in Intera version 5.1, and expanded in version 5.2 to all the data contained in the shared data panel, with a couple minor exceptions.

The scope of TCP/IP communication in version 5.2 is limited to the ability to send and receive messages. It is up to the customer to generate and send data to Sawyer and to do something with the data that Sawyer sends. In order to make use of the data, the customer will need to implement their own server that can read, parse, record, and report on that data. At this time, Rethink Robotics does not offer any product to do those things, nor does it support the system with which Sawyer is communicating.


TCPIP diagram.png


 TCP/IP communication with Sawyer works by sending and/or receiving delimited strings of data. Configure Sawyer in Intera Studio as follows.


Tcpip Start.PNG

 

Name: Name of the device with which Sawyer is communicating. This is user definable.

Sawyer Will: Choose if Sawyer will "connect to a device" (Sawyer is the client) or "receive connections" (Sawyer is the server). If Sawyer is the client, you will need to supply the IP address of the network device to which it is connecting. If Sawyer is the server, the other device will need to know the IP address of Sawyer. Setting a static IP address on Sawyer is recommended in this situation.

IP Address: The IP address of the connected device.

Port: The Port over which the communication will take place.

 

Receiving Data


Sawyer receives a single long, continuous string of data which can contain multiple values in the same message. When Sawyer receives a string of data, it needs to be parsed and each segment placed into a variable. The number of values, the delimiters between them, and the names of the variables are defined as described below. This is done in the UNPACK DATA - IN section.


Tcpip unpackIN.PNG


Start Delimiter: Indicates the start of a message. Possible delimiters are any character or tab (\t), return (\r), new line (\n), or return + new line (\r\n).

End Delimiter: Indicates the end of a message.

Internal Delimiter: Separates fields within the text string.

Max Bytes: Defines maximum number of bytes that constitute a received message. If a message is received with no end delimiter, the signal will be updated with the data if the incoming data is equal to or larger than the Max Bytes.

Timeout: If a full message is not received in X seconds, it's dropped; wait for another message.

 

Define the name and Default Value of the data in the section DEFINE DATA - IN.


Tcpip unpackOUT.PNG

 

Sending Data


Sawyer sends a single long, continuous string of data which can contain multiple values in the same message. When Sawyer sends a string of data, each value it sends can have a delimiter between them. This will allow the receiving device to parse the string and know what to do with the individual values. The number of values, the delimiters between them, and the names of the variables are defined as defined in the PACK DATA - OUT and the DEFINE DATA - OUT sections similar to the UNPACK DATA - IN and DEFINE DATA - IN sections. Save the information and return to the Gallery to confirm connection and communication.


Testing


You can see data being received and manually update and send data using the Shared Data panel. You can use third party products such as Putty or Packet Sender to easily test sending and receiving data. Keep in mind that Rethink Robotics does not support the configuration or use of these products, nor the network configuration. Keep in mind that proper IP addresses, subnet masks, and default gateway settings are required on both devices in order to communicate. some additional information on those topics are located in the Connecting to a Network section and Static IP section. Contact your network administrator for assistance with IP addressing.


Using Received Data in a Behavior Tree


The signals will update as soon as the data is received even if the task is not executing. In the behavior tree, there are many ways to use the data. The most common will be with a Do If node. For example, execute a branch of logic if a received signal is equal to a specific value. See the tutorial on Using TCP/IP for specific examples.


Sending Data from the Behavior Tree


To send data while the task is running, use the Set To node to set the signal to a desired value. In order to send data from the Shared Data, set the signal equal to the value from Shared data. In order to do so, make sure they are of the same data type. For example, if I want to send the position of the tool plate in the Z axis, I would configure a signal as a float with mm as the units. If I use the default name of the signal, it will be "Signal_0_out". In the behavior tree, I will create a Set To node that sets Signal_0_out" to "MEASURED TOOL POSITIONS" -> "ROBOT" -> "TOOL PLATE" -> "Position.z".


Positionz.PNG


Whenever the Do If node is executed the entire string of data will be sent, including all other signals that are configured whether or not any of them have changed. If you want to send data on a regular basis, for example every 5 seconds, you can put a continuous loop in a parallel node with a Set To node and a Wait node. It is recommended to always have a Wait node because sending data too fast may have adverse affects on Sawyer, the network, and or the receiving device.

Senddatacontinuously.PNG


Device Classification (new in Intera 5.5)



Devices are classified into USED BY, USED BY OTHER TASKS  and UNUSED categories. Use the attach and detach button to move a device between the different categories. 

  • USED BY: This consists of the devices that are attached to the current task. Signals of devices in this category can be used in the task and the device would be saved with task. 
  • USED BY OTHER TASKS: This consists of devices that are used by other tasks. "Other tasks" are tasks that are closely linked with the current task. As an example, the main task is "other task" to a subtask and vice versa. Signals of devices in this category cannot be used in the task until it is attached to the task and moved to the USED BY category. 
  • UNUSED: This section consists of devices that are unused by both the current and supporting tasks. 

Known Issues


  • Tools and devices in the unused category that are not used by any task or "other task" would not be available after a restart, therefore make sure the tools or devices are attached to at least one task. The saved tools can still be accessed through the import tool function.