Posts by Sergei Troizky

    It would be helpful if you post the PR position data and also the rest of the program. Since you have CNT25 these 2 motions will be blended with something else further down your program.

    Further down is linear motion in another direction, with no more rotation.

    I don't have the positional data handy right now, but would be surprised if it has something with the issue.

    Here is a fragment of the program:


    !At this point, PR[1,6]=0 ;

    !Tool is hanging downwards.

    L PR[1] 1000mm/sec CNT25 ;

    PR[1,6]=90 ;

    L PR[1] 5deg/sec CNT25 ;


    The idea is to move to clear for rotation, then without stopping switch to rotation.

    However, the rotation is done much faster than 5°/sec (times faster).

    I understand, that the problem is most probably caused by using the same PR, but still do not undestand why.

    Any ideas?

    5-axis robot, R-30iB Plus,.

    It all depends on your abilities on the data source side.

    If possible, send always the absolute value, and separately a "negative" flag.

    In the robot, convert to negative when necessary, by subtracting from zero.

    This being said, what do you need 32-bit values in the robot for?

    Signed 16-bit covers more than ±3.2 meters distance with 0.1mm resolution.

    "Nobody touched the TP ..."

    How can you know that? Users always say this.

    Is it a single-time incident or repeated issue?

    Do you have anything like PalletTool or PickupTool in the robot? These may use PR[1} for own purposes.

    I would avoid such address anyways, as it is the first one you see in the Data screen, hence the most subject to erroneous overwriting.

    I did not mean using Roboguide.
    What I did mean is: at the end of every backup procedure, copy all .va files from MD to the backup folder. This is usually line 17 of the MD directory.

    The .va files may be viewed in any text editor or viewer (e.g. Notepad).

    They are PR positions, not taught positions, I should have clarified. I have them in cartesian representation. The frame I express them in would have the same orientation as an RTCP frame defined at P0 as its origin.

    Assuming the P0 position is indeed the rotation center, assign it as the origin of auxiliary user frame (XY only, ZWPR=0 )and execute joint move from p1 to p2 in this frame.

    Verify the UOP Auto Assignment setup in the System Configuration.

    If it is set to "Simple", the fault reset signal is merged with the program abort.

    FAULT RESET and CSTOPI signals are separate in the "Full" assignment mode.

    Be aware though, that switching to "Full" remaps the UOP signals, which must be reflected in wiring and/or network UOP signals.

    Where do you "go to end_edit"? On Remote iPendant?

    - Are you able to do anything else on remote iPendant?

    iPendant may be locked in SETUP>>Host Comm>>HTTP Authentication.

    - In SELECT>>Program DETAIL, ensure the program is not write-protected.

    - Check the system variables in #UI_CONFIG.$READONLY. All three must be FALSE.

    Please know first of all that I am new to this world of robots.

    Second, I'm confused. You said that I shouldn't use joint move and you would use linear move. So, if using joint move and linear move does not guarantee me that the robot will follow the same path with and without pause-resume, what's the point of saying "I would use linear motion"?

    Well, I will formulate little differently.

    - Linear motion should be used when the path (in general) is a concern, e.g. moving near or around an obstacle. The reason is the path and rotations will be predictable.

    - Exact path may be not be resumed after restart from within terminated CNT curve. If this is a problem, reduce the CNT value or split the motion into smaller segments.

    These are two separate statements.