Mobile Robot Function Blocks for Sysmac Controllers

ATC Europe

Starting Guide. Ver 1.0 RC7

ARCL, Fleet Manager and Robot common communication protocol

COMPUTER PROGRAMMING LANGUAGES

ARCL FEATURES

• Telnet protocol

• Text message oriented

• Human readable

• > 100 robot’s

commands

• Example: Goto Goal01

PLC PROGRAMMING LANGUAGESPLC PROGRAMMING LANGUAGES

ARCLARCL

ARCLARCL

OMRON’S PROPIETARY PROTOCOL

Introduction, communication protocol

Important utilization considerations 1 of 2

� This library is a wrapper of the ARCL (Advanced Robotic Command Language). Read the mobile robot’s ARCL reference

guide before using the library to understand the protocol and its features

� The library can be used to connect a PLC to a robot or fleet manager via WIFI or Ethernet cable. Read the LD series

manual and fleet manager’s manual to understand the connectivity capabilities of these devices

� The library allows to connect a Sysmac PLC to one or several LD series mobile robots, or one Fleet Manager. Each

connection and each FB execution increases the PLC work load. Test the library meticulously and fine tune the PLC

program to avoid to overload the PLC

� Follow the following suggestions to minimize the PLC’s workload:

• Understand and test the ARCL protocol and the Sysmac’s library

• Select the correct controller (speed and memory)

• Program the robot out of the primary task, in a periodic task (20ms or 50ms are recommended)

• Connect to the minimum possible number of robots simultaneously

• Execute the minimum possible number of function blocks at the same time

• Fine tune the task settings “task timeout” and “task period exceed”

� You can use the port forwarding robot capabilities to online programing or monitoring via Sysmac Studio a PLC

installed on the top of a robot

Important utilization considerations 2 of 2

� Use the library taking into account the feasibility of the connection between the controller and the robot. Take into

account the possibility of losing the connection specially in the case of both devices will be connected via WIFI

� There are some topics to take into account about connection lost management. Review the “ARCL_Connect” function

block’s documentation to know more details

� The FB “ARCL_Connect” tries to reestablish the connection when it is lost

� The lost detection depends of the TCPIP parameter “Keep alive monitoring time” and the the “ARCL_Connect”

function block’s input “FastDiconnDetect”

� The best decision about fast or slow detection depends of the application

� The slow detection have the following effects:

• Continues working during short network loses but the messages sent and received are delayed

• It can affect the program flow due the program continues working without knowing that the communications

are lost

� The fast detection have the following effects:

• The network lost is detected and the “ARCL_Connect” function block start the reconnection procedure losing

the possibility of send and receive messages during this process even the lost will be very short and the

communication will be reestablished

PLC connection to Robot or Fleet Manager via the Sysmac’s library

SYSMAC CONTROLLER

Robot

Fleet manager

ARCL

(WIFI OR ETHERNET)

Considerations about the controller’s task configuration

• It is recommended to execute the robot control program out of the primary task to avoid to affect the machine control

program. A fine tuning is needed in function of the program requirements

Considerations about the controller’s ethernet port configuration

• Configure the “Keep Alive monitoring time” parameter of the “Build-in Ethernet/IP Port Settings”. Set the appropriate

value for this parameter. A value of 1s second allow to detect a connection lost in about 30 seconds. Upper values

increase the connection lost detection time. Decide the most appropriate value for the application taking into account if

you want to detect short connection losses and take actions or prefer not to detect short connection loses and allowing

the system to manage the communications by itself with delayed messages

Function block architecture

• The function blocks are based on the TCPIP function blocks supplied on the Sysmac platform.

• The robot’s function blocks are designed using a multilayer architecture to ease the translation to other platforms.

Only the custom socket layer have to be translated

SktTCPConnect

ARCL_Base_SktTCPConnect

Control Robot 1

ARCL_Connect

Firmware Socket LayerSktTCPClose SktTCPSend

ARCL_Base_TCPSend Custom Socket Layer

ARCL_SendCmd ARCL_DoTask ARCL Commands Layer

Control Robot 2 Control Robot N Robot Control Layer

Function block development considerations

• The function blocks are developed in structured text to ease the translation to other platforms

• The interfaces and the source code are well documented

Function block interface considerations

• The Function blocks’ common inputs and outputs follow the Sysmac’s standards

• The function blocks give additional human readable information about the status and error

conditions to ease the program monitorization, traceability and diagnostics

• The function blocks give information regarding the time elapsed for efficiency measurement

Function block’s common inputs and outputs

• Execute (In) -> Starts the function block execution (ARCL command) and keeps it active

until finish. If this signal goes down the function block is interrupted but it doesn’t

affect the robot current activity

• AIV (In)-> Identifies the robot connection (socket). It allows each function block to

