Click or drag to resize

11.1.5 MOTF with Rotated Parts

When MOTF is used to mark parts which are themselves rotated (via ProcessVariablesTransformation) with respect to the belt main direction, it may necessary to take extra steps to achieve the desired marking result.

Definitions used throughout this discussion

Tile

A single sequence of

TileId

An integer number indicating the tile's marking order amongst all those for a given part, whereby the tile with the highest number is the first to be marked.

For example, assuming we have N tiles, we may conventionally (but not necessarily) define our tileIds in the range N/2 .. -(N-1)/2.

The range of tileIds may also be chosen to provide a convenient multiplication factor for calculating a suitable TileOffset (see below) for a given tile.

For example:

N

First tileId

Last tileId

4

2

-1

7

3

-3

Entire part within a single tile, or multiple tiles but NO part rotation.

If either ...

  • the entire part can be marked on a single tile; or

  • the part requires multiple tiles, but is not rotated with respect to the belt direction;

    Motf Tiled Non-Rotated Part.svg not found.

... then proper part alignment can easily be achieved by setting the ProcessVariablesTransformation appropriately, and no additional steps are required.

The Problem with multiple tiles and a rotated part.

When a rotated part needs to be divided across multiple tiles, things become somewhat more complicated.

  • Since the whole part is rotated with respect to the main direction, the contents of each constituent tile will be rotated by that same angle (i.e. the rotation defined in ProcessVariablesTransformation) in the current marking field.

  • However, MOTF-Tracking starts anew for each individual tile, because the tracking offset is reset to 0 when the start condition (MOTF_WAIT_DISTANCE) is met, and then increases again from that position.

  • This means that the centre of rotation of any given tile is always placed at the same position within the current marking field, effectively ignoring the extra tracking offset due to the tile's position within the whole part.

  • Consequently, a contiguous path that has been split across two or more tiles will fail to appear as expected on the part after the tiles have been marked.

    Instead, various apparently disconnected segments of the path will appear in a stepped pattern, similar to this:

    Motf Tiled Rotated Part Problem.svg not found.

The Solution for multiple tiles and a rotated part.

The problem can be solved by specifying an appropriate TileOffset in the main belt direction, which is then automatically added to the current tracking offset for each tile.

The offset can be specifed, for instance, by calling CommandListAppendMotfTileOffset.

For a given tile, the required TileOffset is simply its width (un-rotated size in the belt main direction) multiplied by its tileId (assuming the tileId has been specified as described above):

 

TileOffset = W * tileId

 

 

tileId

TileOffset

2

2 * W

1

W

0

0

-1

-W

 

 

Motf Tiled Rotated Part Offset.svg not found.

 

This allows the whole part to be marked correctly:

Motf Tiled Rotated Part Solution.svg not found.

Calculation and Usage of TileOffset

Please refer to the usage example in the SPICE3SampleApp[Note 1] "Tiling" / "TilingNative".

Notes

  1. The RAYLASE GmbH SP-ICE-3 Software installation package includes a sub-directory named SPICE3SampleApps under which you will find source code for a number of sample applications, each of which demonstrates how to use various ClientAPI functions.