Forum Replies Created

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
  • in reply to: Emergency Stop #10655


    This is so frequently asked topic, that I decided to share some examples here, how you could implement the emergency stop function.

    When using servo controller, you can add new targets to the joints at any given time. For emergency stopping you can just give the current joint values as targets. However, it is not possible to “stop” the internal motion controller, although the servo motion is stopped in 3D scene. This is why you need to use SuspendRun() and ResumeRun() anytime you give new targets.

    Use rounding when comparing the current values to the targets, since there is certain tolerance when the servo is not going to move (e.g. 1e-12 mm distance)

    Please see the simple example “Lifter_Button-Controlled” to understand the basic idea and more sophisticated example “Lifter_Signal-Controlled” for implementing lifter for virtual commissioning with I/Os.


    When you program robot executor and want to stop the robot controller with emergency stop event, you can create a python script which is disabling robot executor (Executor::IsEnabled == False). That is causing the robot not to stop immediately, but still move to the current target.

    To stop immediately, you could create a new target with the current joint values, then call servo.moveImmedate().

    When emergency stop is released, you just enable the robot executor again, and the robot will continue from the next motion point. So this approach is skipping the next target in the moment emergency button was pressed. However, when releasing the emergency stop, it would be possible to force the robot to move to the next target by using python, before enabling the robot executor again.

    And like @ralle mentioned, in any of these examples, there is no decceleration ramp. The stopping is always immediate.

    Please see the attachment “EmergencyStopForRobotExecutor”, which is simple example stopping the executor by python, and the other, a bit more fancy attachment “RobotReactionSpeedGame”

    You must be logged in to view attached files.
    in reply to: robot positioner of track #6854


    The Speeds tab in Works Robot Controller is indeed for robot motions only. The speed of the track is defined by the robot positioner joint properties in Modelling tab.

    The newsest version of the component (v32) in eCatalog has Track::JointSpeed property for percentage value of joint max speed.


    hi ozanerdem,

    Thank you for your feedback.

    These are nice ideas for improvement.


    Elements of the XML files:

    GlobalIdentity is referring to VCID in the eCat. All the models that are listed in a XML file must be found in the eCatalog by that VCID. The components can be any component of the Visual Components Public Models – library or any other component that is saved (-> that means that it has unique VCID) and is linked into the eCatalog Sources

    LocalIdentity number is used locally to link the connections and the attachments between components to the correct components inside the xml file

    Name of the component must be unique in one layout. If there are more components within the same layout, they are separated with space + “#” + index_number, like “GenericFence”, “GenericFence #2”…

    Properties do not need to be included in the xml file, if the property values have not been changed from the default values (property values when saved).

    Locations is
    o   N – Defines Normal vector that is unit vector in X-axis direction.
    o   O – Defines Orientation vector that is unit vector in Y-axis direction.
    o   A – Defines Approach vector that is unit vector in Z-axis direction.
    o   P – Defines Position vector.
    o   Note: The directional vectors N,O and A should be unit vectors and orthonormal. That is, the length of N,O and A should be 1.0, and they should be normal to one another (orthonormal). Otherwise, the vcMatrix object will be skewed.

    Connections are connected physical/abstract interfaces between components. Interface is a behaviour object in a component which can deliver various types of simulation specific information, such as:
    o   Material flow
    o   Communication signals (digital / analogue / messages)
    o   Task publishing
    o   Node/Tool/Base information
    o   Physical attachment information

    Attachments are the hierarchal parent/child –relations between components

Viewing 4 posts - 1 through 4 (of 4 total)