EGM Loses Connection

[Mitch981521]

I know you guys are busy people, but this issue is somewhat urgent. I'm having an issue with getting EGM to maintain a connection with the physical robot. I am using the sample RobotStudio code and a modified version of the C++ code, which has worked on the robot our group has purchased.

We are now testing EGM on an older model (IRB 4600)...the robot is orange if that description helps. Our test code, which just moves the robot to a specified position, works in RobotStudio and the newer robot we purchased. When we test it on this older model, we are getting an error which I believe is caused by EGM not maintaining its connection. When I run the C++ code, it says it's connected, but the RobotStudio code continues to iterate in a loop, until it hits a manual jog instruction. The error says that jog/manual move isn't allowed during EGM, which makes sense. What I don't know is why this robot loses connection with EGM. Here are the items we have checked so far:

• Replaced RobotStudio code with successfully tested version
• Tested from a linux computer which successfully executed EGM on our robot
• Made sure IP addresses matched and verified by pinging
• Tried starting the robotstudio/C++ programs in different orders
• Tried code in both manual/automatic mode
• Ensured that EGM was installed on physical controller

The only differences that come to mind are the robot model year and the port we are using for the connection. Before we were using the service port, but for this testing we have been using a port on the bottom of the controller. We greatly appreciate any assistance! I've attached screenshots of the error message we are receiving in robotstudio and on the teach pendant.

[gavanderhoorn]

First thing: version of RobotWare, StateMachine addin and abb_libegm and abb_librws.

[danielj195]

We have RobotWare 6.08, which should work right? Our CPU version is DSCQ1000, not DSCQ1080 so does that make a difference?

Is the StateMachine Add-in 100% necessary for EGM to function? I do not remember having to install this on newer model of robot we had, so does it maybe come pre-installed?

[danielj195]

We were able to run Wireshark on our connection. The 192.168.125.1 IP address is the controller service port and the 192.168.125.17 IP address is the external computer. As seen in the screenshot, it appears that the controller and computer are successfully sending/receiving UDP messages. The external computer then suddenly begins to reply with a message of the incorrect protocol (ICMP), at which point EGM disconnects and we get the errors shown above. Here is our system platform:

Robotware 6.08.01.00 (version on physical controller and robotstudio) Ubuntu 16.04 ROS Kinetic Using abb_libegm package Controller CPU: DSCQ1000

We do not currently have the StateMachine add-in installed on the controller, but we did not need to install this on our newer ABB robot, so I do not see why it is necessary for this older robot. We greatly appreciate your help!

[gavanderhoorn]

The external computer then suddenly begins to reply with a message of the incorrect protocol (ICMP), at which point EGM disconnects and we get the errors shown above.

From the screenshot it would seem that your PC has closed the UDP port, and that it's telling the controller that it should stop sending packets to that port.

The controller is then doing what it's supposed to: stop sending EGM packets.

You'd have to figure out why the PC closes the UDP port.

Using abb_libegm package

this doesn't tell us anything: which specific commit are you using?

[danielj195]

We were using the latest commit...I pulled it fresh off of github. I will add that we were able to successfully move to a joint position a single time, but then when we tried it again it began to have the connection issues.

Also, whenever we restart controller and get the "RAPID execution state UNDEFINED" in yellow text and try to restart the EGM program on the teach pendant, we always get the error immediately.

[gavanderhoorn]

We were using the latest commit...I pulled it fresh off of github

Apologies for asking again, but please be specific: which hash?

Future readers will not know what "the latest commit" was/is and neither will we.

[danielj195]

That's my fault hash 13eee74

[jontje]

I am using the sample RobotStudio code and a modified version of the C++ code

I assume you are using the code from https://github.com/ros-industrial/abb_libegm/issues/18#issuecomment-473262645, is that correct? Which of the examples are you using? E.g. joint or pose motion? Position or velocity motion?

I think the main issue is due to the RAPID code from the examples has not been extensively tested/verified.

We have RobotWare 6.08, which should work right? Our CPU version is DSCQ1000, not DSCQ1080 so does that make a difference?

Since you have RobotWare 6.08, then the CPU version shouldn't matter as far as I know.

Is the StateMachine Add-in 100% necessary for EGM to function? I do not remember having to install this on newer model of robot we had, so does it maybe come pre-installed?

The StateMachine is completely optional and is not pre-installed. Compared to the basic examples above, then its RAPID code is alot more stable/well tested.

[danielj195]

We had modified the C++ sample code and made our own class, which was working on the robot we have in our lab. The modified code we made was giving the above error on this other robot we have been having issues with. We also tested the exact EGM sample code and got the same issue of EGM losing connection. We were testing the c1_joint_controller_node file.

I do not think the issue is a hardware issue as I was thinking before...EGM is able to successfully communicate with the external computer. It just loses connection after some time. Is the State Machine add-in just an interface that goes on robot studio for EGM?

[ghost]

@danielj195 Could you please post the RAPID program here?

[jontje]

Is the State Machine add-in just an interface that goes on robot studio for EGM?

No, the StateMachine Add-In is a RobotWare Add-In and not a RobotStudio Add-In. The former is a way for adding e.g. RAPID code to a robot system from the get-go after system installation. The latter is for expanding RobotStudio itself with custom functionality.