communicate with the correct robot

• Timeout (In) -> Maximum time allowed to complete the instruction. If it is elapsed the

function block finish with a timeout error. It doesn’t affect the robot current activity.

It the timeout is 0ms the FB doesn’t wait until the robot completes the command.

• Done (Out) -> Indicates that the robot has completed the instruction successfully

• Busy (Out) -> In the case of the ARCL_Connect function block the Busy is true during

the connection process for the rest of the function blocks the Busy signal becomes

TRUE when the command has been successfully sent

• Error (Out) -> Indicates that the instruction has not been completed successfully

• ErrorID (Out) -> Error type identifier. Not standardized at this moment

• ErrorDesc (Out) -> Human readable error description

• Status (Out) -> Human readable current function block execution status

• TimeElapsed (Out) -> Time elapsed since the function block starts. Useful for

traceability and efficiency measurement

Function block common sequence• If a Timeout is specified the function block waits for the robot to complete the requested ARCL command. If the Timeout

is 0ms the function block sends the command to the robot and finish

• IMPORTANT: Each active function block analyses the incoming messages from the robot to know when the robot has

finished the ARCL command. Try to avoid to execute several FBs at the same time to prevent CPU overload

• The function blocks never block the PLC program

• A timeout can be programmed to avoid waiting more than the expected time

• The function blocks can be interrupted at any time disabling the “Execute” input, but it doesn’t interrupt the robot

• A timeout error is generated if the function block is interrupted before the sequence is finished

• If the PLC loses the connection with the robot all the function blocks in execution are aborted

Send ARLC Command

Receive Robot Messages

DoneError

Timeout

Done ARCL Error Timeout Abort

Execute

Discon

nected

Abort

Function blocks available

• There are multiple function blocks for several types of functionalities. There are function blocks

for managing robot connections, jobs, tasks, navigation, etc.

Function block for robot connection management

• The function block for managing robot connection allows to open a connection

between the controller and a robot. It is possible to create multiple instances to

connect the controller with several robots at the same time

• The function block connects to the robot and supervises the connection. If the

connection is lost the function block tries to re-stablish the connection

• IMPORTANT: A “ConnId” must be supplied to the function block. This

identification is added to the “JobId” in the job management function blocks to

speed up the message processing and reduce the PLC’s CPU workload

• IMPORTANT: Decide the value of the input “FastDiconnDetect” in function of

the application. A fast detection allows to take actions quickly but detects short

connection loses that could not effect the robot’s work and can be managed

automatically by the controller’s firmware. In any case the error outputs show

information when a short connection losses are detected

• IMPORTANT: Don’t use the output LastMsg to know the robot status. This

output changes each time that the FB receives a new message. Take into account

that the robot’s ARCL server broadcast unexpected messages to all the

connected clients

Function blocks for getting the robot’s status information

• The function blocks for getting the robot’s status allow us to get information regarding the current position, robot activity and

battery status. The function block ARCL_Status implements the ARCL command “oneLineStatus” and the function block

ARCL_StatusNoOneline implements the ARCL command “Status”

• IMPORTANT: Prioritize the use of the function block ARCL_Status over the use of the function block ARCL_StatusNoOneline due

the ARCL command “oneLineStatus” creates less messaging traffic and less processor workload than the command “Status”

Function block for sending any ARCL command

• This function block sends an ARCL command to the robot and finish. It doesn’t wait for a response from the robot

• It is internally used by other function blocks to send commands but can be used at program level as well

Used in others FB definition

Function block for sending any ARCL command and wait for a message

• This function block sends an ARCL command to the robot and waits until receive a specific message from the robot

• IMPORTANT: The message received is deleted from the message queue so if any function block waits for the same

message it will wait forever or until a timeout error

• IMPORTANT: Messages regarding the ARCL commands “QueueQuery”, “QueueShow”, “QueueShowRobot” and

“QueueShowRobotLocal” cannot be wait due they are treated in a different way by the library

Function block for wait for a message

• This function block waits until receive a specific message from the robot

• IMPORTANT: The message received is deleted from the message queue so if any function block waits for the

same message it will wait forever or until a timeout error

• IMPORTANT: Messages regarding the ARCL commands “QueueQuery”, “QueueShow”, “QueueShowRobot” and

“QueueShowRobotLocal” cannot be wait due they are treated in a different way by the library

Function block for executing tasks

• This function block implement the ARCL commands “doTask” or “doInstantTask” depending of the status of the input

“InstantTask”

Function blocks for cancelling tasks

• Theses function blocks implement the ARCL commands “waitTaskCancel” and “waitTaskFail” (not documented). Both

are the same behavior but the first one finish the task with cancel code and the second one with fail code

Function block for managing pickup jobs• This function block implement the ARCL command “queuePickup”

