MLxRobotResetSearch

For starting this function block. On a rising edge of this input the internal processing will start which is indicated by the Sts_EN status signal.

Internal processing steps typically involve:

• checking if required conditions are met
• sending command data to the robot controller (on the next possible occasion)
• receiving answer data from the robot controller

Since the status bits will only be updated as long as the Enable is active, it is necessary to keep the input enabled until the FB has completed its entire lifecycle which is signalled by the Sts_DN (done) status signal.

Disabling the input too early can mess up the MotoLogix command interface and lead to a hangup situation.

Specifies the motion device targeted by this MotoLogix function.

The MotoLogix data packet supports a maximum of 4 motion devices on one robot contoller. Examples of motion devices are:

• manipulators (e.g. GP7 robot)
• base axes (e.g. gantry system)
• station axes (e.g. servo gripper)

Each motion device gets its own RobotNumber (and slot in the data packet). Some examples:

two robots: R1 and R2

[0]     // R1
[1]     // R2
[2]     // not used
[3]     // not used

two robots on a linear track R1B1 and R2B2

[0]     // R1
[1]     // R2
[2]     // B1
[3]     // B2

robot with a servo gripper R1S1

[0]     // R1
[1]     // S1
[2]     // not used
[3]     // not used

The numbering is fixed in the configuration of the robot controller (cannot be changed by MotoLogix). MLxRobotGetProperties can be used to read this configuration. It will give you practical information for each motion device such as: type, axis names, speed- and motion range.

Status Enabled signal which tells that the FB is currently enabled. It reflects the status of the Enable input.

A common use for Sts_EN is in combination with the Sts_DN (or Sts_PC) signal. This filters the old status which is important because in the PLC scan where the FB gets enabled the Sts_DN still has the status from its previous run (which is probably high) until the FB call is processed.

CASE state OF
...
10:
  // enabling the FB
  someMLxFB.Enable := TRUE;

  // condition to proceed after FB finished
  // --> Sts_DN still has its old status from previous run
  IF (someMLxFB.Sts_DN AND someMLxFB.Sts_EN) THEN
    state := state + 10;
  END_IF;

20:
  ...
END_CASE;

// FB call
someMLxFB(...);
// --> now Sts_DN has the new status

Status done signal which tells that the FB has finished. This means the Enable input can now safely be disabled as the FB has completed its lifecycle.

This status signal keeps its status until the next time this FB is enabled. See Sts_EN on how to filter any old status.

Status error signal which tells that the FB has failed. The Enable input can now be disabled as the FB has aborted its lifecycle.

Now it is important to find the cause of the error. In most cases the robot controller has generated an alarm which explains what the problem is.

Recommended next steps:

• Read the alarm details using MLxGetErrorDetail
• Fix the issue described in the alarm details (e.g. parameter out of range)
• Reset the alarm using MLxReset (also clears the motion queue) or MLxResetAndHold (resets the alarm but leaves the motion queue in place).
• Restart the application

If Sts_ER becomes active but the robot controller does not generate an alarm you should check the SystemState and the conditions/prerequisites for using the FB.

This status signal keeps its status until the next time this FB is enabled. See Sts_EN on how to filter any old status.

The MotoLogix variable which acts as the shared memory for a MotoLogix system.

As the PLC runs through its scan cycle each active MotoLogix FB will read from- and write to this MotoLogix variable.

It is also used for processing the data red from- and sent to the robot controller.

There are a few important rules:

• MLxCommunicationRead must be called at the very beginning of the PLC scan cycle.
• MLxCommunicationWrite must be called at the very end of the PLC scan cycle.
• All other MotoLogix FB’s used in your application must be called inbetween.
• All off this must be handled by the same PLC task, respecting above rules.

Failing to follow above rules can lead to inconsistent data being sent to the robot controller which could result in unexpected motion.