If the StateMachine Add-In is included during the robot system installation, then the Add-In inspects the available RobotWare options and loads system configurations and RAPID modules depending on that.

Also, I forgot to mention that the StateMachine Add-In is intended for use when the application logic has been placed outside the robot controller, so it might not be applicable in your case.

We also tested the exact EGM sample code and got the same issue of EGM losing connection. We were testing the c1_joint_controller_node file.

Then I assume you have been testing against the RAPID code form the TRob1Main module. If so, can you test with this RAPID code instead?

PROC main()
    WaitRob \ZeroSpeed;
    WaitTime 2;

    ! Register an EGM id.
    EGMReset egm_id;
    EGMGetId egm_id;

    ! Setup the EGM communication.
    EGMSetupUC ROB_1, egm_id, "default", "ROB_1", \Joint;

    ! Prepare for an EGM communication session.
    EGMActJoint egm_id
                \J1:=egm_condition
                \J2:=egm_condition
                \J3:=egm_condition
                \J4:=egm_condition
                \J5:=egm_condition
                \J6:=egm_condition
                \MaxSpeedDeviation:=20.0;

    WHILE TRUE DO
        MoveAbsJ home, v200, fine, tool0;

        ! Start the EGM communication session.
        EGMRunJoint egm_id, EGM_STOP_HOLD, \J1 \J2 \J3 \J4 \J5 \J6 \CondTime:=5;

        WaitRob \ZeroSpeed;
        WaitTime 2;    
    ENDWHILE

ERROR
    IF ERRNO = ERR_UDPUC_COMM THEN
        TPWrite "Communication timedout";
        TRYNEXT;
    ENDIF
ENDPROC

[danielj195]

@Thompson104 Here is the RAPID code that we've been using.

MODULE test_egm
    !======================================================================================================

    !***********************************************************
    ! Program data
    !***********************************************************
    ! Home position.
    LOCAL CONST jointtarget home := [[0, 0, 0, 0, 90, 0], [9E9, 9E9, 9E9, 9E9, 9E9, 9E9]];

    ! Identifier for the EGM correction.
    LOCAL VAR egmident egm_id;

    ! Limits for convergance.
    LOCAL VAR egm_minmax egm_condition := [-0.1, 0.1];

    ! EGM pose frames.
    LOCAL CONST pose egm_correction_frame := [[0, 0, 0], [1, 0, 0, 0]];
    LOCAL CONST pose egm_sensor_frame     := [[0, 0, 0], [1, 0, 0, 0]];

    ! The work object (here set to coincidence with ROB_2's base frame).
    LOCAL PERS wobjdata egm_wobj := [FALSE, TRUE, "", [[0, 1000, 0],[1, 0, 0, 0]], [[0, 0, 0],[1, 0, 0, 0]]];

    !    !***********************************************************
    PROC main()
        Joint;
    ENDPROC

    PROC Joint()
            WHILE TRUE DO
            MoveAbsJ home, v200, fine, tool0;

            ! Register an EGM id.
            EGMGetId egm_id;

            ! Setup the EGM communication.
            EGMSetupUC ROB_1, egm_id, "default", "ROB_1", \Joint, \CommTimeout:=10.0;

            ! Prepare for an EGM communication session.
            EGMActJoint egm_id
                        \J1:=egm_condition
                        \J2:=egm_condition
                        \J3:=egm_condition
                        \J4:=egm_condition
                        \J5:=egm_condition
                        \J6:=egm_condition
                        \SampleRate:=4
                        \MaxSpeedDeviation:=20.0;

            ! Start the EGM communication session.
            EGMRunJoint egm_id, EGM_STOP_HOLD, \J1 \J2 \J3 \J4 \J5 \J6 \CondTime:=5 \RampOutTime:=5 \PosCorrGain:=0;

            ! Release the EGM id.
            EGMReset egm_id;

            WaitTime 5;
        ENDWHILE

    ERROR
        IF ERRNO = ERR_UDPUC_COMM THEN
            TPWrite "Communication timedout";
            TRYNEXT;
        ENDIF
    ENDPROC
ENDMODULE

[ejbkdb]

This issue was able to be resolved by implementing jontje's code modification. The original egm example had EGMGetId egm_id; & EGMReset egm_id; inside the while loop (see danielj195 rapid code). This led to unnecessary reassignment of the egm_id. On our controller once egm_id was reset it would drop the udp connection. Moving EGMGetId egm_id; & EGMReset egm_id; outside of the while loop resolved this issue and we stopped dropping the udp connection.

What is curious though is that I'm able to run the original rapid code (Danielj195) virtually in RobotStudio without issue. Danielj195 also says he is able to run on his actual controller without issue.

I believe it is directionally correct to move EGMGetId egm_id; & EGMReset egm_id outside of the while loop to avoid unnecessary reassignment.

[gavanderhoorn]

Seeing as this appears to have been resolved, I'm going to close this.

Feel free to keep commenting here of course.

[danielj195]

@gavanderhoorn Just so others don't run into the issue we were facing, would you or someone else who updates this github be able to post an updated sample code in issue #18 that has the issue fixed? It may save someone else several hours of debugging. Thanks

[gavanderhoorn]

Please post this as a separate issue so we can track it.

Both @jontje and me are rather busy the next few weeks, and an issue would make sure we don't forget about your request.