LProdReg keeps one central register of every product and container moving through a line. Sensors report what they see, conveyors report where their belts are, and the library matches the two into tracked object positions that a kinematics can pick from. Everything is built from flow objects — one function block per real machine part — talking to a single database manager over a request/response channel.
Personal study notes — not a Siemens publication. The manuals on Siemens Industry Online Support are authoritative.
A central product register for process chains: it watches products and containers arrive on running conveyors, keeps their position current while they travel, and hands the right one to a handling device or a sequence of processing stations at the right moment.
LProdReg is the central product register for a process chain. Products and containers are detected as they arrive — randomly — on running conveyors, tracked and updated as they move, prioritised or sorted by position or by a user-defined rule, and handed to actuators as position data for picking. Objects can also be deleted, manually or automatically through defined zones. A separate, static station-based mode shifts objects through a chain of processing stations on the FIFO principle instead of a conveyor. The typical field of application is a “pick and place” task combined with the system function conveyor tracking.
Every real machine part — a conveyor belt, a sensor, an actuator — is modelled as a configurable function block called a flow object (FO). FOs never touch the data directly: they send a REQUEST to the core FB LProdReg_ProductDataBaseManager and get back a RESPONSE, over the global DB LProdReg_DataExchange — a client/server architecture. Only the core FB may read or write the global DB LProdReg_ProductDataBase (the “register”), which is exactly what keeps every FO's access conflict-free. Above all of it sits the wrapper FB LProdReg_RegisterManager, which configures, calls, manages and diagnoses the library blocks beneath it — the recommended, streamlined alternative to wiring the manager and every FO by hand.
Every FO's block name spells out its type, so it can be recognised on sight. The six FO types are Conveyors, Sources, Sensors, Actuators, Stations and Sinks.
Eleven flow objects, grouped into the six FO types, plus the core manager, the wrapper and the HMI faceplate that sit around them. Pick a block below to see what it models, how it works, and what it costs to run.
All fourteen blocks shipped with V3.2, in code work-memory and load memory on an S7-1500T CPU. Each column shares one scale across every block, so the gap between the core manager and the smallest flow object is the real gap.
LProdReg_RegisterManager has no fixed size (hatched bar): it wraps and calls only the blocks a given application configures, so its footprint is whatever the sum of those blocks comes to.
Models a single physical conveyor belt.
One instance per real belt, connected to a TO_PositioningAxis, TO_SynchronousAxis or TO_ExternalEncoder at its conveyorTO input, plus an individual coordinate frame defined at the main FB and referenced via coordSystemIndex. Once enabled it cyclically sends requests to the core FB to keep every product's and container's position on that belt current in the register, every call cycle. At the main FB it is assigned as a “product-conveyor” and/or a “container-conveyor”, depending on what it carries.
Models a static, non-moving storage surface — a table or a platform — handled as a conveyor for register purposes.
Represents a “static storage” area on which objects can be detected, created or processed, exactly as on a moving conveyor, even though nothing here moves. It is configured as a product- and/or container-conveyor under the same rules as FoConveyorBelt, and still needs its own coordinate frame defined at the main FB, referenced via coordSystemIndex.
The manual lists no separate functionalities section for this block — it reuses FoConveyorBelt's conveyor-role configuration in full.
The lightest block in the library.
Models the insertion point that writes one detected — or manually specified — object into the register.
On a rising edge at sensorTrigger, sends the object at index configSource.indexObjectData of the connected object-data array to the core FB, which validates it and inserts it into the storage area of the conveyor named at sensorConveyorID, where it is prioritised and sorted per that conveyor's configuration. Each FO-Source instance inserts only one array element per trigger — a camera reporting several objects per image needs one FO-Source per detectable-object index.
Models the insertion point for a FO-Station, rather than for a conveyor.
On a rising edge at digitalInputTrigger, inserts a product or container — of the configured object type, characteristics, and for containers, container group — directly into the station named at configSourceStation.stationID. The object joins that station's storage area on the FIFO principle. Not configurable or manageable via LProdReg_RegisterManager; it must be wired into the TIA project alongside it.
The manual lists no separate functionalities section for this block beyond its principle of operation.
Models a single-object presence sensor — typically a photoelectric light switch mounted over a belt.
Detects one object via a trigger signal and matches the conveyor's actual position (reference data) with the object data supplied at its objectData input at the instant of triggering. Chained to a FO-Source, the matched object is then inserted into the register automatically.
Models a rectangular x/y detection area painted onto a conveyor — not a physical sensor at all.
Defines a rectangular zone on a conveyor from a cartesian start position and an x/y dimension, attached to a conveyor ID and coordinate frame. Products or containers passing through it are marked in the register (assignedZone). Other FOs then read that marking: a FO-Actuator uses a zone as its picking or placing zone, a FO-Sink uses one as a deletion zone.
The manual lists no separate functionalities section for this block — the zone definition itself, above, is the whole of its behaviour.
Models a vision system that detects several objects at once on a moving belt.
Matches the camera's reported object data (positions, characteristics) with the conveyor's reference position at the moment of triggering, across a definable array of detected objects. Offers three trigger modes: manual digital input (low precision), a TO_OutputCam for equidistant high-precision triggers, or a TO_MeasuringInput for event-based high-precision triggers. Its outputs then feed one FO-Source per detectable-object index, up to LPRODREG_CAMERA_MAX_NO_OF_DETECTABLE_OBJECTS.
The heaviest sensor in the library.
Models a handling device — a kinematic or manipulator — that picks objects off a conveyor and places them elsewhere.
Watches a “picking zone”, and in container modes a “placing zone”, each defined by a FO-Zone, and hands the user position data for the highest-priority object inside — plus a “zone extension” grace length so a kinematic riding MC_TrackConveyorBelt can still finish a grip after the object leaves the strict zone. The user drives a five-state processing sequence at output controllingIndex (idle · searching · object found, waiting for objectPicked · picked, waiting for a place target · waiting for objectPlaced) by triggering those two inputs at the right moments. Six operation modes cover picking from a conveyor or from inside a container pocket, and placing onto a conveyor, into a container pocket, or into a station.
The heaviest flow object in the library.
Models one processing station in a station-based, FIFO-ordered line.
Represents a single processing station with its own FIFO storage area for products and containers in the register. Objects arrive via a FO-SourceStation, or are picked into it by a FO-Actuator (modes 3/6), and become available for processing in arrival order. Triggering processProduct / processContainer processes the object at the front of the queue per the station's configured mode; the next object then advances into that slot.
Models the automatic or manual deletion point for products leaving the process.
Deletes products from the register in one of two modes: automatic deletion by zone, where every product entering a linked FO-Zone is removed each cycle, or manual deletion by product property, where the user activates one or more “deletionBy…” property inputs and fires digitalTriggerInput to delete every product that matches. configSinkProduct.allPropertiesLinked chooses whether all activated properties must match, or any one is enough.
Models the same deletion mechanism as FoSinkProduct, applied to containers.
Operates on the same automatic-by-zone / manual-by-property principle as FoSinkProduct — the manual gives it no separate explanation. Deleting a container also deletes every product or container that was placed in its pockets.
Beyond the flow objects: LProdReg_ProductDataBaseManager is the core — not an FO — that processes every FO's requests and alone owns the register (see Architecture, above). LProdReg_RegisterManager wraps and calls whichever of these blocks an application configures, which is why its own footprint has no fixed size. LProdReg_Hmi_Main is the HMI faceplate for categorised visualisation of the register's content, with delete and filter functions.
A running model of the scenario in Figure 1‑3: products and containers arrive on two conveyors, a camera and a light switch detect them, an FoActuatorKinematic packs products into container pockets, and every object’s life — from first detection to deletion — plays out as a row in LProdReg_ProductDataBase on the right.
Camera FoSensorCamera_1 matches colour/shape object data against the product belt’s reference position the instant it triggers; light switch FoSensorLightSwitch_1 does the same for containers. The actuator tracks the still-moving belt via the system function MC_TrackConveyorBelt while it picks and places.
One row per checked-in object; position updates every tick and state follows the flow object that last touched it. Register order here uses the library’s standard modes (X‑highest on the product conveyor, call order on the container conveyor) — a user-defined rule via LProdReg_UserDefinedObjectConveyorPrioritization could replace either.
| # | Object | Characteristics | Position | State | Flags | Last FO |
|---|
Illustrative traffic between flow objects and LProdReg_ProductDataBaseManager over the client‑server channel — not a byte-accurate protocol trace. Newest entry at the bottom.
The register itself is FB LProdReg_ProductDataBaseManager plus a set of flow objects, but almost nobody wires those by hand. LProdReg_RegisterManager is the streamlined, single‑block alternative: one FB that configures, calls and diagnoses the whole application. This is the block you actually call.
RegisterManager owns the flow objects it needs — conveyors, cameras, light switches, actuators, sinks and zones — and initialises them from one configuration structure. What you connect from your own program is sensor data in, actuator interaction out.
| Name | Data type | Purpose |
|---|---|---|
| enable | Bool | Enables the manager and, in turn, every flow object it owns. |
| useRetainedValues | Bool | TRUE resumes from whatever is already in the retentive ProductDataBase DB after a stop/restart; FALSE clears it on enable. |
| lightSwitchTrigger | Array of Bool | One rising edge per configured light switch, for manual/digital triggering. |
| lightSwitchObjectData | Array of typeObjectDataEntry | The object (position + characteristics) each light switch spawns when it fires. |
| lightSwitchDisable | Array of Bool | Temporarily disables one light switch sensor during operation. |
| cameraTrigger | Array of Bool | Manual reference‑data trigger per camera; only used in triggerMode 1. |
| cameraData | Array of typeSensorCameraData | Incoming object list from the vision system for each camera. |
| cameraDisable | Array of Bool | Temporarily disables one camera sensor. |
| actuatorRuntimeConfig | Array of typeConfigActuatorRuntime | Per‑actuator runtime changes: disable, mode, and pick/place zone re‑assignment with optional property overwrite. |
| transferDataProductConveyor | Array of typeTransferDataFoConveyorBelt | Cross‑PLC position feed for product conveyors with useTransferData = TRUE. |
| transferDataContainerConveyor | Array of typeTransferDataFoConveyorBelt | Same, for container conveyors. |
| config | typeConfigManager | The entire configuration — see below. |
| Name | Data type | Purpose |
|---|---|---|
| valid | Bool | A valid set of outputs is available. |
| busy | Bool | Still processing; more output values will follow. |
| error | Bool | An error occurred — see Errors. |
| status | Word | 16#0000–16#7FFF status, 16#8000–16#FFFF error identifier. |
| diagnostics | typeManagerDiagnostics | Product/container counts per conveyor, state of every internally called flow object, and — on ERR_IN_FLOW_OBJECT — the name and status of the first faulted one via foInError. |
| transferDataActuator | Array of typeTransferDataFoActuator | Cross‑PLC feed when an actuator’s kinematics control logic runs on a secondary PLC. |
diagnostics.numberOfFlowObjects tells you exactly how many flow objects the manager checked in — read it after first enable and use it to size LPRODREG_NO_OF_ACTIVE_FLOW_OBJECTS and the request/response buffer (plus any externally called blocks).
| Name | Data type | Purpose |
|---|---|---|
| actuatorInterface | Array of typeActuatorInterface | The full pick/place interface per actuator — this is what your kinematics‑control program connects to (see Engineering 3.7). |
| dataExchange | typeDataExchange | The request/response channel between flow objects and the database manager, exposed so externally called flow objects (e.g. FO‑Station) can join it — see 3.8. |
| productDatabase | typeProductDataBase | The register itself, exposed so LProdReg_Hmi_Main can be called externally. |
One structure, six parts. This is the part you will keep coming back to while commissioning.
One entry per real belt or static storage that carries products. Sizes at LPRODREG_NO_OF_PRODUCT_CONVEYORS.
| # | Prioritisation | User tag |
|---|---|---|
| 0 | No prioritisation | LPRODREG_PRIO_NO_PRIO |
| 1 | Highest X (conveyor CS) | LPRODREG_PRIO_X_HIGHEST |
| 2 | Smallest X | LPRODREG_PRIO_X_SMALLEST |
| 3 | Smallest Y | LPRODREG_PRIO_Y_SMALLEST |
| 4 | Highest Y | LPRODREG_PRIO_Y_HIGHEST |
| 5 | Smallest Z | LPRODREG_PRIO_Z_SMALLEST |
| 6 | Highest Z | LPRODREG_PRIO_Z_HIGHEST |
| ≥7 | User‑defined (see below) | — |
Same shape as a product conveyor, for belts that carry containers. Sizes at LPRODREG_NO_OF_CONTAINER_CONVEYORS.
The interconnection between the register and one kinematics. Sizes at LPRODREG_NO_OF_ACTUATORS — every configured actuator must be used, or the manager errors.
| # | Pick from | Place to |
|---|---|---|
| 1 | Conveyor | Conveyor |
| 2 | Conveyor | Container pocket |
| 3 | Conveyor | Station |
| 4 | Container pocket | Conveyor |
| 5 | Container pocket | Container pocket |
| 6 | Container pocket | Station |
An array of frames, each referenced to the world coordinate system, used to place conveyors, cameras and light switches relative to one another. Sizes at LPRODREG_NO_OF_COORD_SYSTEMS — you need one frame per conveyor and one per sensor (unless they coincide).
An array of station FO‑IDs. FO‑Station cannot be configured from inside the RegisterManager — it is always called externally (3.8) — this array just tells the manager which IDs to expect, so it can be sized and referenced consistently.
Parameters passed straight through to the core FB ProductDataBaseManager:
The register's actual storage. Every detected product and container lives here, and the size of every array is entirely a function of the configuration tags above.
Four hooks, all already called internally — you extend them, you never call them yourself.
Extends the standard pick‑order modes 0–6 for a FO‑Actuator's picking zone. Position and user‑defined characteristics can both drive the choice — e.g. pick only blue products. Three example strategies ship pre‑written; add more at any index ≥7.
Extends modes 0–6 for how newly inserted products/containers are ordered in the register on a conveyor, again by position or characteristics. One example strategy (by colour) ships pre‑written.
Lets an FO‑Sink delete products by a user‑added characteristic. Set configSinkProduct.deletionByCharacteristics and the target value, then trigger digitalTriggerInput on the sink.
The same mechanism for containers — identical principle, its own FO‑Sink.
Two tag tables ship with the library: LProdReg_InternalTags (leave alone) and LProdReg_ConfigurationTags (yours to set). The manager's own memory footprint is a direct function of these.
| Tag | Default | Sizes… |
|---|---|---|
| LPRODREG_NO_OF_PRODUCT_CONVEYORS | 1 | Product conveyor array |
| LPRODREG_NO_OF_CONTAINER_CONVEYORS | 1 | Container conveyor array |
| LPRODREG_NO_OF_MAX_PRODUCTS_PER_CONVEYOR | 10 | Product storage per product conveyor |
| LPRODREG_NO_OF_MAX_CONTAINERS_PER_CONVEYOR | 10 | Container storage per container conveyor |
| LPRODREG_NO_ACTUATORS | 2 | Actuator array |
| LPRODREG_NO_OF_CAMERAS | 1 | Camera sensor array |
| LPRODREG_NO_OF_LIGHTSWITCHES | 2 | Light switch sensor array |
| LPRODREG_NO_OF_COORD_SYSTEMS | 4 | Coordinate‑frame array |
| LPRODREG_NO_OF_STATIONS | 1 | Station ID array |
| LPRODREG_NO_OF_DIFFERENT_CONTAINER_GROUPS | 1 | Container groups — must match container conveyor count |
| LPRODREG_LENGTH_OF_PRODUCT_POCKET_ARRAY | 10 | Products stored in container pockets |
| LPRODREG_LENGTH_OF_CONTAINER_POCKET_ARRAY | 10 | Containers stored in container pockets |
| LPRODREG_NO_OF_ACTIVE_FLOW_OBJECTS | 16 | Flow‑object array (+2 with Hmi_Main) |
| LPRODREG_NO_OF_REQUEST_RESPONSE_BUFFER_ELEMENTS | 16 | Request/response buffer — must equal active‑FO count |
| LPRODREG_NO_OF_MAX_PICKS_PER_CYCLE | 1 | Multi‑pick ceiling per actuator |
The manual's own path from an empty TIA project to a running register, in order. Each step expands with the concrete detail — and the machine used as the running example throughout is the same three‑conveyor, two‑picker setup as Scenario 2.
A base TIA Portal V20 project. Nothing library‑specific yet — just the usual axis groundwork:
For the HMI faceplate specifically: update the project library's Types from the global library, drag LProdReg_Faceplate onto a screen, connect its Interface tab to the matching PLC variable, then compile and download.
Work through LProdReg_ConfigurationTags by answering these questions for the application:
Add fields (colour, shape, …) to LProdReg_typeObjectUserDefinedProperties if the application needs them. They then become available to: prioritisation/sorting in the register, custom picking strategies at the FO‑Actuator, and deletion by characteristic at an FO‑Sink.
One frame per conveyor and per sensor (camera / light switch), all referenced to the world coordinate system.
Done in the shipped DB LProdReg_RegisterManagerConfig. The manual walks it through the example machine — a product conveyor, two container conveyors and two delta pickers:
Instantiate in Main OB or a Pre‑Servo OB, depending on timing needs, and interconnect with the library's own LProdReg_DataExchange, LProdReg_ProductDataBase, LProdReg_ActuatorInterface and LProdReg_RegisterManagerConfig DBs. From there, hook ActuatorInterface to whatever controls the pickers.
Feed the sensor inputs described in the block interface above: light switch triggers from digital signals plus a prepared object‑data DB per conveyor, and camera triggers plus incoming object count/data from the vision interface.
Wire the manager's actuatorInterface InOut to whatever FB drives the picker. If that FB is built on the LKinCtrl library, its MC_TrackConveyorBelt input conveyorBeltOrigin must be configured to match — positions from the RegisterManager are already in the world coordinate system, so X/Y/Z stay at 0.0 and only orientation A (if the conveyor is rotated against the WCS) matters.
Some flow objects are never called from inside the RegisterManager and must be placed and wired by hand into the shared dataExchange DB:
LProdReg_Hmi_Main is the backing block; LProdReg_Faceplate is what the operator actually sees — a categorised, filterable window into the live register, with delete functions built in.
Manages data exchange between the HMI and the product database, and lets the operator delete objects or search by filter characteristics. Called externally (3.8), so its dataExchange and productDatabase InOuts join the same DBs the RegisterManager uses.
Pick a category, then a conveyor or station number, to narrow the table.
Choose a category (the six chips above) and, where relevant, the conveyor or station number.
Pick the parameter to filter on and enter its value.
Open the configuration icon for a category; set a priority (1, 2, 3…) per parameter to control column order — priority 0 hides it — and pick a gap width for the board.
Select an object to see its full parameters and characteristics; the delete icon removes just that one.
Tick objects (the top checkbox selects all shown), press delete, choose “Delete selected”, confirm twice.
A ticked row that shifts position when the list refreshes is automatically un‑ticked.
With a category and number selected, press delete, choose “Delete category” instead, and confirm twice.
One example project, three projected PLCs, each demonstrating a different shape of application — from the simplest possible register to full conveyor tracking to the purely stationary mode.
A single conveyor belt with a light switch. Products spawn, get detected, are tracked along the register while the belt runs, and are deleted once they reach the end — the smallest possible register application, and the one to read first.
The light switch trigger is simulated as a rising edge every 50 mm of belt travel: a product is inserted every 50 mm, each rotated 60° and offset 20 mm in Y from the last, cycling every 6 products. An externally called FO‑Sink lets the operator manually delete by product ID, source conveyor ID, name, or a characteristic (e.g. colour = blue).
| Axes | Reset, power, home Belt_1 |
| Motion | MC_MoveVelocity |
| Blocks | LProdReg_RegisterManager (1×), LProdReg_FoSinkProduct (1×, external) |
Three conveyors, a camera, two light switches, and two delta pickers — the fullest example, and the one that demonstrates conveyor tracking through the example FB TrackConveyor.
One product conveyor (camera detects blue/red products), two container conveyors (light switches detect boxes = group 1, then pallets = group 2). Both conveyor prioritisations are set to mode 1 (highest X). Picker 1 uses a user‑defined priority (…_CASE_2) so it only ever picks blue products into the 4‑pocket boxes; picker 2 has no such filter and moves any full box onto a pallet. Both pickers are driven through the example FB TrackConveyor (see 7.2), called in OB132 TrackConv_Call, which also does the path planning via MC_MovePath from LKinCtrl.
| Main (1) | Axis funcs Belt_1–3; output‑cam trigger logic for both light switches; TON to simulate camera response; MC_MoveVelocity ×3; RegisterManager; Hmi_Main |
| TrackConv_Call (132) | TrackConv ×2, LKinCtrl_MC_GroupReset ×2 |
One static storage, three processing stations and two sources — the station‑based mode, entirely without conveyor tracking or an actuator. Products and containers are shifted between stations by hand‑triggered requests, and characteristics update as they move.
FO‑SourceStation and FO‑Station cannot be configured through the RegisterManager, so they're always called externally — the manager's own configuration here holds just the one static‑storage conveyor.
| Blocks | LProdReg_RegisterManager (1×), LProdReg_FoSourceStation (2×), LProdReg_FoStation (3×) |
When one PLC's motion‑control resources can't cover every conveyor and kinematic in the line, LProdReg keeps running on a “main PLC” and hands the real axes to a “secondary PLC” — exchanging only the mandatory I/O of the affected flow objects.
Two independent approaches, both built on the same transfer‑area mechanism. Integrate every transfer type and transfer block of the library into the secondary PLC — nothing else from LProdReg is needed there.
Requirements STEP 7 V16+, firmware V2.8+, IRT‑capable devices, one sync domain with a sync master/slave pair, IRT ports interconnected.
Setup create the comm. relation on the main PLC's PROFINET interface → add one transfer area per I/O tag pair, matching lengths exactly → assign each area to MC‑Servo (or an isochronous OB) and a process image partition.
Setup set the secondary interface's operating mode to I‑device → assign the IO controller → tick “parameter assignment by higher‑level IO controller” for IRT on the main side → export/import the GSD file → create and edit transfer areas exactly as for direct exchange.
| Comm. method | Max. transfer area | Max. areas |
|---|---|---|
| Direct data exchange | 3075 Byte | 128 sender / 512 receiver (≤64 CPUs) |
| I‑Device | 1440 Byte | 64 |
| Flow object | Required transfer length |
|---|---|
| FO_ConveyorBelt | 22 Byte (data in) |
| FO_Actuator | 152 Byte — 126 B out + 50 B in |
Maximum data length for a single transfer area is 1024 Byte either way.
When the conveyor belt is on the main PLC but the kinematic tracking it is on a secondary PLC (or vice versa), a 1:1 gearing must run cross‑PLC: the real belt's leading value goes over to a “leading axis proxy” technology object on the other side, which is then geared 1:1 to a virtual representative TO_Axis — and that virtual axis, once its delay time is configured correctly, is what conveyor tracking actually follows.
Every identifier the RegisterManager and its flow objects can raise, reconstructed from the manual's own tables. Errors set status to 16#8000–16#FFFF; warnings sit in 16#7004–16#7FFF and don't stop operation.
| Identifier | Value | Meaning & remedy |
|---|
Drawn from the manual's own NOTE / NOTICE / CAUTION boxes and from how the mechanism actually works.
Only the core FB touches the database directly. DB LProdReg_ProductDataBase is written exclusively by LProdReg_ProductDataBaseManager — every flow object, and your own program, talks to it only through the request/response channel in dataExchange. Writing the DB directly desyncs the register.
Coordinate systems must actually agree. Object position data and conveyor reference data are only meaningful together when they share the same coordinate frame — a mismatched coordSystemIndex on a camera, light switch or conveyor doesn't error, it just silently misplaces every object it touches.
Minimum‑gap and duplicate detection both depend on sensor configuration. minProductGap / minObjectGap and the tolerance‑length duplicate check only work when the triggering camera or light switch is configured correctly for the scene — overlapping camera fields of view need the global (database‑level) version, not the per‑camera one, or a second camera on the same conveyor needs to be called externally.
The manager's own size is 100% a function of its configuration. Every array in LProdReg_ProductDataBase is dimensioned from the tags in LProdReg_ConfigurationTags — get the flow‑object count or buffer size wrong and the manager errors (ERR_INSUFFICIENT_NO_OF_ACTIVE_FLOW_OBJECTS, ERR_DATA_EXCHANGE) rather than quietly truncating.
A camera and a light switch can't share a conveyor. Both enabled on the same product or container conveyor throws ERR_CAMERA_AND_LIGHTSWITCH_AVAILABLE — if a light switch is meant to trigger the camera's timing rather than insert objects itself, leave the light switch disabled and use camera triggerMode 1 or 3/4 instead.
A user‑defined prioritisation function must always return a decision. Exiting LProdReg_UserDefinedActuatorPrioritization's search loop early without declaring which object to process throws ERR_USER_DEFINED_ACTOR_PRIORITIZATION — and a prioritisation index configured but never actually programmed throws ERR_MISSING_USER_DEFINED_PRIORITIZATION.
Objects mid‑process don't survive a shutdown. Even with retained values and a retentive database, anything an actuator had already gripped when LProdReg_RegisterManager was disabled is not retained — the physical object (e.g. still in a gripper) has to be removed by hand before re‑enabling.
Retained values need the whole DB set retentive, not just the flag. useRetainedValues = TRUE only resumes cleanly if DB LProdReg_ProductDataBase itself is marked retentive; otherwise the manager still clears it on enable.
Deleting or skipping an object mid‑grip is a critical window. If a product/container is deleted, skipped, or leaves the exit zone in the moment between “above pick/place” and “pick/place” in FB TrackConveyor's flow, the kinematic still finishes the move it already started — size pick/place and extension zones for the kinematic's real dynamics, not just the belt speed.