Control

6. Control

6.1. Configure a Virtual Controller

Objective:

In this tutorial we’ll look at how you can configure a virtual Controller to match your real Controller using the HAL Robotics Framework for Grasshopper.

Requirements to follow along:

McNeel’s Rhinoceros 3D and Grasshopper, and the HAL Robotics Framework installed on a PC.

Background:

Industrial Controllers are typically comprised of core functionality, such as the ability to run a program, extended through optional extras, like communication protocols or multi-Robot support. To ensure that we only try and interact with your real Controller in a way that is compatible, be it through a network or with exported code, we have added a means to configure your Controller. The constituent parts of this are:

a. Controller - this is essentially a computer to which your Robot and Signals are connected.

b. Capabilities - these are how we organize what a Controller can do and draw parallels between different manufacturers’ Controllers. Capabilities are things like the ability to Upload code to the Controller from a PC or the ability to read the values of Signals remotely.

c. Subsystems - these are similar to the options you have in your Controller. They are the actual software modules that implement different Capabilities.

How to:

All of these different parts are best explored with concrete examples so let’s create a Controller and look at how we can configure it. We can start by navigating to the HAL Robotics tab, Cell panel and placing a Controller. As this is a windowed component, we can double-click to open the catalog and choose our Controller preset. For this example, I’m going to use the IRC5 Compact V2 but you will find details for any other manufacturer’s Controllers in the manufacturer-specific documentation. When we select a Controller a configuration page will pop-up.

The first thing we’ll see at the top is the system version. In the case of ABB this is the Robotware version but for KUKA this would be KUKA System Software or in Universal Robots it will be the Polyscope version. It’s important to note that these are version ranges so don’t expect to see every point release listed. By changing the version we’ll change which Subsystems are available. If I switch down to 5.14, EGM will disappear from the options below because it was only introduced in Robotware 6.

The rest of the window is split in two; on the left is Subsystem and Capability selection and on the right is parametrization. In the left-hand column we can see the Capabilities listed with Subsystems that implement that Capability in a drop-down alongside. Let’s look specifically at Upload. By hovering over the name, we can see that the Upload Capability enables Procedure Uploading to a remote Controller. We can also see that there are two subsystems that offer this Capability, PCSDK and Robot Web Services (RWS). RWS is built in to the latest Robotware versions but to use the PCSDK we need the option “PC Interface” on our Controller. If you don’t have that option you can change Subsystem to ensure we use a compatible method to Upload Procedures to your Controller. There may also be circumstances where we don’t have any of the options installed or don’t want access to a Capability for security purposes. In that case we can deactivate the Capability using its toggle. On the right-hand side of the window, we have the inputs to configure our Subsystems. Only active Subsystems are listed so if we deactivate both EGM Capabilities the EGM parameters will disappear. Once we have changed the relevant properties we can select “Configure” to apply our changes. Closing the window without configuring will leave the Controller in an invalid, unconfigured state.

In future tutorials we’ll look at some specific uses of our Capabilities and Subsystems for exporting and uploading code for a real Controller.

6.2. Export a Procedure

Objective:

In this tutorial we’ll Export some robot code ready to be run on a real Controller using the HAL Robotics Framework for Grasshopper.

Requirements to follow along:

McNeel’s Rhinoceros 3D and Grasshopper, and the HAL Robotics Framework installed on a PC.

Background:

For the most part, the Programming we are doing in the HAL Robotics Framework for Grasshopper doesn’t require our PCs to be in the loop whilst running our Controllers. The major advantage of that is that we delegate all of the Motion Control to the Industrial Controller which has been built specifically to execute code and run our Robots, resulting in excellent predictability, reliability and accuracy. The actual code that a Controller requires will depend on its manufacturer and configuration. For example, ABB IRC5 Controllers require code in the programming language RAPID, KUKA KRC4s require code in KUKA Robot Language (KRL) and Staubli Robots will require VAL+ or VAL3 depending on their generation. Fortunately, the HAL Robotics Framework handles all of this for you as long as you select the right Controller configuration.

How to:

To prepare to export we must have a Procedure ready and a Controller in our document. To properly configure our Controller, we need to return to its configuration screen. This is the page you will see immediately after selecting your Controller or you can get back to it by simply double-clicking on your Controller component. We will use an ABB IRC5 as an example but the same principles hold true for any Controller preset. When we open the configuration window there are two pieces of information that we need to check. The first, and simplest, is the Language. If the Controller Version is correctly set then this should be compatible with your real Controller but you can always export a slightly different Language if you want.

The other element to verify is the Export Settings. These are listed on the right-hand side under the Language version. You should have a list of all of your Procedures. If you haven’t given them identifiable Aliases now would be a good time to do so. There are three scenarios that we need to discuss with these Export Settings:

a. Single Robot - For a single Robot setup you will just need to make sure that your path is correctly set. For ABB Controllers the path is the Task name in your real Controller but for KUKA this is an index which can remain “1”. You also have the option of completely deactivating the export of a Procedure using its toggle, or exporting a Procedure as a library, which means it won’t have a code entry point. This could be useful if you have pre-configured initialization or termination sequences in your Controller.