• IMPORTANT: The connection “ConnId” and the chart “_” are added as a header to the “JobId”. So the JobId received to the

robot is [ConnId]_[JobId]. The JobId is mandatory to allow the function block to identify its messages from the robot by

lower processor work load

Function block for managing drop off jobs

• This function block implement the ARCL command “queueDropoff”

• IMPORTANT: The connection “ConnId” and the chart “_” are added as a header to the “JobId”. So the JobId received to the

robot is [ConnId]_[JobId]

Function block for managing pick up - drop off jobs

• This function block implement the ARCL command “queuePickupDropoff”

• IMPORTANT: The connection “ConnId” and the chart “_” are added as a header to the “JobId”. So the JobId received to the

robot is [ConnId]_[JobId]

Function blocks for cancelling jobs

• There are several function blocks for cancelling jobs. They implement the ARCL commands “queueCancel” or

“queueCancelLocal” depending of the value assigned to the input “Local”

• IMPORTANT INFORMATION. It is necessary to add the “ConnId” and the char “_” to the JobId to cancel jobs created by the

function blocks queuePickup, queueDropoff and queuePickupDropoff due they add this header to the JobId

Function blocks for getting information about jobs’ status

• There are several function blocks for getting information about the status of the jobs in the queue. They implement the ARCL

command “queueShow” and the commands “queueQuery” or “queueQueryLocal” depending of the value for the input “Local”

• The function blocks fill a job list up to 100 jobs with the status of the jobs in the queue. In some of them it is possible to avoid to

receive information about the completed jobs by activating the input “ExcludeCompleted”

• IMPORTANT: These function blocks can generate a big amount of messages and overload the PLC’s. Test them before using

Function blocks for getting information about robot status

• There are several function blocks for getting information about the robot status. They implement the ARCL commands

“queueShowRobot” and “queueShowRobotLocal”

• The function block fill a job list up to 25 robots with the status of the robots. IMPORTANT: It is not possible to ask for

information about a robot in a fleet due the ARCL command “queueShowRobot” doesn’t return this information

• This function block implement the ARCL command “inputQuery”

Function block for reading digital inputs

• This function block implement the ARCL command “outputQuery”

Function block for reading digital outputs

• This function block implement the ARCL command “outputOn”

Function block for deactivating digital outputs

• This function block implement the ARCL command “outputOff”

Function block for activating digital outputs

• This function block executes the task “localizeAtGoal”

Function block for localizing a robot at a goal

• This function block implement the ARCL command “goto”

• The “DefaultHeading” input allows to decide if to use a specific heading or the heading defined in the goal

• The “Heading” has to be in the range of -179 to 180. If it is out of range the default goal value is used

Function block for sending the robot to a goal

Function block for sending the robot to a point in the map

• This function block implement the ARCL command “gotoPoint”

• The “DefaultHeading” input allows to decide if to use a specific heading or the heading defined in the goal

• The “Heading” has to be in the range of -179 to 180. If it is out of range the default goal value is used

Function block for implementing the task “Go”

• This function block implement the task “Go” to cancel in progress waits

• This function block implement the ARCL commands “dock” and “undock”

Function blocks for sending the robot in and out of the dock station

• This function block implement the ARCL command “enablemotors”

Function block for enabling the robot’s motors

• This function block implement the ARCL command “stop”

Function block for stopping the robot

• This function block implement the ARCL command “follow”

Function block for putting the robot in following mode

• This function block implement the ARCL command “say”

Function block for speaking

• This function block implement the ARCL command “ARCLSendText”

Function block for broadcasting text messages to the robot’s clients

• This function block implement the ARCL command “ARCLSendText”

Function block for broadcasting text messages to the robot’s clients

Mobile Robot Function Blocks For Sysmac Controllers

ATC Europe – Francisco Rodríguez

Simple Example Application

Usual pickup-dropoff job’s sequence

Pickup-Dropoff job request

Move to pickup goal

Pick up

Move to dropoff goal

Drop off

Machine – robot

communication

Robot moves and

communicates status

Synchronization with

machine

Robot moves and

communicates status

Synchronization with

machine

queuePickupDropoff command

Parts supplying to a machine by direct communication machine-robot

• The communication is via wifi

• The machine’s controller

request parts to the robot via

function blocks

• The robot starts a pickup -

dropoff job

• During the job the machine can

know the status and position of

the robot via function blocks

Job information

Job information

Route to pickup goal

Route to dropoff goal

How difficult is the program the machine to control the previous sequence?

Open communication with the robot

Program the logic to decide the goal

Send the robot to the goal

Implementation example using Sysmac’s function blocks

Open communication

with the robot

Program the logic to

decide the goal

Send the robot to the

decided goal

Mobile Robot Function Blocks for Sysmac Controllers

ATC Europe