Epson RC+ Project Structure Explained: Files, Folders, and Flow

This article is the second in a series that explains the basics of creating a base project using Epson RC+, Epson’s software for developing and simulating an industrial robotic application. Epson offers a wide range of industrial robots for a variety of applications.

The programming and configuration of the robots are done through the easy-to-use configuration software, Epson RC+, which offers many time-saving features and various add-on packages depending on the complexity of each application. We will cover the overall project structure, types of files, and how they all work together in the application.

Program Files

This will contain all the logic for the robot application. You can define functions to call from within the robot program or leverage an external trigger, such as a PLC. When developing the robot application, you must have a function called “Main”. If this function is not defined, the compiler will throw an error. The main function is called when none of the 6 program bits are set. See the table below for the main functions that can be selected from the remote inputs.

The entire robot program can be written in a single program file or across many.  For organizational purposes, we generally like to separate functions into multiple programs for easier navigation, and based on which program tasks are executed. 

Include Files

Include files are generally used to define constants that can be used across the user program. To create an include file, right-click on “Include Files” in the project tree and select “New”. Fill out the dialog window as follows. We have added two constants for max parts and max speed, which can now be used in the robot program.

By putting all the constants into a single include file, we can use a single line at the top of the program file to give the functions access to use these constants. In the screenshot below, the first line contains an ‘include’ statement that references the constants file we just created. This allows the main function to use the defined constant values instead of hard-coded numbers.

Point Files

Point files are table-style views of all defined points for use in the robot program. The points can be manually adjusted from the programming environment, taught using robot manager, and assigned calculated values during program execution. Each point file contains points numbered from 0 to 999, and there can be multiple point files per robot. There can even be multiple robots per controller, depending on the application requirements.

In this example, we have simply added the two points ‘ptStart’ and ‘ptEnd’. The point files contain data for the most complicated examples, but depending on the application, some are not used. This example uses a SCARA robot, which only uses the X/Y/Z/U positions, since it is a 4-axis robot. Also included in this view is the Local coordinate system used and which Hand (Righty/Lefty) configuration the robot is in for that point.

In the program, the points can be used symbolically as shown below. The Go instruction is a move command for the robot, and the operator can simply use the point label defined in the Points file to access the robot’s positional data.

IO Labels

IO labels are used to assign symbolic names to integer values that represent input and output memory locations. These are useful when performing Input and Output mapping in the user program, rather than leveraging the hardcoded bit/byte/word values in the IO space. Below, we define 2 input bits and 2 output bits to simulate reading and writing to digital IO. The standard I/O is used for local IO on the robot, such as devices on the end-of-arm tooling.

To use these labels in the program, the user must use the proper input and output functions. Below is an example of using the Sw() function to read the status of the input bits and the On/Off functions to assign the output bit value. Notice how the IO Labels are used with these functions to make the logic more readable.

User Errors

User errors define an error space for the user to create custom error messages. The error codes reserved for this are from 8000 to 8999. When using these error messages, we can communicate the issue to an operator via the message field. This message will appear in the Status window when an error occurs in the program logic. This error code can also be used to communicate with the PLC controlling it, enabling easier diagnostics when the robot is not performing properly. A good example of this is communicating issues with tooling actuation controlled locally by the robot controller, even though the robot is part of a larger automation cell.

This example below shows the Error function used with the ‘ToolingError’ User Error we just created. When the Function fcVacuum_ON is called from elsewhere in the user program, it turns on the vacuum gripper’s output and waits for 2 seconds for the vacuum switch input to turn on. The TW value will be true if the 2-second timeout is reached, which is why the Error is thrown within the if statement in this example.

Tasks

Tasks are useful for executing the program on different threads within the robot controller’s CPU.  This allows the robot controller to process different pieces of logic simultaneously. The most useful example of this is having logic that performs Input and Output mapping in a separate task from the logic that controls the robot motion or tooling actuation. It is often desired to keep the functions used to read and write to IO running all the time, but to have the motion commands and functional logic in a task that can be paused or aborted during an Emergency Stop.

The example below shows how to start the IO monitoring function and motion logic in separate tasks. To start a new task, the ‘xqt’ instruction is used with the function that starts in the new task, and the task behavior when a Pause or Emergency Stop is issued. The IO function is set up to continuously run on Emergency Stop, where the motion logic function is set to Normal, which will respond normally to a Pause or Emergency Stop command.

Conclusion

Now you have a basic understanding of how to organize an Epson RC+ project, and you have all the tools needed to get started creating your own application. The most important starting point is to create a ‘Main’ function in a program file and define a few robot points to use in the program. Then I would suggest adding constants with include files and user errors for better troubleshooting. Finally, you could start adding different task executions for different functions. Understanding how all these components interact is vital to developing higher-quality robot programs.