b. Multi-Robot - The only additional check you need to make when using a multi-Robot configuration is that your paths are all correct. Again, that’s Tasks for ABB or the equivalent for other manufacturers.

c. External Axes - The final unique configuration is for External Axes. In the HAL Robotics Framework, we require each Mechanism to have its own Procedure. With External Axes we actually want to merge a number of Procedures into one to Export correctly. We can do this by simply dragging the External Axes’ Procedure(s) onto the main Robot’s Procedure. This marks it as a child Procedure of the Robot and they will be Exported together. When using this kind of configuration please make sure that you have also setup your Joint Mappings correctly for your External Axes. This can be done during the Joint creation when assembling a Mechanism from scratch or using the Mapping input on the Positioner component. Mappings are zero-based in the HAL Robotics Framework and will automatically be converted at Export to match the format of the real Controller.

Now that our Controller is configured, we can place Export component from the HAL Robotics tab, Control panel. We can hook up our Controller, Solution and assign a path to the Destination. When we run the component by toggling Export to true this will generate our code and give us the paths to all exported files as an output. In the second overload of this component there’s one additional input worth discussing, Mode. Inline mode will create a dense code file with as little declarative code as possible. Predeclaration mode will do just the opposite, it will create variables wherever possible to make it easier to change things by hand should you want to. For most scenarios we recommend Inline as it produces shorter code and is faster.

As a final note in this tutorial, we know that there are circumstances where you may need to add very specific lines of code to your Exports. This could be to trigger a particular Tool, send a message or call another piece of code. You can do this using Custom Actions. These are found in the HAL Robotics tab, Procedure panel. You can add any text to the Code input and it will be Exported verbatim. If your Custom Action causes the Robot to Wait or some other Simulatable Action to occur you can add a Procedure to the Simulation input. Just remember that regardless of what you add to the Simulation, only what you put in the Expression will be Exported. Learn more about Custom Actions in this tutorial.

6.3. Upload a Procedure

Objective:

In this tutorial we’ll Upload some robot code to a real Controller using the HAL Robotics Framework for Grasshopper.

Requirements to follow along:

McNeel’s Rhinoceros 3D and Grasshopper, and the HAL Robotics Framework installed on a PC.

Background:

Uploading is the logical successor to Exporting which we looked at above which essentially copies any generated code to the remote Controller and can even run it for you. This is not available on all supported robots so please check the manufacturer-specific documentation to see if it’s available on your Robot.

How to:

To prepare to upload we must do through the same process as exporting, so if you haven’t been through that tutorial above yet please do that before returning here.

The configuration of your Controller will be different depending on the manufacturer so please check the manufacturer-specific documentation to see how to configure your Upload and File Manager subsystems.

Now that our Controller is configured and we are happy with the way our code is Exporting, we can place the Upload component from the HAL Robotics tab, Control panel. We can hook up our Controller and Solution, exactly as we did with Export. You will also find Mode which was discussed in Export. Inline mode will create a dense code file with as little declarative code as possible. Predeclaration mode will do just the opposite, it will create variables wherever possible to make it easier to change things by hand should you want to. For most scenarios we recommend Inline as it produces shorter code and is faster. When we run the component by toggling Upload to true this will generate our code and copy it to the robot.

The AutoRun property will attempt to run the Procedure as soon sa it’s been Uploaded so use it with extreme caution. This is not available on all supported robots so please check the manufacturer-specific documentation to see if it’s available on your Robot and whether there are any restrictions on when it can be used.

6.4. Reuse Controller Data

Objective:

In this tutorial we’ll explore some advanced syntax which allows you to reference data and variables which are already declared on your Controller or rename variables you Export using the HAL Robotics Framework.

Background:

When your Robot and, more importantly, its Controller were installed, it’s possible that certain Tools were calibrated and stored in the Controller’s system variables or that it would be helpful to name Signals so they’re immediately identifiable (e.g. ToolOn) but that they’re named differently in your Controller or even that your Robot’s language doesn’t allow you to name Signals at all. We have therefore given you the option of overriding the way elements are Exported. These are generally useful for Tools, References and Signals but can be used for Targets, Motion Settings or any other declarable type.

How to:

These overrides are all done through the naming of objects, by using special syntax in their Aliases. There are 3 scenarios we permit:

Forcing the declaration of the element, even in Inline mode, e.g. so you can make manual changes to the code later.
Skipping the declaration of the element, e.g. because it’s already in the Controller’s system variables and you want to use that data directly.
Renaming the element, e.g. the Signal which you have called ToolOn for legibility is actually called DO-04 or is index 3 on the real Controller.
[Bonus] A combination of the above.

The syntax you can use is as follows:

Declare an override - Append @ to the Alias
Skip declaration - Append ! to the Alias
Renaming - Append the new name to the Alias

Examples:

Code	Description
`MyTool`	Regular tool declaration.
`MyTool@`	Forces the declaration of the tool.
`MyTool@toolData32`	Forces the declaration of the tool, as a tool variable called toolData32.
`MyTool@!`	No declaration – considers that a “MyTool” tool declaration already exists in the controller.
`MyTool@!toolData32`	No declaration – use the toolData32 tool variable from the controller.