Control of the processing sequence

Understanding the distinction between location and process is essential. In Line Control, a location refers to the physical machine that executes one or more processes. For example, a machine may be designed to assemble connectors onto products. To perform this task, the station integrates subsystems such as a press-in unit or a vision system for inspection, ensuring correct assembly.

These subsystems are general-purpose units and can be utilized in various machines and applications. The machine leverages these subsystems to implement specific processes, typically by running dedicated software that defines how each subsystem should operate. This often involves configuring parameters tailored to the task, such as setting detection patterns for a vision system to identify components.

In Line Control, a production process refers to the specific task or operation performed to manufacture a product, such as "Connector Press In" or "Connector Inspection." Each process defines the exact step required in the production sequence.

A location, by contrast, identifies the physical or logical position of a machine within the production line or shop floor, such as "Station 40 on Line 8030." The location does not determine which process is performed; it only indicates where the machine is situated. If a machine is moved to a different line, its location changes, but the processes it performs remain the same.

Example

The following picture shows a machine implementing the two features Press In and Vision inspection. The machine has been designed to assemble connectors to products. To realize this task, the machine has used the two features Press In and Vision to implement the processes "Connector Press In" (using Press In feature) and "Connector Inspection" using the vision feature.

The machine itself will be used as part of an assembly line. Here in the example, the line is identified by the line number 8030 and the machine will be the station 40 of the line.

A route list defines the sequence of production steps (processes) that a product must follow. Each process is represented as an entry in the route list, and the list itself specifies the order in which these steps are performed.

Different products may require different sets of production steps. Line Control supports multiple route lists to accommodate this. The client registering a work part at Line Control determines which route list will be used for that part.

After the Line Control dataset has been created, the link of the route list is stored inside the Line Control dataset and will be managed by the Line Control server.

A route list specifies all processes required to manufacture a product. Every process that may be executed must be included in the route list; otherwise, it will never receive a positive production release. Beyond listing valid processes, the route list defines their sequence and the conditions under which each process is executed.

Each process in the route list is represented by a production step. Every production step can specify up to five possible target steps, determining the next step based on the outcome of the current process. The default behavior of Line Control is as follows:

For each of the target a processing step can be defined. If no target has been defined for a specific target, the target cannot be used. If a process wants to move the work part to such a target, an error message will be returned and the work part remains on the process.

Example

In this example the work part can be processed by the following processes:

As shown in picture, all processes are defined as processing steps inside the route list. Normally the processing steps will have the same names as the assigned processes but this is not required.

In the next step, the targets for the processing steps are defined. In this example, only the OK (successful processing) NOK (processing was not successful) and the self-target have been specified. So if the Process "Connector Press In" has been executed successfully, the process "Connector Vision" must be executed next. If the machine was not able to press in the connector, the "Rework" process must be next in order.

As shown in the Route lists section, each processing step could contain targets for various processing results. Beside this information, Line Control could manage the work parts state also. For this a state model has been defined, containing the typical work part states:

The state information will be stored in the PartState property of the work part. If you have worked with previous versions of Line Control, you might notice that the OpCon PLC libraries have more than these states for a work part. You could still set the PartState property to one of these values, but Line Control will interpret these additional states always as NOK.

For all work parts which are not SCRAPPED, it is possible to set a new state by calling the SetPartState command. For example, you might want to set a work part into the IN_PROCESSING state if a process has started its work. Or if a work part is NOK, the rework process has the option to set the state to OK again.

Beside the SetPartState command the SetNextStation command will also affect the state of the work part. In case the station will send the new state, this state information will be used. Otherwise Line Control will calculate the new state of the work part using the processing result of the process.

The following picture will show you the most important transitions in the state model. To keep the diagram simple, some transitions have been left out (e.g. transitions for the various SetPartState calls).

Once at least one route list is defined, the Line Control server manages the processing sequence. The station responsible for the first process in the route list must register the work part with Line Control. Each subsequent station sends a production request and a process end message for every process it performs. The final station in the sequence must deregister the work part from Line Control instead of sending a process end message.

