Skip to main content

πŸ”Œ Connecting Machines to Workflows with Parameters

Written by Alex Merkin

What this is

This feature allows you to connect machines to workflows using parameter-based logic, without requiring direct physical mapping or hardware pairing.
You can track:

  • Machine activity (e.g. running, idle)

  • Quantity and timing per machine

  • Operator check-in/check-out

  • Events and transitions during production

It supports real-time monitoring, quantity splits, and multi-machine workflows β€” even when using simulated or partial data sources.

Why it matters

You can now:

  • Monitor machines even without full OPC integration

  • Automate check-in/check-out actions based on live data

  • Split production across multiple machines

  • Record machine usage and performance accurately

  • Reduce errors and increase traceability
    Perfect for manufacturers who need flexible, scalable monitoring tied to actual production logic.

How it works

🧩 1. Define Machine Types & Services

  • Define production services (e.g. "CNC", "Assembly Test Rig")

  • Under each service, create machine types

  • Machines are not hardwired to steps β€” they are connected by parameter logic

πŸ§ͺ 2. Connect via Parameters

Each machine exposes one or more parameters, such as:

  • Status (running, idle, error)

  • Quantity counters

  • Booleans or numeric values

These parameters can come from:

  • OPC-UA servers

  • Simulated sources (e.g. for testing)

  • External systems via parser

You define which parameters are tracked and what behavior they represent.

🧠 3. Use Dynamic or Simulated Data

You can simulate live values that update every few seconds β€” useful for:

  • Demo environments

  • Offline development

  • Workflow testing before physical integration

πŸ”„ 4. Monitor Status & Changes

The system monitors changes and logs machine states. You can:

  • Define status types (Active, Setup, Maintenance, etc.)

  • Set thresholds (e.g. only log changes over 0.01)

  • Log values at fixed intervals (e.g. every 30 minutes)

πŸ” 5. Track Machine Events & Movements

Two core types of logs:

  • Events: machine state or parameter changes (e.g. from idle to running)

  • Movements: material transitions like check-in or check-out

Sessions are created and closed based on parameter conditions, not manual steps alone.

πŸ‘· Operator Workflow

Here's what operators see and do:

🟒 Check-In

  • Operator scans the work order or presses "Start"

  • System starts a machine session and logs:

    • Time-in

    • Current machine status

    • Initial parameter values

In some cases, the system auto-checks-in when a machine begins running.

πŸ”΄ Check-Out

  • Operator ends the session manually or system closes it when work is done

  • Quantity can be entered or taken from the machine (if available)

  • Logs are recorded for:

    • Quantity processed

    • Time out

    • Final status

    • Any trigger-based actions (e.g., open a form)

πŸ”„ Splitting Work by Quantity

If a machine handles limited batches:

  • The operator can check in with partial quantity (e.g. 7 units out of 100)

  • Repeat check-in/check-out for each batch

  • System tracks all sub-sessions under the same work order

πŸŽ“ Example:
100 units need to go through a burn-in oven.
The oven handles 10 units at a time.
The operator runs 10 cycles β€” and the system tracks them all.

🧭 Where to See It

Screen

What you'll find

Machine Panel

Current status, live parameters, check-in button

Work Order / Session

Material flow, quantity reported, timestamps, machine used

Event Log

Parameter changes, machine state transitions, triggers, auto-actions

πŸ› οΈ Behind the Scenes

  • Machine logic is parameter-based, not physical

  • You can track multiple machines in a single workflow

  • Data is structured:
    ​Machine β†’ Parameter Group β†’ Parameter β†’ Value

  • Quantity, status, time-in/time-out are linked per session

  • Setup is managed by your integrator (OPC paths, trigger rules, etc.)

🎯 Best Practices

  • βœ… Use clear parameter names (e.g. CNC3_status, testBench_temp)

  • πŸ§ͺ Simulate your logic in a sandbox before going live

  • πŸ”„ Match machine parameter values to system-defined states (e.g. "running")

  • πŸ“¦ Define fallbacks for quantity if not reported automatically

  • πŸŽ“ Train operators to understand check-in sessions and how status is tracked

πŸ§ͺ For QA & Integrators

  • You can build and test full workflows before machines are fully connected

  • Use simulated data and triggers to refine logic

  • The same approach works with parsers, external logs, or hybrid setups

Did this answer your question?