Reference · built on requestOperator by FibricProduction & maintenance

Cycle Drift

Times each station's cycles from controller timestamps against the SKU standard and proposes a parameter check or a standard update.

Request accessPricing ↗

About

Cycle Drift is an operator for the gap between the cycle time a station is supposed to run and the one it runs. It takes cycle start and end events from the controller with the timestamps the controller applied, through OPC UA subscriptions, Sparkplug metrics on your MQTT broker, or KEPServerEX IoT Gateway, and compares the interval with the standard for the SKU on the job.

When a station drifts over standard, it proposes a parameter check for a person at the station. When a station runs under the standard job after job, it proposes a standard update. Nothing is written to a controller.

This is a reference listing. It documents what Fibric would read from Cycle Drift and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Cycle start and cycle complete tags on each station, observed as OPC UA data changes with the sourceTimestamp the controller applied
  • The same events over MQTT as Sparkplug DDATA metrics, each with name, value, timestamp, and datatype, published by exception with a seq number
  • Tag updates from KEPServerEX IoT Gateway agents: tag ID, value, quality, and timestamp, on change or at the publish rate
  • The SKU or part running at each station and its standard cycle time, from Plex jobs and job operations or a Tulip Table
  • Production and scrap entries from Plex, so a slow cycle is read beside the count it produced
  • Stale flags: a Sparkplug NDEATH that marks an Edge Node's metrics STALE, or an OPC UA status code that is not Good

Proposed actions

  • Target capability: propose a parameter check for a station whose cycle time has drifted from its SKU standard, naming the tags and the window
  • Target capability: propose a standard update, a new cycle time for the SKU at that station, in its Tulip Table record through PUT /tables/{tableId}/records/{recordId}
  • Target capability: propose reporting the measured cycle time as a Tulip machine attribute through POST /attributes/report
  • Target capability: propose a workcenter status change in Plex through POST /production/v1/control/workcenters/{workcenterId}/status when a station is stopped for the check
  • Target capability: propose a drift list per line: stations over standard, by SKU, with the first cycle that crossed the line

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Watch S7-1500 stations over OPC UA

    Cycle complete tags on each S7-1500 CPU are subscribed with their sourceTimestamp. Against the Plex job at that workcenter, the operator proposes a parameter check when cycles run over standard and lists the first slow cycle.

    With SIMATIC S7-1500, Plex

  • Read cycles from Sparkplug on the broker

    DDATA metrics from each Edge Node carry the cycle timestamp. The operator computes cycle time per SKU from a Tulip Table of standards and proposes reporting the measured value as a Tulip machine attribute.

    With Sparkplug, MQTT Broker, Tulip

  • Update a standard that no longer holds

    When a station runs under the standard for a SKU across many jobs, the operator proposes a new standard in the Tulip Table record and shows the cycles behind it, for the industrial engineer to approve.

    With Tulip, KEPServerEX

Requirements

  • Cycle events with controller timestamps: an OPC UA server such as an S7-1500 CPU, a Sparkplug Edge Node on your broker, or KEPServerEX IoT Gateway
  • A standard cycle time per SKU per station: Plex job operations, a Tulip Table, or a sheet
  • A way to know which SKU is running: the job at the workcenter in Plex, or a tag the controller exposes
  • Tags that mark cycle start and cycle end, enabled for OPC UA access or published by the Edge Node
Authentication
It subscribes and proposes through the OPC UA, MQTT, and MES connectors you bind, with the certificates, tokens, and keys those connectors hold; it holds no credentials of its own.

Limits

  • A cycle time is as exact as its timestamp. Sparkplug metrics and OPC UA sourceTimestamp come from the device; a KEPServerEX publish rate adds delay
  • OPC UA data changes filtered by an absolute or percent deadband may skip small value changes; a cycle counter must be subscribed without one
  • It never writes a parameter to the controller. A parameter check is a task for a person at the station
  • Plex documents no webhooks, so the job at a workcenter is polled; a changeover inside the poll interval can credit cycles to the previous job

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Cycle Drift ↗

Questions and answers

Who approves what?
A parameter check or a standard update. The check names the station, the SKU, the standard, the measured cycle times, and the window. The update shows the old and new standard and the cycles behind it. You approve, edit the number, or dismiss.
What is written down?
The tags read and their timestamps, the standard used, the drift found, the proposal, who approved it and when, and the record written in Tulip or Plex with its reversal. Dismissed proposals stay on file with the reason.
Does it write to the PLC?
No. It reads cycle tags over OPC UA, MQTT, or KEPServerEX and never sends a write, a method call, or a command to a controller. A parameter change is done by a person at the station after the check.
Ask about Cycle Drift

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy