Learn how to use the HAL Robotics Framework from Rhinoceros and Grasshopper.

• table of contents
• back to main site
• issues and bugs

6. Control

6.1. Configure a Virtual Controller

6.2. Export a Procedure

6.3. Upload a Procedure

6.4. Monitor Robot State [Coming Soon]

6.5. Stream Positions to a Robot [Coming Soon]


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:

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. 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:

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 initialisation 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 much 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 Expression input in double quotes (“”) 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.


6.3. Upload a Procedure

Coming Soon


6.4. Monitor Robot State

Coming Soon


6.5. Stream Positions to a Robot

Coming Soon