🔌 Connecting Machines to Workflows with Parameters

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