Line Config describes your production line to CedarInsight. Required role: Supervisor.

Recommended configuration order: Counters → Program (with stages) → Products, then optionally Sensors, Takt, Cycle Stations and the Downtime catalogue. See also the commissioning checklist in chapter 3.6.

Line Config → Program defines line configurations. Click a program to open its detail view with the tabs Stages, Sensors, Takt, Products and Program Settings.

Programs usually have stages that are connected to counters or cycle stations:

• An Input stage (defined by the first position in the list)
• Several processing stages with counting between the stages
• An Output stage (defined by the last position in the list)
• Optional: one or more scrap counters

The minimal configuration is one output counter. The counter inputs are used to calculate the OEE values.

The program can also include takt and sensors. Those inputs do not have impact on the OEE calculation, but can be used for correlating in the production analysis or via the AI analysis (see below) .

Each stage is one counting point of the line, in process order:

Roles matter for OEE: the Input stage counts Units In (actual quantity), the Output stage counts Units Out (good quantity), a Defect/Reject stage counts rejected parts, and Intermediate stages are used for throughput and bottleneck analysis.

A stage can alternatively run in Cycle mode instead of Counter mode; it is then fed by a cycle station (section 7.4) rather than a piece counter.

Assign registered sensors (7.5) and takt sources (7.6) to the program and set warning/critical thresholds (Warn low/high, Crit low/high). Assigned sensors and takt appear in the run trend chart (chapter 6.3). The recorded data is used to correlate takt times and sensor values with the throughput of the line, e.g. if air pressure drops, the takt times get longer.

Line Config → Product manages the articles you produce. A product runs on a defined program, but with it's own cycle time. Example: Filling lines that use the same stations for filling and labelling, but fill different container sizes (this different speeds and cycle times).

Per product:

Line Config → Counters is the registry of Pinebox piece counters.The counter values are used as input to the programs. In order to use counters, they need to be defined and configured in the Pinebox.

Each entry stores:

Rather than typing keys manually, use the scan functions:

1. Scan for counters: reads the available counter keys from a selected (or manually entered) host.
2. Scan network: discovers Pinebox devices on the local network for remote counters
3. Import the keys you need; already registered keys are marked.

Read fetches the live values of all registered counters; use this to verify the mapping (unreachable hosts are reported).

Cycle stations monitor machines whose cycles are detected from their power consumption (e.g. presses, moulding machines): the Pinebox measures electrical power/energy, and a detector recognises each machine cycle from the power rise at cycle start and the power fall at cycle end.

In the list of cycle stations, the detected buffers are shown and can be updated

Line Config → Cycle Stations manages the registry (pen symbol). Cycle stations serve as input to the program counters. To use cycle stations, they need to be configured in the Pinebox.

Per station:

As with counters, Scan discovers devices on the network and imports the stations they advertise.

On stall defines what happens when the detector flags a stalled cycle:

• Auto-scrap: the part is automatically counted as scrap,
• Ask operator: a resolution prompt appears; the operator chooses Scrap, Complete or Re-enter,
• Auto-continue: the partial cycle is accepted as complete.

The Calibrate view shows a live power scope (~2 min window; scroll to zoom, drag to pan) with the average power and its rate of change, plus the currently configured thresholds and the observed idle/peak values.

Detector parameters:

Calibration procedure:

1. Let the machine run a few normal cycles.
2. Watch the rate trace (right axis, W/s): set Start rise to the leading-edge peak and End fall to the trailing-edge dip of a cycle.
3. Set Baseline to the observed idle power.
4. Use the energy measurement to determine Min energy: click once on the curve to set the start marker, click again for the end marker; the energy under the curve and the time span are displayed. Set Min energy safely below a normal cycle's energy but above noise level.
5. Save and verify that the Detected Cycles markers match the real machine cycles.

Sensors are the one data type in CedarInsight that is pushed, not polled; everything else (counters, cycle stations, takt) is fetched by CedarInsight itself on a timer, and sensors instead arrive whenever the source decides to send them. The path is:

1. Pinebox: the IO-Link sensor data is configured and poweredread at the hardware/fieldbus level. [PBX]
2. Node-RED: a flow running on the Pinebox (local or remote) cyclically (via cyclic inject) reads that value as described in the Pinebox manual, packages it into the JSON shape CedarInsight expects, and sends it on.
3. CedarInsight: serves the receiving endpoint and stores what arrives. Nothing needs to be configured on the CedarInsight side to make it “listen”; the API is always up as part of the normal backend, and the only setup is registering the sensor here in Line Config → Sensors so incoming keys are recognised.

POST http://<cedarinsight-host>:8000/api/sensors/ingest

sent as a single sample object or an array of them, e.g.

 ''[{"sensor_key": "line1_temp", "value": 74.2, "unit": "°C"}]''

The full payload contract, field-by-field, and a worked Node-RED flow example (input node → function node → HTTP request node) are in chapter 11.6 [PBX]. This section covers the registry side: what to configure here once data is flowing.

Per sensor: Name, Sensor Key (must match the sensor_key the source sends, exactly; this is the only link between the incoming push and the registered row), Unit, Value Type, description.

Use Discover sensors to list keys currently sending live data (i.e. anything that has POSTed to the ingest endpoint recently, whether registered yet or not) and Register them directly, including their current value, so you can identify each signal before naming it.

If a not-yet-registered key's push includes display_name/unit, the sensor is auto-registered on first arrival; Discover will simply show it as already present. Once a sensor is registered and named through the UI, pushed display_name/unit values never overwrite what's set here, the UI always wins.

The Source column in the sensor list reflects whether a sample for that key has arrived recently (within the last 30 seconds):

• OK (green): a sample was received within the last 30 seconds.
• stale (amber): no sample for longer than that; hover the chip for the last-seen time. Registered sensors keep their configuration regardless; this only reflects whether the push side is currently alive.
• — (grey): no sample has ever been received for this key since the backend last started.

This is independent of whether a production run is active; Node-RED can push (and this column will show OK) even with the line stopped.

Takt is the cycle time of one individual unit (e.g. robot) how long that one process took, timed directly by the Pinebox, not derived from a counter. Takt is the time measurement between two events, e.g. a movement from A-to-B with a sensor on both ends.

Takt is complementary information, not a driver of OEE: unlike Counters and Cycle Stations, takt values never feed into Availability, Performance, or state transitions; like sensors they exist purely to catch a single slow (or suspiciously fast) cycle in the moment, via the warn/crit thresholds set on the program assignment (7.1), which raise notifications when breached and get overlaid against actual values in the run trend chart (6.3) for root-causing dips seen in the “real” OEE numbers.

Line Config → Takt registers takt (cycle-time) sources measured by Pinebox timers. Per source: Name, Takt Key (must match the key of the Pinebox takt endpoint exactly [PBX]), Host/Port, description.

Scan for takt reads the available timer keys from a Pinebox (local or remote) and registers them directly.

Assign takt sources to a program (7.1) to monitor cycle times against thresholds and overlay them in the run trend chart.

Line Config → Downtime maintains the two-level reason catalogue used when classifying stops (chapter 5.4): Categories (e.g. “Mechanical”, “Material”, “Organisational”) each containing Reasons.