Example

The following picture will show you the typical messages for a work part running through a production:

In this example, the Station 10 runs the initial process for the work part. Because the work part is first unknown inside Line Control, the Headstation must register the work part calling CreateVmdt. With this command, the work part will be registered at Line Control and the route list which should be used for the work part will be assigned to it. The work part moves to the next station. This station runs the two processes "Connector Press In" and "Connector Inspection". For each process the station has first to request the production release for the process using the GetProcessReleaseInfo command. After the process is done, the station must notify Line Control about this by calling the SetNextStation command.

After the connector processes have been executed, the next process is the "Press-In PCB". This process could be done by two stations, but must be executed only once. In this example the station 280.1 is in order to execute the process. If the station has finished the processing it must send SetNextStation to notify Line Control that the process has been executed. If afterwards Station280.2 will request the production release, Line Control will deny it, because the process has already been executed. This communication pattern will be repeated for all subsequent processes. Finally the work part will reach the Station 920. This station is running the last process (Packaging) and must send DeleteVmdt instead of SetNextStation to remove the work part again from the *Line Control*s database.

In Line Control, you can define groups of work parts that move together through production. For example, if you use work piece carriers (WPCs) that hold multiple work parts, those work parts can form a group within Line Control.

A group must have a unique identifier and is managed similarly to a single work part: it is registered at the first process and deleted after the last process is complete.

When registering a group, all member identifiers and their positions must be specified. You cannot add work parts to a group later; the group is treated as a fixed entity. Deleting a group does not delete its members—this is intentional, as the group is a transport mechanism, while processing always occurs on individual parts. When work parts leave the carrier, the group is no longer needed, but the parts remain under Line Control management.

Groups are first-class entities in Line Control, meaning you can store and retrieve additional data for the group itself. This data is only available while the group exists; deleting the group removes its associated data. You can always access individual work parts using their identifiers.

For communication, production requests return all relevant information, allowing the client to select what it needs. For process end notifications, three scenarios are supported when groups are involved:

Example

The following picture will show you the typical messages for a work part running through a production:

For the example the group consists of 4 single work parts. In the first step, the group will be created with the process end of "Load Line".

For the example we will assume, that all work parts where processed without any errors, so the work parts and the group are in OK state.

The station hosting process 281 will request the production release and will receive for the group and all work parts a production release. The station will process all work parts and then sends the processing results using the standard scenario:

If the station has detected, that the connector was not correctly pressed in at work part WP3, the station will report this with an NOK result for that work part. In this case the group would look like this:

If even more work parts have defects, the station could decide that the processing of the whole group has failed, even when some of the work parts have been successfully processed:

For the example we will assume, that only WP3 has defect, but the other parts have been processed correctly. If the process 610 requests the production release, this will be granted for the group and all work parts except for WP3 (because WP3 should be processed by the Repair process and is in NOK state).

In this example, process 610 will send its results using the bottom-up scenario. The station will send the first processing result after WP1 has been processed:

Then work part 2 will be processed and so on. For the example WP6 has also a defect and was reported with NOK result. After all work parts have been processed, the group looks like this:

The station will now send the SetNextStation message for the group and the Line Control has to calculate the new state and target for the group. For the evaluation of the new state, the Line Control checks if the number of the groups' NOK parts is greater than the configured threshold. If yes, the group will enter the NOK state, otherwise, the group will remain in the OK state.

For the next target, Line Control checks which parts have been processed by process. For this subset the processing step will be taken which at the beginning of the OK chain inside the route list. In this case, this would be the process 276. But if for some reason the process 610 has set a work part to process 900, the processing step for process 900 would be the next target for the group.

Finally the process 276 will send its processing results using the top-down scenario. In this case, all work parts for the process will be evaluated using the global processing result. If the station sends an OK processing result group will look like this:

But if the station sends a NOK result, the group would look like this: