Sample code for use of Smart Gripper services supplied in RWSStateMachineInterface.

[Mariunil]

Hi,

I am using the library againts a ABB IRB14000 YuMi and are experienceing issues using the Smart Gripper services supplied in rws_state_machine_interface.h. The robot have both the SmartGripper Add-In and Statemachine Add-In installed.

Have successfully interfaced against the robot controller with services supplied by rws_state_machine interface.h and other parts of the library. Robot is in auto mode with motors on. Tests performed both with the StateMachine running and stopped. Computer configured to use ip "192.168.125.50". Can read information about robot using http://192.168.125.1/rw?debug=1 succesfully.

As no hints or sample code is supplied for interfacing against the Smart Grippers I am unsure where my mistake is located. Would it be possible to supply sample code on how to interface against the Smart Grippers?

[gavanderhoorn]

It would help if you could clarify what "issues using the Smart Gripper services" actually means.

[Mariunil]

I am sorry, I should have been more clear.

Specifically I am unable to get settings from the grippers using dualGetSettings ( or gripper specific verisons leftGetSettings ), likewise unable to set settings, initialize (dualInitialize) or move grippers (dualGripIn, leftGripIn). I am repeatedly recieving false from these functions, indicating the communication was unsuccesful.

Polling of information about the robot or getting and setting EGM settings are successful, so my connection to the robot should be fine.

[jontje]

Hello @Mariunil,

A few questions:

• Have you powered on the SmartGrippers? The LEDs should be active on the grippers, otherwise use the FlexPedant to turn them on (Menu - Smart Gripper - Configuration - Press the power switch buttons for right/left flanges).
• Can you move the fingers with the FlexPedant? Menu - Smart Gripper - Right/Left Hand - Jog +/-.
• Have you calibrated the fingers? Jog the fingers as much as possible with the Jog - button, and press Calibrate.
• Which version of the SmartGripper Add-In are you using?
• Do you have the TRobSG RAPID module? It is included by the StateMachine Add-In, if you have a compatible SmartGripper Add-In version.

[Mariunil]

• Both right and left flange is powered on. On both grippers, one of the two LEDs are active and the other is blinking.
• I can move the fingers using the FlexPendant using Jog +/- and Grip +/-
• Fingers are calibrated in the described manner.
• SmartGripper Add-In is version v3.56
• I do not have a TRobSG RAPID module.

[jontje]

The issue is that the SmartGripper Add-In version is newer than what the StateMachine Add-In is looking for during installation. However the RAPID code should still work, so you can tell the robot controller to load the RAPID code anyway.

The easiest way is to apply these configurations: config.zip. There are four .cfg files included, and they are in plain text so you can take a look at their contents.

Note: Take a backup before applying the configurations (just in case).

Then you can use RobotStudio to load all files at the same time:

After a warmstart, then the TRobSG module and an IO-signal should have been included.

[Mariunil]

Loaded the configuration and performed a warmstart. Function calls no longer indicate unsuccessful communication but their operation are not successful. When printing settings fetched with rightGetSettings, all settings are zero. After setting via rightSetSettings and fetching again they are still zero.

Likewise for rightGripOut and rightGripIn, no motion is observed in the gripper. Both flanges are powered on and calibrated following the described procedure. On both grippers, one of the two LEDs are active and the other is blinking.

Am using RobotWare version 6.09.02

[jontje]

Have you started RAPID execution? Do you get a printout in the FlexPendant like [SmartGripper]: Initialzed?

Otherwise, can you provide the RWSStateMachineInterface's log? It can be extracted with the getLogText(true) function.

[jontje]

You might need to add the line initializeSGModule; to the TRobMain's procedure LOCAL PROC initializeSubmodules().

I forgot that the TRobMain module probably won't be updated during restart, since it already exists in the system.

[Mariunil]

RAPID execution was not originally started. Performed new tests with RAPID running.

Execution flow was (right gripper only, RAPID not running before start): reset rapid pointer -> start rapid -> toggle IOSignal RUN_SG_ROUTINE -> initialize -> get, adjust and set settings -> calibrate -> opengripper

Printouts from FlexPendant (two screenshots, same test).

From getLogText(). getLogText.txt

initializeSGModule was in my case already added to TRobMain's procedure LOCAL PROC initializeSubmodules()..

Configurations were loaded by performing I-restart -> load config -> warmstart

[jontje]

@Mariunil, just as a follow-up, did you get the SmartGripper to work properly? Or are there still somethings that doesn't work?

[Mariunil]

The SmartGrippers are mostly working properly. Eveything seems to be working as it should besides the functions for fetching the SmartGripper settings, rightGetSettings and dualGetSettings specifically. The return value indicate success, but when printing the values i find them to always be 0.00000, regardless of where in my code i fetch the settings.

What solved the previous issue of being unable to move the grippers was changing the order of the function calls.

Previously I performed: reset rapid pointer -> start rapid -> toggle IOSignal RUN_SG_ROUTINE -> initialize -> get, adjust and set settings -> calibrate -> open gripper

The return values indicated communication success, but there was no movement of the grippers. What solved it was changing the order to:

reset rapid pointer -> start rapid -> set io signal RUN_SG_ROUTINE HIGH ->open gripper

I'm guessing the problem was the initialize and calibrate calls called between setting RUN_SG_ROUTINE HIGH and the open gripper call.

Looks like the interrupt cased by receiving the RUN_SG_ROUTINE only performs one command, and neither the calibrate nor open gripper call were performed due to this in the original execution flow.

[jontje]

Eveything seems to be working as it should besides the functions for fetching the SmartGripper settings, rightGetSettings and dualGetSettings specifically. The return value indicate success, but when printing the values i find them to always be 0.00000, regardless of where in my code i fetch the settings.

Hm... in your log file it seems like you get the values correctly. Event 15 and 18 has the <span class="value">...</span> tags with the retrived values. How did you try and display the values? For me it works if I do something like this:

if (rws_interface.services().sg().rightGetSettings(&sg_settings_r))
{
  std::cout << "Max speed: " << sg_settings_r.max_speed.value << std::endl;
}

The return values indicated communication success, but there was no movement of the grippers.

The return values only indicate if the information was sent/retrieved correctly, but they don't verify that commands are actually applied in the system.

I'm guessing the problem was the initialize and calibrate calls called between setting RUN_SG_ROUTINE HIGH and the open gripper call.

It should not be needed to set the RUN_SG_ROUTINE IO-signal yourself (the helper functions do that implicitly).

[Mariunil]

Hm... in your log file it seems like you get the values correctly. Event 15 and 18 has the ... tags with the retrived values. How did you try and display the values? For me it works if I do something like this:

I have found the issue. I tried to print sg_settings_r.max_speed instead of sg_settings_r.max_speed.value.

The return values only indicate if the information was sent/retrieved correctly, but they don't verify that commands are actually applied in the system.

Ok, good to know.

It should not be needed to set the RUN_SG_ROUTINE IO-signal yourself (the helper functions do that implicitly).

Good to know, thank you.

Everything is now working. Thank you very much for you time and help.

[gavanderhoorn]

Closing as it seems the issues OP was having have been resolved.