McePosTable version

0.2.0

Description of the new feature / enhancement

Currently, an ActionID stops the robot and trigger an action at the end of the motion.
In some cases, it would be interesting to run an action in different circumstances:

• Run an action at the beginning or at the end of a motion without stopping the robot. This event could raise a flag that could be used to trigger an action or to notify that the robot has reached a certain step in the trajectory
• Run an action a certain distance or a certain time after the beginning or before the end of a motion, without stopping the robot

Implementation

We could reserve several ActionID for type of action.
But it could be a little difficult to manage.

Other possibility:
We add a nActionStop variable to a McePosTable entry as SINT

nActionDelay is also added.

Time or distance before the end of motion may be handled by MLxRobotSetDigitalOutputWithMot.

Scenario when this would be used?

In various pick & place or palletization application where vacuum needs to be triggered before pick position.
Or simply a flag raised when the robot has reached a certain step in the trajectory.

This is about optimizing the source code of McePosTable.

In 0.1.0-beta, the program is quite large. There might be room for improvement:

• Try combining state 11/12/13 into a dynamic state 11..19, where everything scales by a global constant NR_OF_INSTANCES
• Remove redundant code like controlled stop
  This can be handled externally using the nPosTableMode and bWaitForStep
• Make things dynamic where possible (e.g. by using FOR loops)
• Remove code related to closure reference

Additional changes:

• Add ACTIONID_WAIT_STEP
• Add a nCustomActionID input so the user can mirror the current nActionID output number. So the bCustomeActionDone refers to the right nActionID
• Transition to state 40 when resetting
• Add nAbortingMode as SINT for the user to choose between a controlled or an uncontrolled stop when resetting PosTable
• Rename nPostableMode to nMode
• Rename nMoveStep to nInstanceNumber
• Rename QAmax to QA_MAX
• Test with 1 or 2 instances
• Limit QA_MAX value
• Increase the max number of instances to 20. Need to shift states > 20 by 10. Start motion states at 10 instead of 11
• Add bUserframeDone and bToolDone temporary variable to enable motion FB
• Use 1 FOR loop for tool, UF and motion FB calls
• Use dynamic states in nPercentComplete mapping
• Remove io.nCustomeActionID. Check CustomActionDone only if nActionID < 20
• Replace the 2 in nPostableMode = 2 by a constant named PT_MODE_2

Description of the new feature / enhancement

Add the possibility to use the very precise switching of a (robot) output, depending on time or distance from the target position. This uses the MlxRobotSetDigitalOutputWithMot function.

Implementation

<This has been implemented in an internal dev version before - please check and add more info here>

Scenario when this would be used?

Applications where accurate path switching is needed. Often used for optimizing cycle time.

PosTable version

v0.2.0

Current behavior

If nMode=2 (single motion) and an entry of PosTable has the default ActionID "wait for step" (nActionID=2), the McePosTable is stuck in state 31.
This happens because the step by step mode and the ActionID both needs a rising edge to continue.

Expected behavior

A single rising edge on bStep should continue the trajectory.

I have the Motologix activated on my YRC1000 and Motologix project installed on my PLC. I am able to read in status from the YRC1000 trough the mlx interface, but I am not able to run the robot from the Motologix interface in the PLC. I suspect this is du to my YRC 1000 parameter are not updated according to https://motologix.yaskawa.eu/setup-robot/part-number/215313/#parameter-settings.
If i get this right, I don't have access to change all this parameters and need help with this from Yaskawa?

We are currently operating a GP 400 on a YRC-1000 with Motologix on a Siemens 1500 CPU. I have successfully installed the Motologix library using TIA (Siemens PLC programming tool).

My current challenge lies in simulating the YRC1000 with the Motologix interface towards a PLC. I am seeking a solution similar to Motosim EG-VRC, which can communicate with a PLC for testing purposes before deployment on the hardware.

What is my option?

In the Rockwell PosTable, the first motion always come to a stop (no blending).

QA is forced to 0 in the UpdateIndex subroutine if CalcFirstMove variable isTrue.
Hence, the next positions are not loaded in anticipation.

QA is normally increased in the UpdateLoadIndex subroutine, but it is missing a big section of code.
But this section is a lot similar compared to what is already done in the UpdateIndex subroutine.

So, we either:

• add the missing code section
• remove the CalcFirstMove from the last IF statement of the UpdateIndex subroutine

McePosTable version

0.2.0

Description of the new feature / enhancement

This is about adding a mechanism which prevents the motion of a PosTable entry to be executed until the configured start conditions for that entry are satisfied. So PosTable would schedule a standstill and only proceed after the start conditions are satisfied.

Ideally, if the conditions are already satisfied in-time, the robot should not have any short standstill, but smoothly continue its trajectory (blended motion).

Implementation

This mechanism only checks before starting the motion. Once the motion of an entry has started, the start conditions are disregarded. So it cannot be used for aborting an already started motion.

The used should be informed about the status of the missing start conditions.

Further specification in the pull request

Scenario when this would be used?

• Pick and place
  Robot needs to wait for authorisation to enter a station/area
• Checking for parts
  Robot needs to wait until all parts have been placed in e.g. a welding jig.

To keep the PR's small, this feature will be implemented in two steps:

• 1) Implement the basic startConditions mechanism (this will always schedule a standstill)
  #36
• 2) Add the functionality for startConditions with look ahead (to prevent a short standstill if conditions are satisfied in-time)
  #37

PosTable version

v0.3.0

Current behavior

When nSmPosTable jumps from a motion state (10 to 29) to state 99 because of an error (Sts_ER on any FB), FB's enable input suddenly goes to False without clearing MLX.InternalData.WritePacket.CommandRequest.

Expected behavior

Transition to state 99 should keep the previous aEnable signals untouched.
So still enabled FB can end their process as usual.

McePosTable version

0.2.0

Description of the new feature / enhancement

Add the possibility to select a robot posture based on TCPPosition.Closure.ReferencePosition of MLxAppDataTeachPoint.

Implementation

It needs to be discussed.

We could add a Reference position array but the data size would be too big.

We could also add a PostureSelection to PosTable entries and allow the user to create several posture reference as an input of McePosTable.

The are a lot of possibilities.

Scenario when this would be used?

Palletization application where the robot must move close to a singularity position.

Or in any application where a posture selection would be more easier to use than an axis position.

• Setup the lib file structure so that it is ready for adding lib functions and data types

There could be a risk that the command buffer fills up over time due to abrupted commands.

Consider adding an MLxReset after MLxStop:

// -------------------------------------
// stop and flush buffered motions with MLxStop
// -------------------------------------
50:
  fbStop.Enable := TRUE;
  IF fbStop.Sts_EN AND fbStop.Sts_DN AND (MLX.SystemState <> 9)
    AND (MLX.SystemState <> 10) AND (MLX.SystemState <> 11) THEN
    IF fbStop.Sts_ER THEN
      io.nErrorCode := 1000 + io.nSmStartStop;
      io.nSmStartStop := 70;
    ELSE
      io.nSmStartStop := 51;
    END_IF;
  END_IF;

// -------------------------------------
// NEW: reset system with MLxReset
// -------------------------------------
51:
  fbReset.Enable := TRUE;
  IF fbReset.Sts_EN AND fbReset.Sts_DN THEN
    IF fbReset.Sts_ER THEN
      io.nErrorCode := 1000 + io.nSmStartStop;
      io.nSmStartStop := 70;
    ELSE
      io.nSmStartStop := 45;
    END_IF;
  END_IF;