# IoTFlows IoTFlows is a manufacturing intelligence platform that monitors machines with plug-and-play sensors or custom integrations to any PLC, robot or sensor, and turns the data into utilization, downtime, OEE, production scheduling and maintenance workflows. Used by 100+ manufacturers (organizations with active devices, October 2026). Customers see 35% less unplanned downtime in the first six months (median across IoTFlows customers, internal data). This file indexes the website, the documentation, the customer stories with their measured results, and the blog. --- # Review the organization audit log Source: https://www.iotflows.com/docs/admin/audit-log/ How to find out who changed something in IoTFlows, when, and what the value was before. The organization audit log lives at /logs and holds one row per change, with a Log message, a color-coded Event chip, and a date. Three filters narrow it: a Users picker, a date range that takes effect on Apply, and a free-text search that matches identifiers as well as words. Selecting a row opens the Log Information modal, which shows the request payload and the record Before and After the change as raw JSON. There is no export. A work order's Activity Logs tab is the same log filtered to that work order, and is the only version the mobile apps reach. # Review the organization audit log Find out who changed something, when they changed it, and what the value was before. **You need to be an Organization Owner or Organization Administrator.** See [Roles and permissions](/docs/admin/roles-reference/#roles). **Web only**, with one exception: the [per-work-order history](#work-order) is the version the mobile apps reach. An *audit log* is a record of the changes people made, one row per change. IoTFlows writes an entry every time someone creates, edits, or deletes something in your organization, and keeps a copy of the record as it stood before the change and after it. Use the log to answer "when did this change", not "what is the current state". Rebuilding a machine's current configuration out of a stack of entries is slower and less reliable than opening the machine and reading it. You do not need the log for a value you can read off the screen that owns it. ## Open the log Select **Logs** in the top navigation, or go to `/logs`. Each row of the table is one change. | Column | What it holds | |---|---| | **Log** | A sentence naming the member and what they changed | | **Event** | A chip naming the kind of change. The color comes from the server, so one kind of event is always one color | | **Date** | When the change was made, as `2:41pm 9/18/25` | The table pages 25 rows at a time. The footer above and below it reads the position in the result, for example `1 - 25 of 213`, with arrows either side to move a page. ![The Logs page at /logs, with Logs selected in the product nav. A dashed Users pill sits at the top left and a date-range button reading 9/15/2026 - 9/21/2026 at the top right, a full-width Search field under them, and below that a table with Log, Event, and Date columns. Fourteen rows are in view, each a sentence naming the member and what they changed, an amber Modified chip, and a timestamp. A header above the table reads 1 - 25 of 1000 with previous and next arrows. Nothing on the page offers a download](/images/admin/adm-log-01.webp) *The organization audit log. There is no export.* There is no export. The log cannot be downloaded as a CSV and cannot be emailed, so copying the rows you need out of the browser is the only way to take them anywhere else. See [What has no export](/docs/monitoring/exports-reference/#no-export). ## Filter by user 1. Select the dashed **Users** pill at the top left. 2. Type into **Search users...** to narrow the list by name, email, or username. 3. Select each member whose changes you want. A blue check marks the row. 4. Select **Apply**. The pill then carries a count of the members you picked, for example **Users 2**, and the table reloads against that set. To drop the filter, reopen the pill and select **Clear**, or select the circle at the left of the pill. ![The filter row of the Logs page with all three filters set. Marked 1, the dashed Users pill carries the count 1 for the one member picked. Marked 2, the date-range button reads 9/15/2026 - 9/21/2026, with its picker open below on a list of presets, a days up to today box, two date fields, a September calendar with the week of the 20th selected, and an Apply button. Marked 3, the full-width Search field holds the word status, and the rows behind the picker all carry the word status](/images/admin/adm-log-02.webp) *Filtering the log by user, date range and free text.* Every filter is written into the address bar, as `users`, `from`, `to`, and `text`. A filtered log is therefore a link: paste the URL into a ticket and the person who opens it lands on the same rows. ## Filter by date range The button at the top right reads the range it will request, for example `9/15/2025 - 9/21/2025`. 1. Select the button to open the calendars. 2. Pick a preset from the left column: **This Week**, **Last Week**, **This Month**, **Last Month**, **This Year**, or **Last Year**. You can instead type a number of `days up to today`, or select a start day and an end day on the two calendars. 3. Select **Apply**. The calendars stop at tomorrow, so you cannot ask for a future range. > **Warning:** > **The table is empty. Where did the entries go?** > > Check the date range before anything else. On first load the button reads the last seven days, but no range has been sent yet, so the table holds whatever window the server returns by default. > > Selecting **Apply** is what puts a range on the request, and a range that ends before the change you are looking for returns nothing. A **Users** filter left applied from an earlier visit is the second thing to check. ## Search the text The **Search...** field runs under the two filters and re-runs the query on each keystroke. It matches the text of the entry, identifiers included, so pasting a work order's or a machine's identifier returns every entry that touched that record. ### Log filters | Filter | Accepts | Notes | |---|---|---| | **Users** | One or more members, picked from a checkbox list | Search the list by name, email, or username. Takes effect on **Apply**. Written to the URL as `users`, once per member | | Date range | A start day and an end day, from a preset, the `days up to today` box, or the calendars | Takes effect on **Apply**. Nothing later than tomorrow. Written to the URL as `from` and `to` | | **Search...** | Free text | Runs as you type, with no **Apply**. Matches identifiers as well as words. Written to the URL as `text` | The three combine. Picking two members, a one-week range, and the word `downtime` returns only the entries that satisfy all three. ## Read the before-and-after diff A *diff* is the same record shown twice, as it stood before a change and as it stood after, so you can compare the two. Select any row. The **Log Information** modal opens on the entry's message and two panes of raw JSON: | Pane | What it holds | |---|---| | **Before** | The whole record as it stood before the change | | **After** | The whole record as it stood after it | Both panes hold the entire record, not only the fields that moved, so read them side by side and find the key that differs. The keys are the API's field names rather than the labels on the screen where the change was made, so a machine's display name reads `asset_custom_name`. Not every entry shows a difference. Entries that created a record carry the same JSON in both panes, and so do some status toggles, where the log records the record as it ended up rather than as it stood a moment earlier. On those, the row's own sentence is the record of what changed. ![The Log Information modal. The entry's message, that a member modified the shock threshold of a SenseAi sensor to 2, sits at the top, and below it two panes side by side headed Before and After, each holding the same sensor record as syntax-highlighted JSON, scrolled to the same line. An arrow points at node_shock_threshold in the After pane, which reads 2 where the Before pane reads 4. A Cancel button closes the modal](/images/admin/adm-log-03.webp) *The before-and-after diff for one change.* > **Info:** > **Why does the close button say Cancel?** > > Nothing in **Log Information** is editable and there is nothing to save, so **Cancel** closes the entry and changes nothing. The log carries no control for editing or deleting an entry, on this modal or on the table behind it. ## Per-work-order history Open a work order and select its **Activity Logs** tab. It is the same log, the same three columns, and the same **Log Information** modal, narrowed to that one work order. IoTFlows builds the tab by searching the log for the work order's identifier, so the tab shows exactly what the organization log shows when you paste that identifier into **Search...**. Use the tab when you already know which work order is in question, and `/logs` when you do not. The **Activity Logs** tab is also the only version of the log that reaches a phone, because `/logs` itself is absent from both mobile apps. See [Work order detail](/docs/maintain/work-order-detail/). ## See also - [Work order detail](/docs/maintain/work-order-detail/) - [Change roles and remove members](/docs/admin/manage-members/) - [Limit which machines a member can see](/docs/admin/machine-access/) - [Exports reference](/docs/monitoring/exports-reference/) --- # Manage payment methods and invoices Source: https://www.iotflows.com/docs/admin/billing/ How an Organization Owner runs IoTFlows billing at /{organization}/settings/billing, the one settings page no other role can open. The page holds a Customer Billing email that every invoice and payment failure is sent to, a list of payment cards added through Stripe, and two tabs: Current Invoice, which previews the period in progress, and Invoices, which lists issued invoices with Paid, Open, Draft, Void, and Uncollectible status chips and a downloadable PDF for each. Set the billing email to a shared finance address, because an unpaid invoice suspends the organization, suspension stops machine data collection, and the gap in the record is permanent. # Manage payment methods and invoices Your cards, the address invoices go to, the period in progress, and every invoice already issued. Billing lives on one page at `/{organization}/settings/billing`, separate from the rest of Organization Settings. It holds three things: the *billing email*, which is the address Stripe sends every invoice and every payment failure to; the payment cards on the organization; and the invoices themselves, split across a **Current Invoice** tab and an **Invoices** tab. **Before you start.** You need to be an *Organization Owner*. An Administrator is not enough, and neither is anything below it. See [Roles and permissions](/docs/admin/roles-reference/#owner-only). ## Open Billing 1. Select your profile picture at the top right of the dashboard. 2. Select **Billing**. Any role can select the menu item, but only an Owner sees the page. Everyone else gets "You are not authorized to access this page. Only organization owners can access this page." If that is you, find your Owner. No other role can change a card, an address, or a payment on this account. ![The full Billing page. An Account heading sits above a Customer Billing row holding a redacted email address and an Edit button. A Cards heading with an Add Card button sits above three card rows, each with its last four digits redacted and the last one carrying a Default chip. Below both, a tab strip reads Current Invoice and Invoices. Numbered callouts 1, 2 and 3 mark the three regions.](/images/admin/adm-bill-01.webp) *The Billing page at /settings/billing, with the Customer Billing email at the top, the Cards list below it, and the Current Invoice and Invoices tabs at the bottom. Only an Organization Owner can open it.* ## Set the billing email The billing email is the **Customer Billing** field in the **Account** section at the top of the page. It is the only address Stripe writes to, and it is independent of your own [profile email](/docs/admin/profile/). 1. Select **Edit** beside the field. 2. Type the address. 3. Select **Save**. An "Invoice email updated" toast confirms the change. **Cancel** discards it. **Use a shared finance address, not a personal one.** `accounting@midwesttooling.com` beats the Owner's own inbox. This address receives payment failures as well as invoices, and a failed payment that sits unread while one person is on vacation is how an organization gets suspended. > **Warning:** > **Why does an unread invoice matter this much?** > > An unpaid account is suspended, and **a suspended organization stops collecting machine data**. The sensors keep running, but nothing is recorded. Paying the bill lifts the lockout and does not backfill the gap, so the hours lost are missing from every report forever. > > See [Restore a suspended organization](/docs/admin/suspended-account/). ![A cropped detail of the Customer Billing row in edit mode. The email field holds the address billing@example.com, and Cancel and Save buttons sit immediately to its right.](/images/admin/adm-bill-02.webp) *The Customer Billing field in edit mode, holding a shared finance address, with Cancel and Save beside it.* ## Add a card Cards are handled by Stripe. IoTFlows never sees or stores the number. 1. Select **Add Card**, at the right of the **Cards** heading. 2. Fill in the **Add Payment Card** dialog: card number, expiry, security code, and the billing details Stripe asks for. 3. Select the checkbox agreeing to the IoTFlows [Terms of Use](https://www.iotflows.com/policies/terms-of-use). **Submit** stays disabled until you do. 4. Select **Submit**. A "Card successfully added!" toast confirms it and the new card appears in the list, showing its brand icon, "Card ending in 4242", and its expiry month and year. If the card is declined or a field is wrong, Stripe's own message appears under the form. Correct the field it names and submit again. If Stripe accepts the card but IoTFlows cannot save it, you get "Card could not be saved" instead, and no card is added. ![The Add Payment Card dialog. Card and Google Pay choices sit at the top with Card selected, above Stripe's empty Card number field carrying the Visa, Mastercard, Amex and Discover marks, then Expiration date, Security code, Country set to United States, and ZIP code. Below them a line explaining that your card information authorizes IOTFLOWS INC to charge future payments, an unchecked checkbox reading By clicking Submit, you have read and agree to the IoTFlows Terms of Use, and Cancel beside a dimmed Submit.](/images/admin/adm-bill-03.webp) *The Add Payment Card dialog, with the Stripe card fields, the Terms of Use checkbox that unlocks Submit, and Cancel and Submit along the bottom.* **You do not need a second card.** Stripe charges the *default card*, the single card marked to take the payment, and never the others. A second card is useful only as a replacement you intend to promote, or as a backup you would promote by hand if the first one failed. Adding a card does not promote it. ## Set the default card The default card carries a blue **Default** chip in the card list. 1. Select the three-dot menu at the top right of the card's row. 2. Select **Set as default**. A "Card has been set to default" toast confirms it, and the chip moves to the card you chose. Do this after adding a replacement card, or the old card keeps taking the charge. ## Remove a card **The web dashboard has no way to remove a card today.** The row menu offers **Set as default** and nothing else. Contact IoTFlows to take an old card off the account, through [support](/docs/get-started/get-support/#contact). Until then, add the new card and make it the default. The old card stays listed but is never charged. > **Info:** > **Leaving IoTFlows?** > > Leaving the account with no working card does not close it. It gets the organization [suspended](/docs/admin/suspended-account/), which stops data collection. Ask [support](/docs/get-started/get-support/#contact) to end the subscription instead. ## The current invoice The **Current Invoice** tab shows the period in progress under an **Upcoming invoice** heading, above the line "This is a preview of the invoice that will be billed on *date*. It may change if the subscription is updated." The table lists each line item with **DESCRIPTION**, **QTY**, **UNIT PRICE**, and **AMOUNT**, grouped under the billing period the item falls in, then totals as **Subtotal**, **Total**, and **Amount due**. Line items charging nothing are hidden, so a short table does not mean a missing charge. The tab renders one **Upcoming invoice** block per upcoming invoice, so more than one can appear. Read the date in each block's first line to tell them apart. Nothing here is payable by hand. The preview becomes an invoice at the end of the period, and the default card is charged automatically. ## Invoice history The **Invoices** tab lists issued invoices, newest first, three rows at a time. Each row carries the amount, the currency, a status chip, the invoice number, a description, the due date, and the date the invoice was created. Change the row count with the **Rows per page** control beneath the table: 3, 6, 9, 12, or **All**. ![The Invoices table with three rows. Each row shows a redacted amount, the currency usd, a colored status chip, an invoice number, a due date, and a created date. A violet box highlights the status column: two green Paid chips and one yellow Uncollectible chip.](/images/admin/adm-bill-04.webp) *The Invoices tab. Each row shows an amount, a status chip, an invoice number, and its dates. The chips on this account read Paid and Uncollectible.* ## Invoice statuses | Status | Means | Action available | |---|---|---| | **Paid** | Stripe charged the default card and the charge cleared. | None. Download the PDF for your records. | | **Open** | The invoice is issued and unpaid. It is either inside its payment window or past due. | Check the **DUE** date. If it has passed, confirm the default card is current, then contact [support](/docs/get-started/get-support/#contact). An open invoice left unpaid is what suspends an organization. | | **Draft** | The invoice is not issued yet and its amount can still change. | None. Wait for it to be issued. | | **Void** | The invoice was canceled and nothing is owed on it. | None. It stays listed for the record. | | **Uncollectible** | IoTFlows has written the invoice off as unpayable. | Contact [support](/docs/get-started/get-support/#contact) before doing anything else. Your organization is at or past suspension. | ## Download an invoice PDF 1. Open the **Invoices** tab. 2. Select the invoice row. 3. In the **Summary** panel that opens beneath the table, select **Invoice PDF**. The PDF opens in a new browser tab. If nothing happens, your browser blocked the pop-up; allow pop-ups for the dashboard and select it again. The **Summary** panel repeats the invoice number and its line items with quantities and unit prices, then **Subtotal**, any discount by coupon name, **Total**, and **Amount due**. A discount row appears only when a coupon applied to that invoice, so an invoice without one is not missing a row. ## See also - [Restore a suspended organization](/docs/admin/suspended-account/), if the lockout is already on screen - [Buy IoTFlows hardware](/docs/hardware/buy/), for devices and pricing questions - [Billing questions](/docs/get-started/faq/#billing), including plan changes and refunds - [Roles and permissions](/docs/admin/roles-reference/#owner-only), for what else only the Owner can do - [Contact support](/docs/get-started/get-support/#contact) --- # Invite people to your organization Source: https://www.iotflows.com/docs/admin/invite-members/ How to add people to an IoTFlows organization, by email or as an existing IoTFlows user. One dialog, Add Member, handles both and is reachable from the member directory at /members and from the members control in the dashboard header. Typing a complete email address offers an emailed invite; typing a name or username searches every IoTFlows account. Every invite carries an organization role, and the role list is served by IoTFlows. A pending invite shows in the directory as the invited email address followed by [Invite sent. Pending account creation] until the person creates their account. There is no resend action: to reissue an invite, remove the pending row and invite the address again. # Invite people to your organization Add someone by email, or add an existing IoTFlows user. **Prerequisite** Organization Owner or Organization Administrator. See [Roles and permissions](/docs/admin/roles-reference/#roles). An *invite* is a pending membership: the organization has reserved a place for an email address, and the person takes it up by creating an IoTFlows account against that address. Both paths, a new person and someone who already uses IoTFlows, run through one dialog called **Add Member**. You do not create accounts for other people, and there is no admin-managed password. ## 1. Invite by email Use this path when the person has never used IoTFlows. 1. Open **Members** at `/members`. 2. Select **Add Member**. 3. Type the person's full email address into the search field, which reads `Invite members via email or search by username or email`. 4. Select the **Invite** row that appears beneath the field, for example **Invite maria.lopez@northfield.com**. Until the address is complete the row reads **Keep typing full email** and does nothing. 5. Choose a role under **Select organization role for member**. 6. Select **Send invite**. The dialog closes and a message reads "Invite has been sent". IoTFlows emails the address with a link to create an account. The person must sign up with the same address the invite went to, see [Sign in to IoTFlows](/docs/get-started/sign-in/). ![The Add Member dialog with a full email address typed into the search field and staged as a line beneath it. Numbered callout 1 marks that staged address, and callout 2 marks Organization Member, the selected option in the four-way role list under the heading Select organization role for member, above Owner, Administrator and Observer. Cancel and Send invite sit at the bottom](/images/admin/adm-invite-01.webp) *Inviting by email. Invite operators as Members, not Observers.* > **Warning:** > **Already invited?** "This email is already a member or has a pending invite in this organization" means the address is already in the directory, either as a member or as an unaccepted invite. Check the directory for that address before sending a second one, see [Pending invites](#pending). ### Invite fields | Field | Required | Notes | |---|---|---| | Email address | Yes | Typed into the search field. Must be a complete, valid address. The invite is bound to this address, so the person cannot accept it with a different one. | | Organization role | Yes | Chosen from the radio list under **Select organization role for member**. **Send invite** stays disabled until one is selected. | ## 2. Add an existing user Use this path when the person already has an IoTFlows account, for example someone who works in a second organization on the same site. 1. Open **Add Member**. 2. Type their name, username, or email address into the search field. 3. Select **Add** on their row in the results, or hover the row and select **Add** on the card that opens. 4. Choose a role under **Select organization role for member**. 5. Select **Confirm Add**. The message reads "Member has been added". No email goes out and nothing is pending: they see the organization the next time they open IoTFlows. You do not choose between the two paths, the dialog chooses for you. One search field covers both, matching against every IoTFlows account, and it only offers to email an invite when the text you typed is a complete address that matched nobody. People already in this organization appear in the results as rows reading "Already a member of this organization", with no **Add** control. ## 3. Choose a role A *role* is the set of actions a person can take across the whole organization, and everyone has exactly one. Hover a role name in the dialog to read its description. The role list is served by IoTFlows, not built into the dashboard. **Add Member** fetches it each time it opens, so the names in front of you are authoritative. The four roles in use today are described in [Roles and permissions](/docs/admin/roles-reference/#roles). **Invite operators as Organization Member, not Organization Observer.** An Observer has read-only access and cannot classify downtime, and downtime classification is the one thing you need operators to do. Observer is for people who read reports and change nothing, such as a plant manager or a customer. A role is not a machine restriction. To hold someone to a subset of the fleet, give them a role and then set their machine access, see [Limit which machines a member can see](/docs/admin/machine-access/). ## 4. Pending invites An invited person has no IoTFlows account yet, so there is nothing to name their directory row after. IoTFlows gives the pending membership a placeholder *handle*, the short identifier every account carries, prefixed `inv_`. A pending invite shows in the directory as the invited email address in italics, followed in amber by `[Invite sent. Pending account creation]`, where a member would show a name and a username. The row still carries the person's role and the same controls as any other row. ![Three rows of the member directory. The first shows a member, with an avatar, a name, a username and the role Organization Owner beneath. The two rows under it are pending invites: each shows an email address in italics beside a silhouette avatar, followed by violet-highlighted amber italic text, in square brackets, Invite sent. Pending account creation, with Organization Administrator beneath](/images/admin/adm-invite-02.webp) *A pending invite shows the invited email address followed by [Invite sent. Pending account creation], where a member shows a name and username.* The same row appears inside **Add Member** when you search for that address, which is the fastest way to tell an unaccepted invite from a typo before you send another one. ## 5. Resend or cancel an invite **There is no resend action.** If an invite has not been accepted, first have the person check their spam folder for mail from IoTFlows and confirm the address on the directory row is the one they read. To reissue, cancel the pending invite and send a fresh one to the same address. To cancel a pending invite: 1. Open **Members** at `/members`. 2. Find the row for the invited address. 3. Select the trash icon at the right of the row. 4. Select **Confirm remove** in the **Remove member** dialog. The message reads "Member has been removed", and the address leaves the directory. To reissue after canceling, send a new invite to the same address from step 1 of [Invite by email](#email). ## 6. Invite from the header You do not have to be on the member directory to invite someone. The members control in the dashboard header holds two buttons: a stack of member avatars that opens `/members`, and an add-person icon beside it, tooltipped "Add members to this organization", that opens the same **Add Member** dialog in place. ![A cropped detail of the right end of the dashboard header. A bordered control holds two member avatars and the count 22, and a violet box highlights the add-person icon button immediately to its right. The theme switch, a megaphone, a settings gear and the account avatar follow](/images/admin/adm-invite-03.webp) *The same invite dialog, reachable from the header's add-person button beside the member avatar stack.* Use the header when you are in the middle of something else, for example assigning a work order and finding that the person you want is not in the organization. Use `/members` when you are inviting several people at once, because the directory shows you who is already there. ## See also - [Roles and permissions](/docs/admin/roles-reference/) - [Change roles and remove members](/docs/admin/manage-members/) - [Create and manage teams](/docs/admin/teams/) - [Limit which machines a member can see](/docs/admin/machine-access/) --- # Leave an organization Source: https://www.iotflows.com/docs/admin/leave-an-organization/ How to end your own membership in an IoTFlows organization, and what it costs you. The Leave organization row sits near the bottom of Organization Settings at /settings/organization and is there for every member whatever their role. Leave, then Confirm Leave, and IoTFlows reports "You left organization" and returns you to the dashboard home. An Organization Owner has to hand ownership to another member first, because an organization cannot be left without an Owner. Leaving costs you every asset, board, team, and chat scoped to that organization; your IoTFlows account and any other organization you belong to are untouched. There is no way back on your own: rejoining takes a fresh invite, and the new membership starts with access to all machines and no team or board memberships. # Leave an organization Remove yourself from an organization, and what you lose when you do. Leaving ends your membership in one organization, and nothing else. The control is the **Leave organization** row in Organization Settings, at `/settings/organization`, and it renders for every member whatever their role. **Before you start.** If you are the *Organization Owner*, the role that pays for IoTFlows, give another member that role first. See [Transfer ownership](/docs/admin/manage-members/#ownership) and [Owner-only actions](/docs/admin/roles-reference/#owner-only). An organization cannot be left without an Owner. ## Leave 1. Open Organization Settings from the gear icon in the dashboard header, or go to `/settings/organization`. 2. Scroll to the **Leave organization** row, below **Organization description**. 3. Select **Leave**. The row turns into a confirmation reading `Are you sure you want to leave Midwest Tooling organization?` 4. Select **Confirm Leave**. IoTFlows reports "You left Midwest Tooling organization", drops the organization from your switcher, and returns you to the dashboard home page. To back out before that, select **Cancel**. ![The bottom of the Organization card in Organization Settings, as a member who is not the Owner sees it. The Organization description row reads IoTFlows demonstration plant., and the Leave organization row sits directly below it, with a violet highlight around its Leave button](/images/admin/adm-leave-01.webp) *Leaving an organization. An Owner must transfer ownership first.* If the request fails, IoTFlows shows an error toast carrying the message the server sent back, and you are still a member. That toast is what an Owner who has not transferred ownership sees. > **Warning:** > **Still in the organization after you left?** > > Check the organization switcher. If the organization is still listed, the membership was not removed, and the likeliest reason is that you are the last administrator of something inside it. Ask an administrator to remove you instead: their dialog has [a second step](/docs/admin/manage-members/#last-admin) that settles what you administer, and the **Leave organization** row has none. ## What you lose Everything scoped to that organization: its assets and reports, its Scheduler and Maintain boards, its teams, and every chat that lives inside it. You keep your account, your profile, and any other organization, see [Switch between organizations](/docs/get-started/switch-organizations/). The full account of what stays behind, including your open work orders, which stay open and become unassigned, is in [What removal does](/docs/admin/manage-members/#after-removal). Leaving is not the same as being removed by an administrator, but the result for your access is identical. If you might come back, ask an administrator to change your role instead, for example to Organization Observer, which keeps the membership and the settings attached to it. Compare the roles in [What each role can do](/docs/admin/roles-reference/#matrix). ## Rejoining There is no self-serve way back in. An Owner or Administrator has to [invite you again](/docs/admin/invite-members/), and the invite builds a new membership rather than restoring the old one. Two things do not come with it: - **Machine access resets to every machine.** Any [restriction](/docs/admin/machine-access/) that was set on your old membership is gone and has to be set again. - **Team and board memberships are gone.** Someone has to add you back to each one by hand. ## See also - [Change roles and remove members](/docs/admin/manage-members/) - [Switch between organizations](/docs/get-started/switch-organizations/) - [Roles and permissions](/docs/admin/roles-reference/) - [Invite people to your organization](/docs/admin/invite-members/) - [Contact IoTFlows](/docs/get-started/get-support/) --- # Limit which machines a member can see Source: https://www.iotflows.com/docs/admin/machine-access/ How to restrict an IoTFlows member to specific machines. Machine access is a per-person list of allowed assets, managed from the member directory at /members: each member row carries a control that reads All machines when the list is empty, or a stack of machine avatars when it is not. Opening it shows the Machine access dialog, where tapping a machine grants or revokes it immediately, with no Save step. An empty list is the default and means the member sees every machine. A restriction narrows everything, including the machine pickers on reports and work orders, so a member reporting that a machine disappeared has usually been restricted. Only an Organization Owner or Administrator can see or change the control. # Limit which machines a member can see Grant a member access to specific machines instead of the whole fleet. **You need to be an Organization Owner or Organization Administrator.** Everyone else does not see the control at all. See [Roles and permissions](/docs/admin/roles-reference/#roles). *Machine access* is a per-person list of the machines someone is allowed to see. Each machine on that list is an *allowed asset*. The list is empty by default, and an empty list means no restriction: the member sees every machine in the organization. You do not need machine access if everyone should see everything. It is a restriction, not a requirement, and an organization that never touches it is configured correctly. ## What machine access controls Machine access is managed from the member directory at `/members`. Each member row carries a control between the person's role and the pencil icon: | What the control shows | What it means | |---|---| | **All machines**, on a dashed pill with a globe | The list is empty. This member sees the whole fleet | | Up to three machine avatars, then a count of the rest, such as `+4` | The member is restricted to those machines | The restriction applies everywhere, not only to the [Assets page](/docs/monitoring/assets-overview/). It narrows the machine pickers too, so a restricted member cannot choose an off-list machine when building a report or creating a work order. Machine access never adds a permission. It can only take machines away from what the person's role already allows. ## Grant access to specific machines 1. Go to `/members`. 2. Find the member's row and select the machine-access control on it. The **Machine access** dialog opens, with that person's name, username, and email at the top. 3. Use **Search machines** to find a machine by name or by identifier, or scroll the list. 4. Select each machine the person should see. A selected machine gets a blue check and the list header counts it, for example `Machines · 4/27 selected`. 5. Select **Done**. ![The Machine access dialog, opened from a member row. The member's avatar, name, username, and email sit at the top, above a blue note marked 1 reading Access restricted to 4 selected machines. Deselect all to grant access to every machine. Below it a Search machines field, a list header reading Machines · 4 of 27 selected, and a scrolling list of machines, each with a photo, a name, an identifier, and a circle on the right. A block of four consecutive rows, marked 2, is highlighted blue with a filled blue check. Close and Done sit at the bottom](/images/admin/adm-access-01.webp) *Granting a member access to specific machines.* > **Info:** > **Is there a Save button?** > > No. Each machine saves the moment you select it, and a toast confirms it: "Access to Haas VF-2 granted". **Close** and **Done** do the same thing, which is to close the dialog. Closing it does not discard anything. Grant machine access by cell, not by a person's current assignment. An operator restricted to one machine files a support ticket every time they cover for someone, and the administrator ends up granting the whole fleet anyway. Restrict a press operator to the six presses in their cell, not to the one press they ran last week. If a grant fails, the toast reads "Failed to update machine access" and the machine goes back to unselected, because nothing was saved. Try it again, and if it keeps failing, [contact IoTFlows](/docs/get-started/get-support/). ## Revoke access 1. Open the **Machine access** dialog on the member's row. 2. Select a machine that is already highlighted. The check clears, and the toast reads "Access to Haas VF-2 revoked". ![A cropped detail of the Machine access list. One row is mid-revoke: its blue highlight has cleared and a small spinner sits where the blue check was. The rows above and below it stay highlighted blue with filled checks](/images/admin/adm-access-02.webp) *Revoking access to one machine.* To lift the restriction entirely, deselect every machine. The note at the top of the dialog switches to "No machines selected. This member can access all machines", and the directory row goes back to reading **All machines**. Removing a member is a different job, and it removes their access to everything rather than narrowing it. See [Change roles and remove members](/docs/admin/manage-members/#remove). ## How access interacts with roles A role says what someone can do. Machine access says which machines they can do it to. The two are set separately and both apply. | Role | Machine access | |---|---| | Organization Owner | Can be restricted, but do not. The Owner is the billing and ownership role and needs the whole fleet | | Organization Administrator | Can be restricted. Administrators still manage machine access for everyone, including themselves | | Organization Member | The usual target. A Member restricted to `Haas VF-2` classifies downtime there and cannot see `Brother S700X1` | | Organization Observer | Can be restricted. Read-only on a shorter list | Changing someone's role does not change their machine access, and clearing their machine access does not change their role. A Member promoted to Administrator keeps the same four machines until you clear the list. For what each role can do, see [Roles and permissions](/docs/admin/roles-reference/#matrix). ## What a restricted member sees A restricted member sees a smaller fleet, with no indication that anything was filtered out. There is no banner, no count of hidden machines, and no request-access control. ![The Assets page as a member restricted to four machines. Four machine cards fill a grid that holds twenty-seven for an unrestricted member, and the tiles above them — uptime, utilization, downtime, and 3 of 4 machines producing — are computed from those four only. Nothing on the page states that machines are hidden](/images/admin/adm-access-03.webp) *What a restricted member sees. A machine that 'disappeared' is usually this.* A machine that "disappeared" is the first report you will get, and a machine missing from a report or work-order picker is the second. Both have the same cause, so check machine access before you treat either as a data problem. Open the member's row at `/members` and read the machine-access control. If it shows a stack of avatars rather than **All machines**, the machine was not lost. For everything else that makes a machine look wrong, see [Troubleshoot monitoring](/docs/monitoring/troubleshoot-monitoring/#start). ## See also - [Roles and permissions](/docs/admin/roles-reference/) - [Change roles and remove members](/docs/admin/manage-members/) - [Assets overview](/docs/monitoring/assets-overview/) - [Review the organization audit log](/docs/admin/audit-log/) --- # Change roles and remove members Source: https://www.iotflows.com/docs/admin/manage-members/ How to work the IoTFlows member directory at /members: one search field covering teams and members, the row controls that change a role and remove someone, and what removal leaves behind. Changing a role opens the Edit member role dialog and reports "Member role changed to" the new role. Removing opens the Remove member dialog, and if the person is the last administrator of something inside the organization, a second step asks whether to keep or delete what they administer. A removed member loses access to everything, and their open work orders stay open and become unassigned. The dashboard has no dedicated transfer-ownership control: ownership moves by setting another member's role to Organization Owner. # Change roles and remove members Change what someone can do, take their access away, or hand the organization to someone else. **Prerequisite** Organization Owner or Organization Administrator. See [Roles and permissions](/docs/admin/roles-reference/#roles). Ownership transfer is Owner only. The *directory* is the member list at `/members`. It carries every person in the organization and every team, and it is where roles change and memberships end. Adding people is a separate task, see [Invite people to your organization](/docs/admin/invite-members/). ## 1. The directory Open **Members** at `/members`. The page holds two panels: **Teams** above, **Members** below. The Teams panel is a table with three columns, **Name**, **Handle**, and **Members**. Selecting a team opens it, see [Create and manage teams](/docs/admin/teams/). The Members panel is one row per person. Each row shows an avatar, the person's name, their public username in italics, and their organization role beneath. A row for an invite nobody has accepted yet reads differently: the invited email address in italics, followed in amber by `[Invite sent. Pending account creation]`, and no role line. See [Pending invites](/docs/admin/invite-members/#pending). Three controls sit at the right of every member row. ![The Members page at /members. A search field across the top reads Search teams and members or invite via email. Below it a Teams panel lists three teams in a table with Name, Handle, and Members columns and a Create Team control. Beneath that a Members panel lists twelve rows, each carrying an avatar, an organization role, a machine-access chip, a pencil, and a trash icon. Ten rows show a name and a public username; two show an email address followed by an amber note reading Invite sent. Pending account creation](/images/admin/adm-members-01.webp) *The directory searches teams and members together.* ### Row actions | Action | Who can | Reversible | Effect | |---|---|---|---| | Machine access chip, reading **All machines** or showing the machines they are scoped to | Owner or Administrator. The chip does not render for anyone else | Yes | Opens the machine-access dialog for that person. See [Limit which machines a member can see](/docs/admin/machine-access/) | | Pencil | Owner or Administrator | Yes, change the role again | Opens **Edit member role**. See [Change someone's role](#role) | | Trash | Owner or Administrator | No, you re-invite and get a new membership | Opens **Remove member**. On a pending row this cancels the invite. See [Remove a member](#remove) | > **Info:** > **Why can I see these controls without an admin role?** > > The machine-access chip is the only row control the dashboard hides from non-admins. The pencil and the trash render for every signed-in member, and IoTFlows enforces the role when the request reaches the platform. Treat the [permission matrix](/docs/admin/roles-reference/#matrix) as the rule, not the controls you happen to see. ## 2. Search members and teams One field at the top of the page filters both panels at once. It reads `Search teams and members or invite via email`. Type any part of a first name, last name, public username, or email address to filter the Members panel. Type any part of a team name or team handle to filter the Teams panel. Searching `line 2` narrows both: teams whose name contains it, and nobody in the member list unless a name matches. Matching members appear under the heading **In this organization**. When nothing matches, the panel reads `No members match "line 2"` or `No teams match "line 2"`. The search covers this organization only. To find someone who already uses IoTFlows but is not a member yet, open **Add Member** and search there instead, see [Add an existing user](/docs/admin/invite-members/#existing). ## 3. Change someone's role 1. Open **Members** at `/members`. 2. Find the person, using the [search field](#search) if the list is long. 3. Select the pencil at the right of their row. 4. Under **Organization Roles**, select a role. Hovering a role name shows its description. 5. Select **Edit role**. The dialog closes and a message reads "Member role changed to Organization Administrator", naming the role you picked. The new role applies immediately: the person does not sign out and back in. IoTFlows serves the role list, so the options in this dialog come from the platform rather than from your organization. What each one can do is in [Roles and permissions](/docs/admin/roles-reference/#matrix). ![The Edit member role dialog, showing one member's avatar, public username, and email at the top. A violet highlight surrounds the radio list headed Organization Roles, with Organization Owner, Organization Administrator, Organization Member, and Organization Observer, and Organization Administrator selected. Cancel and Edit role sit at the bottom](/images/admin/adm-members-02.webp) *Changing a role. Change the role rather than removing and re-inviting.* Change a role rather than removing someone and re-inviting them. Re-inviting creates a new membership, and everything tied to the old one, work orders, board memberships, machine access, and chat history, has to be rebuilt by hand. Changing the role keeps the membership and swaps only what it can do. Choose a role change over a removal whenever the person stays on site. A supervisor who now adds machines moves from Member to Administrator. A seasonal contractor who should read reports and change nothing moves to Observer. An operator who cannot classify downtime is almost certainly an Observer, see [Which role for an operator?](/docs/admin/roles-reference/#roles) ## 4. Remove a member Removal ends the membership. Do the two things below first, because neither is recoverable from the directory afterwards. > **Warning:** > **Before you remove anyone** > > Reassign their open work orders. Removal leaves those work orders open and unassigned, and an unassigned work order is one nobody is watching. > > Reassign from the work order itself, see [Update, discuss, and close a work order](/docs/maintain/work-order-detail/). Then check whether they own anything only they administer, which the dialog asks about in step 5 below. 1. Open **Members** at `/members`. 2. Find the person. 3. Select the trash at the right of their row. 4. In the **Remove member** dialog, check the name, username, and email against the person you meant. Select **Confirm remove**. 5. If a second step appears, answer it. See [If they are the last administrator](#last-admin). A message reads "Member has been removed" and the row leaves the directory. ![The Remove member dialog, headed Remove member, showing one member's avatar, full name, public username, and email address. Cancel sits at the bottom left and Confirm remove at the bottom right](/images/admin/adm-members-03.webp) *Removing a member.* On a row that still reads `[Invite sent. Pending account creation]`, this same dialog is how you cancel the invite. The wording does not change, so the dialog says "Remove member" and reports "Member has been removed" about an address that never accepted. ### If they are the last administrator If the person is the only administrator of something inside the organization, **Confirm remove** does not finish. The dialog swaps to a second step reading `Maria Lopez is the last administrator of at least one resource in this organization.` and asks **Would you like to:** with two options. | Option | What it does | Choose it when | |---|---|---| | **Keep resources and remove member** | Removes the membership and leaves everything they administered in place | Almost always. The resources stay, and you give someone else administrative access to them afterwards | | **Delete all resources and member** | Removes the membership and deletes everything they were the last administrator of | You are cleaning up a test membership, or you have confirmed nobody relies on those resources | Select one, then select **Confirm**. The message is the same, "Member has been removed". Default to **Keep resources and remove member**. Deleting is not reversible from this dialog, and the dialog does not list what it is about to delete. Something nobody noticed this person administered is how a plant loses a setting it was relying on. ## 5. Transfer ownership The *Owner* is the role that pays for IoTFlows and the only one that can hand the organization over. Every organization has at least one, see [Owner-only actions](/docs/admin/roles-reference/#owner-only). The dashboard has no button labelled Transfer ownership. Ownership moves through the role dialog: the current Owner gives another member the **Organization Owner** role, using the steps in [Change someone's role](#role), and then takes **Organization Administrator** for themselves. An Administrator has the same authority minus billing, so the person handing over loses nothing else. ![The Edit member role dialog for a second member, showing their avatar, name, public username, and email. A violet highlight surrounds Organization Owner at the top of the Organization Roles radio list, and its radio is selected](/images/admin/adm-members-04.webp) *Transferring ownership. An Owner cannot leave without doing this first.* Transfer ownership before the current Owner's last day, not after. An Owner cannot leave the organization while they are the only Owner, and an organization whose Owner has gone cannot pay an invoice or clear a suspension. If that has already happened, [contact IoTFlows](/docs/get-started/get-support/). ## 6. What removal does Removal is total. The person loses the organization everywhere it appears: the web dashboard, the mobile app, every board, every team, and every chat inside it. They keep their IoTFlows account and any other organization they belong to, see [Switch organizations](/docs/get-started/switch-organizations/). What the organization keeps: - **Their work orders stay open and become unassigned.** The work is not deleted and not closed. Nobody owns it, and nothing in the product flags it, which is why reassigning before removal matters. - **Their history stays.** Downtime they classified, jobs they ran, and comments they wrote are still attributed to them. - **Whatever they administered stays**, unless you chose **Delete all resources and member** at [the last-administrator step](#last-admin). - **The removal is recorded.** See [Review the organization audit log](/docs/admin/audit-log/). What does not come back: - **Machine access.** A membership you re-create starts with access to all machines, and any [restriction](/docs/admin/machine-access/) you had set is gone. - **Team membership and board membership.** Re-add them by hand. - **The membership itself.** Re-inviting creates a new one, which is the whole reason to change a role instead. > **Info:** > **Someone says a machine disappeared** > > That is usually a machine-access change rather than a removal, because a restricted member keeps their sign-in and only loses the machines. See [Limit which machines a member can see](/docs/admin/machine-access/). ## See also - [Roles and permissions](/docs/admin/roles-reference/) - [Limit which machines a member can see](/docs/admin/machine-access/) - [Create and manage teams](/docs/admin/teams/) - [Invite people to your organization](/docs/admin/invite-members/) - [Review the organization audit log](/docs/admin/audit-log/) --- # Set your organization name, logo, and handle Source: https://www.iotflows.com/docs/admin/org-profile/ How an IoTFlows organization appears to its members and to anyone they chat with. The logo, name, description, and handle all live in the Organization section at /settings/organization, behind an Edit button, and save together with Save. The logo is the exception: it opens a crop dialog and uploads on its own. The handle is the unique short name for the organization and the second half of every member's chat address, in the form username:orghandle. The field accepts lowercase letters, digits, and underscores, and checks availability half a second after you stop typing, but nothing blocks Save on a taken handle. Changing the handle rewrites every member and team chat address, so people outside the organization who saved the old one can no longer find you. # Set your organization name, logo, and handle How your organization appears to your members, and to anyone you chat with. The *organization profile* is the four fields that identify your company across IoTFlows: a logo, a name, a description, and a *handle*, the unique short name other organizations use to reach your people in chat. All four sit in the **Organization** section at the top of Organization Settings, at `/settings/organization`. [Shifts and the organization timezone](/docs/admin/shifts-and-timezone/) are on the same screen, further down. **Before you start.** You need to be an *Organization Owner* or an *Organization Administrator*. See [Roles and permissions](/docs/admin/roles-reference/). The section is read-only until you select **Edit** at its top right. **Edit** unlocks the name, description, and handle together, and one **Save** commits all three. The logo is the exception: it opens its own dialog and uploads on its own. ## Upload a logo 1. Select **Edit** at the top right of the **Organization** section. The logo tile does nothing until you do. 2. Select the logo tile. Your file picker opens. 3. Choose an image. IoTFlows takes any format the browser reads, plus `.heic` and `.heif` from an iPhone, which it converts to JPEG first. 4. Drag the image inside the crop frame, and set the **Zoom** and **Rotation** sliders until the square holds what you want. 5. Select **Preview**. To change the crop, select **Back**. 6. Select **Submit**. An "Organization logo updated" toast confirms the upload and the dialog closes. IoTFlows crops to the square you set and compresses the result to WebP at around 500 KB, so a 12 MB photo straight off a phone is fine. ![The Organization section of Organization Settings in edit mode, with Cancel and Save at the top right in place of Edit. Callout 1 marks the square organization logo tile, callout 2 marks the Organization name field reading IoTFlows, and callout 3 marks the Organization description field reading IoTFlows demonstration plant. The Organization handle row sits between the logo and the name, and a Delete entire organization row and a Leave organization row sit below the description.](/images/admin/adm-org-01.webp) *The Organization section of Organization Settings, with numbered callouts on the logo tile, the Organization name field, and the Organization description field.* Use a square mark rather than a full wordmark. The logo renders at roughly 24 px in the organization switcher and in the organization lists in chat, and text that small is unreadable. If the dialog stays open after **Submit** and no toast appears, the upload failed. This failure is silent, so nothing else tells you. Select **Submit** again, and if it fails twice, [contact IoTFlows](/docs/get-started/get-support/). ## Set the name The name is what members read in the organization switcher, and what people in other organizations see next to your logo when they search for someone in chat. 1. Select **Edit**. 2. Type the name into **Organization name**, for example `Midwest Tooling`. 3. Select **Save**. An "Organization modified" toast confirms it. Nothing checks the name against other organizations, so two companies can carry the same one. The handle is the field that has to be unique. Renaming is safe: the name is in no URL and no report points at it. ## Add a description The description is one optional line of free text. 1. Select **Edit**. 2. Type into **Organization description**, for example `Progressive die stamping, Sterling Heights`. 3. Select **Save**. **You do not need this.** No screen in the web dashboard reads the description back out, so it is a note on the organization record rather than something your members see. Fill it in if you run several organizations and want the record to say which plant is which. ## Change the handle The handle is the second half of every member's chat address. If your handle is `midwesttooling`, a member whose username is `jsmith` is reachable at `jsmith:midwesttooling`. 1. Select **Edit**. 2. Type the new handle into **Organization handle**. The field lowercases what you type and drops anything that is not a letter, a digit, or an underscore, so `Midwest Tooling!` leaves `midwesttooling`. 3. Wait half a second. IoTFlows checks the handle and marks the field with a green check if it is free, or a red exclamation icon if another organization already holds it. 4. Select **Save** once the icon is green. ![A cropped detail of the Organization handle row in edit mode. The focused field reads midwesttooling, and a green check circle sits immediately to the right of it, highlighted. The Organization name row, reading IoTFlows, sits below it for contrast.](/images/admin/adm-org-02.webp) *The Organization handle field being edited. The icon to the right of the field is the availability check, green for free and red for taken.* > **Warning:** > **Why read the icon before saving?** > > **Save** is blocked neither while the check is running nor when the icon is red: the dashboard sends whatever is in the field. The check is advice. Type, pause, look at the icon, then save. To hand your handle to someone, hover the handle row when the section is not in edit mode and select the copy icon that appears beside it. An "Organization handle copied!" toast confirms the copy. If your browser blocks clipboard access you get "Clipboard not supported" or "Failed to copy handle:" instead, and you can select the text and copy it by hand. **Choose a handle you will not want to change.** It is how people outside your organization find you in chat, and the old one stops working the moment you change it. ## What changing the handle breaks The warning icon beside the **Organization handle** label spells this out. Read it before you commit. ![A cropped detail of the Organization handle row with the warning tooltip open above it. The warning icon beside the Organization handle label is highlighted. The amber panel reads that changing this organization handle will update it for every user in the organization, that all message and chat handles will also change, and that this may cause issues for external users trying to find you with the previous handle, and closes with an italic example line reading Example with current organization handle, user:iotflows.](/images/admin/adm-org-03.webp) *The warning on the Organization handle label: changing the handle changes it for every member, and rewrites every chat handle with it.* Changing the handle rewrites the chat address of every member and every team in one step. `jsmith:midwesttooling` becomes `jsmith:mwtooling`, and so does everyone else's. That is only a problem outside your organization. Your own members find each other by name in the [member directory](/docs/admin/manage-members/) and in chat, and never type a handle to do it. People in other organizations do type it. Chat search looks up the exact address, so a supplier who saved `jsmith:midwesttooling` gets no match after the change, with no forwarding and no hint that the address moved. Send your external contacts their new addresses yourself. Nothing else points at the handle. Dashboard URLs carry the organization's UUID, so bookmarks and links you have pasted into email keep working. ## Organization fields | Field | Required | Visible to | Changing it breaks | |---|---|---|---| | **Organization logo** | No | Your members, in the organization switcher; anyone who sees your organization in a chat search | Nothing | | **Organization name** | Yes | Your members, in the organization switcher; anyone who sees your organization in a chat search | Nothing | | **Organization description** | No | Nobody, on any screen in the web dashboard | Nothing | | **Organization handle** | Yes | Everyone on IoTFlows, as the second half of every member and team chat address | Every saved chat address anyone outside your organization holds for your people | Apart from the handle's character filter, the browser validates none of these fields. If **Save** fails, the dashboard shows the error the API returned and closes edit mode without keeping your change; reopen **Edit** and try again. ## See also - [Define shifts and your timezone](/docs/admin/shifts-and-timezone/), the other half of the same settings screen - [Update your profile and handles](/docs/admin/profile/), where each member sets the username in front of the colon - [Start a chat](/docs/messaging/start-a-chat/), where handles get used - [Overview: administer your organization](/docs/admin/overview/) --- # Overview: administer your organization Source: https://www.iotflows.com/docs/admin/overview/ What an IoTFlows administrator owns and where each setting is documented. Four things constrain what a person can do: the organization they belong to, their role, their machine access, and the boards they are on. Settings live on three screens, Organization Settings at /settings/organization with its Settings and Webhooks tabs, your account at /settings/user, and billing at /settings/billing, which only the Organization Owner can open. Three Organization Settings sections are documented under the job they serve instead: auto-downtime rules, operator stations, and webhooks. Set the time zone and shifts before anyone reads a report; everything else can be changed later. # Overview: administer your organization What an administrator owns, and where each setting is documented. An *organization* is the container IoTFlows creates for your company. Every machine, member, team, board and report belongs to exactly one, and nothing is shared across two. IoTFlows creates it for you: there is no self-serve signup, so start at [Quickstart: set up a new organization](/docs/admin/quickstart/) once yours exists. **Before you start.** Almost everything on this page needs one of two roles. An *Organization Owner* is the role IoTFlows bills and the only one that can hand the organization to someone else. An *Organization Administrator* has the same authority minus billing and ownership. See [Roles and permissions](/docs/admin/roles-reference/). ## What an admin owns Four things, and each one narrows the next. Diagram: A diagram of one large box labeled Organization, created by IoTFlows, holding everything else. Inside it a tall box on the left reads Member, one person, one role. Three arrows leave it. The first points to Role, Owner, Administrator, Member or Observer, annotated what they can do, anywhere in the organization. The second points to Machine access, a list of machines, annotated which machines they can do it to, and an empty list means every machine. The third points to Team, a named group of members, which points on to Board, a Scheduler or Maintain board, annotated a board carries its own Owner and Member roles, on top of the organization role. *Organization, members, teams, boards and machine access, and how they constrain each other.* **People.** You [invite someone](/docs/admin/invite-members/), give them a role, and later [change that role or remove them](/docs/admin/manage-members/). One person holds one role in one organization. **Machine access.** A role says what a person can do; machine access says which machines they can do it to. An empty list means every machine, which is the default. See [Roles and machine access](/docs/admin/roles-reference/#machine-access). **Teams and boards.** A *team* is a named group you add to boards in one go. A Scheduler or Maintain *board* carries its own Owner and Member roles on top of the organization role, so an Administrator is not automatically the owner of every board. See [Create and manage teams](/docs/admin/teams/). **How the organization measures time.** The organization time zone and your work shifts decide which shift a stop lands in and which day it is reported on. > **Warning:** > **What has to be right on day one?** > > Set the time zone and shifts before anyone reads a report. Both are used to bucket data as it arrives, so correcting them later does not re-bucket the history you already collected. Every other setting on this page can be changed at any time without invalidating what is already recorded. See [Define shifts and your time zone](/docs/admin/shifts-and-timezone/). ## The settings screens Three screens hold what is labeled "settings". Everything else an admin owns lives on the page for the thing it configures. **Organization Settings**, at `/settings/organization`, opened by the gear icon at the top right of the header. It has two tabs, **Settings** and **Webhooks**. **Your account**, at `/settings/user`. Your avatar, username, per-organization handles, phone number and two-step authentication. It follows you across every organization you belong to. **Billing**, at `/settings/billing`. Organization Owner only. ### Settings router | Setting | Screen | Documented at | |---|---|---| | Name, logo, description, handle | Organization Settings, **Settings** tab | [Set your organization name, logo, and handle](/docs/admin/org-profile/) | | Time zone and work shifts | Organization Settings, **Schedules** | [Define shifts and your time zone](/docs/admin/shifts-and-timezone/) | | Auto-downtime rules and scheduled breaks | Organization Settings, **Auto-Downtime Classifications** | [Classify downtime automatically](/docs/monitoring/auto-downtime-rules/) | | Operator station pairing | Organization Settings, **Assign to Local Device** | [Set up a dedicated operator station](/docs/monitoring/operator-stations/) | | Webhooks | Organization Settings, **Webhooks** tab | [Send events to your own endpoint](/docs/alerts/webhooks/) | | Leaving or deleting the organization | Organization Settings, **Settings** tab | [Leave an organization](/docs/admin/leave-an-organization/) | | Invites, roles, removals, ownership | Member directory, `/members` | [Invite people](/docs/admin/invite-members/), [change roles and remove members](/docs/admin/manage-members/) | | Machine access | Member directory, `/members` | [Limit which machines a member can see](/docs/admin/machine-access/) | | Teams | Member directory, `/members` | [Create and manage teams](/docs/admin/teams/) | | Sensors, firmware, calibration | Devices, `/devices` | [View and manage your devices](/docs/hardware/view-devices/) | | Chat integrations | Integrations, `/integrations` | [Send alerts to Slack, Teams, or Discord](/docs/alerts/chat-integrations/) | | Which events alert whom | The bell on a machine's page | [Set alert rules for a machine](/docs/alerts/asset-event-rules/) | | Downtime categories | The **Classify Downtime** modal, or Organization Settings | [Manage downtime categories](/docs/monitoring/downtime-categories/) | | Status colors and downtime thresholds | Assets page, the **Utilization** tile | [Set status colors and downtime thresholds](/docs/monitoring/status-colors/) | | Uptime goals | Assets page, the **Utilization** tile | [Set OEE and utilization goals](/docs/monitoring/oee-goals/) | | Payment cards and invoices | Billing, `/settings/billing` | [Manage payment methods and invoices](/docs/admin/billing/) | | Your avatar, phone number, two-step auth | Your account, `/settings/user` | [Update your profile](/docs/admin/profile/) | | Who changed what | Logs, `/logs` | [Review the audit log](/docs/admin/audit-log/) | ## Settings documented under the job they serve Three sections of Organization Settings are not documented here. Each configures one job, and you reach it while doing that job rather than while administering the organization: - **Auto-Downtime Classifications** puts reasons on short stops and scheduled breaks without asking an operator. See [Classify downtime automatically](/docs/monitoring/auto-downtime-rules/). - **Assign to Local Device** pairs a shared tablet or PC to one machine so it boots straight into that machine. See [Set up a dedicated operator station](/docs/monitoring/operator-stations/). - The **Webhooks** tab posts machine events to a URL you own. See [Send events to your own endpoint](/docs/alerts/webhooks/). You do not need any of the three to run IoTFlows. Reach for auto-downtime rules once operators complain about classifying the same two-minute stop every hour, for an operator station once a machine has a dedicated screen beside it, and for webhooks only when you are feeding another system. ## What only the Owner can do Four actions are Owner-only. An Administrator gets "Only organization owners can access this page." on the billing page, which is where three of them start. | Action | Where | |---|---| | Open billing, add a card, pay an invoice | [Manage payment methods and invoices](/docs/admin/billing/) | | Clear a suspension | [Restore a suspended organization](/docs/admin/suspended-account/) | | Transfer ownership | [Change roles and remove members](/docs/admin/manage-members/) | | Delete the organization | Organization Settings, **Settings** tab | Plan for the consequence. A suspended organization puts every member behind a modal whose only action goes to billing, so if your one Owner has left the company, nobody left can clear it. Transfer ownership before they go, or [contact support](/docs/get-started/get-support/). See [Owner-only actions](/docs/admin/roles-reference/#owner-only). ## How IoTFlows protects your data - [Security](https://www.iotflows.com/company/security) — Outbound-only connections on port 443, encryption from the sensor to the cloud, and who can see what. ## See also - [Quickstart: set up a new organization](/docs/admin/quickstart/) - [Roles and permissions](/docs/admin/roles-reference/) - [Define shifts and your time zone](/docs/admin/shifts-and-timezone/) - [Classify downtime automatically](/docs/monitoring/auto-downtime-rules/) --- # Change your phone number Source: https://www.iotflows.com/docs/admin/phone-number/ How to add or change the phone number on your IoTFlows account, and why an account without one cannot receive SMS alerts. The number lives on your account rather than on an organization, so one number follows you into every organization you belong to. Select Edit in the Profile section at /settings/user, then Edit Phone Number, pick the country from the flag dropdown, type the rest of the number and Submit. IoTFlows texts a code; type it into Verification code and select Verify. Your profile is only written when the code is accepted, so abandoning the dialog at the code step leaves the old number in place. There is no resend button: select Back and submit the number again. The SMS subscriber list on an alert rule reads this field, so a member without a number is listed as No phone number and cannot be added. # Change your phone number Add or change the number IoTFlows sends SMS alerts and verification codes to. Your number sits on your IoTFlows account, not on an organization, so one number follows you into every organization you belong to. Changing it takes two steps in one dialog: submit the number, then type back the code that arrives by SMS. **Before you start.** Sign in, and have a phone that can receive SMS in your hand. > **Info:** > **Do you need a number if you never want texts?** Add one anyway. A member with no number shows as **No phone number** in an alert rule's [SMS subscriber list](/docs/alerts/asset-event-rules/#subscribers) and cannot be selected; whoever tries is told **This user has not added their phone number**. That error reaches them rather than you, so the failure is invisible from your side. ## Enter the new number 1. Go to **Settings → Profile** at `/settings/user`. 2. Select **Edit** at the top right of the **Profile** heading. The **Phone Number** field never takes typing; **Edit** only reveals the button beside it. 3. Select **Edit Phone Number**. On a narrow screen the button reads **Edit**. 4. In the **Update phone number** dialog, pick your country from the flag dropdown. It opens on the United States, so the field starts at **+1**. 5. Type the rest of the number, with no country code and no leading zero. A Detroit number on the **+1** flag is `313 555 0142`. 6. Select **Submit**. IoTFlows texts a code to that number and the dialog moves to its second step. If it reports **Phone number update request failed.**, the number was rejected and no text was sent. If **Submit** instead keeps spinning with no message at all, the request failed in a way the dialog cannot report: select **Cancel**, reopen it, and read the digits back against the country you picked. **Cancel** backs you out at any point before you verify. ![The Update phone number dialog, cropped to the panel. A country flag dropdown showing the United States flag sits at the left of the field, the number +1 (313) 555-0142 fills the rest, and Cancel and Submit buttons sit along the bottom edge](/images/admin/adm-phone-01.webp) *The Update phone number dialog, with the country flag dropdown set to the United States and a new number typed into the field.* ## Verify the code 1. Type the code from the SMS into **Verification code**. 2. Select **Verify**. IoTFlows reports **Phone number updated successfully**, closes the dialog, and the new number appears in the **Phone Number** field. A wrong or expired code reports **Phone number verification failed** and leaves the dialog open, so you can retype it. **Nothing is saved until the code is accepted.** Closing the dialog at the code step leaves the old number on your profile, and SMS alerts keep reaching the old handset. The **Save** and **Cancel** buttons in the **Profile** heading have no part in this: the dialog writes the number on its own. ![The second step of the Update phone number dialog, cropped to the panel. A single empty field labelled Verification code sits under the Update phone number title, with a Back button at the bottom left and a dimmed Verify button at the bottom right](/images/admin/adm-phone-02.webp) *The verification code step of the Update phone number dialog. Until a code is accepted your profile keeps the old number, and without a number on your profile you cannot be added as an SMS alert subscriber.* ## If the code does not arrive There is no resend button. Select **Back**, which clears the field, then type the number again and **Submit**. That sends a fresh code. Check these before you retry: - **The country code.** The flag dropdown supplies it, so typing it again sends the code to `+1 1 313…`, which is nobody. - **A leading zero.** Trunk prefixes, like the `0` in a UK mobile number, belong to domestic dialing and not to the number you submit here. - **The line type.** A desk extension, a landline, or a VoIP number that does not carry SMS never receives the code. Use a mobile. - **Carrier filtering.** Automated codes are a common target. Check the phone's blocked or spam folder, and try a different handset if your carrier is silently dropping them. The code is sent by the sign-in service IoTFlows authenticates against, not by IoTFlows, and the dialog reports none of that service's failures. If several attempts in a row produce no text and no message, leave it a few minutes before the next one. Once a number is on your account there is no way to remove it. Replace it by running these same two steps with a different number. ## See also - [Set alert rules for a machine](/docs/alerts/asset-event-rules/#subscribers), where the SMS subscriber list reads this number - [Troubleshoot alerts you did not receive](/docs/alerts/troubleshoot-alerts/#sms), what to check when an SMS alert does not arrive - [Update your profile and handles](/docs/admin/profile/), the rest of the settings on this screen - [Turn on two-step authentication](/docs/admin/two-step-auth/), the other account security setting --- # Update your profile and handles Source: https://www.iotflows.com/docs/admin/profile/ How to change your avatar, username, name and per-organization handles at /settings/user. Everything in the Profile section belongs to your account and follows you into every organization, so a new photo or a corrected last name reaches all of them at once. Select Edit before anything on the screen accepts a change, then Save, which reports User information updated. The avatar opens an Edit Profile Picture dialog with a square crop box, Zoom and Rotation sliders, a Preview step and a Submit that reports Profile picture updated. Handles are the exception to the account rule: you carry a separate one in each organization, written you:organization, each with its own availability check, and colleagues search by handle to add you to a chat or assign you work. Email cannot be changed here and the phone number has its own dialog. # Update your profile and handles Your avatar, name, and the handle each organization knows you by. Almost everything on this screen belongs to your account rather than to one organization, so a new photo or a corrected last name reaches every organization you belong to at once. Handles are the exception. A *handle* is the address other people use to find you, written `you:organization`, and you carry a separate one in each of them. **Before you start.** Sign in. No role is required: every member edits their own profile, whatever they can do elsewhere. ## Open your profile 1. Select your avatar at the top right of any page. 2. Select **Profile**. You land on `/settings/user`. 3. Select **Edit** at the top right of the **Profile** heading. Until you select **Edit**, the fields are read-only and the avatar ignores a click. **Save** writes the username and both name fields in one request and reports **User information updated**. If it reports **Error updating user information**, nothing was saved and your typing is still in the fields, so select **Save** again. **Cancel** leaves edit mode. It does not undo an avatar or a handle change, because each of those is written on its own the moment you finish it. > **Info:** > **No Profile item in the menu?** You are on a machine running in [operator view](/docs/monitoring/operator-view/), which hides it along with the rest of the settings. Exit operator view, or open `/settings/user` on another device. ![The Profile page at /settings/user, full width. A round grey avatar carrying the white initials MR, the placeholder an account gets before it uploads a picture, sits above a column of labeled fields reading Username, First name, Last Name, Email and Phone Number, with an Edit button at the top right of the Profile heading. Numbered callouts mark the avatar, the Username field and the name fields](/images/admin/adm-profile-01.webp) *The Profile section of the settings page, with the avatar, Username and name fields. Nothing here accepts a change until you select Edit at the top right.* ### Profile fields | Field | Scope | Visible to | Changeable | |---|---|---|---| | Profile picture | Account | Everyone who shares an organization with you, plus anyone you chat with | Yes, through the crop dialog | | `Username` | Account | Members of your organizations, in the directory and every people picker | Yes, with **Edit** and **Save** | | `First name` | Account | The same | Yes, with **Edit** and **Save** | | `Last Name` | Account | The same | Yes, with **Edit** and **Save** | | `Email` | Account | Members of your organizations, in the member directory | No. Contact [support](/docs/get-started/get-support/) | | `Phone Number` | Account | Nobody. Alert rules read it to send SMS | Yes, but through its own dialog. See [Change your phone number](/docs/admin/phone-number/) | | Organization handle | One per organization | Anyone on IoTFlows who knows it | Yes, one row at a time | ## Upload and crop an avatar 1. Select **Edit**, then select your current picture. 2. Pick an image file. A HEIC photo from an iPhone is converted for you. If the conversion fails, the page reports **Failed to convert HEIC image** and no dialog opens. 3. In **Edit Profile Picture**, drag the photo under the square crop box, then set **Zoom** and **Rotation** with the two sliders. 4. Select **Preview**. It reads **Processing...** while it renders the crop. 5. Check the result. **Back** returns to the crop box with your settings intact. **Cancel** discards the whole thing. 6. Select **Submit**. It reads **Uploading...**, then IoTFlows reports **Profile picture updated** and closes the dialog. The crop box is square and your avatar is displayed as a circle, so leave room around a face rather than cropping tight to it. There is no file size to worry about: the picture is compressed to roughly 500 KB before it is sent, whatever you started with. > **Warning:** > **Still looking at the preview after Submit?** > > The upload failed, and this dialog reports nothing when it does: the spinner stops, the preview stays, no message appears. Select **Cancel** and run the six steps again. If a second attempt sits there too, the server is refusing the file and a third will not help. ![The Edit Profile Picture dialog. A square crop box with a rule-of-thirds grid sits over an uploaded picture, with a Zoom slider and a Rotation slider beneath it and Cancel and Preview buttons along the bottom edge](/images/admin/adm-profile-02.webp) *The Edit Profile Picture dialog, with the square crop box over the uploaded photo and the Zoom and Rotation sliders under it.* ## Username and name Your *username* is the name you chose when you created the account. It is unique across IoTFlows, it is shown in italics beside your full name in the member directory, and it is one of the two things you can [sign in](/docs/get-started/sign-in/) with: the sign-in card accepts **Email or Username**. Set `First name` and `Last Name` even if the username is all anyone sees at a glance. A work-order assignee, a scheduler row and a chat member all label you with your full name. Your username also seeds your [organization handles](#handles): sign up as `mreyes` and your handle in Acme starts out as `mreyes:acme`. You are free to edit that first half organization by organization, so a handle need not match your username, but every handle is checked for uniqueness within its organization because chat and messaging address you by it. `Email` is read-only here because it identifies your account to the sign-in service. Changing it is a support task. ## Per-organization handles A handle reads `maria:acme-mfg`. The half before the colon starts as the username you chose at sign-up and is yours to change. The half after it is the organization's own handle, which an administrator sets on the [organization profile](/docs/admin/org-profile/#handle). 1. Scroll to **User Organization Handles**. Each organization you belong to has a row, with its logo and its name. 2. Select a row to edit it. Only the first half becomes a field; the colon and the organization stay fixed beside it. 3. Type the handle you want. The field lowercases as you type and drops punctuation. 4. Wait half a second. IoTFlows checks that handle against that one organization and reports **User handle available** with a green check, or **User handle not available** with a red icon. 5. Press Enter, or select anywhere outside the field, to save. Each row is checked and saved on its own, so changing your handle in one organization leaves the others alone. Clearing the field and selecting away restores the handle the row had, without sending anything. **Nothing stops you saving while the icon is red.** If that handle is already taken in that organization, the save is refused: the row snaps back to its previous handle and shows the message the server returns. Read the icon before you press Enter. Hover over a saved row and a copy button appears at the end of it. It copies the whole `you:organization` and reports **User handle copied!**. > **Info:** > **Which handle should you pick?** > > Use the same handle in every organization if you work across several. Colleagues search by handle to add you to a [chat from another organization](/docs/messaging/start-a-chat/#external), to assign you a work order, and to place you on a scheduler row. A different handle per organization means being found in only one of them, by whoever guessed right. ![The User Organization Handles panel, showing two rows. Each row carries an organization logo and name on the left and a handle written as a name, a colon and the organization handle on the right. The top row is being edited, so its first half is a text field with a green check beside the organization half. Two numbered callouts mark the editable half of the handle and the availability icon](/images/admin/adm-profile-03.webp) *The User Organization Handles list. Every organization you belong to carries its own handle, written you:organization, with its own availability check.* ## On mobile The iOS and Android apps open this same page in a web view, so every step above is the step on a phone. Selecting the avatar opens the phone's own photo library and camera, and the crop box and both sliders take touch. Two things differ. The **Two-step authentication** section further down reports whether your account has it, but the switch does nothing in the app: [enroll from a desktop browser](/docs/admin/two-step-auth/). And **User Organization Handles** lists every organization you belong to whichever one the app is currently in, so you never [switch organizations](/docs/get-started/switch-organizations/) to fix a handle. ## See also - [Change your phone number](/docs/admin/phone-number/), the one profile field with its own dialog - [Turn on two-step authentication](/docs/admin/two-step-auth/), the other setting on this page - [Switch organizations](/docs/get-started/switch-organizations/#what-follows), and what your account carries across the switch - [Start a chat](/docs/messaging/start-a-chat/#external), where someone else's handle is what you type - [Set up your organization profile](/docs/admin/org-profile/#handle), where the half of your handle after the colon comes from --- # Quickstart: set up a new organization Source: https://www.iotflows.com/docs/admin/quickstart/ The first week of a new IoTFlows organization, in the order the steps have to happen. IoTFlows creates the organization for you; there is no self-serve signup. Set the organization profile and handle at /settings/organization, then the Schedule Timezone and the work shifts, which are saved together and are used to bucket data as it arrives. Then invite your team from /members, give each person a role, and add your machines last. Correcting the timezone or the shifts later does not rewrite reports that were already computed. # Quickstart: set up a new organization The first week of a new IoTFlows organization, in the order the steps have to happen. An *organization* is the container IoTFlows creates for your company. Every machine, member, team, and report belongs to exactly one. IoTFlows creates it for you: there is no self-serve signup, so if you do not have one yet, [contact IoTFlows](/docs/get-started/get-support/) and come back once it exists. **Before you start.** You need to be signed in as an *Organization Owner*, the role IoTFlows bills, or an *Organization Administrator*, which has the same authority minus billing. See [Roles and permissions](/docs/admin/roles-reference/). > **Warning:** > **What has to happen before you add a machine?** > > Set the timezone and the shifts first. Both are used to bucket data as it arrives, so a machine that starts reporting under the wrong timezone produces reports that are wrong by the offset. > > Correcting either one later fixes new data only: it does not repair a report that was already computed. Everything else on this page can be changed at any time. ## 1. Set your organization profile Open **Settings → Organization** at `/settings/organization`. The **Organization** section at the top of the **Settings** tab carries everything that identifies your company across IoTFlows. 1. Select **Edit** at the top right of the section. 2. Select the **Organization logo** tile and upload a square image. It appears in the organization switcher and on shared reports. 3. Set **Organization name** to the name your team says out loud, for example `Midwest Tooling`. 4. Set **Organization handle**, the short identifier used to find you in chat. 5. Add an **Organization description** if you want one. It is optional. 6. Select **Save**. An "Organization modified" toast confirms the change. The handle field takes lowercase letters, digits, and underscores, and drops anything else as you type, so `Midwest Tooling!` leaves `midwesttooling`. Half a second after you stop typing, IoTFlows marks the field with a green check if the handle is free and a red icon if it is taken. **Save** is not blocked by the red icon, so check it first. ![The Organization section of Organization Settings, with an Edit button at the top right. A numbered callout 1 marks the organization logo tile, callout 2 marks the Organization handle, which reads iotflows, and callout 3 marks the Organization name, IoTFlows. Below them sit the Organization description, a Delete entire organization row with a red Delete button, and a Leave organization row.](/images/admin/adm-qs-01.webp) *The organization profile, as an admin sees it on day one.* Pick the handle you want now. Changing it later changes it for every member and rewrites every chat handle with it, in the form `user:midwesttooling`, which breaks the way people outside your company already find you. ## 2. Set the timezone Scroll to the **Schedules** section on the same screen and select its **Edit** button. **Schedule Timezone** is a dropdown of named zones, for example `(GMT-05:00) Eastern Time`. Pick the zone the plant runs on, not the one you are reading this in. IoTFlows uses it to decide which day and which shift a stop, a cycle, or a part count belongs to, so a machine in Ohio reporting under a Pacific zone credits its evening output to the wrong day. Do not select **Save** yet: the section saves the timezone and the shifts together, so set the shifts first. ![A cropped detail of the Schedules section showing its heading, an Edit button, and the Schedule Timezone row. The label sits at the left; at the right a highlighted select reads (GMT-05:00) Eastern Time (US and Canada).](/images/admin/adm-qs-02.webp) *Set the timezone before you add a machine. It buckets data as it arrives.* ## 3. Define your shifts A *shift* is a named block of hours on named days, for example Day, 06:00 to 14:00, Monday through Friday. Shifts drive the shift filters on reports, the [Shift Production](/docs/production/shift-production/) view, and the start-of-shift and end-of-shift [auto-downtime rules](/docs/monitoring/auto-downtime-rules/). Still in **Edit** on the **Schedules** section: 1. Enter a name in **Shift Name**, for example `Day`. 2. Check the days the shift runs. The checkboxes are Monday through Sunday. 3. Set **Shift Start** and **Shift End** on the two time pickers. 4. Select **Add another shift** and repeat for each remaining shift. 5. Select **Save**. A "Work shifts modified" toast confirms both the shifts and the timezone. Shifts cannot overlap in time, which the section states under **Work Schedule**. Three shifts covering a 24-hour day are Day 06:00 to 14:00, Afternoon 14:00 to 22:00, and Night 22:00 to 06:00. ![The Work Schedule panel of the Schedules section, labelled Shifts can't overlap in time. Each shift carries its name in italics, then the days it runs, then its start and end times: Day Shift, Mon through Fri, 08:00:00 to 17:00:00; Evening Shift, Mon through Fri, 17:00:00 to 01:00:00; Third Shift, Mon through Fri, 01:00:00 to 08:00:00; Weekend Shift, Sat and Sun, 10:00:00 to 17:15:00.](/images/admin/adm-qs-03.webp) *Three shifts cover the weekday around the clock, and a fourth covers the weekend.* You do not need a shift for every pattern a person works. One shift per block of plant hours is enough, because shifts describe when the machines run, not who is standing at them. Overnight and weekend coverage is on [Define shifts and your timezone](/docs/admin/shifts-and-timezone/). ## 4. Invite your team Open **Members** at `/members` and select **Add Member**. The modal handles both cases from one search field: someone who has never used IoTFlows, and someone who already has an account. 1. Type an email address, a username, or a name into the search field. 2. For an existing IoTFlows user, select their row in the results. For a new person, select the emailed-invite row the modal offers once the address is valid. 3. Choose a role under **Select organization role for member**. 4. Select **Send invite** for an emailed invite, or **Confirm Add** for an existing user. An invite reports "Invite has been sent"; adding an existing user reports "Member has been added". If you see "This email is already a member or has a pending invite in this organization", look for that person's pending invite in the directory rather than sending a second one. [Invite people to your organization](/docs/admin/invite-members/) covers resending and canceling. ![The Add Member modal. A search field at the top holds a typed address, and numbered callout 1 marks the staged invitee below it. Callout 2 marks the selected role in the list headed Select organization role for member, which offers Organization Owner, Organization Administrator, Organization Member and Organization Observer; Organization Member is chosen. Cancel and Send invite buttons sit at the bottom.](/images/admin/adm-qs-04.webp) *Inviting your first members and choosing their role.* ## 5. Assign roles A *role* is the set of actions a person can take across the whole organization, and everyone has exactly one. You choose it as you invite them, and you can change it afterward from the directory. For a first setup, this is the split that works: - **Organization Administrator** for the one or two people who will add machines, tune calibration, and manage everyone else. - **Organization Member** for operators and supervisors. - **Organization Observer** for anyone who only reads, such as a customer or an executive. Give operators **Organization Member**, not Observer. An Observer cannot classify downtime, and unclassified downtime makes a downtime report useless: the hours are recorded, but nothing says whether they were a tool change or a breakdown. You do not need a second Owner. Owner is the billing and ownership-transfer role, and an Administrator can do everything else. The full table is on [Roles and permissions](/docs/admin/roles-reference/), and a role is separate from [machine access](/docs/admin/machine-access/), which decides which machines a person sees. ![The Members directory after a round of invites, headed Members with an Add Member button. Twelve rows each carry an avatar, the member's name and handle, their organization role, an All machines access chip, and edit and delete actions at the right. Two of the rows show an email address and an amber note reading Invite sent, pending account creation, in place of a name and handle.](/images/admin/adm-qs-05.webp) *The directory once your team is in.* ## 6. Add your machines Add one *asset* for each physical machine you want to watch, and name it the way the floor names it, for example `Haas VF-2` rather than `CNC 3`. [Add a machine](/docs/monitoring/add-an-asset/) covers the dialog, including the machine type and the cycle settings that follow from it. Sensors are not something you pair yourself. Contact IoTFlows to tie your sensors to an asset; this normally happens during onboarding. See [Get support](/docs/get-started/get-support/). Start with the two or three machines that hurt when they stop, confirm their data looks right for a shift, then add the rest. ## 7. What to do in week two Once machines are reporting, the rest of the setup is worth doing with real data in front of you: - Build your [downtime categories](/docs/monitoring/downtime-categories/) out of the reasons operators actually give, then turn on [auto-downtime rules](/docs/monitoring/auto-downtime-rules/) so nobody classifies the obvious stops. - Set [uptime goals](/docs/monitoring/oee-goals/) from the first week of measurement, not from a number named in a meeting. - Turn on [alerts](/docs/alerts/quickstart/) for the machines that matter, and install the [mobile app](/docs/get-started/install-mobile-app/) for whoever carries the pager. - Put a [wallboard](/docs/monitoring/wallboards/) on the floor, and set up an [operator station](/docs/monitoring/operator-stations/) at any machine where operators classify their own downtime. - Group people into [teams](/docs/admin/teams/), and check [billing](/docs/admin/billing/) if you are the Owner. ## See also - [Define shifts and your timezone](/docs/admin/shifts-and-timezone/) - [Invite people to your organization](/docs/admin/invite-members/) - [Roles and permissions](/docs/admin/roles-reference/) - [Add a machine](/docs/monitoring/add-an-asset/) - [Overview: administer your organization](/docs/admin/overview/) --- # Roles and permissions Source: https://www.iotflows.com/docs/admin/roles-reference/ The four IoTFlows organization roles and what each one can do. Organization Owner is the billing and ownership role, Organization Administrator runs day-to-day administration, Organization Member does the shop-floor work including downtime classification, and Organization Observer is read-only. A role says what someone can do; machine access says which machines they can do it to. Scheduler and Maintain boards carry their own Owner and Member roles on top of the organization role. # Roles and permissions Every organization role, what it can do, and how roles combine with machine access. A *role* is the set of actions a person can take across your whole organization. Every member has exactly one. You pick it when you [invite someone](/docs/admin/invite-members/), and you change it later on the [member directory](/docs/admin/manage-members/). IoTFlows serves the role list, so the roles you see in the role picker come from the platform rather than from your organization. This page documents the four roles in use. ## The four roles **Organization Owner.** The highest level of authority, and the only role that can pay for IoTFlows or hand the organization to someone else. An Owner can view and edit every machine, board, and integration in the organization, whether or not they were added to it. Every organization has at least one Owner. **Organization Administrator.** The same authority as an Owner, minus billing, ownership transfer, and deleting the organization. This is the role that runs the plant day to day: adding machines, tuning calibration, managing people, and wiring up alerts. You can have as many as you need. **Organization Member.** The shop-floor role. A Member sees the machines they have access to, classifies downtime, runs jobs, creates work orders, and takes part in chats and boards. A Member cannot change the configuration of the organization or of a machine. **Organization Observer.** Read-only. An Observer sees the machines and reports they have been given access to and changes nothing, including downtime classifications. > **Info:** > **Which role for an operator?** > > Give operators **Organization Member**, not Observer. An Observer cannot classify downtime, and unclassified downtime is what makes a downtime report useless: the hours are recorded, but nothing says whether they were a tool change or a breakdown. See [Classify downtime](/docs/monitoring/classify-downtime/). You do not need more than one Owner. Owner is the billing and ownership-transfer role, and a second one buys you nothing an Administrator does not already have. Keep one Owner, name a few Administrators, and make everyone else a Member. ## What each role can do | Capability | Owner | Administrator | Member | Observer | |---|---|---|---|---| | View machines, reports, and dashboards | Yes | Yes | Yes | Yes | | [Classify downtime](/docs/monitoring/classify-downtime/) | Yes | Yes | Yes | No | | [Add, edit, hide, and archive machines](/docs/monitoring/add-an-asset/) | Yes | Yes | No | No | | [Edit sensor calibration](/docs/hardware/calibrate-senseai/) | Yes | Yes | No | No | | Create and rename downtime categories | Yes | Yes | No | No | | [Invite and remove members](/docs/admin/invite-members/) | Yes | Yes | No | No | | [Change a member's role](/docs/admin/manage-members/) | Yes | Yes | No | No | | Create a team, and manage a team you own | Yes | Yes | Yes | No | | Delete any team | Yes | Yes | No | No | | [Grant and revoke machine access](/docs/admin/machine-access/) | Yes | Yes | No | No | | [Choose who is notified by an alert rule](/docs/alerts/asset-event-rules/) | Yes | Yes | Own notifications only | Own notifications only | | [Manage chat integrations](/docs/alerts/chat-integrations/) | Yes | Yes | No | No | | [Manage webhooks](/docs/alerts/webhooks/) | Yes | Yes | No | No | | Edit organization settings: name, handle, [shifts](/docs/admin/shifts-and-timezone/), [auto-downtime rules](/docs/monitoring/auto-downtime-rules/) | Yes | Yes | No | No | | [View and pay billing](/docs/admin/billing/) | Yes | No | No | No | | [Create and edit work orders](/docs/maintain/create-a-work-order/) | Yes | Yes | Yes | No | | Create a Scheduler or Maintain board | Yes | Yes | Yes | No | | Manage a board's members and settings | Board owner | Board owner | Board owner | Board owner | The last row is not a typo. Managing a board is a [board role](#boards), so it takes board ownership whatever your organization role is. Alert rules are the one row that splits rather than switching off. An Owner or Administrator sees a subscriber list per event and sets who in the organization is notified. Everyone else sees three switches for their own email, push, and SMS on that event, and cannot change anyone else's. > **Warning:** > **Two surfaces check the role id, not the name** > > Most of the product checks the role by name. Two check the role **id**, `1` for Owner and `2` for Administrator: [Operator Performance](/docs/monitoring/operator-performance/), which reads "You are not authorized to view this page." for anyone else, and the **Exit Operator View** control in the profile menu of an [operator station](/docs/monitoring/operator-stations/), which is absent for anyone else. A role outside the four above behaves normally everywhere else and is refused on those two. ## Roles and machine access *Machine access* is a per-person list of the machines someone is allowed to see. It is a restriction layered on top of the role, not a role of its own: the role says what a person can do, machine access says which machines they can do it to. A member with an empty list sees every machine, which is the default. Grant one machine and that member sees only what is on the list, everywhere: the Assets page, the reports, the machine picker on a new work order. For example, a Member restricted to `Haas VF-2` can classify downtime there and cannot see `Brother S700X1` at all. A restriction never adds a permission. Grants live on the member directory and are managed by Owners and Administrators only. See [Limit which machines a member can see](/docs/admin/machine-access/). ## Board roles Scheduler and Maintain boards carry their own **Owner** and **Member** roles on top of the organization role. A board owner manages that board's membership and settings; a board member works on it. Adding someone to a board does not change their organization role, and being an Organization Administrator does not make you the owner of every board. You do not need to plan board roles up front. The person who creates a board owns it, which is the right answer most of the time. Set up the rest when a board outgrows one owner: [Scheduler board members](/docs/production/scheduler-members/) and [Maintain board members](/docs/maintain/board-members/). ## Owner-only actions | Action | Why | |---|---| | Open the billing page, add a card, and pay an invoice | Billing is the Owner's liability. An Administrator gets "Only organization owners can access this page." | | [Restore a suspended organization](/docs/admin/suspended-account/) | The lockout modal every member sees sends them to billing, and only the Owner can act there. A suspended organization stays blocked until its Owner clears it | | [Transfer ownership](/docs/admin/manage-members/) | Ownership is what the platform bills against, so only the current Owner can hand it over | | Delete the organization | Irreversible, and it takes every machine, board, and record with it | The practical consequence is worth planning for: if your only Owner leaves the company, nobody left can pay the invoice or clear a suspension. Transfer ownership before they go, or [contact IoTFlows](/docs/get-started/get-support/). ## See also - [Change roles and remove members](/docs/admin/manage-members/) - [Limit which machines a member can see](/docs/admin/machine-access/) - [Maintain board members](/docs/maintain/board-members/) - [Scheduler board members](/docs/production/scheduler-members/) --- # Define shifts and your timezone Source: https://www.iotflows.com/docs/admin/shifts-and-timezone/ How to set the hours IoTFlows reads your plant by. One Schedule Timezone covers the whole organization, and the work shifts sit under it in the Schedules panel of Organization Settings at /settings/organization; both save together behind one Edit and one Save, confirmed by a "Work shifts modified" toast. A shift carries a name, the days it runs, a start time, and an end time on 15-minute steps. A shift whose end time is at or before its start time runs past midnight and is entered on the day it starts, so a Friday night shift is one entry with Friday checked; the Assets page then shows that shift whole while reports split it at midnight unless Shift islands is on. Shifts cannot overlap, but the platform does not enforce it, so keeping them distinct is on you. Shifts bucket data as it arrives, so an edit changes how new data is bucketed and does not rewrite reports already computed. # Define shifts and your timezone Align every number in IoTFlows with the hours your plant actually works. A *shift* is a named block of hours on named days, for example Night, 22:00 to 06:00, Monday through Friday. IoTFlows sorts every stop, cycle, and part count into the shift and the day it fell in, read against one organization-wide timezone. Both settings live in the **Schedules** panel of Organization Settings, at `/settings/organization`, and they save together. **Before you start.** You need to be an *Organization Owner* or an *Organization Administrator*. See [Roles and permissions](/docs/admin/roles-reference/). ## Set the organization timezone 1. Open Organization Settings from the gear at the top right of the header, and scroll to the **Schedules** panel. 2. Select **Edit** at the panel's top right. Nothing in the panel is editable until you do. 3. Open **Schedule Timezone** and pick the zone the plant runs on. 4. Select **Save**. A "Work shifts modified" toast confirms it. The dropdown lists named zones, for example `(GMT-05:00) Eastern Time (US & Canada)`, rather than raw offsets. A named zone carries its own daylight-saving rule, so your 06:00 shift still starts at 06:00 on the Monday after the clocks move. One zone covers the whole organization. There is no per-shift timezone field, so an organization running plants in two zones aligns its shifts with one of them. Pick the zone of the plant whose reports are read most, and read [Troubleshoot wrong utilization or OEE](/docs/monitoring/troubleshoot-monitoring/#shift-boundaries) before you explain the other plant's numbers. ![The Schedules panel of Organization Settings in edit mode, with Cancel and Save at its top right. The Schedule Timezone row sits below them, its dropdown highlighted and reading (GMT-05:00) Eastern Time (US and Canada).](/images/admin/adm-shift-01.webp) *The Schedule Timezone dropdown in the Schedules panel of Organization Settings. Set this first.* ## Why the timezone comes first The zone decides which day and which shift each reading belongs to. Get it wrong and every number in the product is wrong by the offset, while each one still looks plausible. A machine in Ohio reporting under a Pacific zone credits its evening output to the following day, and the night shift reads as though it produced nothing. Pick the plant's zone, not the head office's, and not the one you happen to be reading this in. The timezone and the shift list save in a single request, so there is no way to change one without the other. Read both back before you leave the panel. > **Info:** > **Why can I open this panel without an admin role?** > > The **Schedules** panel renders its **Edit** button for every signed-in member, unlike the device-assignment block above it. IoTFlows enforces the role when the request reaches the platform. Treat the [permission matrix](/docs/admin/roles-reference/#matrix) as the rule, not the controls you happen to see. ## Add a shift Still in **Edit** on the **Schedules** panel: 1. Enter a name in **Shift Name**, for example `Day`. 2. Check the days the shift runs. The checkboxes are Monday through Sunday. 3. Set **Shift Start** and **Shift End** on the two time pickers. 4. Select **Add another shift**, and repeat for each remaining shift. 5. Select **Save**. The "Work shifts modified" toast covers the shifts and the timezone together. Nothing is written until you select **Save**, and **Cancel** discards every row you added. Define shifts even if you run one. Every report, every [auto-downtime rule](/docs/monitoring/auto-downtime-rules/), and every [operator view](/docs/monitoring/operator-view/) buckets by shift, and a plant with no shifts defined reads its whole day as one undifferentiated block. [Working hours](/docs/production/scheduler/#working-hours) on the scheduler stays switched off until at least one shift exists. ![The Schedules panel with the Schedule Timezone row above the Work Schedule list and its note that shifts can't overlap in time. The list is alphabetical: Afternoon Shift, Mon through Fri, 14:00:00 to 22:00:00; Day Shift, Mon through Fri, 06:00:00 to 14:00:00; Night Shift, Mon through Fri, 22:00:00 to 06:00:00. Four callouts sit on the Day Shift entry: 1 on the shift name in italics, 2 on the days abbreviated to three letters, 3 on the start time and 4 on the end time.](/images/admin/adm-shift-02.webp) *Three shifts covering the day, including one crossing midnight.* A *shift window* is the stretch of clock time one shift covers on one date, for example Night on Friday 12 June, 22:00 to 06:00 the next morning. The shift selector on a report picks a window, not a shift. It preselects the window running right now, and falls back to **All Day** when the current time sits outside every shift. ## Shift fields | Field | Required | Accepts | Notes | |---|---|---|---| | **Shift Name** | Yes | Free text | Labels the bucket in every shift filter, report, and gauge. Give each shift a distinct name. | | Days | Yes | Any of the seven checkboxes, Monday through Sunday | A row with no day checked is ignored, so the shift never appears in a filter. Check the days the shift *starts*. | | **Shift Start** | Yes | A time, on 15-minute steps | The field is not typeable: set it on the clock that opens when you select it. A new row starts at 8:00 AM. | | **Shift End** | Yes | A time, on 15-minute steps | At or before the start time makes the shift [overnight](#overnight). A new row starts at 5:00 PM. | | **Schedule Timezone** | Yes | One named zone for the whole organization | Saved with the shift list, never on its own. | Times are stored and listed to the second, so the read-only list shows `06:00:00 - 14:00:00`. You cannot set the seconds, only the hours and the quarter hour. ![A single shift row in the Schedules panel in edit mode, under the Work Schedule heading and its italic note that shifts can't overlap in time. A text field holding Day Shift sits at the top with a remove cross to its right, checkboxes labeled Monday through Sunday sit below it with Monday through Friday checked, and two pickers labeled Shift Start and Shift End read 08:00 AM and 05:00 PM, each with a clock icon beside it.](/images/admin/adm-shift-03.webp) *One shift row in edit mode: the Shift Name field, the seven day checkboxes, and the Shift Start and Shift End pickers.* ## Overnight shifts A shift whose end time is at or before its start time runs past midnight into the next day. Night, 22:00 to 06:00, is one shift of eight hours, not two entries. Check only the days the shift **starts**. A night shift that runs Friday 22:00 into Saturday 06:00 is a single entry with Friday checked. Adding a second entry for the Saturday morning both double-counts the hours and overlaps. A shift that ends at the same time it starts, for example 06:00 to 06:00, covers a full 24 hours. Use it for a continuous operation that has no break in coverage on the days it runs. ### Where the overnight hours land The live views and the reports divide an overnight shift differently, so the same Friday night shift can give you two different hour counts. The [Assets page](/docs/monitoring/assets-overview/#window) and a machine's own page show the shift whole. Select Friday's night shift and you get all eight hours, 22:00 through 06:00, with no break at midnight. Reports split the shift at midnight. A Friday report on that shift counts 22:00 to 24:00 only, and the six morning hours report on Saturday. To report the shift whole, turn on **Shift islands** in the **Shifts** filter. It puts an overnight shift entirely on the day it begins, so Friday carries all eight hours. It is available on the [Advanced Report](/docs/monitoring/advanced-report/#shift-islands) and the [Downtimes report](/docs/monitoring/downtimes/#filters-reference), and nowhere else. Turn it on for any shift that crosses midnight. For a shift that does not cross midnight it changes nothing: a 08:00 to 17:00 day shift and a 01:00 to 08:00 third shift report identically either way. **The hours are moved, not lost.** The six morning hours are still counted, against the day after the one they were worked. Two things follow from that, and the second is what misleads people. A day the shift never runs collects hours. A Monday-to-Friday night shift spills into Saturday, so a Saturday report shows time for a shift that was never scheduled. A mid-week day can show the right total and the wrong night. Tuesday's eight hours are Tuesday's two before midnight plus Monday night's six after it. The total is right, so nothing on screen suggests you are reading two nights at once. So the split is easiest to see at the ends of a run. Monday is short the hours that belong to it, and Saturday carries hours that do not. ![A daily stacked bar chart on the Advanced Report for one machine on the Evening Shift, which runs 5 PM to 1 AM Monday through Friday, with Shift islands off. Six blue bars stand over the day labels Mon Sep 21 through Sat Sep 26: Monday is visibly shorter than the four that follow it, Tuesday through Friday are equal, and Saturday is a stub about an eighth their height.](/images/admin/adm-shift-04.webp) *A 5 PM to 1 AM shift with Shift islands off. Only one hour falls after midnight, so Monday is an hour short and that hour lands on Saturday.* ![The same daily stacked bar chart with Shift islands on. Five blue bars of equal height stand over Mon Sep 21 through Fri Sep 25, and the Saturday column is empty.](/images/admin/adm-shift-05.webp) *The same shift with Shift islands on. Each night reports whole on the day it began, and Saturday is empty.* > **Warning:** > **A night-shift report is missing hours?** > > Check which view produced the number before you check the data. A report six hours short against the Assets page is the midnight split, not a sensor gap. Turn on **Shift islands**, or read the shift on the Assets page instead. ## Shifts cannot overlap The panel states the rule under **Work Schedule**: shifts can't overlap in time. The platform does not enforce it. An overlapping schedule saves like any other, with the same **Work shifts modified** toast, so nothing on screen tells you the schedule is wrong. Adjust the boundary rather than the second shift's start. A shift ends the instant the next one begins, so Day 06:00 to 14:00 and Afternoon 14:00 to 22:00 do not overlap. If the handover really takes 15 minutes, give the time to one shift or the other; it cannot be in both. Keep the rule yourself, because nothing else will. Read the shift list back after every save and check that each shift ends where the next one begins. You do not need a shift for scheduled breaks. A lunch or a cleandown inside the shift is configured as a [break rule](/docs/monitoring/auto-downtime-rules/#breaks), which classifies the stop without taking the time out of the shift. Carving a break out as its own shift instead leaves two shifts with a gap between them, and the machines keep reporting into the gap. ## Edit or delete a shift Select **Edit** on the **Schedules** panel, change any field on any row, and select **Save**. Every row is rewritten on each save, so a single **Save** can rename one shift, move another's boundary, and change the timezone at once. To delete a shift, select the cross at the right of its **Shift Name** field, then **Save**. The shift disappears from the shift filter everywhere, for past dates as well as future ones, because the filter lists the shifts you have now. Renaming has the same reach. The name is how a bucket is labeled in every report and every export, so a rename shows up on historical windows too. ## What changing shifts does to existing data Shifts bucket data as it arrives. Editing a shift changes how data recorded from now on is sorted, and does not rewrite a report that was already computed under the old schedule. A figure that moved after a shift edit is correct going forward and unchanged historically. This is why the schedule is worth getting right on day one, before the first machine reports. > **Warning:** > **Changing shifts on a plant that is already running?** > > Make the edit at a boundary, ideally between the last shift of one week and the first of the next. An edit made mid-shift leaves one window that is half old schedule and half new, and that is the window somebody will question later. If numbers look wrong straight after an edit, work the checks in order on [Troubleshoot wrong utilization or OEE](/docs/monitoring/troubleshoot-monitoring/#shift-boundaries). The timezone is check one, and the shift schedule is check two. ## See also - [Classify downtime automatically](/docs/monitoring/auto-downtime-rules/), the start-of-shift, end-of-shift, and break rules that read this schedule - [How each metric is calculated](/docs/monitoring/metrics-reference/), what a shift window does to each number - [Troubleshoot wrong utilization or OEE](/docs/monitoring/troubleshoot-monitoring/#shift-boundaries), for production landing in the wrong shift or day - [Set your organization name, logo, and handle](/docs/admin/org-profile/), the other half of the same settings screen - [Track production against shift goals](/docs/production/shift-production/), the view that reads one shift at a time --- # Restore a suspended organization Source: https://www.iotflows.com/docs/admin/suspended-account/ What the IoTFlows suspension lockout looks like, and how an Organization Owner clears it. An unpaid account suspends the organization, which puts every member behind an Organization Suspended dialog that has no close button and covers every route except /{organization}/settings/billing. The dialog offers Go to Billing and Contact Support. Only the Owner can open the billing page, so no other role can clear the lockout. Machine data does not collect while an organization is suspended: the sensors keep running, nothing is recorded, and paying the bill does not backfill the gap, which reports show as unknown time. Clear a suspension the day it starts. # Restore a suspended organization See what the lockout looks like, and reach the one page it leaves open. *Suspension* is the state IoTFlows puts an organization into when its account goes unpaid. It locks the dashboard for every member of that organization at once, and only the Organization Owner can lift it, because the recovery runs through [Billing](/docs/admin/billing/) and no other role can open that page. **Before you start.** Clearing a suspension takes an Organization Owner, see [Owner-only actions](/docs/admin/roles-reference/#owner-only). > **Danger:** > **Does data keep collecting while we are suspended?** > > No. A suspended organization **stops recording machine data**. The sensors keep running and the machines keep making parts, but nothing reaches the record. > > Paying the bill lifts the lockout and does not backfill the gap, so those hours are missing from every report forever. Clear a suspension the day it starts. Every hour it stands is an hour of machine history you do not get back. ## What suspension looks like A dialog headed **Organization Suspended** opens over the dashboard, under a red warning icon. It reads "Your organization has been suspended and access has been restricted," then offers a payment method or support as the two ways out. The dialog cannot be dismissed. There is no close button, and neither Escape nor a click on the backdrop does anything. It reopens on every route in the organization except the billing page, so navigating elsewhere puts it straight back. Two buttons sit along the bottom. **Go to Billing** opens `/{organization}/settings/billing`. **Contact Support** writes to `support@iotflows.com`, the same address linked in the body text. ![The Organization Suspended dialog centered over a blurred dashboard, with a red warning icon above the title and Go to Billing and Contact Support buttons along the bottom edge. Go to Billing is highlighted](/images/admin/adm-susp-01.webp) *The suspension lockout. Billing is the only page you can still reach.* ## What still works The billing page is exempt. It is the one route in a suspended organization that renders normally, which is how an Owner clears the lockout from inside the product. The organization switcher in the header is reachable once you are on billing, so you can move to another organization from there. Suspension applies to one organization, not to your account, so the others you belong to are untouched, see [Switch organizations](/docs/get-started/switch-organizations/). > **Warning:** > **Not the Owner?** Do not try to work around the dialog. **Go to Billing** takes you to a page that answers "Only organization owners can access this page." > > Find your Owner, or write to [support](/docs/get-started/get-support/#contact). The organization stays locked until one of them acts. ## Clear the suspension 1. Select **Go to Billing** in the dialog. 2. Add a working card, see [Add a card](/docs/admin/billing/#add-card). 3. Make it the default, see [Set the default card](/docs/admin/billing/#default-card). 4. Write to [support](/docs/get-started/get-support/#contact) to have the organization reinstated, quoting the organization name. 5. Reload the dashboard once support confirms. The lockout clears when the app refetches your organizations, which it does on load, so a stale tab keeps showing the dialog after the account is current. Reporting picks up again from the moment the suspension lifts, not from the moment the invoice was paid. ## Preventing it Suspension follows an invoice that goes unpaid long enough, so it is an inbox problem before it is a billing problem. Send invoices to an address more than one person reads, see [Set the billing email](/docs/admin/billing/#email). Check the **Invoices** tab for anything sitting on **Open** past its due date, see [Invoice statuses](/docs/admin/billing/#statuses). Replace an expiring card before its last month rather than after the payment fails. ## What the gap looks like in reports Hours inside a suspended period carry no data, so reports count them as *unknown time*: neither uptime nor downtime, gray on the shift status bar. A report spanning the suspension shows a lower total for every metric because its window is shorter than it looks, see [Unknown time](/docs/monitoring/metrics-reference/#unknown). ## See also - [Manage payment methods and invoices](/docs/admin/billing/), the page the lockout leaves open - [Roles and permissions](/docs/admin/roles-reference/#owner-only), for what else only the Owner can do - [Get support](/docs/get-started/get-support/#contact), to have an organization reinstated - [Billing questions](/docs/get-started/faq/#billing), for plans, refunds and invoices --- # Create and manage teams Source: https://www.iotflows.com/docs/admin/teams/ How to create and run an IoTFlows team: a named group of members that boards, chats, and work-order assignment can point at instead of naming people one at a time. Teams live in the Teams section of the member directory at /members, and each team has its own page at /members/teams/. Create Team asks for a team name and a team handle, checks the handle for availability as you type, then asks you to pick at least one other member; you are added automatically. The team page renames the team and edits the handle in place, adds and removes members, promotes members to team owner, and carries Leave Team and Delete Team. Deleting a team needs a team owner or an Organization Owner or Administrator. There is no team image control in the web dashboard: a team gets a colored avatar automatically. # Create and manage teams Group people so boards, chats, and assignments point at a team rather than at individuals. **You need to be an Organization Owner or Organization Administrator to create a team.** See [Roles and permissions](/docs/admin/roles-reference/#roles). A *team* is a named group of members in one organization, for example Maintenance or Second Shift. A *team handle* is the team's short, unique address inside your organization, written as `handle:organization-handle`, for example `maintenance:acme`. Anything that accepts people also accepts a team: [Maintain board members](/docs/maintain/board-members/), [Scheduler board members](/docs/production/scheduler-members/), group chats, and work-order assignment. Build boards, chats, and assignment lists from teams, not from people. A team is edited once when someone joins. A dozen boards named after individuals are edited a dozen times, and one always gets missed. You do not need teams if your whole organization is five people who all work on everything. Teams pay off when the same subset of people keeps appearing in more than one place. ## Create a team Teams live in the member directory, next to the member list. 1. Go to `/members`. 2. In the **Teams** section, select **Create Team**. 3. Enter a **Team Name**, for example `Maintenance`. 4. Enter a **Team Handle**, for example `maintenance`. The dashboard checks it half a second after you stop typing and reports "Team handle available" or "Team handle not available". 5. Select **Add Members**. This button stays disabled until the name is filled in and the handle comes back available. 6. Search for each person by name, username, or email, and select them. Selected people appear as blue chips above the list. 7. Select **Create Team**. A toast reads "Team added", and the new team appears in the **Teams** table with its name, handle, and member count. ![The Create Team dialog. A Team Name field marked 1 holds Press Room, and a Team Handle field marked 2 holds pressroom with a green availability check to its right. A Cancel button and an Add Members button sit at the bottom, and callout 3 marks Add Members, which opens the member picker as a second step of the same dialog](/images/admin/adm-teams-01.webp) *Creating a team.* You cannot create a team on your own. **Create Team** stays disabled until you select at least one other member, and the modal says so: "You will automatically be added as a member of this team." You never appear in the picker, because you are already in the team. ## Team name, handle, and image | Field | Required | Changeable | Used by | |---|---|---|---| | **Team Name** | Yes | Yes, in place on the team page | The label everywhere the team appears: board member lists, chats, assignment pickers | | **Team Handle** | Yes, and it must come back available | Yes, in place on the team page | Addressing the team as `handle:organization-handle`, and the copy button on the team page | | **Members** | Yes, at least one besides you | Yes, add and remove on the team page | Who the team resolves to | | **Owners** | No | Yes, on the team page | Who can delete the team | | Team image | No, and there is no control for it | No | A team gets a colored avatar automatically | The handle is normalized as you type: it is lowercased, and anything that is not a letter, a digit, an underscore, or a space is dropped. Typing `Maintenance-Team!` leaves you with `maintenanceteam`. Handles are checked against the whole organization, so a team cannot take a handle that a member already uses. ## Add and remove members Open a team from the **Teams** table at `/members` to reach its page at `/members/teams/`. 1. Select **Add**. 2. Search for each person and select them. 3. Confirm. The member list on the team page updates immediately. To remove someone, select the trash icon at the right of their row. The toast reads "User has been removed". There is no confirmation step, and no undo: add them again if you remove the wrong person. ![The member list on a team page, six people deep. Each row has an avatar, a full name, a username, a crown button that toggles team owner, and a red trash button. Two rows carry a green badge on the avatar marking them as owners. Add and More buttons sit above the list](/images/admin/adm-teams-03.webp) *Team membership. Build boards from teams, not from individuals.* Removing someone from a team does not remove them from the organization, and it does not touch their role or their [machine access](/docs/admin/machine-access/). For that, see [Change roles and remove members](/docs/admin/manage-members/). ## Rename a team or change its handle Both edits happen in place on the team page, under the team avatar. 1. Select the team name. It becomes a text field. 2. Type the new name and press Enter, or select outside the field. The name saves on its own; there is no Save button. 3. Select the handle to edit it the same way. A spinner runs while the new handle is checked, then a green check or a red exclamation icon replaces it. 4. Press Enter to save the handle. ![The top of a team page. A large circular team avatar lettered M sits above the team name, open as an editable text field holding Maintenance with the cursor in it, and below that the handle reads maintenance:iotflows with a copy button to its right](/images/admin/adm-teams-02.webp) *Renaming a team and editing its handle in place.* The handle field guards itself against saving an unchecked value. | What you see | What happened | |---|---| | "Team handle not available" | Another team or member already holds it. The red icon stays until you type something free | | "Still checking handle availability, please wait..." | You pressed Enter while the check was in flight. Nothing was saved. Wait for the icon, then press Enter again | | "Handle check was in progress. Reverted to previous handle." | You clicked away while the check was in flight. The field went back to the saved handle, and nothing was saved | Clearing the name field and clicking away restores the old name rather than saving an empty one. Changing a handle changes how the team is addressed. Use the copy button beside the handle to get the full `handle:organization-handle` string, and tell anyone who had the old one. ## Team owners A team owner is a member who can delete the team. That is the whole of the power: being a team owner grants nothing else over the team's name, handle, or membership. Select the crown icon on a member's row to promote them. The toast reads "Owner Added", and a green badge appears on their avatar. Select it again to demote them, and the toast reads "Owner Removed". Give a team at least one owner who is not you. Otherwise the only people who can delete the team are the organization's Owner and Administrators, which is fine until the team is one you no longer administer. ## Leave a team Select **More**, then **Leave Team**. You are removed from the member list immediately. Leaving is the same action as removing yourself, so the same warning applies: the team can end up with no owner, and nobody is asked to confirm. Promote another owner before you leave a team you own. ## Delete a team 1. On the team page, select **More**. 2. Select **Delete Team**. 3. Confirm in the **Delete Team** dialog, which asks "Are you sure you want to delete *name* Team?". 4. Select **Delete**. The toast reads "Team deleted". **Delete Team** is disabled unless you are a team owner, an Organization Owner, or an Organization Administrator. Hovering the disabled control explains why: "You must be a team owner or an organization admin to delete this team". Deleting a team removes it from every board, chat, and picker that pointed at it. The people are untouched, but anything that named the team now names nobody. Check the team's boards before you delete it, and replace the team on each one. ## On mobile The team page is the same page in the IoTFlows mobile apps, in a full-height mobile layout without the dashboard chrome. Everything on it works: rename, handle, add, remove, owners, leave, and delete. On Android, you can also reach a team from a [Maintain board](/docs/maintain/board-members/): open the board's member list and select the team to edit it there, without going through `/members`. ![An Android phone showing a Maintain board's member list, with teams listed above individual members, and the team page that opens from it, carrying the team avatar, name, handle, and member rows](/images/admin/adm-teams-04.webp) *Android can edit a team from inside a Maintain board.* ## See also - [Maintain board members](/docs/maintain/board-members/) - [Scheduler board members](/docs/production/scheduler-members/) - [Change roles and remove members](/docs/admin/manage-members/) - [Start a chat](/docs/messaging/start-a-chat/) - [Roles and permissions](/docs/admin/roles-reference/) --- # Turn on two-step authentication Source: https://www.iotflows.com/docs/admin/two-step-auth/ How to add an authenticator app to your IoTFlows account, and what changes at sign-in. Two-step authentication sits on your account rather than on an organization, so one enrollment covers every organization you belong to. Enroll from a desktop browser: the Two-step authentication section at the bottom of /settings/user renders inside the mobile app, but its toggle is inert there, so enrollment and turning the setting off are both web-only. Turning the Authentication App toggle on opens Set up authentication app, which shows a QR code to scan into an authenticator app such as 1Password or Google Authenticator; Next then asks for the 6-digit code, and IoTFlows submits it the moment the sixth digit lands. The sign-in challenge itself works on web, iOS and Android. Turning the toggle off takes effect immediately with no code and no confirmation, and there is no self-serve recovery if you lose the authenticator. # Turn on two-step authentication Add an authenticator app to your account, and see what changes at sign-in. Two-step authentication puts a six-digit code between your password and your account, so a password on its own stops being enough to sign in. The code comes from an *authenticator app*, an app on your phone that generates a fresh code every 30 seconds from a secret it shares with IoTFlows. The setting sits on your IoTFlows account rather than on an organization, so enrolling once covers every organization you belong to. Enrollment takes three steps in one dialog: open it, scan a QR code, then type back a code the app generates. **Before you start.** Sign in on a desktop browser, and have a phone with an authenticator app on it. > **Info:** > **Working from your phone today?** Enroll from a desktop browser anyway. The **Two-step authentication** section renders inside the mobile app, but its toggle does not respond to a tap, so there is no way to finish enrollment there. ## Start enrollment 1. Go to **Settings → Profile** at `/settings/user`. 2. Scroll to **Two-step authentication**, the last section on the page. The **Authentication App** row reads **Disabled** in red. 3. Turn the toggle at the right of that row on. The **Set up authentication app** dialog opens on a QR code. **Cancel** backs you out at any point before you confirm a code, and returns the row to **Disabled**. ![The Two-step authentication section of the profile page. An Authentication App row reads Disabled in red, and a gray toggle switch, highlighted, sits at the right of the row](/images/admin/adm-2fa-01.webp) *The Two-step authentication section at the bottom of Settings → Profile, with the Authentication App row reading Disabled and the toggle beside it off.* ## Scan the QR code IoTFlows uses *TOTP*, the time-based one-time password standard every authenticator implements, so the app is yours to choose: 1Password, Authy, Google Authenticator and Microsoft Authenticator all work. 1. Open the authenticator app and start adding an account. 2. Point it at the QR code in the dialog. 3. Select **Next**. The entry your app creates is labeled **IoTFlows**, with no email address on it. Rename it to include yours if you hold more than one IoTFlows account, because two entries otherwise look identical and only one of the codes works. > **Warning:** > **Do not photograph or share this screen.** The QR code carries the secret itself, and anyone who scans it can generate your codes. It is shown once and cannot be retrieved later. ![The Set up authentication app dialog. A line reading Scan the QR code below into a third party authentication app sits above a QR code inside a violet-outlined square, with Cancel and Next buttons along the bottom edge](/images/admin/adm-2fa-02-v2.webp) *The Set up authentication app dialog, showing the QR code to scan into an authenticator app. The code pictured here is a stand-in, because a real one carries the account secret.* ## Confirm a code The dialog becomes **Confirm Authentication App** and shows six single-digit boxes. Type the current code from your app. IoTFlows submits it the moment the sixth digit lands, so you rarely select **Submit**. A rejected code clears the boxes and prints the reason in red beneath them. Codes expire every 30 seconds, so the usual cause is a code that rolled over between reading it and typing it: wait for the next one and type that. If every code is rejected, the phone's clock is the cause, and setting its date and time to update automatically fixes it. Select **Back** to return to the QR code. It is the same code as before, so scanning it again does not strand the entry you already made. When a code is accepted the dialog closes and the **Authentication App** row reads **Enabled** in green. ![The confirmation step of the Set up authentication app dialog, cropped to a row of six single-digit code boxes under the line Enter the 6-digit code you see in the app](/images/admin/adm-2fa-03.webp) *The Confirm Authentication App step, cropped to the six code boxes where you type the code your authenticator app shows.* ## Signing in afterwards From the next sign-in on, your password is followed by a **Two-step authentication** prompt with the same six boxes. The prompt appears on the web, on iOS and on Android. [Sign in to IoTFlows](/docs/get-started/sign-in/#two-step) covers what you see there. Enrollment is the web-only part, not the use. ### Where two-step authentication applies | Action | Web | iOS | Android | |---|---|---|---| | Enter a code at sign-in | Yes | Yes | Yes | | See whether the setting is on | Yes | Yes | Yes | | Start enrollment | Yes | No | No | | Turn the setting off | Yes | No | No | | Recover a lost authenticator | Support only | Support only | Support only | To turn two-step authentication off, turn the same toggle off. It takes effect immediately, with no code and no confirmation step, and the row returns to **Disabled**. Moving to a new phone is the same pair of actions: turn it off, then enroll again from the new handset. ## If you lose your authenticator There is no self-serve recovery. IoTFlows issues no backup codes, and the sign-in prompt offers no way past it, so an account whose authenticator is gone cannot be signed into at all. [Contact support](/docs/get-started/get-support/) from an address your organization can confirm and ask to have two-step authentication cleared. You then enroll again from the start. Two things make that call unnecessary. Use an authenticator that backs its entries up to an encrypted cloud account, so a lost phone is a restore rather than a recovery. Or scan the QR code into two devices during enrollment, which leaves both generating the same codes. ## See also - [Sign in to IoTFlows](/docs/get-started/sign-in/#two-step), the code prompt on each client - [Update your profile and handles](/docs/admin/profile/), the rest of the settings on this screen - [Change your phone number](/docs/admin/phone-number/), the other account security setting - [Get support](/docs/get-started/get-support/), for a lost authenticator --- # Set alert rules for a machine Source: https://www.iotflows.com/docs/alerts/asset-event-rules/ Configure Event Notifications on one machine: the ten event types across machine status, connectivity, shock, health and temperature, the threshold each one takes, the six channels every event can use, the per-event subscriber lists that decide who is actually told, and which sections each device type shows. # Set alert rules for a machine The per-machine notification matrix: which events fire, who hears about them, and through which channel. Every machine carries the same grid of rules. A *rule* pairs an *event type*, one of the ten conditions IoTFlows watches for, with the channels that carry it: email, push, SMS, the event log, an automatic work order, and any chat integrations your organization has set up. Rules are set one machine at a time and stored on that machine, so the Haas VF-2 and the Doosan 2600 beside it can watch for different things. **Prerequisites.** A machine with a sensor, see [Add a machine](/docs/monitoring/add-an-asset/). Owner or Administrator to decide who is subscribed, see [Roles and permissions](/docs/admin/roles-reference/). Health and temperature events need **firmware 5 or later**, and a BeamTracker shows machine status and connectivity only, see [Which sections you see for which device](#device-visibility). ## Open notification settings 1. Open the machine at `/assets/selected-asset/:id`. 2. Find the row of icons at the top right of the header, above the tab strip. 3. Click the bell. Its tooltip reads **Event Notifications**. The modal opens on the full matrix, headed **Event Notifications** over **Configure alerts for critical machine conditions**. The same bell sits in the control bar of [Operator View](/docs/monitoring/operator-view/), so an operator station reaches the same settings. Nothing here is staged. The footer reads **Changes are saved automatically**, and every switch writes as you flip it, so **Done** closes the modal rather than saving it. ![The Event Notifications modal at full width. A header reads Event Notifications over Configure alerts for critical machine conditions. Below it, five stacked sections titled MACHINE STATUS, CONNECTIVITY, SHOCK EVENTS, HEALTH SCORE and TEMPERATURE, each with a six-column header reading EMAIL, PUSH, SMS, LOG, WORK ORDER over Maintenance, and INTEGRATIONS over Webhooks. Callout 1 marks the section headings, callout 2 marks the six column headers, callout 3 marks the avatar piles in the email column. The footer reads Changes are saved automatically beside a Done button](/images/alerts/alr-rules-01.webp) *The full notification matrix for a SenseAi machine.* ## How a rule is built There is no Add rule button and no master on/off switch. All ten event types are always present, grouped into five sections, and a rule is live on the channels you switch on and silent on the rest. An event type with every column off is a rule that watches nothing. Each row carries three things on its left side and six switches on its right. - **The name.** Either the event type's title, such as **Device Offline**, or a colored *severity* chip that replaces it. Severity is the seriousness IoTFlows assigns the event, written as **CAUTION**, **WARNING** or **CRITICAL**. - **A one-line description** of what fires it, for example "Triggered when the device loses internet or power". - **A threshold**, where the event type takes one. A *threshold* is the number the condition is measured against: ten minutes of stoppage, 100 g of shock, 70 °C. Because the chip replaces the title, the two **Machine Down** rows and the three health rows are told apart by their chip and their description, not by a heading. A row showing **WARNING** in the Machine Status section is **Machine Down** at its warning time. Thresholds save when you click out of the field, not as you type. Type the new value, then click anywhere outside the box and wait for the **Threshold updated** confirmation. ### Event types | Event | On-screen title | Fires when | Threshold | Default | Editable | Devices | |---|---|---|---|---|---|---| | `aet_downtime_warning` | **Machine Down**, shown as a **WARNING** chip | The machine has been stopped for the time threshold | Minutes | The machine's own downtime alert time | Yes | Every device | | `aet_downtime_critical` | **Machine Down**, shown as a **CRITICAL** chip | The machine has been stopped for a longer time threshold | Minutes | The machine's own downtime alert time | Yes | Every device | | `aet_machine_up` | **Machine Up** | The machine starts running again | None | — | — | Every device | | `aet_offline_warning` | **Device Offline** | The device has not reported for the time threshold | Minutes | 10 | Yes | Every device | | `aet_shock_critical` | **Abnormal Shock Detection** | Acceleration at the sensor passes the g threshold | g | 100 | Yes | SenseAi, SenseAi Embedded | | `aet_health_score_caution` | **Caution Health Alert**, shown as a **CAUTION** chip | Health score falls below 60% | % | 60 | No | SenseAi, SenseAi Embedded on firmware 5 or later | | `aet_health_score_warning` | **Warning Health Alert**, shown as a **WARNING** chip | Health score falls below 40% | % | 40 | No | SenseAi, SenseAi Embedded on firmware 5 or later | | `aet_health_score_critical` | **Critical Health Alert**, shown as a **CRITICAL** chip | Health score falls below 20% | % | 20 | No | SenseAi, SenseAi Embedded on firmware 5 or later | | `aet_temperature_warning` | **Warning Temperature**, shown as a **WARNING** chip | Temperature passes the warning threshold | °C or °F | 70 °C (158 °F) | Yes | SenseAi, SenseAi Embedded on firmware 5 or later | | `aet_temperature_critical` | **Critical Temperature**, shown as a **CRITICAL** chip | Temperature passes the critical threshold | °C or °F | 80 °C (176 °F) | Yes | SenseAi, SenseAi Embedded on firmware 5 or later | The full matrix of every event type against every channel is on [Event types and channels](/docs/alerts/event-types-reference/). ## Machine status events **Machine Status** holds the three rules that follow the running state: **Machine Down** at a warning time, **Machine Down** at a critical time, and **Machine Up**. Both **Machine Down** rows take a time threshold in whole minutes. A row with nothing saved yet starts from the downtime alert time stored on the machine, and whatever you type replaces it. Set the warning row to the stop length you want to hear about and the critical row to the stop length that means something is properly wrong, for example 15 minutes and 45 minutes. Set the warning threshold above your normal changeover. A five-minute threshold on a machine that changes over in twelve emails all day, and you will turn it off by Thursday. > **Info:** > **Is this the same as the status color thresholds?** No. The two durations behind green, orange and red on the Assets page are organization-wide and cosmetic, and changing them alerts nobody, see [Set status colors and downtime thresholds](/docs/monitoring/status-colors/). The thresholds here belong to this machine and decide when it tells someone. **Machine Up** has no threshold. It is the closing bracket on a **Machine Down** alert, which is why it depends on it: switching **Machine Down** at the warning time off for yourself on a channel also switches **Machine Up** off on that channel, and leaves the **Machine Up** switch disabled until you turn the warning row back on. ![The MACHINE STATUS section of the Event Notifications modal, cropped to three rows. The first row shows an amber WARNING chip with a Time threshold of 15 min(s), the second a red CRITICAL chip with 45 min(s), the third the title Machine Up with no threshold field at all. Callout 1 marks the warning row, callout 2 marks the critical row, callout 3 marks the Machine Up row](/images/alerts/alr-rules-02.webp) *Machine status events. Turning off Machine Down warning also turns off Machine Up on that channel.* ## Connectivity events **Connectivity** holds one rule, **Device Offline**, and it appears on every device type IoTFlows sells. It fires when the device stops reporting for the time threshold, which defaults to 10 minutes. A device that stops reporting is not the same as a machine that stopped. The machine keeps reading as stopped, because the card shows the last state the cloud recorded, and it is the status bar that grays out for the stretch with no data. See [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). Leave the threshold at 10 minutes unless the machine sits somewhere with known weak coverage. Shortening it to 2 minutes on a machine at the edge of an access point's range turns one flaky afternoon into forty alerts. ![The CONNECTIVITY section of the Event Notifications modal, one row titled Device Offline over the description Triggered when the device loses internet or power. A Time threshold field reads 10 with the suffix min(s) beside it, ringed by a violet highlight](/images/alerts/alr-rules-03.webp) *Device Offline. Available on every device type.* ## Shock events **Shock Events** holds **Abnormal Shock Detection**, which fires when acceleration at the sensor passes a threshold in g. The field accepts 20 to 100, in steps of 1, and starts at 100 g. This threshold is not stored with the rule. It is written to the sensor itself, so changing it here changes the device, and every reading the device reports afterward is judged against the new number. A successful save confirms with **Shock Acceleration Threshold has been changed** rather than the **Threshold updated** the other rows show. The default of 100 g, the top of the range, only flags severe impacts. Lower it toward 20 g to catch smaller shocks too, but go carefully: a press that reports a 45 g shock on every stroke is not faulting, it is a press, and a threshold set below its normal stroke turns every cycle into an alert. ![The SHOCK EVENTS section of the Event Notifications modal, one row titled Abnormal Shock Detection over the description Get notification once asset experiences abnormal shocks. A Vibration threshold field reads 100 with the suffix g beside it, followed by the six channel columns: Email, Push, SMS, Log (on), Work Order and Integrations](/images/alerts/alr-rules-04.webp) *Abnormal shock detection. This threshold is stored on the sensor, so changing it changes the device.* ## Health events **Health Score** holds three rules that watch the same number falling: **Caution Health Alert** at 60%, **Warning Health Alert** at 40% and **Critical Health Alert** at 20%. The health score itself is explained in [Monitor machine health and vibration](/docs/monitoring/machine-health/). Their thresholds are fixed. The percentages are shown for reference and the modal offers no field to change them, so the only decision on these three rows is which channels carry them. Enable the **Warning Health Alert**, not the critical one, as your first health rule. Critical fires at 20%, which on most machines is after the failure you were trying to prevent. Add the caution rule at 60% to the event log only, where it builds a trend without buzzing anybody. ![The HEALTH SCORE section of the Event Notifications modal, three rows. Each shows a severity chip in place of a title and a description naming the percentage. Callout 1 marks the yellow CAUTION row reading Triggered when health score falls below 60%, callout 2 the amber WARNING row at 40%, callout 3 the red CRITICAL row at 20%. None of the three has a threshold field](/images/alerts/alr-rules-05.webp) *The three health alerts. Their thresholds are fixed and not editable.* ## Temperature events **Temperature** holds **Warning Temperature** and **Critical Temperature**, which fire when the sensor's temperature passes their thresholds. The defaults are 70 °C and 80 °C. Each row carries a unit button beside its field showing the unit you are not in. Click it to switch the whole modal between Celsius and Fahrenheit, and the thresholds convert with it: 70 °C reads as 158 °F. The choice is a preference of the browser you are working in, so a colleague opening the same machine may see the other unit. IoTFlows stores the threshold in whole degrees Celsius. A Fahrenheit value is converted and rounded on the way in, so typing 101 °F stores 38 °C and the field reads 100 °F when it comes back. > **Warning:** > **Critical must be higher than warning.** Set the critical threshold below the warning one and a red line reads **Critical must be higher than warning** under the two rows. The message does not block the save. Both values are written as typed, and the critical alert then fires before the warning alert, so correct it before you close the modal. ![The TEMPERATURE section of the Event Notifications modal, two rows. Callout 1 marks the amber WARNING row with a Temperature threshold field reading 70, the suffix °C, and a small °F button beside it. Callout 2 marks the red CRITICAL row with the same controls reading 80](/images/alerts/alr-rules-06.webp) *Temperature alerts. Thresholds follow your Celsius or Fahrenheit preference.* ## Channels Every event type offers the same six columns, and each one is independent of the others. | Column | What it does | Scope | |---|---|---| | **Email** | Emails the event | Per person, through the subscriber list | | **Push** | Sends a phone notification | Per person, through the subscriber list | | **SMS** | Texts the event | Per person, through the subscriber list | | **Log** | Records the event on the machine | The whole machine | | **Work Order** | Opens a maintenance work order | The whole machine | | **Integrations** | Posts to a chat channel or webhook | The whole machine | The split matters. **Email**, **Push** and **SMS** reach people through a subscriber list, where a *subscriber* is one member signed up to one event type on one machine. **Log**, **Work Order** and **Integrations** are settings on the machine, so switching one on changes what everybody sees. Choose SMS only for events someone must act on within the hour. Every channel you add to a rule lowers the attention the rule gets, and a plant where every event buzzes a phone stops reading any of them. ## Email, push and SMS subscriber lists As an Owner or Administrator, the three personal columns are not switches. Each cell is a stack of avatars showing who is subscribed, and a dashed circle with a **+** when nobody is. 1. Click the cell in the **Email**, **Push** or **SMS** column of the row you want. 2. Search the organization in **Search members...** if the list is long. You are sorted to the top. 3. Click a member to subscribe them. Click a subscribed member to remove them. Each change saves on its own and confirms with the member's first name, for example **Maria subscribed**. Close the dropdown when you are done. **The list belongs to the event type, not to the machine's rules as a whole.** Subscribing someone to **Machine Down** tells them nothing about **Device Offline** on the same machine, and this is the single most common reason a rule that looks correct reaches nobody. Members who are not Owners or Administrators see the same three columns as plain switches, which subscribe and unsubscribe only themselves. That is what the footer line means when it reads that email, push and SMS are personal to you. > **Info:** > **Why is a member grayed out in the SMS list?** SMS needs a verified phone number on the recipient's account. A member without one is listed as **No phone number** and cannot be added, and clicking them reports **This user has not added their phone number**. A member who has opted out of texts is listed as **Opted Out**. See [Change your phone number](/docs/admin/phone-number/). ![One event row with the three personal columns populated. Callout 1 marks the Email cell showing three overlapping avatars and a +2 chip, callout 2 marks the Push cell showing two avatars, callout 3 marks the SMS cell showing one avatar. An open dropdown below lists organization members with a Search members field at the top, a check beside each subscribed member and a No phone number label beside one grayed row](/images/alerts/alr-rules-07.webp) *Subscriber lists are per event type. This is the most common reason an alert reaches nobody.* ## Log the event **Log** records the event against the machine without telling anyone. Switch it on and the event joins the **Event Alerts** list on the machine's Health tab, where it stays until somebody dismisses it, see [Review and dismiss machine events](/docs/monitoring/asset-events/). Turn **Log** on for every event type you care about, including the ones you do not want notifications for. It costs no one's attention, and it is what makes "this machine has thrown four caution health alerts this month" a question you can answer. An event type with **Log** off sends its notifications and leaves no record. A machine with an empty event list and an obvious problem usually has a rule notifying but not logging. ## Create a work order automatically **Work Order** opens a maintenance work order each time the event fires. The column header carries **Maintenance** under it: the work order lands on your organization's maintenance board, see [Organize work on the maintenance board](/docs/maintain/maintenance-board/). The rule carries no assignee and no board picker, so the work order arrives unassigned and somebody has to pick it up. Give the board a routine for triaging what arrives before you switch this on for anything that fires often. You do not need an auto work order on every event. Turn it on for events with one obvious response, such as a bearing fault, and leave it off for events that need a person to decide, or you will spend the first month closing work orders nobody opened. **Machine Down** and **Device Offline** are the two to leave off: both fire routinely and usually mean a changeover, a jam or a network, not a repair. ## Attach an organization integration **Integrations** sends the event to a chat channel or your own endpoint. An *integration* is a destination your organization has already set up, such as a Slack channel or a Teams webhook, created once in Organization Settings and reused across machines, see [Send alerts to Slack, Teams, or Discord](/docs/alerts/chat-integrations/). 1. Click the cell in the **Integrations** column of the row you want. 2. Search in **Search integrations...** if you have several. 3. Click an integration to attach it, and click it again to detach it. Attaching confirms with **Production line alerts connected** and detaching with **Production line alerts disconnected**, using the integration's name. An integration that has been disabled in Organization Settings is still listed, dimmed and tagged **Disabled**, and sends nothing until it is enabled again. With nothing set up the dropdown reads **No integrations yet**. You do not need an integration to get alerts. Email and push work with nothing configured beyond a subscriber list. ## Which sections you see for which device The modal hides the sections the device cannot produce, so two machines in the same organization do not offer the same rules. | Section | SenseAi | SenseAi Embedded | BeamTracker | |---|---|---|---| | **Machine Status** | Yes | Yes | Yes | | **Connectivity** | Yes | Yes | Yes | | **Shock Events** | Yes | Yes | No | | **Health Score** | Firmware 5 or later | Firmware 5 or later | No | | **Temperature** | Firmware 5 or later | Firmware 5 or later | No | A BeamTracker counts units passing a point rather than reading a machine's own vibration, so it produces no health score, no temperature and no shock reading, and its modal is two sections long. A SenseAi on firmware below 5 keeps shock but loses health and temperature; ask IoTFlows to update the device, see [Get support](/docs/get-started/get-support/). If the event type you are looking for is not in the list, check the device before you check anything else. It is the reason more often than a permission is. ![The Event Notifications modal opened on a BeamTracker asset. Only two sections are drawn, MACHINE STATUS with three rows and CONNECTIVITY with one, and the panel ends at the footer. A violet highlight marks the empty space below the Connectivity section where the Shock, Health Score and Temperature sections appear for a SenseAi](/images/alerts/alr-rules-09.webp) *The same modal on a BeamTracker: machine status and connectivity only, with no health, temperature or shock.* ## Errors | Message | Cause | Do this | |---|---|---| | **Failed to update event type** | A channel switch, **Log**, **Work Order** or a threshold did not save. The switch flips back to where it was | Retry. Nothing was changed | | **Failed to update email subscription** | A member was not added to or removed from the email list. The avatar pile reverts | Retry, then reopen the modal to confirm the list | | **Failed to update push subscription** | The same, for the push list | Retry, then reopen the modal to confirm the list | | **Failed to update SMS subscription** | The same, for the SMS list | Retry, then reopen the modal to confirm the list | | **This user has not added their phone number** | You tried to add an SMS subscriber with no phone number on their account | Ask them to add and verify one, see [Change your phone number](/docs/admin/phone-number/) | | **Failed to update integrations** | The integration was not attached or detached. The avatar pile reverts | Retry. Check the integration still exists in Organization Settings | | A shock threshold save fails | The spinner on the field keeps turning and the typed value stays on screen | Close the modal and reopen it to see the value that actually saved | | A threshold you typed is not saved | The value is written when the field loses focus. Closing the modal with the keyboard skips that | Retype it, click outside the field, and wait for **Threshold updated** | | The alert reached nobody | The channel is on but the event type's subscriber list is empty | Open the cell in that column on that row and add people, see [Email, push and SMS subscriber lists](#subscribers) | A generic **Something went wrong** or **An error occurred** means the request failed and the change was not saved. Retry it, and if it keeps failing see [Troubleshoot alerts you did not receive](/docs/alerts/troubleshoot-alerts/). ## See also - [Event types and channels](/docs/alerts/event-types-reference/) - [Troubleshoot alerts you did not receive](/docs/alerts/troubleshoot-alerts/) - [Turn on push notifications on your phone](/docs/alerts/mobile-push/) - [Send alerts to Slack, Teams, or Discord](/docs/alerts/chat-integrations/) - [Review and dismiss machine events](/docs/monitoring/asset-events/) --- # Send alerts to Slack, Teams, or Discord Source: https://www.iotflows.com/docs/alerts/chat-integrations/ Create a chat integration on the Integrations page from a webhook URL you generate in Microsoft Teams, Discord or Slack, name it, send it a test event, then attach it to the Integrations column of the event rules on each machine that should reach that channel. # Send alerts to Slack, Teams, or Discord Post IoTFlows alerts into the channel your team already watches. An *integration* is a named destination your organization creates once and reuses on any machine. Each one holds a *webhook URL*, an address the chat platform gives you that posts a message into one channel when something sends to it. IoTFlows does not sign in to Slack, Teams or Discord: you generate the URL there, paste it here, and IoTFlows posts to it. **Prerequisites.** Owner or Administrator, see [Roles and permissions](/docs/admin/roles-reference/). Every other role sees **Integrations** in the navigation dimmed and unclickable, with the tooltip **You must be an Organization Owner or Administrator to access Integrations**. You also need permission to create a webhook in the chat platform itself, which is a separate permission held by that platform. ## How chat integrations work Open **Integrations** in the navigation, at `/integrations`. The page lists every integration the organization has, sorted by name, each card carrying the platform's icon, the name, who created it and when, and an **Enabled** or **Disabled** chip. One integration is one destination channel, not one machine. Create **Production line alerts** once, then attach it to the **Machine Down** rule on all twelve presses. Attaching is per event type and per machine, and it is done in the machine's own notification settings rather than here, see [Attach the integration to an event rule](#attach). Send alerts to the channel the shift already reads, not to a new `#alerts` channel. A dedicated alerts channel is muted within a week. You do not need one integration per machine, and you do not need an integration at all if email and push already reach the right people, see [Overview: alerts and integrations](/docs/alerts/overview/). ![The Integrations page at full width, headed Integrations over Connect IoTFlows with the tools your team already uses, with a blue round plus button at the top right, a Search integrations field below it, and three integration cards. Each card shows a platform icon, a name, a created-on line with the author's avatar, and a status chip. The third card's chip reads Disabled](/images/alerts/alr-int-01.webp) *The Integrations page. Non-admins see the nav item dimmed and unclickable.* Click the blue **+** button at the top right to open **New Integration**. The first step is **Choose a platform**, one tile per platform under an **Alerts** heading. Choosing a tile opens the setup step, which carries that platform's instructions inline. The three sections below mirror them so you can read them before you start. ## Create a Microsoft Teams integration Teams has no plain incoming webhook any more. The URL comes from a Power Automate workflow attached to the channel. 1. In Teams, open the channel where you want messages posted. 2. Click the channel's **⋯** menu, then choose **Workflows**. 3. Select **Send webhook alerts to a channel**. Use **Send webhook alerts to a chat** instead if you want messages in a 1:1 or group chat. 4. Sign in to both Teams and Power Automate when prompted, then click **Next**. 5. Confirm the team and channel, then click **Add workflow**. 6. Copy the generated workflow URL and paste it into **Webhook URL** in IoTFlows. You need to be a team member with permission to create Workflows in the channel. If **Workflows** is missing from the **⋯** menu, ask a team owner to grant access or to create the workflow and send you the URL. ![The New Integration modal on its second step, headed Connect Microsoft Teams, showing a blue Admin permission may be required note, six numbered setup steps ending in copying the generated workflow URL, an Official docs link at the top right of the panel, and the Webhook URL field below it](/images/alerts/alr-int-02.webp) *The in-product Microsoft Teams setup instructions.* ## Create a Discord integration 1. In Discord, find the channel that should receive messages. 2. Hover the channel name and click the **Edit Channel** gear icon, or right-click the channel and choose **Edit Channel**. 3. In the sidebar, choose **Integrations**. 4. Click **Webhooks**, then **New Webhook**. 5. Rename the webhook or set an avatar if you want. The channel is already set to this one. 6. Click **Copy Webhook URL** and paste it into **Webhook URL** in IoTFlows. You need the **Manage Webhooks** permission in that channel, which is usually granted to admins or to specific roles. If **Integrations** does not appear in **Edit Channel**, you do not have it: ask a server admin to add the webhook or to grant your role access. Discord rate-limits each webhook to 30 messages per minute. A single integration attached to a hundred machines can pass that during a plant-wide outage, and the messages over the limit are dropped by Discord rather than queued. ![The New Integration modal on its second step, headed Connect Discord, with six numbered setup steps from Edit Channel through Copy Webhook URL and a closing italic tip reading that the URL should be kept private and that Discord rate-limits to 30 messages per minute per webhook](/images/alerts/alr-int-03.webp) *The Discord setup instructions, including its 30-messages-per-minute webhook limit.* ## Create a Slack integration Slack issues incoming webhooks from an app, so you create a small app in your workspace first. 1. Go to `https://api.slack.com/apps` and click **Create New App**, then **From scratch**. 2. Name the app, pick your workspace, then click **Create App**. 3. In the sidebar, open **Incoming Webhooks** and toggle **Activate Incoming Webhooks** to On. 4. Click **Add New Webhook to Workspace**. 5. Select the channel that should receive messages, then click **Allow**. 6. Copy the new webhook URL, which starts with `https://hooks.slack.com/services/`, and paste it into **Webhook URL** in IoTFlows. For a private channel, join the channel before step 5. Slack does not list a channel you are not in, so the authorization screen looks as though the channel does not exist. Your workspace may restrict who can install apps. An approval-required message after **Create App** means a workspace admin has to approve the request before you can activate the webhook. ![The New Integration modal on its second step, headed Connect Slack, with six numbered setup steps from Create New App through copying a URL beginning https://hooks.slack.com/services/, and a closing italic tip reading that private channels must be joined first or Slack will not list them during authorization](/images/alerts/alr-int-04.webp) *The Slack setup instructions. For a private channel, join it before authorizing.* ### Platforms | Platform | Webhook created in | You need | Rate limit | Gotcha | |---|---|---|---|---| | **Microsoft Teams** | The channel's **⋯** menu, under **Workflows**, which runs on Power Automate | Permission to create Workflows in that channel | None stated in IoTFlows | Pick **Send webhook alerts to a channel**, not the chat variant, unless you want a 1:1 | | **Discord** | **Edit Channel** → **Integrations** → **Webhooks** | The **Manage Webhooks** permission in that channel | 30 messages per minute, per webhook | A missing **Integrations** item in **Edit Channel** means you lack the permission | | **Slack** | An app at `api.slack.com/apps`, under **Incoming Webhooks** | Permission to install apps in the workspace, which many workspaces gate behind admin approval | None stated in IoTFlows | Slack will not list a private channel unless you joined it first | Every row shares one gotcha: the webhook URL is the only secret involved. Anyone holding it can post into that channel as your integration, so treat it the way you treat a password, and do not paste it into a ticket or a chat message. ## Name the integration The name field sits above the setup instructions, so you can fill it before or after you fetch the URL. Neither field has a default and **Create Integration** stays disabled until both carry a value. 1. Type a name in **Integration name**. The placeholder reads `e.g. Production line alerts`. 2. Paste the URL into **Webhook URL**, whose placeholder reads `https://...`. 3. Click **Create Integration**, or press Cmd+Enter on a Mac or Ctrl+Enter elsewhere. Name the integration after the channel it posts to, not after the machines that use it: `#line-2-floor` survives a machine being sold, `Press 4 alerts` does not. The new integration appears at the top of the list and a toast reads **Integration created**. ![A cropped detail of the New Integration modal showing two fields. Callout 1 marks the Integration name field holding Production line alerts, callout 2 marks the Webhook URL field below it holding a redacted https URL behind a link icon](/images/alerts/alr-int-05.webp) *The integration name and its webhook URL. Treat the URL as a secret.* ## Send a test event Test before you attach the integration to anything. A wrong URL fails silently at alert time, and nobody notices for a week. 1. Click the integration's card to expand it. 2. Click **Test integration**. The button reads **Sending...** while it runs. 3. A toast reads **Test event sent**. Now check the channel. **Test event sent** means IoTFlows reached the URL, not that the message arrived. If the toast succeeds and nothing appears in the channel, the webhook was revoked at the platform end: the Teams workflow was turned off, the Discord webhook was deleted, or the Slack app was uninstalled. Create a new webhook there and paste the new URL in, see [Rename or change the URL](#edit). ![The Integrations page with one card expanded, showing its Name and Webhook URL fields, an Enabled toggle switched on, and an action row carrying Delete Webhook on the left and Test integration and Save changes on the right. A violet highlight marks Test integration, and a Test event sent toast sits over the header above](/images/alerts/alr-int-06.webp) *Sending a test event before you rely on it.* ## Attach the integration to an event rule Creating an integration sends nothing on its own. Every message comes from an event rule on a machine that has this integration attached to it. 1. Open the machine and click the bell in its header, labeled **Event Notifications**. 2. Find the row for the event type, such as **Machine Down**. 3. Click the cell in the **Integrations** column, on the right, under the **Webhooks** sub-label. 4. Click the integration in the list. Search by name in **Search integrations...** if the list is long. The cell writes immediately and confirms with **Production line alerts connected**, using the integration's name. Click it again to detach, which confirms with **Production line alerts disconnected**. An attached integration shows as an icon in the cell, up to three, then a `+2` chip. Full rule detail is on [Set alert rules for a machine](/docs/alerts/asset-event-rules/#integrations). ![The right end of the Event Notifications modal, showing the LOG, WORK ORDER and INTEGRATIONS column headers over the Machine Down warning row, whose Integrations cell now carries a Discord icon. The dropdown the cell opened lists three integrations with their platform icons above a Search integrations field, the first checked and marked with a violet highlight, the third tagged Disabled and dimmed](/images/alerts/alr-int-07.webp) *Attaching an integration to an event rule, from the machine's notification settings.* A machine with no integrations in the organization shows **No integrations yet** in that dropdown, with a **Create integration** link back to this page. ## Rename or change the URL Both fields are editable on the card, and both save together. 1. Click the card to expand it. 2. Edit **Name**, **Webhook URL**, or both. 3. Click **Save changes**. The button stays disabled until something changes. A toast reads **Integration updated**. Changing the URL keeps every attachment: the rules pointing at this integration now post to the new channel, with nothing to redo on any machine. That makes an edit the right move when a channel is renamed or a webhook is rotated, and a new integration the wrong one. ## Enable, disable or delete The same expanded card carries an **Enabled** toggle, described as **Allow this integration to receive events**. Disable rather than delete when you want the destination back. A disabled integration stays attached to every rule and stops posting, and it still appears in the per-event dropdown, dimmed and tagged **Disabled**, so a rule that looks configured sends nothing. Turn it back on and the same rules resume. Delete when the channel is gone for good. Click **Delete Webhook** on the expanded card and confirm in **Delete Integration**, which warns that the action cannot be undone and that the webhook URL stops receiving events immediately. Deleting removes the integration from every rule that used it, and the rules themselves stay switched on with nothing in the **Integrations** column. Quiet a noisy channel for a night by disabling the integration, not by deleting it. Deleting loses which machines were attached, and nothing records the list. ## Errors | Message | Cause | Do this | |---|---|---| | **Failed to create integration** | The integration was not created. Nothing was saved | Check the URL is complete and starts with `https://`, then retry | | **Failed to update integration** | A name, URL or enabled change did not save. The card keeps your typed values | Retry, then collapse and reopen the card to see what actually saved | | **Failed to delete integration** | The integration is still there | Retry. Refresh the page before deciding it failed | | **Failed to send test event** | IoTFlows could not reach the webhook URL | Confirm the webhook still exists in the platform and that the URL is pasted whole | | **Failed to update integrations** | Attaching or detaching on a machine's rule failed. The cell reverts | Retry. Confirm the integration still exists on this page | | **Test event sent**, but nothing in the channel | The URL is valid in shape and revoked at the platform end | Create a new webhook in Teams, Discord or Slack and paste the new URL in | A generic **Something went wrong** or **An error occurred** means the request failed and the change was not saved. Retry it, and if it keeps failing see [Troubleshoot alerts you did not receive](/docs/alerts/troubleshoot-alerts/). ## See also - [Set alert rules for a machine](/docs/alerts/asset-event-rules/) - [Send events to your own endpoint](/docs/alerts/webhooks/) - [Troubleshoot alerts you did not receive](/docs/alerts/troubleshoot-alerts/) - [Roles and permissions](/docs/admin/roles-reference/) --- # Event types and channels Source: https://www.iotflows.com/docs/alerts/event-types-reference/ The full lookup for machine alerts: all ten event types with their on-screen titles, what fires each one, the threshold it takes and that threshold's default, the six channels every event offers, which sections each device type shows, and which three channels go through a per-event subscriber list. # Event types and channels Every event type IoTFlows watches for, what fires it, its threshold, and the channels it can be delivered through. An *event type* is one named condition on one machine, such as **Device Offline**. There are ten of them, the list is fixed, and every machine carries all ten. You switch them on per machine in **Event Notifications**, see [Set alert rules for a machine](/docs/alerts/asset-event-rules/). This page is the lookup. It reproduces the matrix as the modal ships it, so you can check a default or a device restriction without opening a machine. ## Event types The key in the first column is the identifier IoTFlows uses internally. It never appears on screen, but support quotes it, and it is the only unambiguous way to name the two **Machine Down** rows apart. | Key | On-screen title | Section | Description on the row | Severity | |---|---|---|---|---| | `aet_downtime_warning` | **Machine Down** | Machine Status | Triggered when asset stops running for specified duration | WARNING | | `aet_downtime_critical` | **Machine Down** | Machine Status | Triggered when asset stops running for specified duration | CRITICAL | | `aet_machine_up` | **Machine Up** | Machine Status | Get notification once asset is running again | None | | `aet_offline_warning` | **Device Offline** | Connectivity | Triggered when the device loses internet or power | None | | `aet_shock_critical` | **Abnormal Shock Detection** | Shock Events | Get notification once asset experiences abnormal shocks | None | | `aet_health_score_caution` | **Caution Health Alert** | Health Score | Triggered when health score falls below 60% | CAUTION | | `aet_health_score_warning` | **Warning Health Alert** | Health Score | Triggered when health score falls below 40% | WARNING | | `aet_health_score_critical` | **Critical Health Alert** | Health Score | Triggered when health score falls below 20% | CRITICAL | | `aet_temperature_warning` | **Warning Temperature** | Temperature | Triggered when temperature exceeds warning threshold | WARNING | | `aet_temperature_critical` | **Critical Temperature** | Temperature | Triggered when temperature exceeds critical threshold | CRITICAL | *Severity* is the seriousness IoTFlows assigns the event, drawn as a colored chip reading **CAUTION**, **WARNING** or **CRITICAL**. Where a row has one, the chip **replaces** the title instead of sitting beside it. That is why the modal shows no visible heading for the two **Machine Down** rows or the three health rows: you identify them by the chip and the description. The health score behind the last group of three is explained in [Monitor machine health and vibration](/docs/monitoring/machine-health/). ## Channels Every event type offers the same six channels, with no exceptions, so this table is a uniform yes. What differs between channels is who they reach and where the setting lives. | Channel | Column header | Reaches | Scope | |---|---|---|---| | Email | **EMAIL** | The event type's email subscribers | Per person | | Push | **PUSH** | The event type's push subscribers, on the mobile app | Per person | | SMS | **SMS** | The event type's SMS subscribers, who each need a verified phone number | Per person | | Log | **LOG** | Nobody. It records the event on the machine's Health tab | The whole machine | | Work order | **WORK ORDER**, sub-labeled `Maintenance` | The maintenance board. The work order arrives unassigned | The whole machine | | Integrations | **INTEGRATIONS**, sub-labeled `Webhooks` | The chat integrations you attach to that row | The whole machine | ### Channels by event | Event | Email | Push | SMS | Log | Work order | Integrations | |---|---|---|---|---|---|---| | **Machine Down** (warning) | Yes | Yes | Yes | Yes | Yes | Yes | | **Machine Down** (critical) | Yes | Yes | Yes | Yes | Yes | Yes | | **Machine Up** | Yes, coupled | Yes, coupled | Yes, coupled | Yes | Yes | Yes | | **Device Offline** | Yes | Yes | Yes | Yes | Yes | Yes | | **Abnormal Shock Detection** | Yes | Yes | Yes | Yes | Yes | Yes | | **Caution Health Alert** | Yes | Yes | Yes | Yes | Yes | Yes | | **Warning Health Alert** | Yes | Yes | Yes | Yes | Yes | Yes | | **Critical Health Alert** | Yes | Yes | Yes | Yes | Yes | Yes | | **Warning Temperature** | Yes | Yes | Yes | Yes | Yes | Yes | | **Critical Temperature** | Yes | Yes | Yes | Yes | Yes | Yes | > **Info:** > **What does "coupled" mean on Machine Up?** Switching **Machine Down** at the warning time off on a channel also switches **Machine Up** off on that channel, and disables its switch until you turn the warning row back on. The coupling runs one way and off only. Turning the warning row on does not turn **Machine Up** on. Turn **Log** on for every event type you care about, including ones you want no notification for. It costs nobody's attention and it is what makes the event countable later, see [Review and dismiss machine events](/docs/monitoring/asset-events/). You do not need **Integrations** to get alerts. Email and push work with nothing configured beyond a subscriber list, and an integration is worth creating only once a team is already watching a Slack, Teams or Discord channel, see [Send alerts to Slack, Teams, or Discord](/docs/alerts/chat-integrations/). ## Thresholds and defaults A *threshold* is the number the condition is measured against. Six of the ten event types take one you can edit, three show a fixed percentage, and one has none. | Event | Field label | Unit | Default | Editable | Limits | |---|---|---|---|---|---| | **Machine Down** (warning) | Time threshold | `min(s)` | The machine's own downtime alert time | Yes | Whole minutes, 0 or more | | **Machine Down** (critical) | Time threshold | `min(s)` | The machine's own downtime alert time | Yes | Whole minutes, 0 or more | | **Machine Up** | None | — | — | — | — | | **Device Offline** | Time threshold | `min(s)` | 10 | Yes | Whole minutes, 0 or more | | **Abnormal Shock Detection** | Vibration threshold | `g` | 100 | Yes | 20 to 100, in steps of 1 | | **Caution Health Alert** | Threshold | `%` | 60 | No | Shown for reference, no input | | **Warning Health Alert** | Threshold | `%` | 40 | No | Shown for reference, no input | | **Critical Health Alert** | Threshold | `%` | 20 | No | Shown for reference, no input | | **Warning Temperature** | Temperature threshold | `°C` or `°F` | 70 °C (158 °F) | Yes | Stored in whole °C, rounded on conversion | | **Critical Temperature** | Temperature threshold | `°C` or `°F` | 80 °C (176 °F) | Yes | Stored in whole °C, rounded on conversion | Four details a lookup has to carry: - **The shock threshold is stored on the sensor, not on the rule.** Changing it writes to the device, so every reading the device reports afterward is judged against the new number, and the confirmation reads **Shock Acceleration Threshold has been changed** rather than the **Threshold updated** every other row shows. - **The two Machine Down defaults come from the machine**, not from a constant, so a machine whose downtime alert time has never been set starts both rows at 0. - **The temperature unit is a preference of the browser you are in**, not of your account. A colleague opening the same machine may see the other unit. - **Thresholds save on blur.** Type the value, then click outside the field and wait for the confirmation. > **Warning:** > **Critical must be higher than warning.** Set a critical temperature below the warning one and a red line reads **Critical must be higher than warning**. It does not block the save. Both values are written as typed, and the critical alert then fires before the warning alert. ## Availability by device The modal hides the sections the device cannot produce, so two machines in the same organization do not offer the same event types. | Section | SenseAi | SenseAi Embedded | BeamTracker | |---|---|---|---| | Machine Status | Yes | Yes | Yes | | Connectivity | Yes | Yes | Yes | | Shock Events | Yes | Yes | No | | Health Score | Firmware 5 or later | Firmware 5 or later | No | | Temperature | Firmware 5 or later | Firmware 5 or later | No | A BeamTracker counts units passing a point rather than reading a machine's own vibration, so it produces no shock, health or temperature reading and its modal is two sections long. A SenseAi below firmware 5 keeps shock but loses health and temperature. **If an event type is missing, check the device before you check anything else.** It is the reason far more often than a permission is. To move a machine off firmware below 5, see [Get support](/docs/get-started/get-support/). ## Subscriber lists Email, push and SMS do not reach "the machine's watchers". Each of those three channels on each of the ten event types carries its own list, so one machine holds thirty independent lists. A *subscriber* is one member signed up to one channel on one event type on one machine. Subscribing someone to **Machine Down** tells them nothing about **Device Offline** on the same machine. | Question | Answer | |---|---| | Who edits the list | Owners and Administrators, see [Roles and permissions](/docs/admin/roles-reference/) | | What everyone else sees | The same three columns as plain switches, subscribing only themselves | | What an empty list does | Nothing, silently. The channel is on and the alert reaches nobody | | Why a member cannot be added to SMS | No verified phone number, listed as **No phone number**, or listed as **Opted Out**, see [Change your phone number](/docs/admin/phone-number/) | | Whether the list follows the person across machines | No. Lists are per machine | An empty subscriber list is the single most common cause of an alert that should have fired and did not, see [Troubleshoot alerts you did not receive](/docs/alerts/troubleshoot-alerts/). ## See also - [Set alert rules for a machine](/docs/alerts/asset-event-rules/) - [Troubleshoot alerts you did not receive](/docs/alerts/troubleshoot-alerts/) - [Monitor machine health and vibration](/docs/monitoring/machine-health/) - [Choose a machine health baseline profile](/docs/monitoring/baseline-profiles/) - [Review and dismiss machine events](/docs/monitoring/asset-events/) --- # Turn on push notifications on your phone Source: https://www.iotflows.com/docs/alerts/mobile-push/ Push is the only IoTFlows channel that reaches someone away from a screen. Allow the operating system permission, see which three things send push (machine event alerts, work orders and their comments, and chat messages), where each notification opens when you tap it, how a notification from a second organization is routed, and the Android sign-out defect that stops push arriving until the app is reinstalled. # Turn on push notifications on your phone Get alerts, work orders and messages on your phone, and know where each one opens. The IoTFlows app delivers push through Apple's Push Notification service on iOS and Firebase Cloud Messaging on Android. The app registers with the service when you sign in, so the only switch you hold is the operating system's notification permission. Push reaches the apps only. The web dashboard sends no browser notification, so somebody who works at the dashboard all day still needs email or SMS. Before you start, you need: - The app installed and signed in, see [Install the mobile app](/docs/get-started/install-mobile-app/). - **Push** switched on for the events you care about, with your name on that event type's push subscriber list, see [Email, push and SMS subscriber lists](/docs/alerts/asset-event-rules/#subscribers). ## Allow notifications The app asks for permission the first time it launches, and [Install the mobile app](/docs/get-started/install-mobile-app/#notifications) covers that prompt. If you declined it, or you inherited the phone, set it in the operating system: - **iOS:** open **Settings**, select **Notifications**, select **IoTFlows**, and turn **Allow Notifications** on. - **Android:** open **Settings**, select **Apps**, select **IoTFlows**, select **Notifications**, and turn notifications on. ![The iOS system dialog over the IoTFlows app asking whether IoTFlows may send notifications, with a violet highlight on the Allow button beside Don't Allow](/images/alerts/alr-push-01.webp) *Granting notification permission. Denied permission fails silently on every rule.* > **Warning:** > **Why does nothing warn me?** Grant the permission during install, not later. A rule with **Push** enabled and permission denied fails silently: the event fires, and nothing in the product shows that the message never reached the phone. You do not need push on every operator's phone. Push is per person, through a subscriber list, so a phone belonging to nobody on a list receives no alerts however the permission is set. ## What sends push Three things send push, from different parts of the product. **Machine event alerts.** Any of the ten event types, when **Push** is on for that event on that machine and you are on its push subscriber list. This is the only family you configure, and you configure it on the web, see [Set alert rules for a machine](/docs/alerts/asset-event-rules/). ![An iPhone lock screen carrying one IoTFlows notification. Its title is the machine's name, and the body reads that the asset has not been utilized for more than the set threshold, with the threshold in minutes in parentheses](/images/alerts/alr-push-02.webp) *A machine-down alert arriving on the lock screen.* **Work orders and their comments.** Maintenance and production work you are involved in, and comments added to it. **Chat messages.** Messages in a conversation you belong to. These are rendered communication-style, so the sender's avatar and name sit on the notification rather than the app's icon. ![An iPhone lock screen carrying one IoTFlows notification rendered in the communication style: the sender's circular photo stands where the app icon would be, badged with the IoTFlows mark, with the sender's name above the message text](/images/alerts/alr-push-04.webp) *Chat notifications are rendered communication-style, with the sender's avatar.* ## Where each notification opens Every IoTFlows notification is a *deep link*: tapping it opens the app at the record it is about, not at the home screen. | Notification | Sent when | Opens | Client | |---|---|---|---| | Machine event alert | An event type with **Push** on fires, and you are on its push subscriber list | That machine | iOS, Android | | Work order | A work order you are involved in is created or changes | That work order | iOS, Android | | Work-order comment | Somebody comments on a work order you are involved in | That work order's comments | iOS, Android | | Chat message | Somebody posts in a conversation you belong to | That conversation | iOS, Android | A comment notification lands on the thread itself, so you can reply without scrolling the record. ![An iPhone lock screen carrying one IoTFlows notification. Its title is the commenter's name followed by the work order's title in parentheses, truncated; the body beneath is the first line of the comment](/images/alerts/alr-push-03.webp) *A work-order comment notification. The title carries the work order, the body the comment.* ## Notifications from another organization If your account belongs to more than one organization, push arrives from all of them, and the app routes each notification to the organization that owns the record before opening it. You do not switch organizations first. For a contractor covering several plants, a machine-down alert from the second plant opens that plant's machine, and the app stays there until you switch back, see [Switch organizations](/docs/get-started/switch-organizations/). ## Marking as read Opening a record clears its notification from the phone. Reading a chat conversation clears the messages already delivered for it, so a thread you have caught up on leaves no stack behind. Machine event alerts are separate from the **Event Alerts** list on a machine's Health tab. Clearing a notification clears nothing for anybody else, and dismissing the logged event is its own action on the web, see [Review and dismiss machine events](/docs/monitoring/asset-events/). ## If push stops arriving Check three things in order: notification permission on the phone, **Push** on for that event on that machine, and your name on that event type's push subscriber list. The list is the usual answer, because it belongs to one event type rather than to the machine, see [Troubleshoot alerts you did not receive](/docs/alerts/troubleshoot-alerts/#push). > **Warning:** > **Push stopped after signing out on Android.** This is a known defect. The app does not unregister its push token when you sign out, and the next session never gets one, so nothing arrives and nothing reports an error. Delete and reinstall the app, or turn the operating system's notification permission for IoTFlows off and back on. If subscribing somebody reports **Failed to update push subscription**, the change was not saved. Retry, then reopen **Event Notifications** and check the avatar pile in the **Push** column. ## See also - [Set alert rules for a machine](/docs/alerts/asset-event-rules/) - [Troubleshoot alerts you did not receive](/docs/alerts/troubleshoot-alerts/) - [Install the mobile app](/docs/get-started/install-mobile-app/) - [Overview: messaging](/docs/messaging/overview/) --- # Overview: alerts and integrations Source: https://www.iotflows.com/docs/alerts/overview/ Every way IoTFlows tells someone something: the six channels a machine event rule can fire through, which of them reach a subscriber list and which change the machine for everyone, where rules and integrations are configured, and the four things that email people without being event rules at all. # Overview: alerts and integrations Every way IoTFlows can tell someone something, and which one to use when. An *event* is a condition IoTFlows watches for on one machine, such as a stop that has lasted longer than fifteen minutes. A *rule* pairs one event type with the *channels* that carry it, where a channel is one way of delivering the news: an email, a notification on a phone, a line on the machine's record. Every machine carries the same grid of ten event types, and nothing is sent until you switch a channel on. ## The six channels A rule offers six columns, and each is an independent switch. Switching two on sends two things. Diagram: A diagram in three tiers. On the left, a box headed Event reads: a machine has been stopped for 15 minutes. An arrow leads right to a box headed Rule, reading Machine Down, switched on for this machine. From the rule, six arrows fan out to the six channel columns. Email reaches the people on that event's subscriber list. Push reaches the same list, in the IoTFlows mobile app. SMS reaches the same list, by text message. Log reaches nobody and records on the machine's Health tab. Work Order opens on your maintenance board, unassigned. Integrations posts to a Slack, Teams or Discord channel. A note across the bottom reads: six independent switches per event type. Email, push and SMS reach a subscriber list; log, work order and integrations change the machine for everyone. *An event fires a rule, and the rule reaches people through six independent channels.* | Channel | Reaches | Needs | Configured on | |---|---|---|---| | **Email** | The people on that event's subscriber list | Nothing | The machine's **Event Notifications** | | **Push** | The same list, in the mobile app | The app installed, with notification permission granted at the operating system | The machine's **Event Notifications** | | **SMS** | The same list, by text message | A verified phone number on each recipient's account | The machine's **Event Notifications** | | **Log** | Nobody. It records the event on the machine's **Health** tab | Nothing | The machine's **Event Notifications** | | **Work Order** | Your maintenance board, as an unassigned work order | A maintenance board | The machine's **Event Notifications** | | **Integrations** | A Slack, Microsoft Teams or Discord channel | An *integration*, a destination created once for the whole organization | Created in **Integrations**, attached per event type | The split down the middle of that table is the one to hold on to. **Email**, **Push** and **SMS** reach people through a *subscriber list*, the members signed up to that one event type on that one machine, so the switch alone sends nothing to nobody. **Log**, **Work Order** and **Integrations** are settings on the machine, so switching one on changes what everybody sees. Choose SMS only for events someone must act on within the hour. Every channel you add to a rule lowers the attention the rule gets, and a plant where every event buzzes a phone stops reading any of them. You do not need an integration to get alerts. Email and push work with nothing configured beyond a subscriber list. **Log** costs nobody's attention at all, so turn it on for every event type you care about, including the ones you want no notification for. ## Where rules live Three surfaces, and only the first is used often. - **Per machine.** The bell on a machine's page opens **Event Notifications**, the grid of ten event types across six channels. Rules are stored on the machine, so each machine is set up separately and there is no organization-wide alert switch. See [Set alert rules for a machine](/docs/alerts/asset-event-rules/). - **Once per organization, for chat.** Create a Slack, Teams or Discord destination on the **Integrations** page at `/integrations`, then attach it to the event rules that should reach it. See [Send alerts to Slack, Teams, or Discord](/docs/alerts/chat-integrations/). - **Once per organization, for your own systems.** A *hosted endpoint* is an HTTPS URL you control that IoTFlows posts events to. Endpoints are added under `/settings/organization` and subscribe to organization-level events, rather than being attached to one machine's rule. See [Send events to your own endpoint](/docs/alerts/webhooks/). Deciding who else is told needs Owner or Administrator. Every other role sees **Email**, **Push** and **SMS** as plain switches that subscribe only themselves, and finds **Integrations** in the navigation dimmed and unclickable. See [Roles and permissions](/docs/admin/roles-reference/). ## Alerts versus work This section draws one line: if it notifies a person or a system, it is documented here. If it creates work, it is documented in the product that owns the work. **Work Order** sits on the line, so it is split. The switch is documented here, because it is one of the six columns in the same grid. The board the work order lands on, and what happens to it afterward, are in Maintain, see [Organize work on the maintenance board](/docs/maintain/maintenance-board/). Turn it on for events with one obvious response, such as a bearing fault. Leave it off for **Machine Down** and **Device Offline**: both fire routinely and usually mean a changeover, a jam or a network problem, not a repair. ## What is not an alert Four things reach people without being event rules, and none of them is configured in **Event Notifications**. | It sends | What it is | Documented on | |---|---|---| | Email at 85% of a trigger point, and a work order at 100% | A *meter*, counting runtime or cycles toward planned maintenance rather than watching for a condition | [Trigger maintenance from meter readings](/docs/maintain/meters/) | | A report, on a daily to yearly cadence | A schedule saved from a report's **Actions** menu | [Email a report and schedule it to repeat](/docs/monitoring/share-and-schedule-reports/) | | A push notification for a message or a mention | Chat, which borrows the push channel and none of the rules | [Overview: messaging in IoTFlows](/docs/messaging/overview/) | | Nothing, until somebody opens it | The **Event Alerts** feed on a machine's **Health** tab, which is what **Log** writes into | [Review and dismiss machine events](/docs/monitoring/asset-events/) | A meter is the one worth knowing about before you build rules. It emails at a trigger point you set rather than at a condition the sensor found, so "tell me every 500 hours of runtime" is a meter and "tell me when this machine stops" is a rule. ## Where to start 1. **Get one alert working end to end.** One machine, one event, yourself as the only recipient, tested by stopping the machine on purpose. See [Quickstart: get an email when a machine goes down](/docs/alerts/quickstart/). 2. **Turn on push for the people on the floor**, who are not reading email while they work. See [Turn on push notifications on your phone](/docs/alerts/mobile-push/). 3. **Fill in the rest of the grid** once you know what you want to be told about, one machine at a time. See [Set alert rules for a machine](/docs/alerts/asset-event-rules/) and [Event types and channels](/docs/alerts/event-types-reference/). If an alert did not arrive, check the subscriber list on that event type before you check anything else. An empty list fails silently, and it is the most common cause by a distance. See [Troubleshoot alerts you did not receive](/docs/alerts/troubleshoot-alerts/). ## See it in a plant - [Integrations](https://www.iotflows.com/platform/integrations) — Machine events in Slack, Microsoft Teams, Discord, email, SMS and push, with webhooks and the REST API for your own systems. ## See also - [Quickstart: get an email when a machine goes down](/docs/alerts/quickstart/) - [Set alert rules for a machine](/docs/alerts/asset-event-rules/) - [Send alerts to Slack, Teams, or Discord](/docs/alerts/chat-integrations/) - [Event types and channels](/docs/alerts/event-types-reference/) --- # Quickstart: get an email when a machine goes down Source: https://www.iotflows.com/docs/alerts/quickstart/ Set up one alert end to end: open Event Notifications on one machine, find the Machine Down row by its amber WARNING chip, set the time threshold in minutes above your normal changeover, add yourself to that event's email subscriber list, then stop the machine on purpose and confirm the email arrives. # Quickstart: get an email when a machine goes down One rule, one recipient, one alert you have watched arrive. A *rule* pairs a condition IoTFlows watches for with the channels that carry it, and is set one machine at a time. This page builds one: an email to you when a machine has been stopped for longer than a number of minutes you choose. It takes about ten minutes, plus the wait for the test alert in step 5. Work on the web, at `/assets`. Every other event type and channel is on [Set alert rules for a machine](/docs/alerts/asset-event-rules/). Before you start, you need: - A machine with a sensor, reporting now, see [Add a machine](/docs/monitoring/add-an-asset/). - Owner or Administrator, to subscribe anyone other than yourself, see [Roles and permissions](/docs/admin/roles-reference/). - A moment when you can stop that machine on purpose. Step 5 is the part teams skip, and the only part that proves the rule works. ## Open the notification settings for a machine 1. Click **Assets** in the top navigation. 2. Click the machine you want to be told about. Its page opens at `/assets/selected-asset/:id`. 3. Click the bell in the row of icons at the top right of the header. Its tooltip reads **Event Notifications**. The modal opens on the full grid of rules for this machine, headed **Event Notifications** over **Configure alerts for critical machine conditions**. Only the first section, **Machine Status**, matters today. Nothing here is staged. The footer reads **Changes are saved automatically**, so **Done** closes the modal rather than saving it. ![The top right of a machine's page. A violet highlight rings the bell icon in the row of icons above the uptime figures, and the tooltip it opens reads Event Notifications](/images/alerts/alr-qs-01.webp) *Opening notification settings for one machine.* ## Turn on Machine Down **Machine Status** is the first section, and its first row is the one you want. It carries an amber **WARNING** chip where a title would be, over the description "Triggered when asset stops running for specified duration". The chip replaces the title, so tell the two **Machine Down** rows apart by color. The red **CRITICAL** row below is the same event at a longer time. Leave it alone today. There is no switch for the event itself and no **Add rule** button. All ten event types are always present, and a rule goes live the moment a channel carries it, which happens in step 4. ![The top of the MACHINE STATUS section, cropped. A violet highlight rings the amber WARNING chip on the first row, which sits above the description Triggered when asset stops running for specified duration and beside a time threshold of 15 min(s). The red CRITICAL row below it reads 60. The EMAIL and PUSH columns on the right are dashed empty circles on both rows](/images/alerts/alr-qs-02.webp) *Turning on Machine Down for this machine.* ## Set the time threshold A *threshold* is the number the condition is measured against. Here it is how many whole minutes the machine has to stay stopped before the event fires. 1. Click the **Time threshold** field in the middle of the row. **min(s)** sits beside it. 2. Type the number of minutes. 3. Click anywhere outside the field, and wait for the **Threshold updated** confirmation. The value is written when the field loses focus, so closing the modal before you click out loses what you typed. The field opens on the downtime alert time stored on the machine, and reads 0 if the machine has none. Set the threshold above your normal changeover. A five-minute threshold on a machine that changes over in twelve emails you all day, and you will turn it off by Thursday. For a machine that changes over in ten minutes, start at 15. ![The Time threshold control on the Machine Down warning row, cropped close. A narrow numeric field reads 15, the suffix min(s) sits to its right, and a violet highlight rings the pair](/images/alerts/alr-qs-03.webp) *The time threshold. Set it above your normal changeover, or it will fire all day.* ## Add yourself as an email subscriber A *subscriber* is one person signed up to one event type on one machine. The **Email** column is a list of people rather than a switch, and an empty list is a rule that reaches nobody. 1. Click the cell in the **Email** column of the **Machine Down** warning row. It is a dashed circle with a **+** while nobody is subscribed. 2. Find yourself at the top of the member list, tagged **(You)**. Search in **Search members...** if you would rather. 3. Click your name. A check appears beside you, and a toast confirms with your first name, for example **Maria subscribed**. Close the dropdown. The rule is live. > **Info:** > **Not an Owner or Administrator?** Everyone else sees **Email**, **Push** and **SMS** as plain switches that subscribe only themselves. Flip the one in the **Email** column, wait for **Event notification ON**, and the rest of this page works the same. **The list belongs to this event type on this machine.** Subscribing to **Machine Down** on the Haas VF-2 tells you nothing about **Device Offline** on the same machine, and nothing about the Doosan 2600 beside it. This is the most common reason a rule that looks correct emails nobody, see [Email, push and SMS subscriber lists](/docs/alerts/asset-event-rules/#subscribers). If **Failed to update email subscription** appears, the avatar disappears again and nobody was added. Retry, then reopen the modal to check the list. ![The Email cell of the Machine Down warning row with its member dropdown open below it. A Search members field sits at the top, the signed-in user is the first row and is tagged (You) with a check beside it, and the other organization members follow unchecked. One avatar now sits in the Email cell above](/images/alerts/alr-qs-04.webp) *Adding yourself as an email subscriber. Enabling the channel alone emails nobody.* ## Stop the machine and confirm the alert An untested alert rule is one you find out about during the failure it was supposed to catch. Test this one now. 1. Run the machine for a minute or two, so IoTFlows records it as running. 2. Stop it. 3. Wait the threshold, then a couple of minutes more. 4. Check your inbox. If the threshold you set is longer than you want to stand at the machine, lower it for the test and put it back before you close the modal. A rule tested at 2 minutes and left at 2 minutes is the rule you switch off by Thursday. ![The delivered alert email, open in a mail client. It is from alerts@iotflows.com, addressed to me, and its subject reads Machine Down - Doosan 2600 (TXV-2600) with the date and time. The body says This asset has not been utilized for more than the set threshold (15 min), then names the machine, its ID and department, shows an idle time of 17 min, and offers a View Dashboard button](/images/alerts/alr-qs-05.webp) *The alert as it arrives. Verify by actually stopping the machine.* Nothing arrived? Work down this list in order. 1. Reopen the modal and check the **Email** cell on the **Machine Down** warning row itself. Subscriber lists are per event type. 2. Check the machine recorded the stop. Its status bar on the machine page shows a red stretch for the time it was down. Gray means the sensor sent nothing, see [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). 3. Check your spam folder, then ask a colleague on the same list whether they got it. Every other symptom is on [Troubleshoot alerts you did not receive](/docs/alerts/troubleshoot-alerts/). ## What to set up next You have a working example. Extend it in this order. - **Turn on Log for the same event.** It records each stop on the machine's Health tab without telling anybody, which is what makes "this machine went down eleven times this month" answerable, see [Review and dismiss machine events](/docs/monitoring/asset-events/). - **Add the people who act on the stop**, not everybody who would like to know. Same dropdown, same event type. - **Repeat on your other machines.** Rules are stored per machine, so steps 1 to 4 run again on each one. You do not need an integration, an automatic work order, or SMS to get alerts. Email and push reach people with nothing configured beyond a subscriber list. Add SMS only for events someone has to act on within the hour, and add a chat integration only for a channel your shift already reads, see [Send alerts to Slack, Teams, or Discord](/docs/alerts/chat-integrations/). ## See also - [Set alert rules for a machine](/docs/alerts/asset-event-rules/) - [Turn on push notifications on your phone](/docs/alerts/mobile-push/) - [Troubleshoot alerts you did not receive](/docs/alerts/troubleshoot-alerts/) - [Event types and channels](/docs/alerts/event-types-reference/) --- # Troubleshoot alerts you did not receive Source: https://www.iotflows.com/docs/alerts/troubleshoot-alerts/ Symptom, cause and fix for an alert that should have fired and did not. Work the delivery path in order: confirm the event fired by turning Log on and reading the machine's Event Alerts list, then the channel switch on that machine's rule, then that event type's subscriber list, which is empty more often than anything else, and only then the destination. Also covers push that stops after an Android sign-out, SMS to a member with no verified phone number, a chat integration whose webhook was revoked, a rule that fires too often, and an event type the device type does not offer. # Troubleshoot alerts you did not receive Symptom, cause and fix for an alert that should have fired and did not. An alert crosses five gates between the machine and the person, and IoTFlows reports a failure at none of them. A rule with an empty subscriber list looks identical to one that works. So the method is to walk the path in order rather than to guess, and to rule out the cheap causes before the ones that need somebody else's phone. Every field named here is set in **Event Notifications** on one machine, see [Set alert rules for a machine](/docs/alerts/asset-event-rules/). ## Start here: four checks Diagram: A diagram of the path an alert travels, drawn as six stages down the left with five numbered failure points beside the arrows between them. The stages read: the machine stops, a condition happens on the floor; the event fires, the stop passes the rule's threshold; a channel carries it, email, push, SMS, log, work order; IoTFlows sends it, to each subscriber or to the destination; the destination accepts it, inbox, phone, or chat channel; somebody reads it, the alert did its job. The five failure points read: 1, threshold, the stop is shorter than the minutes set on the rule, so no event ever exists. 2, the channel is off, that column's switch is off on this machine, or the device type does not show the section at all. 3, empty subscriber list, the column is on, but nobody is subscribed to this event type, and email, push and SMS fail here silently. 4, the channel gate, push permission denied on the phone, no verified phone number for SMS, or a webhook revoked at the platform. 5, the destination, delivered, but sitting in a spam folder or a chat channel nobody reads. A note across the bottom reads: nothing in IoTFlows reports a failure at any of the five, so work down the path in order. *Where an alert can fail: rule disabled, empty subscriber list, threshold, channel permission, and the destination itself.* **Check the subscriber list before the channel.** Switching **Email** on for an event type does not email anybody. The rule sends to the list attached to that event type on that machine, and an empty list fails silently, which is the single most common cause of a rule that looks correct and reaches nobody. Work these four in order. Each rules out a cause the ones after it cannot explain. 1. **Did the event fire at all?** Turn **Log** on for that event type and read the machine's **Event Alerts** list on its Health tab, see [Review and dismiss machine events](/docs/monitoring/asset-events/). Nothing there means the condition never met its threshold, and no channel was ever asked to carry anything. 2. **Is the channel on for this event type?** Open the row in **Event Notifications** and read across its six columns. Each column is an independent switch, and it is set per event type, not per machine. 3. **Is anyone subscribed?** Click the cell in the **Email**, **Push** or **SMS** column of that row. A dashed circle with a **+** means the list is empty, see [Email, push and SMS subscriber lists](/docs/alerts/asset-event-rules/#subscribers). 4. **Can the destination accept it?** Push needs an OS permission, SMS needs a verified phone number on the recipient's account, and an integration needs a webhook that still exists at Slack, Teams or Discord. Then jump to your symptom. | Symptom | Likely cause | Check | Fix | Page | |---|---|---|---|---| | Nobody got the email | The event type's email list is empty | The **Email** cell on that row | Add people to that event type | [Nobody got the email](#email) | | One person gets it, others do not | The list is per event type, and they were added to a different one | The same cell on each event type | Add them to every event they need | [Nobody got the email](#email) | | The alert fired but no email at all | The event type never fired | **Event Alerts** on the machine's Health tab | Lower the threshold, or wait for a real stop | [Start here](#start) | | Push stopped after signing out on Android | The app does not unregister its push token | Whether the app was signed out and back in | Delete and reinstall the app | [Push never arrived](#push) | | A member cannot be added to the SMS list | No verified phone number on their account | The **No phone number** label beside their name | Ask them to add and verify one | [SMS never arrived](#sms) | | The Slack or Teams message never posted | The webhook was revoked at the platform end | **Test integration** on the Integrations page | Create a new webhook and paste the new URL | [The chat message never posted](#chat) | | The same stop alerts twice | Both **Machine Down** rows are on for the same channel | The warning and critical thresholds | Leave the critical row on one channel only | [The rule fired too often](#too-often) | | Alerts all night for a machine nobody runs | The rule does not know about the schedule | Which machines have **Machine Down** enabled | Disable it, or raise the threshold | [The rule fired too often](#too-often) | | The event type is not on the screen | The device cannot produce it | The device type and its firmware | Nothing to fix, see the availability table | [The event type is not in the list](#missing-event) | ## Nobody got the email Confirm the event fired, then open the **Email** cell on that row. Almost every "the alert never arrived" report ends here, with an empty list or a list holding one person who has since left. The list belongs to the event type. Subscribing Maria to **Machine Down** on the Haas VF-2 tells her nothing about **Device Offline** on the same machine, and nothing about **Machine Down** on the Doosan 2600 beside it. Repeat the subscription on every event type and every machine she is responsible for. If the list is right, the email is delivered and unseen rather than unsent. Search the recipient's spam folder and any rule that files mail from unknown senders, then add the sender to their allowed list. > **Info:** > **Do I see the same thing as an Administrator?** No. Owners and Administrators see avatar piles they can edit for everybody. Everybody else sees three plain switches that subscribe and unsubscribe only themselves, so a member reporting "my email switch is on" has confirmed their own subscription and nobody else's, see [Roles and permissions](/docs/admin/roles-reference/). ## Push never arrived Push has two switches the product cannot see: the OS permission on the phone, and the app's registration. A rule with **Push** on and permission denied fails silently, and nothing in IoTFlows shows the message was never delivered. 1. Confirm the recipient is on that event type's **Push** list. 2. Confirm notifications are allowed for IoTFlows in the phone's own settings. 3. Confirm they are signed into the organization the machine belongs to. Push routes per organization. **Push stops arriving after an Android user signs out and back in.** This is a known defect: the app does not unregister its push token on sign-out, and the new session never gets one. Sign out, delete the app, reinstall it and sign in again. See [Turn on push notifications on your phone](/docs/alerts/mobile-push/). ## SMS never arrived SMS reaches a member only if their account carries a verified phone number. A member without one is listed as **No phone number**, cannot be added to the list, and clicking them reports **This user has not added their phone number**. A member who has opted out of texts is listed as **Opted Out** and stays unreachable until they opt back in. See [Change your phone number](/docs/admin/phone-number/). Check the list before you check the carrier. A member who changed their number and did not update their profile is subscribed to an old handset. ## The Slack, Teams or Discord message never posted Work from the integration rather than from the rule. Open `/integrations` and click **Test integration** on the destination. - **Test event sent**, and the message appears in the channel. The integration is fine, so the fault is upstream: the **Integrations** cell on that event row, or the event never firing. - **Test event sent**, and nothing appears in the channel. The webhook was revoked or the channel was deleted at the platform end. Create a new webhook there and paste the new URL into the integration. - **Failed to send test event**. IoTFlows could not reach the URL. Re-copy it from the platform, and check the integration is enabled. An integration tagged **Disabled** is still listed everywhere, including in the per-event dropdown, and sends nothing until it is enabled again. See [Send alerts to Slack, Teams, or Discord](/docs/alerts/chat-integrations/). ## The rule fired too often Too many alerts and no alerts have the same ending, which is a rule nobody reads. Four causes, in the order they are worth checking. - **The threshold is below normal operation.** A 5-minute **Machine Down** on a machine that changes over in 12 alerts on every changeover. Set it above the longest pause that is part of the job. - **Both Machine Down rows are on for the same channel.** The warning and critical rows are separate rules watching the same stop, so a long stop alerts twice. Keep the critical row on a narrower channel, for example SMS for the maintenance lead only. - **Device Offline is set too short.** Ten minutes is the default for a reason. Two minutes on a machine at the edge of an access point's range turns one flaky afternoon into forty alerts, see [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). - **The shock threshold matches the machine's normal stroke.** A press reporting 3 g every cycle is not faulting. Raise the threshold rather than turning the rule off, see [Shock events](/docs/alerts/asset-event-rules/#shock). Rules do not know about shifts or the plant calendar. A machine nobody runs at night still alerts at night, so disable **Machine Down** on machines that are idle by design. ## The rule fired for the wrong machine Rules are stored on the machine, not on the sensor. Two consequences when hardware moves. - A sensor moved to another machine reports against that machine's rules and subscriber lists, not the ones you set up for it before the move. - The shock threshold is the exception. It is written to the device itself, so it travels with the sensor and applies to whatever machine it is now reading. If the alert names a machine you did not expect, open that machine's **Event Notifications** and read its rules. Two machines with similar names is the other common cause, and renaming one is faster than explaining it, see [Edit a machine](/docs/monitoring/edit-assets/). ## The event type is not in the list The modal hides the sections the device cannot produce, so this is a device answer rather than a permission answer. A BeamTracker shows machine status and connectivity only, and a SenseAi on firmware below 5 keeps shock but loses health and temperature. The full table is at [Which sections you see for which device](/docs/alerts/asset-event-rules/#device-visibility). Check the device before you check anything else. It is the reason more often than a role is, and no setting on the page will add the section back. Ask IoTFlows to update a device on old firmware, see [Get support](/docs/get-started/get-support/). ## Errors | Message | Cause | Do this | |---|---|---| | **This user has not added their phone number** | You tried to add an SMS subscriber whose account has no verified number | Ask them to add and verify one, see [Change your phone number](/docs/admin/phone-number/) | | **Failed to send test event** | IoTFlows could not deliver to the integration's webhook URL | Re-copy the URL from the platform, then test again | | **Failed to update event type** | A channel switch, **Log**, **Work Order** or a threshold did not save | Retry. Nothing was changed | | **Failed to update email subscription**, **push**, or **SMS** | A subscriber was not added or removed. The avatar pile reverts | Retry, then reopen the modal to confirm the list | | **Failed to update integrations** | The integration was not attached or detached | Retry, and check the integration still exists | | **Critical must be higher than warning** | An inverted temperature pair. The red line does not block the save | Correct the two values before you close the modal | A generic **Something went wrong** or **An error occurred** means the request failed and the change was not saved. Reopen the modal to see the values that actually stuck, then retry. ## See also - [Set alert rules for a machine](/docs/alerts/asset-event-rules/) - [Event types and channels](/docs/alerts/event-types-reference/) - [Turn on push notifications on your phone](/docs/alerts/mobile-push/) - [Send alerts to Slack, Teams, or Discord](/docs/alerts/chat-integrations/) - [Review and dismiss machine events](/docs/monitoring/asset-events/) --- # Send events to your own endpoint Source: https://www.iotflows.com/docs/alerts/webhooks/ Post IoTFlows events to an HTTPS URL you control. Add a hosted endpoint under Organization Settings with its URL, description and the signing secret you choose, subscribe it to the events your system acts on, and send each event's real test payload to your URL before you write the handler. The selectable event list is served by IoTFlows and read off the screen, so this page shows how to read it rather than reproducing it. # Send events to your own endpoint Post IoTFlows events to a URL you control, and know what arrives before you write the handler. A *hosted endpoint* is an HTTPS URL of your own that IoTFlows posts events to, as an HTTP POST with a JSON body. Endpoints belong to the organization rather than to one machine, so you add one once and choose which events it receives. They are configured self-serve in Organization Settings and are unrelated to REST API access, which IoTFlows grants by hand. **Prerequisites.** Organization Owner or Organization Administrator, see [Roles and permissions](/docs/admin/roles-reference/). An HTTPS URL that accepts a POST and returns a response, reachable from the public internet. You do not need a hosted endpoint to reach Slack, Microsoft Teams or Discord. Each has a purpose-built integration that needs no code, see [Send alerts to Slack, Teams, or Discord](/docs/alerts/chat-integrations/). Build an endpoint when the event has to reach something that is not a chat channel: a CMMS, an ERP, a dashboard of your own, or a queue. ## What a hosted endpoint is An endpoint is three things: a URL, a *signing secret* you choose, and a set of *subscriptions*, where a subscription is one event type switched on for that one endpoint. Nothing is delivered until at least one subscription is on. Endpoints and machine event rules are separate systems. A rule on a machine's **Event Notifications** grid reaches people through email, push, SMS, the log, a work order and chat integrations, see [Overview: alerts and integrations](/docs/alerts/overview/#channels). A hosted endpoint subscribes to organization-level events and carries no per-machine switch, so there is nothing to turn on per asset. You can add more than one endpoint, each with its own secret and its own subscriptions. Split them when two systems want different events, for example a maintenance system that wants faults and a reporting service that wants job completions. ## Add an endpoint 1. Click the gear icon at the top right of the header. It opens Organization Settings at `/settings/organization?select=settings`. 2. Click **Webhooks** in the sub-navigation, at `/settings/organization?select=webhooks`. The page is headed **Hosted endpoints** and lists every endpoint in the organization by URL. 3. Click **Add endpoint**. The **Listen to IoTFlows Events** dialog opens. 4. Fill in the three fields below. 5. Click **Verify**. IoTFlows saves the endpoint and confirms with **Endpoint created**, then replaces the fields with **Select events to listen to** and a switch per event. 6. Switch on the events this endpoint should receive, then click **Close**. The endpoint was saved at step 5 and each switch saves as you flip it, so there is nothing left to submit. The switch list inside the dialog carries event names only. The descriptions and the **Test** buttons are on the endpoint's row afterwards, see [Choose which events to subscribe to](#subscribe). ![The Webhooks tab of Organization Settings, headed Hosted endpoints with an Add endpoint button at the top right. A table under a URL column lists two endpoints, each row ending in a pencil icon and a trash icon](/images/alerts/alr-hook-01.webp) *Hosted endpoints. Configured in Organization Settings by an admin.* ### Endpoint fields | Field | Required | Notes | |---|---|---| | `Endpoint URL (HTTP POST)` | Yes | The full HTTPS URL IoTFlows posts to, for example `https://ops.example.com/hooks/iotflows`. The dialog does not check the URL before submitting it, so confirm a new endpoint with a test payload rather than assuming a typo would have been caught | | `Endpoint Description` | No | Free text, shown on the expanded row. Name the system that consumes it, for example `Maintenance CMMS, production` | | `Endpoint Secret` | No, but treat it as required | The value IoTFlows sends back in the `iotflows-secret` header of every delivery. See [The signing secret](#secret) | **Verify is the save button.** It creates the endpoint and confirms with **Endpoint created**. It does not show you what your handler will receive or whether your handler handled it. For that, send a test payload, see [Send a test payload](#test). ![The Listen to IoTFlows Events dialog. Three stacked text fields are labeled Endpoint URL (HTTP POST), Endpoint Description and Endpoint Secret, with numbered callouts 1, 2 and 3 against them. A Close button sits at the bottom left and a Verify button at the bottom right](/images/alerts/alr-hook-02.webp) *The Listen to IoTFlows Events dialog, with the endpoint URL, description and secret fields.* ## The signing secret The *signing secret* is a string you choose when you create the endpoint. IoTFlows sends it back in the `iotflows-secret` header on every delivery, including test payloads, so your handler can reject a POST that did not come from IoTFlows. Set one. The field accepts an empty value, and an endpoint with no secret has no way to tell an IoTFlows delivery from anything else that finds the URL. Use a long random string, for example the output of `openssl rand -hex 32`, and store it where your handler reads its own configuration. Your handler compares the header with its stored copy and drops the request when they differ: ```js // Express handler for an IoTFlows hosted endpoint. const express = require('express') const app = express() app.post('/hooks/iotflows', express.json(), (req, res) => { if (req.get('iotflows-secret') !== process.env.IOTFLOWS_WEBHOOK_SECRET) { return res.status(401).send('bad secret') } console.log('event received', req.body) res.status(200).send('ok') }) app.listen(3000) ``` A delivery that passes the check prints the event and returns `200`: ```text event received { data: { ... } } ``` To read the secret back later, expand the endpoint's row on the **Hosted endpoints** page. **Secret** is masked; click **Reveal** to show it and **Hide** to mask it again. The field is read-only there, so change a secret from the edit dialog, see [Edit or remove an endpoint](#edit). Because the secret can be read back, treat it as shared with everyone who can open Organization Settings. Give each endpoint its own secret rather than reusing a key your systems already rely on elsewhere. ![The Secret row of an expanded endpoint. The value is masked as dots in a read-only field, with a blue Reveal link directly beneath it](/images/alerts/alr-hook-03.webp) *The signing secret, masked by default.* ## Choose which events to subscribe to Every endpoint on **Hosted endpoints** opens expanded. Under **Events**, each event IoTFlows can send is listed with its description and a **Subscribe** switch. Click the URL, or the chevron beside it, to collapse a row you are not working on. Flip a switch and the change saves immediately. IoTFlows confirms with **Subscribed to** or **Unsubscribed from**, followed by the event's name. There is no **Save** button, and closing the page mid-list leaves the switches you already flipped in place. **This page does not reproduce the event list.** The list is served by IoTFlows and can change without a release, and it cannot be exported, so any table printed here would be a copy that silently goes stale. Read it off the screen instead: the name and the one-line description in the **Events** column are the whole of what each event is. Subscribe to the smallest set of events your system acts on. Every subscription is a delivery your endpoint has to accept and answer, and an endpoint that times out on events it ignores looks like an outage to whoever is watching it. If you cannot name what your handler does with an event, leave it off. ![The Events panel of an expanded endpoint. A header row reads Events on the left and Subscribe on the right. Each row below shows an event name with its description underneath, then a Test button and a toggle switch. Several toggles are on](/images/alerts/alr-hook-04.webp) *The subscribable events. This list is served by IoTFlows and read off the screen; it cannot be exported.* ## Send a test payload Every event row carries a **Test** button, next to its switch. Click it to see the exact JSON IoTFlows sends for that event type, then click **Test** in the dialog to post that JSON to your endpoint. Use it before you write the handler. The dialog shows the real shape of the body, so you can build against the field names rather than guessing them, and it states the header your handler must check: the secret arrives as `iotflows-secret`. A test tells you two things and no more: that your URL answered, and what the body looks like. IoTFlows confirms a delivery with **Message was sent successfully!**, and reports a URL that did not answer as **No response from server**. Whether your handler did the right thing with the body is a question for your own logs. The **Test** button works whether or not the event is subscribed, so you can check an endpoint end to end before you switch anything on. ![A dialog headed Test, the event's name, and Event, above a line reading This is the data that you will be receiving with the defined secret as iotflows-secret header. Below it, a dark code block shows the formatted JSON body for that event type, with Cancel and Test buttons underneath](/images/alerts/alr-hook-05.webp) *A test payload for one event type, so you can build against the real shape.* ## Edit or remove an endpoint Each row on **Hosted endpoints** ends in two controls. - **The pencil** opens the same three fields, filled in. Change the URL, the description or the secret, then click **Reverify**. IoTFlows confirms with **Endpoint updated**. The new secret is used on the next delivery, so change your handler's copy in the same window or you will start rejecting valid deliveries. - **The trash** opens a **Delete Endpoint** confirmation naming the URL. Click **Delete** and the endpoint goes, along with its subscriptions. IoTFlows confirms with **Webhook has been removed**. Neither dialog touches subscriptions. **Reverify** saves the three fields and nothing else, and the edit dialog does not show the event switches at all. Move a URL rather than replacing an endpoint. Editing keeps the subscriptions you have already chosen; deleting and re-adding means switching every event back on by hand. ## Verify deliveries IoTFlows shows you what it sent, not what your server did with it, so confirm deliveries at your end. 1. Send a test payload for one subscribed event, see [Send a test payload](#test). 2. Look for the request in your own server log, and check that the `iotflows-secret` header matched. 3. If **No response from server** appears, the URL did not answer. Check that it is reachable from the public internet, serves a valid TLS certificate, and returns a response rather than holding the connection open. 4. If your handler ran but did nothing, compare the body you received with the test payload for that event type. They are the same shape. An endpoint that stops receiving after a deploy is usually a transport problem rather than a subscription one. The subscriptions survive a deploy; an expired certificate, a moved path and a firewall rule do not, and all three read the same way from the IoTFlows side, which is silence. Re-run the test before you touch any switches. If an alert that should have reached your endpoint never fired in the first place, the problem is on the rule and not on the endpoint, see [Troubleshoot alerts you did not receive](/docs/alerts/troubleshoot-alerts/). ## See also - [Send alerts to Slack, Teams, or Discord](/docs/alerts/chat-integrations/) - [Event types and channels](/docs/alerts/event-types-reference/) - [Troubleshoot alerts you did not receive](/docs/alerts/troubleshoot-alerts/) - [Overview: alerts and integrations](/docs/alerts/overview/) - [Roles and permissions](/docs/admin/roles-reference/) --- # Frequently asked questions Source: https://www.iotflows.com/docs/get-started/faq/ Answers to the questions asked before buying IoTFlows and during the first week after: whether the sensors touch the PLC, what machines they fit, how long an install takes, whether one sensor can cover two machines, what network access the devices need, how an organization gets created, whether a machine's history survives a sensor swap, and where invoices live. # Frequently asked questions The questions people ask before buying IoTFlows, and in the first week after. These answers cover purchasing, product fit, accounts, and billing. Questions that begin "why does this number look wrong" belong to the troubleshooting page for the product involved, not here. ## Buying and hardware ### Do the sensors connect to my PLC or machine controls? No. IoTFlows devices attach magnetically or mount externally and read the machine from outside it. There is no wiring, no PLC integration, and no modification to the equipment, so an installation is reversible. ### What kind of machines can IoTFlows monitor? Any equipment that vibrates, moves, or produces countable output. For example: CNC mills, lathes, grinders and EDMs; stamping presses and press brakes; injection molding machines; packaging and assembly lines; laser cutters and waterjets; robotic cells. ### How long does installation take? | Device | Typical install | What that covers | |---|---|---| | SenseAi | 5 to 10 minutes per machine | Mount the sensor, power it on, connect it to Wi-Fi | | BeamTracker | 10 to 20 minutes | Mount the head, align the laser, connect to Wi-Fi, first calibration | | SenseAi Embedded | 5 to 45 minutes | Depends on whether it mounts on the motor or spindle itself, and how easy that spot is to reach | ### What is the difference between SenseAi and SenseAi Embedded? [SenseAi](/docs/hardware/senseai/) mounts magnetically on the outside of a machine and reads vibration and acoustics. [SenseAi Embedded](/docs/hardware/senseai-embedded/) does the same job, and its IP67 rating lets it mount on the motor itself. Mounting at the source is the reason to choose it. You get the same machine performance either way, plus advanced health analytics from reading the motor directly. The sealed enclosure means Embedded takes no acoustic reading; it reads vibration and temperature. ### Can one sensor cover two machines? No. A sensor is attached to exactly one *asset*, the record that represents one machine, and a sensor already attached to an asset is not offered when you create the next one. You do not need one sensor per spindle either. One sensor per machine is the unit IoTFlows counts, bills and reports on. ### Can I put more than one device on the same machine? Yes, when the machine owes you two kinds of reading. A SenseAi for [uptime](/docs/monitoring/metrics-reference/) alongside a BeamTracker for part counting is the common pairing, and a multi-spindle machine sometimes carries more than one SenseAi. ### Do I need IT involvement or a firewall change? Not with the IoTFlows 4G/LTE router, which puts the devices on an isolated cellular network and asks nothing of your network team. On facility Wi-Fi the devices need 2.4 GHz access and outbound HTTPS on port 443. ## Accounts and organizations ### How is an organization created? IoTFlows creates it. An *organization* is the container holding your machines, members, and billing, and there is no self-serve path to create one. Ask for it when you buy, or [contact support](/docs/get-started/get-support/#contact) with the name you want and the person who should own it. ### Can one account belong to more than one organization? Yes, and the same sign-in reaches all of them. Use the organization switcher to move between them. See [Switch between organizations](/docs/get-started/switch-organizations/). ### How do I add people to my organization? Invite them by email from organization settings and give each one a role. The role decides which pages a person can open and what they can change. See [Invite members](/docs/admin/invite-members/) and [Roles and permissions](/docs/admin/roles-reference/). ### Can I use IoTFlows on my phone? Yes. The dashboard works in a mobile browser, and IoTFlows publishes native apps for iOS and Android. See [Install the mobile app and sign in](/docs/get-started/install-mobile-app/). ## Data and privacy ### What leaves the plant? Sensor readings and whatever your team enters in the dashboard: asset names, downtime reasons, notes, work orders. Devices open outbound connections over HTTPS on port 443. ### Who inside my organization can see the data? Everyone you invite, narrowed by their role, and narrowed further if you restrict a member to specific machines. See [Roles and permissions](/docs/admin/roles-reference/) and [Control who sees which machines](/docs/admin/machine-access/). ### Can I get my data back out? Yes. Most reports export to CSV, and several also export to PDF. See [Available exports](/docs/monitoring/exports-reference/). ### If I swap a sensor, do I lose the machine's history? No. [Uptime, downtime, and production](/docs/monitoring/metrics-reference/) are stored against the asset rather than against the sensor, so replacing a failed sensor leaves the machine's history intact. Contact IoTFlows to attach the replacement to the same asset. ## Billing ### Where are my invoices? At `/{organization}/settings/billing`, which only an organization Owner can open. **Current Invoice** shows the period in progress, and **Invoices** lists the ones already issued. See [Read and manage billing](/docs/admin/billing/). ### How do I change the payment method or the invoice email? Both live on the same billing page, so both need the Owner role. An Administrator or Member who opens it sees "Only organization owners can access this page." ### How do I add devices or change plan? Contact IoTFlows. Plan changes and additional devices are not self-serve, because they change what ships to you as well as what you pay. ### Can I get a refund? Contact support to discuss it. Refunds are handled case by case rather than by a published policy. ### What happens if an account goes unpaid? The organization is suspended. Everyone who signs in is held behind a notice that cannot be dismissed, which links to billing. Only an Owner can open that page, so the organization stays blocked until its Owner clears the balance. See [Reactivate a suspended account](/docs/admin/suspended-account/). ## See also - [Buy IoTFlows hardware](/docs/hardware/buy/) - [Read and manage billing](/docs/admin/billing/) - [Contact support and report bugs](/docs/get-started/get-support/) - [What IoTFlows does](/docs/get-started/overview/) --- # Contact support and report bugs Source: https://www.iotflows.com/docs/get-started/get-support/ How to reach IoTFlows support by email or from the dashboard feedback popover, request training, file a bug with the details support needs, and send a feature request. # Contact support and report bugs Reach a person at IoTFlows, request training, and file a bug or a feature request. Support runs on two channels. Email `support@iotflows.com` for anything needing a reply, an attachment, or an account change. The feedback popover in the dashboard header sends a note without leaving the page, but it is one way. ## Contact support Email `support@iotflows.com`. Locked out instead? See [Sign in to IoTFlows](/docs/get-started/sign-in/). To send a note from the dashboard: 1. Select the feedback icon in the header, to the left of the settings gear. 2. Type your note in **Feedback / Feature Request**. 3. Select **Send Feedback**, then wait for the confirmation "Thanks for your feedback". IoTFlows records the page you were on. > **Note:** > **Waiting on an answer?** Use email. The popover opens no reply thread and takes no files, and its icon is hidden on narrow screens. ## Request training Email `support@iotflows.com` to book onboarding or training. Name the products your team uses, how many people attend, and which shift they work, so the session lands on their shift. ## Report a bug 1. Reproduce the problem once and note the exact time. 2. Email `support@iotflows.com` with every row of [What to include](#what-to-include) that applies. 3. Attach a screenshot. Attachments go by email; the popover takes text only. Always include the timestamp and your organization timezone. Most reports about a wrong number resolve to a shift boundary, and support cannot check that without both. See [Set shifts and your organization timezone](/docs/admin/shifts-and-timezone/). ## Request a feature Send feature requests through the feedback popover, which is titled **Feedback / Feature Request**. Describe the problem you are trying to solve rather than the feature you have in mind. You do not need to email the request as well. ## What to include | Report type | Include | Why | |---|---|---| | Every report | Organization handle, and your client: web, iOS, or Android | One account can see several organizations, and behavior differs per client | | A number looks wrong | Asset name, timestamp with timezone, the shift and date selected | Support replays the window you were looking at | | A machine reads offline | Asset name, device serial, when it last reported | Separates a dropped network from a stopped machine | | Someone cannot see a page | Their email, their role, the page | Most cases are a role gate, not a fault | | Feature request | The problem, and how often it costs you time | Frequency orders the queue | ## See also - [Frequently asked questions](/docs/get-started/faq/) - [Troubleshoot wrong utilization or OEE](/docs/monitoring/troubleshoot-monitoring/) - [Get a device back online](/docs/hardware/troubleshoot-offline-device/) - [Set shifts and your organization timezone](/docs/admin/shifts-and-timezone/) --- # Glossary Source: https://www.iotflows.com/docs/get-started/glossary/ The terms you meet in IoTFlows, each defined in one short paragraph the way the product measures or configures it and linked to the page that explains it: uptime, downtime, unknown time, utilization, the three OEE factors, first pass yield, cycle time, shift goals, downtime categories, severity, planned downtime, status colors, RMS velocity, crest factor, kurtosis, FFT, harmonics, baseline profiles, health score, shock events, parts, operations, detection algorithms, cascading groups, scrap reasons, work sessions, jobs and tasks, the Gantt and Kanban views, the optimizer, simulations, work orders, requests, preventive maintenance, meters, items, reorder points, serialized pieces, event rules, webhooks, MQTT, API keys, 2.4 GHz Wi-Fi, SenseAi, SenseAi Embedded, BeamTracker, the Production Scheduler, Maintain, Inventory, the 4G/LTE router and the IoTFlows edge device. # Glossary The terms you meet in IoTFlows, defined the way the product measures or configures them. Each entry links to the page that covers it in full. - **Monitoring:** [Uptime](#uptime) · [Downtime](#downtime) · [Unknown time](#unknown-time) · [Utilization](#utilization) · [Availability](#availability) · [Performance](#performance) · [Quality](#quality) · [OEE](#oee) · [First pass yield](#fpy) · [Cycle time](#cycle-time) · [Shift goal](#shift-goal) · [Downtime category](#downtime-category) · [Severity](#severity) · [Planned downtime](#planned-downtime) · [Auto-classification](#auto-classification) · [Pareto chart](#pareto-chart) · [Status colors](#status-colors) · [Operator View](#operator-view) · [Operator station](#operator-station) - **Machine health:** [RMS velocity](#rms) · [Peak acceleration](#peak-acceleration) · [Crest factor](#crest-factor) · [Kurtosis](#kurtosis) · [Envelope kurtosis](#envelope-kurtosis) · [FFT spectrum](#fft) · [Harmonics](#harmonics) · [Baseline profile](#baseline-profile) · [ISO 10816](#iso-10816) · [Health score](#health-score) · [Shock event](#shock-event) - **Production:** [Part](#part) · [Operation](#operation) · [Detection algorithm](#detection-algorithm) · [Quantity per cycle](#quantity-per-cycle) · [Cascading group](#cascading-group) · [Scrap reason](#scrap-reason) · [Work session](#work-session) · [Job and task](#job-and-task) - **Scheduling and maintenance:** [Gantt view](#gantt-view) · [Kanban view](#kanban-view) · [Optimizer](#optimizer) · [Simulation](#simulation) · [Work order](#work-order) · [Request](#request) · [Preventive maintenance](#preventive-maintenance) · [Meter](#meter) · [Item](#item) · [Reorder point](#reorder-point) · [Serialized piece](#serialized-piece) - **Alerts and connectivity:** [Event rule](#event-rule) · [Machine event](#machine-event) · [Chat integration](#chat-integration) · [Webhook](#webhook) · [API key](#api-key) · [MQTT](#mqtt) · [2.4 GHz](#2-4-ghz) · [PLC](#plc) - **Manufacturing systems:** [Industry 4.0](#industry-4-0) · [IIoT](#iiot) · [Digital twin](#digital-twin) · [MES](#mes) · [ERP](#erp) · [CMMS](#cmms) - **Products:** [SenseAi](#senseai) · [SenseAi Embedded](#senseai-embedded) · [BeamTracker](#beamtracker) · [4G/LTE router](#4g-lte-router) · [Edge device](#edge-device) · [Production Scheduler](#production-scheduler) · [Maintain](#maintain) · [Inventory](#inventory) ## Monitoring ### Uptime The share of a window a machine spent running: running time divided by running plus stopped time, as the sensor reports them. Uptime is availability, the first factor of OEE. Time the sensor did not report is unknown time and counts in neither term. See [Uptime](/docs/monitoring/metrics-reference/#uptime). ### Downtime The time the sensor reports a machine stopped. A stop counts in full whether or not an operator has classified it: a downtime category changes what the reports can say about the time, not how much of it there is. See [Downtime](/docs/monitoring/metrics-reference/#downtime), [Classify a downtime event](/docs/monitoring/classify-downtime/) and [Downtime tracking](https://www.iotflows.com/solutions/downtime-tracking). ### Unknown time Any interval where the sensor was powered off or had lost its connection. It is the absence of data, not a machine state, so it counts toward neither uptime nor downtime and draws gray on the shift status bar. A lot of unknown time points to a power or connectivity problem, not a production one. See [Unknown time](/docs/monitoring/metrics-reference/#unknown). ### Utilization The same percentage as uptime under another label: **Utilization** on the Assets page KPI row and the Advanced Report, **Uptime** on a machine card. It comes from the sensor alone, so you can read it from the first day, before any part, operation or cycle time exists. See [Uptime](/docs/monitoring/metrics-reference/#uptime) and [Machine utilization](https://www.iotflows.com/solutions/machine-utilization). ### Availability The first OEE factor: how much of the time a machine ran. In IoTFlows, availability is uptime, running time divided by running plus stopped time, measured by the sensor with no operator input. Unknown time never counts, and stops of severity None leave the figure when you turn on **Exclude None**. See [Uptime](/docs/monitoring/metrics-reference/#uptime) and [OEE tracking](https://www.iotflows.com/solutions/oee-tracking). ### Performance The second OEE factor, shown as the parts gauge: parts made against what the machine could have made at its ideal cycle time in the same running time. It reads once an operation with an ideal cycle time is assigned to the machine. See [Performance](/docs/monitoring/metrics-reference/#performance). ### Quality The third OEE factor: the share of parts made that were good. On Shift Production, the **Quality** column shows good parts as a percentage of everything counted, with the bad count beneath it. Scrap you log with a reason is a parallel number and does not come out of the good count. See [Track production against shift goals](/docs/production/shift-production/#board) and [Log scrap](/docs/production/log-scrap/). ### OEE Overall equipment effectiveness: availability × performance × quality. IoTFlows reports the factors on their own, availability as uptime, performance as the parts gauge and quality as good parts over everything counted, from the scrap your team logs, each with its own definition. The OEE goal is one target percentage your organization sets; every machine inherits it until you give that machine its own, and gauges draw green at or above it and red below. See [Set OEE and utilization goals](/docs/monitoring/oee-goals/) and [OEE tracking](https://www.iotflows.com/solutions/oee-tracking). ### First pass yield (FPY) A step's good count divided by the good count of Step 1 in its cascading group, capped at 100%. Read down the line, it shows where parts are lost between operations, not only at the end. It reads green from 95% and amber from 80%. See [FPY](/docs/monitoring/metrics-reference/#fpy). ### Cycle time How long one cycle of an operation takes; a cycle can make more than one part. Three figures carry the name: the ideal cycle time you enter on the operation, the actual cycle time measured from detection events, and a target derived from the ideal and the machine's uptime goal, which colors the actual figure. See [Cycle time](/docs/monitoring/metrics-reference/#cycle-time) and [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/). ### Shift goal The number of parts an operation should finish in a shift, shown as **Calculated Goal** on Shift Production. IoTFlows derives it from the shift duration, the expected downtime and the ideal cycle time, so you move it by changing the cycle time, not by typing it. The **Progress** gauge fills toward it. See [Where the goals come from](/docs/production/shift-production/#goals). ### Downtime category A reason code an operator puts on a machine stop, for example Tool change. Each carries a severity, an optional color, a flag that forces a note, a planned or unplanned setting and an optional category type that groups related categories. One list serves the whole organization. See [Manage downtime categories](/docs/monitoring/downtime-categories/). ### Severity How much a stop of a given downtime category costs you: None, Low, Medium or High. You choose it when you create the category, and it decides the heading the category files under and its color. None marks stops that are nobody's loss, such as a mandated break. Machine events use their own Critical, Warning and Caution scale. See [Set severity](/docs/monitoring/downtime-categories/#severity). ### Planned downtime A setting on a downtime category that marks every stop classified under it as scheduled, such as preventive maintenance or a planned changeover. The category's chip carries a calendar icon, and the picker filters to Planned or Unplanned. Planned is independent of severity: a scheduled rebuild can still be High. See [Mark a category as planned](/docs/monitoring/downtime-categories/#planned). ### Changeover The time from the last part of one run to the first good part of the next, so it includes the swap, the adjustments and every trial part. The sensor records a changeover as a stop like any other: classify it with its own reason so it gets its own bar in the [Pareto chart](#pareto-chart), and set a Machine Down alert threshold above your normal changeover. See [Classify a downtime event](/docs/monitoring/classify-downtime/) and [Measure changeover time](/blog/measure-changeover-time/). ### Auto-classification A rule that puts a downtime category on a stop without anyone opening the classify dialog. Four rules cover short pauses, the start and end of a shift, a shift with no production at all, and scheduled breaks. Each applies to every machine in the organization and is enabled on its own. See [Classify downtime automatically](/docs/monitoring/auto-downtime-rules/). ### Pareto chart A bar chart that ranks downtime reasons by the time they cost, longest first, with a line for the cumulative percentage, so you can read how many reasons make up most of the loss. The Downtimes report draws it as **Downtimes by Category** over the window you select. See [Read the Pareto chart](/docs/monitoring/downtimes/#pareto). ### Status colors The colors a machine's status pill, card border and list row take: green while running or briefly stopped, orange past the orange threshold (one minute by default), red past the red threshold (five minutes by default), and dark red once the stop is classified. The thresholds are set for the whole organization and never change a number. See [Set status colors and downtime thresholds](/docs/monitoring/status-colors/#colors). ### Operator View A display mode for one machine's page, built for the person running it: larger tap targets, no secondary navigation, and four tabs in place of the analytics, **Part Count**, **All Downtime**, **Jobs** and **Notes**. Any signed-in user turns it on from the profile menu. See [Use Operator View on the shop floor](/docs/monitoring/operator-view/). ### Operator station A browser IoTFlows has tied to one machine, so whoever signs in on it lands on that machine's page. An Owner or Administrator pairs the device in Organization Settings, and each sign-in and sign-out clocks the operator in and out. Use it for a shared tablet that stays at the machine. See [Set up a dedicated operator station](/docs/monitoring/operator-stations/#differences). ## Machine health ### RMS velocity The root mean square of the vibration signal: the machine's overall vibration energy, or the signal's effective amplitude. The Health tab charts it as **RMS Velocity** for the X, Y and Z axes and the combined XYZ. It rises with unbalance, misalignment, looseness and general wear. See [Health metrics](/docs/monitoring/machine-health/#metric-table). ### Peak acceleration The largest instantaneous amplitude in the measurement window, charted on the Health tab as **Peak Acceleration** for each axis and the combined XYZ. It rises with bearing defects, gear tooth damage, cavitation and impacts. Divide it by the RMS and you get the crest factor. See [Health metrics](/docs/monitoring/machine-health/#metric-table). ### Crest factor The signal's peak divided by its RMS. Impacts raise the peak without raising the RMS much, so the ratio climbs on bearing spalling, cracked gear teeth, looseness and motor electrical faults. See [Health metrics](/docs/monitoring/machine-health/#metric-table). ### Kurtosis How peaked the vibration signal's amplitude distribution is. Random vibration sits near 3; early bearing damage, impacting looseness, intermittent contact and rubbing push it higher. Kurtosis is one of the 14 metric trend charts on the Health tab. See [The 14 metric trend charts](/docs/monitoring/machine-health/#trends). ### Envelope kurtosis The kurtosis of the high-frequency envelope of the vibration signal, and the most sensitive bearing indicator on the Health tab. It rises with race spalling, ball or roller defects, cage damage and lubrication breakdown, and it is charted for each axis and the combined XYZ. See [Health metrics](/docs/monitoring/machine-health/#metric-table). ### FFT spectrum A fast Fourier transform splits a vibration signal into the frequencies it contains, so a chart of amplitude against frequency shows which rotations and impacts produce the vibration. The Health tab draws four spectra, XYZ, X, Y and Z, for the moment you select. Use it to confirm which fault, not whether there is one. See [The FFT spectrum](/docs/monitoring/machine-health/#fft). ### Harmonics Whole-number multiples of the machine's running speed, labeled 1X through 6X. IoTFlows derives the RPM from the vibration itself and draws the markers on the spectrum. A peak on 1X points to imbalance, on 2X to misalignment, and across several harmonics to looseness. See [Harmonics and RPM](/docs/monitoring/machine-health/#harmonics). ### Baseline profile The reference IoTFlows scores a machine's vibration against, chosen per machine on the Health tab. Every machine starts on **Dynamic Baseline**, which scores the machine against its own normal. The alternatives are the four ISO 10816 / 20816 classes and eight machine-type profiles, 13 in all. See [Choose a baseline profile](/docs/monitoring/baseline-profiles/#profiles). ### ISO 10816 The international standard for judging machine vibration severity, republished as ISO 20816. It sorts machines into classes by power and by how rigid the foundation is, from Class I, small machines up to 15 kW, to Class IV, large machines on flexible foundations. IoTFlows offers the four classes as baseline profiles. See [Choose a baseline profile](/docs/monitoring/baseline-profiles/#profiles). ### Health score A number from 0 to 100 that summarizes a machine's vibration against its baseline profile. Read the trend rather than the value: a score that bends downward over weeks is a fault developing. Three health alerts fire at fixed scores, 60 (caution), 40 (warning) and 20 (critical). See [The health score](/docs/monitoring/machine-health/#score) and [Health events](/docs/alerts/asset-event-rules/#health). ### Shock event An **Abnormal Shock Detection** event, recorded when acceleration at the sensor passes the shock threshold. The threshold is stored on the sensor, accepts 20 to 100 g and defaults to 100 g, so only severe impacts register. With **Log** on, each event joins the machine's event list with its value in g. See [Shock events](/docs/alerts/asset-event-rules/#shock). ## Production ### Part A thing your plant makes, with a name, a picture and files, held in the Parts List. Every production number traces back to a part and one of its operations. See [Create parts and operations](/docs/production/parts-and-operations/#model). ### Operation One thing a machine does to a part, for example a roughing pass, a press stroke or a deburr. The operation carries the detection algorithm, the quantity per cycle and the ideal cycle time, so counts, goals and scheduled tasks all belong to it. See [Create parts and operations](/docs/production/parts-and-operations/#model). ### Detection algorithm The rule on an operation that decides when one cycle has finished, which sets the part count and the measured cycle time. BeamTracker takes **Counter** only. SenseAi and SenseAi Embedded take **Continuous Analysis** when the trace never returns to the stopped level, **Discrete Analysis** when each part is one burst with quiet either side, or **Discrete w/o Merge** when every impact is a part. See [Choose an algorithm](/docs/production/choose-an-algorithm/#choose). ### Quantity per cycle How many parts one machine cycle produces, set on the operation as **QTY/OP**. A four-cavity mold makes four parts per shot, so one detected cycle counts four. See [Create parts and operations](/docs/production/parts-and-operations/#units). ### Cascading group A set of machines one part passes through in sequence, grouped so the Assets page reads them as a line. Each machine gets a step number, and every step after Step 1 reports first pass yield against it. See [Group machines into cascades](/docs/monitoring/asset-groups/#concept). ### Scrap reason A named cause, from one organization-wide list, that every scrap entry carries. You pick it in the **Log Scrap** dialog or on a scrap row when you pause or complete a job. There is no free-text alternative, so every scrapped part rolls up under a reason you can rank. See [Log scrap](/docs/production/log-scrap/#reason). ### Work session One continuous run of a task, with a start, an end, and the good parts and scrap logged in it. **Start** or **Resume** in the job runner opens a session; **Pause** and **Complete Job** close it. The Gantt draws sessions as a strip under each bar. A work session is separate from an operator's clock-in. See [Start, pause, and complete a job](/docs/production/run-a-job/#start). ### Job and task A job is an order for a quantity of a part, usually with a due date. A task is one operation of that job on one machine, and it is what the Production Scheduler plans and an operator runs. The **Create Workorder** form adds one task; creating a work order for each operation fans a job out into one task per operation. See [Job, task, or work order?](/docs/production/overview/#naming) and [Create a production work order](/docs/production/create-a-job/). ## Scheduling and maintenance ### Gantt view The Production Scheduler view that draws each task as a bar on a time axis, in a lane per machine, job or person, with dependencies, working hours, work sessions and a capacity lane. Drag a bar to move it, an edge to resize it, or into another lane to reassign it. The optimizer and simulations start here. See [Gantt view](/docs/production/scheduler/#gantt). ### Kanban view The Production Scheduler view that draws one column per group and one card per task. The columns follow the grouping, not the status: grouped by asset you get a column per machine, by operator a column per person. Drag a card to another column to reassign it; status is a chip on the card. See [Kanban view](/docs/production/scheduler/#kanban). ### Optimizer The **Optimize** pill on the Gantt computes a constraint-aware plan in your browser and draws it as dashed ghost bars, with a banner showing violations and span before and after. Nothing is written until you accept it, and the plan is only as good as the time estimates on the tasks. See [Generate a schedule proposal](/docs/production/optimize-the-schedule/). ### Simulation A draft copy of the schedule that lives in your browser, opened from **Simulations** on the Gantt. Your moves are staged instead of written, and the Simulation band scores the draft against the live schedule as it stood when you started. What-ifs change working hours or relax rules without saving them. **Commit** writes the staged changes. See [Try a schedule change without saving it](/docs/production/simulate-a-schedule/). ### Work order In Maintain, one unit of maintenance work, and the only object Maintain has. Only a title and a group are required. It moves through five statuses, Open, In Progress, On Hold, Done and Approved, and can start by hand, from a classified downtime, a machine event rule, a meter or the job runner's **Maintenance** panel. See [Where work orders come from](/docs/maintain/overview/#origins) and [Create a maintenance work order](/docs/maintain/create-a-work-order/). ### Request A work order raised because a machine needs attention now, rather than one a planner scheduled. It is the same record with fewer fields filled in: whoever is closest to the problem raises it, from Maintain, the job runner, a machine stop or a phone, and a planner completes it. See [Submit a maintenance request](/docs/maintain/submit-a-request/#entry-points). ### Preventive maintenance (PM) A recurrence rule stored on a work order that says when the job comes back: a pattern, an interval and an optional end. There is no separate PM record; a quarterly gearbox inspection is a work order carrying its rule. See [Schedule preventive maintenance](/docs/maintain/preventive-maintenance/#no-pm-object). ### Meter A running total on one machine, runtime hours or a part count, that IoTFlows adds to from the machine's own stream and counts toward a trigger point. Three optional behaviors act on it: an email at 85%, an email at the trigger, and an automatic work order at 100%. A reset starts the next cycle. Use a meter for work that depends on use rather than the calendar. See [Trigger maintenance from meter readings](/docs/maintain/meters/#alerts). ### Item One line in the Inventory catalog: a part you buy, a part you make, or a tool you own. Stock, locations and the ledger all hang off items; stock is a quantity of one item at one location. See [Create and edit items](/docs/inventory/manage-items/). ### Reorder point The available quantity at or below which Inventory flags an item for ordering. It is a field on the item, in the item's own unit, and defaults to 0, so an item appears on the **Low** list only once you set one. See [Monitor low stock and reorder points](/docs/inventory/low-stock/#reorder-point). ### Serialized piece One physical object of an item, told apart from every other: this 6 m bar, that 250 kg roll. Each piece carries its own ID, amount and location. A work order holds a specific piece rather than a quantity, and two work orders holding the same piece at overlapping times raise a schedule violation. See [Track serialized pieces and tools](/docs/inventory/serialized-pieces/). ## Alerts and connectivity ### Event rule The pairing, on one machine, of an event type with the channels that carry it: email, push, SMS, the event log, an automatic work order and your chat integrations. All ten event types are always listed on the machine; a rule is live on the channels you switch on. See [Set alert rules for a machine](/docs/alerts/asset-event-rules/#anatomy). ### Machine event The record IoTFlows writes when an event rule on a machine fires and **Log** is on: a health score falling past a threshold, a stop longer than your downtime threshold, a shock above the sensor's limit. Each event carries a severity, Critical, Warning or Caution, and stays in the machine's list until someone dismisses it. See [Review and dismiss machine events](/docs/monitoring/asset-events/). ### Chat integration A named destination your organization creates once on the Integrations page and reuses on any machine. It holds a webhook URL you generate in Slack, Microsoft Teams or Discord, which posts into one channel. You attach it per event type and per machine. See [Send alerts to Slack, Teams, or Discord](/docs/alerts/chat-integrations/#how). ### Webhook An HTTPS endpoint of your own that IoTFlows posts events to, as an HTTP POST with a JSON body. Owners and Administrators add endpoints, subscribe each one to the events it should receive, and set a secret that IoTFlows sends in the `iotflows-secret` header of every delivery, so your handler can reject anything else. See [Send events to your own endpoint](/docs/alerts/webhooks/#secret). ### API key The credential IoTFlows issues to your organization for the REST API. A program sends it with every request and reads the same records the dashboard shows. Ask IoTFlows for a key. See [Integrations](https://www.iotflows.com/platform/integrations) and [Send events to your own endpoint](/docs/alerts/webhooks/). ### MQTT The lightweight publish-and-subscribe protocol behind IoTFlows' live data. Devices connect out to the IoTFlows cloud over HTTPS and MQTTS on port 443, and open dashboard pages subscribe over MQTT, so a machine card repaints the moment its sensor publishes. See [How the dashboard stays live](/docs/get-started/how-iotflows-works/#live-updates). ### MTConnect An open, royalty-free standard from the MTConnect Institute for machine tool data, such as execution state, spindle speed and part count, served read-only over HTTP by software called an agent. On Enterprise, the IoTFlows [edge device](#edge-device) reads CNC machines over MTConnect as a custom integration, beside the sensor data. See [MTConnect, OPC UA and Modbus compared](/blog/machine-communication-protocols/) and [Custom integrations](https://www.iotflows.com/platform/custom-integrations). ### OPC UA Open Platform Communications Unified Architecture: a platform-independent framework from the OPC Foundation for modeling industrial data and exchanging it securely between clients and servers, with reads and writes governed by access permissions. On Enterprise, the IoTFlows [edge device](#edge-device) reads controllers over OPC UA as a custom integration. See [MTConnect, OPC UA and Modbus compared](/blog/machine-communication-protocols/). ### Modbus A request-and-reply protocol from the Modbus Organization in which a client reads or writes numbered bits and 16-bit registers on a device, over Ethernet (Modbus TCP) or a serial line. On Enterprise, the IoTFlows [edge device](#edge-device) reads Modbus TCP devices as a custom integration. See [MTConnect, OPC UA and Modbus compared](/blog/machine-communication-protocols/). ### 2.4 GHz The Wi-Fi band every IoTFlows device joins; a network that broadcasts only on 5 GHz never appears in the device's scan. A device gets its Wi-Fi credentials over Bluetooth from the mobile app in setup mode, then connects out over HTTPS and MQTTS on port 443. The 4G/LTE router broadcasts 2.4 GHz too. See [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/). ### PLC A programmable logic controller, the computer that runs a machine. IoTFlows sensors read the machine from the outside and never connect to it. On Enterprise, PLC data can be brought in on purpose through the IoTFlows edge device as a custom integration. See [Do the sensors connect to my PLC?](/docs/get-started/faq/#plc) and [Custom integrations](https://www.iotflows.com/platform/custom-integrations). ### SCADA Supervisory control and data acquisition: software, controllers and networks that gather data from a process, show it to operators in one place and send commands and setpoints back to the equipment. IoTFlows sensors read a machine from the outside and send nothing to it, so they run beside a SCADA system without touching it. See [How SCADA differs from IIoT and cloud monitoring](/blog/scada-vs-newer-manufacturing-technologies/). ## Manufacturing systems ### Industry 4.0 A strategy for connected production that Germany set out in 2013: machines, products and software exchange data so a plant can see and adjust its operations while they run, instead of after the shift ends. It is a strategy, not a standard a plant can be certified against. See [What Industry 4.0, IIoT and digital twins mean](/blog/industry-4-0-iot-and-digital-twin/). ### IIoT The industrial internet of things: the sensors, machine controllers and software that collect data from industrial equipment and deliver it to the people and systems that run a plant, such as dashboards, maintenance software and production schedules. See [What Industry 4.0, IIoT and digital twins mean](/blog/industry-4-0-iot-and-digital-twin/#iiot). ### Digital twin A software representation of a machine, line or process that exchanges data with it automatically in both directions, so a change in either one shows up in the other. A copy fed only one way, from the machine to the software, is a digital shadow. See [What Industry 4.0, IIoT and digital twins mean](/blog/industry-4-0-iot-and-digital-twin/). ### MES Manufacturing execution system: software that runs operations on the shop floor. It dispatches orders to work centers, tracks each job through its routing, and keeps the record of what was made, when, by whom and to what quality. ISA-95 places it at Level 3, between the business systems above and the machine controls below. See [What IoT machine data adds to an MES](/blog/manufacturing-excellence-with-mes-and-iot/) and [Machine monitoring vs MES vs CMMS](https://www.iotflows.com/compare/machine-monitoring-vs-mes-vs-cmms). ### ERP Enterprise resource planning: the business system that holds orders, routings, inventory, purchasing and costs, at ISA-95 Level 4. The [Production Scheduler](#production-scheduler) imports jobs from any ERP's CSV or Excel export, and on Enterprise a custom integration builds two-way connectors to the ERP's own API. See [Import a schedule from your ERP](/docs/production/import-erp-schedule/) and [Connecting machine data to your ERP](/blog/connect-machine-data-to-erp/). ### CMMS Computerized maintenance management system: software that records maintenance work orders against each machine, schedules preventive maintenance by calendar or run time, tracks spare parts and keeps the repair history. [Maintain](#maintain) is the IoTFlows CMMS, and [Inventory](#inventory) holds the parts it uses. See [What is a CMMS, and why start it from the machine?](/blog/what-is-a-cmms/). ## Products ### SenseAi A magnet-mounted sensor that reads a machine's vibration and sound and reports its status, uptime, downtime and part counts, with no PLC connection. It mounts on or near the machine and sends its data to the IoTFlows cloud over 2.4 GHz Wi-Fi or the IoTFlows 4G/LTE router. See [SenseAi](/docs/hardware/senseai/). ### SenseAi Embedded SenseAi in a sealed IP67 housing that reads vibration and temperature, with no acoustic channel. It runs the same application and reports the same things, and the housing lets it mount on the motor or spindle itself, where coolant, wash-down or dust would end a standard unit. Reading at the source adds advanced health analytics. See [SenseAi Embedded](/docs/hardware/senseai-embedded/). ### BeamTracker A laser sensor that counts units as they pass a point. Each unit that breaks the beam is a timestamped count, and the time between counts decides whether the line reads running or stopped. It counts without touching the part, which suits a line where units move along a fixed path. See [BeamTracker](/docs/hardware/beamtracker/). ### 4G/LTE router (IFCR-150) The IoTFlows cellular router. It creates its own 2.4 GHz network for IoTFlows sensors and carries their traffic to the cloud over 4G/LTE, so they never join a network the plant owns. It ships configured with its SIM fitted, and one router serves every sensor in range. See [IoTFlows 4G/LTE router](/docs/hardware/lte-router/). ### Edge device The IoTFlows edge device is the on-site gateway behind an Enterprise custom integration, typically for plants with 50+ machines. It reads PLCs, robots and third-party sensors over protocols such as OPC UA, Modbus TCP, EtherNet/IP, Profinet and MQTT, and its signals feed the same event rules as sensor data. Each project is scoped and priced with you. See [Custom integrations](https://www.iotflows.com/platform/custom-integrations). ### Production Scheduler The planning surface of the Scheduling Engine module, on the **Scheduler** tab of Production. It holds every open production work order and draws the same schedule five ways: List, Table, Gantt, Kanban and Calendar. Switching views changes nothing about the schedule, only what you can see and move. See [The Production Scheduler](/docs/production/scheduler/#open). ### Maintain The IoTFlows CMMS, on the web and in the iOS and Android apps. Its only object is the work order: a request, a planned job and a preventive maintenance schedule are the same record with different fields filled in. It shows your organization's work orders in List, Table, Kanban and Calendar views. See [Overview: maintenance management](/docs/maintain/overview/). ### Inventory The IoTFlows storeroom: a catalog of the parts and tools you stock, a count of each one by location, and a ledger of every movement. Maintain and Production hold no stock of their own; a work order reserves what it needs, and closing it moves the stock. See [Overview: track parts and tools](/docs/inventory/overview/). --- # How sensors, the cloud, and the dashboard fit together Source: https://www.iotflows.com/docs/get-started/how-iotflows-works/ The four layers a reading passes through, from the sensor on the machine through Wi-Fi or the 4G/LTE router to the IoTFlows cloud and the dashboard: what each layer decides, why running and stopped is decided on the device while uptime and health are computed in the cloud, and what each layer looks like when it fails. # How sensors, the cloud, and the dashboard fit together Trace one vibration reading from the machine to the number on the screen. Four layers stand between a spindle turning and an uptime figure on a dashboard: the sensor, the network it joins, the IoTFlows cloud, and the client you read it on. Each layer decides something different. Knowing which layer owns which decision tells you where to look when a number looks wrong. ## The four layers A reading takes the same four hops on every machine. Diagram: A diagram of four layers. A machine with a sensor feeds two parallel network paths, Wi-Fi and a 4G/LTE router, which both lead into the IoTFlows cloud, which in turn feeds a dashboard and a mobile app. Labels under each layer read: running or stopped decided here; carries readings, decides nothing; utilization, uptime, downtime, parts, health; live, over MQTT. *How a reading travels: sensor, then Wi-Fi or the 4G/LTE router, then the IoTFlows cloud, then the dashboard and the mobile apps.* 1. **The sensor** sits on the machine and senses it continuously. What it senses depends on the device: SenseAi reads vibration and acoustics, SenseAi Embedded reads vibration and temperature, and BeamTracker reads a laser beam broken by a passing part. 2. **The network** carries what the sensor publishes. That is either a 2.4 GHz Wi-Fi network in your facility or the IoTFlows 4G/LTE router, which makes its own cellular uplink. 3. **The IoTFlows cloud** receives the stream, stores it, and turns it into metrics. 4. **The clients**, meaning the web dashboard and the iOS and Android apps, read those metrics and subscribe to live updates. Each sensor appears in IoTFlows as a *node*, the device record that is paired to one asset. An asset with no node is a name on a list, because every number on this page starts at a node. Choose the 4G/LTE router when plant IT will not put devices on the facility network, or when the machine sits outside Wi-Fi coverage. Otherwise use facility Wi-Fi: it is one fewer device to power and monitor. See [Connect a device through the 4G/LTE router](/docs/hardware/use-the-lte-router/). ## What the sensor decides on the device The sensor decides one thing, and it decides it locally: what just happened on the machine. For SenseAi and SenseAi Embedded that is whether it is running; for BeamTracker, whether a part just passed. It compares what it senses against settings fixed during calibration, and those settings differ by device. SenseAi and SenseAi Embedded first smooth the vibration signal with **Momentum**, so brief swings don't register. Two thresholds then read the smoothed signal: the machine is running once it rises above the upper threshold, and stopped once it falls below the lower one. Momentum keeps a machine that idles for four seconds between cycles from logging four seconds of downtime. BeamTracker measures distance instead. A **Detection distance** and a **Min Object Thickness** bracket where a part counts as present, and the gap between them stops a part hovering on one edge from chattering the count. Those settings are stored on the node, so the decision survives a network outage. A sensor with no route to the cloud still knows the machine is running; it just has nowhere to say so. See [Calibrate SenseAi](/docs/hardware/calibrate-senseai/), [Calibrate BeamTracker](/docs/hardware/calibrate-beamtracker/), and [Calibration settings reference](/docs/hardware/calibration-settings/). This is why calibration matters more than any dashboard setting. Every metric downstream is built from the running and stopped stream, and no cloud calculation can recover a boundary the sensor read wrong. ## What the cloud decides The cloud never re-decides whether the machine was running. It aggregates. Diagram: A two-column diagram divided by a dashed line. The left column, headed On the sensor, runs downward: what the sensor senses, being vibration and acoustics or a laser beam broken by a part; then the settings that shape the decision, which differ by device, with upper and lower thresholds and Momentum for SenseAi and SenseAi Embedded, and detection distance and minimum object thickness for BeamTracker; then a square-wave trace labeled Running or stopped, or a part detected, which both families produce. A single arrow carries that trace across the divider into the right column, headed In the cloud, where it branches into utilization, uptime, downtime, part counts, and a health score measured against a baseline. The left column is footed 'Decided in the moment. A boundary read wrong cannot be recovered.' The right column is footed 'Derived from that timeline. Recomputed on demand.' *What the sensor decides on the device and what the cloud decides. The sensor decides what just happened, running or stopped on SenseAi and a part detected on BeamTracker; utilization, uptime and health scores are computed in the cloud.* From that stream, the cloud computes utilization, uptime, downtime, and part counts, and splits all of them across shifts, departments, and date ranges. For BeamTracker it derives running time from the part detections first. Every metric has one definition, in [Metrics reference](/docs/monitoring/metrics-reference/). Machine health is computed in the cloud too, against a *baseline*: the vibration signature the machine shows when it is healthy, which a health score is measured against. Because a baseline is a statement about one machine over weeks, it can only exist where the history is, which is the cloud. See [Choose a machine health baseline profile](/docs/monitoring/baseline-profiles/). The cloud also owns everything a sensor never sees: jobs, work orders, stock, and people. A part count from a BeamTracker and a scrap count typed by an operator meet for the first time in the cloud. ## How the dashboard stays live The dashboard does not poll for changes. It subscribes. *MQTT* is a lightweight publish-subscribe protocol, the one IoTFlows uses to push changes to open pages the moment they happen. When you open the Assets page, it subscribes to the event stream for your organization and repaints an asset card as each node publishes, with no page refresh. The same transport carries the work queue, the canvas, the production pages, and chat. A work order that a technician closes on a phone changes on your screen while you are looking at it. Live updates and page data are separate. The metrics on a page are loaded once over the API when the page opens; MQTT only keeps them current. If the live connection drops, the page keeps its last-loaded numbers and stops advancing. See [What works without a connection](/docs/get-started/offline-behavior/). ## What happens when a layer drops Each layer fails differently. Read the symptom and go straight to the layer that owns it. ### Layer responsibilities | Layer | Decides | Fails how | Reader-visible symptom | |---|---|---|---| | Sensor | The boundary: running or stopped, or a part detected | Loses power, comes loose from the machine, or is calibrated wrong | The device reads offline in **Devices**, or the machine reads stopped while it is clearly cutting | | Network | Whether readings reach the cloud | Wi-Fi password changes, access point is out of range, router loses its cellular uplink | The device reads offline in **Devices**, and charts show a gap for the length of the outage | | Cloud | Utilization, uptime, downtime, part counts, health scores | Rare, and never partial for one machine | Every machine stops advancing at once, not one | | Client | What you see, and how fast you see it | The browser or phone loses its connection to the live stream | The page keeps its last-loaded numbers and stops updating | The first two rows share a symptom, so check the network before the sensor. See [Troubleshoot an offline device](/docs/hardware/troubleshoot-offline-device/). ## See also - [Connect a device through the 4G/LTE router](/docs/hardware/use-the-lte-router/) - [What works without a connection](/docs/get-started/offline-behavior/) - [Metrics reference](/docs/monitoring/metrics-reference/) - [Troubleshoot an offline device](/docs/hardware/troubleshoot-offline-device/) --- # Install the mobile app and sign in Source: https://www.iotflows.com/docs/get-started/install-mobile-app/ Install the IoTFlows app from the App Store or Google Play, sign in with the same account you use on the web, turn on Face ID on iOS, allow notifications so push alerts arrive, and see which capabilities exist only on a phone: Bluetooth Wi-Fi provisioning, push, camera-first maintenance requests, and the system share sheet. # Install the mobile app and sign in The mobile prerequisite that Wi-Fi provisioning, push alerts, and camera-first work orders all depend on. The IoTFlows app is one app on both platforms and carries the same organizations, assets, and chats as the dashboard. Some things exist only there. Putting a sensor on a network is the important one, and there is no web equivalent for it. Install the app even if you work from a desk. Bluetooth Wi-Fi *provisioning*, sending a device the network name and password it should join, happens over a short-range radio link from a phone standing next to the machine, and it is the only way to put a device on a network. You need an IoTFlows account before the app shows anything. See [Sign in to IoTFlows](/docs/get-started/sign-in/). ## Install 1. Open the [App Store listing](https://apps.apple.com/us/app/iotflows/id6471156025) on iOS, or the [Google Play listing](https://play.google.com/store/apps/details?id=com.iotflows.iotflows_android_app) on Android. 2. Install **IoTFlows**. Searching the store for `iotflows` finds the same listing. 3. Open the app. ## Sign in The app asks for your email address first and decides from the address what to ask for next, the same as the web. An address covered by single sign-on goes to your provider; every other address gets a password field. A two-step code, if your account has one, is asked for here too. ![The IoTFlows iOS sign-in screen with an email field and a Continue button](/images/get-started/gs-mobile-01.webp) *Signing in on iOS. The app uses the same account as the web dashboard.* If you belong to more than one organization, the app opens in one of them and you switch from the drawer. See [Switch between organizations](/docs/get-started/switch-organizations/). ## Turn on biometric sign-in (iOS) Sign in with your password once first. The app cannot enroll a face against an account it has never seen. 1. On the sign-in screen, turn the **Face ID** switch on. 2. Sign in with your email and password. 3. On later launches, select the Face ID button that now sits on the sign-in screen. ![The iOS Face ID enrolment prompt shown over the IoTFlows sign-in screen](/images/get-started/gs-mobile-02.webp) *Turning on Face ID means you do not retype a password at the machine.* Turning the switch back off clears the stored credentials, so the next sign-in asks for the password again. Touch ID works the same way on a device with a home button. The Android app has no biometric option. ## Allow notifications The app asks for notification permission on first launch. Allow it. ![The Android system dialog asking whether IoTFlows may send notifications, with Allow and Don't allow](/images/get-started/gs-mobile-03.webp) *Allow notifications during install. A rule with push enabled and permission denied fails silently.* > **Warning:** > **Declined the prompt?** Every alert rule that sends to the push channel stops arriving on that phone, with no error anywhere in IoTFlows. Turn notifications back on for IoTFlows in the operating system's own settings. See [Troubleshoot alerts](/docs/alerts/troubleshoot-alerts/). ## What the app does that the web does not Four capabilities have no web path. Bluetooth Wi-Fi provisioning is the one that blocks an install, so do that from a phone standing at the machine. See [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/). The app also carries its own **Devices** list under **Settings**, with signal strength per sensor, which is what you read while walking the floor rather than sitting at the dashboard. ### What each client can do | Capability | Web | iOS | Android | Page | |---|---|---|---|---| | Bluetooth Wi-Fi provisioning | No | Yes | Yes | [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/) | | Push notifications | No | Yes | Yes | [Push notifications on mobile](/docs/alerts/mobile-push/) | | Face ID or Touch ID sign-in | No | Yes | No | This page | | Start a request from the camera | No | Yes | Yes | [Submit a maintenance request](/docs/maintain/submit-a-request/) | | Share a photo or file in from another app | No | Yes | Yes | [Submit a maintenance request](/docs/maintain/submit-a-request/) | | Device list with signal strength | Yes | Yes | Yes | [View your devices](/docs/hardware/view-devices/) | | Floor-plan canvas | Yes | No | No | [Build a floor plan](/docs/monitoring/canvas/) | | Global search | Yes | No | No | [Navigate and search the dashboard](/docs/get-started/navigate-the-dashboard/) | You do not need the app on every operator's personal phone. A shared tablet at the machine covers the operator tasks, and the sensor work is done once by whoever installs the hardware. ## See also - [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/) - [Push notifications on mobile](/docs/alerts/mobile-push/) - [Submit a maintenance request](/docs/maintain/submit-a-request/) - [What works without a connection](/docs/get-started/offline-behavior/) --- # Navigate and search the dashboard Source: https://www.iotflows.com/docs/get-started/navigate-the-dashboard/ How the IoTFlows dashboard is laid out: the eight product tabs and the routes behind them, the header search box that finds a machine, part or person by name across your organization, the dark mode switch that is stored on your account rather than the browser, the profile menu that holds Operator View, and what the mobile app carries instead. # Navigate and search the dashboard Where each product lives, how search finds a record by name, and how to change the appearance. The dashboard puts every product behind one row of tabs. Above them sits a header carrying the organization switcher, a search box, and your profile picture. An *organization* is the workspace that owns your machines, people, and data, and its identifier is the first segment of every URL you will see in the address bar. Everything on this page assumes you are [signed in](/docs/get-started/sign-in/). ## The product navigation The tab row holds eight products: **Assets**, **Production**, **Maintain**, **Inventory**, **Messaging**, **Devices**, **Integrations**, and **Logs**. Selecting a tab keeps you in the organization you are already in. ![The dashboard tab row showing Assets, Production, Maintain, Inventory, Messaging, Devices, Integrations and Logs](/images/get-started/gs-nav-01.webp) *The product navigation. A product missing from your nav usually means a role gate, not a bug.* **Members** and **Settings** are not tabs. Member avatars and a gear icon sit at the right of the header, next to your profile picture. ### Where things live Routes below are written without the leading organization segment, so `/assets` appears in the address bar as `//assets`. | Route | Product | Documented at | |---|---|---| | `/assets` | Assets | [Assets overview](/docs/monitoring/assets-overview/) | | `/production` | Production | [Production overview](/docs/production/overview/) | | `/maintenance` | Maintain | [Maintain overview](/docs/maintain/overview/) | | `/inventory` | Inventory | [Inventory overview](/docs/inventory/overview/) | | `/chats` | Messaging | [Messaging overview](/docs/messaging/overview/) | | `/devices` | Devices | [View your devices](/docs/hardware/view-devices/) | | `/integrations` | Integrations | [Alerts overview](/docs/alerts/overview/) | | `/logs` | Logs | [Audit log](/docs/admin/audit-log/) | | `/members` | Members | [Manage members](/docs/admin/manage-members/) | | `/settings/organization` | Organization settings | [Administration overview](/docs/admin/overview/) | | `/settings/user` | Your profile | [Your profile](/docs/admin/profile/) | | `/settings/billing` | Billing | [Billing](/docs/admin/billing/) | > **Note:** > **A product you cannot reach?** That is a role gate, not a bug. **Integrations** stays visible but grayed out for anyone who is not an Owner or an Administrator, and hovering it says so. See [Roles reference](/docs/admin/roles-reference/). ## Global search The search box in the middle of the header searches the organization you are currently in. Results appear as you type, grouped by the type of record, each row carrying a name and a short line of detail. Selecting a result opens that record. ![The header search box with a machine name typed in, showing results under grouped headings](/images/get-started/gs-nav-02.webp) *Global search returns results grouped by type: machines, parts, people, work orders.* Use global search when you know the name of a machine, part, or person. Use the filters on a product page when you know the shape of the answer but not its name, for example every downtime longer than 20 minutes on the press line. Search is web-only. The mobile app searches within a section rather than across the organization. A query that matches nothing returns **No search results found**. Search matches on names, so a machine you know by its serial number may only answer to the name someone gave it in [Add an asset](/docs/monitoring/add-an-asset/). ## Dark mode The sun and moon switch in the header changes the theme. It applies immediately, with no reload. Your choice is stored on your account rather than in the browser, so it follows you to another browser or another computer. Signing in on a new machine brings the theme with you. ![The sun and moon toggle switch in the dashboard header](/images/get-started/gs-nav-03.webp) *Dark mode is stored on your account, so it follows you to another browser.* ## Your profile menu Your profile picture at the far right of the header opens a menu showing your name and email, then **Profile**, **Billing**, **Operator View**, and **Sign out**. **Operator View** turns the dashboard into a full-screen page for one machine, meant for a screen on the floor rather than a desk. Leaving it uses **Exit Operator View** in the same menu. See [Operator View](/docs/monitoring/operator-view/). You do not need Operator View at a desk. It removes the product tabs on purpose, so an operator working one machine cannot wander into billing. ![The profile menu expanded, listing Profile, Billing, Operator View and Sign out](/images/get-started/gs-nav-04.webp) *The profile menu holds the Operator View toggle and your account settings.* ## On mobile The app carries five sections rather than eight: **Assets**, **Production**, **Messaging**, **Maintain**, and a fifth tab for your account, called **Settings** on iOS and **More** on Android. Devices, Inventory, Integrations, and Logs are web-only. Switching organizations moves to a drawer on Android and a modal on iOS. See [Switch between organizations](/docs/get-started/switch-organizations/). ## See also - [Switch between organizations](/docs/get-started/switch-organizations/) - [Roles reference](/docs/admin/roles-reference/) - [Assets overview](/docs/monitoring/assets-overview/) - [Overview: what IoTFlows does](/docs/get-started/overview/) --- # What works without a connection Source: https://www.iotflows.com/docs/get-started/offline-behavior/ What each IoTFlows client keeps when the network drops, which differs by platform: Android stores chats on the device and queues messaging writes in an outbox that flushes oldest first, iOS holds messages in memory and asks you to tap a failed send to retry, Maintain caches its list on iOS only, Inventory paints a cached parts list on both but refuses offline adjustments, and the web dashboard caches nothing at all and freezes on its last-loaded numbers behind a Waiting for Network or Trying to connect toast. # What works without a connection What each client can still do when the network drops, and what happens when it comes back. Every client holds an open connection to the IoTFlows cloud and redraws as readings arrive. What survives losing that connection differs by client, and on mobile it differs by platform. Sections about the phone assume the app is installed. See [Install the mobile app and sign in](/docs/get-started/install-mobile-app/). ## Offline behavior by surface | Surface | Client | Readable offline | Writable offline | On reconnect | |---|---|---|---|---| | Messaging | Android | Yes, chats and history from the on-device database | Yes, queued in the outbox | Outbox flushes, oldest first | | Messaging | iOS | No, messages are held in memory only | No, a failed send turns red | Tap the red bubble to resend | | Chat attachments | Android, iOS | Files opened recently, from the media cache | No | Download resumes | | Maintain | Android | No | No | List refetched | | Maintain | iOS | Yes, the last list fetched for that view | No | Cached list refreshed in place | | Inventory | Android, iOS | Yes, the last parts list fetched | No, adjustments fail | Cached list replaced wholesale | | Everything | Web | No | No | Live updates resume, figures do not refresh | ## On mobile Diagram: A state machine of four boxes in a row, joined left to right by arrows. Live: updates arrive as they happen. Degraded: the last-loaded data stays on screen and stops updating. Offline: reads come from cache, and writes either queue or fail. Reconnecting: the client retries from about one second apart, backing off to about sixty. A return arrow runs from Reconnecting back to Live, labeled: subscriptions are restored and the mobile outbox flushes, oldest message first. *What each client does as the connection degrades: live, degraded, offline, reconnecting.* Check which phone your operators carry before you rely on any of this. **Android** keeps chats, messages, and members in a database on the device, so a thread opens and scrolls with no connection. Its messaging writes go to an *outbox*, a queue holding the actions you took while disconnected: sending, editing, deleting, pinning, reacting, and saving a draft. They publish in the order you made them. **iOS** has neither. Messages are held in memory for as long as the screen is open, and a send that does not reach the server turns red for you to tap. Nothing queues and nothing retries on its own, so leaving the chat loses the message. Attachments are cached on both. A file you opened recently plays from the device instead of the network, and anything older waits. Maintain and Inventory hold less. Inventory paints the last parts list it fetched on both platforms, but a stock count is a shared number other people are changing, so an adjustment made offline fails rather than queuing. Maintain caches its list on iOS only, per view; on Android the tab stays empty until a request succeeds. ## On the web The dashboard caches nothing. There is no offline mode and no stored copy, so a tab opened without a connection shows nothing. A tab already open keeps whatever it last loaded and stops updating. The numbers on screen are the numbers from the moment the link dropped, not the current ones. Two toasts report the same condition in different words: **Waiting for Network** and **Trying to connect**. Both mean an action needed the live connection, it was not there, and the change was not sent. Repeat the action once the connection is back. > **Warning:** > Do not site an operator station on Wi-Fi that drops out, expecting the web dashboard to ride it out. It does not cache, so every dropout blanks the screen. Put the operator on the mobile app instead, or fix the coverage first. ## When the sensor loses connection A sensor that cannot reach the cloud publishes nothing, so the cloud has nothing to record. The gap becomes [unknown time](/docs/get-started/glossary/#unknown-time): gray on the shift status bar, left out of uptime and downtime alike, and reported on its own as unknown hours. If you know what the machine did during the gap, you can change the stretch to running or stopped. The machine card keeps the last state the cloud recorded, so a machine whose sensor dropped while it was stopped still reads as stopped. Check the status bar before you classify anything: gray means the link was down, not the machine. See [Get a device back online](/docs/hardware/troubleshoot-offline-device/). ## On reconnect The web dashboard reconnects on its own, and keeps trying indefinitely. It retries about a second after the drop, then doubles the wait each time up to a minute. It also reconnects at once when your operating system reports the network back, or when you return to the tab. A **Reconnecting** toast stays up while it works. Live updates resume as soon as it succeeds. Figures loaded when you opened the page are not fetched again, so reload if you need a number to be current. Android works through its backlog in a fixed order: the outbox first, then the chat list, then the thread you have open. iOS has no backlog to work through, so a message that failed while you were offline is still sitting there unsent. ## See also - [Install the mobile app and sign in](/docs/get-started/install-mobile-app/) - [Get a device back online](/docs/hardware/troubleshoot-offline-device/) - [Send messages](/docs/messaging/send-messages/) - [Set up an operator station](/docs/monitoring/operator-stations/) --- # Overview: what IoTFlows does Source: https://www.iotflows.com/docs/get-started/overview/ What IoTFlows is and where to start in its docs: the quickstart, how a reading travels from a sensor through Wi-Fi or the 4G/LTE router to the IoTFlows cloud and the dashboard, what the platform reports from that one signal (uptime, downtime, part counts, machine health, and the OEE factors on their own), which device fits which machine (SenseAi, SenseAi Embedded, BeamTracker, the IFCR-150 router, the edge device for Enterprise custom integrations), the eight sections of the docs, which page answers which question, and what you need before the first machine shows data. # What IoTFlows does Learn what IoTFlows measures, which part of it answers your question, and where to start. IoTFlows is a manufacturing intelligence platform that monitors machines with plug-and-play sensors or custom integrations to any PLC, robot or sensor, and turns the data into utilization, downtime, OEE, production scheduling and maintenance workflows. Everything you set up lives in an *organization*, the account that owns your machines, your people and your data. IoTFlows creates it for you, and one sign-in can belong to several. See [Switch between organizations](/docs/get-started/switch-organizations/). ## Start here - [Quickstart](/docs/get-started/quickstart/) — Take one machine from a sensor in the box to live utilization in about an hour. - [How IoTFlows works](/docs/get-started/how-iotflows-works/) — Follow one reading from the sensor through the network and the cloud to your screen. - [Sign in](/docs/get-started/sign-in/) — Sign in at dashboard.iotflows.com with your email, your company's SSO or a two-step code. - [Install the mobile app](/docs/get-started/install-mobile-app/) — Get the iOS or Android app. You need it to put a sensor on Wi-Fi. ## What the platform measures A sensor on the machine decides, second by second, whether the machine is running. The IoTFlows cloud turns that stream into numbers, and the web dashboard and the mobile apps show them live. Diagram: A diagram of four layers. A machine with a sensor feeds two parallel network paths, Wi-Fi and a 4G/LTE router, which both lead into the IoTFlows cloud, which in turn feeds a dashboard and a mobile app. Labels under each layer read: running or stopped decided here; carries readings, decides nothing; utilization, uptime, downtime, parts, health; live, over MQTT. *How a reading travels: sensor, then Wi-Fi or the 4G/LTE router, then the IoTFlows cloud, then the dashboard and the mobile apps.* What a sensor reads depends on the device. SenseAi reads vibration and acoustics, SenseAi Embedded reads vibration and temperature, and BeamTracker reads a laser beam that a passing part breaks. From those readings, IoTFlows reports: - **[Uptime](/docs/get-started/glossary/#uptime):** the share of time the machine ran, running time divided by running plus stopped time. The Assets page shows the same figure as **Utilization**. - **[Downtime](/docs/get-started/glossary/#downtime):** the time the machine was stopped, whether or not anyone has given the stop a reason yet. - **[Part counts](/docs/get-started/glossary/#detection-algorithm):** units BeamTracker counts directly, or cycles a detection algorithm finds in the SenseAi and SenseAi Embedded trace, once you set up a part and an operation. - **[Health score](/docs/get-started/glossary/#health-score):** a 0 to 100 score per machine from the vibration that SenseAi and SenseAi Embedded read, measured against the machine's baseline. IoTFlows reports the [OEE](/docs/get-started/glossary/#oee) factors on their own: availability as uptime, performance as the parts gauge, and [quality](/docs/get-started/glossary/#quality) from the scrap your team logs against a job. Every metric has one definition, in [How each metric is calculated](/docs/monitoring/metrics-reference/). An *asset* is one machine as IoTFlows tracks it, and a *node* is the device record paired to that asset. An asset with no node shows no data. ## The hardware ![IoTFlows sensors beside screens showing the IoTFlows dashboard on a wall display, a laptop, a monitor, and a phone](/images/get-started/gs-overview-01.webp) *The BeamTracker, SenseAi and SenseAi Embedded sensors, and the dashboard they report into on a wall display, laptop, monitor and phone.* Pick a device by what you need to know about a machine, not by what the machine is. | Device | Choose it when | |---|---| | [SenseAi](/docs/hardware/senseai/) | You monitor general machinery on an ordinary shop floor. It reads vibration and acoustics and mounts with magnets on or near the machine. | | [SenseAi Embedded](/docs/hardware/senseai-embedded/) | You can mount on the motor or spindle itself, or the spot sees coolant, wash-down or dust. It reads vibration and temperature and is IP67 rated. | | [BeamTracker](/docs/hardware/beamtracker/) | You count units moving along a fixed path, such as a conveyor. Each unit that breaks its laser beam is one count. | | [IoTFlows 4G/LTE router (IFCR-150)](/docs/hardware/lte-router/) | Plant IT will not put devices on the facility network, or the machine is out of Wi-Fi range. It carries traffic and reads nothing. | For data straight from PLCs, robots or third-party sensors, an Enterprise custom integration connects them through the [IoTFlows edge device](/docs/get-started/glossary/#edge-device). To match a device to one machine, see [Choose for a machine](/docs/hardware/overview/#choose). ## The products Each product has its own section in these docs. Open the one that matches your job. - [Machine monitoring](/docs/monitoring/overview/) — Whether each machine is running now, how much of the shift it ran, and where the stopped time went. - [Production](/docs/production/overview/) — Good and scrap counts against a shift goal, and jobs planned across machines in the Production Scheduler. - [Maintain](/docs/maintain/overview/) — Requests, work orders, preventive schedules and meters, with work orders opened from a stop, a rule or a meter. - [Inventory](/docs/inventory/overview/) — Parts and tools counted by location, with stock that moves when a work order closes. - [Alerts and integrations](/docs/alerts/overview/) — Event rules that reach people by email, push or SMS, post to Slack, Microsoft Teams or Discord, or open a work order. - [Messaging](/docs/messaging/overview/) — Chats between people on the web and in the apps, and comments that stay with a work order. - [Hardware](/docs/hardware/overview/) — Mount, connect and calibrate SenseAi, SenseAi Embedded, BeamTracker and the 4G/LTE router. - [Administration](/docs/admin/overview/) — Members, roles, machine access, shifts and time zone, and billing. You do not need Production or the Production Scheduler to know whether machines are running. Uptime, utilization and downtime come from the sensor alone. ## Which page answers which question | I want to… | Read | |---|---| | Know whether a machine is running right now | [Monitor your fleet on the Assets page](/docs/monitoring/assets-overview/) | | Find out where my machine hours go | [Analyze downtime with Pareto and trend charts](/docs/monitoring/downtimes/) | | Count good parts and scrap per shift | [Overview: track and schedule production](/docs/production/overview/) | | Sequence jobs across machines | [Overview: track and schedule production](/docs/production/overview/) | | Get told when a machine stops | [Overview: alerts and integrations](/docs/alerts/overview/) | | Plan maintenance and act on breakdowns | [Overview: maintenance management](/docs/maintain/overview/) | | Know what spare parts are on the shelf | [Overview: track parts and tools](/docs/inventory/overview/) | | Decide which sensor fits a machine | [Overview: IoTFlows hardware](/docs/hardware/overview/) | | Look up a term | [Glossary](/docs/get-started/glossary/) | ## What you need to get started 1. A device for each machine you want to watch: SenseAi, SenseAi Embedded or BeamTracker. 2. A 2.4 GHz Wi-Fi network that reaches the machine, or the IoTFlows 4G/LTE router. 3. The IoTFlows mobile app on the phone you carry to the machine. Wi-Fi setup runs over Bluetooth from the app. 4. A sign-in with the Organization Owner or Organization Administrator role. Only those roles can add a machine. See [Roles reference](/docs/admin/roles-reference/). IoTFlows onboards the hardware for you. Devices arrive registered to your organization, so you never create one. You add each machine as an asset, and IoTFlows pairs the device to it, usually during onboarding. To have a device paired, see [Contact support](/docs/get-started/get-support/). With those in place, follow the [Quickstart](/docs/get-started/quickstart/) for your first machine. ## The platform and pricing - [The IoTFlows platform](https://www.iotflows.com/) — Monitor, schedule and maintain every machine on the floor, on one platform. - [Pricing](https://www.iotflows.com/pricing) — Per-device plans, the Enterprise plan and the hardware, in one place. ## See also - [Quickstart: see your first machine's data](/docs/get-started/quickstart/) - [How sensors, the cloud, and the dashboard fit together](/docs/get-started/how-iotflows-works/) - [Plan your rollout](/docs/get-started/roll-out-plan/) - [Glossary](/docs/get-started/glossary/) - [Frequently asked questions](/docs/get-started/faq/) --- # Quickstart: see your first machine's data Source: https://www.iotflows.com/docs/get-started/quickstart/ The end-to-end path from a sensor in the box to one machine reporting live utilization, for SenseAi, SenseAi Embedded, and BeamTracker: mount and power the device, connect it to Wi-Fi or the 4G/LTE router, create the machine as an asset, confirm data is arriving, and set what counts as running. # Quickstart: see your first machine's data Go from a sensor in the box to a machine reporting live utilization. This page follows one machine down one path: mount the device, get it online, create the machine in IoTFlows, and check the first hour of data. Plan on an hour, most of which is the machine running while you watch. It covers all three sensors. Two steps differ by device, mounting and calibration, and each carries a tab strip. Pick your device there; the rest of the page reads the same for everyone. Two terms carry the whole page. An *asset* is one machine as IoTFlows tracks it: a name, an identifier, a department, and the device that reports its status. *Utilization* is the share of time that device read the machine as running. Every device reports it, from what it senses: SenseAi and SenseAi Embedded from vibration, BeamTracker from parts passing through its laser beam. See [Metrics reference](/docs/monitoring/metrics-reference/). ## Before you start - A SenseAi, SenseAi Embedded, or BeamTracker that IoTFlows has onboarded to your organization. The device arrives registered; you do not create it. See [IoTFlows hardware](/docs/hardware/overview/). - The IoTFlows mobile app, signed in on the phone you will carry to the machine. Wi-Fi setup runs over Bluetooth from the app and has no web equivalent. See [Install the mobile app](/docs/get-started/install-mobile-app/). - Sign in to the web dashboard as an Organization Owner or Organization Administrator. Other roles cannot create an asset. See [Roles reference](/docs/admin/roles-reference/). - Either the IoTFlows 4G/LTE router, or the name and password of a 2.4 GHz Wi-Fi network that reaches the machine. You do not need parts, operations, or an algorithm to finish this page. Those change how IoTFlows counts parts, not whether the machine reads as running. Come back for them in the [Production quickstart](/docs/production/quickstart/). ## Mount and power the device Where you put the device decides how good every number on this page is. Go to **Devices** at `//devices?select=management` first and find yours in the topology map. It reads offline until the next section. ![The Devices topology map showing assets linked to sensors and on to the cloud](/images/get-started/gs-quickstart-01.webp) *The Devices topology map links each asset to its sensor and on to the cloud. A green dot marks every device that is online.* #### senseai 1. Connect the external antenna to the sensor before anything else. 2. Pick a spot of flat ferrous metal, close to the spindle, motor, or hydraulic pump. Paint is fine; rubber and plastic give the magnet nothing to hold. 3. Attach the sensor with its magnetic base, flat against that surface, where nothing moving can catch it. 4. Connect the USB cable to the sensor and plug the adapter into an outlet. The LED lights when the sensor has power. ![A SenseAi sensor magnetically mounted on the spindle housing of a machining center](/images/get-started/gs-quickstart-02.webp) *SenseAi mounted flat against the spindle housing, where the vibration you want to measure actually is.* A sensor mounted on a guard door reads the door, not the cut. For an enclosed machine or one with no flat steel, see [Install and power up SenseAi](/docs/hardware/install-senseai/). #### embedded 1. Connect the external antenna to the unit, hand-tight. Without it the radio has almost no range and the device will not hold a connection. 2. Pick a spot with metal-to-metal contact, close to the spindle or motor, and position the unit so it reads all three axes of that movement rather than one direction of it. The sealed IP67 enclosure means that spot can be somewhere exposed to coolant, cutting fluid, or wash-down. 3. Clean the surface, then attach the unit by its magnetic base. The base needs ferrous metal; on anything else, contact IoTFlows for a mounting option. 4. Connect the M12 cable to the unit, then to the M12 power adapter or a T-splitter if you are daisy-chaining power. The LED lights when the unit has power. ![A SenseAi Embedded unit magnetically mounted near a machining center's work area, with M12 cabling](/images/get-started/gs-quickstart-11.webp) *SenseAi Embedded held by its magnetic base in a coolant-exposed spot, with the M12 cable run out to power.* Mounting placement and the M12 power options are the substance of this step, and they have their own page: [Install and power up SenseAi Embedded](/docs/hardware/install-senseai-embedded/). #### beamtracker 1. Mount the bracket where every good part passes the beam and nothing else does. A beam that also catches the operator's hand will count hands. 2. Fix the head to the bracket and aim it across the part path, square to the passing part. 3. Connect power. The touchscreen lights and runs its startup sequence. ![A BeamTracker on its bracket beside a conveyor, with the beam crossing the part path](/images/get-started/gs-quickstart-08.webp) *A BeamTracker on its bracket beside a conveyor, with the beam crossing where finished parts pass and nothing else does.* Beam geometry is the whole job here. For bracket options and alignment, see [Install and align BeamTracker](/docs/hardware/install-beamtracker/). ## Connect it to the network Every device takes the same two paths onto the network. Which one you use depends on what you bought. **With the IoTFlows 4G/LTE router**, there is nothing to configure. Power the router within 100 ft (30 m) of the device, near a window for cellular signal, and the device joins its access point on its own. Skip to the next section. See [Connect through the 4G/LTE router](/docs/hardware/use-the-lte-router/). **On your own Wi-Fi**, provisioning happens over Bluetooth, from the phone, standing at the machine. 1. Put the device into setup mode. On SenseAi and SenseAi Embedded, hold the Wi-Fi button for ten seconds until the LED blinks blue. On BeamTracker, tap the **Settings** icon on the touchscreen, then **WiFi Configuration**. 2. In the app, open **Connect Device to WiFi** and select your device from the list of nearby devices. 3. Pick the 2.4 GHz network, type the password, and send it. The device reboots and joins the network. ![The mobile app's device list before setup](/images/get-started/gs-quickstart-03-1.webp) ![Choosing SenseAi, SenseAi Embedded, or BeamTracker in the app](/images/get-started/gs-quickstart-03-2.webp) ![Setup-mode instructions with the app scanning for nearby devices](/images/get-started/gs-quickstart-03-3.webp) ![Choosing a Wi-Fi network and entering the password](/images/get-started/gs-quickstart-03-4.webp) ![A SenseAi with its LED blinking blue in Wi-Fi setup mode](/images/get-started/gs-quickstart-13.gif) *SenseAi* ![A SenseAi Embedded unit with its LED blinking blue in Wi-Fi setup mode](/images/get-started/gs-quickstart-12.gif) *SenseAi Embedded* ![The BeamTracker touchscreen showing its WiFi Setup screen](/images/get-started/gs-quickstart-09.webp) *BeamTracker* Reload the **Devices** page. The device reads online within a minute or two of joining the network. > **Note:** > **Still offline after a few minutes?** The three usual causes are a 5 GHz-only network, a mistyped password, and weak signal at the machine. Work through [Troubleshoot an offline device](/docs/hardware/troubleshoot-offline-device/) before changing anything else. The full procedure, per device, is in [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/). ## Add the machine The device is online and reporting to nothing. Give it a machine to report about. This section is the same for every device. 1. Go to **Assets** at `//assets` and select **Add asset**. 2. The modal opens on **Select Sensor**. Select **Skip, I'll do this later.** 3. In **Find or add a machine...**, type part of the model or manufacturer, for example `VF-2`, and pick the closest entry. 4. In **Machine Identifier**, type the number your plant already paints on the machine, for example `trx-as800`. 5. In **Machine Name**, type the name operators say out loud, for example `Haas VF-2 #3`. 6. Select **Select Department** and pick a department, or type a new name and press Enter to create one. 7. Select **Add Asset** and wait for "Asset has been added". ![The Add Asset modal with numbered callouts on catalog search, custom ID, and department](/images/get-started/gs-quickstart-04.webp) *Adding a machine. The catalog search is a convenience; a machine that is not listed can be typed in.* Both text fields are optional, and leaving **Machine Name** blank costs you: the card falls back to the catalog model name, so a shop with four Haas VF-2s gets four cards reading `Haas VF-2`. Department is required and the catalog model is the one field you cannot change later. Everything else is editable afterwards. Field by field, see [Add a machine](/docs/monitoring/add-an-asset/). ## Pair the device to the machine Nothing on the machine's card fills in until a device is tied to the asset, and this is the one step you do not perform yourself. There is no web path for it, and the **Select Sensor** step you skipped is not the way in. Contact IoTFlows to tie your devices to an asset. See [Get support](/docs/get-started/get-support/). Pairing usually happens during onboarding, so for most readers it is already done by the time the asset exists. Wait for confirmation before continuing: everything below assumes this device reports to this machine. ## Confirm data is arriving 1. Run the machine normally for ten minutes. 2. Go to **Assets** and find the card you just created. The card's status ring turns green while the device reads the machine as running, and gray when it does not. A card that changes color as the machine starts and stops is the whole point of this page. ![The Assets page listing machines with status timelines, parts made, current operation and utilization](/images/get-started/gs-quickstart-06.webp) *The Assets page. Each machine carries a status timeline for the shift, the parts it made, its current operation, and its utilization.* Open the card to see the first hour as a timeline: green where the machine ran, gray where it did not, with a utilization figure over the same window. One hour is enough to prove the path works and not enough to judge the machine. If the card is still blank ten minutes after the machine started, the device is reporting to a different asset. Check with support which asset it is tied to rather than creating a second one. For everything else on this screen, see [The Assets page](/docs/monitoring/assets-overview/). ## Set what counts as running A new device reports raw signal until you tell it what running looks like on this machine. *Sensitivity* is that setting, and it takes a different form on each kind of device. #### vibration Set a **Running Threshold**: a line above the machine's idle vibration and below its running vibration. 1. Open the machine's asset page and select the sensor image at the top right to open the sensor modal, then open the **Calibration** tab. 2. Start the live capture, run the machine through two or three normal cycles, then stop it for a moment so the trace shows both states. 3. Drag **Running Threshold** to sit between the two levels. IoTFlows saves each change and confirms with "Vibration Upper Threshold Updated". 4. Stop the capture. ![The Calibration tab with a live vibration trace, Running Threshold and Stopping Threshold sliders](/images/get-started/gs-quickstart-07.webp) *The Calibration tab, with a live vibration trace. Running Threshold is the level the signal must pass for the machine to read as running.* A machine that reads as running while it idles has a threshold set too low. Raise it until the idle stretch of the trace falls below the line. SenseAi also reads acoustics; SenseAi Embedded is sealed and calibrates on vibration alone. See [Calibrate SenseAi](/docs/hardware/calibrate-senseai/). #### beamtracker BeamTracker reads parts crossing the beam, so you describe the part instead of a signal level. Two settings do it, and you can set them on the touchscreen or in the dashboard. 1. Open the machine's asset page and select the BeamTracker image at the top right, then open the **Calibration** tab. 2. Set **Depth of View (cm)** to the distance the beam has to reach across the part path. 3. Set **Min Object Thickness (cm)** to the width of the part as it passes the beam. 4. Run a few parts through and check the count moves once per part. ![The BeamTracker Calibration tab with the Depth of View and Min Object Thickness fields](/images/get-started/gs-quickstart-10.webp) *Depth of View and Min Object Thickness describe the part crossing the beam. Everything that breaks the beam and matches them counts as one part.* Live calibration needs firmware 2.3 or later. Reading speed, downtime filter, and blocked-sensor stop time sit on the same tab and can wait. See [Calibrate BeamTracker](/docs/hardware/calibrate-beamtracker/). You do not need the rest of the Calibration tab today. One setting per device decides whether the machine reads as running, and it is the only one worth tuning before you have a few days of data to check it against. ## What to do next Leave the machine running for two or three days before you read anything into the numbers. Utilization over one shift tells you about that shift. When you want part counts rather than run time, the next decision is which algorithm the operation uses. BeamTracker uses **Counter**, because the beam already counts parts. The vibration devices infer parts from the signal and choose among the other algorithms. See [Choose an algorithm](/docs/production/choose-an-algorithm/). Then repeat this page for a second machine. The account work is done, so the second one takes the twenty minutes of mounting, provisioning, and calibrating rather than the full hour. ## See also - [Calibrate SenseAi](/docs/hardware/calibrate-senseai/) - [Calibrate BeamTracker](/docs/hardware/calibrate-beamtracker/) - [Production quickstart](/docs/production/quickstart/) - [The Assets page](/docs/monitoring/assets-overview/) - [Alerts quickstart](/docs/alerts/quickstart/) --- # Plan your rollout Source: https://www.iotflows.com/docs/get-started/roll-out-plan/ A four-phase plan for putting a plant on IoTFlows: pilot at least 10 machines on one line for two weeks, win operator adoption and turn on alerts, cut the downtime category list down to reasons you can act on, and only then add scheduling and maintenance. Each phase carries a gate that has to close before the next one starts. # Plan your rollout Take a plant from a boxed sensor to a shop floor that acts on its own data, in four phases. Rollouts stall in the same place. The pilot produces numbers nobody trusts, so nobody acts on them, and the project is judged on that. The sequence below is built to close that gap in the first two weeks. Each phase ends at a gate. Do not start the next phase until the gate closes, even if the hardware for it is already on site. ## The four phases | Phase | Duration | Who | Done when | |---|---|---|---| | 1. One line | 2 weeks | Installer, plant admin | A supervisor reads yesterday's numbers and agrees with them | | 2. Operator adoption | Weeks 3 to 6 | Supervisors, operators | 95% of downtime events are classified within 24 hours | | 3. Reasons that mean something | Weeks 6 to 12 | Continuous improvement, maintenance | The top three downtime categories each have an owner and a date | | 4. Scheduling and maintenance | Month 3 onward | Planners, maintenance | Jobs and work orders are created in IoTFlows, not in a spreadsheet | Diagram: A left-to-right timeline of four rollout phases, each box naming the phase and its duration: 1. One line, 2 weeks; 2. Operator adoption, weeks 3 to 6; 3. Downtime reasons, weeks 6 to 12; 4. Scheduling and maintenance, month 3 onward. An arrow runs left to right beneath the boxes and passes through four diamond gate markers, one under each phase. The gate under each phase reads, in order: a supervisor agrees with yesterday’s numbers; 95% of stops classified within 24 hours; top three categories have an owner and a date; jobs and work orders live in IoTFlows. The arrow only continues past a gate once that condition is met. *The four rollout phases and the gate that has to close before each one ends.* ## Phase 1: one line, two weeks Pick one line and monitor at least 10 machines on it. If the line has fewer, add the machines that feed it. Include the bottleneck and the machines whose problems you already argue about, because those are the ones a supervisor can check the data against from memory. Choose a pilot line with a single-shift schedule and a stable part mix. A three-shift cell with changeovers will produce data you cannot yet explain, and the pilot will be judged on that. Set the organization timezone and the shift schedule before the first sensor reports. A *shift* is a named window of the working day, and every number IoTFlows reports is bucketed into one. Shift changes do not apply to data already recorded, so a shift set wrong in week 1 leaves week 1 permanently unreadable. See [Set shifts and the organization timezone](/docs/admin/shifts-and-timezone/). Then bring up the hardware. [Quickstart](/docs/get-started/quickstart/) covers one machine end to end: mount the device, get it on Wi-Fi, create the asset, and confirm data is arriving. Calibrate every device before you trust its numbers. It takes under five minutes per device. A SenseAi on the machine housing can read the machine well, but only [calibration](/docs/hardware/calibrate-senseai/) tells you whether it does. Run the machine cutting and then idle, and adjust the thresholds until the two read differently. Until someone does that, a device can report a cutting machine as stopped, and every number built on it is wrong. Set a first uptime goal 5 to 10 points above the current average, not at the number you wish you had. *Uptime* is the share of scheduled time a machine spent running; see the [metrics reference](/docs/monitoring/metrics-reference/). If the line runs at 55% today, set the goal at 60%. **The gate.** A supervisor opens yesterday on the [assets overview](/docs/monitoring/assets-overview/) and agrees with what it says. If they can point at a stop that the system missed, fix calibration before going further. ## Phase 2: operator adoption Phase 1 tells you a machine stopped. Only an operator can tell you why. This is the phase most rollouts skip, and skipping it is what leaves you with months of unclassified downtime. Put a screen next to each monitored machine. In **Devices**, open **Assign to Local Device** and use **Assign Asset** to tie the tablet to its machine, so the operator sees their own line and nothing else. See [Set up operator stations](/docs/monitoring/operator-stations/). Train on the why before the how. Operators need to hear that the data is used to remove the obstacles that slow them down, and that it is not used to rank people. A system introduced as a scoreboard gets gamed within a week. Turn on alerts in this phase, not at the end. An alert that reaches a supervisor's phone while the machine is still down is what turns a report into a response. Start with one rule on the pilot line, for example a stop longer than 15 minutes on the bottleneck. See [Alerts overview](/docs/alerts/overview/). **The gate.** 95% of downtime events on the pilot line are classified within 24 hours, for two consecutive weeks. ## Phase 3: downtime reasons that mean something A *downtime category* is the reason an operator assigns to a stop, for example **Tool change** or **Waiting on material**. The category list is the single largest lever on whether the data is worth reading. Keep the list short. Eight to twelve categories that map to an action beat forty that map to a feeling. An operator facing a forty-item list picks the first plausible one, and a Pareto chart built from that answers nothing. See [Set up downtime categories](/docs/monitoring/downtime-categories/). Automate the stops that have only one possible reason. Rules can classify micro-stops under two minutes, shift changeovers, and scheduled breaks without an operator touching them, which leaves the operator's attention for the stops that are actually ambiguous. See [Classify downtime automatically](/docs/monitoring/auto-downtime-rules/). Review the data on a fixed weekly slot with supervisors, maintenance, and continuous improvement in the room. Sort [Downtimes](/docs/monitoring/downtimes/) by total duration for the past week, take the top three, and give each one a name and a date. **The gate.** The top three categories each have an owner and a deadline, and last week's top three were reviewed against this week's. ## Phase 4: scheduling and maintenance Once downtime data is trusted, the same machine records can carry the work. [Production Scheduler](/docs/production/scheduler/) plans jobs against real cycle times instead of estimates, and [Maintain](/docs/maintain/overview/) turns a recurring downtime category into a preventive maintenance schedule. You do not need phase 4 if your goal was to find out where the hours go. Phases 1 to 3 answer that on their own, and a plant that adopts scheduling before its operators classify downtime is planning against numbers it does not believe. Add these one product at a time, on the pilot line first, for the same reason phase 1 started with one line. ## Pitfalls **Monitoring the whole plant in week 1.** Forty machines produce forty calibration problems at once, and nobody can tell a bad sensor from a bad shift schedule. Start with at least 10: enough to compare machines against each other, and few enough that someone checks every device's calibration against its machine. **Setting the goal at the industry benchmark.** A team that starts 30 points below its target stops looking at the target. Raise it as the line improves. **Using the data to punish.** Operators who are measured rather than helped hide problems, and the classification rate collapses. The gate in phase 2 is the first thing to go. **Installing and forgetting.** Devices drop off Wi-Fi and calibration drifts. Check [Devices](/docs/hardware/view-devices/) weekly for anything offline or reconnecting repeatedly. **Growing the category list to cover every case.** Every category added past roughly a dozen dilutes the ones that matter. Add a category only when someone would act differently because of it. ## A readiness checklist Before you call a phase done: 1. The organization timezone matches the plant, and every shift is defined with its real start and end times. 2. Each monitored machine reads as running when it is cutting, and stopped when it is not. 3. Each machine has an uptime goal set from its own history. 4. Every monitored machine has a screen an operator can reach without leaving the machine. 5. Operators have been told what the data is for, by their own supervisor. 6. At least one alert rule reaches a phone or a chat channel. 7. The category list is under a dozen entries and every entry names an action. 8. A weekly downtime review is on the calendar with named attendees. ## See also - [Set shifts and the organization timezone](/docs/admin/shifts-and-timezone/) - [Set up downtime categories](/docs/monitoring/downtime-categories/) - [Alerts overview](/docs/alerts/overview/) - [Quickstart: see your first machine's data](/docs/get-started/quickstart/) --- # Sign in to IoTFlows Source: https://www.iotflows.com/docs/get-started/sign-in/ Every route into IoTFlows: the email-first sign-in at dashboard.iotflows.com, when an address is redirected to a company identity provider instead of asking for a password, the six-digit two-step code on web and mobile, Face ID on iOS, and how to reset a forgotten password. # Sign in to IoTFlows Every route into the product, and how to get back in when one fails. IoTFlows signs you in at `dashboard.iotflows.com/login`. The page asks for your email address first and decides from the address what to ask for next: a password, or a handoff to your company's identity provider. The same account signs you in to the iOS and Android apps. You need an invitation from an organization before any of this shows data. You can create an account from the sign-in page, but a new account belongs to no organization and sees an empty product until someone [invites it](/docs/admin/invite-members/). Organizations themselves are not self-serve. IoTFlows creates yours during onboarding, so [contact support](/docs/get-started/get-support/) if nobody has invited you. ## Sign in with email 1. Go to `dashboard.iotflows.com/login`. 2. Type your address in **Email or Username**, then select **Continue**. 3. Type your **Password**, then select **Sign in**. ![The IoTFlows sign-in card with a single Email or Username field and a Continue button](/images/get-started/gs-signin-01.webp) *The sign-in page asks for your email first. What happens next depends on whether your organization uses SSO.* Between step 2 and step 3, IoTFlows looks the address up. Most addresses get the password field. To sign in as someone else, select your address above the password field to go back. Landing in the wrong organization is normal on a multi-organization account, and it is not a sign-in failure. See [Switch between organizations](/docs/get-started/switch-organizations/). ## If your organization uses SSO *SSO*, or single sign-on, means your company's identity provider holds your credentials and vouches for you to IoTFlows. For an address covered by SSO, **Continue** sends you to your provider's own sign-in page rather than showing a password field. Sign in there and the provider returns you to the dashboard, already signed in. You do not need a separate IoTFlows password if your organization uses SSO. The password field never appears for those addresses, and resetting a password does nothing for them, because your provider owns the credential. ## If two-step authentication is on *Two-step authentication* asks for a six-digit code from an authenticator app after your password, so a stolen password alone does not get anyone in. After **Sign in**, the card is replaced by **Two-step authentication** and six code boxes. Type the current code from your authenticator app. IoTFlows submits it the moment the sixth digit lands, so you do not select **Continue**. Enrolment happens on the web only. See [Add two-step authentication](/docs/admin/two-step-auth/). ![The Two-step authentication screen with six single-digit code boxes](/images/get-started/gs-signin-03.webp) *The two-step code prompt. This appears on web, iOS and Android once you have enrolled.* > **Note:** > **Lost the authenticator app?** There is no self-serve recovery. [Contact support](/docs/get-started/get-support/) from an address your organization can confirm, and ask to have two-step authentication cleared. ## Sign in on mobile The mobile apps use the same account and the same email-first flow, including the SSO handoff and the six-digit code. Install them first: see [Install the mobile app and sign in](/docs/get-started/install-mobile-app/). On iOS, you can turn on Face ID or Touch ID after one successful sign-in, and later sign-ins take a glance instead of a password. The Android app has no biometric option and asks for the password each time. ### Sign-in methods | Method | Web | iOS | Android | Set up on | |---|---|---|---|---| | Email and password | Yes | Yes | Yes | Not applicable | | SSO through your identity provider | Yes | Yes | Yes | Your identity provider | | Two-step code | Yes | Yes | Yes | Web only | | Face ID or Touch ID | No | Yes | No | The iOS app | ## Reset your password 1. Select **Forgot your password?**, which appears once the password field is showing. 2. Type your username on **Reset Password**, then select **Continue**. 3. Read the code IoTFlows emails you, and type it into **Code**. 4. Type the same new password into **New password** and **Confirm new password**, then select **Continue**. The new password needs at least 8 characters, one uppercase letter, one lowercase letter, one number, and one special character. The form checks all five as you type and lists any that are unmet. ## See also - [Add two-step authentication](/docs/admin/two-step-auth/) - [Switch between organizations](/docs/get-started/switch-organizations/) - [Install the mobile app and sign in](/docs/get-started/install-mobile-app/) - [Contact support and report bugs](/docs/get-started/get-support/) --- # Switch between organizations Source: https://www.iotflows.com/docs/get-started/switch-organizations/ How to move an IoTFlows account between the organizations it belongs to: the switcher in the dashboard header, the drawer on Android and the modal on iOS, why your handle carries the organization it is used in, and what carries across the switch. # Switch between organizations Move between the organizations your account belongs to, on any client. One IoTFlows account can belong to several organizations. An *organization* is the workspace that owns a set of machines, people, and data, and nothing is shared between two of them unless someone deliberately shares it. Everything below assumes your account has been invited to more than one organization. If it belongs to one, no switcher appears. ## Switch on the web The switcher sits at the far left of the header, showing the current organization's logo and name. 1. Select the organization name in the header. 2. Pick an organization from the list. ![The dashboard header with the organization switcher open, listing two organizations below the current one](/images/get-started/gs-switch-01.webp) *The organization switcher. Data that looks missing is often the wrong organization.* Switching lands you on the Assets page of the new organization, not on the page you were reading. The organization is also the first segment of every URL, so opening a link someone sent you from their organization switches you to it. ## Switch on mobile On **Android**, tap the organization at the top of the home screen. A drawer slides in with your account details, a search box, and the organization list. On **iOS**, open **Settings** and tap the organization. A modal opens with a searchable list. ![The iOS organization selection modal listing the organizations on the account above a search bar](/images/get-started/gs-switch-02.webp) *Switching organizations on iOS opens a modal; Android uses the navigation drawer.* ## What follows you across the switch Your account follows you, and so does your username. A *handle* is that username qualified by the organization it is used in, written `maria:acme`, so the same person is `maria:acme` in one organization and `maria:iotflows` in another. What makes a handle unique is the organization, not the name in front of it. Your [profile](/docs/admin/profile/), your role, and the timezone the numbers are reported in are all set by the organization you are in. Chats are the exception. A chat can hold people from more than one organization, and IoTFlows badges the outside organizations on the member list. The badge is drawn against whichever organization you are currently in, so the same chat looks external from one side and internal from the other. Push notifications route themselves. Tapping one opens the item in an organization you can reach it from, switching you if you are somewhere else. You do not need a second account to work with a customer or a vendor. [Cross-organization chat](/docs/messaging/start-a-chat/) reaches them from the organization you are already in. > **Warning:** > An asset list, report, or work order board with nothing in it is usually the wrong organization rather than a bug. Check the switcher before filing one. ## See also - [Edit your profile](/docs/admin/profile/) - [Start a chat](/docs/messaging/start-a-chat/) - [Leave an organization](/docs/admin/leave-an-organization/) - [Navigate and search the dashboard](/docs/get-started/navigate-the-dashboard/) --- # BeamTracker Source: https://www.iotflows.com/docs/hardware/beamtracker/ BeamTracker is a laser sensor that counts units as they pass a point: each unit breaking its beam registers a timestamped count, and the time between counts decides whether the line reads as running or stopped. It has a built-in touchscreen for on-device setup, ships with an external antenna only, since M12 power and the mounting bracket are ordered separately, and reports no machine health, vibration or temperature, so those alerts are unavailable on a BeamTracker asset. # BeamTracker What BeamTracker counts, what ships in the box, and what it does not report. BeamTracker is a laser sensor that counts units as they pass a point. It counts without touching the part, so it suits a line where units move through a fixed path and a sensor on the machine could not tell them apart. Deciding between devices? [SenseAi](/docs/hardware/senseai/) derives counts from a machine's own cycle, and [Overview: IoTFlows hardware](/docs/hardware/overview/) compares all four devices. ## What BeamTracker measures ![A BeamTracker shown from the front and the back. The front is a tall gray housing filled by a touchscreen reading BeamTracker with a Get Started button. The back carries two round lenses, the emitter and receiver, above the product label, with a stub antenna on top and a threaded M12 connector below](/images/hardware/hw-beamtracker-01.webp) *BeamTracker, front and back: the touchscreen used to set it up on the device, and the lenses the beam leaves and returns through.* BeamTracker uses a single-point invisible laser as a tripwire across the part flow. Each unit that breaks the beam registers a count and a timestamp. State follows from the time between counts, which you set during calibration. Parts arriving within the expected timing read as running; no part for longer than the configured duration reads as stopped. There is no third state. From that stream, the cloud reports: - Part counts and throughput rates. - Utilization and running-versus-stopped time. Every figure is defined in [how each metric is calculated](/docs/monitoring/metrics-reference/). - Downtime, with duration, frequency and a reason once classified. - Historical production trends by day, week, month, quarter, or year. - Alerts for slow production and extended downtime. Data is encrypted in transit and at rest across the IoTFlows cloud. ## What BeamTracker does not report BeamTracker measures a beam, not the machine, so it produces no vibration reading and no machine health data. On a BeamTracker asset the dashboard hides the **Health** tab, and the only alerts you can configure are **Machine Status** and connectivity. You do not get machine health, vibration, shock or temperature alerts from a BeamTracker. If you need those on the same equipment, add a [SenseAi](/docs/hardware/senseai/) alongside it. ## Specifications | Property | Value | |---|---| | Type | Single-point laser sensor, non-contact | | Detects | A unit breaking the beam | | Display | Built-in touchscreen for setup, calibration and status | | Connectivity | Wi-Fi, 2.4 GHz only | | Connectors | Industrial M12 | | Power | 4.5 to 28 V DC over M12 | | Ingress protection | IP67: dustproof, and immersion to 1 m (3 ft) for 30 minutes | | Range | Up to 8 m (26 ft), resolved to the millimetre | | Detection cutoff | Configurable, for different unit sizes and line speeds | ## In the box ![A BeamTracker retail box](/images/beamtracker/box.webp) *A BeamTracker ships pre-configured, and is set up from its own screen rather than from the dashboard.* | Item | Quantity | Notes | |---|---|---| | BeamTracker device | 1 | Includes the built-in touchscreen | | External antenna | 1 | Connect it before powering the device on | The M12 power adapter, the M12 cable and the mounting bracket are ordered separately. The cable is an extension, 1 to 3 meters (3 to 10 ft), for when the adapter will not reach the device; an M12 T-splitter daisy-chains power between devices mounted close together. ## Requirements | Requirement | Value | |---|---| | Account | An IoTFlows organization you can sign in to | | Network | A 2.4 GHz Wi-Fi network, or an [IoTFlows 4G/LTE router](/docs/hardware/lte-router/). 5 GHz is not supported | | Phone | An iOS or Android device. Wi-Fi setup runs over Bluetooth from [the mobile app](/docs/get-started/install-mobile-app/), not from the web | | Line of sight | A clear path for the beam across the part flow | | Mounting | A stable position, square to the direction units travel | | Time | 5 to 15 minutes | BeamTracker needs units to pass a defined path in a consistent direction. Where they do not, or where the beam cannot see them cleanly, count from the machine's cycle with a SenseAi instead. Sensors are tied to an asset by IoTFlows during onboarding. If a sensor is not reporting against the right machine, [contact support](/docs/get-started/get-support/). ## See also - [Install and align BeamTracker](/docs/hardware/install-beamtracker/) - [Calibrate BeamTracker](/docs/hardware/calibrate-beamtracker/) - [Configure tracking for bottling and packaging lines](/docs/production/packaging-lines/) - [SenseAi](/docs/hardware/senseai/) - [Overview: IoTFlows hardware](/docs/hardware/overview/) --- # Buy IoTFlows hardware Source: https://www.iotflows.com/docs/hardware/buy/ The two ways to buy IoTFlows devices: the online shop, which applies tiered quantity discounts automatically at checkout, and the sales team, for a platform demo, custom requirements, larger orders, and corporate accounts spanning several organizations. # Buy IoTFlows hardware Buy devices from the online shop or through the sales team, and take the volume discount either way. There are two ways to purchase IoTFlows products. Both offer tiered discounts based on quantity. A *tiered discount* is a price break that applies once the order reaches a quantity, so ten sensors cost less per unit than one does. Because both routes carry the same tiers, the choice is about how much help you want with the order, not about price. Decide which device the machine needs before you buy. [Overview: IoTFlows hardware](/docs/hardware/overview/) compares SenseAi, SenseAi Embedded, BeamTracker, and the 4G/LTE router. ## Online shop For immediate purchases, the online shop is the fastest way to get started. Browse the full range of products, view pricing, and place the order directly. Tiered discounts are applied automatically at checkout. [Visit the IoTFlows shop](https://iotflows.com/shop/products) ![The IoTFlows shop listing SenseAi, SenseAi Embedded, BeamTracker and the IFCR.150 4G/LTE router, each with Buy Now and Pricing Calculator buttons](/images/hardware/hw-buy-01.webp) *The online shop lists the devices available without contacting sales.* Buy from the shop when: - You know which device you need and how many. - You want the quantity discount without a conversation about it. - You are an individual or a small team ordering for one plant. ## Contacting sales For a more personalized order, contact the sales team. They give a demo of the platform, discuss your specific needs, and help design a solution that fits your goals. Reach them through [iotflows.com](https://iotflows.com). Contact sales when: - You want a platform demo before you commit. - You are discussing a custom solution or specific requirements. - You are an enterprise customer, or the order is a large one. - You want a corporate account for managing several organizations. Sales is not a gate on the shop. If you already know the part and the quantity, order it and skip the conversation. > **Info:** > IoTFlows onboards the hardware before it ships. Devices arrive tied to your organization, so there is no claiming, registration, or activation step to work through when the box lands. Mount the device, connect it, and it reports. ## See also - [Overview: IoTFlows hardware](/docs/hardware/overview/) - [Quickstart](/docs/get-started/quickstart/) - [Billing and invoices](/docs/admin/billing/) - [Contact support and report bugs](/docs/get-started/get-support/) --- # Calibrate BeamTracker Source: https://www.iotflows.com/docs/hardware/calibrate-beamtracker/ Calibrate a BeamTracker in two halves: the beam values decide what the laser counts as a part, and the downtime filter decides how long a gap between parts may run before the line reads as stopped. Both live in the device's Calibration tab on the dashboard, alongside a live beam view that plots the raw reading against the thresholds you are setting. # Calibrate BeamTracker Tune what a BeamTracker counts as a part, and how long a gap may run before the line reads as stopped. BeamTracker measures the distance to whatever is in front of it, many times a second. Calibration sets two independent things: the *beam values*, which decide which readings count as a part passing, and the *downtime filter*, which decides how long the line may go without a part before it reads as stopped. Get the first wrong and counts are wrong. Get the second wrong and the counts are right while uptime is not. Calibrate after installing, after a line speed change, after moving the device, and whenever counts stop matching what the line made. **Prerequisites:** the device is installed and aimed, in [Install and align BeamTracker](/docs/hardware/install-beamtracker/), and online. You need the line available to run parts through the beam. ## Open the calibration panel 1. Open the dashboard and select the asset the BeamTracker is paired to. 2. Click the BeamTracker device to open its panel. 3. Select the **Calibration** tab. ![The dashboard with a BeamTracker device selected, opening its Edit Sensor panel](/images/beamtracker/calibration-beamtracker-selection.webp) *Open the device from its asset, then work in the Calibration tab. Everything on this page is on that tab.* Which fields appear depends on the device's firmware, shown as **Firmware Version** in the same panel. Live beam calibration needs 2.3 or later, blocked sensor stop time needs 2.1, and the laser light toggle needs 3.0. A device below those shows fewer controls rather than disabled ones. ## Set what counts as a part Four values decide whether a reading is a part. Three are distances in centimetres, measured out from the sensor face. | Field | What it sets | |---|---| | **Reading Speed** | How heavily readings are averaged before they are judged. `Faster 3X` through `Slower` | | **Min Object Thickness (cm)** | How far an object must back off again before it stops counting | | **Gap from Background (cm)** | Spare room left between the detection zone and the background surface | | **Depth of View (cm)** | The far edge of the detection zone. Anything past it is background | The *background* is the surface the beam lands on when nothing is passing, for example the far guard rail of a conveyor. Everything nearer than **Depth of View** is a candidate part, and everything past it is ignored. That is what stops a forklift crossing the aisle behind the line from being counted. **Min Object Thickness** is how far the reading must climb back before a part counts as gone. It is a floor, not a ceiling. Set it to the thinnest part you must count, never the thickest, because a floor set too high drops small parts silently and no error says so. **Reading Speed** trades responsiveness for stability. Choose a faster setting when parts pass in under a second and the count runs low. Choose a slower one when the count runs high on a dusty line, since heavier averaging rides over a single noisy reading. The `Faster` options need firmware 3.0 or later. ![The expanded Advanced Settings section of the Calibration tab: a Reading Speed dropdown set to Standard, above three numeric fields reading Min Object Thickness 1 cm, Gap from Background 2 cm, and Depth of View 14 cm](/images/hardware/hw-cal-bt-01.webp) *The BeamTracker configuration panel. These four values decide what counts as a part.* If saving reports **Detection distance plus thickness must be between 6 and 800 cm**, those two values together have landed outside what the device holds. Reduce whichever of them you set last. ## Set the range from the device screen You can also set the far edge at the machine. On the device's screen, tap the **Settings** icon at the top right and open **Calibrate Sensor**, which shows the distance it is reading now. 1. Clear the beam path, so the reading is the distance to the background. 2. Place an object where you want the far edge of the detection zone. 3. Tap **Calibrate**. The sensor then registers only objects nearer than that distance. Use this path when you are at the machine, or the device predates live calibration. Otherwise prefer the dashboard, which shows the readings while you set the thresholds. ## Run a live beam calibration **Live Laser Calibration** plots the raw distance reading against your thresholds while the line runs, so you can watch a real part cross them instead of guessing at numbers. 1. Start the live view and run parts through the beam. 2. Watch where the trace sits with the beam clear, and where it drops as each part passes. 3. Clear the beam and click **Set as Background** to move the background to the current reading. 4. Drag the threshold handles, or type into the fields, until every part crosses the detection line and nothing else does. ![The Live Laser Calibration panel showing a live distance trace that sits near 48 cm and drops to about 32 cm as each part passes, with bands marking beyond background ignored, background padding, minimum object thickness and detected, and a vertical beam rail whose handles read padding 3, thickness 4 and detection 41 cm](/images/hardware/hw-cal-bt-02.webp) *Live beam calibration. The background reading and the detection threshold must be far enough apart to survive dust.* **Set as Background** rejects a reading under 7 cm with **Reading must be at least 7 cm to use as the background**: nothing nearer leaves room for a detection zone. Aim at a further surface. If the reading is valid but tight, the panel keeps it and tells you it reduced your padding and thickness to fit. ## Set the downtime filter The **Downtime Filter** is how long the line stays running after the last part. Every part resets the timer. If no part arrives within the filter, the line switches to stopped, back-dated to the last part, so the report does not credit the gap as uptime. | Production pattern | Filter | |---|---| | Fast continuous production | 15 to 45 seconds | | Moderate paced operations | 1 to 5 minutes | | Batch or intermittent work | 5 to 20 minutes | Watch your normal part-to-part time, then set the filter a little longer to absorb ordinary pauses. Too short chops a running shift into hundreds of false stops. Too long swallows real downtime and reports uptime the line did not earn. ![Two machine status timelines for the same 9AM shift, the upper one broken into many narrow red and green bands, the lower one showing a few wide bands](/images/beamtracker/downtime-threshold-convert-to-uptime.webp) *The same shift before and after the downtime filter is set to the line's real part-to-part time. The gaps between parts stop registering as separate stops.* ## Classify short stops automatically **Auto-Classify Downtimes** labels any stop shorter than its value as a short downtime, so nobody classifies brief pauses by hand. With a 10-minute filter and a 30-minute auto-classify value, stops from 10 to 30 minutes are labeled automatically and anything longer waits for a person. Auto-classify must be greater than the downtime filter. If it is not, saving reports **Auto-classify must be greater than downtime filter**, naming the current filter value. Raise the auto-classify value above it. You do not need this if your operators already classify every stop, or if the distinction between a short pause and a real stoppage does not drive anything you report on. ## Stop the line when the beam stays blocked **Blocked Sensor Stop Time** covers a part that halts in the beam. Without it, an object parked in front of the sensor holds the reading inside the detection zone and the line keeps reading as running. Turn the toggle on and set the seconds, minimum 25. Below that the field reports **Minimum is 25 seconds**. Turn it on where a jam leaves the part sitting in the beam. Leave it off where parts always clear, since a false trip records a stop that never happened. ## Turn the laser light on **Laser Light** makes the beam visible. Turn it on while aiming or checking coverage, then off for production. It is an installer's aid, not a setting the line runs on. Needs firmware 3.0 or later. ## Verify against a real run Calibration is settled by comparison, not by inspection. 1. Run the line normally and count parts at the machine for a fixed window. 2. Compare that count to the dashboard for the same window. 3. Check that running and stopped on the timeline match what the line actually did. 4. Watch the next 24 to 48 hours before adjusting again. Counts low: a part is crossing outside the detection zone, or below the thickness floor. Counts high: something other than a part is crossing, or one part registers twice on a reading speed set too fast. Counts right but uptime wrong: move the downtime filter, not the beam values. ## See also - [BeamTracker](/docs/hardware/beamtracker/) - [Install and align BeamTracker](/docs/hardware/install-beamtracker/) - [Configure tracking for bottling and packaging lines](/docs/production/packaging-lines/) - [Troubleshoot part counts](/docs/production/troubleshoot-part-counts/) - [Calibration settings](/docs/hardware/calibration-settings/) --- # Calibrate SenseAi and SenseAi Embedded Source: https://www.iotflows.com/docs/hardware/calibrate-senseai/ Tune running and stopped detection for one specific machine from the device's Calibration tab: stream live vibration while the machine works and while it idles, place the running and stopping thresholds against what you captured, then use momentum to stop the status flickering. The same panel carries the shock threshold, the channel selection, the uptime filter and short-stop handling, and this page maps every control to the setting it writes and whether that setting belongs to the sensor or the machine. # Calibrate SenseAi and SenseAi Embedded Tune running and stopped detection for one specific machine. A SenseAi arrives with settings taken from machines like yours, which is a starting point rather than an answer. Two machines of the same model and age vibrate differently, and so does one machine depending on where the device sits. Calibration is how you check that this device tells running apart from stopped here, and correct it when it does not. A calibration takes under five minutes, most of it spent watching the machine work. **Prerequisites.** The device must be online, see [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/). You need to be able to run the machine and stop it while you watch. ## What calibration decides A SenseAi reports one of two states: running or down. There is no third state and nothing in between. The state flips when the vibration trace crosses a threshold and stays across it long enough. Everything downstream comes off that one decision. Uptime, downtime, and the part counts and cycle times derived from the same trace are all built on where you put the thresholds. See [Metrics reference](/docs/monitoring/metrics-reference/). **Calibrate after installing a device, after moving one, after significant machine maintenance, and whenever the numbers stop matching what the floor says happened.** You do not need to recalibrate after a part change unless the new part changes the machine's idle vibration. This is also how you find out whether the device is mounted somewhere useful. A device on the machine housing can read the machine perfectly well. What settles it is running the machine cutting and then idle and checking that the two read differently, rather than judging the mount by eye. ## Open the calibration view 1. Open the machine from **Assets**. 2. Click the picture of the device beside the machine name. 3. Stay on the **Calibration** tab, which opens by default. #### senseai ![The asset detail header for a machine called DMU 85 monoBLOCK, showing its picture, name, identifier, a status bar across the working day, and uptime and downtime totals. The small SenseAi image between the status figures is outlined, marking what to click to open calibration.](/images/senseai/calibration-senseai-selection.webp) *Click the device image on the machine's page to open its calibration view.* #### embedded ![The asset detail header for a machine, with the small SenseAi Embedded image beside the uptime figures outlined, marking what to click to open calibration.](/images/senseai-embedded/calibration-senseai-embedded-selection.webp) *Click the device image on the machine's page to open its calibration view.* You can also reach the same view from **Devices**, which suits working through several sensors in one sitting. Getting to a device there takes the **Edit Sensor** button rather than a click on the sensor card, see [Open a device](/docs/hardware/view-devices/#open). The header above the tabs names the device, its firmware version, its IP and MAC addresses, the network it is on, and the machine it reports for. **Check the firmware version now.** The live capture panel described below needs **2.0 or later**. Below that, the tab shows three sliders with their own submit buttons and none of the charts, and the only controls are sensitivity, momentum and shock threshold. ![The Edit Sensor dialog on the Calibration tab. The header names the sensor, its network, IP address and firmware version, alongside the machine it reports for. Below the Calibration and Networks tabs, a Vibration chart fills the panel with Running Threshold, Stopping Threshold and Momentum controls beside it, an unchecked Acoustics chart sits grayed below it, and a Detected Uptimes chart with an Insights readout of operation count, average cycle time, total uptime and total downtime sits under that. A Shock Acceleration Threshold slider runs across the panel, with Uptime Filter and Auto-Classify Downtimes fields at the bottom.](/images/senseai/calibration-senseai-calibration-page.webp) *The whole calibration view, which is the same panel on both form factors. Every control on this page lives in it.* Changes made here take effect on the device as you make them. There is no separate save step and no apply button. ## Capture a running baseline 1. Start the machine and let it reach a normal working cycle. 2. Click the blue play button at the top right of the tab. 3. Watch the **Vibration** chart for a full cycle, or two minutes, whichever is longer. The device streams a reading every few seconds while capture is on, so you are watching the machine now rather than a stored average. A timer beside the play button counts the capture, and the line above it tells you when this device was last calibrated and for how long. Note two things: the band the trace sits in while the machine works, and its lowest point during the smoothest part of the cut. The second number is the one that matters, because a threshold set above it will drop the machine to stopped every time the cut eases off. On firmware 3.2 and later a **Wi-Fi signal** chart captures alongside the vibration chart. Use it while you are here to check the device has usable signal where it is mounted: see [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). ## Capture a stopped baseline 1. Leave capture running. 2. Stop the machine, but leave it powered on. 3. Watch the trace settle, then click the red stop button. **Capture the machine powered on and not working, not switched off.** A powered machine still runs fans, pumps and hydraulics, and that floor is what the stopping threshold has to clear. Calibrating against a dead machine sets the threshold too low, and the machine then reads as running all shift. Stopping capture fills in the **Detected Uptimes** chart and the **Insights** panel beside it: operation count, average cycle time, total uptime and total downtime for the stretch you recorded. That is your scoring tool for the rest of this page. Every time you change a threshold, this chart redraws against the same capture, so you can compare settings without running the machine again. ## Set the running and stopping thresholds Two controls sit beside the **Vibration** chart, each a slider with a number field. | Control | What it means | Set it | |---|---|---| | **Running Threshold** | The level the trace must rise above for the machine to read as running. Where uptime starts counting. | Just below the lowest point of the running band you captured. | | **Stopping Threshold** | The level the trace must fall below for the machine to read as down. Where uptime stops counting. | Just above the highest point of the idle band you captured. | Both run from 0.001 to 0.7, and you can drag the slider or type an exact value. Each saves on its own when you release the slider or leave the field, and the dashboard confirms with **Vibration Upper Threshold Updated** or **Vibration Lower Threshold Updated**. The product ships its own explanation of the two, reachable from the ⓘ icon beside the **Vibration** label: ![The Calibration Explanation dialog. Its top half labels a vibration trace with the Running Threshold, described as establishing the baseline from which uptime calculations start, and the Stopping Threshold, described as defining the endpoint for calculating uptime, with a Calculated Uptime bar below showing the single block of runtime the pair produces. Its lower half compares momentum values of 0.3, 0.2, 0.1 and 0.05 on the same signal, the higher values producing a smooth trend and the lower values sharp repeated spikes.](/images/senseai/calibration-explanation.webp) *The in-product explanation, reached from the information icon beside the Vibration label. The upper panel shows where each threshold acts on the trace; the lower panel shows the same signal at four momentum values.* **Leave a gap between the two.** A machine whose vibration wanders across a single line flips state on every wander, and the gap is what absorbs normal variation. Leave a buffer against your observed values too, rather than setting each threshold exactly on the band you measured. ![A detail of the Calibration tab showing the Vibration checkbox ticked above a live trace. To the right, Running Threshold reads 0.0405, Stopping Threshold reads 0.0284 and Momentum reads 0.2, each with its own slider. The chart is shaded green above the running threshold and red below the stopping threshold.](/images/senseai/running-stopping-thresholds-settings.webp) *The threshold controls beside the vibration chart. The green band is what counts as running, the red band as stopped.* ## Set momentum *Momentum* is how much the device smooths the trace before comparing it to the thresholds. Higher momentum responds more slowly and ignores brief excursions. Lower momentum responds faster and follows every spike, as the lower panel of the explanation image above shows at four values. The slider runs from 0.2 to 2 in steps of 0.05, and saves when you release it. **Raise the running threshold when a running machine reads as stopped. Raise momentum instead when the status flickers between running and down on a machine that is genuinely running.** The thresholds change what counts as motion; momentum changes how long that motion has to persist before the state moves. A machine that ramps up and down gradually wants higher momentum. One that cycles in sharp bursts wants lower momentum, or the device smooths the bursts away and misses them entirely. > **Warning:** > **Momentum is not retroactive.** Changing it does not re-score data you have already captured. Capture again after every momentum change, or you are reading the old value's results. Momentum is stored per channel. If you run vibration and acoustics together, each carries its own momentum and its own pair of thresholds. ## Set the shock threshold A *shock* is a single sharp acceleration, the signature of a crash or a collision rather than of work. **Shock Acceleration Threshold** is the level in g above which the device reports one. The slider runs from **20 g to 100 g** in steps of 1, starts at 100 g, and saves when you release it. Set it above anything the machine does normally and below anything you want to hear about. A press that hits 35 g every stroke needs a threshold well clear of 35 g, or every stroke reads as a crash. Watch the normal range during calibration first, then place the threshold against what you saw. **You do not need this if nobody acts on shock events.** It has no effect on running or stopped detection, so leaving it at its shipped value costs you nothing in uptime accuracy. ![The Shock Acceleration Threshold control, a single full-width slider with its current value shown in g in the label above it.](/images/shared/shock-threshold-settings.webp) *The Shock Acceleration Threshold slider, here at the top of its range.* ## Choose which channels the device analyses Two checkboxes above the charts decide which channels the device analyses: **Vibration** and **Acoustics**. At least one stays selected, and the dashboard will not let you clear both. **Default to Vibration alone.** Acoustics picks up the room as well as the machine, so on a floor with neighbouring equipment it adds noise rather than signal. Turn it on when the work is audible but barely moves the housing. Each channel carries its own running threshold, stopping threshold and momentum, so turning acoustics on means calibrating a second set of three controls rather than reusing the vibration numbers. ## Filter out short uptimes The *uptime filter* drops any run shorter than a set number of seconds, so a bump against the machine or a neighbor's vibration does not register as production. Enter a value in seconds under **Uptime Filter** and click away from the field. It applies to data older than about 30 minutes, so recent history is left alone. ![The Uptime Filter control, a small number field with a placeholder of 00 and the word seconds beneath it.](/images/shared/uptime-filter-threshold-settings.webp) *The Uptime Filter field. Any run shorter than this many seconds is removed from uptime.* The effect on the record looks like this: ![A before and after comparison of the same status bar across a working day. In the Before bar, several very narrow green slivers interrupt long red stretches. In the After bar, those slivers are gone and the red stretches run unbroken.](/images/shared/uptime-convert-to-downtime.webp) *Before and after the uptime filter. Short green slivers inside a long stop are absorbed into the downtime around them.* > **Warning:** > **Set this last.** Applied before the thresholds and momentum are right, the uptime filter hides the symptom you were about to use to correct them. A machine that keeps producing one-second runs is telling you the thresholds are wrong, not that it needs a filter. Most machines settle between 5 and 15 seconds. Very stable environments can go lower, to 3 to 5 seconds. Floors with a lot of neighbouring vibration may need 15 to 30 seconds. ## Handle short stops Short pauses are part of how most machines run. Tool changes, part loading and indexing all stop the spindle without being downtime anybody wants to chase. The **Treat short downtimes as uptime** toggle picks how they are handled, and the field below it sets the cutoff in minutes. The field's label changes with the toggle, so the label tells you which behavior is active: | Toggle | Field label | What happens to a stop under the cutoff | |---|---|---| | Off | **Auto-Classify Downtimes** | It stays downtime and is given the Short Downtime reason code automatically. | | On | **Downtime Threshold** | It is converted to runtime and stops counting as downtime at all. | ![The short-stop control: a Treat short downtimes as uptime toggle switched on and colored green, above a field labeled Downtime Threshold containing the value 2, with the word minutes beneath it.](/images/shared/downtime-threshold-settings.webp) *The short-stop control with the toggle on. The field label reads Downtime Threshold, so stops under two minutes become runtime.* **Leave the toggle off when you want the pauses visible and sorted.** Classified stops still appear as downtime, in a darker red than unclassified ones, so the shift record keeps them while the reason code explains them. ![A before and after comparison of the same status bar. In the Before bar, short stops appear in the same bright red as every other stop. In the After bar, those short stops are rendered in a darker red, distinguishing them from unclassified downtime, while the bar's overall pattern is unchanged.](/images/shared/downtime-threshold-classify.webp) *Auto-classify, with the toggle off. Short stops stay downtime and turn darker red, marking them as classified.* **Turn the toggle on when short pauses are part of the cycle** and counting them distorts the numbers. Indexing time and brief cooldowns are the usual cases. ![A before and after comparison of the same status bar. In the Before bar, short red stops break up long green runs. In the After bar, those short stops have become green, merging the runs on either side into continuous uptime.](/images/shared/downtime-threshold-convert-to-uptime.webp) *Convert to uptime, with the toggle on. Short stops disappear into the runs around them.* Both behaviors look back at stops older than about 30 minutes rather than reclassifying live, so neither changes what the floor sees right now. The Short Downtime reason code itself is edited in **Organization Settings** under **Short Downtimes**, and the colors these bars use are set from **Assets Overview** under **Adjust Status Colors**. See [Status colors](/docs/monitoring/status-colors/). ## Verify the calibration Calibration is settled by comparison, not by inspection. 1. **Test both states.** Run the machine for a few minutes, then stop it and leave it idle. Check the dashboard reflects both. 2. **Review the last hour.** Compare the recorded uptime and downtime against what the machine actually did. 3. **Watch 24 to 48 hours.** Look for a pattern of mis-detection rather than a single wrong reading, then adjust once. Make one change at a time and re-check before the next. Two changes at once leave you unable to say which one helped. **Gray on the status bar is not downtime.** It marks a stretch the device was not reporting at all, which is a connectivity problem rather than a calibration one. A bar striped with gray through a shift points at the network, not the thresholds. See [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). ## Common mistakes | Mistake | What it causes | |---|---| | Thresholds set too close together | Rapid flickering between running and down | | Momentum set too low | Every minor vibration moves the state | | Uptime filter set before the thresholds | Masks a calibration problem instead of fixing it | | Only one state captured | Thresholds placed against a guess rather than a measurement | | Idle captured with the machine switched off | Stopping threshold set below the machine's real floor, so it reads as running all shift | ## Troubleshoot calibration **The live charts stay empty after you press play.** The device is not reporting. Confirm it is online and paired to this asset, then see [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). **The machine reads as running when it is idle, or idle when it is running.** The thresholds are in the wrong place for this machine. Capture both states again and reset them against what you see. Check you captured true idle, powered on and not working, rather than the machine switched off. **Everything still reads as running after you raise the stopping threshold.** The mount is passing the device a neighbouring machine's vibration rather than this machine's. The surface has to be mechanically tied to the parts that move, see [Install and power up SenseAi](/docs/hardware/install-senseai/). **The status flickers between running and down.** Raise momentum, then widen the gap between the two thresholds. If it persists, something near the machine is vibrating it. The uptime filter is the last resort here, not the first. **A change does not seem to take effect.** Confirm the device is online, wait 30 to 60 seconds, then reload the page. If a setting snaps back to its old value with a red message, the save failed and nothing changed on the device. ## What differs on SenseAi Embedded The procedure above is the whole procedure for SenseAi Embedded. Every control and every step is the same. One difference: **SenseAi Embedded takes no acoustic reading**, because its IP67 enclosure is sealed. It calibrates on vibration alone (its temperature reading has no thresholds here), the acoustics channel does not apply, so [Choose which channels the device analyses](#channels) is a section you can skip, and the second set of thresholds and momentum never comes into play. ## Calibrate from the mobile app **The IoTFlows mobile app exposes sensitivity and momentum only.** *Sensitivity* is a single combined control over what counts as motion, in place of the two thresholds the dashboard gives you. Use the app at the machine for one quick adjustment. **Use the dashboard for a first calibration**: the app has no live trace and no **Detected Uptimes** chart, so you cannot see what you are setting the thresholds against. See [Install the mobile app](/docs/get-started/install-mobile-app/). Sensitivity also appears on the web for devices running firmware below 2.0, alongside momentum and the shock threshold, each with its own submit button. ## Where each setting is stored Two of these controls belong to the **machine**, not the sensor. Swapping the sensor on a machine carries those two across; the rest are device settings and go with the device. | Control | Stored as | Belongs to | |---|---|---| | **Running Threshold** | `node_vibration_upper_threshold`, `node_acoustic_upper_threshold` | The sensor | | **Stopping Threshold** | `node_vibration_lower_threshold`, `node_acoustic_lower_threshold` | The sensor | | **Momentum** | `node_vibration_momentum`, `node_acoustic_momentum` | The sensor | | **Shock Acceleration Threshold** | `node_shock_threshold` | The sensor | | Channel checkboxes | `node_analysis_mode` | The sensor | | **Sensitivity** (firmware below 2.0, and mobile) | `node_sensitivity` | The sensor | | **Uptime Filter** | `asset_uptime_filter_seconds` | The machine | | **Auto-Classify Downtimes** / **Downtime Threshold** | `asset_auto_classify_downtimes_less_than_min` | The machine | | **Treat short downtimes as uptime** | `asset_filter_downtime_instead_of_classification` | The machine | Field-by-field detail, including ranges and defaults, is on [Calibration settings](/docs/hardware/calibration-settings/). ## See also - [Calibration settings](/docs/hardware/calibration-settings/) - [Status colors](/docs/monitoring/status-colors/) - [Troubleshoot monitoring](/docs/monitoring/troubleshoot-monitoring/) - [Install and power up SenseAi](/docs/hardware/install-senseai/) - [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/) --- # Calibration settings Source: https://www.iotflows.com/docs/hardware/calibration-settings/ Look up any SenseAi, SenseAi Embedded or BeamTracker calibration field: its unit, the range the control accepts, its shipped default, what it changes, and where it is edited. Starts with a symptom router that maps what the numbers are doing wrong to the one field that corrects it, and links each row to the procedure page that explains how to set it. # Calibration settings Look up one calibration field: its unit, range, default, and what it changes. This page is a lookup table. It does not explain how to calibrate a device, because the procedure differs by device family and each has its own page: [Calibrate SenseAi and SenseAi Embedded](/docs/hardware/calibrate-senseai/) and [Calibrate BeamTracker](/docs/hardware/calibrate-beamtracker/). Every row here links to the section that sets it. ## Which field do I change? Find the symptom, then read across to the field. Change one field, verify against a real run, then change the next. | The numbers are doing this | Change this | |---|---| | A running machine reads as stopped | **Running Threshold**, lower it | | A stopped machine reads as running | **Stopping Threshold**, raise it | | Status flickers between running and down | **Momentum**, raise it | | One-second runs appear inside a long stop | **Uptime Filter** | | Tool changes and part loading count as downtime | **Auto-Classify Downtimes**, or the toggle above it | | Every press stroke reports a crash | **Shock Acceleration Threshold**, raise it | | Part counts run low | **Min Object Thickness**, lower it, or **Depth of View** | | Part counts run high | **Reading Speed**, slower, or **Depth of View**, shorter | | Counts are right but the line reads as stopped mid-run | **Downtime Filter** | | A jammed part leaves the line reading as running | **Blocked Sensor Stop Time** | ## SenseAi calibration fields These apply to SenseAi and SenseAi Embedded. Embedded takes no acoustic reading, so its acoustic copies of the first three fields never come into play. | Field | Stored as | Unit | Range | Default | Effect | Edited on | |---|---|---|---|---|---|---| | [Running Threshold](/docs/hardware/calibrate-senseai/#thresholds) | `node_vibration_upper_threshold`, `node_acoustic_upper_threshold` | Signal level | 0.001 to 0.7, step 0.0001 | Set during calibration | Where uptime starts counting | Web | | [Stopping Threshold](/docs/hardware/calibrate-senseai/#thresholds) | `node_vibration_lower_threshold`, `node_acoustic_lower_threshold` | Signal level | 0.001 to 0.7, step 0.0001 | Set during calibration | Where uptime stops counting | Web | | [Momentum](/docs/hardware/calibrate-senseai/#momentum) | `node_vibration_momentum`, `node_acoustic_momentum` | — | 0.2 to 2, step 0.05 | 0.2 | How much the trace is smoothed before it is compared to the thresholds | Web, mobile | | [Shock Acceleration Threshold](/docs/hardware/calibrate-senseai/#shock) | `node_shock_threshold` | g | 20 to 100, step 1 | 100 | The acceleration above which the device reports a shock. No effect on running or stopped detection | Web | | [Vibration and Acoustics checkboxes](/docs/hardware/calibrate-senseai/#channels) | `node_analysis_mode` | — | At least one selected | Vibration | Which channels the device analyses. Each channel carries its own thresholds and momentum | Web | | [Sensitivity](/docs/hardware/calibrate-senseai/#mobile) | `node_sensitivity` | — | 0.001 to 0.96, step 0.001 | 0.5 | A single combined control over what counts as motion, in place of the two thresholds | Mobile, and web below firmware 2.0 | | [Uptime Filter](/docs/hardware/calibrate-senseai/#uptime-filter) | `asset_uptime_filter_seconds` | Seconds | 0 or more | Empty | Drops any run shorter than this from uptime | Web | | [Auto-Classify Downtimes](/docs/hardware/calibrate-senseai/#short-stops) | `asset_auto_classify_downtimes_less_than_min` | Minutes | 0 or more | Empty | Stops under this length are labeled Short Downtime automatically | Web | | [Treat short downtimes as uptime](/docs/hardware/calibrate-senseai/#short-stops) | `asset_filter_downtime_instead_of_classification` | — | On or off | Off | On, stops under the cutoff become runtime instead of being classified. The field label above changes to **Downtime Threshold** | Web | The last three fields belong to the **machine**, not the sensor, so swapping a sensor carries them across. The rest go with the device. Full map on [Where each setting is stored](/docs/hardware/calibrate-senseai/#settings-map). > **Info:** > **Why is my shock slider only reaching 20 g?** The 20 to 100 g range is the decided range and the dashboard is being updated to match. A device still on the older build shows a 2 to 20 g slider. Set it to the top of whatever range you are shown, and revisit after the update. ## BeamTracker calibration fields The three distances are measured out from the sensor face, in centimetres. They are the units the fields are labeled with and the units the validation messages quote, so enter them as centimetres rather than converting. | Field | Stored as | Unit | Range | Default | Effect | Edited on | |---|---|---|---|---|---|---| | [Reading Speed](/docs/hardware/calibrate-beamtracker/#beam-values) | `node_reading_moving_average_count` | Readings averaged | `Faster 3X` (1), `Faster 2X` (2), `Faster` (3), `Fast` (5), `Standard` (10), `Slow` (20), `Slower` (50) | `Standard` | How heavily readings are averaged before they are judged. Slower rides over a single noisy reading | Web | | [Min Object Thickness](/docs/hardware/calibrate-beamtracker/#beam-values) | `node_calibration_min_object_tickness` | cm | 0 to 100 | 2 | How far the reading must climb back before a part counts as gone. A floor, not a ceiling: set it to the thinnest part you must count | Web | | [Gap from Background](/docs/hardware/calibrate-beamtracker/#beam-values) | `node_calibration_gap_from_background` | cm | 0 to 100 | 2 | Spare room left between the detection zone and the background surface | Web | | [Depth of View](/docs/hardware/calibrate-beamtracker/#beam-values) | `node_calibration_max_distance` | cm | 1 to 795, and Depth of View plus thickness must fall between 6 and 800 | 400 | The far edge of the detection zone. Anything past it is background | Web, device screen | | [Downtime Filter](/docs/hardware/calibrate-beamtracker/#downtime-filter) | `node_filter_downtime_seconds` | Seconds or minutes | 0 or more | Empty | How long the line stays running after the last part. Every part resets the timer | Web | | [Auto-Classify Downtimes](/docs/hardware/calibrate-beamtracker/#auto-classify) | `asset_auto_classify_downtimes_less_than_min` | Minutes | Greater than the downtime filter | Empty | Stops under this length are labeled automatically | Web | | [Blocked Sensor Stop Time](/docs/hardware/calibrate-beamtracker/#blocked) | `node_publish_stop_after_running_seconds` | Seconds | 25 or more | 60, toggle off | How long an object may sit in the beam before the line reads as stopped. Needs firmware 2.1 | Web | | [Laser Light](/docs/hardware/calibrate-beamtracker/#laser) | `node_is_laser_on` | — | On or off | Off | Makes the beam visible for aiming. An installer's aid, not a production setting. Needs firmware 3.0 | Web | Three ranges are enforced on save and report a message rather than clamping the value: | Message | What to do | |---|---| | **Detection distance plus thickness must be between 6 and 800 cm** | Reduce whichever of the two you set last | | **Auto-classify must be greater than downtime filter** | Raise the auto-classify value above the filter value the message names | | **Minimum is 25 seconds** | Raise the blocked sensor stop time | ## Where each field is edited Most fields are web only. Three exceptions are worth knowing before you walk to the machine: - **Momentum and Sensitivity** are the only calibration controls in the mobile app. Sensitivity replaces the two thresholds there, so the app adjusts a calibration rather than making one. See [Calibrate from the mobile app](/docs/hardware/calibrate-senseai/#mobile). - **Depth of View** can be set from the BeamTracker's own screen, under **Settings** then **Calibrate Sensor**, by placing an object at the far edge you want. See [Set the range from the device screen](/docs/hardware/calibrate-beamtracker/#on-device). - **Sensitivity, Momentum and Shock Acceleration Threshold** appear on the web for devices below firmware 2.0, each with its own **Send** button, in place of the threshold sliders. **You do not need this page to calibrate a device.** Both procedure pages carry the values you need in the order you set them. Come here when you already know the field and want its range, its default, or the setting it writes. ## See also - [Calibrate SenseAi and SenseAi Embedded](/docs/hardware/calibrate-senseai/) - [Calibrate BeamTracker](/docs/hardware/calibrate-beamtracker/) - [Troubleshoot monitoring](/docs/monitoring/troubleshoot-monitoring/) - [Troubleshoot part counts](/docs/production/troubleshoot-part-counts/) - [LED and screen status codes](/docs/hardware/led-and-status-codes/) --- # Connect a device to Wi-Fi Source: https://www.iotflows.com/docs/hardware/connect-to-wifi/ Put any IoTFlows sensor onto a 2.4 GHz network using Bluetooth from the mobile app: hold the Wi-Fi button until the LED blinks blue, or open WiFi Configuration on the BeamTracker touchscreen, then hand the device its credentials from the phone and save the network to your organization so the next device provisions without retyping it. # Connect a device to Wi-Fi Put any IoTFlows sensor onto a network using Bluetooth from the mobile app. The procedure is the same for all three devices. Only the first step differs, because SenseAi and SenseAi Embedded have a button and BeamTracker has a touchscreen. If your devices ship with an IoTFlows 4G/LTE router, skip this page. Devices assigned to a router join it on their own: see [Connect a device through the 4G/LTE router](/docs/hardware/use-the-lte-router/). ## Before you start **This requires the iOS or Android app.** Bluetooth provisioning is not available on the web, so a device that is not yet on a network cannot be set up from the dashboard. Install the app from [Install the mobile app](/docs/get-started/install-mobile-app/). The dashboard refuses the job in as many words: *Device must be online to connect to Wi-Fi. Please use the IoTFlows iOS or Android app for Wi-Fi provisioning.* Once a device **is** online, moving it to a different network is a dashboard task and needs no phone at all. That is [Change the network later](#change). You also need: - **A powered device**, mounted or on the bench. See the install page for [SenseAi](/docs/hardware/install-senseai/), [SenseAi Embedded](/docs/hardware/install-senseai-embedded/) or [BeamTracker](/docs/hardware/install-beamtracker/). - **A 2.4 GHz network and its password.** 5 GHz is not supported by any IoTFlows device. - **Bluetooth turned on** on the phone, and the phone near the device. The app shows **Bluetooth is ON** or **Bluetooth is OFF** before it scans. Turn it on in the phone's settings, not in the app. **This is not pairing.** The **Add Device** button on the same screen ties a sensor to a machine, which IoTFlows does for you during onboarding. This page covers **Connect Device to WiFi**, which is the network only. If a device is on the network but reporting for the wrong machine, [contact support](/docs/get-started/get-support/). Diagram: A sequence diagram with four actors in a row: your phone, the device, the Wi-Fi network, and the IoTFlows cloud. Three numbered exchanges run between them. First, the phone finds the device over Bluetooth, which works only while the device is in setup mode. Second, the phone sends the network name and password to the device over that Bluetooth link. Third, the device reboots, joins the Wi-Fi network on its own, and reports to the cloud. A note reads that the phone is out of the picture after step two, so nothing that goes wrong afterwards is a phone problem. *The provisioning sequence: your phone talks to the device over Bluetooth, hands it Wi-Fi credentials, and the device then reaches the cloud on its own.* Bluetooth carries the credentials once. The phone does not need to stay near the machine afterwards. ## Put the device in setup mode *Setup mode* is the window in which a device accepts Wi-Fi credentials over Bluetooth. Outside it, the app cannot see the device at all. | Device | How to enter setup mode | Indicator | Timeout | |---|---|---|---| | SenseAi | Hold the **Wi-Fi** button for 10 seconds | LED blinking blue | Not published | | SenseAi Embedded | Hold the **Wi-Fi** button for 10 seconds | LED blinking blue | Not published | | BeamTracker | Tap the **Settings** icon, then **WiFi Configuration** | The **WiFi Setup** screen | Not published | On the two sensors, the LED blinks purple while you hold the button and turns red at ten seconds. Release it then. The device reboots and comes back blinking blue. If the LED is already blinking blue, the device is in setup mode and you can leave it alone. ![A SenseAi with its LED blinking blue, the pattern that means the device is in Wi-Fi setup mode](/images/senseai/senseai-wifi-setup-mode.gif) *The setup-mode LED pattern. A device that is not blinking blue will not appear in the app's scan.* On BeamTracker there is no LED to read. Tap the **Settings** icon in the top right of the touchscreen, then **WiFi Configuration**. The screen switches to **WiFi Setup** and displays a QR code alongside pairing instructions, and it stays there until you leave the screen or provisioning finishes. ![The BeamTracker Get Started screen after boot](/images/beamtracker/beam-tracker-get-started.webp) *Get Started* ![The BeamTracker screen showing a pairing QR code](/images/beamtracker/beamtracker-qr-code.webp) *QR code* ![The BeamTracker WiFi Setup screen, listening for credentials over Bluetooth](/images/beamtracker/beamtracker-wifi-setup.webp) *WiFi Setup* Every pattern these devices show is decoded in [LED and screen status codes](/docs/hardware/led-and-status-codes/). ## Connect from the app 1. Open the app and go to **Settings**, then **Devices**. 2. Tap **Connect Device to WiFi**. 3. On **Select the product you'd like to set up**, choose SenseAi, SenseAi Embedded or BeamTracker. 4. The app scans over Bluetooth and lists what it finds under **Select a Device**. Pick yours. Devices are named by their identifier, in the form `IoTFlows_F0:9E:9E:0C:36:14`. ![The app's Devices screen, with an Add Device button, a Connect Device to WiFi button, and the list of devices already paired](/images/get-started/gs-quickstart-03-1.webp) *Devices* ![The product picker, offering SenseAi, SenseAi Embedded and BeamTracker](/images/get-started/gs-quickstart-03-2.webp) *Pick the product* ![Setup instructions for holding the Wi-Fi button, above a Nearby Devices panel showing Scanning for devices](/images/get-started/gs-quickstart-03-3.webp) *Scanning* If the app reports **No nearby device found**, the device is not in setup mode. It either never entered it or has since left it. Repeat [Put the device in setup mode](#setup-mode) and scan again. ## Choose a network The device scans for networks around it and the app lists what it found. Pick the network, type the password, and tap **Provision Device**. Two things to check before you type: - **The network must be 2.4 GHz.** A 5 GHz-only SSID will not appear in the device's scan, because the device's radio cannot see it. If the network you expect is missing, that is usually why. - **The password is case-sensitive.** Type it rather than relying on autocomplete. - **The device has to hold the network from where it is mounted**, not from where you are standing. A sensor provisions fine on a bench and then drops all shift if the machine sits at the edge of coverage. Keep it within about 100 ft (30 m) of the access point it joins, and check the signal afterwards in [Weak signal](/docs/hardware/troubleshoot-offline-device/#signal). ## Save the network to your organization The app keeps a list of **Known Wi-Fi Networks** for your organization. Save the network on the first device you provision, using **Add New Network** and **Save Credentials**, and every later device on that line can pick it from the list instead of having its passphrase retyped at the machine. **Do this on the first device, not the tenth.** Twenty sensors provisioned from a known network is twenty chances not to mistype a passphrase, and it is what lets a password change be pushed to all of them at once from [Manage saved Wi-Fi networks](/docs/hardware/manage-wifi-networks/). Credentials are stored against the organization, so anyone on your team provisioning a device sees the same list. ## Confirm the device is online The app shows two checks in order: **Sending Wi-Fi credentials**, then **Confirming Wi-Fi connection**. Both end in **Successful**, followed by **Device has been successfully provisioned!** ![The app's success screen, showing Sending Wi-Fi credentials Successful, Confirming Wi-Fi connection Successful, and the line Device has been successfully provisioned](/images/get-started/gs-quickstart-03-4.webp) *What success looks like. Both checks have to pass; the first alone only means the device heard you.* Then confirm it in the dashboard, at **Devices**, before you leave the machine. The device reads online within a minute or two of joining. If provisioning fails, the app shows **Wi-Fi Status: network not found** and reboots the device to retry. Read that message loosely: the app does not distinguish a missing network from a rejected password, so it reports the same line for both. Check the passphrase first, then confirm the SSID is 2.4 GHz. A device that provisions and then stays offline in the dashboard has a different problem: it joined the network but cannot reach the cloud, usually a captive portal or blocked outbound traffic. Work [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/#never-online). ## Change the network later **If the device is online, do it from the dashboard.** Two routes reach the same **Networks** tab: - **From the machine, which is how most people get there.** Open the machine from **Assets**, click the picture of the device beside it, then open **Networks**. - **From Devices**, which suits working through several sensors in one sitting. The tab lists the networks your organization already knows, with the device's current one ticked. Press **Connect** on another to move the device to it, or **Add Network** to enter a new **Wi-Fi SSID** and **Wi-Fi Password**. The dashboard sends the credentials over the device's existing connection, so you need no Bluetooth, no app, and no trip to the machine. ![The Edit Sensor dialog in the dashboard with its Networks tab selected, showing the sensor name, its current WiFi SSID, IP address, firmware version and the machine it reports for, above a list of the organization's known networks. Each row carries a Connect action, the network in use is ticked, and an Add Network link sits below the list.](/images/hardware/hw-wifi-03.webp) *The Networks tab of an online sensor. Each known network carries a Connect action, the one in use is ticked, and Add Network takes a new SSID and password.* The tab reports **Wi-Fi credentials sent to device**, then **Connecting to Wi-Fi**, and the device drops off its old network and rejoins on the new one. If it has not come back in 45 seconds, the dashboard gives up with **Wi-Fi connection failed, please try again**. That usually means the new network is not reachable from where the device sits, and the device falls back to what it had. **Choose the dashboard when the device is online, which is nearly always.** Only use the Bluetooth procedure above when the device is offline, because a device that cannot reach the cloud cannot be told anything over it. > **Warning:** > **Moving a device to a network it cannot reach.** The dashboard will send credentials for any network you type, including one with no coverage at the machine. The device leaves its working network to try, fails, and you lose the connection you were using to reach it. Recovering it means walking out with a phone. Confirm coverage before you switch a device you cannot easily get to. If the device is offline, provisioning again over Bluetooth overwrites the old network. Put it back into setup mode and run the procedure above. The ten-second button hold on SenseAi and SenseAi Embedded is one action with two outcomes, depending on where the device is now: - **On facility Wi-Fi**, the hold clears the stored credentials and restores the defaults, which sends the device back to looking for an IoTFlows 4G/LTE router. - **On a router**, the hold reboots it into setup mode, blinking blue, ready for the procedure above. So the same gesture moves a device either way, and the LED afterwards tells you which happened. Blinking blue means it is waiting for credentials; anything else means it has gone looking for a router. Both patterns are in [LED and screen status codes](/docs/hardware/led-and-status-codes/#leds). Changing the password on a network many devices already use is not this procedure either. Update it from [Manage saved Wi-Fi networks](/docs/hardware/manage-wifi-networks/), which saves the new password to your organization so nobody retypes it. **There is no bulk push:** each device still has to be sent the new credentials from its own **Networks** tab. ## See also - [Manage saved Wi-Fi networks](/docs/hardware/manage-wifi-networks/) - [Connect a device through the 4G/LTE router](/docs/hardware/use-the-lte-router/) - [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/) - [LED and screen status codes](/docs/hardware/led-and-status-codes/) --- # Install and align BeamTracker Source: https://www.iotflows.com/docs/hardware/install-beamtracker/ Mount a BeamTracker across the flow of finished parts and aim its beam: the device is a single unit with no reflector, firing an invisible laser that resolves to the millimetre at up to 8 meters (26 ft), mounted on a separately ordered bracket, powered over M12 at 4.5 to 28 V DC, and set up from its own touchscreen rather than from the dashboard. # Install and align BeamTracker Mount a BeamTracker across the part flow, aim the beam, and confirm it booted. BeamTracker counts units as they pass a point. It fires an invisible laser across the path parts travel, and each part that breaks the beam registers a count. Where you aim it decides what gets counted, so mounting and aiming are the whole job. This page ends with a powered, aimed device. Setting the detection thresholds is a separate procedure, in [Calibrate BeamTracker](/docs/hardware/calibrate-beamtracker/). **Before you start:** have the line stopped and safe to reach into, and have the mounting bracket and M12 power on hand. Both are ordered separately from the device. ## Check what is in the box The box holds the device, with its built-in touchscreen, and one external antenna. The mounting bracket, the M12 power adapter, and the M12 cable are ordered separately. Inspect before you mount. Check the screen and enclosure for damage, the M12 connector for bent pins, and the two lenses on the front face for fingerprints or shipping film. A smeared lens is a weak beam. If a part is missing or damaged, stop and [contact support](/docs/get-started/get-support/). ## Connect the antenna Thread the external antenna onto the connector and hand-tighten it. Use no tools, and stop when it is snug. Connect it before powering the device on, because without it the radio has almost no range and the device will not hold a connection. ## Understand how the beam works A *tripwire* is the right mental model: BeamTracker fires one invisible laser point from the front face and watches for that point to be interrupted. It is not a camera and not a wide-angle scanner, so it sees only what crosses that single line. The device is one unit. There is no reflector to mount opposite it, and nothing to align it against beyond the surface the beam lands on. ![A BeamTracker mounted on a bracket at the edge of a conveyor, its beam shown as a dashed line crossing the part path to a point on the far side](/images/beamtracker/laser-beam-illustration-with-beams.webp) *BeamTracker fires a single beam across the part path from the lens pair on its front face. One unit, no reflector: the beam simply lands on whatever is opposite.* A part is counted when it interrupts that beam, which means it has to be bigger than the laser point, opaque enough to block it, and travelling through the line rather than past it. Glass and clear film may not register at all. The background matters too. Aim across a stable surface, because anything moving behind the part path can break the beam on its own and add counts nobody made. ## Choose a mounting point Aim for a point where **every good part passes the beam and nothing else does**. That single sentence decides most installations. A beam that also catches an operator's hand will count hands. A beam across a spot where parts are stacked, reworked, or set down will count each pass. Pick the narrowest point in the flow where finished parts move one way and nothing else crosses. The location also has to give you: - **A clear line of sight** across the part path, perpendicular to the direction of travel. - **A working distance of up to 8 meters (26 ft)** from the device to the part path. The beam resolves to the millimetre across that range, and the cutoff beyond which it ignores everything is set during [calibration](/docs/hardware/calibrate-beamtracker/). - **A stable background** behind the part path, with nothing moving in it. - **A readable screen.** Setup and status live on the device, so an operator has to be able to see it. Coolant, cutting fluid and wash-down are not constraints. BeamTracker is IP67, so pick the point that gives the beam a clean run rather than retreating to a dry spot. What the beam cannot survive is a path it cannot see across: mist, airborne chips and spray break a reading in a way the housing does not. ![A BeamTracker product render, mounted on a slotted steel L-bracket by two bolts, with its touchscreen showing a Get Started button, the antenna rising from the top and an M12 cable leaving the bottom](/images/hardware/hw-install-bt-01.webp) *BeamTracker on its L-bracket: the screen faces the operator, the antenna clears the top, and the M12 cable leaves the bottom. The two bolts in the slotted arc are what you loosen to aim the beam.* ## Mount and aim the device 1. Fasten the bracket to the surface you picked, using fasteners suited to that material. Check it is level and that it does not move when the machine runs. 2. Attach the BeamTracker to the bracket and tighten it down, with the screen turned toward where an operator will stand. 3. Aim the front face square across the part path, so the beam crosses at one consistent point. 4. Run a part through and watch that it breaks the beam cleanly. A bracket that vibrates walks the beam off its target over a shift, so the tug test at step 1 matters more here than on a magnet-mounted sensor. ![Bottles moving along a conveyor past a bracket-mounted BeamTracker, whose screen shows the part count rising from 775 and a green Running status](/images/hardware/hw-install-bt-02.gif) *A BeamTracker counting a bottling line: each bottle crossing the beam adds one to the count on the device screen, which reads Running while parts keep arriving.* ## Connect power BeamTracker takes **4.5 to 28 V DC** over M12. The rating is printed on the device label, which is the authority if a document disagrees. Connect the M12 cable to the device first: align the keyed connector, push until it clicks, then hand-tighten the locking collar. An M12 joint resists vibration only when it is fully seated and locked. Then power the other end with either the M12 power adapter, into a standard 100 to 240 V AC outlet, or an M12 T-splitter, to daisy-chain from power already running to a nearby device. Choose the splitter when several devices sit close together and you do not want an outlet for each. ## Confirm first boot The screen lights as soon as the device has power, runs its startup checks, and shows the IoTFlows boot screen. What happens next depends on how this device reaches the internet. - **On an IoTFlows 4G/LTE router:** the device connects on its own. See [Connect a device through the 4G/LTE router](/docs/hardware/use-the-lte-router/). - **On facility Wi-Fi:** the screen shows setup instructions and a QR code. Provision it from the mobile app, in [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/). ![The BeamTracker get-started screen](/images/beamtracker/beam-tracker-get-started.webp) ![The BeamTracker screen showing a QR code for the mobile app](/images/beamtracker/beamtracker-qr-code.webp) ![The BeamTracker screen in Wi-Fi configuration mode](/images/beamtracker/beamtracker-wifi-setup.webp) ![The BeamTracker screen while connecting to Wi-Fi](/images/beamtracker/beamtracker-trying-to-connect-wifi.webp) The screen is touch-enabled, and it is where the device reports a beam that is not landing where it should. If it says the beam is misaligned, re-aim the front face before going further, then set the detection range in [Calibrate BeamTracker](/docs/hardware/calibrate-beamtracker/). ## If the screen stays dark 1. Reseat the M12 cable at the device end and lock the collar. 2. Reseat the other end at the adapter or the T-splitter. 3. Look into both connectors for bent pins or packed debris. 4. Confirm the outlet is live, or that an industrial supply sits within 4.5 to 28 V DC. If the screen stays dark on a known-good supply, [contact support](/docs/get-started/get-support/) with the device serial from the label. For a device that powers up but will not stay online, see [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). ## See also - [Calibrate BeamTracker](/docs/hardware/calibrate-beamtracker/) - [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/) - [BeamTracker](/docs/hardware/beamtracker/) - [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/) --- # Install and power up SenseAi Embedded Source: https://www.iotflows.com/docs/hardware/install-senseai-embedded/ Mount a SenseAi Embedded on the motor or spindle it should read, connect the antenna, power it over M12 at 4.5 to 28 V DC from either the supplied adapter or a T-splitter, and confirm first boot; the sealed IP67 housing is what lets the unit sit in coolant and wash-down close to the source, and the job takes 5 to 45 minutes depending on how reachable that spot is. # Install and power up SenseAi Embedded Mount a SenseAi Embedded at the source, power it over M12, and confirm it booted. SenseAi Embedded runs the same application as [SenseAi](/docs/hardware/senseai/). What the sealed IP67 housing buys is placement: the unit can go on the motor or the spindle itself, in coolant and wash-down that a standard SenseAi would not survive. Reading at the source is what adds advanced health analytics on top of machine performance. Plan on 5 to 45 minutes. The spread is not about the enclosure, it is about whether you can reach the spot you want. This page ends with a powered device. Getting it onto the network is a separate procedure, in [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/). **Before you start:** have the machine stopped and safe to touch, and know which machine this unit belongs to. Sensors are tied to an asset by IoTFlows during onboarding, so if you are unsure which device goes on which machine, [contact support](/docs/get-started/get-support/). ## Check what is in the box The box holds two things: the device and one external antenna. The M12 power adapter and the M12 cable are ordered separately, so confirm you have them before you walk out to the machine. The cable is an extension, 1 to 3 meters (3 to 10 ft), for when the adapter alone will not reach the unit. The full list, with specifications and network requirements, is on [SenseAi Embedded](/docs/hardware/senseai-embedded/). Inspect before you mount. Check the enclosure for cracks, the antenna connector for damage, and both M12 connectors for bent pins or debris. A bent pin is cheaper to find on the bench than on the motor. If a part is missing or damaged, stop and [contact support](/docs/get-started/get-support/). ## Connect the antenna Thread the external antenna onto the device connector and hand-tighten it. Use no tools, and stop when it is snug rather than forcing it. Connect it before you power the unit on, because without it the radio has almost no range and the device will not hold a connection. Nothing is damaged by powering up without it. Once mounted, point the antenna vertically and check it clears anything that moves. ## Choose a mounting location Get as close to the source as the machine allows: the motor, the spindle, or the housing that carries them. That proximity is the reason to choose Embedded over a standard SenseAi. The surface has to meet three tests: - **Ferrous.** The magnetic base needs steel or iron. Paint does not matter, the magnet holds through it, but rubber, plastic, and aluminum give it nothing to grip. - **Coupled.** The metal must be tied to the parts that move. A guard, a cover, or a panel bolted to the frame passes the sensor its own ringing rather than the driveline's, and the machine then reads as one state all shift. - **Clear.** Nothing moving can strike the unit, the antenna, or the cable, and it must not block an access panel or a maintenance point. Coolant, cutting fluid, and wash-down are not constraints here. The IP67 housing is sealed, so use that to get nearer the source rather than retreating to a dry spot. ![A SenseAi Embedded unit magnet-mounted on the body of a machine motor, with its M12 cable routed away from moving parts](/images/hardware/hw-install-se-01.webp) *An Embedded unit mounted on the motor itself, with the cable run kept clear of moving parts.* Wipe the surface clean of oil and debris, then set the magnetic base flat against it. Place one edge first and roll the unit down rather than dropping it on, then try to move it by hand to confirm it is seated. Keep the unit square to the surface, not tilted on an edge or a fillet. A tilt shows up later as a non-zero mean in the vibration KPIs, which you clear with the zero-offset reset in [Calibration settings](/docs/hardware/calibration-settings/). If the only reachable spot is non-ferrous, [contact IoTFlows](/docs/get-started/get-support/) for a mounting option rather than settling for a worse location. Whichever spot you pick, [calibration](/docs/hardware/calibrate-senseai/) is where you confirm it reads the machine. ## Connect power SenseAi Embedded takes **4.5 to 28 V DC** over M12. The rating is printed on the device label, which is the authority if a document disagrees. Connect the M12 cable to the unit first. Align the keyed connector, push until it clicks, then hand-tighten the locking collar. An M12 joint resists vibration only when it is fully seated and locked. Then power the other end one of two ways: - **An M12 power adapter**, into a standard 100 to 240 V AC outlet. Use this unless you have a reason not to. - **An M12 T-splitter**, to daisy-chain the unit from power already running to a nearby device. Choose this when several units sit close together and you do not want an outlet for each. ![An M12 power adapter with a female M12 connector and an AC plug](/images/shared/m12-female-power-cable.webp) ![An M12 T-splitter with one female and two male connectors](/images/shared/m12-t-connector-splitter.webp) ![An M12 male-to-female extension cable](/images/shared/m12-male-to-female-cable.webp) ## Confirm first boot The power LED lights as soon as the unit has power, and the status LED runs a boot sequence for 30 to 60 seconds. What happens next depends on how this device reaches the internet. - **On an IoTFlows 4G/LTE router:** the unit connects on its own, within 2 to 5 minutes. See [Connect a device through the 4G/LTE router](/docs/hardware/use-the-lte-router/). - **On facility Wi-Fi:** the LED blinks blue, which is Wi-Fi setup mode. Provision it from the mobile app, in [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/). ![A SenseAi Embedded unit with its status LED blinking blue in Wi-Fi setup mode](/images/senseai-embedded/senseai-embedded-wifi-setup-mode.gif) *The LED blinking blue at first boot: the unit has power and is waiting to be put on Wi-Fi.* Every pattern the LED can show is listed in [LED and screen status codes](/docs/hardware/led-and-status-codes/). ## If it will not power on A dead unit is almost always the connection or the supply. Work through this in order: 1. Reseat the M12 cable at the device end and lock the collar. 2. Reseat the other end at the adapter or the T-splitter. 3. Look into both connectors for bent pins or packed debris. 4. Confirm the outlet is live, or that an industrial supply sits within 4.5 to 28 V DC. If the magnetic base will not hold instead, the surface is the suspect: confirm it is ferrous, then find a flatter or thicker section of the same casting. Thin sheet gives the magnet less to pull against. If the unit stays dark on a known-good supply, [contact support](/docs/get-started/get-support/) with the device serial from the label. ## See also - [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/) - [Calibrate SenseAi and SenseAi Embedded](/docs/hardware/calibrate-senseai/) - [SenseAi Embedded](/docs/hardware/senseai-embedded/) - [LED and screen status codes](/docs/hardware/led-and-status-codes/) --- # Install and power up SenseAi Source: https://www.iotflows.com/docs/hardware/install-senseai/ Mount a SenseAi on a machine and bring it online: connect the external antenna, pick a flat metal surface close to the spindle or main motor, attach the magnetic base square against it, power the unit from the supplied adapter or a machine USB port supplying at least 500 mA, and confirm the LED at first boot. # Install and power up SenseAi Mount a SenseAi on a machine, power it, and confirm it booted. A SenseAi arrives pre-configured. There is nothing to flash, wire, or claim: IoTFlows registers the device before it ships, so your first task is physical. Plan on 15 to 30 minutes for the first device and less for each one after it. This page ends with a powered device. Getting it onto the network is a separate procedure, in [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/). **Before you start:** have the machine stopped and safe to touch, and know which machine this sensor belongs to. Sensors are tied to an asset by IoTFlows during onboarding, so if you are unsure which device goes on which machine, [contact support](/docs/get-started/get-support/). ## Check what is in the box Each SenseAi ships with the device, one external antenna, one USB cable, and one power adapter. The full list, with the specifications and network requirements, is on [SenseAi](/docs/hardware/senseai/). If the antenna or the adapter is missing, stop and [contact support](/docs/get-started/get-support/). Neither part is optional. ## Connect the antenna Screw the external antenna onto the connector on the SenseAi housing, hand-tight, before you power the device on. Connect it first because without it the radio has almost no range and the device will not hold a connection. Nothing is damaged by powering up without it. Point the antenna vertically once the device is mounted. Metal between it and the access point costs signal, worth knowing before you pick a spot. ## Choose a mounting location You are looking for a surface that carries the machine's own vibration. Pick a spot that is flat ferrous metal, as close as you can get to the spindle or the main motor. Paint does not matter: the magnetic base holds through it. ![A SenseAi magnet-mounted on the white-painted frame of an injection molding machine, its USB cable running down to power, with a violet callout line labeling the sensor](/images/hardware/hw-install-sa-01.webp) *A good mount on an injection molding machine: the SenseAi sits flat on a casting tied to the parts that move, and the paint under the magnet makes no difference.* A good location meets all four of these: - It picks up vibration from the machine's operation. - It is out of the way of moving parts, chips, and the operator. - It is as close as possible to the spindle or the primary vibration source. - It offers a clear, stable magnetic surface. The surface also has to be mechanically tied to the parts that move. A guard door, an access cover, or a sheet-metal panel is metal, and the magnet holds on it, but joints and fasteners sit between that panel and the spindle. Even a structural casting can be isolated this way if it carries nothing but its own weight. What reaches the sensor in those spots is the panel ringing on its own, not the driveline. That costs you the machine state. Running and down come from one threshold on the vibration trace, so when the trace looks much the same cutting as stopped, no threshold separates the two and the machine reads as one state all shift. Part counts and cycle times come off that same trace, so they go with it. What the base cannot grip is anything non-ferrous. Rubber, plastic, and aluminum give the magnet nothing to hold, however flat they are. If the only reachable spot is non-ferrous, [contact IoTFlows](/docs/get-started/get-support/) for a mounting option; if it is washed with coolant, use [SenseAi Embedded](/docs/hardware/senseai-embedded/), which is sealed and mounts at the motor. Wipe the surface clean, then set the magnetic base flat against it. The base holds hard, so place one edge first and roll the device down rather than dropping it on. Keep the device square to the surface, not tilted on an edge or a fillet. A tilted sensor shows up later as a non-zero mean in the vibration KPIs, which you then have to clear with the zero-offset reset described in [Calibration settings](/docs/hardware/calibration-settings/). > **Info:** > A mount is not judged by eye. Run the machine cutting, then let it sit idle, and check that the two read differently in [Calibrate SenseAi and SenseAi Embedded](/docs/hardware/calibrate-senseai/). A device on the machine housing rather than the textbook spot can still read the machine well. ## Connect power SenseAi takes 5 V over USB-C and draws up to 500 mA. You have two options. **Use the supplied adapter** unless you have a reason not to. Connect the USB cable to the SenseAi, connect the other end to the adapter, and plug the adapter into an outlet. **Use a machine USB port** when the machine has a spare one and you want the sensor to power down with the machine. Connect the USB cable to the SenseAi and the other end to the port. Machine ports are usually USB-A, which the supplied cable does not fit. A USB-A to USB-C adapter lets you keep the IoTFlows cable rather than sourcing one of your own. > **Warning:** > The port must supply at least 500 mA. A port below that browns the device out under load, which reads as a sensor that keeps dropping off the network rather than as a power problem. When you cannot confirm the rating, use the adapter. ## Confirm first boot The power LED lights as soon as the device has power. What happens next depends on how this device reaches the internet. - **On an IoTFlows 4G/LTE router:** the device connects on its own. See [Connect a device through the 4G/LTE router](/docs/hardware/use-the-lte-router/). - **On facility Wi-Fi:** the LED blinks blue, which is Wi-Fi setup mode. Provision it from the mobile app, in [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/). ![A SenseAi seen from the front, antenna up, with the status LED below the WiFi and RESET buttons blinking blue](/images/senseai/senseai-wifi-setup-mode.gif) *The LED blinking blue at first boot: the device has power and is waiting to be put on Wi-Fi. If nothing lights at all, reseat the connector before assuming the unit is dead.* Every pattern the LED can show is listed in [LED and screen status codes](/docs/hardware/led-and-status-codes/). ## If nothing lights A dark LED is almost always the connection, not the unit. Work through this in order: 1. Reseat the USB-C connector at the device end until it clicks home. 2. Reseat the other end at the adapter, and confirm the outlet is live. 3. Move to the supplied adapter if you started on a machine USB port. 4. Try the second SenseAi's cable and adapter, if you have another device on site. If the LED stays dark on a known-good adapter and outlet, [contact support](/docs/get-started/get-support/) with the device serial from the housing. ## See also - [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/) - [Calibrate SenseAi and SenseAi Embedded](/docs/hardware/calibrate-senseai/) - [LED and screen status codes](/docs/hardware/led-and-status-codes/) - [Quickstart: see your first machine's data](/docs/get-started/quickstart/) --- # LED and screen status codes Source: https://www.iotflows.com/docs/hardware/led-and-status-codes/ Decode what an IoTFlows device is showing you: every SenseAi and SenseAi Embedded LED color and pattern, every BeamTracker touchscreen state, and the next step for each, from blinking blue in Wi-Fi setup mode through steady cyan and orange, which report the machine as down or running once the unit is online. # LED and screen status codes Every indicator pattern on every device, and what to do about it. SenseAi and SenseAi Embedded report their state through a single LED, BeamTracker on its touchscreen. Both answer the same three questions in order: does the unit have power, did it join the network, and what is the machine doing. **You do not need this page while a device reads online.** The [Devices](/docs/hardware/view-devices/) page is the authority on connectivity. Read the indicator when the dashboard says offline and you need to know how far the device got. ## SenseAi and SenseAi Embedded LEDs Both units run the same application and use the same patterns. | Device | Color | Pattern | State | Next step | |---|---|---|---|---| | Both | Blue | Blinking | Wi-Fi setup mode, waiting for credentials | Send the network and password from the mobile app: [Connect to Wi-Fi](/docs/hardware/connect-to-wifi/) | | Both | Red | Flashing every few seconds | Joining the configured network | Wait two minutes, then work [Device never came online](/docs/hardware/troubleshoot-offline-device/#never-online) | | Both | Orange, green, white, cyan | One blinking sequence | Joined the network, opening the cloud connection | Wait for a steady color | | Both | Cyan | Steady | Online; the machine reads as down | None | | Both | Orange | Steady | Online; the machine reads as running | None | | Both | Purple, then red | While you hold the Wi-Fi button | Ten-second reset reached | Release. The unit reboots into setup mode or back onto the router | | Both | Nothing | Dark | No power | Check the supply: [nothing lights](/docs/hardware/install-senseai/#no-led) | A unit reports the machine as running or down, with no third state, so steady cyan is not a fault. A machine paused between cycles sits below the running threshold [calibration](/docs/hardware/calibrate-senseai/) sets, and shows cyan. ![A SenseAi with its LED blinking blue in Wi-Fi setup mode](/images/senseai/senseai-wifi-setup-mode.gif) *Setup mode* ![A SenseAi cycling through the reconnect color sequence](/images/senseai/senseai-reconnecting-to-wifi.gif) *Reconnecting* ![A SenseAi lit steady cyan](/images/senseai/senseai-cyan.webp) *Down* ![A SenseAi lit steady orange](/images/senseai/senseai-orange.webp) *Running* ![A SenseAi Embedded with its LED blinking blue in Wi-Fi setup mode](/images/senseai-embedded/senseai-embedded-wifi-setup-mode.gif) *Setup mode* ![A SenseAi Embedded cycling through the reconnect color sequence](/images/senseai-embedded/senseai-embedded-reconnecting-to-wifi.gif) *Reconnecting* ![A SenseAi Embedded lit steady cyan](/images/senseai-embedded/senseai-embedded-cyan.webp) *Down* ![A SenseAi Embedded lit steady orange](/images/senseai-embedded/senseai-embedded-orange.webp) *Running* ## BeamTracker screen states BeamTracker has no status LED. The touchscreen carries the same information in words. | Screen | Means | Next step | |---|---|---| | Dark, no response | No power | Check the M12 connection: [screen stays dark](/docs/hardware/install-beamtracker/#no-power) | | IoTFlows boot screen | Powered and starting | Wait | | **Get Started** | Booted, not yet configured | Tap through to set up the device | | QR code | Offering the pairing code | Scan it, or open **Connect Device to WiFi** in the app | | **WiFi Setup** | Listening over Bluetooth | Select BeamTracker in the app and send the network | | **Connecting…** | Joining the network | Wait. It appears online within five minutes | | **Connection Failed** | The network refused the device | Confirm it is 2.4 GHz and re-enter the password | | Readable but dim | Brightness or glare, not a fault | Raise brightness in the device settings menu, shade the screen, wipe it dry | ![The BeamTracker Get Started screen](/images/beamtracker/beam-tracker-get-started.webp) *Get Started* ![The BeamTracker screen showing a pairing QR code](/images/beamtracker/beamtracker-qr-code.webp) *QR code* ![The BeamTracker WiFi Setup screen](/images/beamtracker/beamtracker-wifi-setup.webp) *WiFi Setup* ![The BeamTracker screen while it joins a network](/images/beamtracker/beamtracker-trying-to-connect-wifi.webp) *Connecting* ## IFCR-150 router lights The [IoTFlows 4G/LTE router](/docs/hardware/lte-router/) ships configured, so nothing on it needs reading during a normal install. Power it, allow a few minutes for it to reach the cellular network, and the devices behind it join its access point on their own. Check the devices instead. A sensor on steady cyan or orange has a path to the cloud through the router; one still flashing red does not. If every device behind a router is offline at once, work [Device never came online](/docs/hardware/troubleshoot-offline-device/#never-online). ## See also - [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/) - [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/) - [Install and power up SenseAi](/docs/hardware/install-senseai/) - [IoTFlows 4G/LTE router](/docs/hardware/lte-router/) --- # IoTFlows 4G/LTE router Source: https://www.iotflows.com/docs/hardware/lte-router/ The IFCR-150 is a cellular router that gives IoTFlows sensors their own 2.4 GHz network, reaching the cloud over 4G/LTE instead of facility Wi-Fi; it ships configured with its SIM fitted, needs no IT change request, and keeps every device behind it off the plant network entirely. # IoTFlows 4G/LTE router When to put devices on the IFCR-150 instead of facility Wi-Fi, and what it isolates. ## What it is The IFCR-150 is a cellular router. It creates its own 2.4 GHz Wi-Fi network for IoTFlows sensors and carries their traffic to the cloud over 4G/LTE, so they never join a network the plant owns. It ships configured. Power it on, give it a few minutes to reach the carrier, and devices assigned to it join on their own. There is nothing to set up on the router itself. **Choose the router when** plant IT will not admit devices to the facility network, when the machine sits outside Wi-Fi coverage, or when a pilot must not wait on an IT change request. **You do not need it** once your devices are approved on facility Wi-Fi. One router serves the sensors within range of it, not one router per sensor. | Consideration | Facility Wi-Fi | IFCR-150 | |---|---|---| | Approval | An IT change request to admit each device | None. The devices never join the plant network | | Setup per device | Send the network and password from the mobile app | None. Devices join the router on their own | | Path to the cloud | The plant's own internet connection | The router's 4G/LTE uplink | | Where it works | Anywhere plant Wi-Fi reaches the machine | Anywhere the building has a cellular signal | | Exposure to plant systems | The device sits on a network the plant owns | None | ## Specifications | Property | Value | |---|---| | Model | IFCR-150 4G/LTE cellular router | | Uplink | 4G/LTE, over a SIM fitted by IoTFlows before shipping | | Access point | 2.4 GHz Wi-Fi, matching what the sensors support | | Wired ports | Three LAN, one WAN | | Antennas | Four, external | | Indicators | 4G, LAN1, LAN2, LAN3, Wi-Fi, WAN, power | | Range to devices | Keep sensors within about 100 ft (30 m) of the router | | Configuration | None. It ships ready to power on | ![A product render of the IFCR-150 4G/LTE cellular router, a flat black box with four external antennas and a front panel of labeled indicator lights reading 4G, LAN3, LAN2, LAN1, Wi-Fi, WAN and power](/images/shared/ifcr150.webp) *The IFCR-150. The indicator row runs 4G, LAN1 to LAN3, Wi-Fi, WAN and power, left to right on the front edge.* ## What it isolates *Network isolation* means the sensors and the facility network have no route to each other. Devices behind the IFCR-150 are on the router's own network, and their only path out is its cellular uplink. They cannot reach plant systems, and plant systems cannot reach them. This is the argument to hand plant IT. Admitting a sensor to the corporate network is a security review; putting it on a router that never touches that network is not. Diagram: Two network boundaries drawn side by side as separate dashed enclosures with no line between them. The left enclosure, the facility network, holds plant IT systems and office and production Wi-Fi, and is footed never sees the sensors. The right enclosure, the IoTFlows router network, holds the sensors above the IFCR-150 router they join. An arrow leaves the router downward to a 4G/LTE carrier box and on to the IoTFlows cloud, so the only path out is cellular. A dashed divider labeled no route runs between the two enclosures, and no arrow crosses it. *Devices on the IFCR-150 never touch the facility network. This is the diagram to hand plant IT.* ## Coverage and SIM The SIM is fitted before the router ships, so there is no carrier account to open and no plan to choose. Cellular coverage decides whether the router works, and it is a property of the building rather than the device. Site it where a phone gets a usable signal: near a window or an exterior wall, high rather than low, out of a metal cabinet. Stand the four antennas vertical and clear of metal. Work outward from there. Sensors need to be within about 100 ft (30 m) of the router they join, so its position is a compromise between the signal it gets and the machines it covers. Where those pull apart, favour the cellular signal: a router with no uplink takes every device with it, while a sensor out of range takes only itself. For placement step by step, see [Connect a device through the 4G/LTE router](/docs/hardware/use-the-lte-router/). ## See also - [Connect a device through the 4G/LTE router](/docs/hardware/use-the-lte-router/) - [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/) - [How IoTFlows works](/docs/get-started/how-iotflows-works/) - [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/) --- # Manage saved Wi-Fi networks Source: https://www.iotflows.com/docs/hardware/manage-wifi-networks/ Move a deployed SenseAi, SenseAi Embedded or BeamTracker onto a different network from the dashboard's Networks tab, without a phone or a trip to the machine: push a new SSID and password over the device's existing connection, reuse a network your organization has already saved, or delete saved credentials that have gone stale. The device must be online; an offline device still needs Bluetooth provisioning from the mobile app. # Manage saved Wi-Fi networks Change the network on a device that is already deployed, and maintain the credentials your organization reuses. A *saved network* is an SSID and password stored on your organization rather than on one device. Save the plant's `IoTFlows0` network once, and every later device joins it without anyone retyping the passphrase or needing to know it. **Prerequisites.** The **Owner** or **Administrator** role, see [Roles and permissions](/docs/admin/roles-reference/). **The device must be online.** Getting a device onto a network for the first time is [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/). ## Open the device's Networks tab 1. Go to **Devices**. 2. Click **Edit Sensor** at the top right. The sensor cards on the map are not clickable. 3. Find the device you want to move in the **Sensor List** dialog. 4. Click the gear icon on its row. 5. Open the **Networks** tab. All three devices have this tab. It lists every network your organization has saved, plus **IoTFlows**, the built-in default a device looks for when it has no credentials of its own. A tick marks the one this device is on now. ![The Edit Sensor dialog with the Networks tab selected. Above the tab sit the sensor's name, current WiFi SSID, IP address, firmware version and MAC address, alongside the machine it reports for. Below it, three networks are listed: IoTFlows, which carries a Connect action but no delete icon, and two saved organization networks, which carry both. A tick marks the network the sensor is on, and an Add Network link sits under the list.](/images/hardware/hw-wifi-03.webp) *The Networks tab on an online device. This is the web counterpart to Bluetooth provisioning.* ### Networks tab fields | Field | What it does | Applies to | |---|---|---| | Network row | A saved network, or **IoTFlows**, the built-in default. The tick marks the one the device reports being on. | The organization | | **Connect** | Pushes that network's stored password to this device. | This device | | **Add Network** | Opens the form for credentials nobody has saved yet. | Both | | **Wi-Fi SSID** | The network name to send. Required. | Both | | **Wi-Fi Password** | The passphrase. Leave empty for an open network. | Both | | Delete icon | Removes the saved credentials from your organization. Absent on **IoTFlows**. | The organization | ## Push new credentials Do this when the site's Wi-Fi password changed, or the device is moving to a network nobody has saved yet. 1. Click **Add Network**. 2. Enter the **Wi-Fi SSID**. 3. Enter the **Wi-Fi Password**. 4. Click **Connect Wi-Fi**. The dashboard sends the credentials over the connection the device already has, so no phone is involved. It reports **Wi-Fi credentials sent to device**, then **Connecting to Wi-Fi** while the device leaves the old network and rejoins on the new one. Success reads **New Wi-Fi connection added**, and the network is saved for the next device. If the device has not reappeared after 45 seconds, the dashboard gives up with **Wi-Fi connection failed, please try again** and the device falls back to the network it had. Confirm the new network reaches the machine before retrying: see the warning in [Change the network later](/docs/hardware/connect-to-wifi/#change). ## Reuse a saved organization network Click **Connect** on any row. The dashboard pushes that network's stored password and reports the same sequence as above. **Choose this when** the device is moving between networks your organization already runs, for example a sensor joining the cell the rest of its line is on. There is no bulk action. A password change on a network ten devices use is ten pushes, so work down the **Devices** list in one sitting. ![The Networks tab mid-push. Under the row for the network being joined, a green tick reads Wi-Fi credentials sent to device and a spinner below it reads Connecting to Wi-Fi, while that row's Connect action shows its own spinner. The IoTFlows row above carries a Connect action but no delete icon; the saved networks below carry both.](/images/hardware/hw-networks-02.webp) *Pressing Connect on a saved network. The tab reports the credentials sent, then waits for the device to rejoin on the new network.* ## Delete a saved network 1. Click the delete icon on the network's row. 2. Click **Delete** in the **Delete Network** dialog. The tab confirms **Network has been deleted**. **IoTFlows** carries no delete icon, because it is the built-in default rather than something you saved. Deleting removes the credentials from your organization only. **Devices already on that network stay connected**, because they hold the password they were given. Delete a network when the site retires the SSID, or when a stored password is stale. ## When the device is offline A device that cannot reach the cloud cannot be told anything over it. The tab disables **Connect** and **Add Network** and shows an orange **Device Offline** banner: *The device must be online to switch Wi-Fi connections. For initial Wi-Fi setup, please use the IoTFlows iOS or Android app.* **Use Bluetooth provisioning from the app when the device is offline, new, or has no working connection to push over.** That is [Put the device in setup mode](/docs/hardware/connect-to-wifi/#setup-mode), and this page does not replace it. If the device should be online and is not, start at [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). ![The Networks tab on an offline device. An orange Device Offline banner sits above the network list, reading that the device must be online to switch Wi-Fi connections and that initial setup needs the IoTFlows iOS or Android app. Every Connect action below it is grayed out.](/images/hardware/hw-networks-03.webp) *When the device is offline the web tab cannot reach it, and tells you to use the mobile app instead.* ## See also - [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/) - [View and manage your devices](/docs/hardware/view-devices/) - [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/) - [Roles and permissions](/docs/admin/roles-reference/) --- # Overview: IoTFlows hardware Source: https://www.iotflows.com/docs/hardware/overview/ The three IoTFlows sensors and the router that connects them: SenseAi reads vibration and acoustics on general machinery, SenseAi Embedded runs the same application from an IP67 housing that mounts on the motor itself, BeamTracker counts units passing a point with a laser, and the IFCR-150 4G/LTE router carries any of them when facility Wi-Fi is not an option. # Overview: IoTFlows hardware What each device measures, what it fits, and which one this machine needs. Every number in IoTFlows starts at a sensor on a machine. Each sensor appears in the platform as a *node*, the device record paired to one machine, and it is the node that decides in the moment whether the machine is running. Choosing hardware is therefore choosing what you will be able to ask later. ## The three sensors and the router **[SenseAi](/docs/hardware/senseai/)** reads vibration and acoustics through a magnetic base. It suits general machinery, and it is the default choice. **[SenseAi Embedded](/docs/hardware/senseai-embedded/)** runs the same application as SenseAi and reads vibration and temperature, with no acoustic channel, because its housing is sealed. That IP67 seal is what it buys you: the unit can go on the motor or the spindle itself, in coolant and wash-down. **[BeamTracker](/docs/hardware/beamtracker/)** fires a laser across a path and registers a count each time a unit breaks the beam. It has a touchscreen for setup and is also IP67. The **[IFCR-150 4G/LTE router](/docs/hardware/lte-router/)** is not a sensor. It is how sensors reach the cloud when facility Wi-Fi is not available to them, and it pairs with any of the three. ![A product render of the four IoTFlows devices in a row: the IFCR-150 router with four antennas, then the round SenseAi puck, the BeamTracker with its touchscreen, and the small SenseAi Embedded unit, each sensor shown from the front and from the back](/images/hardware/hw-overview-01.webp) *Left to right: the IFCR-150 router, SenseAi, BeamTracker and SenseAi Embedded, each sensor shown front and back.* ## Compare the devices *Machine health* is the trend in a machine's vibration signature over weeks, scored against a baseline. Only the sensors that read vibration can produce it. | Device | Measures | Best for | Environment | Power | Part counting | Machine health | Page | |---|---|---|---|---|---|---|---| | SenseAi | Vibration and acoustics | General machinery | Ordinary shop floor | USB-C, 5 V, 500 mA minimum | Derived from the cycle | Yes | [SenseAi](/docs/hardware/senseai/) | | SenseAi Embedded | Vibration and temperature | Mounting at the source | IP67: coolant, wash-down, cabinets | 4.5 to 28 V DC over M12 | Derived from the cycle | Yes, with advanced analytics | [SenseAi Embedded](/docs/hardware/senseai-embedded/) | | BeamTracker | A unit breaking a laser beam | Counting units passing a point | IP67, and needs clear line of sight | 4.5 to 28 V DC over M12 | Counted directly | No | [BeamTracker](/docs/hardware/beamtracker/) | | IFCR-150 router | Nothing. It carries traffic | Sites where plant Wi-Fi is closed | Ordinary shop floor | Mains | n/a | n/a | [4G/LTE router](/docs/hardware/lte-router/) | All three sensors need a 2.4 GHz Wi-Fi network or the router. None of them supports 5 GHz. ## Choose for a machine Choose **SenseAi** when you need to know whether a machine is running, how healthy it is, and how many parts it made. It reads vibration, calibrated thresholds decide where running begins and ends, and the algorithm derives part counts and cycle times from that same trace. One sensor answers all three questions. Choose **BeamTracker** when you need to count units as they pass a point rather than derive counts from a machine's own cycle. **You do not need both on the same equipment** unless you need that count *and* vibration health. Adding a second device to a machine that already reports what you ask of it buys nothing. Between the two SenseAi form factors, choose **SenseAi Embedded** when you can mount on the motor itself, since reading at the source is what adds the advanced health analytics. Choose standard **SenseAi** when the motor is not reachable or not safe to mount on. Diagram: A decision tree for choosing a device, reading downward from the question: what do you need to know about this machine? It splits into two branches. The left branch, whether it is running, how healthy it is, and how many parts it made, leads to a second question, can you mount on the motor itself, which splits again: yes leads to SenseAi Embedded, no leads to SenseAi. The right branch, a count of units as they pass a point, leads straight to BeamTracker. Two notes sit under the tree: needing both answers on the same equipment means using both devices, and the IFCR-150 router is a network choice rather than a device choice. *Choosing a device: start from what you need to know about the machine, not from what the machine is.* ## What IoTFlows does before the box arrives Devices arrive claimed and registered to your organization. IoTFlows also pairs each sensor to the machine it will report for, which is why nothing in the documentation describes a pairing flow. If you are unsure which unit belongs on which machine, [contact support](/docs/get-started/get-support/). Your first hardware task is therefore mounting, not configuration. Unbox the device, put it where it can read the machine, power it, and get it on a network. ## See it in a plant - [SenseAi](https://www.iotflows.com/products/senseai) — Reads vibration and sound from the outside of the machine, on a magnetic base. - [SenseAi Embedded](https://www.iotflows.com/products/senseai-embedded) — Reads vibration and temperature at the motor or spindle, in a sealed IP67 housing. - [BeamTracker](https://www.iotflows.com/products/beamtracker) — Counts every part that crosses its laser, with a touchscreen on the device. ## See also - [SenseAi](/docs/hardware/senseai/) - [BeamTracker](/docs/hardware/beamtracker/) - [Buy IoTFlows hardware](/docs/hardware/buy/) - [How IoTFlows works](/docs/get-started/how-iotflows-works/) --- # SenseAi Embedded Source: https://www.iotflows.com/docs/hardware/senseai-embedded/ SenseAi Embedded runs the same application as SenseAi but reads vibration and temperature, with no acoustic channel, because its IP67 housing is sealed; the rating buys placement, letting it mount on the motor or spindle itself where reading at the source adds advanced health analytics, and it ships with an external antenna only, since the M12 power adapter and cable are ordered separately, and needs a 2.4 GHz Wi-Fi network or an IoTFlows 4G/LTE router. # SenseAi Embedded What SenseAi Embedded measures, what ships in the box, and where it can go that a standard SenseAi cannot. SenseAi Embedded runs the same application as [SenseAi](/docs/hardware/senseai/) and reports the same things. It is not a different product for a different buyer. What its sealed IP67 housing buys is placement: it mounts on the motor or spindle itself, and on surfaces where coolant, wash-down or dust would end a standard unit. Reading at the source is what adds *advanced health analytics*, the bearing and multi-axis detail that needs vibration measured at the component rather than through the machine frame. ## What SenseAi Embedded measures ![A SenseAi Embedded shown from the front and the back. The front is a gray metal housing marked SenseAi Embedded with a recessed button, and a threaded M12 connector and a stub antenna rise from the top edge. The back carries two metal magnetic pads between four corner screws](/images/hardware/hw-embedded-01.webp) *SenseAi Embedded, front and back: the M12 connector on the top edge, and the magnetic base on the back that must sit flat against the machine.* SenseAi Embedded reads vibration and temperature. The housing is sealed, so unlike SenseAi it takes no acoustic reading, and neither device measures current. From those readings, the cloud reports: - Machine status in real time: running or down. There is no third state. - Uptime, utilization, and production insights. Every figure is defined in [how each metric is calculated](/docs/monitoring/metrics-reference/). - Root-cause downtime analysis, with operator notes on each stop. - Historical performance by day, week, month, quarter, or year. - Anomaly detection and shock severity. - Machine health trends from vibration KPIs: mean, RMS, and standard deviation. - Temperature, with a Warning and a Critical Temperature alert at thresholds you set, 70 °C and 80 °C by default, on firmware 5 or later. See [Temperature events](/docs/alerts/asset-event-rules/#temperature). Data is encrypted in transit and at rest across the IoTFlows cloud. Thresholds you set during [calibration](/docs/hardware/calibrate-senseai/) decide where running begins and ends. Part counts and cycle times are derived from the same trace by the [algorithm](/docs/production/choose-an-algorithm/) you pick for that machine. Choose SenseAi Embedded when you can mount on the motor or spindle itself, or when the mounting point sees coolant, wash-down or dust. You do not need it when the best mounting point is reachable and dry: a standard [SenseAi](/docs/hardware/senseai/) reports the same machine performance and reads acoustics as well as vibration. ## Specifications | Property | Value | |---|---| | Type | Vibration and temperature sensor, IP67 | | Reads | Vibration and temperature. No acoustic channel | | Connectivity | Wi-Fi, 2.4 GHz only | | Connectors | Industrial M12 | | Power | 4.5 to 28 V DC over M12. The supplied adapter takes a standard 100 to 240 V AC outlet | | Operating temperature | -20 °C to 60 °C (-4 °F to 140 °F) | | Ingress protection | IP67: dustproof, and immersion to 1 m (3 ft) for 30 minutes | | Mounting | Magnetic base, ferrous surface required | ## In the box ![A SenseAi Embedded retail box](/images/senseai-embedded/box.webp) *A SenseAi Embedded ships pre-configured. The housing is sealed, so there is nothing to open or wire inside it.* | Item | Quantity | Notes | |---|---|---| | SenseAi Embedded device | 1 | Pre-configured; the housing is sealed | | External antenna | 1 | Connect it before powering the device on | The M12 power adapter and the M12 cable are ordered separately. The cable is an extension, 1 to 3 meters (3 to 10 ft), for when the adapter will not reach the unit; an M12 T-splitter daisy-chains power between units mounted close together. ## Requirements | Requirement | Value | |---|---| | Account | An IoTFlows organization you can sign in to | | Network | A 2.4 GHz Wi-Fi network, or an [IoTFlows 4G/LTE router](/docs/hardware/lte-router/). 5 GHz is not supported | | Phone | An iOS or Android device. Wi-Fi setup runs over Bluetooth from [the mobile app](/docs/get-started/install-mobile-app/), not from the web | | Mounting surface | A clean ferrous surface, on the motor or spindle where you can reach one | | Time | 5 to 45 minutes, depending on how reachable the mounting point is | IP67 covers temporary immersion, not permanent submersion, and the unit is rated to 60 °C. Do not mount it where either limit is passed. Sensors are tied to an asset by IoTFlows during onboarding. If a sensor is not reporting against the right machine, [contact support](/docs/get-started/get-support/). ## See also - [Install and power up SenseAi Embedded](/docs/hardware/install-senseai-embedded/) - [Calibrate SenseAi and SenseAi Embedded](/docs/hardware/calibrate-senseai/) - [LED and screen status codes](/docs/hardware/led-and-status-codes/) - [Overview: IoTFlows hardware](/docs/hardware/overview/) --- # SenseAi Source: https://www.iotflows.com/docs/hardware/senseai/ SenseAi is a magnet-mounted sensor that reads vibration and acoustics to report machine status, uptime, downtime reasons and vibration health without a PLC connection; it ships with an external antenna, a USB cable and a power adapter, and needs a 2.4 GHz Wi-Fi network or an IoTFlows 4G/LTE router, a phone for setup, and a flat magnetic mounting surface. # SenseAi What SenseAi measures, what ships in the box, and what it needs to run. SenseAi is a vibration and acoustic sensor that reports what a machine is doing without a PLC connection or an integration project. It magnet-mounts on or near the machine, reads the machine's own vibration and sound, and sends that stream to the IoTFlows cloud over Wi-Fi. It suits most industrial equipment. Comparing devices before you buy? [Overview: IoTFlows hardware](/docs/hardware/overview/) puts SenseAi, SenseAi Embedded, BeamTracker, and the 4G/LTE router side by side. ## What SenseAi measures ![A SenseAi shown from the front and the back. The front is a black disc carrying the IoTFlows logo and a status LED. The back shows two metal magnetic strips across a recessed contact face, with the screw-on antenna rising from the top edge of both views](/images/hardware/hw-senseai-01.webp) *SenseAi, front and back: the screw-on antenna, and the magnetic strips on the mounting face that must sit flat against the machine.* SenseAi reads vibration and acoustics. It does not measure current. From that one stream, the cloud reports: - Machine status in real time: running or down. There is no third state. - Uptime, utilization, and production insights. Every figure is defined in [how each metric is calculated](/docs/monitoring/metrics-reference/). - Root-cause downtime analysis, with operator notes on each stop. - Historical performance by day, week, month, quarter, or year. - Anomaly detection and shock severity. - Machine health trends from vibration KPIs: mean, RMS, and standard deviation. Data is encrypted in transit and at rest across the IoTFlows cloud. Thresholds you set during [calibration](/docs/hardware/calibrate-senseai/) decide where running begins and ends, which is what makes the machine read as running or down. Part counts and cycle times are derived from the same trace by the [algorithm](/docs/production/choose-an-algorithm/) you pick for that machine. You do not need a second device to get part counts from a machine SenseAi is already on. Choose [BeamTracker](/docs/hardware/beamtracker/) when you need to count units as they pass a point rather than derive counts from a machine's own cycle. Add both only when you need that count *and* vibration health on the same equipment. ## Specifications | Property | Value | |---|---| | Type | Vibration and acoustic intelligence sensor | | Connectivity | Wi-Fi, 2.4 GHz only | | Wi-Fi security | WPA2-PSK or WPA3 | | Power | USB-C, 5 V, 500 mA minimum | | Antenna | External, screw-on | | Mounting | Magnetic base | | Outbound traffic | HTTPS on port 443 | ## In the box ![A SenseAi retail box](/images/senseai/box.webp) *A SenseAi ships pre-configured. There is nothing to flash or wire before mounting.* | Item | Quantity | Notes | |---|---|---| | SenseAi device | 1 | Pre-configured; no on-site setup of the unit itself | | External antenna | 1 | Connect it before powering the device on | | USB cable | 1 | | | Power adapter | 1 | Use it unless the machine has a spare USB port supplying at least 500 mA | ## Requirements | Requirement | Value | |---|---| | Account | An IoTFlows organization you can sign in to | | Network | A 2.4 GHz Wi-Fi network, or an [IoTFlows 4G/LTE router](/docs/hardware/lte-router/). 5 GHz is not supported | | Phone | An iOS or Android device. Wi-Fi setup runs over Bluetooth from [the mobile app](/docs/get-started/install-mobile-app/), not from the web | | Mounting surface | A flat, stable magnetic surface on or near the machine | | Time | 15 to 30 minutes per device | Choose the 4G/LTE router over facility Wi-Fi when IT will not put devices on the corporate network, when coverage on the floor is poor, or when you want the sensors isolated from factory systems. Sensors are tied to an asset by IoTFlows during onboarding. If a sensor is not reporting against the right machine, [contact support](/docs/get-started/get-support/). ## See also - [Install and power up SenseAi](/docs/hardware/install-senseai/) - [Calibrate SenseAi and SenseAi Embedded](/docs/hardware/calibrate-senseai/) - [LED and screen status codes](/docs/hardware/led-and-status-codes/) - [Overview: IoTFlows hardware](/docs/hardware/overview/) --- # Troubleshoot a device that is offline Source: https://www.iotflows.com/docs/hardware/troubleshoot-offline-device/ Work the chain from power to radio to network to cloud when an IoTFlows device stops reporting: what the signal icon's three levels mean in dBm, why a device that drops several times a day is nearly always a signal problem rather than a failed sensor, and how to tell a dead device from a dead link when a machine reads as stopped. # Troubleshoot a device that is offline Find out why a device stopped reporting, and what to change. A device that is not reporting has broken one of four links: it has no power, its radio is not associated, its network cannot reach the internet, or the cloud is not receiving what it sends. Each break has a different fix, and they look nearly identical on the dashboard. Working them in order is faster than guessing. **Prerequisites:** physical access to the device, and access to the devices page to see its status. Provisioning a network needs the mobile app, in [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/). ## Start here: three checks Diagram: A chain of four stages joined left to right by arrows: Power, the device has power; Radio, it joins Wi-Fi or LTE; Network, it reaches the internet; Cloud, IoTFlows receives the stream. A marker under each stage names the failure that breaks it: a dark LED or blank screen at Power; a 5 GHz network or wrong passphrase at Radio; no DHCP address or outbound port 443 blocked at Network; and a device that is online but sends no readings at Cloud. *Where the chain can break: power, radio, network, cloud. Work along it in that order.* Do these three before anything else. They separate the four cases in about a minute. 1. **Look at the device.** A SenseAi shows its state on the LED, a BeamTracker on its screen. Both are decoded in [LED and screen status codes](/docs/hardware/led-and-status-codes/). A dark device is a power problem, not a network one. 2. **Look at the signal icon** on the devices page. A struck-through icon means the platform has no signal reading at all. One arc means the device is associated but weak. 3. **Check a second device on the same network.** If every device on one access point went quiet together, the problem is the network or the access point, not any device. Use the table to jump to the right section. | Symptom | Likely cause | Check | Fix | |---|---|---|---| | Never appeared after install | Provisioning did not complete | LED or screen state | [Device never came online](#never-online) | | Online, then offline, repeatedly | Weak or contended signal | Signal icon, then the RSSI chart | [Device drops repeatedly](#drops) | | Online but the machine reads stopped | Sensor detached, or nothing to report | Machine actually running? | [Device is online but sends no data](#no-data) | | One arc on the signal icon | Distance, metal, or interference | RSSI chart while running | [Weak signal](#signal) | | Button or screen will not start setup | Hold time too short | LED color while holding | [Will not enter setup mode](#setup-mode) | | App cannot find the device | Bluetooth range or permissions | Phone Bluetooth and location | [Bluetooth pairing fails](#bluetooth) | ## Device never came online A device that has never reported since installation almost always failed provisioning rather than hardware. 1. Confirm the device has power and has finished booting. Give a BeamTracker two to three minutes. 2. Confirm the network is **2.4 GHz**. The radios do not join 5 GHz networks, and a dual-band network advertising one name may hand the device the wrong band. 3. Confirm the security is WPA or WPA2. WEP is not supported, and a hidden network will not be found by a scan. 4. Re-enter the passphrase. It is case-sensitive, and a wrong one fails identically to a network that is out of range. 5. Confirm the access point issues DHCP addresses and is not filtering by MAC. If it filters, add the device's MAC, shown on its label and in its device panel. 6. Confirm outbound **port 443** is open. The devices reach the cloud over HTTPS and MQTTS, and a firewall that allows browsing may still block them. If the app reports **Wi-Fi connection failed, please try again**, the device heard the credentials and could not join. That is a wrong passphrase or the wrong band, not a broken device. If the dashboard reports **Device must be online to add a network. Please use the IoTFlows iOS or Android app for Wi-Fi provisioning.**, you have hit the rule rather than a fault: the web dashboard can only add a network to a device it can already reach. A device that is offline has to be provisioned over Bluetooth from the mobile app. ## Device drops repeatedly **Check the signal before you check the sensor.** A device that drops several times a day is nearly always a signal problem, and swapping the sensor moves the problem to a new serial number rather than fixing it. 1. Read the signal icon on the devices page. One arc is enough to explain repeated drops on its own. 2. Open the device and read the **WiFi RSSI** chart on its **Analyze** tab, which plots the live value in dBm. 3. Watch it while the machine runs a full cycle. A signal that is adequate on an idle machine and collapses under load is being blocked by something that moves. 4. If the value is fine and drops continue, restart the access point and check how many clients it is carrying. The RSSI chart streams live rather than replaying history, so it shows nothing for a device that is offline right now. Read it during a good period to find out how much margin you have, not after a drop to find out what happened. ## Device is online but sends no data An online device with no new data is reporting honestly about a machine that is not running, or it has lost contact with the machine. 1. Confirm the machine is actually running and producing. 2. Confirm the sensor is still attached. A SenseAi that has been knocked off its mounting surface stays online and reads nothing. 3. For a BeamTracker, confirm parts still cross the beam and nothing has moved the aim. 4. If the machine is running and the device is mounted, the thresholds are wrong rather than the hardware. See [Calibrate BeamTracker](/docs/hardware/calibrate-beamtracker/) or the SenseAi equivalent. ![An asset status bar running from before noon to after 2pm, its green running stretches and red downtime stretches broken up by a dozen gray stretches where the device was not reporting](/images/hardware/hw-trouble-03.webp) *Two hours of a shift in which the device kept dropping. The gray stretches are time the sensor was not reporting, not downtime the machine ran up.* ### Not sure whether the machine or the link is down? A machine whose sensor went offline still reads as stopped, because the card carries the last state the cloud recorded. The status bar is what tells the two apart: the stretch of the shift where the device was not reporting is grayed out rather than colored as downtime. That makes intermittent trouble visible as well. A device that keeps losing power or network through a shift leaves the bar striped with gray, which is the signature of a connection problem rather than a machine that genuinely keeps stopping. Work that as [a device that drops repeatedly](#drops). Open the asset itself and the live sensor tile goes gray instead of stopped, for the same reason: nothing is arriving to say either way. ## Weak signal The signal icon has three strength levels and a struck-through state, each standing for a band of received signal strength in dBm. A less negative number is stronger. Diagram: Four signal icons side by side, each over the band it stands for. Three arcs means above -50 dBm, a comfortable margin. Two arcs means -50 to -60 dBm, workable but worth watching. One arc means -60 dBm or below, where drops are expected. A struck-through icon means no reading at all, so the device is offline or is not reporting its signal. *The four states of the signal icon, and the band of received signal strength each one stands for. One arc, or a struck-through icon, explains repeated drops on its own.* Fix it by shortening the path or clearing it. Keep the device within about 100 ft (30 m) of the access point it joins, move that access point closer if you can, and reposition the external antenna away from metal. Machine enclosures, metal walls and other 2.4 GHz equipment all cost you signal. Choose the [IoTFlows 4G/LTE router](/docs/hardware/use-the-lte-router/) when the facility network cannot be improved, when plant IT will not admit the devices, or when the machine sits outside coverage. You do not need it where the devices already hold three arcs. ## Will not enter setup mode *Setup mode* is the state in which a device accepts new network credentials over Bluetooth. On a SenseAi or SenseAi Embedded, hold the Wi-Fi button for a full 10 seconds. The LED blinks purple and then turns red, and only then do you release it. Releasing early is the usual reason nothing happens. On a BeamTracker, setup mode is on the screen: wait for the boot to finish, then open **Settings** and the network option. If the screen shows nothing, power cycle it and let it boot fully before touching it. ## Bluetooth pairing fails 1. Confirm Bluetooth is on and the phone is within about 10 ft (3 m) of the device. 2. On Android, grant the app location permission. Android will not scan for Bluetooth devices without it, and the failure looks like an absent device. 3. Confirm the device is in setup mode before scanning. 4. Force close the app and reopen it, then retry. ## Still stuck Two messages on the dashboard are not about your device at all. **Waiting for Network** means your own browser has lost its realtime connection to IoTFlows, so reload the page. **Something went wrong** and **An error occurred** are the platform's generic failures: the request did not complete and nothing was saved, so retry it. If the device has power, the correct band and an open path to the internet and still will not report, [contact support](/docs/get-started/get-support/) with the device serial, the network it is on, and what the LED or screen shows. ## See also - [LED and screen status codes](/docs/hardware/led-and-status-codes/) - [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/) - [Connect a device through the 4G/LTE router](/docs/hardware/use-the-lte-router/) - [Get support](/docs/get-started/get-support/) --- # Connect a device through the 4G/LTE router Source: https://www.iotflows.com/docs/hardware/use-the-lte-router/ Bring a SenseAi, SenseAi Embedded or BeamTracker online through the IFCR-150 without touching the facility network: site the router where a phone gets signal, keep every device within 100 ft (30 m) of it, let the devices join its Wi-Fi on their own, and confirm them at Devices in the dashboard. One router serves a cell, not one per machine. # Connect a device through the 4G/LTE router Bring a device online without touching the facility network. The [IoTFlows 4G/LTE router](/docs/hardware/lte-router/) is an IFCR-150 that creates its own 2.4 GHz Wi-Fi network for your sensors and reaches the cloud over cellular. Devices are set to join it before they ship, so there is nothing to type at the machine. For facility Wi-Fi instead, see [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/). **You need** an IFCR-150 from IoTFlows. Nothing else: no app, no credentials, and no change request to plant IT. Diagram: A chain of four stages joined left to right by arrows: the devices, being SenseAi, SenseAi Embedded and BeamTracker; the IFCR-150 router they join over 2.4 GHz Wi-Fi; the 4G/LTE carrier the router reaches over its SIM; and the IoTFlows cloud, where the device reads online. A marker under each stage names what it needs: the devices within 100 ft (30 m) of the router; the router sited where a phone gets signal; the SIM fitted before shipping, nothing to do; and the device online in the dashboard. A note under the router reads: if the dashboard says offline, check here before the sensor. *Devices to router to carrier to cloud. If the dashboard says offline, check the router's uplink before the sensor.* ## Power and place the router 1. Choose a spot where a phone gets a usable cellular signal: near a window or an exterior wall, high rather than low, outside any metal cabinet. 2. Keep every device that will use the router within about 100 ft (30 m) of it, measured to the device as mounted, not to where you stand. 3. Stand the four antennas vertical and clear of metal. Placement is most of the signal quality you will get. 4. Connect the power adapter. Where the cellular signal and the device range pull apart, favour the cellular signal. A router with no uplink takes every device with it. Diagram: A side view of a production cell. On the left is the exterior wall with a window in it. The IFCR-150 router is mounted high on that wall beside the window, its four antennas standing vertical, labeled: high, beside a window or exterior wall, where a phone gets signal, antennas vertical and clear of metal. Below the router, against the same wall, stands a metal cabinet with a crossed-out router inside it, labeled: not in here, and not low. On the right is a machine with a sensor on it. A dimension line runs from the router to the sensor as mounted, labeled: within about 100 ft (30 m), router to device as mounted. *Where the router goes: high beside a window or exterior wall, antennas vertical, out of any metal cabinet, and within about 100 ft (30 m) of each device as mounted.* ## Confirm the cellular link The router ships configured, with its SIM fitted. Give it a few minutes after power-up to reach the carrier. The front panel carries seven indicators, **4G**, **LAN1** to **LAN3**, **Wi-Fi**, **WAN** and power, but their colors and patterns are not published. Read the link off the devices instead: a SenseAi on steady cyan or orange has a path to the cloud through the router, and one still flashing red does not. The patterns are in [LED and screen status codes](/docs/hardware/led-and-status-codes/#leds). If no device behind the router comes online after ten minutes, the router has no cellular link. Move it toward a window or exterior wall and check the antennas. Do not open the SIM slot: it is seated before shipping, and reseating it is not a support step. If a better position does not fix it, [contact support](/docs/get-started/get-support/). ## Provision the device A *SSID* is the name a Wi-Fi network broadcasts. The router's SSID is another 2.4 GHz network as far as your devices are concerned, so everything on [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/) about range and signal applies to it. The difference is that nobody types the credentials. **A device straight from the box** needs nothing. Mount and power it within range of the router, following [Install and power up SenseAi](/docs/hardware/install-senseai/) or its [Embedded](/docs/hardware/install-senseai-embedded/) and [BeamTracker](/docs/hardware/install-beamtracker/) counterparts, and it joins on its own. **A SenseAi or SenseAi Embedded that was on facility Wi-Fi** has to be sent back to its defaults: 1. Hold the **Wi-Fi** button. The LED blinks purple while you hold it. 2. Release when the LED turns red, at ten seconds. 3. The device reboots, clears the stored network, and goes looking for the router. The same hold on a device already on a router puts it into setup mode instead, blinking blue. So blinking blue after the reboot means there was no facility network to clear. **A BeamTracker that was on facility Wi-Fi** has no button to reset. Provision it onto the router's network from its touchscreen and the [mobile app](/docs/get-started/install-mobile-app/), using [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/#setup-mode), and ask [support](/docs/get-started/get-support/) for the router's network name and password. ## Confirm in the dashboard Open **Devices** in the dashboard. A device reads online within a minute or two of joining the router, and its **Networks** tab shows the router's SSID as its current network. That is the check that matters: [View and manage your devices](/docs/hardware/view-devices/). **The LED is steady but the dashboard says offline.** The device is on the router and the router has no uplink. Check the router first, not the sensor: work [Confirm the cellular link](#uplink). Every device behind one router going offline at once points the same way. ## Add more devices **You do not need one router per machine.** Put one router at the cell and provision every device in range onto it. Split routers when the count or the distance degrades the signal, not by default. The signs are the same as on any Wi-Fi network: one arc on the signal icon at **Devices**, or devices that drop and rejoin through the shift. Read the signal in [Weak signal](/docs/hardware/troubleshoot-offline-device/#signal) before you buy a second router. A device out of range is fixed by moving the router or adding one nearer the machine, not by replacing the device. A new device for a cell that already has a router needs only the range check in [Power and place the router](#place). ## See also - [IoTFlows 4G/LTE router](/docs/hardware/lte-router/) - [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/) - [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/) - [View and manage your devices](/docs/hardware/view-devices/) --- # View and manage your devices Source: https://www.iotflows.com/docs/hardware/view-devices/ The Devices page draws every sensor your organization owns as a topology map: which machine each device is attached to, whether the cloud is hearing from it, and how strong its Wi-Fi signal is. Opening a device shows its firmware, MAC, IP and current SSID, and carries the two tabs that change anything, Calibration and Networks. You do not add, rename or remove hardware here: IoTFlows claims and registers every device before it ships. # View and manage your devices The topology map, per-device detail, and how to tell a healthy device from a struggling one. A *topology map* is a diagram of what each device is attached to and what it reaches, drawn instead of a flat list. It answers two questions at a glance: which machine a sensor reports for, and whether it is reaching the cloud. **Prerequisites.** Signed in. Changing device settings needs the **Owner** or **Administrator** role, see [Roles and permissions](/docs/admin/roles-reference/). ## The topology map Go to **Devices**. The page opens at `/devices?select=management` with three columns: **Asset**, **Sensor**, and **Gateway**. Read a row from left to right: the machine, the sensor attached to it, then the **Cloud** card it reports through. The Cloud card is an endpoint marker rather than a status, so its dot is always green. Clicking an asset card opens that machine's page. The sensor card opens nothing, even though the cursor changes over it. Device settings live behind **Edit Sensor**, see [Open a device](#open). A machine with no sensor attached is listed under the map with a red pulsing marker. Contact IoTFlows to tie your sensors to an asset, see [Get support](/docs/get-started/get-support/). ![The Devices page on the Management tab, under three column headings: Asset, Sensor and Gateway. Five machine cards on the left each link by a curved line to a sensor card, and all five sensor lines converge on a single Cloud card on the right. Every sensor card carries a gray Wi-Fi icon and a green dot. An Edit Sensor button sits at the top right.](/images/hardware/hw-devices-01.webp) *The device topology map: which machine each sensor is attached to, and whether it is reaching the cloud.* ## Read the connectivity indicators Each sensor card carries two indicators: a dot for whether the cloud is hearing from the device, and a Wi-Fi icon for its signal strength. *RSSI* is received signal strength in dBm. It is negative, and closer to zero is stronger. ### Connectivity indicators | Indicator | Means | Do this | |---|---|---| | Green pulsing dot | The device is online and reporting. | Nothing. | | Gray dot | The device is not reaching the cloud. | [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). | | Wi-Fi icon, three arcs | Stronger than -50 dBm. | Nothing. | | Wi-Fi icon, two arcs | Between -50 and -60 dBm. | Nothing, but expect it to drop as the plant fills up. | | Wi-Fi icon, one arc | -60 dBm or weaker. | Move the access point or router closer to the machine. | | Crossed-out Wi-Fi icon | The device is offline, or it is online and reporting no signal figure. | Read the dot beside it to tell those two apart. | Treat one arc as the cause before you treat it as a symptom. A device that drops for minutes at a time on weak signal produces downtime that looks like a machine problem: the machine reports stopped, and the stoppage has no cause anyone can name. ![A single BeamTracker sensor card enlarged. Below the device name and its id sit the card's two indicators: a Wi-Fi icon showing one arc, and a filled green dot.](/images/hardware/hw-devices-02.webp) *The two indicators on a sensor card. This BeamTracker is online, which is the green dot, but it is down to a single arc, and a signal that weak is the thing to treat as a cause.* > **Info:** > **Device offline but the machine is running?** The sensor lost the network, not the machine. The asset card keeps the last state the cloud recorded, so it still reads stopped, and the status bar grays out for the stretch with no data. Gray on the bar is absence of data, not downtime. ## Open a device 1. Go to **Devices**. 2. Click **Edit Sensor** at the top right. 3. Find the device in the **Sensor List** dialog. 4. Click the gear icon on its row. BeamTracker opens its own dialog and the two SenseAi devices share another, but all three carry the same detail panel and the same two tabs. ## Device detail fields The panel across the top of the dialog is read-only. It reports what the device is, what network it is on, and the machine it reports for. | Field | Meaning | Editable | Where it comes from | |---|---|---|---| | **Name** | The device's name. | No | Set by IoTFlows at registration | | **Id** | The device's unique identifier. | No | Set by IoTFlows at registration | | **WiFi SSID** | The network the device is on right now. | No | Reported by the device | | **IP Address** | The device's address on that network. | No | Reported by the device | | **Firmware Version** | The firmware the device is running. | No | IoTFlows pushes updates | | **MAC Address** | The Wi-Fi radio's hardware address. | No | Reported by the device | | **Publish Metrics Interval min(s)** | How often the device sends metrics, in minutes. SenseAi and SenseAi Embedded only. | No | Set by IoTFlows | | **Publish Raw and FFT** | Whether the device also sends raw waveform and frequency data. SenseAi and SenseAi Embedded only. | No | Set by IoTFlows | | **Machine Name** | The machine this device reports for. | Yes, on the asset | You | | **Machine Id** | That machine's identifier. | Yes, on the asset | You | **Firmware Version** decides which health view the machine gets. At firmware 5 or above the asset's **Health** tab shows the advanced machine-health dashboard; below 5 it falls back to the older health view. See [Machine health](/docs/monitoring/machine-health/). ![The detail panel at the top of the Edit Sensor dialog. Left of a product render, a crossed-out Wi-Fi icon and a gray dot sit above the fields Name, Id, WiFi SSID, IP Address and Firmware Version, which reads 3.15. To the right, the attached machine's picture beside Machine Name and Machine Id. The Calibration and Networks tabs sit underneath.](/images/hardware/hw-devices-03.webp) *Device detail, on a sensor that is offline. Firmware below 5, as here, is why a machine has the older health view rather than the machine-health dashboard.* ## Rename a device You cannot. The device **Name** is set when IoTFlows registers the device, and no field on the dashboard or in either mobile app changes it. Contact IoTFlows to have one changed, see [Get support](/docs/get-started/get-support/). What you can rename is the machine. **Machine Name** is editable on the asset itself, and reports, alerts and exports all carry it rather than the sensor's name, so it is almost always the name you meant. See [Add an asset](/docs/monitoring/add-an-asset/). ## Wi-Fi and calibration from here Two tabs sit under the detail panel. They are the only things in this dialog that change anything. **Calibration** tunes what the device reads as running and as stopped, for this one machine. See [Calibrate SenseAi and SenseAi Embedded](/docs/hardware/calibrate-senseai/) and [Calibrate BeamTracker](/docs/hardware/calibrate-beamtracker/). **Networks** moves the device onto a different Wi-Fi network over the connection it already has, with no phone and no trip to the machine. It refuses an offline device, which cannot be told anything over the cloud. See [Manage saved Wi-Fi networks](/docs/hardware/manage-wifi-networks/). You do not need the Networks tab for a device that has never been online. That one takes Bluetooth provisioning from the mobile app, see [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/). There is no bulk action. Credentials are saved for the whole organization but delivered one device at a time, so a site-wide password change costs one pass through this dialog per device. Work down the **Devices** list in one sitting. ## On mobile On iOS, open **Settings** > **Devices**. Each row shows the device name, the machine it reports for, and **Online** or **Offline** beside a green or dark gray light. Tapping through gives the sensitivity and momentum values, the same two the web **Calibration** tab writes. Android lists the same devices with the same **Online** and **Offline** states and no tap-through to settings. Both apps do Bluetooth Wi-Fi provisioning. ![The Device List on the iOS Settings Devices screen. Four rows, each with a sensor icon and a green dot, the device name above the word Online, and the machine name above its department with the machine's photo on the right.](/images/hardware/hw-devices-05.webp) *The native device list on iOS. Android shows the same list read-only.* ## How hardware gets added You do not add hardware here. IoTFlows claims and registers every device before it ships, and ties it to a machine during onboarding. There is no **Add device** button on this page. Contact IoTFlows when you buy a device, move one to a different machine, or need a device name changed, see [Get support](/docs/get-started/get-support/). ## See also - [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/) - [Manage saved Wi-Fi networks](/docs/hardware/manage-wifi-networks/) - [Calibrate SenseAi and SenseAi Embedded](/docs/hardware/calibrate-senseai/) - [Machine health](/docs/monitoring/machine-health/) - [Overview: IoTFlows hardware](/docs/hardware/overview/) --- # Adjust stock and track locations Source: https://www.iotflows.com/docs/inventory/adjust-stock/ Every stock movement in IoTFlows lands at one location and writes one ledger row. This page covers opening the Adjust stock modal from an item's detail, reading Stock by location, the three directions the modal offers (Add, which writes a Receipt; Remove, which writes an Issue; and Set count, which writes an Adjustment for the difference), the note that makes a correction auditable, and the Reserved and Incoming figures that explain why what is on the shelf and what is available to a new job are different numbers. Adjusting stock takes an Owner or Administrator role, and the same adjustment exists on the web, iOS and Android. # Adjust stock and track locations Record a receipt, an issue, or a corrected count, at one location, with a note. --- Stock in IoTFlows is never a single number on an item. It is a quantity of one item at one *location*, which is one node of your location tree: `Main Plant › Storeroom › Shelf B`. Every change to a quantity writes a row in the item's *ledger*, the **Transaction history** at the foot of its detail, so the count and the history can never disagree. Adjusting stock takes an [Owner or Administrator role](/docs/admin/roles-reference/). Every other member can open an item and read its quantities, but the **Adjust** buttons are not rendered for them. You also need an item to adjust: see [Create and edit items](/docs/inventory/manage-items/). ## Open an item's stock 1. Go to the **Items** tab of Inventory, at `/inventory?select=items`. 2. Select the item to open its detail drawer. 3. Scroll to **Stock by location**. 4. Select **Adjust** on the location you are correcting. The modal opens titled **Adjust stock**, followed by the item's name, with that location already selected and its current quantity loaded. Two other buttons open the same modal. **Add a location**, at the top right of the **Stock by location** card, opens it with no location chosen and zero on hand, which is how you stock an item somewhere for the first time. On an item held as individually numbered *pieces*, each piece carries its own **Adjust** button instead, covered on [Track serialized pieces and tools](/docs/inventory/serialized-pieces/). There is no way to adjust stock from the catalog list or from an item card. Stock is adjusted from the item's detail, one location at a time. ## Read Stock by location The **Stock by location** card lists one row per location that holds this item, each with its full breadcrumb path, its own quantity in the item's unit, and its own **Adjust** button. A quantity that has gone below zero is printed in red. The **On hand** figure at the top of the drawer is the sum of those rows. A location with no row holds zero of this item, not an unknown amount, which is why adjusting at a new location starts from zero rather than from the item's total. ![The Stock by location card on an item's detail, showing two location rows with their quantities and Adjust buttons](/images/inventory/inv-stock-01.webp) *Stock by location on one item, with one row per location and an Adjust button on each.* **On mobile.** Inventory ships on iOS and Android with the same stock model. The item detail carries the same per-location rows, and the adjustment sheet offers the same three directions and the same note field. Standing at the shelf with a phone is the common case for a count, so the mobile path matters more on this page than elsewhere. ![An item's stock by location on the iOS app, listing each location with its quantity](/images/inventory/inv-stock-05.webp) *Stock by location in the mobile app. This is the screen a storeroom uses standing at the shelf, which is why the mobile path matters more here than elsewhere.* ## Choose a direction The modal never asks for a signed number. You pick a direction, then a positive quantity, and IoTFlows supplies the sign. | Direction | Quantity you enter | Use when | Transaction recorded | |---|---|---|---| | **Add** | How much arrived | Stock came in from outside a work order: a delivery, a return from a bench, a correction you can name as an arrival | **Receipt** | | **Remove** | How much left | Stock left outside a work order: scrapped at the shelf, sold, consumed by something IoTFlows does not track | **Issue** | | **Set count** | The new counted total | You have physically counted the shelf and the number on screen is wrong | **Adjustment**, for the difference only | All three land at the one location selected in the modal. [Transaction types](/docs/inventory/transaction-types/) lists the other eight types, which are written by work orders rather than by hand. ## Add stock with a receipt A *receipt* is stock arriving. Select **Add**, which is labeled `Stock coming in`. 1. Confirm the **Location** at the top of the modal, or pick another. 2. Enter the amount with the **+** and **−** tiles, or type it into the number field. 3. Write a **Note** saying where it came from, for example `PO 4471, Grainger, 2 boxes`. 4. Select **Apply**. IoTFlows confirms with **Stock updated** and writes a **Receipt** for the amount. The item's detail, its ledger and the catalog counts all refresh. The card under the note field previews the result before you commit it: it reads **New on hand here**, showing the current quantity, an arrow, and the quantity you are about to create, with a green pill carrying the change. Changing the location clears the amount, because an amount counted against one shelf means nothing against another. ![The Adjust stock modal set to Add, with a location, a quantity of 24, a note, and a preview reading 12 to 36](/images/inventory/inv-stock-02.webp) *The Adjust stock modal in Add, with a note saying where the stock came from and the before and after preview beneath it.* ## Remove stock with an issue An *issue* is stock leaving. Select **Remove**, which is labeled `Stock going out`, then enter how much left and apply. IoTFlows writes an **Issue** for that amount. You do not need **Remove** for parts a work order consumes. A work order reserves what it requires and moves the stock when it is completed, and doing both leaves the shelf short twice over. See [How work orders move stock](/docs/inventory/how-work-orders-move-stock/). > **Warning:** > **Removing more than you have is allowed.** The preview turns red and warns `This will drive on hand negative`, and **Apply** stays enabled. A negative count almost always means a receipt was never recorded rather than that the shelf owes you parts, so count the shelf and use **Set count** instead of removing past zero. ## Correct a count with Set count A *set* is a correction to a counted total. Select **Set count**, which is labeled `Correct to a counted total`. The field prefills with what IoTFlows currently believes is at that location. 1. Replace the prefilled figure with the number you counted. 2. Read the preview: it shows the old quantity, the new one, and the difference as a pill reading, for example, `-3 correction`. 3. Write a **Note** naming who counted and when. 4. Select **Apply**. IoTFlows writes an **Adjustment** for the difference, not for the total. Counting 41 where the system held 44 writes a single `-3` row, so the ledger still reconciles to the quantity on the shelf. **Apply** is disabled when the counted total matches what is already there. There is no correction to record, so the modal has nothing to write. Use **set** only after a physical count, and always with a note saying who counted. Receipt and issue tell you what happened; set tells you only that somebody disagreed with the number, and without a note nobody can audit it later. ![The Adjust stock modal set to Set count, with the counted total entered, a note naming the counter, and a correction pill](/images/inventory/inv-stock-03.webp) *Set count after a physical count, with the note naming who counted. The pill beside the new total shows the correction the ledger will record.* ## Write a note The **Note** field is optional to the form and close to mandatory in practice. It is offered in all three directions, and the item's **Transaction history** carries a **Note** column to print what you write, which is the only place a future reader can find out why a number moved. > **Warning:** > **The note is not reaching Transaction history.** Checked on the web app on 2026-09-21: a note typed into **Adjust stock** applies without an error and the quantity moves correctly, but the ledger's **Note** column reads `—` on the new row, and the transaction comes back from the API with no note on it. Keep writing them, since that is the field the product reads back from, and until the column fills in, keep anything you have to be able to audit in a second place as well. Write what the quantity alone cannot say: `Counted by J. Okafor, cycle count week 38` on a set, `PO 4471 short by 6, supplier notified` on a receipt, `Scrapped, bent on unload` on an issue. ![The adjust stock sheet on Android in Set mode, with the counted total and the note field filled in](/images/inventory/inv-stock-06.webp) *Setting a counted quantity on Android. The note is what makes a set auditable later.* ## Pick or create the location **Location** is required on every adjustment, and **Apply** stays disabled until one is chosen. The picker is your location tree: search it with **Find a location**, or expand it and select a node. You can create a location without leaving the modal. Select the **+** beside a node to add one inside it, or **Add a location** at the tree's root for a top-level one, type the name, and confirm. IoTFlows answers **Location created** and selects it. > **Info:** > **Told the location was created but nothing is selected?** The message `Location created, but the response did not identify it. Reopen to see it.` means the location was saved and the modal could not select it. Close the modal, reopen **Adjust**, and pick the new location from the tree. Nothing was lost, and you do not need to create it again. ## Reserved by work orders *Reserved* is how much of an item open work orders are holding. When a work order requires a part, that quantity is netted out of what other jobs can draw on, but it is still physically on the shelf and no transaction has been written. The **Reserved by open work orders** card lists one row per work order, with its number, its status, the location it is holding stock at, and the amount in amber. Select the arrow on a row to open the work order: maintenance work orders open on the Maintenance page, production ones in the scheduler. This is why two numbers that look like they should agree do not. **On hand** is what is on the shelf; **Available** is on hand minus reserved, and it is what a new job can actually take. The item's detail shows **On hand**, and the catalog's list mode carries all four figures side by side, covered in [Create and edit items](/docs/inventory/manage-items/#views). Reorder points are measured against **Available**, so an item can be flagged low while a full shelf sits in the storeroom spoken for. See [Monitor low stock and reorder points](/docs/inventory/low-stock/). ![A tool's Reserved by open work orders card above its Coming back from open work orders card, each listing work orders with a number, a status, a location and a quantity](/images/inventory/inv-stock-04.webp) *Reserved by work orders and incoming from them, which is why on hand and available differ.* ## Incoming from work orders *Incoming* is the mirror of reserved: what open work orders will add to this item. A manufactured part is being produced, and a reusable tool is on its way back to the shelf, so a tool's card is titled **Coming back from open work orders** instead. The total appears under **On hand** as a green `+6 incoming` line, and the card beneath lists the work orders bringing it, each against the location it will land at. Incoming is deliberately not added into **Available**. None of it is on a shelf yet, and a job cannot pull from stock that does not exist. > **Warning:** > **Do not receive incoming stock by hand.** Adding a quantity that a work order is about to create counts it twice: once when you apply the receipt, and again when the work order is completed and writes its own. Let the work order land it, then count the shelf if the number looks wrong. ## When an adjustment fails A failed **Apply** raises the reason IoTFlows gave and saves nothing. The quantity on the shelf is unchanged, no ledger row is written, and the modal stays open with your entries intact, so you can correct and apply again. Some failures return no reason, which renders as an empty message. Treat that the same way: the request failed, the change was not saved, and applying it again is safe. If it keeps failing, see [Get support](/docs/get-started/get-support/). ## See also - [Transaction types](/docs/inventory/transaction-types/) - [Monitor low stock and reorder points](/docs/inventory/low-stock/) - [How work orders move stock](/docs/inventory/how-work-orders-move-stock/) - [Track serialized pieces and tools](/docs/inventory/serialized-pieces/) --- # How work orders move stock Source: https://www.iotflows.com/docs/inventory/how-work-orders-move-stock/ A work order carries two parts lists, Parts Required and Create/Release Parts, and neither one moves anything until the work order closes. Raising it reserves the required lines, which drops what is available to other jobs without changing what is on the shelf. Setting it to Done is what moves the stock: IoTFlows shows a read-only summary of both directions, and the backend then consumes the required lines, produces the created ones, writes the inventory transactions and clears the reservation. This page maps each action to the transaction it creates, explains reserved, incoming and available, and shows where the result lands in the ledger. # How work orders move stock Which work-order action creates which transaction, and where the movement actually happens. A *work order* is one job in Maintain or Production. It carries two parts lists, and closing it is the only thing that moves stock: everything before that is a claim on a shelf, not a withdrawal from it. The movement itself is performed by the IoTFlows backend, not by the browser or the app. You confirm it, the server does it. That is why this page reads the same whether your technicians close jobs on the web, on iOS or on Android, and why no page tells you to correct a count by hand after a job closes. This page explains the model. The procedure for closing a maintenance work order is on [Complete and confirm materials](/docs/maintain/work-order-detail/#complete), and for a production job on [Complete the job](/docs/production/run-a-job/#complete). ## The two bindings An item reaches a work order in one of two ways, and the difference is where it was written down. **On the work order itself.** A work order has a **Parts Required** section and a **Create/Release Parts** section. A line in either one names an item, one location, and a quantity. Adding a line here is a decision about this job and nothing else. **On an operation.** An *operation* is one step in making a part, held on the Parts List and reused by every job that runs it. It carries its own required and created items, and those are *rules* rather than quantities: a rule says how the item scales with the work. Four bolts for every one part, one cutting tube for every 50, or one torque wrench however large the run is. When a job is raised against that operation, IoTFlows scales each rule to the job's quantity and stages the result as work-order lines. A run of 401 parts at one tube per 50, with rounding on, stages nine tubes. Editing the staged lines before you submit is expected, and the rule on the operation does not change. The editor is on [Bind materials to an operation](/docs/production/bind-materials/#require). ### Choose where to bind Bind on the **operation** when the item scales with the work and the operation runs more than once. The rule is written once and every future job inherits it, which is the only way the number a planner sees and the number a job reserves stay the same number. Bind on the **work order** when the draw is specific to this job: the gasket that failed on this pump, the fixture borrowed for one shift. You do not need a binding at all. Inventory works as a standalone catalog and ledger, and stock can be received and issued from the item's own detail. Skip bindings if your work orders rarely touch the storeroom, and accept that closing those jobs will move nothing. ## Reserved versus on hand Raising a work order with a required line **reserves** that quantity. A *reservation* is a claim on stock that is still physically on the shelf: it writes no transaction, and the on-hand count does not move. Diagram: A diagram of one item's four stock figures. A bracket labeled On hand 120 spans a bar split into two boxes, a narrow Reserved 30 and a wide Available 90, captioned 'Spoken for by open work orders' and 'What a new work order can take today'. Set apart to the right behind a gap, with a dashed outline, is a fourth box reading Incoming +40, captioned 'Promised by open work orders that create it. Not on a shelf yet.' A line across the bottom reads: available equals on hand minus reserved, and incoming is counted on its own and never added into available. *On hand splits into reserved and available. Incoming is counted on its own and is never added into available.* Four figures describe one item, and only two of them count what is physically there. | Figure | What it counts | Changes when | |---|---|---| | **On hand** | What is on the shelf right now, summed across locations | A transaction is written | | **Reserved** | The quantity on required lines of open work orders | A line is added, edited or deleted, or the work order closes | | **Available** | On hand minus reserved: what a new job can still take | Either of the two above changes | | **Incoming** | What open work orders that create this item will add | A created line is added, edited or deleted, or the work order closes | *Incoming* is a forecast, not stock. None of it is on a shelf yet, so IoTFlows keeps it out of available on purpose. A job cannot pull from a quantity that does not exist, and an available figure that quietly included it would let two planners commit the same future delivery. ### Where each figure appears The four columns appear together in the **Items** tab in list mode. The item's own detail is different: it shows **On hand**, a green `+40 incoming` line beneath it, and two cards named **Reserved by open work orders** and **Incoming from open work orders** that name the jobs on each side. There is no Available figure on the item detail, so read the list when that is the number you need. Both surfaces are covered on [Adjust stock and track locations](/docs/inventory/adjust-stock/#reserved). Read available, not on hand, before you promise a part to a new job. A storeroom with 120 gaskets on the shelf and 30 already claimed can honor an order for 90, and a reader who looks at the wrong column promises 120. ### Shortages Every required line carries its own availability, already net of that work order's own reservation. A negative value is exactly the amount that location is short by, and the completion summary prints **short 12** in red beside the line. A created line can never be short, because it adds stock rather than taking it. ## What happens on completion Setting a work order's status to **Done** is the moment stock moves. If the work order lists nothing in **Parts Required** and nothing in **Create/Release Parts**, it closes immediately and nothing is written. If either list has lines, a read-only summary appears first: a **Complete work order** dialog in Maintain, and the same summary folded into the session dialog on a production job. Diagram: A two-column diagram. The left column is headed 'On the work order' and holds four boxes; the right column is headed 'When you set it to Done' and holds four boxes, each reached by an arrow from the box beside it. Row one: Parts Required, a consumable, four GSK-3IN gaskets, leads to Stock out, four leave Rack A Bin 3. Row two: Parts Required, a tool, TW-350 torque wrench, leads to Custody out, the tool leaves its shelf. Row three: Create/Release Parts, a part the job makes, leads to Stock in, the quantity lands at the line's location. Row four: Create/Release Parts, the same tool listed back, leads to Custody in, the tool returns to its shelf. A line across the bottom reads: raising the work order reserves, closing it moves, and nothing between the two writes a ledger row. *A required line takes stock out when the work order closes and a created line puts it back. A tool travels the same path, as custody out and custody in.* The summary groups the lines the way the movement reads. **Parts Consumed** is what closing the job deducts, and **Added to Inventory** is what it adds, split into **Produced** and **Tools Returned** when the job does both. A *reusable tool* is an item that comes back rather than being used up: a torque wrench, a fixture, a tube. It appears in the second group because closing the job hands it back, not because the job manufactured one. Selecting **Complete** flips the status. The backend then consumes the required lines, produces the created ones, writes one inventory transaction per line, and clears the reservation. ### Action to transaction | Action | Work order type | Transaction created | Direction | |---|---|---|---| | Add a line to **Parts Required** | Maintain or Production | None. The quantity is reserved | Neither | | Add a line to **Create/Release Parts** | Maintain or Production | None. The quantity becomes incoming | Neither | | Delete a line before closing | Maintain or Production | None. The reservation or forecast clears | Neither | | Close a job that requires a consumable | Maintain or Production | One row per line, at that line's location | Out | | Close a job that requires a tool | Maintain or Production | One row per line: the tool leaves the shelf into the job's custody | Out | | Close a job that creates a part | Production, and Maintain where a job rebuilds something | One row per line, at that line's location | In | | Close a job that creates a tool | Maintain or Production | One row per line: the tool returns to its shelf | In | | Pause a production job | Production | None. A pause moves nothing | Neither | The badge each of these rows prints in the ledger is listed on [Transaction types](/docs/inventory/transaction-types/). Every work-order badge begins **WO**. ### Reconcile before you close, not after The completion summary is read-only, and there is no quantity field on it. It states the consequence of closing and gives you one chance to refuse. So the reconciliation happens on the work order, not in the dialog. If the technician used six gaskets and the line says four, select **Cancel**, correct the line in **Parts Required**, and set the status to **Done** again. Closing on a line you know is wrong is how counts drift, and no later adjustment will say which job the difference belonged to. > **Warning:** > **Reopening a closed work order** > > Nothing in IoTFlows stops a closed work order from being reopened and closed again, and the completion summary appears on every close where the job has parts. Whether the backend writes a second set of transactions on the second close is not confirmed. Until it is, treat a reopen as a reason to check the item's ledger, and prefer [a counted correction](/docs/inventory/adjust-stock/#set) to a second close. ## What happens on a production work order A scheduler task and a Work Queue job are work orders, so everything above applies to them unchanged. Three things are specific to production. **The lines usually arrive prefilled.** Picking an operation in the create modal stages its rules against the quantity you typed, so a planner confirms numbers rather than restating them. A staged line whose shelf cannot be resolved is dropped when the work order is submitted, which is the one way a part you saw in the modal can be missing from the job afterwards. **Created lines are what the scheduler projects output from.** The projected-output curve reads the work order's own created lines. Output is declared, never inferred from the shape of the job, so a job that produces something and does not say so contributes nothing to the forecast. See [What created parts show you on the scheduler](/docs/production/bind-materials/#forecast). **Logging parts made is not a stock movement.** The count you enter during a session records how many good parts the machine produced, and it writes no inventory transaction. Stock arrives only from a created line at close. Compare [Log good parts](/docs/production/run-a-job/#log-parts). A serialized piece adds one more consequence. Each piece is a capacity-1 resource, so two jobs requiring the same physical bar appear as a conflict on the scheduler with nobody writing a rule. See [Violations: piece conflicts](/docs/production/schedule-issues/#pieces). ## Reading the result in the ledger Open **Inventory** and select the **Transactions** tab. Each row is one movement: **Type**, **Item**, **Location**, **Change**, **Note**, **By** and **Date**. A closed work order shows up as one row per part line, carrying a **WO** badge and a signed change. A job that consumed four gaskets and produced one rebuilt pump writes two rows, not one, because each line moved a different item at a different location. The ledger has no work-order column and no work-order filter. To trace a specific job, filter by type, then match on the item, the timestamp of the close, and the person in **By**. The same rows appear under the item's own detail, which is usually the faster route when you already know which part you are asking about. ## When nothing moved **A completion wrote no transaction.** The work order had nothing in either parts list, so it closed immediately with a **Task completed!** toast and no summary. Bind the parts and close it again, or record the movement from the item with [Add stock with a receipt](/docs/inventory/adjust-stock/#receipt). **The close appeared to succeed, then the status came back.** The **Task completed!** toast is shown before the request returns, so a failed close prints it and then the server's own error message, and the board reverts to the previous status. The stock did not move. Try the transition again. **A part you added in the create modal is not on the job.** A staged line with no location is dropped at submit, and a line whose rule has no quantity is never staged at all. Add it back on the work order, with a location, before closing. ## See also - [Transaction types](/docs/inventory/transaction-types/) - [Complete and confirm materials](/docs/maintain/work-order-detail/#complete) - [Bind materials to an operation](/docs/production/bind-materials/) - [Adjust stock and track locations](/docs/inventory/adjust-stock/#reserved) - [Overview: track parts and tools](/docs/inventory/overview/) --- # Monitor low stock and reorder points Source: https://www.iotflows.com/docs/inventory/low-stock/ The Low Stock tab lists every purchased item at or below its reorder point, with the quantity available, the reorder point it fell under, and a suggested order quantity. This page covers opening the tab, the exact rule that puts an item on the list, how an item stocked as pieces is judged, setting a reorder point against your supplier's lead time, and the four things the list leaves out. Viewing is open to every member; changing a reorder point takes an Owner or Administrator role. # Monitor low stock and reorder points What is below its reorder point right now, and what this view leaves out. A *reorder point* is the available quantity at or below which IoTFlows flags an item for ordering. It is a field on the item, counted in the item's own unit, and it defaults to 0, so an item appears here only once you set one. See [Create and edit items](/docs/inventory/manage-items/#fields). Every member can open this tab. Changing a reorder point takes an [Owner or Administrator role](/docs/admin/roles-reference/). ## Open Low Stock 1. Open **Inventory** from the top navigation. 2. Select the **Low Stock** tab. The address bar reads `/inventory?select=low_stock`. The heading carries the number of items on the list. When nothing is low, the tab reads **Everything is above its reorder point.** Each row shows the item's picture, name and SKU, a **Low stock** or **Shortage** pill, and three numbers: - **Available** is on hand minus what open work orders have reserved, explained in [Adjust stock and track locations](/docs/inventory/adjust-stock/#reserved). - **Reorder point** is the level set on the item. - **Suggested order** is the reorder point minus available. Ordering that much puts the item back at its reorder point exactly, with nothing spare. **View item** opens the item in the right-hand drawer, where you adjust stock or change the reorder point without leaving the list. The tab itself carries no search, no sort and no filters. ![The Low Stock tab listing six purchased items, each with an available quantity, a reorder point, a suggested order quantity and a View item button](/images/inventory/inv-low-01.webp) *The Low Stock view. Only purchased items are fetched, so a manufactured item never appears here however low it runs.* **On mobile.** The same list is the **Low** segment of the Inventory screen, beside **Items** and **Transactions**. It reads the rows the catalog already loaded, so the two cannot disagree. ![The Low segment of the Inventory screen on Android, listing purchased items below their reorder point](/images/inventory/inv-low-03.webp) *The Low segment on Android. It is derived from the same rows as the catalog, so the two cannot disagree.* ## How the list is built The tab asks for the purchased items in your organization, then keeps the ones that are short. Three rules decide it: - Available is at or below the reorder point, and the reorder point is above 0. The row reads **Low stock**. - Available is negative, whatever the reorder point says. More is reserved than is on the shelf, and the row reads **Shortage**. - A reorder point of 0 never flags an item. An item with no reorder point reaches this list only by going negative. At or below, not below: an item with 20 available and a reorder point of 20 is on the list. ### What appears here | Segment | Appears | Why | |---|---|---| | Purchased | Yes | The tab fetches purchased items only | | Manufactured | No | Not fetched. You make these rather than order them, so change the item's **Type** to Purchased if it belongs here | | Tools | Yes, with a **Tool** chip | **Tools** is a filter over the types, not a type of its own, and every item created in IoTFlows is purchased. Running out of racks stops a job the same way running out of bolts does | | An item stocked as pieces | Yes, as one row | Judged on how many of its *pieces*, the physical units it is held as, are still free, not on a quantity | | A single piece | No | Pieces are counted under the item they belong to, never listed on their own | An item stocked as pieces holds no stock itself, so its own available is permanently 0 and no restocking could clear it. It is judged on how many of its pieces no open work order is holding, its reorder point counts pieces, and the row carries a **Pieces** chip to say so. See [Track serialized pieces and tools](/docs/inventory/serialized-pieces/). ## Set a reorder point that works 1. Select **View item** on the row, or open the item from the **Items** tab. 2. Select the **Reorder point** field in the item's meta card. 3. Enter the number and save. The field saves on its own, and a failed save reverts it and raises **Could not update item**. Set the reorder point to cover your supplier's lead time at your normal consumption rate, not to a round number. For a nitrile gasket you draw 40 of a week from a supplier who ships in three weeks, that is 120, plus whatever cushion your receiving takes. A round number set without that arithmetic is worse than none. A reorder point of 10 on a part you use twice a year is a permanent alert, and a list nobody finishes reading. ![An item's reorder point field beside its current stock, with an arrow from the stock figure to the reorder point](/images/inventory/inv-low-02.webp) *How an item lands in Low Stock.* ## What Low Stock does not show **Manufactured items.** You do not get a low-stock view for anything you make. Track those from the **Items** tab filtered to **Manufactured**, where list mode carries the same quantity columns. **Stock that is already on order.** Incoming quantities are not netted into available, so an item stays on this list until a receipt lands its stock. A job cannot pull from stock that is not on a shelf yet. **Where the shortage is.** Each row is one organization-wide number. An item can be low overall while one location is full, so open the item and read **Stock by location** before you order. **What the item's own pill says.** The pill on an item's detail is judged against **On hand**, this list against **Available**. A full shelf spoken for by open work orders therefore reads **In stock** on the detail and still appears here. > **Info:** > **The list is empty, but I know something is low.** > Check the item's **Type** first: a part switched to **Manufactured** is not fetched here, however low it runs. Then check its reorder point, since 0 or blank never flags. Both fields are on the item's detail, covered in [Create and edit items](/docs/inventory/manage-items/#fields). ## See also - [Create and edit items](/docs/inventory/manage-items/) - [Adjust stock and track locations](/docs/inventory/adjust-stock/) - [Transaction types](/docs/inventory/transaction-types/) - [How work orders move stock](/docs/inventory/how-work-orders-move-stock/) --- # Create and edit items Source: https://www.iotflows.com/docs/inventory/manage-items/ The Items tab of Inventory is the catalog of everything you stock. This page covers browsing it, the All, Purchased, Manufactured and Tools segments, searching by name or SKU, the card and list modes, creating an item, every field an item carries and whether it can be changed later, marking an item as a reusable tool, and editing or deleting one. Creating and editing items takes an Owner or Administrator role, and the catalog is the same on the web, iOS and Android. # Create and edit items The catalog and every field on an item. An *item* is one line in the catalog: a part you buy, a part you make, or a tool you own. The catalog lives on the **Items** tab of Inventory, at `/inventory?select=items`. Stock, locations and the ledger all hang off items, so this is where a part starts. Creating, editing and deleting items takes an [Owner or Administrator role](/docs/admin/roles-reference/). Every other member can browse, search and open items, but the **Add Item** button is hidden for them and the per-item menu is disabled. If you only need one part set up end to end, the shorter path is [Quickstart: add an item and set its stock](/docs/inventory/quickstart/). ## Browse the catalog Open **Inventory** and stay on the **Items** tab. Each row or card is one item, with its name, its *SKU* (your own code for the part, unique in your catalog), its tool chip if it carries one, and its quantities. The count beside the **Inventory Items** heading is what the current segment and search return, not how many items you own. Pieces are not listed here. A *piece* is one individually tracked physical unit of an item, and it is managed on that item's detail, covered on [Track serialized pieces and tools](/docs/inventory/serialized-pieces/). Select any item to open its detail drawer, where stock by location, per-piece stock, reservations and the item's own fields live. ![The Inventory Items tab in card mode, showing a grid of item cards with the toolbar above them](/images/inventory/inv-items-01.webp) *The Items tab of the Inventory page in card mode, with the segment filter, the search box and the Add Item button in the toolbar.* **On mobile.** The catalog is a tab of its own in the iOS app and sits under **More** on Android. Both carry the same segments, the same search and the same create and adjust actions. Barcode scanning is a mobile-only extra that this documentation does not cover. ![The Inventory item list on Android, showing the segment filter above a list of items](/images/inventory/inv-items-06.webp) *The item catalog on Android, reached from the More tab. It carries the same segments and the same search as the web.* ## The segments The pill above the list narrows the catalog. It holds four segments, and only one is active at a time. The catalog opens on **All**. **Purchased** and **Manufactured** are the item's *type*, which is what it is to you: something you buy in, or something you make. **Tools** is a different axis. A tool is still purchased or manufactured, so **Tools** narrows the list to the items ticked as a *reusable tool*, equipment a job takes and gives back rather than uses up. On a narrow screen the pill becomes a dropdown labeled with the active segment, for example **All types**. | Segment | Contains | Appears in Low Stock | |---|---|---| | **All** | Every purchased and manufactured item, tools included. The default. | Each item follows its own type | | **Purchased** | Items typed Purchased. Everything created on the web starts here. | Yes | | **Manufactured** | Items typed Manufactured. | No | | **Tools** | Items ticked as a reusable tool, whichever type they carry. | Only the purchased ones | Get the type right. Only purchased parts are fetched for the **Low Stock** tab, so a manufactured item never appears there however low it runs. See [Monitor low stock and reorder points](/docs/inventory/low-stock/). ![Close crop of the Inventory segment pill with All, Purchased, Manufactured and Tools, numbered one to three on the last three](/images/inventory/inv-items-02.webp) *The segment filter above the catalog: All, Purchased, Manufactured and Tools. Only purchased items are fetched for the Low Stock tab.* ## Search by name or SKU Type into **Search name or SKU...** under the toolbar. The search runs on the server a fifth of a second after you stop typing, and it matches the item name and the SKU, so `FLT` and `Hydraulic filter` both find `FLT-2004`. Search and the segment combine. Searching `bar` with **Tools** active returns only reusable items matching `bar`, and an empty result reads **No items match your search**. The query is held in the address bar as `?q=`, so a search is a link you can send to someone. Select **×** in the field to clear it. ## Card and list modes The pair of buttons to the right of the segment pill switches between list and card. The catalog opens in list, and your choice is remembered in the browser for the next visit. **List mode** gives every item a row with four quantity columns: **On hand**, **Reserved**, **Incoming** and **Available**. Available is on hand minus what open work orders have reserved, which is the number the reorder point is measured against. [Adjust stock and track locations](/docs/inventory/adjust-stock/) explains where each of the four comes from. **Card mode** shows the item's picture, its stock pill reading **In stock**, **Low stock** or **Shortage**, and **Available** alone. Choose list mode when you are reconciling counts or looking for what is short, because it is the only mode showing reserved and incoming side by side. Choose card mode when you are browsing a catalog you do not know by SKU. A narrow window stacks the list into rows that read like cards. ![The Inventory Items tab in list mode, showing item rows with On hand, Reserved, Incoming and Available columns](/images/inventory/inv-items-05.webp) *The catalog in list mode, which it opens in, with On hand, Reserved, Incoming and Available as columns.* ## Create an item 1. Select **Add Item** in the toolbar. 2. Add an **Item Image**. It is optional, and it is what makes a part recognizable to whoever is sent to fetch it. 3. Enter a **Name**, for example `Hydraulic filter, 10 micron`. 4. Enter a **SKU**, for example `FLT-2004`. 5. Enter a **Description**, optionally. One line, for example `Spin-on, replaces Parker 925039`. 6. Enter a **Unit**. A *unit* is what one of the item is measured in. It is free text, it defaults to `each`, and `box`, `L` and `kg` are all valid. 7. Enter a **Reorder point**, or leave it empty for 0. 8. Leave both checkboxes clear unless the item is a tool or is stocked as pieces. Both are covered below. 9. Select **Add Item**. IoTFlows confirms with **Item added**, or **Tool added** if you ticked the tool box. **Add Item** stays disabled until both **Name** and **SKU** carry text. Submitting an empty one raises **Name and SKU are required**. If the save fails for another reason, the toast carries the reason the server gave and the modal keeps what you typed. ![The Add Item modal with numbered callouts on Name, SKU, Unit and Reorder point](/images/inventory/inv-items-03.webp) *Every field on the Add Item modal. Name and SKU are required, and there is no type control: everything created here starts as Purchased.* ![The New item sheet in the mobile app, with fields for item picture, name, SKU, unit and reorder point above the reusable-tool and stocked-as-pieces toggles](/images/inventory/inv-items-07.webp) *Creating an item in the mobile app. Name and SKU are required here exactly as they are on the web.* ## Item fields The **Add Item** modal offers no type control. Everything created on the web is created as **Purchased**, and a part you make has to be re-typed afterwards on its detail. | Field | Required | Accepts | Effect | Editable later | |---|---|---|---|---| | **Name** | Yes | Text | Identifies the item everywhere it is listed, reserved or ordered | Yes, from **Edit Item** or the name on the item's detail | | **SKU** | Yes | Text, your own code | The second thing search matches, and what the delete dialog quotes back to you | Yes, from **Edit Item** or the SKU on the item's detail | | **Description** | No | Text | Shown on the item's detail. Use it for the cross-reference a buyer needs | Yes, from **Edit Item** or the description on the detail | | **Type** | Not offered on create | `Purchased` or `Manufactured` | Decides the segment it sits in, and whether it is ever fetched for Low Stock | Yes, from the **Type** field on the item's detail only | | **Unit** | No, defaults to `each` | Free text: `each`, `box`, `L`, `kg` | Labels every quantity on the item. Changing it relabels the numbers, it does not convert them | Yes, from **Edit Item** or the **Unit** field on the detail | | **Reorder point** | No, defaults to 0 | A number, in the item's unit | The available quantity at or below which the item is flagged low. 0 is never flagged low | Yes, from **Edit Item** or the **Reorder point** field on the detail | | **Item Image** | No | An image you crop in place | The picture on the item's card | Yes, from **Edit Item** | | **This is a reusable tool** | No | Checkbox | Adds the **Tool** chip, puts the item in the **Tools** segment, and means the quantity comes back when a work order closes | **No.** Set it at creation | | **This item is stocked as pieces** | No | Checkbox | The item holds no stock of its own. Its pieces do, and every count on it is a count of pieces | **No.** Set it at creation | The two checkboxes exclude each other. Ticking the tool box clears the pieces box and disables it, because a tool is already one object that comes back whole, while pieces exist to divide a quantity of material. > **Warning:** > **Can you change the two checkboxes later?** No. Neither the **Edit Item** modal nor the item's detail offers them, so an item created as ordinary material cannot be turned into a tool, and an item created as material cannot be switched to piece tracking. Delete the item and create it again, or [contact IoTFlows](/docs/get-started/get-support/) if it already carries stock history you need. ## Mark an item as a reusable tool Tick **This is a reusable tool** in the **Add Item** modal to create one: a torque wrench, a fixture, a rack, a tube. Mark an item as a reusable tool when it comes back. Tools are checked out and in rather than consumed, which is a different ledger and a different question at the end of the month. A work order reserves a tool exactly as it reserves material, but closing the work order returns the quantity instead of spending it. A tool reads differently across the product. Its list row and card carry a sky **Tool** chip, its modals say **Edit Tool** and **Delete Tool**, and its incoming quantity reads **coming back** rather than **incoming**. Serializing a tool has a scheduler consequence. Each piece is a capacity-1 resource, so two jobs needing the same physical fixture show as a conflict without anyone writing a rule. See [Find and fix problems in the schedule](/docs/production/schedule-issues/). ![Close crop of the Add Item modal showing the This is a reusable tool checkbox ticked, with its helper text below](/images/inventory/inv-items-04.webp) *The reusable tool checkbox on the Add Item modal. A tool is stocked and reserved like any material, but the quantity comes back when the work order closes.* ## Edit or delete an item Two paths edit an item, and they cover different fields. **The Edit Item modal** takes the picture, name, SKU, description, unit and reorder point in one pass. Select the **⋮** menu on an item's row or card, then **Edit Item**, then **Save changes**. IoTFlows confirms with **Item updated**, and clearing the name still raises **Name and SKU are required**. **The item's detail** edits one field at a time. Select the item to open it, then select the name, SKU, description, **Type**, **Unit** or **Reorder point**: each is click-to-edit and saves on its own. A save that fails reverts the field and raises **Could not update item**. Use the detail when you are changing the **Type**, because that is the only place it can be changed. Use **Edit Item** for everything else, since it saves the whole set in one request. To delete, select **Delete Item** in the same **⋮** menu. The dialog names the item and its SKU: the item leaves the catalog and its stock history is retained. Deleting is not undoable here, so an item a work order still reserves is better left in place with its stock set to zero. > **Info:** > **Stock is not edited here.** Neither path changes what is on the shelf. Quantities move only through **Adjust stock** or through a work order, so that every change writes a ledger row. See [Adjust stock and track locations](/docs/inventory/adjust-stock/) and [How work orders move stock](/docs/inventory/how-work-orders-move-stock/). ## See also - [Track serialized pieces and tools](/docs/inventory/serialized-pieces/) - [Adjust stock and track locations](/docs/inventory/adjust-stock/) - [Transaction types](/docs/inventory/transaction-types/) - [Link required and created parts to an operation](/docs/production/bind-materials/) --- # Overview: track parts and tools Source: https://www.iotflows.com/docs/inventory/overview/ Inventory is the IoTFlows storeroom: a catalog of the parts and tools you stock, a count of each one by location, and a ledger of every movement. It runs on the web, iOS and Android. An item is a catalog line, stock is a quantity of one item at one location, a piece is an individually numbered unit of a serialized item, and every change to a count writes a transaction. Maintain and Production hold no stock of their own: a work order reserves what it requires, and closing it moves the stock and writes the ledger rows server-side. # Overview: track parts and tools What Inventory holds, and how Maintain and Production draw on it. Inventory is the IoTFlows storeroom: a catalog of the parts and tools you stock, a count of each one shelf by shelf, and a ledger of every movement. It sits at `//inventory` on the web and ships as a native screen in the iOS and Android apps. Nothing has to be configured before you open it, though creating and editing anything in it takes an [Owner or Administrator role](/docs/admin/roles-reference/). **You do not need Inventory to run Maintain.** Work orders, requests and preventive maintenance all work against an empty catalog. Turn Inventory on when "we were waiting on a part" has become a common reason work orders sit **On Hold**, because a count and a *reorder point*, the level at which an item needs reordering, are what answer that. ## The stock model An *item* is one line in the catalog: a part you buy, a part you make, or a tool you own. *Stock* is a quantity of one item at one place, so an item with 12 in the crib and 4 at the line carries two stock rows and a total of 16. Every change to a count is a *transaction*, a row recording what moved, how much, where and when. Nothing moves stock without writing one, including a correction after a physical count, so the ledger answers "why is this number different from last week". Three figures hang off every item. **On hand** is what is physically there, **reserved** is what open work orders have spoken for, and **available** is on hand minus reserved. Available is the one that answers "can this job start". ## Items, pieces and locations Diagram: A diagram in two parts. Across the top sit two boxes, Work order, from Maintain, and Operation, from Production, with a note to their left reading: Maintain and Production hold no stock of their own, they write to the same ledger. An arrow drops from each box, merges onto one short horizontal line, and points down into the last box of the row below. That row is a left-to-right chain of four boxes joined by arrows. Item: the catalog entry, one row per part or tool, TW-350. Piece: one numbered unit of it, wrench #7, only if serialized. Location: where stock sits, Rack A Bin 3, counted per shelf. Transaction: one row per move, receipt, issue, scrap, transfer. A line across the bottom reads: stock is a quantity of one item, at one location, and every change to it writes a transaction. *Item, piece, location and transaction, and how work orders and operations touch each.* A *location* is a named place stock sits, for example `Rack A, Bin 3` or a service truck. Counts are held per location, so a work order's part line comes off one named shelf rather than off the item in the abstract. A *piece* is one individually numbered unit of an item, for cases where the single unit matters: a calibrated gauge, a fixture, a rebuilt motor. A serialized item becomes a grouping and holds no stock of its own; its pieces hold it. Serializing is optional and most items never need it; see [Track serialized pieces and tools](/docs/inventory/serialized-pieces/). The catalog filters by four segments: **All**, **Purchased**, **Manufactured** and **Tools**. Purchased and manufactured are the two item types. Tools is a second axis rather than a third type: a tool is still purchased or manufactured, and the segment narrows the list to items flagged reusable. ### Object model | Object | Is | Tracked by | Page | |---|---|---|---| | **Item** | One catalog line: a part or a tool | Name, SKU, type, unit, reorder point | [Create and edit items](/docs/inventory/manage-items/) | | **Piece** | One numbered unit of a serialized item | Its own stock, under its parent item | [Track serialized pieces and tools](/docs/inventory/serialized-pieces/) | | **Location** | A named place stock sits | One count per item, per location | [Adjust stock and track locations](/docs/inventory/adjust-stock/) | | **Stock** | A quantity of one item at one location | On hand, reserved, available | [Adjust stock and track locations](/docs/inventory/adjust-stock/) | | **Transaction** | One recorded movement | Type, quantity, location, work order, time | [Transaction types](/docs/inventory/transaction-types/) | ## How work orders draw on stock A work order in Maintain carries two parts lists: what it requires and what it creates. Raising it **reserves** the required lines, so what is available to other jobs drops before anyone has been to the shelf. Moving the work order to **Done** is what moves the stock. IoTFlows shows you the materials to confirm, then performs the movement server-side: it consumes the required lines, produces the created ones, writes the transactions and clears the reservation. Nobody adjusts a count by hand to make this happen. A reusable tool travels the same path with a different meaning. Requiring it takes it into the job's custody, and creating it hands it back to its shelf. The full model is on [How work orders move stock](/docs/inventory/how-work-orders-move-stock/), and the procedure for closing a job is on [Update, discuss, and close a work order](/docs/maintain/work-order-detail/#complete). ## How operations draw on stock In Production, the same two lists are bound one level up, on the operation, so every work order raised against that operation inherits them scaled to the quantity ordered. A binding is a rule, not a transaction: it states how much an item scales with the work, and closing the work order is still what writes the ledger rows. See [Link required and created parts to an operation](/docs/production/bind-materials/). Serialized pieces reach the scheduler as well. Each piece is treated as a capacity-1 resource, so two jobs needing the same physical bar or roll read as a conflict without anyone writing a scheduling rule. See [Find and fix problems in the schedule](/docs/production/schedule-issues/#pieces). ## What Inventory is not **It is not purchasing.** There are no purchase orders, suppliers or vendor prices. [Monitor low stock and reorder points](/docs/inventory/low-stock/) tells you what has fallen under its reorder point; the ordering happens in your own system. **It does not decide reorder points for you.** You set one per item, and it is only as good as the lead time and consumption rate behind it. **It does not hold a bill of materials.** What a job consumes is expressed by binding items to the operation that consumes them, not by a recipe stored on the item. **It is not a second part counter.** Counts of what a machine produced come from its sensor and live in [Production](/docs/production/overview/). Stock changes only when a work order closes or somebody adjusts it, so the two numbers answer different questions and are allowed to differ. ## See it in a plant - [Maintain and Inventory](https://www.iotflows.com/platform/maintain#inventory) — Parts come off the shelf when the work order that used them closes. ## See also - [Quickstart: add an item and set its stock](/docs/inventory/quickstart/) - [How work orders move stock](/docs/inventory/how-work-orders-move-stock/) - [Create and edit items](/docs/inventory/manage-items/) - [Link required and created parts to an operation](/docs/production/bind-materials/) --- # Quickstart: add an item and set its stock Source: https://www.iotflows.com/docs/inventory/quickstart/ Get one part under control in Inventory: create an item with a name and a SKU, set its unit and its type, receive an opening count at a named location, set the reorder point that flags it for ordering, and confirm it in the Low Stock tab. Creating and editing items takes an Owner or Administrator role. Everything created here is live on the web, iOS and Android. # Quickstart: add an item and set its stock One item, one location, one stock level, one reorder point. This is the shortest path through Inventory: create one part, say which shelf it sits on, record how many you have, and set the level at which it needs ordering. The steps are written against the web at `/inventory`, and what you create is live in the iOS and Android apps too. Creating and editing items takes an [Owner or Administrator role](/docs/admin/roles-reference/), and the model behind the words is on [Overview: track parts and tools](/docs/inventory/overview/). **Start with the ten parts your technicians ask for most, not the whole storeroom.** An inventory nobody trusts is worse than none, and trust comes from the counts being right on the parts people actually use. Work through this page for one of those ten, then repeat it nine times. ## Create an item An *item* is one line in the catalog: a part you buy, a part you make, or a tool you own. 1. Open **Inventory** and stay on the **Items** tab. 2. Select **Add Item**. 3. Enter a **Name**, for example `Hydraulic filter, 10 micron`. 4. Enter a **SKU**. A *SKU* is your own code for the part, unique in your catalog, for example `FLT-2004`. Name and SKU are the only required fields: **Add Item** stays disabled until both carry text, and submitting without them raises **Name and SKU are required**. 5. Enter a **Description** and an **Item Image**. Both are optional, and the image is what makes a part recognizable to whoever is sent to fetch it. 6. Select **Add Item**. IoTFlows confirms with **Item added** and the item appears in the list. If the save fails, the toast carries the reason the server gave and the modal keeps what you typed. > **Info:** > **Do you need either checkbox?** Probably not. Tick **This is a reusable tool** only for equipment a job takes and gives back, such as a fixture, which is reserved like anything else but is not used up. Tick **This item is stocked as pieces** only when each physical unit is tracked on its own, such as a bar or a roll; see [Track serialized pieces and tools](/docs/inventory/serialized-pieces/). A plain consumable needs neither. ![The Items tab of the Inventory page with the Add Item button highlighted in the toolbar](/images/inventory/inv-qs-01.webp) *Creating an item.* **On mobile.** The same catalog is a tab of its own in the iOS app and sits under **More** on Android, with the same segments, search, and create and adjust actions. ![The Inventory item list in the mobile app on the Items segment, showing bar stock, filters, bearings and inserts with their on-hand quantities, and a low-stock badge on one row](/images/inventory/inv-qs-05.webp) *The item list in the mobile app, reached from the More tab. On iOS the same list has its own slot in the tab bar.* ## Set its type and unit Two fields decide how the item is counted and where it is listed. **Unit** is what one of it is measured in: `each`, `box`, `L`, `kg`. It is free text, it defaults to `each`, and you set it while creating the item. Every quantity on the item is read in this unit, so changing it later relabels the numbers rather than converting them. **Type** is **Purchased** or **Manufactured**, and everything created on the web starts as **Purchased**: the **Add Item** modal has no type control. To change it, select the item to open its detail, then select the **Type** field, which is click-to-edit. An edit that fails reverts the field and raises **Could not update item**. Get the type right, because only purchased parts are fetched for the **Low Stock** tab. A manufactured item never appears there however low it runs. ![The Type and Unit fields on an item's detail, with numbered callouts on each, Type reading Purchased](/images/inventory/inv-qs-02.webp) *Type and unit. Type decides whether the item ever appears in Low Stock.* ## Receive stock A *receipt* is the transaction that records stock coming in. Stock is held per location, so an opening count means naming the shelf it sits on. 1. Select the item in the list to open its detail. 2. Under **Stock by location**, select **Add a location**. 3. In the **Adjust stock** dialog, pick the location on the map. If your organization has none yet, select **Add your first location** and name what you would walk to, for example `Warehouse › Aisle 3 › Bin 12`. 4. Leave the direction on **Add**, which is **Stock coming in**. 5. Enter the quantity you counted on that shelf, by typing it or stepping it with the **+** and **−** tiles. 6. Enter an optional **Note**, for example `opening count`. It lands on the ledger row. 7. Read the **New on hand here** line, which shows the count before and after, with the change beside it. 8. Select **Apply**. IoTFlows confirms with **Stock updated**. The three directions write three different transactions. **Add** writes a receipt, **Remove** writes an issue, and **Set count** takes the total you physically counted and writes an adjustment for the difference. The rest of the set is on [Transaction types](/docs/inventory/transaction-types/), and the longer procedure is on [Adjust stock and track locations](/docs/inventory/adjust-stock/). ![The Adjust stock dialog in Add mode, with the quantity stepper highlighted and the new on hand total below it](/images/inventory/inv-qs-03.webp) *Receiving stock for the first time.* ![The adjust stock sheet on Android in Add mode, with the quantity field highlighted](/images/inventory/inv-qs-06.webp) *Receiving stock on Android. Add, Remove and Set map to the receipt, issue and adjustment transactions the web records.* ## Set a reorder point A *reorder point* is the available quantity at which an item needs ordering. Select the **Reorder point** field on the item's detail and enter a number in the item's unit. Set it to cover the lead time at your normal rate of consumption. A filter you get through at four a week, from a supplier who takes two weeks, needs a reorder point of at least 8, plus whatever margin that supplier's reliability has earned. An item whose reorder point is 0 is never flagged low. It is still flagged as a shortage if its available quantity goes negative, which happens when open work orders reserve more than is on the shelf. ![The Reorder point field on an item's detail, showing a value in the item's unit](/images/inventory/inv-qs-04.webp) *The reorder point. Set it to cover lead time at your normal consumption rate.* ## Check it in Low Stock Open the **Low Stock** tab. An item is listed when its available quantity is at or below its reorder point, or when available has gone negative. Available is on hand minus what open work orders have reserved, so an item can be listed with parts still on the shelf: 10 in the bin against 6 reserved is 4 available, and a reorder point of 5 flags it. The item you set up above should not be listed, because you received more than its reorder point. To watch the mechanism work, raise the reorder point above what you received, reload, confirm the item appears with an amber **Low stock** pill, then set the reorder point back. What else the view covers is on [Monitor low stock and reorder points](/docs/inventory/low-stock/). ## See also - [Create and edit items](/docs/inventory/manage-items/) - [Adjust stock and track locations](/docs/inventory/adjust-stock/) - [Monitor low stock and reorder points](/docs/inventory/low-stock/) - [How work orders move stock](/docs/inventory/how-work-orders-move-stock/) --- # Track serialized pieces and tools Source: https://www.iotflows.com/docs/inventory/serialized-pieces/ An item stocked as pieces holds no stock of its own: each physical bar, roll, sheet, tube or container is tracked as its own record, with its own id, its own unit, its own amount and the one location it sits at. This page covers deciding when to serialize an item, adding a piece with its opening receipt, reading and adjusting per-piece stock, the capacity-1 conflict a piece raises on the scheduler when two work orders hold it at once, deleting a piece, and why a reusable tool cannot be stocked as pieces. Pieces take an Owner or Administrator role, and they exist on the web, iOS and Android. # Track serialized pieces and tools Track stock as individually identified objects, each with its own size and its own shelf. --- Most stock is a pooled quantity: 40 M8 bolts on Shelf B, and any one of them will do. Some stock is not. A *piece* is one physical object of an item, told apart from every other one: this 6 m bar, that 250 kg roll, this numbered container. An item whose stock is held that way is *serialized*, which the interface calls **stocked as pieces**. Adding, adjusting and deleting pieces takes an [Owner or Administrator role](/docs/admin/roles-reference/). Every other member can read the pieces and their amounts. You also need an item that was created with the pieces box ticked: see [Create and edit items](/docs/inventory/manage-items/). ## When to serialize Serialize when the answer to "where is *that* one" matters, or when each unit holds a different amount. A shop that buys steel in bars needs to know that bar `SB-3` is the one with 1.2 m left on it, not that it owns 14 m of steel spread across four bars nobody can tell apart. Do not serialize consumables. A thousand pieces of the same bolt is a thousand records nobody will maintain, and the pooled count already answers every question you have about them. **You do not need pieces if the units are interchangeable**, however expensive they are. The choice is permanent. **This item is stocked as pieces** is posted only when the item is created, and neither the Edit Item modal nor the item detail renders a control for it. > **Warning:** > **Can this be changed later?** No. An item created as pooled stock can never be re-stocked as pieces, and an item created as pieces can never be pooled. The only way out is to delete the item and create it again, which costs you its stock history. Decide before you create it. ### Item versus piece | | Item | Piece | |---|---|---| | What it is | A catalog line: `Steel Bar, 1045, 50 mm` | One physical object of it: bar `SB-3` | | Identified by | Its name | Its **Piece ID**, stored as the piece's SKU. Every piece carries the parent item's name, so the id is the only thing telling two apart | | Unit | What one piece *is*: `Bars`, `Rolls` | What is *on* this piece: `meters`, `kg`, `ft` | | Holds stock | No. A piece-stocked item never moves stock itself | Yes, at exactly one location | | **On hand** reads | **Pieces on hand**: how many pieces exist, in the item's unit | The amount on this piece, in the piece's unit | | Reorder point | Counts pieces, so "keep 2 bars spare" is the threshold that means something | Not used | | Transaction history | Every piece's ledger merged, with the **Item** column on to say which piece each row belongs to | Its own rows only | The catalog list marks a serialized item with a blue **Pieces** badge, and its **On hand**, **Reserved** and **Available** columns all count pieces rather than material. Pieces are never listed there on their own; they belong to their item. [Low Stock](/docs/inventory/low-stock/) judges a serialized item on how many of its pieces no work order is holding, against the item's reorder point. ## Add a piece with a receipt 1. Open the item from the **Items** tab of Inventory, at `/inventory?select=items`. 2. In the **Pieces** card, select **Add a piece**. 3. Enter a **Piece ID**. IoTFlows suggests the next free `SKU-n`, for example `SB-3`, and skips any suffix already taken. Overwrite it with whatever actually identifies the piece on the floor: a bin tag, a lot number, a heat number. 4. Enter the **Unit** the amount is measured in, for example `meters`. This is the piece's own unit, not the item's. 5. Pick the **Location** where the piece physically sits. A piece is one object, so it gets exactly one. 6. Enter the **Amount** on the piece, using the **+** and **−** tiles or the number field. 7. Select **Add piece**. **Add piece** stays disabled until the id, the unit, the location and an amount above zero are all set. IoTFlows then does two things. It creates the piece as a part in its own right, pointing back at its parent item, and it posts an opening *receipt*, the transaction that records stock arriving, for that amount at that location, noted `Piece added`. A **Piece added** toast confirms both. The item's picture is copied onto the piece so it looks like the material it came from. The piece keeps its own copy, so you can change it later. ![The Add a piece modal for a serialized item, showing the Piece ID, Unit, Location and Amount fields](/images/inventory/inv-piece-01.webp) *The Add a piece modal, with the piece ID, the unit the amount is measured in, the one location the piece sits at, and the opening amount posted as a receipt.* Those are two requests, and the second can fail on its own. When it does, the piece exists with no stock and no location, and IoTFlows says so by name: `Piece SB-3 was created but its stock was not recorded. Set it with Adjust stock.` The piece then appears in the list reading **Not placed**. Fix it with that row's **Adjust** button rather than deleting it and starting again. A failed create raises the reason IoTFlows gave, or `Could not add the piece.` when the response carries none, and nothing is created. The commonest cause is a **Piece ID** already in use. ## Read per-piece stock On a serialized item, the **Pieces** card sits where **Stock by location** would be, because the pieces *are* the stock. Each row carries the **Piece Id**, the **Location** it sits at, and the **Amount** on it in the piece's own unit. ![The Pieces card on an item's detail, listing four pieces with their ids, locations and amounts, each with an Adjust button](/images/inventory/inv-piece-02.webp) *The Pieces card on an item's detail, listing each piece with its id, its location and the amount left on it. On a serialized item this card replaces Stock by location.* Three things you can do from it: - **Select a row** to open that piece as an item of its own, with a blue **Piece** badge and a back button carrying the item's name. Its SKU is editable there; its name is not, since the name belongs to the item. - **Select Adjust** on a row to open the [Adjust stock](/docs/inventory/adjust-stock/) modal against that piece, with its location already selected. This is how you record material consumed off a bar or a roll. - **Select the trash icon** to delete the piece. There is no **Adjust** button on the item itself, and no way to post a transaction against it. Stock lands on a piece or it lands nowhere. The item's **Reserved by open work orders** and **Incoming** cards group by piece too, so you see which specific bar a job is holding rather than a quantity. **On mobile.** Pieces ship on iOS and Android with the same model: the item detail lists its pieces, each piece carries its own amount and location, and adjusting is per piece. Reading a piece id off a tag while standing at the rack is the common case, so the phone matters here. ![An item's pieces on the iOS app, each row showing the piece id and the amount on it](/images/inventory/inv-piece-04.webp) *Per-piece tracking in the mobile app. Each piece carries its own stock and its parent item name.* ## Pieces on the scheduler Serializing has a consequence outside the storeroom. A piece is one object, so it cannot be in two places at once, and IoTFlows treats every piece as a resource of capacity 1 without anyone authoring a rule. When two work orders hold the same piece over overlapping times, the [Schedule issues](/docs/production/schedule-issues/) panel raises a violation naming it: `Piece SB-3 of Steel Bar is held by 2 work orders at the same time. A piece can only be in one place at a time.` Work orders that are not on the board count as holders too, so a maintenance job that took the bar still conflicts with a production job planning to use it. A piece held by one work order, or by none, raises nothing. Pooled stock raises nothing either, whatever the quantity: two jobs each pulling 5 m from a pooled 8 m is a shortage question, not a conflict. **Serialize the materials your jobs fight over**, and this warning arrives for free. ## Delete a piece Select the trash icon on a piece's row and confirm. The dialog is titled **Delete Item** rather than Delete Piece, and names the piece by its id. ![The delete confirmation dialog for a piece, titled Delete Item and naming the piece by its id](/images/inventory/inv-piece-03.webp) *The delete confirmation for a piece. It is titled Delete Item, names the piece by its id, and states that the stock history is retained while the record leaves the catalog.* IoTFlows confirms with **Item deleted**. The piece leaves the item's **Pieces** card and its rows leave the item's merged **Transaction history**, because that history is the union of the pieces that still exist. The piece's own transaction history is retained on the server, but it is no longer reachable from the item. Delete a piece when the physical object is gone: the bar was used up, the container was returned to the supplier. Do not delete one to correct its amount. Use **Adjust** for that, so the correction is a transaction somebody can read later. A failed delete raises the reason IoTFlows gave and changes nothing. If the piece is still listed after the dialog closes, the delete did not happen. ## Pieces and reusable tools A *reusable tool* is equipment a job takes and gives back: a rack, a tube, a basket, a fixture. **A tool cannot be stocked as pieces.** In the Add Item modal, ticking **This is a reusable tool** disables the pieces box and clears it, with the reason stated in place: a tool is already one object that comes back whole, while pieces divide a quantity of material into separately tracked objects. So the two answer different questions, and you pick one: - **To track an individual tool**, create it as its own item and mark it a reusable tool. One item per physical fixture, each with its own name and SKU. A work order that requires it reserves it, and a work order that creates it hands it back. See [Create and edit items](/docs/inventory/manage-items/). - **To track material held in separate physical lots**, stock the item as pieces. One item for the material, one piece per bar, roll or container. Pieces are created as **Purchased** whatever their item's type, and never as tools. That is why a piece's delete dialog says Item, and why pieces never appear under the **Tools** segment of the catalog. ## See also - [Create and edit items](/docs/inventory/manage-items/) - [Adjust stock and track locations](/docs/inventory/adjust-stock/) - [Schedule issues](/docs/production/schedule-issues/) - [How work orders move stock](/docs/inventory/how-work-orders-move-stock/) - [Monitor low stock and reorder points](/docs/inventory/low-stock/) --- # Transaction types Source: https://www.iotflows.com/docs/inventory/transaction-types/ The Transactions tab is the organization's stock ledger: one row per movement, carrying its type, item, location, signed change, note, author and time. This page lists all eleven transaction types with the short badge the ledger prints, the backend's full name, the direction the badge is colored for and what creates each one. It also covers the eight type filters and what each keeps, why the ledger has no work-order column, and why old rows still read Production. # Transaction types Every transaction type the ledger can print, and what creates each one. A *transaction* is one row recording one change to stock: a quantity, an item, a location, a time, and the person who caused it. The *ledger* is every such row for the organization, in one list. On-hand figures are the sum of those rows, so the ledger is the only place a count can be explained. ## The ledger Open **Inventory** and choose the **Transactions** tab, at `/inventory?select=transactions`. The heading reads **Stock Transactions**, followed by the number of rows currently shown. Each row carries seven columns: **Type**, **Item**, **Location**, **Change**, **Note**, **By** and **Date**. **Change** is signed and colored, so `+12` is green and `-4` is red. A zero stays gray, because a transfer or an adjustment that nets out is neither a gain nor a loss. The ledger pages 12 rows at a time. Where a movement came from a work order, the **Note** is where it says so: an automatic note reads `Auto-generated upon completion of Work Order: #237`. Notes are clamped to two lines, with the full text on hover. > **Warning:** > **Tracing one work order.** The ledger has no work-order column, no work-order filter and no link back to the job. Filter by type, then match on the item, the timestamp and the name in **By**. An organization with no movements shows **No stock transactions yet.** For one item's history instead of the whole organization, open the item and read **Transaction history** at the bottom of the drawer; on an item stocked as [pieces](/docs/inventory/serialized-pieces/#when), individually numbered units of the same part, that list merges every piece and keeps the **Item** column to say which one moved. **On mobile.** The ledger is the **Transactions** segment of the Inventory screen on iOS and Android, with the same type filters. Rows stack rather than forming columns, which is what the web does too in the item drawer and in a narrow window. ![The Transactions segment of the Inventory screen in the mobile app, showing stacked ledger entries grouped by day, each with a type badge, location, timestamp and a signed change](/images/inventory/inv-txn-02.webp) *The transactions ledger in the mobile app, carrying the same typed filters as the web.* ## Transaction types Every row wears a badge in the **Type** column. The label is short so it fits a fixed-width column; hover it to read the backend's full name, so **WO Checkout** is **Work Order Checkout**. A badge beginning **WO** was written by a work order rather than by a person. The badge's color is its *direction*, not its type: four tones carry all eleven badges, so you can scan the column for what came in, what left, and what only moved. Diagram: A legend of eleven transaction badges in four columns, one column per direction. In, described as stock the organization did not have before: Receipt, WO Receipt, WO Return, WO Check-In, and a dashed Production. Out, described as stock that left the shelf: Issue, WO Issue, WO Checkout. Loss, described as gone, and the row a supervisor hunts for: Scrap. Neutral, described as the same total, moved or corrected: Transfer, Adjustment. A line across the bottom reads: four tones carry eleven badges, the color follows the direction rather than the type, and Production, dashed, is legacy. *The 11 transaction types grouped by direction: in, out, loss and neutral.* | Badge | Full name | Direction | Created by | Notes | |---|---|---|---|---| | **Receipt** | Receipt | In | **Add** on an item's stock adjustment, and the starting count on a new piece | The stock-in you write by hand. See [Add stock with a receipt](/docs/inventory/adjust-stock/#receipt) | | **WO Receipt** | Work Order Receipt | In | The server, on a work-order close | Stock a job made, arriving at that line's location | | **WO Return** | Work Order Return | In | The server, on a work-order close | Stock that went out against a job and came back | | **WO Check-In** | Work Order Check-In | In | The server, on a work-order close | A tool returning from a job's custody. Nothing was bought | | **Issue** | Issue | Out | **Remove** on an item's stock adjustment | The stock-out you write by hand | | **WO Issue** | Workorder Issue | Out | The server, on a work-order close | A job consuming a required line. The full name is the backend's own wording, without the space | | **WO Checkout** | Work Order Checkout | Out | The server, on a work-order close | A tool leaving the shelf into a job's custody. The count drops with nothing used up | | **Scrap** | Scrap | Loss | The server. No web control writes one | Stock leaves like an issue, but it gets the ledger's one flag color because it is the row a supervisor hunts for | | **Transfer** | Transfer | Neutral | The server. No web control writes one | Stock changing location. The organization's total does not move | | **Adjustment** | Adjustment | Neutral | **Set count** on an item's stock adjustment | A counted correction, up or down. See [Correct a count with Set count](/docs/inventory/adjust-stock/#set) | | **Production** | Production | In | Nothing new. See [Legacy types](#legacy) | Old rows only | Three types are the only ones a person writes directly, and all three come from the same control: **Add**, **Remove** and **Set count** on [Adjust stock and track locations](/docs/inventory/adjust-stock/#directions). Everything else is written by the server when a work order closes, which is covered on [How work orders move stock](/docs/inventory/how-work-orders-move-stock/#completion). > **Info:** > **Which badge does a close write?** IoTFlows sets that server-side, and no client screen names the pairing, so read the badge on the row rather than predicting it from the parts list. What each close moves, and in which direction, is on [What happens on completion](/docs/inventory/how-work-orders-move-stock/#completion). Logging scrap against a production job is a different record. It reaches the job, the schedule and historical production, and writes no ledger row. See [Where scrap appears](/docs/production/log-scrap/#where). You do not need the ledger to answer "how many are on the shelf". That figure is **On hand** on the item itself, and the ledger only tells you how it got there. Open the ledger when a count is wrong, when you want to know who moved something, or when you are reconciling a month. ## Filter by type Eight chips sit beside the heading, one at a time. Eleven types would be eleven buttons, so the chips group them by the question people actually ask. | Chip | Keeps | |---|---| | **All** | Every row, including a type this version does not recognize | | **Receipts** | Receipt, WO Receipt, and legacy Production | | **Issues** | Issue, WO Issue | | **Returns** | WO Return | | **Tooling** | WO Checkout, WO Check-In | | **Transfers** | Transfer | | **Adjustments** | Adjustment | | **Scrap** | Scrap | **Tooling** holds both halves of custody, out and back, rather than filing the check-in under receipts. That is the filter to use for the question "where is the torque wrench", since the two rows for one tool sit together. Choosing a chip filters the rows already loaded, updates the count next to the heading and returns you to page 1. Below a tablet width the chips collapse into a dropdown showing the selected filter, which is also what the mobile apps show. ## Legacy types **Production** is a legacy type. The backend used to write it for anything a job produced, then split that into the work-order types above. New rows use those; old rows keep **Production** so a historical ledger still reads correctly. It is toned as stock in, and the **Receipts** chip keeps it, so a receipts filter over a long window returns both the old rows and the new ones. A type the client has never seen prints as a gray badge carrying whatever the server called it, so a new backend type is readable the day it ships. It matches no chip, though: until the client learns it, it appears under **All** only. ## See also - [How work orders move stock](/docs/inventory/how-work-orders-move-stock/) - [Adjust stock and track locations](/docs/inventory/adjust-stock/#directions) - [Track serialized pieces and tools](/docs/inventory/serialized-pieces/#stock) - [Create and edit items](/docs/inventory/manage-items/) - [Bind materials to an operation](/docs/production/bind-materials/) --- # Give people access to Maintain Source: https://www.iotflows.com/docs/maintain/board-members/ Board membership decides who can be assigned a maintenance work order. Your organization has one maintenance board, and you add people to it as named members or as whole teams from the Invite to Maintain dialog in the control bar above the board. The dialog writes as you click, with no Save step: one click adds a person or a team, a crown marks a board owner, and a trash icon removes access. Android carries the same membership list; iOS does not have this surface. # Give people access to Maintain Add technicians and supervisors to the Maintain board, and decide who owns it. A *board* is the shared container behind a work-order surface. Your organization has one maintenance board, and it sits behind the **Maintain** nav entry. Board membership is what fills the **Assignee** list on a maintenance work order, so a person who is not on the board cannot be given a job. You add either a *member*, one named person, or a team. Adding a team adds everyone in it, both the people in it today and anyone added to it later. **Invite the whole maintenance team, not just the planners.** A technician nobody can assign work to gets told by radio instead, and the board stops being the record of what was done. **Before you start** - Board owner. The dialog is not role-gated in the dashboard, so anyone who can open the board can open it and change who is on it. See [Board roles](/docs/admin/roles-reference/#boards). - A team has to exist before you can add it. See [Create a team](/docs/admin/teams/#create). ## 1. Open Invite to Maintain 1. Select **Maintain** in the top navigation. The board opens at `//maintenance`. See [Open the board](/docs/maintain/maintenance-board/#open). 2. Press **Invite** in the control bar above the board, between the status filter and the blue create button. It carries a stack of the current members' avatars, and on windows narrower than about 1280 px the word **Invite** drops and only the avatars remain. The dialog is headed **Invite to Maintain**. There is one maintenance board per organization, so there is no board to choose first. ![The Invite to Maintain dialog. A search field at the top reads Who would you like to add?, and under it a line with a building icon reads Anyone in your organization can access this board. Below that a TEAMS heading with a count of 1 lists the Maintenance team, with its handle, a stack of its member avatars, a dashed plus button, a filled blue crown, and a trash icon. Under it a MEMBERS heading with a count of 4 lists four people, each with their name, username, a crown and a trash icon; all four member crowns are outlined, so the team is the board's only owner.](/images/maintain/mnt-members-01.webp) *The Invite to Maintain dialog, with one team and four named members on the maintenance board. Invite the whole maintenance team, not just the planners.* There is a second way in, for the moment you notice the person you want is missing from the assignee list. In **New Maintenance Workorder**, open the **Assignee** field and press **Manage board members** at the foot of the list. The same dialog opens, headed **Invite to this board**. ## 2. Invite a member 1. Click the search field, **Who would you like to add?**. The list opens with every team in your organization under **Teams**, then every person under **Users**. 2. Type to filter. Full names, team names, handles, usernames and email addresses all match. 3. Click the person. The dialog writes as you click, so there is no Save button. A toast reads `User has been added to your board`, and the person appears under **Members**. People outside your organization are not listed here. To give a contractor maintenance work, add them to the organization first. See [Invite people to your organization](/docs/admin/invite-members/#email). ## 3. Invite a team Open the same search field and click a team under **Teams**. The toast reads `Team has been added to your board`, and the team appears in the **Teams** section above **Members**. Each team row carries its members as a stack of up to three avatars, or the text `0 members` when the team is empty. **Check that count before you rely on the team.** An empty team sits on the board but puts nobody in the assignee list, so a work order assigned to **2nd shift maintenance** has nobody to give it to. To fill it without leaving the board, press the dashed **+** on its row. A panel headed **Manage** plus the team's name opens, listing who is already **In team** and offering everyone else under **Add people**. This writes to the team itself, so a person you add here joins that team everywhere it is used, not only on this board. ## 4. Owners A *board owner* is a member marked as responsible for the board. Click the crown on a member's or a team's row to set it. The crown fills blue, its tooltip changes from **Mark as board owner** to **Board owner · click to remove**, and clicking it again takes ownership away. There is no confirmation step and no success toast; the crown filling in is the confirmation. Teams hold ownership on the same terms as people. ### Board roles | Role | Can view | Can edit work orders | Can manage members | |---|---|---|---| | Member | Yes | Yes | No | | Owner | Yes | Yes | Yes | > **Warning:** > **Does the dashboard enforce this?** > > Not today. The **Invite** control, the crown and the trash icon render for everyone who can open Maintain, and the dialog's own line reads **Anyone in your organization can access this board**. > > Treat Owner as a record of who is responsible for the board rather than as a lock. Organization roles are a separate system and do gate features. See [Roles and permissions](/docs/admin/roles-reference/). **You do not need to add someone so they can read the board.** In the dashboard today, membership's one effect is the assignee list: it decides who can be given a work order, not who can open Maintain. Adding every operator who glances at the Kanban lengthens the assignee list without changing what anyone can see. ## 5. Remove access Press the trash icon on the row. The row disappears at once, with no confirmation step, and a toast reads `User has been removed from board` or `Team has been removed from board`. Check what that person still has open before you press it. The dialog writes board membership and nothing else, so it does not reassign their work orders. Hand those over from the work-order drawer first. See [Update, discuss, and close a work order](/docs/maintain/work-order-detail/). Removing a team takes that team's access away from this board only. The team itself and the people in it are untouched, and anyone who is also on the board under their own name keeps their access. To take a person out of a team rather than off the board, press the dashed **+** on the team's row and remove them under **In team**. ## 6. On Android Android carries the same membership list. Open **Maintain**, then press the avatar stack in the header above the board; the list opens as a sheet with the same **Teams** and **Members** sections, the same crown, and the same trash icon. **iOS does not have this surface.** On an iPhone or iPad, change board membership on the web at `//maintenance`. Everything else on the board, including assigning a work order to someone already on it, works on both phones. See [On mobile](/docs/maintain/maintenance-board/#mobile). ![Board membership on an Android phone, filling the screen. A search field at the top reads Who would you like to add?, with a TEAMS heading and one team row below it, then a MEMBERS heading and four people, each row carrying an avatar, a name, a username, a crown and a trash icon.](/images/maintain/mnt-members-02.webp) *Board membership on Android: the same one team and four members as the web dialog, listed under Teams and Members headings in a full-height sheet.* ## 7. If a change does not stick Every action here is optimistic: the row updates first and the request follows. When the request fails, the row goes back to what it was and a toast names what failed, so a change that draws and then reverts a second later has not been saved. | Toast | What it means | |---|---| | `Failed to update owner` | The ownership change did not reach IoTFlows. The crown reverts to its previous state. | | `Failed to remove` | The member or team is still on the board, or the person is still in the team. | | `Failed to add` | The person was not added to the team. The team's member count is unchanged. | A success is equally quiet, and worth learning so you can tell the two apart: `User has been added to your board`, `Team has been added to your board`, `User has been removed from board`, `Team has been removed from board`, and `Added to {team}` or `Removed from {team}` for the team panel. The crown has no toast at all. ## See also - [Create and manage teams](/docs/admin/teams/) - [Give people access to a scheduler board](/docs/production/scheduler-members/) - [Roles and permissions](/docs/admin/roles-reference/) - [Organize work on the maintenance board](/docs/maintain/maintenance-board/) - [Create a maintenance work order](/docs/maintain/create-a-work-order/) --- # Create a maintenance work order Source: https://www.iotflows.com/docs/maintain/create-a-work-order/ The New Maintenance Workorder modal carries every field a work order can hold: title, description, group, priority, asset, one assignee, due date, recurrence, time estimate, notes, required and created parts, images and files. Only a title and a group are required, and Create stays disabled until both exist. Everything else is optional at create time and editable afterwards from the work-order drawer. # Create a maintenance work order A fully specified work order: who, what machine, when, and with which parts. The **New Maintenance Workorder** modal holds every field a work order can carry. Two are required, a title and a group. The rest are chips along the bottom of the modal, all optional now and all editable later in the [work-order drawer](/docs/maintain/work-order-detail/). This page goes through them in the order the modal presents them. For the shortest path through this modal, see [Quickstart: create and close your first work order](/docs/maintain/quickstart/). For reporting a problem from the floor instead of planning the work, see [Submit a maintenance request](/docs/maintain/submit-a-request/). ## 1. Open the create form 1. On the web, select **Maintain** in the top navigation. The board opens at `//maintenance`. 2. Select the blue **+** above the board. The modal opens with the cursor already in the title field. Two shortcuts reach the same modal. In the **Calendar** view, drag across the days the job should run and the modal opens with the due date, the due time and the time estimate already filled from what you dragged. On a phone, **Create maintenance order** on the maintenance screen opens it unchanged. ![The New Maintenance Workorder modal, with a title field, a description area, a wrapped row of chips reading Group, Priority, Due Date, Asset, Assignee, Estimate, Notes, Required Parts, Create/Release Parts, Images and Files, and a grayed-out Create button at the bottom right](/images/maintain/mnt-create-01.webp) *The New Maintenance Workorder modal: a title field and a description at the top, and below them the row of property chips that carries every other field, ending in the Create button.* Each chip shows its label until it holds a value, then shows the value. Nothing is written until you select **Create**, so closing the modal discards the whole form, including any group you created inside it. ## 2. Title and description Type the problem into **Work order title**. Write what is wrong rather than what to do, so the technician can judge it: `Spindle coolant leak at the rear seal` tells them more than `Fix the mill`. The title is what the board, the Kanban card and every notification show. The description below it is rich text with no toolbar. Bold, italic, underline, strikethrough and lists survive from keyboard shortcuts and from pasted text. Use it for what the operator saw, what has already been tried, and anything a technician needs before walking to the machine. ## 3. Group A *group* is a named, colored bucket for the kind of work, for example `Electrical` or `Weekly PMs`. It is required: **Create** stays grayed out until the work order has one, and a new organization starts with none. 1. Select the **Group** chip. 2. Pick a group from the list, or type into **Search groups...** to narrow it. 3. To make a new one, select **Add group**, pick a color from the swatch, type into **Group name...**, and select **Create Group**. Enter or Tab creates it too. The new group is saved to the board immediately, selected on this work order, and available to every later one. ![The Group dropdown open over the modal, listing the board's colored groups above an Add group row expanded into a color swatch, a Group name field holding Weekly PMs, and a Create Group button, with the expanded row outlined](/images/maintain/mnt-create-02.webp) *Groups, created inline with a color. Use them for the kind of work, not the department.* **Use groups for the kind of work, not the department that does it**: Electrical, Hydraulics, Safety. Groups drive the board's color and its grouping, and a board grouped by department just reproduces your org chart. See [Organize work on the maintenance board](/docs/maintain/maintenance-board/). ## 4. Priority A *priority* is a single-choice label that sorts and colors the work order on the board. The list comes from IoTFlows rather than from your organization, so you pick from it rather than editing it. Select the **Priority** chip and pick one from the row. The first entry is the default and means no priority, and the chip stays blank while it is selected. The **Due Date** chip sits directly beside it, and a **Recurrence** chip joins the row as soon as a due date exists. ![A cropped detail of the chip row with the Priority chip showing a colored flag and a priority name, and the Due Date chip showing a date and a time, numbered one and two](/images/maintain/mnt-create-03.webp) *Priority and due date. Recurrence needs a due date to anchor to.* ## 5. Asset Select the **Asset** chip and pick the machine the work is on. **Search assets...** matches both the machine name and its identifier, so `CNC-04` finds it as readily as `Haas VF-2`. **Clear asset** at the bottom of the dropdown removes it again. A work order with no asset is still valid, but it never appears in any machine's maintenance history, which is most of the reason to file it in IoTFlows rather than on paper. ## 6. Assignees An *assignee* is the person or team responsible for the work. **Search people or teams...** lists both; team rows show how many members they hold. The create form takes exactly one assignee. If the job needs several, pick the person who owns the outcome here and add the rest afterwards, on [Update, discuss, and close a work order](/docs/maintain/work-order-detail/). **Manage board members** at the bottom of the dropdown opens the board's member list if the person you want is missing from it. See [Give people access to Maintain](/docs/maintain/board-members/). ![The Assignee dropdown open over the modal, listing people with avatars and usernames and teams with member counts, one row selected, and a Manage board members button at the bottom](/images/maintain/mnt-create-04.webp) *The assignee picker, open over the board's people and teams, with one person selected.* ## 7. Due date Select the **Due Date** chip, then pick a date and, if it matters, a time. Leaving the time empty saves the work order as due at 09:00. Once a date is set, a timezone selector appears under it: **Local Timezone**, **Organization Timezone** or **Custom Timezone**. Local is the timezone of the browser you are typing in, which is the wrong one if you are planning work for a plant in another region. **Clear date** removes the date, the time and any recurrence built on it. ## 8. Recurrence The **Recurrence** chip only appears once the work order has a due date, because the series is anchored to it: the due date is the first occurrence, and everything after it is counted from there. Select the chip and pick a preset: **Daily**, **Weekly on** that weekday, **Every Weekday (Monday to Friday)**, **Monthly on** that weekday of the month, or **Annually on** that date. **Custom** opens interval, weekday and end-date controls for anything else, and the series can be given an end date that uses the same time as the due date. A work order with a recurrence rule is a preventive maintenance schedule. There is no separate object for one. See [Schedule preventive maintenance](/docs/maintain/preventive-maintenance/). ## 9. Time estimate An *estimate* is how long the work should take, stored in minutes and shown in the board's Table view and its CSV export. The field takes free text: `2h 30m`, `1d 3h`, `90m` and `1.5d` all parse, and a bare number is read as minutes. The parsed value is echoed under the field as `= 2 hrs 30 mins`. Text it cannot read shows a red **Invalid format**, and a work order created with that text in the field saves with no estimate at all. **You do not need an estimate on a reactive work order.** Estimates earn their keep on planned and recurring work, where they feed the schedule. Guessing at one for a breakdown nobody has looked at yet only adds a number that will be wrong. ## 10. Notes The **Notes** chip is a plain-text field, separate from the description and shown in its own row in the drawer. Use it for what surrounds the job rather than the job itself: a purchase order number, a gate code, the fact that the machine can only be taken down on a Sunday. ## 11. Required and created parts Two chips bind stock to the work order. **Required Parts** is what the job consumes. **Create/Release Parts** is what it produces, or the tool it hands back when it is finished. Each line is a part, a location and a quantity. Search the catalog, pick the location to take from (or to put into), and adjust the quantity, which starts at one or at whatever the location suggests. The required side opens on purchased parts, since maintenance usually consumes bought stock; the create side opens on everything, because a job as often returns a tool as makes a part. ![The Required Parts panel with two staged lines showing part name, SKU, a location breadcrumb and a quantity box, above an inline part search](/images/maintain/mnt-create-05.webp) *The Required Parts panel with two staged lines, each showing its part, the location it comes from, and a quantity.* > **Warning:** > **Why did a part I added not appear on the work order?** > > A line with no location is dropped when the work order is created, and so is a line whose quantity is zero. The panel marks the first case in amber, `Set a location, or this part is not reserved`. Fix both before you select **Create**: a dropped line reserves nothing and the work order shows no sign it was ever there. Nothing moves in Inventory at create time. The stock is deducted and added when somebody moves the work order to **Done**, after they confirm the amounts. See [How work orders move stock](/docs/inventory/how-work-orders-move-stock/). **Most maintenance work orders leave Create/Release Parts empty.** Fill it in when the job returns a tool to the crib or rebuilds a part that goes back on the shelf, not when it only fixes a machine. ## 12. Images and files The **Images** chip takes JPEG, PNG, GIF, WebP, BMP and SVG, by drag and drop or by selecting the tile. Each image is converted to WebP and capped at 1600 px on its long edge before it uploads, so a phone photograph does not arrive as a 6 MB file. On a phone, **Take photo** opens the camera straight into the form. Anything the chip rejects names itself in a toast, ` is not a valid image`. The **Files** chip takes any file type, unconverted: a PDF of the manual page, a wiring diagram, a quote. Both upload as you add them rather than at **Create**, so a failure shows up immediately as `Failed to upload `, and both preview under the description where you can remove one before submitting. ![The create modal with an image thumbnail and a PDF chip named press-04-pump-curve previewing under the description, and the Images and Files chips each showing a count of one](/images/maintain/mnt-create-06.webp) *One photograph and one PDF attached to a work order, previewed under the description.* ## 13. Create Select **Create**. The button stays grayed out until the work order has both a title and a group, and Cmd+Enter (Ctrl+Enter on Windows) submits without reaching for it. A green **Maintenance workorder created** confirms it and the card appears on the board. A red **Failed to create workorder** means nothing was saved; the modal stays open with everything you typed, so correct what you can and select **Create** again. ## Create fields | Field | Required | Accepts | Editable later | In CSV export | |---|---|---|---|---| | Title | Yes | Plain text | Yes | Yes, as **Title** | | Description | No | Rich text | Yes | Yes, with formatting stripped | | Group | Yes | One group from the board, or a new one created inline | Yes | Yes, as **Group** | | Priority | No | One entry from the IoTFlows priority list | Yes | Yes, as **Priority** | | Asset | No | One machine in the organization | Yes | Yes, as **Asset** | | Assignee | No | One person or one team | Yes, and more than one | Yes, as **Assigned To** | | Due date | No | A date, an optional time, and a timezone | Yes | Yes, as **Due Date** | | Recurrence | No | A preset or a custom rule, with an optional end date | Yes | Yes, as **Recurrence** | | Time estimate | No | Free text such as `2h 30m`, stored in minutes | Yes | Yes, as **Estimated Time (min)** | | Notes | No | Plain text | Yes | Yes, as **Notes** | | Required parts | No | Part, location and quantity per line | Yes | No | | Create/Release parts | No | Part, location and quantity per line | Yes | No | | Images | No | JPEG, PNG, GIF, WebP, BMP, SVG | Yes | No | | Files | No | Any file type | Yes | No | The export carries the columns the **Table** view is showing at the time, so a field is missing from the CSV if its column is switched off. See [Exports reference](/docs/monitoring/exports-reference/). ## See also - [Schedule preventive maintenance](/docs/maintain/preventive-maintenance/) - [Update, discuss, and close a work order](/docs/maintain/work-order-detail/) - [Work order fields and statuses](/docs/maintain/work-order-fields/) - [How work orders move stock](/docs/inventory/how-work-orders-move-stock/) --- # Organize work on the maintenance board Source: https://www.iotflows.com/docs/maintain/maintenance-board/ The maintenance board at //maintenance shows one organization's whole maintenance backlog in four views: List, Table, Kanban, and Calendar. Every view reads the same work orders and can be grouped by asset, by group, or by the person assigned. A scope toggle, a status filter with its own time window, a machine filter, a group filter, and a search box narrow what all four show, and the Table view exports the result as a 15-column CSV. # Organize work on the maintenance board Four views of the same backlog, and how to shape one you can run a shift from. The maintenance board is every maintenance work order in your organization on one screen. The four views do not hold different work: they draw the same list as a column, a table, a set of lanes, or a month, and the grouping, filters, and scope you set apply to all of them. For what happens once you select a work order, see [Update, discuss, and close a work order](/docs/maintain/work-order-detail/). ## 1. Open the board 1. Select **Maintain** in the top navigation. The board opens at `//maintenance`. 2. Select any card or row to open that work order in the drawer on the right. There is one maintenance board per organization and no board picker. Every maintenance work order is here, whatever created it. ![The maintenance board in List view: a control bar holding a My Work and All toggle, a Machines filter, a pill with List, Table, Kanban and Calendar, a grouping pill reading Asset, a density button, a magnifier, a status filter reading Active, an Invite to Maintain button and a blue create button, above work orders listed in sections headed by machine name](/images/maintain/mnt-board-01.webp) *The maintenance board in List view, with the control bar above it: the My Work and All scope toggle, the Machines filter, the view pill, the grouping pill, and the status filter, Invite to Maintain, and create controls on the right.* The board updates live: a technician moving a work order to **In Progress** on a phone changes the card on your screen without a refresh. It remembers the view and grouping you left it in, but in this browser rather than on your account, so a second computer starts at List grouped by asset. ### Board views | View | Best for | Grouping | Drag | Client | |---|---|---|---|---| | **List** | Working down a backlog one work order at a time | Asset, Group, People, None | No | Web, iOS, Android | | **Table** | Bulk-checking due dates, and exporting | Asset, Group, People, None | Column headers reorder; rows stay put | Web. On a phone this view is **Card** | | **Kanban** | The daily standup, and re-filing work in bulk | Asset, Group, People, None | Yes, between columns. Sets the field the columns are built from | Web, iOS, Android | | **Calendar** | The weekly plan | Ignores grouping | Yes, sets the due date | Web, iOS, Android | Run the daily standup from **Kanban** grouped by people, and the weekly plan from **Calendar**. **Table** is for exporting and for checking a hundred due dates at once, not for reading. ## 2. List view List puts the backlog in one scrollable column, split into sections by the current grouping. Select a row and the list narrows to a 450 px column while the work order opens beside it. Nothing drags in List. To move a work order to another machine, group, or person, open it and change the field, or switch to Kanban. Choose List when one person is working through their own queue, and Kanban when you are looking at everybody's. ## 3. Table view Table is one row per work order, under the same section headings as List. It shows more fields at once than any other view, and is the only one you can export. Four columns are always on: **WO #**, **Title**, **Assigned To**, and **Asset**. Six more are on out of the box: **Group**, **Status**, **Priority**, **Due Date**, **Recurrence**, and **Last Updated**. Five are off: **Description**, **Estimated Time (min)**, **Requested By**, **Notes**, and **Created At**. That is 15 columns in all, and [Work order fields](/docs/maintain/work-order-fields/) describes what each one holds. Open the column picker at the end of the header row to turn a column on or off, drag a header sideways to reorder, and use **Reset to Default Order** to put them back. Both choices live in this browser, so a colleague sees their own columns, and the export in §10 follows yours. ![Table view of the maintenance board showing rows of work orders under machine-name section headings, with columns for WO number, Title, Assigned To, Asset, Group, Status, Priority and Due Date, the later columns running off the right edge, an Add Workorder link under each section, and a CSV button in the control bar](/images/maintain/mnt-board-02.webp) *Table view, one row per work order under machine-name section headings. This is the view the CSV export reads.* ## 4. Kanban view Kanban draws one column per group: one per machine, one per maintenance group, or one per person, depending on §6. **The columns are never statuses.** Nothing on this board moves a work order from **Open** to **In Progress** by dragging. Status is set in the drawer, on [the status row](/docs/maintain/work-order-detail/#status). Dragging a card sets the field its column stands for. | Grouped by | Dragging a card to another column | |---|---| | **Asset** | Reassigns the work order to that machine. The **Unassigned** column clears the asset | | **Group** | Moves it to that maintenance group | | **People** | Removes the assignee it was filed under and adds the person or team you dropped it on. The **Unassigned** column only removes | ![Kanban view of the maintenance board grouped by people, showing four columns headed by an avatar and a name, one of them a team rather than a person, each column holding cards that carry a work-order number, a priority chip, a colored group label, a status chip, a title, a machine name, a recurrence line and a time estimate, with a photograph at the top of the cards that have one and an Add workorder box at the foot of every column](/images/maintain/mnt-board-03.webp) *Kanban grouped by people: one column per assignee, each card showing its machine, group, and priority. Dragging a card to another column reassigns the work order.* A move the server rejects shows the message it returned, and the board reloads, so the card snaps back. > **Warning:** > **Why did a second assignee disappear?** Grouped by people, a drag removes the assignee whose column you dragged from and adds the one you dropped on, so a work order with two people on it loses the one it was filed under. To add somebody without removing anybody, use the assignee list in the drawer. ## 5. Calendar view Calendar places each work order on its due date. The buttons at the top left step through time and **today** returns to now; the ones at the top right switch between **month**, **week**, and **day**. A block runs backward from the due date by the time estimate, so a 90-minute job due at 14:00 is drawn from 12:30. With no estimate it is an hour, and an estimate of exactly 24 hours makes it all-day. - **A work order with no due date is drawn on today**, as an all-day block, and it moves to the next today tomorrow. Give it a due date to pin it. - **A month cell shows five work orders**, then a **+N more** link. - **Dragging or resizing a block sets the due date** and nothing else. It saves immediately and confirms with ` updated`. On failure it shows `Issues updating work order` and snaps back, or `Resize reverted: Issues updating work order` after a resize. Select an empty day in month view to open [the create modal](/docs/maintain/create-a-work-order/) already due that day at 9:00 AM with a 60-minute estimate. In week or day view, drag down a range of hours instead: the work order comes back due at the end of the range, with the length of the range as its estimate. ![Calendar view of the maintenance board in month mode, a six-week grid with colored work-order blocks placed on their due dates, prev, next and today buttons at the top left, the month name in the center, and month, week and day buttons at the top right](/images/maintain/mnt-board-04.webp) *Calendar view in month mode, with work orders drawn on their due dates and a +N more link on the busiest day. Dragging a block to another day changes the due date.* Calendar ignores the grouping pill and offers every filter regardless of it. Its own choice of month, week, or day is remembered separately from the view pill. ## 6. Group by asset, group, or people The grouping pill sets what the sections in List and Table, and the columns in Kanban, are built from. | Grouping | Sections or columns are | Use it to answer | |---|---|---| | **Asset** | One machine each | Which machine is soaking up the maintenance hours | | **Group** | One maintenance group each, in the group's color | Whether Electrical is drowning while Hydraulics is idle | | **People** | One person or team each | Who is working on what today | | **None** | A single **All Tasks** section | Nothing on its own. Use it with a filter, for a flat list | Anything unfiled collects in an **Unassigned** section: no machine under **Asset**, no group under **Group**, nobody assigned under **People**. Four of the five ways a work order can be created leave the group empty, so **Unassigned** under **Group** is the planner's inbox. Grouped by **People**, a work order is filed under one owner: its team if a team is assigned, otherwise the first person on it. It appears once, not once per assignee. The grouping travels in the URL as `?maintenance_group_by=people`, so a board you paste into a message opens the way you left it. The view does not: whoever opens the link sees their own last-used view. > **Info:** > **Why did my filter clear itself?** Each grouping shows only the filters that make sense for it, and switching drops the ones it hides. Moving to **Asset** clears a group filter, moving to **Group** clears a machine filter, and **None** shows both and clears neither. ## 7. My work *My work* is a scope rather than a filter: it asks IoTFlows for your work orders only, instead of hiding the rest after they arrive. The toggle sits at the far left of the control bar and is always visible. **My Work** shows only work orders assigned to you, **All** shows the organization's. It applies to every view and travels in the URL as `show_my_work_only=true`. ![A cropped detail of the left of the maintenance control bar. A violet box surrounds a two-button pill: the left button carries a single-person icon labeled My Work, and the right button, carrying a group icon and labeled All, is highlighted blue as the live scope. The dashed Machines filter chip sits outside the box to its right](/images/maintain/mnt-board-05.webp) *The My Work and All scope toggle at the left of the control bar. My Work asks for your assigned work orders only, and is the usual reason a work order seems to be missing.* Leave the board on **All** unless you are working your own queue. A supervisor who leaves it on **My Work** is reading a board that predicts nothing, because the work they are accountable for is assigned to somebody else. ## 8. Filters and search Three controls narrow every view, and all three are in the URL, so a filtered board is a link you can send. **Status.** The filter on the right offers **Active**, **Done**, and **All**, and opens on **Active**. **Active** is **Open**, **In Progress**, and **On Hold**; **Done** covers both closed statuses, **Done** and **Approved**. **Done** and **All** add a time window over the date a work order was last updated, defaulting to the last 7 days, with 1, 30, and 90 days beside it and 1 and 5 years on Enterprise plans. **Active** has no window and never hides an open work order for being old. **Machines and Groups.** The **Machines** filter appears when the board is grouped by **Asset** or **None**, the **Groups** filter when it is grouped by **Group** or **None**, and both appear in Calendar. There is no filter by person: use **People** grouping or the **My Work** scope. **Search.** Select the magnifier and type. The board filters after a 400-millisecond pause and writes the text into the URL as `?q=`, and **Escape** or the **X** clears it. > **Warning:** > **A work order you cannot find?** Check, in this order: the **My Work** toggle, the search box, the status filter and its time window, then the **Machines** or **Groups** filter. A work order completed three weeks ago is hidden by **Done** at 7 days, not deleted. When nothing matches, the board says `No work orders found for the selected filters`. ## 9. Density and card fields *Density* is how much vertical space a row or card takes. The toggle in the control pill reads **Compact view** or **Large view**, naming the one it would switch you to. Each view keeps its own setting. List and Table start compact because they are for scanning, and Kanban starts large because a card carrying a photo needs the room. In Kanban, **Card fields** appears beside it: a popover headed **Show Fields** that sets what each card carries. | Field | On by default | |---|---| | **Hero Image**, **Assignee**, **Asset**, **Group**, **Recurrence**, **Estimated Time**, **Details** | Yes | | **Description**, **Due Date** | No | ![A popover headed Show Fields, opened from a settings button at the right of the maintenance control pill, holding two columns of chips: Hero Image, Machine, Estimated Time, Group, Recurrence and Details in blue for on, Description and Due Date in gray for off. The board is grouped by People, so no Assignee chip is listed. The density button, a pair of arrows pointing inward, sits between the grouping pill and the settings button](/images/maintain/mnt-board-06.webp) *The Card fields popover in Kanban, headed Show Fields, with a toggle for each field a card can carry. The density button sits to its left.* Grouped by **People** the list changes to match: **Assignee** drops out, because the column already names them, and **Asset** becomes **Machine**. The popover has no reset, so turn fields off deliberately. Density and card fields live in this browser, like the column choices in §3. They are yours, not the board's. ## 10. Export the table The **CSV** button appears at the right of the control bar in **Table** view only. Selecting it writes `maintenance-tasks-YYYY-MM-DD.csv` straight from the work orders on screen. - **Your filters, search, and scope apply.** The file holds exactly the rows the table holds. - **Grouping does not.** The file is one flat list with no section headings. Add the **Group** or **Asset** column if you need that. - **The columns are the table's columns, in the table's order.** Turn on everything in §3 first and the file carries all 15. - **Nothing is re-queried.** The export never leaves the browser, so there is no progress bar and no failure message. A row missing from the file was missing from the board. Two columns do not read the way the screen reads. **Status** is written as `Not Started`, `In Progress`, `On Hold`, `Completed`, and `Approved`, and dates are written as full UTC timestamps, so `2026-09-18T14:00:00.000Z` rather than the local time on the card. For what else IoTFlows exports and in what shape, see [Exports reference](/docs/monitoring/exports-reference/). ## 11. On mobile Maintain has full native parity, so the board on a phone is the same board, reading the same URL parameters. It needs the app: see [Install the mobile app](/docs/get-started/install-mobile-app/). The view pill offers **Card**, **Kanban**, **List**, and **Calendar**. **Card** is what **Table** is on the web: a 15-column table does not fit a phone, so the rows become cards. The grouping pill, the **My Work** and **All** toggle, and the status, machine, and group filters are all there. ![The IoTFlows Android app showing the maintenance board in Card view, a vertical stack of work-order cards under a machine-name heading, with a view pill reading Card, Kanban, List and Calendar above them and a search icon and filter icon in the top bar](/images/maintain/mnt-board-07.webp) *The maintenance board on Android in Card view, with the same grouping, scope, and filter controls as the web board.* Two differences. Search runs on the device rather than on the server, matching the title, description, work-order number, and machine name. And there is no CSV button: export from a browser. Dragging a card between Kanban columns starts after a short press, about a fifth of a second, so a scroll is not read as a drag. ## See also - [Update, discuss, and close a work order](/docs/maintain/work-order-detail/), what opens when you select a card - [Work order fields](/docs/maintain/work-order-fields/), what every column and card field holds - [Schedule preventive maintenance](/docs/maintain/preventive-maintenance/), where the **Recurrence** column comes from - [Exports reference](/docs/monitoring/exports-reference/), every export IoTFlows produces - [Give people access to Maintain](/docs/maintain/board-members/), who appears in **People** grouping and the assignee pickers --- # Trigger maintenance from meter readings Source: https://www.iotflows.com/docs/maintain/meters/ A meter counts a machine's runtime hours or part count toward a trigger point, and acts when it gets there. Each meter lives on the Meters tab of a machine's page, carries three independent behaviors (an email at 85%, an email at the trigger, and an automatic work order at 100%), and starts a new cycle when a technician resets it. Resets are logged with who made them, and every work order the meter produced stays reachable from the meter card. # Trigger maintenance from meter readings Count runtime or parts toward a trigger point, and act automatically when the machine gets there. **Before you start.** You need a machine that is already reporting, from [Add a machine](/docs/monitoring/add-an-asset/). You need to be an Owner or an Administrator, from [Roles and permissions](/docs/admin/roles-reference/). ## 1. What a meter counts A *meter* is a running total on one machine that never goes down on its own. IoTFlows adds to it from the machine's own stream, so nobody types a reading in. A *trigger point* is the number the total is counting toward. Reaching it is what makes the meter act. Open a machine from the Assets page and select the **Meters** tab, at `//assets/selected-asset/`. The tab is headed **Usage Meters** and shows one card per meter. See [Inspect a single machine](/docs/monitoring/asset-detail/#tabs) for the other tabs. Each card carries three numbers and a chart: - **Time to Service** is how long the meter has left at the rate it has been running since its last reset. It reads `N/A` until there are two readings in the current cycle, and `Exceeded` once the total is past the trigger point. - **Current** is the latest total. It turns amber at 75% of the trigger point and red at 100%. - **Trigger Point** is the number you set. The chart draws the total as a solid area and the forecast as a dashed one, against a red dashed line at the trigger point. The range buttons above it are **1M**, **3M**, **6M**, **1Y** and **All**, and open on **All**. Each reset starts a fresh segment, so the line drops back to zero at every reset rather than climbing forever. ![The Meters tab of a machine, headed Usage Meters with a New Meter button, showing meter cards stacked vertically; the first card reads Time to Service ~2 weeks, Current 985.79 hours in amber and Trigger Point 1,250 hours above a sawtooth area chart that resets to zero at each service and rides a red dashed trigger line, and the next card's header row is visible below it](/images/maintain/mnt-meter-01.webp) *Meters on a machine. Each counts toward a trigger point.* > **Info:** > **A meter or a recurrence rule?** > > Choose a meter when the machine's usage varies week to week. Calendar PMs on a machine that ran two shifts last week and none this week are either early or late, never right. > > Choose a recurrence rule when the job is owed by the calendar whatever the machine did, like an annual inspection. See [Schedule preventive maintenance](/docs/maintain/preventive-maintenance/#no-pm-object). ## 2. Create a meter 1. On the **Meters** tab, select **New Meter**. The **Create Meter** modal opens. 2. Enter a **Name**, for example `Spindle bearing grease`. 3. Pick a **Meter Type**. The list is served by the platform; the runtime type counts in `hours` and the production type counts in `count`. Leave it on **None** and the meter counts with no unit. 4. Enter a **Trigger Point**. It starts at `1000`. 5. Turn on the behaviors you want. All three are off by default, and all three are covered in [The three alert behaviors](#alerts). 6. Select **Create Meter**. A toast reads **Meter created** and the card appears on the tab. **Create Meter** stays disabled until the name has a character in it. Nothing else is required. ⌘+Enter, or Ctrl+Enter on Windows, submits the form; Escape closes it and discards what you typed. A failed create raises the server's own message, or **Failed to create meter** when it has none. ### Meter fields | Field | Required | Unit | Effect | |---|---|---|---| | **Name** | Yes | — | Names the card and the emails the meter sends. Editable later. | | **Meter Type** | No | Sets the unit | The runtime type reads `hours`, the production type reads `count`, **None** reads nothing. The unit is a label on the numbers, not a conversion. | | **Trigger Point** | No, defaults to `1000` | The type's unit | The number the total counts toward. Drawn as the red dashed line on the chart. | | **Early Warning Alert** | No | — | Emails the maintenance team at 85% of the trigger point. | | **Email Warning** | No | — | Emails the maintenance team when the trigger point is reached. | | **Auto Work Order Creation** | No | — | Creates a maintenance work order at 100%. | ![The Create Meter modal with a Name field reading Spindle bearing grease, a Meter Type dropdown set to Runtime Hours, a Trigger Point (hours) field reading 2000 with an hours suffix, and three labelled toggles below a divider, with numbered callouts 1, 2 and 3 on the name, the type and the trigger point](/images/maintain/mnt-meter-02.webp) *Creating a meter and setting its trigger point.* ## 3. Set the trigger point Set it to the interval the work is actually owed on, in the meter's own unit: 500 running hours between grease intervals, 20,000 parts between die changes. To change it later, select the **Trigger Point** number on the card and type over it. Enter saves, Escape cancels, and clicking away saves. A value of zero or less, or anything that is not a number, is discarded with no message, so check the number went in. Changing the trigger point moves the red line and recomputes **Time to Service** straight away. It does not rewrite history: the totals already recorded stay where they are, and a meter that was under its old trigger point can be over the new one the moment you save. ## 4. The three alert behaviors Each behavior is its own toggle on the card, and they are independent. A meter with all three off still counts; it never tells anyone. | Behavior | Fires at | Channel | Creates work order | |---|---|---|---| | **Early Alert** | 85% of the trigger point | Email to the maintenance team | No | | **Email Warning** | The trigger point, 100% | Email to the maintenance team | No | | **Auto Work Order** | 100% | A work order for the maintenance team | Yes | The toggles are labeled **Early Warning Alert**, **Email Warning** and **Auto Work Order Creation** in the create modal, and **Early Alert**, **Email Warning** and **Auto Work Order** on the card. They are the same three settings. A toggle writes the moment you flip it, and a thin progress bar runs across the top of the card while it saves. A failed write puts the toggle back where it was and raises **Failed to update meter**. Turn on the 85% early warning when the work needs a part ordered, and the 100% auto work order when it does not. An auto work order that arrives the day the part runs out is a work order that sits On Hold. You do not need all three. Two emails about the same meter four days apart is how people learn to filter the sender. ![A cropped detail of a meter card's control panel showing three toggle rows labelled Early Alert, Email Warning and Auto Work Order, numbered one to three, beside a Reset Meter button](/images/maintain/mnt-meter-03.webp) *The three behaviors: early warning at 85%, email at the trigger, and an automatic work order at 100%.* > **Warning:** > **The line under the chart is not a status** > > Every meter card carries the sentence **Work order created when usage reaches N** under its chart, whether **Auto Work Order** is on or off. It restates the trigger point; it does not tell you the behavior is armed. The toggle is the only place that does. ## 5. Reset a meter A *reset* ends the current cycle and starts the count again from zero on the date you give it. Reset the meter when the work is done, not when the work order is created, or the next cycle starts early. 1. On the card, select **Reset Meter**. The **Reset Usage Meter** dialog opens. 2. Set **Reset Date**. It defaults to today, and you can backdate it to the day the technician actually did the job. 3. Select **Confirm Reset**. A toast reads **Meter reset successfully** and the card reloads: **Current** drops back toward zero, the chart starts a new segment at the reset date, and **Time to Service** reads `N/A` until the new cycle has two readings in it. The dialog takes a date and not a time. Every reset is stored at noon UTC on the date you pick, so a reset dated today and a reading from this morning land in the order you would expect wherever your plant is. A failed reset raises **Failed to reset meter** and the cycle is unchanged. ![The Reset Usage Meter dialog with the line Set the date when the meter was reset, a Reset Date field holding today's date, and Cancel and Confirm Reset buttons with Confirm Reset outlined, over a meter card whose Current figure of 2128.12 hours is red](/images/maintain/mnt-meter-04.webp) *Resetting a meter after the work is done.* ## 6. Reset history Select the **⋮** button beside **Reset Meter**, then **Reset History**. The dialog lists every reset on the meter, newest first. | Column | What it holds | |---|---| | **Reset Date** | The date the cycle restarted from. | | **Updated By** | The member who logged the reset, with their avatar. | | **Last Modified** | When the row was last written, to the minute. | Only the newest row carries **Edit** and **Delete**, because only the newest reset bounds the cycle the meter is counting now. Select **Edit** to correct the date and **Save** to write it: the toast reads **Reset updated**, or **Failed to update reset**. **Delete** removes the reset and folds its cycle back into the one before it, with **Reset deleted** or **Failed to delete reset**. A meter nobody has reset yet reads **No reset history found**. ![The Reset History dialog showing a three-column table of Reset Date, Updated By and Last Modified with three rows, and Edit and Delete buttons on the top row only](/images/maintain/mnt-meter-05.webp) *The Reset History table: one row per reset, with the member who logged it and when. Only the newest row can be edited or deleted.* ## 7. Linked work orders Select **⋮**, then **Work Orders**, to see the maintenance work orders this meter produced, newest first. Each row shows the work order number, its title, its status badge and when it was last touched. Selecting a row closes the dialog and opens the maintenance board with that work order in the drawer, at `//maintenance?selected_wo=`. From there it is an ordinary work order: assign it, add parts, close it. See [Update, discuss, and close a work order](/docs/maintain/work-order-detail/). A meter that has never reached 100% with **Auto Work Order** on reads **No pending work orders for this meter**. This list is the meter's own output, so a work order you raised by hand for the same job does not appear here. This dialog is the fastest way to answer "did anyone act on this meter", which is worth checking before you reset it. ## 8. Edit or delete a meter Everything on the card is editable in place, and every edit saves on its own: - Select the **name** to rename the meter. Enter saves, Escape cancels. An empty name is discarded. - Select the **type pill** beside the name to change the meter type. The card's list holds the platform's types and no **None** option, so a meter created without a type can be given one here but not have it taken away. - Select the **Trigger Point** number to change it, as in [Set the trigger point](#trigger-point). - Flip any of the three toggles. Each edit applies to the card immediately and then writes. If the write fails, the card reverts and raises **Failed to update meter**, so the number you are looking at is always the number that saved. To delete, select **⋮**, then **Delete Meter**, then **Delete** in the confirmation. A toast reads **Meter has been deleted** and the card leaves the tab. > **Warning:** > **Check Work Orders before you delete** > > The confirmation asks only "Are you sure you want to delete meter *name*?". It does not count the work orders the meter created or say what happens to them. Open **Work Orders** first and close or reassign anything still open, so nothing is left on the board with no meter behind it. ## See also - [Schedule preventive maintenance](/docs/maintain/preventive-maintenance/). The calendar alternative to a meter, for work the machine's usage does not drive. - [Set alert rules for a machine](/docs/alerts/asset-event-rules/). The other way a machine raises a work order on its own. - [Inspect a single machine](/docs/monitoring/asset-detail/). The tabs beside **Meters** on the same page. - [Create a maintenance work order](/docs/maintain/create-a-work-order/). Every field a work order carries, including the ones an auto work order arrives without. - [How each metric is calculated](/docs/monitoring/metrics-reference/#production). Where the part counts a meter reads come from. --- # Overview: maintenance management Source: https://www.iotflows.com/docs/maintain/overview/ Maintain is the IoTFlows CMMS, and a work order is its only object: a request, a planned job and a preventive maintenance schedule are all the same record with different fields filled in. Work orders arrive from five places, from the board itself, a classified downtime, a machine event rule, a meter reaching its trigger point, or the Maintenance panel in the job runner. They move through Open, In Progress, On Hold, Done and Approved, and closing one moves stock in Inventory. # Overview: maintenance management What Maintain tracks, and how it connects to machines, production and stock. Maintain is the IoTFlows *CMMS*, a computerized maintenance management system: the one place maintenance work is asked for, planned, done and recorded. It sits at `//maintenance` on the web and ships as a native screen in the iOS and Android apps. Nothing needs setting up before you open it. Getting the rest of your maintenance team onto the board is on [Give people access to Maintain](/docs/maintain/board-members/). ## What a work order is here A *work order* is one maintenance job: a title, a machine, a priority, a due date, the people doing it, and the parts it will use. It is the only object Maintain has. A request an operator files from a phone, a job a planner writes out field by field, and a quarterly lubrication schedule are the same record with different fields filled in. Diagram: A diagram in two bands. The top band, headed where a work order comes from, holds five boxes side by side: The board, you fill it in, on the web or a phone; A downtime, classify a stop, then create one from it; A machine event, a rule's Work Order switch, automatic; A meter, automatic, when it reaches its trigger; A job on the floor, the Maintenance panel in the runner. An arrow drops from each of the five onto one horizontal line, and a single arrow runs from that line down into the first box of the second band. The second band, headed the statuses it moves through, runs left to right: Open, filed, nobody is on it; then start work; In Progress, somebody is working it; then complete; Done, the work is finished; then approve; Approved, signed off. A two-way arrow hangs below In Progress to a fifth box, On Hold, blocked or waiting, labeled on hold going down and resume coming back. An arrow drops from Done to a note reading: closing consumes the parts it required and adds the parts it created. A line across the bottom reads: a preventive maintenance job is one of these, with a recurrence rule on it. *The work-order state machine, and the five places a work order can come from.* Every work order carries one of five statuses: **Open**, **In Progress**, **On Hold**, **Done** and **Approved**. What each one means, and every field behind it, is on [Work order fields and statuses](/docs/maintain/work-order-fields/). There is no separate preventive-maintenance object. A *PM* is a work order with a recurrence rule on it, so anything you can do to a work order you can do to a PM: reassign it, attach a photograph, change its parts list. See [Schedule preventive maintenance](/docs/maintain/preventive-maintenance/). ### Where work orders come from | Origin | Creates | Page | |---|---|---| | The maintenance board, on the web or a phone | A work order you fill in yourself | [Create a maintenance work order](/docs/maintain/create-a-work-order/) | | Classifying a machine stop | A work order prefilled with that machine and the downtime category as its title | [Classify a downtime](/docs/monitoring/classify-downtime/#work-order) | | A machine event rule with its **Work Order** column switched on | A work order automatically, unassigned, each time that event fires on that machine | [Set up machine event rules](/docs/alerts/asset-event-rules/#work-order) | | A meter reaching its trigger point, with **Create Work Order when triggered** checked | A work order automatically, on runtime hours, a calendar interval or a parts count | [Trigger maintenance from meter readings](/docs/maintain/meters/) | | The **Maintenance** panel in the job runner | A work order prefilled with the machine the operator is running | [Run a job](/docs/production/run-a-job/#maintenance) | Every entry point an operator can reach, web and mobile, is collected on [Submit a maintenance request](/docs/maintain/submit-a-request/). ## The board and the drawer Maintain is one board per organization, and everything filed lands on it. You cannot split maintenance across several boards the way the Scheduler splits production. The board offers four views of the same work orders: **List**, **Table**, **Kanban** and **Calendar**. Filters narrow them by completion status, machine, group and people, where a *group* is a named, colored bucket you define on the board, for example `Electrical` or `Weekly PMs`. See [Organize work on the maintenance board](/docs/maintain/maintenance-board/). Selecting a work order opens it in a drawer beside the board, so the list stays in view. The drawer is where the work happens: change status, edit any field inline, tick off a checklist, attach photographs and files, and talk to the assignees in a comments thread. See [Update, discuss, and close a work order](/docs/maintain/work-order-detail/). ## How Maintain connects to the rest of IoTFlows **Machines.** A work order points at an asset, so a machine's maintenance history is the work orders that named it. The stops and events behind them come from [Monitoring](/docs/monitoring/overview/). **Alerts.** A machine event rule can open a work order instead of, or as well as, emailing somebody. The rule carries no assignee, so an automatic work order arrives unassigned and somebody has to triage it. **Production.** An operator raises a request without leaving the job runner, and the job keeps running while they do. Production work itself is scheduled separately, on the [Scheduler](/docs/production/scheduler/). **Inventory.** A work order has two parts lists: what it requires and what it creates. Moving it to **Done** deducts the first from stock, adds the second, and writes the inventory transactions, after asking you to confirm. See [How work orders move stock](/docs/inventory/how-work-orders-move-stock/). ## What Maintain does not do **It does not schedule production.** A maintenance work order and a production task are different objects on different boards, and blocking a machine for maintenance does not take it out of the production schedule. **It does not classify downtime.** Opening a work order from the **Classify Downtime** modal and saving the reason are two separate actions in the same modal: doing one does not do the other. **It does not hold the parts catalog.** A work order references parts that already exist in Inventory. Creating a part is an Inventory task. **You probably do not need meters** if your maintenance is date-driven. A recurrence rule already covers "every 90 days". Reach for a meter only when the interval depends on how hard the machine ran, for example 500 spindle hours rather than three months. ## Where to start New to Maintain: run one work order end to end with [Quickstart: create and close your first work order](/docs/maintain/quickstart/), which touches the board, the drawer and the status flow. Setting Maintain up for a team: put your maintenance people [on the board](/docs/maintain/board-members/) first, then check what each organization role can do in [Roles reference](/docs/admin/roles-reference/). ## See it in a plant - [Maintain](https://www.iotflows.com/platform/maintain) — Work orders that open from a stop, a machine event rule, a meter or a request, in one backlog. ## See also - [Quickstart: create and close your first work order](/docs/maintain/quickstart/) - [Create a maintenance work order](/docs/maintain/create-a-work-order/) - [Schedule preventive maintenance](/docs/maintain/preventive-maintenance/) - [How work orders move stock](/docs/inventory/how-work-orders-move-stock/) --- # Schedule preventive maintenance Source: https://www.iotflows.com/docs/maintain/preventive-maintenance/ Preventive maintenance in IoTFlows is a recurrence rule on a work order, not an object of its own. The Recurrence picker sits in the create modal and in the work-order drawer, anchors every pattern to the work order's due date, and takes an interval, a weekday set, an end date, and the timezone the rule is read in. A rule authored in the planner's timezone rather than the plant's lands on the wrong shift every time it fires. # Schedule preventive maintenance Make a maintenance job repeat on a fixed calendar, and make it land on the right shift. **Before you start.** You need a work order with a due date, from [Create a maintenance work order](/docs/maintain/create-a-work-order/#due-date). Set your organization timezone first, in [Shifts and timezone](/docs/admin/shifts-and-timezone/#timezone), so a rule can be pinned to the plant instead of to whoever wrote it. ## 1. There is no separate PM object A *recurrence* is a rule stored on a work order that says when the job comes back: a pattern, an interval, and an optional end. Each date the rule produces is an *occurrence*. The work order's due date is the first one, and every later occurrence is counted from it. A *PM*, a preventive maintenance job, is that rule and nothing else. There is no PM record, no PM list and no PM permission: a quarterly gearbox inspection is a work order carrying `Monthly on the first Tuesday`. That is the payoff, because anything you can do to a work order you can do to a PM: reassign it, attach the last technician's photograph, change its parts, export it. See [Update, discuss, and close a work order](/docs/maintain/work-order-detail/). One path cannot make a PM. A request raised from the **Maintenance** panel in the job runner is submitted with its recurrence fields empty, so nobody creates a schedule by accident from the floor. See [Submit a maintenance request](/docs/maintain/submit-a-request/#job-runner). > **Info:** > **Should this be a recurrence at all?** > > You do not need recurrence for a job that repeats irregularly. A filter change that is due every 500 spindle hours falls on a different date every month, and a calendar rule either replaces it too early or lets it run too long. > > Use a meter instead, so the trigger is runtime rather than the calendar: [Trigger maintenance from meter readings](/docs/maintain/meters/). ## 2. Add a recurrence rule The same picker appears in two places. **In the create modal**, from the board at `//maintenance`: 1. Set a due date on the **Due Date** chip. This is the first occurrence. 2. Select the **Recurrence** chip. 3. Pick a pattern, or **Custom** for anything the list does not cover. 4. Create the work order. The chip reads **Recurring** until you do. Selecting **Recurrence** before there is a due date raises **Set a due date first**, because the series has nothing to count from. **In the work-order drawer**, on a work order that already exists: 1. Open the work order from the board. The URL gains `?selected_wo=`. 2. In **Properties**, select the **Recurrence** row. It reads **Add recurrence** while the work order has no rule. 3. Pick a pattern, then select **Save**. This row is the one exception to the drawer's save-on-change behavior. The two pickers hold the same controls under shorter labels in the drawer: **End Recurrence** is **Ends** there, and **Time Zone** is **Timezone**. The field names below are the create modal's. ![The create modal's recurrence panel with Recurrence Pattern set to Custom, a Recurrence Frequency control reading Weekly, a row of round day pills with Mon highlighted, and a Repeat every field reading 1 week, with numbered callouts on the pattern control, the weekday row and the interval field](/images/maintain/mnt-pm-02.webp) *The Recurrence picker with a weekly pattern being set, showing the pattern control (1), the weekday row (2), and the interval (3). A work order carrying one of these is a preventive maintenance schedule; there is no separate PM object.* ## 3. Daily, weekly, monthly, annual The pattern list is built from the due date, so its wording changes with the date you picked. A work order due Tuesday, October 6, 2026 offers these. | Pattern | Example rule | Next occurrences | |---|---|---| | Daily | `Daily` | Oct 7, Oct 8, Oct 9 | | Weekdays only | `Every Weekday (Monday to Friday)` | Oct 7, Oct 8, Oct 9 | | Weekly | `Weekly on Tuesday` | Oct 13, Oct 20, Oct 27 | | Monthly, by weekday | `Monthly on the first Tuesday` | Nov 3, Dec 1, Jan 5 | | Annual | `Annually on October 6` | Oct 6 2027, Oct 6 2028, Oct 6 2029 | Monthly patterns repeat by weekday, not by date. A due date that is the last Tuesday of its month also offers `Monthly on the last Tuesday`, which is what you want for a job that has to happen before a month closes rather than on the 27th. The picker previews **Next 3 occurrences** under the list so you can check a rule before saving it. The preview covers the daily, weekday, weekly and annual patterns; several of the monthly ones show none, so read the rule's own wording there. > **Warning:** > **The create modal names the wrong weekday** > > The table above is what the drawer's picker offers. The create modal's picker reads the due date a calendar day early: give a new work order a due date of Tuesday, October 6 and it offers `Weekly on Monday`, `Monthly on the first Monday` and `Annually on October 5`, and preselects the `Mon` pill. The recurrence panel shown above is in exactly that state. > > The offset is in the picker's wording, not in the date you set — the **Due Date** chip still reads `Oct 6`. Set the pattern in the drawer after the work order exists, or check the rule on the work order once it is saved. ## 4. Intervals Every preset runs at an interval of one. To run a job every second week or every third month, pick **Custom**, set **Frequency**, then set **Repeat every** to the number you want. A rule set to `Weekly, repeat every 6 weeks` on a Tuesday lands on Oct 6, Nov 17 and Dec 29. Daily has no interval field in either picker. A rule that skips days is a weekly rule with the right days selected, not a daily rule with an interval. ## 5. Weekday sets A custom weekly rule carries a row of day pills, and it can land on more than one day. Select `Mon`, `Wed` and `Fri` and one rule covers a three-times-a-week greasing round, rather than three work orders that drift apart the first time somebody edits one. The pill for the due date's own weekday is selected when the panel opens — in the create modal, the pill for the day before it, as [Daily, weekly, monthly, annual](#patterns) describes. Keep at least one selected, or the rule has no day to land on. The pills are inert on the daily, monthly and yearly frequencies. ## 6. End date **End Recurrence** is **Never** until you change it. Set it to **On a Specific Date** and a date and a time appear, already filled in: thirteen weeks past the due date, at 9:00 AM. That is a default, not a reading of your due time — a work order due at 8:00 AM still ends at 9:00. Change both to the date and time the series should stop. The calendar will not offer a date before the due date, and the time is a dropdown of half hours. ![A cropped detail of the recurrence panel's end section, with End Recurrence set to On a Specific Date, a date button reading 1/5/2027 beside a time dropdown reading 9:00 AM, and a clear cross to the right of them](/images/maintain/mnt-pm-04.webp) *The end-date field in the recurrence panel with a date and a time set. An end date stops the recurrence, and a rule that produced no next occurrence usually hit this.* Give a rule an end date when the work has a horizon: a warranty inspection for the first year, a weekly check while a machine is on watch after a rebuild. Leave it at **Never** for standing maintenance, and stop it by hand when the machine is retired. A recurring work order that stopped producing a next occurrence has almost always hit its end date. Open the rule and read the date before looking anywhere else. > **Warning:** > **Why did a count-limited rule not stop?** > > The third option, **After Number of Occurrences**, does not reach the server. The work order saves with the pattern and no end, so the rule keeps going past the count you typed. > > To stop a series after a fixed number of jobs, use **On a Specific Date** and set it to the date of the last occurrence you want. ## 7. Choose the timezone The date and time you type are read as wall-clock time in the timezone you select, then stored in UTC. **Time Zone** offers **Local Timezone**, the browser's own zone, **Organization Timezone**, the one set in [Shifts and timezone](/docs/admin/shifts-and-timezone/#timezone), and **Custom Timezone**, any zone from the list. It is one setting covering both the due time and the end date, but it is easy to miss, because neither picker shows it until something else is set. In the create modal it appears at the bottom of the custom recurrence panel only once **End Recurrence** is **On a Specific Date**; in the drawer it sits in the **Due Date** dialog, labelled with the zone it currently resolves to rather than the word Timezone. Select that label to open the choice. **Set this to the plant's timezone, not the planner's.** A weekly PM authored from a different timezone lands on the wrong shift, and it does it every week without anyone noticing which week it started. Choose **Organization Timezone** for a single-site organization, and **Custom Timezone** when you are planning work for a plant in a region other than your own. ![A cropped detail of the recurrence panel showing the Time Zone label, a highlighted select reading Local Timezone, and the zone's full name, GMT minus 04:00 Eastern Time US and Canada, to the right of the control](/images/maintain/mnt-pm-03.webp) *The Time Zone selector in the recurrence panel, set to Local Timezone, with the zone it resolves to shown beside it. Its three choices are Local Timezone, Organization Timezone, and Custom Timezone. Set this to the plant's timezone, not the planner's.* A planner in Detroit writing an 8:00 AM Tuesday PM for a plant in Phoenix, with **Local Timezone** left alone, stores it at 12:00 UTC. That is 5:00 AM in Phoenix, three hours before first shift. It is worse than a constant error: Phoenix does not observe daylight saving, so the same rule slips to 6:00 AM in November and back again in March. *How a recurrence rule generates occurrences, and what happens when the rule's timezone is not the plant's.* ## 8. Edit a recurring work order A recurring work order edits like any other. **Properties** shows the live rule in its **Recurrence** row, written out as a sentence, for example `Repeats every week on Tuesday until 12/22/2026`. Select the row to change it: the panel opens on the current rule, and **Save** writes the new one. Changing the due date moves the whole series, because the pattern is anchored to it. Move a Tuesday PM to Wednesday and every future occurrence moves with it. A failed date change reads **Issues updating due date**, and the value in the drawer reverts. A work order with no due date can still be given a rule from the drawer. Saving one sets the due date to today at the work order's due time, or 9:00 AM if it has none, so check the date afterwards rather than assuming the series starts next week. ## 9. Stop a recurrence To end a series and keep the work order, open the **Recurrence** row, pick **Does not repeat**, and select **Save**. The rule is cleared and the work order stays where it is, with its history, comments and attachments intact. In the create modal, **Clear** in the top right of the recurrence dropdown does the same before the work order exists. Clearing the due date also drops the rule, because the series has nothing left to anchor to. Deleting the work order is the wrong way to stop a PM. It takes the machine's maintenance history with it, which is the record the next person needs when the same bearing fails again. ## Recurrence fields | Field | Values | Required | Effect | |---|---|---|---| | **Recurrence Pattern** | `Does not repeat`, `Daily`, `Weekly on `, `Every Weekday (Monday to Friday)`, the monthly patterns the due date allows, `Annually on `, `Custom` | Yes | Sets the frequency, and for a preset the interval and weekday set behind it | | **Frequency** | `Daily`, `Weekly`, `Monthly`, `Yearly` | In **Custom** only | The unit the interval counts in | | **Repeat every** | A whole number, 1 or more | No, defaults to 1 | How many of that unit between occurrences. Not offered for daily | | Day pills | Any set of the seven weekdays | Weekly only | Which days a weekly rule lands on | | **End Recurrence** | `Never`, `On a Specific Date`, `After Number of Occurrences` | No, defaults to `Never` | What stops the rule. Only a date is stored | | End date and time | A date on or after the due date, a time on the half hour | Only when the end is a date | The last moment the rule can produce an occurrence | | **Time Zone** | `Local Timezone`, `Organization Timezone`, `Custom Timezone` | No, defaults to `Local Timezone` | The zone the due time and the end date are read in before they are stored as UTC | The saved rule is shown as a sentence on the work order, in the **Recurrence** column of the board's Table view, on the card in every other view when that field is switched on, and in the CSV export. Turning the column on and off is in [Organize work on the maintenance board](/docs/maintain/maintenance-board/#density). ## See also - [Trigger maintenance from meter readings](/docs/maintain/meters/). Runtime and cycle counts as the trigger, instead of the calendar. - [Shifts and timezone](/docs/admin/shifts-and-timezone/#timezone). Set the organization timezone a rule can be pinned to. - [Create a maintenance work order](/docs/maintain/create-a-work-order/#recurrence). Every other field a work order carries. - [Organize work on the maintenance board](/docs/maintain/maintenance-board/). Find recurring work in the calendar and table views. - [Work order fields and statuses](/docs/maintain/work-order-fields/). Every field, status and export column, in one table. --- # Quickstart: create and close your first work order Source: https://www.iotflows.com/docs/maintain/quickstart/ Run one maintenance job through Maintain end to end on the web: create a work order from the board with a title and a group, assign it to a technician, move it to In Progress, add a checklist item and tick it, complete it at Done, and sign it off at Approved. Create needs a title and a group and nothing else; every other field can be filled in later from the drawer. # Quickstart: create and close your first work order One work order from request to closed, end to end. This runs a single maintenance job through every step Maintain has: create it on the board, assign it, start it, tick a checklist item, complete it, and sign it off. Work on the web, at `//maintenance`. For what Maintain is, read [Overview: maintenance management](/docs/maintain/overview/). Getting your maintenance team onto the board is on [Give people access to Maintain](/docs/maintain/board-members/). This is the happy path. Recurring work, parts and the other entry points are branches, linked where you pass them. > **Info:** > **Which machine should you use?** > > Do this on the machine that is actually broken, not a test asset. A work order against a real machine comes back when you filter the board by that machine, which is the payoff you are trying to demonstrate. ## 1. Create a work order A *work order* is one maintenance job: a title, a machine, the people doing it, and what they need. It is the only object Maintain has. 1. Select **Maintain** in the top navigation. The board opens at `//maintenance`. 2. Select the blue **+** above the board. The **New Maintenance Workorder** modal opens. 3. Type the problem into **Work order title**. Write what is wrong rather than what to do, so the technician can judge it: `Spindle coolant leak at the rear seal` tells them more than `Fix the mill`. 4. Select the **Group** chip and pick a group, for example `Hydraulics`. A *group* is a named, colored bucket for the kind of work. If your organization has none yet, type a name into **Group name...** in the same dropdown, pick a color, and create it there. 5. Select the **Asset** chip and pick the machine the work is on. 6. Select **Create**. ![The New Maintenance Workorder modal with a title typed, a row of property chips below it, and the Create button at the bottom right](/images/maintain/mnt-qs-01.webp) *The New Maintenance Workorder modal, opened from the blue + above the board.* **Create** stays grayed out until the work order has both a title and a group. Every other chip in that row is optional now and editable later from the drawer, so leave priority, due date and parts alone on this pass. Filling them in properly is [Create a maintenance work order](/docs/maintain/create-a-work-order/). A green **Maintenance workorder created** toast confirms it and the new card appears on the board. A red **Failed to create workorder** means nothing was saved: the modal stays open with everything you typed, so retry **Create**. ## 2. Assign it 1. Select the new card on the board. It opens in a drawer beside the list, and the address gains `?selected_wo=` with the work order's id, so that link goes straight back to it. 2. In the drawer, select **Assignees**. 3. Pick a person or a team from the list. A toast naming the handle you added confirms it. ![The Assignees control in the work-order drawer with its dropdown open, listing people and teams with avatars](/images/maintain/mnt-qs-02.webp) *The assignee picker in the work-order drawer, open over the list of people and teams.* Add as many assignees as the job needs; select a name again to remove it. **Assign a person, not a team, when one named person owns the outcome.** A team assignment tells four people the work exists and none of them that it is theirs. ## 3. Start it A *status* says where a work order is in its life. There are five: **Open**, **In Progress**, **On Hold**, **Done** and **Approved**. Everything created lands on **Open**. Select **In Progress** in the status row at the top of the drawer. The row is five buttons, one per status; each shows only an icon until it is the live status, and then it widens to show its label. The board card updates as soon as you select it. Two of those labels are not the status name. The first button reads **Not Started** when it is active, and the fourth reads **Completed**. The statuses are still **Open** and **Done**, which is what the board card, the status filter and the reports call them. ![A row of five status buttons at the top of the work-order drawer, with the In Progress button expanded and labeled](/images/maintain/mnt-qs-03.webp) *The status row in the work-order drawer, with In Progress selected.* Nothing forces the order: any status can follow any other. **On Hold** is for work that started and then stalled, waiting on a part or on the machine coming free. What each status means is on [Update, discuss, and close a work order](/docs/maintain/work-order-detail/). ## 4. Add a checklist item and tick it A *checklist* is the list of small steps inside one work order, ticked off as the work happens. 1. In the drawer, open the **Checklist** section. 2. Type a step into **Add a task...**, for example `Isolate and lock out the machine`. 3. Select the blue **+** beside the field. A **Task added** toast confirms it. 4. Select the circle beside the item to tick it. The text strikes through and the green progress bar above the list fills. ![The Checklist section of the drawer with one item struck through and ticked, and a full green progress bar above it](/images/maintain/mnt-qs-04.webp) *A checklist item, ticked, with the progress bar above it filled.* **You do not need a checklist if the title already says the whole job.** Checklists earn their keep on work nobody should improvise: a lockout sequence, a PM route with eight lubrication points, an inspection somebody has to sign for. ## 5. Complete it Select the fourth button in the status row, the check-circle. A **Task completed!** toast confirms it and the card moves on the board. The button widens and reads **Completed**; the status is **Done**. ![The status row in the drawer with the fourth button expanded and labeled Completed, a check-circle icon beside it](/images/maintain/mnt-qs-05.webp) *The fourth status button, selected. It reads Completed; the status it sets is Done, and it closes the work order.* **Done** is the transition that moves stock. If the work order lists parts it requires or creates, a dialog opens first and you confirm what was actually consumed and produced. Yours lists no parts, so it closes straight away. The parts path is [How work orders move stock](/docs/inventory/how-work-orders-move-stock/). ## 6. Approve it Select **Approved**, the fifth button in the status row. This is the sign-off: the work is done and somebody has checked it. ![The status row in the drawer with the Approved button expanded and labeled, a stamp icon beside it](/images/maintain/mnt-qs-06.webp) *The Approved button, the last status in the row, marked with a stamp icon.* Stock already moved at **Done**, so **Approved** moves nothing further. Skip it if your team has no review step, and keep using **Done** as the end of the line. ## 7. What you just built One work order, from a title somebody typed to a signed-off record. That record is the machine's maintenance history: filter the board by that asset and the job is there, with who did it, what they ticked off, and when it closed. Three branches open from here: - **The work came from the floor, not from you.** Operators report problems from a phone, from the job they are running, or from the board. See [Submit a maintenance request](/docs/maintain/submit-a-request/). - **The work repeats.** A quarterly lubrication is a work order with a recurrence rule on it, not a separate object. See [Schedule preventive maintenance](/docs/maintain/preventive-maintenance/). - **There is more than one of these now.** Group, filter and lay out the backlog across four views on [Organize work on the maintenance board](/docs/maintain/maintenance-board/). ## See also - [Create a maintenance work order](/docs/maintain/create-a-work-order/) - [Update, discuss, and close a work order](/docs/maintain/work-order-detail/) - [Organize work on the maintenance board](/docs/maintain/maintenance-board/) - [Work order fields and statuses](/docs/maintain/work-order-fields/) --- # Submit a maintenance request Source: https://www.iotflows.com/docs/maintain/submit-a-request/ Report a machine problem from wherever you found it: the blue + above the maintenance board, the Maintenance panel in the job runner, the Create Maintenance Workorder button in Classify Downtime, the Maintenance tab on a machine's page, or the Create Maintenance Request sheet on a phone. Every path except the board submits with no group, no assignee and no recurrence, so a request raised from the floor cannot be a preventive maintenance schedule. # Submit a maintenance request Every way to report a machine problem, from the floor or from a desk. A *request* is a work order raised because a machine needs attention now, rather than one a planner scheduled. It is the same record as every other work order with fewer fields filled in, which [Overview: maintenance management](/docs/maintain/overview/#work-order) describes. Whoever is closest to the problem raises it, and a planner completes it on the board. Report from the machine, with a photo, while the problem is in front of you. A request typed at a desk an hour later loses the one thing a technician needs, which is what it looked like. Getting your team onto the board is [Give people access to Maintain](/docs/maintain/board-members/). ## Where a request can start | Start from | Client | Can set recurrence | Attaches | Page | |---|---|---|---|---| | The blue **+** above the maintenance board | Web | Yes | Images, files | [From the maintenance board](#board) | | The **Maintenance** panel in the job runner | Web, mobile app | No | Images, files, a photo from the camera | [From the job you are running](#job-runner) | | **Create Maintenance Workorder** in **Classify Downtime** | Web | No | Images, files | [From a stop or a machine](#machine) | | The **Maintenance** tab on a machine's page | Web | No | Images, files | [From a stop or a machine](#machine) | | The wrench in the job header on a phone | Mobile app, mobile web | No | Images, files, a photo from the camera | [From your phone](#phone) | Work orders also arrive without anyone typing one, from a meter reading or a machine event rule; those origins are on [Overview: maintenance management](/docs/maintain/overview/#connections). ## From the maintenance board Use the board when you are planning the work rather than reporting it. It is the only path that can set a group, an assignee, an estimate or a recurrence. 1. Select **Maintain** in the top navigation. The board opens at `//maintenance`. 2. Select the blue **+** above the board. The **New Maintenance Workorder** modal opens. 3. Type the problem into **Work order title**, then pick a **Group**. 4. Select **Create**. **Create** stays grayed out until the work order has both a title and a group. A green **Maintenance workorder created** toast confirms it; a red **Failed to create workorder** means nothing was saved, and the modal keeps what you typed. Every field on this modal is [Create a maintenance work order](/docs/maintain/create-a-work-order/). ![The New Maintenance Workorder modal open over the maintenance board, with a title field, a row of property chips including Group, and a Create button at the bottom right](/images/maintain/mnt-request-01.webp) *The New Maintenance Workorder modal on the maintenance board, the only path that can set a group, an assignee and a recurrence.* ## From the job you are running You need a job open in the runner, which is [Run a job](/docs/production/run-a-job/#open). 1. In the panel rail down the right of the runner, select **Maintenance**. The panel opens with the cursor in the title and the **Asset** chip already set to the machine the job is running on. 2. Type the fault into **What needs maintenance?**. 3. Add what you saw to **Add description...**. 4. Set the chips the technician needs: **Priority**, **Due Date**, **Asset**, **Required Parts**, **Create/Release Parts**, **Images** and **Files**. 5. Select **Submit Request**, or press ⌘+Enter (Ctrl+Enter on Windows). **Submit Request** stays grayed out until the request has a title. Nothing else is required, and no group is asked for. A green **Maintenance request created** toast closes the panel; a red **Failed to create request** means nothing was saved and everything you typed is still on screen. Write the detail into the description. **Notes** on this panel is not sent with the request. Your job is untouched. The task stays **In Progress** and its work session keeps running while you fill the form in. > **Info:** > **Why is there no Recurrence chip?** > > This panel submits with the recurrence fields, the group and the assignee empty, so a request raised from the floor cannot repeat. Recurring work is created on the board: [Schedule preventive maintenance](/docs/maintain/preventive-maintenance/). ![The Maintenance panel open over the job runner, with a title field reading What needs maintenance, a description box, a row of chips for Priority, Due Date, Asset, Required Parts, Images and Files, and a Submit Request button across the bottom](/images/maintain/mnt-request-02.webp) *The Maintenance panel in the job runner, with the machine already filled in. Requests raised here cannot be recurring.* [Operator View](/docs/monitoring/operator-view/) hides this panel inside its job view, because the operator page already carries the same maintenance action beside its machine controls. ## From a stop or a machine Both of these open the same panel as the job runner, with the machine already set. - While classifying a stop, select **Create Maintenance Workorder** in **Classify Downtime**. The title arrives prefilled with the downtime category and the description with your note, so a stop you have already explained needs one more press. The steps are [Create a work order from a stop](/docs/monitoring/classify-downtime/#work-order). - On a machine's page, select **Maintenance** in the panel rail. Raise it from the stop when the request explains that downtime, so the classification and the work order carry the same words. ## From your phone You need the IoTFlows app, which is [Install the mobile app](/docs/get-started/install-mobile-app/). The same layout loads in a phone browser below 640 px wide. *Capture-first* means taking the photograph before you write anything, so the request carries evidence rather than a memory. Work in that order: the photo tells the technician more than the title will. 1. Open the job in **My Work**. 2. Select the wrench in the job header. The **Create Maintenance Request** sheet slides up. 3. Select the **Images** chip, then **Take photo**. The rear camera opens, and the photo you keep attaches to the request. 4. Type the fault into **What needs maintenance?**. 5. Select **Submit Request**. The sheet takes photographs, not video or voice. To attach a video, add it to the job's own **Attachments** instead, which is [Run a job on mobile](/docs/production/run-a-job/#mobile). ![The Create Maintenance Request sheet on a phone, its Attach chip open over a menu reading Take Photo, Record Video, Voice Note, Photo Library and Choose Files](/images/maintain/mnt-request-03.webp) *Attaching a photograph on a phone: Take Photo under the Attach chip opens the rear camera from inside the Create Maintenance Request sheet.* ## Attach photos and files The **Images** and **Files** chips behave the same way on every path except the board's modal, which has its own uploader. | Chip | Takes | How to add | |---|---|---| | **Images** | JPEG, PNG, GIF, WebP, BMP, SVG | Drop onto the tile, select **Drop or click to add images**, or select **Take photo** on a phone | | **Files** | Any file type, unconverted | Drop onto the tile, or select **Drop or click to add files** | Images are converted to WebP and capped at 1600 px on the long edge before they upload, so a 12-megapixel photo stays cheap to open on shop-floor Wi-Fi. Files go up untouched. Anything the **Images** chip does not recognize is rejected by name, as ` is not a valid image`; send it through **Files** instead. An upload that fails raises `Failed to upload ` for that file alone and the rest continue, so check the count on the chip before you submit. Each attachment carries a **×** to remove it before you submit. ## What happens next The request lands in **Open** on the maintenance board with its attachments, in the same list as planned work. The panel sends no group, no assignee and no estimate, so the board fills its own defaults in: the request arrives in a group called **Default**, with a **1h** duration, and already carrying an assignee. Replacing those three with the real group, owner and estimate is the planner's first job: [Organize work on the maintenance board](/docs/maintain/maintenance-board/). From there it is an ordinary work order: assigning, discussing and closing it are [Update, discuss, and close a work order](/docs/maintain/work-order-detail/). Parts you listed under **Required Parts** ride along on the work order and move stock when it reaches **Done**, not when the request is raised. That accounting is [How work orders move stock](/docs/inventory/how-work-orders-move-stock/). ![The maintenance board's HAAS EC-1600 section, with the newly raised request highlighted as the first row, reading Open and carrying the group Default, above two planned work orders in Safety and Electrical](/images/maintain/mnt-request-06.webp) *The new request at the top of its machine's section on the board, in Open like the planned work around it, and wearing the group Default until a planner sets a real one.* ## See also - [Create a maintenance work order](/docs/maintain/create-a-work-order/) - [Update, discuss, and close a work order](/docs/maintain/work-order-detail/) - [Run a job](/docs/production/run-a-job/#maintenance) - [Classify downtime](/docs/monitoring/classify-downtime/#work-order) - [Install the mobile app](/docs/get-started/install-mobile-app/) --- # Update, discuss, and close a work order Source: https://www.iotflows.com/docs/maintain/work-order-detail/ The work-order drawer is where a maintenance job is worked: it carries the five status buttons, the editable properties, a checklist, images and files, a live comment thread, and the work order's own activity log. Selecting Done opens a read-only completion dialog whenever the work order lists parts, and the backend moves the stock when the status flips. # Update, discuss, and close a work order The work-order drawer: status, fields, checklists, attachments, comments, and history. Everything after a work order is created happens in one panel. A technician moves the status, ticks off steps, adds a photo, and asks a question in the comments without leaving it, and the board behind it updates as they go. This page assumes a work order exists. To make one, see [Create a maintenance work order](/docs/maintain/create-a-work-order/). For what each field means and where else it shows up, see [Work order fields](/docs/maintain/work-order-fields/). ## 1. Open the drawer The *drawer* is the 640 px panel that slides in from the right of the maintenance board and holds one work order. 1. Select **Maintain** in the top navigation. The board opens at `//maintenance`. 2. Select any card or row, in any of the four views. The address bar gains `?selected_wo=`. That URL is the work order's permanent link: paste it into a comment or an email and whoever opens it lands on the same work order, with the same view behind it. The **Calendar**, **Kanban**, **List**, and **Table** views all use the same parameter. ![The work-order drawer open on the right of the maintenance board, showing a priority chip, a title, a row of five status buttons, a description, collapsible Images, Attached Files and Checklist sections, and a right column holding the Properties list above a Comments heading, with four numbered callouts on the status row, the properties, the checklist and the comments](/images/maintain/mnt-detail-01.webp) *The work-order drawer, open beside the board. The left column holds the work, the right column holds its properties and comments.* The left column carries the priority chip, the title, the status row, the description, and then collapsible sections for **Images**, **Attached Files**, **Checklist**, **Parts Required**, **Create/Release Parts**, and **Activity Logs**. The right column carries **Properties** and **Comments**. Below about 800 px of panel width, the two columns stack: **Properties** moves under the description and **Comments** drops to the bottom. Nothing is removed. Close the drawer with the **X** at the top right, or with the **Work Orders** breadcrumb beside it. Either one removes `selected_wo` from the URL and leaves the board where it was. The trash icon next to the **X** deletes the work order, behind a confirmation. ## 2. The status flow A *status* says where a work order is in its life. The status row is five buttons, one per status. Each shows an icon only until it is the live status, then it widens to show its label and stops being clickable. Two of the labels are not the status name. The first button reads **Not Started** when it is active and the fourth reads **Completed**. The statuses are **Open** and **Done**, which is what the board card, the status filter, and reports call them. ![A cropped detail of the five status buttons in the work-order drawer under a Materials ready chip, numbered one to five below each button: a clock, a play triangle, a warning circle, a check circle and a stamp, with the second button widened, tinted green and labeled In Progress](/images/maintain/mnt-detail-02.webp) *The status row: five buttons for Open, In Progress, On Hold, Done, and Approved. The active button widens and reads Not Started for Open and Completed for Done.* Nothing enforces an order. Every button except the live one is selectable, so a work order can go from **Open** straight to **Done**, or back from **Approved** to **In Progress**. The sequence below is the intended path, not a gate. ### Statuses | Status | Means | Who sets it | Next states | Side effects | |---|---|---|---|---| | **Open** | Created, not started. Every work order lands here, whichever of the five origins created it. | Whoever creates it | Any | None | | **In Progress** | Somebody is working on it now. The button pulses while it is live. | The technician | Any | None | | **On Hold** | Started and blocked. It stays on the board and keeps its assignee. | Anyone | Any | None | | **Done** | The work is finished. | The technician | Any, including reopening | Opens the completion dialog if the work order lists parts, shows a **Task completed!** toast, and moves stock | | **Approved** | Signed off by somebody other than the person who did the work. | Anyone | Any | None. Stock moved at **Done** | Use **On Hold** when the work is blocked by something outside the technician's control, a part on order or a machine still in production. Reassigning the work order instead hides the fact that nothing is happening, and the board stops predicting anything. If a status change fails, the button snaps back to the previous status and a toast carries the server's reason. The change was not saved. ## 3. Edit any field inline Nothing in the drawer has a Save button. Every editable value writes as soon as you leave it, and the board card behind the drawer updates at the same moment. The title is the large text at the top. Select it, type, and press Enter or click away to save. A spinner sits beside it while the save is in flight. **Properties** holds the rest, in this order: **Due Date**, **Duration**, **Recurrence**, **Assignees**, **Group**, **Notes**, **Requested**, **Created On**, and **Asset**. ![A cropped detail of the Properties list in the work-order drawer with the Notes row switched into an open text input, the other rows showing their values as plain text](/images/maintain/mnt-detail-03.webp) *Editing a field without leaving the drawer.* Rows behave in one of three ways: - **Text rows**, which is **Notes**. Select the value, type, and press Enter to save or Escape to discard. Clicking away also saves. - **Picker rows**: **Due Date**, **Recurrence**, **Assignees**, **Group**, and **Asset**, plus the priority chip above the title. Each opens a dropdown and writes on selection. - **Read-only rows**: **Duration**, **Requested**, and **Created On**. They display what the work order already holds. The time estimate is set in the create modal and cannot be changed from the maintenance drawer. **Assignees** takes as many people as you need, added and removed one at a time. Each one confirms with a toast naming the handle, for example `sam.reyes added`. Every inline edit is optimistic: the new value appears immediately and is reverted if the request fails. A failed priority change reads **Issues updating priority** and a failed date change reads **Issues updating due date**. Other failures carry the message the server returned. ## 4. Checklists A *checklist* is a list of steps on the work order, each one tickable, independent of the work order's own status. 1. Expand **Checklist** in the left column. 2. Type a step into the input and press Enter. A **Task added** toast confirms it. 3. Tick a step to complete it. Select its text to rename it, or the trash icon to delete it. The section header carries the item count, so a collapsed checklist still shows how much work the job was broken into. Ticking every item changes nothing about the status: closing the work order is still a separate action in the status row. Any failure in this section reads **Issues updating tasks**, and the list reloads from the server. ![The expanded Checklist section of the work-order drawer showing four steps, the first two ticked and struck through, and an input row for adding another step](/images/maintain/mnt-detail-04.webp) *A checklist on the work order.* Use a checklist when the job has steps that somebody could get wrong or skip, for example lock out, drain, replace seal, refill, run for 10 minutes. You do not need one when the description already says it in a sentence. ## 5. Attachments The drawer keeps pictures and documents apart, in two collapsible sections that both show their count in the header. **Images** takes pictures only. Each one is converted to WebP in the browser before it uploads, so a phone photo does not arrive at full size. On a phone the section offers the camera directly. **Attached Files** takes anything else: a PDF manual, a spreadsheet, a vendor quote. Each row shows the file name and its size, and files can be dropped onto the section as well as picked. Select a row to download it, or its delete control to remove it. Deletes confirm with **File deleted** or **Image deleted**. An upload that fails reads **Failed to upload file.** or **Error uploading file.**, and a delete that fails reads **Failed to delete file** or **Failed to delete image**. Dropping a mixed selection onto **Images** skips the non-images and names them in the toast. ## 6. Comments **Comments** is a chat room attached to the work order, not a list of notes. Messages travel over MQTT, so one posted in this drawer appears in everybody else's drawer without a refresh. ![The Comments panel in the work-order drawer, scrolled back through a thread of three timestamped messages, with a composer at the bottom and the round jump-to-latest button outlined above it](/images/maintain/mnt-detail-05.webp) *Comments are a chat thread attached to the work order. Scrolling back puts a jump-to-latest button in the corner, which carries the unread count when there is one.* A message can be replied to, reacted to with an emoji, or pinned. Scrolling back through the thread loads older messages as you go. Unread comments show as a blue count on the jump-to-latest button in the bottom right of the panel. Your read position advances on its own as you scroll to the newest message, and there is no way to mark a thread unread again. The panel appears only on work orders that have a chat room. The full messaging surface, including direct messages and organization channels, is [Messaging](/docs/messaging/overview/). ## 7. The activity log The *activity log* is the organization's audit trail filtered to this one work order. Expand **Activity Logs** at the bottom of the left column. ![The expanded Activity Logs section of the work-order drawer showing a three-column table of Log, Event and Date rows describing file uploads, a status change, a due-date change and an assignee being added, each tagged Modified, with a 1 to 10 of 11 pager underneath](/images/maintain/mnt-detail-06.webp) *The activity log for this work order.* It is a three-column table, **Log**, **Event**, and **Date**, ten rows per page. It answers who changed the status, when the assignee changed, and when the due date moved, which is the argument a disputed work order usually turns on. The same entries appear in the organization-wide [Audit log](/docs/admin/audit-log/), mixed in with every other event. Use this section when you care about one work order, and the audit log when you care about a person or a day. ## 8. Complete and confirm materials Selecting the fourth button, **Completed**, sets the status to **Done** and ends the job. If the work order lists nothing in **Parts Required** or **Create/Release Parts**, it closes immediately with a **Task completed!** toast. If it lists parts on either side, a **Complete work order** dialog opens first. ![The Complete work order dialog, titled with a boxes icon, listing a Parts Consumed group with two part rows showing quantities and stock locations and an Added to Inventory group with one row, above Cancel and Complete buttons](/images/maintain/mnt-detail-07.webp) *The completion dialog lists what closing the work order takes out of stock and what it adds back. It is read-only: the backend moves the stock when the status flips to Done.* The dialog states the consequence of closing, in both directions: **Parts Consumed** is what will come out of stock, and **Added to Inventory** is what will go back in, each with its quantity and its stock location. A reusable tool appears in the second list because closing the job hands it back rather than manufacturing it. The dialog is read-only, and it writes nothing itself. If a quantity is wrong, select **Cancel**, fix the line in **Parts Required** or **Create/Release Parts** on the work order, and select **Completed** again. Selecting **Complete** flips the status, and the movement is performed on the backend at that moment. The full accounting is in [How work orders move stock](/docs/inventory/how-work-orders-move-stock/). ## 9. Approve An *approval* is a sign-off recorded as the fifth status: the work is done and somebody has checked it. Select **Approved**. Nothing else happens: stock moved at **Done**, and no report or schedule keys off **Approved** today. It is a record that a second person looked. You do not need this status if your team has no review step. Treat **Done** as the end of the line and leave the fifth button alone, rather than half your board sitting in a state nobody applies consistently. ## 10. Field visibility The **Properties** list is configurable. Select the gear icon beside the **Properties** heading to open **Show/Hide Fields**, a grid of ten checkboxes: **Due Date**, **Duration**, **Recurrence**, **Assignees**, **Group**, **Notes**, **Asset**, **Requested**, **Created On**, and **Last Updated**. ![The Show/Hide Fields menu open above the Properties list, a two-column grid of ten labeled checkboxes with a Reset link at the top right and a blue Done button underneath](/images/maintain/mnt-detail-08.webp) *Field visibility is stored on this device and does not sync.* All ten are on by default except **Last Updated**. **Reset** returns the list to those defaults, and **Done** closes the menu. > **Info:** > **Why does a colleague see a field I hid?** The setting is stored in this browser on this device and is never sent to IoTFlows, so it does not follow you to a second computer or to the phone, and it changes nothing for anyone else. Hiding a field also hides only the row: the value stays on the work order and still appears in exports and on the board. ## 11. On mobile Tapping a card on the maintenance screen opens the same drawer full screen, with the same `selected_wo` parameter behind it. The back arrow at the top left returns to the board. The layout is the stacked one: the title, the status row, the description, then **Properties**, then the collapsible sections, with **Comments** inline underneath. Everything on this page works there, including the completion dialog. The camera is offered directly in the **Images** section. ## See also - [Work order fields](/docs/maintain/work-order-fields/), every field in the drawer and what it feeds - [How work orders move stock](/docs/inventory/how-work-orders-move-stock/), what **Done** does in Inventory - [Organize work on the maintenance board](/docs/maintain/maintenance-board/), the four views the drawer opens over - [Messaging](/docs/messaging/overview/), the chat surface behind **Comments** --- # Work order fields and statuses Source: https://www.iotflows.com/docs/maintain/work-order-fields/ Every field a maintenance work order can hold, the five statuses it moves through, how priorities work, and the 15 columns the maintenance table exports. Only a title and a group are required, and the time estimate is the one field you cannot change after the work order exists. Two statuses are spelled differently in the CSV than on screen: Open exports as Not Started and Done exports as Completed. Column, card, and density preferences are stored per device. # Work order fields and statuses Every field, status, priority, and export column on a maintenance work order. A maintenance work order is one record. A request from the floor, a planned job, and a recurring preventive maintenance schedule are all the same object with different fields filled in, which is why one field list covers all three. See [Overview: maintenance management](/docs/maintain/overview/). Only two fields are required: **Title** and **Group**. Everything else can stay empty, and nearly everything else can be changed later from the work-order drawer. > **Info:** > **Looking for production job fields?** > > Those are on [Job and scheduler fields](/docs/production/job-fields-reference/). Production tasks and maintenance work orders share one API and the same five statuses, and little else: a maintenance work order carries a group, a checklist, and a recurrence, while a production task carries an operation, a part, a quantity, and work sessions. ## Fields **Required** means the **Create** button stays disabled until the field has a value. **Inline editable** means you can change the value in place in the [work-order drawer](/docs/maintain/work-order-detail/#inline-edit), with no Save step. **In CSV** is the maintenance table export, listed column by column under [CSV export columns](#csv). | Field | Type | Required | Inline editable | In CSV | |---|---|---|---|---| | **WO #** | Number, assigned by IoTFlows | Automatic | No | Yes, as **WO #** | | **Title** | One line of text | **Yes** | Yes, the large text at the top of the drawer | Yes | | **Description** | Rich text, with its own file attachments | No | Yes | Yes, with formatting stripped | | **Group** | One maintenance group, created inline if none fits | **Yes** | Yes | Yes | | **Status** | One of five | Starts at **Open** | Yes, from the status row | Yes | | **Priority** | One entry from the platform's priority list | No | Yes, from the chip above the title | Yes | | **Asset** | One machine | No | Yes | Yes | | **Assignees** | People and teams | No | Yes, as many as you need | Yes, as **Assigned To** | | **Due date** | Date, time, and the timezone it is read in | No | Yes | Yes, as **Due Date** | | **Recurrence** | A repeat rule anchored to the due date | No | Yes | Yes, as **Recurrence** | | **Time estimate** | Minutes, typed as `2h`, `30m`, or `1.5d` | No | **No**, set at create only | Yes, as **Estimated Time (min)** | | **Notes** | Plain text | No | Yes | Yes | | **Parts Required** | Inventory lines, each a part and a quantity | No | Yes | No | | **Create/Release Parts** | Inventory lines | No | Yes | No | | **Checklist** | Tickable steps, independent of the status | No | Yes | No | | **Images** | Pictures, converted to WebP on upload | No | Yes | No | | **Attached Files** | Anything that is not an image | No | Yes | No | | **Comments** | A chat room attached to the work order | No | Yes | No | | **Requested By** | The person who created it | Automatic | No | Yes | | **Created At** | Timestamp | Automatic | No | Yes | | **Last Updated** | Timestamp, moved by any edit | Automatic | No | Yes | Three things about that table are worth saying in sentences. **The time estimate is a create-time field.** The create modal asks for it, and the maintenance drawer shows it as plain text with no way in, so a work order created with the wrong estimate keeps it. The same field is editable on a production task, in the scheduler's drawer. **A group is required, and a fresh organization has none.** The first work order you create forces you to name a group before anything else. See [Group](/docs/maintain/create-a-work-order/#group). **Recurrence is a rule, not an object.** There is no separate preventive maintenance record: the rule lives on the work order and fires from its due date. See [Schedule preventive maintenance](/docs/maintain/preventive-maintenance/). ## Statuses Five statuses, in the order the work is meant to move through them. Nothing enforces that order: any status can go to any other, including reopening a closed work order. The flow, and what each transition does, is in [The status flow](/docs/maintain/work-order-detail/#status). | Status | Means | Drawer button | In CSV | Next states | |---|---|---|---|---| | **Open** | Created, not started. Every work order lands here, whichever origin created it | **Not Started** | `Not Started` | Any | | **In Progress** | Somebody is working on it now | **In Progress** | `In Progress` | Any | | **On Hold** | Started and blocked. It keeps its assignee and stays on the board | **On Hold** | `On Hold` | Any | | **Done** | The work is finished. Moves stock if the work order lists parts | **Completed** | `Completed` | Any, including back to **In Progress** | | **Approved** | Signed off, after the work was done | **Approved** | `Approved` | Any | > **Warning:** > **Why does the CSV say Not Started when the board says Open?** > > The export renames two statuses on the way out. **Open** is written `Not Started` and **Done** is written `Completed`, which matches the drawer's buttons rather than the board card, the status filter, or a report. If you pivot an export by status, filter on the CSV spellings in the table above, not the ones on screen. ## Priorities Priority is a colored label. It does not sort the board, does not change what the completion dialog moves, and triggers nothing automatically. The list is the platform's, not your organization's. It arrives from IoTFlows with a name and two colors, one for light mode and one for dark, and Maintain has no editor for it, so you cannot add a priority or rename one. Two behaviors surprise people: - **The create modal preselects the first priority in the list** and hides its label while it is selected. A work order where nobody touched the priority chip carries that first priority, not an empty one. - **The drawer's chip only appears when the work order has a priority.** A work order created by an automatic origin, from a classified downtime or a meter reaching its trigger point, can arrive with none, and then there is no chip above the title until you set one. You do not need a priority on every work order. Set one when the board is long enough that a technician has to choose what to pick up next, and leave it alone on a board where the due dates already say that. ## CSV export columns The **CSV** button in [Table view](/docs/maintain/maintenance-board/#export) writes `maintenance-tasks-` and today's date. Fifteen columns are available. Four are always exported, six more ship visible, and the other five are ones you turn on in the column picker. **The export follows the table, not this list.** It writes the columns the table is showing, in the order you dragged them, so a default download is 10 of the 15. The numbering below is the default order. | No. | Column header | Source field | Always exported | |---|---|---|---| | 1 | **WO #** | `workorder_number` | Yes | | 2 | **Title** | `workorder_title` | Yes | | 3 | **Assigned To** | `assigned_to_users`, `assigned_to_teams` | Yes | | 4 | **Asset** | `workorder_asset` | Yes | | 5 | **Group** | `workorder_group.group_name` | No, visible by default | | 6 | **Status** | `workorder_status_uuid` | No, visible by default | | 7 | **Priority** | `workorder_priority.workorder_priority_name` | No, visible by default | | 8 | **Due Date** | `workorder_due_timestamptz` | No, visible by default | | 9 | **Recurrence** | `workorder_recurrence_description` | No, visible by default | | 10 | **Description** | `workorder_description` | No | | 11 | **Estimated Time (min)** | `workorder_duration_min` | No | | 12 | **Requested By** | `created_by_user` | No | | 13 | **Notes** | `workorder_notes` | No | | 14 | **Last Updated** | `workorder_updated_at` | No, visible by default | | 15 | **Created At** | `workorder_created_at` | No | How the values are written: - **WO #** carries the hash, for example `#148`, so a spreadsheet reads it as text rather than a number. - **Assigned To** lists people's full names first, then team names, comma separated. A placeholder account named `Unnamed` is skipped. - **Asset** is the machine's custom name, falling back to its catalog model name when it has none. - **Due Date**, **Last Updated**, and **Created At** are full UTC timestamps, for example `2026-09-18T14:00:00.000Z`, not the local time the card shows. - **Description** and **Notes** have their formatting stripped to plain text. - **Recurrence** is the sentence the server writes for the rule, for example `Every 2 weeks on Mon, Thu`, not the individual rule fields. - **Estimated Time (min)** is a plain number of minutes. An empty cell means no estimate was set, or that an unparseable one was discarded at create time. Parts, checklist items, attachments, and comments have no column. Nothing in the maintenance export carries them, so a checklist is readable only in the drawer. For every other export in the product, see [Exports reference](/docs/monitoring/exports-reference/#board-csvs). ## What is stored per device Maintain keeps your view preferences in this browser, on this device. None of them are sent to IoTFlows, so they do not follow you to a second computer or to the phone, and they change nothing for anybody else looking at the same board. | Preference | Where you set it | Default | |---|---|---| | Table columns and their order | The column picker in Table view | The four always-on columns plus **Group**, **Status**, **Priority**, **Due Date**, **Recurrence**, **Last Updated** | | Kanban card fields | **Card fields** in Kanban | Everything except **Description** and **Due Date** | | Drawer **Properties** fields | The gear beside **Properties** | All ten except **Last Updated** | | Density | The **Compact view** / **Large view** toggle, per view | List and Table compact, Kanban large | | Last view and last grouping | Selecting a view or a grouping | **To do**, grouped by asset | Two consequences follow. **Two people export different files from the same board**, because the export reads the table columns and each person's are their own, so agree the columns before comparing files. And **clearing your browser data resets all five**, which is the fastest way back to the defaults above if a board has drifted. Hiding a field hides the row, never the value. A hidden **Notes** row still holds its text, and a column turned off in the table is still on the work order. ## See also - [Update, discuss, and close a work order](/docs/maintain/work-order-detail/), where most of these fields are edited - [Create a maintenance work order](/docs/maintain/create-a-work-order/), where they are first set - [Organize work on the maintenance board](/docs/maintain/maintenance-board/#table), the table these columns come from - [Exports reference](/docs/monitoring/exports-reference/#board-csvs), every other CSV and PDF in the product - [Job and scheduler fields](/docs/production/job-fields-reference/), the same reference for production tasks --- # Manage chat members and settings Source: https://www.iotflows.com/docs/messaging/manage-a-chat/ How to administer an IoTFlows chat from its info panel: select the chat's name in the header to open the panel, which carries the chat picture and name, an Add button, a More menu, and the Members, Media, Files, and Voice tabs. Edit renames a group and changes its picture, capped at 80 characters, and any member can do it. Add Members picks people and teams from the selected organization or accepts a full handle like maria:acme. Hovering a member row exposes Make Owner, Remove Owner, and Delete, none of which the web client gates on ownership. Leave removes only you and keeps the chat for everyone else; Delete Chat is shown to either side of a direct chat and removes the chat and its history for both of them; the dashboard offers no Delete Chat on a group, so a group is deleted from iOS or Android. Read receipts run on iOS and Android in direct chats only, as one check for sent and two for read; the web shows none, and no group shows any. # Manage chat members and settings Rename a group, change who is in it, and leave one properly. Everything on this page happens in a chat's info panel, the same panel for a direct chat and a group. A *chat owner* is a member who can delete the chat for everyone; a group can have several, and the rest of the membership is flat. **Before you start:** have a group chat. See [Start a direct or group chat](/docs/messaging/start-a-chat/). ## Open chat info 1. Select **Messaging** in the navigation to open `/chats`. 2. Select the chat in the list. 3. Select the chat's picture or its name in the header. **More** in the same header, then **Info**, does the same thing. The panel replaces the thread. At the top sit the chat picture and name, then **Add** and **More**, then four tabs: **Members**, **Media**, **Files**, and **Voice**. **Back** at the top left returns you to the messages. A direct chat has no **Add** button and no **Edit**, because its membership and its name are both fixed. See [Chat types](/docs/messaging/start-a-chat/#types). ![The info panel of a group chat with five members, showing the group picture and name, the Add and More buttons, and the Members tab listing each member with their handle](/images/messaging/msg-manage-01.webp) *The chat info panel.* The **Media**, **Files**, and **Voice** tabs list everything anyone has ever attached to the chat. See [Browse a chat's media, files, and voice notes](/docs/messaging/share-files-and-voice-notes/#browse). ## Who can do what | Action | Member | Owner | |---|---|---| | Rename the group and change its picture | Yes | Yes | | Add members, including from another organization | Yes | Yes | | Remove a member | Yes | Yes | | Make or remove an owner | Yes | Yes | | Leave the chat | Yes | Yes | | Delete the chat | No | Yes, but not from the dashboard | > **Warning:** > **Why can I see controls I am not supposed to use?** > > **Make Owner**, **Remove Owner**, and **Delete** appear on every member row for everyone, including on your own row, and the server decides whether the request goes through. Treat the rows above as the intent, not as a lock. > > The dashboard's group **More** menu is **Edit** and **Leave** and nothing else, so an owner cannot delete a group from the web. Delete a group from iOS or Android. A direct chat is the reverse: its **More** menu is **Delete Chat** alone. ## Rename a group and set its image 1. Select **Edit** at the top right of the info panel, or **More** and then **Edit**. 2. Type the new name. The field holds 80 characters and stops there. 3. Optional: select the picture square above the name, then upload and crop an image for the group. 4. Select **Done**. A toast reads **Chat updated**. **Done** stays inactive while the name is empty, so a group cannot be left unnamed. The new name and picture reach everyone in the chat, not only you. ![The Edit view of a group chat's info panel, with the group picture square above a focused name field holding the group name](/images/messaging/msg-manage-02.webp) *Renaming a group and setting its image.* ## Add members 1. Select **Add** in the info panel. The **Add Members** dialog opens. 2. Pick people from **Users** and teams from **Teams**. Both lists come from the organization you have selected. 3. Optional: type into **Who would you like to add?** to filter the two lists by name, handle, or email. 4. Select **Add Members**. Everyone you pick becomes a blue chip above the lists, and **Add Members** stays inactive until there is at least one. Anyone already in the chat is dimmed in the list and cannot be picked twice. Adding a team adds it as one row in **Members** rather than as its people, so the chat follows the team. See [Create and manage teams](/docs/admin/teams/). ## Add someone from another organization Type their whole handle into the search field, including the organization after the colon, then press Enter. A comma or Tab does the same thing. The lookup is exact rather than a search, so `maria` alone finds nothing and `maria:acme` fails if their organization's handle is `acme-mfg`. A handle that does not exist reports **No matches found**, and a handle you have already added reports **User already added**. See [Add someone from another organization](/docs/messaging/start-a-chat/#external). An external member carries a small orange marker on the bottom right of their avatar in **Members**. Hovering their name lists the organizations they belong to. ## Remove a member 1. Open the **Members** tab. 2. Hover the member's row. **Make Owner**, **Remove Owner**, and **Delete** appear on the right. 3. Select **Delete**, in red. There is no confirmation step: the row disappears and a toast reads **User has been removed**, or **Team has been removed** for a team. Everything that person wrote stays in the thread, and they keep no access to the chat. ![A member row in the Members tab under the pointer, with Make Owner, Remove Owner, and a red Delete revealed at the right of the row](/images/messaging/msg-manage-03.webp) *Removing a member from a group chat.* To put them back, add their handle again. ## Owners An owner is marked by a green shield on the top right of their avatar, labeled **Owner** on hover. Ownership decides one thing: who sees **Delete Chat**. Hover a member row and select **Make Owner** or **Remove Owner**. A toast reads **Owner Added** or **Owner Removed**, and the shield appears or disappears on the row. Both buttons show on every row whatever the row's current state, so read the shield rather than the buttons. Give a group a second owner while the first is still in it. A group whose only owner leaves has nobody who can delete it. ## Read receipts Read receipts are a mobile feature, and they cover direct chats only. | Where | What a message you sent shows | |---|---| | Web | Nothing, in either chat type | | iOS and Android, direct chat | One check once the message reaches IoTFlows, two checks once the other person has read it | | iOS and Android, group chat | Nothing. The signal describes one other reader, so a group has nothing to say | Every client reports how far you have read, whatever it displays. That position is stored against the chat rather than against the device, so reading a thread on the web clears its unread count on your phone and reopens it at the same **Unread Messages** divider. See [The chat list and unread counts](/docs/messaging/search-messages/#list). A message that has not reached IoTFlows yet shows a clock instead of a check. See [When you lose connection](/docs/messaging/send-messages/#offline). ## Leave a chat 1. Select **More** in the info panel or in the chat header. 2. Select **Leave**. 3. Read the dialog, which names the chat, and select **Leave**. A toast reads **Left chat with** the chat's name, the chat drops off your list, and the dashboard returns to `/chats`. The chat, its history, and your messages stay exactly as they are for everyone else. You cannot rejoin by yourself: someone still in the chat has to add your handle again. **Leave** appears on groups only. A direct chat offers **Delete Chat** instead. ![The info panel of a group chat with the More menu open, showing Edit and Leave, with Leave highlighted](/images/messaging/msg-manage-04.webp) *A group offers Leave. The chat stays exactly as it is for everyone else.* ## Delete a chat 1. Select **More** in the info panel or in the chat header. 2. Select **Delete Chat**, in red. 3. Read the dialog, which names the chat, and select **Delete**. A toast reads **Chat deleted** and the dashboard returns to `/chats`. The chat disappears for every member, taking its messages, its pins, and its attachments out of reach. On a direct chat, either person can delete it, and it goes for both of them. **On a group, the dashboard offers no Delete Chat at all**, to an owner or to anyone else: the group **More** menu carries **Edit** and **Leave** only. Delete a group from iOS or Android, where the owner check runs against a payload that carries it. ![The info panel of a direct chat with the More menu open, showing Delete Chat as its only item, highlighted](/images/messaging/msg-manage-05.webp) *A direct chat offers Delete Chat instead. There is no Leave.* > **Info:** > **Leaving or deleting?** > > Leave a chat rather than deleting it when other people still need the history, which is almost always the case on a group that ran for any length of time. Deleting removes it for everyone, and there is no way back. Delete when the chat was a mistake, for example a group created against the wrong handle before anyone posted to it. Nothing in the dashboard brings a deleted chat back, so move anything worth keeping before you delete: download the attachments you need, and put the decision in the work order it belongs to. See [Chat versus work-order comments](/docs/messaging/overview/#chat-vs-comments). ## See also - [Start a direct or group chat](/docs/messaging/start-a-chat/) - [Create and manage teams](/docs/admin/teams/) - [Search and organize your chats](/docs/messaging/search-messages/) - [Switch organizations](/docs/get-started/switch-organizations/) - [Share photos, files, and voice notes](/docs/messaging/share-files-and-voice-notes/) --- # Overview: messaging in IoTFlows Source: https://www.iotflows.com/docs/messaging/overview/ IoTFlows carries two kinds of conversation: chats, which hang off the people in them and live at /chats on web and natively in both mobile apps, and work-order comments, which hang off one job. This page says which one a message belongs in, and explains cross-organization chats and the orange badge that marks them. # Overview: messaging in IoTFlows What chat is for, and when a work order's comments are the better place to write. IoTFlows carries two kinds of conversation, and they never meet. A chat hangs off the people in it; a work order's comments hang off the job. Which one you pick decides whether the next person to touch that machine ever reads what you wrote. ## What chat is A *chat* is a conversation between people you choose: one other person, or a group. Every chat holds exactly one *thread*, the running list of messages inside it. There are no channels, and no sub-thread hanging off a single message. A chat belongs to one organization. The list at `/chats` is the list for the organization you are signed into, and switching organizations switches the list. See [Switch organizations](/docs/get-started/switch-organizations/). In a thread you can send text, replies, photos, videos, files, and voice notes, pin a message, and react to one. Each has its own page, linked at the end. ## Chat versus work-order comments Every work order carries its own thread, on the **Comments** tab of the work-order drawer. It behaves like a chat, but it is attached to the work order rather than to a list of people. See [Update, discuss, and close a work order](/docs/maintain/work-order-detail/#comments). *Chat threads are attached to people; comment threads are attached to a work order.* | | Chat | Work-order comments | |---|---|---| | Attached to | The people you add | One work order | | Where you open it | **Messaging** in the top navigation, at `/chats` | The **Comments** tab on the work order | | What belongs in it | Anything: a shift handover, a question about a part, a photo of a leak | Everything about that one job | | Found again by | Opening the chat | Opening the work order | | Unread shows as | A count on the chat's row in the list | A blue count on the jump-to-latest button | > **Info:** > **Chat or comments?** > > Put anything about a specific work order in that work order's comments. A decision made in chat is invisible to the technician who picks the job up next week, and the work order is the thing they open. > > Everything else belongs in chat: the question that has no work order yet, the handover note, the photo somebody needs to look at before anyone raises a job. > > You probably do not need a group chat per machine. A question about one job already has a home on that job. ## Cross-organization chat A chat can include people from outside the organization you are in. An *external organization* is any organization in the chat other than the one you have selected: a contractor, a customer, or another of your sites that IoTFlows runs as its own organization. You add their people by handle, the same way you add a colleague. A *handle* is a username qualified by its organization, written `maria:acme`. See [Start a direct or group chat](/docs/messaging/start-a-chat/). IoTFlows marks those chats so nobody posts to the wrong audience. An orange badge in the chat header carries the outside organization's logo and name, and members from outside are marked in the chat's member list. With more than one outside organization in the chat, the badge stacks up to three logos and drops the names. Hovering it lists them all under **Outside your organization**. ## Where chat appears | Client | Where | |---|---| | Web | **Messaging** in the top navigation, at `/chats` | | Android | Natively in the app | | iOS 18 and later | Natively in the app | | iOS 17 and earlier | The same web dashboard, opened inside the app | The phone notifies you when a message arrives, including from organizations you are not signed into. See [Get push notifications](/docs/alerts/mobile-push/#what-sends). What a chat holds offline, and what becomes of a message you send with no connection, differs by platform. See [What works without a connection](/docs/get-started/offline-behavior/). ## See also - [Quickstart: start a chat with your team](/docs/messaging/quickstart/) - [Start a direct or group chat](/docs/messaging/start-a-chat/) - [Send, reply to, edit, and delete messages](/docs/messaging/send-messages/) - [Update, discuss, and close a work order](/docs/maintain/work-order-detail/#comments) - [Get push notifications on your phone](/docs/alerts/mobile-push/) --- # Pin messages and add reactions Source: https://www.iotflows.com/docs/messaging/pin-and-react/ Pin a chat message from its own menu, either for everyone with Pin for All or for yourself with Pin for Me: pinned messages surface in a banner under the chat header and in a Pinned Messages list, and unpinning from either place removes the pin for whoever holds it. Reactions come from the emoji row that opens above the same menu, or from a searchable picker behind its chevron, and each person's reaction is one emoji they can take back by selecting their own chip. # Pin messages and add reactions Keep the message that matters findable, and acknowledge one without typing. A *pin* is a marker on one message that lifts it into a banner under the chat header and into the chat's Pinned Messages list. Pins and reactions both start from the message's own menu: right-click the message on the web dashboard, or press and hold it on a touch screen. **Before you start:** have a chat to work in. See [Start a direct or group chat](/docs/messaging/start-a-chat/). ## Pin for the chat 1. Right-click the message. On a touch screen, press and hold it. 2. Select **Pin for All**. Every member of the chat gets the banner, and the message picks up a small pin icon next to its timestamp. No role is required, and the message does not have to be yours: anyone in the chat can pin anyone's message, and anyone can unpin it. ![The message menu open over a chat thread, showing the two pin entries in the middle of the list. Numbered callout 1 marks Pin for All and callout 2 marks Pin for Me](/images/messaging/msg-pin-01.webp) *Pinning for the whole chat, or just for yourself.* ## Pin for yourself 1. Right-click the message, or press and hold it. 2. Select **Pin for Me**. You get the banner and the pin icon; nobody else sees either, and nothing tells the chat that you kept the message. ## Pin scopes | Scope | Visible to | Appears in | |---|---|---| | **Pin for All** | Every member of the chat, including members from another organization | The pinned banner and the **Pinned Messages** list, for everyone | | **Pin for Me** | You, on every client you sign in to | The pinned banner and the **Pinned Messages** list, in your view only | > **Info:** > **Which pin do you want?** > > Pin for the chat when everyone needs the message: the drawing, the part number, the address of the site the crew is driving to. Pin for yourself when only you need to come back to it, so you are not editing everyone else's banner to keep your own note. ## The pinned banner and list The banner sits directly under the chat header as soon as the thread has one pin, reading **Pinned Message**, or **Pinned Message #1**, **#2** and so on when there is more than one. - Select the row to scroll the thread to that message. The banner moves on to the next pin, so repeated selections cycle through them. - Select the **X** to unpin. - Select the pin icon at the right to open **Pinned Messages**, the full list. Select **Back** to return to the conversation. That list is a thread of its own, so the message menu works there too: right-click an entry for **Unpin**, **Reply**, **Copy Text**, and the [delete actions](/docs/messaging/send-messages/#delete-options). ![A chat thread with a banner under the header reading Pinned Message over a single truncated line of the pinned message, with an X and a pin icon at its right. The banner is highlighted](/images/messaging/msg-pin-02.webp) *The pinned banner at the top of the thread.* > **Warning:** > **Unpinning is not scoped the way pinning is** > > Both the banner's **X** and the list's **Unpin** remove the pin the message actually carries. If the message is pinned for the chat, either one unpins it for every member, even if you also pinned it for yourself. There is no way to drop only your own pin on a message the chat has pinned as well. ## React with the quick row 1. Right-click the message, or press and hold it. 2. Select an emoji from the row that floats above the menu. The reaction lands under the message as a chip carrying the emoji and small avatars of the people who chose it. Once a message has five reactions or more, the chips show a number instead of the avatars. Select a chip to join that reaction. Select the chip you are already in to take your reaction back. Each person's reaction is a single emoji, so choosing a second one replaces the first. The row holds a default set that IoTFlows sends with the chat. Inside the mobile app's web view it shows the first seven of them, and the rest sit behind the picker. ![A rounded row of eight emoji floating above an open message menu in a chat thread, ending in a chevron button that opens the full emoji picker](/images/messaging/msg-pin-03.webp) *The quick reaction row, floating above the message menu.* ## Find any emoji 1. Open the message menu and select the chevron at the end of the reaction row. 2. Type into **Search Emojis...**, or scroll the sections below it. 3. Select the emoji. The picker opens in place of the row and the menu, so the menu's other actions leave the screen while it is up. Dismiss it and right-click the message again to reach them. The picker reaches the whole set, grouped under section headings. What you type goes to IoTFlows rather than filtering the panel locally, so the search covers every emoji the platform carries, not the handful in the row. Type `wrench` instead of scrolling the tool section. > **Warning:** > **Pin or reaction did not stick?** > > Chat rides a live connection of its own. When it is down, pinning reports **Waiting for Network** and a reaction reports **Trying to connect**, which is the same fault under a second string. Nothing is saved in either case, so do it again once the connection returns. See [What works offline](/docs/get-started/offline-behavior/). ## In a work order's comments A work order's **Comments** tab is a chat thread, so it carries the same pinned banner, the same **Pinned Messages** list, and the same reactions. Pin the measurement the next technician needs rather than repeating it. See [Work order detail](/docs/maintain/work-order-detail/#comments). ## On mobile Chats are native on Android and on iOS 18 and later, where a long press opens the same menu with the same pin entries and reaction row. On iOS 17 and earlier the app opens the dashboard's web view, so these steps apply as written. See [Install the mobile app](/docs/get-started/install-mobile-app/). ## See also - [Send, reply to, edit, and delete messages](/docs/messaging/send-messages/) - [Search and organize your chats](/docs/messaging/search-messages/) - [Manage chat members and settings](/docs/messaging/manage-a-chat/) - [Share photos, files, and voice notes](/docs/messaging/share-files-and-voice-notes/) --- # Quickstart: start a chat with your team Source: https://www.iotflows.com/docs/messaging/quickstart/ Send your first IoTFlows message end to end: open Messaging at /chats, start a direct chat by picking a colleague out of the Users list, type into the Write a message box and press Enter, then answer what comes back by right-clicking the message and choosing Reply. # Quickstart: start a chat with your team One chat, one message, one reply. A *chat* is a conversation between people you choose. This page walks the shortest path: open the chat list, start a direct chat with one colleague, send a message, and reply to their answer. **Before you start:** sign in to the dashboard on the web. See [Sign in to IoTFlows](/docs/get-started/sign-in/). For the same job on a phone, see [On mobile](/docs/messaging/start-a-chat/#mobile). ## Open Chats 1. Select **Messaging** in the top navigation. The dashboard opens `/chats`. 2. Read the list on the left, headed **Messages**. Each row is one chat, and the count on a row is how many messages in it you have not read. 3. Select a row to open that chat's thread on the right. The list holds the chats for the organization you are signed into. See [Switch organizations](/docs/get-started/switch-organizations/). ![The chat list at /chats showing seven chats, the top row carrying an unread count of 1, with the compose button beside the Messages heading](/images/messaging/msg-qs-01.webp) *The chat list at /chats, headed Messages, with an unread count on the one row holding unread messages and the compose button at its top right.* ## Start a chat 1. Select the compose button at the top right of the **Messages** heading. The left pane switches to the new-chat view. 2. Find the person. Everyone in your organization is listed under **Users**, your teams above them under **Teams**, and the **Search** field narrows both lists as you type. 3. Select their row. IoTFlows creates the chat and opens its empty thread. There is no confirmation step and nothing to name. If you pick the wrong person, the empty chat stays in the list until you open its info panel and select **Delete Chat**. See [Manage a chat](/docs/messaging/manage-a-chat/). > **Info:** > **One question, or a standing team?** > > You do not need to create a group for a one-off question. Start a direct chat. Groups are for teams that keep talking, like the second-shift maintenance crew. > > To reach someone outside your organization, type their *handle*, a username qualified by its organization, into **Search**, for example `maria:acme`, and press **Enter**. See [Start a direct or group chat](/docs/messaging/start-a-chat/). ![The new-chat panel with the Search field highlighted and the Teams and Users lists below it](/images/messaging/msg-qs-02.webp) *The new-chat panel, with the Search field at the top and the organization's people listed below it under Users.* ## Send a message 1. Select the box at the bottom of the thread, which reads **Write a message...**. 2. Type what you want to say, for example `Line 3 press is down, I'm heading over now`. 3. Press **Enter**. The message appears at the bottom of the thread with the time under it. Shift+Enter starts a new line instead of sending, so a two-line note goes out as one message. > **Warning:** > **Nothing sent, and a "Waiting for Network" toast?** > > Messages travel over a live connection the dashboard holds open in the background, separate from loading the page. If it has dropped, the send fails with **Waiting for Network** and your text stays in the box. Wait a few seconds and press **Enter** again. ![A single sent message bubble at the bottom of an otherwise empty thread, showing the message text and the time it was sent](/images/messaging/msg-qs-03.webp) *A sent message in the thread, aligned right in its own bubble with the send time beneath it.* ## Reply A *reply* is a message that carries a quote of the one it answers. Use it once a thread covers two things at once. 1. Right-click the message you are answering. On a phone or tablet, press and hold it instead. 2. Select **Reply**. A preview of that message appears above the message box. 3. Type your answer and press **Enter**. The reply posts with the quote attached, and selecting the quote jumps to the original. To drop the quote before sending, select the **X** on the preview. The same menu carries **Copy Text**, **Edit**, and the two delete actions. See [Send, reply to, edit, and delete messages](/docs/messaging/send-messages/). ## See also - [Start a direct or group chat](/docs/messaging/start-a-chat/) - [Send, reply to, edit, and delete messages](/docs/messaging/send-messages/) - [Share files, photos, and voice notes](/docs/messaging/share-files-and-voice-notes/) - [Overview: messaging in IoTFlows](/docs/messaging/overview/) --- # Search and organize your chats Source: https://www.iotflows.com/docs/messaging/search-messages/ Find a message again in IoTFlows chat: the Search Messages box above the chat list searches every chat you belong to in the selected organization and waits for you to stop typing, the magnifier in a chat's header searches only that chat and fires on every keystroke, and either result jumps the thread to the message and flashes it blue for a second. A chat's unread count clears when you reach the bottom of the thread, not when you open it, and on web the list column drags between 300 and 500 px wide without remembering the width. # Search and organize your chats Find a message you remember, and keep the unread count worth reading. Chat gives you one list and two searches. The list at `/chats` says what is waiting, the box above it searches every chat you belong to, and the magnifier in a chat's header searches only the chat that is open. All three read the organization selected in the header, so a message in another organization needs [a switch first](/docs/get-started/switch-organizations/). **Before you start:** have a chat to open. See [Start a direct or group chat](/docs/messaging/start-a-chat/). ## The chat list and unread counts The list runs down the left of `/chats`. Each row carries the chat's picture, its name, when the last message arrived (a time today, a date before that), one line of that message, and a gray pill counting what you have not read. A direct chat is named for the other person, a group for the group. The list is ordered by activity. A new message moves its chat to the top and adds one to the pill, unless you sent it or already have that chat open. Opening a chat with unread messages does not drop you at the newest one. The thread opens where you stopped reading, under an **Unread Messages** divider. ![The chat list column at /chats, with a gray unread count pill on the top row](/images/messaging/msg-search-01.webp) *The chat list at /chats, with a gray unread count on the right of the one row holding unread messages.* The pill clears when you reach the bottom of the thread, not when you open it. While you are scrolled up, a down-arrow button at the bottom right of the thread carries a blue count: select it to jump to the newest message, which clears the pill too. Leave a chat halfway and the pill keeps whatever is still below you. There is no mark-as-unread, no mute, and no archive, so the count stays honest only if you read a thread to the bottom or leave it alone. A work order's comment thread is a chat of its own, and the reliable way back to it is to open the work order. See [Chat versus work-order comments](/docs/messaging/overview/#chat-vs-comments). ## Search across every chat 1. Select **Messaging** in the navigation to open `/chats`. 2. Type into the **Search Messages...** box above the list. The results replace the list. Search covers every chat you belong to in the selected organization, direct and group, and it waits for a pause in your typing before it runs. Each result names the chat it came from, the time of the message, and the matching text. A file sent with no message of its own shows a paperclip and the file name, so `torque-spec-rev-c.pdf` is findable by name months later. ![The Search Messages box above the chat list, with message results from three chats listed below it](/images/messaging/msg-search-02.webp) *The Search Messages box above the chat list, with results from three different chats replacing the list.* Selecting a result clears the box, opens that chat, and scrolls the thread to the message, flashing it blue for about a second. A message older than what the thread has loaded is fetched with its neighbors first, so you land on it in context. A query that matches nothing returns "No search results found" in place of the list. Clearing the box brings the chat list back. > **Info:** > **Searched the wrong box?** > > The search box in the site header looks for records, not messages. Message search lives above the chat list and nowhere else. See [Global search](/docs/get-started/navigate-the-dashboard/#search). ## Search inside one chat 1. Open the chat. 2. Select the magnifier at the top right of the chat header, to the left of the **...** menu. 3. Type into the **Search Messages...** bar that slides down under the header. This search reads only the open chat, and it runs on every keystroke. Each result shows who sent the message, its text or file name, and its time. Selecting one jumps the thread to that message with the same blue flash. ![The search bar open under a chat header, listing matching messages from that chat with each sender's name](/images/messaging/msg-search-03.webp) *The in-thread search bar under a chat header, with matches from that chat listed by sender.* The bar stays open, so you can jump to one match and come back for the next. Select the **X** at its right to clear the text and close the bar. Unlike the list search, this one has no empty state: a query that matches nothing shows nothing. > **Info:** > **Which search do you want?** > > Search inside the chat when you remember who said it, and globally when you only remember what was said. Global search across a busy organization returns more than you can read, so a two-word query like `bearing arrived` beats `bearing` by itself. ## Resize the pane The border between the chat list and the thread is a drag handle 8 px wide. Hover it until the pointer changes, then drag sideways. The list opens at 300 px, which is also its minimum, and stops at 500 px. The width is not saved. Returning to `/chats` later puts the list back at 300 px. You do not need this. Widen the list only when the names you are scanning are cut off, for example when several chats start "Line 4 Changeover". On mobile the list and the thread each fill the screen and swap as you open and close a chat, so there is no handle to drag. ## See also - [Send, reply to, edit, and delete messages](/docs/messaging/send-messages/) - [Pin messages and add reactions](/docs/messaging/pin-and-react/) - [Navigate the dashboard](/docs/get-started/navigate-the-dashboard/#search) - [Manage chat members and settings](/docs/messaging/manage-a-chat/) --- # Send, reply to, edit, and delete messages Source: https://www.iotflows.com/docs/messaging/send-messages/ Work a thread in IoTFlows chat: type into the Write a message box and press Enter to send, then right-click any message (long press on a touch screen) for Reply, Edit, Delete for Myself, and Delete for Everyone. Edit and Delete for Everyone appear only on your own messages, neither delete asks for confirmation, an unsent draft is saved per chat and reappears on your other devices, and every one of these actions travels over MQTT, so all of them fail together behind a Waiting for Network toast. # Send, reply to, edit, and delete messages Say something, quote something, and correct something. Everything on this page happens in an open chat: the thread filling the page at `/chats`, with the composer under it. Replying, editing, and deleting all start the same way, from the message's own menu. **Before you start:** have a chat to write in. See [Start a direct or group chat](/docs/messaging/start-a-chat/). Chat does not use the dashboard's REST API. Sends, edits, deletes, pins, and reactions all publish over MQTT, the live connection that also delivers other people's messages to you. That is worth telling support, because it explains why all of them fail together while the rest of the dashboard keeps loading. ## Send a message 1. Select the chat in the list on the left. 2. Type into the box at the bottom, headed **Write a message**. 3. Press Enter. Shift+Enter starts a new line instead of sending. The smiley button to the right of the box inserts an emoji at the cursor, and the paperclip and camera buttons open the attachment flow. See [Share files and voice notes](/docs/messaging/share-files-and-voice-notes/). Your message appears in the thread the moment you press Enter, dimmed, and turns solid when the server confirms it. A message that stays dimmed has not reached anyone. ## Reply to a message 1. Right-click the message you are answering. On a touch screen, press and hold it for a moment. 2. Select **Reply**. 3. Type your answer and press Enter. A blue bar appears above the composer while you write, carrying the name of the person you are answering and the line you are answering. Select the **X** at its right to drop the reply and send an ordinary message instead. The reply lands in the thread with that quoted line above your own text. Selecting the quote scrolls the thread back to the original message and highlights it for a second, which is how someone reading tomorrow finds the question your answer belongs to. ![A sent message in a chat thread, carrying above its own text a quoted line in a tinted box with the original sender's name over a single line of their message](/images/messaging/msg-send-01.webp) *Replying quotes the message you are answering.* ## Edit a message 1. Right-click your own message and select **Edit**. 2. Change the text in the composer, which opens holding what you wrote. 3. Press Enter. **Edit** appears only on messages you sent. There is no time limit, and the edited text replaces the original for everyone in the chat. The bar above the composer reads **Edit Message** while you work. Select the **X** on it to abandon the edit and leave the message as it was. Starting an edit cancels a reply you had lined up, and starting a reply cancels an edit, so the composer is only ever doing one of the two. ![The chat composer in edit mode, with a pencil icon and the label Edit Message above the box, the original text loaded into the box, and an X to cancel at the right](/images/messaging/msg-send-02.webp) *Editing a message you sent.* ## Delete options | Option | Removes for | Reversible | |---|---|---| | **Delete for Myself** | You. Every other member keeps the message. Available on anyone's message, including your own. | No | | **Delete for Everyone** | Every member of the chat. Available on your own messages only. | No | Neither option asks you to confirm, and neither can be undone. The message disappears from the thread as soon as you select it. > **Info:** > **Which delete do you want?** > > Delete for everyone when the message was wrong: the part number, the machine, the date. Delete for yourself when it was merely noise in your own view. Deleting for everyone takes a turn out of the conversation with no marker left behind, which is the right outcome for a correction and the wrong one for tidying, because the replies that quoted it stay where they are. ## Delete a message 1. Right-click the message. On a touch screen, press and hold it. 2. Select **Delete for Myself** or **Delete for Everyone**. ![The message menu open over a chat thread, with a row of emoji reactions floating above it. The menu lists Reply, Copy Text, Pin for Me, Pin for All, Edit, then Delete for Myself and, in red, Delete for Everyone. Numbered callout 1 marks Delete for Myself and callout 2 marks Delete for Everyone](/images/messaging/msg-send-03.webp) *Delete for Myself removes the message from your view only. Delete for Everyone removes it for every member of the chat.* The same menu carries **Copy Text**, which puts the message on your clipboard, and the two pin actions. A row of emoji opens above the menu at the same time, for reacting without selecting anything from the list. See [Pin messages and add reactions](/docs/messaging/pin-and-react/). ## Drafts A *draft* is text you have typed into a chat's composer and not sent. IoTFlows saves it per chat as you type and puts it back when you open that chat again, on the web dashboard and on your phone alike. Nobody else sees it. Keeping a draft takes no action. Leave the chat, close the tab, or open the conversation on your phone, and the half-written sentence is waiting. Clearing the box clears the draft. A draft only saves while you are connected. Text typed during an outage stays on screen, with nothing to tell you it was not stored, and leaving the chat loses it. ![A chat thread whose composer holds an unsent half-written message, with the send button active and no message added to the thread above it](/images/messaging/msg-send-04.webp) *Drafts follow you between devices.* ## When you lose connection The web dashboard queues nothing. If the live connection is down when you press Enter, IoTFlows shows **Waiting for Network**, publishes nothing, and leaves your text in the box so you can send it again once the connection returns. Deleting and pinning report the same thing. Adding a reaction reports **Trying to connect**, which is the same condition under a different string. Android is the exception: it holds messaging actions you take while offline in an *outbox*, a queue that publishes them in order once you are back. iOS keeps no queue. See [What works offline](/docs/get-started/offline-behavior/). > **Warning:** > **"Waiting for Network" on a page that otherwise works?** > > Chat rides its own connection, so reports and the asset list keep loading while messaging is down. Reload the tab. If the toast comes back, tell support that the MQTT connection is not establishing, rather than treating it as a sign-in problem. See [Get support](/docs/get-started/get-support/). ## On mobile Chats are native on Android and on iOS 18 and later, where the message menu opens with a long press and carries the same actions. On iOS 17 and earlier, the app opens the dashboard's web view, so these steps apply as written. See [Install the mobile app](/docs/get-started/install-mobile-app/). ## See also - [Pin messages and add reactions](/docs/messaging/pin-and-react/) - [Share files and voice notes](/docs/messaging/share-files-and-voice-notes/) - [Search messages](/docs/messaging/search-messages/) - [What works offline](/docs/get-started/offline-behavior/) - [Start a direct or group chat](/docs/messaging/start-a-chat/) --- # Share photos, files, and voice notes Source: https://www.iotflows.com/docs/messaging/share-files-and-voice-notes/ Attach a photo, a document, or a recorded voice note to an IoTFlows chat from any client: on the web dashboard the paperclip beside the composer opens Photo or Video, File, and Camera, and the preview that follows carries the compressed-versus-original choice, where compressed caps the longest side at 1600 px and arrives as a thumbnail under Media while an original arrives as a download row under Files. Voice notes record by holding the microphone, iOS and Android add slide-left-to-cancel and slide-up-to-lock, and both phones can share a photo in from another app, which the web cannot. # Share photos, files, and voice notes Get an image, a document, or a recorded note to your team from any client. Every attachment travels the same way: pick it, look at the preview, send it. Two things change the outcome. Whether an image goes compressed or at full resolution decides how it arrives, and which client you are on decides what you can attach at all. **Before you start:** have a chat open. See [Start a direct or group chat](/docs/messaging/start-a-chat/). ## Send a photo or video 1. Open the chat. 2. Select the paperclip to the left of the composer. 3. Select **Photo or Video**. 4. Pick one or more images, or a video. 5. Type a note into the **Type a message...** box if you want one. 6. Select the send arrow. Dragging files from your desktop onto the open thread opens the same preview, which is faster than the menu when the file is already on screen. ![The chat composer's paperclip menu open over the Write a message box, listing Photo or Video, File, and Camera, with a highlight box around the paperclip that opened it](/images/messaging/msg-file-01.webp) *Attaching a photo or video.* Send several at once and each one becomes its own message, and the note you typed is repeated under every one of them. A reply you had lined up attaches to the first. ## Compressed or original Two buttons sit at the top left of the preview, and the one in blue is the one that will be used. The picture icon is **Send in a quick way**, which compresses. The document icon is **Send without compression**, which sends the file you picked, byte for byte. Compressing caps the longest side at 1600 px and re-encodes the image as WebP, which is why a phone photo sent this way lands in the thread in a moment. Send the original when someone will zoom into it: a nameplate, a crack, a wiring detail. Send compressed for everything else. The original is slow on plant Wi-Fi and nobody waits for it. The choice also decides how the image arrives. A compressed image appears in the thread as a picture you can open, and it is listed under **Media** in chat info. An original arrives as a file row with a download button, no thumbnail, and it is listed under **Files**. ![The attachment preview dialog showing an image, with two icon buttons at its top left: numbered callout 1 marks the picture icon that compresses, and callout 2 marks the document icon that sends the original](/images/messaging/msg-file-02.webp) *Send the original when someone will zoom into it. Compressed for everything else.* > **Warning:** > **Sending a video?** > > Select **Send without compression** first, because the browser's compression step handles still images only. > > If the preview closes and nothing appears in the thread, that is what happened: pick the video again and send it without compression. ## Send a file 1. Select the paperclip, then **File**. 2. Pick one or more files. 3. Check the names and sizes listed in the preview. 4. Select the send arrow. The browser's chooser applies no type filter, so a PDF, a spreadsheet, a DXF, and a firmware binary all go. If everything you picked is a JPEG, PNG, GIF, WebP, or SVG, the compress button appears here too, set to original. ## Take a photo in the app Select the paperclip, then **Camera**. The browser asks for permission the first time, your webcam appears, and **Capture** freezes a still that lands in the usual preview. Use this for a whiteboard or a printed work instruction sitting next to the laptop. For anything you have to walk to, use the phone: its camera reaches the machine and the laptop does not. The web capture is a still image, so recording video is a phone capability. ## Record a voice note A *voice note* is an audio message recorded in the composer and posted to the thread like any other message. 1. Empty the composer. The microphone button appears only when there is no text in it. 2. Hold the microphone down. It turns red and pulses while it records. 3. Release to stop. 4. Play the recording back in the player that replaces the composer. 5. Select the send arrow, or the **X** to throw it away. Nothing is posted until you send it, so a recording you dislike costs nothing. In the thread, a voice note arrives as a play button, a waveform, and its length. The waveform is drawn from the audio itself the first time anyone plays it, so it looks flat until then. ![Two voice notes in a chat thread under a PDF attachment, each one a circular play button, a bar waveform beside it, and the recording's length underneath](/images/messaging/msg-file-03.webp) *A voice note with its waveform.* On iOS and Android, hold the microphone in the same place, then slide left to cancel the recording or slide up to lock it so you can stop holding. Releasing goes to the same preview the web shows. ![An iOS chat screen recording a voice note: the microphone button is enlarged, a running clock and a Slide to cancel hint fill the composer row, and an arrow marks the hold gesture on the button](/images/messaging/msg-file-05.webp) *Hold to record a voice note on mobile.* ## Share from another app A photo you just took in the camera app, or a PDF a supplier emailed you, can go straight into IoTFlows without opening it. On iOS this is a *share extension*: a small piece of the app that the system share sheet runs, which uploads the attachment and posts the message over its own connection rather than waking the full app. 1. Select **Share** in the app holding the file. 2. Select **IoTFlows**. 3. Under **Create as**, select **Send as Message**. 4. Under **Attach as**, select **Images** or **Files**. 5. Select **Continue**, then pick the chat. **Create as** also routes to **Maintenance Request**, which opens the request form with the attachment staged. See [Submit a maintenance request](/docs/maintain/submit-a-request/). iOS adds **Production Work Order** as a third destination; Android offers the first two. The web dashboard is not a share target. Dragging a file onto an open thread is the closest thing a browser has. Diagram: A diagram in three stages, left to right. A box reading 'Another app: Photos, Files, a supplier's email' has an arrow into a box reading 'IoTFlows share sheet: Create as, then Attach as Images or Files'. Three arrows leave it: to 'Send as Message, pick a chat, posts into the thread', to 'Maintenance Request, opens the request form with the files staged', and to 'Production Work Order, iOS only'. A line underneath reads: the web dashboard is not a share target, drag a file onto the thread instead. *The share sheet routes: another app to IoTFlows, then to a chat or a maintenance request.* ## Browse a chat's media, files, and voice notes Select the chat's name or picture in the header to open chat info. Four tabs run across it: **Members**, **Media**, **Files**, and **Voice**. | Tab | Holds | |---|---| | **Media** | Compressed images, as a grid of thumbnails. Select one to open it full size. | | **Files** | Everything sent without compression: documents, videos, and original-quality images. | | **Voice** | Voice notes, each with its own player. | Each tab loads the most recent items and fetches older ones as you scroll. An empty one says so: "No images have been shared in this chat." An image sent as an original is under **Files**, not **Media**, which is where people go looking for a photo they know they sent. ![The chat info panel with the Media tab open, showing a grid of shared image thumbnails. Numbered callouts mark the Media, Files, and Voice tabs across the top](/images/messaging/msg-file-04.webp) *Everything shared in a chat, browsable by type.* ## Download and save On the web, every attachment carries a download control: the round button on a file or voice bubble in the thread, the download control in the expanded image, or the row itself under **Files**. The file arrives wherever your browser puts downloads, under the name it was sent with. On iOS, open the image or video and select **Share** for **Save Video**, **Save to Files**, or AirDrop. On Android, open the image and select **Save to phone**, which writes it into `Pictures/IoTFlows` or `Movies/IoTFlows` and reports progress in a system notification. Tapping a document on Android downloads it and hands it to whichever app opens that type, rather than keeping a copy in your files. ## Attachment types | Type | Web | iOS | Android | Size or format notes | |---|---|---|---|---| | Photo | Yes, compressed or original | Yes, always compressed | Yes, compressed or original | Web compression caps the longest side at 1600 px and writes WebP. iOS re-encodes to JPEG at a low quality setting with no original option. Android compresses to WebP unless you check **Send original (no compression)**. | | Video | Yes, uncompressed only | Yes | Yes | Arrives in the thread as a file row on the web, and is listed under **Files** on every client. | | Any other file | Yes | Yes | Yes | The browser's chooser enforces no type filter and no size limit. Several at once is fine. | | Camera capture | Yes, still photo | Yes, photo or video | Yes, photo or video | Web capture uses the webcam at its own resolution. Android splits the choice into **Take photo** and **Record video**. | | Voice note | Yes, hold the microphone | Yes | Yes | Phones add slide left to cancel and slide up to lock. | | Shared in from another app | No | Yes | Yes | iOS offers three destinations, Android two. | You do not need the phone app to share files. Everything except the share sheet and video capture works in the browser, so a planner at a desk never has to install anything. ## When an upload fails | What you see | What happened | |---|---| | **Failed to upload file.** | The upload was rejected or threw. Nothing was posted to the chat. Send it again. | | **An error occurred while uploading the file.** | The connection dropped part way through. The progress bar stops and no message appears. | | **Waiting for Network** | The file reached storage, but chat's live connection was down when IoTFlows tried to post the message, so nobody sees it. See [Send messages](/docs/messaging/send-messages/#offline). | | **Error downloading file:** | The download link could not be issued. Reload the tab and select the download again. | A voice note is the one case with no toast. If it fails, its bubble sits in the thread at whatever progress it reached and never turns into a message. Record it again. ## See also - [Send, reply to, edit, and delete messages](/docs/messaging/send-messages/) - [Submit a maintenance request](/docs/maintain/submit-a-request/) - [What works offline](/docs/get-started/offline-behavior/) - [Manage chat members and settings](/docs/messaging/manage-a-chat/) - [Install the mobile app](/docs/get-started/install-mobile-app/) --- # Start a direct or group chat Source: https://www.iotflows.com/docs/messaging/start-a-chat/ Start any IoTFlows conversation from the compose button on the chat list at /chats: pick one person or team out of the Users and Teams lists for a direct chat, select New Group to gather several and name them, or type a full handle like maria:acme to pull in someone from another organization, which marks the chat with an orange external badge. # Start a direct or group chat Direct, group, and cross-organization conversations. Every chat starts in the same place, the compose button on the chat list at `/chats`. What you pick next decides whether the conversation is between two people, a standing group, or a thread that spans two organizations. You pick people by handle. A *handle* is a username qualified by its organization, written `maria:acme`. An *external organization* is any organization in a chat other than the one you have selected: a contractor, a customer, or another of your sites that IoTFlows runs as its own organization. **Before you start:** sign in to the dashboard. See [Sign in to IoTFlows](/docs/get-started/sign-in/). A chat belongs to the organization you have selected, so switch first if you are in the wrong one. See [Switch organizations](/docs/get-started/switch-organizations/). ## Chat types | Type | Members | Can add external | Renameable | |---|---|---|---| | Direct | You and one handle you pick, either a person or a team. Membership is fixed once the chat exists. | Yes, when the handle you pick belongs to another organization | No | | Group | You and every handle you select, with members added and removed afterward | Yes, as many handles as you need | Yes, from the chat's info panel | Both types carry the same messages, replies, attachments, and pins. See [Send, reply to, edit, and delete messages](/docs/messaging/send-messages/). ## Start a direct chat 1. Select **Messaging** in the top navigation, then the compose button at the top right of the **Messages** heading. 2. Find the person. Your organization's people are listed under **Users** and your teams above them under **Teams**. The **Search** field narrows both lists on a name, a username, an email address, or a handle, so `maria`, `maria@acme.com`, and `maria:acme` all find the same person. 3. Select their row. IoTFlows creates the chat and opens its empty thread. Selecting a **Teams** row starts the chat with the team instead of one person, which is how you reach a crew whose shift you do not know. See [Teams](/docs/admin/teams/). A direct chat has no name, no confirmation step, and no way to add a third person later. If you picked the wrong row, open the chat's info panel and select **Delete Chat**. ![The new-chat panel with text typed into the Search field and the matching people listed under Users, each row showing a name above its handle](/images/messaging/msg-start-01.webp) *Starting a direct chat with someone in your organization.* ## Start a group chat 1. Open the compose view and select **New Group**. 2. Select everyone you want in the group. Each one becomes a chip in the field at the top of the screen, headed **Select Users**, and selecting a chosen row again takes them back out. 3. Remove a chip by selecting the **X** on it. With the field empty, Backspace highlights the last chip and a second Backspace deletes it. 4. Select **Next** to name the group. **Next** stays inactive until at least one member is selected. A group can mix people and teams, and members can be added and removed after the chat exists. See [Manage chat members and settings](/docs/messaging/manage-a-chat/). > **Info:** > **One group per machine?** > > You do not need a group per machine. Machine-specific conversation belongs in the work order's comments, where the next technician finds it. Group chats are for the people who work together, not for the equipment they work on. ![The Select Users screen of the group flow with four chosen members shown as chips above the list, and the Next button active at the top right](/images/messaging/msg-start-02.webp) *Creating a group chat.* ## Add someone from another organization 1. Ask the person for their handle. Everyone finds their own on their profile page. See [Update your profile and handles](/docs/admin/profile/). 2. Type the whole handle into the search field, including the organization after the colon. 3. Press Enter. A comma or Tab does the same thing. The lookup is exact rather than a search: IoTFlows checks whether that one handle exists. In the direct flow a match creates the chat immediately. In the group flow it lands as a chip alongside the members you picked from the list, and adding the same handle twice reports **User Already Added**. Someone from another organization you have chatted with before is already in the **Users** or **Teams** list, with a small marker on their avatar. Anyone new has to be typed in full. > **Warning:** > **"No matches found" under the search field?** > > No account carries that handle. Check the spelling of both halves, and check that you typed the organization part: `maria` alone is not a handle, and `maria:acme` fails if their organization's handle is `acme-mfg`. ![The group flow's member field with an external handle accepted as a chip, sitting next to two members picked from the organization's own list](/images/messaging/msg-start-03.webp) *Adding someone from another organization by handle.* > **Info:** > **Why not email?** > > Add a vendor or customer by handle rather than emailing them a PDF. Cross-organization chat keeps the thread with the work, and everyone who joins later reads the whole history. Email does not. Once the chat exists, its header carries an orange badge with the outside organization's logo and name, so nobody posts to the wrong audience. See [Cross-organization chat](/docs/messaging/overview/#cross-org). ![The header of an open chat, with the chat name on the left and an orange pill to its right carrying an organization logo and the organization's name](/images/messaging/msg-start-04.webp) *The orange badge in the chat header that marks a chat spanning two organizations.* ## Name a group 1. Type into **Group Name** on the **New Group** screen. A name is required, and it stops at 80 characters. 2. Optional: select the image square to the left of the name, then upload and crop a picture for the group. 3. Select **Create**. IoTFlows creates the chat and opens its thread. **Create** stays inactive while the name is empty. Name the group after the standing job, not after today's members: `Second-shift maintenance` still reads correctly in six months, `Maria and Jon` does not. Any member can rename a group later, and change its picture, from the chat's info panel. See [Manage chat members and settings](/docs/messaging/manage-a-chat/). ## On mobile Chats are native on Android and on iOS 18 and later. On iOS 17 and earlier, the app opens the dashboard's web view, so the steps on this page apply as written. See [Install the mobile app](/docs/get-started/install-mobile-app/). ## See also - [Manage chat members and settings](/docs/messaging/manage-a-chat/) - [Send, reply to, edit, and delete messages](/docs/messaging/send-messages/) - [Update your profile and handles](/docs/admin/profile/) - [Switch organizations](/docs/get-started/switch-organizations/) - [Overview: messaging in IoTFlows](/docs/messaging/overview/) --- # Add a machine Source: https://www.iotflows.com/docs/monitoring/add-an-asset/ Create a machine as an asset in IoTFlows: pick its catalog model, set the name and identifier your plant uses, assign a department, and add tags. # Add a machine Create the machine record that a sensor's data reports into. An *asset* is one machine as IoTFlows tracks it: a catalog model, a name, an identifier, a department, and the sensor that reports its status. Nothing in Machine monitoring has data for a machine until that machine exists as an asset. You create assets one at a time from the Assets page. **Before you start** - Sign in as an Organization Owner or Organization Administrator. Other roles see the **Add asset** button but cannot open it. See [Roles reference](/docs/admin/roles-reference/). - Nothing else. The asset does not need a sensor to exist. See [Pair a sensor](#pairing). ## Open Add asset 1. Go to **Assets** at `//assets`. 2. Select **Add asset** at the top of the page. ![The Add asset button in the Assets page toolbar](/images/monitoring/mon-add-01.webp) *The Add asset button sits at the top right of the Assets page toolbar, beside Edit Assets.* The **Add Asset** modal opens on **Select Sensor**. Skip it: select **Skip, I'll do this later.** to reach the catalog. ## Find the machine in the catalog The catalog is the shared list of machine models IoTFlows already knows. Each entry carries a photo, a model identifier, and a manufacturer, and picking one is what gives the asset card its picture and model line. 1. Select **Find or add a machine...** and type part of the model or the manufacturer, for example `VF-2`. 2. Select the machine from the results. ![The Find or add a machine field showing catalog search results](/images/monitoring/mon-add-02.webp) *The Find or add a machine field searches the IoTFlows catalog and returns matching models with a photo and manufacturer. Every asset starts from a model in this list.* The catalog is the one field you cannot change after saving. Every other field on this page is editable from the asset's **Edit** modal. See [Edit, hide, archive, or delete a machine](/docs/monitoring/edit-assets/). > **Note:** > **Model not in the catalog?** The search covers the whole IoTFlows catalog, not only models your organization already runs. If nothing matches, pick the closest model from the same manufacturer, then set **Machine Name** and **Machine Identifier** to your own values. Those two fields and the photo are what operators read on the board, so the catalog entry matters less than it looks. To have your exact model added, [contact IoTFlows support](/docs/get-started/get-support/). ## Name and ID Two fields carry your plant's own vocabulary onto every screen. 1. In **Machine Identifier**, type the number your plant uses for this machine, for example `trx-as800`. 2. In **Machine Name**, type the name operators say out loud, for example `Haas VF-2 #3`. ![The Machine Identifier and Machine Name fields filled in, with numbered callouts](/images/monitoring/mon-add-03.webp) *Machine Identifier and Machine Name sit below the selected catalog model. Set the identifier to whatever your plant already paints on the machine.* Set the custom asset ID to whatever your plant already paints on the machine. Every export, every report and every operator conversation uses that number, and a system that invents its own gets translated by hand forever. Both fields are optional, and leaving **Machine Name** blank costs you. The asset then falls back to the catalog model name, so a shop with four Haas VF-2s gets four cards reading `Haas VF-2`. ## Assign a department A *department* is the single grouping every asset must have, for example `Machining` or `Welding`. The Assets page filters by it and the utilization reports group rows by it. 1. Select **Select Department**. 2. Pick an existing department, or type a new name and press Enter to create it. Creating a department here creates it for the whole organization, and IoTFlows confirms with "Department has been added". Department is required: **Add Asset** stays disabled until you pick one. Choose the departments you would want as section headings in a report you hand to a plant manager. If a split only ever matters as a filter, make it a tag instead. ## Add tags A *tag* is a free-text label, and one asset can carry any number of them. 1. Select **Tags**. 2. Pick a tag from the list of tags already used in your organization, or type a new one and press Enter or Tab. 3. Repeat for each tag you want. ![The Tags field of the Add Asset modal with two tags applied](/images/monitoring/mon-add-04.webp) *The Tags field holds any number of labels as removable chips, for filters the department field cannot express.* You do not need tags on day one. Add them when you first want a filter the department field cannot express, for example `5-axis` across three departments, or `lease-return-2027` on the six machines going back. ## Pair a sensor An asset reports no status, no uptime and no production until a sensor is tied to it. You do not do this yourself, and the **Select Sensor** step in the **Add Asset** modal is not the way in. Skip that step. Contact IoTFlows to tie your sensors to an asset. See [Get support](/docs/get-started/get-support/). Tying a sensor to an asset does not calibrate it. A SenseAi reports raw signal until it is calibrated against the machine. See [Calibrate a SenseAi sensor](/docs/hardware/calibrate-senseai/). ## Save and verify 1. Select **Add Asset**. 2. Wait for the confirmation "Asset has been added". The modal closes and the Assets page reloads. 3. Find the new card on the Assets page and check that the name and identifier read the way your plant says them. 4. If a sensor is already tied to this asset, check that the card reads as live rather than gray within a few minutes. **Add Asset** stays disabled until you have selected both a machine and a department. If the button is active and the save still fails, the modal shows the message the server returned, or "Something went wrong" when there is no message. Nothing is saved in that case. See [Troubleshoot wrong utilization or OEE](/docs/monitoring/troubleshoot-monitoring/). ## Add asset fields | Field | Required | Accepts | Used by | Changeable later | |---|---|---|---|---| | Sensor | No | Skip this step | Status, uptime, downtime, production counts | Contact IoTFlows | | Machine (catalog) | Yes | One entry from the IoTFlows machine catalog | Card photo, model line, manufacturer logo | No | | **Machine Identifier** | No | Free text, for example `trx-as800` | Exports, reports, search | Yes, in the asset's **Edit** modal | | **Machine Name** | No | Free text | Every card, board, report and work order | Yes, in the asset's **Edit** modal | | **Select Department** | Yes | One department, existing or newly typed | Assets page filter, report grouping | Yes, in the asset's **Edit** modal | | **Tags** | No | Any number of free-text labels | Assets page filter | Yes, in the asset's **Edit** modal | ## See also - [Edit, hide, archive, or delete a machine](/docs/monitoring/edit-assets/) - [Group machines into cascades](/docs/monitoring/asset-groups/) - [Calibrate a SenseAi sensor](/docs/hardware/calibrate-senseai/) - [Control who sees which machines](/docs/admin/machine-access/) --- # Build a utilization report Source: https://www.iotflows.com/docs/monitoring/advanced-report/ The Advanced Report totals uptime, downtime and unknown hours for a set of machines over a period, as KPI cards, a stacked bar per interval, a pie and a row per machine grouped by department. Pick a rolling preset or a custom range at a daily to yearly interval, filter by machine and shift, exclude Unknown and None from the utilization figure, switch to only-uptime or percent view, and export the result as CSV or PDF. # Build a utilization report Put a number on how much your machines ran over a period, and find the machine that drags it down. The Advanced Report is the utilization report: how many hours each machine ran, how many it did not, and what share of the period that is. It answers the monthly and quarterly questions that the live Assets page cannot, because it covers a period you choose rather than the current shift. The page is at `/assets?select=advanced_report`. **Prerequisites.** Machines reporting, see [Monitor your fleet on the Assets page](/docs/monitoring/assets-overview/). Every figure on this page is defined in [Metrics](/docs/monitoring/metrics-reference/). ![The Advanced Report over the last four weeks. A filter bar shows Machines 5, Shifts, Sort by Name (A to Z), Group by Department and Reset Filters on the left, and Exclude Unknown, Exclude None, Only Uptime and Percent switches, an Actions menu and a Last 4 weeks date button on the right. Four KPI cards read Total Utilization 64.76%, Uptime Hours 2,176.07h, Downtime Hours 1,183.93h and Unknown Hours 0.00h. Below them a stacked bar chart shows one bar per week, W34 to W37, with uptime in blue and downtime in red, beside a pie with 64.76% in its center. Under the charts, five machine rows are grouped under two department headings, Machining and Production.](/images/monitoring/mon-adv-01.webp) *The utilization report over the last four weeks, with machines grouped by department.* ## Read the report Four KPI cards sit above the charts. **Total Utilization** is the share of the period the machines ran, **Uptime Hours** and **Downtime Hours** are the totals behind it, and **Unknown Hours** is time no sensor was reporting. *Utilization* here is availability, the same measure the Assets page calls uptime, see [Metrics](/docs/monitoring/metrics-reference/). The stacked bar chart splits every interval of the period into uptime, downtime and unknown, so you can see whether the number moved. For example, at a weekly interval over 12 weeks, a plant that lost a week to a plant shutdown shows one bar that is nearly all red, and the surrounding bars tell you whether that was the exception. The pie next to it carries the same three totals for the whole period, with the utilization percentage in its center. Every time on this page is in the organization's time zone, not yours. The line under the filter bar names it, see [Shifts and time zone](/docs/admin/shifts-and-timezone/). ## Choose what the number includes Four switches at the right of the filter bar change what the utilization figure counts and how the charts draw it. ![Four toggle switches in a row at the right of the Advanced Report filter bar, labeled Exclude Unknown, Exclude None, Only Uptime and Percent, all off](/images/monitoring/mon-adv-02.webp) *The four report switches: Exclude Unknown, Exclude None, Only Uptime and Percent.* ### Switches reference | Switch | What it does | Recomputes | |---|---|---| | **Exclude Unknown** | Removes unknown time from the utilization calculation | Yes | | **Exclude None** | Removes downtime of severity **None** from the utilization calculation | Yes | | **Only Uptime** | Draws only the uptime series on the bar charts, dropping downtime and unknown | No, display only | | **Percent** | Labels every bar as a percentage of its interval instead of hours | No, display only | *Unknown* time is any stretch where the sensor was powered off or had lost its connection. It counts toward neither uptime nor downtime, and the **Unknown Hours** card and the gray band on every chart carry it as its own bucket. For example, a machine whose SenseAi was unplugged for a weekend shows 48 unknown hours, not 48 hours of downtime. A machine with a large unknown figure has a connectivity problem, not a production one, see [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). *None* is a downtime severity, given to categories whose stops are not a loss. The purpose of None is legally required breaks: a mandated one-hour lunch is downtime on the sensor, but no one is accountable for it. Which categories carry it is set in [Manage downtime categories](/docs/monitoring/downtime-categories/). Exclude Unknown and None when you are comparing machines or holding someone to a number. A machine that lost Wi-Fi for two days and a department that takes a longer mandated break both look worse than they are with the switches off. Leave them in when the question is where the shift actually went, because a number that excludes the lunch hour and the dead sensor no longer adds up to the length of the shift. **Only Uptime** and **Percent** change nothing about the figures. They redraw the charts from data already loaded, so flipping them costs no wait, and they are recorded in the report's URL so a shared, scheduled or PDF copy renders the same way. ## Find the machine that drags the number down Under the charts is one row per machine: its photo, name, identifier and department, its own stacked bar per interval, its own pie, and its uptime, downtime and unknown hours for the period. Click a row to open the machine, see [Inspect a single machine](/docs/monitoring/asset-detail/). ![Five machine rows on the Advanced Report grouped under three department headings, Machining, Production and Sheetmetal, sorted worst performing first. Each row shows a machine photo, a name such as Doosan 2600 with its identifier TXV-2600, a small stacked bar chart per week, a small pie with the machine's utilization percentage, and uptime, downtime and unknown hours in blue, red and gray. The Doosan 2600 reads 12.51% and the DMG DMU 65 under it reads 93.36%.](/images/monitoring/mon-adv-03.webp) *Per-machine rows grouped by department, which is where a single bad machine shows up.* Two controls in the filter bar order the rows. **Sort by** offers **Name (A to Z)**, **Name (Z to A)**, **Top Performing** and **Worst Performing**. Choose **Worst Performing** when the fleet number has dropped and you want to know which machine did it: the row at the top is the answer. For example, a machining department whose DMG DMU 65 runs at 93.36% while the Doosan 2600 beside it runs at 12.51% has one problem, not a department-wide one. **Group by** has one option, **Department**, which puts a dashed heading over each department's machines. Choose it when you report to department leads, so each reads their own block. You do not need it for a single department. ## Set the period and filters The date button at the far right of the filter bar opens the period picker. It has two parts: an interval, and a range. 1. Pick an interval: **Daily**, **Weekly**, **Monthly**, **Quarterly** or **Yearly**. One bar on the chart is one interval. 2. Pick a range. The presets change with the interval, and each is a rolling window, so the same report reopened next week shows next week's data. 3. For fixed dates, click **Custom range** and pick a start and end. A custom range is frozen and reopens on the same dates. | Interval | Presets | |---|---| | **Daily** | **Last 7 days**, **Last 14 days**, **Last week (Mon - Sun)** | | **Weekly** | **Last 4 weeks**, **Last 6 weeks**, **Last 8 weeks**, **Last 12 weeks** | | **Monthly** | **Last 3 months**, **Last 6 months**, **Last 9 months**, **Last 12 months** | | **Quarterly** | **Last 2 quarters**, **Last 4 quarters**, **Last 8 quarters** | | **Yearly** | **Last 2 years**, **Last 3 years**, **Last 5 years** | Choose a rolling preset for a report someone opens every week or receives on a schedule. Choose a custom range for a before-and-after comparison, for example the four weeks before a spindle rebuild and the four weeks after, where the dates must not move. **Machines** narrows the report to selected departments or individual machines. **Shifts** counts only time inside the shifts you tick, so a night-shift report excludes the day shift's hours. **Reset Filters** clears the machine, shift, sort and group settings and keeps the period and the exclude switches. ### Shift islands The **Shift islands** toggle at the top of the **Shifts** popover decides where an overnight shift's hours land. Off, which is the default, the report splits the shift at midnight: a 10:00 PM to 5:00 AM shift reports two hours on its start date and five on the next. On, all seven hours report on the start date. Turn it on whenever you are reporting a shift that crosses midnight. It changes nothing for a shift that does not, so leaving it on costs a day-shift report nothing. For what the split does to the numbers, see [Where the overnight hours land](/docs/admin/shifts-and-timezone/#overnight-hours). Like the shift ticks, the toggle takes effect on **Apply**, and **Clear** resets it along with the shift selection. While it is on, the report carries an **Islands** badge on the collapsed **Shifts** button, which is the only place the setting is visible once the popover closes. Turning it on also hides **All Day (24/7)** from the list, and clears it if you had it ticked. A 24-hour window has no start day to move hours onto, so the two settings cannot both apply. ![The Shifts popover open on the Advanced Report. A row labeled Shift islands with an information icon sits at the top, its switch turned on and blue. Below it an ALL SHIFTS heading counts 4, over the shifts Day Shift, Evening Shift, Third Shift and Weekend Shift, with Evening Shift ticked. There is no All Day (24/7) row. Clear and Apply buttons sit at the bottom, and the Shifts button behind the popover carries a blue Islands badge.](/images/monitoring/mon-adv-05.webp) *The Shift islands toggle sits at the top of the Shifts popover. Turning it on hides All Day (24/7), because a 24-hour window has no start day to move hours onto.* The setting travels with the report everywhere it goes. A shared link, a scheduled email, a PDF and a CSV are all built from the report's URL, so the recipient opens the report you built. The **Report Summary** in the share and schedule dialogs names the setting in both states, and the CSV title block records it when it is on, see [Share and schedule reports](/docs/monitoring/share-and-schedule-reports/) and [Available exports](/docs/monitoring/exports-reference/#advanced-csv). ## Export the report The **Actions** menu at the right of the filter bar downloads the report in two forms, both using the filters and switches you have set. What each export carries is listed in [Available exports](/docs/monitoring/exports-reference/). ### Export formats | Format | Contains | Where it goes | |---|---|---| | **CSV** | A header block naming the date range, time zone, shifts and active switches, then one row per machine per interval with uptime, downtime and unknown hours and percentages, plus the machine's tags | `Utilization_Report__to_.csv` in your downloads | | **PDF** | The report as rendered, cards, charts and rows included | `Utilization_Report__to_.pdf` in your downloads | ### Download a CSV 1. Set the period, filters and switches. 2. Open **Actions**. 3. Click **Download as CSV**. The file opens with a header block, so a spreadsheet built from it records what it was: `Utilization Report - Aug 18, 2026 - Sep 14, 2026`, the generation date and time zone, the shifts, and a line for each exclude switch that was on. The rows below carry `Department Name`, `Asset Name`, `Asset Identifier`, `Period`, `Category`, `Uptime Hours`, `Downtime Hours`, `Unknown Hours`, the three percentages, and `Tags`. Choose CSV when you want to pivot the rows yourself, for example uptime by tag across every machine tagged `cell-3`. ### Download a PDF 1. Set the period, filters and switches. 2. Open **Actions**. 3. Click **Download as PDF**. 4. Wait for **Generating PDF report… this may take a few seconds.** to become **PDF report generated successfully.** ![The Actions menu open on the Advanced Report. Under a Report actions heading it lists Download as PDF, Download as CSV, Share and Schedule](/images/monitoring/mon-adv-04.webp) *Generating the PDF. The previous documentation hedged this as 'if available'; it exists.* The PDF is rendered from the report exactly as you see it, switches included. Choose PDF when the reader needs the picture rather than the rows, for example a monthly review with a plant manager. You do not need to export to get the report to other people. **Share** emails the current view to members of your organization, and **Schedule** sends it on a cadence, see [Email a report and schedule it to repeat](/docs/monitoring/share-and-schedule-reports/). ### Export errors | Message | Means | |---|---| | **Failed to download CSV. Please try again.** | The browser could not build the file. Wait for the report to finish loading and retry | | **Something went wrong generating the PDF.** | The PDF service could not render the report. Retry; if it repeats, narrow the date range | ## See also - [Email a report and schedule it to repeat](/docs/monitoring/share-and-schedule-reports/) - [Analyze downtime with Pareto and trend charts](/docs/monitoring/downtimes/) - [Metrics](/docs/monitoring/metrics-reference/) - [Available exports](/docs/monitoring/exports-reference/) - [Set OEE and utilization goals](/docs/monitoring/oee-goals/) --- # Inspect a single machine Source: https://www.iotflows.com/docs/monitoring/asset-detail/ Read one machine's page at /assets/selected-asset/:id: the header's live status pill and its orange and red thresholds, the sensor tile and its Wi-Fi signal icon, uptime, downtime and the Uptime gauge against the machine's goal, then the Analytics tab's per-operation counts, Record Production for backfilling a count the sensor missed, the Uptime/Downtime and Runtime Comparison charts, the downtime Pareto and the Activity feed, notes on the Health tab, and which of the Jobs, Health and Meters tabs answers which question. # Inspect a single machine Everything one machine's page tells you, and which tab answers which question. The header says what the machine is doing right now. The tabs below it hold the history: counts, runtime, stops, jobs, vibration and meters. **Prerequisites.** A machine with a paired sensor, see [Add a machine](/docs/monitoring/add-an-asset/). Every number here is defined in [Metrics](/docs/monitoring/metrics-reference/). ## Open a machine Click any card on the Assets page, or open `/assets/selected-asset/:id` directly. The breadcrumb reads **Assets / Doosan 2600**, and **Assets** takes you back with your filters intact. The control bar under it holds the shift selector for the header, a bell for event rules, **Auto-Detect** for the operations the sensor should count, and a menu with **Edit**, **Hide**, **Archive**, **Delete Data** and **Delete**, covered in [Edit, hide, archive, or delete a machine](/docs/monitoring/edit-assets/). ![The page for a Haas EC-1600. Numbered callouts mark the machine photo inside a green ring with its name, model and department, a green Running pill, the SenseAi sensor tile at the right with a green online dot beside green uptime and red downtime figures, and the 15% Uptime gauge at the far right. The shift timeline runs below the header, from 8am to 5pm.](/images/monitoring/mon-detail-01.webp) *One machine's page. The header answers what it is doing right now.* ## The header | Element | Shows | Configured on | |---|---|---| | Photo and ring | The machine's picture inside a ring in the current status color | [Edit a machine](/docs/monitoring/edit-assets/) | | Name, identifier, department, tags | The custom name, or the catalog name. The custom identifier, or the asset id | [Edit a machine](/docs/monitoring/edit-assets/) | | Status pill | **Running**, or **Last Op** and how long ago the machine last ran, in the current status color | [Status colors](/docs/monitoring/status-colors/) | | Sensor tile | The device, an online dot, and a Wi-Fi signal icon. Click it to open the device | [View your devices](/docs/hardware/view-devices/) | | Uptime and downtime | Hours in each state for the selected shift | [Shifts and timezone](/docs/admin/shifts-and-timezone/) | | **Uptime** gauge | Uptime as a percentage of the shift, against this machine's goal. Click it to set the goal | [Set OEE and utilization goals](/docs/monitoring/oee-goals/) | | Shift status bar | One colored segment per state change across the shift. Click a stop to classify it | [Classify a downtime event](/docs/monitoring/classify-downtime/#status-bar) | The pill has two states, because a sensor reports a machine as running or down and nothing else. The color adds how long the stop has lasted: green until the orange threshold, one minute by default, orange until the red threshold, five minutes by default, and red after that. A classified stop is dark red at once. Both thresholds are organization-wide, see [Status colors](/docs/monitoring/status-colors/). The sensor tile lights orange while the machine runs and cyan while it is stopped. A flat gray tile means the cloud has not heard from the device since you opened the page. The Wi-Fi icon's three levels are defined in [Read the connectivity indicators](/docs/hardware/view-devices/#indicators). A weak signal here is the usual cause of gray stretches on the status bar. ![The sensor tile in a machine page header, cropped close: a SenseAi lit orange, a pulsing green dot at its top right for online, and a three-arc Wi-Fi icon at its top left with an arrow pointing to the icon.](/images/monitoring/mon-detail-02.webp) *The sensor tile carries signal strength as a Wi-Fi icon. A weak signal here explains gaps in the charts below.* Pick the shift that had the problem rather than the whole day. A day spanning three shifts averages away the one you are looking for. ## The Analytics tab Analytics is the default tab. It holds five cards: **Operation(s) Production**, **Uptime/Downtime (hours)**, **Runtime Comparison (hours)**, **Downtime Classifications** and **Activity**. Each has its own date range and shift filter, remembered per machine. **Operation(s) Production** lists one row per operation run in the window. An *operation* is one part and the step this machine performs on it, see [Parts and operations](/docs/production/parts-and-operations/). Each row shows the count against its goal, good and scrapped parts per hour or day, and cycle time or production rate. For example, `Bracket 4417-A · Mill` reads 212 of 240 at a cycle time of 1:42 against a goal of 1:30. The amber **Auto-Detecting** label names what the sensor is counting. If it is empty, the machine counts nothing. Set it with **Auto-Detect**, see [Auto-detect operations](/docs/production/auto-detect-operations/). ![The Operation(s) Production card on the Analytics tab. An Auto-Detecting label at the top names the current operation, a blue Modify Counts button sits at the right, and below are two operation rows, each with a part image, the operation name, a count against its goal, a seven-day bar chart of good and scrapped parts, and a cycle time gauge.](/images/monitoring/mon-detail-03.webp) *The Analytics tab: production counts per operation, and how they moved day to day.* **Uptime/Downtime (hours)** stacks running, down and unknown hours per day, seven days by default, with an **Uptime** gauge for the range. **Exclude None** drops stops of severity None from both figures, see [The None severity](/docs/monitoring/metrics-reference/#none). **Runtime Comparison (hours)** draws the current period in blue over the previous one in gray, **Daily** or **Monthly**, for one shift. It catches a machine that has quietly slowed: a gray line consistently above the blue is a week of lost hours nobody noticed. ![Two cards from the Analytics tab. Uptime/Downtime (hours) stacks green uptime, red downtime and gray unknown bars for each of the last 30 days beside a 78% Uptime gauge. Runtime Comparison (hours) below it draws a blue line for the current month over a gray line for the previous month, with the gray line above the blue one for most of the month.](/images/monitoring/mon-detail-05.webp) *Daily runtime and the runtime comparison chart, for spotting a machine that has quietly slowed.* **Downtime Classifications** is this machine's downtime Pareto, categories ranked by hours lost, with a severity filter. It reads like the fleet report in [Read the Pareto chart](/docs/monitoring/downtimes/#pareto). Its **Classify** button opens the modal on any stop in the range. ## Production counts and backfilling The sensor counts parts on its own. To *backfill* is to record a count it missed, for example forty parts made while the device was offline for an hour. 1. On the **Operation(s) Production** card, click **Modify Counts**. The **Record Production** modal opens. 2. Pick the **Operation**. 3. Set the **Session Time** to the window the parts were made in. 4. Replace **Good Parts** with the true number. It is pre-filled with what the sensor detected in that window, and **Use Auto-Count** restores that figure. 5. Click **Add Scrap** for any rejects, with a reason code for each. 6. Click **Record Production**. The count is stored as a manual session on the work-order timeline above the operation rows, and a toast reads **Production recorded**. Backfill counts only when you know the true number and why the sensor missed it. A backfilled count changes OEE and FPY for that period permanently, and nothing on the Advanced Report marks it as manual. If the sensor misses parts while online, the fix is in [Troubleshoot part counts](/docs/production/troubleshoot-part-counts/), not here. ![The Record Production modal. An Operation dropdown at the top showing Rewinding, Finished Roll, a Session Time panel with a timeline and start and end fields, a Good Parts section with a note reading Auto-detected 3 parts in this window, a Use Auto-Count 3 button, and a minus, 3, plus stepper highlighted beneath it, a Scrap section with an Add Scrap button, and Cancel and Record Production buttons along the bottom.](/images/monitoring/mon-detail-04-v2.webp) *Backfilling a count. It changes OEE and FPY for that period permanently, and nothing marks it as manual.* ## The activity feed An *activity* is one interval of the machine's timeline in a single state, running or down. The **Activity** card lists every activity in the window, newest first, under pills for **All**, **Uptime**, **Classified** and **Unclassified**. The count on each pill is the size of that group. A stop shows its start, duration and category, with icons to split, classify or delete it. A running interval shows the operation it was counted against. The steps are in [Classify a downtime event](/docs/monitoring/classify-downtime/#activity-list) and [Delete an activity](/docs/monitoring/classify-downtime/#delete). You do not need the feed to classify a stop you can see; use the status bar. The feed is for the end-of-shift backlog, when **Unclassified** is the only pill that matters. ![The Activity card on the Analytics tab with pills reading All 32, Uptime 15, Classified 13 and Unclassified 4. Below, a mixed list of entries newest first: a green running interval with its operation, a dark red stop classified as Tool change with its start time and duration, and a red unclassified stop with split, pencil and trash icons.](/images/monitoring/mon-detail-06.webp) *The activity feed: every state change and edit on this machine, newest first.* ## Notes Notes are free text attached to the machine, not to a shift, so a note about a bearing that started to whine in March is still there in June. They live in the **Notes** list on the Health tab and in the **Notes** tab of [Operator View](/docs/monitoring/operator-view/). Both write to the same list. 1. On the Health tab, click **Add Note**. 2. Leave the date and time at now, or set them to when it happened. 3. Type the note and press **⌘+Enter**. Each note shows its text, timestamp and author. Click the pencil to edit in place: **Enter** saves, **Escape** cancels, and the note is marked as edited. The trash icon deletes at once, with no confirmation on the Health tab. A timestamped note is also a marker on the health charts. Click it and the charts jump to that moment, see [Monitor machine health and vibration](/docs/monitoring/machine-health/). ![The Notes list on the Health tab with three notes, each showing its text, a timestamp and an author avatar, and pencil and trash icons at the right. The Add Note button at the top of the list is highlighted.](/images/monitoring/mon-detail-07.webp) *Notes are timestamped and attached to the machine, not to a shift.* ## The other tabs | Tab | Answers | Requires | Page | |---|---|---|---| | **Analytics** | What did this machine make, and where did the time go | A paired sensor | This page | | **Jobs** | What is it working on, and what is queued | Jobs assigned to this machine | [Start, pause, and complete a job](/docs/production/run-a-job/) | | **Health** | Is the machine degrading | A SenseAi or SenseAi Embedded | [Monitor machine health and vibration](/docs/monitoring/machine-health/) | | **Meters** | How far is it from its next service | A meter on this machine | [Trigger maintenance from meter readings](/docs/maintain/meters/) | The Health tab is absent for a BeamTracker asset, because a beam sensor reads no vibration. A SenseAi on firmware below 5 keeps the tab but shows raw vibration, mean, standard deviation and RMS charts instead of the health score. Firmware is listed in [View your devices](/docs/hardware/view-devices/#fields). ## On mobile On a phone, a back link to **Assets** and a filter icon replace the breadcrumb and control bar, and the shift selector moves into the **Filters** sheet. Tapping the status bar opens the classification sheet, and tapping the **Uptime** gauge opens the goal modal. Each Analytics card collapses under its heading, and the page remembers which you closed. ## Errors | Message | Means | |---|---| | **Failed to record production** | The session was not saved; counts are unchanged. Retry | | **Failed to add note** | The note was not saved; retry | | **Failed to update note** | The edit was not saved; the note shows its previous text | | **Failed to delete note** | The note is still there; retry | | **Failed to delete activity** | The activity is still there; retry | ## See also - [Monitor machine health and vibration](/docs/monitoring/machine-health/) - [Classify a downtime event](/docs/monitoring/classify-downtime/) - [Set OEE and utilization goals](/docs/monitoring/oee-goals/) - [Metrics](/docs/monitoring/metrics-reference/) --- # Review and dismiss machine events Source: https://www.iotflows.com/docs/monitoring/asset-events/ Read the Event Alerts list on a machine's Health tab: what an event is and how it differs from the rule that fired it, the severity and type filter pills, how rows are grouped by age and sorted, dismissing one event or a whole time group, and the two ways an event becomes a work order. # Review and dismiss machine events The event feed for one machine, and what to do with what it flags. An *event* is the record IoTFlows writes when an alert rule on this machine fires: a health score falling past 60%, a stop longer than your downtime threshold, a shock above the sensor's g limit. The rule decides when that happens and who gets told. The event is what the rule leaves behind, and the **Event Alerts** list on the Health tab is where you read it. **Prerequisites.** A SenseAi or SenseAi Embedded asset on firmware 5 or later, see [Monitor machine health and vibration](/docs/monitoring/machine-health/). At least one event type enabled on the machine, see [Set alert rules for a machine](/docs/alerts/asset-event-rules/). ## Open the event list 1. Open the machine's page at `/assets/selected-asset/:id`. 2. Click **Health** in the tab strip under the header. 3. In the right column of the **Machine Health Summary** card, click **Alerts**. That column holds two tabs, each with its own count: **Alerts**, the events, and **Notes**, the comments people have left on this machine's charts. The chip beside the **Event Alerts** heading repeats the total. The list ignores the time range buttons at the top of the tab. Moving from **7d** to **90d** redraws every chart and leaves the list alone, because it is not a window: it is every event on this machine that nobody has dismissed yet. To *dismiss* an event is to mark it handled, which takes it off this list. With nothing outstanding, the card reads **No Active Alerts**, over **All systems operating normally**. ![The Event Alerts column on the Health tab. Alerts and Notes tabs sit at the top with counts, then a heading reading EVENT ALERTS with an 8 total chip, then two rows of filter pills for Severity and Type. Below them three events from the last hour are drawn flat, then a group header reading LAST 24 HOURS with a count chip of 5 sits over a collapsed stack of cards. Each row carries a type icon, a title, a colored value pill, a relative time such as 22m ago, a one-line message and a Dismiss link](/images/monitoring/mon-events-01.webp) *The event list for one machine. Each row is a rule that fired.* ## Filter by severity and type Two rows of pills sit above the list. **Severity** offers **All**, **Critical**, **Warning** and **Caution**, and **Type** offers **All**, **Health**, **Temp**, **Machine** and **Shock**. The two combine, so **Critical** plus **Temp** shows only critical temperature events. The number on each pill counts the whole list, not what the other row leaves. **Critical (4)** still reads 4 with **Health** selected, even when only one of those four critical events is a health event. **Device Offline events count as Machine.** Type is read from the event type's own name, and a lost connection carries none of the four, so it falls in with **Machine Down** and **Machine Up**. Filter before you clear anything. The bulk action described in [Dismiss a whole group](#dismiss-all) acts on what the filters leave visible, which makes "clear every caution and keep the criticals" two clicks. ![A cropped detail of the two filter rows. The Severity row shows All, Critical, Warning and Caution pills with counts in parentheses, with Critical selected and filled red. The Type row below shows All, Health, Temp, Machine and Shock pills with counts, with All selected. Callout 1 marks the severity row and callout 2 marks the type row](/images/monitoring/mon-events-02.webp) *Filtering the feed by severity and event type.* ## Read an event Every row carries the same six things: - A type icon: a heart for health, a thermometer for temperature, a falling clock for machine status, a waveform for shock. - The event title, for example **Warning Health Alert** or **Machine Down**. - The measured value, in a pill colored by severity, with the unit the event type implies: `%` for a health score, `°C` for temperature, `G` for shock, `min` for a stop. - How long ago it fired, written as `22m ago`, `6h ago`, `Yesterday` or `3d ago`. - The one-line message the event type carries. - A **Dismiss** link. Rows are grouped by age under **Last 15 min**, **Last hour**, **Last 6 hours**, **Last 24 hours** and **Older**. A group with no events is not drawn at all. Inside a group, critical sorts above warning above caution, and newer above older within one severity. A group of three events or fewer is drawn flat. A group with more than three collapses into a stack of three cards under a header carrying the count. Click the header to expand it. Click a row to line every chart on the tab up on the moment the event fired, and a panel headed **Existing at this time** lists the notes and events within five minutes of it. In a collapsed stack the first click expands the group instead, so expand the group, then click the row. See [the timestamp inspector](/docs/monitoring/machine-health/#inspector). > **Warning:** > **Why does a temperature event read °C when I set the rule in °F?** The value pill is always Celsius. The threshold on the rule follows your unit preference, the event does not. ### Event severities | Severity | Color | Typically from | |---|---|---| | **Critical** | Red | **Critical Health Alert**, which fires below 20%. **Critical Temperature**. **Machine Down** at its critical threshold | | **Warning** | Amber | **Warning Health Alert**, which fires below 40%. **Warning Temperature**. **Machine Down** at its warning threshold | | **Caution** | Yellow | **Caution Health Alert**, which fires below 60%. Also the fallback: an event arriving with no severity of its own is shown as a caution | Severity belongs to the event type, not to the event, so you cannot raise or lower one row. It sets the row's color, its position in the group, and which severity pill counts it. Which event types exist and what each one fires on is in [Event types reference](/docs/alerts/event-types-reference/). ## Dismiss one event Click **Dismiss** at the right of the row. The row leaves immediately and a toast reads **Event has been dismissed**. Dismissing sets a flag on the event rather than deleting it, so the record survives. No view in the dashboard shows dismissed events, so treat dismissal as the end of your involvement with that row, not as a way to find it again next week. **Dismiss an event when you have decided about it, not to clear the list.** Clearing the list unread every morning trains everyone to skip the next one, and the next one is the bearing that gave four weeks of warning. ## Dismiss a whole group **Dismiss All** appears on a group's header, and only on a group holding more than three events. A group of three or fewer has no header, so those rows are dismissed one at a time. 1. Set the severity and type filters to the events you mean to clear. 2. Click the group header, for example **Last 24 hours**, to expand it. 3. Click **Dismiss All**. It dismisses the events the filters leave visible in that group, not the whole list. With **Caution** selected, the criticals in the same group stay. A toast reports the count, for example `12 events dismissed`. Use **Dismiss All** on a group that is one incident repeated: forty shock events from one crash, or a run of **Machine Down** rows from a shift everybody already knows about. Dismiss one at a time when the group is mixed, because one bulk click takes the row you had not read yet along with the thirty-nine you had. ![An expanded time group in the event list. The header reads LAST 24 HOURS with a count chip of 5, a chevron, a red Dismiss All button ringed by a violet highlight, and a Collapse button. Five event rows are listed below it, each with its own Dismiss link](/images/monitoring/mon-events-03.webp) *Dismiss All clears one time group, and only the events the filters leave visible.* ## Turn an event into work No button on an event row opens a work order. Two routes exist instead, and they answer different questions. **Have the rule open it.** Every event type on a machine carries a **Work Order** column in **Event Notifications**, with a member to assign the work order to. Turn it on and each event of that type arrives on the maintenance board with nobody having to notice it. Set this up in [Set alert rules for a machine](/docs/alerts/asset-event-rules/). **Open one yourself.** For an event you read and decided about, raise the work order by hand so you can write what you actually saw into it, see [Create a work order](/docs/maintain/create-a-work-order/). You do not need the automatic work order on every event type. Turn it on for events with one obvious response, such as a critical health alert. Leave it off for **Machine Down** and **Device Offline**, which fire often and usually mean a person, a jam or a network, not a repair. ## Errors | Symptom | Cause | Do this | |---|---|---| | **Failed to dismiss event** | The dismissal did not save, and the row comes back when the list reloads | Retry. The event is unchanged | | **Failed to dismiss events** | The same, for **Dismiss All**. None of the group was dismissed | Retry, or dismiss the rows one at a time | | The list is empty while the machine is clearly in trouble | No event type is enabled for what is happening, or the event type is enabled to notify but not to log | Open **Event Notifications** and check the rule and its **Log** switch, see [Set alert rules for a machine](/docs/alerts/asset-event-rules/) | | No **Alerts** card anywhere on the tab | The asset is on firmware below 5 and shows the legacy health view | Ask IoTFlows to update the device, see [Get support](/docs/get-started/get-support/) | | A BeamTracker machine has no list at all | A BeamTracker has no **Health** tab, and the list lives on that tab | Read its events from the notifications they send. See [Set alert rules for a machine](/docs/alerts/asset-event-rules/) | ## See also - [Set alert rules for a machine](/docs/alerts/asset-event-rules/) - [Monitor machine health and vibration](/docs/monitoring/machine-health/) - [Create a work order](/docs/maintain/create-a-work-order/) - [Event types reference](/docs/alerts/event-types-reference/) --- # Group machines into cascades Source: https://www.iotflows.com/docs/monitoring/asset-groups/ A cascading group ties machines that one part passes through in sequence into a single line on the Assets page. Step 1 is the reference: every step after it reports first pass yield, parts lost and a rate difference against Step 1's count. You create and name groups from the Cascading Group field in a machine's Edit dialog, give each machine a step number, and switch the whole line onto a new part and a per-machine operation in one action. A cascade reads in full only in list view, and changes the Assets page rather than any report. # Group machines into cascades Treat several machines that run as one line as a single unit. A *cascading group*, or cascade, is a set of machines that one part passes through in sequence, grouped so the Assets page reads them as a line instead of as unrelated machines. Each machine gets a step number, and every step after the first reports what fraction of Step 1's output reached it. **Group machines that a part passes through in sequence, where a stop anywhere stops the line.** Do not group machines that merely sit near each other. A cascade reports as one unit, so grouping independent machines hides which one is the problem. **Before you start** - Sign in as an Organization Owner or Organization Administrator. Other roles see the **Cascading Group** field and the cascade actions disabled rather than hidden. See [Roles reference](/docs/admin/roles-reference/). - Add the machines first. **Cascading Group** appears in a machine's **Edit** dialog, not in **Add asset**. See [Add a machine](/docs/monitoring/add-an-asset/). - Have two or more machines with sensors reporting. A group with one member draws as an ordinary machine, not as a line. ## What a cascading group is Take a bottling line: a blow molder forms the bottle, a detabber trims the tab left by the mold, a spin trimmer finishes the neck, and a leak detector rejects the bottles that do not hold pressure. Each machine is its own asset with its own counts, so none of them can say how many molded bottles came off the line good. That is what the group adds. Step 1 is the reference, every downstream step is compared against it, and the comparison is *FPY*, first pass yield: the percentage of Step 1's parts that reached this step. See [FPY](/docs/monitoring/metrics-reference/#fpy). Groups belong to the organization and a machine belongs to at most one. The step number is per machine, so a group is assembled one machine at a time. ## Create a group You create the group while editing the first machine in the line, then point the rest of the line at it. 1. On the Assets page, select **⋮** on the line's first machine, then select **Edit**. 2. Select the **Cascading Group** field, then select **Create new group**. 3. Type a name that names the line, for example `Bottling Line 1`. 4. Leave both toggles off. They are covered in [Baseline yield on cycle time](#baseline). 5. Select **Add**. IoTFlows confirms with "Cascading group created" and selects the new group on this machine. 6. Set **Step**, the numeric field beside the group, to `1`. 7. Select **Edit Asset**. IoTFlows confirms with "Asset has been edited". 8. Repeat steps 1, 2, 6 and 7 for every other machine in the line, picking the existing group from the list and setting **Step** to `2`, `3`, and so on. ![The Edit asset dialog with the Cascading Group dropdown open in create mode: a name field, an Add button, and the toggles Hide First Pass Yield and Baseline yield on cycle time, with the Step field to the right of the dropdown](/images/monitoring/mon-group-01.webp) *The Cascading Group field in a machine's Edit dialog, open in create mode, with the group name, the Step field, and the two per-group toggles.* A machine you leave without a step sorts after every numbered one, so give every member a number. ## How grouped cards read A cascade is drawn differently in each view mode, and only one of them draws it in full. | View mode | What the cascade shows | |---|---| | **List** | The whole treatment: a group header naming the line, its step count and its part; a **Step** number on each row; and an **FPY** column in place of **Utilization** | | **Card** | The group's cards stay together as a block. The header and FPY appear only when the grid is a single column, so on a phone or a narrow window | | **Large uptime card** | FPY on each machine, and only for a group in [cycle-time baseline](#baseline) mode. No header and no step order | | **Large card**, **Cycle count** | Nothing. The machines draw as ordinary cards | **Read a cascade in list view.** It is the only mode that shows the header, the step order and the FPY column at a desktop width. See [Choose a view mode](/docs/monitoring/assets-overview/#views). Grouping the page can also dissolve a cascade. **Group by** left unset or set to **Department** keeps cascades intact; **Status** and **Machine type** break them into individual machines, because those headings cut across the line. A cascade whose machines sit in different departments renders whole, under the department of Step 1. ![A cascade in the Assets list view under a header reading Line 6, 5 steps, with the part Bottle 200ml beside it. The first three of its rows are visible: Blow molder, Detabber and Trimmer infeed, each carrying a Step number, a status ring, the machine name and identifier, and hourly production bars.](/images/monitoring/mon-group-02.webp) *A cascade in list view: the group header names the line and its step count, and each machine row carries its step number.* ## FPY across a cascade Every downstream step is compared against Step 1, not against the step immediately before it: ``` fpy = this step's good count ÷ Step 1's good count, capped at 100% ``` For a five-step bottling line that molded 39,000 bottles in the window: | Step | Produced | Loss vs Step 1 | FPY on the card | |---|---|---|---| | 1 · Blow molder | 39,000 | — | 100% | | 2 · Detabber | 38,632 | 368 | 99.1% | | 3 · Trimmer infeed | 38,100 | 900 | 97.7% | | 4 · Trimmer outfeed | 37,835 | 1,165 | 97.0% | | 5 · Leak detector | 37,696 | 1,304 | 96.7% | So the figure is cumulative: Step 5's 96.7% is the share of molded bottles that passed the leak detector, not the share of trimmed bottles that passed it. The 532 parts lost between Step 2 and Step 3 is the difference between two rows, which the card does not compute for you. Each downstream step also carries two numbers under its percentage: **parts lost** against Step 1, and a **rate difference** in operations per minute against Step 1's rate. A step running slower than Step 1 is where the line is throttled. Both are hidden on a step that matched or beat Step 1, and its FPY reads 100% rather than more. FPY reads green from 95%, amber from 80%, and red below that. A step with no operation assigned reads `—`, because there is no count to compare, which is what [Cascade a part and operation](#cascade-part) fixes. ![The rightmost columns of five cascade rows, each showing a part count made, a current rate and a target rate beside its FPY figure. Step 1 reads 39K made, 54.3 ops per minute and 100% FPY in green. The four steps below it fall away from that reference in step: 99.1%, 97.7%, 97.0% and 96.7% FPY, each with its parts lost against Step 1 and its rate difference in red beneath, from minus 368 parts and minus 0.5 ops per minute down to minus 1,304 parts and minus 1.8 ops per minute.](/images/monitoring/mon-group-03.webp) *The FPY column in list view. Each downstream step reads its percentage of Step 1's count, with parts lost and the rate difference beneath it.* ## Baseline yield on cycle time Comparing against Step 1 assumes the steps handle the same part one for one. Where they do not, turn on **Baseline yield on cycle time** in the group's settings. Each step is then measured against its own expected output, the parts it could have produced at its operation's [ideal cycle time](/docs/monitoring/metrics-reference/#cycle-time), with no reference step at all. The group header carries a **Cycle-time baseline** badge when this is on. That expected count spans the whole window, not the running part of it, so a stop counts against the number exactly as a slow cycle does. A step down for half the window reads at most 50%. See [Performance](/docs/monitoring/metrics-reference/#performance). **Default to leaving it off.** Turn it on when the steps do not run one for one: when a step makes several sub-assemblies per finished unit, when the steps' ideal cycle times differ by design, or when the "line" is a single machine you still want a yield figure for. A one-machine group shows FPY only in this mode, since it has no Step 1 to compare against. **Hide First Pass Yield** drops the FPY column from the group's rows and gives the space to the other columns. It is the setting for a group you want held together and ordered without a yield figure. Turning it on forces the cycle-time baseline off and disables it, because there is nothing left for a baseline to measure. ### Group settings | Setting | Effect on the card | Effect on reports | |---|---|---| | Group name | Labels the group header in list view | None | | **Step** | Sets the draw order, and makes Step 1 the reference for FPY | None | | **Hide First Pass Yield** | Drops the FPY column from every row in the group | None | | **Baseline yield on cycle time** | FPY is measured against each step's own ideal cycle time, and the header gains a **Cycle-time baseline** badge | None | Nothing in this table reaches a report. The Downtimes report and the Advanced Report have no cascade dimension: they list machines individually, whatever groups those machines belong to. A cascade changes how the Assets page reads, not what a report says. See [Available exports](/docs/monitoring/exports-reference/). ## Cascade a part and operation in one action When the line changes over to a new part, one dialog switches every machine in the group instead of you editing each one. 1. In list view, select the part block in the group header, or **Set Part** if the line has no part yet. 2. Search for the part by name. The list is filtered by the server, so a part you have not searched for will not be in it. 3. Select the part. The dialog moves to **Assign operations per machine**, pre-filled by step order: Step 1 takes the part's first operation, Step 2 its second, and so on. 4. Correct any machine whose target is wrong, or set it to **Don't change** to leave that machine alone. The footer counts how many of the group will change. 5. Select **Update N machines**. IoTFlows confirms with "Updated 5 machines" for a five-machine line. This sets the operation each machine auto-detects, the same setting as **Switch operation** on a single card, see [Auto-detect operations](/docs/production/auto-detect-operations/). It is what gives every step a count, and therefore an FPY figure. Two things stop the dialog short. A part with no operations reads "This part has no operations to assign", so define them first, see [Parts and operations](/docs/production/parts-and-operations/). Leaving every machine on **Don't change** reports "Pick an operation for at least one machine". Each machine is switched by its own request, so a run can half succeed: "Updated 4 machines" alongside "Failed to update 1 machine". Reopen the dialog and apply again to the one that failed. ![The Assign operations per machine dialog, opened from the highlighted part block in the group header behind it. A part header shows the part photo, Bottle 200ml, and 5 operations, and below it five rows, each naming a step and machine with its current operation and a dropdown holding the new one. The footer reads 5 of 5 will change beside an Update 5 machines button.](/images/monitoring/mon-group-04.webp) *The cascade part dialog on its second panel, assigning one operation per machine, pre-filled by step order, with a count of how many machines will change.* ## Edit or delete a group Every change to a group is made from the same **Cascading Group** field, reached through **Edit** on any machine. - **Rename a group, or change its settings.** Select the pencil on the group's row, change the name or either toggle, then select **Save**. IoTFlows confirms with "Group updated". - **Change a machine's position.** Set a new **Step** on that machine and select **Edit Asset**. - **Take one machine out of the line.** Select the cross on the **Cascading Group** field to clear the selection, then select **Edit Asset**. The machine returns to the fleet as an ordinary card, and the step numbers of the machines left behind do not renumber themselves. - **Delete the group.** Select the trash on the group's row, then **Delete** in the confirmation. IoTFlows confirms with "Cascading group deleted". > **Note:** > **What does deleting a group destroy?** The grouping only. The confirmation says it: "This action cannot be undone. Any assets currently assigned to this group will be unassigned." Every machine stays, with its sensor, its history, its operations and its counts, so a five-step line becomes five ordinary cards. If the delete fails, the toast reads "Failed to delete cascading group" and the group is still there. A group that drops below two members stops being drawn as a line. It still exists, and it still holds its settings, so adding a second machine back restores the cascade without you recreating anything. ## See also - [Auto-detect operations](/docs/production/auto-detect-operations/) - [Monitor your fleet on the Assets page](/docs/monitoring/assets-overview/) - [How each metric is calculated](/docs/monitoring/metrics-reference/#fpy) - [Parts and operations](/docs/production/parts-and-operations/) - [Edit, hide, archive, or delete a machine](/docs/monitoring/edit-assets/) --- # Monitor your fleet on the Assets page Source: https://www.iotflows.com/docs/monitoring/assets-overview/ The Assets page is the live view of every monitored machine in your organization. A KPI row totals uptime, downtime, utilization and how many machines are producing right now; a daily utilization trend sits beside it; and each machine gets a card carrying a status ring, an uptime gauge against its goal, hourly production against goal, and cycle time. Five view modes, saved to your account, trade detail against fleet size, and filters, grouping and a shift window decide what the page counts. # Monitor your fleet on the Assets page See what every machine is doing right now, and which ones need attention. An *asset* is one monitored machine: a catalog model, your own name and identifier for it, and the sensor that reports on it. The Assets page draws every asset in the organization at once, updates as sensors publish, and is the page most operators and supervisors leave open all shift. **Prerequisites.** Signed in, with at least one machine reporting. Contact IoTFlows to tie your sensors to an asset, see [Get support](/docs/get-started/get-support/). ## Open the Assets page Go to **Assets**. The page opens at `/assets?select=overview`. Machines you are not granted access to never appear here. So do machines hidden from the **Edit Assets** list, which stay editable but are drawn out of the fleet view. How the fleet is drawn depends on the view mode you last chose, see [Choose a view mode](#views). Every mode shows the same machines and the same window; they differ in how much of each machine they draw. ![The Assets page in list view. A filter toolbar runs across the top, a utilization trend chart with Zoom buttons sits beside four KPI tiles reading 71:15h Uptime, 68.2% Utilization, 33:14h Downtime and 9 of 14 Machines Producing, and four machine rows below each carry a photo, hourly production bars, current operation, cycle time, a utilization donut and a full-width green and red status bar running 8AM to 5PM.](/images/monitoring/mon-assets-01.webp) *The fleet in list view, with the shift status bar under each machine. Green is running and red is down.* ## Read the fleet KPIs Four tiles across the top total the whole fleet for the window you have selected. | Tile | Shows | |---|---| | **Uptime** | Total hours every machine spent running, as `71:15h` | | **Utilization** | Running time as a percentage of running plus down time, green when it meets the goal and red when it does not | | **Downtime** | Total hours every machine spent down | | **Machines Producing** | How many machines are running right now, over the total, as `9/14` | Two controls sit in the corner of the **Utilization** tile. **Adjust OEE Goal** sets the organization-wide goal that colors the number, see [Set uptime goals](/docs/monitoring/oee-goals/). **Adjust Status Colors** sets the two thresholds described in [Read a machine card](#cards). Beside the tiles, a chart plots utilization over time so you can see whether this shift is normal. **Zoom** regroups it: **Day** plots the last month a day at a time, **Week** the last three months a week at a time, **Month** all your history a month at a time, and **All** every point ungrouped. Zoom changes only this chart, not the machine timelines below it. Every figure on this page is defined in [Metrics](/docs/monitoring/metrics-reference/). ![The four fleet KPI tiles: 33:18h Uptime in green, 67.6% Utilization in red, 15:59h Downtime in red, and 8 of 14 Machines Producing. Two small icons in the top right corner of the Utilization tile are outlined in blue.](/images/monitoring/mon-assets-02.webp) *The two controls in the corner of the Utilization tile: Adjust OEE Goal on the left, Adjust Status Colors on the right.* ## Read a machine card Each card carries the machine's photo inside a colored status ring, its name and identifier, uptime and downtime for the window, an **Uptime** gauge against that machine's goal, hourly production against the hourly goal, and cycle time or production rate colored against the cycle-time goal. Under the identifier, a running machine shows a **Running** pill. A stopped machine shows **Last Op** and how long ago it was, in the current status color, so the card answers "how long" without being opened. A *shift status bar* runs the width of the machine, from the start of the window to its end, colored for the state the machine was in at each moment. It is the one element that shows you the shape of the shift rather than its totals: six short red stretches and one long one are the same downtime total and completely different problems. ![A machine card for DMG DMU 65, identifier DMU-65. A green ring surrounds the machine photo, a green Running pill sits beside it, 05:02h uptime and 00:21h downtime are below, a 93% Uptime gauge and a 7 made count gauge sit at the right, and a green shift status bar runs 8am to 5pm along the bottom.](/images/monitoring/mon-assets-03.webp) *A running machine's card: green ring, Running pill, Uptime against goal, parts made, and the shift status bar.* A sensor reports a machine as running or down. There is no third state. What the colors add is how long it has been down. ### Status colors | Color | Means | |---|---| | Green | Running | | Orange | Down past the first threshold, one minute by default | | Red | Down past the second threshold, five minutes by default | | Dark red | Down, and the stop has been classified | | Gray | No data from the sensor for that stretch | Gray is absence of data, not downtime. A bar striped with gray through a shift is a connectivity problem, not a machine that keeps stopping, and the card still reads stopped because it carries the last state the cloud recorded. See [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). Both thresholds are organization-wide, and you set them in **Adjust Status Colors**. See [Status colors](/docs/monitoring/status-colors/). A classified stop skips them: it is drawn dark red from the moment it is classified, rather than working through orange first. Dark red is only the default. Each downtime category can carry a color of its own, picked from a palette under **Color** when you add or edit the category. Reports and Pareto charts draw that category in its color, see [Manage downtime categories](/docs/monitoring/downtime-categories/). ![A machine card for Doosan 2600, identifier TXV-2600. A red ring surrounds the machine photo and a red pill reads Last Op: 11 minutes ago. Uptime is 00:42h and downtime 04:52h, the Uptime gauge reads 13%, and the shift status bar along the bottom is almost entirely red.](/images/monitoring/mon-assets-04.webp) *A machine stopped eleven minutes, well past the five-minute red threshold.* Click any card to open that machine, see [Inspect a single machine](/docs/monitoring/asset-detail/). ## Choose a view mode Five icons at the right of the toolbar switch how the fleet is drawn. | Mode | Shows | Best for | |---|---|---| | Card | Photo, status, uptime gauge, hourly production, cycle time | The default, up to roughly 20 machines | | Large card | The same, at a size readable across a room | A wallboard or a supervisor's second monitor | | Large uptime card | Uptime and goal given the whole card, with first pass yield where it is enabled | Watching goal attainment rather than activity | | Cycle count | Production counts and cycle time, other elements dropped | Count-driven work, where the number is the point | | List | One dense row per machine | Large fleets, and scanning for anything stopped | **Choose the list view above roughly 20 machines.** Card view stops being scannable at the point where you have to scroll to see the whole fleet. Your choice is saved to your IoTFlows account, not to the browser, so it follows you to any machine you sign in on. A toast reading "View settings changed" confirms the save. On a phone, only Card and Cycle count are offered, with List added on a tablet. ![The five-icon view switcher from the Assets toolbar, each icon labeled by an arrow: Card, Large Card, Large Uptime Card, Cycle Count and List, left to right.](/images/monitoring/mon-assets-05.webp) *The five view modes. Your choice is saved to your account, not the browser.* ![The Assets page in card view: twenty machine cards in a four-wide grid, split under the department headings Production, Sheetmetal and UliProd. Each card carries a status ring, an Uptime percentage, an hourly production chart and a status bar, and the rings are a mix of green for running and red for stopped.](/images/monitoring/mon-assets-06.webp) *Card view at twenty machines, grouped by department. This is about as much fleet as fits before you start scrolling.* ## Filter the fleet **Department** and **Tag** narrow the page to part of the fleet. A *tag* is a label you attach to machines yourself, for a set that crosses departments, such as `CNC`. **Machine type** filters by catalog model, and is offered only in the expanded view, which the arrows icon opens. Every filter is held in the URL, so a filtered page is a link you can send. **Reset filters** clears them all. ![The Assets filter bar in expanded view, carrying six chips: Department with a count of 4, Machine type, Tag with a count of 1, Group by Department, Sort by Name A to Z, and Shift Day Shift. Each applied chip has a cross for clearing it.](/images/monitoring/mon-assets-07.webp) *The filter bar in expanded view. Machine type appears only here, and a chip carries the number of values you picked.* ## Group and sort **Group by** splits the page under headings: **Department**, **Status** or **Machine type**. **Sort by** orders the machines within each group: name A to Z, name Z to A, department, or machine type. Group by **Department** for everyday use: it matches how most plants are organized. Group by **Status** when you are working a shift and want everything stopped collected at the top. Leaving **Group by** unset draws the fleet as one flat run. ![The Assets page in list view, with machine rows collected under the department headings Machining and Production. Each row carries a status ring, hourly production bars, the current operation, cycle time, a utilization donut, and a full-width status bar.](/images/monitoring/mon-assets-08.webp) *Grouping by department puts each area under its own heading.* ## Choose the window **Shift** decides what every number on the page counts. Leaving it alone tracks the current shift live. You can also pick a named shift, **All Day**, or **Custom Time** with your own start and end in 30-minute increments, and set the date to yesterday or any past day. The page refreshes itself every minute and redraws a card as soon as its sensor publishes. **Selecting a shift or a date stops the refresh**, because the window is now historical and a refresh would have nothing to add. Clear the shift filter to go live again. A shift that crosses midnight is shown whole here. Pick Friday's 10 PM to 6 AM shift and the page counts all eight hours, with no break at midnight. Reports divide the same shift at midnight unless **Shift islands** is on, which is why this page and a report can disagree about one night, see [Where the overnight hours land](/docs/admin/shifts-and-timezone/#overnight-hours). Shifts themselves are defined once for the organization, see [Shifts and time zone](/docs/admin/shifts-and-timezone/). ## When a machine is missing Work down this list before suspecting the data. 1. Clear the filters. A department or tag filter is the usual answer. 2. Check that the machine is not hidden in **Edit Assets**. 3. Check your machine access. A grant you do not have removes the machine from the page entirely, see [Machine access](/docs/admin/machine-access/). 4. If the machine is on the page but gray, the sensor is not reporting. See [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). You do not need to add anything here to fix a missing machine. **Add asset** provisions a new machine, and that is a different task, see [Add a machine](/docs/monitoring/add-an-asset/). ## See also - [Inspect a single machine](/docs/monitoring/asset-detail/) - [Analyze downtime with Pareto and trend charts](/docs/monitoring/downtimes/) - [Status colors](/docs/monitoring/status-colors/) - [Metrics](/docs/monitoring/metrics-reference/) - [Display a wallboard on a TV](/docs/monitoring/wallboards/) --- # Classify downtime automatically Source: https://www.iotflows.com/docs/monitoring/auto-downtime-rules/ Four organization-wide rules put a reason code on the stops operators should not have to classify by hand: short downtimes, the start of a shift, the end of a shift, and a machine down for an entire shift. Scheduled break windows add a reason for lunch and breaks. Which rule to turn on first, and which to leave off until the shift schedule is trusted. # Classify downtime automatically Rules that put a reason on the stops operators should not have to. *Auto-classification* is a rule that assigns a downtime category to a stop without anyone opening the classify modal. Four rules cover the stops every plant sees: short pauses, the edges of a shift, a shift with no production at all, and scheduled breaks. Each rule applies to every machine in the organization, and each carries its own **Enabled** or **Disabled** state. **Prerequisites.** Organization Owner or Organization Administrator, see [Roles and permissions](/docs/admin/roles-reference/). A shift schedule, see [Shifts and timezone](/docs/admin/shifts-and-timezone/): three of the four rules and every break window are measured against it. A category for each rule to assign, see [Manage downtime categories](/docs/monitoring/downtime-categories/). ## What the rules do The rules live under **Auto-Downtime Classifications**, at the bottom of Organization Settings. 1. Click the gear icon at the top right of the header, between the feedback icon and your profile picture. It opens Organization Settings at `/settings/organization`, on the **Settings** tab. 2. Scroll past the organization details and the device assignment block. **Auto-Downtime Classifications** is the last panel on the page. The panel lists each rule with its state and the category it assigns. Click **Edit** to change either, and **Close** when you are done. Every change saves as you make it, so there is no **Save** button. | Rule | Triggers when | Assigns | Configurable values | |---|---|---|---| | **Short Downtimes** | A machine is down for less than the machine's threshold, 5 minutes by default | The category you pick, or converts the stop to uptime | Enabled, category. The threshold and the convert-to-uptime choice are set per machine | | **Start of Shift** | A machine is down as a scheduled shift begins | The category you pick | Enabled, category | | **End of Shift** | A machine is down as a scheduled shift ends | The category you pick | Enabled, category | | **Entire Shift** | A machine is down for the whole of a scheduled shift | The category you pick | Enabled, category | | **Breaks** | A machine is down inside a break window during a scheduled shift | The category on that window | One or more windows, each with a start, an end, a category, and its own enabled flag | Rules apply to stops as they are recorded from the moment you enable them. To put a reason on stops that already sit in the backlog, use [Bulk classify](/docs/monitoring/classify-downtime/#bulk). ![The Auto-Downtime Classifications panel on the organization settings page, with an Edit button in its header. Four rows read Short Downtimes, Start of Shift, End of Shift and Entire Shift. Short Downtimes and Start of Shift show Enabled in green, End of Shift and Entire Shift show Disabled in gray, and each row ends with the category it assigns in italic blue. A fifth row, Breaks, carries a plus button and lists two windows, one for Lunch Break and one for No job. Numbered callouts 1 to 4 mark the four rule rows](/images/monitoring/mon-auto-01.webp) *The four automatic classification rules and their current state.* ## Short downtimes A *short downtime* is a stop under a cutoff you set per machine. Tool changes, part loading and indexing all stop a machine for a minute or two without being downtime anybody wants to chase. This rule has two halves in two places. The organization rule turns it on and names the category it assigns. The cutoff, and whether the stop is classified or converted to uptime instead, are machine settings on the calibration panel, see [Handle short stops](/docs/hardware/calibrate-senseai/#short-stops) for SenseAi and [Classify short stops automatically](/docs/hardware/calibrate-beamtracker/#auto-classify) for BeamTracker. 1. Click **Edit** on the **Auto-Downtime Classifications** panel. 2. Turn on the **Short Downtimes** switch. An **Enabled** toast confirms it. 3. Click the category chip and pick the reason to assign, for example `Short Downtime`. A **Downtime Category Updated** toast confirms it. A machine whose calibration has **Treat short downtimes as uptime** switched on ignores the category: its short stops become uptime and never reach the classify backlog. **Turn on short downtimes first.** It removes the majority of a plant's unclassified rows, and it is the rule least likely to hide something you needed to see. ![The Short Downtimes row of the panel in Edit mode. A small switch is on, followed by the text If machines are down for less than the specified duration (default 5 minutes), auto classify downtimes as, a category chip reading Short Downtimes, highlighted with a violet box, and the words or convert them to uptime based machine settings](/images/monitoring/mon-auto-02.webp) *The short-downtime rule. Turn this one on first.* ## Start of shift Machines rarely start cutting the minute a shift begins. Warm-up, the morning meeting and the first setup all read as downtime on the status bar. Turn on **Start of Shift** and pick the category to assign, for example `Shift start`. The rule reads the shift boundary from your schedule, so a stop that runs across the start of a shift is classified from the moment the shift begins. ## End of shift The mirror of the rule above. Cleanup, the last part off the machine and the walk to the clock all read as downtime before the shift ends. Turn on **End of Shift** and pick the category to assign, for example `Shift end`. Together, the two shift-edge rules leave only the stops in the middle of a shift for operators to explain. ## Entire shift A machine that never runs during a scheduled shift, because it had no job, no operator or a fault carried over from the day before, produces one stop the length of the shift. Turn on **Entire Shift** and pick the category to assign, for example `No job scheduled`. The rule matches a stop only when the machine is down for the whole shift, so a machine that runs for one cycle is left for an operator. **Leave Entire Shift off until you trust your shift schedule.** If the schedule says a shift ran when the plant was closed, every machine reads as down for the whole of it, and this rule silently classifies a shift of real downtime under whatever category you chose. Turn it on once the shifts on [Shifts and timezone](/docs/admin/shifts-and-timezone/) match the calendar on the floor. ![The Entire Shift row of the panel. The state reads Disabled in gray, followed by the text If machines are down for the entire duration of a shift, auto classify the downtime as, and the category Entire Shift Down in italic blue](/images/monitoring/mon-auto-03.webp) *The entire-shift rule, left off until the shift schedule is trusted.* ## Scheduled breaks A *break window* is a start and end time inside which any stop during a scheduled shift is classified with the category you attach. Lunch is the usual one. A plant with two lunch waves adds two windows. 1. Click **Edit** on the panel, then the **+** beside **Breaks**. 2. In **Add Downtime Break**, set the start hour, minute and AM or PM, then the end. 3. Click the category chip and pick the reason, for example `Lunch break`. 4. Click **Add Break**. A **Downtime Break Added** toast confirms it, and the window appears enabled. Each window carries its own switch. Turn one off to keep it for later without deleting it. Changing a time saves on the spot with a **Start Time Updated** or **End Time Updated** toast. The trash icon deletes the window immediately, with no confirmation, and a **Downtime Break Deleted** toast follows. ### Break window fields | Field | Values | Notes | |---|---|---| | Start time | Hour 01 to 12, minute 00 to 59, AM or PM | Stored to the minute. Read against the organization timezone | | End time | Hour 01 to 12, minute 00 to 59, AM or PM | Same | | Category | Any downtime category | Picked from the same list operators use | | Enabled | On or off | On when the window is created | A window only fires during a scheduled shift. A stop at 12:15 on a day with no shift is not classified, so a break window never turns weekend silence into `Lunch break`. ![The two break windows of the panel in Edit mode. Each has a switch, the text During scheduled shifts, if machines are down, between, hour, minute and AM or PM selectors for the start and end, the words classify downtimes as, a category chip, and a trash icon. The first window runs 12:00 AM to 12:30 AM with its switch on and the category Lunch Break. The second runs 02:02 PM to 02:30 PM with its switch on and the category No job. Callout 1 marks the first window's time selectors and callout 2 its switch](/images/monitoring/mon-auto-04.webp) *Scheduled break windows. Each carries its own enabled flag.* ## Turn a rule off 1. Click **Edit** on the **Auto-Downtime Classifications** panel. 2. Turn off the rule's switch. A **Disabled** toast confirms it. 3. Click **Close**. The rule stops assigning its category to new stops. Turning a rule off does not remove the category it assigns from the list, and it does not touch a break window: those have their own switches under [Scheduled breaks](#breaks). ## What the rules do not do - They do not reclassify a stop an operator already put a reason on. A rule fills empty slots. - They do not touch a stop longer than the short cutoff that sits inside a shift. Those wait for an operator, see [Classify a downtime event](/docs/monitoring/classify-downtime/). - They do not set the short-downtime cutoff. That is a machine setting on the calibration panel, and it defaults to 5 minutes. - They do not change the numbers. A classified stop is still downtime in [Uptime](/docs/monitoring/metrics-reference/#uptime) unless the machine converts short stops to uptime. > **Info:** > **Rules appear to do nothing?** Three of the four rules and every break window are measured against the shift schedule. If a shift-edge stop stays unclassified, or a break window never fires, the organization timezone or the shift times are wrong. Check both on [Shifts and timezone](/docs/admin/shifts-and-timezone/) before touching the rules. ## See also - [Shifts and timezone](/docs/admin/shifts-and-timezone/) - [Manage downtime categories](/docs/monitoring/downtime-categories/) - [Classify a downtime event](/docs/monitoring/classify-downtime/) - [Troubleshoot monitoring](/docs/monitoring/troubleshoot-monitoring/) --- # Choose a machine health baseline profile Source: https://www.iotflows.com/docs/monitoring/baseline-profiles/ Set the reference a machine's health scores are judged against on the Health tab: Dynamic Baseline, four ISO 10816 classes, or one of eight machine-type profiles, which profile fits which machine, and what the confirm dialog recalculates. # Choose a machine health baseline profile Pick the standard your machine's health scores are measured against. A *baseline profile* is the reference IoTFlows scores a machine's vibration against. It is set per machine on the **Health** tab, and every machine starts on **Dynamic Baseline**. Changing it recalculates that machine's health scores and diagnostics, so it is a setting you get right once rather than one you tune. **Prerequisites.** A SenseAi or SenseAi Embedded asset on **firmware 5 or later**, see [Monitor machine health and vibration](/docs/monitoring/machine-health/). Owner or Administrator, see [Roles and permissions](/docs/admin/roles-reference/). ## What a baseline profile does The profile decides what counts as normal for this machine. Every number on the Health tab is a comparison against it: the [health score](/docs/monitoring/machine-health/#score), the seven **Operations Metrics** gauges, and the diagnostics behind them. The choice matters most where a machine's normal is unusual. A reciprocating compressor runs with strong harmonics all the time, so a profile that expects a smooth motor keeps scoring a healthy compressor as faulty. The profile belongs to the asset, not to your account, so everyone in the organization sees the same scores. IoTFlows does not publish the thresholds behind each profile. > **Info:** > **Not the same baseline as calibration.** The running and stopped baselines you capture in [Calibrate SenseAi and SenseAi Embedded](/docs/hardware/calibrate-senseai/#running) decide whether the machine reads as running or down. A baseline profile decides how its health is scored. Neither one changes the other. ## The available profiles The profile dropdown sits at the top left of the **Health** tab, opposite the time range buttons, and its label is the machine's current profile. It lists 13 profiles in three groups, with the number of options beside each group name: **Adaptive** (1), **ISO 10816 / 20816** (4) and **Machine Type** (8). *ISO 10816*, republished as ISO 20816, is the international standard for judging machine vibration severity. It sorts machines into classes by power and by how rigid the foundation is, which is what the four ISO options name. ![The baseline profile dropdown open on the Health tab. A Search profiles box sits at the top, and below it three group headings with a count beside each: Adaptive 1, holding Dynamic Baseline, selected with a blue radio dot; ISO 10816 / 20816 4, holding the four ISO class options; and Machine Type 8, whose list starts at Centrifugal Pump and runs past the bottom of the scrolling panel. Every option carries a one-line description under its name. Numbered callouts 1, 2 and 3 mark the three group headings](/images/monitoring/mon-baseline-01.webp) *The 13 baseline profiles in their three groups.* Type in **Search profiles...** to filter the list. The search matches both the profile name and its description, and a group disappears when none of its options match. A search that matches nothing shows **No profiles match your search**. ![A cropped detail of the profile dropdown with the word gearbox typed into the search box. The Adaptive and ISO groups are gone and only the Machine Type group remains, showing one option, Gearbox, with the description Gear drives, gear mesh frequencies dominate, sidebands indicate wear](/images/monitoring/mon-baseline-02.webp) *Searching the profile list.* ### Baseline profiles Expected signature is what the profile treats as ordinary for that machine. 1X and 2X are multiples of running speed, see [Harmonics and RPM](/docs/monitoring/machine-health/#harmonics). | Profile | Group | Fits | Expected signature | Notes | |---|---|---|---|---| | **Dynamic Baseline** | Adaptive | Any machine, and the only fit for a custom or one-off one | Whatever the machine's own recent readings show | The default, and the right one unless you can name the machine's class | | **ISO Class I – Small machines (≤15 kW)** | ISO 10816 / 20816 | Small electric motors, pumps and fans | Up to 15 kW, typically on rigid mounts | Pick an ISO class by power and foundation, not by what the machine makes | | **ISO Class II – Medium machines (15–75 kW)** | ISO 10816 / 20816 | Medium motors, pumps, fans and blowers | 15 to 75 kW with no special foundation | The class most shop-floor machines fall into | | **ISO Class III – Large machines, rigid foundation (>75 kW)** | ISO 10816 / 20816 | Large motors, pumps and turbines | Over 75 kW on a rigid or heavy foundation | The foundation matters as much as the power | | **ISO Class IV – Large machines, flexible foundation** | ISO 10816 / 20816 | Large machines on flexible or lightweight structures, such as turbogenerators | A structure that moves with the machine | The standard allows more vibration here than on a rigid foundation | | **Centrifugal Pump** | Machine Type | Centrifugal pumps | Cavitation, misalignment and vane-pass harmonics | Read it alongside the **Cavitation Risk** gauge | | **Positive Displacement Pump** | Machine Type | Reciprocating and gear pumps | Pulsating by design, so higher harmonics are expected | — | | **Electric Motor (General)** | Machine Type | AC and DC motors | Dominated by 1X, imbalance, and 2X, misalignment | Use it when the motor is what you are watching, not the machine it drives | | **Fan / Blower** | Machine Type | Centrifugal and axial fans | Blade-pass harmonics, sensitive to imbalance | — | | **Reciprocating Compressor** | Machine Type | Reciprocating compressors | High harmonic content is normal and valve impacts are expected | The clearest case for a machine-type profile: a general profile keeps flagging what belongs here | | **Screw Compressor** | Machine Type | Rotary screw compressors | Meshing frequencies, moderate high-frequency energy | — | | **Gearbox** | Machine Type | Gear drives | Gear mesh frequencies dominate, and sidebands indicate wear | — | | **Turbine (Steam / Gas)** | Machine Type | Steam and gas turbines | High speed and tight tolerances, sensitive to imbalance and rub | — | **Which one to pick.** - Choose **Dynamic Baseline** when the machine is unusual, custom, or you do not know its class. It learns from recent data and is the right default. - Choose an **ISO class** when the machine matches one cleanly and you need scores you can hold against an external standard. - Choose a **machine-type** profile when the fault signature matters. A reciprocating compressor's harmonics are normal, and a general profile keeps flagging them. **You do not need to change this on most machines.** Dynamic Baseline scores a machine against itself, which is what you want when the question is "has this machine changed". Change the profile when the machine clearly belongs to one of the other 12, or when a machine keeps scoring low with nothing wrong on the floor. ## Change the profile 1. Open the machine's page at `/assets/selected-asset/:id` and click **Health**. 2. Click the profile button at the top left. 3. Type in **Search profiles...** to narrow the list, or scroll to the group you want. 4. Click the profile. The dropdown closes and the **Change baseline profile** dialog opens. 5. Check the dialog. It names the new profile with its description, and shows the current profile and the new one side by side. 6. Click **Apply changes**, or **Cancel** to keep the profile you have. A toast confirms the change by name, for example **Baseline profile updated to Gearbox**. Nothing is written until you confirm: picking a profile in the dropdown only opens the dialog. ![The Change baseline profile dialog. Its text says the chosen profile will be set as the new baseline profile for this asset and that health scores and diagnostics will be recalculated using the new profile thresholds, with that whole warning boxed. A blue panel below names Gearbox with its description, and under it a row shows the chip Dynamic Baseline, an arrow, and the chip Gearbox. Cancel and Apply changes buttons sit along the bottom](/images/monitoring/mon-baseline-03.webp) *Changing the profile recalculates every health score and diagnostic against the new thresholds.* ## What happens next The Health tab reloads on the new profile. Health scores and diagnostics are recalculated against its thresholds, which is what the confirm dialog warns about. Expect the numbers to move, sometimes by a lot. A compressor that scored low on **Dynamic Baseline** can score well on **Reciprocating Compressor**, because the harmonics the first profile counted against it are ordinary for the second. That is recalculation, not a repair and not a fault. So compare scores within one profile, not across a change. If you also run health rules on this machine, check them after the move: they fire on the recalculated scores, see [Asset event rules](/docs/alerts/asset-event-rules/). ## Errors | Symptom | Cause | Do this | |---|---|---| | **Failed to update baseline profile** | The change did not save, and the machine keeps the profile it had | Open the dropdown again and repeat the change. If it repeats, see [Get support](/docs/get-started/get-support/) | | No profile dropdown on the machine's page | The asset carries a BeamTracker, or the device is on firmware below 5 | Neither has a health baseline, see [Monitor machine health and vibration](/docs/monitoring/machine-health/#legacy) | | Every score jumps right after a change | Recalculation on the new thresholds | Nothing. Read the trend from the change forward | | Gauges read **No Data** after a change | The sensor has not collected enough samples yet | Wait, then check the device is reporting in [View your devices](/docs/hardware/view-devices/#indicators) | ## See also - [Monitor machine health and vibration](/docs/monitoring/machine-health/) - [Review and dismiss machine events](/docs/monitoring/asset-events/) - [Asset event rules](/docs/alerts/asset-event-rules/) - [Calibrate SenseAi and SenseAi Embedded](/docs/hardware/calibrate-senseai/) --- # Map your floor with Canvas Source: https://www.iotflows.com/docs/monitoring/canvas/ Build a floor plan at /assets?select=canvas whose machine tiles show live status: add a floor-plan image, draw the floor with rectangles, lines, arrows, ellipses, polygons, stars and text, drag each machine tile into position, edit any element in the property drawer, and rely on autosave. Desktop only, one canvas per organization. # Map your floor with Canvas Build a floor plan whose tiles show live machine status. A *canvas* is a drawing surface for your organization, reached from the Assets page. Every machine appears on it as a *status tile*: a card with the machine's picture, name, identifier and live state. You draw the floor around the tiles and drag each to where its machine stands. **Prerequisites.** Canvas is desktop only: it is absent from the mobile app's Assets tabs. To edit, sign in as an Organization Owner or Administrator, see [Roles reference](/docs/admin/roles-reference/). Tiles show status only for machines with a paired sensor, see [Add a machine](/docs/monitoring/add-an-asset/). **Choose Canvas when** your operators think in floor position, "the press by the dock", rather than in machine names. If your fleet is a list on a spreadsheet, the [Assets page](/docs/monitoring/assets-overview/) is faster to build and easier to keep correct. ## Open Canvas Open **Assets** and select the **Canvas** tab. The address bar reads `/assets?select=canvas`. On first open, every machine sits on a diagonal from the top left: the default placement, not a saved layout. There is one canvas per organization, so every edit is saved for everyone. ![The Canvas tab showing a floor plan of about ten machine tiles arranged over rectangles and labels that outline the cells, with some tiles reading Running in green and others showing a stop time in orange or red](/images/monitoring/mon-canvas-01.webp) *A finished floor plan. Tiles show live machine status in position.* ## Add a background Start with the floor-plan image, because elements stack in the order you add them and nothing can be sent behind an earlier one. 1. In the toolbar at the bottom of the screen, select the **image** button. 2. Choose an image file. It lands near the top left at its natural size. 3. Drag a corner handle until it covers the floor. The image is stored inside the canvas, so a large photograph slows every load. Export it at about the size it will display. You do not need a background if a few rectangles and labels show where each cell is. A plan of six machines is often clearer without one. ![A floor-plan drawing placed on the canvas with its corner handles showing, and the image button highlighted in the toolbar at the bottom of the screen](/images/monitoring/mon-canvas-02.webp) *Adding a floor plan image as the background.* ## Draw the floor Each toolbar button adds one element at the center of your view. Drag it into place, then use a corner handle to resize it or the top handle to rotate it. ![The Canvas toolbar with numbered callouts on its buttons: rectangle, line, arrow, ellipse, polygon, star, image, text, and the red clear button at the end](/images/monitoring/mon-canvas-03.webp) *The element types: rectangle, line, arrow, ellipse, polygon, star, image and text.* ### Canvas elements The numbers match the callouts on the toolbar, left to right. Every element also has a position and a rotation. | | Element | Adds | Properties | Live data | |---|---|---|---|---| | 1 | Rectangle | A rounded box, for a cell outline | Size, corner radius, fill | None | | 2 | Line | A line with a handle at each end | Length, stroke | None | | 3 | Arrow | A line with an arrowhead, for flow | Length, stroke, pointer | None | | 4 | Ellipse | An oval | Size, fill | None | | 5 | Polygon | A regular polygon, five sides by default | Count, radius, fill | None | | 6 | Star | A star, five points by default | Count, inner and outer radius, fill | None | | 7 | Image | A picture from your computer | Size | None | | 8 | Text | A label. Double-click it to edit the words | Font size, fill | None | | | Status tile | One per machine, placed for you | Size | Name, identifier, picture, live state | To remove an element, select it and press **Delete**. The red button at the end of the toolbar clears every drawn element, with no confirmation. Tiles stay. ## Place machine tiles You do not add tiles. Every machine is already on the canvas, and one added later appears at the default position the next time the tab loads. 1. Find the tile by its name. Zoom out if it is off screen, see [Zoom and pan](#zoom). 2. Drag it to the machine's position on the floor. 3. To enlarge it, drag a corner handle. A tile keeps its proportions and cannot shrink below its default size. The tile reads **Running** in green, or the time since the last stop in the current status color: orange after one minute and red after five by default, dark red at once for a classified stop. See [Status colors](/docs/monitoring/status-colors/). A tile with no status line means the asset has no paired sensor, not a canvas fault: contact IoTFlows to tie one to the machine, see [Get support](/docs/get-started/get-support/). A tile that reads a stop while the machine is running means the sensor is offline, see [Troubleshoot an offline device](/docs/hardware/troubleshoot-offline-device/). ![A status tile for a Haas VF-2 being dragged from the default diagonal into a rectangle labeled CNC cell, with an arrow from its old position to its new one; a second tile beside it shows a name and identifier but no status line](/images/monitoring/mon-canvas-04.webp) *Dragging a machine tile into position. A tile with no status means the asset has no paired sensor.* ## Edit an element Select any element and the property drawer opens on the right, titled with the element type. Type a value and press **Enter** to apply it. ![A selected rectangle on the canvas with the property drawer open at the right, showing the Position, Transform, Dimensions, Appearance and Fill sections with X, Y, rotation, W, H, opacity, corner radius and a color swatch](/images/monitoring/mon-canvas-05.webp) *The property drawer for the selected element.* ### Property drawer fields | Property | Applies to | Effect | |---|---|---| | **X**, **Y** | Every element | Position, in canvas units | | **Rotation** | Every element | Degrees clockwise | | **W**, **H** | Rectangle, ellipse, star, image, text, tile | Size. A tile changes both together | | **W** | Line, arrow | Distance between the two ends | | **Opacity** | Shapes, lines, text | 0 is invisible, 1 is solid | | **Corner radius** | Rectangle | Rounds the corners | | **Count** | Polygon, star | Sides, or points | | **Radius**, **Inner radius**, **Outer radius** | Polygon, star | Overall size, and how deep a star's points cut | | **Font size** | Text | Scales with zoom | | **Fill** | Rectangle, ellipse, polygon, star, text | Color, from the swatch or as a hex value | | **Stroke** | Line, arrow | Color and weight | | **Pointer** | Arrow | Length and width of the arrowhead | ## Arrange and layer Elements draw in the order you added them, so a newer shape covers an older one, and status tiles draw above every shape. There is no control to send an element forward or back: to put a shape behind another, delete the one that should be on top and add it again. ## Zoom and pan - **Zoom:** scroll the mouse wheel. The view zooms around the pointer. - **Pan:** drag any empty part of the canvas. - **Select:** click an element. One at a time; there is no box selection. Zoom and pan are remembered in your browser, not on the canvas. ## Saving Every change saves on its own within a fraction of a second. There is no save button and no undo: dragging a tile back is the only way to reverse a move. If a save fails, a toast carries the server's message or reads "Something went wrong". The change is on your screen but not stored, so reload the tab to see what was kept. ## See also - [Display a wallboard on a TV](/docs/monitoring/wallboards/) - [Monitor your fleet on the Assets page](/docs/monitoring/assets-overview/) - [Status colors](/docs/monitoring/status-colors/) - [Add a machine](/docs/monitoring/add-an-asset/) --- # Classify a downtime event Source: https://www.iotflows.com/docs/monitoring/classify-downtime/ Put a reason on a machine stop from the status bar, the machine page's Activity list, Operator View's All Downtime tab, or the iOS work-order screen. Classify one stop or many at once, split a stop that holds two reasons, change an activity's operation, remove a classification, delete a false activity, and open a maintenance work order from the classification modal. # Classify a downtime event Every way to put a reason on a stop, and how to correct one you got wrong. A *downtime event* is one stretch of a machine's timeline in the down state, as defined in [Metrics](/docs/monitoring/metrics-reference/). Classifying it means picking a category, adding a note if the category asks for one, and saving. Until you do, the stop counts as **Unclassified** on every report. **Prerequisites.** A category list to pick from, see [Manage downtime categories](/docs/monitoring/downtime-categories/). You do not need to classify every stop by hand: rules in [Classify downtime automatically](/docs/monitoring/auto-downtime-rules/) handle short stops, shift edges and scheduled breaks. ## Where you can classify Each surface opens the same **Classify Downtime** modal, so the category list, the note field and the errors are identical everywhere. What differs is how many stops you can select and where the surface sits. | Surface | Client | Single | Bulk | Split | |---|---|---|---|---| | Status bar segment on a machine page or in Operator View | Web | Yes | No | Yes | | **Activity** list on a machine page | Web | Yes | No | Yes | | **All Downtime** tab in Operator View | Web | Yes | Yes | Yes | | Work-order detail | iOS app | Yes | Yes | Yes | | Downtimes report | Web | Read only | No | No | Choose the status bar for a stop you can see happening. Choose the **Activity** list or the **All Downtime** tab when you are clearing a backlog at the end of a shift. The Downtimes report ranks stops but does not edit them, see [Analyze downtime with Pareto and trend charts](/docs/monitoring/downtimes/). ## Classify from the status bar The status bar at the top of a machine page, `/assets/selected-asset/:id`, draws one segment per activity across the shift. An *activity* is one interval in a single state, running or down. Red segments are stops. 1. Click the red segment. A card opens showing the start time, the duration and the current category, if any. 2. Click the pencil icon. The **Classify Downtime** modal opens. 3. Pick a category. Categories are grouped by severity, **None** to **High**, and a calendar icon marks the ones that stand for [planned downtime](/docs/monitoring/downtime-categories/#planned). 4. Narrow the list if it is long. Switch the grouping to **Category Type**, filter to **Planned** or **Unplanned**, or turn off **Show Default** to hide the built-in IoTFlows categories. See [Open the category list](/docs/monitoring/downtime-categories/#open). 5. Type a note in **Additional notes** if the category marks it with an asterisk. 6. Click **Classify**. Gray on the bar is not downtime. It is a stretch where the sensor sent nothing, and it carries no segment to classify. See [Troubleshoot an offline device](/docs/hardware/troubleshoot-offline-device/). ![The shift status bar at the top of a machine page, running 8am to 5pm. Dark red stops separated by thin green running stretches fill the bar to about 1:30pm, one stop near 11:30am is highlighted in bright red, and the rest of the bar is empty](/images/monitoring/mon-classify-01.webp) *Classifying from the shift bar: click the stop you can see.* ![The Classify Downtime modal scrolled to the end of its category list. Chips sit under the Low, Medium and High severity headings, Lunch Break and Tool Change carry a blue calendar icon marking them as planned downtime, several chips carry an amber alert icon, and Jammed Machine is selected and shaded. An empty Additional notes field, a Create Maintenance Workorder link and the Cancel, Remove Classification and Classify buttons run along the bottom](/images/monitoring/mon-classify-02.webp) *The classification modal. The note field is required for some categories.* ## Classify from a machine's activity list The Downtimes report table is read only. The list for working through a backlog is **Activity** on the machine page, under the Analytics tab. 1. Open the machine page and scroll to **Activity**. 2. Click the **Unclassified** filter. The count beside it is the size of the backlog. 3. On a stop, click the pencil icon and classify as in [the status bar](#status-bar). The **Downtime Classifications** section on the same page also carries a **Classify** button. It lists every stop in the section's date range, and you pick one from the list before the modal opens. ![The Activity list on a machine page with filter pills reading All 32, Uptime 15, Classified 13 and Unclassified 4, the Unclassified pill selected, and four stops below it each with a start time, a duration, and split, pencil and trash icons](/images/monitoring/mon-classify-03.webp) *Classifying from the Activity list, filtered to Unclassified, when you are working through a backlog.* ## Bulk classify Bulk classification applies one category and one note to several stops in one save. On the web it lives in Operator View, see [Use Operator View on the shop floor](/docs/monitoring/operator-view/). 1. Open the machine in Operator View and click the **All Downtime** tab. 2. Click each stop to select it, or click **Select all N unclassified**. 3. Click **Classify N Downtimes** in the bar that appears at the bottom. 4. Pick a category, add a note, and click **Classify N Downtimes**. Only unclassified stops are selectable. Use bulk for a run of stops that genuinely share one cause, for example five short stops during one mold wash. Do not use it to empty the backlog with a guess: six stops labeled **Other** teach the [Pareto](/docs/monitoring/downtimes/#pareto) nothing. ![Operator View for Doosan 2600 with the All Downtime tab selected, the Unclassified filter active, six stops each with a ticked checkbox, a Deselect all button at the top right, and a bottom bar reading 6 selected and Classify 6 Downtimes](/images/monitoring/mon-classify-04.webp) *Bulk classification. Use it for a run of stops that genuinely share one cause.* ## Split a downtime A *split* cuts one stop into two at a time you choose, so each half can carry its own category. 1. Open the stop from the status bar or a list and click the split icon. The **Split Downtime** modal opens. 2. Drag the **Split time** slider between the stop's start and end. 3. Click **Split**. The toast says the split can take up to about 20 seconds. 4. Classify each half. Split a stop when one interval contains two genuinely different reasons, for example a 90-minute stop where a changeover ran into a breakdown at the 30-minute mark. Do not split to make a number look better; the Pareto is only useful if the categories are honest. ![The Split Downtime modal for a stop from 12:54 pm to 2:21 pm, with a Split time slider set to 1:57 pm, an arrow pointing at the slider handle, and Cancel and Split buttons](/images/monitoring/mon-classify-05.webp) *Splitting a stop that contains two different reasons.* ## Change an activity's operation Running activities carry the operation the machine was making. If the machine was running a different job than the one recorded, the counts land on the wrong part. 1. In the **Activity** list, click the **Uptime** filter. 2. Click the pencil icon on the activity. The **Edit Activity** modal opens. 3. Pick the correct **Operation** and save. This edits the activity, not the job. For the job itself see [Run a job](/docs/production/run-a-job/). ## Unclassify Removing a classification puts the stop back in the unclassified queue and keeps the interval itself. 1. Open a classified stop. 2. Click **Remove Classification**, in the modal or on the card. 3. Confirm **Remove**. Unclassify when the category was wrong and the right one is not yet known. If you already know the right category, classify again instead: the new category replaces the old one in one step. ![The popup card for a stop headed STOPPED 11:49am to 12:10pm, classified as Jammed Machine with a Medium severity badge. Four icons sit at the right, and a tooltip reading Remove Classification hangs under the first](/images/monitoring/mon-classify-06.webp) *Removing a classification puts the stop back in the queue.* ## Delete an activity Deleting removes the activity record itself, not only its category. Use it for an activity that did not happen, for example a stop recorded while a sensor was being remounted. 1. Open the activity from the status bar or a list. 2. Click the trash icon. 3. Confirm **Delete**. You do not need delete to fix a wrong reason. That is [unclassify](#unclassify) or a new classification, and both keep the history. ## Create a work order from a stop A stop that needs maintenance can become a work order without leaving the modal. 1. In **Classify Downtime**, click **Create Maintenance Workorder**. 2. Fill in the panel that expands. The title is prefilled with the category and the description with your note, and the machine is set to the one whose page you are on. 3. Click **Submit Request**, then click **Classify**. Fields and follow-up are on [Create a work order](/docs/maintain/create-a-work-order/). ![The Classify Downtime modal with Robot Failure selected, Motor 1 has failed typed in Additional notes, and a New Maintenance Request panel expanded below. The panel's title reads Robot Failure, its description Motor 1 has failed, its machine Doosan 2600, and a Submit Request button spans its bottom](/images/monitoring/mon-classify-07.webp) *Turning a stop into a maintenance work order without leaving the classification.* ## On mobile In the IoTFlows iOS app, open a work order and tap **Classify Downtime** under the shift timeline. The badge on the button is the unclassified count. Tap one segment to classify it, or tap several to classify them together. Each segment carries **Split** and **Unclassify**, but the app cannot delete an activity. The Android app shows downtime but cannot classify it. See [Install the mobile app](/docs/get-started/install-mobile-app/). ## Errors | Message | Means | |---|---| | **This category requires an additional note** | The category was configured with a mandatory note. Type one in **Additional notes** and classify again | | **Failed to classify** | The save did not reach the server. Nothing changed; retry | | **Failed to remove classification** | The category is still on the stop; retry | | **Failed to delete activity** | The activity is still there; retry | ## See also - [Manage downtime categories](/docs/monitoring/downtime-categories/) - [Classify downtime automatically](/docs/monitoring/auto-downtime-rules/) - [Analyze downtime with Pareto and trend charts](/docs/monitoring/downtimes/) - [Create a work order](/docs/maintain/create-a-work-order/) --- # Manage downtime categories Source: https://www.iotflows.com/docs/monitoring/downtime-categories/ Downtime categories are the reason codes operators pick from when they classify a machine stop. Create one under a severity heading, require a note on the reasons that need one, mark it as planned downtime, tag it with a category type, give it a color that carries through to the Downtimes report, rename it, and understand why deleting one unclassifies every stop that ever used it. # Manage downtime categories Build the list of reasons operators pick from, and decide which ones demand a note. A *downtime category* is a reason code an operator puts on a machine stop, for example `Tool change`. Each carries a severity, an optional color, a flag that forces a note, a planned or unplanned setting, and an optional category type. One list serves every machine in the organization. **Prerequisites.** Organization Owner or Organization Administrator, see [Roles and permissions](/docs/admin/roles-reference/). Other roles see the controls disabled. ## Open the category list Categories have no settings page. You edit them from the **Classify Downtime** modal, from **Auto downtime classification** under `/settings/organization`, or from the classify sheet on a phone. Categories sit under four severity headings: **None**, **Low**, **Medium**, **High**. IoTFlows ships built-ins every organization sees; turn off **Show Default** to leave only your own. Only your own carry a pencil, so built-ins cannot be renamed, recolored, or deleted. Three controls sit above the list and change what you see, not what is stored: | Control | Options | Effect | |---|---|---| | Grouping | **Severity**, **Category Type** | Which headings the chips file under, see [Group categories with types](#types) | | Planned filter | **All**, **Planned**, **Unplanned** | Hides categories that do not match, see [Mark a category as planned](#planned) | | **Show Default** | On or off, on by default | Whether the built-in IoTFlows categories are listed | Your choices are saved in the browser and reapplied everywhere the picker appears, including the classify sheet on a phone. An operator who filters to **Unplanned** still sees that filter tomorrow, so say so before you leave a shared touchscreen set that way. ![The Classify Downtime modal. Under the heading Select Downtime Category sit three controls: a Severity and Category Type pair with Severity selected, an All, Planned and Unplanned filter with All selected, and a Show Default switch turned on. Below them the underlined severity headings None in gray and Low in green each carry a row of rounded category chips. Chips the organization created carry a pencil, Lunch Break and Tool Change carry a blue calendar icon marking them as planned downtime, and a plus button follows the last chip in each severity](/images/monitoring/mon-cat-01.webp) *The downtime category list, with the grouping, planned filter and Show Default controls above it.* ## Create a category 1. Click the **+** on the severity row the category belongs under. 2. Type a name in **Category name**. 3. Turn on **Require additional note** if the reason is not actionable alone. 4. Turn on **Planned downtime** if this reason is work you schedule. 5. Pick a **Category type**, or leave it clear. 6. Pick a color, or leave the default red. 7. Click **Add**. A **Downtime category added** toast confirms it. An empty name returns `Category name is required` and creates nothing. ### Category fields | Field | Required | Values | Effect | |---|---|---|---| | **Category name** | Yes | Free text | The label operators see everywhere | | Severity | Yes | The row you create under | See [Set severity](#severity) | | **Require additional note** | No | On or off, off by default | Makes **Additional notes** mandatory | | **Planned downtime** | No | On or off, off by default | Marks stops as scheduled, see [Mark a category as planned](#planned) | | **Category type** | No | One type, or none | Tags it for grouping, see [Group categories with types](#types) | | **Color** | No | Default red, or a swatch | Colors it on the Downtimes report | ![The Add Medium Category form open over the category list, beside the chips filed under the None and Low severity headings. The form holds a name field reading Troubleshooting, a Require additional note row whose checkbox is ticked and whose helper text reads Operator must add a note when classified, a Planned downtime row whose toggle is off, a Category type list of Breaks, Changeovers, Failures, Material and Tooling with Failures carrying a check and a New type field below it, a Color row showing a dark red dot, a line reading Downtimes classified under this category will show as the default red, and Cancel and Add buttons](/images/monitoring/mon-cat-02.webp) *Creating a category: the severity row you open the form under sets its severity.* ## Set severity *Severity* is how much a stop of this kind costs you, from **None** to **High**. It decides the heading the category files under and its color. The edit form has no severity control, so a category cannot move between headings. To move one, create it again under the correct row, then read [Delete a category](#delete). ### Severity levels | Severity | Use for | Where it shows | |---|---|---| | **None** | Not a loss: a break | Gray heading | | **Low** | Planned work: a changeover | Green heading | | **Medium** | Avoidable stops: waiting on material | Amber heading | | **High** | Stops needing someone now: a breakdown | Red heading | ## Require a note Turn on **Require additional note** and the operator must fill **Additional notes** before the stop will save. The category then carries an amber alert icon in the picker. Require a note only where the reason alone tells you nothing you can act on. `Other` and `Breakdown` earn it. `Changeover` does not: ten copies of the word "changeover" is all it buys you. Notes drive the only-with-notes filter on the [Downtimes report](/docs/monitoring/downtimes/). ![The Edit Category form open over the Classify Downtime modal, for the Machine Failure chip which carries an amber alert icon and a pencil. The form holds a name field reading Machine Failure, a Require additional note row whose checkbox is ticked and whose helper text reads Operator must add a note when classified, a Planned downtime row whose toggle is off, a Category type list of Changeovers, Failures, Material and Tooling with Failures carrying a check, a Color row showing the default red dot, and Delete, Cancel and Save buttons](/images/monitoring/mon-cat-03.webp) *The Require additional note control: Operator must add a note when classified.* ## Mark a category as planned *Planned downtime* is a stop you scheduled, for example a changeover or a preventive maintenance window. It is a setting on the category, not on the individual stop, so every stop classified under `Preventive maintenance` is planned and every stop under `Breakdown` is not. Turn on **Planned downtime** in the add or edit form. Its helper line reads "Downtime using this category is planned". The setting is off by default, and you can change it on an existing category without touching the stops already classified under it. A planned category carries a calendar icon on its chip, ahead of the name, with the tooltip **Planned downtime**. Operators see the icon while they classify, which is the cheapest way to tell them that a reason is one you expected. ![The Edit Category form open over the Classify Downtime modal, above the Tool Change chip in the Low severity row. The form holds a name field reading Tool Change, an unticked Require additional note row, a Planned downtime row whose toggle is on and whose helper text reads Downtime using this category is planned, and a Category type list with a Clear link at its right and four rows, Changeovers carrying a blue check, then Failures, Material and Tooling, each with a pencil and a trash icon, above a New type field and a plus button. A Color row showing the default red dot and the Delete, Cancel and Save buttons close the form](/images/monitoring/mon-cat-05.webp) *The Planned downtime toggle and the Category type picker, both on the category form.* ### Choose planned or unplanned Turn **Planned downtime** on when you decided in advance that the machine would stop: - Scheduled preventive maintenance - A changeover or setup you wrote into the schedule - A break or a shift handover the plan accounts for Leave it off for everything the schedule did not account for, including a tool that broke early and a changeover that was not planned for that shift. If you have to think about whether a reason was scheduled, it was not. > **Warning:** > **Planned is not the same as low severity.** Severity says what a stop costs you, planned says whether you chose it. A four-hour scheduled rebuild is planned and still **High**. Set the two independently, see [Set severity](#severity). Today the flag drives the picker: the calendar icon on the chip, and the **All**, **Planned**, **Unplanned** filter above the list. The category filter on the [Downtimes report](/docs/monitoring/downtimes/) and the [Advanced report](/docs/monitoring/advanced-report/) still lists categories by severity, so plan to read planned and unplanned apart by selecting the categories themselves. ## Group categories with types A *category type* is a tag you put on a downtime category so that related categories can be grouped and reviewed together, for example a `Failures` type over `Machine Failure`, `Robot Failure` and `Jammed Machine`. Types belong to the organization, and one type can carry any number of categories. A category holds at most one type. Types are separate from severity: severity ranks a single category, a type collects several. ### Create a type Types are managed from inside the category form, so there is no separate page. 1. Click the **+** on a severity row, or the pencil on an existing category. 2. Type a name in **New type** under **Category type**. 3. Click the **+** beside the field. A **Category type added** toast confirms it, and the new type is selected for this category. 4. Click **Add** or **Save** to store the type on the category. Creating a type adds it to the organization immediately, before you save the category. If you close the form without saving, the type stays and the category keeps the type it had. ### Assign, clear, rename and delete | Action | How | Result | |---|---|---| | Assign | Click a type in the list | A check mark marks it | | Clear | Click the selected type again, or click **Clear** | The category files under **No Category Type** | | Rename | Click the pencil on the type, edit, click the check | Renames it everywhere, on every category that carries it | | Delete | Click the trash on the type, then confirm | Removes the type from the organization | Rename rather than delete. A rename keeps every category grouped as it was, which is the whole point of the tag. ### Group the picker by type Switch the grouping control above the list from **Severity** to **Category Type**. The chips then file under one heading per type, sorted alphabetically, with **No Category Type** last. Categories with no type collect there, which makes that heading the list of categories still to tag. The grouping is a view, not a change to the categories. Switching back to **Severity** leaves every category exactly as it was. ![The Select Downtime Category list with Category Type chosen on the grouping control, All on the planned filter and Show Default turned off. Category chips file under five underlined blue headings: Breaks carrying Break, Lunch and Lunch Break, each with a calendar icon; Changeovers carrying Tool Change, also with a calendar icon, and Testing; Failures carrying Tool Broken, No Power, Robot Failure, Jammed Machine and Machine Failure; and Material carrying No Part, No Sample, No Parts and No inventory](/images/monitoring/mon-cat-06.webp) *The picker grouped by category type, with the planned filter beside it.* ### Decide whether you need types You probably do not need types. A list of eight to twelve categories reads fine under the four severity headings, and a tag on top of that is one more thing to maintain. Add types when the same review keeps cutting across severities. For example, `Machine Failure` is **High** and `Jammed Machine` is **Medium**, but a maintenance review wants both, so a `Failures` type earns its place. Keep the number of types well under the number of categories: a type per category groups nothing. ## Change a color 1. Click the pencil, then the swatch beside **Color**. 2. Pick a swatch, or **Default red** to clear the color. 3. Click **Save**. A **Downtime category updated** toast confirms it. A category with no color draws in the standard downtime red. Your color carries through to the Pareto and the by-interval and by-asset bars on the Downtimes report. You do not need a color on every category. Color the two or three reasons you are working on now and leave the rest red. ![The Edit Category form for Machine Failure scrolled to its color grid, with the Planned downtime row and the Category type list above it. Twenty-one swatches sit in three rows, the dark default red first, and a white check mark marks a violet swatch in the bottom row. The Color dot at the right of the row has turned violet, and the line under the grid reads Downtimes classified under this category will show as Violet 600 instead of the default red](/images/monitoring/mon-cat-04.webp) *The color palette: a category's color carries through to the charts on the Downtimes report.* ## Delete a category Click the pencil, click **Delete**, then confirm in the **Delete Downtime Category** dialog. > **Warning:** > **Deleting a category rewrites your history.** It comes off every downtime ever classified with it, and those stops become unclassified. There is no undo. Rename rather than delete. Open the pencil, change the name, and save: the stops keep their classification. ## Design a category list Keep the list to eight to twelve categories. Operators classify from a touchscreen mid-shift, and a list that scrolls gets the first visible item every time. The Pareto then measures list order, not the plant. Write categories at the level you can act on. `Machine problem` names nothing, and wins the Pareto every month without telling you what to fix. Set **Planned downtime** on the whole list in one pass, when you build it. It is a single toggle per category, and doing it later means going back through a list an operator has already been classifying against. ## See also - [Classify a downtime event](/docs/monitoring/classify-downtime/) - [Classify downtime automatically](/docs/monitoring/auto-downtime-rules/) - [Analyze downtime with Pareto and trend charts](/docs/monitoring/downtimes/) - [Plan your rollout](/docs/get-started/roll-out-plan/) --- # Analyze downtime with Pareto and trend charts Source: https://www.iotflows.com/docs/monitoring/downtimes/ The Downtimes report ranks your downtime reasons by the time they cost, using a Pareto chart, a by-interval trend and a by-machine breakdown over a paginated table of individual stops. Filter by department or machine, shift, category, severity, and only-with-notes, sort by date or duration, pick a rolling date preset, and export the result as CSV or PDF. Shift islands, in the Shifts popover, reports a shift that crosses midnight entirely on the day it began. # Analyze downtime with Pareto and trend charts Find the few downtime reasons that cost the most, and see whether they are getting better. The Downtimes report is the root cause analysis tool for production losses. It answers three questions about every stop in your fleet: which reasons cost the most time, how that changes over time, and which machines carry it. The page is at `/assets?select=downtimes`. **Prerequisites.** Machines reporting, see [Monitor your fleet on the Assets page](/docs/monitoring/assets-overview/). Stops classified, see [Classify a downtime event](/docs/monitoring/classify-downtime/). Every figure on this page is defined in [Metrics](/docs/monitoring/metrics-reference/). ![The Downtimes report over the last four weeks. A filter bar across the top shows Machines 22, Shifts, Categories 17, Sort by Date: New to Old, Reset Filters, an Only with Notes toggle, an Actions menu and a Last 4 weeks date button. Below it, the Downtimes by Category Pareto chart ranks nine categories from Mold Wash at 60.76 hours down to Unclassified at 0 hours, with a cumulative percentage line rising to 100 percent. Under that, Downtimes by Time Interval shows four stacked weekly bars, W34 to W37, and Downtimes by Asset shows one stacked bar per machine numbered 214 to 256, each with an hours label.](/images/monitoring/mon-down-01.webp) *The Downtimes report. The Pareto orders your reasons by the time they cost.* ## Read the Pareto chart **Downtimes by Category** ranks every downtime reason by total duration, longest first. Each bar is one category, and the line over the bars is the cumulative percentage, so you can see how few categories carry most of the loss: the few that matter end where the line flattens. Start with the leading bar. A plant with 60 hours of **Mold Wash** and 3.5 hours of **Parts in inspection** gets more back from a faster mold wash than from a faster inspection. > **Warning:** > **Is Unclassified your tallest bar?** Then the Pareto is ranking the absence of reasons, not the reasons. Put reasons on the stops, or turn on [automatic classification](/docs/monitoring/auto-downtime-rules/) for the routine ones. ![The Downtimes by Category Pareto chart. Nine bars run left to right in descending order: Mold Wash 60.76 hours, Unplanned maintenance 31.76, Required foreman approval 27.84, Samples sent to postcure 16.50, Lunch Break 10.35, Mold Wash (Sand Blast) 7.73, Parts in inspection 3.50, Breaks - None 0.68 and Unclassified 0.00. A cumulative percentage line climbs from about 40 percent at the first bar to 100 percent at the last.](/images/monitoring/mon-down-02.webp) *A Pareto with a clear leader. That bar is where the next improvement is.* ## Read the interval and asset charts Two stacked bar charts follow the Pareto. Both split each bar by category, in the Pareto's colors, with a legend on the right. Hover any bar for its exact value. **Downtimes by Time Interval** plots downtime per day, week, month, quarter or year, depending on the interval in the date filter. Read it to see whether a reason is trending, seasonal, or responding to a fix. For example, a **Mold Wash** segment that shrinks week over week after the wash procedure changes is the evidence the change worked. **Downtimes by Asset** plots the same downtime per machine, with a duration label on each segment such as `16.73h`. Read it to see whether a category is spread across the floor or concentrated on one machine. Click a category in the legend to hide or show it. Hiding the leading category is the fastest way to see what is underneath it. ![Two stacked bar charts with a category legend on the right of each. Downtimes by Time Interval shows four weekly bars labeled W34 (W3 AUG) to W37 (W1 SEP), each split by category color with hour labels such as 26.01h for Mold Wash. Downtimes by Asset shows one bar per machine, numbered 214 to 256, split by the same colors, with labels such as 16.73h on machine 226 and 17.78h on machine 244.](/images/monitoring/mon-down-03.webp) *The same downtime split by interval and by machine.* ## Filter the report The filters sit across the top of the page, or behind the **Filters** button on a phone. Every filter is written into the address bar, so the URL is the report: copy it and it opens in the same state for anyone with access. The date filter picks both a window and an *interval*, the grouping the by-interval chart uses. Choose **Daily**, **Weekly**, **Monthly**, **Quarterly** or **Yearly**, then a rolling preset such as **Last 7 days**, or a custom range. A rolling preset stays rolling: a link to **Last 7 days** shows the last seven days on the day it is opened. ### Filters reference | Filter | Values | Applies to | |---|---|---| | **Date** | An interval (**Daily**, **Weekly**, **Monthly**, **Quarterly**, **Yearly**), then a rolling preset for that interval or a custom range | Every chart and the table. The interval also sets the grouping of **Downtimes by Time Interval** | | **Machines** | Whole departments, or individual machines inside them | Every chart and the table | | **Shifts** | One or more of your organization's shifts, multi-select | Every chart and the table. Only stops inside the selected shifts count | | **Shift islands** | On or off, at the top of the **Shifts** popover. Off by default | Every chart and the table. On, a shift that crosses midnight reports entirely on the day it began | | **Categories** | Individual downtime categories, plus **Unclassified** | Every chart and the table | | **Severity** | A group heading inside **Categories**: **Unclassified**, **None**, **Low**, **Medium**, **High**, each with a count. Ticking a heading selects every category of that severity | Every chart and the table | | **Sort** | **Date: New to Old**, **Date: Old to New**, **Duration: High to Low**, **Duration: Low to High** | The table only | | **Only with Notes** | On or off | The table only. Hides stops that carry no operator note | *Severity* is a rank each category carries, set when the category is created, see [Manage downtime categories](/docs/monitoring/downtime-categories/). **Reset Filters** clears every filter except the date. Turn on **Shift islands** before you read a night shift's downtime. Off, the hours a shift works after midnight are charged to the next day, so a Monday-to-Friday night shift puts downtime on Saturday, a day it never ran. This report and the [Advanced Report](/docs/monitoring/advanced-report/#shift-islands) are the only two places the toggle exists, see [Where the overnight hours land](/docs/admin/shifts-and-timezone/#overnight-hours). ![The right of the Downtimes by Time Interval chart, filtered to the Evening Shift, which runs 5 PM to 1 AM Monday through Friday, with Shift islands off. Three columns stand over the day labels Thu Sep 24, Fri Sep 25 and Sat Sep 26. The Thursday and Friday columns are tall, each a red Unclassified block over a blue Entire Shift Down block labeled 12h and 28h. The Saturday column is a stub, labeled 3.34h and 10h.](/images/monitoring/mon-down-06.webp) *The last three days of the week, Shift islands off. Saturday carries ten hours of Entire Shift Down from Friday night, on a day the Evening Shift never runs.* Two filters answer two different questions: - Filter to **Only with Notes** when you are building a maintenance case. The notes are what a technician needs. - Filter to **Unclassified** when you are checking whether operators are keeping up. A growing unclassified share means the habit is slipping, not that the plant is running better. ![The Downtimes report filter bar with the Categories popover open. The bar shows Machines 22, Shifts, Categories 14, Sort by Date: New to Old, Reset Filters, an Only with Notes toggle, an Actions menu and a Last 4 weeks button. The popover has a Search categories box, then a LOW heading with its own checkbox and 12 categories such as Short Downtimes, Shift change and Machine setup, then a MEDIUM heading with 21 categories such as No job and Broken tool, and Clear and Apply buttons at the bottom.](/images/monitoring/mon-down-04.webp) *Every filter on the report. The severity headings inside Categories select every reason of that severity at once.* ## Read the detail table Below the charts, a table lists each stop matching the filters, 25 to a page. | Column | Shows | |---|---| | Machine | Photo, name and identifier, with the stop's start and end times | | **Duration** | How long the stop lasted | | **Category** | The downtime reason, or blank if unclassified | | **Categorized By** | The person who classified it, or IoTFlows AI for stops an automatic rule classified | | **Note** | The operator's note, if one was added | | **Severity** | The category's severity as a colored badge: **None**, **Low**, **Medium** or **High** | The table covers stops that overlap your selected dates and shifts, up to the first 1,000 stops or the first three months. A stop that began before the window, or falls past that limit, is not listed. Narrow the date range if you need every row. Every time on this page is in the organization's time zone, not yours, see [Shifts and time zone](/docs/admin/shifts-and-timezone/). ![Six rows of the downtime detail table. Each row shows a machine photo with a name such as C2 and an identifier such as #6, a duration such as 00:03:59.21 over its start and end times, a category such as Foil factory splice, Mechanical Issue (Specify Why) or Operator Stopped, the avatar and first name of the person who classified it, a note such as Jam or Putting labels, and a severity badge reading Medium, High or Low.](/images/monitoring/mon-down-05.webp) *The detail table. Filtering to only-with-notes builds a maintenance case quickly.* ## Export the report The **Actions** menu at the right of the filter bar downloads the report in two forms, both using the filters you have set. What each export carries is listed in [Available exports](/docs/monitoring/exports-reference/). ### Download a CSV 1. Set the filters. 2. Open **Actions**. 3. Click **Download as CSV**. The file `Downtime Classification Data.csv` carries one row per stop: machine identifier and name, start and end timestamps, duration, category and note. Choose CSV when you want the rows themselves, to pivot in a spreadsheet. ### Download a PDF 1. Set the filters. 2. Open **Actions**. 3. Click **Download as PDF**. 4. Wait for **Generating PDF report… this may take a few seconds.** to become **PDF report generated successfully.** The file `Downtime_Report__to_.pdf` is rendered from the report as you see it, charts included. Choose PDF when the reader needs the picture rather than the rows, for example a weekly review with a plant manager. You do not need to export to get the report to other people. **Share** emails the current view to members of your organization, and **Schedule** sends it on a cadence, see [Email a report and schedule it to repeat](/docs/monitoring/share-and-schedule-reports/). ### Export errors | Message | Means | |---|---| | **Failed to download CSV. Please try again.** | The browser could not build the file. Reload the page and retry once the table has loaded | | **Something went wrong generating the PDF.** | The PDF service could not render the report. Retry; if it repeats, narrow the date range | ## Classify as it happens The report is only as honest as its classifications. Two habits keep it useful. Turn on automatic classification for short stops, start and end of shift, and scheduled breaks, see [Classify downtime automatically](/docs/monitoring/auto-downtime-rules/). Put a tablet at each machine, assigned to that machine, so operators classify a stop as it happens and the note is fresh, see [Set up a dedicated operator station](/docs/monitoring/operator-stations/). ## See also - [Classify a downtime event](/docs/monitoring/classify-downtime/) - [Manage downtime categories](/docs/monitoring/downtime-categories/) - [Classify downtime automatically](/docs/monitoring/auto-downtime-rules/) - [Email a report and schedule it to repeat](/docs/monitoring/share-and-schedule-reports/) - [Available exports](/docs/monitoring/exports-reference/) --- # Edit, hide, archive, or delete a machine Source: https://www.iotflows.com/docs/monitoring/edit-assets/ Rename a machine, take it off the fleet view with Hide, retire it with Archive, restore it, delete one created by mistake, and permanently delete the last few hours of its data. # Edit, hide, archive, or delete a machine Clean up the asset list without losing data you still need. Every field you set when you added a machine stays editable. Four further actions take a machine off the board: **Hide**, **Archive**, **Delete**, and **Delete Data**. They differ in what they remove and in whether you can undo them. Only **Delete** and **Delete Data** destroy anything, and both ask you to confirm before they run. **Before you start** - Sign in as an Organization Owner or Organization Administrator. Other roles see these controls disabled rather than hidden. See [Roles reference](/docs/admin/roles-reference/). - Open the Assets page at `//assets`. See [Monitor your fleet on the Assets page](/docs/monitoring/assets-overview/). Two controls reach everything on this page: - The **⋮** menu on any machine card, list row, or machine page. It carries **Edit**, **Hide**, **Archive**, **Delete Data**, and **Delete**. - **Edit Assets**, at the top of the Assets page. It opens one scrolling list of every machine, split into an **Assets** tab and an **Archived Assets** tab, with the same actions as icons on each row. ![The three-dot menu open on a machine card, showing Edit, Hide, Archive, Delete Data and Delete](/images/monitoring/mon-edit-01.webp) *The ⋮ menu on a machine card lists Edit, Hide, Archive, Delete Data and Delete. Every action on this page starts here or in the Edit Assets list.* ## Edit a machine 1. Select **⋮** on the machine, then select **Edit**. 2. Change any of **Custom Machine Image**, **Machine Identifier**, **Machine Name**, **Select Department**, **Tags**, and **Cascading Group**. 3. Select **Edit Asset**. IoTFlows confirms with "Asset has been edited" and the card redraws with the new values. The catalog model is the one thing you cannot change here. It supplies the photo, the model line, and the manufacturer logo, so correcting it means creating the machine again. Every other field is editable, as listed in [Add asset fields](/docs/monitoring/add-an-asset/#fields). Renaming is safe at any time: reports, exports, and work orders read the current name. **Cascading Group** and **Step** place the machine in a line, which is its own task, see [Group machines into cascades](/docs/monitoring/asset-groups/). ## Hide a machine To *hide* a machine is to take it off the Assets page while it keeps recording. 1. Select **⋮** on the machine. 2. Select **Hide**. IoTFlows confirms with "Asset is now hidden" and the card leaves the page. Hiding filters the machine out of the Assets page and nothing else. Its sensor keeps reporting, its uptime and downtime keep accruing, and it stays in reports, work orders, and the scheduler. The card is gone, so the **⋮** menu is gone with it. Bring the machine back from **Edit Assets**: the **Assets** tab lists every machine including hidden ones, each hidden row carries a **Hidden** badge, and the eye icon on the row puts it back on the board. ## Archive a machine To *archive* a machine is to retire it from the working asset list while keeping everything it recorded. 1. Select **⋮** on the machine, then select **Archive**. 2. Read the confirmation, for example "Are you sure you want to archive Haas VF-2 (trx-as800)?" 3. Select **Archive**. IoTFlows confirms with "Asset has been archived". The machine leaves the Assets page and appears only under **Archived Assets** in **Edit Assets**. Everything it recorded stays: activity, classified downtime, operations, and part counts. Archive is the right move for a machine that has left the plant, and the only move for one that has run production, because [Delete](#delete) is blocked there. ## Restore an archived machine 1. On the Assets page, select **Edit Assets**. 2. Select the **Archived Assets** tab. 3. Find the machine and select the circular arrow at the right of its row, labeled **Unarchive Asset**. 4. Select **Unarchive** in the confirmation that replaces the row. IoTFlows confirms with "Asset unarchived" and the machine returns to the Assets page with its history intact. Nothing expires: a machine archived last year restores the same way. ![The Archived Assets tab of the Edit Assets modal with one archived machine and its unarchive control](/images/monitoring/mon-edit-03.webp) *The Archived Assets tab of Edit Assets. The circular arrow at the right of a row, labeled Unarchive Asset, returns that machine to the Assets page.* ## Delete a machine Deleting removes the asset record itself, the one you created in [Add a machine](/docs/monitoring/add-an-asset/). There is no trash to restore from and no undo. 1. On the Assets page, select **Edit Assets**. 2. On the **Assets** tab, find the machine and select the trash icon on its row. 3. Select **Delete** in the confirmation that replaces the row. IoTFlows confirms with "Asset has been removed". **Delete is blocked for any machine that has operation data.** The trash icon renders gray and carries the reason: "This asset can't be deleted because it has been used in production and has operation data attached to it. If you are no longer using this asset, you can archive it instead." There is no override and no force. [Archive the machine](#archive) instead, which is the intended path for anything that has ever run. ![A grayed-out Delete control with the tooltip explaining that the asset has operation data attached](/images/monitoring/mon-edit-02.webp) *Delete is grayed out for a machine that has operation data, and the tooltip on it points to archiving instead.* > **Note:** > **Delete grayed out on a machine you just created?** The **Delete** entry in the **⋮** menu reads as blocked on a card, a list row, and a machine page even when the machine has never reported. Delete from the **Edit Assets** list instead, which enables the trash icon for any machine with no recorded activity. ## Delete the last N hours of data This deletes the machine's recorded history for a window ending now and leaves the machine itself in place. Use it after a calibration session writes hours of false running time onto a machine that was standing still. 1. Select **⋮** on the machine, then select **Delete Data**. 2. Set the hours field in the sentence **Permanently delete the last N hours of data**. It opens at 2 and accepts up to 240, which is 10 days. 3. Select **Continue**. 4. Type `DELETE` in the confirmation field. 5. Select **Delete Data**. IoTFlows confirms with "Last 8 hours of data has been deleted" for an 8-hour window. ![The Delete Asset Data dialog with the hours field filled in](/images/monitoring/mon-edit-04.webp) *The Delete Asset Data dialog. The hours field sets how far back the delete reaches, counting back from now, and the delete is irreversible.* > **Warning:** > **No undo, and the numbers move.** The dialog says so in red before it takes your confirmation. Deleting recorded history changes uptime, downtime, and every count for that window, on the board and in every report that covers it. See [Uptime](/docs/monitoring/metrics-reference/#uptime). The window always ends at the current moment, so there is no way to delete a stretch that ended yesterday and keep what came after it. Run it while the bad data is still the most recent data. You do not need this to fix one wrong stop or one misread operation. A single activity can be corrected or removed from the machine's activity list, see [Delete an activity](/docs/monitoring/classify-downtime/#delete). ## Choosing between hide, archive and delete | Action | Removes from | Keeps data | Reversible | Blocked when | |---|---|---|---|---| | **Hide** | The Assets page | Yes, all of it | Yes, from **Edit Assets** | Never | | **Archive** | The Assets page, into **Archived Assets** | Yes, all of it | Yes, from **Archived Assets** | Never | | **Delete** | Everywhere, permanently | No | No | The machine has operation data | | **Delete Data** | Nothing, the machine stays | Everything outside the chosen window | No | Never | Choose **Hide** when a machine is temporarily out of service and you want it out of the fleet view. Choose **Archive** when it has left the plant but its history still matters to your reports. Delete only a machine created by mistake, and if it has ever run an operation, the product will not let you. Hide and archive are both reversible. **Delete** and **Delete Data** are the two to slow down for. ## See also - [Add a machine](/docs/monitoring/add-an-asset/) - [Group machines into cascades](/docs/monitoring/asset-groups/) - [Troubleshoot wrong utilization or OEE](/docs/monitoring/troubleshoot-monitoring/) - [Review the organization audit log](/docs/admin/audit-log/) --- # Available exports Source: https://www.iotflows.com/docs/monitoring/exports-reference/ Every export IoTFlows offers, with the column list for each one. Seven surfaces download data: the Downtimes report, the Advanced Report and historical production as CSV or PDF, and Operator Performance, Production Insights, the maintenance table and the scheduler table as CSV. Every export carries the filters you have on screen. The PDF is rendered from the report URL, so it looks like the page; the CSV carries the rows. The audit log has no export. # Available exports Every export in the product: where it lives, what format, and what it contains. Seven surfaces download data. Three reports offer both CSV and PDF, four tables offer CSV only, and everything else in IoTFlows is read on screen. Every export sends the rows the surface is currently showing, so the filters you set are the filters you get. ## Exports by surface | Surface | Format | Respects filters | Column reference | Page | |---|---|---|---|---| | Downtimes report, `/assets?select=downtimes` | CSV, PDF | Yes | [Downtimes CSV](#downtimes-csv) | [Analyze downtime](/docs/monitoring/downtimes/) | | Advanced Report, `/assets?select=advanced_report` | CSV, PDF | Yes | [Advanced Report CSV](#advanced-csv) | [Build a utilization report](/docs/monitoring/advanced-report/) | | Historical production, `/production?select=historical_report` | CSV, PDF | Yes | [Historical production CSV](#historical-csv) | [Compare production over weeks and months](/docs/production/historical-production/) | | Operator Performance, `/assets?select=operator_performance` | CSV | Yes | [Operator report CSV](#operator-csv) | [Measure operator work sessions](/docs/monitoring/operator-performance/) | | Production Insights, `/production?select=insights` | CSV | Yes | [Production Insights CSV](#insights-csv) | [Analyze cost and on-time performance](/docs/production/production-insights/) | | Maintenance board, **Table** view, `/maintenance` | CSV | Yes | [Work order fields](/docs/maintain/work-order-fields/) | [Organize work on the maintenance board](/docs/maintain/maintenance-board/) | | Scheduler board, **Table** and Gantt, `/production?select=scheduler` | CSV | Yes | [Job and scheduler fields](/docs/production/job-fields-reference/) | [Plan jobs in the Production Scheduler](/docs/production/scheduler/) | The three reports put their downloads in one place. Open **Actions** at the right of the filter bar and pick **Download as PDF** or **Download as CSV**, under the **Report actions** heading. The same menu carries **Share** and **Schedule**. The four tables each carry their own control: - **Operator Performance**: a **CSV** button on the toolbar, next to the date range. It is disabled while the report is empty. - **Production Insights**: an **Export CSV** button at the right of the **All operations** table. With **Group** set to **None** it downloads immediately. With **Group** set to **Job** or **Asset** it opens a menu offering **Operation rows**, **Totals by job** or **Totals by asset**, and **Rows + totals**. - **Maintenance** and **Scheduler**: a **CSV** button on the filter bar, rendered only on the **Table** view. The scheduler repeats it as a download icon on the Gantt toolbar, so you do not have to leave the board to get the file. ### Choose CSV or PDF Use CSV when the number is going into a spreadsheet, and PDF when it is going into a meeting. The PDF is rendered on the server from the URL you are on, so it carries the filters and switches you had on screen and it looks like the page: the same charts, the same order. The CSV carries the rows, and nothing else. You do not need either one to get a report to someone who does not log in. **Share** emails the same view to a colleague now, and **Schedule** emails it on a cadence, see [Emailed and scheduled reports](#email). ## CSV column references ### Downtimes CSV Downloads as `Downtime Classification Data.csv`. One row per stop, covering every row the filters match rather than the 25 on the visible page. The header is the raw field names. | Column | Holds | |---|---| | `asset_identifier` | The machine's identifier, or its UUID if it has none | | `asset_name` | The machine's name | | `utilization_start_timestamp` | When the stop began | | `utilization_end_timestamp` | When the stop ended | | `downtime_duration` | The stop's length, formatted for reading | | `downtime_duration_seconds` | The same length in seconds | | `downtime_category_name` | The reason on the stop, empty when the stop is unclassified | | `utilization_downtime_note` | The note an operator left on the stop | Sort on `downtime_duration_seconds`, not on `downtime_duration`. The formatted column is text, so a spreadsheet puts `9m 12s` above `1h 4m`. ### Advanced Report CSV Downloads as `Utilization_Report_2026-08-01_to_2026-08-31.csv`. The file opens with a title block, then a blank line, then the table. The title block records what produced the numbers: the report title and date range, the generation date and your organization timezone, the shifts selected, and one line for each switch that was on, reading `Excluding Unknown from OEE`, `Excluding None from OEE` or `Showing only uptime`. Skip those rows when you import the file, or the spreadsheet reads the title as the header. A report built with **Shift islands** on adds one more line, `Shift islands: on (an overnight shift is counted on the day it began)`. It follows the same rule as the switches: the line appears only when the setting is on, and its absence means the shift was split at midnight. Read it before you compare two exports of the same night shift, because that one line is what separates them, see [Shift islands](/docs/monitoring/advanced-report/#shift-islands). One row per machine per interval, with these 12 columns: `Department Name`, `Asset Name`, `Asset Identifier`, `Period`, `Category`, `Uptime Hours`, `Downtime Hours`, `Unknown Hours`, `Uptime Percentage`, `Downtime Percentage`, `Unknown Percentage`, `Tags`. `Period` is the interval's start and `Category` is its label, so a monthly report at a daily interval writes 31 rows per machine. Multiple tags arrive in one cell, comma separated. Each figure is defined once in [How each metric is calculated](/docs/monitoring/metrics-reference/). ### Historical production CSV Downloads as `Production_Historical_Report.csv`. The name carries no date, so rename the file before you file it or you will not know which window it covers. One row per operation per machine per interval, with these 11 columns: `Timestamp`, `categories`, `part_name`, `operation_name`, `operation_description`, `asset_identifier`, `asset_name`, `total_operation_good_count`, `total_operation_scrap_count`, `asset_good_count`, `asset_scrap_count`. `Timestamp` is the interval's start and `categories` is its label. The two `total_operation_*` columns are the operation's counts across every machine that ran it, repeated on each machine's row, and the two `asset_*` columns are that one machine's share. > **Warning:** > **Columns not lining up?** This file is written without quoting, unlike every other export here. A part name, operation name or description containing a comma splits into two cells and shifts the rest of that row left. > > Every data row also ends with a trailing comma, so spreadsheets show one empty column at the right. Remove commas from the names you care about, or check the row widths after importing. ### Operator report CSV Downloads as `operators_report_Aug 1, 2026_to_Aug 31, 2026.csv`. One row per clocked session, per operator and machine. An operator and machine pair with no sessions in the window still gets a row, with `N/A` in the clock columns. | Column | Holds | |---|---| | `Username` | The operator's IoTFlows handle | | `User First Name`, `User Last Name`, `User Email` | The operator's profile fields | | `Asset Name`, `Asset Identifier` | The machine worked during the session | | `Department Name` | The machine's department | | `Clocked Category` | The label the report gives this session | | `Clocked Runtime Hours`, `Clocked Downtime Hours` | The machine's uptime and downtime during the session | | `Clocked Runtime Percentage`, `Clocked Downtime Percentage` | The same two as a share of the session | | `Clock Start`, `Clock End` | When the operator clocked in and out | > **Warning:** > **Hours columns missing from the file?** The header is taken from the first row of the report. If that row is an operator and machine pair with no sessions, the file comes out in the shorter ten-column form, without the four `Clocked` hour and percentage columns, and the name and email cells are blank on every row below. Filter the report to operators who worked in the window, then download again. ### Production Insights CSV Downloads as `production-insights-operations-2026-09-19.csv`, or `production-insights-operations-job-totals-2026-09-19.csv` for a totals-only export. Either file holds every row the table's search, status and hide-zero filters match, in the sort order the table is in, not just the visible page. There are two layouts, and one control that writes them: - **Operation rows**, 17 columns: `Job`, `Operation`, `Part`, `Asset`, `Asset ID`, `Workorder #`, `Title`, `Status`, `Labor Hours`, `Production Hours`, `Units`, `Total Cost`, `Labor $/unit`, `Production $/unit`, `Profit`, `Profit $/unit`, `Created`. - **Totals by job** or **Totals by asset**, 10 columns: the group name, then `Operations`, `Units`, `Labor Hours`, `Production Hours`, `Labor Cost`, `Production Cost`, `Total Cost`, `Profit`, `Profit $/unit`. **Rows + totals** writes both tables into one file, separated by a blank line. Pick it when you want a finance reader to see the summary without losing the detail behind it, and pick **Operation rows** when the file is going into a pivot table. ### Maintenance and scheduler table CSVs Both boards export the columns their table is showing, in the order it is showing them. Grouping is ignored: the file is one flat list, whatever the board is grouped by on screen. Both files open with a *byte order mark*, the marker that tells Excel a file is Unicode, so accented names survive the import. | Board | File | Always exported | Total columns available | |---|---|---|---| | Maintenance | `maintenance-tasks-2026-09-19.csv` | **WO #**, **Title**, **Assigned To**, **Asset** | 15 | | Scheduler | `scheduler-tasks-2026-09-19.csv` | **Title**, **Assignees**, **Operation**, **Part**, **Quantity**, **Asset**, **Job** | 24 | To widen the export, turn the columns on in the table first. The maintenance table ships showing six optional columns, and the scheduler two, so a default download is far narrower than the totals above. **Part** is the one column that behaves differently. The scheduler table draws the part and the operation in a single cell, but the CSV gives the part its own column, placed immediately after **Operation**. Every column is defined in [Work order fields and statuses](/docs/maintain/work-order-fields/) and [Job and scheduler fields](/docs/production/job-fields-reference/). ## Emailed and scheduled reports The Downtimes report, the Advanced Report and historical production each carry **Share** and **Schedule** alongside the two downloads in the **Actions** menu. **Share** emails the view you built to members of your organization now. **Schedule** saves that view and emails it on a daily to yearly cadence. Neither is a download. Nothing lands in your Downloads folder, and a recipient has to be a member of your organization already, because both dialogs pick from the member list rather than taking a typed address. Choose an export when you need the numbers to leave IoTFlows, and a schedule when the same people need the same report every week. Full procedure in [Email a report and schedule it to repeat](/docs/monitoring/share-and-schedule-reports/). ## What has no export The audit log at `/logs` has no export in any format. Read it in the browser, and filter it down before you go looking, see [Review the organization audit log](/docs/admin/audit-log/). The live monitoring surfaces have none either, by design. The Assets page, Canvas, wallboards and a machine's Health tab are all views of the current moment, and the reports exist to put a window around that data. For utilization use the Advanced Report, and for stops use the Downtimes report. ## Export errors | Message | What happened | Fix | |---|---|---| | Failed to download CSV. Please try again. | The browser could not build the file from the rows on screen | Reload the page, wait for the table to finish loading, then download again | | Something went wrong generating the PDF. | The server could not render the report URL | Try again. If it repeats, narrow the date range: a long window at a fine interval is the usual cause | | An error occurred while downloading | A file or image attached to a work order failed to download. This is not a report export | Open the work order and download the attachment from its detail panel | The PDF takes a few seconds, and a toast reads **Generating PDF report… this may take a few seconds.** while it works. Leaving the page cancels it. ## See also - [Email a report and schedule it to repeat](/docs/monitoring/share-and-schedule-reports/) - [Work order fields and statuses](/docs/maintain/work-order-fields/) - [Job and scheduler fields](/docs/production/job-fields-reference/) - [Review the organization audit log](/docs/admin/audit-log/) - [How each metric is calculated](/docs/monitoring/metrics-reference/) --- # Monitor machine health and vibration Source: https://www.iotflows.com/docs/monitoring/machine-health/ Read the Health tab on a SenseAi asset: the health score and its trend, the seven operations metrics including bearing health, the X, Y and Z axes, the FFT spectrum with its harmonic markers and RPM, the spectrogram and 3D view, the 14 metric trend charts and what each one rises with, the timestamp inspector that lines every chart up on one moment, the legacy view for firmware below 5, and how to tell degradation from a noisy baseline. # Monitor machine health and vibration Read the health dashboard well enough to tell degradation from noise. The Health tab turns the sensor's vibration stream into one score, seven condition gauges, a frequency spectrum and fourteen trend charts. This page says what each surface shows and stops there: the score bands and gauge thresholds are IoTFlows' own and are still being tuned. **Prerequisites.** A SenseAi or SenseAi Embedded asset on **firmware 5 or later**; the firmware is listed in [View your devices](/docs/hardware/view-devices/#fields). A baseline profile, see [Choose a machine health baseline profile](/docs/monitoring/baseline-profiles/). **The Health tab does not exist for a BeamTracker asset**, because a beam sensor reads no vibration. ## Open the Health tab 1. Open the machine's page at `/assets/selected-asset/:id`, or click its card on the Assets page. 2. Click **Health** in the tab strip under the header, between **Jobs** and **Meters**. The **baseline profile** dropdown at the top left names the profile the score is measured against. The time range buttons at the top right set the window every chart shows, from **1h** to **2y**. The dashboard opens on **7d**. ![The Health tab of a SenseAi asset. A baseline profile dropdown reading Dynamic Baseline sits at the top left and a row of time range buttons from 1h to 2y at the top right, with 30d selected. Below them the Machine Health Summary card shows a Health Score Trend chart with a score of 62 in its corner and a line sloping down over the month, a row of seven Operations Metrics gauges, and an events list in a narrow column on the right](/images/monitoring/mon-health-01.webp) *The machine health dashboard. Read the trend before the number.* ## The health score and its trend The *health score* is a number from 0 to 100 that summarizes the machine's vibration against its baseline. It is a proprietary IoTFlows calculation derived from the vibration metrics shown lower on the same page, RMS and crest factor among them. IoTFlows does not publish the weights. The **Health Score Trend** chart at the top of the **Machine Health Summary** card draws the score across the selected range, with the latest value in its corner. Widen the range to see whether a move is a day's noise or a month's slope. **Read the trend before the number.** A score of 62 that has been 62 for a month is a machine with a noisy baseline. A score of 78 that was 94 last week is the one to open a work order on. ![The Health Score Trend chart over 30 days. The line holds near 94 for the first two weeks, then bends downward and ends at 62, with the current value 62% shown large in the chart's corner. An arrow marks the point where the line starts to fall](/images/monitoring/mon-health-02.webp) *A score of 62 that was 94 four weeks ago. This is the shape that justifies a work order.* ## Bearing health and the operations metrics *Bearing health* is a score for the rolling elements of the machine, derived from the high-frequency part of the vibration signal where bearing defects show first. It is one of seven **Operations Metrics** gauges under the health score trend. Each gauge fills one to four bars and carries one of five labels: **Good**, **Satisfactory**, **Unsatisfactory**, **Unacceptable** or **No Data**. | Gauge | What it scores | |---|---| | **Cavitation Risk** | Vapor bubbles collapsing in a pump or hydraulic system | | **Structural Looseness** | A mount, foot or fastener that has worked loose | | **Imbalance** | A rotating part whose mass is off center | | **Lubrication** | Bearing lubrication breaking down | | **Alignment** | Shafts or couplings that are out of line | | **Bearing Health** | Wear or damage in the bearings | | **Temperature** | The sensor's temperature reading, when the device reports one | Each gauge except Temperature has its own trend chart below the summary card, so you can see when a condition began. Watch the bearing gauge first: bearing damage is the fault a vibration sensor catches earliest, and the one with the longest lead time before failure. ![The Operations Metrics row of the Machine Health Summary card. Seven gauges read Cavitation Risk, Structural Looseness, Imbalance, Lubrication, Alignment, Bearing Health and Temperature, each with four bars and a label. Bearing Health shows two yellow bars and the label Unsatisfactory, highlighted with a violet box, while the others show three or four green bars and read Good or Satisfactory](/images/monitoring/mon-health-03.webp) *The Bearing Health gauge at Unsatisfactory, and its trend chart below the summary card.* ## Read the three axes A SenseAi reads vibration on three axes, **X**, **Y** and **Z**, and combines them into **XYZ**. Every metric trend chart draws all four as separate lines, and the FFT section draws a spectrum for each. Compare the axes when a metric rises. All three moving together is wear or load. One axis moving alone points at a directional fault, most often alignment or looseness: a shaft out of line pushes in one direction, and a loose foot rocks in one plane. ![The RMS Velocity trend chart with four lines labeled X, Y, Z and XYZ over seven days. The X and Z lines run flat near the bottom while the Y line climbs steadily through the week to more than twice their level. An arrow marks the Y line](/images/monitoring/mon-health-04.webp) *Three axes on one trend chart. One axis moving on its own points at alignment rather than wear.* ## The FFT spectrum An *FFT* (fast Fourier transform) splits a vibration signal into the frequencies it contains, so a chart of amplitude against frequency shows which rotations and impacts are producing the vibration. The dashboard draws four: **XYZ FFT Spectrum**, **X FFT Spectrum**, **Y FFT Spectrum** and **Z FFT Spectrum**, frequency in Hz across the bottom and amplitude in g up the side. A spectrum is one moment, not a trend. Until you pick a moment the chart reads **Select a point from trend charts**. Click a point on any trend chart, or on the spectrogram, and all four spectra load the reading nearest that timestamp, see [Inspect one moment across every chart](#inspector). **You do not need the FFT to act.** The score, the trend and the bearing gauge cover most decisions. The spectrum is for confirming *which* fault, not *whether*. ![The XYZ FFT Spectrum chart, titled with an RPM figure and a timestamp, with frequency in Hz along the bottom and amplitude in g up the side. Two tall peaks rise from a low floor. Numbered callouts 1 and 2 mark the first peak at the running speed and the second at twice that frequency](/images/monitoring/mon-health-05.webp) *The FFT spectrum with the running speed and its second harmonic marked.* ## Harmonics and RPM A *harmonic* is a whole-number multiple of the machine's running speed. If a shaft turns at 1,800 RPM, that is 30 Hz, and the harmonics sit at 60, 90, 120 Hz and so on, labeled **1X** through **6X**. IoTFlows derives the RPM from the vibration itself and shows it in the spectrum's title, for example **FFT Spectrum 2D @ 1785 RPM**. Harmonic markers are drawn as dashed lines and listed with their frequencies under the chart. They are on by default; click **Hide Harmonics** to see the bare spectrum. Where the energy sits against the markers names the fault. A peak on 1X is imbalance. A peak on 2X is misalignment. Energy across several harmonics is looseness, and a cluster well above 6X, unrelated to running speed, is a bearing. ![A cropped detail of an FFT spectrum. Dashed amber vertical lines labeled 1X, 2X, 3X and 4X stand at even spacing across the chart, an amber Hide Harmonics button sits above it at the right, and a legend under the chart lists each harmonic with its frequency in Hz](/images/monitoring/mon-health-06.webp) *Harmonic markers placed from the machine's RPM.* ## The spectrogram and the 3D view The **FFT Spectrogram 2D (Frequency vs Time)** chart shows every moment in the range at once: time along the bottom, frequency up the side, amplitude as color. A band that brightens toward the right is a fault growing. A band bright all the way across is the machine's normal signature. Click anywhere on the spectrogram to select that timestamp. A vertical line marks it and the four spectra load that moment. ![The FFT Spectrogram 2D chart over two weeks, with time along the bottom, frequency in Hz up the side and amplitude drawn as color. Most of the chart is dark. One horizontal band in the upper half starts faint at the left and grows brighter toward the right edge. An arrow marks that band](/images/monitoring/mon-health-07.webp) *The spectrogram over two weeks. A band brightening over time is degradation.* **FFT 3D Frequency Bands** below it plots the same data as ridges running through time. It reads well on a slide and less well at a desk: the spectrogram is easier to point at, and it is the one you can click. ![The FFT 3D Frequency Bands chart for the same two weeks, drawn as colored ridges in a three-dimensional box with time on one axis, frequency in Hz on another and amplitude in g as height. One ridge rises steadily from the back of the box to the front](/images/monitoring/mon-health-08.webp) *The 3D view of the same data, for presentations rather than diagnosis.* ## The 14 metric trend charts The **Time-Domain Metrics** section at the bottom draws one chart per vibration metric, fourteen in all, each with X, Y, Z and XYZ lines. Two come up often enough to define here. *Crest factor* is the signal's peak divided by its RMS. Impacts raise the peak without raising the RMS much, so the ratio climbs. *Kurtosis* measures how peaked the signal's distribution is. Random vibration sits near 3; a bearing defect adds spikes that push it higher. Click the **i** icon on any chart for its definition and the faults it points at. Those panels are the source for the table below. ### Health metrics | Metric | What it measures | Rises when | |---|---|---| | **RMS Velocity** | Overall vibration energy, the effective amplitude of the signal | Unbalance, misalignment, looseness, general wear | | **Peak Acceleration** | The largest instantaneous amplitude in the window | Bearing defects, gear tooth damage, cavitation, impacts | | **Crest Factor** | Peak divided by RMS | Bearing spalling, gear tooth cracks, looseness impacts, motor electrical faults | | **Peak-to-Peak** | The full swing from most positive to most negative | High unbalance, bearing clearance, impact loads, structural looseness | | **Kurtosis** | How peaked the amplitude distribution is; about 3 for random vibration | Early bearing damage, impacting looseness, intermittent contact, rubbing | | **Envelope Kurtosis** | Kurtosis of the high-frequency envelope, the most sensitive bearing indicator | Race spalling, ball or roller defects, cage damage, lubrication breakdown | | **Dominant Spectral Energy** | Amplitude of the strongest frequency in the spectrum | Depends on which frequency dominates: 1X is unbalance, 2X misalignment, high frequency bearings | | **Zero Crossing Rate** | How often the signal crosses zero, a rough measure of dominant frequency | Bearing modulation, variable speed, resonance, beat frequencies | | **Mean** | The average of the signal, near zero for a healthy mount | Sensor mounting angle, temperature drift, low-frequency movement, calibration drift | | **Standard Deviation** | Spread of the amplitude, close to RMS for a vibration signal | Variable process load, intermittent bearing impacts, loose components, resonance | | **Variance** | Standard deviation squared, the signal's power | Load fluctuation, a developing fault, unstable operation, resonance | | **Energy** | Sum of squared amplitudes over the window | Wear progressing, growing unbalance, bearing degradation, alignment drifting | | **Skewness** | Asymmetry of the amplitude distribution, near zero when healthy | One-directional impacts, bearing cage defects, gear tooth damage, structural asymmetry | | **Mean Absolute** | Average of absolute amplitude, like RMS but less swayed by peaks | The same causes as RMS: unbalance, misalignment, bearing wear, looseness | ![The Time-Domain Metrics section: a two-column grid of fourteen trend charts titled RMS Velocity, Peak Acceleration, Crest Factor, Peak-to-Peak, Kurtosis, Envelope Kurtosis, Dominant Spectral Energy, Zero Crossing Rate, Mean, Standard Deviation, Variance, Energy, Skewness and Mean Absolute. Each chart carries a one-line description under its title, an i icon and an expand icon at the right, and four colored lines for X, Y, Z and XYZ](/images/monitoring/mon-health-09.webp) *The 14 metric trend charts. The reference table on this page says what each one rises with.* ## Inspect one moment across every chart Every trend chart shares one selected timestamp. Click a point on any of them, or on the spectrogram, and the dashboard lines up on that moment: - A vertical marker appears on every trend chart at the same time. - The four FFT spectra load the reading nearest that timestamp and show it in their title. - The **Operations Metrics** gauges switch to their values at that moment, with the timestamp shown in a blue chip beside the heading, and each metric chart shows an **@selected** chip. - A panel opens listing any notes or events already recorded at that moment, with an **Add Note** button to record one, and **Clear Selection** to return every chart to the latest reading. Use it to answer "what did the spectrum look like when the score dropped": click the inflection point on the health score trend and read the spectra. Notes added here appear in the machine's **Notes** list, see [Inspect a single machine](/docs/monitoring/asset-detail/#notes), and clicking a note there selects its moment on these charts. ![Three metric trend charts stacked, each with a vertical marker line at the same position and an @selected chip in its header. A floating panel at the lower right shows the selected date and time, an Add Note button and a Clear Selection button. An arrow runs down through the three aligned markers](/images/monitoring/mon-health-10.webp) *The timestamp inspector lines every chart up on one moment.* ## Legacy health (firmware below 5) A SenseAi on firmware below 5 keeps the **Health** tab but shows the older view: tiles reading **Vibration Mean (g)**, **Vibration Std Dev (g)** and **Vibration RMS (g)**, a **Vibration (g)** chart of the last 256 raw samples, a **Vibration Spectrogram**, and trend charts of mean, standard deviation and RMS with a shaded band for the expected range. It has no score, no gauges, no FFT spectra and no inspector. A mean or RMS line that has left its band and stayed out is still a machine that has changed. For the full dashboard, ask IoTFlows to update the firmware, see [Get support](/docs/get-started/get-support/). ## What to do with a falling score 1. Widen the time range to **30d** or **90d** and confirm the fall is a slope, not a step that has since recovered. 2. Read the **Operations Metrics** gauges. The one that has left **Good** names the condition. 3. Open that gauge's trend chart and find when it began. 4. Click that moment and read the FFT spectra with harmonics on, to confirm which fault: 1X, 2X, many harmonics, or high-frequency energy. 5. Open a work order from the event the sensor raised, see [Review and dismiss machine events](/docs/monitoring/asset-events/), or create one directly, see [Create a work order](/docs/maintain/create-a-work-order/). To be told rather than to look, set a health or vibration rule for the asset in [Asset event rules](/docs/alerts/asset-event-rules/). ## Errors | Symptom | Cause | Do this | |---|---|---| | No **Health** tab on the machine's page | The asset carries a BeamTracker | None. A beam sensor reads no vibration | | The tab shows mean, standard deviation and RMS tiles instead of a score | Firmware below 5 | Ask IoTFlows to update the device, see [Get support](/docs/get-started/get-support/) | | Charts read **No frequency band data available. Waiting for sensor data...** or gauges read **No Data** | The sensor has not yet collected enough samples for a baseline, or the device is offline | Check the device in [View your devices](/docs/hardware/view-devices/), then wait for the baseline to fill | | **Failed to update baseline profile** | The profile change did not save | Retry. If it repeats, see [Choose a machine health baseline profile](/docs/monitoring/baseline-profiles/) | ## See also - [Choose a machine health baseline profile](/docs/monitoring/baseline-profiles/) - [Review and dismiss machine events](/docs/monitoring/asset-events/) - [Asset event rules](/docs/alerts/asset-event-rules/) - [Create a work order](/docs/maintain/create-a-work-order/) - [Inspect a single machine](/docs/monitoring/asset-detail/) --- # How each metric is calculated Source: https://www.iotflows.com/docs/monitoring/metrics-reference/ The definition behind every number IoTFlows shows and what each one leaves out. Uptime is availability, running time over running plus stopped, and is the number the interface has labeled OEE. Unknown time and None-severity breaks sit outside both uptime and downtime. The parts gauge measures output against the ideal cycle time, FPY compares a step's count to the first step's in a cascade, and every window is calculated whole rather than averaged per shift. Quality comes from the scrap your team logs against a job, and there is no combined OEE figure. # How each metric is calculated The definition behind every number on every screen, and what each one leaves out. Every metric comes from two streams: the running and stopped states a sensor reports, and the detection events that count parts. This page defines each number once, and every other page links here. **The number the interface labels OEE is availability, not OEE.** IoTFlows is renaming that label to Uptime, and this page uses Uptime throughout. ## Uptime *Uptime* is availability: the share of the window a machine spent running. ``` uptime = running time ÷ (running time + stopped time) ``` The sensor decides running and stopped, the same state that colors the shift status bar. For example, a machine that ran 6 h 30 min of a 9 h shift and was stopped 2 h 30 min reads 72% uptime. Time the sensor did not report is left out of both terms, see [Unknown time](#unknown). The same percentage carries two labels: **Uptime** on a machine card and machine page, **Utilization** on the Assets KPI row and the Advanced Report. The **Uptime** KPI tile on the Assets page is different: that one is total running hours, as `71:15h`. See [Read the fleet KPIs](/docs/monitoring/assets-overview/#kpis). Diagram: A diagram in three columns under the heading Textbook OEE: Availability times Performance times Quality. Under Availability, a box reads Uptime, running divided by running plus stopped, with the input labeled: running and stopped states from the sensor. Under Performance, a box reads Parts gauge, parts made divided by parts possible at the ideal cycle time, with the input labeled: detection events, and the ideal cycle time in the Parts List. Under Quality, a box reads Quality, good parts divided by everything counted, with the input labeled: good parts and scrap your team logs against a job. A note across the bottom reads: nothing multiplies these together. There is no combined OEE figure; read each number on its own. *The three factors of textbook OEE and the number IoTFlows shows for each: uptime and the parts gauge from the sensor, quality from the good parts and scrap your team logs. Nothing multiplies them together.* **There is no combined OEE figure in the product.** IoTFlows shows availability as uptime and performance as the parts gauge, both from the sensor, and quality on [Shift Production](/docs/production/shift-production/) as good parts over everything counted, from the scrap your team logs against a job (see [Log scrap](/docs/production/log-scrap/)). Each reads on its own. Comparing an IoTFlows uptime of 85% to an OEE of 60% from another system is comparing one factor to a product of three. ## Downtime *Downtime* is the time the sensor reported the machine stopped. Every minute is running or stopped unless the sensor was silent. Downtime is the same total with or without a reason on it. A *classified* stop carries a downtime category, an *unclassified* stop does not, and both count in full. Classification changes what the [Downtimes report](/docs/monitoring/downtimes/) can say about the time, not how much there is, see [Classify a downtime event](/docs/monitoring/classify-downtime/). A stop's red or orange on the status bar is a duration threshold and has no effect on the number, see [Set status colors and downtime thresholds](/docs/monitoring/status-colors/). ## Unknown time *Unknown time* is any interval where the sensor was powered off or had lost its connection. It is absence of data, not a machine state, and it counts toward **neither** uptime nor downtime. For example, a SenseAi unplugged over a weekend produces 48 unknown hours, not 48 hours of downtime. On the shift status bar the stretch is gray, and the card keeps the last state the cloud recorded, so an offline machine can still read stopped. Gray on the bar is what separates a dead link from a stopped machine, see [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). On the Advanced Report, turn on **Exclude Unknown** when you want to be certain the report's **Total Utilization** follows this definition, see [Choose what the number includes](/docs/monitoring/advanced-report/#switches). ## The None severity *None* is a downtime severity for categories whose stops are nobody's loss. Its purpose is legally required breaks: a mandated one-hour lunch is a stop on the sensor, but it should not count against the plant. A None-severity stop is downtime by default. With **Exclude None** on, it leaves both uptime and downtime, the same way unknown time does. For example, a department that takes the mandated hour reads 82% uptime with the switch off and 93% with it on, because the hour leaves the denominator too. Which categories carry None is set in [Set severity](/docs/monitoring/downtime-categories/#severity). Diagram: A horizontal bar representing one shift from 8am to 5pm, divided into segments. Most of the bar is running. A short classified stop labeled Tool change sits around 9:30, a short unclassified stop around 10:30, a one-hour break labeled Lunch, severity None, from 12 to 1, and a stretch labeled Sensor offline, Unknown, from about 2:20 to 3. A key beneath assigns each kind of segment to a bucket: running counts as uptime; a classified stop and an unclassified stop both count as downtime; the None break counts as downtime, or as neither with Exclude None on; sensor offline counts as neither. A note reads: uptime percentage is running divided by running plus stopped. Minutes in neither bucket are why the percentages do not add up to the length of the shift. *How a shift's clock divides: uptime, classified downtime, unclassified downtime, a None break and unknown time. This is the figure behind most questions of the form why does this not add up.* ### What is excluded from uptime and downtime | Excluded | When | Toggle | Why | |---|---|---|---| | Unknown time | Always | **Exclude Unknown** on the Advanced Report makes it explicit | The sensor reported nothing, so there is no state to count | | Stops with severity None | Only when the toggle is on | **Exclude None** on the Advanced Report | A mandated break is a stop no one is accountable for | Leave Unknown and None in when you are asking where the shift went, because a number without them no longer adds up to the shift. Exclude them when you are comparing machines or holding someone to a number. ## Performance *Performance* is the parts gauge: actual output against what the machine could have produced at its ideal cycle time in the same running time. ``` performance = parts made ÷ (running time ÷ ideal cycle time) ``` The *ideal cycle time* is entered per operation in the Parts List, see [Set cycle times and filters](/docs/production/cycle-times-and-filters/). The gauge is green when the percentage meets the machine's goal and red when it does not, see [Set uptime goals](/docs/monitoring/oee-goals/). Watch uptime to find machines that are stopped, and the parts gauge to find machines that are running slowly. A machine can sit at 95% uptime and still miss its goal, because uptime does not know how fast the machine was going. For example, a press running all shift at 40 strokes a minute against an ideal of 60 shows a green uptime ring and a red parts gauge. You do not need the parts gauge to tell whether a machine is stopped. It earns its place once an operation with an ideal cycle time is assigned to the machine. ## FPY *FPY*, first pass yield, compares a step's good count with the good count of Step 1, the first step of its cascading group. ``` fpy = this step's good count ÷ Step 1's good count, capped at 100% ``` Where a step produced less than Step 1, the difference is the loss from the first step through to this one, so the figure is cumulative down the line. For example, if Step 1 (OP10) made 1,200 parts and Step 2 (OP20) made 1,080, Step 2 reads 90% FPY and a loss of 120. It is a multi-operation measure, which is why it appears only on cascading group cards, see [Group machines into cascades](/docs/monitoring/asset-groups/). It reads green from 95% and amber from 80%. A group can instead measure each step against its own cycle-time baseline, with no reference step. The group page says when to use which. ## Cycle time Three cycle-time figures appear in the product, from three places. | Figure | Comes from | Appears as | |---|---|---| | *Actual cycle time* | Detection events: running time between counted parts | **Cycle time** on cards and machine pages, and its inverse **Production rate** | | *Ideal cycle time* | Entered per operation in the Parts List | The basis of the parts gauge and the hourly goal | | Target | The machine's goal, see [Set uptime goals](/docs/monitoring/oee-goals/) | The color threshold on the cycle-time figure | A red cycle time means the machine is producing more slowly than its goal allows, not that it is stopped. For example, a machining center with a 90 s ideal cycle that is turning parts every 2 min reads a red **Cycle time** and a green **Uptime**, and both are correct. ## Production metrics *Hourly production* is parts counted per clock hour, drawn as bars on the machine card against a per-hour goal derived from the ideal cycle time and the machine's goal, see [Set cycle times and filters](/docs/production/cycle-times-and-filters/). *Machines producing* on the Assets page KPI row counts machines whose sensor reports running at this moment, out of the filtered fleet. It is the one KPI on the row with no window. Any selected window, including one spanning several shifts, is calculated **across the whole window**, not as an average of per-shift figures. For example, a machine at 90% on a long day shift and 50% on a short night shift reads 80% for the two together, because the day shift contributed more minutes. Which minutes fall in the window is itself a question for a shift that crosses midnight. On a report, such a shift is divided at midnight and its later hours are counted on the next day, unless **Shift islands** is on. The live views never divide it. So the same night shift has two defensible denominators, see [Where the overnight hours land](/docs/admin/shifts-and-timezone/#overnight-hours). ## Where each metric appears | Metric | What it measures | Basis | Excludes | Appears on | |---|---|---|---|---| | Uptime (%) | Availability, running ÷ (running + stopped) | Sensor states | Unknown always, None with the toggle | Cards and machine pages as **Uptime**; Assets KPI row and Advanced Report as **Utilization** | | Uptime (hours) | Total running time | Sensor states | Unknown | Assets KPI row, Advanced Report **Uptime Hours** | | Downtime | Total stopped time | Sensor states | Unknown, None with the toggle | Assets KPI row, cards, Downtimes report, Advanced Report | | Unknown | Time with no sensor data | Gaps in the stream | Neither uptime nor downtime | Advanced Report **Unknown Hours**, gray on status bars | | Performance | Output against the ideal cycle time | Detection events, Parts List | Machines with no operation | Parts gauge on cards and Shift Production | | FPY | This step's count against Step 1's | Good counts in a cascade | Groups in cycle-time baseline mode | Cascading group cards | | Actual cycle time | Running time per counted part | Detection events | Stopped time | Cards and machine pages | | Hourly production | Parts per clock hour against the ideal | Detection events, Parts List | Nothing | Cards, Shift Production | | Machines producing | Machines running right now | Live sensor state | Nothing, no window | Assets KPI row | ## See also - [Troubleshoot wrong utilization or OEE](/docs/monitoring/troubleshoot-monitoring/) - [Build a utilization report](/docs/monitoring/advanced-report/) - [Set cycle times and filters](/docs/production/cycle-times-and-filters/) - [Group machines into cascades](/docs/monitoring/asset-groups/) - [Set uptime goals](/docs/monitoring/oee-goals/) --- # Set OEE and utilization goals Source: https://www.iotflows.com/docs/monitoring/oee-goals/ One percentage colors every gauge in IoTFlows. Set the organization goal from the Utilization tile on the Assets page, override it on the machines whose realistic ceiling genuinely differs by turning on Set Custom Utilization / OEE Goal in a machine's Uptime gauge, and read the table of which surface uses which goal. The coloring is binary, green at or above and red below, with no orange; the same percentage also colors the parts and cycle gauges; and the comparison is computed across the whole window you are viewing rather than averaged per shift. Owner or Administrator. # Set OEE and utilization goals Set the percentage that every uptime and production gauge in IoTFlows is colored against. An *OEE goal* is a single target percentage. At or above it a gauge draws green, below it the gauge draws red. Your organization has one goal, and every machine inherits it until you give that machine a goal of its own. The metric being judged is *uptime*, availability: running time over running plus stopped time. See [Uptime](/docs/monitoring/metrics-reference/#uptime). **Before you start** - Sign in as an Organization Owner or Organization Administrator. See [Roles reference](/docs/admin/roles-reference/). - Have machines reporting for at least a few weeks. A goal set before you have a baseline is a guess. See [Add a machine](/docs/monitoring/add-an-asset/). ## Set the organization goal The organization goal is the default every machine inherits, and it is the only goal the fleet **Utilization** tile uses. 1. Open the Assets page at `/assets`. 2. In the row of tiles across the top of the page, select the target icon in the top right corner of the **Utilization** tile, tooltipped **Adjust OEE Goal**. Selecting the percentage itself opens the same dialog. 3. In **Set OEE Goal**, type your target under **Set Organization Utilization / OEE Goal**. Enter a whole percentage, for example `62`, not `0.62`. 4. Select **Set**. IoTFlows confirms with "Organization OEE Goal Updated" and recolors the page. The goal belongs to the organization, so every member sees the new number on their next load. ![The Set OEE Goal dialog, headed Set Organization Utilization / OEE Goal, with a large percentage field reading 62 next to a percent sign, and Cancel and Set buttons along the bottom](/images/monitoring/mon-goal-01.webp) *The Set OEE Goal dialog, reached from the Utilization tile on the Assets page. Set the organization number from your own baseline, not from an industry figure.* ## Set a goal for one machine **You do not need a per-machine goal for every asset.** Set one only where a machine's realistic ceiling genuinely differs from the plant's: - A machine that runs two hours a day by design, such as a sample press or a deburring cell. - A machine whose work is set-up heavy, where cutting time is a small share of the shift. - A machine that waits on an upstream cell and can never run more than that cell allows. Everywhere else, leave the organization goal in place. A fleet where every machine carries its own goal stops being comparable, because a green gauge no longer means the same thing on two cards. 1. Open the machine at `/assets/selected-asset/:id`. See [Inspect a single machine](/docs/monitoring/asset-detail/#open). 2. Select the **Uptime** gauge in the header. On a phone the gauge carries the hint "Tap to set Uptime goal". 3. Turn on **Set Custom Utilization / OEE Goal**. **Custom Goal for Machine** on the right becomes editable and **Default Organization Goal** on the left dims. 4. Type the percentage for this machine. 5. Select **Set**. IoTFlows confirms with "Asset OEE Goal Updated". This machine's gauges recolor immediately and no other machine changes. To put the machine back on the plant's number, open the same dialog, turn **Set Custom Utilization / OEE Goal** off, and select **Set**. The custom goal is cleared rather than remembered, so switching back later means typing it again. > **Note:** > **Why is the left-hand field editable?** **Default Organization Goal** is the organization's number, shown beside the custom one so you can see what this machine is departing from. Set the organization goal from the **Utilization** tile on the Assets page instead, where the dialog names what you are changing and the fleet figure is on screen next to it. ![The Set OEE Goal dialog opened from a machine, with the Set Custom Utilization / OEE Goal switch on. Two percentage fields sit side by side: Default Organization Goal reading 62 and dimmed on the left, Custom Goal for Machine reading 45 and active on the right](/images/monitoring/mon-goal-02.webp) *The same dialog opened from a machine's Uptime gauge, with Set Custom Utilization / OEE Goal turned on: the organization's 62% on the left, this machine's 45% on the right.* ## Where the goal appears Every surface below colors a percentage against a goal. Only one of them uses the organization's. | Surface | Uses organization goal | Uses machine goal | |---|---|---| | **Utilization** tile at the top of the Assets page | Yes | No | | **Uptime** gauge on a machine card, in every card view | No | Yes | | **Utilization** column in list view | No | Yes | | Parts and cycle-time gauges on a machine card | No | Yes | | **Uptime** gauge in a machine page header | No | Yes | | Header gauge in Operator View | No | Yes | | Progress and cycle gauges on Shift Production | No | Yes | | Machine cards and rows on a phone | No | Yes | "Machine goal" means the machine's own goal where you have set one, and the organization goal everywhere else. In a plant that has never set a per-machine goal, every row in that table resolves to the same number. **The coloring is binary.** At or above the goal a gauge is green; below it, red. There is no orange. Orange on the Assets page is a downtime threshold, a duration rather than a percentage, and it is unrelated to the goal. See [Set status colors and downtime thresholds](/docs/monitoring/status-colors/). **The goal also colors production, not just uptime.** The parts gauge compares parts made against what the ideal cycle time implies for the period you are viewing, then colors that percentage against the same OEE goal. Raising the organization goal from 60% to 80% turns some parts gauges red without anything changing on the floor. The ideal cycle time behind that comparison is set per operation. See [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/). ![Two machine cards side by side. The left card, Doosan 2600, has an Uptime gauge reading 13% in red with the goal marker well above the filled arc; the right card, Epoxy granite VMC, has an Uptime gauge reading 98% in green with the goal marker below the filled arc](/images/monitoring/mon-goal-03.webp) *Two machine cards side by side: the Uptime gauge is green on the machine at or above its goal and red on the machine below it.* ## The goal and the window you are viewing A *window* is the period selected at the top of the page: a shift, a day, or a custom range. Every surface in the table reports the window you have selected. The goal itself is one percentage and does not move with it; what moves is the figure it is compared against. **That figure is computed across the whole window, not averaged per shift.** A machine that ran 90% on first shift and 30% on second, both shifts the same length, reads 60% for the day. It does not report that one shift met the goal and one missed it. A custom range covering three shifts totals running and stopped time across all three and divides once. So a goal that looks like it is being applied to the wrong period is a window problem, not a goal problem. Check the shift and date selectors before you change the number, see [Choose the window](/docs/monitoring/assets-overview/#window). ## Choose a number **Set the first goal from your own baseline, not from an industry number.** A plant reading 48% that sets a goal of 85% has told every operator the board is fiction, and a board nobody believes is a board nobody reads. 1. Open the Advanced Report over the last complete quarter. See [Build a utilization report](/docs/monitoring/advanced-report/). 2. Read the organization's utilization for that period. That figure is your baseline. 3. Set the goal a few points above it. A plant at 48% sets 55%, not 85%. 4. Leave it alone for a quarter, then move it when the plant moves. Per-machine goals follow the same rule against that machine's own history rather than the plant's. The Advanced Report breaks the period down by machine, so read that machine's row and set its goal from there. ## When a change does not save A failed save shows the message the server returned, or the generic "Something went wrong" toast, and the dialog stays open with your number still in it. Nothing was written. Reopen the dialog and read the goal back before assuming the change took. See [Troubleshoot wrong utilization or OEE](/docs/monitoring/troubleshoot-monitoring/). ## See also - [Track production against shift goals](/docs/production/shift-production/) - [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/) - [How each metric is calculated](/docs/monitoring/metrics-reference/#uptime) - [Build a utilization report](/docs/monitoring/advanced-report/) - [Set status colors and downtime thresholds](/docs/monitoring/status-colors/) --- # Measure operator work sessions Source: https://www.iotflows.com/docs/monitoring/operator-performance/ The Operator Performance report at /assets?select=operator_performance pairs each operator with the machine they worked and totals the machine's uptime percentage, uptime hours and downtime hours for their clocked sessions. Sessions come from sign-ins on a paired operator station, so the report's real job is finding sessions that were never closed. Filter by machine, operator and a window of up to 31 days, read each card as stacked hours per session or as a status strip, add or correct clock entries by hand, and export the whole report as CSV. Owner or Administrator, web only. # Measure operator work sessions Per-operator uptime and hours, and where the numbers come from. The Operator Performance report pairs every operator with a machine they worked and totals what that machine did while they were clocked in. A *work session* is one stretch between an operator's *clock-in* and their clock-out on one machine. The report is at `/assets?select=operator_performance`. **Prerequisites.** Owner or Administrator, see [Roles reference](/docs/admin/roles-reference/). Web only: the tab is absent from the Assets page in the mobile app. A device paired to a machine as an operator station, see [Set up a dedicated operator station](/docs/monitoring/operator-stations/), because that pairing is what turns a sign-in into a clock-in. ## Open the report 1. Go to **Assets**. 2. Click the **Operator Performance** tab. The address bar reads `/assets?select=operator_performance`, followed by the `from` and `to` timestamps of the window. Every filter lives in the URL, so a report you want a supervisor to see is a link you can paste. One card appears for each operator and machine pairing with a session in the window. An operator who worked three machines gets three cards, and each card counts only their sessions on that machine. ![The Operator Performance tab of the Assets page. A toolbar holds dashed Machines and Operators filter pills at the left, and a Bar Chart switch, a CSV button, a date range button and a blue Add Clock In/Out button at the right. Below it, four cards each show an operator avatar overlapping a machine photo, the operator's name, the machine name and identifier, then three figures: a percentage, uptime hours in blue and downtime hours in red, with a horizontal stacked bar chart underneath and a clock button at the card's top right.](/images/monitoring/mon-opperf-01.webp) *The operator performance report, populated. Do not reuse the existing empty-state image.* **You do not need this report if nobody signs in at a machine.** Sessions come from station sign-ins and from the entries you add by hand here. With neither, the report stays empty and there is nothing to measure. ## Filters and the period Three controls sit above the cards, and all three write to the URL. **Machines** narrows the report to whole departments or named machines, applied with **Apply**. **Operators** narrows it to named people, searching by name, username or email, applied with **Run**. The date button at the right sets the window. It opens on the last three days: midnight three days ago to 11:59 PM yesterday. Set any range up to 31 days, with a start time and an end time for the first and last day. A longer range is refused with "Date range cannot exceed 31 days. Please select a shorter range.", and **Apply** stays disabled until you shorten it. There are no rolling presets here, so every visit starts from that three-day window. ## The bar chart Each card leads with three figures for the operator's whole time on that machine. **Uptime** is the share of their sessions the machine spent running, and *uptime* is availability, see [Uptime](/docs/monitoring/metrics-reference/#uptime). **Uptime Hours** and **Downtime Hours** are the hours behind it. With the **Bar Chart** switch on, each card draws one horizontal bar per session, stacked into uptime in blue, downtime in red and unknown time in gray, labeled in hours. *Unknown* time is any stretch the sensor reported nothing, and it counts toward neither figure. ![One operator card with the Bar Chart switch on, showing a horizontal stacked bar for each work session. Each bar carries a blue uptime segment and a red downtime segment labeled in hours, against a session label on the left axis.](/images/monitoring/mon-opperf-02.webp) *Bar chart view. One bar per session, stacked into uptime, downtime and unknown hours.* ## The timeline view Turning **Bar Chart** off replaces the bars with a status strip laid across the window, on an axis labeled by date and hour. Use it to see when in the window the operator's sessions sat, rather than how long they added up to. The switch is available only for a window of three days or shorter. Above that it is grayed out and locked on, which is why a monthly report only ever shows bars. The default window is inside that limit by a minute. ![One operator card with the Bar Chart switch off, showing a rounded horizontal status strip in place of the bars, over a time axis labeled with dates and hours such as Sep 17, 06:00 AM.](/images/monitoring/mon-opperf-03.webp) *The timeline view. The strip shows where in the window the operator's sessions sat, on an axis labeled by date and hour.* The strip does not tell you whether a session closed. The clock timeline in [Edit or delete an entry](#entry-edit) does. ## What each column means A *clocked item* is one work session with its own totals. Each bar on a card is a clocked item, and so is each row of the CSV. | Column | Definition | Source | |---|---|---| | **Uptime** | Share of the operator's sessions on this machine that the machine spent running | The sensor's running and stopped states | | **Uptime Hours** | Hours the machine ran during those sessions | The sensor | | **Downtime Hours** | Hours the machine was stopped during those sessions | The sensor | | Unknown hours | Hours the sensor reported nothing during a session. Drawn as the gray band on a bar, never as a card figure | Gaps in sensor reporting, see [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/) | | Clocked category | The label the report gives one session. It names the bar on the chart and fills the `Clocked Category` column in the CSV | The report endpoint | | Clock start, clock end | The two clock events that bound the session. The end is empty when the session was never closed | Station sign-in and sign-out, or a manual entry | Every timestamp is in the organization's time zone, not the browser's, see [Shifts and time zone](/docs/admin/shifts-and-timezone/). ## Add a manual clock-in Use this when an operator worked but no session exists: they signed in on their own laptop, or the tablet was down. 1. Click **Add Clock In/Out** at the right of the toolbar. 2. On **Select Operator**, search and click the person. 3. On **Select Assets**, search by machine name or identifier and click the machine. 4. Choose **Clock In**, **Clock Out** or **Clock In & Out**. 5. Set the date and time for each action you chose. 6. Click **Add Time**. The report reloads and a toast reads "Time added". ![The Add Clock In/Out dialog on its third step. The chosen operator and machine sit in two blue chips at the top, above a three-way selector reading Clock In, Clock Out and Clock In & Out with Clock In & Out chosen, and below it a green Clock In heading with a date button and a time picker, then a red Clock Out heading with its own date button and time picker. An Add Time button sits at the top right.](/images/monitoring/mon-opperf-04.webp) *Adding a manual clock-in entry to correct a session.* ### Manual clock-in fields | Field | Required | Notes | |---|---|---| | Operator | Yes | Any organization member. People with a pending invite are not listed | | Asset | Yes | The machine the session belongs to. Search matches the custom name, the custom identifier or the catalog name | | Action | Yes | **Clock In**, **Clock Out** or **Clock In & Out**. Defaults to **Clock In** | | **Clock In** date and time | For **Clock In** and **Clock In & Out** | Defaults to 6:00 AM yesterday | | **Clock Out** date and time | For **Clock Out** and **Clock In & Out** | Defaults to 9:00 AM yesterday | **Why is the entry on the wrong day?** Both pickers default to yesterday, not today. Click straight through and you file a session for yesterday morning, on a machine that may already have one. **Clock In & Out** writes two separate events. If the clock-in saves and the clock-out fails, the session is left open, so check the timeline before you retry. ## Edit or delete an entry Every clock event can be moved, flipped or removed, whether a station wrote it or you did. 1. Click the clock button at a card's top right. The **Operator Clockin/Clockout** dialog lists that operator's clock events on that machine, oldest first. 2. Each event reads **Clocked In** or **Clocked Out** with its date and time. Between a clock-in and the clock-out that follows it, a pill gives the length, for example `8h 12m`. 3. Hover an event to reveal its pencil and trash icons. 4. Click the pencil to change the date and time, then click **Edit Time**. A toast reads "Time entry updated". 5. Click the trash, confirm the event named in the dialog, and click **Delete**. A toast reads "Time entry deleted". In the edit dialog, clicking the green **Clocked In** or red **Clocked Out** label flips the event to the other kind. Use that when a sign-out was recorded as a sign-in, which otherwise leaves two clock-ins in a row and no session between them. An event with no duration pill after it is a session nobody closed. Add the missing clock-out with the dialog's own **Add Clock In/Out** button, which arrives prefilled with this operator and machine. ## Edit a work session's times A *job work session* is the stretch an operator spent on one job. It is not a clock session, and it is corrected on the machine's page rather than here. Open the machine, find the work-session strip under its operations, and drag either end of a session bar, see [Inspect a single machine](/docs/monitoring/asset-detail/). To type the times instead, open **Job History** and edit the session in its **Work Sessions** list, where you can also delete one or add one with **New Session**, see [Start, pause, and complete a job](/docs/production/run-a-job/). Times are validated before they are sent. The edit is refused with "Session cannot start in the future", "Start time must be before end time", "Start and end time cannot be the same", "Session cannot end in the future", or "Overlaps with another session" naming the job it collides with. Editing a job session changes what the job is credited with, not the operator's clocked hours here. ## Export to CSV Click **CSV** in the toolbar. The file downloads as `operators_report__to_.csv`, for example `operators_report_Aug 20, 2026_to_Sep 19, 2026.csv`. The export writes one row per clocked item: the operator's username, first name, last name and email, the machine's name and identifier, the department, the clocked category, that session's uptime and downtime in hours and as percentages, and the clock start and end. A pairing with no sessions in the window still gets a row, with `N/A` in the three clock columns. What every export in the product carries is listed in [Available exports](/docs/monitoring/exports-reference/). The button is disabled while the report is empty. There is no PDF and no scheduled version of this report. ## Reading the report fairly Use this report to find sessions that were never closed, not to rank people. An operator who forgets to clock out looks like the best performer on the hours columns, which is exactly why the manual edit exists. Two more reasons the number is not a person's performance. The uptime percentage is the machine's, so an operator who spent a shift waiting on tooling carries that machine's downtime. And a session only exists if someone signed in at a paired station, so an operator working a machine without one looks like they did nothing. For why the machine was stopped, go to [Analyze downtime with Pareto and trend charts](/docs/monitoring/downtimes/). ## Errors | Message or symptom | Means | |---|---| | "You are not authorized to view this page." | Your role is neither Owner nor Administrator. The tab shows for everyone; the report does not | | "No operator report data available for selected date range." | No sessions matched. Widen the window, clear the **Operators** filter, or confirm a station is paired | | "Date range cannot exceed 31 days. Please select a shorter range." | **Apply** stays disabled until the range is 31 days or shorter | | The **Bar Chart** switch is grayed out | The window is longer than three days, so the timeline is unavailable | | "Something went wrong with clock in", "Something went wrong with clock out" | That clock event was not written. With **Clock In & Out**, the other event may already exist | | "Failed to download CSV. Please try again." | The file was not written. Nothing on the server changed | | A clock-in with no duration pill after it | The operator never clocked out. Add the clock-out by hand | ## See also - [Set up a dedicated operator station](/docs/monitoring/operator-stations/) - [Find your next job in the Work Queue](/docs/production/work-queue/) - [Start, pause, and complete a job](/docs/production/run-a-job/) - [Available exports](/docs/monitoring/exports-reference/) - [Roles reference](/docs/admin/roles-reference/) --- # Set up a dedicated operator station Source: https://www.iotflows.com/docs/monitoring/operator-stations/ Pair a shared tablet or PC to one machine from Assigned Asset in Organization Settings so it boots straight to /assets/operator-asset/:id after every sign-in, with a header that has no product navigation. The pairing lives in that browser's local storage, so it holds whoever signs in; each sign-in clocks the operator in on the machine. Leaving needs an Owner or Administrator, and unassigning is the same setting in reverse. # Set up a dedicated operator station Pair a shared tablet or PC to one machine so it boots straight into it. An *operator station* is a browser that IoTFlows has tied to one machine. Whoever signs in on it lands on that machine's page, with no way to browse to the rest of the fleet. It is the platform's *kiosk* mode: a device that stays at the machine and shows only it. You need an Owner or Administrator role to set one up, see [Roles reference](/docs/admin/roles-reference/). Do the setup on the device that will become the station, signed in. ## How an operator station differs An operator station is not [Operator View](/docs/monitoring/operator-view/), which is a display preference any user can turn on and off. A station is a pairing between a browser and a machine. | | Operator View | Operator station | |---|---|---| | Set from | The profile menu, on any machine page | **Assigned Asset** in Organization Settings | | Who can turn it on | Any signed-in user | Owner or Administrator | | Who can leave it | Any signed-in user | Owner or Administrator | | Where it lands after sign-in | The Assets page, as usual | The paired machine, every time | | Header | The standard header | A reduced header with no product navigation | | Clocks the operator in | No | Yes, on every sign-in and sign-out | **Choose an operator station when** the device is shared and stays at the machine. Because the pairing lives in that browser's local storage, signing in as a different person does not change which machine the station shows, and clearing site data unpairs it. **Choose Operator View when** a person works from their own account and moves between machines. A supervisor's laptop needs neither. ## Assign this device to a machine The assignment is stored in the browser's local storage, not on your account. It is per device and per browser: a tablet paired in Safari is not paired in Chrome. 1. On the device that will become the station, sign in as an Owner or Administrator. 2. Click the gear icon at the top right of the header. It opens Organization Settings at `/settings/organization`. 3. Scroll to **Assign to Local Device**. 4. Next to **Assigned Asset**, click **Assign Asset**. 5. In the **Asset-Device Assignment** dialog, search for the machine, for example `Haas VF-2`, and click it. ![The right end of the standard header showing the notifications bell, the gear icon and the user avatar, with the gear icon highlighted](/images/monitoring/mon-station-05.webp) *The gear icon at the top right of the header opens Organization Settings.* The machine's name and identifier appear next to **Assigned Asset**. Nothing else changes until the next sign-in or reload. ![The Assign to Local Device section of Organization Settings with the Asset-Device Assignment dialog open over it, showing a search box reading Search assets above a list of machines, with the asset picker highlighted](/images/monitoring/mon-station-01.webp) *Assigning this device to a machine. The pairing is stored in this browser, not on your account.* ## Confirm the station boots correctly 1. Sign out from the profile menu. 2. Sign in again, as the operator's account if it has one. The browser lands on `/assets/operator-asset/:id`, where `:id` is the machine you assigned, instead of on the Assets page. Every later sign-in and reload does the same. If it lands on the Assets page, see [Errors](#errors). Each sign-in on a station also clocks the operator in on that machine, and each sign-out clocks them out. That is where the work sessions on the machine's page come from, see [Operator performance](/docs/monitoring/operator-performance/). ![A freshly launched browser showing one machine's page at /assets/operator-asset with a reduced header, no sidebar, no breadcrumbs and no Assets back link](/images/monitoring/mon-station-02.webp) *A paired station boots straight to its machine.* ## What the operator sees The station shows the [machine page](/docs/monitoring/asset-detail/) with everything that leads away from it removed: no sidebar, no breadcrumbs, and no **Assets** back link. The operator can classify stops, correct counts, run jobs and leave notes as on the standard page, see [Classify a downtime event](/docs/monitoring/classify-downtime/). The header is reduced to the organization name, the dark mode switch, the feedback button, a **Sign out** button and the avatar. The avatar menu holds **Sign out**, and **Exit Operator View** for an Owner or Administrator. There is no product navigation, by design. ![The reduced station header: the organization name at the left, then a dark mode switch, a feedback button, a Sign out button and the user avatar at the right, with no product menu between them](/images/monitoring/mon-station-03.webp) *The station header. There is no product navigation, by design.* ## Unassign the device Unassigning is the same setting in reverse. It needs an Owner or Administrator, because only they can leave the station to reach settings. 1. On the station, click the avatar and click **Exit Operator View**. The browser goes to the Assets page with the standard header. 2. Click the gear icon at the top right of the header, then scroll to **Assign to Local Device**. 3. Next to the machine's name, click the **×** labeled **Clear asset from local device**. The section returns to the **Assign Asset** button. From the next sign-in the device behaves like any other browser. **Exit Operator View** alone does not unpair. It releases the browser until the next sign-in or reload, which boots back to the machine. Use it to reach settings, then unassign. ![The Assigned Asset row in Organization Settings showing a machine's photo, name and identifier with the red clear control beside it highlighted](/images/monitoring/mon-station-04.webp) *Unassigning. The device leaves station mode and behaves like any other browser.* ## Moving a station to a different machine You do not need to unassign first. Exit Operator View, click the gear icon, click the change icon next to **Assigned Asset** and pick the new machine. The next sign-in boots to it, and clock-ins from then on go against it. Moving the physical device does nothing on its own. A tablet carried from the Haas VF-2 to the Okuma beside it still boots to the Haas until someone changes the assignment. ## Errors | Symptom | Means | |---|---| | The station boots to the Assets page instead of the machine | Site data was cleared, or this is a different browser or profile. Assign again | | The operator cannot leave the machine page | That is the role gate working. Only an Owner or Administrator sees **Exit Operator View** | | **Assigned Asset** is missing from Organization Settings | You are signed in as an operator. Sign in as an Owner or Administrator | ## See also - [Use Operator View on the shop floor](/docs/monitoring/operator-view/) - [Roles reference](/docs/admin/roles-reference/) - [Classify a downtime event](/docs/monitoring/classify-downtime/) - [Offline behavior](/docs/get-started/offline-behavior/) --- # Use Operator View on the shop floor Source: https://www.iotflows.com/docs/monitoring/operator-view/ Turn on Operator View from the profile menu so every machine page at /assets/selected-asset/:id renders as a full-screen operator page: a header with live status and the Uptime gauge, then a four-tab strip of Part Count, All Downtime, Jobs and Notes. Log parts, bulk classify stops, run a job and leave notes without leaving the machine. The toggle is per browser, and anyone can turn it off. # Use Operator View on the shop floor A full-screen machine page an operator can work a whole shift from. *Operator View* is a display mode for a single machine's page. It drops the secondary navigation, enlarges every tap target, and replaces the Analytics tabs with four counters that are also tabs: **Part Count**, **All Downtime**, **Jobs** and **Notes**. Everything an operator does during a shift happens inside one of those four. **Prerequisites.** A machine with a paired sensor, see [Add a machine](/docs/monitoring/add-an-asset/). Shifts defined, so the counters cover the right hours, see [Set shifts and timezone](/docs/admin/shifts-and-timezone/). **Choose Operator View when** a person works at one machine on their own account. **Choose an operator station when** the device is shared and should boot into the machine without anyone signing in, see [Set up a dedicated operator station](/docs/monitoring/operator-stations/). A supervisor reading several machines needs neither: the standard [machine page](/docs/monitoring/asset-detail/) shows the same numbers with charts. ## Turn on Operator View 1. Click your avatar at the top right of the header. 2. Click **Operator View**. The page reloads. 3. Open **Assets** and click the machine. The address bar still reads `/assets/selected-asset/:id`, but the page renders as the operator page. The setting is stored in the browser, not on your account, so a tablet at the machine keeps it after sign-out and your desk PC is unaffected. On a phone the layout stacks, with the tab strip pinned to the top as you scroll. ![The profile dropdown open under the avatar at the top right of the header, listing Profile, Billing, Operator View and Sign out, with Operator View highlighted](/images/monitoring/mon-opview-01-v2.webp) *Turning on Operator View from the profile menu.* ## The KPI tab strip Above the strip sit the machine's photo, name and identifier, the live status pill, the **Uptime** gauge against the machine's goal, and the shift's status bar. Click a stop on the bar to classify it, see [Classify from the status bar](/docs/monitoring/classify-downtime/#status-bar). The control bar above holds a back link to **Assets**, the shift selector and the notifications bell. Each tab shows a number for the selected shift. Click the tab to open it. The page remembers which tab was open on each machine, so a refresh lands where the operator left off. | | Tab | Shows | Operator can | Page | |---|---|---|---|---| | 1 | **Part Count** | Parts made this shift, from the sensor | Correct a count, edit a work session | [Production metrics](/docs/monitoring/metrics-reference/#production) | | 2 | **All Downtime** | Downtime this shift as hours and minutes, red when above zero | Classify, split, unclassify or delete stops, singly or in bulk | [Classify a downtime event](/docs/monitoring/classify-downtime/) | | 3 | **Jobs** | Open jobs on this machine, active and queued | Start, pause, resume and complete a job, log parts and scrap | [Run a job](/docs/production/run-a-job/) | | 4 | **Notes** | Notes on this machine, all time | Add, edit and delete a note | [Notes](/docs/monitoring/asset-detail/#notes) | ![The operator page for one machine: a header with the machine photo, a green Running pill, an Uptime gauge and a status bar, then a row of four large tabs reading Part Count, All Downtime, Jobs and Notes, each with a number, with four numbered callouts on the tabs](/images/monitoring/mon-opview-02.webp) *The operator page. The tab strip is the whole interface: Part Count, All Downtime, Jobs, Notes.* ## Part Count The **Part Count** tab is the **Operation(s) Production** card from the standard page at operator scale. An **Auto-Detecting** label names the operation the sensor is counting against. Below it, a timeline shows the shift's work sessions, and one row per operation shows the count against its goal, with the shortfall in red as **Behind** or the surplus in green. The goal is the operation's hourly goal scaled to the shift, for example `240` over an eight-hour shift at 30 an hour. It is set on the operation, not here, see [Set OEE and utilization goals](/docs/monitoring/oee-goals/). Use **Modify Counts** when the sensor missed parts, for example after a bar feeder ran dry unnoticed. It records a manual session against an operation, see [Production counts and backfilling](/docs/monitoring/asset-detail/#backfill). You do not need this if the count is right. ![The Part Count tab with an Auto-Detecting label at the top, Modify Counts and Auto-Detect buttons at the right, a work-session timeline, and one operation row showing 212 parts against a goal with 28 in red labeled Behind](/images/monitoring/mon-opview-03.webp) *Part Count against the shift goal, as the operator sees it.* ## All Downtime and bulk classify The **All Downtime** tab lists the shift's activities as cards, with a green bar for uptime and a red bar for a stop. It opens on the **Unclassified** filter, which is the backlog. The other filters are **All**, **Uptime** and **Classified**, each with its count. Each stop carries **Classify**, **Split** and **Delete**. A classified stop shows its category and severity chip, and swaps **Classify** for **Edit** and **Remove**. An uptime card carries **Edit**, which changes the operation the run counted against. Bulk classification is the reason this tab exists. Click stops to select them, or click **Select all N unclassified**, then click **Classify N Downtimes** in the bar at the bottom. The steps, and when not to use it, are in [Bulk classify](/docs/monitoring/classify-downtime/#bulk). ![The All Downtime tab on the Unclassified filter with four stop cards ticked, a bar at the bottom reading 4 selected and Classify 4 Downtimes, and the classification modal open on its category picker, with numbered callouts on the selection and the picker](/images/monitoring/mon-opview-04.webp) *Bulk classifying several stops with the same reason.* ## Jobs The **Jobs** tab lists the machine's production jobs behind an **Active**, **Done** and **All** toggle, with a **+** to create one and the shift timeline above the list. The number on the tab counts active and queued jobs, not closed ones. Click a job to open it. The detail view has the same controls as the Work Queue: **Start**, which becomes **Pause** and then **Resume**; a **−** and **+** counter with **Add Parts** for a larger number; **Scrap**; and **Complete Job**. Every change goes to the same job session the Work Queue reads, so a supervisor sees it at once. The procedure lives in [Run a job](/docs/production/run-a-job/) and [Log scrap](/docs/production/log-scrap/). A job opened from **Done** or **All** can be reopened, which returns it to in progress. ![The Jobs tab detail view for one active job: a sidebar with the job's progress, a Pause button, a parts counter with minus and plus buttons, Add Parts, Scrap and Complete Job, beside a file viewer showing the job's drawing](/images/monitoring/mon-opview-05-v2.webp) *The Jobs tab runs the job without leaving the machine's page.* ## Notes The **Notes** tab is the machine's note list, newest first, with **Add Note** at the top. Each note shows its author and time, and can be edited or deleted in place. It is the same list as **Notes** on the standard page's Health tab, so a note about chatter at 2 pm is what the maintenance planner reads next morning, see [Notes](/docs/monitoring/asset-detail/#notes). ## Leaving Operator View The **Assets** link at the top left returns to the fleet page. Operator View stays on, so the next machine opened renders the same way. To turn it off, click your avatar and click **Exit Operator View**. The page reloads as the standard machine page. Any signed-in user can do this: Operator View is a display preference, not a lock. A device that must stay on its machine whoever is signed in is an operator station, whose exit is gated to an Owner or Administrator, see [Set up a dedicated operator station](/docs/monitoring/operator-stations/) and [Roles reference](/docs/admin/roles-reference/). ![The profile dropdown open in Operator View, listing Profile, Billing, Exit Operator View and Sign out, with Exit Operator View highlighted](/images/monitoring/mon-opview-06-v2.webp) *Turning Operator View off from the same menu. Any signed-in user can do this.* ## Errors | Message | Means | |---|---| | **No active session — start the job first** | You logged parts or scrap on a job that is not running. Click **Start** on the job, then log again | | **Failed to log part**, **Failed to record scrap** | The session was not updated; the counter shows the last saved value. Retry | | **Failed to update job status** | The status change was not saved; the job returns to its previous state. Retry | | **Failed to classify** | None of the selected stops were classified; the selection is kept. Retry | | **This category requires an additional note** | The category you picked needs a note before **Classify** is enabled, see [Downtime categories](/docs/monitoring/downtime-categories/) | ## See also - [Set up a dedicated operator station](/docs/monitoring/operator-stations/) - [Classify a downtime event](/docs/monitoring/classify-downtime/) - [Run a job](/docs/production/run-a-job/) - [Log scrap](/docs/production/log-scrap/) - [Inspect a single machine](/docs/monitoring/asset-detail/) --- # Overview: monitor machines and OEE Source: https://www.iotflows.com/docs/monitoring/overview/ What machine monitoring in IoTFlows answers and which page answers which question. Utilization, downtime and machine health come from the sensor alone; the parts gauge needs an ideal cycle time, and there is no combined OEE figure. Five views cover it: the Assets page for now and the current shift, the machine page for one machine, Downtimes for where the stopped time went, the Advanced Report for a month or quarter, and Canvas for a floor plan with live status. Shifts and the organization time zone must be set before any number is trustworthy. # Overview: monitor machines and OEE What monitoring tells you about your machines, and which page answers which question. Machine monitoring turns the running and stopped states a sensor reports into numbers about a machine: whether it is running now, how much of the shift it ran, and where the stopped time went. It needs a device online, see [Quickstart: see your first machine's data](/docs/get-started/quickstart/), and shifts defined, see [Shifts and time zone](/docs/admin/shifts-and-timezone/). ## What monitoring gives you Every number here is defined once, on [How each metric is calculated](/docs/monitoring/metrics-reference/). Three of them carry the section. *Utilization* is the share of a window the machine spent running, see [Uptime](/docs/monitoring/metrics-reference/#uptime). The same percentage is labeled **Uptime** on a machine card. *Downtime* is the time the sensor reported the machine stopped, with or without a reason on it, see [Downtime](/docs/monitoring/metrics-reference/#downtime). *OEE* is the textbook product of availability, performance and quality. IoTFlows shows availability as uptime and performance as the parts gauge from the sensor, and quality from the scrap your team logs against a job, each on its own, see [Uptime](/docs/monitoring/metrics-reference/#uptime). Beside those three, the sensor's vibration trace feeds a health score per machine, see [Monitor machine health and vibration](/docs/monitoring/machine-health/). ### Do you need parts and operations? You do not need parts and operations to use this section. Utilization, downtime and machine health come from the sensor alone. The parts gauge does not: it needs an ideal cycle time entered per operation, and quality is never measured. Start with the sensor numbers. Add operations when you want to know whether a running machine is running fast enough, see [Overview: track and schedule production](/docs/production/overview/). ## The five views Start from the question, not the page. Diagram: A diagram of five rows. Each row is a question on the left, an arrow, and a box on the right naming the monitoring view that answers it. Which machines are running right now, and how is the shift going: the Assets page, Assets, Overview tab. Why does this one machine read the way it does: the machine page, opened from any card. Where did the stopped time go, and which reason costs the most: Downtimes, Assets, Downtimes tab. How much did each machine run this month or quarter: Advanced Report, Assets, Advanced Report tab. Where does each machine sit on the floor, and is it running: Canvas, Assets, Canvas tab. *The five monitoring views and the question each one answers.* ### Question router | I want to know… | Page | |---|---| | Which machines are running right now, and how the shift is going | [Monitor your fleet on the Assets page](/docs/monitoring/assets-overview/) | | Why one machine's number reads the way it does | [Inspect a single machine](/docs/monitoring/asset-detail/) | | Where the stopped time went, and which reason costs the most | [Analyze downtime with Pareto and trend charts](/docs/monitoring/downtimes/) | | How much each machine ran this month or quarter | [Build a utilization report](/docs/monitoring/advanced-report/) | | Where each machine sits on the floor, and whether it is running | [Map your floor with Canvas](/docs/monitoring/canvas/) | The first four are tabs of the same **Assets** page, at `/assets?select=overview`, `downtimes`, `advanced_report` and `canvas`. The machine page opens from any card. For anything about now or the current shift, start on the Assets page, which is live. Open the Advanced Report only for a period longer than a day: it covers a range you choose rather than the current shift. ## What you must configure first Two settings decide whether any number is trustworthy. 1. **Shifts and the organization time zone.** Every window on every page is a shift, and every time is in the organization's time zone, not yours. For example, a 7 AM to 3 PM shift left in the wrong time zone reports the machine stopped for hours nobody worked, and the night shift's stops land on the wrong date. See [Shifts and time zone](/docs/admin/shifts-and-timezone/). 2. **The running threshold.** The sensor decides running or stopped by where the vibration sits against a threshold set during calibration. A threshold set too high reads every machine as stopped. See [Calibrate SenseAi and SenseAi Embedded](/docs/hardware/calibrate-senseai/). Two more are optional. A [downtime category](/docs/monitoring/downtime-categories/) list gives operators reasons to pick from, and an [uptime goal](/docs/monitoring/oee-goals/) colors each number green or red against a target. Both change what the pages can say, not what they count. ## Where to go next Read one shift end to end on [Quickstart: read your first shift of machine data](/docs/monitoring/quickstart/). If a number already looks wrong, go straight to [Troubleshoot wrong utilization or OEE](/docs/monitoring/troubleshoot-monitoring/). ## See it in a plant - [Machine monitoring](https://www.iotflows.com/platform/machine-monitoring) — Whether each machine is running, how much of the shift it ran and where the stopped time went, from a sensor and with no PLC. ## See also - [Quickstart: read your first shift of machine data](/docs/monitoring/quickstart/) - [How each metric is calculated](/docs/monitoring/metrics-reference/) - [Shifts and time zone](/docs/admin/shifts-and-timezone/) - [Monitor your fleet on the Assets page](/docs/monitoring/assets-overview/) --- # Quickstart: read your first shift of machine data Source: https://www.iotflows.com/docs/monitoring/quickstart/ Read one shift of machine data correctly, from the four fleet KPIs on the Assets page down to a single stop. Pick the shift before the date, read the uptime, utilization, downtime and machines-producing tiles, read one machine's card and its status ring, open one stop from the machine's status bar and give it a downtime category. Needs a device online and shifts defined. # Quickstart: read your first shift of machine data Read one shift correctly, from the KPI row down to a single stop. This page walks the happy path through the Assets page and one machine, with no branches. Every control it skips is covered on [Monitor your fleet on the Assets page](/docs/monitoring/assets-overview/). Before you start, you need: - A device online and sending data. If not, follow the [get started quickstart](/docs/get-started/quickstart/#confirm). - At least one shift defined for the organization, see [Shifts and time zone](/docs/admin/shifts-and-timezone/). Without one, every number on this page is a whole calendar day. ## Open the Assets page 1. Sign in to the dashboard on the web. 2. Click **Assets** in the top navigation. The page opens at `/assets?select=overview`. The page shows every machine you are allowed to see, live: four tiles across the top and a card for each machine below. ![The full Assets page during a shift. A toolbar runs across the top, four KPI tiles sit beside a utilization chart, and a grid of machine cards below shows a mix of green rings and red rings](/images/monitoring/mon-qs-01.webp) *The Assets page mid-shift. Every machine in the organization, live.* If the page is empty, no machine has been added yet. See [Add a machine](/docs/monitoring/add-an-asset/). ## Pick the shift and date A *shift* is a named window of the day, such as Day Shift from 06:00 to 14:00, defined once for the organization. Every number on the Assets page counts only the shift you have selected. 1. Click the shift selector in the toolbar. It shows the current shift by default. 2. Under **Shift**, pick the shift you want to read. 3. Under **Select Date**, leave today selected. 4. Click **Apply**. ![The shift selector popover on the Assets page toolbar, with numbered callouts on the Shift list, where Day Shift is selected, and on the Select Date calendar showing today](/images/monitoring/mon-qs-02.webp) *Pick the shift before the date. A day that spans three shifts averages away the shift that had the problem.* Read the shift view first, not the day view. **All Day** is also in the list, but a day that spans three shifts averages away the shift that had the problem. For example, a night shift at 40% utilization and two day shifts at 85% read as a 70% day. If the list holds only **All Day** and **Custom Time**, no shifts have been defined yet. Define them first, on [Shifts and time zone](/docs/admin/shifts-and-timezone/), then come back. ## Read the four fleet KPIs The four tiles total every machine on the page for the shift you picked. ![The KPI row on the Assets page with four numbered callouts: an Uptime tile reading 33:18h, a Utilization tile reading 67.6% in red, a Downtime tile reading 15:59h, and a Machines Producing tile reading 8 of 14](/images/monitoring/mon-qs-03.webp) *The four fleet KPIs: uptime, utilization, downtime and machines producing.* 1. **Uptime** is the hours every machine spent running this shift, added together. 2. **Utilization** is uptime as a percentage of uptime plus downtime. It is green when it meets the organization's goal and red when it does not. 3. **Downtime** is the hours every machine spent stopped, added together. 4. **Machines Producing** is how many machines are running right now, over the total, as `8/14`. The first three describe the shift so far. The fourth describes this moment: a fleet can read 90% utilization and `2/14` producing at once, if a break started a minute ago. Each metric is defined, with its formula, in [Metrics](/docs/monitoring/metrics-reference/). ## Read one machine's card Find the machine you know best and read its card. Two elements matter today; the rest is explained on [Read a machine card](/docs/monitoring/assets-overview/#cards). ![A single machine card for a running machine, with numbered callouts on the green status ring around the machine photo, the green and red shift status bar along the bottom, the hourly production bars, and the Uptime gauge](/images/monitoring/mon-qs-04.webp) *One machine's card. The ring is now, the bar is the shift so far.* The *status ring* is the colored ring around the machine's photo. It shows the machine's state at this moment: green for running, orange or red for stopped, with red meaning it has been stopped longer. A sensor reports a machine as running or down, and nothing else; the colors add how long. The *shift status bar* runs along the bottom of the card from the start of the shift to now, colored for the state the machine was in at each moment. The ring is now; the bar is the shift so far. Six short red stretches and one long one are the same downtime total and completely different problems. Gray on the bar is not downtime. It means the sensor sent nothing for that stretch. A bar striped with gray is a connectivity problem, see [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). ## Open one stop A stop is only a red stretch until someone says why it happened. 1. Click the card. The machine's own page opens at `/assets/selected-asset/:id`. 2. Find the status bar at the top of the page. It is the card's bar drawn wider. 3. Click a red segment. A card opens showing the stop's start time and duration. ![The shift status bar at the top of a machine page, with one bright red stop segment highlighted among green running stretches](/images/monitoring/mon-qs-05-v2.webp) *Clicking a segment of the shift bar on the machine page opens that stop.* ## Give it a reason A *downtime category* is a named reason for a stop, such as **Tool Change** or **No Operator**, chosen from a list your organization maintains. Classifying a stop attaches one category to it, so reports can rank reasons by the time they cost. 1. On the stop's card, click the pencil icon. The **Classify Downtime** modal opens. 2. Pick a category. They are grouped by severity, **None** to **High**. 3. If the category is marked with an asterisk, type a note in **Additional notes**. The modal will not save without it. 4. Click **Classify**. ![The Classify Downtime modal with numbered callouts on the category chips, grouped by severity with one selected, and on the Additional notes field marked with a red asterisk](/images/monitoring/mon-qs-06.webp) *Giving a stop a reason. Some categories require a note before they will save.* The segment turns dark red as soon as it saves. That is how a classified stop looks everywhere. You do not need to classify every stop today. Stops under a minute, breaks, and the start and end of a shift can be classified for you by rules, see [Automatic downtime rules](/docs/monitoring/auto-downtime-rules/). If the category list is empty or does not fit your floor, build it on [Manage downtime categories](/docs/monitoring/downtime-categories/). ## What you just learned You read one shift from the top down: - The shift selector decides what every number counts. Shift first, then date. - The four tiles total the fleet for the shift. Three describe the shift so far, one describes now. - On a card, the ring is now and the bar is the shift so far. Gray on the bar is missing data, not downtime. - A stop opens from the machine page's status bar, and a category is what turns it into a reason. ### Every machine reads as stopped If every card carries a red ring while the machines are running, the sensors do not yet know what running looks like on those machines. Set the running threshold on each one, see [Set the running and stopping thresholds](/docs/hardware/calibrate-senseai/#thresholds). ## See also - [Monitor your fleet on the Assets page](/docs/monitoring/assets-overview/) - [Classify a downtime event](/docs/monitoring/classify-downtime/) - [Metrics](/docs/monitoring/metrics-reference/) - [Shifts and time zone](/docs/admin/shifts-and-timezone/) --- # Email a report and schedule it to repeat Source: https://www.iotflows.com/docs/monitoring/share-and-schedule-reports/ The Downtimes report, the Advanced Report and the historical production report all carry Share and Schedule in their Actions menu. Share emails the view you built to members of your organization now, with an optional message. Schedule saves it as an automation that emails on a daily to yearly cadence, to a fixed recipient list. A schedule needs a rolling date preset, so a report on a fixed from-to window cannot be scheduled. Automations are listed, paused, edited and deleted from the same dialog, one list per report. # Email a report and schedule it to repeat Get the report you are looking at to the people who need it, once or every week. Three reports carry the same two actions in their **Actions** menu. **Share** emails the current view to members of your organization straight away, and **Schedule** saves that view and emails it on the cadence you pick. Both send the report exactly as your toolbar has it, so build the report first and send it second. **Prerequisites.** A report you can already build, see [Analyze downtime with Pareto and trend charts](/docs/monitoring/downtimes/) or [Build a utilization report](/docs/monitoring/advanced-report/). ## Share a report by email now 1. Build the report: set the date range, machines, shifts and switches you want the reader to see. 2. Open **Actions** at the right of the filter bar. 3. Click **Share**. 4. Click the recipients field, then pick members from the list. **Search members…** filters it, and **Select all** and **Clear** work on the whole organization. 5. Add a message, or leave it empty. 6. Click **Send**. A toast confirms the send: **Report shared with 3 recipients**. ![The Share report dialog open over the Downtimes report. A Recipients field holds three member chips with avatars, a Message box below it carries an optional note, and a read-only Report block lists the time interval, date range, machines, shifts and categories being sent. Cancel and Send buttons sit at the bottom right.](/images/monitoring/mon-share-01.webp) *Sharing a report by email to organization members.* The **Report** block at the bottom of the dialog is read-only. It lists the time interval, date range, machines, shifts and any switch that is on, copied from the toolbar. Read it before you send: it is the report the recipient gets, not the one you meant to build. On the Advanced Report and the Downtimes report the block carries a **Shift islands** row, reading either `On — an overnight shift counts on the day it began` or `Off — an overnight shift splits at midnight`. It is shown in both states, so a night-shift report and the same report with the toggle on never read alike, see [Shift islands](/docs/monitoring/advanced-report/#shift-islands). Historical production has no such row, because that report has no toggle. ## Schedule a recurring report An *automation* is a saved copy of a report view that IoTFlows emails on a cadence to a fixed list of recipients. 1. Set the toolbar's date button to a rolling preset, such as **Last 7 days** or **Last 4 weeks**. 2. Open **Actions**, then click **Schedule**. 3. Click the **+** button, or fill in the form if this is your organization's first automation for this report. ![The Actions menu open on a report toolbar, listing Download as PDF, Download as CSV, Share and Schedule under a Report actions heading, with the date button beside it reading Last 4 weeks](/images/monitoring/mon-share-02.webp) *Scheduling a report to repeat. The toolbar must be on a rolling preset, not a fixed window.* The date range is the one rule the form enforces. A schedule needs a *rolling* period: a window counted back from the send date rather than fixed to two dates. Pick **Last 4 weeks**, and every email covers the four completed weeks before it was sent. > **Warning:** > **Does the date button show two dates?** Then the report is on a fixed window and new automations are disabled. The dialog opens on its list with an amber banner, **Pick a date range preset to schedule emails**, and the **+** button is grayed out. Open the date button, click a **Last N** preset, click **Apply**, and try again. The button reads the preset name, **Last 8 weeks**, when the window is rolling, and a date span, **8/18/2026 - 9/14/2026**, when it is not. ![The amber banner at the top of the Email automations dialog, reading Pick a date range preset to schedule emails, with the explanation that scheduled emails need a rolling window and that the report is on a custom date range. The plus button above it is greyed out.](/images/monitoring/mon-share-04.webp) *With a fixed date range selected, scheduling is refused. A schedule needs a rolling period.* **Last week (Mon - Sun)** is the exception among the presets. It names one finished calendar week rather than a count back, so it writes fixed dates and blocks scheduling like a custom range does. For a Monday recap of the week before, use **Last 7 days**. ## Name and cadence **Name** is required and appears only in the automations list. Name it for the audience and the rhythm, for example `Monday maintenance recap`, so the list stays readable once there are six of them. **Cadence** is how often the email goes out: **Daily**, **Weekly**, **Monthly**, **Quarterly** or **Yearly**. **Weekly** adds a **Day of week** picker, Monday by default. No other cadence exposes one, and none lets you set the hour. Cadence is independent of the report's own time interval. A report bucketed into daily bars can be emailed weekly, which is the usual shape: daily detail, one email a week. Under the picker, a preview line reads **Next email Mon, Sep 21 covers Sep 8, 2026 – Sep 14, 2026**. Check it before you save. It is the cheapest way to catch a cadence that does not line up with the window. Fill in the recipients below, then click **Create automation**. The dialog returns to the list with the new automation on it, and a toast reads **Automation created**. ![The New email automation form. A Name field holds Monday maintenance recap, a Delivery section shows five cadence chips with Weekly selected and a Day of week picker set to Monday, a preview line reads Next email covers a date range, and a Recipients section shows three member avatars. A read-only Report Summary sits at the bottom.](/images/monitoring/mon-share-03.webp) *The automation fields: name, cadence and recipients.* ### Automation fields | Field | Required | Values | Notes | |---|---|---|---| | **Name** | Yes | Free text | Shown in the automations list and nowhere else | | **Cadence** | Yes | Daily, Weekly, Monthly, Quarterly, Yearly | How often the email is sent. Independent of the report's time interval | | **Day of week** | Weekly only | Monday to Sunday, Monday by default | Hidden for every other cadence | | **Recipients** | Yes, at least one | Members of your organization | No free-text email addresses | | **Enabled** | No | On or off | Set from the switch on the list row, not in the form. Off pauses the emails and keeps the automation | | **Report Summary** | — | Read-only | Time interval, date range, machines, shifts, categories, sort, grouping and switches, copied from the toolbar when you create the automation. On the two reports that have it, a **Shift islands** row shows on or off. Editing an existing automation reads every row back from the saved report, not from your current toolbar | | Time of day | — | Not configurable | You choose the cadence and, for a weekly report, the day. There is no field for the hour | ## Recipients Recipients come from your organization's member list. Click the avatar to open the picker, search by name, and click a member to add or remove them. **Select all** adds everyone, and **Clear** empties the list. At least one recipient is required either way. An automation with an empty list cannot be saved, and **Send** stays disabled until a share has someone to go to. Neither dialog takes an outside address. To reach a customer, an auditor or a corporate office with no seat, either [invite them to the organization](/docs/admin/invite-members/) first, or download the PDF and send it yourself, see [Available exports](/docs/monitoring/exports-reference/). Schedule a report to a plant manager who has an account and will not open it, rather than asking them to check the dashboard every Monday. You do not need a schedule when the audience is one conversation: share once instead. A weekly email that nobody asked for gets filtered into a folder, and the one that mattered goes unread with it. ## Review scheduled reports Open **Actions › Schedule** again. The dialog opens on **Email automations**, everything already scheduled for this report. Each row carries the name, a cadence badge, the date window it sends, the delivery day for a weekly one, and avatars for its recipients. The switch on the right pauses and resumes it, confirmed by a toast that names it: **Monday maintenance recap paused**. A paused automation keeps its settings and sends nothing. ![The Email automations list with two rows. Each row shows a name, a blue cadence badge reading Daily or Weekly, the date window and delivery day beneath it, a group of recipient avatars, an enable switch and a three-dot menu. A plus button sits above the list.](/images/monitoring/mon-share-05.webp) *Existing report automations, with edit and delete.* Each report keeps its own list. The Downtimes report shows only downtime automations, and the Advanced Report and the historical production report each show only theirs, so a report that looks unscheduled may be scheduled from another page. ### Available on | Report | Share now | Schedule | |---|---|---| | [Downtimes](/docs/monitoring/downtimes/), at `/assets?select=downtimes` | Yes | Yes | | [Advanced Report](/docs/monitoring/advanced-report/), at `/assets?select=advanced_report` | Yes | Yes | | [Historical production](/docs/production/historical-production/), at `/production?select=historical_report` | Yes | Yes | | Every other page, including the Assets page and [Operator Performance](/docs/monitoring/operator-performance/) | No | No, export instead | ## Edit or delete an automation Open the **⋯** menu on a row. **Edit** reopens the form on that automation. Change the name, the cadence, the delivery day or the recipients, then click **Save changes** for a toast reading **Automation updated**. You cannot change what the report contains. The **Report Summary** now reads **These are the report parameters saved with this automation**, and stays read-only. To send a different date range, different machines or different switches, build that report on the toolbar, create a new automation, then delete this one. The same is true of light and dark mode. An automation renders in whichever theme the dashboard was set to when you clicked **Create automation**, and switching your account's theme afterward does not change automations already saved. To send a report in the other mode, switch the dashboard's theme, build the report again, create a new automation, then delete this one. **Delete** asks to confirm, then removes the automation. The dialog says the action cannot be undone, and it is right: nothing restores a deleted schedule. Emails already sent are unaffected. ## What recipients receive Every recipient is a member of your organization, so the report goes to the address on their IoTFlows account. Nothing is posted to a public link. A share carries your message, if you wrote one, and the report as your toolbar had it when you clicked **Send**. A scheduled email carries the report saved with the automation, over the window that ends when it is sent. Both carry a link back to the report on the dashboard with the filters already applied. The recipient signs in and lands on the view you built rather than a picture of it, so they can move the date range or open a machine from there. ## Errors | Message | Means | Do this | |---|---|---| | **Pick a date range preset from the toolbar to schedule emails.** | The report is on a fixed window, so no automation can be created | Pick a **Last N** preset on the date button and click **Apply** | | **Could not share report** | Nothing was sent, and no recipient was emailed | Retry. If it repeats, see [Get support](/docs/get-started/get-support/) | | **Could not save automation** | The schedule was not created | Check the name and at least one recipient, then retry | | **Could not update automation** | The edit, or the pause switch, did not save. The switch flips back to where it was | Retry. Until it saves, the automation is still sending on its old settings | | **Could not delete automation** | The automation is still live and still sending | Retry, or pause it with the switch as a stopgap | Where the server sends its own explanation, the toast shows that instead of the message above. ## See also - [Analyze downtime with Pareto and trend charts](/docs/monitoring/downtimes/) - [Build a utilization report](/docs/monitoring/advanced-report/) - [Available exports](/docs/monitoring/exports-reference/) - [Invite members to your organization](/docs/admin/invite-members/) --- # Set status colors and downtime thresholds Source: https://www.iotflows.com/docs/monitoring/status-colors/ Two durations decide when a stopped machine turns orange and then red on the Assets page. Set both, and the color red itself, from Adjust Status Colors on the Utilization tile. The thresholds are organization-wide, they are cosmetic rather than analytical, and a classified stop skips them for dark red. Owner or Administrator. # Set status colors and downtime thresholds Make the board's colors mean what your plant means by "a problem". A sensor reports a machine as running or down, with nothing in between. The colors on the Assets page carry the part the state word cannot: how long the machine has been down. A *threshold* is that duration, a number of minutes counted from the moment the machine last ran. You set two of them. The first turns a stopped machine orange, the second turns it red. **Before you start.** Sign in as an Organization Owner or Organization Administrator, see [Roles reference](/docs/admin/roles-reference/). Both thresholds and the red itself are organization-wide, so one setting covers every machine and every member. ## Open status colors 1. Open the Assets page at `/assets`. 2. In the row of tiles across the top of the page, select the sliders icon in the top right corner of the **Utilization** tile, tooltipped **Adjust Status Colors**. It sits to the right of the target icon that sets the goal, see [Set OEE and utilization goals](/docs/monitoring/oee-goals/#org). 3. Type the two minute figures described below. 4. Select **Set**. IoTFlows confirms with "Status Colors Set" and every open board recolors. If the save fails, the toast carries the message the server returned and nothing was written. Reopen the dialog and read the numbers back before assuming the change took, see [Troubleshoot wrong utilization or OEE](/docs/monitoring/troubleshoot-monitoring/). ## The status colors The dialog is headed **Status Colors**, over a panel reading **Set Times for Asset Status Colors**. A preview bar across the top shows the split you are building, the two large fields hold the thresholds in minutes, and the italic line underneath restates them as a sentence. | Color | Means | Threshold | Where shown | |---|---|---|---| | Green `#16a34a` | Running, or stopped for less time than the orange threshold | Below the orange threshold | Status pill, photo ring, card border, list row, Canvas tile | | Orange `#d97706` | Stopped, and the stop is older than the orange threshold | Orange threshold up to the red one | The same | | Red, `#dc2626` until you change it | Stopped past the red threshold, with no reason on the stop yet | Past the red threshold | The same | | Dark red `#7f1d1d` | Stopped, and the stop has been classified | None. It applies the moment a reason is saved | The same | | Gray `#94a3b8` | The sensor sent nothing for that stretch | None | The shift status bar only | A classified stop skips the thresholds. It draws dark red from the moment the reason is saved, rather than working through green and orange first, see [Classify a downtime event](/docs/monitoring/classify-downtime/). Dark red is only the default: where the category carries a color of its own, the stop draws in that color, see [Change a color](/docs/monitoring/downtime-categories/#color). Gray is the absence of data rather than downtime. A bar striped with gray through a shift is a connectivity problem, not a machine that keeps stopping, and the card still reads stopped because it carries the last state the cloud recorded. See [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). **You probably do not need to change the red.** The swatch beside the red field opens a palette, and each color there has a light and a dark version so the board stays legible in both themes. Change it only where red already means something else on your floor, for example a plant whose andon lights reserve red for a safety stop. ![The Status Colors dialog. Numbered callouts mark the preview bar running green, then amber, then red with a small triangle under each boundary; the large amber 1 labeled min; the large red 5 labeled min(s); and the red swatch button beside it. An italic line reads Your machines' status will change to orange after 1 minutes of inactivity and to red after 5 minutes, and Cancel and Set sit along the bottom.](/images/monitoring/mon-color-01.webp) *Status colors and the two downtime thresholds behind them.* ## The orange threshold Orange is the first warning. It is the left-hand field, and it defaults to one minute. **Set it near your normal changeover time.** Orange should mean "this stop has run longer than a tool change". On a line that indexes in forty seconds, one minute is right; on a cell whose fixture swap takes six, one minute paints the board orange all shift. A threshold of `0` colors the machine the moment a stop is recorded, which turns every gap between cycles into a warning. Nothing below your shortest routine stop is useful. ## The red threshold Red is the call to act. It is the right-hand field, it defaults to five minutes, and it is the one carrying the color swatch. **Set it at the point where someone should be walking to the machine.** That is a decision about your floor rather than about the software: on a bottleneck cell it might be three minutes, on a machine that runs a two-hour program unattended it might be thirty. The red threshold cannot sit below the orange one. Typing a smaller number snaps it back to the orange figure, and raising orange above red pushes red up to match. > **Note:** > **Why is the board always green?** Thresholds tuned so that almost nothing ever turns orange teach people not to look at the board. If a shift ends with no color on it, the numbers are too generous, not the plant too good. Compare them against a real shift on the Downtimes report, see [Analyze downtime with Pareto and trend charts](/docs/monitoring/downtimes/). ## Where the colors appear The thresholds are evaluated live in your browser, against the time since each machine last ran. They color: - Every view on the Assets page, including the rows of a cascading group, see [Monitor your fleet](/docs/monitoring/assets-overview/#colors). - The status pill and the photo ring in a machine's page header, see [Inspect a single machine](/docs/monitoring/asset-detail/#header). - Machine tiles on Canvas, see [Map your floor with Canvas](/docs/monitoring/canvas/#tiles). - Operator View, and machine cards and rows in the mobile app. - A wallboard, because a wallboard is one of those views on a bigger screen, see [Display a wallboard on a TV](/docs/monitoring/wallboards/). **The thresholds never change a number.** Uptime, downtime and utilization are the same whatever you set here, and no report, chart or export carries a color threshold at all. A stop of four minutes is four minutes of downtime whether the card was orange or red while it happened, see [How each metric is calculated](/docs/monitoring/metrics-reference/). **A color is not an alert.** Nobody is notified when a machine turns red. The delay before IoTFlows sends a machine-down notification is a separate, per-machine setting, so a plant that wants to be told about long stops sets that as well, see [Set alert rules for a machine](/docs/alerts/asset-event-rules/). ![Three consecutive rows of the Assets list. DMG DMU 65 carries a green Running pill inside a green photo ring, DMG Mori an orange Last Op: 1 minute ago pill inside an orange ring, and Robot Line 3 a red Last Op: 9 minutes ago pill inside a red ring. A shift bar runs under each row in the same colors.](/images/monitoring/mon-color-02.webp) *The same stop at three ages: green under the first threshold, orange past it, and red past the second.* ## See also - [Monitor your fleet on the Assets page](/docs/monitoring/assets-overview/#colors) - [Classify downtime automatically](/docs/monitoring/auto-downtime-rules/) - [Manage downtime categories](/docs/monitoring/downtime-categories/#color) - [Set alert rules for a machine](/docs/alerts/asset-event-rules/) - [Map your floor with Canvas](/docs/monitoring/canvas/) --- # Troubleshoot wrong utilization or OEE Source: https://www.iotflows.com/docs/monitoring/troubleshoot-monitoring/ Symptom, cause and fix for machine numbers that do not match the floor. Check the organization timezone first, because it is the one setting that moves every number at once while leaving each one looking plausible. Then the shift schedule, then the window and the Exclude switches on screen, then the machine's own status bar, where gray means the sensor was silent and red means it was stopped. Also covers uptime that reads too high or too low, stops that never appear, unclassified backlog, and the four edits that rewrite history. # Troubleshoot wrong utilization or OEE Symptom, cause and fix for numbers that do not match the floor. *Uptime* is availability: running time over running plus stopped time. It is the number the interface has labeled OEE, and it is built from one thing, the running and stopped states a sensor reported. So a number that looks wrong is usually wrong about where a boundary fell, what the window covered, or what the sensor was doing at the time. Every metric named on this page is defined in [How each metric is calculated](/docs/monitoring/metrics-reference/). ## Start here: four checks Diagram: A decision tree headed My numbers do not match the floor, branching into four checks to work in order. Check 1, the organization timezone: does the Schedules panel name your plant's zone? Its blast radius is every number, on every machine, in every window. Check 2, the shift schedule: do the times and days match the floor's calendar? Its blast radius is every number scoped to a shift. Check 3, the window on screen: the shift, the date, the filters, and the Exclude switches. Its blast radius is every number on this screen. Check 4, this one machine: gray on its status bar, or thresholds set wrong. Its blast radius is one machine. A note across the bottom reads: widest blast radius first. A wrong timezone leaves every number looking plausible, which is why it is checked before anything else. *My numbers look wrong: the four branches, starting with the organization timezone.* **Check the organization timezone before anything else.** It is the single setting that makes every number wrong at once, and nobody suspects it, because the numbers still look plausible. A plant in Detroit whose organization reads `UTC` sees whole shifts of production land in the wrong day. Work the four in order. Each rules out a cause the ones after it cannot explain. 1. **Timezone.** Open Organization Settings from the gear at the top right of the header and read **Schedule Timezone** in the **Schedules** panel. It must name the plant's zone, not the head office's and not yours. 2. **Shift schedule.** In the same panel, read **Work Schedule**. The days on each shift matter as much as its times. 3. **The window on screen.** Read the shift and date selector, the department and tag filters, and the **Exclude Unknown** and **Exclude None** switches if you are on the Advanced Report. 4. **This one machine.** Read its status bar across the window in question. Gray is time the sensor said nothing; red is time it said the machine was stopped. Then jump to your symptom. | Symptom | Likely cause | Check | Fix | Page | |---|---|---|---|---| | Uptime higher than the floor believes | Short stops converted to uptime | The machine's **Treat short downtimes as uptime** toggle | Turn it off, or raise the cutoff | [Utilization too high](#too-high) | | Uptime lower than the floor believes | Shift schedule longer than the plant runs | **Work Schedule** against the real calendar | Shorten the shift, or classify the edges | [Utilization too low](#too-low) | | Machine reads running while it sits idle | Running threshold below the idle band | The vibration trace against both thresholds | Raise the running threshold | [Running when idle](#running-when-idle) | | A stop everyone saw is not in the report | Uptime filter, downtime filter, or a rule | The machine's filter values, then the activity list | Lower the filter, or split the activity | [Downtime not recorded](#missing-downtime) | | Half the shift is unclassified | No automatic rules, or none that fit | **Auto-Downtime Classifications** | Turn on short downtimes first | [Too much unclassified time](#unclassified) | | Production lands in the wrong shift or day | Timezone, or an overnight shift misdefined | **Schedule Timezone**, then the shift times | Correct the zone, then the shifts | [Shift boundaries](#shift-boundaries) | | Your spreadsheet and the dashboard disagree | Unknown time, None breaks, or window averaging | What the window excludes | Recompute on the platform's definition | [Manual calculation](#manual-check) | | A number you read yesterday has moved | Backfill, deleted data, or a calibration change | Who changed what, and when | Nothing to fix, but know the cause | [Numbers changed](#retroactive) | ## Utilization too high Uptime above what the floor believes is almost always stopped time being counted as running time. 1. Open the machine's calibration panel and read the short-stop control. With **Treat short downtimes as uptime** on, every stop under the cutoff becomes runtime. A 10-minute cutoff on a machine that stops six times a shift adds an hour of uptime nobody worked. See [Handle short stops](/docs/hardware/calibrate-senseai/#short-stops). 2. Read the stopping threshold. Set too low, the trace never falls below it, and a machine humming on standby reads as running. See [Running when idle](#running-when-idle). 3. Check whether **Exclude None** is on. It removes a mandated lunch hour from the denominator as well as the numerator, which raises the percentage without anyone producing more. See [The None severity](/docs/monitoring/metrics-reference/#none). 4. Rule out the **Uptime Filter**. It drops runs shorter than a set number of seconds, so it pushes uptime down, never up. See [Filter out short uptimes](/docs/hardware/calibrate-senseai/#uptime-filter). **Convert short stops to uptime only when the pause is part of the cycle.** Indexing and brief cooldowns qualify. A tool change does not: it is real stopped time, and converting it means the plant can never see what tool changes cost. ## Utilization too low A number below the floor's expectation is usually honest, and the fix is a schedule change rather than a settings change. 1. Compare **Work Schedule** to the hours the plant actually runs. A shift defined 6 AM to 6 PM on a plant that runs 7 AM to 3:30 PM adds three and a half hours of downtime to every machine, every day. 2. Check the days on each shift. A shift listing Saturday and Sunday on a plant that runs five days makes every weekend a full shift of downtime. 3. Read the Pareto on the Downtimes report for the same window. If one category carries most of the loss, the number is correct and the problem is on the floor. See [Read the Pareto chart](/docs/monitoring/downtimes/#pareto). 4. Read the **Unknown Hours** card on the Advanced Report. A machine whose sensor was offline half the period has a connectivity problem, not a production one. See [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). You do not need to change the goal to fix this. A goal changes what color a gauge draws, not what it counts, see [Set OEE and utilization goals](/docs/monitoring/oee-goals/#choosing). ## Machine shows running when idle The sensor reports running or stopped, and nothing in between. The state flips when the vibration trace, smoothed by momentum, crosses a threshold, so a machine that reads running while it sits idle has a threshold problem rather than a hardware fault. 1. Open the calibration panel and watch the live trace with the machine standing still. Note the highest point the idle band reaches. 2. Raise the **Running Threshold** to just above that point, leaving a buffer. It is the control that decides where uptime starts. 3. Leave a gap between **Running Threshold** and **Stopping Threshold**. A machine whose vibration wanders across a single line flips state on every wander. See [Set the running and stopping thresholds](/docs/hardware/calibrate-senseai/#thresholds). 4. If the state flickers on a machine that is genuinely running, raise **Momentum** instead. Momentum smooths the trace so brief swings don't move the state. See [Set momentum](/docs/hardware/calibrate-senseai/#momentum). **Raise the threshold when the state is wrong. Raise momentum when the state is right but unstable.** The two look alike on a card and are opposite on the trace. Confirm the sensor is still attached before touching either. A SenseAi knocked off its mounting surface reads a neighboring machine, see [Device is online but sends no data](/docs/hardware/troubleshoot-offline-device/#no-data). > **Info:** > **Reading a BeamTracker instead?** It decides state from parts crossing a beam rather than from vibration, so the equivalent controls are detection distance and minimum object thickness. See [Set what counts as a part](/docs/hardware/calibrate-beamtracker/#beam-values). ## Downtime not recorded A stop everyone on the floor saw, and the report does not carry, was filtered, absorbed or never detected. | Where it went | How to tell | What to do | |---|---|---| | Converted to uptime | The stop was shorter than the machine's cutoff and the toggle is on | Raise the cutoff, or turn the toggle off, in [Handle short stops](/docs/hardware/calibrate-senseai/#short-stops) | | Absorbed by the downtime filter | A BeamTracker whose downtime filter exceeds the gap between parts | Lower the value in [Set the downtime filter](/docs/hardware/calibrate-beamtracker/#downtime-filter) | | Never detected | The machine kept vibrating while it was not producing | Raise the running threshold in [Calibrate SenseAi](/docs/hardware/calibrate-senseai/#thresholds) | | Recorded as unknown | The sensor was offline for the stretch | The bar is gray, not red. See [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/#stopped-or-offline) | | Outside the window | The stop crossed a shift boundary or the date you selected | Widen the window, or clear the shift filter, in [Choose the window](/docs/monitoring/assets-overview/#window) | | Merged into a longer stop | One stop on the record covers two real events | Split it in [Split a downtime](/docs/monitoring/classify-downtime/#split) | Read the machine's activity list before changing any setting. It lists every interval in the window with its start, duration and state, so it tells you whether the platform recorded one long stop, several short ones, or nothing at all. See [The activity feed](/docs/monitoring/asset-detail/#activity). ## Too much unclassified time Unclassified downtime is still downtime. It counts in full, and no percentage on any screen moves when somebody classifies it, see [Downtime](/docs/monitoring/metrics-reference/#downtime). What a backlog costs you is the Pareto: a report whose largest bar reads Unclassified cannot say where the time went. 1. Turn on the **Short Downtimes** rule first. It removes the majority of a plant's unclassified rows and is the rule least likely to hide something you needed to see. See [Short downtimes](/docs/monitoring/auto-downtime-rules/#short-downtimes). 2. Add break windows for lunch and scheduled breaks, which are otherwise classified by hand every day. See [Scheduled breaks](/docs/monitoring/auto-downtime-rules/#breaks). 3. Clear the existing backlog with bulk classify. Rules never reach back, so turning one on leaves yesterday untouched. See [Bulk classify](/docs/monitoring/classify-downtime/#bulk). 4. If operators are classifying and the backlog still grows, the category list is too long or too vague to pick from. See [Design a category list](/docs/monitoring/downtime-categories/#design). **Leave the Entire Shift rule off until the shift schedule is trusted.** If the schedule says a shift ran when the plant was closed, every machine reads as down for the whole of it, and the rule silently files a shift of real downtime under whatever category you chose. ## Shift boundaries look wrong Production landing in the wrong shift, the wrong day, or split across two of them is almost always a timezone or schedule problem. 1. Open Organization Settings and read **Schedule Timezone**. Shift boundaries are read against this zone, so a wrong value moves every one of them by the offset between the two. The dropdown lists named zones such as `(GMT-05:00) Eastern Time (US & Canada)` rather than raw offsets, so the zone carries its own daylight-saving rule. 2. Read the shift times. An overnight shift is one whose end time is at or before its start time, for example 10 PM to 6 AM, and needs no second entry for the morning. 3. Check that shifts do not overlap. The panel states the rule under **Work Schedule**. 4. Check the days on each shift. A night shift running Friday into Saturday is entered on Friday alone. 5. Rule out the midnight split before calling it an error. Reports divide an overnight shift at midnight unless **Shift islands** is on, while the Assets page shows it whole, so the two disagree by design. Check the ends of the run rather than the middle: the first day of a run is short, and the day after the last night carries hours, while a day mid-run can total correctly out of two different nights. See [Where the overnight hours land](/docs/admin/shifts-and-timezone/#overnight-hours). The timezone and the shifts save together. Click **Edit** on the **Schedules** panel, make both changes, then click **Save**, and a **Work shifts modified** toast confirms it. There is no way to save one without the other, so read both back before leaving the panel. Full procedure in [Shifts and timezone](/docs/admin/shifts-and-timezone/). ![The Schedules panel in Organization Settings. A row labeled Schedule Timezone holds a dropdown reading a GMT offset followed by a named zone, highlighted with a violet box. Below it, a Work Schedule row lists each shift with its name, its days abbreviated to three letters, and its start and end times](/images/monitoring/mon-trouble-02.webp) *The organization timezone. It is the one setting that makes every number wrong at once.* Correcting the zone does not move data that is already recorded. It moves the boundaries that data is read against, so historical reports redraw against the corrected shifts rather than losing anything. ## OEE does not match a manual calculation First, confirm you are comparing the same measure. **IoTFlows has no combined OEE figure.** It reports availability as uptime, performance as the parts gauge and quality from the scrap your team logs, each on its own, and nothing multiplies them together. Comparing an IoTFlows uptime of 85% to an OEE of 60% from another system compares one factor to the product of three. Once you are comparing uptime to availability, four things explain nearly every remaining difference. | Difference | Why | Where it is decided | |---|---|---| | The hours do not add up to the shift | Unknown time counts toward neither uptime nor downtime | [Unknown time](/docs/monitoring/metrics-reference/#unknown) | | A break is missing from the total | **Exclude None** removes None-severity stops from both terms | [The None severity](/docs/monitoring/metrics-reference/#none) | | A multi-shift window is not the average of its shifts | The window is calculated whole, so a longer shift contributes more minutes | [Production metrics](/docs/monitoring/metrics-reference/#production) | | Short stops are missing from downtime | The machine converts them to uptime | [Handle short stops](/docs/hardware/calibrate-senseai/#short-stops) | For example, a 9-hour shift reading 6 h 30 min uptime and 1 h 30 min downtime is not missing an hour: the sensor was offline for it, and unknown time sits outside both terms. Uptime is 6.5 ÷ 8 = 81%, not 6.5 ÷ 9 = 72%. **Turn Exclude Unknown and Exclude None on when you are comparing machines or holding someone to a number. Leave them off when you are asking where the shift went**, because a number that excludes the lunch hour and the dead sensor no longer adds up to the length of the shift. See [Choose what the number includes](/docs/monitoring/advanced-report/#switches). ## Numbers changed retroactively A figure you read yesterday can legitimately read differently today. Four edits rewrite history, and none of them marks the record. | Edit | What moves | Where it is done | |---|---|---| | Backfilling a count | Production counts, the parts gauge and FPY for that window, permanently. See [Production counts and backfilling](/docs/monitoring/asset-detail/#backfill) | **Modify Counts** on the machine page | | Deleting the last N hours of data | Uptime, downtime and every count for that window, with no undo. See [Delete the last N hours of data](/docs/monitoring/edit-assets/#delete-data) | **Delete Data** on the Assets page, Owner or Administrator | | Changing the uptime filter or the short-stop cutoff | Uptime and downtime for stops older than about 30 minutes, because both settings reach back rather than applying only to new data | The machine's calibration panel | | Deleting or splitting an activity | The shape of the timeline for that stretch. See [Delete an activity](/docs/monitoring/classify-downtime/#delete) | The activity list on the machine page | Three things that look retroactive and are not: - **Classifying a stop.** A reason code changes what the Downtimes report can say about the time, not how much of it there is. - **Turning on an auto-classification rule.** Rules act on stops recorded after they are enabled and never reclassify the backlog. See [What the rules do not do](/docs/monitoring/auto-downtime-rules/#limits). - **Changing momentum or a threshold.** Neither re-scores data already captured, so the old values' states stand until new data arrives. A live window also moves on its own. A shift in progress recalculates every minute, so a figure read at 10 AM and quoted at 2 PM will not match. Select a completed shift or a past date to freeze it, see [Choose the window](/docs/monitoring/assets-overview/#window). ## Still stuck **Something went wrong** and **An error occurred** are the platform's generic failures. Either means the request did not complete and nothing was saved, so the setting still holds its old value however the form looks. Retry it, then reopen the panel and read the value back before assuming the change took. Two symptoms belong elsewhere. A machine missing from a report rather than reading wrong is usually a filter or an access grant, see [When a machine is missing](/docs/monitoring/assets-overview/#missing). A single silent device is a connection problem, see [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). Otherwise, [contact support](/docs/get-started/get-support/) with the machine, the exact window, the number you expected and the number you saw. The window matters more than the machine: most reports of a wrong figure turn out to be two people reading two different windows. ## See also - [Shifts and timezone](/docs/admin/shifts-and-timezone/) - [Calibrate SenseAi](/docs/hardware/calibrate-senseai/) - [How each metric is calculated](/docs/monitoring/metrics-reference/) - [Classify downtime automatically](/docs/monitoring/auto-downtime-rules/) - [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/) --- # Display a wallboard on a TV Source: https://www.iotflows.com/docs/monitoring/wallboards/ Put a live fleet view on a shop-floor screen: expand the Assets page to full screen, install the IoTFlows app on a Chromecast with Google TV, pair it with the code it displays, send it any dashboard URL from the Send URL Link modal, set its zoom, and rename or delete screens. Paired screens reload their URL on boot. # Display a wallboard on a TV Put a live fleet view on a shop-floor screen and keep it there. A *wallboard* is a dashboard view shown full screen on a display nobody is sitting at. There are two ways to run one: expand a view in any browser, or send a view to a *paired screen*, a TV running the IoTFlows app that reloads its URL on its own after a reboot. **Prerequisites.** Sign in as an Organization Owner or Administrator, see [Roles reference](/docs/admin/roles-reference/). For a paired screen, a Chromecast with Google TV or another Google TV device, see [Set up a Chromecast](#chromecast). **You do not need a paired screen to try this.** Full-screen mode in any browser is the same view. Choose a paired screen when the display must survive a power cut unattended: it reloads its URL on boot, while a browser tab opened by hand comes back to a sign-in page. ## Enter full-screen wallboard mode 1. Open **Assets** on the **Overview** tab, see [Monitor your fleet](/docs/monitoring/assets-overview/). 2. Set the filters, grouping and view mode the board should show. 3. Click the **expand** icon, the diagonal arrows at the right of the filter row. The cards fill the window and the address bar gains `?maximize=isExpanded`. The **X** at the top right returns to the normal page. A bookmark of that address opens straight into the board. ![The Assets overview expanded to fill the browser window, with about twelve machine cards in a grid showing green Running and red stopped states, the filter buttons in a strip along the top and a close X at the top right](/images/monitoring/mon-wall-01.webp) *Full-screen wallboard mode. The same fleet view with the chrome removed.* ## Pair a screen A *screen code* is the number the IoTFlows TV app shows while it is not yet tied to an organization. Entering it in the dashboard ties the screen to yours. 1. Click the **TV** icon at the top right of the header. The **Send URL Link** modal opens. 2. Under **Select Screen**, click **Add Screen**. 3. Type the number the screen is displaying into **Screen code** and click **Submit code**. The toast reads "Screen has been added". 4. Type a name a colleague would recognize, for example `Press bay east`, into **Screen name** and click **Submit Name**. The toast reads "Screen name added". The screen stays paired until you delete it. Its header shows a live clock where the search box would be, which is how you tell a paired screen from a signed-in laptop. ![The Send URL Link modal with the Add Screen form open under two paired screens, a numbered callout on the Screen code field holding the six-digit number 482913, and the Submit code button beside a Cancel button](/images/monitoring/mon-wall-02.webp) *Pairing a TV by screen code. Codes expire; generate a new one if it is rejected.* ## Send a view to a paired screen The modal sends one URL to one screen, and it opens with the address of the page you are on. 1. Arrange the view, expanded so the URL carries `maximize=isExpanded`. 2. Click the **TV** icon. **Url link** is prefilled with the current address; edit it to send a different page. 3. Under **Select Screen**, click the screen's row so it highlights. 4. Click **Send Link**. The toast reads "Link has been sent" and the screen navigates to that URL. Any dashboard URL works. For example, send `/assets?select=canvas` for the floor plan in [Map your floor with Canvas](/docs/monitoring/canvas/), or the board from [Shift production](/docs/production/shift-production/). The screen updates live, like your own browser. ![The Send URL Link modal with the Url link field holding an assets address ending in maximize=isExpanded, a TV Zoom field reading 1, two screens named Main floor screen and Press bay east listed under Select Screen with the first highlighted, and the Send Link button highlighted at the bottom right](/images/monitoring/mon-wall-03.webp) *Sending the current view to a paired screen.* ## Set the zoom level **TV Zoom** scales the page on the screen: `1` is the size in your browser, `2` is double, `0.5` is half. A value outside `0.5` to `2` snaps to the limit when you leave the field. Zoom travels with the link, so change it and click **Send Link** again. Start at `1.5` and go up until the smallest number on a card is readable from where operators stand. ![A cropped detail of the Send URL Link modal showing the TV Zoom label above a small number field reading 1.5](/images/monitoring/mon-wall-04.webp) *The TV Zoom field. Send the link again after changing it; zoom travels with the URL.* ## Rename or remove a screen Both actions sit on the screen's row in the **Send URL Link** modal. - To rename, click the **pencil**, type the new name and click **Save**. The toast reads "Screen name changed". - To remove, click the **trash**, then click **Delete** on the confirmation. The toast reads "Screen deleted". Deleting a screen unpairs it. The display keeps showing what it last loaded until it restarts. There is no undo: pair it again by code if you deleted the wrong one. ## Screen settings | Field | What it does | Default | Notes | |---|---|---|---| | **Url link** | The page the screen navigates to | The page you opened the modal from | Include `?maximize=isExpanded` for a full-screen board | | **TV Zoom** | Scales the page on the screen | `1` | `0.5` to `2` | | **Screen code** | The number an unpaired screen displays | Empty | Digits only. Codes expire | | **Screen name** | The label in the **Select Screen** list | Empty | Changed with the pencil | ## Set up a Chromecast A paired screen is a Chromecast with Google TV, or any Google TV device, running the IoTFlows TV app. You do not cast from your own browser or phone: the app loads the dashboard itself and shows a screen code until it is paired. 1. Plug the Chromecast into the TV and finish Google's own setup, including Wi-Fi. 2. Open the Play Store on the TV and install [IoTFlows](https://play.google.com/store/apps/details?id=com.iotflows.iotflows_google_tv_app), the app whose listing reads "TV app to display screens from IoTFlows dashboard". 3. Open the app. It shows the screen code. 4. Pair it from the dashboard, see [Pair a screen](#pairing). The app relaunches itself after a reboot or a Play Store update, which is what keeps the board up unattended. ## Choosing what to display A board is read from 20 ft (6 m) away in a glance, so send less than you would look at yourself. Filter to one department or tag, and pick the view mode whose numbers matter to the people under the screen, see [Choose a view mode](/docs/monitoring/assets-overview/#views). Choose the Assets overview when the floor thinks in machine names, Canvas when it thinks in position, and the shift board when the question is "are we on pace". ![A wall-mounted TV showing the Assets overview in full-screen mode, sixteen machine cards grouped by department in green and red](/images/monitoring/mon-wall-05.webp) *A wallboard on a shop-floor TV. Paired screens reload their URL on boot, so they come back after a power cut.* ## Errors | What you see | Cause | Fix | |---|---|---| | A screen code is rejected | Codes expire | Submit the code the screen is showing now | | Stale numbers or a sign-in page | The screen lost its network or session | Check its connection, then send the link again | ## See also - [Map your floor with Canvas](/docs/monitoring/canvas/) - [Monitor your fleet on the Assets page](/docs/monitoring/assets-overview/) - [Shift production](/docs/production/shift-production/) - [Set up a dedicated operator station](/docs/monitoring/operator-stations/) --- # Detect operations automatically Source: https://www.iotflows.com/docs/production/auto-detect-operations/ Auto-detection is the setting that tells a machine which operations to watch for, so counts reach the right part without anyone touching the dashboard at a changeover. Every entry point is on the machine, not the Parts List: the Auto-Detect button on a machine's detail page, and the operation block on an Assets list row. A SenseAi shows Discrete and Continuous tabs, a BeamTracker shows Count. Discrete takes checkboxes and submits with Auto-Detect; Continuous and Count take one operation and save the moment you pick. An operation with no detection algorithm never appears in the list. Once the machine runs, its Assets row reports the measured cycle time and production rate. # Detect operations automatically Let a machine work out which operation it is running, instead of telling it at every changeover. *Auto-detection* is the setting that lists the operations a machine should watch for. IoTFlows matches the sensor's signal against that list and files each cycle it recognizes under one of the operations on it. A machine with nothing assigned still reports uptime and downtime, and its parts column stays empty. Every entry point into auto-detection is on the machine. This page covers all of them, plus the one shortcut that sets a whole line in a single action. **Before you start** - A part with at least one operation, and a detection algorithm on that operation. See [Create parts and operations](/docs/production/parts-and-operations/). - The machine has to run the operation while it is assigned. Nothing is detected from an idle machine. > **Note:** > **Looking for this on the Parts List?** It is not there. The Parts List defines what an operation *is*: its algorithm, its ideal cycle time, its quantity per cycle. Assigning an operation to the machine that runs it happens on the machine, through the modal below. ## When auto-detection helps Assign operations when: - The machine runs parts you can name in advance. Assign every discrete operation it runs, in one pass, and leave them assigned. - Counts have to survive a changeover with nobody at a keyboard. - You entered an ideal cycle time you are not confident in, and want a measured figure to check it against. **You do not need auto-detection to see whether a machine is running.** Uptime, downtime and OEE come from the sensor alone, see [How each metric is calculated](/docs/monitoring/metrics-reference/). Auto-detection is what turns that running signal into a part count, a production rate, and a shift goal. ## Start from a machine's detail page This is the path the rest of the production docs use, and the one to take when you are setting up a single machine. 1. Open **Assets** and select the machine, for example `HAAS VF-2`. The address is `/assets/selected-asset/:id`. 2. Select **Auto-Detect** in the control bar. **Select Auto-Detect Operations** opens. On a phone the same control is an icon in the page header rather than a labeled button. Both open the same modal. ![The Assets / HAAS VF-2 breadcrumb above the control bar of the machine's detail page, with a violet highlight around the blue Auto-Detect button at the bar's right end, beside the notifications bell and the actions menu, and the shift filter at its left end](/images/production/prod-auto-01.webp) *The Auto-Detect button in the control bar of a machine's detail page, which opens Select Auto-Detect Operations.* ## Start from the Assets page The Assets page opens the same modal without leaving the fleet view, which is the faster path when you are setting several machines in a row. 1. Open **Assets** at `/assets` and switch to list view. 2. Find the machine's row. The block in the middle names the operation it is detecting now, its part, and its count. 3. Select that block. Its tooltip reads **Switch operation**. A machine with nothing assigned carries a **Set operation** button in the same place. Cascading group cards carry the block as well, so a line drawn as a cascade can be switched machine by machine from the card. Plain cards outside a cascade have no entry point, so use list view or the machine's detail page. ![One row of the Assets list view for HAAS VF-2, with a violet highlight around the operation block in the middle of the row. The one clickable block holds the part photo, the operation name OP10, the part name BH-4021, Count 10, a refresh icon, and on its right-hand side a cycle time of 00:04:30 and a production rate of 0.2 ops/min](/images/production/prod-auto-02.webp) *The second entry point: the operation block on an Assets list row, whose tooltip reads Switch operation.* ## Choose the part and operations The modal lists every operation in the organization that the machine's device can detect, each row naming the operation and the part it belongs to. The device decides the tabs: - A **SenseAi** or **SenseAi Embedded** shows **Discrete** and **Continuous**. - A **BeamTracker** shows **Count** and nothing else. To find an operation in a long list, type into the search box at the top. It searches part name, operation name and description, and the server does the filtering, so an operation you have not searched for may not be in the list. **On the Discrete tab, check every operation the machine runs, then select Auto-Detect.** The tab takes checkboxes, so one pass covers every part on the machine. IoTFlows confirms with **Discrete Auto-classification Set** and closes the modal. **On the Continuous and Count tabs, select one operation.** Both are radio buttons. They save the moment you select, confirm with **Continuous Auto-Classification Set** or **Count Auto-Classification Set**, and close. Neither has a submit button, only **Close**. To stop a continuous machine detecting without choosing another operation, select **No Continuous Detection** at the top of the list. The **Count** tab carries no equivalent row. The two tabs are exclusive, and each says so above its list. Selecting discrete operations clears the machine's continuous operation, and selecting a continuous operation clears every discrete one. ![The Select Auto-Detect Operations modal on the Discrete tab, with BH-4021 typed into the search box above and an amber line warning that selecting Discrete operations disables any Continuous operation. The search has narrowed the list to that part's two operations, and both checkbox rows are checked, OP10 - Rough mill and OP20 - Finish, marked with callouts 1 and 2. Add/Edit Parts sits in the header and Close and Auto-Detect in the footer](/images/production/prod-auto-03.webp) *Choosing which part and operations to detect. The Discrete tab takes checkboxes, so one pass assigns every operation the machine runs.* ## Choose the detection algorithm The algorithm is a field on the operation, not on the machine, and it decides which tab the operation appears under: the two discrete algorithms put it on **Discrete**, Continuous Analysis on **Continuous**, and Counter on **Count**. Which one to pick is on [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/#choose). **An operation with no algorithm never appears in this modal.** The modal states it outright: "Operations without a detection algorithm will not appear in the auto-detect selection list." So does the device mismatch. A SenseAi will not show a Counter operation, and a BeamTracker will not show a discrete or continuous one. If the operation you want is missing, fix it without leaving the modal: 1. Select **Add/Edit Parts** in the header. The modal becomes **Add/Edit Parts & Operations**. 2. Search for the part, or type a new name and select **Create "*name*"**. 3. Select the part, type a name under **New Operation**, then select **Add**. 4. Expand **More details (optional)** and set **Detection Algorithm**. Set **Qty per Cycle** and **Cycle Time (sec)** here too if you know them. Unlike the Parts List, cycle time here is one plain number in seconds. 5. Select **Done — Back to Operations**. The list reloads and the new operation is in it. Use the pencil beside an existing operation to change the same three fields on it. ## Review the detected cycle time Let the machine run the operation, then open its row on the Assets page. Beside the operation block it reports two figures: - **Cycle time**, the *detected cycle time*: the running time between counted parts, measured from the detection events themselves. - **Production rate**, the same number inverted, in the operation's unit per minute. Neither is the number you typed. The ideal cycle time on the operation is a target, and this is what the machine actually did. Comparing the two is the quickest check that the algorithm and the assignment are both right. For example, a machining center set to a 90 second ideal that reports a detected 92 seconds is working. One that reports 8 seconds is counting something that is not a part. **Read the detected figure only over a window that ran one part mix.** If the machine changed over inside the window, the detector averages two parts into a single number that describes neither, and the fix is a stopwatch on the part you care about, not a different setting. ![The right half of an Assets list row, showing a shift count of 10 made, then the operation OP10 on part BH-4021 with Count 10, and beside it two stacked figures: 00:04:30 labeled Cycle time, and 0.2 ops/min labeled Production rate, with a violet arrow pointing up at the cycle time](/images/production/prod-auto-04.webp) *The measured cycle time and production rate on an Assets list row, after the machine has run the operation. An implausible figure means the machine ran something else during the window.* ## Accept or adjust Nothing has to be accepted. The assignment is already live and the detected cycle time is a reading, not a proposal. What you do next depends on what the reading says. | What the detected cycle time says | What it means | What to change | |---|---|---| | Close to the ideal cycle time you entered | The algorithm and the assignment are both right | Nothing | | Roughly half or double the ideal | The signal is being merged or split wrongly | Switch the operation's algorithm, see [Switch to a different algorithm](/docs/production/choose-an-algorithm/#switch) | | Plausible, but the ideal is a long way off | The ideal cycle time was a guess | Re-time the cycle and correct it, see [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/) | | Nothing at all, after the machine has run | No operation is assigned, or the wrong one is | Reopen the modal and check the selection | | Implausible on every reading | The machine is running something other than the assigned operation | Assign the operations it actually runs, or cut the window to one part | Counts that are still wrong after that are on [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/). ## Set a whole cascade in one action Machines grouped into a cascade get a group-level shortcut. **Set Part** in the group header picks one part, pre-fills each machine with the part's operation matching its step number, and applies the lot in one request per machine. It writes exactly the same setting as **Switch operation** on a single card. The procedure, its **Don't change** option, and what a half-successful run looks like are on [Group machines into cascades](/docs/monitoring/asset-groups/#cascade-part). The shortcut is the only part of auto-detection that is role gated: **Set Part** is disabled unless you sign in as an Organization Owner or Organization Administrator, see [Roles reference](/docs/admin/roles-reference/). ## Auto-detect fields | Field | Required | Effect | |---|---|---| | Search | No | Filters the list by part name, operation name or description. The server filters, so an operation you have not searched for may not be listed | | **Discrete** checkboxes | On a SenseAi running discrete operations | Check every operation the machine runs. Nothing is saved until you select **Auto-Detect** | | **Continuous** radio | On a SenseAi running a continuous operation | Saves the moment you select it, then closes the modal | | **No Continuous Detection** | No | The first row of the **Continuous** tab. Clears the machine's continuous operation and leaves it detecting nothing | | **Count** radio | On a BeamTracker | The only tab a BeamTracker shows. Saves on selection, like **Continuous** | | **Auto-Detect** | On the **Discrete** tab | Submits the whole checked set as the machine's operations. The other two tabs have no submit button | | **Add/Edit Parts** | No | Opens **Add/Edit Parts & Operations** inside the same modal, for creating or correcting the operation you are missing | ## See also - [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/) - [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/) - [Group machines into cascades](/docs/monitoring/asset-groups/#cascade-part) - [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/) - [Create parts and operations](/docs/production/parts-and-operations/) --- # Link required and created parts to an operation Source: https://www.iotflows.com/docs/production/bind-materials/ Every operation row in the Parts List at /production?select=parts_list ends in two cells: what a run of the operation takes off the shelf, and what it puts back. A binding is a rule, not a transaction. It says how much of an item a given amount of work turns into, so a work order raised against the operation stages its own materials at its own quantity. Closing that work order is what moves stock, and the created side is what the scheduler's capacity lane projects output from. Editing the bindings needs Organization Owner or Administrator; every other member sees the same list read-only. # Link required and created parts to an operation Tell IoTFlows what an operation consumes and what it produces. Every operation in the Parts List has two ends. One lists what a run of it takes off the shelf, the other lists what it leaves behind. Fill them in and a work order raised against that operation arrives with its own materials already worked out, the ledger records the movement when the job closes, and the scheduler can forecast what the week will produce. **Before you start** - Sign in as an Organization Owner or Organization Administrator. This editor is the only role-gated edit surface on the Parts List: every other member can open it and read it, but not change it. See [Roles and permissions](/docs/admin/roles-reference/). - Create the items in Inventory first. There is no create-an-item path from this editor, and an item it cannot find cannot be bound. See [Create and edit items](/docs/inventory/manage-items/). - A part carrying at least one operation. See [Add an operation](/docs/production/parts-and-operations/#operation). ## What binding does A *required part* is an item that one run of the operation consumes or holds: the tube of sealant, the four bolts, the torque wrench. A *created part* is what the operation leaves behind: the machined housing it produces, or a tool it hands back to the shelf. Neither one moves stock by itself. **A binding is a rule, not a transaction.** It states how an item scales with the work, so that anything downstream can do its own arithmetic: one tube per 50 pieces, four bolts every time, one screwdriver however big the job is. The rule reaches the floor in three steps. You bind the item here, on the operation, and a work order raised against that operation copies the rule onto itself, scaled to the quantity ordered. Closing the work order is what consumes, produces, and writes the ledger rows. One of those four items is not consumed at all. A *reusable tool* is an ordinary inventory item carrying the reusable-tool flag, so it needs no separate list here, and it wears a **Tool** chip wherever it appears. Binding it is how you say the operation holds it, or hands it back. See [Create and edit items](/docs/inventory/manage-items/). ### Binding types | Binding | Means | On completion | Also feeds | |---|---|---|---| | **Required**, ordinary item | One run takes this much off the shelf | Stock out, against the job | The work order's **Parts Required** list, and the reservation that holds the stock from the moment the job is raised | | **Required**, reusable tool | The operation holds the tool while it runs | The tool leaves the shelf into the job's custody | The scheduler's tooling lane, where the same tool booked on overlapping jobs reads as a conflict | | **Created**, ordinary item | One run produces this much | Stock in, credited to the job | The work order's **Create/Release Parts** list, and the scheduler's projected-output rows | | **Created**, reusable tool | The operation hands the tool back | The tool returns to its shelf | The tooling lane, where this is what ends a hold an earlier operation opened | **Bind materials only for items you actually count in Inventory.** Binding a consumable nobody stocks produces transactions nobody reconciles, and a ledger that carries movements nobody checks stops being worth reading. If shop rags and cutting fluid are not in your catalog, leave them out of this editor. ## Add a required part 1. Open **Production**, then the **Parts List** tab at `/production?select=parts_list`. 2. Find the part, and the operation's row inside it. 3. Click the package icon at the end of that row, tooltipped **Assign the tools, materials and parts this operation needs**. The **Required for** editor opens, and with nothing bound yet it opens its item picker for you. 4. Search the item by name or SKU. The picker searches the whole catalog on the server, and its **All**, **Purchased**, **Manufactured** and **Tools** tabs narrow the list. Each row shows what is available. 5. Click the item. The line is created immediately, with no Save button. 6. Set the **Amount**. Type how much of the item in the first box, then how many of the operation that covers in the second. `1` `tube` per `50` `ops` reads back under the item name as *50 ops needs 1 tube*. The number commits when you leave the box or press Enter. 7. Set **Preferred location** to the shelf this is normally pulled from. 8. Leave **Round up** ticked for anything that cannot be half taken. 9. Click **Done**. ![The Required for OP30 Tap editor, headed MS-7420 Manifold, open over the Parts List, with column headers reading Item, Preferred location, Depends on operation, Amount and Round up. One line holds an item named TS-560 Thread Sealant, and the line under its name reads 50 ops needs 1 tube. Its preferred location is Warehouse > Shelf 2, the Depends on operation toggle is on and boxed in violet, and the Amount column, also boxed, holds two number boxes reading 1 tube per 50 ops](/images/production/prod-bind-01.webp) *The Required for editor on one operation. The amount reads as a sentence under the item name: 50 ops needs 1 tube.* The second number is counted in the operation's own unit, which defaults to `ops`. See [Unit and quantity per cycle](/docs/production/parts-and-operations/#units). **Turn Depends on operation off for anything the run holds rather than takes.** A screwdriver is one screwdriver whether the order is 10 parts or 10,000, so a fixed line drops its second box and reads *1 ea however much is run*. Turning it back on starts again at one per operation rather than reviving whatever the line held before. **Round up** is a property of the item, not of the arithmetic. A tube cannot be half taken, so 401 pieces at one tube per 50 needs nine tubes, while 2.5 kg of resin has no such floor. The box is ticked for you when the item's unit counts whole things, cleared when it does not, and left empty on a fixed line, which divides by nothing. **Preferred location** decides which shelf a job starts from, and setting it here is the only way to make that answer stable. A line with no shelf sends the job to the fullest one holding that item at the time it is raised; a line whose shelf cannot be resolved at all reaches the planner flagged, then is dropped from the order if they submit without placing it. IoTFlows resolves shelves for at most 25 distinct unplaced items per operation, and the rest stage without one. An item stocked as [serialized pieces](/docs/inventory/serialized-pieces/) cannot be bound as itself, because the parent holds no stock. The picker lists its pieces instead, grouped under the parent's name. ## Add a created part The creates side is the same editor under a different name. Open it from the second icon at the end of the operation row, tooltipped **Assign what this operation makes, or the tool it releases**, and the **Created by** editor opens the same way. 1. Search and click the item this operation produces. 2. Set the **Amount** the same way. On this side the sentence reads *1 ops makes 1 housing*, or *50 ops releases 1 fixture* when the item is a reusable tool. 3. Click **Done**. Bind the release of a tool to the operation that hands it back, not to the one that took it. A fixture taken at OP10 and listed on the creates side of OP30 is a fixture that comes back when OP30 closes, and that is the only thing that ends the hold. Once both sides carry something, the two cells at the end of the row stop being bare icons and become chips: the first item's name and its rule, compressed to `x1/50`, or the first name and `+2` when more than one item is bound. ![The Requires and Creates columns of the MS-7420 Manifold routing, cropped out of the Parts List. The two rows above hold bare package icons; on the bottom row the left cell holds a rounded chip with a package icon reading TS-560 Thread Sealant x1/50, and the right cell a chip with a package-plus icon reading MS-7420 Manifold x1/1](/images/production/prod-bind-02.webp) *The end of an operation row once both sides are bound. The left chip is what the operation needs, the right is what it makes.* **Bind created parts even if your stockroom does not track finished goods.** It costs one line per operation, and it is the only thing that turns the scheduler's capacity lane into an output forecast. Nothing else on the board infers output. ## Remove a binding 1. Open the editor from the row, on the side the item is bound to. 2. Click the trash icon at the end of the line. The row turns into **Remove _item_ from this operation?** 3. Click **Remove**, or the X to keep it. Removing a binding changes the rule and nothing else. Work orders already raised against the operation carry their own copies of the lines and keep them, so a rule deleted today does not disturb a job that started yesterday. Fix those on the work order itself. ## What happens when the work order closes Closing the work order is where stock actually moves, and IoTFlows performs the movement server-side. It consumes the required lines, produces the created ones, writes the inventory transactions, and clears the reservation. Nothing you do in this editor writes a transaction. Two things happen before that. A required line **reserves** its stock as soon as the job is raised, so what is available to other jobs drops immediately even though nothing has been consumed. And the completion dialog states both directions of the movement before it happens, read-only: what will be consumed, what will be produced, and at which locations. That dialog reports the consequence rather than negotiating it. A quantity that turned out wrong is corrected in the work order's **Parts Required** and **Create/Release Parts** sections, not there. The full model, including which transaction type each movement lands as in the ledger, is on [How work orders move stock](/docs/inventory/how-work-orders-move-stock/) and [Transaction types](/docs/inventory/transaction-types/). The procedure for closing a job is on [Update, discuss, and close a work order](/docs/maintain/work-order-detail/). ## What created parts show you on the scheduler The Gantt's capacity lane draws a projected-output row per part, and it reads those rows out of each work order's **Create/Release Parts** lines. Those lines are the ones your binding staged when the job was raised, which is why filling in the created side pays off on a screen you never opened. Output is declared, never inferred. There is no fallback that guesses what a routing produces from its shape, so a part no work order declares gets no row, and a board where nothing declares anything gets no projected-output section at all. A part with a routing but no declared output still appears, under a header reading **No output declared** that names Create/Release Parts as the fix. Once Inventory has stock levels for the parts on the board, the row becomes a projected balance rather than a cumulative total. It opens at what is on the shelf, climbs on created lines and falls on required lines, and a curve crossing below zero is a shortage the schedule is heading for. Two lines never move that curve. A reusable tool is skipped on both sides, because a tool handed back is not output. A completed work order contributes no climb either, since its movement is already inside the opening count. See [Plan jobs in the Production Scheduler](/docs/production/scheduler/). ## When a change does not save Every write in this editor is immediate, and a failure raises the server's own message when it sends one. When it does not, the dashboard falls back to a short string that names what failed: **Could not load this operation's items** when the list will not open, **Could not add this item**, **Could not save this change**, or **Could not remove this item**. The line goes back to the value the server holds, so a control that appears to snap back is a rejected write rather than a broken switch. Two failures carry their own meaning. An item you cannot find in the picker does not exist in Inventory yet, and has to be created there first. An amount of `0` or a negative number in either box is refused with no message at all: the old number returns, because a rule requiring none of something it lists derives nothing. ## See also - [How work orders move stock](/docs/inventory/how-work-orders-move-stock/) - [Plan jobs in the Production Scheduler](/docs/production/scheduler/) - [Update, discuss, and close a work order](/docs/maintain/work-order-detail/) - [Create parts and operations](/docs/production/parts-and-operations/) - [Create and edit items](/docs/inventory/manage-items/) --- # Choose a production tracking algorithm Source: https://www.iotflows.com/docs/production/choose-an-algorithm/ The detection algorithm on an operation is the rule that turns a sensor's signal into part counts. BeamTracker takes Counter and nothing else. A SenseAi machine takes Continuous Analysis when the trace never returns to the stopped level, Discrete Analysis when each part is one burst with idle time around it, and Discrete w/o Merge when every impact is a part. Compare all four, validate against a hand count over ten parts, and switch without losing the operations already assigned to a machine. # Choose a production tracking algorithm Pick the rule that turns a machine's signal into part counts. A *detection algorithm* is the rule IoTFlows applies to a sensor's signal to decide that one cycle has finished. Every operation carries exactly one, chosen in the Parts List. It decides the part count and the measured [cycle time](/docs/monitoring/metrics-reference/#cycle-time), which makes it the most common reason a number on the screen disagrees with the number on the floor. There are four. The device on the machine decides which ones you can pick. The shape of the signal decides which one you should. **Before you start** - Sign in as an Organization Owner or Organization Administrator. See [Roles reference](/docs/admin/roles-reference/). - Create the part and at least one operation. The algorithm is a field on the operation, not on the machine. See [Create parts and operations](/docs/production/parts-and-operations/). ## Choose in one question Start with the device, because it removes most of the choice. - **BeamTracker** takes **Counter** and nothing else: it counts units passing a point rather than deriving counts from a machine's own cycle. - **SenseAi and SenseAi Embedded** take one of the three analysis algorithms. Counter is not offered for them. For a SenseAi machine, one question decides it. **Does the signal fall back to the stopped level between parts?** - **No, the machine runs steadily and the trace stays up** → **Continuous Analysis**. For example, an injection molder that holds pressure through the cycle. - **Yes, and each part is one burst with quiet either side** → **Discrete Analysis**. For example, a CNC mill that sits idle while the operator unloads and reloads. - **Yes, and each part is one sharp impact you want counted on its own** → **Discrete w/o Merge**. For example, a press where every stroke is a part. **When the answer is not obvious, start with Discrete Analysis.** It adapts to cycle-time variation instead of assuming a fixed cycle, which makes it the least wrong choice on a machine nobody has measured. **You do not need to revisit this on a machine whose counts already validate.** Switching to chase one bad shift replaces a right number with a wrong one. ## How each algorithm reads the signal The four differ in what they treat as the end of a cycle, not in how hard they look. Diagram: Four rows, one per detection algorithm, each drawing the signal the sensor reports and marking every point that becomes a count. Counter, labeled BeamTracker only, is a line that sits high while the beam is clear and dips each time a part passes; each of its five dips is one count. Continuous Analysis is one long unbroken running block divided into six equal time slices, because it divides running time by the cycle time rather than reading the shape of the trace. Discrete Analysis and Discrete w/o Merge are drawn on the same irregular trace of three bursts, where the middle burst carries a short dip in it. Discrete Analysis marks three counts, merging that dip back into one burst. Discrete w/o Merge marks four on the identical trace, because it reads the dip as the end of one cycle and the start of another. *The four algorithms drawn as the signal each one reads, with the point it counts marked.* Note the bottom two rows. They are the same trace drawn twice, and the counts differ by one. Discrete Analysis reads the dip in the middle burst as noise inside one cycle and merges it. Discrete w/o Merge reads it as the end of one cycle and the start of the next. That is why a machine that rings twice per part counts double under one and correctly under the other. ## Compare the four algorithms | Algorithm | Detects | Best for | Cycle time needed | Typical failure | |---|---|---|---|---| | **Counter** | Each break of the beam | Any BeamTracker. Counting units as they pass a point | Ideal only, for goals | Parts pass without breaking the beam, so nothing is counted | | **Continuous Analysis** | Running time, divided by the cycle time | Machines that hold a steady, predictable cycle | Measured and accurate. It is the divisor | The entered cycle time drifts from the real one, and the count drifts with it | | **Discrete Analysis** | One cycle per burst, short dips merged back in | Machines with variable cycles and clear idle time between parts | Ideal only, for goals | Two fast parts merge into one burst and the count comes in low | | **Discrete w/o Merge** | Every burst, with nothing merged | Machines whose every impact is one part | Ideal only, for goals | One part rings more than once and the count comes in double or worse | *Ideal cycle time* is the target you enter on the operation. Where the table says "ideal only, for goals", the algorithm counts without reading it, and the number drives the shift goal and the parts gauge instead. See [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/) and [Cycle time](/docs/monitoring/metrics-reference/#cycle-time). ## Counter Counter takes each break of the BeamTracker beam as one cycle, multiplied by the operation's [quantity per cycle](/docs/production/cycle-times-and-filters/). There is no pattern analysis and nothing to tune in the algorithm itself. What it needs is a device that sees the parts, which is a calibration job rather than an algorithm one. See [Set what counts as a part](/docs/hardware/calibrate-beamtracker/#beam-values). Short gaps between parts are handled on the device too, by the BeamTracker **Downtime Filter**, which holds the machine as running when parts pass less than that far apart. See [Set the downtime filter](/docs/hardware/calibrate-beamtracker/#downtime-filter). Counter end to end on a line, from the count point to the validated count, is on [Configure tracking for bottling and packaging lines](/docs/production/packaging-lines/). ## Continuous Analysis Continuous Analysis divides running time by the cycle time. It never looks at the shape of the trace, which is what makes it right for a machine that never returns to the stopped level and wrong for one that does. The cycle time you enter is the divisor, not a target, so its accuracy is the accuracy of the count. Measure it over 10 to 20 cycles rather than taking it off a quote or a router. This is the only algorithm that shows a **Downtime Filter** percentage on the operation row. The filter converts any stop shorter than that percentage of the cycle time into [uptime](/docs/monitoring/metrics-reference/#uptime), so brief in-cycle pauses stop reading as downtime. The field accepts 0 to 200% and clamps anything higher; set it on [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/). ## Discrete Analysis Discrete Analysis detects individual cycles from the vibration pattern and merges short pauses back into the cycle they interrupted. It counts the events it detects rather than dividing by a number, so it tolerates parts that take 1:50 and parts that take 2:10 on the same machine. Enter a cycle time anyway. The algorithm does not read it to count, but the shift goal and the parts gauge do. ## Discrete w/o Merge Discrete w/o Merge counts every burst it detects and merges nothing. It is for a machine whose events are the parts, where merging would combine two strokes into one. Because nothing is merged, short stops between strokes reach the downtime record as hundreds of one-minute rows unless the machine absorbs them first. Set **Downtime Threshold** with **Treat short downtimes as uptime** switched on, so stops under the cutoff become runtime. See [Handle short stops](/docs/hardware/calibrate-senseai/#short-stops). > **Warning:** > **Counting twice as many parts as you make?** On this algorithm that is one part ringing more than once, not a sensor fault. Move to Discrete Analysis, which merges the second ring back into the cycle. See [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/). ## Set the algorithm on an operation 1. Open **Parts List** at `/production?select=parts_list`. 2. Expand the part to show its operations. 3. Click the algorithm pill in the operation's row, or **Select Algorithm** if it has none yet. 4. Hover an option to read what it detects, then click it. The change saves as soon as you pick it. There is no separate save. ## Validate your choice Validate against a hand count, never against a total that looks about right. 1. Let the machine run normally for one to two hours, or one full shift. 2. Open **Shift Production** at `/production?select=part` and read the count for that operation. 3. Compare it with a hand count, the machine's own counter, or the count implied by the runtime and the cycle time. 4. Open **Downtimes** at `/assets?select=downtimes` and check that real stops are there and brief pauses are not filling the list. 5. Calculate accuracy as the IoTFlows count divided by the actual count, times 100. Read the result against these bands: | Accuracy | Verdict | What to do | |---|---|---| | 95 to 105% | Good | Nothing | | 90 to 95%, or 105 to 110% | Acceptable | Tune the cycle time or the downtime filter | | Below 90%, or above 110% | Wrong | The algorithm is a misfit, or the cycle time is badly off | **Validate with ten parts, not one shift.** A count that is right ten times in a row is right. A shift total that happens to land near the truth is a coincidence you pay for later. ## Switch to a different algorithm Switch when the count fails validation the same way repeatedly, not after one bad day. | Symptom | Move from | Move to | |---|---|---| | Count runs 10 to 20% high, and real cycle times vary by more than 20% | Continuous Analysis | Discrete Analysis | | Count runs low on a machine that runs very consistently | Discrete Analysis | Continuous Analysis | | Strokes are missed on a machine firing events close together | Discrete Analysis | Discrete w/o Merge | | Count is two or three times the real output | Discrete w/o Merge | Continuous Analysis | Changing the algorithm can collide with machines that already run other operations on that part. When it does, a **Confirm Algorithm Change** dialog lists every machine affected and explains the conflict. Confirming removes those other operations from the machines listed, so read the list before you click **Confirm**. Revalidate after every switch. The counts either side of the change come from different rules, so they are not comparable. ## Common mistakes **Continuous Analysis on a machine with variable cycles.** Parts take 30, 45 and 60 seconds and the operation is set to the 45-second average. Short cycles are overcounted and long ones undercounted, so the total is wrong even though the average is right. Use Discrete Analysis. **Discrete w/o Merge with no short-stop handling.** Every gap between strokes lands in the downtime record, and the report fills with one-minute stops nobody can classify. Set the machine's short-stop cutoff first, in [Handle short stops](/docs/hardware/calibrate-senseai/#short-stops). **Trusting a configuration nobody checked.** The count looks plausible for weeks, and by the time someone compares it with a hand count the history is already wrong. **Quantity per cycle left at 1 on a multi-cavity mold.** A four-cavity mold set to 1 reports a quarter of its real output, and no algorithm change fixes it. Set quantity per cycle to the parts the machine makes per cycle, in [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/). ## See also - [Configure tracking for CNC mills and lathes](/docs/production/cnc-machines/) - [Configure tracking for injection molding](/docs/production/injection-molding/) - [Configure tracking for stamping and punch presses](/docs/production/stamping-presses/) - [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/) - [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/) --- # Configure tracking for CNC mills and lathes Source: https://www.iotflows.com/docs/production/cnc-machines/ Set up part counting on a machining center whose cycle time changes with the part. Mount the SenseAi near the spindle, measure a typical cycle by hand, create the part with one operation per thing the machine does, set the operation's algorithm to Discrete Analysis, then assign every operation the machine runs to it at once from the Auto-Detect modal's Discrete tab, which is multi-select. Validate against a hand count, expect 40 to 85% uptime depending on how much of the cycle an operator carries, and read setup time out of the Downtimes report. # Configure tracking for CNC mills and lathes Count parts on a machine whose cycle time changes with the job. A CNC mill, lathe, grinder or machining center runs a different cycle for every part, anywhere from 30 seconds to 30 minutes. [Discrete Analysis](/docs/production/choose-an-algorithm/#discrete) is the algorithm for that case: it counts the cycles it detects rather than dividing running time by a fixed number, so one operation stays accurate when the part changes. Allow 30 to 45 minutes for the first machine. **Before you start** - A SenseAi or SenseAi Embedded tied to the machine. Contact IoTFlows to tie your sensors to an asset, see [Get support](/docs/get-started/get-support/). - Sign in as an Organization Owner or Organization Administrator, see [Roles reference](/docs/admin/roles-reference/). ## Why Discrete Analysis fits a CNC Four things about machining point at the same algorithm. - **Cycle times vary with the part.** Discrete Analysis counts detected cycles, so it never assumes they are equal. - **The machine idles between parts.** Loading, inspection and tool changes drop the trace back to the stopped level, and that fall is what ends a cycle. - **Cutting has a vibration signature.** The algorithm reads the shape of the burst instead of the clock. - **Operators pace the work.** Short pauses inside a cycle merge back into it rather than splitting one part into two. **You do not need a second sensor to count parts.** SenseAi derives part counts and cycle times from the same vibration trace that produces the running and stopped state. **Choose [Continuous Analysis](/docs/production/choose-an-algorithm/#continuous) instead when the trace never falls back to the stopped level between parts.** A bar-fed lathe running one job unattended sits closer to that case than to a machining center that stops for every load. ## Mount the sensor on the machine ![A SenseAi magnet-mounted on the sheet-metal housing beside the work envelope of a vertical machining center](/images/production/prod-cnc-01.webp) *SenseAi on a machining center, mounted on the spindle housing.* 1. Mount as close as you can get to the spindle, the tool changer or the main motor housing. 2. Pick flat ferrous metal mechanically tied to the parts that move. A guard door holds the magnet and passes on its own ringing rather than the driveline's, see [Choose a mounting location](/docs/hardware/install-senseai/#mounting). 3. Keep the device out of the coolant spray path. Where coolant is unavoidable, use [SenseAi Embedded](/docs/hardware/senseai-embedded/), which is sealed and mounts at the motor. 4. Connect power and put the device on Wi-Fi, see [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/). 5. Run 5 to 10 complete machining cycles while you calibrate, so the thresholds are set against real cutting rather than a spindle warm-up, see [Calibrate SenseAi and SenseAi Embedded](/docs/hardware/calibrate-senseai/). Verify the mount rather than judging it by eye. Run the machine cutting, then let it idle, and confirm the two read differently. ## Measure a typical cycle time Discrete Analysis adapts to variation, and you still enter a cycle time. The algorithm does not read it to count. The shift goal and the parts gauge do, see [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/). 1. Pick a part you run often. 2. Time 10 to 20 complete cycles by hand, from part load to part unload. 3. Average them. For example, 4:15, 4:30, 4:10, 4:25 and 4:20 average to 4:20. 4. Note the range as well as the average. Simple parts at 2 to 3 minutes and complex ones at 10 to 15 minutes on the same machine are normal, and Discrete Analysis handles the spread. ## Create the part and its operations 1. Open **Parts List** at `/production?select=parts_list`. 2. Click **+ Add Part**. 3. Enter a **Part Name**, for example `Aluminum Bracket`. **Part Description** is optional. 4. Under **Assign Operations**, name the first operation `OP10` and describe it, for example `Rough mill, vertical`. 5. Enter **Operation Cycle Time** in the h, m and s boxes. For the 4:20 average, that is 4 in the m box and 20 in the s box. 6. Enter a standard deviation in the boxes beside it. Leaving either at zero blocks the part with **Cycle time and standard deviation must be greater than zero**. 7. Add the machines that run this operation. 8. Click **Add another operation** for each further thing the machine does differently, then **Add Part**. 9. Back on the Parts List, expand the part, click the operation's **Algorithm** cell and choose **Discrete Analysis**. It saves as you pick it. 10. Set **QTY/OP** to the parts one cycle makes. One is usual on a CNC. Raise it only when the setup runs several identical parts at once. Create one operation per thing the machine does differently, not one per step on the router, see [Create parts and operations](/docs/production/parts-and-operations/). The table shows no **Downtime Filter** column here: that column belongs to Continuous Analysis alone, so a Discrete operation has nothing to leave blank. ## Assign the operations to the machine 1. Open **Assets** at `/assets` and click the machine. 2. Click **Auto-Detect** to open **Select Auto-Detect Operations**. 3. Stay on the **Discrete** tab. A SenseAi machine shows the **Discrete** and **Continuous** tabs only, because Counter is BeamTracker's algorithm. 4. Check every discrete operation this machine runs. The list is checkboxes, not a single choice. 5. Click **Auto-Detect**. The dashboard confirms with **Discrete Auto-classification Set**. Selecting discrete operations clears any continuous operation the machine was set to, and the modal says so above the list. The full flow, including detected cycle times and the Parts List entry point, is on [Detect operations automatically](/docs/production/auto-detect-operations/). ## Run more than one part on the same machine Because the Discrete tab is multi-select, **assign every part the machine runs at once and leave them assigned.** Nobody touches the dashboard at a changeover, and each part's output is reported separately, see [Compare production over weeks and months](/docs/production/historical-production/). | Your situation | What to do | What it costs | |---|---|---| | A handful of parts you run repeatedly | Create an operation for each and assign them all | Nothing. This is the normal setup | | A job shop where every job is new | Create one generic operation, for example `CNC-MILL-GENERAL`, at an average cycle time | Counts stay accurate. The goal and the parts gauge run against an average, so both are approximate | ## Validate the count 1. Let the machine run normally for two to four hours. 2. Open **Shift Production** at `/production?select=part` and read the count for the operation. 3. Compare it with a hand count over the same window. Twenty parts made should read 20, give or take one or two. 4. Open **Downtimes** at `/assets?select=downtimes` and check that real stops are there while measuring and chip clearing are not filling the list. 5. Change to a part with a different cycle time and confirm the count stays right. Accuracy bands and what to do at each one are on [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/#validate). ## What to expect from a CNC *Uptime* is availability: the share of the window the machine spent running, see [Uptime](/docs/monitoring/metrics-reference/#uptime). How much of the cycle an operator carries sets the ceiling, so a manual machine and a lights-out cell are not comparable. | How the machine runs | Uptime to expect | Goal to set | |---|---|---| | Manual, operator-intensive | 40 to 60% | 45 to 60% | | Semi-automatic, operator loads and unloads | 50 to 70% | 60 to 75% | | Fully automatic | 75 to 85% | 75 to 85% | | Lights-out with automation | — | 85 to 90% | Set the goal on [Set OEE and utilization goals](/docs/monitoring/oee-goals/). **Start from your own baseline plus 5 to 10%, not from the table.** A goal the machine has never met teaches operators to ignore the number. ## Track setup and changeover Setup is usually the largest single loss on a CNC, and it is invisible until stops carry reasons. 1. Create a **Setup / Changeover** category, see [Create a category](/docs/monitoring/downtime-categories/#create). Add **Tool Change** and **Tool Breakage** while you are there. 2. Have operators classify the stop at a job change, see [Classify a downtime event](/docs/monitoring/classify-downtime/). 3. After two to four weeks, read the total off the Pareto chart on the [Downtimes report](/docs/monitoring/downtimes/#pareto). 4. Work the setup time down, then watch the same chart month over month. **You do not need operators to classify every stop.** Set the short-stop cutoff first so measuring and chip clearing never reach the list, and what is left is worth someone's attention, see [Handle short stops](/docs/hardware/calibrate-senseai/#short-stops). ## Troubleshoot a CNC | Symptom | Cause | Fix | |---|---|---| | Parts missing from the count | Short or gentle cycles the sensor does not separate from idle | Lower the **Running Threshold**, or move the sensor closer to the spindle, see [Set the running and stopping thresholds](/docs/hardware/calibrate-senseai/#thresholds) | | Count runs high | Tool changes or probe touches read as cycles | Raise the **Running Threshold**, and recalibrate against full cycles rather than a tool change | | Uptime looks wrong while the count is right | The entered cycle time no longer matches what the machine runs | Re-time the current parts and update **Ideal Operation Cycle Time**. Discrete Analysis reads it for goals, not for counting | | The downtime list fills with one-minute stops | Measuring and chip clearing are reaching the record | Set **Downtime Threshold** with **Treat short downtimes as uptime** on, see [Handle short stops](/docs/hardware/calibrate-senseai/#short-stops) | Counts that are wrong in a way no threshold fixes are on [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/). ## See it in a plant - [CNC machine monitoring](https://www.iotflows.com/solutions/cnc-machine-monitoring) — Every CNC on one screen, any brand or age: uptime, parts, setup time, and controller data on Enterprise. ## See also - [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/) - [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/) - [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/) - [Calibrate SenseAi and SenseAi Embedded](/docs/hardware/calibrate-senseai/) - [Configure tracking for injection molding](/docs/production/injection-molding/) --- # Create a production work order Source: https://www.iotflows.com/docs/production/create-a-job/ The Create Workorder form adds one task to the production queue: one operation, on one machine, for a quantity of a part. Only the title is required, and every other field is a chip above it. Picking a machine auto-fills the operation, the time estimate and the parts that operation reserves. The form always assigns the new task to you and has no due date control, so work created here lands in My Work and starts out unscheduled on the board. Create from the Scheduler instead when you are planning work for somebody else. # Create a production work order Put a task in the queue with the machine, the operation, the quantity and the files an operator needs to run it. The **Create Workorder** form adds one *task* to the production queue: one operation, on one machine, for a quantity of one part. It is the same form on the web and in the mobile app. Only the title is required. Every other field is a chip in the row above the title, and each chip opens a small panel over the form. **Before you start** - Production Scheduler is part of the Scheduling Engine module. Seeing the **Work Queue** tab is not proof you are entitled to it. See [Module entitlement](/docs/production/overview/#entitlement). - A part with at least one operation, if you want the task to count anything. See [Create parts and operations](/docs/production/parts-and-operations/). You can create both from inside this form, see [Operation and quantity](#operation). - Nothing on this form is role-gated. Any member of the organization can open it and create work. - The camera tile is mobile only. See [Install the mobile app](/docs/get-started/install-mobile-app/). > **Info:** > **Creating work for somebody else?** > > Use the board, not this form. The Work Queue form always assigns the new task to you and has no due date control. > > The Scheduler's **Create** button opens a longer version of the same dialog, adding **Priority**, **Due Date**, **Assignee**, **Budget** and **Notes**. See [Plan jobs in the Production Scheduler](/docs/production/scheduler/). ## Open the create form 1. Go to the Work Queue at `/production?select=work_queue`. 2. Press the blue circular **+** at the top right of the toolbar. The dialog opens headed **Create Workorder**. It also opens from the **+** in the mobile toolbar, labeled **Create work order**, and from the **Jobs** tab of a machine page, where the machine is filled in for you. See [Run a job from the machine page](/docs/monitoring/operator-view/#jobs). ![The Create Workorder dialog. A header reads Create Workorder with a close cross at the right. Below it an Assigned to line carries a green pill with the creator's avatar and name. Two rows of gray chips follow: Part of Job, Operation, Asset, Required Parts and Create/Release Parts on the first, then Images, Files, Dependency and Time Estimate on the second, each with a small icon. Under the chips sits an empty title line reading What needs to be done? and a description area reading Add description. A full-width Create Workorder button fills the footer, grayed out, with the words Command+Enter to submit beneath it.](/images/production/prod-create-01.webp) *The Create Workorder dialog as it opens from the Work Queue, with every field collapsed into the chip row above the title.* The form resets every time it opens. Nothing is kept from the last work order you created, so a dialog you close by accident is a dialog you retype. Press **Cmd+Enter**, or **Ctrl+Enter** on Windows, to submit without reaching for the button. The footer says which one your machine takes. ## Machine and parent job **Asset** is the machine that will run the task. Open the chip, search by name or identifier, and pick one. The list shows thirty machines at a time, so search rather than scroll in a large plant. **Part of Job** is the *parent job*, the order this task belongs to: a quantity of a part, due on a date, that fans out into one task per operation. Tasks that share a parent job show the same job chip on every card in the queue. ![A cropped detail of the chip row with two numbered violet callouts. Callout 1 marks the Asset chip, filled and reading HAAS VF-2 beside a wrench icon. Callout 2 marks the Part of Job chip at the head of the row, filled and reading PO-1003 beside a briefcase icon. Between them sits a third filled chip reading OP10 · BH-4021, the operation the machine filled in. The chips after them, Work Sessions, Required Parts, Create/Release Parts, Images, Files, Dependency and Time Estimate, are gray and unset.](/images/production/prod-create-02.webp) *The Asset and Part of Job chips at the head of the chip row. Choosing a machine fills in the operation, and the parent job too when that machine already has queued work.* Choosing a machine fills in two other fields for you. The **Operation** chip takes the operation the machine is [auto-detecting](/docs/production/auto-detect-operations/), the one its sensor is already counting against. The **Part of Job** chip takes the parent job of the machine's most advanced open task, preferring one in progress, then one on hold, then one not started. Both are suggestions. Clear either chip and pick your own, and nothing refills it until you change the machine again. To start a job that does not exist yet, open **Part of Job** and press **Create new job**. That opens the **Create Job** dialog, where you name the job, choose or create its part, set a quantity and a due date, and the new job is selected here when you save it. > **Warning:** > **Create Job can create a whole routing** > > The **Create a workorder for each operation** toggle in that dialog is off by default, and its button reads **Create Job**. > > Turn it on and the button changes to **Create Job + 4 Workorders**. Saving then posts one task per operation on the part's *routing*, its ordered list of operations, on top of the one you are filling in here. > > Read the button before you press it. ## Operation and quantity **Operation** is the step this task performs, for example `OP20 Turn` on part `BH-4021`. The picker groups operations under their part, and searches both names on the server, so typing a part number finds every operation on it. ![A cropped detail of the chip rows with the Operation panel open below them. The panel's top row shows a cog icon beside the operation name OP20 Bore with the part name MS-7420 Manifold beneath it, and a small cross to clear it. Below sits a label reading Required Qty (optional) over an input holding 250, and a Done button at the bottom right. The chip the panel hangs from is outlined blue and reads OP20 Bore · MS-7420 Manifold · Qty 250, and a chip further down reads 1 day 5 hrs 10 mins, the estimate the form worked out from the cycle time.](/images/production/prod-create-03.webp) *The Operation chip open on a chosen operation, with the Required Qty (optional) box beneath it.* **Required Qty (optional)** appears under the operation once one is chosen. It is how many good parts this task is for, and it is what the queue counts against, for example `12/250 pcs` on the card. > **Warning:** > **Choosing an operation overwrites the title** > > The title follows the operation name, every time the operation changes. Type `Rush order for Acme` first, then pick `OP20 Turn`, and the title reads `OP20 Turn`. > > Set the operation first, then write the title. ### Create a part or an operation without leaving the form Press **Create New Operation** in the operation panel to switch the panel into create mode. It works on every platform, not only in the mobile app. 1. Search for the part, or type a new name and press the create row. The form posts the part and toasts **Part created**. 2. Type the operation name. **More details (optional)** expands to a description, a quantity per cycle, an ideal cycle time in seconds, and a detection algorithm. 3. Press create. The form toasts **Operation created** and lists the new operation under the part. A part created this way arrives with no usable operation. The API creates a placeholder called `Untitled Operation` and the form deletes it, so step 2 is not optional if you want the task to count anything. For the full field list, see [Operation fields](/docs/production/parts-and-operations/#operation-fields). ## Work sessions A *session* is one run of a task: a start, an end, the good parts made and the scrap logged against them. The **Work Sessions** chip appears only once both a machine and an operation are set, because a session logs parts made for that operation on that machine. Press the chip, then **Add Work Session**. The **New Work Session** editor opens with a **Start** and **End**, a **Good Parts** stepper, scrap rows carrying a reason and a note, and a free note field. Sessions staged here are held on the form. Nothing is posted until you create the work order, so a session you stage and then delete costs nothing. Opened from the Work Queue, the editor defaults to the last hour. Opened from a machine's **Jobs** tab it fills the gap instead: from the end of the previous finished session on that machine, or from the shift start, up to now. The editor refuses a window it cannot store. It reads **Start time must be before end time**, **Start and end time cannot be the same**, **Session cannot start in the future**, **Session cannot end in the future**, or **Overlaps with another session** naming the job and the times it collides with. **Set workorder status** appears under the staged sessions as soon as one of them has both a start and an end. It offers **On Hold** and **Completed**, and applies that status to the new work order after it is created. Leave it alone to create the task at **Not Started**. Use it when you are recording work that already happened. A task you are backfilling at the end of a shift is finished, and creating it at **Not Started** leaves the queue claiming there is work to do. ## Required and created parts **Required Parts** is what the task consumes, and **Create/Release Parts** is what it leaves behind: a part it makes, or a tool it hands back to the crib. Each line names a part, a location to take it from or put it into, and an amount. Both lists fill themselves from the operation. When the chosen operation has material rules, choosing it stages every rule as a line and scales the amounts to the quantity you entered. For example, an operation that takes two carbide inserts per part stages `Carbide insert CNMG-432 x 500` against a quantity of 250. See [Bind materials to an operation](/docs/production/bind-materials/). A staged line reserves nothing until it has both a location and an amount above zero. A line missing either turns amber and reads `Set a location, or this part is not reserved`, and the chip count turns amber with it. Pressing **Create Workorder** with an amber line stops once and explains itself: `2 staged parts will not be reserved: set a location and an amount, or press Create again to continue without them.` Fix the lines, or press the button a second time to create the work order without them. Delete a line and it stays deleted. The prefill remembers what you removed and does not put it back when you change the quantity. ## Images and files **Images** takes photographs and drawings that should render inline, and **Files** takes everything else. Both accept a drop as well as a click, and both upload as soon as the file lands. Images are converted to WebP and capped at 1600 px on the long edge before upload, so a phone photograph does not arrive as an 8 MB file. The chip accepts JPEG, PNG, GIF, WebP, BMP and SVG, and rejects anything else with ` is not a valid image`. Send a PDF or a STEP file through **Files** instead. **You do not need to attach the drawing to every task.** Attach it to the part once, in the Parts List, and every task on that part's operations shows it. The **Files** panel in the job runner, the page an operator opens a task on, has two sections: **Work Order Files** and **Part Files**. It reads both. See [Add pictures and files](/docs/production/parts-and-operations/#files). ## Dependency A *dependency* says this task cannot start until another one is done. Open the chip, search the production work orders by title, operation or part, and pick the predecessor. ![A cropped detail of the open Dependency panel. A row holds a chain-link icon beside the work order title Saw manifold billet, with the operation name OP10 Saw beneath it and a cross at the right to clear the selection. The chip the panel hangs from is outlined blue and reads Saw manifold billet beside a chain-link icon, and the title line behind the panel still reads What needs to be done?, so picking a predecessor does not overwrite the title the way picking an operation does.](/images/production/prod-create-05.webp) *The Dependency chip open on a chosen predecessor. Set one only when this task truly cannot start until that one finishes.* **Each result shows a title over an operation, and never the job it belongs to.** The same operation queued on two different orders gives two results that read identically, so a search that returns a pair tells you nothing about which one to pick. Search the title rather than the operation when the distinction matters, or set the link on the Gantt instead, where the task carries its job. **Set a dependency only when the second task genuinely cannot start first.** Dependencies constrain the Gantt, and a schedule over-constrained on the first pass is harder to debug than a late job. Sawing before turning is a dependency; running two unrelated jobs in a preferred order is not. Once set, the link drives three things on the board: an arrow on the Gantt, a **Predecessor is late** entry in Schedule issues when the predecessor cannot finish in time, and the red bar that goes with it. See [Link dependent tasks](/docs/production/scheduler/#dependencies) and [Waiting on a late predecessor](/docs/production/schedule-issues/#late-pred). The operator never sees it. The job runner has no dependency field, so a task whose predecessor is unfinished still looks ready to start from the floor. This form does not check for a cycle. The Gantt does, and refuses a link that would create one with **That link would create a circular dependency**, so an impossible chain built here surfaces the next time somebody drags it. ## Time estimate and due date The *estimate* is how long the task should take. It is what the Gantt draws the bar from and what the optimizer packs against, and it is the field most often left empty. **Time Estimate** takes free text. `2h 30m`, `90m`, `1 day 3 hours` and a bare `90` all parse; anything else reads **Invalid format** in red under the input and is discarded on create. The form fills it in for you from the operation's ideal cycle time times the quantity, and says where the number came from: `Estimated from 45s cycle x 250 pcs`. Edit it or clear it once and the form stops touching it, even if you change the operation afterwards. > **Warning:** > **This form cannot set a due date** > > There is no due date control anywhere on it. A task created here has no due date, which makes it *unscheduled*: it keeps a row in the Gantt's left rail with a crossed-out calendar, and a chip pinned down the left edge of the chart instead of a bar. > > Give it a date in the board's Table view before you expect it to schedule. See [Schedule work that has no dates](/docs/production/scheduler/#unscheduled) and [Edit in place](/docs/production/scheduler/#inline). Priority is set for you the same silent way. The form takes the first priority in your organization's list and offers no picker, so change it on the board if it matters. ## Create the work order Press **Create Workorder**. The button stays grayed out until the title has text in it, which is the form's only validation. **The form always assigns the new task to you.** The **Assigned to** line above the chip row names you, it is read-only, and there is no assignee picker. A task created here lands in your **My Work** list rather than in the Available Work list everybody shares. ![A cropped detail of the top of the Create Workorder dialog, ringed in violet. A small gray label reads Assigned to, followed by a green rounded pill holding a circular avatar and the creator's name. Nothing beside the pill is clickable: there is no dropdown arrow, no add button and no second name.](/images/production/prod-create-04.webp) *The Assigned to line above the chip row. It always names you, and the Create Workorder form has no control to change it.* To hand the work to somebody else afterwards, add them on the job page in the mobile app, or drag the task into their lane on the board. See [On mobile](/docs/production/work-queue/#mobile) and [Group by asset, job or operator](/docs/production/scheduler/#grouping). On success the form toasts **Workorder created successfully**, closes, and the queue reloads. The new task appears at once on the page you created it from, and does not appear on anybody else's open queue until they reload. ### Job fields | Field | Required | Accepts | Visible to operator | Editable later | |---|---|---|---|---| | **Title** | Yes | Free text, overwritten by the operation name | Yes, as the job title | On the board | | **Description** | No | Rich text: bold, italic, underline, strike, lists, headings | Yes, under **Notes**, with the formatting stripped | On the board | | **Asset** | No | One machine | Yes, in the machine bar | Yes, in the job page's **Details** panel | | **Part of Job** | No | One existing job, or one you create inline | Yes, as a chip and the **Job** control | Yes, on the job page | | **Operation** | No | One operation on one part | Yes, as a chip | Yes, on the job page | | **Required Qty** | No | A whole number of pieces | Yes, as `made / ordered pcs` | Yes, in the **Details** panel | | **Work Sessions** | No | Start, end, good parts, scrap with reasons, a note | Yes, in session history | Yes, on the job page | | **Required Parts** | No | Part, location, amount | No | On the board, in the task drawer | | **Create/Release Parts** | No | Part, location, amount | No | On the board, in the task drawer | | **Images** | No | JPEG, PNG, GIF, WebP, BMP, SVG | Yes, in the file viewer | On the board | | **Files** | No | Any file type | Yes, under **Work Order Files** | On the board | | **Dependency** | No | One production work order | No | On the board | | **Time Estimate** | No | `2h 30m`, `90m`, `1 day 3 hours`, or a bare number of minutes | Yes, as **Duration** | On the board | | **Assignee** | Set for you | You, always | Yes, under **Assigned To** | In the mobile app, or on the board | | **Priority** | Set for you | The first priority in your organization's list | Only as a colored dot in the queue's list mode | On the board | | **Due date** | Not on this form | Nothing. The field has no control | Yes, as **Due**, reading `--` | On the board | For the full field list across every production surface, including the scheduler columns and the export, see [Job and scheduler fields](/docs/production/job-fields-reference/). ## When creation fails | What you see | What happened | What to do | |---|---|---| | **Create Workorder** stays grayed out | The title is empty | Type a title. Nothing else is required | | `2 staged parts will not be reserved: set a location and an amount, or press Create again to continue without them.` | A staged parts line has no location, or an amount of zero | Fix the amber lines, or press the button again to create without them | | **Failed to create workorder**, or a message from the server | Nothing was created. The form stays open with your work in it | Read the server's message if there is one, then try again | | **Workorder created, but a work session failed to log** | The task exists. One or more staged sessions did not save | Open the task and add the session from its history. See [Session history](/docs/production/run-a-job/) | | **Workorder created, but the status update failed** | The task exists at **Not Started**. The **On Hold** or **Completed** you chose did not apply | Set the status on the job page | | ` is not a valid image` | The **Images** chip rejected the file type | Attach it through **Files** instead | | `Failed to upload ` | That one attachment did not upload. Everything else on the form is intact | Try the file again, or create the task and attach it from the board | | **Failed to create part**, **Failed to create operation**, **Failed to create job** | An inline create failed. The parent form is untouched | Try again, or create it in the Parts List first | A generic **Something went wrong** or **An error occurred** means the request failed and nothing was saved. See [Troubleshoot monitoring](/docs/monitoring/troubleshoot-monitoring/). ## On mobile The mobile app opens the same form with the same fields. Only the layout changes, and which layout you get depends on the viewport rather than the device, see [On mobile](/docs/production/work-queue/#mobile). ![The Create Workorder sheet on a phone. An Assigned to pill sits under the title, then a wrapped row of chips reading Part of Job, Operation, Asset, Required Parts, Create/Release Parts, Images, Files, Dependency and Time Estimate, a What needs to be done field, and a Create Workorder button across the footer.](/images/production/prod-create-06.webp) *The same Create Workorder form in the mobile app. Every field is a chip: part of job, operation, asset, required and created parts, images, files, dependency and time estimate.* One control is mobile only. **Take photo** appears as a second dashed tile inside both the **Images** and the **Files** panels, and opens the rear camera straight into the upload. A photograph taken that way goes through the same WebP conversion as a file picked from the gallery. Everything else behaves as it does on the web, including the self-assignment. The one thing the phone adds afterwards is the **People** section on the job page, which is the only assignee control anywhere in the Work Queue. See [On mobile](/docs/production/work-queue/#mobile). ## See also - [Start, pause, and complete a job](/docs/production/run-a-job/) - [Find your next job in the Work Queue](/docs/production/work-queue/) - [Plan jobs in the Production Scheduler](/docs/production/scheduler/) - [Job and scheduler fields](/docs/production/job-fields-reference/) - [Submit a maintenance request](/docs/maintain/submit-a-request/) --- # Set cycle times and downtime filters Source: https://www.iotflows.com/docs/production/cycle-times-and-filters/ Three numbers on an operation decide whether counts and goals match the floor: the ideal cycle time in the Ideal Operation Cycle Time column of the Parts List at /production?select=parts_list, the quantity per cycle in QTY/OP, and the continuous downtime filter percentage, which only Continuous Analysis operations carry and which accepts 0 to 200%. Production rate is the same number inverted, 60 divided by the cycle in seconds. The Calculated Goal on Shift Production, the parts gauge and the hourly bars are all derived from the ideal cycle time, and none of them can be set anywhere else. # Set cycle times and downtime filters The three numbers that decide whether your counts and your goals match the floor. Every goal, pace and gauge in Production is derived from figures you type onto an operation in the Parts List, at `/production?select=parts_list`. Three of them carry the weight: the ideal cycle time, the quantity per cycle, and the continuous downtime filter. Counts still arrive when these are wrong, measured against the wrong target, which is much harder to notice. **Before you start** - A part with at least one operation. See [Create parts and operations](/docs/production/parts-and-operations/). - The operation's detection algorithm set, because it decides which of these fields appear and whether the count itself reads the cycle time. See [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/). ## Set the ideal cycle time *Ideal cycle time* is how long one good cycle of this operation takes when the machine is running well. You enter it. Nothing measures it for you. Three figures in the product are called a cycle time, and only one of them is yours to type: | Number | Source | Used for | |---|---|---| | **Ideal** | Typed here, on the operation | The shift goal, the hourly goal and the parts gauge. Continuous Analysis also divides running time by it to produce the count | | **Goal** | Derived from the ideal cycle time and the machine's uptime goal. See [Set OEE and utilization goals](/docs/monitoring/oee-goals/#machine) | The threshold the actual figure is colored against: green at or below it, red past it | | **Actual** | Measured from detection events while the machine runs | What the machine really did, on the Assets page, the machine page and Shift Production | To set the ideal: 1. Open **Production**, then the **Parts List** tab at `/production?select=parts_list`. 2. Click into the operation's **Ideal Operation Cycle Time** cell. 3. Type the cycle across the four boxes: `hr`, `min`, `sec`, and after the decimal point, hundredths of a second. A 20-second molding cycle is `0 : 0 : 20 . 0`. A half-second press stroke is `0 : 0 : 0 . 50`. 4. On a **Discrete Analysis** or **Discrete w/o Merge** operation, set the tolerance percentage in the box beside it. Hover it to read the **Cycle Time Range** it produces, for example `(00:01:48 - 00:02:12)` for a 2-minute cycle at 10%. 5. Click elsewhere. The cell saves on its own, with no Save button. The hour box takes a single digit, minutes and seconds stop at 59, and the tolerance runs 1 to 99% and falls back to 10% if you clear it. **Continuous Analysis** and **Counter** operations carry no tolerance box and save with the tolerance at zero. **Set the ideal cycle time to the best sustainable cycle, not the fastest one ever recorded.** Every pace figure on the site is measured against it, so a heroic number makes a normal shift look like a failure and trains people to ignore a red gauge. Time 10 to 20 consecutive cycles on a good day and use that. ![The Algorithm and Ideal Operation Cycle Time columns of one Parts List operation row, a Counter operation, with two numbered violet callouts: 1 on the four cycle-time boxes reading 0 hr, 0 min, 1 sec and 33 after the decimal point, and 2 on the swap control beside them, labeled H:M:S over an up-down arrow, which restates the same cycle as a rate in ops per minute](/images/production/prod-cycle-01.webp) *Ideal cycle time and production rate are the same number stated two ways.* ## Production rate is the same number *Production rate* is the ideal cycle time turned over: parts per minute instead of seconds per part. ``` production rate = 60 ÷ cycle time in seconds ``` A 20-second cycle is `3.0 ops/min` and a half-second stroke is `120.0 ops/min`. The unit is the operation's own **OP UNIT** label, which defaults to `ops`. See [Unit and quantity per cycle](/docs/production/parts-and-operations/#units). On a **Counter** operation, and only there, the Parts List cell carries a swap control beside the boxes. Click it to switch the cell between `H:M:S` and the rate, type the rate, and the cycle time is written back from it. The two figures can never disagree, because only the cycle time is stored. Everywhere else the rate is a reading rather than an input. Shift Production and the machine page show **Ideal**, **Goal** and **Actual** together, with one arrow that flips all three between a cycle time and a rate. **Enter whichever number your plant already quotes.** A press rated at 120 strokes a minute is easier to type as a rate than as `0.50` seconds, and a molder quoted at a 22-second cycle is easier to type as a cycle. On a Counter operation you have the choice; on the other three, convert once and type the cycle. ## Set quantity per cycle *Quantity per cycle* is how many parts one detected cycle of this operation yields. It is the **QTY/OP** cell on the row, with its own unit label beside it, which defaults to `made`. The field reference is on [Unit and quantity per cycle](/docs/production/parts-and-operations/#units). It belongs on this page because **the cycle time is per cycle, never per part**. A two-cavity mold with a 22-second shot makes two parts every 22 seconds: the cycle time stays `22.0` and QTY/OP goes to `2`. Halving the cycle time instead gets the part count right and every rate, goal and gauge wrong. The number reaches three places: - **Part counts** are the cycle count multiplied by it. A four-cavity mold left at `1` reports a quarter of its real output. - **Gauges reported in ops** divide it back out, which is the second gauge Shift Production draws beside Progress on any operation whose cycle yields more than one part. See [Read the board](/docs/production/shift-production/#board). - **A work order's time estimate** divides the pieces ordered by it. 500 pieces at a 45-second cycle, 2 per cycle, estimates `3 hrs 8 mins` and shows its working as `Estimated from 45s cycle x 500 pcs at 2/cycle`. **Leave QTY/OP at 1 unless the machine really yields more or fewer parts per cycle.** It is the only field on the row that scales the answer, so it is the first cell to check when a count comes out doubled or halved, and the last one to change when a count looks close. ![The Description and QTY/OP columns of one Parts List operation row, with the QTY/OP field ringed in violet: it holds the value 2 with the unit label made beside it, and the description beside it reads 2-cavity mold, black ABS](/images/production/prod-cycle-02.webp) *Quantity per cycle. A two-cavity mold produces two parts per cycle.* ## Set the continuous downtime filter A *downtime filter* is a share of the ideal cycle time under which a stop is counted as running time instead of as downtime. It exists so that brief in-cycle pauses on a machine that never fully stops do not fill the downtime record. Only **Continuous Analysis** operations have one. That algorithm produces its count by dividing running time by the cycle time, so a pause counted as downtime is also a pause that costs parts. See [Continuous Analysis](/docs/production/choose-an-algorithm/#continuous). The **Downtime Filter** column appears on a part only when at least one of its operations runs that algorithm, and inside that part only the Continuous rows carry an editable cell. On a part whose operations are all discrete, the column is not on the table at all. 1. Click the **Downtime Filter** cell on the Continuous Analysis row. 2. Type a percentage. The field accepts `0` to `200` and clamps anything higher as you type. 3. Click elsewhere to save. Hovering the cell reads back what the current number does. Read the percentage as a length of time, because that is what it becomes: 150% of a 20-second cycle is a 30-second window, and every stop shorter than 30 seconds is converted to uptime. Diagram: Two horizontal bars covering the same three minutes. The upper bar, labeled ideal, one cycle every 20 seconds, is divided into nine equal cells and annotated nine cycles in three minutes. The lower bar, labeled actual, what the sensor saw, is mostly running and is broken by three pauses: an 8 second pause and a 26 second pause, both drawn in violet and marked becomes uptime, and a 48 second pause drawn in gray and marked stays downtime. A dashed violet line inside the 48 second pause marks where the filter window ends, 30 seconds in. The actual bar is annotated under 5 cycles in the same 3 minutes. A key below reads: filter window, 150 percent of a 20 second cycle, equals 30 seconds. A closing line reads: a stop shorter than the window is counted as running time. The 48 second stop runs past it, so it stays downtime. *Ideal cycle time against actual, with the continuous downtime filter window marked. Pauses inside the window are not counted as stops.* Because the window is a multiple of the cycle time, changing the cycle time moves the filter with it. An operation re-timed from 20 to 40 seconds at 150% goes from hiding 30-second stops to hiding minute-long ones without anybody touching the filter. **You do not need a downtime filter on a machine that runs continuously.** The filter exists to stop short in-cycle pauses reading as stops, and a truly continuous process has none to hide, so all the filter does there is hide real ones. Start at `0`, watch the [Downtimes report](/docs/monitoring/downtimes/#table) for a week, and raise it only if that list fills with pauses nobody on the floor would call a stop. Short stops on the other three algorithms are handled on the machine instead, by **Downtime Threshold** with **Treat short downtimes as uptime**. See [Handle short stops](/docs/hardware/calibrate-senseai/#short-stops). ## Where the shift goal comes from The **Calculated Goal** on Shift Production is derived from the ideal cycle time you set here. That page reads the number and cannot set it. There is no per-operation goal override anywhere in the product. ``` Goal = (Shift Duration - Expected Downtime) / Cycle Time ``` Expected downtime is the historical average for that operation and machine. See [Where the goals come from](/docs/production/shift-production/#goals). Two more numbers follow the same cycle time. The parts gauge, *performance*, measures actual output against what the ideal cycle time implies over the window, so it moves the moment you change the ideal. The hourly bars carry a per-hour goal derived from the same figure and the machine's uptime goal. See [Performance](/docs/monitoring/metrics-reference/#performance) and [Production metrics](/docs/monitoring/metrics-reference/#production). The downtime filter feeds a different pair. Converting a stop to running time raises [uptime](/docs/monitoring/metrics-reference/#uptime) and lowers [downtime](/docs/monitoring/metrics-reference/#downtime) for that machine, so a filter set too high flatters the board. ## Cycle settings reference | Field | Unit | Affects | Set too high | Set too low | |---|---|---|---|---| | **Ideal Operation Cycle Time** | Hours, minutes, seconds, hundredths | The shift goal, the hourly goal, the parts gauge, the filter window. On Continuous Analysis, the count itself | Goals are met on a bad shift, the parts gauge sits above 100%, and Continuous Analysis undercounts | Goals are unreachable, the gauge reads red on a good shift, and Continuous Analysis overcounts | | Tolerance, beside the cycle time | Percent, 1 to 99. Discrete algorithms only | The **Cycle Time Range** drawn around the ideal | The range covers cycles that are not this operation | The range excludes cycles the machine really runs | | **QTY/OP** | A count, fractions allowed | Part counts, the ops gauges, work order time estimates | Counts read high by the same factor | Counts read low by the same factor. A four-cavity mold at `1` reports a quarter of its output | | **Downtime Filter** | Percent of the cycle time, 0 to 200. Continuous Analysis only | Uptime and downtime on the machines running that operation | Real stops are absorbed into uptime and never reach the Downtimes report | Brief in-cycle pauses fill the downtime record | ## Check your numbers against the floor Check the numbers you typed against what the machine reports, once it has run the operation for an hour or more. 1. Open the machine's row on the **Assets** page and read the **Cycle time** it reports beside the operation. That figure is measured from detection events, not from anything you entered. See [Review the detected cycle time](/docs/production/auto-detect-operations/#cycle-time). 2. Compare it with your ideal. A figure within a few percent means the ideal is a fair target; a figure half or double the ideal is an algorithm problem rather than a cycle-time one. 3. Open **Shift Production** at `/production?select=part` and read **Ideal**, **Goal** and **Actual** together on the operation's row. 4. Check the parts gauge. A gauge above 100% means the machine beat an ideal cycle time that is set too slow, not that it outran physics. 5. Open the [Downtimes report](/docs/monitoring/downtimes/#table) and confirm that real stops are in the list and short in-cycle pauses are not. That is the filter's verdict. Validate the count itself against a hand count rather than against a total that looks about right. The procedure and its accuracy bands are on [Validate your choice](/docs/production/choose-an-algorithm/#validate). **When a change does not save**, the cell puts the old value back and the dashboard raises the server's message as a toast. Retype the value once; a message that returns is a number being rejected, not a number being lost. Counts that stay wrong after all three of these numbers check out are on [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/). ## See also - [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/) - [How each metric is calculated](/docs/monitoring/metrics-reference/#cycle-time) - [Set OEE and utilization goals](/docs/monitoring/oee-goals/) - [Track production against shift goals](/docs/production/shift-production/) - [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/) --- # Compare production over weeks and months Source: https://www.iotflows.com/docs/production/historical-production/ Historical, at /production?select=historical_report, charts good parts and scrap across days, weeks, months, quarters or years, then breaks the total into one card per operation and one row per machine that ran it. Every Last N preset ends at the last completed period, so this week never competes with a full one. Show Scrap adds a second red column beside each period's good column, and only scrap logged against a job reaches it. Actions downloads the view as CSV or a server-rendered PDF, or emails it now or on a cadence. # Compare production over weeks and months Put this week's output next to the last eleven, operation by operation and machine by machine. Historical is the report you open once the shift board has told you something is off. It charts good parts and scrap across a range of days, weeks, months, quarters or years, then breaks each period's total into one card per operation and one row per machine that ran it. Nothing here is editable. It is a report rather than a board, and it is the only production surface that produces a file. **Before you start** - Create parts and operations and assign them to machines, so there are counts to chart. See [Create parts and operations](/docs/production/parts-and-operations/). - Log scrap against jobs if you want the scrap half of the chart to hold anything. See [Log scrap and manage scrap reasons](/docs/production/log-scrap/). There is no role gate. Anyone who can see a machine can read its production history. ## Open the report Open **Production**, then the **Historical** tab, at `/production?select=historical_report`. It opens on **Last 7 days** at a daily interval. A line under the toolbar names the time zone every date on the page is calculated in: your organization's, not your browser's. See [Shifts and time zone](/docs/admin/shifts-and-timezone/). ## Choose the interval and the window The date button at the right of the toolbar sets both at once. Pick an interval down the left of the panel, then a preset or **Custom range** on the right, then **Apply**. The interval is the width of one column in the chart. | Interval | Presets | One column covers | |---|---|---| | **Daily** | Last 7 days, Last 14 days, Last week (Mon - Sun) | One day | | **Weekly** | Last 4, 6, 8 or 12 weeks | One week, Monday through Sunday | | **Monthly** | Last 3, 6, 9 or 12 months | One calendar month | | **Quarterly** | Last 2, 4 or 8 quarters | One calendar quarter | | **Yearly** | Last 2, 3 or 5 years | One calendar year | Every **Last N** preset ends at the most recent completed period. **Last 4 weeks** is the four finished weeks before this one, and leaves the week you are in out of the chart. That is what keeps the comparison fair: a Tuesday-afternoon week never competes with a full one. **Compare weeks rather than days when the part mix changes.** A day-to-day comparison across a changeover measures the changeover. A weekly column absorbs the setup, and what is left is the thing you wanted to see. A **Last N** preset writes `last_n_cycle` into the address bar and no fixed dates, so the link stays *rolling*: it counts back from the day it is opened rather than naming two dates. **Custom range**, and **Last week (Mon - Sun)**, write `from` and `to` instead, which freezes the window. Only a rolling link can be scheduled, see [Schedule a recurring report](/docs/monitoring/share-and-schedule-reports/#schedule). ## Read the chart The chart across the top is the whole organization. One column per period, stacking every operation that ran in it, one color each. Hover a column for a shared tooltip listing each operation's count for that period, with **Total Good** beneath them. Drag sideways across the chart to zoom into part of the range. There is no legend: the operation names are in the tooltip and in the cards below. ![The Historical tab at /production?select=historical_report showing twelve weekly columns, each stacking five operations in shades of blue and gray with the part count printed on every segment, above the OP20-FINISHING and OP30-ASSEMBLY cards and their machine rows](/images/production/prod-hist-01.webp) *Historical production by week. Each column stacks the operations that ran in that week.* ## Separate good parts from scrap Scrap is hidden until you ask for it. Set **Show Scrap**, to the left of **Actions**, and a red column appears beside each period's good column. Scrap does not sit on top of good parts, it stands next to them. So a period with scrap reads as two columns, made and rejected, and the tooltip gains a **Total Bad** to go with **Total Good**. The same toggle adds the red series to every operation card and machine row below. **Only scrap logged against a job reaches this chart.** A part thrown in the reject bin and never recorded is invisible here, and it is still counted as good everywhere else. If the red column is missing on a week you know went badly, check that scrap was logged before you check the sensor. See [Log scrap and manage scrap reasons](/docs/production/log-scrap/). ![Four weekly periods of the historical chart with the Show Scrap switch turned on and highlighted, each period drawing a tall blue good column and a short red scrap column beside it](/images/production/prod-hist-02.webp) *Show Scrap on. A red scrap column joins each period's good column.* The toggle travels in the address bar as `toggle_show_scrap`, so a link you send opens with scrap showing. ## Read the operation cards Below the chart, one card per operation. Each names the operation, its description, and the part it produces, for example `OP10-MACHINING` over `Bevel Gear 2`, then carries two figures and its own bar chart over the same periods. The two figures are marked with icons rather than labels. The clock is the cycle time; the grid of dots is the good count for the window. Inside the card, one row per machine that ran the operation, with the machine's picture, its name and its custom identifier, the same two figures, and the same chart drawn in gray instead of blue. This is where a flat total comes apart. An operation that held steady all quarter can hide one machine that fell off in week 9 and a second that covered for it. Read the machine rows whenever the operation total looks fine and the floor disagrees. ## Filter by part, operation, and shift Two filters sit at the left of the toolbar, with **Reset filters** after them. | Filter | Values | Effect | |---|---|---| | **Part / Operation** | Every part in the organization, expanding to its operations, multi-select, with a search box | Limits the chart and the cards to the operations you check. Checking a part checks all of its operations | | **Shifts** | **All Day (24/7)**, **All Shifts**, or any named shift, multi-select | Counts only parts made inside the shifts you check | **All Day (24/7)** counts everything in the window, including parts made outside every named shift. **All Shifts** counts only the hours your named shifts cover. Use **All Shifts** when an unattended weekend would otherwise flatter or spoil the comparison, and **All Day (24/7)** when you want the plant's whole output. **Reset filters** clears both filters and keeps the date range. This report has no **Shift islands** toggle, so a shift that crosses midnight is always split at midnight here: parts made after midnight are counted on the next day. Compare a night shift day by day on the [Advanced Report](/docs/monitoring/advanced-report/#shift-islands) instead, which can report the shift whole, or widen the interval to weekly so the split falls inside one bar. See [Where the overnight hours land](/docs/admin/shifts-and-timezone/#overnight-hours). ## Export, share, or schedule the report **Actions**, at the right of the toolbar, holds four items under a **Report actions** heading. | Action | What you get | |---|---| | **Download as PDF** | A server-rendered copy of the report as you have it on screen. It takes a few seconds, and leaving the page cancels it. The file is named for the window on a custom range, `Production_Historical_Report_2026-06-29_to_2026-09-20.pdf`, and for today's date on a **Last N** preset | | **Download as CSV** | One row per operation, per machine, per period, named `Production_Historical_Report.csv`. Columns in [Historical production CSV](/docs/monitoring/exports-reference/#historical-csv) | | **Share** | Emails the view you built to members of your organization now | | **Schedule** | Saves the view and emails it on a cadence from daily to yearly | The PDF is rendered from the URL you are on, so it carries your filters, your date range and the **Show Scrap** state, and it looks like the page. The CSV carries the rows and nothing else. See [Choose CSV or PDF](/docs/monitoring/exports-reference/#csv-or-pdf). **Share** and **Schedule** are not downloads, and neither takes a typed email address: both pick from your organization's member list. See [Email a report and schedule it to repeat](/docs/monitoring/share-and-schedule-reports/). **You do not need this page to know whether the shift in front of you will hit its goal.** Shift Production carries the live counts, the goals and the hourly bars for the shift under way. Historical exists to compare finished periods, and to produce the file. See [Track production against shift goals](/docs/production/shift-production/). ## When a number looks wrong | Symptom | Cause | Fix | |---|---|---| | The chart is empty and no operation cards appear | Nothing was counted in the window, or the **Part / Operation** filter excludes everything that was | Select **Reset filters**, then widen the date range before you suspect the machines | | A week is short and you know it was not | The comparison includes a period the plant was down, or the **Shifts** filter excludes the shift that ran | Check the **Shifts** filter first. **All Shifts** drops any hour outside a named shift, including an unattended weekend | | Scrap is missing from a period | Scrap for those parts was never logged against a job | See [Log scrap and manage scrap reasons](/docs/production/log-scrap/) | | The counts do not match the hand count on the floor | The operation's detection algorithm is reading the signal wrong | See [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/) | | The dates are a day off from your own calendar | The report runs in your organization's time zone, which the line under the toolbar names | See [Shifts and time zone](/docs/admin/shifts-and-timezone/) | | A night shift's first day is short, and the day after the shift ended has parts on it | The shift crosses midnight, and this report always splits it there | Read the run weekly instead of daily, or compare the hours on the [Advanced Report](/docs/monitoring/advanced-report/#shift-islands). See [Where the overnight hours land](/docs/admin/shifts-and-timezone/#overnight-hours) | | **Failed to download CSV. Please try again.** | The browser could not build the file from the rows on screen | Wait for the cards to finish loading, then download again. See [Export errors](/docs/monitoring/exports-reference/#errors) | | **Something went wrong generating the PDF.** | The server could not render the report URL | Try again, then narrow the range. A long window at a fine interval is the usual cause | | The **+** button in the **Schedule** dialog is grayed out | The date button is on a custom range or **Last week (Mon - Sun)**, which are fixed windows | Pick a **Last N** preset and select **Apply**. See [Schedule a recurring report](/docs/monitoring/share-and-schedule-reports/#schedule) | ## See also - [Track production against shift goals](/docs/production/shift-production/) - [Log scrap and manage scrap reasons](/docs/production/log-scrap/) - [Exports and report columns](/docs/monitoring/exports-reference/) - [Email a report and schedule it to repeat](/docs/monitoring/share-and-schedule-reports/) - [Analyze cost and on-time performance](/docs/production/production-insights/) --- # Import a schedule from your ERP Source: https://www.iotflows.com/docs/production/import-erp-schedule/ Turn a CSV or Excel export from your ERP into scheduled jobs. The importer runs as a six-step wizard: Upload, Read file, Check columns, Match people, Preview and Import. Only Job / Order number and Task name have to be mapped; rows sharing an order number become one job, and each row becomes one task under it. Column detection, date parsing and status translation all run in your browser. Parts the file names but your organization does not have are created automatically, which is the main source of duplicate parts, so the preview and the post-import cleanup both matter. # Import a schedule from your ERP Turn a CSV or Excel export from your ERP into scheduled jobs. The importer is a wizard that reads your export, shows you what it plans to create, and writes nothing until you press the button on the last step. It runs entirely against the file you upload: SAP, Epicor, Oracle and a hand-built spreadsheet all go through the same six steps. Two of those steps are yours to get right. **Check columns** decides which of your columns feeds which field, and **Preview** is the last place to catch a part that is about to be created by mistake. **Before you start** - Production Scheduler is part of the Scheduling Engine module. The tab strip renders for every organization, so seeing the **Scheduler** tab is not proof you are entitled to it. See [Module entitlement](/docs/production/overview/#entitlement). - A CSV or Excel export from your ERP, with one row per task. - Owner or Administrator, because an import can create parts and operations for the whole organization. The **Import** button itself is not role-gated in the dashboard. See [Roles reference](/docs/admin/roles-reference/). Diagram: A vertical list of the importer’s six steps, numbered top to bottom and joined by downward arrows, under the column headings Step and What you decide. 1. Upload: which file, and which sheet. 2. Read file: nothing, detection runs in your browser. 3. Check columns: which column feeds which field. 4. Match people: who each name in the file is, and the step appears only when an Assignee column is mapped. 5. Preview: what gets created, row by row. 6. Import: nothing, watch it run, then clean up. A dashed violet line runs between step 5 and step 6, labeled: nothing is written above this line. *The six import steps and what you decide at each one.* ## Prepare the file Export your schedule as CSV, `.xlsx` or `.xls`. Each row becomes one task, and **rows that share a value in the order column become one job**. That is the *row grouping*, and it is the behavior you want from a routing export: if your ERP writes one row per operation, leave the file as it is and let the importer group it. Only two fields have to be mapped: **Job / Order number** and **Task name**. Everything else is optional, and a column you do not map is either ignored or kept in the task's notes. **Map the smallest set that gets a usable schedule on the first import.** Order number, task name, quantity and due date are enough to see the week on the board. Add the part, operation and machine columns on the next import, once you trust what the matching is doing. The header row does not have to be the first row. The parser scans the first ten rows of each sheet and picks the one that looks most like headers, so the title and filter rows that ERP exports put on top are fine. Two columns with the same header are read as `Resource` and `Resource (2)`; a column with no header at all becomes `Column 7`. > **Info:** > **Does the file leave my browser?** > > No. Parsing, column detection, date parsing and status translation all run locally, with no network call and no AI. The only thing sent to IoTFlows is the jobs and tasks you confirm on the last step. If you would rather start from a file that already fits, press **Download sample template** on the upload step. It writes `schedule-import-template.csv`, one column per mappable field with an example value, and five rows across two order numbers so you can see the grouping. ## Upload the file 1. Open the **Scheduler** tab of the Production page. See [Open the board](/docs/production/scheduler/#open). 2. Press **Import** in the control bar, at the right of the row above the board. 3. Drag the export onto the drop zone, or click it to browse. ![The Import ERP Schedule dialog on its first step. A five-part step indicator across the top reads Upload, Read file, Check columns, Preview, Import, with Upload active; Match people is not listed yet, because no Assignee column has been mapped. Below it a large dashed drop zone, ringed in violet, carries an upload-cloud icon and the text Drag and drop your ERP schedule (CSV or Excel), or click to browse, and under that a smaller line reading Exported from your ERP: SAP, Epicor, or any order report. We will figure out the columns for you. A Download sample template link sits at the bottom left, and the footer reads Upload a file to continue.](/images/production/prod-import-02.webp) *Uploading the export from your ERP. CSV and Excel are both accepted.* A parsed file shows as a card reading the file name and `412 rows · 17 columns`. Press **Continue** on the card, or the button in the footer. If the workbook has more than one sheet, the dialog lists every non-empty sheet with its row count and waits for you to pick one. It never guesses across sheets. ### If the file will not upload | What you see | What happened | |---|---| | **Please upload a .csv, .xlsx or .xls file.** | The file has another extension. Re-export it. | | **No data found in this workbook.** | Every sheet in the workbook is empty, or has headers with no rows under them. | | **No columns detected. Make sure one of the first rows contains headers.** | The parser found no header-like row in the first ten rows. Delete the preamble above your headers. | | **No data rows found in the file.** | The sheet has headers and nothing else. | ## Read file The **Read file** step has nothing to decide. IoTFlows matches each of your headers to a field by keyword, guesses the date format from the values in your due-date column, seeds the ERP status codes, and loads your parts, operations, machines, members, priorities and existing production jobs so the later steps can match against them. Detection is a header-keyword match, not a reading of your data. Each header is scored against every field's keyword list and assigned to its best match, and no column is used twice, so `Prodn Supervisor` lands on **Assignee** and `Confirmed Finish Date` lands on **Due date** without either being named in the field list. If you have saved a setup whose column headers are exactly this file's headers, it is applied here and the dialog toasts **Applied your saved setup "SAP weekly export"**. See [Save the mapping for next time](#profiles). The step ends on **Check columns** by itself. ## Check the columns This is the step that decides what your file means. Each row names an IoTFlows field on the left and carries a **Column in your file** drop-down on the right. Choose **Not in my file** to leave a field unmapped. A field the detector filled carries a green **✓ auto-matched** chip. A required field it could not fill is lifted into a **Please check these first** section at the top of the panel, and the footer button stays disabled until both required fields are mapped. ![The Check columns step of the Import ERP Schedule dialog, its title bar carrying an Auto-detected chip and its step indicator now showing six steps with Check columns active. Three numbered violet callouts mark the attention section and the two fields inside it. Callout 1 sits on the heading Please check these first, beside an amber warning triangle. Callout 2 and callout 3 sit on the two drop-downs under it, both reading Not in my file: the first belongs to Job / Order number, carrying a red asterisk and the note that rows sharing the same number become one Job, and the second to Task name, noting that each row becomes a task with this name. Above them a Saved setups panel holds a text box reading Save current setup as, for example SAP weekly export, with a Save button. Below them a date panel reads My file's dates look like Month/Day/Year, with a green result reading 09/24/2026 arrow 2026-09-24, and a collapsible section headed Everything else we matched opens on its first row, Part, carrying a green tick chip reading auto-matched against the file's own Material Number column. The footer button, Next - match people, is greyed out.](/images/production/prod-import-04.webp) *Checking the column mapping. Only Job / Order number and Task name are required.* ### Import fields | Field | Section | Required | Matches against | Example | Auto-detected from | |---|---|---|---|---|---| | **Job / Order number** | Required | Yes | Existing production jobs, by title | `PO-1001` | `order`, `job`, `work order`, `wo`, `production order`, `job num`, `job number` | | **Task name** | Required | Yes | Your parts by name, when **Part** is unmapped or does not match | `Engrave Nameplate 2-1/2 x 1` | `task name`, `task`, `material description`, `item description`, `op desc`, `operation description` | | **Part** | Common | No | Your parts, by part number first and then by name | `Y841070` | `material number`, `part number`, `part`, `item number`, `sku` | | **Operation** | Common | No | Operations on the matched part, by name | `Engraving` | `operation`, `op`, `routing operation`, `routing`, `activity`, `process`, `op code`, `op seq` | | **Quantity** | Common | No | Nothing. `1.000` is read as 1 | `25` | `order quantity`, `quantity`, `qty`, `order qty` | | **Due date** | Common | No | Nothing. Parsed with the format you pick below | `11/04/2025` | `confirmed finish date`, `due date`, `due`, `finish date`, `need by`, `ship date` | | **Status** | Common | No | The status table below | `Open` | `system status`, `status`, `order state`, `state` | | **Assignee** | Common | No | Members, by username, email or full name | `jsmith` | `assignee`, `assigned to`, `owner`, `prodn supervisor`, `supervisor`, `operator` | | **Asset / Machine** | Common | No | Machines, by custom name, custom ID, machine name or machine ID | `Laser-01` | `asset`, `machine`, `work center`, `workcenter`, `resource`, `equipment`, `resource id`, `resource desc` | | **Priority** | Advanced | No | Your work order priorities, by name | `High` | `priority` | | **Time estimate** | Advanced | No | Nothing. Reads `2h 30m`, `1.5h`, `90m`, `1d`, or a bare number as minutes | `2h 30m` | `time estimate`, `duration`, `estimate`, `run time`, `runtime`, `hours` | | **Budget** | Advanced | No | Nothing. `$1,250.50` is read as 1250.50 | `500` | `budget`, `cost`, `amount` | | **Description** | Advanced | No | Nothing | `Customer rush order` | `description`, `details`, `long description` | | **Notes** | Advanced | No | Nothing | `Handle with care` | `notes`, `note`, `comment`, `comments`, `remarks` | | **Setup hours** | Advanced | No | Nothing. Added to production hours | `0.5` | `est setup hours`, `setup hours`, `setup time`, `setup` | | **Production hours** | Advanced | No | Nothing. Added to setup hours | `3.0` | `est prod hours`, `prod hours`, `production hours`, `run hours`, `labor hours` | The **Section** column is how the importer classifies a field, not a heading you will see. The panel shows anything needing attention first and folds the rest under **Everything else we matched**. **Setup and production hours beat Time estimate.** When either is mapped, their sum in hours becomes the task's time estimate and a mapped **Time estimate** column is ignored. When none of the three is mapped and the row matched an operation that has a cycle time, IoTFlows estimates the task from that cycle time and the quantity. Columns with no field of their own are listed under **Extra columns** as chips. Click any you want to keep and its values are written into each task's notes as `Customer PO: 44812`, one line per column. ### Tell the importer how to read your dates `11/4/25` is November 4 in one plant and March 11 in another, so the date format is a choice, not a guess. Pick one from **My file's dates look like** and the panel parses the first date in your file next to it: `"11/4/2025" → 2025-11-04` in green, or `"11/4/2025" doesn't match, try another option` in red. The options are month/day/year with a four-digit or two-digit year, `4.11.2025`, ISO `2025-11-04`, compact `20251104`, an Excel date number, and **Auto-detect per value**. A two-digit year of 00 to 69 reads as 2000s, 70 to 99 as 1900s. Dates land at noon in your organization's timezone, so a day-only date cannot drift across a date boundary. `00/00/0000` is read as a deliberate blank. Anything else that will not parse leaves that task with no due date and adds to the **Invalid dates** count on the preview. ### Status translation When a **Status** column is mapped, the panel lists each ERP code it knows about next to what it will become. Change any of them, and the change travels with the saved setup. | ERP token | Maps to | |---|---| | `CRTD` | Open | | `REL` | Open | | `PCNF` | In Progress | | `CNF` | In Progress | | `PRC` | In Progress | | `TECO` | Completed | | `CLSD` | Completed | | `DLV` | Completed | Plain English works with no codes at all. `open`, `new`, `todo` and `backlog` become Open; `in progress`, `started`, `active` and `running` become In Progress; `on hold`, `hold`, `paused` and `blocked` become On Hold; `closed`, `complete`, `done` and `finished` become Completed; `approved`, `accepted` and `signed off` become Approved. A value it does not recognize imports as Open. > **Info:** > **Why did a closed order import as closed when the cell says six things?** > > SAP writes every active status at once, for example `CLSD PRT CNF DLV PRC GMPS MACM SETC`. The importer does not take the first token: it takes the most advanced one it recognizes, in the order Approved, Completed, On Hold, In Progress, Open. A trailing `*` on a truncated token is stripped first. ## Match people The **Match people** step appears only when an **Assignee** column is mapped. It lists every distinct value in that column with the number of tasks behind it, and what each one resolved to. A value matches a member on their username, email address or full name. It does not match on the IoTFlows organization handle, which never appears in an ERP export. Matching is *fuzzy*, meaning a value does not have to be written exactly the way IoTFlows has it. The importer tries the exact value, then the value with case and punctuation flattened, then a match on shared words, then a spelling that differs by no more than two characters. Approximate matches are worth a look: `J. Smith` and `jsmith` both land on Jane Smith, but so could `jsmyth`. ![The Match people step of the Import ERP Schedule dialog, its intro reading These are the people listed in your Prodn Supervisor column. Three stat tiles across the top read Matched 8, Saved for next time 2 and Still unmatched 2, the last in amber. The list below is scrolled to its end, so four of its ten rows show, each pairing a value from the file and its task count with what that value resolved to. M.REYES, 3 tasks, and S.DUVAL, 3 tasks, carry a green tick, a member name and the word saved, and their Assign to member drop-downs hold that member. J.OKAFOR, 2 tasks, and T.NAKAMURA, 1 task, are ringed together in violet: each carries an amber person icon and the text No match, imports unassigned, with a drop-down reading Match automatically. A collapsed Saved people panel below the list carries the count 2, and the footer button reads Continue - 2 left unmatched.](/images/production/prod-import-05.webp) *Matching assignee names from your ERP to IoTFlows members.* For anything left over, open **Assign to member** and pick the person, or pick **Leave unassigned** to say that the value is not a member at all. **Match automatically** puts the row back to whatever the fuzzy match found. Every choice you make here is remembered for this organization, so the same supervisor code resolves by itself on every future import. Open **Saved people** at the bottom of the step to review or remove them. The list lives in this browser, not on the server, so a colleague importing from their own machine starts with an empty one. Leaving a value unmatched is not an error. Those tasks import with no assignee, and the footer button says so: **Continue - 2 left unmatched**. ## Check the preview The preview is exactly what will be created. Five tiles across the top count **New jobs**, **Added to existing**, **Tasks**, **New parts** and **Invalid dates**. **An order number that already has a job is reused, not duplicated.** Its tasks are added under the existing job, and the tile counts it as **Added to existing**. The match is case-insensitive, against the first word of an existing job's title, which is what the importer titles a job it creates. > **Warning:** > **Importing the same file twice** > > Jobs are deduplicated; tasks are not. Re-importing a file you already imported attaches a second copy of every task to the same job. Narrow the export to the rows that are new, or hide the rows you already have before importing. ![The Preview step of the Import ERP Schedule dialog, scrolled to the opened What we matched to your system panel. A violet rectangle rings its Parts block, headed PARTS from Material Number, whose two lines read 9 matched to your existing parts and 4 not in your system yet, so they'll be created as new parts, each with the operation from your file. Blocks for assignees, machines and priorities follow, the assignee one amber: 2 no member matched yet. Below them the editable table shows three rows. Face flange, under order PO-1004, carries a blue tick and the word existing against the part FL-3308 Flange, and the two rows under PO-1005 each carry a green plus and the word new against the part Y-841070.](/images/production/prod-import-06.webp) *The preview. Parts that do not match are auto-created, which is the main source of duplicates after an import.* ### What gets created alongside the tasks A part your file names that your organization does not have is created rather than skipped, because a task with no part and no operation schedules nothing. Those creations are collected in a panel headed **We'll add 4 new items to your system**, where every name is editable. - **A name that already exists wins over creating.** Before a part is slated for creation, its name is checked against your parts, and an exact match links the row to that part instead. The row is tagged **matched by name** in the table. - **Each new part gets at least one operation**, because a part with none cannot carry a task. With an **Operation** column mapped, the operation takes the file's value: a bare `20` becomes `OP20`, a code like `MILL` stays `MILL`. With no operation column, they are named `OP10`, `OP20`, `OP30` by position. - **Parts you already have that carry no operation get one too**, listed separately under **Existing parts that need an operation**. - Every part the import creates is stamped with `[ERP import weekly.xlsx 2026-09-20]` in its description, so the whole set is findable afterwards. On any row you can rename the part, choose **Link to existing…** to point it at a part you already have, or tick **Skip** to create nothing. > **Warning:** > **Auto-created parts are the main source of duplicates** > > A part number your ERP writes as `Y841070` and IoTFlows holds as `Y-841070` will not match, so the import creates a second part, and every count and cost against it lands on the wrong record. Read the new-items panel before importing, and link anything you recognize. ### Fix rows in the table Open **What we matched to your system** for a field-by-field count of what matched and what did not: assignees, machines and priorities that found nothing import blank, and are listed here rather than left for you to find on the board. Everything in the table is editable. Click a cell to change the task name, quantity, due date, time estimate, part, operation, machine, priority, assignee or status, and click the eye icon on a row to hide it. Hidden rows are struck through, tagged **won't import**, and dropped from the totals and from the creation plan. A small amber dot next to a matched value means it was matched approximately rather than exactly. Use **Columns** to show a field your file did not map, or to hide one you do not want to read. The footer button counts what you are about to create: **Import 12 jobs · 47 tasks**. Nothing has been written up to this point. ## Run the import Press the button. The importer creates the new parts and operations first, then each job, then its tasks. A progress bar tracks each phase, and the **Parts & operations** bar appears only on a run that is creating parts. ![The Import step of the Import ERP Schedule dialog after a finished run, with all six steps in the indicator now complete. Three full progress bars read Parts and operations 4 of 4, Jobs 12 of 12 and Tasks 47 of 47, above a green line reading Import complete. Three tiles below count 47 created, 0 skipped and 0 failed. A green strip reads Created 4 new parts for this import. Tagged in each part's description so you can find them later, with an Archive created parts button at its right. A single Download report link sits under it: this run failed nothing, so no Download retry file link appears. The footer holds Back and Done.](/images/production/prod-import-07.webp) *The Import step after it finishes: what was created, what did not fully go through, and the two downloads.* Leave the dialog open while it runs. The close button is disabled until it finishes, and closing afterwards refreshes the board behind it. When it is done you get **Import complete**, a count of tasks created, skipped and failed, and a toast reading **Imported 47 tasks · created 4 parts**. **Download report** writes a CSV with one row per imported row, carrying the result, the reason and the new work order's ID. ### When rows do not import Anything that did not fully go through is listed under the counters, in red when the thing does not exist and amber when it exists but is incomplete. | What you see | What happened | |---|---| | **Part "Y841070" could not be created** | The part was not created. Its tasks still import, without a part or an operation. | | **Could not add operations to "Bracket"** | The part exists with no operation, so its tasks import with no operation. | | **Job PO-1001 could not be created** | The job failed, and none of its tasks were imported. | | **Task "Deburr & Inspect" (order PO-1002) could not be created** | That one task was not created. Everything else in the job was. | | **Task "Anodize" (order PO-1002) was created, but its status did not save** | The task exists and reads Open. Set the status on the board. | | **3 tasks failed. Download the retry file to re-send them** | A toast summarizing the red rows above. | | **Imported with 2 warnings. Some details didn't save (retry file available)** | Everything was created, but a detail on two of them did not save. | **Download retry file** writes a JSON file holding every failed call with its endpoint and payload. It is not something you can re-upload here: it exists so the failure can be diagnosed or replayed by IoTFlows. Send it with your support request. See [Get support](/docs/get-started/get-support/). A generic **Something went wrong** or **An error occurred** means the request failed and nothing was saved. ## Save the mapping for next time A *mapping profile*, called a **saved setup** on screen, is one named copy of everything you decided on the **Check columns** step: the column mapping, the extra columns you kept in notes, the status code map and the date format. ![A cropped detail of the Saved setups panel at the top of the Check columns step. A bookmark icon heads the panel, above a line reading A saved setup is reused automatically when its columns match your file. Load a different one, or save the current setup below. One saved row, tinted green, reads SAP weekly export with a green tick at its left and the word Applied, a Revert link and a trash icon at its right. Under it, ringed in violet, sits the save control: a text box reading Save current setup as, for example SAP weekly export, and a Save button beside it, greyed out because the box is empty.](/images/production/prod-import-08.webp) *Saving the mapping so the next import from the same ERP skips the mapping step.* To save one, type a name into **Save current setup as…** at the top of the **Check columns** step and press **Save**. Name it after the export, not the week: `SAP weekly export` rather than `Week 38`. The next file whose headers are exactly the same, in the same order, picks it up on the **Read file** step by itself and the row reads **Applied**. Headers have to match exactly, which is deliberate: an SAP setup can never be applied to an Epicor file. Change anything after a setup is applied and the row stops reading **Applied**. **Re-apply** puts the saved values back, and **Revert** goes back to what the detector suggested. The trash icon deletes a setup. **You do not need a saved setup for a one-off file.** Detection fills most of the panel on its own, and a setup that only ever matches one file is a name to remember for nothing. Save one when the same export lands every week. > **Warning:** > **Saved setups live in your browser** > > Both saved setups and saved people are stored in this browser for this organization, not on the server. A colleague importing the same export from their own machine gets none of it, and clearing site data loses all of it. Two people who both run imports should each save their own. ## Clean up after an import Work through this in the first few minutes, while the result screen is still open. 1. **Archive the parts you did not mean to create.** **Archive created parts** on the result screen archives every part that import created, in one click. It is the fastest way out of a run that matched nothing, and it is only on screen until you close the dialog. 2. **Find the rest by their tag.** Parts created by an import carry `[ERP import ]` in their description, so an import you cleaned up a day later is still identifiable. Archiving a part cannot be undone from the dashboard, so read the name before you archive it. See [Edit or delete](/docs/production/parts-and-operations/#edit). 3. **Fill in the blanks the matching left.** Assignees, machines and priorities that matched nothing imported empty. The **What we matched to your system** panel counted them, and the board is where you set them: see [Edit in place](/docs/production/scheduler/#inline). 4. **Give the undated tasks dates.** Tasks that imported with an unparseable date have no due date, so they sit outside the Gantt's timeline. See [Schedule work that has no dates](/docs/production/scheduler/#unscheduled). 5. **Delete what should not be there.** **Jobs** in the scheduler control bar opens the job list, where a job can be renamed or deleted. Individual tasks are deleted from the board, and a deleted work order is recoverable on the server for 30 days: see [Undo and redo](/docs/production/scheduler/#undo). Then read the board. An import of a few hundred tasks usually double-books something, and the issues panel is the fastest way to see what: [Find and fix problems in the schedule](/docs/production/schedule-issues/#open). ## See also - [Plan jobs in the Production Scheduler](/docs/production/scheduler/) - [Create and organize parts](/docs/production/parts-and-operations/) - [Give people access to a scheduler board](/docs/production/scheduler-members/) - [Job and scheduler fields](/docs/production/job-fields-reference/) - [Find and fix problems in the schedule](/docs/production/schedule-issues/) --- # Configure tracking for injection molding Source: https://www.iotflows.com/docs/production/injection-molding/ Set up part counting on an injection molding machine, whose shot cycle repeats to the second. Mount the SenseAi on the injection unit or near the hydraulic power unit, time 10 to 20 shots by hand, create the part with one operation per mold, set the operation's algorithm to Continuous Analysis, set QTY/OP to the cavity count, and set the Downtime Filter so brief mold-open pauses do not read as stops. The filter takes 0 to 200%. The Continuous tab of the Auto-Detect modal is single choice, so the machine carries one operation at a time and you re-pick it at every mold change. # Configure tracking for injection molding Count parts on a machine whose shot cycle repeats to the second. An injection molding machine runs the same cycle over and over: clamp, inject, hold, cool, eject. [Continuous Analysis](/docs/production/choose-an-algorithm/#continuous) is the algorithm for that case: it divides running time by the cycle time you enter instead of hunting for one burst per part, which is what you want on a machine whose trace never falls back to the stopped level between shots. Allow 30 to 45 minutes for the first machine. **Before you start** - A SenseAi or SenseAi Embedded tied to the machine. Contact IoTFlows to tie your sensors to an asset, see [Get support](/docs/get-started/get-support/). - Sign in as an Organization Owner or Organization Administrator, see [Roles reference](/docs/admin/roles-reference/). ## Why Continuous Analysis fits a molder Four things about molding point at the same algorithm. - **The cycle time is known and it repeats.** Every shot takes about the same time, so dividing running time by that number is accurate. - **The pauses are short.** Mold open, ejection and mold close interrupt the trace for a second or two and should not read as stops. - **The volume is high.** Hundreds or thousands of shots a day, so a detector that misreads one burst in fifty is wrong by hundreds of parts. - **The rhythm is steady.** Once the machine is at temperature it holds the same cycle until something interrupts it. **You do not need a second sensor to count parts.** SenseAi derives part counts and cycle times from the same vibration trace that produces the running and stopped state. **Choose [Discrete Analysis](/docs/production/choose-an-algorithm/#discrete) instead when the machine waits between shots.** A molder where an operator loads inserts by hand, or takes parts off before the next cycle starts, looks more like a machining center than a molder to the sensor. ## Mount the sensor on the machine ![A horizontal injection molding machine, with the clamp unit and mold area on the left and the injection unit, hopper and hydraulic power unit on the right](/images/production/prod-mold-01.webp) *A horizontal injection molding machine. The injection unit and the hydraulic power unit, on the right of the machine, both carry the cycle.* 1. Mount on flat ferrous metal close to the injection unit or the hydraulic pump. Both work through every shot, so both carry the cycle. 2. Do not mount on a guard, a cover or a sheet-metal panel. The magnet holds, and what the device reads is the panel's own ringing rather than the machine's, see [Choose a mounting location](/docs/hardware/install-senseai/#mounting). 3. Stay clear of the barrel and its heater bands. [SenseAi Embedded](/docs/hardware/senseai-embedded/) is rated to 60 °C (140 °F), and a barrel zone runs far past that. 4. Connect power and put the device on Wi-Fi, see [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/). 5. Run 10 or more complete shots while you calibrate, so the thresholds are set against a molding cycle and not against a dry cycle or a warm-up, see [Calibrate SenseAi and SenseAi Embedded](/docs/hardware/calibrate-senseai/). Verify the mount rather than judging it by eye. Run the machine molding, then stop it, and confirm the two read differently. ## Measure the shot cycle Continuous Analysis divides running time by this number, so the accuracy of the number is the accuracy of the count. Measure it, do not take it off the machine's setup sheet. 1. Let the machine run normally until it settles at temperature. 2. Time 10 consecutive shots with a stopwatch, from shot start to shot start. 3. Average them. For example, 22, 21, 23, 22, 21, 22, 23, 22, 22 and 22 seconds average to 22 seconds. 4. Note the pauses between shots as well. In molding they usually run 1 to 5 seconds, and they are what the downtime filter is for. **Time the shot, not the part.** On a multi-cavity mold one shot makes several parts, and the cavity count is set separately on the operation. ## Create the part and its operation 1. Open **Parts List** at `/production?select=parts_list`. 2. Click **+ Add Part**. 3. Enter a **Part Name**, for example `Automotive Clip`. **Part Description** is optional. 4. Under **Assign Operations**, name the operation after the mold, for example `MOLD-CLIP-4CAV`, and describe it, for example `4-cavity mold, black ABS`. 5. Enter **Operation Cycle Time** in the h, m and s boxes. For a 22-second shot, that is 22 in the s box. 6. Enter a standard deviation in the boxes beside it. Leaving either at zero blocks the part with **Cycle time and standard deviation must be greater than zero**. 7. Add the machines that run this operation, then click **Add Part**. 8. Back on the Parts List, expand the part, click the operation's **Algorithm** cell and choose **Continuous Analysis**. It saves as you pick it. 9. Set **QTY/OP** to the number of cavities in the mold. A four-cavity mold is 4. *Quantity per cycle* is the parts one cycle makes, so on a molder it is the cavity count. A four-cavity mold running 100 shots made 400 parts, and the same mold left at 1 reports a quarter of its real output. Full field reference on [Create parts and operations](/docs/production/parts-and-operations/). **Create one operation per mold, not one per part number.** If you run the same clip in a two-cavity and a four-cavity mold, the cavity count differs, so the two need separate operations: `MOLD-CLIP-2CAV` and `MOLD-CLIP-4CAV`. ## Set the downtime filter A *downtime filter* converts any stop shorter than a set percentage of the cycle time into uptime, so brief in-cycle pauses stop reading as stops. It is the one field only Continuous Analysis has: the **Downtime Filter** column appears on the Parts List once the part carries a continuous operation, and nowhere else. 1. On the Parts List, expand the part. 2. Click the operation's **Downtime Filter** cell and type a percentage. 3. Press Enter or click away. It saves on blur. The field takes **0 to 200%** and clamps anything higher. **200% is the recommended starting point for a molder.** On a 22-second cycle that converts every stop under 44 seconds into runtime, leaving the real interruptions in the downtime record: material shortages, mold problems, an operator stopping the machine. Check that 44 seconds against your own stops before you accept it, because a 40-second material hiccup now reads as production. If stops in that range are worth seeing, come down. At the same cycle, 50% still covers an 11-second pause, which is twice the longest mold open. **You do not need a filter on a machine whose pauses never reach the downtime record.** Leave the field empty, run a shift, and read the [Downtimes report](/docs/monitoring/downtimes/#pareto) first. A filter set on a machine that has no short pauses only hides its real ones. ## Assign the operation to the machine 1. Open **Assets** at `/assets` and click the machine. 2. Click **Auto-Detect** to open **Select Auto-Detect Operations**. 3. Open the **Continuous** tab. A SenseAi machine shows the **Discrete** and **Continuous** tabs only, because Counter is BeamTracker's algorithm. 4. Select the operation's radio button. This list is single choice, not checkboxes. The dashboard saves as you pick, confirms with **Continuous Auto-Classification Set** and closes the modal. There is no submit button on this tab, only **Close**. To stop detection without choosing another operation, select **No Continuous Detection**. Selecting a continuous operation clears any discrete operation the machine was set to, and the modal says so above the list. The full flow, including detected cycle times and the Parts List entry point, is on [Detect operations automatically](/docs/production/auto-detect-operations/). ## Handle mold and material changes Because the **Continuous** tab is single choice, **a molder carries one operation at a time.** A mold change is two jobs: swap the mold, then re-pick the operation. Skipping the second counts the new mold's shots against the old mold's cycle time and cavity count, which is the most common reason a molder's numbers go wrong after a changeover. A color or material change is different. Same mold, same operation, nothing to re-pick, and 15 to 30 minutes of downtime worth seeing rather than absorbing. 1. Create a **Material Change** category, see [Create a category](/docs/monitoring/downtime-categories/#create). Add **Mold Change** while you are there. 2. Have operators classify the stop when it happens, see [Classify a downtime event](/docs/monitoring/classify-downtime/). 3. If changeovers are frequent and always look the same, write a rule so they classify themselves, see [Classify downtime automatically](/docs/monitoring/auto-downtime-rules/). 4. After two to four weeks, read the total off the Pareto chart on the [Downtimes report](/docs/monitoring/downtimes/#pareto). ## Validate the count 1. Let the machine run normally for one to two hours. 2. Open **Shift Production** at `/production?select=part` and read the count for the operation. 3. Work out what it should be. One hour of running time is 3,600 seconds, so at 22 seconds a shot that is 163 shots, and a four-cavity mold makes 652 parts. 4. Compare the two. Within 5 to 10% is right. 5. Open **Downtimes** at `/assets?select=downtimes` and confirm real stops are recorded while mold-open pauses are not filling the list. Accuracy bands and what to do at each one are on [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/#validate). ## What to expect from a molder *Uptime* is availability: the share of the window the machine spent running, see [Uptime](/docs/monitoring/metrics-reference/#uptime). How much of the cycle a person carries sets the ceiling, so a machine an operator tends and a lights-out cell are not comparable. | How the machine runs | Uptime to expect | |---|---| | An operator loads inserts or takes parts off | 60 to 75% | | Fully automatic, nobody in the cycle | 75 to 85% | | Lights-out, running unattended around the clock | 85 to 90% | Set the goal on [Set OEE and utilization goals](/docs/monitoring/oee-goals/). **Start from your own baseline plus 5 to 10%, not from the table.** A goal the machine has never met teaches operators to ignore the number. If the process has a quality check, log rejects separately so the good count is the number you compare, see [Log scrap](/docs/production/log-scrap/). ## Troubleshoot a molder | Symptom | Cause | Fix | |---|---|---| | Count runs high | The downtime filter is converting real stops into runtime | Lower **Downtime Filter**, then check the Downtimes report for the stops that reappear | | Count runs low | Mold-open pauses are recorded as downtime, so running time is short | Raise **Downtime Filter**. At 200% you are at the ceiling, so set **Downtime Threshold** with **Treat short downtimes as uptime** instead, see [Handle short stops](/docs/hardware/calibrate-senseai/#short-stops) | | Count is a fixed fraction of real output, and the fraction matches the mold | **QTY/OP** is still 1 on a multi-cavity mold | Set **QTY/OP** to the cavity count. The count corrects immediately | | Count is off by the same ratio all shift, and changing the filter does nothing | The entered cycle time no longer matches the shot | Re-time 10 shots and update **Ideal Operation Cycle Time** on the Parts List. Continuous Analysis divides by it, so the count is only as good as that number | | Numbers went wrong at a changeover and stayed wrong | The operation was not re-picked, so shots are counted against the previous mold | Re-pick the operation on the **Continuous** tab, see [Assign the operation to the machine](#assign) | | Uptime reads low on a shift the machine ran through | The running threshold sits above the molding trace, so part of the cycle reads as stopped | Lower the **Running Threshold**, see [Set the running and stopping thresholds](/docs/hardware/calibrate-senseai/#thresholds) | | The downtime list fills with one-minute stops | Pauses the operation's filter does not reach are still recorded | Set **Downtime Threshold** with **Treat short downtimes as uptime** on, see [Handle short stops](/docs/hardware/calibrate-senseai/#short-stops) | Counts that stay wrong after the cycle time and the filter are both right are on [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/). ## See it in a plant - [Injection molding machine monitoring](https://www.iotflows.com/solutions/injection-molding-machine-monitoring) — Shots and cavities counted on every press, mold-open pauses filtered, and mold maintenance on the count. ## See also - [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/) - [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/) - [Track production against shift goals](/docs/production/shift-production/) - [Calibrate SenseAi and SenseAi Embedded](/docs/hardware/calibrate-senseai/) - [Configure tracking for CNC mills and lathes](/docs/production/cnc-machines/) --- # Job and scheduler fields Source: https://www.iotflows.com/docs/production/job-fields-reference/ Every field a production task can hold, the five statuses it moves through, the fields a work session carries, and the 24 columns the scheduler table exports. Title is the only required field on a task, and a parent job carries no status of its own. Six export columns are always on, the CSV adds a Part column the table does not have, and two more ship visible, so a default export is nine of the 24. Maintenance work orders are a different object with a different field list. # Job and scheduler fields Every job field, every scheduler column, and every export column, in one place. Production stores two objects with the same shape and different work to do. A *job* is the order: a part, a quantity, a due date. A *task* is one operation of that job on one machine. The task is what the board schedules, what an operator runs, and what nearly every field below belongs to. See [Job, task, or work order?](/docs/production/overview/#naming). > **Info:** > **Looking for maintenance work order fields?** > > Those are on [Work order fields and statuses](/docs/maintain/work-order-fields/). The two objects share one API endpoint and the same five underlying statuses, and little else: a maintenance work order carries a group, a checklist and a recurrence, while a production task carries an operation, a part, a quantity and work sessions. ## Job fields **Title is the only required field.** Everything else can stay empty, and the create forms fill several of them in for you once you pick a machine. See [Create a production work order](/docs/production/create-a-job/). **Editable inline** says where you can change the field without opening the task, in the board's [Table](/docs/production/scheduler/#table) and [Kanban](/docs/production/scheduler/#kanban) views. **Appears in CSV** is the scheduler table export, listed in full under [Scheduler CSV columns](#csv). | Field | Type | Required | Editable inline | Appears in CSV | |---|---|---|---|---| | **Title** | Free text, overwritten by the operation name | Yes | Table, Kanban | **Title** | | **Description** | Rich text | No | Table, Kanban | **Description** | | **Asset** | One machine | No | Table, Kanban, by picker | **Asset** | | **Part of Job** | One parent job | No | Table, Kanban, by picker | **Job** | | **Operation** | One operation on one part | No | Table, Kanban, by picker | **Operation**, and **Part** | | **Quantity** | Whole number of pieces | No | Table, Kanban | **Quantity** | | **Due Date** | Date and time | No | Table, by date picker. Kanban, as a duration | **Due Date** | | **Time Estimate** | `2h 30m`, `90m`, `1 day 3 hours`, or a bare number of minutes | No | Table, Kanban | **Time Estimate** | | **Priority** | One entry from your organization's priority list | No | Table, by picker | No | | **Assignees** | People and teams, any number | No | Table, Kanban, by picker | **Assignees** | | **Budget** | Number, no currency symbol | No | Table, Kanban | **Budget($)** | | **Notes** | Free text | No | Table, Kanban | **Notes** | | **Dependency** | One other production task | No | Table, Kanban, by picker | **Dependent on** | | **Required Parts** | Lines of part, location and amount | No | No. The cell opens the task | **Parts Required** | | **Create/Release Parts** | Lines of part, location and amount | No | No. The cell opens the task | **Create/Release Parts** | | **Images** | JPEG, PNG, GIF, WebP, BMP, SVG | No | Table, from the cell. Kanban, under **Details** | **Images**, as file names | | **Files** | Any file type | No | Table, from the cell. Kanban, under **Details** | **Attached Files**, as file names | | **Work Sessions** | See [Session fields](#session-fields) | No | Through the clock icon in the **Quantity Made** cell | No. Sessions feed **Quantity Made**, **Labor Hours** and the columns computed from them | | **Status** | One of the five in [Job statuses](#statuses) | Created at **Not Started** | Table, Kanban, from the status chip | **Status** | | **Quantity Made** | Number, summed from sessions or set as an override | Derived | No | **Quantity Made** | | **Labor Hours** | Duration, from sessions or an override | Derived | Table, Kanban | **Labor Hours**, in hours | | **Machining Hours** | Duration, machine time recorded against the task or an override | Derived | Table, Kanban | **Machining Hours**, in hours | | **Actual Cost** | Currency, computed from the two hour figures | Computed | No | **Actual Cost** | | **Timeline** | Percentage, computed | Computed | No | **Timeline** | | **Quantity Progress** | `made/ordered`, computed | Computed | No | **Quantity Progress** | | **Comments** | A thread on the task | Added by people | No. The cell opens the comments panel | No | | **Number** | Whole number, assigned when the task is created | Automatic | No | No | **You do not need most of this.** A task with a title, a machine, an operation, a quantity and a due date schedules and runs. Budget and the two hour overrides exist for plants costing their schedule in [Insights](/docs/production/production-insights/), and a plant that is not doing that should leave all three empty rather than fill them with guesses. The two create forms carry different subsets. The Work Queue form offers ten chips and no **Priority**, **Due Date**, **Assignee**, **Budget** or **Notes**; the board's **Create** dialog offers all fifteen, most of them with a keyboard shortcut. See [Create a production work order](/docs/production/create-a-job/#open). > **Warning:** > **The Kanban card's Due field takes a duration, not a date** > > Click the due date on a kanban card and the input reads `e.g., 2h, 30m`. What you type is a length of time from now: `2h` sets the due date to two hours from this moment, and it writes the same figure into **Time Estimate** on the way past. > > The field also only appears on a task that already has a due date. To set or change a date properly, use the **Due Date** column in Table view. See [Edit in place](/docs/production/scheduler/#inline). ### The job itself A parent job is created from **Create new job** in either create form, or from **Jobs** on the board. It holds four fields. | Field | Type | Required | Notes | |---|---|---|---| | **Job name** | Free text | Yes | The title every task on the job shows in its **Job** chip | | **Part** | One part, or a new one typed in | No | The part the job makes. Its operations are what the job can fan out into | | **Qty** | Whole number | No | Copied onto every task the job creates | | **Due** | Date, with a time defaulting to 17:00 in your organization's timezone | No | Copied onto every task, unless the job links its tasks in sequence and works their dates backward from it | **A job has no status of its own.** Status lives on the tasks, so a job is finished when its tasks are, and a job bar on the Gantt is a rollup of the bars beneath it. Turning on **Create a workorder for each operation** posts one task per operation on the part's *routing*, its ordered list of operations. That is the point at which the fields above start being copied, so a part with no operations creates a job and nothing else. ## Job statuses Five statuses, and the labels every production surface gives them. | Status | Means | Set by | Next states | |---|---|---|---| | **Not Started** | Nobody has started it. Every task is created here | Creation, the status chip, an ERP import | **In Progress** from **Start**. Any status from the chip | | **In Progress** | A work session is open on it | **Start** or **Resume** in the job runner, the status chip, an ERP import | **On Hold** from **Pause**, **Completed** from **Complete Job**. Any status from the chip | | **On Hold** | Paused between sessions. No session is open | **Pause** in the job runner, the status chip, an ERP import | **In Progress** from **Resume**. Any status from the chip | | **Completed** | The work is done and the last session is closed | **Complete Job** in the job runner, the status chip, an ERP import | **In Progress** from **Reopen Job**. Any status from the chip | | **Approved** | Completed work that somebody has signed off | The status chip and an ERP import only. No button in the product sets it | **In Progress** from **Reopen Job**. Any status from the chip | **The status chip does not enforce an order.** Both board menus will take any status from any other, including straight from Not Started to Approved, with one exception: the Table's menu grays **Not Started** out, so only a kanban card can send a task back to the beginning. The job runner is the surface with rules. It will not complete a paused task, and it offers **Reopen Job** rather than a status list. See [Job actions](/docs/production/run-a-job/#actions-table). Choosing **On Hold** or **Completed** from the chip opens the same session capture the runner's **Pause** and **Complete Job** dialogs use, so the count and scrap are recorded before the status changes. ### Where each status counts | Surface | Treated as live work | Treated as finished | |---|---|---| | Scheduler **Completion status** filter | **Active**: Not Started, In Progress, On Hold | **Completed**: Completed and Approved, over a lookback period | | Work Queue, and a machine's **Jobs** tab | Everything else | Completed and Approved leave the list | | Gantt bars | Everything else | Completed and Approved draw at reduced opacity, never read as overdue, and drop out of the late-predecessor check | | Insights **Workorders** KPI | Anything that is not Completed or Approved | Completed alone. An Approved task counts in neither chip | The Insights row is the one that surprises people. See [Completion and on-time KPIs](/docs/production/production-insights/#kpis) before you read a completion percentage on a board that approves work after closing it. ## Session fields A *session* is one run of a task: a start, an end, the good parts made and the scrap logged against them. Sessions are what **Quantity Made**, **Labor Hours** and the shift and cost reports are built from. | Field | Type | Required | Notes | |---|---|---|---| | **Start** | Date and time, to the minute | Yes | Cannot be in the future, and cannot overlap another session on the same machine | | **End** | Date and time, to the minute | Yes, except on a running session | Must be after **Start**, and cannot equal it | | **Good Parts** | Whole number, stepper or typed | No | Summed across sessions into the task's **Quantity Made** | | **Scrap** | Rows of quantity, reason and note | No | A row with a quantity and no reason blocks the save | | **Session Notes** | Free text | No | The only place a session records why something happened | | **Operation** | One operation on the task's part | No | Shown where the host offers it. Changing it here changes the work order, and therefore every other session on it | | **Duration** | Computed from **Start** and **End** | Computed | Shown beside the **Session Time** header | A session records no operator name. The Job History card shows the times, the counts, the scrap breakdown and the note, and nothing that says who ran it, so put anything the next shift needs into the note itself. See [Session history](/docs/production/run-a-job/#history) and [Log scrap and manage scrap reasons](/docs/production/log-scrap/). Sessions staged inside a create form are held on the form and posted after the task exists. Everywhere else they save immediately. ## Scheduler CSV columns The **CSV** button in [Table view](/docs/production/scheduler/#export) writes the columns the table is showing, in the order you dragged them. Twenty-four columns are available. Six are always on, the **Part** column is added by the export alone, and the remaining seventeen are the ones you turn on in the column menu. The numbering below is the default order. A default export is nine columns: the six always-on ones, the **Part** column, and the two that ship visible, **Quantity Progress** and **Status**. | # | Column | Source field | Notes | |---|---|---|---| | 1 | **Title** | `workorder_title` | Always exported | | 2 | **Assignees** | `assigned_to_users`, `assigned_to_teams` | Full names then team names, comma separated. A placeholder user named `Unnamed` is skipped | | 3 | **Operation** | `workorder_operation.operation_name` | Always exported | | 4 | **Part** | `workorder_operation.part_name` | The export's own column. The table draws the part and the operation in one cell, so the CSV splits them | | 5 | **Quantity** | `workorder_quantity` | The quantity ordered, not the quantity made | | 6 | **Asset** | `workorder_asset` | The machine's custom name, falling back to its catalog model name | | 7 | **Job** | `parent_workorder.workorder_title` | Empty on a task with no parent job | | 8 | **Due Date** | `workorder_due_timestamptz` | ISO 8601 in UTC, for example `2026-09-24T21:00:00.000Z`. Empty on an unscheduled task | | 9 | **Time Estimate** | `workorder_duration_min` | Minutes, as a plain number | | 10 | **Quantity Made** | Override, else the auto-detected count | `0` when there is neither | | 11 | **Labor Hours** | Override, else auto-detected | Minutes converted to hours, rounded to two decimals | | 12 | **Machining Hours** | Override, else auto-detected | Minutes converted to hours, rounded to two decimals | | 13 | **Actual Cost** | Computed | Labor hours at the assignees' average wage, plus machine hours at the machine's hourly rate. Falls back to $50 and $100 an hour when a rate is missing | | 14 | **Timeline** | Computed | Labor plus machining hours against the estimate, as a percentage. Empty without an estimate or without logged time | | 15 | **Quantity Progress** | Computed | `made/ordered`, for example `180/250`. Empty when nothing was ordered | | 16 | **Status** | `workorder_status_uuid` | One of the five labels above | | 17 | **Parts Required** | `workorder_requires_parts` | Every line as `Part xQty`, semicolon separated. Not the chip's summary | | 18 | **Create/Release Parts** | `workorder_creates_parts` | Same format | | 19 | **Dependent on** | `dependent_on_workorder` | The predecessor's operation name, falling back to its title | | 20 | **Budget($)** | `workorder_budget` | A number with no currency symbol | | 21 | **Notes** | `workorder_notes` | The task's notes field | | 22 | **Description** | `workorder_description` | Formatting is stripped | | 23 | **Images** | `workorder_files` | Names of the image files, semicolon separated | | 24 | **Attached Files** | `workorder_files` | Names of everything that is not an image | **Actual Cost and Insights price the same task differently.** The column above uses the assignees' own wage and the machine's own rate, while Insights prices every task at two flat rates you type into the report. Do not compare the two numbers. See [Set hourly rates](/docs/production/production-insights/#rates). **Comments** is the one table column with no export column. It is available in the column menu, it is in the default column order, and the CSV writer skips it, so a table showing comments still exports 24 columns at most. The file is named `scheduler-tasks-` and today's date, written UTF-8 with a byte order mark and CRLF line endings, with any value containing a comma, a quote or a line break wrapped in quotes. Grouping is ignored: the file is one flat list of every task the filters loaded. Every other export in the product is in [Exports reference](/docs/monitoring/exports-reference/#board-csvs). ## Kanban card fields **Card fields**, the gear on the Kanban control bar, decides what each card carries. Thirteen fields are available, six are on out of the box, and the choice is stored in your browser rather than on the board. | Field | Shows | On by default | |---|---|---| | **Hero Image** | The first image attached to the task, full width across the top of the card | Yes | | **Assignee** | Avatars of the people and teams on the task | Yes | | **Qty Progress** | Parts made against parts ordered, with a bar | Yes | | **Description** | The task's description | No | | **Operation** | The operation and its part | No | | **Asset** | The machine's picture and name | Yes | | **Quantity** | The quantity ordered | No | | **Job** | The parent job's title | Yes | | **Due Date** | The due date, in red once it has passed | No | | **Dependencies** | The task this one waits on | No | | **Details** | An expandable block holding Timeline, Labor Hours, Machining Hours, Actual Cost, Notes, Images and Files | Yes | | **Timeline** | Logged time against the estimate | No | | **Budget** | The budget figure | No | The list follows the grouping. Under **Group by operator** the **Assignee** option is replaced by **Machine**, because a card sitting in a person's column does not need their name on it. **Job** is dropped from the cards under **Group by job** for the same reason, without leaving the menu. A field that is switched on but empty shows nothing. A card with no attached image never renders a hero image, however the menu is set, which is why two cards in the same column can be different heights. See [Compact mode and card fields](/docs/production/scheduler/#fields). ## See also - [Create a production work order](/docs/production/create-a-job/) - [Plan jobs in the Production Scheduler](/docs/production/scheduler/) - [Exports reference](/docs/monitoring/exports-reference/) - [Work order fields and statuses](/docs/maintain/work-order-fields/) - [Start, pause, and complete a job](/docs/production/run-a-job/) --- # Log scrap and manage scrap reasons Source: https://www.iotflows.com/docs/production/log-scrap/ Scrap is recorded against the work session that made it, from the Scrap button in the job runner's action rail, and every entry needs a reason code drawn from one organization-wide list. The Pause Session dialog, the Complete Job dialog and the Job History session editor hold that session's scrap as editable rows and refuse to save a row that has a quantity and no reason. Reason codes are created, renamed and deleted inside the Log Scrap dialog itself, and deleting one makes every entry already logged against it print its raw identifier. Scrap never comes out of the good count. # Log scrap and manage scrap reasons Record a bad part against a cause, and keep the list of causes short enough to act on. *Scrap* is a part a job produced that you cannot ship. You record it against the [work session](/docs/production/run-a-job/) that made it, never against the machine or the shift, so a scrap entry always carries the job, the operator and the time with it. Every entry needs a *scrap reason code*: a named cause, held in one list that the whole organization shares. The reason is not optional, and there is no free-text alternative to it. **Before you start** - A job in progress. See [Start the job](/docs/production/run-a-job/#start). - Nothing on this page is role-gated. Anyone who can open a job can log scrap against it and change the organization's reason list. ## Log scrap during a job 1. Open the running task from the Work Queue. The runner is at `/production/work-queue/`. 2. Press **Scrap** in the action rail, below the part counter. 3. Set **Scrap Quantity** with the minus and plus buttons. It opens at 1 and will not go below it. 4. Pick a reason. See [Choose a reason](#reason). 5. Add a note if the reason alone does not explain the failure. See [Add a note](#note). 6. Press the red button, which reads **Log 3 Scrap** for a quantity of 3. The dialog closes and **Scrap recorded** confirms the write. The entry lands on the session that is open right now, and the job's scrap total moves with it. ![A cropped detail of the job runner's left action rail on a running job. A This Session counter reads 0 between minus and plus buttons, over the line Total: 24 / 40 and an Add Parts button. Below them a Scrap button carries a trash icon and its label in red and sits ringed in violet. A Complete Job button in green follows below it.](/images/production/prod-scrap-01.webp) *The Scrap button in the job runner's action rail, below the part counter and above Complete Job. It is grayed out until the job is In Progress.* > **Info:** > **Not sure why Scrap is gray?** > > **Scrap** is disabled unless the job's status is In Progress. A paused job has no open session to write to, so press **Resume** first. See [Pause and resume](/docs/production/run-a-job/#pause). Two entries on the same reason inside one session become one entry. The quantities are added, so logging 2 against **Tool wear** and then 3 more leaves a single entry of 5 rather than two of its own. The quantity is a stepper with no keyboard entry, so 30 parts is 30 presses. For a batch that size, or for scrap you are reconstructing at the end of a run, use the scrap rows in the **Pause Session** or **Complete Job** dialog instead, where the quantity is a field you can type into. See [Log several reasons at once](#batch). ## Choose a reason The reason list belongs to the organization, not to the machine, the part or the operation. The same codes appear on every job, so one you add for a press is live on the mill down the row. Tap a tile to select it. The tile turns red and the footer button becomes active. The dialog offers no free-text box and no way to skip the question, so the button stays disabled until a code is selected. A list can still hold a catch-all such as **Not Entered**. It is an ordinary code on an ordinary tile, and it answers nothing: scrap logged against it reports as scrap with no cause. Rename it to a real cause rather than deleting it, because entries already logged against it break when the code goes. See [Rename or delete a reason](#edit-reason). ![The Log Scrap dialog headed Log Scrap over Record defective or rejected parts. A Scrap Quantity block holds a large red 3 between minus and plus buttons. Below it a Scrap Reason header carries an Add New button at the right, then seven tiles in two columns reading Dimensional out of spec, Programming error, Incorrect setup, Surface finish, Mishandling damage, Tool wear / broken tool and Not Entered, each with a pencil and a trash icon. The whole grid is ringed in violet, and the Tool wear / broken tool tile inside it is filled red. A Notes box holds the line Blade dulled through the second bar. Three billets came off with torn faces, and a footer carries Cancel and a red Log 3 Scrap button.](/images/production/prod-scrap-02.webp) *The Log Scrap dialog: a quantity stepper over a two-column grid of the organization's reason codes, with Tool Wear selected in red. The footer button stays disabled until a reason is picked.* Keep the reasons to causes you can act on. *Operator error* is not a cause, because nothing follows from reading it in a report. *Tool wear* and *material defect* each send the next conversation somewhere useful, one to the tool crib and one to receiving. You do not need a code per part number. The list is organization-wide and has no grouping, so a code per part becomes a list nobody reads to the bottom of. ## Add a note **Notes** is optional free text. Use it for the detail the code cannot carry: the tool number, the heat lot, which of the four cavities failed. A second entry on the same reason replaces the note rather than appending to it. Leave the box empty and the earlier note survives the merge. Put the whole story in one note rather than spreading it across two entries. ### Scrap reason fields | Field | Required | Notes | |---|---|---| | **Scrap Quantity** | Yes | A stepper in **Log Scrap**, minimum 1. In the session dialogs it is a typed field that accepts 0, and a row left at 0 is dropped when the dialog saves | | **Scrap Reason** | Yes | One code from the organization-wide list. **Log Scrap** will not submit without it, and a session will not save while any row has a quantity and no reason | | **Notes** | No | Free text on the entry. A later entry on the same reason replaces it | | **Reason name** | Yes | The code's own label, set when you create it. A code has no description, no color, no severity and no owner | ## Log several reasons at once Scrap belongs to the session, and a session's whole scrap list is editable in three places: the **Pause Session** dialog, the **Complete Job** dialog, and the session editor inside **Job History**. Each carries a **Scrap** heading with the running total beside it and an **Add Scrap** button. Every press of **Add Scrap** adds a row. A row holds a quantity you can type or step, a **Select reason...** dropdown, a trash icon that removes the row, and a **Scrap note (optional)** line of its own. One row per cause, so a session that lost parts three ways reads as three rows. Every row with a quantity above zero needs a reason. The dropdown outlines itself in red the moment a row has a quantity and no reason, before you save anything, so an unexplained row is visible while you are still typing. Save with one still missing and the dialog stops with **Please select a reason for all scrap entries** and writes nothing. Pick a reason for it, or set the row to 0, which drops the row on save. ![The Complete Job dialog for OP10 Saw. Under a Parts Made This Session stepper reading 0 over of 40 target, a Scrap heading reads Scrap (6) with an Add Scrap button at the right. Three rows follow, each with a quantity between minus and plus buttons, a reason dropdown and a trash icon, over its own scrap note line. The rows read 3 Tool wear / broken tool, 2 with an empty Select reason dropdown outlined in red and the whole row ringed in violet, and 1 Dimensional out of spec. A New Reason Code link, a Session Notes box and a footer with Cancel and Complete Job sit below them.](/images/production/prod-scrap-03.webp) *The Complete Job dialog's Scrap section with three rows. The middle row has a quantity and an empty reason dropdown outlined in red, and the job will not close until it is filled.* **New Reason Code**, under the rows, creates a code without closing the dialog. It cannot rename or delete one. See [Rename or delete a reason](#edit-reason). Use the rows when you are accounting for a whole run at the end of it, and the **Scrap** button when a part fails in front of you. > **Warning:** > **Why does an old session open with an unexplained row?** > > A session recorded before its scrap was itemized carries a total and no breakdown. The dialog seeds a single row with that total and an empty reason, so the next pause or complete asks you to name it. Setting the row to 0 clears the block, and it clears the session's scrap total with it. ## Create a scrap reason code 1. Press **Scrap** on any running job. 2. Press **Add New**, at the right of the **Scrap Reason** heading. 3. Type the name. Enter saves it, Escape cancels. 4. Press **Add Reason**. **Scrap reason code added** confirms the write, and the new code is selected for the entry you were in the middle of. It is live on every job in the organization from that moment. An organization with no codes yet reads **No reason codes yet** where the list would be, and no scrap can be logged until one exists. > **Warning:** > **Who can change the list?** > > Nothing here is role-gated, so anyone who can open a job can add, rename and delete a code for the whole organization. Agree the list before the floor starts adding to it, or it fills with near-duplicates like *Tool Wear*, *tool wear* and *worn tool*, which split one cause across three lines of every report. ## Rename or delete a reason Both controls sit on the tile itself, inside the **Log Scrap** dialog. To rename, press the pencil. The tile expands into a text field across the full width of the list. Edit the name and press **Save**, or press Enter. **Scrap reason code updated** confirms it. Renaming is safe for history. An entry stores the code rather than its text, so every scrap already logged picks up the new name. To delete, press the trash. **Delete Reason Code** asks you to confirm, and **Delete** removes it. > **Danger:** > **Deleting a code breaks the entries that used it** > > Job History looks each entry's reason up in the live list. Once the code is gone the lookup fails, and every scrap entry already logged against it prints a raw identifier where its name used to be. > > Rename a code that has gone out of use. Delete only one that nothing was ever logged against. Two surfaces carry the pencil and the trash: the **Log Scrap** dialog on the job runner, and the same dialog on a machine's **Production** tab. The session dialogs can add a code but not change one, and the mobile scrap sheet can do neither. ![The Scrap Reason section of the Log Scrap dialog, cropped. An Add New button sits at the right of the heading. Below it, six reason tiles in two columns each carry a name, a pencil icon and a trash icon, and Tool wear / broken tool is filled red as the selected reason. A seventh, Surface finish, is open for editing and spans both columns as a text field over a green Save button and a gray cancel button.](/images/production/prod-scrap-04.webp) *The reason list inside Log Scrap, with Add New above it and a pencil and a trash icon on every tile. One tile is open for renaming, expanded across both columns.* ## On mobile The mobile job page logs scrap from the **Scrap Parts** tile in **Production Summary**, which opens a bottom sheet headed **Log Scrap**. The sheet takes a typed **Quantity**, a **Reason Code** dropdown marked required, and optional **Notes**. Leave the reason empty and the field turns red under the line **A reason code is required**, and the button stays disabled. The sheet reads the organization's codes but cannot add to them. Create the code you need on a desktop runner first. See [Create a scrap reason code](#create-reason). ## Where scrap appears **Scrap does not come out of the good count.** Logging 3 scrap lowers no parts-made figure anywhere. Good and scrap are two parallel numbers, so if those 3 parts were already counted as made, correct the count yourself from the part counter. See [Log good parts](/docs/production/run-a-job/#log-parts). Once logged, scrap reaches three places: - **The job.** **Job History** totals it across every session in a **Scrap** tile, and each session card carries a **Scrap Breakdown** with one line per reason, its note and its quantity. See [Session history](/docs/production/run-a-job/#history). - **The schedule.** The work-sessions strip under a Gantt bar draws a thin mark at the right edge of any session that logged scrap, and the segment's label reads `2 scrap`. See [Compare the plan with what was logged](/docs/production/scheduler/#sessions). - **Historical production.** **Show Scrap** puts a red column beside each period's good column, and the CSV export gains `total_operation_scrap_count` and `asset_scrap_count`. See [Separate good parts from scrap](/docs/production/historical-production/#scrap). *FPY*, first pass yield, compares a step's good count with the first step's in a cascading group, so it moves only when a good count moves. Hand-logged scrap is not subtracted from a good count, which is why a shift full of scrap entries can leave FPY where it was. See [FPY](/docs/monitoring/metrics-reference/#fpy) and [FPY across a cascade](/docs/monitoring/asset-groups/#fpy). If a count looks wrong rather than a request failing, start at [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/). ## When something fails | Message | What happened | What to do | |---|---|---| | **No active session** | The session closed between opening the dialog and submitting it | Press **Resume**, then log the scrap again. Nothing was written | | **Failed to record scrap** | The entry did not save | Nothing was written. Retry from **Scrap** | | **Please select a reason for all scrap entries** | A scrap row has a quantity above zero and no reason | Pick a reason for that row, or set its quantity to 0 | | **Failed to add scrap reason code** | The code was not created | Retry. Check it is not already in the list under another spelling | | **Failed to update scrap reason code** | The rename did not save | The tile still carries the old name, and so does every entry using it | | **Failed to delete scrap reason code** | The code is still in the list | Retry. Nothing was removed and no entry changed | ## See also - [Start, pause, and complete a job](/docs/production/run-a-job/) - [Compare production over weeks and months](/docs/production/historical-production/#scrap) - [Metrics reference](/docs/monitoring/metrics-reference/#fpy) - [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/) --- # Generate a schedule proposal Source: https://www.iotflows.com/docs/production/optimize-the-schedule/ The Optimize pill on the scheduler Gantt computes a constraint-aware plan and draws it as dashed indigo ghost bars with a banner reading violations and span before and after. Nothing is written until you click Apply, which saves every included move as one undoable batch. Completed, locked and in-progress work is pinned and never moves, and a scoped run on a selection holds the rest of the board fixed and plans the selection around it. Clicking a ghost skips that move, so you can apply part of a proposal. # Generate a schedule proposal Let IoTFlows compute a constraint-aware plan from the work already on the board, then review it before any of it is written. Resequencing a busy week by hand means holding dependencies, machine availability, shift hours and tool contention in your head at once. The optimizer does that arithmetic and hands you the answer as a preview. It writes nothing on its own. You get a set of proposed bars and a banner of numbers, and you decide whether the numbers are worth the moves. **Before you start** - Production Scheduler is part of the Scheduling Engine module. The tab strip renders for every organization, so seeing the **Scheduler** tab is not proof you are entitled to it. If you are not sure, [contact IoTFlows](/docs/get-started/get-support/). - You need edit access to the board. See [Give people access to a scheduler board](/docs/production/scheduler-members/). - The work needs **Time Estimate** values. A task without one is planned as an hour, which is rarely right. See [Create a production work order](/docs/production/create-a-job/). - Optimize runs on the Gantt. See [Plan jobs in the Production Scheduler](/docs/production/scheduler/#gantt). ## What Optimize does A *proposal* is a computed plan the board shows you but has not saved. The optimizer walks your work orders in dependency order, earliest due date first, and gives each one the earliest slot where its machine, its materials and its predecessors all allow it. It only ever changes two things on a work order: the due date and the **Time Estimate**. Quantities, statuses, assignees, dependencies and the machine stay exactly as they are. **Put real Time Estimates on the work before you judge the optimizer.** A task with no estimate is drawn as a one-hour bar carrying a `~1h` chip, and the plan is only as good as the durations it is given. A board where most bars read `~1h` produces a thin proposal, and that is the most common cause of a disappointing first run. ## Run it on the whole board With nothing selected, click **Optimize** in the Gantt toolbar. The proposal appears immediately, since it is computed in your browser. ![A cropped detail of the left half of the Gantt toolbar. Four pills read Sequence, Working hours, Work sessions and Optimize, the last carrying a sparkle icon and ringed in violet, with undo, redo and download icons past a divider to its right.](/images/production/prod-opt-01.webp) *The Optimize pill in the Gantt toolbar, after Sequence, Working hours and Work sessions. It plans against the Time Estimate on each task, so a task without one is planned as an hour.* **Run it on a selection first.** A whole-board run on a busy schedule moves work people have already promised to customers, and the fastest way to lose trust in the optimizer is to apply one of those. [Optimize only what you selected](#scoped) is the safer first run. > **Info:** > **Should Working hours be on?** Turn it on before you optimize if the plan has to stay inside shifts. The optimizer reads the same toggle the bars do: with **Working hours** off it plans straight through nights and weekends, and the proposal will be shorter than anything the floor can deliver. See [Turn on Working hours](/docs/production/scheduler/#working-hours). Optimize is unavailable in Sequence view, because those bars stand for order rather than time and carry no time axis to move along. ## Review the proposal Every move is drawn as a dashed indigo ghost bar at the proposed time, joined to its live bar by a dotted line, with a chip above it reading how far it shifts: `6h later`, `1.2d earlier`, or `gets scheduled` for a task that had no date. ![The Gantt with a proposal on screen. An indigo banner reads Optimized proposal: span 66.9d to 15.2d, 54 moves, 3 scheduled from No date, with Recompute, Apply 54 moves and a cross at its right end. Below it six lanes of the DMG DMU 65 group each hold a narrow live bar toward the right of the chart, and well to the left of each sits a dashed indigo ghost bar joined to it by a dotted horizontal line, with a chip above reading 3.1d earlier, 8.8d earlier, 11.4d earlier or 9.4d earlier. A violet arrow runs from the top lane's live bar back to its ghost.](/images/production/prod-opt-02.webp) *An optimizer proposal on the Gantt. Each move it suggests is drawn as a dashed indigo ghost bar, joined to the live bar by a dotted line, and nothing is written until you apply.* **You do not need to accept the whole proposal.** Click a ghost to skip that one move: it turns gray, takes a `skipped` label, and **Apply** relabels itself `Apply 12 of 18`. Click it again to put the move back. Skipping is how you protect a job you have already promised without losing the rest of the plan. To protect it permanently, right-click the bar and choose **Lock scheduling** instead, which takes it out of every future run. ## Read the banner *Span* is the stretch from the earliest start to the latest finish across the board's scheduled work, written as `66.9d`. Lower is better. The banner above the chart is one sentence of numbers followed by the three actions. It reads, in order: violations before and after, span before and after, the number of moves, and the number of tasks scheduled from **No date**. Violations only appear when the board has at least one before or after, so a permanent `0 to 0` never sits there. ![An indigo banner across the top of the Gantt carrying a sparkle icon, with four numbered callouts in the board header immediately beneath it. Callout 1 marks the sentence, which reads Optimized proposal: violations 5 to 4, span 66.9d to 15.2d, 54 moves, 3 scheduled from No date. Callout 2 marks a Recompute button with a refresh icon, callout 3 a filled indigo button reading Apply 54 moves, and callout 4 a small cross at the right end.](/images/production/prod-opt-03.webp) *The proposal banner: one line reading violations and span before and after with the number of moves, then Recompute, Apply and the cross that discards.* **If span barely moves and violations do not fall, discard it.** Eighteen moves that buy half a day are eighteen conversations you now owe the floor, and a proposal that gains nothing is telling you the schedule was not the problem. The banner does not report double-booked machines. To see that number change, check the issues pill before and after, or run the optimizer inside a [Simulation](/docs/production/simulate-a-schedule/#optimize), whose band carries **Double-booked** as its own metric. ### Proposal actions | Action | Effect | Undoable | |---|---|---| | Click a ghost bar | Skips that move and dims the ghost. **Apply** relabels to `Apply 12 of 18` | Nothing is written yet | | **Apply N moves** | Writes a due date and a **Time Estimate** to every included work order | Yes, as one step | | **Recompute** | Discards this proposal and runs the optimizer again over the same scope | Nothing is written | | The cross at the right end | Discards the proposal and leaves the board as it was | Nothing is written | | Clicking **Optimize** again | Same as the cross | Nothing is written | | Regrouping the board | Clears the proposal | Nothing is written | ## Apply the proposal **Apply** saves every move you did not skip. Each work order is written on its own, and the whole set lands in the undo history as a single entry, so one **Undo** puts the schedule back where it was. A run of more than one work order confirms with **Apply optimized schedule · 18 work orders**. > **Warning:** > **What does Apply write to a task with no estimate?** The one-hour default. A `~1h` bar that moves comes back with a real **Time Estimate** of 60 minutes, which then looks like a number somebody chose. Set the estimates you know before you apply, not after. If some of those writes fail you get **4 of 18 updates failed, reverted**: the four that failed go back to the dates they had, the rest are saved, and the proposal closes either way. Run it again for the ones that did not take. Inside a Simulation, **Apply** stages the moves instead of writing them, so they join the draft and wait for Commit. See [Run the optimizer inside a Simulation](/docs/production/simulate-a-schedule/#optimize). ## Recompute A proposal goes stale the moment one of the work orders in it changes underneath you, whether you dragged the bar, edited it in the drawer, or a colleague moved it. The banner replaces its numbers with **The schedule changed while previewing. Recompute to get a fresh proposal.** and **Apply** is disabled until you do. ![A cropped detail of the indigo proposal banner. Where the sentence of numbers was, it reads The schedule changed while previewing. Recompute to get a fresh proposal. The Recompute button is ringed in violet and the Apply button to its right is dimmed.](/images/production/prod-opt-05.webp) *When a work order in the proposal changes, the banner replaces its numbers with a line saying the schedule changed, and Apply is disabled until you recompute.* Only the due date, machine and duration of a work order the proposal moves are watched. Editing a title, or a bar the proposal left alone, does not flip the banner. **Recompute** reruns the optimizer over the same scope the proposal started with, so a scoped run stays scoped. Any ghosts you had skipped come back included. ## Discard Click the cross at the right end of the banner to throw the proposal away. Clicking **Optimize** again does the same thing, and so does regrouping the board. Nothing was written, so there is nothing to put back. ## Optimize only what you selected A *scoped run* is a run that may move only the work orders you selected. Select bars first, by dragging a box across the chart, **Shift**-clicking to add, or holding **Ctrl** and clicking one bar to take its whole dependency chain. The pill then reads **Optimize 5 selected**. ![A cropped detail of the Gantt toolbar with bars selected on the board below. The Optimize pill, ringed in violet, has widened to read Optimize 5 selected. To its left sit Sequence and Working hours unfilled and Work sessions filled blue, and to its right the undo, redo and download icons.](/images/production/prod-opt-04.webp) *With bars selected, the pill reads Optimize 5 selected. A scoped run may move only those five work orders and plans them around everything else.* Everything outside the selection is held exactly where it is. It still reserves its machine time and its materials first, so the selection is planned *around* the untouched work rather than on top of it, and an unselected predecessor still sets the floor for a selected successor. The banner names the scope: **Optimized 5 selected:**, then the same numbers. Press **Esc** to clear the selection when you are done. Select a rush order and its chain, run it, read the span, and you have asked "how early can this finish without disturbing anything else" and got an answer in one gesture. ## What it will not move *Pinned* work keeps its dates and its machine and is reserved before anything else is placed. Three things are pinned, always: work that is **Completed**, work that is **In Progress**, and work you locked with **Lock scheduling** on the bar's right-click menu. A locked bar carries a padlock and cannot be dragged by hand either. Select only pinned work and there is nothing to plan. The board says so rather than opening an empty banner: **Nothing to optimize in the selection: those work orders are completed, locked or in progress.** A run that finds no improvement is also a valid answer, not a failure. The banner opens reading `0 moves` with **Apply** disabled, which means the optimizer could not beat the plan you already have. ## What it respects ### What Optimize respects and what it pins | Input | Treated as | Notes | |---|---|---| | Completed, in-progress and locked work | Pinned | Reserved first, then planned around | | Everything outside the selection, on a scoped run | Pinned | Same treatment as completed work, for that run only | | Dependencies | Hard constraint | A task starts no earlier than its predecessor finishes, pinned predecessors included | | One job at a time per machine | Hard constraint | Keyed to the machine on the work order, so the answer is the same in every grouping | | Working hours | Respected when **Working hours** is on | Off, the plan runs through nights and weekends | | Setup time on the work order | Added before the task starts | Arrives from your ERP import or the API; no dashboard field sets it | | A serialized piece or a reusable tool | Capacity constraint | Work waits for the piece or the tool to come free. See [the capacity lane](/docs/production/scheduler/#capacity) | | Demand larger than the shop owns | Placed anyway | No amount of moving fixes it, so it stays flagged as a violation | | Now | Floor | Nothing is planned into the past, so overdue work all comes forward | | The machine on the task | Untouched | The optimizer plans each task on the machine it already has | | A task with no due date | Pulled in when it has a machine | It gets a date and the banner counts it under `scheduled from No date` | Tasks with no due date and no machine stay in the unscheduled chips down the left of the board. Give one a machine, or drag it onto a date yourself, and the next run will plan it. See [Schedule work that has no dates](/docs/production/scheduler/#unscheduled). ## See also - [Try a schedule change without saving it](/docs/production/simulate-a-schedule/) - [Find and fix problems in the schedule](/docs/production/schedule-issues/) - [Plan jobs in the Production Scheduler](/docs/production/scheduler/) - [Create a production work order](/docs/production/create-a-job/) --- # Overview: track and schedule production Source: https://www.iotflows.com/docs/production/overview/ Production covers two halves, set up separately and answering different questions. Tracking turns a machine's signal into part counts and is available to every customer: it needs a part, an operation, a detection algorithm and an ideal cycle time, and it produces the Shift Production and Historical boards. Scheduling adds jobs, tasks, sessions, the scheduler board, the Work Queue, ERP import and cost insights, and needs the Scheduling Engine module. Parts and operations are a hard prerequisite for scheduling, because a task is one operation on one machine. # Overview: track and schedule production What counting parts needs, what scheduling adds, and which of the two you are entitled to. Production covers two halves, set up separately and answering different questions. *Tracking* turns a machine's signal into part counts, and every IoTFlows customer has it. *Scheduling* puts named work on named machines with dates on it, and it is licensed as the Scheduling Engine module. Both sit under **Production** in the top navigation, which opens on the Parts List at `/production?select=parts_list`. ## Tracking versus scheduling Five objects carry this whole section, and the line between tracking and scheduling runs between the second and the third. A *part* is a thing you make, named with the number your plant already uses, for example `BH-4021`. An *operation* is one step in making it, for example `OP20 Turn`. The operation carries the [detection algorithm](/docs/production/choose-an-algorithm/) and the [ideal cycle time](/docs/production/cycle-times-and-filters/) that turn a sensor's signal into counts, so it, not the part, is what tracking depends on. A *job* is an order for a quantity of a part, for example 250 of `BH-4021` due Friday. A *task* is one operation of that job on one machine. A *session* is one run of a task: start, stop, parts made, scrap logged. Diagram: A left-to-right chain of five boxes under two bands. The first band, headed Tracking, every customer, holds Part, described as what you make, BH-4021 housing, and Operation, described as one step in making it, OP20 Turn, with its algorithm. An arrow crosses the gap into the second band, headed Scheduling, needs the Scheduling Engine module, which holds Job, an order for 250 of BH-4021 due Friday, then Task, one operation of that job on one machine, then Session, one run of a task with start, stop and parts made. *The five objects Production runs on, and the two halves that own them. Parts and operations count what machines make; jobs, tasks and sessions come with the Scheduling Engine module.* ### Job, task, or work order? A *work order* is the record behind all three. In Production it is a job or a task, and in [Maintain](/docs/maintain/overview/) it is a maintenance work order raised against an asset. The two lists never mix. The dialog that adds a task to the board is headed **Create Workorder**, and creates the same object. ## What tracking needs Tracking is available to every customer and needs three things in place. 1. **A machine reporting.** A sensor tied to the asset and calibrated. See [Quickstart: see your first machine's data](/docs/get-started/quickstart/). 2. **A part with at least one operation.** Both are created in the Parts List, which needs Organization Owner or Organization Administrator. See [Roles and permissions](/docs/admin/roles-reference/). 3. **A detection algorithm and an ideal cycle time on the operation.** The algorithm decides what counts as one part. The cycle time decides what that count is measured against. See [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/) and [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/). What you get back is the count itself: the live shift board, the daily and monthly history, and the parts gauge on each machine card, defined at [Performance](/docs/monitoring/metrics-reference/#performance). ### You do not need the Scheduler to count parts If your question is "how many did that press make this shift", set up parts and operations and stop there. Shift Production answers it, and nothing on that board needs a job. Add scheduling when the question changes to who was supposed to run what, on which machine, by when. That is heavier setup: every job needs a quantity, a due date and a routing to fan out across. ## What scheduling adds Scheduling adds the plan and the record of working to it. The scheduler board holds jobs and tasks across five views, the Work Queue is where an operator picks one up, sessions record what actually ran, and Insights prices the result. Parts and operations are a hard prerequisite, not a recommendation. A task is one operation on one machine, so a part with no operations has nothing to schedule. **Create Job** builds one task per operation on the part's routing, which means the routing decides the shape of every job you create. ## Module entitlement | Capability | Tracking | Scheduling Engine | Page | |---|---|---|---| | Parts, operations and routings | Yes | Yes | [Create parts and operations](/docs/production/parts-and-operations/) | | Detection algorithms | Yes | Yes | [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/) | | Cycle times and downtime filters | Yes | Yes | [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/) | | Live shift counts against a goal | Yes | Yes | [Track production against shift goals](/docs/production/shift-production/) | | Daily, weekly and monthly output | Yes | Yes | [Compare production over weeks and months](/docs/production/historical-production/) | | Production Scheduler | No | Yes | [Plan jobs in the Production Scheduler](/docs/production/scheduler/) | | Jobs, tasks and work sessions | No | Yes | [Create a production work order](/docs/production/create-a-job/) | | Work Queue | No | Yes | [Find your next job in the Work Queue](/docs/production/work-queue/) | | ERP schedule import | No | Yes | [Import a schedule from your ERP](/docs/production/import-erp-schedule/) | | Cost and on-time performance | No | Yes | [Analyze cost and on-time performance](/docs/production/production-insights/) | The module is additive: everything in the Tracking column stays as it was. > **Info:** > **How do I tell whether we have the module?** The Production tabs render for every organization, so seeing **Scheduler** or **Insights** in the tab strip is not proof you are licensed for them. Ask IoTFlows if you are not sure, see [Contact support and report bugs](/docs/get-started/get-support/). ## Where to start Start with one part on one machine. [Quickstart: count your first parts](/docs/production/quickstart/) takes a single part through an operation, an algorithm and a cycle time, then validates the count against ten parts made by hand. Once one machine counts correctly, repeat it per machine type. [CNC mills and lathes](/docs/production/cnc-machines/), [injection molding](/docs/production/injection-molding/) and [stamping presses](/docs/production/stamping-presses/) are the same setup with the algorithm and the filters already chosen. If a count is already wrong, go to [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/) before adding anything else. A wrong count is a wrong shift goal and a wrong job estimate later. Come back to [Plan jobs in the Production Scheduler](/docs/production/scheduler/) when the routings are in and you want work assigned rather than counted. ## See it in a plant - [Production monitoring](https://www.iotflows.com/solutions/production-monitoring) — Every part counted from the machine's own signal, against a goal for the shift. - [Production Scheduler](https://www.iotflows.com/platform/production-scheduler) — Jobs planned on the machines you already monitor, in list, table, Gantt, Kanban and calendar views. ## See also - [Quickstart: count your first parts](/docs/production/quickstart/) - [Create parts and operations](/docs/production/parts-and-operations/) - [Plan jobs in the Production Scheduler](/docs/production/scheduler/) - [Overview: monitor machines and OEE](/docs/monitoring/overview/) --- # Configure tracking for bottling and packaging lines Source: https://www.iotflows.com/docs/production/packaging-lines/ Set up part counting on a line whose output is units moving past a point: bottles, cans, packets, tubes, cartons or cases. Mount a BeamTracker across the part path after the last reject point, set the operation's algorithm to Counter, name the unit in OP UNIT so gauges read bottles/min, and set QTY/OP to 1 when the beam sees each unit or to the pack count when it sees a case. A Counter operation's cycle time feeds goals and the rate, never the count, and the downtime filter lives on the device in seconds rather than on the Parts List as a percentage. The Count tab of the Auto-Detect modal is single choice, so the line carries one operation at a time and you re-pick it at every product change. # Configure tracking for bottling and packaging lines Count finished units as they pass a point on the line, whatever the machines upstream are doing. A filling, capping, packing or labeling line ends with units moving along a fixed path in one direction: bottles, cans, packets, tubes, cartons or cases. [Counter](/docs/production/choose-an-algorithm/#counter) is the algorithm for that case. It takes each break of a [BeamTracker](/docs/hardware/beamtracker/) beam as one cycle, so the count is what left the line rather than what any single machine in it was doing. Allow 30 to 45 minutes for the first line. **Before you start** - A BeamTracker tied to the asset, installed and aimed. See [Install and align BeamTracker](/docs/hardware/install-beamtracker/), and contact IoTFlows to tie your sensors to an asset in [Get support](/docs/get-started/get-support/). - Sign in as an Organization Owner or Organization Administrator, see [Roles reference](/docs/admin/roles-reference/). ## Why Counter fits a line Three things about a line point at the same algorithm. - **The output is units passing a point.** They travel a fixed path in one direction, which is exactly what a beam across that path measures. - **No single machine's cycle is the line's output.** A filler, a capper and a case packer each run their own rhythm, and a sensor on any one of them counts that machine rather than the line. - **The count does not depend on a number you typed.** Counter counts beam breaks, so an entered cycle time that drifts out of date changes the goal without changing the count. **Count from the machine's own cycle with a [SenseAi](/docs/hardware/senseai/) instead when what you need is the state of one machine rather than the units leaving the line.** SenseAi derives counts and cycle times from the machine's vibration trace, so it tells you which machine stopped. A BeamTracker at the discharge tells you the line stopped, not where. **You do not need both on the same equipment.** Add a second device only when you want the line's output and one machine's health from the same place, and expect to calibrate each separately. ## Choose the count point ![A BeamTracker mounted on a bracket at the edge of a conveyor, its beam shown as a dashed line crossing the part path to a point on the far side](/images/beamtracker/laser-beam-illustration-with-beams.webp) *The beam crosses the part path at one point. Everything that breaks it is counted, so the count point decides what the number means.* Aim for a point where **every good unit passes the beam and nothing else does**. On a line that means one place in particular: after the last reject or divert station, so the number is what the line produced rather than what it attempted. 1. Pick the narrowest point in the flow, where units run single file. A beam across a mass-flow conveyor two units wide counts neither reliably. 2. Stay off accumulation tables and buffer loops. A unit that backs up, drifts forward and backs up again crosses the beam more than once. 3. Keep hands, totes and operator reach out of the beam. A beam that catches a hand counts hands. 4. Mount within **8 m (26 ft)** of the part path, with a stable surface behind it and nothing moving in the background. 5. Fasten the bracket to something that does not move when the line runs. A bracket that vibrates walks the beam off its target over a shift. **Clear and reflective units are the one case to plan around.** Glass and clear film may not break the beam at all. Aim at an opaque feature instead, such as the closure, the label band or the filled body of the container, or move the count point downstream and count cases rather than bottles. Wash-down is not a constraint. BeamTracker is IP67, so it is the air the beam crosses that limits placement: mist, steam and spray break a reading in a way the housing does not. Full mounting detail is on [Choose a mounting point](/docs/hardware/install-beamtracker/#mounting). ## Set what the beam counts as a unit Four values on the device's **Calibration** tab decide whether a reading is a unit. The procedure and the field reference are on [Set what counts as a part](/docs/hardware/calibrate-beamtracker/#beam-values). Three of them need a line-specific answer. - **Depth of View** sets the far edge of the detection zone. Pull it in front of the far guard rail, so a tote crossing the aisle behind the line is background rather than product. - **Min Object Thickness** is a floor, not a ceiling. Set it to the thinnest unit you must count, for example a tube rather than a case, because a floor above that drops small units silently. - **Reading Speed** trades responsiveness for stability. A line at 120 units a minute presents a unit every 0.5 seconds, so choose a faster setting when the count runs low and a slower one when a dusty line counts high. Set these by watching a real unit cross the thresholds rather than by typing numbers, in [Run a live beam calibration](/docs/hardware/calibrate-beamtracker/#live). ## Create the part and its operation 1. Open **Parts List** at `/production?select=parts_list`. 2. Click **+ Add Part**. 3. Enter a **Part Name**, for example `500 mL Spring Water`. **Part Description** is optional. 4. Under **Assign Operations**, name the operation after the product and container, for example `FILL-500ML`, and describe it, for example `500 mL PET, 24-count case`. 5. Enter **Operation Cycle Time**. For a line running 120 units a minute, that is 0 in the hour and minute boxes and `0.5` seconds. 6. Add the machines that run this operation, then click **Add Part**. 7. Back on the Parts List, expand the part, click the operation's **Algorithm** cell and choose **Counter**. It saves as you pick it. 8. Click the **OP UNIT** cell and name what the line counts, for example `bottles`. The label is free text, capped at 12 characters. 9. Set **QTY/OP** to what one beam break yields. A **Counter** operation carries no standard deviation box, unlike the two discrete algorithms, and saves with the tolerance at zero. **QTY/OP is decided by what the beam sees, not by what the line makes.** Point the beam at single bottles and one break is one bottle, so leave it at `1`. Point it at cases leaving a packer and one break is a case, so a 24-count case is `24`. Getting this wrong is the reason a line's count comes out as an exact multiple of reality. The field reference is on [Unit and quantity per cycle](/docs/production/parts-and-operations/#units). ## Enter the line speed as a rate A line is quoted in units a minute, and a **Counter** operation is the one place the Parts List takes that number directly. The cell carries a swap control beside the cycle-time boxes: click it, type `120`, and the cycle time is written back from the rate. See [Production rate is the same number](/docs/production/cycle-times-and-filters/#rate). The unit beside the rate is the **OP UNIT** label you set, so a line reading `120.0 bottles/min` is a gauge an operator can check against the line's rating plate. **On a Counter operation this number never touches the count.** It sets the **Calculated Goal** on Shift Production, the parts gauge and the hourly bars, and nothing else. That is the opposite of [Continuous Analysis](/docs/production/choose-an-algorithm/#continuous), where the cycle time divides running time to produce the count. A line whose counts are right and whose goal is wrong has a cycle time problem; a line whose counts are wrong has a beam problem. ## Set the downtime filter on the device The **Downtime Filter** for a BeamTracker is how long the line stays running after the last unit. Every unit resets the timer, and if none arrives inside the filter the line switches to stopped, back-dated to the last unit. **It is not the Parts List Downtime Filter column.** That column belongs to Continuous Analysis, it is a percentage of the cycle time, and it does not appear on a Counter operation. A BeamTracker's filter is on the device's **Calibration** tab and is set in time, see [Set the downtime filter](/docs/hardware/calibrate-beamtracker/#downtime-filter). Start from the line's real unit-to-unit time and add room for ordinary pauses. A line running continuously sits in the 15 to 45 second band. A line that fills a buffer, pauses while a case is packed and resumes needs a filter past the longest normal gap, or every pack cycle reads as a stop. **Turn on Blocked Sensor Stop Time if a jam leaves a unit sitting in the beam.** Without it, a parked unit holds the reading inside the detection zone and the line keeps reading as running through the whole stoppage. The minimum is 25 seconds, see [Stop the line when the beam stays blocked](/docs/hardware/calibrate-beamtracker/#blocked). ## Assign the operation to the line 1. Open **Assets** at `/assets` and click the line's asset. 2. Click **Auto-Detect** to open **Select Auto-Detect Operations**. 3. Stay on the **Count** tab. A BeamTracker shows **Count** and nothing else, because the three analysis algorithms read a vibration trace. 4. Select the operation's radio button. This list is single choice, not checkboxes. ![The Select Auto-Detect Operations modal on a BeamTracker asset. Count is the only tab, drawn as a single full-width pill below a search box. Under it two radio-button rows, neither selected, each naming a Counter operation over the part it belongs to: FILL-500ML - Fill and cap, 500 mL PET over 500 mL Spring Water, and CASE-24 - Case pack, 24 count over 500 mL Spring Water. Add/Edit Parts sits in the header and Close alone in the footer, with no submit button](/images/production/prod-line-02.webp) *The Count tab of the Auto-Detect modal, the only tab a BeamTracker shows. It is single choice, so the line carries one operation at a time.* The dashboard saves as you pick, confirms with **Count Auto-Classification Set** and closes the modal. There is no submit button on this tab, only **Close**. **An operation with no algorithm never appears in this list, and neither does one set to an algorithm the device cannot run.** A BeamTracker lists Counter operations only. If the operation you want is missing, create or correct it from **Add/Edit Parts** inside the same modal, see [Detect operations automatically](/docs/production/auto-detect-operations/#algorithm). **The Count tab has no "stop detecting" row.** The **Continuous** tab carries **No Continuous Detection**; this one does not, so a line keeps its operation until you pick a different one. ## Handle product and size changes Because the **Count** tab is single choice, **a line carries one operation at a time.** A product change is two jobs: change the line over, then re-pick the operation. Skipping the second files the new product's units under the old product's part, which is the most common reason a line's numbers go wrong after a changeover. A size change is more than a re-pick. A 330 mL can and a 2 L bottle are different objects to the beam, so re-check the beam values as well: 1. Re-pick the operation on the **Count** tab. 2. Confirm **Min Object Thickness** still sits below the new unit, in [Set what counts as a part](/docs/hardware/calibrate-beamtracker/#beam-values). 3. Confirm the new line speed against the operation's rate, so the goal matches what the line can now do. 4. Classify the changeover itself, so the time shows up as downtime rather than disappearing. Create a **Changeover** category in [Create a category](/docs/monitoring/downtime-categories/#create), and write a rule if changeovers always look the same, in [Classify downtime automatically](/docs/monitoring/auto-downtime-rules/). **A label or flavor change needs none of this** when the container is identical. Same object, same beam values, same operation. ## Validate the count 1. Let the line run normally for one to two hours. 2. Count units at the discharge for a fixed window, or read the counter on the line's own control panel. 3. Open **Shift Production** at `/production?select=part` and read the count for the operation over the same window. 4. Compare the two. Within 5 to 10% is right. 5. Open **Downtimes** at `/assets?select=downtimes` and confirm real stops are recorded while normal gaps between units are not filling the list. Counting against the line's own panel is worth doing once even where you trust it, because the two counters rarely sit at the same point in the flow. A panel counting filled bottles and a beam counting packed cases are both right and will never agree. Accuracy bands and what to do at each one are on [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/#validate). ## What a BeamTracker line does not report A BeamTracker measures a beam, not a machine, so a line tracked this way reports counts, rates, running time and downtime, and nothing about the condition of the equipment. | Available | Not available | |---|---| | Part counts and throughput | Vibration and machine health | | Running and stopped time, and uptime | Temperature and shock readings | | Downtime with duration and reason | The **Health** tab, which the dashboard hides on a BeamTracker asset | | **Machine Status** and connectivity alerts | Health, vibration, shock and temperature alerts | Add a [SenseAi](/docs/hardware/senseai/) on a machine in the line if you need those, see [What BeamTracker does not report](/docs/hardware/beamtracker/#limits). Set the line's goal from its own baseline rather than from its rating plate, in [Set OEE and utilization goals](/docs/monitoring/oee-goals/). *Uptime* is availability, the share of the window the line spent running, see [Uptime](/docs/monitoring/metrics-reference/#uptime). Log rejects against the job so the good count is the number you compare, see [Log scrap](/docs/production/log-scrap/). ## Troubleshoot a line | Symptom | Cause | Fix | |---|---|---| | Count is an exact multiple or fraction of real output | **QTY/OP** does not match what one beam break yields | Set it to `1` for single units, or the pack count where the beam sees cases, see [Create the part and its operation](#operation) | | Count runs low on clear containers | Glass or clear film is passing without breaking the beam | Move the count point to an opaque feature or to cases, see [Choose the count point](#count-point) | | Count runs low on small units | **Min Object Thickness** sits above the unit, so it is dropped silently | Lower it to the thinnest unit you must count, see [Set what counts as a part](/docs/hardware/calibrate-beamtracker/#beam-values) | | Count runs high, and the line has a buffer | Units are backing up and re-crossing the beam | Move the count point off the accumulation table to a single-file section | | Count runs high on a dusty or misty line | **Reading Speed** is averaging too lightly, so one noisy reading reads as a unit | Choose a slower reading speed | | Counts are right and the goal is wrong | The rate on the operation no longer matches the line | Re-enter the line speed on the operation, see [Enter the line speed as a rate](#rate) | | Downtime list fills with short stops through a normal shift | The device downtime filter is shorter than the line's real unit-to-unit gap | Raise **Downtime Filter** past the longest normal gap, see [Set the downtime filter](#filter) | | A jam ran for an hour and the line reported it as running | A unit parked in the beam held the reading inside the detection zone | Turn on **Blocked Sensor Stop Time**, minimum 25 seconds, see [Stop the line when the beam stays blocked](/docs/hardware/calibrate-beamtracker/#blocked) | | Numbers went wrong at a changeover and stayed wrong | The operation was not re-picked, so units count against the previous product | Re-pick on the **Count** tab, see [Handle product and size changes](#changeovers) | | Counting stopped entirely | The device is offline, and a BeamTracker counts nothing while it is | See [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/) | Counts that stay wrong after the beam values and QTY/OP are both right are on [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/#beamtracker). ## See it in a plant - [Packaging line monitoring](https://www.iotflows.com/solutions/packaging-line-monitoring) — Every unit counted after the last reject, each line’s rate, and the step that stopped the line. ## See also - [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/) - [Calibrate BeamTracker](/docs/hardware/calibrate-beamtracker/) - [Install and align BeamTracker](/docs/hardware/install-beamtracker/) - [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/) - [Configure tracking for stamping and punch presses](/docs/production/stamping-presses/) --- # Create parts and operations Source: https://www.iotflows.com/docs/production/parts-and-operations/ The Parts List at /production?select=parts_list holds every part your plant makes and the operations that make it. A part carries a name, a picture and files; an operation carries the step number, the unit, the quantity per cycle, the detection algorithm and the ideal cycle time, and it is the thing every count, goal and job actually hangs off. Add Part creates a part named New Part with no dialog, and every field after that is edited in place on the row and saved when you leave the cell. # Create parts and operations The parts your machines run, and the operations that make them. Every production number in IoTFlows traces back to this page. A count, a shift goal, a pace, a scheduled job and a material transaction all belong to an operation, and an operation belongs to a part. Nothing counts until both exist. **Before you start** - Sign in as an Organization Owner or Administrator. See [Roles and permissions](/docs/admin/roles-reference/). - A machine already reporting to IoTFlows, if you want to see the counts land. See [Quickstart: see your first machine's data](/docs/get-started/quickstart/). This page is the field-by-field reference for the Parts List. If you have never set one up, run [Quickstart: count your first parts](/docs/production/quickstart/) first and come back here for the fields it skipped. ## The parts model A *part* is a thing your plant makes, named the way your traveler and your purchase orders name it. A part counts nothing by itself. It is a folder with a picture and some drawings in it. An *operation* is one thing a machine does to that part, for example a roughing pass, a press stroke or a deburr. The operation is where the work happens. It carries the *detection algorithm*, the rule that turns the sensor's signal into cycles, the *ideal cycle time*, how long one good cycle takes, and the units the count is reported in. Three relationships hold everywhere in the product: - A part holds as many operations as you like. An operation belongs to exactly one part. - An operation runs on one or more machines. You assign it from the machine, not from here. See [Detect operations automatically](/docs/production/auto-detect-operations/). - A scheduled task is one operation on one machine. That is why parts and operations are a hard prerequisite for the scheduler. See [Plan jobs in the Production Scheduler](/docs/production/scheduler/). **Create one operation per thing the machine does differently, not one per line on the router.** If two router steps run at the same rate on the same machine, one operation counts both correctly and halves your setup. Split them only when the cycle time, the algorithm or the machine differs. **You do not need a part to know whether a machine is running.** Machine state, uptime, downtime and utilization come from the sensor alone and appear on the Assets page with no part on file. See [Monitor your fleet on the Assets page](/docs/monitoring/assets-overview/). ![The Parts List at /production?select=parts_list, showing the Sort by and Add Part toolbar, the search box, and four part cards: GB-6610 Gear Blank, PL-3080 Cover Plate, BH-4021 and MS-7420 Manifold. Each card carries the part picture, the part name in sky blue and a paperclip, over a table of its operations with the columns OP, Operation(s), OP UNIT, Description, QTY/OP, Algorithm and Ideal Operation Cycle Time](/images/production/prod-parts-01.webp) *The parts list. Each part carries the operations that make it.* ## Create a part 1. Open **Production**, then the **Parts List** tab, at `/production?select=parts_list`. 2. Click **Add Part**. A part called `New Part` appears at the top of the list and the dashboard confirms with **Part has been added**. There is no dialog. 3. Click the part's name, type the number your plant already uses, for example `BH-4021`, and press Enter. Clearing the name and clicking away puts the old name back rather than saving an empty one. On a phone, **Add Part** opens a sheet with a single **Part Name** field, and submitting it empty returns **Please enter a part name**. The desktop button never asks, so it cannot produce that message. ### Part fields | Field | Required | Accepts | Used by | |---|---|---|---| | **Part name** | Yes | Free text, edited in place on the part header | The Parts List, Shift Production, Historical, the scheduler and every job that runs one of its operations | | **Part picture** | No | One image, cropped and zoomed in the dashboard. JPEG, PNG, WebP and HEIC all upload | The thumbnail beside the part on Shift Production, on scheduler cards and in the Work Queue | | **Files** | No | Any number of files of any type, up to the browser's upload limit | The work order, so the operator running the job can open them | A production part has no number field, no description and no unit of its own. The part name is the number, which is why it is worth typing the plant's real one: a part called `Bracket v2` matches no paperwork anybody on the floor is holding. ![The header strip of a part card on the Parts List with three numbered violet callouts: 1 on the Add Part button in the toolbar above, 2 on the round part picture control at the left of the header, 3 on the open part name input holding BH-4021](/images/production/prod-parts-02.webp) *Creating a part. The name is the only thing a part needs.* ## Add pictures and files The picture is the circle at the left of the part header. Click it, choose an image, drag and zoom it inside the crop frame, and confirm. It replaces whatever was there. Files sit behind the paperclip beside the part name, which carries a badge with the number attached. 1. Click the paperclip. **Files** opens, headed with the part name. 2. Click **Click or drag files to upload**, or drop files anywhere in the panel. Several at once is fine, and each one shows its own progress row. 3. Hover a file for **Download** and **Delete**. Delete asks once, in the row itself, with **Cancel** and **Delete**. 4. With two or more files attached, the download arrow in the panel header takes all of them at once. Click a file to preview it in place rather than downloading it. PDF, plain text, JSON, XML, CSV and Markdown, images, audio and video, and `.step` and `.stp` CAD models through the built-in viewer all preview. Anything else downloads. **Attach the drawing here rather than emailing it.** Part files ride along to the work order, so the operator opens the print from the job they are running instead of hunting for it. That is the whole reason the field exists. ![The Files panel headed Files over the part name BH-4021, with a download-all arrow at its top right, listing three attachments: BH-4021.step at 840 KB, BH-4021-REV-C.pdf at 1 MB, each with a colored file icon, and setup-photo.jpg at 249 KB showing a thumbnail of the photo, above a dashed Click or drag files to upload zone and the line 3 files attached](/images/production/prod-parts-03.webp) *Pictures and files on a part. The operator sees these from the job.* ## Add an operation 1. Click **+ Add operation** at the foot of the part's table. 2. Type the operation name, for example `OP10`, and press Enter. The dashboard confirms with **Operation has been added**. 3. Fill in the rest of the row cell by cell. Every cell on the row saves when you leave it, by pressing Enter or Tab or by clicking elsewhere. There is no Save button and no draft state, so a half-filled operation is already live. A new operation arrives with a name and nothing else. Until it has an algorithm it counts nothing, and it does not appear in the assignment list on the machine. ### Operation fields | Field | Required | Accepts | Effect on counting | |---|---|---|---| | **OP** | No | Up to four digits, nothing else | None. It orders the routing. See [Operation sequence](#sequence) | | **Operation(s)** | Yes | Free text, set when you create the row and editable after | None | | **OP UNIT** | No | Free text up to 12 characters. Defaults to `ops` | None. It labels the count wherever the operation is shown | | **Description** | No | Free text, for example `Rough mill` | None | | **QTY/OP** | No | A number, fractions allowed, with its own unit label beside it. The label defaults to `made` | Multiplies every detected cycle. See [Unit and quantity per cycle](#units) | | **Algorithm** | Yes, to count anything | One of the four the server offers | Decides what counts as one cycle. See [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/) | | **Downtime Filter** | No | 0 to 200%. The column appears only when the part has at least one Continuous Analysis operation, and the field is editable only on that operation's row | Converts stops shorter than that share of the cycle time into running time. See [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/) | | **Ideal Operation Cycle Time** | Yes, for goals and pace | Hours, minutes, seconds and hundredths, plus a tolerance percentage on the two Discrete algorithms | Continuous Analysis divides running time by it to produce the count. The other three read it for goals only. See [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/) | | **Requires** and **Creates** | No | Inventory items | None. They move stock when the work order closes. See [Link required and created parts to an operation](/docs/production/bind-materials/) | Changing the algorithm on an operation that other machines already run can come back with a **Confirm Algorithm Change** dialog listing those machines. Confirming removes the operation from them. See [Switch to a different algorithm](/docs/production/choose-an-algorithm/#switch). ![One operation row on the Parts List, OP10 Rough Mill, under the column header row OP, Operation(s), OP UNIT, Description, QTY/OP and Algorithm. Four numbered violet callouts sit beside the fields they name: 1 against the round step marker reading 10, 2 against the OP UNIT cell reading ops, 3 against the QTY/OP cell reading 1 made, and 4 against the Algorithm cell's Discrete Analysis pill. The Description cell reads Rough mill both faces](/images/production/prod-parts-04.webp) *An operation's fields. Quantity per cycle is the field behind most doubled counts.* ## Operation sequence The *sequence* is the step number the operation holds in the routing, shown as a circle in the **OP** column and joined to its neighbors by a hairline. 1. Click the circle. On an operation with no number yet, hover the row and click the dashed `+`. 2. Type the step number, for example `20`. Digits only, four at most. 3. Press Enter. The rows resort themselves and the marker rings once so you can follow the one that moved. Escape cancels. Operations without a number sit at the end of the list, in whatever order the server sent them. > **Warning:** > **Why did OP100 land above OP20?** Step numbers sort as text, not as numbers, so `100` comes before `20` the same way `Ba` comes before `Bx`. Pad the numbers to a fixed width and the problem disappears: number the routing `010`, `020`, `100` rather than `10`, `20`, `100`. ![The OP and Operation(s) columns of a part table, three rows deep under their column headers. Round step markers reading 10, 20 and 30 sit in a vertical line joined by a hairline, against the operation names OP10 Rough Mill, OP20 Finish and OP30 Deburr](/images/production/prod-parts-05.webp) *Operation sequence. Create one operation per thing the machine does differently.* ## Unit and quantity per cycle *Quantity per cycle* is how many parts one detected cycle of this operation produces. It is the **QTY/OP** cell, and it multiplies the count the algorithm arrives at. | What the machine does | QTY/OP | Result | |---|---|---| | One cycle makes one part | `1` | The count is the cycle count. This is the usual case | | A four-cavity mold shoots four parts | `4` | 100 cycles count as 400 parts | | Two cycles are needed to finish one part | `0.5` | 100 cycles count as 50 parts | **Check this cell first when a count comes out doubled or halved.** It is the only field on the row that scales the answer, so a mold changed from two cavities to four shows up here as a count that is exactly half of reality. The operation carries two unit labels, both free text and both capped at 12 characters: - **OP UNIT** names what the operation counts, and defaults to `ops`. Set it to `cycles`, `passes` or `strokes` when that reads better on a gauge. - The label beside **QTY/OP** names what one cycle yields, and defaults to `made`. Set it to `cut`, `shot` or `lbs`. These are labels, not conversions. Changing `ops` to `lbs` changes what the gauge on [Track production against shift goals](/docs/production/shift-production/#board) says, not what it counts. Use QTY/OP for the arithmetic. ## Edit or delete Everything on this page is edited in place. Click a cell, change it, and leave the cell. Parts carry their actions in the `...` menu at the far left of the header, which appears on hover: - **Archive this part** asks `Are you sure you want to archive part BH-4021?` and confirms with **Part has been archived**. - **Delete this part** asks `Are you sure you want to permanently delete part BH-4021?` and confirms with **Part has been removed**. Operations carry an archive icon and a trash icon at the right of the row, also on hover, with the same two confirmations and the toasts **Operation has been archived** and **Operation has been deleted**. **Archive rather than delete once an operation has produced anything.** Deleting an operation removes its historical association: the production it counted stays in your data, but no longer carries the operation's name, so the run disappears from anything that groups by operation. Archived parts leave the Parts List. There is no view of archived parts and no restore control in the dashboard, so treat archiving as a one-way move and contact IoTFlows if you need one back. See [Contact support and report bugs](/docs/get-started/get-support/). ## Search and sort the parts list The search box above the list matches part names and operation names together, so typing `GB-66` finds the part and typing `DEBURR` finds the part that has that operation. Typing writes the text into the address bar as `?q=`, which means a filtered list is a link. Send `/production?select=parts_list&q=BH-4021` to someone and they open the same view. No match returns `No matches found for BH-4021`. **Sort by**, at the top left, offers four orders: | Sort option | Order | |---|---| | **Date: New to Old** | Most recently created part first. The default | | **Date: Old to New** | Oldest part first | | **Name (A to Z)** | Part name ascending | | **Name (Z to A)** | Part name descending | On a phone the same four are in the toolbar's view menu, labeled **Newest**, **Oldest**, **Name A-Z** and **Name Z-A**. ![The top of the Parts List with BH typed into the search box and the Sort by control above it reading Date: New to Old. The list below is narrowed to the single part BH-4021, whose paperclip carries a badge reading 3, over its one operation row OP10](/images/production/prod-parts-06.webp) *Searching the parts list.* ## See also - [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/) - [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/) - [Detect operations automatically](/docs/production/auto-detect-operations/) - [Link required and created parts to an operation](/docs/production/bind-materials/) - [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/) --- # Analyze cost and on-time performance Source: https://www.iotflows.com/docs/production/production-insights/ Insights, at /production?select=insights, prices scheduled work at two hourly rates you type in: Labor $/hr and Production $/hr, defaulting to $35 and $50. It multiplies each task's labor hours and machine hours by those rates, compares the result with the Budget typed on the task, and reports completion, on-time, cost, profit and margin across a date range that opens on the last 90 days. The rates live in the report and are never saved to your organization. A task with no due date counts as on time, and an Approved task counts as neither Completed nor Active. # Analyze cost and on-time performance Put an hourly cost on work the scheduler already recorded, and see what finished late. Insights prices the schedule. It takes every task in a date range, multiplies the hours logged against it by two hourly rates you type in, and reports what that work cost, what it made against the budget on the task, and how much of it hit its due date. The page reads the scheduler's records and writes nothing back. Nothing here changes a job, a task, or a session. **Before you start** - **The Scheduling Engine module.** Every organization sees the **Insights** tab whether or not it is licensed, so the tab strip is not proof. See [Module entitlement](/docs/production/overview/#entitlement). - **Web only.** Neither mobile app has an Insights tab. - **Tasks with hours on them.** Insights counts hours operators and machines actually logged, so a schedule nobody has run against produces an empty report. See [Start, pause, and complete a job](/docs/production/run-a-job/). - **A Budget on the tasks**, if you want profit rather than cost. See [Job and scheduler fields](/docs/production/job-fields-reference/). There is no role gate. Anyone who can open Production can open Insights and change the rates. ## Open Insights Open **Production**, then the **Insights** tab, at `/production?select=insights`. The report opens on the last 90 days, at a labor rate of $35 an hour and a production rate of $50 an hour. Those are defaults in the page, not settings your organization chose. ![The Insights tab at /production?select=insights, showing the Production tab strip above a filter bar with Machines, Jobs and Operations pills on the left, a search-and-status pill with a 90d date button in the center and an Options button on the right, above the Workorders, Financials and Hours cards](/images/production/prod-insights-01.webp) *Production Insights. Requires the Scheduling Engine module and is web only.* ### Narrow the window and the work Seven controls sit in the filter bar, and they split into two kinds. | Control | Where | What it narrows | |---|---|---| | **Date range** | The center pill: `1d`, `7d`, `30d`, `90d`, `1y`, or **Custom** with two date fields and **Apply** | Refetches the report | | **Labor $/hr**, **Production $/hr** | The **Options** menu | Refetches the report | | **Machines** | Filter pill, grouped by department | Filters the rows on screen | | **Jobs**, **Operations** | Filter pills, each with a search box | Filters the rows on screen | | Search | The magnifier inside the center pill, matching workorder number, title, part, job, operation and machine | Filters the rows on screen | | **All** / **Done** / **On Hold** | Status buttons in the center pill | Filters the rows on screen | Only the date range and the two rates go back to the server. Everything else narrows rows the page already holds, so the cards, both charts and the table move the instant you click. **Machines**, **Jobs** and **Operations** write themselves into the address bar, so a filtered view is a link you can send. **Reset**, in the **Options** menu, clears every filter and returns the window to 90 days. ## Completion and on-time KPIs Three cards run across the top. **Workorders** carries the counts, **Financials** carries the money, and **Hours** is a donut splitting total hours into production and labor. A task is *on time* when it completed before its due date, or when it has no due date at all. It is behind when it has a due date and either completed after it or is still open past it. | KPI | Definition | Counts what | |---|---|---| | **Workorders** | Every task in the window after the filters | Tasks, not jobs. A job for 250 of `BH-4021` with three operations contributes three | | **Completed** | Tasks at status **Done** | Closed work only | | **Active** | Tasks that are neither **Done** nor **Approved** | Open, In Progress and On Hold | | **Completion** | Completed ÷ Workorders | The whole window, not a rolling rate | | **On-time** | On time ÷ (on time + behind) | Every task carrying a due date, plus every task carrying none | | **Losing money** | Share of tasks whose profit is below zero | Needs budgets to mean anything | | **Margin** | Total profit ÷ total budget | The small percentage under the **Financials** number | > **Warning:** > **Why don't Completed and Active add up to Workorders?** > > A task at status **Approved** counts in neither. It stays in the **Workorders** total and it lowers **Completion**, so a plant that approves tasks after closing them reads as less complete than it is. > **Info:** > **A task with no due date counts as on time.** > > It lands in both halves of the on-time fraction, so a board where half the work was never given a due date reports an on-time rate it did not earn. Check the **Due date** column before you trust the number. See [Job and scheduler fields](/docs/production/job-fields-reference/). ![The Workorders card, showing a large count above four chips reading Completed, Active, Completion as a percentage and On-time as a percentage, beside the Financials card and its Total cost, Labor cost, Production cost and Losing money chips, with numbered callouts on Completion and On-time](/images/production/prod-insights-02.webp) *Completion and on-time KPIs across the period.* ## Set hourly rates Select **Options** at the right of the filter bar. It holds two fields. 1. Enter **Labor $/hr**, the hourly cost of an operator. It opens at `35`. 2. Enter **Production $/hr**, the hourly cost of a machine running. It opens at `50`. 3. Select **Apply**, or press Enter in either field. A blue dot on the **Options** button means a rate is typed but not applied. **Reset**, beside **Apply**, returns both fields to the defaults and clears the filters with them. > **Warning:** > **The rates are not saved.** > > They belong to the report, not to your organization, so they return to $35 and $50 on every page load and nobody else sees the numbers you typed. Write your two rates down somewhere your team can find them, or two people will price the same week differently. **Use fully burdened hourly cost, and use one pair of rates for the whole plant.** Fully burdened means wage plus benefits, overhead and downtime allowance for labor, and machine cost plus power, tooling and floor space for production. Insights applies one labor rate and one production rate to everything in the window by design, so there is no per-machine rate to argue about. A per-machine rate that is really a guess turns every machine comparison into a comparison of guesses. ![The Options popover open below the Options button, showing a numbered callout on a Labor $/hr field reading 35 and a second on a Production $/hr field reading 50, each prefixed with a dollar sign, above a Reset link and a dimmed Apply button](/images/production/prod-insights-03.webp) *Setting hourly rates. Use fully burdened cost, and set them once for the whole plant.* ## The cost model A task's *actual* is what it cost: the hours recorded against it, priced at your two rates. A task's *budget* is the dollar figure typed on the task when it was created, which is what you expected to be paid or to spend. Profit is the difference. | Input | Set on | Unit | Used in | |---|---|---|---| | **Labor $/hr** | The **Options** menu on this page | Dollars per hour | Labor cost, Total cost, `Labor $/unit`, Profit | | **Production $/hr** | The **Options** menu on this page | Dollars per hour | Production cost, Total cost, `Production $/unit`, Profit | | Labor hours | Sessions operators logged against the task | Hours | Labor cost, the **Hours** donut | | Production hours | Machine time recorded against the task | Hours | Production cost, the **Hours** donut | | **Budget** | The task, in **Create Workorder** or inline on the scheduler board | Dollars | Profit, Margin, the **Budget** bar | | Units | The task's good count | Parts | The two per-unit columns, `Profit/u` | Total cost is labor cost plus production cost. Profit is budget minus total cost, and margin is total profit over total budget across the window. For example, `OP20 Turn` on job `BH-4021` logs 6.0 labor hours and 9.5 production hours. At $35 and $50 that is $210 of labor and $475 of production, so total cost is $685. Against a $900 budget the task shows $215 profit and a 23.9% margin, and 400 good parts make that $1.71 profit a unit. > **Info:** > **No budgets on your tasks?** > > Then profit and margin have nothing to subtract from, and the **Financials** card reads as pure loss. Use **Total cost**, **Labor cost** and **Production cost** on that card and ignore the large number above them until budgets are in. ## Budget versus actual **Financials: Profitability**, the column chart below the cards, is where cost meets the quote. One column per bucket, bucketed on the date each task was *created*. The **Weekly** and **Monthly** toggle at its top right also moves the **Volume** chart above it. | Series | Color | Shows | Visible by default | |---|---|---|---| | **Budget** | Gray | The bucket's total quote, drawn as a wide bar behind the rest | No. Select it in the legend | | **Production cost** | Dark orange | Machine hours priced at **Production $/hr** | Only when no task in the window has a budget | | **Labor cost** | Light orange | Operator hours priced at **Labor $/hr** | Only when no task in the window has a budget | | **Profit / Loss** | Green, turning red below zero | Budget minus total cost, stacked on the cost | Only when at least one task has a budget | The chart reads your data before it draws. Give one task a budget and it switches from a cost breakdown to a profit stack, so two organizations looking at the same chart can see different series. Select **Budget** in the legend to put the quote behind the stack, and the gap between the gray bar and the colored one is the variance. The largest gap is the job worth opening. A week where production cost runs long against a flat budget usually means the machine took longer than the quote assumed, which the `Production / Labor (h)` column in the table below will confirm. ![The Financials Profitability column chart with a Weekly and Monthly toggle at its top right, showing gray Budget bars behind narrower stacks of dark orange production cost, light orange labor cost and a green Profit segment that turns red below the zero line in three weeks, with a violet arrow at the deepest of them, Aug 17](/images/production/prod-insights-04.webp) *Budget against actual. The largest variance is the job worth investigating.* **You do not need this page to know whether you are late.** On-time is visible on the scheduler board, where an overdue task is marked in place. Insights exists to put money on it. See [Plan jobs in the Production Scheduler](/docs/production/scheduler/). ## The operations table **Details: All operations** at the foot of the page is one row per task, 20 rows a page, sorted newest first. Select any header to sort by it. Three of its columns pack two numbers each, colored dark orange for production and light orange for labor: `Production / Labor (h)` draws a bar for each, scaled to the largest value on the page rather than in the whole report; `Production / Labor Cost` prices those hours; and `Production / Labor $/unit` divides by good count and adds a donut showing production's share of the cost. `Profit` and `Profit/u` are green at or above zero and red below. The **Group** pill above the table offers **None**, **Job** and **Asset**. Grouping moves that column to the front, keeps each group's rows together, and adds a totals row per group covering every matching row rather than only the page on screen. Group by **Job** to find the job that lost money, and by **Asset** to find the machine that keeps eating hours. ![The All operations table grouped by job, showing the Job, Operation, Part, Asset, WO #, Title, Status, Qty and Profit columns, with a totals row closing each of four job groups, a Group pill set to Job above it and an Export CSV button carrying a menu chevron above right](/images/production/prod-insights-05.webp) *The operations table, and its CSV export.* ## Export **Export CSV**, at the top right of the table, downloads every row your filters match in the sort order on screen, not only the visible page. With **Group** set to **None** it downloads at once. With **Group** set to **Job** or **Asset** it opens a menu offering **Operation rows**, **Totals by job** or **Totals by asset**, and **Rows + totals**. Column lists for all three layouts are in [Production Insights CSV](/docs/monitoring/exports-reference/#insights-csv). The file carries the rates you applied, baked into the cost columns, so label it with them before you send it on. ## When the report is empty | Symptom | Cause | Fix | |---|---|---| | **No insights available for the selected range.** | No task was created inside the window | Widen the date range before you suspect the data. A new board often has nothing in the last 90 days | | The cards read zero and the charts are blank | The filters exclude everything | Select **Reset** in the **Options** menu, then reapply one filter at a time | | **No workorders match the current filters.** under the table | The search box or a status button is still narrowing rows | Clear the search with the **✕** inside the pill, and select **All** | | **Not enough date data** under a chart | The matching tasks carry no creation date, so nothing can be bucketed | Check the range. An ERP import that skipped dates also causes it. See [Import a schedule from your ERP](/docs/production/import-erp-schedule/) | | Every cost column reads `$0.00` | Both rate fields are empty, so nothing is priced | Reopen **Options**, enter both rates, and select **Apply** | | Cost is zero but the work ran | No session was ever logged against the task, so there are no hours to price | See [Start, pause, and complete a job](/docs/production/run-a-job/) | | **Failed to load insights.** | The request for the report failed | Select **Retry**. If it repeats, narrow the range: a year at a busy plant is a large request | ## See also - [Plan jobs in the Production Scheduler](/docs/production/scheduler/) - [Start, pause, and complete a job](/docs/production/run-a-job/) - [Job and scheduler fields](/docs/production/job-fields-reference/) - [Exports and report columns](/docs/monitoring/exports-reference/) - [Compare production over weeks and months](/docs/production/historical-production/) --- # Quickstart: count your first parts Source: https://www.iotflows.com/docs/production/quickstart/ Take one machine from no production data to a part count you trust. Create a part on the Parts List at /production?select=parts_list, add an operation to it, set the operation's detection algorithm and ideal cycle time, then assign the operation to the machine from the asset's Auto-Detect button. Validate by running ten parts by hand and comparing them with the count on Shift Production. Every field saves as you leave it, and no part of this setup needs new hardware. # Quickstart: count your first parts One part, one operation, and a count on the screen you can trust. IoTFlows counts parts from the signal the machine's sensor already reports, so this setup adds no hardware. You create a *part*, the thing the machine makes, then an *operation*, one step in making it. The operation carries the two settings that turn signal into counts, and the machine has to be told which operation it is running. Allow about 20 minutes at the keyboard, plus the time the machine needs to make ten parts. **Before you start** - A machine already reporting to IoTFlows, with its running threshold set. See [Quickstart: see your first machine's data](/docs/get-started/quickstart/). - A stopwatch or a phone, for [step 4](#cycle-time). This page takes one part through the whole path with no branches. **You do not need to load every part you make before you count anything.** One part on one machine tells you whether the numbers are right, and a wrong setup repeated across 40 parts is 40 things to unpick. ## Create a part 1. Open **Production**, then the **Parts List** tab, at `/production?select=parts_list`. 2. Click **Add Part**. A part called `New Part` appears at the top of the list, and the dashboard confirms with **Part has been added**. 3. Click the part's name, type the number your plant already uses, for example `BH-4021`, and press Enter. Name the part what the traveler and the purchase order call it. Everyone who later reads a count or a job is matching it against paperwork, and a part called `Bracket v2` matches nothing. ![The top of the Parts List with the newly created part BH-4021 at the head of the list, GB-6610 Gear Blank beneath it, and a violet highlight on the Add Part button at the right of the toolbar](/images/production/prod-qs-01.webp) *Creating a part. Use the number your plant already uses.* > **Info:** > **Nothing appeared when you clicked Add Part?** The button creates the part straight away, with no dialog. If a red toast came back instead, the request failed and nothing was saved. Try again, and see [Contact support and report bugs](/docs/get-started/get-support/) if it keeps failing. ## Add an operation An *operation* is one thing the machine does to the part, for example a roughing pass or a press stroke. Counts, cycle times and goals all hang off the operation, not the part. 1. Click **+ Add operation** at the bottom of the part's table. 2. Type the operation name, for example `OP10`, and press Enter. The dashboard confirms with **Operation has been added**. 3. Click the **Description** cell and describe the step, for example `Rough mill`. 4. Click the circle in the **OP** column and set the step number, for example `10`. The rows reorder themselves to match. Leave **QTY/OP** at `1` unless one cycle of this operation finishes more than one part. A four-cavity mold is `4`; a milling pass is `1`. ![The BH-4021 part table on the Parts List, showing the row for OP10 described as Rough mill with the inline Add operation input open beneath it, and two numbered violet callouts: 1 beside the round OP step marker reading 10 at the left of the row, 2 inside the open operation name input](/images/production/prod-qs-02.webp) *Adding OP10 to a part.* Create one operation per thing the machine does differently, not one per line on the router. Two router steps that run at the same rate on the same machine count correctly as one operation, and halve your setup. ## Pick a detection algorithm A *detection algorithm* is the rule IoTFlows applies to the sensor's signal to decide that one cycle has finished. It is the single biggest influence on whether the count matches the floor. 1. Click **Select Algorithm** in the operation's **Algorithm** column. 2. Hover an option to read what it detects. 3. Click the one that fits. It saves as you pick it. The device narrows the choice before you do. A BeamTracker takes **Counter** and nothing else, and a SenseAi or SenseAi Embedded takes one of the three analysis algorithms. **On a SenseAi machine nobody has measured yet, start with Discrete Analysis.** It adapts to cycle-time variation instead of assuming a fixed cycle. Which to pick, and how to tell when you have picked wrong, is on [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/#choose). ![The Algorithm cell of an operation row reading Select Algorithm with its dropdown open below it, listing the four algorithms as colored pills in order: Continuous Analysis, Discrete Analysis w/o Merge, Discrete Analysis and Counter, with a violet highlight around the open dropdown](/images/production/prod-qs-03.webp) *The detection algorithm. Which one to pick is on its own page.* Set the algorithm before you go on. An operation with no algorithm never appears in the assignment list in [step 5](#assign), and the modal says so. ## Set the ideal cycle time The *ideal cycle time* is how long one good cycle of this operation takes when the machine runs well. Continuous Analysis divides running time by it to produce the count. The other three algorithms count the signal directly and read this number for goals and pace. 1. Time 10 to 20 complete cycles with a stopwatch, from the start of one to the start of the next. 2. Average them. Five cycles at 4:15, 4:30, 4:10, 4:25 and 4:20 average to 4:20. 3. Click the **Ideal Operation Cycle Time** cell and type the average across the `hr`, `min` and `sec` boxes. The box after the decimal point takes hundredths of a second, so a 1.33 second press stroke is `1` then `33`. 4. On the two Discrete algorithms, leave the `%` box at its default of `10`. It is how far a cycle may vary and still be read as this operation, and the cell shows the resulting range on hover. On a Counter operation the cell opens on a rate in ops per minute instead of the clock boxes. The arrow beside it flips between the two, and both write the same number. **Enter the best sustainable cycle, not the fastest one ever recorded.** Pace and the shift goal are both measured against this number, so a heroic figure makes every normal shift read as a failure. The full set of numbers this feeds, and the downtime filter that goes with it, are on [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/). ![The Algorithm and Ideal Operation Cycle Time cells of an operation row: a Discrete Analysis pill, then 0 hr, 4 min, 20 sec and 0 hundredths entered across four boxes, with a plus-or-minus 10 percent tolerance box beside them](/images/production/prod-qs-04.webp) *Ideal cycle time. Use the best sustainable cycle, not the fastest ever recorded.* ## Assign the operation to the machine The operation now knows how to count. The machine does not yet know it is running this operation, and until it does, nothing is counted. 1. Open **Assets**, click the machine, for example `HAAS VF-2`, at `/assets/selected-asset/:id`. 2. Click **Auto-Detect** in the toolbar. **Select Auto-Detect Operations** opens. 3. Pick the tab that matches your algorithm. A SenseAi machine shows **Discrete** and **Continuous**; a BeamTracker shows **Count**. 4. Select your operation. The **Discrete** tab takes checkboxes, so you can assign every discrete operation the machine runs in one pass. **Continuous** and **Count** take one operation at a time. 5. Click **Auto-Detect**. The dashboard confirms with **Discrete Auto-classification Set**. ![The Select Auto-Detect Operations modal opened from the asset HAAS VF-2, on the Discrete tab, its list of checkbox rows scrolled to the operation OP10 on part BH-4021, which is checked. Violet highlights mark the checked row and the Auto-Detect button in the footer](/images/production/prod-qs-05.webp) *Assigning the operation to the machine that runs it.* The tabs are exclusive. Selecting discrete operations clears any continuous operation the machine was set to, and the reverse, which the modal warns about above the list. Both entry points into this modal, and what to do when you have no measured cycle time at all, are on [Detect operations automatically](/docs/production/auto-detect-operations/). ## Run ten parts and check the count 1. Run the machine normally and count ten parts by hand as they come off. 2. Open **Production**, then **Shift Production**, at `/production?select=part`. 3. Find the row for your operation. The **Progress** gauge holds the good parts counted so far. 4. Compare the two numbers. **Validate with ten parts, not one shift.** A count that is right ten times in a row is right. A shift total that happens to land near the truth hides an error that only surfaces when someone quotes a job from it. Ten out of ten means you are done. Nine or eleven is close enough to accept and watch. Anything further out is a setup problem, not noise, and the accuracy bands that say which is which are on [Validate your choice](/docs/production/choose-an-algorithm/#validate). ![The Operation, Calculated Goal and Progress columns of the Shift Production board, eight operation rows deep. The last row is OP10 on part BH-4021, calculated goal 6, its Progress gauge full and green reading 10 made, with a violet highlight around that count in the center of the gauge](/images/production/prod-qs-06.webp) *Ten parts run, ten counted. Validate with ten, not with a shift total.* ## If the count is wrong Work through the table in order. Four of the six causes are settings you entered on this page, so rule those out before you go near the sensor. | What you see | Likely cause | Fix | |---|---|---| | The row is not on the board at all | The operation is not assigned to the machine, or the machine has not run since you assigned it | Repeat [step 5](#assign) and check the confirmation toast | | The count stays at zero while the machine runs | The machine reads as stopped, so there is no running signal to divide or to read cycles from | Check the machine's state on the Assets page, then [Set the running and stopping thresholds](/docs/hardware/calibrate-senseai/#thresholds) | | The count is roughly double | Every part rings twice and both rings are counted | Move to an algorithm that merges, see [Switch to a different algorithm](/docs/production/choose-an-algorithm/#switch) | | The count is roughly half | Two parts run close enough together to read as one cycle | Move to an algorithm that does not merge, same page | | The count is close but drifts through the shift | The ideal cycle time is off, and Continuous Analysis divides by it | Re-time the cycle and redo [step 4](#cycle-time) | | The count is right, the goal is not | The goal comes from the cycle time and the machine's OEE goal, not from the count | See [Set OEE and utilization goals](/docs/monitoring/oee-goals/#where) | Anything still wrong after that is on [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/). ## What to do next Repeat steps 1 to 5 for the other parts this machine runs, assigning the discrete ones together in one pass. Nobody has to touch the dashboard at a changeover after that. ## See also - [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/) - [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/) - [Track production against shift goals](/docs/production/shift-production/) - [Create parts and operations](/docs/production/parts-and-operations/) - [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/) --- # Start, pause, and complete a job Source: https://www.iotflows.com/docs/production/run-a-job/ The job runner is the page an operator works a task on, at /production/work-queue/. Start opens a work session, the part counter and the scrap button write to that session, and pause and complete both close it. Add to count adds to the session's count; Set session total replaces it, which is the mistake that costs a shift. Job History is where sessions are created, edited and deleted, and the right-hand rail carries the job's details, comments, files, queue and a maintenance request form. # Start, pause, and complete a job Work a task from the moment you pick it up to the moment you close it out, and log the parts and the scrap as you go. The *job runner* is the page an operator runs one [task](/docs/production/overview/#split) on: one operation, on one machine, for a quantity of a part. It opens at `/production/work-queue/` when you click a task in the Work Queue, and it is the only page that starts, pauses and completes production work. Everything the runner records hangs off a *session*: one continuous run of the task, with a start, an end, the good parts logged against it and the scrap. Starting the job opens a session and pausing closes it. **Before you start** - A task to run. See [Find your next job in the Work Queue](/docs/production/work-queue/). - Production Scheduler is part of the Scheduling Engine module. The tab renders for every organization, so seeing it is not proof you are entitled to it. See [Module entitlement](/docs/production/overview/#entitlement). - Nothing on this page is role-gated. Anyone who can open the task can start it, log parts against it, change its machine and complete it. ## Open the job 1. Go to the Work Queue at `/production?select=work_queue`. 2. Click the task. The runner opens and your filters travel with it in the address bar. The runner is four regions around a file viewer. The action rail on the left holds progress, **History**, the start control, the part counter, **Scrap** and **Complete Job**. The panel rail on the right holds the job's details, comments, files, queue and maintenance. The machine's shift status bar runs along the bottom. ![The job runner on the task Spindle run-in after rebuild, with its file viewer open. A row of file tabs runs across the top of the viewer: Drawing.pdf, a selected beam_case_v1_3_NT.stp, a screen recording, a text file, and two more STP files, followed by a chevron for more files and a download icon. The center pane shows a 3D STP model of a machined enclosure, with a small orientation cube at the top right and a hint reading Left click: rotate, Right click: pan, Scroll: zoom. A narrow rail down the left edge carries a Progress header reading 1114 / 5000 over a partly filled bar, 22.3% beside a red clock and 08:00 AM, a History button, a large Resume button with a green play icon, a This Session block with grayed minus and plus buttons around a zero over the line Total: 1114 / 5000, and grayed Add Parts, Scrap and Complete Job buttons. A rail down the right edge stacks Details, Comments, Files, Queue, Maintenance and a Classify button carrying a red 1 badge. A bar across the bottom shows the machine's photograph inside a green ring, the name DMG Mori - SenseAi Embedded and the identifier DMG MORI DMU 80 (HV), with a mixed red and green status bar under a timeline ruler from 8am to 5pm.](/images/production/prod-run-01.webp) *The job runner on a resumed task, with an STP file open in the viewer and its file tabs running across the top.* If the task carries a PDF or an image **of its own**, the runner opens it in the viewer for you. It picks the first PDF, or the first image when there is no PDF. A file that reaches the task through its part does not open itself, however many there are, so a task whose only drawing lives on the part opens on `No File Selected`. See [Files, including 3D models](#files). ## Start the job Press **Start**, the large button below **History**. The task moves to **In Progress** and the platform opens a session against it. ![A cropped detail of the top of the job runner's left rail. A Progress header reads 0 / 200 above an empty progress bar, with 0.0% at the left and a red clock icon beside 01:00 PM at the right. Below sits a History button, and under it a tall bordered button carrying a large circled play icon over the word Start in green, ringed in violet.](/images/production/prod-run-02.webp) *The Start button in the job runner's left rail. Starting the job opens a work session, and logging parts before that fails with No active session.* Three things stay disabled until a session is open: the part counter, **Scrap** and **Complete Job**. A task you have not started cannot be finished in one press. **Start and Resume are the same action.** Pressing **Start** on a fresh task raises the toast **Job resumed**, because the runner sends the same status change either way. The wording is misleading and the task did start. Starting does not assign the task to you. It flips the status chip, and the change reaches the Work Queue and the board within seconds. See [Pick up a job](/docs/production/work-queue/#pick-up). ## Log good parts The part counter sits under **This Session**. The minus and plus buttons move the session's count by one, and **Add Parts** opens a keypad for larger numbers. Every press writes to the server immediately and toasts **Parts updated**. There is no save button and no undo beyond pressing minus. ![The Log Parts dialog. A two-segment control at the top carries Add to count on the left, selected and filled white, and Set session total on the right, with violet callout 1 in front of the first label and callout 2 in front of the second. Under it a recessed panel is headed Parts to Add over a large 8, with the line Session total: 12 beneath. A three-column keypad of the digits 1 to 9, a C, a 0 and a backspace fills the lower half, over a footer holding Cancel at the left and Confirm at the right.](/images/production/prod-run-03.webp) *The Log Parts dialog. Add to count adds the number you type to the session's count; Set session total replaces it.* ### Log parts | Mode | Meaning | Use when | |---|---|---| | **Add to count** | Adds the number you type to the session's count. The dialog previews the result, so typing `8` into a session that already holds 4 reads `Session total: 12` | You are logging the parts you just made. This is the default and the right answer almost every time | | **Set session total** | Replaces the session's count with the number you type | You are correcting a count you already logged, and you know the true total for this session | | **+** and **−** | Add or remove one part | You are counting at the machine, one part at a time | **Use add when you are logging the parts you just made, and set when you are correcting the running total.** Operators reach for set out of habit and overwrite a shift's count with the last hour's. Two details make that mistake survivable. **Set session total** replaces the count for the current session only, not for the whole task, so an earlier shift's sessions keep their numbers. And a session you have overwritten can be repaired in **History**, see [Session history](#history). The minus button is disabled at zero, so a session count cannot go negative. If the write fails the runner toasts **Failed to update parts** and reloads the task, and the number on screen snaps back to what the server holds. Scrap is logged the same way, from the **Scrap** button beside the counter. Every scrap entry needs a reason, see [Log scrap and manage scrap reasons](/docs/production/log-scrap/). > **Warning:** > **Two part counts, one screen** > > The **Progress** bar at the top of the rail counts the parts you logged by hand, summed across every session. > > The **Quantity** line in the **Details** panel shows what the machine's sensor counted, or the override a planner typed in the Scheduler table. > > The two numbers are collected differently and will not match. The saw job in the screenshots on this page reads `24 / 40` in the rail and `12 / 40 pcs` in the panel at the same moment, with nothing wrong: the operator logged 24 by hand and the sensor counted 12. See [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/). ## Pause and resume Press **Pause** to stop for a break, a shift change or a breakdown. The **Pause Session** dialog opens on the session's count so you can correct it before the session closes. 1. Check **Parts Made This Session**. It is prefilled with what you logged, and the stepper or the field changes it. 2. Add scrap rows if the session produced scrap that is not logged yet. Each row needs a quantity and a reason. 3. Write a **Session Notes** line. The placeholder asks for the reason for pausing. 4. Press **Pause Session**. The task moves to **On Hold**, the platform closes the session, and the runner toasts **Job paused**. ![A cropped detail of the job runner's whole left rail on a paused job. The Progress header reads 24 / 40 over a bar filled just past halfway, with 60.0% at the left and a red clock beside 01:00 PM at the right. Under the History button, the large action button carries a circled play icon over the word Resume in green. Below it the This Session counter reads 0 with its minus and plus buttons grayed out over the line Total: 24 / 40, and the Add Parts, Scrap and Complete Job buttons are grayed out with it.](/images/production/prod-run-04.webp) *The job runner's left rail on a paused job, where Start has become Resume. Pausing closes the session and resuming opens a new one.* Press **Resume** to carry on. The task returns to **In Progress**, the platform opens a **new** session, and the counter starts again at zero. The total above it keeps every session's parts. A task run across three shifts therefore holds three sessions, which is exactly what **History** shows. That is the record the shift reports and the cost report read. **A paused job cannot be completed.** **Scrap** and **Complete Job** are both disabled while the task is on hold, because there is no session to write to. Press **Resume**, then **Complete Job**. ## Complete the job Press **Complete Job**. The dialog is the pause dialog with one section added. 1. Confirm **Parts Made This Session**. This is the last chance to correct the number before the session closes. 2. Check the scrap rows, and add any that are missing. 3. Read the inventory summary, described below. 4. Write a closing note if the next person needs one. 5. Press **Complete Job**. The task moves to **Completed**, the session closes, and the runner toasts **Job completed**. **Parts Consumed** and **Added to Inventory** appear above the notes when the task touches stock. They are a read-only statement of what closing the job does: the material it deducts, the parts it adds, and the tools it hands back to the crib. To change either list, close the dialog and edit the task's parts, see [Required and created parts](/docs/production/create-a-job/#parts). The section is hidden when you pause, because a pause moves no stock. A scrap row with a quantity and no reason blocks the save. The dialog stops with **Please select a reason for all scrap entries** and outlines the row in red. ## Reopen a completed job On a task that reads **Completed** or **Approved**, the large button becomes **Reopen Job**. Press it, write a **Reason for reopening**, and press **Reopen**. The task returns to **In Progress** and the runner toasts **Job reopened**. Reopen when the parts came back from inspection, or when the job was closed on the wrong count. Do not reopen to add a forgotten session: **New Session** in **History** does that without disturbing the status. ### Job actions | Action | Ends the session | Reversible | Available on | |---|---|---|---| | **Start** | No, it opens one | Yes, pause or complete | Web and mobile | | **Pause** | Yes | Yes, **Resume** | Web and mobile | | **Resume** | No, it opens a new one | Yes, **Pause** | Web and mobile | | **Complete Job** | Yes | Yes, **Reopen Job** | Web and mobile | | **Reopen Job** | No | Yes, complete it again | Web and mobile | Every action is on both platforms, none is role-gated, and none has a keyboard shortcut. The labels differ: the mobile buttons read **Start Work Order**, **Resume Work Order** and **Reopen Work Order**, see [On mobile](#mobile). ## Session history **History**, at the top of the left rail, opens the **Job History** dialog. It works at any status, including on a task nobody has started. ![The Job History dialog. A header reads Job History over Saw manifold billet · MS-7420 Manifold. Two tiles beneath give Good Parts 24 in green and Scrap 2 in red. A Work Sessions row follows, carrying 3h 7m total, a count chip reading 4 and a blue New Session button. Two date headings, Sun, Sep 20th, 2026 and Sat, Sep 19th, 2026, group four cards. Each card shows a time range such as 6:12 AM to 7:39 AM, a clock and a duration, a pencil and a trash icon, then Good and Scrap tiles. The two cards with scrap carry a Scrap Breakdown block naming the reason, its note and its quantity, and every card ends with the operator's session note. A Close button sits in the footer.](/images/production/prod-run-05.webp) *The Job History dialog: good parts and scrap totaled across every session, then one card per session with its own edit and delete controls.* The two tiles at the top are the task's totals, summed across sessions. Below them, sessions are grouped by date and ordered newest first. Each card carries its time range, its duration, its good and scrap counts, the scrap broken down by reason with each entry's own note, and the session note. It does not name who logged the session or who last edited it, so put anything the next shift needs into the note itself. A session still running reads **In Progress** where its end time would be. **New Session** opens the session editor with a **Start**, an **End**, a **Good Parts** stepper, scrap rows and a note. On a task with no sessions yet, the editor prefills the quantity ordered and the scheduled window, which is the case where you are closing out yesterday's job this morning. The pencil on a card opens the same editor on that session. The trash asks **Delete Session** and warns that it cannot be undone, then toasts **Session deleted**. > **Warning:** > **Deleting a session deletes its parts** > > A session carries the good parts and the scrap logged against it. Removing the session removes both from the task's totals, and from every report that reads them. > > Edit the session instead when the times are wrong but the counts are right. The editor refuses a window it cannot store, and says which rule you broke: **Session cannot start in the future**, **Session cannot end in the future**, **Start time must be before end time**, **Start and end time cannot be the same**, or **Overlaps with another session**, naming the job it collides with and the times. That overlap check reaches across jobs. It compares against every other production task on the same machine, so it catches a backfilled session that claims the press was running two jobs at once. ## The job detail panels The rail down the right edge opens one panel at a time over the viewer. **Details**, **Comments**, **Files**, **Queue** and **Maintenance** are panels; **Classify** opens a modal. ![The right side of the job runner. The Details panel is open, headed Details with a close cross, then the job title Saw manifold billet in cyan over two chips, PO-1012 and MS-7420 Manifold · OP10 Saw, each with a cross to clear it. Rows below give Machine with a thumbnail beside Haas EC-1600 and EC-1600ZT-5AX, Quantity reading 12 / 40 pcs over a part-filled progress bar, Due 9/18/2026, Duration 1h 18m, an Assigned To row holding one avatar and the name M. Reyes, and a Notes block reading Customer PO: 44823 and Plant: 1000. The rail down the right edge stacks six icon buttons, Details highlighted, then Comments, Files, Queue, Maintenance and Classify, the last carrying a red badge reading 58. Violet callouts 1 to 5 sit in the left padding of the first five buttons.](/images/production/prod-run-06.webp) *The job runner's right-hand rail with the Details panel open. The red badge on Classify counts stops on this machine that nobody has given a reason.* **Details** is an editor, not a summary. Four fields change the task from here, and each one saves as soon as you set it. | Field | How to change it | Notes | |---|---|---| | Parent job | Press the job chip and pick a job | The cross beside the chip clears it | | Part and operation | Press the operation chip and pick an operation | Changing it changes what the task counts | | Machine | Press the machine row, then pick a machine | Toasts **Machine updated** | | Quantity | Click the number, type, press **Enter** | **Escape** cancels | The rest of the panel is read-only: the part number, the due date, the duration, the assignees and the task's notes. Assignees cannot be changed here, see [On mobile](#mobile). **Queue** lists the tasks waiting behind this one and jumps to any of them. It holds only work assigned to you or to one of your teams, even though the page loads the whole queue, so an operator with no assignments reads `No items in queue` while the floor has plenty of work. **Classify** opens the machine's activity list filtered to **Unclassified**, and the red badge counts the stops on that machine nobody has given a reason. Clearing it from here is the same action as clearing it from the machine page, see [Classify a downtime](/docs/monitoring/classify-downtime/). The machine bar along the bottom draws the current shift for the machine the task runs on. Gray stretches are time the sensor reported nothing, not downtime. Clicking the bar opens the same machine modal as the **Machine** row above. ## Comments **Comments** is a chat room attached to the task, not a notes field. Messages persist on the work order, and everyone who opens the task sees the whole thread. Use it for the things the next shift needs and the session note is too small for: a fixture that needs shimming, a tool that is running long, a photograph of a bad edge. A task created before its chat room existed reads `No chat available for this job`. Log what you need in the session note instead. ## Files, including 3D models **Files** lists everything the task can open, in two sections. **Work Order Files** are attached to this task. **Part Files** come from the part, so they appear on every task for every operation on that part. Clicking a file opens it as a tab in the center viewer. Tabs stay open until you close them, so a drawing and a setup sheet can sit side by side. ### File types the viewer renders | File | Opens as | Controls | |---|---|---| | `.pdf` | An embedded document | Your browser's own PDF controls | | `.jpg` `.jpeg` `.png` `.gif` `.bmp` `.webp` `.svg` | An image | Zoom from 50% to 300%, and a reset | | `.step` `.stp` `.iges` `.igs` `.stl` | A 3D model you can rotate | The viewer's own camera controls | | `.mp4` `.webm` `.ogg` `.mov` | A video player | Play, scrub, volume | | `.mp3` `.wav` | An audio player | Play, scrub, volume | | `.txt` `.json` `.xml` `.csv` `.md` | Plain text | None | | Anything else | `Preview not available for this file type` | **Download File** | ![The center of the job runner with two tabs above the viewer: a document tab reading manifold-rev-c.pdf and an active tab carrying a cube icon and a truncated manifold-rev... name, each with its own close cross. A download icon sits at the far right of the tab strip. The viewer below renders a shaded 3D model of the manifold body, a long block with two raised bosses and three port bores through the top face, drawn in white against the panel. A small orientation cube sits at the top right of the viewer, and a pill along the bottom reads Left click: rotate, Right click: pan, Scroll: zoom.](/images/production/prod-run-07.webp) *A STEP file open in the job runner's center viewer, which renders 3D models alongside PDFs, images and video.* The download icon at the right of the tab strip saves the file you are looking at. A file attached to the task while you have the runner open opens itself in a new tab. **Attach the drawing to the part, not to the task.** A drawing on the part reaches every task on every operation for that part, and a drawing on one task reaches that task alone. See [Add pictures and files](/docs/production/parts-and-operations/#files). The one thing you give up is the automatic open. The runner only auto-opens a file the *task* carries, see [Open the job](#open), so an operator working from a part drawing has to press **Files** and click it. Attach it to the part anyway and take the extra click: a drawing that lives on one task is invisible on the next operation. ## Raise a maintenance request **Maintenance** opens a maintenance request form inside the runner, with this task's machine already filled in. Give it a title, a description, a priority and a due date, attach photographs, and press create. It toasts **Maintenance request created**. The request is a maintenance work order and lands in Maintain. Nothing about the production task changes: it stays **In Progress**, and its session keeps running while you fill the form in. **Use this panel for the fault that just stopped you, and Maintain for everything else.** From here the machine is filled in and you are already standing at it, which is what makes the request worth writing. Planned work, work on another machine and recurring work belong in [Submit a maintenance request](/docs/maintain/submit-a-request/). Setting a recurrence without a due date stops with **Set a due date first**. A failed create reads **Failed to create request**, and nothing was saved. ## On mobile The runner switches to the mobile layout inside the iOS and Android apps, and in any browser window narrower than 640 px. **The runner adds one rule the rest of the Work Queue does not: at 1024 px or wider it uses the web layout anyway**, so an iPad in the app gets the desktop runner in landscape. ![The job page on a phone. A header carries a back chevron labeled My Work, a wrench icon and a comments icon, then a part thumbnail beside WO #1043 and the title Bore and ream, with a green In Progress chip at the right. Below, an amber Pause button and a green Complete button sit side by side, ringed in violet. A Production Summary card follows, holding a circular progress ring reading 30 of 50, then Good Parts 30 and Scrap Parts 2 tiles, each carrying a This Session line. A This Session card with large minus and plus buttons around a 12 sits under it, then rows for All Production Sessions, the machine, and Classify Downtime.](/images/production/prod-run-08.webp) *The job page in the mobile app with the job running. Pause and Complete sit side by side above the production summary; completion is a button, not a slide.* The mobile page carries the same job and the same sessions, arranged as a scrolling list. - The primary action sits at the top: **Start Work Order**, **Resume Work Order**, **Pause** beside **Complete**, or **Reopen Work Order**. Completing a job is a button press, not a slide. - **Production Summary** draws the total as a ring. The **Good Parts** tile opens the keypad, and the **Scrap Parts** tile opens a scrap sheet that will not save until you pick a reason code. - The keypad's mode toggle reads **Add to count** and **Absolute**, and the button under it reads **Add Parts** or **Set Count**. Absolute is the same thing as **Set session total** on the web. - The **This Session** stepper vibrates on each press and ignores a second press inside 200 ms, so a gloved double tap counts once. - **All Production Sessions** opens the same **Job History** dialog. - **People** lists the requester and the assignees, with **+ Add** beside them. This is the only place in the Work Queue where you can put your own name on a task. - **Attachments** adds files from **Photos**, **Camera**, **Video** or **File**. Photographs are converted to WebP and capped at 1600 px before upload. Part files are listed but cannot be removed here. - **Classify Downtime** carries the shift bar and the unclassified count, and the wrench in the header opens the maintenance form. **The mobile viewer does not render 3D models.** A `.step` or `.iges` file opens in the plain file view, which cannot draw it. Open that task on a desktop runner when you need the model. ## When something fails | Message | What happened | What to do | |---|---|---| | **No active session** | You logged parts or scrap on a task that is not running | Press **Start** or **Resume** first | | **Failed to update parts** | The count did not save | The runner reloads the task, so read the counter before pressing again | | **Failed to record scrap** | The scrap entry did not save | Retry from **Scrap**. Nothing was written | | **Please select a reason for all scrap entries** | A scrap row has a quantity and no reason | Pick a reason, or set that row's quantity to zero | | **Failed to update work order** | The status change did not save | The chip may already show the new status. Reload the page to see the truth | | **Failed to update machine** | The machine change did not save | The task is still on the old machine | | **Failed to create session**, **Failed to update session**, **Failed to save session** | The session editor could not write | Nothing was saved. Check the times against the rules in [Session history](#history) | | **Failed to delete session** | The session is still there | Retry. Its parts are still counted | | **Failed to create request** | The maintenance request was not created | Retry from the **Maintenance** panel | If a part count looks wrong rather than a request failing, start at [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/). ## See also - [Log scrap and manage scrap reasons](/docs/production/log-scrap/) - [Find your next job in the Work Queue](/docs/production/work-queue/) - [Create a production work order](/docs/production/create-a-job/) - [Submit a maintenance request](/docs/maintain/submit-a-request/) - [Use Operator View on the shop floor](/docs/monitoring/operator-view/#jobs) --- # Find and fix problems in the schedule Source: https://www.iotflows.com/docs/production/schedule-issues/ The Schedule issues pill on the scheduler Gantt is the one place that lists everything wrong with the board: machines booked twice at the same time, serialized pieces two work orders both need, tooling with no units free, past-due work and work waiting on a predecessor that cannot finish in time. It is always on screen, including at zero, and its count is distinct work orders rather than findings. Conflicts and violations come first and carry one-click fixes that move the task to the earliest free slot; the two at-risk sections come last and are folded, because moving an overdue job's date is a judgment call rather than a repair. # Find and fix problems in the schedule One list of everything wrong with the board, and the one-click fixes for the problems that have one. Three separate things can be wrong with a schedule: a machine booked twice, a material two jobs both need, and work that will not land on time. The board finds all three and lists them in one panel. The panel is a read surface with buttons. It never blocks an edit, and it changes nothing until you press a fix. **Before you start** - Production Scheduler is part of the Scheduling Engine module. The tab strip renders for every organization, so seeing the **Scheduler** tab is not proof you are entitled to it. If you are not sure, [contact IoTFlows](/docs/get-started/get-support/). - Schedule issues live on the Gantt. The other four views do not carry the pill. See [Gantt view](/docs/production/scheduler/#gantt). ## Open Schedule issues The pill sits in the row above the chart, after the Gantt's display pills and before **Simulations**. It reads `3 issues` in amber when the board has problems and `No issues` in slate when it does not. Click it to open the panel underneath. ![A cropped detail of the right-hand end of the row above the Gantt chart. An amber pill carrying a warning triangle reads 21 issues and is ringed in violet. To its left, inside a white pill group, sit a filled blue Work sessions pill, an Optimize pill, undo and redo arrows and a download icon; to its right, a separate Simulations pill.](/images/production/prod-iss-01.webp) *The issues pill. The count is distinct work orders, so one work order with two problems counts once.* **The count is distinct work orders, not findings.** A task that is both double-booked and past due is one thing to go and look at, so it adds one to the pill and appears in two sections of the list. The list says the same thing in every grouping. Each engine reads the machine, the materials and the dependencies off the work order itself rather than off the lanes on screen, so grouping by job or by operator cannot make a clash disappear. It does read only what the board loaded. Filters and search change the set of work orders the board fetches, so narrowing to one department narrows the sweep with it. See [Filter and search](/docs/production/scheduler/#filters). ## How the list is ordered The panel groups rows into sections, one per kind and subject, ordered worst first: conflicts, then violations, then the two *at-risk* sections, meaning work the board expects to miss its date. Each section header carries its icon, its subject and a count, for example `Double-booked: Machine: Haas VF-2`. **The two at-risk sections come last and open folded.** On a busy floor almost everything is past due, and an open list of 200 overdue rows pushes the rows somebody can act on off the card. Click a header to fold or unfold it. ![The lower half of the Schedule issues panel, floating over the Gantt, with four numbered violet callouts down its left side. Callout 1 marks an amber section headed Double-booked: Machine: Press 4 with a count chip of 2, holding two rows. Callout 2 marks a rose section headed Piece in two places at once: BAR-41…, also with a chip of 2. Every row carries a work order number and title, a crosshair button, a sentence of detail, a smaller line of dates and a small fix button in the section's own color. Callouts 3 and 4 mark two red section headers at the bottom, Past due with a chip of 6 and Predecessor is late with a chip of 1, both collapsed behind right-pointing chevrons.](/images/production/prod-iss-02.webp) *The issues panel. At-risk sections come last and are folded, so the rows you can act on stay visible.* Every row names the work order, states the problem in one sentence, and carries a crosshair button that scrolls the chart to that bar and selects it. A double-booked row also prints the window the two jobs overlap, so you can cross-read it against the board. ## Conflicts: double-booked machines A task is *double-booked* when another scheduled, unfinished task needs the same machine over an overlapping stretch of time. It is the amber family, and today the only resource it watches is the machine on the work order. The detail sentence names up to three of the other jobs: **Needs the same machine as #1042 and #1043 at the same time.** Under it sits the overlap window. Three kinds of work occupy nothing and are never flagged: completed tasks, tasks with no due date, and tasks with no machine assigned. Bars that meet end to end do not conflict either, since the sweep allows a second of slack. ## Violations: piece conflicts A *violation* is a physical fact the schedule breaks rather than a timing clash. Violations are rose, and they are warn-only: the board flags them and still saves the edit that caused them. A *piece conflict* is the common one: two work orders hold the same serialized piece over the same window. A serialized piece is one physical object, a specific bar, roll or sheet tracked individually in Inventory, so the clash is real however different the two machines are. See [Serialized pieces](/docs/inventory/serialized-pieces/). **You do not need to author anything to get these.** Piece conflicts are computed from the reservations already in Inventory, so any two jobs needing the same piece surface here on their own. ![A rose section of the Schedule issues panel headed Piece in two places at once: BAR-41…, truncated, with a count chip of 2. Two rows are ringed in violet. They name #1416 Y841070 Bracket - OP10 Rough Mill and #1411 MS-7420 Manifold - OP10 Saw, and each repeats the sentence Piece BAR-4140-05 of 4140 Bar 2 in is held by 2 work orders at the same time. A piece can only be in one place at a time. Under that each row reads Peak 2 of 1 at Sep 29, 9:00 AM and carries a rose button reading Move to when BAR-4140-05 is free.](/images/production/prod-iss-03.webp) *A piece conflict. Two jobs need the same physical piece, computed from Inventory with no rule authored.* Holders the board cannot see still count. A maintenance work order or one filtered out by status occupies the piece, widens the window and is named under **Not on this board** with a link, but is never flagged itself, because it has no bar to ring. Reservations are unioned by part, not by location. Moving a bar to another shelf does not make it two bars. ### Tooling in use Reusable tooling is the other live violation. A rack, tube or fixture set is an ordinary inventory item marked reusable, reserved through a task's required parts, and it has a real count: **6 FX-220 Vise Jaw Set needed at once, but only 4 are available in this window.** Asking for more than the plant owns is worded differently and has no fix, because no amount of moving creates an eleventh set: **This work order needs 12 FX-220 Vise Jaw Set, but only 10 exist. Split the job, raise the capacity per unit, or get more.** Both kinds read real dates rather than bar positions, so they stay true in Sequence view, where the bars carry no time axis. See [the capacity lane](/docs/production/scheduler/#capacity) for the same occupancy drawn over time. ## At risk: overdue At risk is the red family, and **Past due** is the simpler half of it. It means the due date has passed and the task is not complete. The detail gives the date and the age: **Was due Sep 12, 3:00 PM, 8 days ago.** **At-risk rows carry no fix, on purpose.** Moving an overdue job's date is a judgment call about a commitment you made to a customer, not a repair the board can make for you. ## At risk: waiting on a late predecessor A *late predecessor* is an unfinished task this one depends on that cannot finish before this one is due to start. The board takes the later of the predecessor's due date and right now, and compares that with this task's start. The detail names them: **#1031 and #1034 cannot finish before this is due to start.** It stays a separate section from **Past due** because the remedy is different. A late predecessor is a sequencing problem you fix by moving one of the two bars or dropping the link; a past-due date is a promise you have already missed. ## Quick fixes Sections you can act on carry a button on each row, wearing that row's color. The label names what it will do, for example **Move to when Haas VF-2 is free**. ![A cropped detail of one amber row in the Schedule issues panel. It reads #1397 Y841070 Bracket - OP30 Deburr, with a crosshair button at its right, the sentence Needs the same machine as #1317 at the same time, a smaller line reading Sep 28, 2:00 PM to Sep 28, 5:00 PM, and an amber button reading Move to when Press 4 is free. A violet arrow runs in from the right and points at the button.](/images/production/prod-iss-04.webp) *A quick fix moves the task to the earliest slot when the machine frees.* A fix writes one work order: a new due date and an explicit **Time Estimate**. It goes into the undo history, so **Ctrl+Z** puts it back. If the write fails you get **Update failed, reverted** and the bar returns to where it was. The search respects the things you would expect it to. It starts no earlier than now, waits for every scheduled predecessor to finish, lands inside shift hours when [Working hours](/docs/production/scheduler/#working-hours) is on, and counts holders that are not on the board as occupants. **A fix is offered only when there is one.** No button appears on a locked bar, on a task with no due date, when the earliest free slot is where the task already sits, or when the demand is larger than the plant owns. > **Warning:** > **What does a fix write to a `~1h` bar?** A real 60-minute **Time Estimate**. A task drawn as an hour because nobody gave it a duration comes back carrying that hour as a number somebody chose, so put real estimates on the work before you start fixing it. See [Create a production work order](/docs/production/create-a-job/). The same fix appears as a rose entry on a bar's right-click menu when the bar has a rule violation. A double-booking's fix lives in the panel only. And the board warns you before you create the problem: drag a bar onto a window where a piece or a tool is already taken and the drag ghost grows a rose line saying so, without stopping the drop. Inside a Simulation a fix is staged rather than written, so it joins the draft and waits for **Commit**. See [Try a schedule change without saving it](/docs/production/simulate-a-schedule/). ### Issue kinds | Kind | Section | Color | Means | Quick fix | |---|---|---|---|---| | **Double-booked** | Conflicts | Amber | Two scheduled tasks need the same machine over the same stretch of time | Moves the task to the earliest slot when that machine frees | | **Piece in two places at once** | Violations | Rose | Two work orders hold the same serialized piece over the same window | Moves the task to the earliest slot when the piece frees | | **Tooling in use** | Violations | Rose | More units of a reusable tool are needed at once than are free in the window | Moves the task to the earliest slot when enough units free up | | **Tooling in use**, more than exists | Violations | Rose | The task alone reserves more units than the plant owns | None. Split the job or buy more | | **Past due** | At risk, folded | Red | The due date has passed and the task is not complete | None, on purpose | | **Predecessor is late** | At risk, folded | Red | A task this one depends on cannot finish before it is due to start | None, on purpose | The panel also carries wording for machine-eligibility rules and material shortages. Those arrive with authored scheduling rules, which are not shipped, so no board produces them today. ## Reading the colors on the board The panel is a legend for the board rather than a second vocabulary. Every color in it means the same thing on a bar. ![A cropped detail of five Gantt rows on one machine, each holding a single narrow capsule-shaped bar, with three numbered violet callouts. Callout 1 marks a bar filled and outlined in red, sitting left of the dashed NOW line. Callout 2 marks a bar washed with diagonal amber stripes, with an amber warning triangle beside its title. Callout 3 marks a plain slate bar carrying a thin rose ring, with a rose shield icon beside its title. The two remaining bars are also amber-striped.](/images/production/prod-iss-05.webp) *The board's color language: red at risk, amber double-booked, rose rule violation.* ### Color language | Color | On the board | In the panel | |---|---|---| | Red | The whole bar surface turns red | The **Past due** and **Predecessor is late** sections and their icons | | Amber | Diagonal stripes across the bar and a warning triangle beside the title | The **Double-booked** sections, their count chips and their fix buttons | | Rose | A thin ring around the bar and a shield icon beside the title | The violation sections, their count chips and their fix buttons | | Blue | A ring, meaning the bar is selected | Not used | A selection ring wins over a violation ring, so selecting a violating bar hides its rose edge until you click away. Amber stripes and a rose ring sit on the same bar happily, because sharing a machine and sharing a bar of steel are two different problems with two different remedies. The left rail carries the same two icons on a group header when anything inside it is flagged, and a bar's hover tooltip repeats the detail with the partner work orders named. ## When the list is empty The pill stays on screen at zero. It turns slate, swaps its triangle for a shield with a tick and reads **No issues**, and the panel says **Nothing is wrong with this schedule.** That is the point of an ungated surface: somewhere to look to confirm the board is clean, rather than something that only appears once it is not. **Work the conflicts and violations, and leave at risk folded.** Those two are schedule mistakes with mechanical fixes, and clearing them takes minutes. Overdue is a commitment problem, and no amount of dragging bars will fix it. Empty means clean for the work the board loaded and for the three things it checks. It is not a promise about material you never reserved, or about a department your filters left out. ## See also - [Plan jobs in the Production Scheduler](/docs/production/scheduler/) - [Try a schedule change without saving it](/docs/production/simulate-a-schedule/) - [Generate a schedule proposal](/docs/production/optimize-the-schedule/) - [Serialized pieces](/docs/inventory/serialized-pieces/) --- # Give people access to a scheduler board Source: https://www.iotflows.com/docs/production/scheduler-members/ Board membership decides who can be assigned work on the Scheduler. Your organization has one production board, and you add people to it as named members or as whole teams. The Invite to Scheduler dialog writes as you click, with no Save step: one click adds a person or a team, a crown marks a board owner, and a trash icon removes access. Owner is recorded on the board but the dashboard does not gate anything on it today. # Give people access to a scheduler board Add planners and operators to the Scheduler board, and decide who owns it. A *board* is the shared container behind a work-order surface. Your organization has one production board, and it sits behind the **Scheduler** tab. Board membership is what fills the **Assignee** list, so a person who is not on the board cannot be given a job. You add either a *member*, one named person, or a team. Adding a team adds everyone in it, both the people in it today and anyone added to it later. **Add teams rather than people.** A board built from named individuals needs editing every time someone changes shift or leaves. A board built from **Press cell** and **Planning** does not. **Before you start** - Production Scheduler is part of the Scheduling Engine module. The tab strip renders for every organization, so seeing the **Scheduler** tab is not proof you are entitled to it. See [Module entitlement](/docs/production/overview/#entitlement). - Board owner. The dialog is not role-gated in the dashboard, so anyone who can open the Scheduler can open it and change who is on the board. See [Roles and permissions](/docs/admin/roles-reference/). - A team has to exist before you can add it. See [Create and manage teams](/docs/admin/teams/). ## Open board members 1. Open the **Scheduler** tab of the Production page. See [Open the board](/docs/production/scheduler/#open). 2. Press the **Invite** control in the row above the board, between **Jobs** and the blue **+** that creates a work order. It carries a stack of the current members' avatars, and on windows narrower than about 1280 px the word **Invite** drops and only the avatars remain. The dialog is headed **Invite to Scheduler**. ![The Invite to Scheduler dialog. A search field at the top reads Who would you like to add?, and under it a line with a building icon reads Anyone in your organization can access this board. Below that a TEAMS heading with a count of 1 lists one team row, Press cell, carrying its handle, a stack of its member avatars, a dashed plus button, a filled blue crown, and a trash icon. Under it a MEMBERS heading with a count of 3 lists three people, each with their name, username, a crown and a trash icon; the first person's crown is filled blue and the other two are outlined.](/images/production/prod-schedmem-01.webp) *The Invite to Scheduler dialog, with one team and three named members on the production board. Add teams rather than individuals.* There is a second way in, for the moment you notice the person you want is missing from the assignee list. In **Create Workorder**, open the **Assignee** chip and press **Manage board members** at the foot of the dropdown. The same dialog opens, headed **Invite to this board**. On a phone, it opens as a bottom sheet from the avatar stack in the Scheduler header. ## Invite a member 1. Click the search field, **Who would you like to add?**. The list opens with every team in your organization under **Teams**, then every person under **Users**. 2. Type to filter. Full names, team names, handles, usernames and email addresses all match. 3. Click the person. The dialog writes as you click, so there is no Save button. A toast reads `User has been added to your board`, and the person appears under **Members**. People outside your organization are not listed here. To give a contractor a job, add them to the organization first, see [Invite people to your organization](/docs/admin/invite-members/). ## Invite a team Open the same search field and click a team under **Teams**. The toast reads `Team has been added to your board`, and the team appears in the **Teams** section above **Members**. Each team row carries its members as a stack of up to three avatars, or the text `0 members` when the team is empty. **Check that count before you rely on the team.** An empty team sits on the board but puts nobody in the assignee list. To fill it without leaving the board, press the dashed **+** on its row. A panel headed **Manage** plus the team's name opens, listing who is already **In team** and offering everyone else under **Add people**. This writes to the team itself, so a person you add here joins that team everywhere it is used, not only on this board. ## Make someone an owner A *board owner* is a member marked as responsible for the board. Click the crown on a member's or a team's row to set it. The crown fills blue, its tooltip changes from **Mark as board owner** to **Board owner · click to remove**, and clicking it again takes ownership away. There is no confirmation step and no success toast; the crown filling in is the confirmation. Teams hold ownership on the same terms as people. ![A cropped detail of the MEMBERS section of the board members dialog, headed MEMBERS with a count of 3, showing the first two of its rows. The upper row's crown icon is filled solid blue, marking that person as a board owner, with a violet highlight ring drawn around it; the lower row's crown is a gray outline. Both rows also carry a trash icon at the far right.](/images/production/prod-schedmem-02.webp) *The crown on a member's row, filled blue to mark a board owner. The row beneath it shows the same control in its unset, outlined state.* ### Board roles | Role | Can view the board | Can edit jobs and tasks | Can manage members | |---|---|---|---| | Member | Yes | Yes | No | | Owner | Yes | Yes | Yes | > **Warning:** > **Does the dashboard enforce this?** > > Not today. The members dialog, the crown and the trash icon render for everyone who can open the Scheduler, and the dialog's own line reads **Anyone in your organization can access this board**. > > Treat Owner as a record of who is responsible for the board rather than as a lock. Organization roles are a separate system and do gate features, see [Roles and permissions](/docs/admin/roles-reference/). **You do not need to add someone so they can look at the board.** Membership decides who can be assigned work. Adding every operator who glances at the Gantt lengthens the assignee list without changing what anyone can see. ## Remove access Press the trash icon on the row. The row disappears at once, with no confirmation step, and a toast reads `User has been removed from board` or `Team has been removed from board`. Removing a team takes that team's access away from this board only. The team itself and the people in it are untouched, and anyone who is also on the board under their own name keeps their access. To take a person out of a team rather than off the board, press the dashed **+** on the team's row and remove them under **In team**. ## If a change does not stick Every action here is optimistic: the row updates first and the request follows. When the request fails, the row goes back to what it was and a toast names what failed, so a change that draws and then reverts a second later has not been saved. | Toast | What it means | |---|---| | `Failed to update owner` | The ownership change did not reach IoTFlows. The crown reverts to its previous state. | | `Failed to remove` | The member or team is still on the board, or the person is still in the team. | | `Failed to add` | The person was not added to the team. The team's member count is unchanged. | ## See also - [Create and manage teams](/docs/admin/teams/) - [Give people access to Maintain](/docs/maintain/board-members/) - [Roles and permissions](/docs/admin/roles-reference/) - [Plan jobs in the Production Scheduler](/docs/production/scheduler/) - [Find your next job in the Work Queue](/docs/production/work-queue/) --- # Plan jobs in the Production Scheduler Source: https://www.iotflows.com/docs/production/scheduler/ The Production Scheduler at /production?select=scheduler shows one production schedule in five views: List, Table, Gantt, Kanban and Calendar. Table is the default and the only view with a CSV button. Grouping by asset, job or operator changes what the rows and columns mean in every view but Calendar. Dragging work between machines, editing in place and linking dependent tasks all write straight to the work order and revert on screen if the write fails. The Gantt carries Sequence view, Working hours mode, the work-sessions strip, unscheduled chips and the capacity lane. # Plan jobs in the Production Scheduler Five views of the same schedule, and how to move work between machines and people. The scheduler board holds every production work order your plant has open. It is one dataset drawn five ways, and switching views changes nothing about the schedule, only what you can see and what you can grab. This page covers all five views, the controls they share, and the Gantt-only controls that make dates on the board mean the same thing as dates in the plant. **Before you start** - Production Scheduler is part of the Scheduling Engine module. The tab strip renders for every organization, so seeing the **Scheduler** tab is not proof you are entitled to it. If you are not sure, [contact IoTFlows](/docs/get-started/get-support/). - You need membership of the scheduler board. That is a board-level permission rather than an organization role. See [Give people access to a scheduler board](/docs/production/scheduler-members/). - The board schedules operations, so your parts need routings before anything can land on it. See [Create parts and operations](/docs/production/parts-and-operations/). ## Open the board Go to **Production**, then the **Scheduler** tab, at `/production?select=scheduler`. Three words carry the whole page. A *job* is the order: a part and a quantity, like 400 of MS-7420 Manifold. A *task* is one operation of that job on one machine, like OP20 Mill on Haas VF-2, and tasks are what you see on the board. A *board* is the scheduler itself, with its own member list. The board opens in whichever view you used last. On a first visit that is **Table**. The view is remembered in your browser rather than in the URL, so a link you paste to a colleague opens on their view, not yours. ![The Scheduler tab of the Production page, full width. A control bar across the top holds a search button, a view pill and a group-by pill, both drop-downs, a compact-mode toggle, a three-part status filter with Active selected, and on the right Import, Jobs, Invite and Create buttons. Below it, rows of work orders sit under collapsible machine headings reading HAAS EC-1600 with seven tasks and HAAS VF-2 with thirteen, each row carrying a work-order number, a title, a due date that turns red once it has passed, an operation name, a status chip and a time.](/images/production/prod-sched-01.webp) *The scheduler board at /production?select=scheduler, in List view. The same schedule is available in five views from the view pill in the control bar.* ### Which view answers which question | View | Best for | Drag to reassign | Edit in place | Dependencies | |---|---|---|---|---| | **List** | Reading the backlog top to bottom, grouped | No | Status only | Not shown | | **Table** | Comparing fields across many tasks, and exporting | Yes, rows between groups | Most columns | **Dependent on** column | | **Gantt** | Sequence, overlap, dependencies and capacity | Yes, bars between lanes | Dates and durations, by dragging | Arrows between bars | | **Kanban** | Moving work between machines, jobs or people | Yes, cards between columns | Title, time estimate, status, assignee | **Dependencies** card field | | **Calendar** | Seeing the week the way the floor sees it | No | Dates and durations, by dragging | Not shown | **Use Gantt when sequence and dependencies are the problem, Kanban when the question is who or which machine owns a task, and Table when you are about to export.** Calendar is the one to open when somebody asks what Tuesday looks like. ## List view List is the flattest view: one row per task, under a heading for each group. A row carries its status chip, title, operation, assignees and due date, and turns its due date red once it has passed. Clicking the status chip changes the status without opening anything. Nothing else on the row is editable, and you cannot drag a row anywhere. Open a task by clicking it, and it fills the panel on the right. ## Table view Table is the default view and the only one with a CSV button. Each row is a task and each column is a field, with the columns you are not using turned off rather than deleted. The always-on columns are **Workorder**, **Assigned To**, **Operation**, **Required Qty**, **Machine** and **Part of Job**. Every other column is optional, and only **Quantity Progress** and **Status** are on out of the box. Turn the rest on from the column control, drag the headers into the order you want, and both choices are remembered in your browser. Most cells edit in place. Click a cell, change it, and the board writes the work order as you leave the cell. ![The scheduler in Table view, full width, grouped by asset. A machine heading row reads Haas EC-1600, and the seven rows beneath it carry columns headed Workorder, Assigned To, Operation, Required Qty, Machine, Part of Job, Quantity Progress and Status. Each row starts with a drag handle, and the assignee names are redacted. A CSV button sits at the right of the control bar above the table.](/images/production/prod-sched-02.webp) *Table view, grouped by asset. Each row is one task and each column a field; this is the only view with a CSV button.* Column meanings are in [Job and scheduler fields](/docs/production/job-fields-reference/), which is also the column list for the export. ## Gantt view Gantt draws each task as a bar on a time axis, in a lane per machine, job or person. It is the only view that shows how work overlaps, and the only one that draws dependencies as arrows. A bar's right edge is its due date, which is the anchor. The start is worked backwards from the duration, so shortening a task moves its start and leaves its due date alone. A task with no duration of its own is treated as an hour long. Drag a bar to move it, drag either edge to resize it, and drag it into another lane to reassign it. Click selects; double-click or right-click then **View work order** opens the panel. Hold **Ctrl** and click a bar to select everything up and down its dependency chain. ![The scheduler in Gantt view, full width, with the machine filter set to two machines. A left rail lists the Line 10 and Press 4 lanes, each with a name, a machine identifier and a task count, and one row per task beneath it. The plot to the right shows task bars under a two-tier date header running Thursday 17 to Saturday 26 September, with a red NOW line through Saturday 19. A grey connector elbows from the OP10 PL-3080 Cover Plate bar on Press 4 up to the OP20 bar on Line 10, and a violet arrow traces it. A toolbar above the chart holds Sequence, Working hours, Work sessions and Optimize pills, an issue count and Simulations.](/images/production/prod-sched-03.webp) *Gantt view, grouped by asset, with dependency arrows drawn between bars. Use it when sequence and dependencies are the problem.* Three surfaces live on the Gantt and have pages of their own. **Schedule issues** lists everything wrong with the board, and is there even at zero: see [Find and fix schedule problems](/docs/production/schedule-issues/). **Optimize** proposes a replanned schedule you can review before applying: see [Optimize the schedule](/docs/production/optimize-the-schedule/). **Simulations** turns the board into a draft that writes nothing until you commit it: see [Try a schedule change without saving it](/docs/production/simulate-a-schedule/). ## Kanban view Kanban draws one column per group and one card per task. **The columns are the grouping, not the status**: grouped by asset you get a column per machine, grouped by operator a column per person. A task's status is a chip on the card that you click to change, and there is no status-column board. Drag a card to another column to reassign it. Click the title or the time estimate on a card to edit it in place. ![The scheduler in Kanban view, full width, grouped by asset. Four columns are headed with a machine picture and name: Line 2, DMG MORI DMU 80 - SenseAi Embedded, Line 10 and Line 4. Each holds a stack of cards, and a card carries its work-order number, a priority chip, a group chip, a status chip reading On Hold, In Progress or Not Started, an assignee avatar, the task title, the machine and the job it belongs to. Cards on tasks that have made parts also carry a quantity-progress bar reading 2400 made against 6000 required.](/images/production/prod-sched-04.webp) *Kanban view, grouped by asset: one column per machine, and status as a chip on each card rather than as a column.* ## Calendar view Calendar places each task on the day and time its due date falls, and is the only view with no grouping at all. Drag an event to move it and drag its edge to resize it, and both write the due date and the duration. ![The scheduler in Calendar view, full width, showing the September 2026 month grid with a Today button, back and forward arrows and a Month, Week, Day switch. The first two weeks are empty and the last two carry a stack of task entries on each weekday, each a single line with a status icon and the task title, and a plus-three-more link where a day holds more than five. The control bar above shows Machines and Operations filter pills and no group-by pill.](/images/production/prod-sched-05.webp) *Calendar view, two weeks of the schedule placed by due date. It is the only view with no grouping control.* **You probably do not want Calendar as your planning view.** It has no lanes, so two tasks on the same machine at the same time look no different from two on different machines. Plan on the Gantt and use Calendar to answer date questions. ## Group by asset, job or operator The group-by pill sets what the rows, lanes and columns mean. It applies to List, Table, Gantt and Kanban, and carries in the URL as `scheduler_group_by`. | Group by | The question it answers | |---|---| | **Asset** | What is this machine doing next | | **Job** | How far through this order are we | | **Operator** | Who is overloaded | | **None** | One flat list of everything | **Grouping by operator answers "who is overloaded"; grouping by asset answers "what is that machine doing next".** Switch between the two rather than picking one, because a board that looks balanced by machine is often piled onto two people. Regrouping is free. It does not reload the board and it cannot change what the board thinks is wrong: double-bookings and rule violations are read off each work order, not off the lane it happens to be sitting in, so the issue count is the same in all four groupings. ![A cropped detail of the scheduler control bar. The group-by pill, an icon-and-chevron drop-down, is ringed in violet, and its open menu lists Asset, Job, Operator and None with a blue tick beside Operator. The view pill sits to its left, filled blue.](/images/production/prod-sched-06.webp) *The group-by pill set to Operator. Grouping by operator answers who is overloaded; by asset, what that machine does next.* ## Reassign by dragging Dragging a task into another group reassigns it, and what gets written depends on the grouping: the machine when grouped by asset, the parent job when grouped by job, and the assignee when grouped by operator. The write is optimistic. The task appears in its new home straight away, and goes back if the server refuses. ![Two machine lanes of the Gantt, cropped: Line 10 with four task rows above, Press 4 below. The OP10 PL-3080 Cover Plate bar is held mid-drag out of the Press 4 lane, with a dashed path rising from it to a ringed ghost bar in a highlighted Line 10 row and a chip beside it reading Sep 24, 12:00 AM to Sep 24, 3:00 AM, then Line 10. A violet arrow traces the same path.](/images/production/prod-sched-07.webp) *A task mid-drag from one machine lane to another. Dropping it writes the new machine onto the work order.* Two limits are worth knowing before you try. On the Gantt, lane dragging reassigns only when the board is grouped by asset or job; grouped by operator the bars stay put, and you reassign the person from the Kanban, the Table or the task panel. And dropping anything into an **Unassigned** lane does nothing, because there is no machine or job to write. Clear the field from the task panel instead. ## Edit in place Most edits happen on the board rather than in a form. Every one of them writes a single work order immediately, and there is no Save button anywhere on this page. | Where | What you can change | |---|---| | Table cell | Title, assignees, quantity, machine, job, due date, time estimate, status, dependency, budget, notes and the other optional columns | | Kanban card | Title, time estimate, status, assignees | | List row | Status | | Gantt bar | Start, duration and, by lane, machine or job | | Calendar event | Due date and duration | | Task panel | Every field, including the ones no view exposes | When a write fails, the board puts the old value back on screen and tells you. That is the behavior to rely on: if the value is still there after the toast, it did not save. ![A cropped detail of Table view with the Due Date column turned on. A toast pinned to the top of the window, ringed in violet, carries a red cross and reads Issues updating due date. Three rows show below it under headings Part of Job, Due Date, Quantity Progress and Status, and the Due Date cell on the JOB-2784 row still reads Oct 1, 1:00 PM, the value it held before the edit.](/images/production/prod-sched-08.webp) *An inline edit that the server refused. The board reverts the change on screen and raises a toast naming the field.* ## Link dependent tasks A *dependency* says one task cannot start until another finishes. Each task holds at most one. On the Gantt, hover a bar, then drag from the small handle at its right edge onto the bar that follows it. The line turns invalid while you are over a target that would close a loop, and dropping it there raises **That link would create a circular dependency** and writes nothing. Elsewhere, set it from the **Dependent on** column in Table or from the task panel. Remove a link by right-clicking the bar and choosing **Remove dependency**, or by clearing the field. Dependencies drive the red bars. A task turns red when its own due date has passed, or when an unfinished predecessor cannot finish in time for it to start. A predecessor that is merely still open, but on schedule, leaves its dependents alone. ## Schedule work that has no dates A task with no due date is *unscheduled*. It is not hidden: on the Gantt it keeps a tinted row in the left rail, marked with a crossed-out calendar where the date would be, and a chip pinned down the left edge of the chart, inside its own machine, job or operator group. The group header counts them in a badge carrying the same icon. Drag a chip onto the chart to schedule it. It snaps to the next sensible slot, after its predecessor or after the last task on that lane, and **a task dragged in with no time estimate of its own takes a default duration of one hour**. Set a real estimate afterwards, or the board is planning against a number nobody chose. Chips select like bars, so you can schedule a backlog in one gesture: click one, **Shift**-click another to take the range, or use the group header's orange calendar pill to take every date-less task in that group, then drag the lot in. They land back to back from the drop point. Dragging a scheduled bar back over the left rail unschedules it again, and so does **Clear date** in its right-click menu. ![The left portion of a Gantt board grouped by asset. The DMG MORI DMU 80 lane header carries a badge of a crossed-out calendar and the number 2, and the two amber-tinted rows below it end in that same crossed-out calendar icon where a date would be. Each of those rows carries a small chip pinned just right of the left rail, with a grip handle and the operation name. A violet arrow runs from the upper chip rightwards onto the chart, to a green dashed ghost bar marking the drop point, and a card beneath it reads Sep 16, 8:00 PM, finishes Sep 16, 9:00 PM, assigns to DMG MORI DMU 80 - SenseAi Embedded.](/images/production/prod-sched-15.webp) *Unscheduled work floats as chips down the left of the Gantt until you drag it onto the chart. Work dragged in with no time estimate takes a one-hour default duration.* ## Read the Gantt in Sequence view Three pills above the Gantt change what the bars mean rather than what is on the board. All three remember their setting. ### Gantt display modes | Mode | Shows | Disabled when | Persisted | |---|---|---|---| | **Sequence** | Equal-width bars in execution order, with no time axis | Never | Yes | | **Working hours** | Durations that consume shift time only | No shifts are set up for the organization | Yes | | **Work sessions** | A strip under each bar carrying what operators logged | Sequence is on | Yes, and on by default | **Sequence** strips the time axis out and gives every task the same width, in the order the work runs. It answers "what comes after what" on a board where a three-day job and a twenty-minute one are otherwise incomparable. It is read-only: dragging a bar there has no time to write, so nothing moves. Zoom, the work-sessions strip and the capacity lane all switch off with it, because each of them is drawn against a time axis that Sequence does not have. ![A Gantt board with the Sequence pill filled blue in the toolbar and ringed in violet. The header above the plot reads EXECUTION ORDER over numbered columns one to ten instead of dates, and every bar is the same width, placed in the column matching its position in the run order. The Work sessions and Optimize pills beside the Sequence pill are dimmed, as is the zoom bar. One bar is drawn in red with a dashed red link running to the task that depends on it.](/images/production/prod-sched-11.webp) *Sequence view: equal-width bars showing execution order only. There is no time axis, so work sessions and Optimize are unavailable here.* ## Turn on Working hours **Working hours** makes durations consume shift time only. With it off, a 14-hour job started at 8am finishes at 10pm whether or not anybody is in the building. **Turn on Working hours before you trust any Gantt date.** Without it a 14-hour job on an 8-hour shift finishes overnight on the board and tomorrow afternoon in the plant. The pill is disabled until your organization has shifts, with the tooltip **Set up work shifts in Organization Settings to enable working-hours scheduling**. See [Shifts and timezone](/docs/admin/shifts-and-timezone/). Once shifts exist, the board shades the off-shift stretches and every drag, resize and optimizer run respects them. ![A cropped detail of the Gantt toolbar and the top of the chart. The Working hours pill, carrying a clock icon, is filled blue and ringed in violet, with the Sequence pill beside it inactive and Work sessions active. The plot below lays diagonal hatching over every off-shift stretch, and the task bars sitting inside those stretches carry the same hatch and a warning triangle. The issue count beside the pills reads 13 issues.](/images/production/prod-sched-12.webp) *The Working hours pill, on. Durations consume shift time only, so a 14-hour job on an 8-hour shift spans into the next day.* ## Compare the plan with what was logged A *work session* is a stretch of time an operator clocked against a task, carrying the parts they made in it. The **Work sessions** pill draws those sessions as a strip under each bar, and it is on by default. The strip is drawn in absolute time, not relative to the bar, which is the whole point: a session that started before the planned start hangs left of the bar, and one that ran past the due date hangs right of it. Blue is worked time, green means a session is running right now, amber means it finished past the due date, and the hatched gaps are idle stretches between sessions. Click a segment to open that session's history, or right-click a bar and choose **Work sessions**. Unscheduled tasks get a strip too, because work gets logged against tasks nobody dated. ![Two Gantt rows of one job, cropped. Under each planned bar sits a thin strip of logged session blocks. The top strip starts left of its bar and runs two blue blocks reading 180 and 220, either side of a hatched idle gap, ending in an amber tail past the bar's right edge. The bottom strip runs a blue 150 block, a hatched gap, then an In Progress block capped in green that reaches the red NOW line. A violet arrow runs from the top planned bar down onto the overrunning end of its strip.](/images/production/prod-sched-13.webp) *The work-sessions strip under each bar: what operators actually logged, against what was planned.* ## Read the capacity lane The *capacity lane* is a band docked below the Gantt, drawn on the same time axis as the bars. It has no on-off switch. It appears when the board has something to put in it, and it holds two independent sections that fold separately from the lane's own header. ### Capacity lane rows | Row | Shows | Comes from | Appears when | |---|---|---|---| | **Tooling** | How many units of a reusable tool are left on the shelf over time, stacked by the work order holding them | A reusable inventory item reserved on a task's required parts | Any task on the board reserves that tool, or a task returns units of it | | **Projected output, part** | Finished parts of one part number over time, opening at what is on the shelf today | The **Create/Release Parts** lines on each operation | A work order on the board declares that it creates that part | | **Projected output, operation** | The buffer waiting between one step and the next | The scheduled quantities on each step of the routing | The part has more than one operation, for every step but the last | Tooling rows answer more than how many are taken at 2pm. Because the columns are stacked by work order, they also say which job is holding them and when it gives them back. A row crossing below zero is a shortage, drawn in rose. **Projected output is declared, never guessed.** It is computed from the **Create/Release Parts** field on the operation, so a part nothing on the board declares gets no row, and a board that declares nothing gets no output section at all. That is the payoff for binding materials in the first place. See [Link required and created parts to an operation](/docs/production/bind-materials/) and [How work orders move stock](/docs/inventory/how-work-orders-move-stock/). ![The capacity lane docked below a Gantt board, its tooling row ringed in violet. The label cell reads FX-220 Vise Jaw Set over 8 of 10 sets left, and the plot beside it is a step chart drawn on the same time axis as the bars above: it opens at a dashed capacity line of 10, drops to 8 when a job takes two sets, dips to 7 and back to 8 twice as other jobs take and return theirs, and climbs back to 10 when the last job hands its sets in. Above the lane sit three Y841070 Bracket tasks and one MS-7420 Manifold task, the work those steps belong to.](/images/production/prod-sched-14.webp) *The capacity lane's tooling rows: units in use over time, stacked by work order, so you can see which job holds them and when it gives them back.* ![The capacity lane docked below a Gantt board, whose Robot Line 3 lane holds two OP30 Hugo Benzing Ring rows. The lane opens with a Tooling capacity header over a thin FX-220 Vise Jaw Set heat strip, then a Projected output header. Under that, a part header row carries a round gear picture, the name Hugo Benzing Ring and the line 0 on hand, 10,000 by Sep 29, beside a green cumulative curve that climbs dashed and settles solid with the running total 6,000 printed on it. Two amber operation rows, OP10 and OP20, sit indented beneath. A violet arrow drops from the first OP30 bar on the board straight down to the point where the output curve steps up.](/images/production/prod-sched-16.webp) *The projected output row. It is computed from the Create/Release Parts field on an operation, so the curve forecasts finished parts across the scheduled work.* ## Zoom and move around The bar along the bottom of the Gantt holds the navigation. Zoom in and out with the plus and minus buttons, jump to a density with the **Hour**, **Day**, **Week** and **Month** presets, fit the whole schedule on screen, or jump to now. The board opens on **Day**, and on the planned work rather than on wherever the history starts. Hold **Ctrl** or **Cmd** and scroll to zoom at the cursor, which on a trackpad is a pinch. Plain horizontal scroll pans. The zoom controls are all inert in Sequence view. Select bars and the same bottom bar grows a second half: nudge the selection an hour or a day either way, align every start to the earliest, distribute one after another honoring setup time and dependencies, or clear the dates entirely. **Esc** clears the selection. ## Undo and redo Every edit the board makes is undoable with **Ctrl+Z**, and **Ctrl+Shift+Z** puts it back. The undo button's tooltip names the change it is about to reverse, so you can check before you press it. The history holds the last 50 changes and is cleared when you enter or leave a Simulation. **Deleting is the exception and cannot be undone here.** A deleted work order goes to trash on the server for 30 days, which is a different thing from a schedule change the board can invert, so it never enters the undo history. ## Filter and search Filters and search change what the board loads, not what it hides, so they apply to all five views at once and their settings live in the URL. | Control | Filters by | Shown when | |---|---|---| | Machines | Department and machine | Grouped by asset or none, and always in Calendar | | Parts and operations | Part and operation | Grouped by job or none, and always in Calendar | | Completion status | **Active**, **Completed** or **All**, with a lookback period on the last two | Always | The status filter defaults to **Active**, which covers Not Started, In Progress and On Hold. **Completed** and **All** ask you for a period, because completed work goes back as far as your history does. The 1 day, 7 day, 30 day and 90 day periods are open to everyone; 1 year and 5 years need an Enterprise plan. Search sits behind the magnifier in the control bar and matches work orders on the server. Filters that do not apply to the current grouping are dropped from the URL when you switch, so a machine filter does not quietly survive a move to operator grouping. ## Compact mode and card fields Two display controls narrow the board without changing it. **Compact** tightens the rows. It is available on List, Table and Kanban, and each one remembers its own setting, so a compact table does not force a compact kanban. List starts compact; the other two do not. **Card fields** decides what a kanban card carries, and only appears on Kanban. The list of fields follows the grouping, since a card in an operator column has no use for a person's name. Out of the box a card shows its part picture, job, assignee, machine, details and quantity progress. Reset puts the defaults back. ![The card-fields gear button on the Kanban control bar, ringed blue, with its popover open beneath. The popover is headed SHOW FIELDS with a Reset link, and lists thirteen fields in two columns: Hero Image, Assignee, Qty Progress, Description, Operation, Asset, Quantity, Job, Due Date, Dependencies, Details, Timeline and Budget. Hero Image, Assignee, Qty Progress, Asset, Job and Details are filled blue; the rest are grey.](/images/production/prod-sched-09.webp) *The card-fields menu on Kanban, where you choose which fields each card carries. The list of fields follows the current grouping.* ## Export the table The **CSV** button sits at the right of the control bar in Table view, and the Gantt toolbar repeats it as a download icon. No other view has one. The file mirrors the table: it carries the columns you have turned on, in the order you dragged them, and ignores the grouping entirely, writing one flat list of every task the filters loaded. It adds one column the table does not have, a **Part** column immediately after **Operation**, because the screen renders both in a single cell. Twenty-four columns are available in total, so a default export is nine of them and a fully expanded one is all 24. The file is named `scheduler-tasks-` and today's date, and it is written UTF-8 with a byte-order mark so Excel opens accented part names correctly. The column list is in [Job and scheduler fields](/docs/production/job-fields-reference/), and every other export in the product is in [Exports reference](/docs/monitoring/exports-reference/). ![A cropped detail of the right end of the scheduler control bar in Table view, showing a bordered pill button with a download icon labeled CSV, next to Import, Jobs and Invite buttons.](/images/production/prod-sched-10.webp) *The CSV button in Table view. It writes the columns the table is showing, in their current order, plus a Part column the table does not have.* ## When an edit fails | What you did | What you see | What happened | |---|---|---| | Dragged a dependency onto a task that already feeds the first one | **That link would create a circular dependency** | No link was made | | Moved, resized or reassigned one bar on the Gantt | **Update failed, reverted** | The bar went back where it was | | Moved a selection of bars | **3 of 8 updates failed, reverted** | The three that failed went back; the other five saved | | Resized an event in Calendar | **Resize reverted: Issues updating work order** | The event snapped back to its old length | | Dragged an event in Calendar | **Issues updating work order** | The event snapped back to its old day | | Changed a field in the task panel | **Issues updating due date**, **Issues updating asset**, **Issues updating priority**, **Issues updating group** or **Issues updating tasks** | The field went back to its old value | | Deleted from the Gantt | **Delete failed**, or **2 of 5 work orders could not be deleted** | Those rows are still on the board | | Hovered a disabled **Working hours** pill | **Set up work shifts in Organization Settings to enable working-hours scheduling** | The organization has no shifts yet | A generic **Something went wrong** or **An error occurred** means the request failed and nothing was saved. Try the edit again, and if it keeps failing, [contact IoTFlows](/docs/get-started/get-support/). ## See also - [Try a schedule change without saving it](/docs/production/simulate-a-schedule/) - [Find and fix schedule problems](/docs/production/schedule-issues/) - [Link required and created parts to an operation](/docs/production/bind-materials/) - [Find your next job in the Work Queue](/docs/production/work-queue/) - [Job and scheduler fields](/docs/production/job-fields-reference/) --- # Track production against shift goals Source: https://www.iotflows.com/docs/production/shift-production/ Shift Production, at /production?select=part, lists every operation that has run this shift with its calculated goal, good count, pace and hourly bars, and expands each operation into one row per machine. The Progress gauge is green at or above the machine's OEE goal and red below it, with no orange. Goals here are read-only: the calculated goal comes from the operation's ideal cycle time in the Parts List, and the percentage that colors the gauge comes from the OEE goal. Six filters write themselves into the URL, which is what makes the board sendable to a TV. # Track production against shift goals See whether this shift will hit its numbers, operation by operation and machine by machine. Shift Production is the board you leave open while a shift runs. It lists every operation that has produced since the shift started, with the parts counted so far against the goal for the shift, the pace each machine is holding, and an hourly bar chart showing where the output landed. Nothing on this page is editable. It reads the numbers other pages set, which is what makes it safe to put on a screen the whole cell can see. **Before you start** - Create the part and at least one operation, and assign the operation to a machine. See [Create parts and operations](/docs/production/parts-and-operations/). - Set an ideal cycle time on the operation. Without one, every goal on this page reads `0`. See [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/). - Have your shifts defined for the organization. See [Shifts and time zone](/docs/admin/shifts-and-timezone/). There is no role gate. Anyone who can see a machine can read its production board. ## Read the board Open **Production**, then the **Shift Production** tab, at `/production?select=part`. On a phone the tab is labeled **Shift**. Every row is one operation, with the part it produces named underneath, for example `OP100-CUTTING-BLANK` over `Aluminum can`. Six columns follow it. An *OEE goal* is the single target percentage every gauge in IoTFlows is colored against. Each machine inherits the organization's until you give it one of its own. See [Set OEE and utilization goals](/docs/monitoring/oee-goals/). | Column | What it shows | |---|---| | **Operation** | The operation name, the part beneath it, and the part picture where one is set | | **Calculated Goal** | The number of good parts this operation should finish during the shift | | **Progress** | A half gauge. The center number is good parts made so far, labeled with the operation's own unit, and the arc fills to the percentage of the goal reached. A tick on the arc marks the OEE goal | | **Production Rate** | Three figures, **Ideal**, **Goal** and **Actual**, over a bar drawing the measured cycle time with an arrow at the ideal. The swap arrow flips all three between a cycle time and a rate per minute, for example `00:00:00.50` and `120.0 ops/min` | | **Quality** | Good parts as a percentage of everything counted, with the bad count beneath it in red | | **Hourly Production** | One bar per clock hour of the shift | An operation that runs on more than one machine carries a chevron at the left of its row. Select it to expand the operation into one line per machine, carrying the same columns. That is the only place the board separates two machines running the same operation, so it is where you go when the operation total is behind and you need to know which machine is dragging it. Operations with a *quantity per cycle* other than 1, meaning one cycle that yields more than one part, draw a second gauge to the left of Progress counting cycles rather than parts. ![The Shift Production board. Six operation rows under the column headings Operation, Calculated Goal, Progress, Production Rate, Quality and Hourly Production, each expanded into the machine line beneath it with its own gauge and hourly bars. Four Progress gauges are green and two, OP30-ASSEMBLY and OP400-CLEANING-DESIGN, are red](/images/production/prod-shift-01.webp) *Live shift production. Counts per operation and per machine against the shift goal.* **The gauges are green or red, never orange.** The Progress gauge draws green while the percentage of the goal reached is at or above the machine's OEE goal, and red below it. The cycle-time bar underneath the rates is green while the measured cycle is faster than the ideal, and red the moment it reaches or passes the arrow. See [Set OEE and utilization goals](/docs/monitoring/oee-goals/#where). **You do not need this page to know whether a machine is running.** Machine state, uptime and downtime live on the Assets page and do not need a part, an operation or a cycle time. See [Monitor your fleet on the Assets page](/docs/monitoring/assets-overview/). ## Read the hourly bars Every operation row, and every machine row inside it, draws one bar per clock hour since the shift began. Good parts go up from the zero line and scrap hangs below it in red. Hover a bar for its **Good** and **Bad** counts. The bar color is the hour's own verdict. Blue means the hour met or beat its hourly goal; amber means it fell short. The hourly goal comes from the ideal cycle time and the machine's goal, see [Production metrics](/docs/monitoring/metrics-reference/#production). This is the part of the row that does not average. An operation can sit at 96% of its shift goal with a green gauge and still carry one amber hour that lost 60 parts, and that hour is the one worth asking about while the shift is still running. ![An hourly production bar chart for one operation, OP10-MACHINING on Bevel Gear 2, across ten hours of a shift. Nine bars are blue and the last, the 5 PM hour, is amber and visibly shorter, marked with a violet callout arrow](/images/production/prod-shift-02.webp) *Hourly production against the calculated goal.* ## Filter the board Six filters sit across the top of the page, with **Reset filters** at the end of them. | Filter | Values | Effect | |---|---|---| | **Parts** | Any part in the organization, multi-select | Shows only operations that produce the selected parts | | **Departments** | Any department, multi-select | Shows only operations running on machines in those departments | | **Machine type** | Any machine type, multi-select | Shows only operations running on that class of equipment | | **Tags** | Any asset tag, multi-select | Shows only operations on tagged machines | | **Sort by** | Name (A to Z), Name (Z to A), Department, Machine type | Reorders the rows. It does not sort by progress or by rate | | **Shift** | A named shift, **All Day**, or **Custom Time** with your own start and end in 30-minute increments, on yesterday or any past date | Sets the window every count, goal and bar on the page is calculated over | **Shift** defaults to the shift you are in right now, or to **All Day** when the current time falls outside every named shift. The filter is the same control the Assets page carries, see [Choose the window](/docs/monitoring/assets-overview/#window). ![The Shift Production filter bar wrapped onto two rows, with six numbered callouts, reading Part, Department, Machine type, Tag, Sort by set to Name (A to Z) and Shift set to Day Shift 2026-09-18, followed by a Reset Filters button](/images/production/prod-shift-03.webp) *The six filters on the shift view.* Every filter writes itself into the address bar, so the URL is the view. Copy it, bookmark it, or send it to a screen and it reopens filtered exactly as you left it. **Reset filters** clears all six and returns the board to the current shift. ## Put the board on a TV The board is built to be sent to a wall display, and the control that makes it readable from across a cell is the **Expand Operations** switch at the top right. 1. Filter the board down to the cell the screen belongs to, usually with **Departments** or **Tags**. 2. Set the switch. Its label names what flipping it will do: **Collapse Operations** while machine rows are showing, **Expand Operations** while they are hidden. Collapsed, each operation is one line and its per-machine rows are hidden. 3. Add `&hide_tabs=true` to the URL to drop the Scheduler, Work Queue, Parts List, Historical and Insights tab bar from the top of the page. This is read when the page loads, so it has to be in the URL before you send it. 4. Copy the address bar and send it to the screen. See [Send a view to a paired screen](/docs/monitoring/wallboards/#send). ![The Shift Production board collapsed for a wall display. Nine operations render as nine single lines, each one gauge, one rate and one hourly bar chart, with no machine rows beneath them and no tab bar across the top. The switch at the top right reads Expand Operations](/images/production/prod-shift-04.webp) *TV collapse mode, for a wallboard at the cell.* The collapse state travels in the URL alongside the filters, as `operations_expanded` and `assets_expanded`, so the screen opens the way your browser looked. **The board has no refresh timer of its own.** It loads its numbers when the page opens and reloads them whenever you change a filter or flip the switch, unlike the Assets page, which refreshes every minute. Reload the page to catch a browser tab up. ## Where the goals come from Two different goals color this page, and neither one is set here. | Goal | Set on | Applies to | |---|---|---| | **Calculated Goal**, a part count | The operation's ideal cycle time in the Parts List. See [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/) | One operation, on every machine that runs it | | **OEE goal**, a percentage | The organization, or one machine where you have overridden it. See [Set OEE and utilization goals](/docs/monitoring/oee-goals/#machine) | Every gauge on the machine, here and on the Assets page | The calculated goal is derived for you from the shift, not typed in: ``` Goal = (Shift Duration - Expected Downtime) / Cycle Time ``` Expected downtime is the historical average for that operation and machine, which is why a machine with a long changeover history is given a goal a lower one would not get. **Goals on this page are read-only, and there is no per-operation override.** If a goal is wrong, the number behind it is wrong. Change the cycle time in the Parts List to move the calculated goal, and change the OEE goal to move the threshold the gauge is colored against. Both recalculate on the next load. To reach the cycle time from here, select **Add/Edit Parts** at the top right, then edit the operation's ideal cycle time. Goals recalculate for future shifts; the shift already under way keeps the goal it started with. ## When a number looks wrong | Symptom | Cause | Fix | |---|---|---| | **Calculated Goal** reads `0` | The operation has no ideal cycle time | Set one in the Parts List. See [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/) | | "There are no parts in production for this shift." | Nothing has been counted in the selected window | Check the **Shift** filter before you check the machine. A named shift that ended hours ago shows the shift, not today | | The count does not match the hand count on the floor | The operation's detection algorithm is reading the signal wrong | See [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/) and [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/) | | **Quality** reads 100% with scrap in the bin | Scrap counts only once it is logged against the job | See [Log scrap and manage scrap reasons](/docs/production/log-scrap/) | | An operation is behind but every machine row looks fine | The operation is split across machines and no single one is far off | Read the hourly bars rather than the totals. One amber hour on each of three machines is the same lost shift | | The numbers have not moved in an hour | The page loaded before those parts were counted | Reload. The board has no timer, see [Put the board on a TV](#tv) | Use this board for the shift in front of you. To compare one shift against last week, or to export the counts, go to [Compare production over weeks and months](/docs/production/historical-production/): Shift Production itself has no export. ## See also - [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/) - [Set OEE and utilization goals](/docs/monitoring/oee-goals/) - [Compare production over weeks and months](/docs/production/historical-production/) - [Display a wallboard on a TV](/docs/monitoring/wallboards/) - [Metrics](/docs/monitoring/metrics-reference/#production) --- # Try a schedule change without saving it Source: https://www.iotflows.com/docs/production/simulate-a-schedule/ A Simulation is a sandbox on the scheduler Gantt. Every move is staged in your browser instead of being written, and a dashed teal band scores the draft against the live schedule frozen at the moment you started, on violations, double-bookings, overdue work, span and unscheduled tasks. The What-ifs drawer adds custom working hours and rule relaxations that change the projection but are never saved. Commit writes the staged work orders and cannot be undone; Discard throws the draft away without asking. # Try a schedule change without saving it A sandbox on the Gantt where you move work, change the rules, and read the before-and-after numbers before anything is written. The scheduler board writes every drag straight to the work order. That is right for one correction and wrong for a plan: pulling a rush order forward, taking a machine down for a day, or resequencing a week takes a dozen moves, and you want to see the whole result before any of it is real. A Simulation gives you that. It stages your moves, scores them against the schedule you started from, and holds them until you commit or throw them away. **Before you start** - Production Scheduler is part of the Scheduling Engine module. The tab strip renders for every organization, so seeing the **Scheduler** tab is not proof you are entitled to it. If you are not sure, [contact IoTFlows](/docs/get-started/get-support/). - You need membership of the scheduler board. That is a board-level permission rather than an organization role. See [Give people access to a scheduler board](/docs/production/scheduler-members/). - Simulations run on the Gantt. See [Plan jobs in the Production Scheduler](/docs/production/scheduler/#gantt). ## What a Simulation is A *Simulation* is a draft copy of the board that lives in your browser. The *draft* is the schedule your staged changes would produce, and the *baseline* is the live schedule frozen the moment you started, which is what the draft is scored against. To *commit* is to replay your staged changes as real writes. What a Simulation stages is tasks. A *task* is one operation of a job on one machine, and it is the record the board's own messages call a work order. Both words appear on this page because both appear on screen. **Run a Simulation when the change is big enough that you want the before-and-after numbers.** Edit the board directly for anything you would not bother measuring, and use undo if you get it wrong. **You do not need a Simulation to try the optimizer.** The **Optimize** pill already gives you a reviewable proposal on the live board, covered in [Generate a schedule proposal](/docs/production/optimize-the-schedule/). Reach for a Simulation when you want to combine several changes and score them together. ## Start a Simulation On the Gantt, click **Simulations** in the control row, to the right of the issues pill. ![A cropped detail of the right-hand end of the Gantt control row. After the Work sessions and Optimize pills and the undo, redo and download icons sits an amber issues pill reading 19 issues, and to its right, ringed in violet, an outlined pill carrying an eye icon and the word Simulations.](/images/production/prod-sim-01.webp) *The Simulations pill in the Gantt control row, to the right of the issues pill. Clicking it turns the whole board into a draft.* The board tints teal, a dashed teal outline wraps the chart, the pill changes to **Simulation on**, and the Simulation band appears above the bars. The What-ifs drawer stays closed until you ask for it. ## Read the Simulation band The band carries a **SIMULATION** badge, the line **Draft · nothing is saved yet**, the metrics, and the three controls: **What ifs**, **Discard** and **Commit**. Four metrics are always there; **Violations** makes five when there is one to report. ![A dashed teal band across the top of the Gantt, with five numbered violet callouts in the strip of board below it. On the left a filled teal pill reads SIMULATION, callout 1, beside the line Draft, nothing is saved yet. In the middle, callout 2 marks four labeled figures reading Double-booked 13, Overdue 6, Span 66.9d and Unscheduled 4, each a single number with no arrow. On the right, callouts 3, 4 and 5 mark What ifs, Discard, and a filled Commit button that is greyed out.](/images/production/prod-sim-02.webp) *The Simulation band as it looks on open, before anything is staged: a SIMULATION badge, the metrics as single numbers, and the What ifs, Discard and Commit controls. Nothing is saved until you commit.* A metric that has not moved shows one number. A metric that has moved shows `baseline → draft`, in green when the draft is better and rose when it is worse. Every metric is better low, **Span** included. ### Simulation metrics | Metric | Counts | Better when | Shown when | |---|---|---|---| | **Violations** | Work orders breaking a capacity rule, such as two jobs holding the same tool at once | Lower | The baseline or the draft has at least one, so a permanent 0 never sits there | | **Double-booked** | Work orders sharing a machine or another capacity-1 resource with an overlapping bar | Lower | Always | | **Overdue** | Scheduled, uncompleted work orders whose due date is already past | Lower | Always | | **Span** | The stretch from the earliest start to the latest due date on the board, shown as `12.4d` once it passes a day | Lower | Always | | **Unscheduled** | Work orders with no due date, which are the chips down the left of the board | Lower | Always | The baseline is scored against your real rules and the draft against the rules as the Simulation has them, so relaxing a rule moves **Violations** even when you have staged no moves at all. ## Move work in the draft Everything the Gantt does to a bar, it does in a Simulation: drag a bar to a new time, resize it, drag it into another machine's lane, link a dependency, drag an unscheduled chip onto a date, nudge a whole selection, or take a quick fix from the issues panel. The difference is where the change goes. Instead of a write, it is recorded in a staged ledger and the board redraws from that. Undo and redo work normally inside the Simulation, and both stacks start empty when it opens, so undo reaches back to the start of your draft and no further. Repeated edits to one work order collapse into a single staged change. **Commit 6** means six work orders, not six gestures. ![The Simulation band after six work orders have been restaged. Double-booked is the one metric that moved and reads 13 with an arrow to 2, both in green, with a violet arrow rising from the board below to point at it. Overdue 6, Span 66.9d and Unscheduled 4 are each still a single number. The Commit button on the right is now filled and reads Commit 6.](/images/production/prod-sim-03.webp) *The Simulation band after several bars have been moved. The band scores the draft against the frozen live baseline, green for better and rose for worse.* ## Open the What-ifs drawer A *what-if* is a change to the rules or the calendar the draft is planned against, rather than to the work itself. Click **What ifs** in the band to open the drawer on the right of the board. The controls sit at the top and an **Impact** report sits under them. ![A drawer down the right side of the Gantt headed What-ifs, with Reset and close controls, a strip of the board still showing to its left. Under a line explaining that the simulation reschedules as you change things, callout 1 marks an unchecked Custom hours checkbox, captioned Add, extend or turn shifts on or off for this simulation, with a 24/7 button at the right of the row. Callout 2 marks a row under the heading Machine and material rules, carrying the tool name FX-220 Vise Jaw Set, the label Shared resource, a checked box and a cap field reading 10. Callout 3 marks the lower half of the drawer, headed Impact, which reads Adjust a shift or rule above to see the projected effect on each work order.](/images/production/prod-sim-04.webp) *The What-ifs drawer, open beside the board. These overrides apply to the draft only and never change your real shifts or rules.* ### What-ifs overrides | Override | Affects | Applies to | Persists after commit | |---|---|---|---| | **Custom hours** | The working calendar the draft is planned against | This draft, in this browser | No | | A shift inside **Custom hours**, on or off | Whether that shift's time counts as available | This draft, in this browser | No | | A machine or material rule, on or off | Whether the rule raises violations and constrains the optimizer | This draft, in this browser | No | | **cap** on a shared resource | How many units of that resource the draft may use at once | This draft, in this browser | No | Nothing in the drawer is ever saved. **Commit writes the staged work orders and only those**, so a draft built on an imagined Saturday shift commits the dates you staged, not the shift. Once you change any of these, the **Impact** report below fills in. It runs the optimizer against your simulated rules and calendar and reports what re-planning would buy you: a headline finish date for the batch, how many days sooner or later that is, and a row per work order with its current due date, its projected one and the delta. The report is tagged **Advisory** and has no Apply button, because it is priced in hours and rules that are not real. To act on it, move the bars yourself and commit. ## Try different working hours Check **Custom hours**. The drawer seeds an editable copy of every real shift your organization has, all switched on. From there you can uncheck a shift to take it out of the draft, rename it, retime its days, set its start and end, extend its end by **+2h** or **+4h**, or add a shift that does not exist. **24/7** replaces the lot with one around-the-clock block, and clicking it again puts your real shifts back. Only the checked shifts build the draft's calendar. A running total tells you what you bought: `+16h working time / week`, or **No added working time. These hours are already covered by your shifts.** when the change lands on time you already had. ![A cropped detail of the left end of the Gantt toolbar inside a Simulation, the Simulation's dashed teal outline running down the left edge. The Working hours pill, carrying a clock icon, is filled and dimmed at the same time and ringed in violet, unlike the fully saturated Work sessions pill beside it. The Sequence and Optimize pills are inactive.](/images/production/prod-sim-05.webp) *With Custom hours on, the toolbar's Working hours pill is locked and controlled from the What-ifs drawer.* With **Custom hours** on, the toolbar's **Working hours** pill locks. It stays filled but dims, and hovering it gives the reason: **Controlled by Custom hours in the What-ifs panel**. The override already forces the draft to schedule inside working time, so the toggle has nothing left to say. **Use custom hours to answer "what would a Saturday shift buy me", then take that answer to whoever schedules shifts.** It changes the projection, never the plan. Real shifts are set once for the whole organization in [Shifts and timezone](/docs/admin/shifts-and-timezone/). ## Relax a rule Under **Custom hours**, the drawer lists the machine and material rules the board actually has, checked on. Uncheck one and the draft ignores it. Where a rule carries a number, such as how many of a reusable tool you own, edit the **cap** instead of turning it off, which is how you ask what three more would be worth. Rule overrides are warn-only. An ignored rule stops raising violations and stops constraining the optimizer, but neither the rule nor the override blocks an edit: the board lets you make the move and tells you what it costs. Today those rows come from reusable tooling reserved on work orders. Serialized pieces never appear in the list, because one physical bar or roll is a capacity of exactly 1 and there is nothing to dial. They still raise violations in the draft like any other conflict. ## Run the optimizer inside a Simulation The **Optimize** pill keeps working inside a Simulation, and it plans against your simulated rules and calendar rather than the real ones. The proposal renders as dashed ghost bars with its own banner. **Apply** behaves differently here. Instead of writing, it stages every move it proposes, so the count on **Commit** jumps by the number of bars it moved and the metrics rescore against the same frozen baseline. You can then keep editing by hand before deciding. Optimize is unavailable in Sequence view, and regrouping the board clears an open proposal. ## Commit the draft **Commit** writes the staged work orders to the real schedule. The button carries the count, is disabled until something is staged, and takes you back to the live board when it finishes. ![A cropped detail of the right end of the Simulation band, its dashed teal edge closing just past the last control. A What ifs button carrying a slider icon, a Discard button carrying a cross, and a filled teal Commit 6 button carrying a check mark, ringed in violet.](/images/production/prod-sim-07.webp) *Commit writes the staged changes to the real schedule. The number on the button is work orders, not edits.* > **Warning:** > **Can you undo a commit?** No. Entering and leaving a Simulation both clear the undo history, and the commit is not added to it, so there is no single action that takes the schedule back. Read the metrics before you press it. Each staged work order is written on its own. If some of those writes fail you get **3 of 6 updates failed, reverted**: the three that failed go back to the values they had at the baseline, the other three are saved, and the Simulation closes either way. Run it again for the ones that did not take. ## Discard the draft **Discard** throws the draft away and returns the board to the live schedule. It does not ask. The staged changes, the rule overrides and the custom hours all go at once, and the undo history goes with them, so there is no way back to a discarded draft. Clicking **Simulation on** leaves the same way when nothing is staged. Once something is staged, that pill stops working and tells you so: **Use Commit or Discard in the Simulation band to leave.** ## What you cannot do while a Simulation is open A few actions write real data and have no staged form, so the board refuses them and says why. | Action | What happens instead | |---|---| | Delete a work order, from the bottom bar, the right-click menu or the Delete key | **Exit scenario mode to delete work orders**, and nothing is deleted. This message names the feature by its internal name; everything else calls it a Simulation | | Click a bar to open the work order's details panel | **Commit or discard the Simulation to open a work order.** | | Click a work-session block, or open work sessions from the right-click menu | **Commit or discard the Simulation to edit work sessions.** | | Click **Simulation on** with changes staged | **Use Commit or Discard in the Simulation band to leave.** | ![A cropped detail of the top of the window after a bar was clicked inside a Simulation. A white toast carrying an information icon floats over the app header, ringed in violet, reading Commit or discard the Simulation to open a work order. Below it the control row shows Optimize 1 selected, so the bar took the selection but no details panel opened, and a filled teal Simulation on pill sits beside the issues pill, with the dashed teal Simulation band under them.](/images/production/prod-sim-06.webp) *Opening a work order inside a Simulation raises a toast instead. Deleting a work order, opening the details panel and editing work sessions all wait until you commit or discard.* The draft itself is stored in your browser, separately from your view preferences, under the key `schedulerGanttScenario`. Two consequences worth knowing. A page reload restores an open Simulation exactly as you left it, and the key is removed the moment you commit or discard. The other consequence is a trap. Switching to List, Table, Kanban or Calendar leaves the Simulation on, and those views show the live schedule rather than your draft, because staged changes exist only on the Gantt. An edit made there writes straight through. ## When someone else changes the live schedule The board keeps receiving updates while your Simulation is open, but the draft holds the values it froze on the work orders it is drawing. A colleague dragging a bar you are planning around does not shift the experiment under you. Regrouping and filtering flow through as normal, since those change which rows you see rather than what they say. When you leave, IoTFlows compares the frozen baseline with what is now live and tells you how far it drifted: **4 live changes happened while your Simulation was open. Showing the current schedule now.** The last write wins. Your commit is a write, so it overwrites whatever a colleague set on the same work order while you were planning, and anything they change after your commit overwrites yours. On a busy board, that is an argument for short Simulations. ## See also - [Generate a schedule proposal](/docs/production/optimize-the-schedule/) - [Find and fix problems in the schedule](/docs/production/schedule-issues/) - [Plan jobs in the Production Scheduler](/docs/production/scheduler/) - [Set your shifts and timezone](/docs/admin/shifts-and-timezone/) --- # Configure tracking for stamping and punch presses Source: https://www.iotflows.com/docs/production/stamping-presses/ Set up stroke counting on a press that fires 10 to 120 times a minute. Mount the SenseAi on the frame near the ram, measure the stroke rate, create the part with one operation per die, set the operation's algorithm to Discrete w/o Merge, then assign every die's operation at once from the Auto-Detect modal's Discrete tab, which is multi-select. Because nothing is merged, every gap between strokes reaches the downtime record until you set the machine's Downtime Threshold with Treat short downtimes as uptime switched on. Operation Cycle Time takes whole seconds, so a press faster than 60 strokes per minute cannot carry an exact cycle time and its shift goal is approximate. # Configure tracking for stamping and punch presses Count strokes on a machine that fires tens of times a minute. A stamping or punch press makes one part per stroke, and each stroke is a sharp impact the sensor can see on its own. [Discrete w/o Merge](/docs/production/choose-an-algorithm/#no-merge) is the algorithm for that case: it counts every burst it detects and merges nothing, so two strokes a second apart stay two parts. Allow 30 to 45 minutes for the first press. **Before you start** - A SenseAi or SenseAi Embedded tied to the press. Contact IoTFlows to tie your sensors to an asset, see [Get support](/docs/get-started/get-support/). - Sign in as an Organization Owner or Organization Administrator, see [Roles reference](/docs/admin/roles-reference/). ## Why Discrete w/o Merge fits a press Four things about a press point at the same algorithm. - **Every stroke is a separate event.** The ram hits, and that impact is the part. - **The strokes come fast.** A press runs 10 to 120 strokes per minute, so any rule that merges nearby events merges real parts. - **One stroke is one part.** Nothing has to be reassembled from several bursts, which is the job merging exists to do. - **The gaps between strokes are brief.** They belong to the rhythm rather than to the downtime record, and they are handled on the machine instead of in the algorithm. **You do not need a second sensor to count strokes.** SenseAi derives part counts and cycle times from the same vibration trace that produces the running and stopped state. **Choose [Discrete Analysis](/docs/production/choose-an-algorithm/#discrete) instead when the press rings more than once per stroke.** Impact and rebound on a heavy mechanical press can read as two events, and Discrete Analysis merges the second back into the cycle. A count that runs at exactly double the real output is that problem and nothing else. ## Mount the sensor on the press ![A C-frame press seen from the operator side, with a SenseAi magnet-mounted on the flat side of the frame above the electrical cabinet, level with the ram and the die area](/images/production/prod-press-01.webp) *SenseAi on a press, mounted on the frame beside the ram rather than on a guard.* 1. Mount on the frame as close as you can get to the ram or the drive, where the stroke is strongest. 2. Pick flat ferrous metal that is mechanically part of the press. A guard or a sheet-metal panel holds the magnet and passes on its own ringing rather than the driveline's, see [Choose a mounting location](/docs/hardware/install-senseai/#mounting). 3. Connect power and put the device on Wi-Fi, see [Connect a device to Wi-Fi](/docs/hardware/connect-to-wifi/). 4. Run 10 or more strokes in production while you calibrate, so the thresholds are set against real strokes rather than a dry cycle, see [Calibrate SenseAi and SenseAi Embedded](/docs/hardware/calibrate-senseai/). Verify the mount rather than judging it by eye. Run the press, then stop it, and confirm the two read differently. ## Count at the part exit instead A [BeamTracker](/docs/hardware/beamtracker/) at the exit chute counts parts leaving the press rather than strokes happening inside it. It runs the [Counter](/docs/production/choose-an-algorithm/#counter) algorithm, which takes each break of its beam as one cycle. **Choose a BeamTracker at the exit when:** - The press rings more than once per stroke and no threshold separates the rings cleanly. - You want the count to be parts that cleared the die, not strokes that may have misfed. - The press is one station of a line and the count you report on belongs to the line. A BeamTracker is a calibration job rather than an algorithm choice. Set what the beam treats as a part in [Set what counts as a part](/docs/hardware/calibrate-beamtracker/#beam-values), and set how long the line stays running after the last part in [Set the downtime filter](/docs/hardware/calibrate-beamtracker/#downtime-filter). That filter lives on the device and is measured in seconds. **You do not need a BeamTracker if the SenseAi count already validates.** A second device is a second thing to calibrate. If you go this way, the full Counter setup is on [Configure tracking for bottling and packaging lines](/docs/production/packaging-lines/), which covers the same algorithm on any line of units passing a point. ## Measure the stroke rate 1. Run the press normally for 5 minutes and let it settle. 2. Count strokes for one full minute, off the press counter if it has one. For example, 45 strokes in a minute is 45 SPM. 3. Divide 60 by that number to get the cycle time. At 45 SPM, 60 ÷ 45 is 1.33 seconds per stroke. 4. Note the pauses between strokes as well. On a press they run from a fraction of a second to a second or two, and they are what the machine's short-stop setting is for. **Operation Cycle Time takes whole seconds.** The h, m and s boxes are number fields read as integers, so 1.33 is stored as 1 and there is no sub-second entry. Discrete w/o Merge does not read the [cycle time](/docs/monitoring/metrics-reference/#cycle-time) to count, so the count is unaffected. The shift goal and the parts gauge do read it, so round to the nearest whole second and treat the goal as approximate unless the stroke rate divides into 60 evenly, as 60, 30, 20, 15 and 12 SPM do. ## Create the part and its operation 1. Open **Parts List** at `/production?select=parts_list`. 2. Click **+ Add Part**. 3. Enter a **Part Name**, for example `Steel Bracket`. **Part Description** is optional. 4. Under **Assign Operations**, name the operation after the die, for example `STAMP-BRACKET-100T`, and describe it, for example `100-ton press, progressive die`. 5. Enter **Operation Cycle Time** in the h, m and s boxes. For a 1.33-second stroke, that is 1 in the s box. 6. Enter a standard deviation in the boxes beside it. Leaving either at zero blocks the part with **Cycle time and standard deviation must be greater than zero**. 7. Add the machines that run this operation, then click **Add Part**. 8. Back on the Parts List, expand the part, click the operation's **Algorithm** cell and choose **Discrete w/o Merge**. It saves as you pick it. 9. Set **QTY/OP** to the parts one stroke makes. On a press this is almost always 1. *Quantity per cycle* is the parts one cycle makes. A progressive die carries a part through several stations per stroke and still finishes one part per stroke, so it is 1, the same as a single-hit die. Raise it only for a multi-out die that drops more than one part per stroke, see [Create parts and operations](/docs/production/parts-and-operations/). Create one operation per die, not one per part number. The table shows no **Downtime Filter** column here: that column belongs to Continuous Analysis alone, so a Discrete w/o Merge operation has nothing to leave blank. ## Handle the gaps between strokes Because nothing is merged, every gap between strokes can reach the downtime record, and a shift turns into hundreds of one-minute rows nobody can classify. The fix sits on the machine, not on the operation. Two layers do two different jobs: | Layer | Where you set it | What it does | |---|---|---| | **Algorithm** | The operation, on the Parts List | **Discrete w/o Merge** counts every detected burst as one stroke | | **Short-stop handling** | The machine, on the sensor's **Calibration** tab | Converts any stop under the cutoff into runtime before it reaches the report | Set the second layer from **Downtime Threshold** with **Treat short downtimes as uptime** switched on, see [Handle short stops](/docs/hardware/calibrate-senseai/#short-stops). The field is in minutes. With the toggle off, the same field is labeled **Auto-Classify Downtimes** and short stops stay in the record with a reason code instead of disappearing. | Press type | Strokes per minute | Downtime Threshold | Why | |---|---|---|---| | High-speed stamping | 60 to 120 | 10 to 15 minutes | Removes brief pauses and leaves only major stops | | Medium-speed punching | 30 to 60 | 5 to 10 minutes | Balances detail against noise | | Low-speed forming | 10 to 30 | 3 to 5 minutes | Slower work needs more sensitivity | | Manual feed presses | Varies | 2 to 5 minutes | Keeps operator pauses visible | **Read the threshold as a decision about what you are willing to stop seeing.** A 10-minute threshold converts a 9-minute material jam into runtime, so it is also a statement that 9-minute jams are not worth reporting. Start at the low end of the band, run a shift, then raise it only if the [Downtimes report](/docs/monitoring/downtimes/#pareto) is still full of pauses nobody can act on. ## Assign the operation to the machine 1. Open **Assets** at `/assets` and click the press. 2. Click **Auto-Detect** to open **Select Auto-Detect Operations**. 3. Stay on the **Discrete** tab, which holds both discrete algorithms. A SenseAi machine shows the **Discrete** and **Continuous** tabs only, because Counter is BeamTracker's algorithm. 4. Check every die's operation that this press runs. The list is checkboxes, not a single choice. 5. Click **Auto-Detect**. The dashboard confirms with **Discrete Auto-classification Set**. Because the tab is multi-select, **assign every die the press runs at once and leave them assigned.** A die change then needs nothing on the dashboard, and each die's output is reported separately, see [Compare production over weeks and months](/docs/production/historical-production/). Selecting discrete operations clears any continuous operation the machine was set to, and the modal says so above the list. The full flow is on [Detect operations automatically](/docs/production/auto-detect-operations/). ## Track die changes and material loading A die change is the largest single stop on most presses, and it is invisible until stops carry reasons. A typical one runs 15 to 60 minutes, so it clears any threshold in the table above. 1. Create a **Die Change** category, see [Create a category](/docs/monitoring/downtime-categories/#create). Add **Setup / Adjustment** for the fine-tuning after the die is in. 2. Add **Material Loading** as well. Coil loading takes 5 to 10 minutes, so keep **Downtime Threshold** at or below 5 minutes if you want those stops in the record at all. 3. Have operators classify the stop when it happens, see [Classify a downtime event](/docs/monitoring/classify-downtime/). 4. If changeovers always look the same, write a rule so they classify themselves, see [Classify downtime automatically](/docs/monitoring/auto-downtime-rules/). 5. After two to four weeks, read the totals off the Pareto chart on the [Downtimes report](/docs/monitoring/downtimes/#pareto). ## Validate the count 1. Let the press run normally for one to two hours. 2. Open **Shift Production** at `/production?select=part` and read the count for the operation. 3. Work out what it should be. A press at 60 SPM running for 60 minutes made 3,600 strokes. 4. Compare the two. Within 2 to 3% is right on a press, which counts more precisely than a machine whose cycles have to be inferred from a varying trace. 5. Open **Downtimes** at `/assets?select=downtimes` and confirm real stops are recorded while the gaps between strokes are not filling the list. Accuracy bands and what to do at each one are on [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/#validate). ## What to expect from a press *Uptime* is availability: the share of the window the machine spent running, see [Uptime](/docs/monitoring/metrics-reference/#uptime). How the material reaches the die sets the ceiling, so a hand-fed press and a coil-fed one are not comparable. | How the press runs | Uptime to expect | |---|---| | Manual feed, operator places every blank | 50 to 65% | | Auto feed from coil | 65 to 80% | | Lights-out automation | 80 to 90% | Set the goal on [Set OEE and utilization goals](/docs/monitoring/oee-goals/). **Start from your own baseline plus 5 to 10%, not from the table.** A goal the press has never met teaches operators to ignore the number. Watch the stroke rate over time as well as the total. A rate that drifts down points at tooling wear, and downtime that climbs while the rate holds points at material, see [Compare production over weeks and months](/docs/production/historical-production/). ## Troubleshoot a press | Symptom | Cause | Fix | |---|---|---| | Count is double or triple the real output | The press rings on impact and again on rebound, and nothing merges the second ring | Switch the operation to **Discrete Analysis**, which merges it, see [Switch to a different algorithm](/docs/production/choose-an-algorithm/#switch) | | Count is slightly low | Gentle strokes sit below the running threshold | Lower the **Running Threshold**, then move the sensor closer to the ram and check for metal-to-metal contact, see [Set the running and stopping thresholds](/docs/hardware/calibrate-senseai/#thresholds) | | The downtime list fills with one to five minute stops | **Downtime Threshold** is below the press's own rhythm | Raise it, and confirm **Treat short downtimes as uptime** is on, see [Handle short stops](/docs/hardware/calibrate-senseai/#short-stops) | | Real stops are missing from the record | **Downtime Threshold** is above the stops you care about | Lower it. At 5 minutes, coil loading reappears | | The shift goal does not match the strokes the press makes | The cycle time was rounded to a whole second | Expected on any press that does not divide into 60 evenly. Compare against a stroke count rather than the goal, see [Measure the stroke rate](#stroke-rate) | | Uptime reads low on a shift the press ran through | The running threshold sits above the trace between strokes, so the gaps read as stopped | Lower the **Stopping Threshold** and raise momentum, see [Set the running and stopping thresholds](/docs/hardware/calibrate-senseai/#thresholds) | Counts that stay wrong after the algorithm and the thresholds are both right are on [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/). ## See it in a plant - [Stamping press monitoring](https://www.iotflows.com/solutions/stamping-press-monitoring) — Every stroke counted on every press, the gaps between strokes filtered, and die maintenance on the hit count. ## See also - [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/) - [BeamTracker](/docs/hardware/beamtracker/) - [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/) - [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/) - [Calibrate SenseAi and SenseAi Embedded](/docs/hardware/calibrate-senseai/) --- # Troubleshoot inaccurate part counts Source: https://www.iotflows.com/docs/production/troubleshoot-part-counts/ Symptom, cause and fix for a part count that does not match the floor. Check QTY/OP in the Parts List first, because an exact 2x or 0.5x error is a multiplier rather than a detector: one cycle producing two parts, or two cycles producing one. A count that drifts over a shift is the ideal cycle time on Continuous Analysis, which divides running time by it. Also covers a count of zero, BeamTracker counting things that are not parts, counts that stop when the sensor goes offline, and why the platform's gross count and an ERP's good-parts figure are not the same number. # Troubleshoot inaccurate part counts Symptom, cause and fix for a count that does not match the floor. A part count is built from three things in a fixed order: the sensor's signal, the detection algorithm that decides where one cycle ends, and the quantity per cycle that turns cycles into parts. A wrong count is a fault in one of them, and the shape of the error tells you which. Every metric named on this page is defined in [How each metric is calculated](/docs/monitoring/metrics-reference/). ## Start here: three checks Diagram: A decision tree headed My part count does not match the floor, branching into three symptoms, each with the field to check first and the cause to check after it. Branch 1, the count reads too high, more parts than the floor made: check QTY/OP first, because exactly two or three times the real number means the field multiplies every count by what it holds; then check the algorithm, where one part ringing twice is counted twice on Discrete w/o Merge. Branch 2, the count reads too low, fewer parts than the floor made: check QTY/OP first, because exactly half or a quarter means a four-cavity mold is left at 1 and reports a quarter of its output; then check the detector, where two cycles merge into one or parts cross outside the beam. Branch 3, the count drifts over a shift, right at first and wrong by the end: check the ideal cycle time first, because there is no clean ratio and Continuous Analysis divides running time by that figure, so an error compounds; then check the downtime filter, where a value set too low turns in-cycle pauses into stops and drops the cycles inside them. A note across the bottom reads: check QTY/OP before the algorithm. An exact 2x or 0.5x error is almost never the detector; it is one cycle producing two parts, or two cycles producing one. *Count too high, too low, or drifting: three branches, starting with quantity per cycle.* **Check quantity per cycle before you change the algorithm.** An exact 2× or 0.5× error is almost never the detector. It is one cycle producing two parts, or two cycles producing one, and no algorithm change corrects a multiplier. Work these three before you read a symptom below. 1. **Compare like with like.** Read the count on **Shift Production** at `/production?select=part` for the same operation, machine and shift the floor counted. Most reports of a wrong number are two people reading two different windows. 2. **Read QTY/OP** on the operation's row in the **Parts List** at `/production?select=parts_list`, then divide the platform's count by the floor's. Exactly 2, 4, 0.5 or 0.25 is this field. See [Set quantity per cycle](/docs/production/cycle-times-and-filters/#qty). 3. **Read the machine's status bar** across that window. Gray is time the sensor said nothing, and nothing was counted in it. Red is time it reported the machine stopped. See [The header](/docs/monitoring/asset-detail/#header). Then jump to your symptom. | Symptom | Likely cause | Check | Fix | Page | |---|---|---|---|---| | Count is a clean multiple of the truth | QTY/OP higher than the cycle yields | **QTY/OP** on the operation row | Set it to the parts one cycle makes | [Count is roughly double](#double) | | Count is a clean fraction of the truth | QTY/OP left at `1` on a multi-part cycle | **QTY/OP** on the operation row | Set it to the parts one cycle makes | [Count is roughly half](#half) | | Right early in the shift, wrong by the end | Ideal cycle time off, on Continuous Analysis | The measured cycle against the ideal | Re-time over 10 to 20 cycles | [Count drifts](#drift) | | No count at all | No operation assigned to the machine | The operation block on the machine's row | Assign one | [Count is zero](#zero) | | BeamTracker counts more than passed | Something that is not a part crossing the zone | **Depth of View** and **Gap from Background** | Pull the zone off the background | [BeamTracker extras](#beamtracker) | | Counting stops partway through a shift | The sensor went offline | Gray on the status bar, then the device | Get it online, then backfill | [Counts stop mid-shift](#stops) | | IoTFlows and the ERP disagree | The two count different things | Whether the ERP figure is good parts only | Compare gross against gross | [ERP mismatch](#erp) | | A change will not save | The request failed, nothing was written | Reopen the cell and read the value back | Retype it once | [Still stuck](#stuck) | **You do not need to change anything on a count within a few percent.** Accuracy of 95 to 105% against a hand count is a working configuration, and chasing the last two points replaces a right number with a wrong one. The bands are on [Validate your choice](/docs/production/choose-an-algorithm/#validate). ## Count is roughly double Divide the platform's count by the real count, and read the answer rather than the difference. 1. **Exactly 2.00, 3.00 or 4.00.** This is **QTY/OP**, which multiplies every count by what it holds. An operation whose cycle makes one part reports double at `2`. See [Set quantity per cycle](/docs/production/cycle-times-and-filters/#qty). 2. **Near 2× but not exact, on Discrete w/o Merge.** One part is ringing more than once, and that algorithm merges nothing, so each ring is a cycle. Move to Discrete Analysis, which merges the second ring back in. See [Discrete Analysis](/docs/production/choose-an-algorithm/#discrete). 3. **High by a varying amount, on Continuous Analysis.** The ideal cycle time is the divisor there, so a cycle entered shorter than the real one manufactures parts. A molder timed at `11.0` seconds that really runs 22 reports twice its output. See [Set the ideal cycle time](/docs/production/cycle-times-and-filters/#ideal). 4. **High, with the machine reading as running while it sits idle.** The stopping threshold is below the idle band, so standby vibration is counted as production. Raise it. See [Set the running and stopping thresholds](/docs/hardware/calibrate-senseai/#thresholds). An operation that overcounts on one machine and is correct on the others running it is a calibration problem on that machine, not an operation problem. ## Count is roughly half The same division, in the other direction. 1. **Exactly 0.5, 0.33 or 0.25.** **QTY/OP** is left at `1` on a cycle that yields more than one part. A four-cavity mold at `1` reports a quarter of its output, and no algorithm change recovers the rest. See [Set quantity per cycle](/docs/production/cycle-times-and-filters/#qty). 2. **Low by a varying amount, on Discrete Analysis.** Two fast parts are landing inside one burst and merging into a single cycle. Move to Discrete w/o Merge, then set the machine's short-stop cutoff, because nothing absorbs the gaps between strokes there. See [Discrete w/o Merge](/docs/production/choose-an-algorithm/#no-merge) and [Handle short stops](/docs/hardware/calibrate-senseai/#short-stops). 3. **Low on Continuous Analysis.** The entered cycle time is longer than the real one, so each real cycle is credited as a fraction of one. Re-time it. 4. **Low, with short green runs missing from the status bar.** The **Uptime Filter** drops any run shorter than its value, so a machine whose cycle is shorter than the filter loses those cycles. Lower it. See [Filter out short uptimes](/docs/hardware/calibrate-senseai/#uptime-filter). 5. **Low on a BeamTracker.** Parts are crossing outside the detection zone or under the thickness floor. **Min Object Thickness** is a floor, not a ceiling: set it to the thinnest part you must count, because a floor above that drops small parts silently. A transparent or highly reflective part can pass without registering at all. See [Set what counts as a part](/docs/hardware/calibrate-beamtracker/#beam-values). ## Count drifts over a shift Drift has its own signature: right in the first hour, wrong by the end, and the error grows with running time rather than holding a clean ratio. That points at **Continuous Analysis**, the only algorithm that reads the ideal cycle time to produce a count. It divides running time by that figure, so every minute the machine runs compounds the error. A press entered at 21 seconds against a real 22-second cycle runs about 5% high, which is invisible in ten minutes and half an hour of phantom production across a week. 1. Open the machine's row on the **Assets** page and read the **Cycle time** beside the operation. That figure is measured from detection events, not from anything you typed. See [Review the detected cycle time](/docs/production/auto-detect-operations/#cycle-time). 2. Compare it against the ideal on the operation. A gap of more than a few percent is your drift. 3. Re-time the cycle over 10 to 20 consecutive cycles on a good day, and enter that. See [Set the ideal cycle time](/docs/production/cycle-times-and-filters/#ideal). 4. Read the **Downtime Filter** on the same row. Set too low, brief in-cycle pauses are recorded as downtime, running time shrinks, and the cycles inside those pauses are never counted. Set too high, real stops become running time and the count rises. See [Set the continuous downtime filter](/docs/production/cycle-times-and-filters/#filter). Drift that survives all four is usually the machine. Tool wear, a worn mold and a heater struggling to hold temperature all lengthen the real cycle, and the platform is reporting that correctly. Watch the measured cycle time for a week before moving the ideal to meet it, see [Cycle time](/docs/monitoring/metrics-reference/#cycle-time). > **Info:** > **Is it drift or a step change?** Drift widens with running time. A count that was right until Tuesday and has been wrong by the same margin since is a change somebody made: an algorithm switch, a new QTY/OP, or a recalibration. Check the operation's settings before you re-time anything. ## Count is zero Nothing counted at all is a different problem from a count that is wrong. Work these in order, because each is cheaper to check than the next. 1. **The window.** Shift Production reads the shift and date you selected, not the current moment, and says **There are no parts in production for this shift.** when that window holds nothing. 2. **The operation assignment.** Counts are recorded against an operation assigned to that machine. Open **Assets** at `/assets` in list view: a machine with nothing assigned carries a **Set operation** button where the part and count would be. See [Start from the Assets page](/docs/production/auto-detect-operations/#from-card). 3. **The algorithm.** An operation with none shows **Select Algorithm** in the Parts List instead of an algorithm pill, and detects nothing until one is picked. See [Set the algorithm on an operation](/docs/production/choose-an-algorithm/#set). 4. **The device.** A status bar gray for the whole window means the sensor reported nothing, so there was no signal to count. See [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). 5. **The machine's state.** A status bar red for the whole window means the sensor was reporting, and reporting stopped. If the machine was running, the running threshold sits above the vibration it produces. See [Set the running and stopping thresholds](/docs/hardware/calibrate-senseai/#thresholds). ## BeamTracker counts extra parts BeamTracker counts units passing a point, so an extra count is something other than a part crossing the detection zone, or one part crossing it twice. | Cause | How to tell | Fix | |---|---|---| | The zone reaches past the background | Counts arrive while the line is idle | Reduce **Depth of View** until the background sits outside the zone | | Nothing separates the zone from the background | Counts come in bursts, with dust or vibration on the line | Raise **Gap from Background** to leave spare room | | A part registers twice | The count runs near double at high line speed | Choose a slower **Reading Speed**, so readings are averaged more heavily | | The bracket vibrates | Extra counts rise and fall with the machine running | Remount the device so the beam holds still across the part flow | | The thickness floor is too low | A shallow feature on the part counts as a second part | Raise **Min Object Thickness** toward the thinnest part you must count | All five fields are on the device's **Calibration** tab, and the fastest way to set them is to watch a real part cross the thresholds in the live view. See [Run a live beam calibration](/docs/hardware/calibrate-beamtracker/#live) and [BeamTracker calibration fields](/docs/hardware/calibration-settings/#beamtracker-fields). If saving reports **Detection distance plus thickness must be between 6 and 800 cm**, those two values together have left the range the device holds; reduce whichever you set last. **Fix the counts before you touch the downtime filter.** The beam values decide what is counted, while the filter only decides how long a gap between parts may run before the line reads as stopped. Counts right but uptime wrong is the filter's problem. See [Set the downtime filter](/docs/hardware/calibrate-beamtracker/#downtime-filter). ## Counts stop mid-shift A count that runs correctly and then stops is usually the link to the sensor rather than the sensor's judgment. 1. Read the machine's status bar across the shift. A gray stretch beginning where the counts stopped is a device that went silent, and gray is not stopped time: nothing was recorded for it in either direction. See [Not sure whether the machine or the link is down?](/docs/hardware/troubleshoot-offline-device/#stopped-or-offline). 2. Get the device back online. Power, Wi-Fi range and a router moved since installation cover most cases. See [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). 3. Expect nothing to arrive late. Parts made during the gap are not counted when the device reconnects, so the shift total stays short unless somebody enters them. 4. If you know the true number, backfill it. On the machine's **Operation(s) Production** card, click **Modify Counts**, set the session time to the gap, and enter the parts made. See [Production counts and backfilling](/docs/monitoring/asset-detail/#backfill). Two other causes flatten the same line. The operation was switched mid-shift, so later parts are counted against the new operation rather than the one you are reading. Or the page has not been reloaded, because Shift Production has no refresh timer, see [Put the board on a TV](/docs/production/shift-production/#tv). **Backfill only when you know the true number and why the sensor missed it.** A backfilled count changes uptime, performance and FPY for that window permanently, and nothing on any report marks it as manual. ## Counts do not match the ERP Start by establishing that the two systems are counting the same thing. They usually are not. | Difference | Why | |---|---| | IoTFlows counts cycles, not good parts | The count is detected cycles multiplied by QTY/OP, so it is gross output, including anything the floor later rejected | | Logged scrap is not deducted | Scrap logged against a job is recorded beside the good count, and nothing subtracts it. See [Where scrap appears](/docs/production/log-scrap/#where) | | The ERP records a declaration, IoTFlows records an event | A part counted at 11:58 and declared at end of shift lands in two different hours, sometimes two different days | | Setup and test pieces are counted | The sensor cannot tell a qualification piece from a production piece. The ERP usually never sees it | | The windows are not the same | The ERP's day is a plant calendar; the platform's is the organization timezone and shift schedule. See [Shift boundaries look wrong](/docs/monitoring/troubleshoot-monitoring/#shift-boundaries) | Compare gross against gross, for one shift, on one machine, on one operation. If the platform's count matches the ERP's declared quantity plus its scrap and its setup pieces, both systems are right and there is nothing to fix. If a gap survives that, work it as a count problem: divide one figure by the other and follow the branch it lands in. **Do not reconcile to the part.** A machine-derived count and a hand declaration will never agree exactly, and a configuration tuned until they do is tuned to somebody's paperwork rather than to the machine. ## Still stuck **Something went wrong** and **An error occurred** are the platform's generic failures. Either means the request did not complete and nothing was saved, so the field still holds its old value however the form looks. Retype the value once, then reopen the row and read it back before assuming the change took. Two symptoms belong elsewhere. Uptime, downtime or OEE that looks wrong while the counts are fine is on [Troubleshoot wrong utilization or OEE](/docs/monitoring/troubleshoot-monitoring/). A device that is silent rather than miscounting is on [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/). Otherwise, [contact support](/docs/get-started/get-support/) with the machine, the operation, the exact window, the count you expected and the count you saw. Send the ratio between the two as well: it is the one fact that decides which section above applies. ## See also - [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/) - [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/) - [Calibrate BeamTracker](/docs/hardware/calibrate-beamtracker/) - [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/) - [How each metric is calculated](/docs/monitoring/metrics-reference/) --- # Find your next job in the Work Queue Source: https://www.iotflows.com/docs/production/work-queue/ The Work Queue is the operator's list of scheduled production tasks. My Work holds what is assigned to you or to one of your teams; Available Work holds everything else the queue loaded. It opens on My Work on every platform, which is why an operator with no assignments sees an empty page. Filters narrow it by machine, tag, operation and completion status, and list mode adds the due date and a priority dot that the cards do not show. Starting a job does not assign it to you: only the mobile job page and the Scheduler change who owns a task. # Find your next job in the Work Queue What is assigned to you, what is available to pick up, and how to narrow the queue to the machine you are standing at. The *work queue* is every scheduled production task in your organization on one page, with the job runner one click away. It is the **Work Queue** tab of the Production page, at `/production?select=work_queue`. Each row is a *task*, one operation on one machine, which is what a job fans out into. See [Tracking versus scheduling](/docs/production/overview/#split). One request loads the queue and the page sorts it into two lists: work assigned to you, and *available work*, meaning everything else. You see one list at a time. **Before you start** - Production Scheduler is part of the Scheduling Engine module. The tab strip renders for every organization, so seeing the **Work Queue** tab is not proof you are entitled to it. See [Module entitlement](/docs/production/overview/#entitlement). - Board membership, if you want anything under My Work. A planner can only assign work to someone on the production board. See [Give people access to a scheduler board](/docs/production/scheduler-members/). - Nothing on this page is role-gated. Anyone who can open the Production page can filter the queue, create a work order and delete one. ## My work versus available work The toggle at the top center switches the page between two lists. **My Work** holds every task assigned to you by name and every task assigned to a team you belong to. **Available Work** is everything else the queue loaded: tasks assigned to somebody else, and tasks assigned to nobody at all. ![The Work Queue tab of the Production page in card mode, below the Scheduler, Work Queue, Parts List, Shift Production, Historical and Insights tab strip. Across the top sit the Machines, Tag and Operations filter buttons on the left, a My Work and Available Work toggle at the center with Available Work selected in blue, and on the right an Active, Done, All status control, a Card and List switch, and a blue circular plus button. Below them, eight job cards each carry a round part picture on the left, most of them the grey package placeholder, then a row of chips naming the parent job, the part and the operation, a bold job title, a count in pieces, a Requested By line, and the machine's name, identifier and photograph at the right edge. A status chip and a trash icon sit at the top right of each card: the chips read Not Started on six cards, In Progress in green on the PO-1012 OP10 Saw card and On Hold in amber on the PO-1012 OP30 Tap card.](/images/production/prod-wq-01.webp) *The Work Queue in card mode, scoped to Available Work. The My Work and Available Work toggle sits at the top center, the three filter buttons at the top left.* **The queue opens on My Work, on every platform.** The page writes `show_my_work_only=true` into the address bar the first time you land on it, so an operator whose planner has assigned nothing sees `No work assigned to you` over an empty page. Press **Available Work** before concluding the floor has nothing to run. ![A cropped detail of a two-button pill control, ringed in violet. The left half carries a person icon and the words My Work and is filled blue to show it is selected; the right half carries a clipboard icon and the words Available Work, left unfilled.](/images/production/prod-wq-02.webp) *The scope toggle at the top of the Work Queue, with My Work selected. Available Work is the other half of the same control.* Available Work is not a claim list. Nothing leaves it when somebody starts one of its jobs, see [Pick up a job](#pick-up). A job you create from this page is the exception. The create form always assigns the new work order to you, so it lands in **My Work** rather than in the list everyone shares. See [Create a production work order](/docs/production/create-a-job/). ## Filters Three filter buttons sit at the top left and the completion status control sits beside the scope toggle. Each button opens a searchable list over an **Apply** footer, and nothing changes until you press **Apply**. A **Clear** button appears beside **Apply** only once at least one box in that list is ticked, so a filter you have never set offers no way to clear it and does not need one. The middle button is labelled **Tag**, in the singular, although it filters on all of the tags you tick. Filtering happens on the server. Every control writes to the address bar and the page reloads the queue from it. ![The top row of the Work Queue with four numbered violet callouts. Callout 1 marks the Machines button, open on a panel with a Search machines box at the top, then the departments Demo, Machining and Production, each carrying a count and listing its machines with a checkbox, a name and an identifier beneath it, and a full-width blue Apply button pinned to the bottom. Callout 2 marks the Tag button and callout 3 the Operations button, both closed. Callout 4 marks the three-segment Active, Done, All control to the right of the scope toggle, with Active filled blue.](/images/production/prod-wq-03.webp) *The Work Queue filter row: Machines, Tags and Operations on the left, and the Active, Done and All status control to the right of the scope toggle.* ### Queue filters | Filter | Values | Persisted | |---|---|---| | **Machines** | Your departments, each expanding to the machines in it | `machines` in the address bar | | **Tags** | The tags on your machines | `tags` in the address bar | | **Operations** | Your parts, each expanding to its operations | `operations` in the address bar | | **Active / Done / All** | **Active** is Not Started, In Progress and On Hold. **Done** is Completed and Approved. **All** is all five. **Done** and **All** also take a lookback of 1, 7, 30 or 90 days, and default to 7 | `completion_status` and `last_updated_n_days` in the address bar | | **My Work / Available Work** | The two lists above | `show_my_work_only` in the address bar, set to `true` on first load | | **Card / List** | The two layouts below | Saved in your browser, per device | Everything in the address bar survives a reload and travels in a link you can send to someone. None of it survives leaving the tab: the tab strip navigates to a bare `?select=work_queue`, so coming back from **Scheduler** drops your filters and puts you on My Work again. The 1-year and 5-year lookbacks appear in the **Done** list behind a padlock reading `Enterprise plans only`. **Filter by machine, not by yourself, if you cover a cell.** My Work shows only what a planner has already assigned. The next job on the press you are standing at is usually in Available Work, and **Machines** is what finds it. **Reset Filters** appears beside the three buttons as soon as one of them is set. It clears machines, tags, operations and the **Done** lookback, and leaves the scope toggle and the completion status alone. Two lists are not quite what their names suggest. **Tags** is built from the tags on your machines rather than from anything on the job. **Operations** groups by part, so checking a part header checks every operation under it. The web queue has no search box. Search is a mobile control, see [On mobile](#mobile). ## Card and list modes The **Card** and **List** switch at the top right changes the layout, and your choice is saved in the browser rather than in the address bar. **Card** gives each task a band of its own: the part photograph, chips for the parent job, the part and the operation, the status chip, the count against the quantity ordered, the number of attached files, who requested it, and the machine with its identifier and photograph. **List** drops to one line per task and adds two fields the card does not carry. The due date, written as a distance from now and turning red once it is past, and a priority dot: red for High, yellow for Medium, blue for Low. ![The Work Queue in list mode, showing eleven single-line rows under the same toolbar, with List now selected instead of Card. Each row runs from a small round part thumbnail, through the job title with the machine name and a clock icon with a relative due date beneath it, to chips naming the parent job, part and operation, a small colored priority dot, a status badge reading Not Started, In Progress or On Hold, the machine's photograph, and a trash icon. The first two rows show their due dates in red, reading about 17 hours ago and 1 day ago. The dots run red on the PO-1011 rows, amber on the PO-1012 rows and blue on the three PO-1010 rows at the bottom.](/images/production/prod-wq-04.webp) *The Work Queue in list mode. Each row carries the due date and a priority dot, neither of which appears on a card.* **Use list mode when you are deciding what to run next, and card mode when you are hunting for a part.** Due date and priority are the two fields that answer "what next", and they exist only in list mode. Card mode is the one that shows you what the part looks like. The count on a web card, for example `12/50 pcs`, is the machine's auto-detected count. A count corrected by hand in the Scheduler table does not replace it here, although it does replace it on the mobile card and on the board. See [Edit in place](/docs/production/scheduler/#inline). > **Warning:** > **The trash icon deletes the work order** > > Both layouts carry one, on the card at the top right and on a list row at the far right. It opens a **Delete Work Order** confirmation and, on **Delete**, moves the work order to the trash for the whole organization. Nothing in the dashboard restricts it to planners. ## Pick up a job 1. Press **Available Work**. 2. Filter to your machine with **Machines**. 3. Switch to **List** and read down the due dates. 4. Click the task. The job runner opens at `/production/work-queue/` and your filters travel with it. 5. Check the machine and the quantity on the job, then press **Start**. See [Start, pause, and complete a job](/docs/production/run-a-job/). **Starting a job does not make it yours.** The web queue has no assign control. A started task keeps whatever assignees it had, stays in Available Work, and still shows there for everybody else; the status chip is the only thing that changes, to **In Progress**. There are two ways to actually own an existing task. Add yourself on the job page in the mobile app, see [On mobile](#mobile). Or ask a planner to drag it into your lane on the board, see [Group by asset, job or operator](/docs/production/scheduler/#grouping). Creating a new work order is different: the create form assigns it to you automatically, see [My work versus available work](#scope). ## On mobile The dashboard switches to the mobile layout inside the iOS and Android apps, and in any browser window narrower than 640 px. An iPad in a browser is wider than that and gets the web layout above; an iPad running the IoTFlows app gets the mobile one. ![The Work Queue on a phone. A toolbar across the top holds a two-button My Work and Available control ringed in violet with My Work selected, a search icon, a filter icon carrying a count badge, and a plus button. Below it, three job cards each show the part thumbnail, the job title, chips for the job and operation, a status badge, and a quantity progress bar.](/images/production/prod-wq-05.webp) *The Work Queue in the mobile app, opened on My Work. The scope control in the toolbar switches to Available.* Five things differ from the web: - The scope control reads **My Work** and **Available**, and it sits in the toolbar rather than at the top center. - The filters move into a **Filters** sheet, with the card and list switch at the top of it. The filter button carries a count of how many are set. - A search box opens from the toolbar. It matches the task title, its description, its work order number, the machine name and the parent job title. - Card mode uses the mobile work order card, which draws a quantity progress bar and honors a count corrected by hand. - The job page gains a **People** section listing the requester and the **Assignees**, with an **+ Add** button beside them. This is the only assign control anywhere in the Work Queue. Adding yourself toasts **Assignee added**, and the tap target next to your name removes you again with **Assignee removed**. A failure reads **Failed to add assignee** or **Failed to remove assignee**, and the assignment did not save. ## How the queue stays current The page subscribes to your organization's work order updates. When a task already on your screen changes anywhere in the product, the queue fetches that one task again and redraws its card in place, so a status chip flips to **In Progress** while you are watching. Bursts are collapsed, so a bulk edit on the board costs one round of updates rather than one per task. Two limits follow from "already on your screen". - A task that was not in the queue when it loaded never appears. A job a planner creates while you have the page open is invisible to you until the queue reloads. - A task never moves between My Work and Available Work on its own. The split is computed once per load, so an assignment that changes under you shows up in the card's contents and not in which list holds it. The queue reloads whenever the address bar changes: any filter, the status control, the scope toggle. There is no refresh timer and no refresh button, so the quickest way to force a reload is to flip the scope toggle and flip it back. ## See also - [Start, pause, and complete a job](/docs/production/run-a-job/) - [Create a production work order](/docs/production/create-a-job/) - [Plan jobs in the Production Scheduler](/docs/production/scheduler/) - [Give people access to a scheduler board](/docs/production/scheduler-members/) - [Run a job from the machine page](/docs/monitoring/operator-view/#jobs) --- # Altium Packaging Runs on Live Yield Source: https://www.iotflows.com/customers/altium-packaging/ How Altium Packaging's Memphis plant counts every bottle on its ten lines with BeamTracker, reads first pass yield and the bottles lost at every step of every line as they happen, schedules maintenance by the bottle in Maintain, and runs the floor from live data on TVs, desktops and phones instead of reports that took days or weeks. Altium Packaging's plant in Memphis, Tennessee, counts every bottle on its ten bottling lines with BeamTracker and reads their first pass yield as the bottles move: how many of the bottles that started down a line made it through each step, and how many were lost where. Maintenance runs on the same counts in Maintain, so a wear part is inspected on the bottle it is due. The numbers run live on TV screens on the shop floor and in the break room, on desktops and on phones, so the team deals with losses as they happen, not weeks later. ## The Challenge Altium Packaging makes plastic bottles and containers for dairy, water, beverage, food, household and specialty chemical brands. In Memphis, its ten bottling lines run anywhere from 20 to 140 bottles a minute, and every bottle passes through several machines on its way down a line. A count at the end of a line says how many good bottles came off it. It doesn't say how many started, or where the rest were lost. A bottle can be formed at the first step and rejected at the last, and at 140 a minute a small loss at one step adds up to thousands of bottles a shift. Without a count at every step, the plant could see that a line was down on yield but not which machine was costing it. The rest of the plant ran on the same delay: - **Reports that took days or weeks.** By the time the yield numbers arrived, the shift they described was long over. - **Meetings about the past.** The team met over old reports and hoped everyone remembered exactly what had happened at that moment. - **Wear measured in bottles, scheduled by the calendar.** The Slide Knife on one of the line's steps needs inspecting every 100,000 bottles. A line that ran fast all week reached the count early, and one that ran slow reached it late, so a date-based schedule was always either early or overdue. - **Losses nobody saw coming.** A part that missed its inspection or replacement, or an operator unsure of the role they played in the line, cost production before anyone knew it had happened. ## The Solution Altium Packaging put a BeamTracker at every step of its ten bottling lines, set each line up as one cascade in IoTFlows, and ran its maintenance in Maintain, all on the same live counts. ### A count at every step A BeamTracker at every step counts each bottle as it passes, at anything from 20 to 140 a minute, and reads that machine's rate in bottles per minute. See [Configure tracking for bottling and packaging lines](/docs/production/packaging-lines/). ### Every line as one cascade The machines a bottle passes through are grouped into a [cascading group](/docs/monitoring/asset-groups/), one per line, each with its step number. Step 1 is the reference: every step after it reports its first pass yield, the share of Step 1's bottles that reached it, with the bottles lost and the rate difference against Step 1 underneath. Yield reads green from 95%, amber from 80% and red below that, so a step falling behind stands out on the page. ### One changeover for the whole line When a line switches to a new bottle, one action sets the part on the whole cascade and the operation on each of its machines, so every step keeps counting against the right part from the first bottle of the run. See [Cascade a part and operation](/docs/monitoring/asset-groups/#cascade-part). ### Maintenance by the bottle In Maintain, each wear part gets a meter that counts the bottles the line has actually made. The Slide Knife's meter counts toward 100,000. The team gets an email as it gets close, and at 100,000 the inspection opens as a work order on its own. Once the knife is inspected, a reset starts the next 100,000. See [Trigger maintenance from meter readings](/docs/maintain/meters/). ### The line on every screen The live numbers, first pass yield included, run on TV screens on the shop floor and in the break room, on desktops and on phones, so operators, technicians and managers all see the same line at the same moment. See [Display a wallboard on a TV](/docs/monitoring/wallboards/). ### Where the bottles go On a cascade, a line's yield reads step by step. The view below is drawn from a five-step Altium line: Line 2 molded 22,860 bottles between 8 AM and 1 PM and 22,080 of them passed the leak detector: 96.6% first pass yield, 780 bottles lost. The steps in between say where: 148 at the detabber, another 207 by the trimmer infeed, and 351 at the leak detector, the largest single loss on the line. The rate column tells the same story in bottles per minute, so the team can see whether a step is losing bottles or simply running slow. ![A cascade in the Assets list view headed Line 2, 5 steps, part 1-gal jug, for 8 AM to 1 PM. Five rows: Step 1, Blow molder, 22.9K made, 83.1 bottles a minute against a target of 85.0, 100.0% FPY. Step 2, Detabber, 22.7K made, 82.6, 99.4% FPY, minus 148 bottles and minus 0.5 bottles a minute. Step 3, Trimmer infeed, 22.5K, 81.4, 98.4%, minus 355 bottles and minus 1.7. Step 4, Trimmer outfeed, 22.4K, 81.1, 98.1%, minus 429 and minus 2.0. Step 5, Leak detector, 22.1K, 80.0, 96.6%, minus 780 bottles and minus 3.1 bottles a minute. Every FPY figure is green.](/images/customers/altium-packaging/altium-line-2-fpy.webp) *A simplified view with sample data: one bottling line as a cascade, with each step's first pass yield, the bottles lost and the rate difference against Step 1.* Because every number is live, a drop shows while the shift is still running. The team talks it through on the floor, helps the operator at that step, and adjusts the line before the losses add up, instead of finding them in a report a week later. ![A wall-mounted TV over a blurred plant floor, showing the IoTFlows Assets page filtered to the Bottling department on the day shift, headed Bottling, 10 lines. Ten line cards in two rows: Line 1 at 112 bottles a minute, 96% uptime, 32K made; Line 2 at 80, 92%, 22K; Line 3 at 24, stopped, with a red Last Op: 6 min ago pill, 71%, 5.1K; Line 4 at 138, 98%, 41K; Line 5 at 60, 89%, 16K; Line 6 at 20, 94%, 5.6K; Line 7 at 96, 93%, 27K; Line 8 at 40, 97%, 12K; Line 9 at 120, 84%, 30K; Line 10 at 72, 91%, 20K. Each card has hourly bars from 8 AM, hours up and down, and a shift bar. A strip along the bottom reads Slide knife inspection, Line 2, 92,400 of 100,000 bottles, work order at 100,000.](/images/customers/altium-packaging/altium-bottling-wallboard-10-lines.webp) *A simplified view with sample data: all ten bottling lines live on the shop-floor TV, with the Slide Knife's count toward its next inspection along the bottom.* ### Inspected on the bottle it was due The same counts drive maintenance. Because the meter counts what the line actually made, the Slide Knife is inspected on the bottle it is due, whether the line ran fast or slow that week. The work order lands in Maintain with the line attached, and nothing depends on someone remembering to check a counter. ![A meter card titled Slide knife inspection, Line 2, production count, with Early Alert, Email Warning and Auto Work Order switched on. Time to Service reads about 2 hours, Current 92,400 in amber and Trigger Point 100,000. Below, a two-week sawtooth chart climbs to the red dashed trigger line about once a day and drops to zero at each reset. A pill reads Early alert sent at 85,000, and a note reads Work order created when the count reaches 100,000.](/images/customers/altium-packaging/altium-slide-knife-meter.webp) *A simplified view with sample data: a production-count meter for the Slide Knife inspection. It climbs to 100,000 bottles about once a day on a line like this one, opens the work order and starts again at each reset.* ## The Results - **From Old Reports to the Live Line** — - **First pass yield on every step of all ten bottling lines**, live, with the bottles lost and the rate difference at each step - **Losses found at the machine that caused them**, while the shift is still running, instead of in an end-of-line total days later - **Every bottle counted** by BeamTracker at every step, at 20 to 140 bottles a minute - **Maintenance by the bottle:** the Slide Knife inspected every 100,000 bottles, with the work order opened automatically - **Production significantly optimized** by keeping wear parts on the count they are due and every step on its yield - **Live numbers on the floor, in the break room, on desktops and on phones**, in place of reports that took days or weeks - **Issues talked through, operators helped and operations adjusted in real time** - **Fewer losses** from a missed inspection or replacement, or from an operator unsure of their role in the line For a plant where every bottle passes through several machines, that is the difference between knowing a line came up short and knowing which step, which hour and how many bottles. > **Success:** > "Now we can talk through issues, help our operators and adjust operations in real time. We used to wait days or weeks for reports, then hold meetings and hope the team knew exactly what had happened. IoTFlows has been a game changer for us." > > **Steve Petti, Plant Manager, Altium Packaging** ## The Features Behind It - **BeamTracker** at every step of every bottling line for a count of every bottle and each machine's rate. See [BeamTracker](https://www.iotflows.com/products/beamtracker/). - **Cascading groups** that read each line step by step. See [Group machines into cascades](/docs/monitoring/asset-groups/). - **First pass yield**, bottles lost and rate difference on every step. See [FPY across a cascade](/docs/monitoring/asset-groups/#fpy). - **Production-count meters** that open a work order at the count a part is due. See [Trigger maintenance from meter readings](/docs/maintain/meters/). - **Maintain** for the work orders, from the first alert to sign-off. See [Maintain](https://www.iotflows.com/platform/maintain/). - **Wallboards** on TV screens across the floor and the break room, with the same numbers on desktops and phones. See [Display a wallboard on a TV](/docs/monitoring/wallboards/). --- # Criollos Foods Raises Productivity 35% Source: https://www.iotflows.com/customers/criollos-foods/ How Criollos Foods improved bagging line efficiency by tracking real-time production rates, downtime causes, and operator performance metrics. ## The Challenge Criollos Foods, a leading producer of premium bagged and canned food products, faced critical visibility challenges on their bagging lines. With multiple product SKUs running on the same equipment throughout the day, they struggled to understand where inefficiencies existed and why production targets weren't being consistently met. Key challenges included: - **Unclear operator performance visibility** with no data on how different operators affected bagging line speeds - **Unknown downtime causes** - difficulty identifying whether delays were due to equipment issues, product changeovers, or other factors - **Inconsistent production rates** - some operators achieving 20 bags/minute while the target was 30 bags/minute with no clear insight into why - **Long setup times** between product changeovers with no tracking or optimization capability - **Training gaps** - inability to quickly identify which operators needed additional coaching to maximize machine performance - **No data-driven insights** into production efficiency and operator capability gaps ## The Solution Criollos Foods implemented IoTFlows BeamTracker across their bagging line operations, complemented by SenseAi sensors, to transform production visibility and enable data-driven optimization. ### BeamTracker: Precision Production Rate Tracking and Downtime Intelligence BeamTracker deployed on bagging lines provides the precision and analytical depth Criollos needed to understand exactly how their lines were performing and what was holding them back. **The Production Visibility Gap:** Before BeamTracker, Criollos had no precise way to measure whether their bagging lines were actually hitting target production rates. Were they achieving 30 bags per minute as planned, or falling short? When downtime occurred, they couldn't identify patterns across weeks and months to understand which issues were chronic problems versus one-off events. **The BeamTracker Solution:** BeamTracker provides extremely precise production tracking and downtime intelligence: - **Real-time production rate monitoring** - tracks actual bags per minute against target rates (e.g., 30 bags/min goal) - **Automatic downtime categorization** - every stoppage is logged and categorized by cause - **Week-over-week and month-over-month trend analysis** - identifies which downtime causes are recurring and costing the most production time - **Operator performance correlation** - links production rates to individual operators to identify training needs - **Product changeover tracking** - measures setup times between different SKUs > **Info:** > **Precision That Drives Action:** BeamTracker transformed production management from guesswork to data-driven decisions. Every production rate, every downtime event, every trend—tracked automatically with the precision needed to identify real improvement opportunities. 1. **Phase 1: Production Line Instrumentation.** Deployed IoTFlows BeamTracker on bagging lines to capture real-time production rates, downtime events, and product changeover times with precision tracking. 2. **Phase 2: Production Rate Monitoring Dashboard.** Created dashboards displaying actual production rates vs. target rates (30 bags/min) for each product SKU, with operator identification to correlate performance to individual team members. 3. **Phase 3: Downtime Trend Analysis.** Implemented week-over-week and month-over-month downtime tracking to identify chronic issues causing the most production loss, enabling targeted improvement initiatives. 4. **Phase 4: Operator Performance Program.** Launched an operator performance tracking system that identified training gaps, allowing management to provide targeted coaching to newer operators running at slower rates to help them reach the 30 bags/min target production rate. **SenseAi Integration:** SenseAi sensors complement BeamTracker by providing additional real-time machine status visibility, enabling team leaders to instantly see which lines are running and which need attention. ## The Results Within the first three months of implementation, Criollos Foods achieved measurable improvements across production efficiency, operator performance, and downtime reduction: - **Key Performance Improvements** — **Production Rate Precision (BeamTracker)** - **35% productivity increase** through identifying and training operators running below the 30 bags/min target rate - **92% of production lines** now consistently hitting target production rates, up from sporadic achievement - **Real-time visibility** into actual bags per minute vs. target for every line and operator - **Clear operator performance correlation** enabling targeted training and skill development **Downtime Intelligence (BeamTracker)** - **45% reduction** in unplanned downtime through trend analysis identifying chronic issues - **Week-over-week and month-over-month tracking** revealing which downtime causes cost the most production time - **Data-driven prioritization** of improvement initiatives based on actual impact - **Automatic downtime categorization** replacing guesswork with precise root cause data **Process Optimization (BeamTracker + SenseAi)** - **20-minute reduction** in average product setup/changeover time through data-driven process optimization - **Instant line status visibility** enabling faster response when production rates drop - **Performance-based training programs** targeting operators who need support to reach target speeds > **Success:** > "The visibility into operator performance was eye-opening. We could immediately see which team members needed additional training to reach target speeds. Within weeks of targeted coaching based on the IoTFlows data, our newer operators were hitting 30 bags per minute. The downtime tracking also revealed setup procedures we could streamline. This platform has transformed how we manage our bagging operations." > > **Juan Perez, Warehouse Operations Manager, Criollos Foods** ## Implementation Highlights ### Precision Production Rate Tracking (BeamTracker) BeamTracker displays live production rates for each bagging line down to bags per minute, with clear target rate benchmarks (e.g., 30 bags/min). Supervisors instantly see which lines are hitting targets and which are underperforming, with the ability to correlate performance to specific operators, shifts, and product SKUs. ### Downtime Trend Analysis (BeamTracker) Every downtime event is automatically categorized and tracked over time. BeamTracker's trend analysis reveals which issues cause the most production loss across weeks and months—transforming scattered incidents into actionable patterns. Management can now prioritize improvement initiatives based on actual data showing which problems cost the most production time. ### Operator Performance Correlation (BeamTracker) Each operator's production rates are tracked across different products and shifts, creating a clear picture of capability gaps. Operators running at slower rates (e.g., 20 bags/min vs. 30 bags/min target) are immediately identified, enabling management to provide focused training and support. The data shows exactly which team members need coaching to reach target speeds. ### Week/Month Comparison Analytics (BeamTracker) BeamTracker enables week-over-week and month-over-month performance comparisons, revealing trends that would be invisible with daily or shift-level views alone. This longitudinal analysis identifies chronic issues (e.g., "equipment failure causes 15% of downtime every month") versus one-time events, ensuring improvement efforts target the right problems. ### Target vs. Actual Performance Monitoring (BeamTracker) The system continuously compares actual production rates to target rates, highlighting performance gaps by operator, shift, and product. Supervisors see an hour fall short on [Shift Production](/docs/production/shift-production/) while it is still running, and step in before significant production is lost. ### Real-Time Line Status Visibility (SenseAi) While BeamTracker provides deep production analytics on the bagging lines, SenseAi extends visibility to machines where BeamTracker couldn't be deployed. SenseAi sensors installed on auxiliary equipment and supporting machinery provide instant status awareness—allowing team leaders to see at a glance which machines are running, idle, or experiencing issues across the entire facility. This ensures no blind spots remain in production monitoring. ## Built on the Same Data Everything Criollos Foods once listed as its next step now runs on the platform it already uses, on the counts BeamTracker and SenseAi record today: - **Production scheduling** - the [Production Scheduler](/docs/production/scheduler/) plans line assignments, product sequencing and shifts on the production rates each line has actually held - **Downtime trends** - the [Downtimes report](/docs/monitoring/downtimes/#pareto) ranks every stop reason by the time it costs, week over week and month over month, so a recurring issue is fixed before it costs another shift - **Real-time alerts** - [Machine Down alerts](/docs/alerts/asset-event-rules/#machine-status) reach supervisors by email, push, SMS, Slack or Teams when a line has been stopped past the threshold set for it - **Maintenance from the floor** - classifying a stop can [open a maintenance work order](/docs/monitoring/classify-downtime/#work-order) in Maintain in the same step, closing the loop between the problem and the fix - **First pass yield across a line** - machines grouped into a [cascade](/docs/monitoring/asset-groups/) report first pass yield and the units lost at every step against the first The vision is clear: a food manufacturing operation where every operator performs at peak efficiency, every downtime pattern is visible, and continuous improvement is driven by precise data rather than guesswork. See how it works on [production monitoring](https://www.iotflows.com/solutions/production-monitoring). --- # Datwyler Halves Shift-Changeover Downtime Source: https://www.iotflows.com/customers/datwyler/ How Datwyler's injection molding plant in Ontario, California, cut shift-changeover downtime by 50% and material-changeover downtime by 30% in six months, and raised fleet efficiency 20%, with SenseAi and the Downtimes report. Datwyler's plant in Ontario, California, runs more than 20 injection molding machines making precision components. With SenseAi on every machine and a reason on every stop, it cut shift-changeover downtime in half and material-changeover downtime by 30% within six months, and the fleet now runs 20% more efficiently. ## The Challenge Datwyler's production managers could see that a machine was down. What they could not see was why. A stop could be a material change, a shift handoff, an equipment fault, a setup or a cleaning cycle, and nothing recorded which. - **No ranking of the losses.** There was no systematic way to tell which kind of downtime cost the most. - **Fixes aimed at symptoms.** Without causes, improvement work was reactive and scattered. - **No way to tell whether a fix worked.** Each shift and each month stood on its own, with no trend to compare against. - **No accountability.** Downtime could not be tied to a process, a procedure or a team. ## The Solution Datwyler put SenseAi on its injection molding fleet and made downtime classification part of every shift. ### SenseAi on every molding machine SenseAi detects every stop from the machine's vibration, with no PLC connection and nothing for an operator to start or stop. Each stop lands on the machine's timeline the moment it happens. ### The routine stops classified automatically Three organization-wide [automatic rules](/docs/monitoring/auto-downtime-rules/) put a reason on the stops nobody should have to explain: short downtimes, stops at the start of a shift and stops at the end of one. The Downtimes report credits those stops to IoTFlows AI. ### A reason on every other stop Operators and supervisors [classify everything else by hand](/docs/monitoring/classify-downtime/), from a list of [downtime categories](/docs/monitoring/downtime-categories/) the plant keeps refining. Every shift handoff, material change and unexpected pause now arrives with a cause. ### Weekly and monthly reports Rather than watching live dashboards, Datwyler reviews the [Downtimes report](/docs/monitoring/downtimes/) week over week and month over month, with the reports [emailed on a schedule](/docs/monitoring/share-and-schedule-reports/). ![The Auto-Downtime Classifications panel in organization settings, applying to every machine. Short Downtimes, under 5 minutes by default, Start of Shift and End of Shift are enabled and highlighted, each assigning a reason of the same name. Entire Shift is disabled, and no break windows are set, so breaks are classified by operators. A footer reads Categorized By, with IoTFlows AI beside a small blue sparkle avatar, and everything else: by hand, beside an empty dashed avatar.](/images/customers/datwyler/datwyler-auto-rules-v4.webp) *The rules Datwyler runs: short downtimes and the start and end of each shift are classified automatically; operators and supervisors classify the rest.* ### What the history showed The weekly and monthly views revealed patterns that were invisible day to day. Week over week, Datwyler could see which days consistently had longer shift changeovers, whether material-change procedures were improving, and how new operators performed in their first weeks. Tuesday shift transitions turned out to add 8 to 10 minutes of downtime, every week: too small to notice on the day, costly over months. Month over month, the team tracked the cumulative effect of each improvement, found the persistent problems worth an engineering fix, compared production teams and set data-backed targets for the next cycle. Supervisors who see their shift's numbers improve in the weekly report become advocates for the process. ![Downtimes by Time Interval, monthly, for 20 molding machines, in sample data. Six stacked bars fall from 234 hours in Month 1 to 176 hours in Month 6. Material change shrinks from 90 to 63 hours and shift change from 64 to 32 hours, while unplanned maintenance, short downtimes, start of shift and end of shift hold roughly steady.](/images/customers/datwyler/datwyler-monthly-downtime-v3.webp) *A simplified view of six months like Datwyler's, in sample data: shift-change downtime halves and material-change downtime falls by 30%, while the other reasons hold steady.* ## The Results - **Downtime Transformation** — - **50% less shift-changeover downtime**, from streamlining the handoff procedures the reports exposed - **30% less material-changeover downtime**, from targeting the material types that needed the longest setups - **20% higher efficiency** across a fleet of more than 20 injection molding machines - **Within six months** of putting SenseAi on the fleet - **A reason on every stop**, automatic for the routine ones and by hand for the rest - **Evidence over opinion**: improvement work is chosen from cumulative charts, and each fix is checked against the weeks that follow > **Success:** > "IoTFlows didn't just give us data—it gave us a method. By tracking downtime categorization week to week and month to month, we could see exactly where our biggest problems were and track whether our fixes actually worked. The 50% reduction in shift changeover time came directly from acting on patterns we saw in the historical reports. That's not luck; that's discipline meeting data." > > **Brien Stevenson, Site Director, Datwyler** ## The Features Behind It - **SenseAi** on every molding machine, detecting each stop from vibration. See [SenseAi](https://www.iotflows.com/products/senseai/). - **Automatic classification** of short downtimes and shift starts and ends. See [Classify downtime automatically](/docs/monitoring/auto-downtime-rules/). - **Downtime categories** under severity headings, refined as the plant learns. See [Manage downtime categories](/docs/monitoring/downtime-categories/). - **Classification by operators and supervisors** for every other stop. See [Classify a downtime event](/docs/monitoring/classify-downtime/). - **The Downtimes report**, with the Pareto and the by-interval trend. See [Analyze downtime with Pareto and trend charts](/docs/monitoring/downtimes/). - **Scheduled reports** for the weekly and monthly reviews. See [Email a report and schedule it to repeat](/docs/monitoring/share-and-schedule-reports/). See how it works on [downtime tracking](https://www.iotflows.com/solutions/downtime-tracking/). --- # Hilco Vision Raises Production Over 20% Source: https://www.iotflows.com/customers/hilco-vision/ How Hilco Vision transformed their optical manufacturing operation from reactive firefighting and missed targets to real-time predictive control, turning every downtime event into an elimination opportunity. ## The Question Every Manufacturer Asks Every day at Hilco Vision began with the same ritual: production targets written on a whiteboard, shift schedules posted, machines humming to life. By mid-afternoon, the gap between target and reality would start to reveal itself. Sometimes they were ahead. Often they were behind. Always, there was the same nagging uncertainty: *Will we hit our numbers today?* The honest answer was uncomfortable. Nobody really knew until the shift ended and the final count was in. By then, it was too late to change course, too late to adjust priorities, too late to salvage a missed target. Production planning had become an exercise in educated guessing. Set ambitious goals, work hard, hope for the best, and deal with whatever outcome materialized at 5:00 PM. Some days brought pleasant surprises. Other days brought explanations for why targets were missed—vague references to "machine issues" or "unexpected delays" that lacked the data to prevent recurrence. What Hilco Vision needed wasn't hope. It was certainty. Not at the end of the day, but in the middle of it—when decisions could still make a difference. ## The Predictability Problem Hilco Vision manufactures precision optical components products where quality and consistency are non-negotiable. But despite running sophisticated equipment and employing skilled operators, their operation suffered from a fundamental flaw: **unpredictability.** Production targets were set each day, but whether they'd be met was essentially a coin flip. Some days they'd exceed goals by 15%. Other days they'd fall short by 20%. The variability wasn't random there were causes but those causes were invisible. When they missed targets, the post-mortem was always unsatisfying: - "The machines were down a lot today" (But why? For how long? Which ones?) - "We had some quality issues" (When did they start? What triggered them?) - "Setup took longer than expected" (How much longer? Which setups specifically?) Without data, every explanation was vague. Without visibility, every day was a surprise. ## The Turning Point: What If We Could Predict the Future? Hilco Vision deployed IoTFlows with a specific goal: **make production outcomes predictable before they happen.** Two systems working in concert transformed their operation: **BeamTracker** became their crystal ball tracking production rates with such precision that by mid-afternoon, it could calculate with confidence whether they'd hit daily targets. Not a guess. Not a hope. A data-driven prediction. **SenseAi** became their operational intelligence engine capturing every machine event, every stoppage, every anomaly, and turning raw sensor data into actionable insights through algorithmic analysis. Together, these systems didn't just monitor production. They created a predictive control loop that fundamentally changed how Hilco Vision operates. ![Shift Production for one operation at 2:00 PM on a day shift from 7 AM to 5 PM, in sample data. The calculated goal is 4,000 and 2,690 good parts are counted so far. Seven hourly bars run from 7 AM to 2 PM against a dashed hourly goal of 400: four are blue at or above the goal and three are amber below it, at 340, 395 and 318. A note reads Goal to 2 PM 2,800, 110 behind, three hours left. The bars for 2 PM to 5 PM are empty.](/images/customers/hilco-vision/hilco-vision-shift-hourly.webp) *A simplified view of a shift like Hilco Vision's, in sample data: at 2 PM the operation is 110 parts behind, and the three amber hours say where to look while three hours are still left.* ## From Reactive to Predictive: The Three Capabilities That Changed Everything ### 1. The Prediction Engine: Know Your Outcome Before It Happens BeamTracker doesn't just count parts. It calculates velocity, identifies trends, and projects outcomes in real-time. Now, at 2:47 PM on a Tuesday, the production manager doesn't wonder if they'll hit 40,000 units. The system tells them: > **Target: 40,000 units | Current: 26,800 | Projected: 38,600 | Alert: 1,400 units short** That 1,400-unit gap is visible with two hours left in the shift. Not at 5:00 PM when it's too late. At 2:47 PM when they can *do something about it*. The response is immediate: - Identify which line is running slowest - Check if an operator needs support - Adjust priorities to focus on high-velocity products - Allocate resources to the bottleneck By 5:00 PM, the board shows 40,200 units. Target exceeded. **This is the power of predictive visibility.** Not knowing what happened. Knowing what *will* happen in time to change it. > **Success:** > **Shift from Hope to Control:** "Before IoTFlows, we'd set a target and hope we hit it. Now we know by mid-afternoon exactly where we'll land and whether we need to adjust. That shift from hoping to knowing is everything. It turns production management from firefighting into orchestration." > > **Swapnil Rane, Engineering Manager, Hilco Vision** ### 2. The Intelligence Layer: Making Sense of Complexity Optical manufacturing isn't simple. Machines behave unpredictably. Some processes run smoothly for hours, then suddenly slow down. Understanding *why* required detective work until SenseAi automated the investigation. SenseAi uses algorithmic analysis to turn raw machine data into production intelligence: - **Pattern recognition algorithms** identify when machine behavior deviates from normal operation, flagging potential issues before they cause major downtime - **Real-time production estimation** calculates expected output for processes that previously had no reliable forecast - **Anomaly detection** catches unusual events that would otherwise go unnoticed until they became critical problems What used to require a production engineer manually reviewing logs now happens automatically. The system doesn't just capture data it *understands* it. ### 3. The Elimination Strategy: Every Downtime Event Becomes an Opportunity Here's where most manufacturers fail: they capture downtime data, but never systematically eliminate the root causes. Hilco Vision built something different: **a downtime elimination process.** Every stoppage is: 1. **Captured** - SenseAi logs the exact time, duration, and machine 2. **Categorized** - Was it equipment failure? Setup delay? Quality issue? Material shortage? 3. **Analyzed** - BeamTracker shows cumulative impact over days and weeks 4. **Prioritized** - Which categories cost the most production time? 5. **Targeted** - Create specific elimination or minimization plans for the biggest offenders This isn't about monitoring downtime. It's about *systematically destroying it*. - **The Downtime Elimination Cycle** — **Week 1-2: Discovery Phase** - Capture and categorize all downtime events - Identify top 3 causes by cumulative impact - Surprising finding: "Minor" stoppages add up to 18% of total downtime **Week 3-4: Intervention Phase** - Target #1 cause with specific process improvement - Track whether intervention reduces frequency or duration - Adjust approach based on results **Week 5-8: Validation Phase** - Compare downtime patterns before and after intervention - Calculate ROI of improvement initiative - Move to next highest-impact category **Result:** Systematic, data-driven reduction of previously "unavoidable" downtime ## The Whole Factory, Live The combination of SenseAi and BeamTracker created something Hilco Vision never had before: a complete digital representation of their factory floor. Every machine. Every operator. Every process. All visible in real-time with predictive insights layered on top. **What this means practically:** - **Morning:** Review overnight production vs. targets, identify which lines need attention - **Mid-shift:** Check real-time projections, course-correct if falling behind - **End of day:** Analyze downtime by category, prioritize tomorrow's improvements - **End of week:** Compare performance trends, validate improvement initiatives - **End of month:** Calculate cumulative impact of systematic downtime elimination This isn't a dashboard they check occasionally. It's the operational nervous system of the business. ## The Cultural Transformation Technology enables change, but culture determines whether it sticks. Hilco Vision's transformation wasn't just about sensors and algorithms. It was about changing how the team thinks about production management. **Before:** - Waiting: Reports arrived days after the shift - Reactive: Respond to problems after they occur - Blame-oriented: "Who caused the downtime?" - Acceptance: "Some days are just bad days" **After:** - Real-time: Analyze and adjust while the shift is still running - Proactive: Predict and prevent issues before they impact targets - Process-oriented: "What caused the downtime and how do we eliminate it?" - Systematic: "Every problem is an opportunity for permanent improvement" The result shows in the output: Hilco Vision's production is up more than 20%. The data made this cultural shift possible. When downtime is categorized and tracked, conversations move from blame to solutions. When predictions show target shortfalls with time to correct, teams can act rather than react. ## Why Predictability Matters More Than Speed Many manufacturers focus on running faster higher line speeds, faster setups, quicker changeovers. Hilco Vision discovered something more valuable: **predictability.** A production line that runs at 90% capacity but hits targets consistently is more valuable than one that sometimes runs at 110% but frequently misses goals. Customers don't care about your best day. They care about reliable delivery. BeamTracker's predictive alerts transformed Hilco Vision from a manufacturer that *sometimes* exceeds expectations to one that *consistently* delivers on commitments. That reliability is a competitive advantage no amount of speed can replicate. ## The Difference Between Visibility and Intelligence Most "smart factory" implementations stop at visibility: dashboards showing machine status, production counts, and downtime totals. Hilco Vision went further. They built **operational intelligence**: - Visibility tells you a machine is down. Intelligence tells you *why* and predicts when it will happen again. - Visibility shows you missed a target. Intelligence warns you two hours before the shift ends that you're going to miss it. - Visibility captures downtime. Intelligence prioritizes which downtime to eliminate first based on cumulative impact. The difference isn't semantic it's the gap between reactive data collection and proactive operational control. ## Looking Forward: From Firefighting to Orchestration Hilco Vision's journey isn't finished. They're now expanding their predictive capabilities: - **Predictive maintenance** - using SenseAi pattern recognition to identify machines showing early signs of degradation - **Dynamic scheduling** - leveraging BeamTracker's production velocity data to optimize job sequencing in real-time - **Quality correlation** - connecting downtime events to quality metrics to catch issues before they reach customers - **Cross-facility benchmarking** - comparing performance patterns across production areas to identify best practices But the foundation is set: complete factory digitization, predictive production control, and systematic downtime elimination. **The result:** A manufacturing operation that doesn't react to problems it anticipates them, prevents them, and continuously eliminates their root causes. ## The Answer to the Question It's 2:47 PM on a Tuesday. The production target is 40,000 units. Current count: 26,800. The production manager doesn't wonder if they'll make it. The screen shows: **Projected final count: 40,200 units.** They'll exceed the target. They know this with two hours left in the shift. Not because of luck. Not because of hope. Because **unpredictable became predictable.** See how it works on [production monitoring](https://www.iotflows.com/solutions/production-monitoring). --- # Hugo Benzing Raises Efficiency 20% Source: https://www.iotflows.com/customers/hugo-benzing/ How Hugo Benzing's US plant gained 20% efficiency, saves 10+ planning hours a week and went live in under two weeks with the IoTFlows Production Scheduler. Hugo Benzing's plant in Wixom, Michigan, plans coiling, heat treatment and packing in the IoTFlows Production Scheduler. Planning the tubes, racks and boxes every order depends on, not just the machines, has raised efficiency by 20%. The planners save more than 10 hours a week, and the schedule was live in under two weeks. ## The Challenge Hugo Benzing has made safety elements for moving parts for more than 90 years. Its retaining rings, snap rings and other rings hold assemblies together inside car engines, and its US plant, Hugo Benzing LLC, makes them by the tens of thousands. ![A cross-section of a car transmission, with Benzing rings highlighted in green throughout its clutch packs and gear sets](/images/customers/hugo-benzing/hugo-benzing-transmission-cutaway.webp) *Benzing rings at work inside a transmission. Image: Hugo Benzing.* Every ring order takes the same route through the plant: 1. **Coiling.** A coiling machine forms the rings from wire. 2. **Heat treatment.** The rings are loaded into tubes, 150 to 200 to a tube depending on the ring's size, and the tubes go into an oven. 3. **Packing.** The finished coils run through a shrink-wrap conveyor and are packed for the customer. The coilers and the ovens are easy to put on a schedule. What runs out first is everything that travels with the rings: the heat-treat tubes, the racks and the boxes. The plant runs more than 10 types of tube, with tens to hundreds of each. A 50,000-ring order alone fills somewhere between 250 and 334 tubes, and every one of them is in the oven, not on the shelf, until that order's heat treatment ends. Whether the next ring size can go into an oven on Thursday depends as much on how many tubes, racks and boxes are free by Thursday as on whether an oven is. Hugo Benzing's planners answered those questions in a stack of complex Excel sheets: - **One sheet per question.** How long each coiling run would take, when each oven was free, how many tubes, racks and boxes were out. - **No view of the knock-on effect.** None of the sheets showed what happened to everything else when one order moved, and with several ring sizes running at once, orders move every day. - **No live numbers from the floor.** Coiler uptime and the coils actually made came in after the fact, so the plan and the plant drifted apart during the shift. ## The Solution Hugo Benzing put the whole route, from coiling to packing, on IoTFlows: SenseAi on the coiling machines, BeamTracker on the packing line, and the Production Scheduler on top of both. The planners were scheduling live in under two weeks. ### SenseAi on every coiling machine SenseAi sensors on the coilers track uptime and downtime and count the coils each machine makes, live. The planners see whether a coiling run is on pace while it is still running, not at the end of the shift. ### BeamTracker after the shrink-wrap conveyor A BeamTracker counts every assembled coil as it leaves the shrink-wrap conveyor, so the number packed for a customer is a count, not an estimate. ### Every job built in the Production Scheduler The planners build every job directly in the [Production Scheduler](https://www.iotflows.com/platform/production-scheduler/), from the part and operation data already set up in IoTFlows. There is no ERP import in between: the routing for each ring, coil, heat-treat and pack, is already on the part, so every new order starts from it. ### Tubes, racks and boxes as tooling The tubes, racks and boxes are each set up as a reusable tool that a job reserves for as long as it needs them. Under the Gantt, the [capacity lane](/docs/production/scheduler/#capacity) starts from what is on the shelf today and draws, for each one, how many are free at every moment of the week, which order is holding them and when they come back. ![A Production Scheduler Gantt for one week with four lanes: Coiler 1 running 50,000 retaining rings and then 30,000 snap rings, Oven 1 heat-treating the retaining rings, Oven 2 heat-treating the snap rings on Thursday, and Packing. Below the lanes, the Tooling capacity row for heat-treat tubes drops from 300 to 50 while the retaining rings are in the oven and returns to 300 before the snap rings take 200. The Projected output rows show 50,000 retaining rings ready by Friday and the coiled rings building up before the oven.](/images/customers/hugo-benzing/hugo-benzing-capacity-lane.webp) *A simplified view of a week like Hugo Benzing's: the coiler, the ovens and packing on the Gantt, with the heat-treat tubes and the projected output in the capacity lane below.* ### Where the plan breaks, seen first Those lines are where a plan breaks, and where the planners now see it break first. Take the tubes. Drag the snap rings' heat treatment a day earlier and the line drops below zero, in rose, before anything is saved. Move it back to when the retaining rings' tubes return and the shortage is gone. The same shortage appears in the [Schedule issues](/docs/production/schedule-issues/) list as tooling with no units free, so it cannot hide on a part of the Gantt nobody is looking at. ![The same week with the snap rings' heat treatment in Oven 2 moved a day earlier and ringed in rose. The heat-treat tubes row drops from 50 to minus 150 while both heat treatments overlap, drawn in rose, and the row's label reads 150 short.](/images/customers/hugo-benzing/hugo-benzing-tube-shortage.webp) *Moving the snap rings into the oven a day early: the tubes go 150 short while both heat treatments overlap, and the scheduler shows it before the change is saved.* ### How many rings will be ready to ship Because each operation declares the rings it makes, the capacity lane also projects output: how many retaining rings will be finished, and by when, and how many coiled rings are waiting for an oven at any point in the week. It starts from what is already on hand, so the planners see where they stand today and where they will be by Friday. See [Link required and created parts to an operation](/docs/production/bind-materials/). ## The Results - **From Spreadsheets to One View** — - **20% more efficiency** from optimizing the tubes, racks and boxes every order depends on - **10+ hours of planning saved** every week - **Under two weeks** from kickoff to planning live in the Production Scheduler - **One view** of the coilers, the ovens, the tubes, racks and boxes, and the rings ready to ship - **Tube, rack and box shortages seen while planning**, before a job is saved, instead of on the floor - **Live coiling numbers** from SenseAi: uptime, downtime and coils made on every coiler - **Every packaged coil counted** by BeamTracker after the shrink-wrap conveyor - **A stack of complex Excel sheets retired**, along with the rework every time an order moved For a plant where one shared resource decides what every machine can do next, that is the difference between finding a conflict on Thursday morning and seeing it on Monday, while there is still time to move something. > **Success:** > "We love the entire IoTFlows platform. It has revolutionized our visibility into our operations, from the coilers to the ovens to the packing line." > > **Morne Grobler, Operations Manager, Hugo Benzing** ## The Features Behind It - **SenseAi** on the coiling machines for uptime, downtime and coil counts. See [SenseAi](https://www.iotflows.com/products/senseai/). - **BeamTracker** on the packing line for a count of every packaged coil. See [BeamTracker](https://www.iotflows.com/products/beamtracker/). - **Gantt planning** across coilers, ovens and packing lines. See [Plan jobs in five views](/docs/production/scheduler/). - **Tooling capacity** for the tubes, racks and boxes, with each shortage drawn before it happens. See [Read the capacity lane](/docs/production/scheduler/#capacity). - **Projected output** for every ring, from what is on hand and the parts each operation creates. See [Link required and created parts to an operation](/docs/production/bind-materials/). - **Schedule issues** that list any tool with no units free. See [Find and fix problems in the schedule](/docs/production/schedule-issues/). --- # Jesel Responds to Issues in Minutes Source: https://www.iotflows.com/customers/jesel/ How Jesel transformed daily manufacturing operations by using real-time OEE data and cycle time validation to identify process deviations early and make informed decisions. ## The Challenge: From Blind Spots to Baseline Understanding Jesel operates precision CNC machinery where every second matters and every process deviation compounds into cost and quality impacts. Yet like many manufacturers, they faced a critical gap: **they lacked real-time visibility into how well each machine was actually performing.** Common manufacturing challenges plagued them: - **Unknown machine utilization** - no clear picture of which machines were running at full capacity and which had hidden downtime - **OEE blindness** - unable to measure overall equipment effectiveness in real-time across the shop floor - **Cycle time uncertainty** - relying on theoretical times from bills of material without knowing if actual production matched planned times - **Late problem detection** - deviations in setup, tooling, or processes discovered too late to prevent scrap or rework - **Reactive troubleshooting** - addressing issues after they impacted production rather than catching them early - **Decision-making based on assumptions** - operations managed by intuition rather than data The result: a manufacturing operation running blind, making decisions based on estimates rather than evidence, and unable to systematically improve what they couldn't see. ![A Jesel belt drive pair, machined and assembled](/images/customers/jesel/jesel-belt-drive-pair-wide.webp) *A Jesel belt drive pair. Every machine that makes one is monitored by SenseAi.* ![Jesel cam cores lined up after machining](/images/customers/jesel/jesel-cam-cores-wide.webp) *Jesel cam cores. OEE on the machines that cut them is reviewed daily.* ## The Transformation: Real-Time Visibility Becomes Operational Reality Jesel deployed IoTFlows machine sensors and dashboards to capture real-time performance data across their CNC equipment. The impact was immediate and profound, suddenly they could see what had been invisible. ### Discovering OEE: The Master Metric Overall Equipment Effectiveness (OEE) is the gold standard metric for manufacturing performance, combining availability, performance, and quality into a single number. But you can't manage what you can't measure. With IoTFlows, Jesel now tracks OEE continuously and displays it on accessible dashboards. Every operator, supervisor, and manager can see: - **Availability** - how much of the scheduled time the machine is actually running - **Performance** - how fast the machine is running compared to its theoretical maximum - **Quality** - what percentage of parts produced meet specifications This transparency transformed how the shop floor operated. Suddenly, improving OEE wasn't a vague goal, it was a visible, measurable, achievable target that everyone could see improving in real-time. ### Cycle Time Validation: Theory Meets Reality Jesel's bills of material contained cycle time estimates, the theoretical time it should take to complete each operation. But theory doesn't account for real-world variations in operator skill, tool wear, setup differences, and machine behavior. IoTFlows changed this equation. By comparing actual measured cycle times against the times specified in the bills of material, Jesel discovered: - **Systematic deviations** - certain products consistently running faster or slower than planned - **Setup inefficiencies** - tooling and fixture setup taking longer than estimated - **Operator variance** - experienced operators completing cycles faster than newer staff - **Tool performance degradation** - cycle times increasing as tools wear - **Process improvement opportunities** - where the biggest gaps existed between theory and reality This wasn't abstract data, it was actionable intelligence that informed every manufacturing decision. ![A table titled Cycle time against the bill of material, for four CNC operations in sample data. OP10 Turning: BOM 2:30, actual 2:24, green. OP20 Milling: BOM 4:10, actual 4:52, red, with a note reading tool wear, cycle rising since Tuesday. OP30 Drilling: BOM 1:45, actual 1:41, green. OP40 Finishing: BOM 3:20, actual 3:58, red, with a note reading new setup. Each row carries a bar for the actual time with a marker at the BOM time.](/images/customers/jesel/jesel-cycle-times-v2.webp) *A simplified view of a day's check like Jesel's, in sample data: two operations run faster than the bill of material, one has slowed with tool wear and one is running slow after a new setup.* ## Daily Operations Transformed > **Success:** > "The IoTFlows Machine Sensors continue to provide us with valuable real-time data that we rely on to measure machine utilization and overall equipment effectiveness (OEE). The dashboard has become an essential tool in our daily operations, not only for monitoring how well each machine is performing, but also for quickly identifying areas that need attention, including setups, tooling performance, and other process-related issues. > > I use the dashboard every day to compare and validate actual cycle times against the times listed in our bills of material. This has helped improve accuracy, highlight deviations early, and support more informed decision-making across our manufacturing processes." > > **Pete Gonella, Director of Manufacturing, Jesel** This isn't theoretical improvement, this is how Jesel now operates, day in and day out. The dashboard has become indispensable. ## Key Operational Impacts - **From Visibility to Decision-Making** — **Response Time** - Seconds or minutes to respond to an issue, down from hours or days before IoTFlows - Problems caught on the shift they happen, not in a report days later **Machine Utilization Clarity** - Real-time view of which machines are fully utilized and which have capacity - Ability to balance workload across equipment based on actual performance data - Elimination of guesswork about where bottlenecks exist **OEE as Daily Driver** - Continuous visibility into the three components of OEE (availability, performance, quality) - Shift-by-shift comparison revealing patterns and performance trends - Accountability tied to visible, measurable metrics **Cycle Time Intelligence** - Actual cycle times compared directly against bills of material estimates - Early detection of deviations before they become expensive problems - Data-driven refinement of planned cycle times based on reality **Setup and Tooling Insights** - Clear visibility into setup time variations and optimization opportunities - Identification of tooling performance issues before quality suffers - Continuous feedback on process-related performance drivers **Informed Decision-Making** - Operations guided by evidence rather than intuition - Resource allocation decisions based on real performance data - Continuous improvement initiatives targeted at the biggest impact areas ## Why This Matters In precision manufacturing, small deviations compound. A setup that runs 5 minutes slower than expected, repeated 20 times a day, becomes an hour of lost capacity. A tool that's degrading unseen creates quality issues that appear downstream. A machine running at 85% of theoretical capacity instead of 95% drains profitability across thousands of parts. Jesel's advantage isn't investing in new equipment, it's **understanding and optimizing what they already have**. By making utilization, OEE, and cycle times visible, they've unlocked performance that was always there, just hidden. ## The Daily Dashboard Routine For Jesel, the IoTFlows dashboard isn't a report you check weekly. It's a tool Pete and his team consult every day: - **Morning:** Review overnight production OEE to understand machine behavior - **Throughout the day:** Monitor cycle times against estimates to catch deviations early - **Setup changes:** Validate that new setups match planned cycle times - **Problem-solving:** When a machine underperforms, the data is immediately available to diagnose why - **Decision-making:** Resource allocation and production scheduling informed by real performance metrics This daily reliance on data-driven insights has fundamentally changed the culture of manufacturing management at Jesel. ## Looking Forward: Continuous Refinement Building on the foundation of real-time OEE and cycle time visibility, Jesel is exploring advanced analytics to predict tool wear before it impacts quality, optimize setup procedures based on performance data, and leverage historical patterns to continuously refine bills of material estimates. The vision is clear: a precision manufacturing operation where every machine's performance is visible, every decision is data-backed, and continuous improvement is built into daily operations rather than relegated to annual reviews. See how it works on [OEE tracking](https://www.iotflows.com/solutions/oee-tracking). --- # MiRus Sees the Cost of Every Job Source: https://www.iotflows.com/customers/mirus/ How MiRus, a Marietta, Georgia implant maker, raised efficiency by more than 20% with live machine data from SenseAi and SenseAi Embedded, and a two-way Epicor connector that ties every job to its machining and labor hours. MiRus runs its machines on IoTFlows and its jobs in Epicor, and a two-way connector between the two ties every job to the machining and labor hours behind it. Seeing productivity live, and solving issues sooner because of it, has raised efficiency by more than 20%. The connector went live in about a month. ## The Challenge MiRus, in Marietta, Georgia, makes implants for the spine, the structural heart and the extremities, built from its own molybdenum-rhenium alloy, MoRe. Implants are made in small, exacting batches, and every one of them carries machine time and skilled labor. Two questions sat at the center of the operation, and neither had a quick answer: - **How are the machines doing right now?** Productivity on the floor showed up after the fact, so an issue on a machine could cost a shift before anyone saw it. - **What did a job really cost?** The machining hours and the labor hours behind each job were hard to get from the ERP alone, if they could be had at all. Without them, nobody could say whether an improvement on the floor was paying off in the cost of a product line. ## The Solution MiRus put its machines on IoTFlows and connected IoTFlows to its ERP, so the floor and the books finally read from the same data. ### SenseAi and SenseAi Embedded on the machines SenseAi and SenseAi Embedded sensors report each machine's productivity live: running, stopped, and how long. The team sees an issue while it is happening, and solves it sooner. ### A two-way Epicor connector, built in about a month IoTFlows built a connector against MiRus's own Epicor, as a [custom integration](https://www.iotflows.com/platform/custom-integrations/). It pulls every job from the ERP and correlates it with the machining and labor hours it actually took, without a file export or a spreadsheet in between. ### Every job, its hours and its cost With every job carrying its hours, MiRus sees how efficiency gains on the floor have lowered its labor and machining costs, and how they have raised the profitability of each product line. ![A diagram with four boxes. SenseAi on the machines and SenseAi Embedded, productivity live, feed IoTFlows, where each job is matched to the machining and labor hours behind it. IoTFlows and Epicor exchange data both ways: jobs in, hours back.](/images/customers/mirus/mirus-epicor-flow.webp) *How the data moves: the machines report live to IoTFlows, and the Epicor connector runs both ways.* ### Where every job stands Each job from Epicor arrives with the hours planned for it, and fills in with the machining and labor hours it actually took. A job running over its hours stands out while there is still time to ask why, and a job that came in under shows where an improvement on the floor has paid off. ![A list headed Jobs from Epicor, marked Synced 2 min ago, with four jobs. Each row shows the job number, the part, planned and actual machine hours, planned and actual labor hours, and the variance: a wedge plate 11% under, a pedicle screw 5% under, a valve frame 10% over and highlighted in amber, and a bone staple 10% under.](/images/customers/mirus/mirus-epicor-jobs.webp) *A simplified view with sample data: each Epicor job with its planned and actual machining and labor hours.* ## The Results - **From the Floor to the Books** — - **More than 20% higher efficiency** from seeing productivity live and solving issues sooner - **About a month** from kickoff to a live, two-way Epicor connector - **Every job tied to its machining and labor hours**, without exporting anything from the ERP - **Labor and machining costs** that show how each efficiency gain pays off - **Profitability by product line**, built from the hours each job really took - **Real-time productivity** on every machine, from SenseAi and SenseAi Embedded For a manufacturer whose products are made in small, exacting batches, knowing what each job really took is the difference between believing an improvement worked and seeing it in the cost of the product. > **Success:** > "The real-time visibility has been amazing for optimizing our operations. With the ERP integration, I see the numbers and where every job stands, without digging for them in our ERP." > > **Dennis Moreno, Vice President of Manufacturing and Operations, MiRus** ## The Features Behind It - **SenseAi** for live productivity on every machine. See [SenseAi](https://www.iotflows.com/products/senseai/). - **SenseAi Embedded** for machines that need the sensor built in. See [SenseAi Embedded](https://www.iotflows.com/products/senseai-embedded/). - **A two-way ERP connector** built against the customer's own Epicor, for Enterprise customers. See [Custom integrations](https://www.iotflows.com/platform/custom-integrations/) and [Integrations](https://www.iotflows.com/platform/integrations/). - **Downtime tracking** that shows when and why a machine stopped. See [Find out why a machine stopped](/docs/monitoring/downtimes/). *Cover image: MiRus 3DR interbody implants, with their porous lattice walls. Render: MiRus.* --- # Ranpak: Blueprint for Global Excellence Source: https://www.iotflows.com/customers/ranpak/ How Ranpak transformed a single-factory pilot into a blueprint for worldwide deployment, unlocking a new business model that shifts from reactive repairs to predictive fleet intelligence across thousands of customer machines. ## The Stakes: When Success at One Site Unlocks Opportunity Everywhere Most pilot programs answer a simple question: *Does this work?* Ranpak's pilot deployment of IoTFlows at a single facility was designed to answer something far more ambitious: *Can we build a model that transforms how we operate globally and how we serve customers worldwide?* The answer needed to be definitive. Because if this worked, it wouldn't just optimize one factory. It would become the blueprint for operational excellence across every Ranpak facility on the planet. And beyond that, it would unlock an entirely new value proposition: proactive health monitoring for the thousands of machines Ranpak deploys in customer facilities around the world. This wasn't a test. It was the foundation for a strategic transformation. ## The Challenge: Excellence at Scale Requires Data, Not Assumptions Ranpak manufactures sustainable protective packaging solutions, machines and materials that replace plastic bubble wrap and foam with paper-based alternatives. Their equipment runs in their own factories and in customer facilities globally, converting paper into protective packaging at high speeds. But like any manufacturer operating complex machinery across diverse environments, Ranpak faced fundamental operational blind spots: **Machine Utilization: The Optimization Gap** - Which machines were running at peak efficiency? Which were underperforming? - Was material usage aligned with production output, or were machines consuming resources inefficiently? - Without granular machine-level data, optimizing the entire facility to maximum capacity was guesswork. **Downtime: The Recurring Mystery** - Machines stopped for various reasons: mechanical failures, material jams, operator errors, scheduled maintenance. - Each downtime event represented lost production, but without systematic tracking, patterns remained invisible. - Were certain machine types more failure-prone? Were specific issues recurring preventably? **Material Consumption: The Hidden Variable** - Total material usage could be tracked at the facility level, but connecting consumption to specific machine behavior required inference, not instrumentation. - Was excessive material usage due to operator technique, machine calibration, or process inefficiency? The question wasn't whether Ranpak could run their facility effectively, they were already doing that. The question was: **Could they achieve systematic, data-driven optimization that could be replicated everywhere?** ## The Solution: Unified Machine Intelligence Through Dual-Product Deployment Ranpak deployed both **SenseAi** and **BeamTracker** in a tightly integrated configuration, creating a unified intelligence layer across the entire facility. This wasn't just monitoring. It was building a complete operational nervous system for every machine on the floor. ### SenseAi: The Vibration Intelligence Engine SenseAi transformed Ranpak's approach to understanding machine behavior and material consumption: **Vibration Analytics for Operational Insight** - Advanced sensor arrays capture vibration signatures from each machine - Continuous monitoring of machine operating states and behavior patterns - Foundation for future predictive health monitoring capabilities **Feed Rate Analysis for Material Optimization** - Real-time tracking of material consumption through vibration-based feed rate monitoring - Correlation between machine operating states and material usage patterns - Identification of machines consuming excessive material due to calibration drift or mechanical issues **Downtime Root Cause Intelligence** - Every stoppage captured with precise duration and contextual machine state data - Categorization of failures by type: mechanical, material-related, operator intervention, quality hold - Pattern analysis across machine types to identify systematic issues vs. isolated incidents ### BeamTracker: The Production Accountability System BeamTracker brought precision tracking to production output across the facility: **High-Accuracy Production Monitoring** - Real-time counts per machine, per shift, per day - Production velocity tracking to identify underperforming equipment - Cumulative output trends over time to validate improvement initiatives **Utilization Optimization Through Transparency** - Complete visibility into which machines are running, idle, or in maintenance states - Identification of capacity bottlenecks and underutilized assets - Data-driven rebalancing of workloads to maximize facility throughput **Goal Attainment Through Balanced Performance** - Facility-wide production targets decomposed to machine-level expectations - Real-time variance analysis: which machines are exceeding targets, which are falling behind - Immediate visibility when aggregated performance trends toward shortfall ### The Power of Integration: Two Systems, One Intelligence Layer The breakthrough wasn't deploying two products. It was the **synergy between them**. - **SenseAi** explains *why* a machine is underperforming (vibration anomaly, excessive material consumption, recurring failure pattern) - **BeamTracker** quantifies *how much* that underperformance costs in lost production and identifies which machines need optimization first Together, they create a closed-loop optimization system: 1. BeamTracker identifies a machine running below capacity 2. SenseAi diagnoses the root cause through vibration and feed rate analysis 3. Maintenance or calibration intervention targets the specific issue 4. BeamTracker validates that the fix restored optimal performance 5. Both systems track whether the issue recurs ## Business Outcomes: From Reactive Management to Systematic Excellence The pilot deployment delivered three transformational capabilities that became the foundation for global scalability. ### 1. Complete Machine Utilization Visibility For the first time, Ranpak had granular, real-time data on every machine in the facility. **Before IoTFlows:** - Aggregate facility output was tracked, but machine-level performance was inferred from shift reports - Utilization assumptions were based on planned uptime, not instrumented reality - Identifying which machines needed optimization required manual observation and anecdotal feedback **After IoTFlows:** - Every machine's uptime, downtime, production output, and material consumption tracked continuously - Immediate identification of underperforming equipment with quantified impact on facility capacity - Data-driven path to balance workloads and optimize all machines to maximum sustainable utilization > **Success:** > **From Guessing to Knowing:** "Before, we'd plan production based on assumptions about machine capacity. Now we know exactly what each machine is capable of and where the gaps are. That visibility is the foundation for systematic optimization—you can't improve what you can't measure." > > **Chiran JBR, Operations Manager, Ranpak** ### 2. Systematic Downtime Tracking and Root Cause Analysis Downtime shifted from an unavoidable disruption to a measurable problem with identifiable patterns. **The Foundation for Future Optimization:** **Comprehensive Capture** - SenseAi logs every stoppage with duration, machine ID, and contextual state data - Operators categorize events: mechanical failure, material jam, quality issue, scheduled maintenance - No downtime event goes unrecorded or unexplained **Pattern Recognition Across Machine Types** - Aggregate downtime by machine type: Do certain models fail more frequently? - Identify recurring failure modes: Are the same issues happening repeatedly across different machines? - Quantify cumulative impact: Which failure categories cost the most production time? **Data-Driven Maintenance Planning** - Historical failure data enables targeted maintenance schedules - Identification of high-impact failure patterns guides resource allocation - Track whether maintenance interventions reduce failure frequency and duration **The Result: From Reactive Fixes to Systematic Improvement** This comprehensive downtime tracking creates the foundation for moving beyond reactive maintenance—understanding which failures occur most frequently and implementing targeted solutions to reduce their recurrence. - **Downtime Pattern Analysis in Action** — **Recurring Issue Identified:** - Multiple machines of the same model experiencing material feed jams - Pattern analysis reveals these jams account for significant cumulative downtime - Vibration data collected during normal operation vs. jam events **Data-Driven Response:** - Focused maintenance attention on machines with highest jam frequency - Scheduled inspections during planned downtime rather than reactive emergency stops - Documentation of failure patterns to guide future predictive strategies **Measured Impact:** - Systematic tracking enables prioritized maintenance scheduling - Shift from unplanned emergency stops to planned interventions - Foundation established for future predictive maintenance capabilities ### 3. Material Usage Optimization Through Feed Rate Intelligence Material consumption became a controllable variable, not an accepted cost. SenseAi's vibration-based feed rate analysis revealed insights previously hidden: - **Machine-specific consumption patterns:** Some machines were using 12-15% more material than others for identical output due to calibration drift - **Operator technique impact:** Feed rate variability correlated with different operator approaches, enabling targeted training - **Process efficiency opportunities:** Certain production configurations consumed more material without corresponding quality or speed benefits **The Optimization Loop:** 1. BeamTracker tracks production output per machine 2. SenseAi monitors material feed rates through vibration analytics 3. Ratio analysis identifies machines with inefficient material-to-output performance 4. Calibration adjustments or operator training targets specific inefficiencies 5. Continuous monitoring validates improvement and flags new deviations **Result:** Data-driven path to minimize material waste while maintaining or improving production quality and speed. ## The Blueprint: What Makes This Scalable Globally The pilot wasn't just successful , it was **replicable**. Ranpak now has a proven deployment model for rolling out IoTFlows across all facilities worldwide: ### Standardized Instrumentation - Defined sensor placement and configuration per machine type - Calibrated vibration analysis baselines for normal operation - Consistent downtime categorization taxonomy across facilities ### Proven ROI Metrics - Quantified value from utilization optimization - Measured downtime reduction through systematic tracking and pattern analysis - Documented material usage efficiency gains ### Repeatable Implementation Process - Installation playbook tested and refined at pilot facility - Training curriculum for operators and maintenance teams - Integration with existing production management systems validated **Phase 2 is already mapped:** Deploy to additional Ranpak manufacturing facilities using the exact blueprint proven at the pilot site. ## Beyond Internal Operations: The New Customer Value Proposition Here's where the vision gets transformative. Ranpak doesn't just manufacture packaging materials. They deploy thousands of machines in customer facilities worldwide: food distributors, e-commerce fulfillment centers, manufacturers who need protective packaging on-demand. Currently, those customer-deployed machines are serviced **reactively**. A machine fails, the customer calls for support, a technician dispatches, repairs are made, production resumes. **What if Ranpak could shift from reactive service to predictive intervention?** ### The Vision: Global Fleet Health Monitoring Imagine deploying the same SenseAi and BeamTracker intelligence proven at Ranpak's own facility across their entire customer-deployed machine fleet: **Proactive Health Diagnostics Across Thousands of Machines** - Deploy continuous vibration monitoring to customer machines globally - Enable early detection of degradation patterns before failures occur - Future capability: Predictive alerts to Ranpak service teams: "Machine #4721 at Customer Site XYZ showing bearing wear signature—intervention recommended within 7 days" **From Break-Fix to Prevention** - Shift from reactive emergency calls to scheduled maintenance windows - Enable proactive parts shipment based on usage patterns and failure history - Prevent catastrophic failures that cause extended customer downtime **Guaranteed Maximum Uptime as a Service** - New value proposition: Machines aren't just sold—they're continuously monitored and maintained for peak performance - Transform customer SLA from "we'll fix it when it breaks" to "we monitor it continuously and intervene proactively" - Market differentiation: Ranpak machines come with intelligent fleet management, not just warranty support **Data-Driven Customer Success** - Aggregate performance analytics across customer base - Benchmarking: "Your facility's machines are operating at 94% of optimal efficiency, here's how to close the gap" - Continuous improvement recommendations based on global fleet intelligence ### The Business Model Transformation This isn't just operational excellence. It's a **strategic business model evolution**: - **From product sales to service relationships:** Machines become the platform for ongoing value delivery - **From reactive support to predictive service:** Reduce emergency dispatch costs while increasing customer satisfaction - **From individual transactions to fleet optimization:** Serve customers with the same intelligence Ranpak uses internally The pilot facility proved the technology works. The global deployment will prove the operational model scales. The customer fleet rollout will prove the business model transforms. ## Why This Matters: The Difference Between Monitoring and Intelligence Many manufacturers deploy sensors and call it "smart manufacturing." They track production. They log downtime. They generate reports. Ranpak built something fundamentally different: **operational intelligence through unified machine learning**. **Monitoring tells you what happened.** Intelligence tells you why it happened, identifies patterns that indicate when it might happen again, and guides you to prevent it. **Monitoring counts production.** Intelligence optimizes utilization, balances workloads, and identifies capacity bottlenecks. **Monitoring logs downtime.** Intelligence categorizes root causes, identifies patterns, and enables systematic elimination. **Monitoring is descriptive.** Intelligence is analytical and prescriptive. The integration of SenseAi and BeamTracker created more than visibility, it created a **closed-loop optimization engine** that continuously drives performance improvement. ## Looking Ahead: The Roadmap from Pilot to Global Standard Ranpak's journey is unfolding in three strategic phases: ### Phase 1: Pilot Success: Complete - Single-facility deployment - Validation of technology, integration, and ROI - Development of replicable deployment blueprint - **Outcome:** Proof of concept becomes operational standard ### Phase 2: Global Manufacturing Rollout: In Progress - Deployment across all Ranpak factories worldwide - Standardization of operational intelligence across facilities - Cross-facility benchmarking and best practice sharing - **Target Outcome:** Operational excellence as a competitive advantage ### Phase 3: Customer Fleet Intelligence: Strategic Vision - Deployment to thousands of customer-deployed machines - Proactive health monitoring leveraging patterns learned from internal operations - Predictive maintenance capabilities to prevent failures before they impact customers - Guaranteed maximum uptime as a service offering - **Target Outcome:** Business model transformation from product sales to intelligent service delivery Each phase builds on the previous one. The pilot proved the foundation. Global deployment scales the capability. Customer fleet deployment transforms the business. ## The Competitive Advantage: When Operations Become Strategy Most manufacturers view operational improvements as cost reduction initiatives. Ranpak recognized something deeper: **operational intelligence becomes strategic differentiation**. When you can: - Optimize every machine to maximum sustainable utilization - Identify failure patterns and implement targeted solutions to reduce recurrence - Build the foundation to monitor and maintain thousands of customer machines proactively - Create performance visibility that competitors lack You're not just running a better factory. You're **competing on a different level entirely.** The pilot facility didn't just prove ROI on a technology investment. It validated a vision for how manufacturing excellence creates customer value that's impossible to replicate without the same foundational intelligence. ## From Proof of Concept to Global Blueprint It's not often that a single facility deployment becomes the template for worldwide transformation. But Ranpak didn't implement IoTFlows to solve a local problem. They implemented it to **prove a global solution**. The data is definitive. The blueprint is ready. The vision is clear. **What started as one facility's optimization journey is becoming the operational standard for every Ranpak factory worldwide, and the foundation for an entirely new way to serve customers.** Complete machine visibility. Systematic downtime analysis. The foundation for predictive maintenance and proactive fleet monitoring. This is manufacturing excellence that scales from one machine to thousands. From one facility to every facility. From internal operations to customer success. **The pilot proved it works. Now the real transformation begins.** See how it works on [predictive maintenance](https://www.iotflows.com/solutions/predictive-maintenance). --- # RNPSA Halves Maintenance Response Time Source: https://www.iotflows.com/customers/rnpsa/ How RNPSA's continuous vibration monitoring and Maintain integration eliminated silent tool crashes, collapsed silos between operations and maintenance, and created a forensic view into every machine incident. ## The Hidden Problem RNPSA operates a fleet of critical precision machines where even minor issues cascade into major problems. But here's what made their situation precarious: **they couldn't see the problems happening.** When an operator inadvertently inputs the wrong parameters, a tool can crash into a part at high speed, a catastrophic event that should never go undetected. Yet without continuous monitoring, RNPSA had a blind spot: if no one was watching the machine, how would they know it happened? The damage would only be discovered when the shift changed hands or during routine inspection. Beyond operator errors, countless other anomalies could occur: - **Silent tool crashes** - imperceptible at first but destroying tool lifespan and part quality - **Abnormal vibration patterns** - early signals of bearing wear, alignment issues, or mechanical stress - **Undiagnosed downtime causes** - operators restarting machines without documenting what went wrong - **Isolated departments** - operations and maintenance working from incomplete information with fragmented communication ## The Transformation: Three Breakthrough Capabilities RNPSA deployed IoTFlows with three integrated capabilities that fundamentally changed how they manage critical machines. ### 1. Continuous Vibration Monitoring: The Machine's Black Box RNPSA installed vibration sensors on their critical machines, continuous listeners to every movement, every anomaly, every potential problem. The result: **a forensic record of every incident.** When an operator accidentally sets wrong inputs and crashes a tool, the vibration data captures the exact moment of impact. RNPSA can now: - **Rewind to the incident** - pull historical vibration data from any time period - **Identify the machine** - know with certainty which of their critical machines was affected - **Pinpoint the exact time** - down to the second when the crash occurred - **Quantify the damage** - assess severity from the vibration signature itself - **Find the operator** - correlate timing to shift schedules to identify who was running the machine > **Success:** > Rather than discovering a tool crash during a routine inspection ("When did this happen? Who was running it? How bad is it?"), RNPSA now has a complete digital forensic record. This transforms operator accountability and accelerates root cause analysis. ### 2. Data-Driven Performance Intelligence Beyond incident detection, RNPSA uses continuous vibration and operational data to systematically improve machine performance. By combining downtime classifications with performance metrics, they've built a **machine performance playbook** that answers critical questions: - **Which machines are running optimally?** - baseline vibration signatures for healthy operation - **Where are the weak points?** - machines showing early stress signals before failure - **What drives efficiency?** - correlating operator techniques with vibration patterns and output - **Which maintenance interventions worked?** - measuring before/after vibration signatures to validate repairs This data-driven approach replaced guesswork with evidence, allowing RNPSA to make targeted improvements rather than generic interventions. ### 3. Maintain: Collapsing Silos, Accelerating Response But detection and analysis mean nothing without action. RNPSA's real innovation came through integrating **Maintain, a bridge between what operators see and what maintenance does.** When downtime is categorized, operators don't just log the event, they **immediately create a work order** directly within the same system. Need a tool replaced? Click "Create Work Order." Machine needs realignment? Click "Create Work Order." Any task required? One click. The impact was profound: - **Maintenance gets real-time intelligence** - not a handwritten note left on the supervisor's desk - **Context travels with the request** - vibration data, historical patterns, operator observations all attached - **Priority is automatic** - critical vibration anomalies auto-escalate work orders - **Communication collapses** - operations and maintenance speak the same language, see the same data - **Accountability increases** - every action is logged, tied to a specific machine and time - **Response time dropped 50%** - maintenance no longer waiting for shift handoffs or email chains > **Info:** > **The Department Bridge:** Before Maintain, an operator noticed a problem, told the shift supervisor, who wrote a note, which the next shift supervisor read, who called maintenance. Now: operator logs downtime and creates work order in one action. Maintenance sees it immediately with all contextual data attached. ![Two panels in sample data. On the left, the Event Alerts list for CNC Lathe 3 under Last 15 min: an Abnormal Shock Detection row with a waveform icon and a red 164 G pill, 4m ago, and a Machine Down row, 3m ago. On the right, the Classify Downtime panel for the same stop with the category Tool crash selected, the note Wrong offset entered, tool broke on part, and the Create Maintenance Workorder section open with the title Tool crash prefilled, the machine CNC Lathe 3 and a Submit Request button.](/images/customers/rnpsa/rnpsa-crash-work-order.webp) *A simplified view of an incident like RNPSA's, in sample data: the crash is on record with its severity, and the operator who classifies the stop opens the work order in the same step.* ## The Results: From Reactive to Intelligent Six months after deployment across critical machines, RNPSA achieved a transformation in how they operate: - **Operational Excellence Realized** — **Incident Visibility: 100%** - Every tool crash, every abnormal vibration, every operator error now leaves a digital record - Historical data accessible for investigation and learning - No more "I wonder what happened" moments **Maintenance Efficiency: 50% Improvement** - Work orders created in real-time, not discovered later - Maintenance responds with complete context, not guesses - Communication between departments streamlined and accelerated **Performance Optimization** - Data-driven decisions on machine adjustments replacing operator intuition - Early warning signals allowing preventive action before failure - Continuous improvement culture powered by vibration intelligence **Cross-Department Collaboration** - Operations and maintenance aligned on real-time data - Shared visibility into machine health eliminating blame and finger-pointing - Operators empowered with tools to flag issues and request fixes immediately > **Success:** > "Continuous vibration monitoring gave us eyes we never had before. We can see tool crashes that would have been invisible, identify the exact moment and severity, and pull historical data to understand what went wrong. Add in Maintain, and suddenly operations and maintenance aren't working in silos, we're collaborating on the same data in real-time. That's transformed how we manage these critical machines." > > **Miguel Silva, Systems Engineer, RNPSA** ## Why Vibration Monitoring Changes Everything Most manufacturers track production output and obvious downtime. They miss the subtler signals, the barely-perceptible vibrations that indicate a machine is distressed. RNPSA realized that **vibration is a machine's language.** Every abnormal vibration tells a story: - Bearing degradation - Alignment drift - Impact events (like tool crashes) - Spindle stress By listening continuously to this language, RNPSA doesn't just react to failures, they **predict, prevent, and learn from them.** ## The Integration Multiplier Vibration monitoring alone is powerful. Maintain integration multiplies that power by creating a continuous improvement cycle: 1. **Vibration Detection.** Sensors detect abnormal vibrations, tool crashes, or mechanical anomalies in real-time. 2. **Operator Observes.** The operator or supervisor receives an alert and observes the machine condition and circumstances. 3. **Downtime Classification.** The operator classifies what caused the downtime—tool failure, operator error, material issue, or equipment problem. 4. **Work Order Creation.** Based on the classification, a work order is immediately generated and routed to the maintenance team with full context. 5. **Maintenance Action.** Maintenance responds with complete information—vibration data, downtime classification, and historical patterns—enabling targeted fixes. 6. **Historical Record.** The entire incident—detection, classification, action taken, and results—is recorded for future reference. 7. **Future Prevention.** Historical patterns inform preventive strategies, allowing RNPSA to anticipate and prevent similar issues before they occur. This isn't a linear process anymore. It's a closed loop where every incident generates intelligence, and that intelligence prevents the next incident. ## Looking Forward: Factory-Wide Orchestration RNPSA's vision extends beyond critical machines. They're implementing IoTFlows' Production Scheduler to coordinate maintenance windows with production schedules, deploying Predictive Health Models to forecast component failures weeks in advance, and rolling out Maintain Optimization to automatically assign maintenance tasks based on skill and availability. The foundation is built: continuous intelligence from vibration monitoring, immediate cross-department collaboration through Maintain, and data-driven decision making from downtime classification. The next phase transforms these insights into factory-wide orchestration—where every department moves in synchronized precision. See how it works on [Maintain](https://www.iotflows.com/platform/maintain) and [predictive maintenance](https://www.iotflows.com/solutions/predictive-maintenance). --- # Sorinex Raises Efficiency 50% Source: https://www.iotflows.com/customers/sorinex-exercise-equipment/ How Sorinex achieved 50% efficiency gains and 60% faster issue resolution with real-time machine visibility and downtime tracking. ## The Challenge Sorinex, a world-class manufacturer of exercise equipment serving professional athletes, military units, and collegiate programs, faced critical operational challenges. Their manufacturing facility operated with limited real-time visibility into machine performance, making it difficult to identify why equipment underperformed or when unexpected downtime would occur. Key challenges included: - **Blind spots in equipment performance** with no real-time tracking of critical production machines - **Unclear downtime causes** leading to delayed problem resolution and production inefficiencies - **No centralized visibility** into operational data across multiple manufacturing lines - **Reactive troubleshooting** that consumed hours to identify root causes of inefficiencies - **Production delays** due to inability to predict or quickly resolve equipment issues ## The Solution Sorinex implemented IoTFlows to gain complete real-time visibility into their manufacturing operations. The solution was deployed in less than a week, allowing the team to immediately start monitoring critical machines and identifying operational inefficiencies. ### Phase 1: Rapid Deployment Installed SenseAi sensors across critical production equipment in under 5 days, establishing immediate real-time data collection. ### Phase 2: Real-Time Visibility Dashboard Created centralized dashboards displaying live machine performance metrics, enabling instant identification of equipment status and performance anomalies. ### Phase 3: Downtime Tracking & Root Cause Analysis Implemented automated downtime categorization and root cause analysis tools to quickly identify why machines were underperforming or offline. ### Phase 4: Performance Optimization Leveraged real-time data insights to identify inefficiencies, optimize production workflows, and improve critical machine efficiency by 50%. ![Downtimes by Category for a plant's critical machines over one month, in sample data. Six bars in descending order: Waiting on material 31.4 hours, Changeover 22.6, Mechanical issue 15.8, Program and setup 11.2, Quality check 6.5 and Operator break 4.1, 91.6 hours in all, with a cumulative line reaching 59% after the first two bars and 76% after three.](/images/customers/sorinex/sorinex-downtime-pareto.webp) *A simplified view of a first month like Sorinex's, in sample data: once every stop has a cause, three categories account for three quarters of the downtime.* ## The Results Within the first month of implementation, Sorinex achieved significant operational improvements: - **Key Performance Improvements** — - **50% increase** in efficiency on critical production machines - **Started tracking and monitoring** critical equipment in less than 1 week - **60% faster** issue identification and resolution time - **87% improvement** in root cause visibility for operational inefficiencies - **Real-time downtime categorization** reducing troubleshooting time from hours to minutes - **Immediate actionable insights** into machine performance drivers > **Success:** > "The speed of implementation was remarkable. We went from limited visibility to complete operational transparency in less than a week. We're now identifying inefficiencies we didn't even know existed. IoTFlows has fundamentally changed how we approach manufacturing optimization." > > **Kyle Simpson, Operations Manager, Sorinex** ## Implementation Highlights ### Real-Time Equipment Visibility The platform provides instant visibility into all critical machines with live performance metrics, machine status indicators, and performance dashboards. Customizable alerts notify teams immediately when equipment performance drops or anomalies are detected. ### Downtime Tracking & Root Cause Analysis Automated systems categorize downtime events and identify root causes—whether from maintenance issues, operator actions, material problems, or equipment failures. This visibility transformed troubleshooting from hours of investigation into minutes of identification. ### Operational Inefficiency Detection Advanced analytics highlight subtle performance issues and inefficiencies that were previously hidden. The team can now see exactly what's driving production delays and optimization opportunities, leading to the 50% efficiency gain on critical machines. ## Looking Forward Building on this success, Sorinex is expanding IoTFlows to additional production lines and exploring advanced predictive analytics to further optimize manufacturing processes. The foundation of real-time visibility has proven transformative for operational decision-making. See how it works on [retrofit machine monitoring](https://www.iotflows.com/solutions/retrofit-machine-monitoring). --- # Stanley Black & Decker Traces Every Weld Source: https://www.iotflows.com/customers/stanley-black-decker/ How Stanley Black & Decker used the IoTFlows edge device to pull every welding data point from the robotic welding machines on a major automotive customer's production lines, so its analytics team could score every weld and flag each welding head for maintenance before quality drops. Stanley Black & Decker used the IoTFlows edge device to pull every welding data point from the robotic welding machines on a major automotive customer's production lines: Tucker automated stud-welding systems, the line Stanley Engineered Fastening builds for car bodies. Its advanced analytics team scores the quality of every weld that goes into a car, and the customer sees how its machines are performing and which welding head needs maintenance before quality slips. ![A close-up of a Tucker TH519 stud-welding head on a robot, black with the Tucker name down its side, its stud feed and shielding nozzle pointing down, against a dark background.](/images/customers/stanley-black-decker/sbd-tucker-weld-head.webp) *A Tucker stud-welding head on a robot. Image: Stanley Engineered Fastening.* ## The Challenge Every car body carries thousands of welds, and every one of them has to meet the automaker's quality standard. On the production lines of one of Stanley Black & Decker's major automotive customers, many of those welds are made by robots carrying Tucker stud-welding heads, line after line. Tucker is Stanley Engineered Fastening's line of automated stud-welding systems for body-in-white: controllers, feeders and weld heads that join studs, brackets and grounding points to the car body. ![A Tucker TH510 stud-welding head mounted on the wrist of an orange industrial robot, its cable package curving over the arm.](/images/customers/stanley-black-decker/sbd-tucker-head-on-robot.webp) ![A Tucker stud-welding controller: a grey cabinet on casters with a touchscreen, warning labels and the Tucker name in red.](/images/customers/stanley-black-decker/sbd-tucker-controller.webp) ![Four Tucker weld studs in bright steel: a threaded stud, a flanged stud with a hex nut, a capped stud and a short ribbed stud.](/images/customers/stanley-black-decker/sbd-tucker-weld-studs.webp) The project, led by Dr. Amir Kashani, Director of AI at Stanley Black & Decker, had three goals: - **Every weld, not a sample.** The quality of a car depends on all of its welds, so the analysis had to see every one of them. - **Every data point behind each weld.** The robotic welders record far more than whether a weld happened. The analytics team needed all of it. - **Maintenance before quality slips.** A welding head wears gradually. The customer needed to see that wear coming, and service the head before the welds it makes fall below standard. None of that data was reaching an analytics team in a form it could use. ## The Solution IoTFlows connected the welding lines as a [custom integration](https://www.iotflows.com/platform/custom-integrations/), with the IoTFlows edge device on the floor and the analysis delivered back to the customer. ### The IoTFlows edge device on every welding machine The IoTFlows edge device pulls data straight from the robotic welding machines on the customer's production lines: every welding data point they record, for every weld. ### Every weld to the analytics team IoTFlows streams the data and hands it to Stanley Black & Decker's advanced analytics team, who run their own analysis on it to determine the performance of every single weld that went into a car, against the quality standard the automaker needs to meet and exceed. ### Results back to the customer The results are sent back and presented to the customer, so it sees how each machine is performing and when a welding head looks like it needs maintenance, before weld quality degrades. ![A diagram left to right. Tucker stud-welding heads on every robot on the line feed the IoTFlows edge device, which pulls every weld data point. The edge device feeds IoTFlows, which streams every weld, and the analytics team, which scores every weld. The results flow on to the customer's view: machine performance and the heads due for service.](/images/customers/stanley-black-decker/sbd-flow-v2.webp) *How the weld data moves: from the welding heads through the IoTFlows edge device to the analytics team, and back to the customer.* ### What one weld looks like A stud weld lasts a few dozen milliseconds. The head lifts the stud on a low pilot arc, the main arc melts the stud's tip and the spot on the car body, and the head plunges the stud into the melt. The welders record that cycle for every stud, and the IoTFlows edge device collects all of it. ![A card headed One stud weld, Cell 2, Head 3, marked In tolerance. A chart over 60 milliseconds shows the weld current in blue: a low pilot arc, then a main arc at about 1,050 amps for 42 milliseconds, then off at the plunge. The stud position in dashed amber lifts 1.5 millimeters, holds through the main arc, then plunges below the surface. A list beside it reads weld current 1,050 A, arc voltage 24.6 V, weld time 42 ms, lift 1.5 mm, penetration 0.9 mm, energy 1.08 kJ.](/images/customers/stanley-black-decker/sbd-stud-weld-v2.webp) *A simplified view with sample data: the current and stud position through one stud weld, and the values recorded for it.* ### A welding head, before it drifts Because every weld is scored, the quality of each welding head becomes a trend rather than a surprise. When a head's welds start drifting toward the quality limit, it is flagged for maintenance while its welds still meet the standard. ![A chart headed Cell 2, Head 3, weld quality, marked Maintenance due. Over four weeks the quality line holds steady, then drifts down toward a dashed red quality limit in week four. An amber point on the line reads Flagged for maintenance, before the line reaches the limit. Three tiles below read Welds captured: every one; Data per weld: every point; Head 3: service now.](/images/customers/stanley-black-decker/sbd-weld-head-v2.webp) *A simplified view with sample data: one welding head's weld quality drifting toward the limit, and flagged for maintenance before it gets there.* ## The Results - **Every Weld, Accounted For** — - **100% traceability**: every weld captured from the robotic welding machines on the customer's production lines - **Every welding data point** pulled by the IoTFlows edge device, not a sample - **The quality of every weld** that goes into a car, scored by Stanley Black & Decker's analytics team - **Maintenance per welding head**, flagged before weld quality degrades - **A live view for the customer** of how its welding machines are performing For an automaker, a weld that falls below standard is a quality problem that can travel a long way down the line. Seeing every weld, and every head's trend, turns it into a maintenance task scheduled in time. > **Success:** > "IoTFlows is one of the best platforms I have ever worked with." > > **[Dr. Amir Kashani](https://www.linkedin.com/in/akashani/), Director of AI, Stanley Black & Decker** ## The Features Behind It - **The IoTFlows edge device** for PLC, controller, robot and sensor data over any protocol, with drivers written when one is missing. See [Custom integrations](https://www.iotflows.com/platform/custom-integrations/). - **Integrations** to hand the data to the systems and teams that need it. See [Integrations](https://www.iotflows.com/platform/integrations/). - **Alerts** to the people who act on them. See [Overview: alerts and integrations](/docs/alerts/overview/). *Cover and product images: Stanley Engineered Fastening, Tucker stud welding.* --- # Storm Power Doubles Machine Utilization Source: https://www.iotflows.com/customers/storm-power-components/ How Storm Power Components in Decatur, Tennessee, doubled machine utilization with SenseAi on its CNC machines, lasers and presses, took chemical bath timing errors to zero with BeamTracker, and ties operator bonuses to measured performance. Storm Power Components runs CNC machines, lasers, presses, polishing machines and chemical baths in Decatur, Tennessee. With SenseAi on its machines and BeamTracker on its baths, it doubled machine utilization, took bath timing errors to zero and now bases operator bonuses on measured performance. ## The Challenge Storm Power Components was scaling production to meet growing demand on top of manual tracking and operator memory. Nobody could see what the factory was doing. - **No machine visibility.** Team leaders had no way to know which CNC machines, lasers or presses were running, idle or in trouble without walking the floor. - **Problems found late.** Issues surfaced only after they had already cost production. - **Chemical baths run on memory.** Metal parts go through acid baths to remove rust, scale, oil and oxides, prepare the surface for paint and coating, and restore corrosion resistance. Each bath has its own duration, and parts sometimes stayed too long or not long enough because someone forgot to move them. - **Unknown machine performance.** There was no data on what each polishing machine produced, or how one compared with another. - **Scheduling by intuition.** Machines were scheduled on gut feel rather than on how busy they really were. - **No operator accountability.** Individual performance could not be measured, so high performers could not be rewarded. ## The Solution Storm Power Components put SenseAi on its machines and BeamTracker on its process steps. ### SenseAi on the CNC machines, lasers and presses SenseAi reads each machine's vibration and sound from the outside and decides running or stopped every second, with no PLC connection. See [SenseAi](https://www.iotflows.com/products/senseai/). ### Every machine's status, live Team leaders see which machines are running and which are down [on the Assets page](/docs/monitoring/assets-overview/), with each machine's uptime and utilization, instead of walking the floor to find out. A stop shows the moment it happens. ### Operator performance per machine Each operator's performance is tracked on the machine they run, [session by session](/docs/monitoring/operator-performance/). For the first time, Storm could measure individual productivity, and it now bases operator bonuses on it. ### BeamTracker on the chemical baths BeamTracker records the exact time each part enters and leaves each bath, the actual time it spent there, and the average cycle time per bath, so the process standard comes from data. See [BeamTracker](https://www.iotflows.com/products/beamtracker/). ### Polishing machines compared BeamTracker tracks the production rate of each polishing machine, so Storm can compare them, find the underperformers and spot a machine whose performance is degrading. ## The Results - **Machine Utilization Doubled** — - **2x machine utilization** since implementation - **Scheduling on real utilization data**, with the workload balanced across the equipment by how it actually performs - **Real-time visibility** across CNC machines, lasers, presses and process equipment, with issues caught the moment they happen - **Zero chemical bath timing errors**: no forgotten parts and no wrong bath durations, with entry and exit times recorded for every part - **Performance-based operator bonuses**, backed by each operator's measured performance per machine - **Growing demand met with the existing equipment** > **Success:** > "SenseAi gave us eyes we never had before. Our team leaders can instantly see which machines are running, which are down, and identify issues immediately instead of discovering them hours later. That visibility transformed our ability to manage production." > > **Ben Huskey, Quoting Manager, Storm Power Components** ## How Storm Works Now - **Team leaders** watch machine status through the shift and act on a stop as soon as it happens. - **Operators** move parts between baths on BeamTracker's timing instead of memory. - **Managers** review machine-level production rates to schedule the work and reward the top performers. - **Capacity planning** starts from each machine's measured utilization. ## The Features Behind It - **SenseAi** on the CNC machines, lasers and presses, deciding running or stopped from vibration and sound. See [SenseAi](https://www.iotflows.com/products/senseai/). - **BeamTracker** on the chemical baths and polishing machines, timing every part and tracking each machine's rate. See [Install and align BeamTracker](/docs/hardware/install-beamtracker/). - **The Assets page**, with every machine's live status, uptime and utilization. See [Read the fleet KPIs](/docs/monitoring/assets-overview/). - **Operator Performance**, pairing each operator with the machine they ran for their clocked sessions. See [Measure operator work sessions](/docs/monitoring/operator-performance/). See how it works on [machine utilization](https://www.iotflows.com/solutions/machine-utilization/). --- # What is machine monitoring, and what does it measure? Source: https://www.iotflows.com/blog/what-is-machine-monitoring/ Machine monitoring records each machine’s run state, part counts, cycle times, stops and health. See where each signal comes from and what a plant does with it. > Question: What does machine monitoring measure, and what does a plant get from it? ## Key takeaways - Machine monitoring records six things per machine: run state, part counts, cycle times, stops with reasons, unknown time and health. - Run state decided every second is the base record, because every uptime, downtime and cycle-time number is built from it. - Unknown time is the gap when a sensor reports nothing, and it belongs in neither uptime nor downtime. - A sensor, a controller connection and manual entry each deliver different signals, so most plants combine two of them. - A plant gets measured run time, the stop reasons that cost the most hours and a part count it can schedule against. Machine monitoring measures what each machine does through the shift: whether it is running or stopped, second by second, how many parts it makes, how long each cycle takes, how long and why it stops, when no data arrived, and how healthy it is. From those records a plant gets measured run time, the stop reasons that cost the most hours and a part count to schedule against. This guide is for plant managers and owners deciding what to monitor. It defines each signal, shows where each one comes from, and ends with what to monitor first. ## What is machine monitoring? > **Definition.** **Machine monitoring** is the automatic, timestamped recording of what each production machine does: when it runs and stops, how many parts it makes and how long each takes, why each stop happened, and how its vibration compares with its healthy baseline. The word that matters is *automatic*. A paper log written at the end of a shift records what someone remembers. A monitoring system records the moment a spindle stops turning, whether anyone noticed or not. Kentucky’s MEP center splits monitoring into two levels. Basic monitoring uses sensors that show whether machines are running, idle or stopped, and intermediate monitoring adds throughput and cycle counts.[1] The same page puts the cost at a few hundred to a few thousand dollars per machine, with installations usually done within a few days.[1] The first number most plants read is *uptime*: running time divided by running plus stopped time. The [glossary entry for uptime](/docs/get-started/glossary/#uptime) gives the exact calculation, and [what is machine utilization](/blog/what-is-machine-utilization/) covers how it differs from OEE. ## What signals does machine monitoring record? Machine monitoring records six signals per machine. Each answers one question, and each has a unit you can check against the floor. | Signal | Question it answers | Unit | |---|---|---| | Run state | Is it running right now? | Running or stopped, each second | | Part count | How many did it make? | Parts per hour or per shift | | Cycle time | How long does one part take? | Seconds or minutes per part | | Stops | How long, and why? | Minutes, with a reason code | | Unknown time | When was there no data? | Minutes with no report | | Health | Is the machine wearing? | Vibration against a baseline | Uptime and downtime are not separate signals. Both are sums of the run-state record inside your shifts. Figure: One hour on a CNC mill. The run-state bar shows 41 minutes running, a 9-minute tool change, a 2-minute short stop and 8 minutes unknown while the sensor was offline. Twenty part ticks fall one every 2 minutes, and vibration stays steady. *Five of the six records on one shared clock; cycle time is the gap between part ticks. Sample data.* ### Run state, every second *Run state* is whether the machine is running or stopped, decided from a physical signal such as vibration, sound, motor current or a passing part. Purdue’s MEP describes the approach: monitoring a machine’s amperage or its vibrational noise lets software determine the machine’s status and track production automatically.[2] Decide it often enough to see short stops. A system that checks a machine every 15 minutes can miss a 9-minute jam completely, while one that decides each second logs the stop at 10:41 and the restart at 10:43. [How sensors detect machine state](/blog/how-sensors-detect-machine-state/) explains the thresholds behind that decision. ### Part counts and cycle times A *part count* is the number of cycles the machine completed, multiplied by the parts each cycle makes. A press with a two-out die makes 2 parts per stroke, and a four-cavity mold makes 4 per shot. *Cycle time* comes from the same record: running time divided by the parts made. In the hour above, 41 running minutes and 20 parts give one part every 2.05 minutes, which rounds to the 2 minutes the ticks show. ### Stops, durations and reasons A *stop* is any stretch the run state reads stopped. The machine records its start, end and duration on its own. The reason still comes from a person, because a 14-minute stop looks identical in the signal whether the operator was changing a tool or waiting for material. Operators put a reason code on each stop, and automatic rules can tag routine ones such as short stops or the start of a shift. [Downtime reason codes](/blog/downtime-reason-codes/) shows how to build a list operators will use. ### Unknown time *Unknown time* is any interval when the monitoring device sent nothing, because it lost power or its network connection. It isn’t a machine state, so it counts as neither running nor stopped. For example, a sensor unplugged over a weekend produces 48 unknown hours, not 48 hours of downtime. The [unknown time definition](/docs/monitoring/metrics-reference/#unknown) shows how it is kept out of both terms. A lot of unknown time points to a power or Wi-Fi problem, not a production one. ### Machine health *Machine health* compares a machine’s vibration with its own healthy baseline, so wear shows as drift before it becomes a breakdown. A 2016 NIST paper used low-cost sensors to determine the operating condition of milling machines and to detect anomalies, and noted that older machines can be retrofitted with new sensors.[3] Health is optional for most machines. Add it where a breakdown stops a line or a repair takes days. ## How do you get data off a machine? You get data off a machine in one of three ways: an external sensor reads it from the outside, a controller connection reads what the machine’s PLC or CNC control already knows, or a person types it in. Each delivers a different set of signals. | | External sensor | Controller connection | Manual entry | |---|---|---|---| | Run state each second | Yes | Yes | No | | Part count | Yes | Where the control counts | Shift totals | | Cycle time | Yes | Yes | No | | Stop duration | Yes | Yes | Long stops only | | Stop reason | No | Alarm code only | Yes | | Unknown time | Yes | Yes | No | | Vibration health | Yes | No | No | | Program and alarms | No | Yes | No | Stop reasons come from operators in every setup. A controller alarm can suggest a reason but doesn’t replace one. An *external sensor* mounts on the machine and reads vibration, sound or a passing part. It works the same on a 1985 lathe and a new machining center, because it never touches the control. [Monitoring an old machine with no network port](/blog/monitor-old-machines-without-a-plc/) covers where to mount one. A *controller connection* reads the control over a protocol such as MTConnect or OPC UA. OPC UA, released in 2008, identifies each client and server with X.509 certificates and supports message signing and encryption.[4] Even so, a connection to a PLC or CNC control is a security concern for many plants, and IT usually reviews it first. [MTConnect, OPC UA and Modbus compared](/blog/machine-communication-protocols/) explains each protocol. *Manual entry* is a person writing down counts, stops and reasons. It is the only source of stop reasons and scrap causes, and the weakest source of times, because nobody logs a 2-minute jam. [Manufacturing data collection](/blog/manufacturing-data-collection/) works one shift through both ways. > **Which source fits your machines?** > > - **Choose an external sensor** for run state, counts, cycle times and health on every machine, of any brand or age, with no access to the control. > - **Add a controller connection** where you need alarm codes, program names or process values such as spindle load, and IT has approved it. > - **Keep manual entry** for what only a person knows: the reason for a stop, the cause of scrap and notes for the next shift. [Sensor-based vs PLC machine monitoring](/compare/sensor-based-vs-plc-machine-monitoring/) sets out what each approach reads, signal by signal, with its sources. ## What does a plant do with each number? A plant uses each monitoring number for one decision, made by one role. The table pairs them. | Number | Decision it drives | Who acts | |---|---|---| | Uptime by machine | Add a shift, or buy a machine | Plant manager | | Stop reasons by hours | Which loss to fix first | Supervisor | | Part count vs shift goal | Whether the shift is on pace | Operator | | Cycle time by part | Quotes and schedule run rates | Planner | | Unknown time | Which device or network to fix | Maintenance, IT | | Health trend | When to plan a repair | Maintenance | Uptime answers capacity questions before any money is spent. [Storm Power Components](/customers/storm-power-components/) doubled machine utilization across its CNC machines, lasers and presses, and now schedules on real utilization data. Stop reasons ranked by the hours they cost show where to start. Datwyler’s injection molding plant cut shift-changeover downtime in half and material-changeover downtime by 30% within six months, once every stop carried a reason, as the [Datwyler story](/customers/datwyler/) describes. Cycle times change what a machine is asked to do. A Michigan MEP client fitted 16 machines with real-time monitoring and cut cycle times from 23 to 19 seconds, with quicker response to problems.[5] ## One shift, read from its records Here is what the records say about one hypothetical shift on a Haas VF-2 machining center. Breaks are set as planned time, so the shift leaves 450 scheduled minutes. #### Worked example: One shift on a Haas VF-2 with 450 scheduled minutes - Run state: 315 minutes running, 105 minutes stopped, 30 minutes unknown while the Wi-Fi dropped. - Stops: waiting for material 45 minutes, tool changes 30, setup 20 and short stops 10, for 105 minutes. - Parts: 189 made, at an ideal cycle time of 1.5 minutes. Uptime is 315 ÷ (315 + 105) = 315 ÷ 420 = 75%. Checked the other way, the stopped share is 105 ÷ 420 = 25%, and 100% − 25% = 75%. Performance is 189 ÷ (315 ÷ 1.5) = 189 ÷ 210 = 90%. Checked the other way, the actual cycle is 315 ÷ 189 = 1.667 minutes, and 1.5 ÷ 1.667 = 90%. **Result:** Uptime 75%, performance 90%, top stop reason waiting for material (45 of 105 minutes) Figure: A 450-minute shift on a Haas VF-2: 315 minutes running, 105 stopped and 30 unknown. Leaving unknown time out gives 315 ÷ 420 = 75% uptime; counting it as stopped gives 315 ÷ 450 = 70%. *The same shift read two ways: counting unknown time as stopped costs the machine 5 points. Sample data.* > **Don’t count unknown time as downtime** > > Had the 30 unknown minutes been counted as stopped, uptime would read 315 ÷ 450 = 70%, and the machine would take the blame for a Wi-Fi drop. Fix the device or network instead, and keep the two numbers apart. The useful finding is the 45 minutes of waiting for material. That is a supply problem at the cell, not a machine problem, and no paper log would have timed it. ## Monitor machines with IoTFlows IoTFlows is a manufacturing intelligence platform that monitors machines with plug-and-play sensors or custom integrations to any PLC, robot or sensor, and turns the data into utilization, downtime, OEE, production scheduling and maintenance workflows. A SenseAi on each machine decides running or stopped every second on the device, counts parts from the machine’s own cycle and records every stop for an operator to classify in a tap. [Machine monitoring](/platform/machine-monitoring/) works the same on any brand and any age, with no PLC or controller access. The results read in [five views](/docs/monitoring/overview/#views): the Assets page for the live fleet, the machine page, Downtimes for where the stopped time went, the Advanced Report for a month or quarter, and Canvas for a floor plan with live status. ## What should you monitor first? Start with run state on the machines that limit output, and add signals only when a decision needs them. - **Start with run state and stops** when nobody can say how many hours each machine ran last week. Uptime and a ranked list of stop reasons come from the sensor alone, from the first shift. - **Add part counts and cycle times** once shifts are set and you want to know whether a running machine runs fast enough. Validate each count against ten parts counted by hand first. - **Add health** on the few machines where a breakdown stops a line, such as the one 5-axis machining center every job passes through. - **Add a controller connection** when a recurring question depends on what only the control knows, such as which alarm stopped the machine, and IT has reviewed it. - **You don’t need** every signal on every machine. A manual saw that runs 2 hours a shift needs run state, not health. Read one week of stops before changing anything. The largest block of stopped time nobody was logging is the first thing to fix. ## Questions ### Do I need a PLC connection for machine monitoring? No. A sensor on the outside of a machine records run state, part counts, cycle times, stop durations and vibration health with no access to the control. Connect the controller only where you need what it alone holds, such as alarm codes, the active program or a process value, and plan for IT to review that connection first. ### How is machine monitoring different from an MES? Machine monitoring records what each machine did: when it ran, what it made and why it stopped. An MES manages what the plant should make and how each order ran, with routings, work instructions and genealogy. Monitoring comes first when nobody knows how much the machines run, because every MES report depends on an accurate machine record. ### Is machine monitoring the same as condition monitoring? No. Condition monitoring tracks the health of a machine, through vibration, temperature or oil, to plan maintenance before a failure. Machine monitoring tracks production: run state, counts, cycle times and stops. One vibration sensor can feed both, since the same signal shows whether a spindle is turning and whether its vibration is drifting from its healthy baseline. ### How accurate is a sensor-based part count? Check it before you trust it. Run ten parts, count them by hand and compare with the system. A count that reads exactly double or half the real number is a quantity-per-cycle setting, such as a two-cavity mold set to one, and not a fault in the sensor. Fix the multiplier and validate again. ## Sources 1. [Enhance Your Existing Equipment with Machine Monitoring](https://louisville.edu/servicecenters/news/enhance-your-existing-equipment-machine-monitoring), University of Louisville Service Centers (Kentucky MEP), accessed Oct 27, 2026 2. [Is Legacy Equipment Slowing You Down?](https://mep.purdue.edu/news-folder/is-legacy-equipment-slowing-you-down/), Purdue Manufacturing Extension Partnership, accessed Oct 27, 2026 3. [Machine Condition Detection For Milling Operations Using Low Cost Ambient Sensors](https://www.nist.gov/node/1268861), National Institute of Standards and Technology, accessed Oct 27, 2026 4. [Unified Architecture](https://opcfoundation.org/about/opc-technologies/opc-ua/), OPC Foundation, accessed Oct 27, 2026 5. [M R Products, Inc: Technology Adoption Improves Data, Capacity & Quality](https://www.nist.gov/node/1741691), National Institute of Standards and Technology, Manufacturing Extension Partnership, accessed Oct 27, 2026 --- # What cycle time is and how to measure it per part Source: https://www.iotflows.com/blog/what-is-cycle-time/ Cycle time is how long one cycle really takes, timed at the machine. Learn which cycle to time, how to measure it per part and which figure to use for each job. > Question: How do I measure the real cycle time of a machine, not the programmed one? ## Key takeaways - Cycle time is the time one cycle takes as measured at the machine, not the time a program or setup sheet predicts. - State cycle time per cycle, then divide it by the parts each cycle makes to get the time per part. - Time 10 to 20 consecutive cycles from the same point to the same point, after the first parts off. - Report the median of the timed cycles, because one cycle with a stop inside it pulls the mean up. - Use the ideal cycle time for OEE performance, the measured median for quoting and logged run rates for scheduling. You measure a machine's real cycle time by timing the cycles it actually runs, from one cycle start to the next, over 10 to 20 consecutive cycles once the process has settled. Take the median of those times, not the mean, and divide by the parts each cycle makes to get the time per part. The programmed time is a prediction; the timed median is what the machine does. This guide is for engineers and leads who need one cycle-time number they can defend in a quote, a schedule and an OEE review. It works one molding press through by hand, two ways. ## What is cycle time? > **Definition.** **Cycle time** is the time one cycle of an operation takes, measured on the machine from a fixed point in one cycle to the same point in the next. One cycle can make several parts, so cycle time is stated per cycle and divided by the parts per cycle to give the time per part. The Lean Enterprise Institute puts the key condition plainly: cycle time is the time to produce a part or complete a process "as timed by actual measurement".[1] A number on a setup sheet, a CAM printout or a routing is an estimate until someone times it. The [glossary entry for cycle time](/docs/get-started/glossary/#cycle-time) separates the figure you enter from the one the machine reports. Total parts divided by total time is not a cycle time. It is a production rate for the whole period, with every stop and every slow start inside it. For example, a press that makes 3,600 parts in a 450-minute shift averages one part every 7.5 seconds, even though each part takes 6.5 seconds to mold. Two neighboring terms get mixed up with cycle time. *Takt time* is the pace customer demand requires, and *lead time* is how long an order takes from release to delivery. A machine can cycle faster than takt and still miss demand once stops and scrap are counted, so compare takt with planned time per good part, as the [flow KPIs](/blog/manufacturing-kpis/#flow) show. ## Machine, part and operator cycle time Three cycle times describe one station, and each answers a different question. | Cycle | What it measures | Example | |---|---|---| | Machine cycle time | One complete machine cycle | 7 min 30 s on a Haas VF-2 | | Part cycle time | Machine cycle ÷ parts per cycle | 3 min 45 s, 2 parts per cycle | | Operator cycle time | The operator's full work loop | 2 min 10 s to unload, deburr, load | Machine and operator cycle time follow the Lean Enterprise Institute's definitions. The numbers are a hypothetical fixture job. LEI defines *machine cycle time* as the time a machine requires to complete all of its operations on one piece, and *operator cycle time* as the time an operator takes to complete all the work elements at a station before repeating them, measured by direct observation.[1] Part cycle time is the figure quotes and costs use. *Parts per cycle* is the number of finished parts one machine cycle makes. A 4-cavity mold makes four parts per shot, and a two-station fixture on a mill makes two per cycle. Keep the cycle time per cycle and record the multiple separately, as the [quantity per cycle setting](/docs/production/cycle-times-and-filters/#qty) does. When a cavity is blocked off, parts per cycle drops to three and the cycle time stays the same. The operator cycle decides who sets the pace. When the operator works while the machine cuts, the station repeats at the slower of the two. On the VF-2 above, the 2 min 10 s loop fits inside the 7 min 30 s cycle, so the machine sets the pace. When the operator and machine take turns, add the two. ## Programmed, actual and ideal cycle time Three versions of the machine cycle time exist for any operation. Each has one job, and the trouble starts when one stands in for another. | Version | Where it comes from | Use it for | |---|---|---| | Programmed | CAM estimate, setpoints, setup sheet | A first estimate before the first run | | Actual | Cycles timed on the machine | Quotes, checks, setting the ideal | | Ideal | The best sustainable actual cycle | OEE performance and shift goals | The *programmed cycle time* is what the part program or the machine's setpoints predict. It leaves out time the machine adds. A CAM estimate skips acceleration, tool changes and probing, and a molder's setpoints skip mold movement and the take-out robot clearing the mold. The *actual cycle time* is what this guide measures. The *ideal cycle time* is a target you choose from the actuals on a good day, and [setting the ideal cycle time](/blog/ideal-cycle-time/) covers who owns it and what a wrong one does to OEE. You don't need the programmed time once the machine has run the job. Replace it with a timed figure after the first settled run. ## How do you measure the real cycle time? You measure it one of three ways: with a stopwatch, from the machine's control, or from a sensor on the machine. All three time the same interval when you set them up to, and they differ in how many cycles they see. | | Stopwatch | Machine control | Sensor on the machine | |---|---|---|---| | Cycles timed | 10 to 20 per study | Every cycle | Every cycle | | Works on any brand or age | Yes | No | Yes | | Includes load and unload | Yes, start to start | Depends on the timer | Yes, start to start | | Needs an IT review | No | Yes | No | A control timer that starts and stops on program events leaves out work done between programs. Default to a sensor when you want every cycle on every machine, whatever its age. A stopwatch study is enough for one quote or one check, and the control adds the program name where a plant has already connected it. ### With a stopwatch 1. **Pick a settled operation.** Choose a job past its first parts off, with the machine warm and the program or mold proven. 2. **Choose the start point.** Pick one visible event, such as door close on a mill or mold close on a press, and time from it to the same event in the next cycle. 3. **Time 10 to 20 consecutive cycles.** Write every time down, including the odd ones, and note what happened in any cycle that ran long. 4. **Take the median.** Sort the times and take the middle value. The [median section](#median) explains why it beats the mean. 5. **Divide by parts per cycle.** Divide the median by the parts one cycle makes to get the part cycle time. ### From the control or a sensor A CNC control or a molder's controller times its own cycles. MTConnect, the open standard many CNC controls report through, defines a process timer as the time from the beginning of production of a part on a piece of equipment until production of that part is complete.[4] A connection to the control is a security concern for many plants, and IT usually reviews it first. A vibration sensor on the outside of the machine times cycles from the machine's own signal. A *detection algorithm* decides where one cycle ends, and the right one depends on the machine type: a burst per part on a mill, an impact per stroke on a press, a steady trace on a molder. The [algorithm guide](/docs/production/choose-an-algorithm/#choose) matches each one to its machine. Cycle time and part count come from the same detected cycles, so [part counting methods](/blog/part-counting-methods/) apply here too. ## Traps that skew a measured cycle Most bad cycle times come from timing the right machine over the wrong interval. Check for these four before you trust a number. - **Averaging across stops.** Dividing a shift by its part count folds every stop into the cycle. Time cycles only while the machine runs, and leave a cycle with a stop inside it out of the average. - **Load and unload in one study and out of the next.** Timing cut to idle one day and door close to door close the next gives two numbers for one cycle. Time start to start on every machine and write the convention down. - **First-part-off cycles.** The first cycles after a setup or mold change run slow while the operator checks the part and the mold comes to temperature. Start timing once the process has settled. - **Mixed jobs in one window.** A window that spans a job change averages two operations. Time one operation at a time. > **Per cycle or per part?** > > A figure divided by parts per cycle before it goes into a system that also multiplies by parts per cycle comes out four times too small on a 4-cavity mold. Enter the cycle per cycle wherever the system has a separate parts-per-cycle field, and divide only when you need the time per part. ## Median or mean, and why the spread matters Use the median of the timed cycles as the machine's cycle time. NIST's statistics handbook explains why: extreme values in the tails distort the mean, while the median, based on ranks, is not distorted by them.[2] Cycle times are skewed in exactly this way. A cycle can run 15 seconds long when a part sticks, but it can't run 15 seconds short. Figure: Twenty timed shots on a 150-ton press plotted on a seconds axis: 19 sit between 25 and 27 s and one runs 41 s. The median is 26.0 s, the mean 26.75 s, and the programmed cycle 24 s sits left of every shot. *One stuck-part shot moves the mean 0.75 s and leaves the median at 26 s. Sample data.* The spread tells you as much as the middle value. NIST defines the *range* as the largest value minus the smallest, and warns that it depends on the two most extreme points; the *interquartile range* covers the middle half of the data instead.[3] Report both the median and the spread of the cycles. - **A tight spread** (a few percent of the cycle) means the machine sets the pace. The median is a safe number to quote from. - **A wide spread** means the operator or the material sets the pace. On an operator-loaded mill with cycles from 6 to 9 minutes, time more cycles and find out which work element varies before you quote. - **A spread that grows over days** points at the process. Tool wear lengthens cycles a few seconds at a time. ## Worked example: a 150-ton molding press For example, a 150-ton injection molding press runs a 4-cavity mold for a polypropylene cap. The setup sheet's setpoints add up to a 24-second cycle. Here is the real cycle, computed two ways. #### Worked example: Method 1: time 20 shots with a stopwatch - Twenty consecutive shots, timed mold close to mold close, after the first hour of the run: 26, 25, 26, 27, 26, 25, 26, 26, 27, 26, 25, 26, 41, 26, 27, 26, 25, 26, 26 and 27 seconds. - The 41-second shot had a stuck part pulled by hand. - Sorted, the 10th and 11th values are both 26 s, so the median is 26 s. - The mean of all 20 is 535 ÷ 20 = 26.75 s. Without the 41-second shot, it is 494 ÷ 19 = 26.0 s. **Result:** Cycle time = 26.0 s per shot, or 26.0 ÷ 4 = 6.5 s per part #### Worked example: Method 2: divide running time by shots - Planned production time is 450 minutes. The press ran 393 minutes, or 23,580 seconds, and stopped for 57. - The shot counter on the press screen read 900 shots for the shift, so 900 × 4 = 3,600 parts. - Running time ÷ shots is 23,580 ÷ 900 = 26.2 s. **Result:** Cycle time = 26.2 s per shot, or 6.55 s per part The two methods agree within 0.2 seconds a shot. The difference is short pauses, too brief to count as stops, that sit inside the running time and outside the timed shots. Figure: Bars for one shift on a 4-cavity press: programmed cycle 24.0 s, stopwatch median 26.0 s, running time ÷ shots 26.2 s, and shift time ÷ shots 30.0 s, which includes 57 minutes of stops. *Both measured methods land near 26 s; dividing the whole shift by shots reads 30 s. Sample data.* The wrong method reads 27,000 ÷ 900 = 30.0 seconds a shot, 15.4% longer than the press really cycles. That number belongs to availability, not to the cycle. The programmed 24 seconds is wrong in the other direction: a quote built on it prices every part 0.5 seconds too fast. ## Measure cycle times automatically IoTFlows puts a SenseAi on each machine. It reads vibration and sound from outside, with no PLC connection, and reports part counts and cycle times derived from the machine's cycle. The actual cycle time IoTFlows reports is the running time between counted parts, so stops stay out of it, as the [metrics reference](/docs/monitoring/metrics-reference/#cycle-time) defines. Each operation carries the detection algorithm for its machine type: Discrete Analysis on CNC mills, Discrete w/o Merge on presses, and Continuous Analysis on molders, which divides running time by the shot cycle you timed. Shift Production shows the ideal, goal and actual cycle side by side, and [production monitoring](/solutions/production-monitoring/) puts every count against the shift goal. Jesel, a valvetrain manufacturer, uses this to compare "actual measured cycle times against the times specified in the bills of material", as its [customer story](/customers/jesel/) describes. ## Which cycle time should you use? Use a different cycle time for each job, and never let one stand in for another. | Job | Cycle time to use | Why | |---|---|---| | Quoting a part | Measured median ÷ parts per cycle | What the machine does when it runs | | Scheduling a job | Logged run rate, losses included | Real jobs include stops and scrap | | OEE performance | Ideal cycle time | Measures speed loss against a target | | Setting the ideal | Median of a good shift | A pace the process sustains | | Daily review | Actual against ideal | Shows drift as it happens | | Before the first run | Programmed, marked as an estimate | Nothing else exists yet | > **Measured median or ideal?** > > Choose the measured median when the question is how long a part takes: quotes, costs and capacity checks. Choose the ideal when the question is how much speed was lost: OEE performance and shift goals. Measuring performance against the actual median reads close to 100% every shift and hides the losses OEE exists to find. A quote also needs the setup share per part. LEI's *effective machine cycle time* adds load and unload and the changeover spread over the batch to the machine cycle.[1] For schedules, [plan on real run rates](/blog/production-scheduling-on-real-run-rates/), which fold in the stops and scrap a quote leaves out. ## Questions ### Is cycle time the same as throughput? No. Throughput is parts made over a whole period, stops included. A molding press that makes 3,600 parts in a 450-minute shift has a throughput of one part every 7.5 seconds, while each 4-cavity shot takes 26 seconds, or 6.5 seconds a part. The gap between the two figures is the downtime and short pauses in the shift. ### Should cycle time include load and unload? Include load and unload when they happen on every cycle and the machine waits for them, as on an operator-loaded mill, by timing from one cycle start to the next. Leave changeovers out, because they happen between runs and belong to downtime. Write down which convention you use, so the next person times the same interval. ### How many cycles should I time? Time 10 to 20 consecutive cycles on a settled process. Fewer than 10 can land on an unusually good or bad stretch. Time more when the spread is wide, as on an operator-paced cell, and repeat the timing after any change to the program, the tooling or the material. ### Why does the control's cycle timer disagree with my stopwatch? The control's timer starts and stops on program events, so it can leave out door opening, part loading and anything else the operator does between programs. A stopwatch timed from one cycle start to the next includes them. Both figures are correct for their own interval, so pick the interval that matches your question. ## Sources 1. [Cycle Time, Lean Lexicon](https://www.lean.org/lexicon-terms/cycle-time/), Lean Enterprise Institute, accessed Oct 27, 2026 2. [1.3.5.1 Measures of Location, NIST/SEMATECH e-Handbook of Statistical Methods](https://www.itl.nist.gov/div898/handbook/eda/section3/eda351.htm), National Institute of Standards and Technology, accessed Oct 27, 2026 3. [1.3.5.6 Measures of Scale, NIST/SEMATECH e-Handbook of Statistical Methods](https://www.itl.nist.gov/div898/handbook/eda/section3/eda356.htm), National Institute of Standards and Technology, accessed Oct 27, 2026 4. [ProcessTimer.Process, MTConnect SysML Model V2.5](https://model.mtconnect.org/Version2.5/ObservationInformationModel/ObservationTypes/SampleTypes/ProcessTimerProcess), MTConnect Institute, accessed Oct 27, 2026 --- # How to monitor stamping presses, stroke by stroke Source: https://www.iotflows.com/blog/how-to-monitor-stamping-presses/ Track strokes, parts per stroke, stops, die and coil changes and scrap on any press. Compare a frame sensor, exit beam and press control on a 40 SPM shift. > Question: What should a plant track on a press, and how? ## Key takeaways - Track strokes, strokes per minute, parts per stroke, stops with reasons, die and coil changes, and scrap on every press. - A stroke count becomes a part count only after you multiply it by the parts the die makes per stroke. - Set the short-stop cutoff above the pauses that belong to the stroke rhythm and below the shortest coil change. - Log die changes and coil changes as separate reasons, because each one has its own fix and its own owner. - Compare counted strokes with run time × rated strokes per minute, and the gap is short stops and slow running. A plant should track six things on every stamping press: strokes, the stroke rate, the parts each stroke makes, stops long enough to act on, die and coil changes, and scrap. Capture strokes and run state with a vibration sensor on the press frame, count finished parts with a beam at the exit, and read the press control's counter where you need the die number or the last stop's reason. This guide is for plant managers and process engineers running mechanical presses of mixed ages. It works one hypothetical 200-ton press through a shift, computed two ways, so you can see what each number catches. ## What should you track on a press? > **Definition.** **Strokes per minute (SPM)** is the number of times a press ram completes its cycle, down through the die and back to the top, in one minute, the rate at which a press can make parts while it runs. A press makes its output one stroke at a time, so most of what you need follows from counting strokes and timing the gaps between them. The table lists the six numbers and the question each one answers. | Metric | Question it answers | Where it comes from | |---|---|---| | Strokes | How many hits did the press make? | Frame sensor or press control | | Strokes per minute | Is it running at the die's rate? | Strokes ÷ run minutes | | Parts per stroke | How many parts does one hit make? | The die, recorded per job | | Stops with reasons | Where did the stopped time go? | Data for length, people for reason | | Die and coil changes | How long do changeovers take? | Stops tagged with their own reason | | Scrap | How many parts can't ship? | Operators, with a reason | Strokes per minute differs widely from press to press. One press maker lists its 2,000 kN gap-frame crank press at 25 to 45 SPM with its longest stroke and 40 to 85 SPM with its shortest.[1] The same maker's 220-ton link-motion press for progressive dies runs 50 to 120 SPM, and its 660-ton model 30 to 70.[2] Record a rated SPM for each die, not for each press, because the die sets the speed. ## Strokes are not parts A stroke count becomes a part count only after you multiply it by the parts the die makes per stroke. *Parts per stroke* is that multiplier, and the glossary entry for [quantity per cycle](/docs/get-started/glossary/#quantity-per-cycle) defines the same setting for any machine. **Parts made** = Strokes × parts per stroke The die type decides the multiplier: - **Single-hit die:** one blank in, one part out, so the multiplier is 1. - **Progressive die:** the strip advances through several stations on its own, and each stroke finishes one or more parts at the last station.[3] A progressive die making one bracket per stroke is 1. A two-out die is 2. - **Transfer die:** independent dies at each station, with mechanical arms moving the part between them.[3] It finishes one part per stroke unless the last station drops two. A count that reads exactly double or half is a multiplier setting, or a press that rings twice per stroke, not a counter fault. For example, a two-out progressive die set to 1 reports exactly half the parts the bin holds. The guide to [part counting methods](/blog/part-counting-methods/) covers how each counting method turns a signal into a count. A stroke also isn't a good part. A misfeed stroke moves the ram and makes nothing usable, and the carrier strip of a progressive die is engineered scrap that never counts as a part. Scrap to track is parts that left the die and can't ship, logged with a reason. ## How do you capture strokes and parts? You capture strokes and parts in one of three places: on the frame, at the exit or in the press control. Each one sees something the others don't. Figure: A press with three capture points: a vibration sensor on the frame reads strokes and run state, a beam across the exit chute counts parts that left the die, and the press control holds a stroke counter, the die ID and the last stop reason. *Three places to read a press. The frame sensor works on any press, of any age.* **A vibration sensor on the frame** feels each stroke as a sharp impact, well above the level of an idling flywheel. It counts strokes and reads running or stopped from outside the press, with nothing wired into the control. Mount it on the frame near the ram, never on a guard, which rings on its own. **A beam at the exit** counts each part that breaks it on the way down the chute. It counts parts that cleared the die rather than strokes, so a misfeed stroke doesn't add one. It needs a chute where parts fall one at a time. **The press control** already counts. A die protection unit from one press-control maker keeps parts, batch and total-hits-on-a-tool counters, and detects improper part ejection, misfeeds and material buckling before die damage occurs.[5] Reading it gives you the die number and the reason the press last stopped. A connection to the control is a security concern for many plants, and IT usually reviews it first. | | Frame sensor | Exit beam | Press control | |---|---|---|---| | Works on any press age | Yes | Yes | No | | Counts strokes | Yes | No | Yes | | Counts parts that left the die | No | Yes | With part-ejection sensors | | Reads running or stopped | Yes | From gaps in the count | Yes | | Knows the die and last stop reason | No | No | Yes | | Needs a connection to the control | No | No | Yes, IT usually reviews it | A frame sensor and an exit beam both read the press from outside. Where a press already has a networked control, the control is a third option, not a replacement. > **Which capture method to start with** > > Default to a vibration sensor on the frame of every press, because it reads strokes and stops the same way on a 1987 flywheel press and a new one. Add a beam at the exit when misfeeds are common and you want the count to be parts that cleared the die. Read the control when a recurring question needs the die number or the stop reason it holds. You don't need control data to find out where a shift's hours went. The [sensor-based versus PLC comparison](/compare/sensor-based-vs-plc-machine-monitoring/) lays out what each approach sees on any machine, with its sources. ## Which method fits which press? The press's speed, its feed and how its slide moves decide which capture method fits. Use the table as a starting point for each press on the floor. | Press type | Stroke rate | What to count | Best first capture | |---|---|---|---| | Gap-frame mechanical, hand-fed | Set by the operator | Strokes, operator pauses | Frame sensor | | Gap-frame mechanical, coil-fed | Tens of SPM | Strokes × parts per stroke | Frame sensor | | Straight-side, progressive die | Tens of SPM | Strokes × parts per stroke | Frame sensor | | Link-motion, progressive die | Up to about 120 SPM | Strokes × parts per stroke | Frame sensor | | High-speed precision | Hundreds of SPM | Strokes from the control | Press control counter | | Transfer press | Tens of SPM | Parts at the last station | Exit beam | | Servo press | Changes by job | Strokes, per job | Frame sensor and control | Stroke rates are indicative, from press makers' published ranges. Use your press's rating and each die's own rate. A servo press needs the extra column. One press maker says its servo presses achieve a wide variety of stroke lengths and slide movement profiles,[4] so the same press can run a slow draw job in the morning and a fast blanking job after lunch. Record the rate for each job, and read the job from the control when the press runs several. ## How do you separate short stops from downtime? You separate them with a short-stop cutoff: a stop shorter than the cutoff counts as running time, and a longer one reaches the downtime record and gets a reason. Without it, every pause between strokes is a stop, and a shift becomes hundreds of one-minute rows nobody can classify. Set the cutoff from two numbers on each press: - **The longest pause that belongs to the rhythm:** the operator reaching for a blank, the feed indexing, a part clearing the chute. On a press these run from a fraction of a second to a second or two. - **The shortest stop you'd act on:** usually the coil change. If coils take 8 minutes to load, a 10-minute cutoff hides every one of them. The cutoff goes between them. For example, a coil-fed press at 40 SPM with 8-minute coil loads takes a 5-minute cutoff. A hand-fed press needs a lower one, because operator pauses are the loss you want to see. > **A cutoff hides what sits under it** > > Any stop under the cutoff disappears into running time, including a 4-minute jam under a 5-minute cutoff. Start low, run a shift, and raise the cutoff only if the record still fills with pauses nobody can act on. The stroke rate catches what the cutoff hides, as the worked example shows. The guide to [micro-stops](/blog/micro-stops/) covers where these short stops land in OEE. The press setup guide gives a [starting cutoff band by stroke rate](/docs/production/stamping-presses/#short-stops). ## Track die and coil changes separately A die change and a coil change are both changeovers, but they need separate reasons, because each one has its own fix and its own owner. A die change swaps the tooling for a new part number. A coil change reloads material for the same part. | Reason | What it covers | Who acts on it | |---|---|---| | Die change | Last good part to first good part | Die setter | | Setup and adjustment | Shims, feed length, first-hit tuning | Die setter | | Coil change | Threading a new coil | Operator, material handling | | Misfeed or jam | Strip or blank stuck in the die | Operator, tooling | | Die repair | Broken punch, slug pulling | Toolroom | | Waiting on material | No coil or blanks at the press | Materials | A starting list for a press shop. Add a code only when the same reason keeps landing in other. Time a die change from the last good part of the old run to the first good part of the new one, as the guide to [measuring changeover time](/blog/measure-changeover-time/) explains. The SMED method aims at a changeover in single-digit minutes, under 10,[6] and the element log is where you find the minutes to move outside the stop. Die setting itself is governed by OSHA's mechanical power press rule, 29 CFR 1910.217, which this guide doesn't cover.[7] Coil changes are predictable, so you can check them against arithmetic. For example, a 3,000-foot coil fed 4 inches per stroke lasts 9,000 strokes, which is 225 minutes at 40 SPM. A press that stops for a coil every 90 minutes is running a shorter coil than you think, or losing material somewhere. Build each reason by [creating a downtime category](/docs/monitoring/downtime-categories/#create) for it, so die change minutes and coil change minutes never mix. ## A 200-ton press at 40 SPM The numbers below follow one hypothetical press through one shift, computed two ways: from the clock and from the counter. #### Worked example: For example, a 200-ton press with a two-out progressive die - Shift: 480 minutes with a 30-minute lunch, so planned time is 450 minutes. - Rated speed for the die: 40 SPM, two parts per stroke. Short-stop cutoff: 5 minutes. - Stops above the cutoff: a 38-minute die change, a 12-minute coil change and a 10-minute misfeed jam, 60 minutes in all. Run time is 450 − 60 = 390 minutes. - Stroke counter at the end of the shift: 14,040 strokes. Scrap logged: 280 parts. From the clock, the press should have made 390 × 40 = 15,600 strokes, or 15,600 × 2 = 31,200 parts. From the counter, it made 14,040 × 2 = 28,080 parts, and 28,080 − 280 = 27,800 were good. The counter is 15,600 − 14,040 = 1,560 strokes short. At 40 SPM that's 1,560 ÷ 40 = 39 minutes, and its average rate while running was 14,040 ÷ 390 = 36.0 SPM. **Result:** The clock predicts 31,200 parts and the counter shows 28,080: 39 minutes of short stops and slow strokes Figure: Minutes on one press shift: 450 planned, 60 of logged stops (die change, coil change, misfeed), 390 run, then 39 minutes of short stops and slow strokes, leaving 351 minutes' worth of counted strokes at 40 SPM. *The downtime record explains 60 minutes; the stroke count finds 39 more. Sample data.* The two methods answer different questions. The clock says the press stood for 60 minutes, and the reasons say die changes cost most of it. The counter says it lost another 39 minutes while it was supposedly running, in stops too short to log and strokes slower than the die's rate. Split by OEE factor, that's availability of 390 ÷ 450 = 86.7%, performance of 14,040 ÷ 15,600 = 90.0% and quality of 27,800 ÷ 28,080 = 99.0%. The [OEE calculation guide](/blog/how-to-calculate-oee/) works through each factor. Without the stroke count, the 39 minutes would vanish into a run time that looks like 390. ## Monitor presses with IoTFlows IoTFlows puts a [SenseAi](/products/senseai/) on the frame of each press. It attaches magnetically in seconds, calibrates in under five minutes and reads each stroke from outside the press, with no PLC or controller access. The Discrete w/o Merge algorithm counts every stroke at 10 to 120 strokes a minute, times the parts per stroke you set for each die. One operation per die keeps each die's output separate. The Downtime Threshold keeps the gaps between strokes out of downtime, and operators tag die changes and coil loads in a tap. A BeamTracker at the exit chute counts parts that cleared the die instead. On Enterprise, the IoTFlows edge device reads the press control, and it reads only the controls you choose to connect. Validate the count against [a stroke count by hand](/docs/production/stamping-presses/#validate) before you trust the shift goal. ## Set up monitoring on your presses 1. **List every press and every die.** Write down each press with its tonnage, its feed (hand, coil or transfer) and every die it runs. Record each die's rated SPM and its parts per stroke. 2. **Pick the capture method per press.** Put a vibration sensor on the frame of every press first. Add an exit beam where misfeeds are common, and plan a control connection only where a question needs the die number or stop reason. 3. **Validate the count over an hour.** Run the press for one to two hours and compare the count with run minutes × SPM, or with the press counter. A count that reads exactly double or half is a parts-per-stroke setting or a press that rings twice. 4. **Set the short-stop cutoff.** Place it above the pauses that belong to the stroke rhythm and below the shortest coil change on that press. 5. **Create the press reasons.** Add separate reasons for die change, setup and adjustment, coil change, misfeed and die repair before anyone classifies a stop. 6. **Compare clock and counter weekly.** Each week, compare counted strokes with run time × rated SPM for each die. A gap that grows is short stops or slow running, and a rate that falls on one die points at its tooling. 7. **Rank the losses after four weeks.** Rank classified stops by hours and work the largest reason first. If die changes lead, time them by element next. ## Questions ### Does a misfeed stroke count as a part? Not as a good part. A sensor on the frame counts the stroke because the ram still moved, and a press control counter does the same. A beam at the exit counts only parts that left the die. Log the parts a misfeed ruined as scrap with a reason, so the good count stays right whichever counter you use. ### Should a die change count as planned downtime? Give it its own reason either way. Some plants mark scheduled die changes as planned so they don't lower availability, but the press still could not run for those minutes. Whatever your convention, report die change minutes per week beside the number of changes, so you can see whether shorter changes are paying off. ### How do I check that a press stroke count is right? Run the press normally for an hour or two, then compare the recorded count with run minutes multiplied by the stroke rate, or with the press control's own counter. A press at 60 strokes a minute for 60 minutes made 3,600 strokes. A count within 2 to 3% is right, and one that reads exactly double points to a press that rings twice per stroke. ### Do I need to connect to the press control to monitor a press? No. A vibration sensor on the frame reads strokes and run state from outside the press, on any brand or age. Connect the control when you need what only it holds, such as the die number or the reason for the last stop. That connection is a security concern for many plants, so IT usually reviews it first. ### How fast should a stamping press run? At the rate the die and the part allow, which is often below the press's rated maximum. Record a rated strokes per minute for each die, the speed that job is meant to run, and compare actual strokes against it. A stroke rate that falls on the same die over weeks points at tooling wear or material, not at the press. ## Sources 1. [C Frame Crank Press (SN series specifications)](https://www.seyi.com/c-frame-crank-press_sn.html), SEYI Machinery, accessed Oct 27, 2026 2. [Progressive Stamping Link-Motion Press (SM2 series specifications)](https://www.seyi.com/progressive-stamping-link-motion-press_sm2.html), SEYI Machinery, accessed Oct 27, 2026 3. [Transfer dies vs progressive dies: differences and advantages](https://www.minifaber.com/blog-minifaber/transfer-dies-vs-progressive-dies-differences-and-advantages), Minifaber, accessed Oct 27, 2026 4. [Press Controls and Monitoring](https://www.stamtec.com/auxiliary-press-equipment/press-controls-and-monitoring), Stamtec, accessed Oct 27, 2026 5. [DiPro 1500 Die Protection System](https://www.wintriss.com/wcg/automation/dipro1500.html), Wintriss Controls Group, accessed Oct 27, 2026 6. [Single Minute Exchange of Die (SMED)](https://www.lean.org/lexicon-terms/single-minute-exchange-of-die/), Lean Enterprise Institute, accessed Oct 27, 2026 7. [29 CFR 1910.217, Mechanical power presses (2024 edition)](https://www.govinfo.gov/content/pkg/CFR-2024-title29-vol5/xml/CFR-2024-title29-vol5-sec1910-217.xml), US Government Publishing Office, accessed Oct 27, 2026 --- # Part counting methods and which one fits your machine Source: https://www.iotflows.com/blog/part-counting-methods/ Count parts from machine cycles, a beam break, the controller’s counter or a hand tally. Match a method to CNC, molding, presses and packaging, then check it. > Question: Which counting method fits my machine? ## Key takeaways - Count machine cycles and multiply by parts per cycle when each cycle makes a fixed number of parts. - Count beam breaks when finished units pass one point in single file, such as after the last reject on a packaging line. - A controller counter adds program names and good or bad splits, but check whether it counts cycles or parts. - An exact multiple of the hand tally is a parts-per-cycle setting; an uneven error is the detector. - Validate every new count against a hand tally and the machine’s own cycles before anyone reports from it. The counting method that fits your machine depends on where one part becomes visible. Count machine cycles and multiply by the parts each cycle makes on a CNC, a press or a molder. Count beam breaks where finished units pass one point in single file, as on a packaging line or a bagger. Read the controller’s counter when the machine already reports one, and keep a hand tally to prove the others. This guide is for manufacturing engineers choosing how to count across a mixed floor. It covers how each signal becomes a count, a machine-by-machine table, the errors each method makes and one validation worked two ways. How a sensor tells running from stopped is a separate question, answered in [how a sensor knows a machine is running](/blog/how-sensors-detect-machine-state/). ## What are the four ways to count parts? There are four sources of a part count: the machine’s own cycle, a beam break at a fixed point, the controller’s counter and a person with a tally. Each counts a different event, so each answers a slightly different question. > **Definition.** **Part count** is the number of parts a machine or line made in a window, built from one countable event, such as a machine cycle, a beam break or a controller tick, multiplied by the number of parts each event yields. | Method | One count means | Needs | Best at | |---|---|---|---| | Machine cycles | One cycle of the machine | A sensor on the machine | Any machine, any age | | Beam break | One unit passing a point | A clear single-file path | Line output after rejects | | Controller counter | One tick of the control | A connection to the control | Program names, good and bad | | Hand tally | One part a person saw | Time and attention | Proving the other three | The first two count from outside the machine. The controller counter reads inside it. The event decides what the number means. A cycle count says what the machine did, including scrap and setup pieces. A beam after the last reject station says what the line shipped. The rest of this guide takes each method in turn. ## How does a machine cycle become a part count? A machine cycle becomes a part count when a rule decides where one cycle ends, counts those ends, and multiplies the total by the parts each cycle yields. The rule has to match the shape of the machine’s signal. **Part count** = Detected cycles × parts per cycle > **Definition.** **Detection algorithm** is the rule that decides, from a sensor’s signal, when one machine cycle has finished, which sets both the part count and the measured cycle time for the operation the machine is running. The [glossary entry for detection algorithm](/docs/get-started/glossary/#detection-algorithm) uses the same meaning. Three signal shapes cover most machines, and each takes a different rule. Figure: A CNC trace with three bursts and one merged dip counts 3 cycles. A press trace with six impacts counts 6 strokes. A molder trace that never drops counts 5 cycles from run time. A beam with five breaks counts 5 units. *Each signal shape takes its own counting rule; the dots mark what becomes a count. Sample data.* ### One burst per cycle A CNC mill vibrates while it cuts and falls back to idle while the operator unloads and reloads. Count one cycle each time the trace falls back to idle and stays there. Merge short dips back into the burst they interrupt. A tool change or a probe move drops the trace for a few seconds without finishing the part, so a rule that counts every dip splits one part into two. Counting bursts also beats dividing run time by an average cycle when the job mix changes, as [the CNC part-count guide](/blog/cnc-cycle-time-and-part-counts/#count-cycles) works through. ### One impact per part A stamping press makes one part per stroke, and each stroke is a sharp impact. At 10 to 120 strokes a minute, a rule that merges nearby events merges real parts, so count every impact on its own. The exception is a heavy press whose ram rebounds and rings twice per stroke. That press counts close to double under an every-impact rule. Move it to the merging rule, or count at the exit chute with a beam instead. ### A trace that never drops An injection molder at temperature cycles without resting: clamp, inject, hold, cool, eject. The trace stays up through every shot, dipping for a second or two at mold open, so there is no fall to idle to count. Divide running time by the measured cycle time instead. **Cycles** = (Running time) ÷ (Measured cycle time) Here the cycle time is the divisor, so its accuracy is the count’s accuracy. For example, a molder that really runs a 22-second shot but is entered at 21 seconds reports 3,600 ÷ 21 = 171 shots an hour instead of 3,600 ÷ 22 = 164, about 4.8% high. Time 10 to 20 consecutive shots on a good day, and see [setting the ideal cycle time](/blog/ideal-cycle-time/) for why the number needs an owner. ### Parts per cycle Every cycle count needs one multiplier: the parts one cycle makes. A four-cavity mold makes 4 parts per shot, a two-out die 2 parts per stroke and a four-station vise fixture 4 parts per cycle. Keep the cycle time per cycle and put the multiple in the [quantity per cycle setting](/docs/production/cycle-times-and-filters/#qty). Halving the cycle time instead gets the part count right on a division rule and every rate, goal and gauge wrong. ## When does a beam break count better? A beam break counts better than a machine cycle when finished units travel a fixed path in one direction and the number you report is what left the line. A laser or light beam across the path registers one count each time a unit interrupts it. That makes the beam the right method for packaging lines, baggers, case packers and conveyors carrying output from several machines. On a filling line, no single machine’s cycle is the line’s output, and a filler, a capper and a case packer each run their own rhythm. The count point decides what the number means. Put the beam after the last reject or divert station, so the count is good output rather than attempts. Four rules pick the exact spot: - **Single file.** A beam across a conveyor two units wide counts neither lane reliably. - **Off accumulation.** A unit that backs up and drifts forward crosses the beam twice. - **A gap between units.** Two cartons touching end to end break the beam once for two. - **An opaque feature.** Clear glass and film may pass without breaking the beam, so aim at the cap or the label band. One break is whatever the beam sees. Aimed at single bottles, one break is 1 bottle. Aimed at cases leaving a packer, one break is a case, so a 24-count case carries a multiplier of 24. The [packaging line guide](/blog/how-to-monitor-a-packaging-line/#count-point) covers count points in detail. A beam also counts parts leaving a press, at the exit chute. Choose it there when the press misfeeds or rings more than once per stroke, because the exit count includes only parts that cleared the die. ## When should you read the controller’s counter? Read the controller’s counter when the machine already reports one, IT has approved the connection, and you need what only the control knows: which program ran, which job it belonged to and how many parts it marked good or bad. A connection to the control is a security concern for many plants, and IT usually reviews it first. Check first whether the counter counts cycles or parts, because the standards keep them apart. MTConnect defines a cycle count as the “accumulation of the number of times a cyclic function has attempted to, or is planned to attempt to execute”,[1] and a part count as an “aggregate count of parts”.[2] Packaging machines that follow PackML split the count by quality instead. The standard’s example of its processed count is “the number of products that were made, including all good and defective products”, and the processed count minus the defective count is the non-defective output.[3] Molding machines on the OPC UA plastics model report `JobCycleCounter`, “the number of finished cycles in the job”, beside separate counters for good, bad and test sample parts.[4] The mold’s cavity count is `NumCavities`, an optional property, so confirm your machine fills it in before you trust a part count built on it.[5] | Counter question | Why it matters | |---|---| | Cycles or parts? | A cycle count needs parts per cycle | | Good, bad or both? | Processed counts include rejects | | Does it reset? | A job counter restarts with each job | | When was it last reset? | A reset mid-window breaks the check | Choose the controller counter when you need program or job names on every count. Default to a sensor where the fleet mixes builders and decades, or where some machines have no network port at all. The [sensor versus PLC comparison](/compare/sensor-based-vs-plc-machine-monitoring/) sets out what each approach sees, with its sources. ## Where do manual counts still fit? Manual counts still fit in two places: as the reference that proves every automatic count, and as the record where no machine signal separates the parts. Everywhere else, a hand count is slower and less frequent than the machine. People count in three ways. A tally sheet marks parts as they come off. A count at packout multiplies full totes or cases by their standard quantity. A count by weight divides a bin’s net weight by the weight of one part, measured over 50 parts. A hand count carries no timestamps, so it cannot show an hourly rate or when the machine stopped. A count written at the end of a shift is also a count from memory. Log it hourly when it is the record, for example at a hand-assembly bench where no machine cycle exists. ## Which method fits each machine type? The method that fits each machine follows from its signal: count bursts on a CNC, every impact on a press, run time divided by the cycle on a molder, and beam breaks on a packaging line or a bagger. | Machine | Signal between parts | Counting method | Parts per count | |---|---|---|---| | CNC mill or lathe | Falls to idle at each load | Count bursts, merge dips | Parts per fixture, often 1 | | Bar-fed lathe, one job | Never falls to idle | Run time ÷ cycle time | 1 | | Injection molder | Stays up, brief mold-open dips | Run time ÷ shot time | Working cavities | | Stamping press | One sharp impact per stroke | Count every impact | Outs per stroke, often 1 | | Packaging line | Units pass single file | Beam after the last reject | 1 per unit, or case count | | Bagger | One bag per discharge | Beam at the discharge | 1 per bag | The machine-by-machine guides for CNC, molding and packaging cover mounting, setup and the hand check for each. A molder with an operator loading inserts by hand waits between shots, so it counts like a CNC. A bar-fed lathe running one job unattended never rests, so it counts like a molder. The signal decides, not the machine’s name. Figure: Four questions in order. Single-file units: count beam breaks. One impact per part: count every impact. Idle between parts: count bursts, merge dips. Trace never drops: divide run time by cycle. Otherwise read the controller or count by hand. *Ask the questions in order; the first yes picks the method, then multiply by the parts each count yields.* > **Not sure which rule fits?** > > Start with counting bursts and merging short dips when you can’t tell the machine’s signal shape. That rule adapts when cycle times vary, so it is the least wrong choice on a machine nobody has measured. Move to counting every impact if the count runs low on fast strokes, and to dividing run time if the trace never falls to idle. You don’t need two methods on one machine whose count already validates. A second counter is a second thing to calibrate and a second number to argue about. ## What makes a part count wrong? A part count goes wrong in one of three places: the signal, the rule that finds cycles in it, or the multiplier that turns cycles into parts. The shape of the error tells you which. | Failure | What you see | Fix | |---|---|---| | Merged cycles | Low by an uneven amount | Count every impact instead | | Double counts | High, near but not exactly 2× | Merge the second ring | | Multi-cavity mold left at 1 | Exactly ½, ⅓ or ¼ of the truth | Set the working cavities | | Parts per cycle set too high | Exactly 2, 3 or 4 times the truth | Set the parts one cycle makes | | Cycle time off on division | Error grows with running time | Re-time 10 to 20 cycles | | Beam misses units | Low, on clear or touching units | Aim at an opaque feature | Divide the system count by the hand tally and read the ratio, not the difference. Merged cycles happen when two fast parts land inside one burst, for example a press at 90 strokes a minute on a rule that merges dips. Double counts happen when one part rings twice on an every-impact rule, or a unit crosses the beam twice on an accumulation table. Multi-cavity molds fail in two ways. A four-cavity mold left at 1 reports a quarter of its output. A four-cavity mold running with one cavity blocked makes 3 parts a shot, so a setting of 4 overcounts by one part in three, as [the molding guide](/blog/monitor-injection-molding-machines/#double-half) shows. Check parts per cycle before you touch the rule. An exact multiple is almost never the detector, and no rule change fixes a multiplier. The [part-count troubleshooting guide](/docs/production/troubleshoot-part-counts/) works each symptom through to a fix. ## Count parts automatically with IoTFlows IoTFlows counts parts from each machine’s own signal, with no PLC connection. A magnetic SenseAi reads the machine’s vibration and sound and takes one of three detection algorithms: Discrete Analysis counts one burst per cycle and merges short dips, Discrete w/o Merge counts every impact, and Continuous Analysis divides running time by the cycle time. A [BeamTracker](/products/beamtracker/), an IP67 laser counter that bolts on in 10 to 20 minutes, runs Counter: each beam break is one cycle, with ±2% count accuracy. Every operation carries a quantity per cycle, so cavities, multi-out dies and case counts multiply correctly. The [algorithm comparison](/docs/production/choose-an-algorithm/#compare) sets all four side by side. > The visibility into operator performance was eye-opening. We could immediately see which team members needed additional training to reach target speeds. Within weeks of targeted coaching based on the IoTFlows data, our newer operators were hitting 30 bags per minute. The downtime tracking also revealed setup procedures we could streamline. This platform has transformed how we manage our bagging operations. > > Juan Perez, Warehouse Operations Manager, Criollos Foods ([story](https://www.iotflows.com/customers/criollos-foods/)) ## How do you validate a count by hand? You validate a count by comparing it with a hand tally over the same window, twice: once in parts and once in cycles. The parts ratio tells you whether the count is right. The cycles ratio tells you whether the detector or the multiplier is wrong. **Count accuracy** = (System count) ÷ (Hand tally) 1. **Pick a window and a reference.** Run the machine normally for 20 minutes to two hours on one operation. Use a hand tally of parts, and the machine’s own stroke or shot counter if it has one. 2. **Read both counts for the same window.** Note the system’s part count, its cycle count and the hand tally for the same start and end times. Most disagreements are two people reading two windows. 3. **Divide parts by parts.** Divide the system’s parts by the hand tally. At 95 to 105%, leave the setup alone. 4. **Divide cycles by cycles.** Divide the system’s cycles by the machine’s real cycles. A cycles ratio of 1 with a parts ratio off is the multiplier; both off by the same ratio is the detector. #### Worked example: For example, a two-out die on a stamping press - The press runs 30 strokes a minute with a two-out die, so it makes 2 parts per stroke. - Window: 20 minutes of running with no stops. The press’s stroke counter moves from 48,210 to 48,810, which is 600 strokes. - Hand tally: 24 totes packed 50 to a tote, which is 1,200 parts. That agrees with 600 strokes × 2 = 1,200. - The system reports 2,316 parts at 2 parts per cycle, which is 1,158 detected cycles. Way 1, in parts: 2,316 ÷ 1,200 = 1.93. Way 2, in cycles: 1,158 ÷ 600 = 1.93. Both ratios match and neither is a clean 2, so the multiplier is right and the detector finds about 1.93 events per stroke: the ram rings twice on most strokes. Moving the press to the merging rule, the next 20-minute window reads 1,192 parts, or 596 cycles, against 1,200 parts and 600 strokes. **Result:** Accuracy after the fix = 1,192 ÷ 1,200 = 99.3% in parts, and 596 ÷ 600 = 99.3% in cycles Had the die been set to 4 parts per cycle with a clean detector, the system would read 2,400 parts from 600 cycles. The parts ratio would be exactly 2.00 and the cycles ratio exactly 1.00, which points at the setting, not the sensor. Validate with ten parts first, then with a longer window, as the [first-count quickstart](/docs/production/quickstart/#validate) describes. A count that matches part for part is right. A shift total that lands near the truth can hide two errors that cancel, and stamping lines get their own walkthrough in [how to monitor stamping presses](/blog/how-to-monitor-stamping-presses/). ## Questions ### Can one sensor count parts on any machine? A vibration sensor counts parts on any machine whose cycle shows up as a burst, an impact or a steady trace, which covers most CNC machines, presses and molders. It cannot tell units apart on a conveyor carrying output from several machines. Count those units with a beam across the conveyor at a point they pass in single file. ### Should I count strokes or parts on a stamping press? Count strokes when every stroke makes a known number of parts, then multiply by the parts per stroke, such as 2 for a two-out die. Count parts at the exit chute with a beam when the press misfeeds often or rings more than once per stroke, because the exit count only includes parts that cleared the die. ### Does an automatic part count include scrap? Yes. A cycle count and a beam count both record gross output, so startup pieces, test parts and rejects are counted with the good ones, unless the beam sits after the last reject station. Log scrap with a reason and subtract it, or compare gross with gross when you check the count against an ERP figure. ### How many parts should I hand count to validate a count? Count at least ten parts or ten cycles against the same window the system reports, then repeat over a longer run of 20 minutes to two hours. A count that matches part for part over ten parts is right. A shift total that lands near the truth can hide two errors that cancel each other. ## Sources 1. [CycleCount, MTConnect SysML Model V2.5](https://model.mtconnect.org/Version2.5/ObservationInformationModel/ObservationTypes/EventTypes/CycleCount/), MTConnect Institute, accessed Oct 27, 2026 2. [PartCount, MTConnect SysML Model V2.5](https://model.mtconnect.org/Version2.5/ObservationInformationModel/ObservationTypes/EventTypes/PartCount/), MTConnect Institute, accessed Oct 27, 2026 3. [OPC 30050: OPC UA for PackML, Common Object Model, version 1.01](https://reference.opcfoundation.org/specs/OPC-30050/full), OPC Foundation, accessed Oct 27, 2026 4. [OPC 40083, OPC UA for Plastics and Rubber Machinery, General Type Definitions: 18.4.7 ActiveCyclicJobValuesType](https://reference.opcfoundation.org/specs/OPC-40083/18.4.7), OPC Foundation, accessed Oct 27, 2026 5. [OPC 40083, OPC UA for Plastics and Rubber Machinery, General Type Definitions: 18.2.11 CyclicJobInformationType](https://reference.opcfoundation.org/specs/OPC-40083/18.2.11), OPC Foundation, accessed Oct 27, 2026 --- # How a sensor knows a machine is running Source: https://www.iotflows.com/blog/how-sensors-detect-machine-state/ A sensor tells running from stopped by comparing vibration or sound with two calibrated levels and ignoring brief swings. See how, and when to use the control. > Question: How can vibration and sound tell running from stopped without the control? ## Key takeaways - A working machine vibrates and sounds well above its powered-idle level, and a sensor on the frame measures that gap. - Two thresholds with a gap between them, plus smoothing, keep the state steady when the signal hovers near one line. - Flicker barely changes total running time but multiplies the number of stops, which breaks downtime records and alerts. - Calibrate against the machine powered on and idle, not switched off, and confirm that cutting and idle read differently. - Connect the control only for what it alone knows, such as alarm codes, program names and process values. Vibration and sound tell running from stopped because a working machine shakes its frame and makes noise well above the level it reaches when it is powered on and idle. A sensor on the outside measures that level every second, compares it with two calibrated thresholds and ignores brief swings, so the state changes only when the change lasts. Nothing connects to the control. This guide is for engineers setting up machine monitoring without PLC access. It covers what each signal looks like, why one threshold flickers, where the stopped line goes, how to keep a neighbor's press out of the record and when the control is the better source. ## What does a running machine look like? A running machine looks like a higher level: the size of its vibration or sound, averaged over a second or so, sits well above where it sits while the machine waits. The sensor doesn't need to know what the machine is making. It needs a level for working and a lower one for waiting. > **Definition.** **Machine state** is whether a machine is running or stopped at a given moment, decided from a signal such as vibration, sound, motor current or a controller status, and recorded as a timeline from which uptime and downtime are calculated. That timeline is the input to [uptime](/docs/get-started/glossary/#uptime): running time divided by running plus stopped time. Every number built on it is only as good as the moments where the state flips. ### Off, powered idle and working A machine has three levels, not two. Off is near zero. *Powered idle* is the machine switched on and not working, with its fans, pumps and drives still turning. Working sits above both. Powered idle is never silent. On the automotive machining line in a 2006 MIT study, the actual machining took at most 14.8% of the line's energy; the rest went to starting up and holding the equipment in a “ready” position.[2] That ready-state equipment hums and vibrates too, so the stopped line sits above powered idle, never at zero. | Machine | Working signal | Powered-idle floor | |---|---|---| | CNC mill or lathe | Spindle under cutting load | Coolant pump, chip conveyor, fans | | Stamping press | A sharp peak on each stroke | Flywheel turning between strokes | | Injection molder | Clamp, inject and eject in sequence | Hydraulic pump running | | Surface grinder | Wheel in contact with the part | Wheel spinning, not in contact | | Case packer | Rhythmic indexing | Drives powered, infeed empty | Sample machines. Your levels depend on the machine, its condition and where the sensor sits. ### Vibration or sound Vibration travels through the frame, so a sensor magnet-mounted on the machine reads that machine. Sound travels through the air, so a microphone hears the room as well. Factory floors are loud: about 38% of manufacturing workers were exposed to hazardous noise in the last year, by NIOSH's count.[3] A 2024 study of a legacy pipe bender names the problem directly: sound monitoring on a real shop floor suffers mainly from noise from neighboring machines.[1] Default to vibration. Add sound when the work is audible but barely moves the housing, such as light trimming on a heavy cast base, and calibrate it as its own channel with its own thresholds. ## How does a threshold set the state? A threshold splits the signal: above the running threshold the machine reads running, and below the stopping threshold it reads stopped. With one line doing both jobs, any signal that hovers near it flips state again and again. ### Why one threshold flickers A light cut is the usual culprit. On a CNC lathe, a finishing pass loads the spindle far less than roughing, so its vibration can sit right on a line set for the whole cycle. Every dip below the line logs a stop, and every rise logs a restart. Figure: 12 minutes of vibration on a CNC lathe: idle, roughing with a 6 s tool change, a 1 min load, a finishing pass near the line, then idle with a 3 s bump from a press next door. One threshold logs 11 stops; two thresholds and smoothing log 2. *The same trace read two ways: one threshold flickers through the finishing pass, while two thresholds and smoothing give one clean run. Sample data.* The figure shows 12 minutes on a hypothetical lathe. One threshold logs 11 stops, from a 6-second tool change, the finishing pass and a 3-second bump from a press next door. Two thresholds with smoothing log the 2 stops that happened: the part load and the end of the job. ### Two thresholds and smoothing > **Definition.** **Hysteresis** is the gap between two thresholds: a signal must rise above the upper one to switch a state on and fall below the lower one to switch it off, so a signal wandering between the two lines keeps its current state. Hysteresis handles a signal that wanders. *Smoothing* handles one that spikes: the sensor averages the last few seconds before it compares the level with either line. A related method, a *hold time*, requires the new state to persist for a set number of seconds before it counts. Both cost a delay. A stop is recorded a few seconds after it starts, and a stop shorter than the delay never appears. Set the delay shorter than the shortest stop you want to see, and let [short-stop handling](/blog/micro-stops/#cutoff) decide what happens to the stops that do appear. Flicker hides in time totals and shows in counts. In the pipe-bender study, a sound model without smoothing counted 215 machining events in one hour against 112 that happened. A buffer that took the majority of the last 5 readings brought the count to 120, while total machining time stayed within 0.2% of the true value either way.[1] #### Worked example: One shift on a CNC lathe with a light finishing pass - Planned production time: 450 minutes. The lathe runs 60 cycles and stops 25 times, for 50 minutes in all, so it runs 400 minutes. - With one threshold, the finishing pass dips below the line twice per cycle for 2 seconds: 60 × 2 = 120 false stops, worth 120 × 2 = 240 seconds, or 4 minutes. - One threshold: running 396 minutes, uptime 396 ÷ 450 = 88.0%, with 25 + 120 = 145 stops. - Two thresholds and a 5-second hold: running 400 minutes, uptime 400 ÷ 450 = 88.9%, with 25 stops. **Result:** Uptime moves 0.9 points; the stop count rises 5.8 times, from 25 to 145 Those 120 false stops do the damage. Each one asks an operator for a reason, inflates stops per hour and can trip a stop alert. Any count taken from the falls in the trace triples too, which is why [part counting methods](/blog/part-counting-methods/) start from a clean state. > **Move the threshold or the smoothing?** > > Move a threshold when the state is wrong: a running machine reads stopped, or an idle one reads running. Add smoothing when the state is right but unstable, flickering on a machine that is plainly running. The two look alike on a status bar and are opposite on the trace. ## Is the machine idle or cutting? Idle and cutting are separate states to the sensor only if their levels don't overlap at the mount. So decide what “running” means for this machine first, then check that a gap exists where you need it. Figure: Vibration ranges on a CNC lathe: off near 0 g, powered idle 0.015 to 0.026 g, spindle on and not cutting 0.022 to 0.034 g, finishing 0.055 to 0.075 g, roughing 0.08 to 0.11 g. Thresholds at 0.04 and 0.05 g sit in the gap between 0.034 and 0.055 g. *Each condition reads as a range; the thresholds go in the gap between the highest stopped range and the lowest running range. Sample data.* On this hypothetical lathe, the stopping threshold sits at 0.04 g, above the highest stopped reading of 0.034 g. The running threshold sits at 0.05 g, below the lightest cut at 0.055 g. Leave a buffer on both sides rather than placing either line on a measured edge. The spindle turning with no cut overlaps powered idle here, so it reads as stopped. That is the right answer for most plants, since a spindle turning in air makes nothing. If your plant counts a warm-up cycle or air cutting as running, you need a mount where those levels clear idle, or that time stays in downtime. > **Capture idle with the power on** > > Capture the stopped level with the machine switched on and not working. A machine switched off sits far below its real floor, so a threshold set against it reads the coolant pump as production and shows the machine running all shift. [Machine shows running when idle](/docs/monitoring/troubleshoot-monitoring/#running-when-idle) walks through the fix. ## What about vibration from the machine next door? A neighbor's vibration reaches the sensor through the floor and the frame, and its sound through the air, so you keep it out with the mount, the channel and a minimum run length. Each one stops a different kind of intrusion. - **The mount.** On a casting tied to this machine's drive, the neighbor's vibration has crossed a floor and a machine base before it arrives, while this machine's own reaches the sensor directly. - **The channel.** Vibration stays tied to the machine it's mounted on; sound picks up every press and compressor in the bay. - **Smoothing.** A 3-second bump from a forklift or a press stroke next door averages out below the running threshold, as the figure above shows. - **A minimum run length.** Drop any run shorter than a few seconds, such as 10 seconds on a machine whose real cycles last minutes, so a sliver that gets through never counts as production. Set the minimum run length last. Applied first, it hides the slivers that tell you a threshold or the mount is wrong. Test the neighbor on purpose. Leave this machine powered and idle, run the machine next to it through a few cycles and watch the trace. If the trace crosses the running threshold, move the sensor before you touch the thresholds. ## Where should the sensor go? Mount the sensor on flat steel mechanically tied to the parts that move, as close to the spindle or main motor as you can reach. Placement decides which states the sensor can see at all. The pipe-bender study tested four sensor positions on one machine. A sensor on the hydraulic pump showed distinct signals when cutting occurred but could not capture the machine's other operating states.[1] The same machine read differently from each spot. | Mount | What the trace shows | |---|---| | Spindle housing or headstock | The cut, clearly separated from idle | | Main motor casting | Running, with some idle hum | | Hydraulic unit | Pump load, which can miss motion | | Guard door or sheet-metal cover | The panel ringing; cutting looks idle | | Base near the floor | Neighbors as much as this machine | The [mounting guide](/docs/hardware/install-senseai/#mounting) covers the surfaces a magnet holds on but that fail anyway. For mount points on four common old machines, see [how to monitor an old machine with no network port](/blog/monitor-old-machines-without-a-plc/#mounting). ## What does calibration check? Calibration checks that this sensor, on this mount, reads this machine's working and powered-idle levels differently, and places the thresholds in the gap between them. 1. **Capture the machine working.** Run several full cycles, including the lightest cut the machine makes, such as a finishing pass. Note the lowest point the trace reaches while working. 2. **Capture powered idle.** Stop the machine but leave it switched on. Note the highest point the trace reaches while it waits. 3. **Place the thresholds in the gap.** Put the stopping threshold just above the idle high and the running threshold just below the working low. If the two captures overlap, move the sensor before you go on. 4. **Set the smoothing.** Add smoothing if the state flickers on a machine that is plainly running. Reduce it if short bursts, such as single press strokes, go missing. 5. **Compare one hour with what you watched.** Stand at the machine for an hour, note each stop and its length, and compare your notes with the timeline. 6. **Watch 24 to 48 hours.** Look for a pattern of wrong readings, not one bad minute, then change one setting at a time and check again. The [SenseAi calibration guide](/docs/hardware/calibrate-senseai/) maps each step to the controls on the device. ## Detect machine state with IoTFlows A SenseAi magnet-mounts on the machine, reads vibration and sound from the outside and decides running or stopped every second on the device, with no PLC connection. It compares the trace with a running and a stopping threshold, and its momentum setting smooths the trace so brief swings don't flip the state. The settings live on the device, so the state is decided at the machine rather than in the cloud, as [the data path](/docs/get-started/how-iotflows-works/#on-device) explains. SenseAi Embedded, sealed for coolant and washdown, reads vibration and temperature and decides state from vibration. See [SenseAi](/products/senseai/). [Storm Power Components](/customers/storm-power-components/) runs SenseAi on its CNC machines, lasers and presses, deciding running or stopped from vibration and sound. > SenseAi gave us eyes we never had before. Our team leaders can instantly see which machines are running, which are down, and identify issues immediately instead of discovering them hours later. That visibility transformed our ability to manage production. > > Ben Huskey, Quoting Manager, Storm Power Components ([story](https://www.iotflows.com/customers/storm-power-components/)) ## When do you need controller data instead? You need controller data when the question is why or what, not whether: alarm codes, program names, spindle load and process values live only in the control. A sensor answers whether the machine ran, when it stopped and for how long. | | Sensor on the outside | Controller connection | |---|---|---| | Running or stopped | Yes | Yes | | When each stop began and ended | Yes | Yes | | Alarm code behind a stop | No | Yes | | Program or part running | No | Yes | | Spindle load and feed override | No | Yes | | Works with no network port | Yes | No | | Touches the control | No | Yes, IT usually reviews it first | Use this guide to pick the source for each machine: - **Use a sensor alone** when your questions are uptime, downtime and stop lengths, on any brand or age of machine. This covers most of what a plant manager asks. - **Add controller data** when a recurring question needs an alarm code, a program name or a process value, on the machines whose control can share it. A connection to the control is a security concern for many plants, so plan an IT review into the project. - **Use a different signal** when the work doesn't move the frame. A curing oven, a heat-treat furnace or a chemical bath runs on time and temperature, so a beam counter at the load point or the process controller is the better source. - **Change the mount, then the method,** when calibration shows working and idle overlapping. If no reachable mount separates them, that machine needs a different signal. The [sensor-based versus PLC comparison](/compare/sensor-based-vs-plc-machine-monitoring/) sets out what each approach reads, with its sources. ## Questions ### Can a sensor tell idle from cutting? Yes, when the two read differently at the mount. Cutting loads the spindle and the frame, so it sits well above powered idle. A spindle turning with no cut can sit close to idle, so decide first whether that time counts as running, then check that a threshold separates it. If the captures overlap, move the sensor closer to the spindle. ### Will a forklift or the press next door make my machine read as running? Not when the sensor is set up well. A bump lasts a second or two, so smoothing keeps it below the running threshold, and a minimum run length removes any sliver that gets through. A neighbor that shakes the frame for minutes is a mounting problem: move the sensor onto a casting tied to this machine's drive. ### How fast does a sensor detect a stop? Within seconds. The sensor checks the level every second and waits a few seconds before it changes state, so a brief dip doesn't count. The same delay hides any stop shorter than it, so keep the delay shorter than the shortest stop you want in the record. ### Do I need to recalibrate when the job changes? Not for every job. Recalibrate after you install or move the sensor, after major maintenance on the machine, and when the record stops matching what the floor saw. A new job matters only when it changes the lightest cut or the idle level, such as a finishing pass much lighter than anything the machine ran during calibration. ### Does sound work better than vibration? Not on most floors. A microphone hears the room as well as the machine, and noise from neighboring machines is a known problem for sound-based monitoring. Vibration travels through the frame, so it stays tied to one machine. Add sound when the work is audible but barely moves the housing, and calibrate it as its own channel. ## Sources 1. [Operation and Productivity Monitoring from Sound Signal of Legacy Pipe Bending Machine via Convolutional Neural Network (CNN)](https://par.nsf.gov/servlets/purl/10528445), International Journal of Precision Engineering and Manufacturing, Kim et al., 2024, via NSF Public Access Repository, accessed Oct 27, 2026 2. [Electrical Energy Requirements for Manufacturing Processes](https://web.mit.edu/2.813/www/readings/Gutowski-CIRP.pdf), 13th CIRP International Conference on Life Cycle Engineering, Gutowski, Dahmus and Thiriez (MIT), 2006, accessed Oct 27, 2026 3. [Manufacturing Statistics: Noise and Hearing Loss](https://www.cdc.gov/niosh/noise/surveillance/manufacturing.html), National Institute for Occupational Safety and Health (CDC), accessed Oct 27, 2026 --- # Detecting CNC tool crashes from shock events Source: https://www.iotflows.com/blog/cnc-tool-crash-detection/ Catch every CNC tool crash from the shock it sends through the machine: what a crash looks like in g, how to set the threshold and what to do after each alert. > Question: How can a plant know every time a tool crashes, even when nobody reports it? ## Key takeaways - A CNC tool crash shows up as one sharp acceleration, far above the peaks of normal cutting and tool changes. - A shock threshold records every crash with its time, machine and peak g, whether or not anyone reports it. - Set the threshold high first, review every event, then lower it in steps until routine work starts crossing it. - After every shock alert, inspect the tool, part, fixture and spindle, log the cause and open a work order. - A spindle-load monitor in the control adds automatic stops and catches the slow overload of a dull tool. A plant knows every time a tool crashes by mounting a vibration sensor on each CNC and recording every shock above a set threshold in g. A crash hits the machine far harder than cutting or a tool change does, so the threshold catches it whether or not anyone saw it. Each event carries the time, the machine and its peak value. This guide is for maintenance leads and manufacturing engineers who find crash damage after the fact. It covers what a crash looks like as a signal, how to set the threshold and what to do with each alert. ## What counts as a CNC tool crash? > **Definition.** **CNC tool crash** is an unplanned collision between the tool, holder or spindle and the part, vise, fixture or machine, caused by a motion the program or setup did not intend, such as a rapid move into the part, a wrong offset or a tool breaking in the cut. Most crashes start with a number, not a machine fault. A setup operator types a tool length offset of 4.125 as 41.25, and the next rapid move drives the tool into the vise. Haas describes exactly that case: an incorrect number typed into the offset column, sometimes from a missing decimal point, with a scrapped part or a broken tool as the result.[1] Its controls have carried a setting since 2001 that warns when an offset changes by more than a set amount.[1] | Cause | What happens | Where it starts | |---|---|---| | Rapid into the part or vise | Full traverse speed into metal | Wrong work offset or clearance plane | | Wrong tool length offset | Tool reaches deeper than programmed | Mistyped offset, tool and offset mismatch | | Wrong tool called | Longer tool runs a shorter tool's path | Tool table or magazine out of step | | Tool breaks in the cut | Shank or holder hits the part | Worn tool, packed chips, heavy feed | | Part not seated | Part lifts or shifts into the tool | Chips on locators, loose clamp | Every cause in this table is a setup or process error, so the fix is a procedure, not a part. ## What does a crash cost? A crash costs the tool, the part and often the spindle, and the spindle damage can stay hidden. A patent for a CNC control's collision detector puts it plainly: “When a spindle collision occurs, the machine tool may fail at the time.”[2] The same document describes the harder case. No problem may be found at the time of the collision, but a failure is found after a certain time period, through abnormal noises from the spindle or a decrease in machining accuracy.[2] | Damage | When it shows | If nobody logged the crash | |---|---|---| | Tool and holder | At once | Replaced, never recorded | | Part | At inspection | Scrapped as a bad part | | Vise or fixture | Next setup | Blamed on wear | | Spindle bearings | Weeks later, as noise or heat | Blamed on age | | Accuracy | Next first-article check | Chased as a program problem | The unreported crash is the expensive one. For example, a second-shift operator on a Haas VF-2 breaks an end mill, swaps it and restarts the job. Three weeks later the spindle runs hot, and nobody can say what changed. ## What a crash looks like as a signal A crash is a single spike of acceleration, many times higher than anything the machine does in normal work, lasting a fraction of a second. Cutting looks different: a band of vibration that rises and falls with every cycle. > **Definition.** **Shock event** is a single sharp acceleration above a set threshold, measured in g at a sensor on the machine and recorded with its time and peak value. On a CNC, a shock event is the signature of a crash or collision rather than of cutting. *Peak g* is the highest acceleration in the event, where 1 g is the acceleration of gravity. The [glossary entry for a shock event](/docs/get-started/glossary/#shock-event) uses the same terms. Two numbers tell a crash from normal work: how high the peak goes, and whether it repeats. | Event | Peak at the housing | Duration | How often | |---|---|---|---| | Finishing pass | 2–5 g | Whole pass | Every cycle | | Roughing pass | 8–18 g | Whole pass | Every cycle | | Tool change | 15–24 g | Under 1 s | Every tool change | | End mill breaks in the cut | 50–80 g | One burst | Rare | | Rapid into the vise | 100 g to past 200 g | One spike | Rare | Sample values for one hypothetical vertical mill with the sensor on the spindle housing. Measure your own machine before you set a threshold. Figure: One minute of acceleration on a vertical mill: roughing between 8 and 18 g, a tool change peak of 24 g, then a crash spike of 148 g above a 50 g threshold. The status bar turns from Running to Machine Down at the crash. *Normal cutting stays in a low band; the crash is one spike, and the machine stops. Sample data.* The figure shows why a threshold works. Roughing and the tool change stay well under 50 g, and the crash at 148 g is six times the highest normal peak. Mount the sensor on the spindle housing or the head casting, where the shock arrives first. Every bolted joint between the tool and the sensor softens the peak, and the [CNC mounting guide](/blog/how-to-monitor-cnc-machines/#mount) covers the spots that work. ## How do you set the shock threshold? You set the shock threshold by starting high, reviewing every event and lowering it in steps until routine work starts to cross it. Then you settle one step above that point. Both mistakes are costly. A threshold set low reports a collision during normal machining, and one set high fails to detect a collision that has actually occurred.[2] 1. **Start at the top of the range.** Set the threshold at the sensor's maximum alert level, so only severe impacts fire. Leave it for two weeks of normal production. 2. **Review every event.** For each event, ask the operator on shift what happened and write the answer next to the peak value. A threshold is only as good as the review behind it. 3. **Lower it in steps.** Drop the threshold by 10 to 20 g and run another week. Each step down catches smaller impacts, such as tools that break in the cut. 4. **Stop when routine work crosses it.** When events start arriving from normal work, such as every tool change or every pass of one tool, you've gone one step too far. Raise the threshold between the highest routine peak and the smallest real event. 5. **Recheck after a process change.** A new fixture, a heavier roughing tool or a sensor moved to another spot changes the peaks. Review a week of events after each change. #### Worked example: Four weeks of shock events on a hypothetical vertical mill The SenseAi sits on the spindle housing. Your peaks will differ with where the sensor sits relative to the spindle, so read these values as a pattern, not as targets. - Weeks 1–2 at 100 g: 1 event, 148 g. A rapid into the vise after a wrong work offset. - Week 3 at 60 g: 2 events, 66 g and 71 g. Both were end mills that broke in the cut and were replaced without a report. - Week 4 at 30 g: 23 events between 30 and 33 g, each as a face mill entered the cut on one job. None was a crash. - The highest routine peak is 33 g. The smallest real event is 66 g. The gap runs from 33 to 66 g. A 45 g threshold sits 45 − 33 = 12 g above routine work and 66 − 45 = 21 g below the smallest real event. **Result:** Threshold = 45 g: 12 g above routine peaks, 21 g below real events Figure: Four weeks of shocks on one mill on a 0 to 160 g scale: roughing 8 to 18 g, tool changes 15 to 24 g, face mill entry 30 to 33 g, broken end mills at 66 and 71 g and a crash at 148 g. A 45 g threshold sits in the gap. *Put the threshold in the gap between routine peaks and real events. Sample data.* > **Don't set it below normal work** > > A threshold under a machine's routine peaks turns every cycle into an alert, and people stop reading them within a week. This is also why shock detection suits CNC crashes and not presses: on a press, every stroke is an impact. ## What to do after a shock alert After a shock alert, keep the machine stopped, inspect it, log the cause and open a work order before the next part runs. A restart without a check is how a crash becomes a spindle failure three weeks later. | Check | How | Fail sign | |---|---|---| | Tool and holder | Look at edges, shank and taper | Chips, bends, scoring | | Spindle taper | Indicate runout at the taper | Runout past the builder's limit | | Spindle bearings | Run at low and mid speed, listen | New noise, heat or vibration | | Vise, fixture and part | Check jaws, locators and the part | Dents, shifted locators | | Machine accuracy | Probe or cut a reference feature | Dimension out of tolerance | Use the spindle runout limit and warm-up procedure from the machine builder's manual. Then record the incident in three places: - **The stop reason.** Classify the downtime as a tool crash, with the cause in the note: "Wrong offset, tool broke on part." A [reason code list](/blog/downtime-reason-codes/) with one crash code and a required note keeps causes comparable. - **The work order.** Open one for the spindle check and any repair, so the inspection is done and signed off rather than promised. [Opening work orders from downtime](/blog/work-orders-from-downtime/) covers the handoff. - **The fix.** Change the procedure that allowed it: an offset check on the setup sheet, a prove-out at reduced rapid or a second sign-off on new programs. ## Turn shock events into crash forensics *Crash forensics* is matching each shock event's time stamp to the job, program and shift that were running, so every crash has a cause and an owner. The event gives you the second it happened and how hard it hit. The plant's own records give you the rest. For example, a month of events on six mills might show five crashes. Matched to the job records, four came in the first hour after a setup, and three of those ran the same revised program. Review the log once a month, grouped three ways: - **By cause:** wrong offsets point to the setup sheet; broken tools point to tool life or feeds. - **By program or job:** a program with two crashes needs a prove-out, not a reminder. - **By shift and hour:** crashes clustered after setups or at shift start point to handover and training. The aim is a fix, not a culprit. A record that exists for every crash, reported or not, lets an operator say "it happened" without having to. ## Record every shock with IoTFlows IoTFlows records shocks with the sensor that already tracks uptime on each CNC: a SenseAi, or a [SenseAi Embedded](/products/senseai-embedded/) on the spindle motor where coolant reaches. Both detect shocks well past 200 g. The Abnormal Shock Detection rule fires above a threshold you set from 20 to 100 g, 100 g by default. Each event can email, push, text or post to chat, join the machine's event log with its value in g, and open a Maintain work order, as the [shock rule settings](/docs/alerts/asset-event-rules/#shock) describe. RNPSA, a mining equipment manufacturer in Matehuala, Mexico, put SenseAi sensors on its critical machines. [Its story](/customers/rnpsa/) reports zero silent failures (no undetected tool crashes or abnormal shocks) and 100% incident forensics, six months after deployment. ## When is a spindle-load monitor worth adding? A spindle-load monitor in the control is worth adding when you want the machine to stop itself, or to catch overload that builds slowly. A shock threshold records the impact; the control acts on load. Haas controls, for example, let the operator set a load limit for each tool. Past it, the control raises an alarm, enters feed hold or beeps, as Setting 84 selects, which can help prevent machine damage through tool failures.[3] | | Shock threshold on a sensor | Spindle-load monitor in the control | |---|---|---| | What it measures | Acceleration in g at the housing | Spindle load against a limit | | Set per | Machine | Tool | | Stops the axes itself | No | Yes, alarm or feed hold | | Catches a dull or overloaded tool | No | Yes | | Works on any brand or age | Yes | Only controls that offer it | | Keeps a fleet-wide event log | Yes | Needs a connection to the control | A threshold also misses impacts below it. A 3 mm end mill that snaps may never reach 45 g, and neither will a tool that wears until it rubs. > **Shock threshold, load monitor or both?** > > Start with a shock threshold on every CNC when the question is "did it crash, and when?", because it works on any machine and logs every event in one place. Add the control's load monitor on machines where a crash or a broken tool costs a spindle, such as high-speed spindles and lights-out cells, so the machine stops itself. Pulling that load data into a fleet-wide log means a connection to the control, a security concern for many plants that IT usually reviews first. Shock detection doesn't predict a failure; it records an impact the moment it happens. For gradual wear, such as a bearing damaged by an old crash, pair it with [condition-based maintenance](/blog/maintenance-strategies/#condition-vs-predictive). The [sensor and PLC comparison](/compare/sensor-based-vs-plc-machine-monitoring/) sets out what each approach sees. ## Questions ### Does a tool crash always damage the spindle? No, but you can't tell from the outside. A crash can break the machine at once, or leave it running normally while the spindle bearings carry damage that shows up weeks later as noise or lost accuracy. That delay is why every crash deserves a spindle check and a logged cause, even when the next part measures good. ### What shock threshold should I start with on a CNC mill? Start at the top of the sensor's alert range, so only severe impacts fire, and review every event for two weeks. Then lower the threshold in steps of 10 to 20 g, reviewing again after each step, until routine work such as tool changes or a face mill entering the cut starts to cross it. Settle one step above that point. ### Is shock detection the same as predictive maintenance? No. A shock threshold detects an impact that has already happened and records when and how hard it was. Predictive maintenance watches slow changes, such as rising vibration from a worn bearing, and acts before a failure. The two meet after a crash: watch the spindle's vibration trend over the following weeks for any change from its usual level. ### Can a vibration sensor stop the machine when it detects a crash? Stopping the axes is the control's job. A sensor mounted on the outside of the machine reads it without connecting to the control, so it can't change how the machine runs. It records the shock and alerts the people who need to know. For an automatic stop, use the control's own load limit, set to alarm or feed hold. ## Sources 1. [Avoiding That Crash](https://www.haas.co.uk/resources/better-techniques/control-tips/avoiding-that-crash/), Haas Automation UK, accessed Oct 27, 2026 2. [US 10,839,317 B2, Control device and machine learning device](https://patents.google.com/patent/US10839317), United States Patent and Trademark Office, via Google Patents, accessed Oct 27, 2026 3. [Protect Your Tools](https://www.haas.co.uk/resources/better-techniques/control-features/protect-your-tools/), Haas Automation UK, accessed Oct 27, 2026 --- # When the production schedule leaves no time for PM Source: https://www.iotflows.com/blog/pm-vs-production-schedule/ Book PM as a job on its machine so it takes capacity, time it to changeovers and weekends, price each deferral, and agree who decides when PM and orders clash. > Question: How do we fit planned maintenance into a full production schedule? ## Key takeaways - Preventive maintenance gets bumped because the schedule counts every shift hour as open to orders, so the first order that wants the slot wins. - Book each PM as a job on its machine, with its full duration, so the schedule plans orders around it. - Place PM beside changeovers and weekends, when the machine is already stopped, so each task costs fewer production hours. - Deferring a PM moves its hours into a later week, and it pays only when the late order costs more than the failure risk. - Agree before any collision that maintenance sets each PM’s window and the planner picks the slot inside it. You fit planned maintenance into a full production schedule by booking each PM as a job on its machine, with its own duration, so it takes capacity the way an order does. Then time each task to a stop the schedule already has, such as a changeover or a weekend, price every deferral before you grant it, and agree in advance who decides when a PM and an order want the same hours. This guide is for maintenance leads and plant managers whose PM list keeps losing to the order book. Building the task list itself is covered in [how to build a preventive maintenance schedule](/blog/preventive-maintenance-schedule/). ## Why does PM keep getting bumped? PM gets bumped because the production schedule treats the machine as always available. Capacity is the shift hours, every one of them is open to orders, and the PM lives in another system with no hours on the machine’s lane. For example, a Haas VF-2 on two 8-hour shifts has 80 hours a week. The planner loads 72 hours of orders and 4.5 hours of changeovers, a 95.6% load that looks efficient. The 4-hour way-lube and filter service due Wednesday has nowhere to go: the 3.5 hours left are Friday’s last hours, half an hour short and two days late. > **Definition.** **Planned downtime** is time a machine is scheduled not to produce, booked in advance for work such as preventive maintenance or a changeover, so it comes out of the hours the schedule can fill with orders. PM only becomes planned downtime once it holds hours on the schedule. Log the PM stop under a planned reason, as the [planned downtime](/docs/get-started/glossary/#planned-downtime) entry describes, so it stays out of your unplanned losses. Three habits keep the machine always available on paper: - **Two calendars.** Orders sit in the schedule and PM sits in the maintenance system, and nobody lays one over the other. - **No durations.** A PM with no hours on it can’t be reserved, even by a planner who wants to. - **Loads near 100%.** A machine planned to its last hour has no room for anything that wasn’t on the plan. [Loading each machine below its planned hours](/blog/production-scheduling-on-real-run-rates/#load) explains why queues explode past about 85%. ## Book PM as a job on the machine Book each PM as a job on the machine it stops, with a duration and a date, before any orders are loaded. The schedule then subtracts its hours the same way it subtracts a changeover. **Hours open to orders** = Shift hours − booked PM − booked changeovers On the VF-2, 80 − 4 − 4.5 leaves 71.5 hours, so the 72 hours of orders no longer fit. The schedule shows half an hour of overload at the end of Friday, a week ahead, instead of a skipped PM on Wednesday. Half an hour is a decision you can make: trim an order, move one to a twin machine, or book the PM beside a changeover. 1. **Create the PM as a job on its machine.** Title it so the floor can read it: `PM: way lube and filters, CNC-04`. Put it on the machine, never on a department or a cell. 2. **Give it the full time on the machine.** Count lockout, the work, restart and a first-part check. A 3-hour service with 30 minutes to lock out and 30 minutes to warm up and check the first part holds the machine for 4 hours. 3. **Place it inside its window.** Maintenance gives every PM a window, such as 3 days either side of the due date for a 4-week task. Book the job on a slot inside it. 4. **Pin it before orders are loaded.** Fix its date so re-sequencing and rush orders move around it, not through it. A PM that floats with the orders ends up after all of them. 5. **Load orders into the hours that are left.** Load the week against the hours open to orders. Any overload now appears as a late order you can see and price. Figure: One machine’s 80-hour week. Waiting for a gap, four orders and three changeovers fill 76.5 hours and the 4-hour PM due Wednesday has no slot. Booked as a job beside Wednesday’s changeover, it costs 2.5 hours and every order still fits. *The same week with the PM waiting for a gap and booked beside a changeover. Sample data.* ## Put PM where the machine already stops The cheapest hour for PM is one the machine is already stopped for. Booked beside Wednesday’s 1.5-hour changeover, the 4-hour service overlaps it, so it costs 2.5 hours of order time instead of 4, and the 72 hours of orders fit with 1 hour to spare. | Stop | Length, for example | PM that fits | |---|---|---| | Changeover | 1–2 h | Lube, filters, short inspections | | Break or shift meeting | 30 min | Operator checks | | Unscheduled shift | 8 h | Inspections and adjustments | | Weekend | 48 h | Rebuilds, spindle and ballscrew checks | | Planned shutdown | 3–5 days | Annual and multi-machine work | Overlap a PM with a changeover only when the two jobs don’t need the same access or the same lockout. To use changeovers, you need to know how long they really run. [Measuring changeover time](/blog/measure-changeover-time/) gives you the figure to book against. ### Let a usage meter open the window A calendar PM lands wherever the calendar says. A usage-based PM is due after a set number of run hours or parts, and an early warning before that point turns the due date into a window you can fit to the schedule. #### Worked example: A 400-run-hour service on a CNC mill - Interval: 400 run hours. The mill runs 12 hours each weekday, 60 a week, and sits idle at weekends, so it runs 3,000 hours in a 50-week year. - The 85% warning arrives at 340 hours, on Thursday of week 6. The trigger, 400 hours, arrives on Thursday of week 7. - The window holds a weekend at 360 hours and a changeover on Tuesday of week 7 at 375 hours. Servicing at the changeover every cycle gives 3,000 ÷ 375 = 8 services a year instead of 3,000 ÷ 400 = 7.5. - Each service at the changeover costs 2.5 production hours, so 8 × 2.5 = 20 hours. Each service on its own costs 4, so 7.5 × 4 = 30 hours. Technician time rises from 30 hours to 8 × 4 = 32. **Result:** At the changeover: 20 production hours a year instead of 30, for 2 more technician hours Figure: Run hours climb 60 a week toward a 400-hour trigger. The Early Alert at 340 hours opens a window that closes at 400 hours; the PM is booked at Tuesday’s changeover at 375 hours and the meter resets. *The early warning opens a window, and the PM goes on the first natural stop inside it. Sample data.* Size the warning so the window always spans at least one natural stop. [Warning early enough to stage the job](/blog/usage-based-maintenance/#warning) shows how to work out the lead time from daily usage. [Altium Packaging](/customers/altium-packaging/) runs a wear part on counts this way. Its Slide Knife is inspected every 100,000 bottles: the team gets an email as it gets close, and at 100,000 the inspection opens as a work order on its own. ## What does deferring a PM cost? Deferring a PM doesn’t save its hours. It moves them into a later week, which is usually just as full, and adds the risk that the failure the task prevents arrives first. Plants that lean on reactive maintenance pay for it in production time. In a NIST survey of 71 US manufacturing establishments, the half that relied most on reactive maintenance, 69% of their maintenance on average, lost 10.38% of planned production time to unplanned downtime. The half that relied least, at 22% reactive, lost 4.91%.[1] That second half also spent more on maintenance: 2.9 cents per dollar shipped against 1.6.[1] PM isn’t free. It trades maintenance hours for production time, and each deferral is a bet on that trade. #### Worked example: A rush order and a 4-hour PM want the same Wednesday - The machine’s output is worth $150 an hour of contribution. A rush order for 200 brackets needs Wednesday’s 4 hours to ship Thursday. - Keep the PM: the order ships Friday, and expedited freight to make up the day costs $800. - Defer the PM a week: if the way-lube failure it prevents happens in that week, the repair is a 16-hour stop and $2,500 in parts, so 16 × $150 + $2,500 = $4,900. - Deferring pays only if the chance of that failure in the extra week is below 800 ÷ 4,900. **Result:** Defer only if the chance of failure in the extra week is below 16.3% You rarely know that chance, but you do know the task’s as-found record. A task whose last service found the part worn near its limit fails the test. One that found the part like new three services running passes it, once. Put your own hourly figure in from [pricing an hour of downtime](/blog/cost-of-downtime/). ## Who decides when PM and an order collide? Maintenance decides whether a PM can move and how far. The planner decides where it goes inside that limit, and the plant manager decides only when someone wants to go past it. Write the rule down before the first collision, so nobody negotiates it on a Wednesday afternoon with a truck waiting. | PM type | Can it move? | Who decides | Limit | |---|---|---|---| | Dated by a regulation | No | Nobody | The due date | | Last as-found worn or borderline | Earlier only | Maintenance lead | The due date | | Routine, last as-found like new | Inside its window | Planner | End of the window | | On a usage meter | To a stop before 100% | Planner | The trigger point | | Already deferred once | Escalate | Plant manager | One more interval | Set each window when you write the task, not when it collides. A 4-week task might allow 3 days either side. A regulation-dated task has no window. OSHA requires each mechanical power press it covers to be inspected and tested at least once a week for the condition of its clutch/brake mechanism, antirepeat feature and single-stroke mechanism, with an exception for presses that meet the standard’s control-reliability and brake-monitoring requirements.[2] > **Keep, move or defer the PM?** > > Keep the date when a regulation sets it or the last service found the part worn. Move the PM earlier, to the last natural stop before its due date, whenever an order wants its slot. Defer it only inside its window, only once, and only when the late-order cost beats the failure cost in the example above. ## Run PM and production on one schedule In IoTFlows, Maintain and the Production Scheduler work on the same machines the sensors monitor. Maintain holds each PM as a recurring work order or a [meter](/docs/maintain/meters/#alerts) that emails at 85% and opens the work order at 100%, and its Calendar view shows the backlog by due date. In the [Production Scheduler](/platform/production-scheduler/), book the stop as a task on that machine with its time estimate, and choose **Lock scheduling** so the optimizer plans orders around it. The Schedule issues list flags any order [double-booked against it](/docs/production/schedule-issues/#double-booked), and a Simulation shows what moving the PM does to overdue work before you commit. ## Run a weekly PM and schedule review Collisions shrink when maintenance and planning meet before the week is released, not after it starts. Hold a 30-minute review each Thursday, with the maintenance lead and the planner, before next week’s schedule goes to the floor. 6. **Pull the next two weeks of PM.** List every calendar PM due in the next two weeks and every meter past its 85% warning, with each task’s hours on the machine. 7. **Match each PM to a natural stop.** Find a changeover, an unscheduled shift or a weekend inside each window. Book the PM beside it, or on its own slot when there is none. 8. **Book and pin before orders load.** Put every PM on the schedule as a job with its duration, and fix its date. Then let the planner load orders into what is left. 9. **Settle collisions with the written rule.** Apply the decision table to every clash. Anything past its window goes to the plant manager in the same meeting, not by email next week. 10. **Review last week’s misses.** Give each missed PM a cause: no slot booked, bumped by an order, part missing or estimate too short. When “bumped by an order” shows up every week, the load target is too high. Track PM compliance from the same list, counting a late PM as a miss. The first month shows which machines have no natural stops and which PM estimates are wrong, and both are fixed on the schedule, not on the shop floor. ## Questions ### How much capacity should I hold back for PM each week? Add up the hours each machine’s PM tasks need in a year, including lockout and restart, and divide by 52 for the average week. Hold that much back from the order load, then book each task in the week it falls due. A machine with a 4-hour service every 4 weeks averages 1 hour a week but needs all 4 hours in one of them. ### Should PM run on overtime and weekends instead of during shifts? Use the weekend when an hour of technician overtime costs less than an hour of lost output on that machine, which is common on the bottleneck. Keep PM inside shifts on machines with spare capacity, because the overtime buys nothing there. Plan weekend PM weeks ahead so the technicians, parts and lockout steps are ready on Saturday morning. ### What if a machine runs around the clock with no natural stops? Group its PM into planned shutdowns at a fixed interval, booked months ahead, and do every task due before the next shutdown in that stop. Most around-the-clock machines still change over, so put short tasks there. Keep any task a regulation dates on its date, whatever the shutdown plan says. ## Sources 1. [Maintenance Costs and Advanced Maintenance Techniques in Manufacturing Machinery: Survey and Analysis, International Journal of Prognostics and Health Management 12(1) (2021)](https://pmc.ncbi.nlm.nih.gov/articles/PMC9890517/), National Institute of Standards and Technology (D. Thomas and B. Weiss), via PubMed Central, accessed Oct 27, 2026 2. [29 CFR 1910.217, Mechanical power presses](https://www.law.cornell.edu/cfr/text/29/1910.217), Legal Information Institute, Cornell Law School, accessed Oct 27, 2026 --- # Turn a classified stop into a work order in the same step Source: https://www.iotflows.com/blog/work-orders-from-downtime/ Open the work order where the operator classifies the stop, so it starts with the machine, reason, time, duration and note. Decision guide and example inside. > Question: How does a machine stop become maintenance work without a phone call? ## Key takeaways - Open the maintenance work order where the operator classifies the stop, so the reason and the request are one action. - Turn a stop into a work order when it needs a technician or a part, or when it keeps coming back. - Keep changeovers, material waits, staffing gaps and short stops out of the maintenance backlog; they belong in the downtime report. - A work order from a stop carries five things: the machine, the stop reason, the down time, the duration and the operator's note. - Close the loop by reading the same stop reason on the same machine for four weeks after the repair. A machine stop becomes maintenance work without a phone call when the operator who classifies the stop opens the work order in the same step. The stop already holds the machine, its start time and its duration. The operator adds the reason and a note, so the work order starts from the machine’s own record while the machine is still down, not from somebody’s memory at the end of the shift. This guide is for maintenance leads and production supervisors who want breakdowns reported from the machine. It covers which stops should become work orders, what each one must carry, who triages them, and how to check that the repair held. ## What is a work order from a stop? A work order from a stop is a maintenance job opened from a recorded machine stop, at the moment someone puts a reason on it. > **Definition.** **Downtime work order** is a maintenance work order opened from a recorded machine stop while the stop is being classified, so it starts with the machine, the stop reason, the time the machine went down, how long it has been down and the operator’s note. A *work order* is one unit of maintenance work on one machine, as the [glossary entry](/docs/get-started/glossary/#work-order) defines it. What changes here is where it starts. Without the link, a stop reaches maintenance by word of mouth: the operator tells a supervisor, who calls or leaves a note, and the start time is whatever somebody remembers. The gap is measurable. NIST researchers built a list of work order data elements from real maintenance records at several manufacturers. The first timestamp on it is the *machine down time-stamp*, the date and time the machine goes down.[1] They call the gap from machine down to the work order being issued the *time to issue work order*.[1] On a phone path, that gap runs from minutes to a whole shift, and the down time is a guess. Opened from the classified stop, the gap is the time the operator took to classify, and the down time is the machine’s own. [A night-shift tool crash, reported both ways](/blog/what-is-a-cmms/#origins), shows the difference on one stop. ## Which stops should become work orders? A stop should become a work order when fixing it needs a maintenance skill or a part, or when it will come back until something on the machine changes. Everything else belongs in the downtime report, not the backlog. For example, a 40-minute changeover on a CNC lathe needs a setter, not a technician. A work order for it adds a job that somebody has to close for nothing. | Stop reason | Open a work order? | Why | |---|---|---| | Tool crash | Yes, every time | Check spindle, turret and fixture | | Hydraulic or coolant leak | Yes | Needs a technician and parts | | Motor, drive or electrical fault | Yes | Needs a qualified electrician | | Jam, once in a shift | No, add a note | The operator clears it | | Same jam, third time in a shift | Yes | It recurs until the cause is fixed | | Changeover or setup | No | Production work, already planned | | Waiting for material | No | A supply problem | | No operator | No | A staffing problem | | Short stops under the cutoff | No | A rule classifies them | | Quality hold | Only if the machine caused it | Worn tooling or drift is maintenance | | Planned maintenance | No, it has one | The PM is already a work order | Mark the maintenance reasons in your reason list once, so operators don’t decide stop by stop. The repeat rule is the one most plants miss. One 4-minute jam on a 200-ton press is an operator task. The third in a shift points at a worn guide or a misfeeding coil, and nobody reports it, because each jam alone looked minor. > **Should the operator or the reason decide?** > > Let the reason decide. Pick 3 to 6 reasons that always open a work order, such as Tool crash and Hydraulic leak, and make a note required on each. Leave the operator’s judgment for repeat stops only, with one threshold: the third stop with the same reason in one shift. A short reason list makes this work. [Which downtime reason codes to log](/blog/downtime-reason-codes/) covers the 8 to 12 codes operators pick from, and which stops a rule should classify instead. ## What must the work order carry? A work order from a stop must carry five things: the machine, the stop reason, the time the machine went down, how long it has been down, and the operator’s note. | Field | Example | Why maintenance needs it | |---|---|---| | Machine | Haas ST-20 lathe, Cell 3 | Where to go, and whose history it joins | | Stop reason | Coolant pressure low | Which skill and parts to bring | | Down time | Tuesday 10:02 | Starts the repair clock | | Duration so far | 2 min, still down | Whether production is waiting | | Operator note | Pump loud, gauge at 0 bar | What the technician would ask first | Add a photo when the cause is visible: a leak, a broken guard, a nest of chips around the chuck. Write the title as what is wrong, not what to do. “Coolant pressure low, pump noisy” lets the technician judge urgency, and “Fix lathe” doesn’t. The down time is the field a phone call loses first, and every repair measure depends on it. NIST’s list runs from machine down through technician arrival, problem found, parts ordered and received, problem solved and machine up, to work order completion.[1] Each repair metric is the gap between two of them. *Time to dispatch*, for example, runs from machine down to the technician arriving.[1] Figure: A coolant fault stops a CNC lathe at 10:02. The work order opens at 10:04, the technician arrives at 10:14 and the lathe runs again at 10:47: 2 min to issue, 12 min to dispatch, 45 min to repair. The work order stays open 61 min. *One stop, timestamp by timestamp, with the repair clock started by the machine itself. Sample data.* The same paper notes that *work order completion time*, from issue to close, is often used to approximate time to repair.[1] In the figure, the repair took 45 minutes, from 10:02 to 10:47. The work order stayed open 61 minutes, because the technician closed it after cleanup and the close-out note. Report repair time from the machine’s down and up times. Use the work order’s own dates for the backlog: how much is open, and for how long. ## Who triages a work order from a stop? One named person triages each shift’s work orders from stops: the maintenance lead or planner on day shift, and the senior technician on call at night. Triage is four decisions, made within minutes of the work order landing: is it maintenance, how urgent is it, who takes it, and does it need parts. Set urgency from two facts the work order already carries: whether the machine is still down, and how much an hour of that machine’s downtime costs. | Situation | Priority | Respond within | |---|---|---| | Constraint machine down now | Urgent | 15 min | | Other machine down now | High | 1 hour | | Running, same fault recurring | Medium | Same shift | | Running, wear noticed | Low | Next planned window | Example windows for a two-shift plant. Set yours from the cost of an hour of downtime on each machine. Three rules keep triage from becoming a second phone call: - **Assign before you diagnose.** A work order with an owner moves; a well-described one with no owner waits. - **Close, don’t delete, what isn’t maintenance.** Write why in the note and correct the stop’s reason, so the downtime report stays honest. - **Let operators open work orders.** Limiting creation to the maintenance office puts the handoff, and the guessed start time, back in the path. ## How do you close the loop? You close the loop when the stop reason that opened the work order stops recurring on that machine, and you check that in the downtime data, not in the work order’s status. Done means the technician finished. It doesn’t mean the cause is gone. The loop has four links: 1. **Stop reason.** The operator classifies the stop. 2. **Work order.** It opens in the same step, with the five fields. 3. **Repair.** The technician fixes the cause and writes what they found in the close-out note. 4. **Trend.** Somebody reads the same reason on the same machine every week for four weeks. #### Worked example: Coolant pressure faults on a CNC lathe - For four weeks, a Haas ST-20 lathe stops on Coolant pressure low 5 to 7 times a week. Operators reset the pump and restart, and nobody calls maintenance. - Those four weeks cost 112, 96, 108 and 116 minutes: 432 minutes, or 108 minutes a week. - In week 5, the plant makes Coolant pressure low a maintenance reason. At 10:02 on Tuesday, the operator classifies the stop and opens the work order in the same step. The technician replaces a worn pump impeller, and the lathe runs again at 10:47. - Weeks 6 to 8 cost 18, 0 and 15 minutes: 33 minutes, or 11 minutes a week. The weekly loss fell (108 − 11) ÷ 108 = 89.8%, which gives the lathe back 97 minutes of running time a week. **Result:** Loop closed: the reason fell from 108 to 11 minutes a week and stayed there for three weeks Figure: Weekly minutes of Coolant pressure low on one lathe: 112, 96, 108 and 116 in weeks 1 to 4, 81 in week 5 when the work order opened from the stop, then 18, 0 and 15. The weekly loss falls from 108 to 11 min. *The same stop reason before and after one work order opened from the stop. Sample data.* Each repeat stop fixed at its cause is a breakdown that stops coming back. In a NIST survey of 71 US manufacturing establishments, the half that relied more heavily on preventive and predictive maintenance had 52.7% less unplanned downtime than the half that relied most on reactive repairs.[2] A loop that turns repeat stops into repairs is how a plant starts moving work from reactive to planned. When a reason stays high after the repair, take it to the [weekly downtime review](/blog/downtime-root-cause-review/), which works a reason down to its cause and checks the fix per shift. When the same reason returns after two repairs, the machine needs a different trigger, such as run hours or a condition limit: see [how to choose a maintenance strategy](/blog/maintenance-strategies/). ## Open a work order from Classify Downtime In IoTFlows, the operator opens the work order from the same **Classify Downtime** dialog that puts the reason on the stop. A sensor detects the stop in seconds, with no PLC. The operator picks the reason, types the note and clicks **Create Maintenance Workorder**. The work order comes prefilled, with the reason as its title, the note as its description and the machine already set. **Submit Request**, then **Classify**, and both save from [one dialog](/docs/monitoring/classify-downtime/#work-order). The work order lands in the Maintain backlog as Open. RNPSA, a mining equipment manufacturer in Matehuala, Mexico, works this way. Before, an operator told the shift supervisor, who wrote a note, which the next shift supervisor read before calling maintenance. Now the “operator logs downtime and creates work order in one action,” and RNPSA halved its maintenance response time, as [RNPSA’s story](/customers/rnpsa/) describes. See how [Maintain](/platform/maintain/) works. ## Set it up in one week 1. **Mark the maintenance reasons.** Pick the 3 to 6 reasons in your list that always need a technician, such as Tool crash, Hydraulic leak and Electrical fault. Tell every shift that these reasons open a work order. 2. **Require a note on each one.** Make the note mandatory on those reasons. Ask for what the operator saw and heard, in one line: “Pump loud, gauge at 0 bar.” 3. **Set the repeat threshold.** Agree that the third stop with the same reason on the same machine in one shift opens a work order, whatever the reason. 4. **Name the triage owner for each shift.** Write down who triages on days and on nights, and the response window for each priority. 5. **Read the reason after every repair.** For four weeks after a work order closes, read its stop reason on that machine each week. If the reason is back, reopen the work order with the next question for the technician. 6. **Review closed work orders every month.** Count work orders closed as not maintenance, by reason. A reason with many is mislabeled, or too close to a production reason in the list. ## Questions ### Should operators be allowed to open maintenance work orders? Yes. The operator sees the stop first and knows what the machine was doing when it stopped. Sending the request through a supervisor or the maintenance office adds a handoff, and every handoff loses the stop time or a detail. Let operators open work orders from a short list of maintenance reasons, and let the triage owner close the ones that turn out not to be maintenance. ### What if the operator picks the wrong stop reason? Let the technician correct it when closing the work order, and change the stop's reason to match what they found. The downtime Pareto and the reason trend both read the stop's reason, so a wrong one hides the effect of the repair. Count corrections every month: a reason that is often wrong is named too vaguely or sits next to a similar one in the list. ### Should every machine stop open a work order automatically? No. A machine stops for changeovers, jams, breaks and material waits far more often than for repairs, so a work order on every stop fills the backlog with jobs nobody needs. Open work orders automatically only from events with one obvious maintenance response, such as a shock past the crash threshold, and let a person classify ordinary stops. ### How is a work order from a stop different from a maintenance request? It is a request that starts from the stop record. A request filed from a phone or a paper form carries only what the person types, often hours later. A work order opened while classifying the stop starts from the machine's own down time and the stop reason, so response and repair times can be measured from the machine instead of from memory. ## Sources 1. [Developing Maintenance Key Performance Indicators from Maintenance Work Order Data](https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=924883), National Institute of Standards and Technology (Brundage, Sexton, Morris, Moccozet, Hoffman), NAMRC/MSEC 2018, accessed Oct 27, 2026 2. [Maintenance Costs and Advanced Maintenance Techniques in Manufacturing Machinery: Survey and Analysis](https://pmc.ncbi.nlm.nih.gov/articles/PMC9890517/), International Journal of Prognostics and Health Management (Thomas and Weiss, NIST), accessed Oct 27, 2026 --- # Production line monitoring without PLCs Source: https://www.iotflows.com/blog/production-line-monitoring-without-plcs/ Yes. A laser counter at every step, read against Step 1, gives you line yield, the units lost at each step and the step that stopped first, with no PLC access. > Question: Can I monitor a whole line without touching the PLCs? ## Key takeaways - Sensors mounted outside the machines report running, stopped, unit counts and cycle times with no connection to any PLC. - A counter at every step, compared against Step 1, shows first pass yield and where each lost unit went. - When a line stops, look first at the step whose count stopped first, because the other steps stop in response. - Controller data adds alarm codes, programs and process values, and IT usually reviews that connection before it goes live. Yes, you can monitor a whole line without touching its PLCs. Read each step from the outside instead: a laser counter at every step counts the units that pass it, and a vibration sensor on a machine reports when it runs and stops. Compared in sequence, those counts give you line yield, the units lost at each step and the step that stopped first. This guide is for plant managers and engineers who want line-level numbers before, or instead of, a controller integration project. It works one hypothetical bagging line through from count points to rollout. ## What you can measure from outside a machine > **Definition.** **Retrofit monitoring** means measuring a machine with sensors added to its outside, such as a vibration sensor on the frame or a laser counter across a conveyor, so machine state and part counts come from what the machine does rather than from its controller. Two signals cover most of what a line manager asks. A sensor on a machine's frame reads its vibration and sound and decides whether it is running or stopped. A laser counter aimed across a conveyor counts every unit that breaks its beam, and the gap between units says whether that point on the line is moving. | Question | Signal | Source | |---|---|---| | Is the machine running? | Vibration and sound | Sensor on the machine | | How many units passed? | Beam breaks | Counter across the conveyor | | How fast is the step running? | Units per minute | Counter, from count timing | | How long was it stopped? | Gaps between units or cycles | Either sensor | | Which alarm fired? | Alarm code | Controller only | | Which program or recipe ran? | Program name | Controller only | The last two rows mark the line between the two approaches. Everything above them comes from outside the machines, and it answers the questions a daily production meeting asks: how much, how fast, how long down and where. Running time and unit counts also feed two of the three OEE factors, availability and performance, which [how to calculate OEE](/blog/how-to-calculate-oee/) works through by hand. ## Why line monitoring often starts at the PLC A *PLC* (programmable logic controller) is the computer that runs a machine's sequence. NIST groups industrial control systems under *operational technology*: programmable systems and devices that interact with the physical environment.[1] The glossary entry for [PLC](/docs/get-started/glossary/#plc) covers how monitoring sensors relate to one. The PLC already holds the count, the state and the alarms, so it looks like the obvious source. Getting the data out of every PLC on a line is where the work starts. ### Machines on one line speak different protocols A line assembled over 20 years can run on several networks at once. HMS Networks' 2026 analysis of newly installed factory network nodes puts PROFINET at 30%, EtherNet/IP at 25%, EtherCAT at 20% and Modbus TCP at 5% within Industrial Ethernet, with older fieldbus networks still at 14% of new nodes.[2] A bagger from one builder and a case packer from another can sit on two different ones, and a machine from the 1990s may have no network port at all. Each of those machines then needs its own adapter. AMT's MTConnect use case says it plainly: devices designed without MTConnect in mind “will always require a custom adapter”, and where no data can be extracted from a machine, the standard is impractical.[3] ### Access needs a review first [OPC UA](/blog/machine-communication-protocols/#opc-ua), a platform-independent framework for industrial data, lets a client read and write data based on access permissions.[4] A connection that can write to a controller is a security concern for many plants, and IT usually reviews it first. That review is sensible, so put it on the project plan from the first day. ## Put a counter at every step A count at the end of the line tells you how many good units came off it. It doesn't tell you how many started, or where the rest went. A counter at every step does, as long as you compare each step with the same reference. > **Definition.** **First pass yield (FPY)** is the share of units that pass through a process step, or a whole line, the first time without being rejected or reworked. On a line counted at every step, a step's FPY is its count divided by the count at Step 1. The glossary entry for [first pass yield](/docs/get-started/glossary/#fpy) uses the same formula. **Step FPY** = (Units counted at this step) ÷ (Units counted at Step 1) Comparing every step with Step 1, not with the step before it, keeps the figure cumulative. Step 4's FPY is the share of everything the line started that reached Step 4. #### Worked example: One shift on a four-step bagging line - Step 1, bagger: 24,000 bags formed and filled. - Step 2, checkweigher: 23,640 bags accepted past its reject chute. - Step 3, metal detector: 23,592 bags accepted. - Step 4, case packer infeed: 23,400 bags. FPY at Step 2 is 23,640 ÷ 24,000 = 98.5%. At Step 3 it is 23,592 ÷ 24,000 = 98.3%. At Step 4 it is 23,400 ÷ 24,000 = 97.5%. The loss at each step is the difference between two rows: 360 bags at the checkweigher, 48 at the metal detector and 192 between the detector and the packer infeed. **Result:** Line FPY = 97.5%, with 360 of the 600 lost bags at the checkweigher Figure: Four steps of a bagging line count 24,000, 23,640, 23,592 and 23,400 bags, for FPY of 100%, 98.5%, 98.3% and 97.5%. Bars of bags lost at each step show 360 at the checkweigher, 48 at the metal detector and 192 at the packer infeed. *A counter at every step turns one end-of-line shortfall into a loss at each step. Sample data.* The end-of-line count alone says the shift came up 600 bags short. The step counts say 60% of that loss is the checkweigher, so the first question is whether the bagger's fill weight is drifting, not whether the packer is dropping bags. > **Count after each reject point** > > A counter upstream of a reject chute counts bags the step is about to throw away. Mount each counter after the last reject or divert point of its step, where units run single file, and keep it off accumulation tables, where one unit can cross the beam twice. The full placement checklist, including clear containers, is in [choosing a count point](/docs/production/packaging-lines/#count-point). ## Find the step that stopped the line first Steps on a line are coupled. When one stops, the steps after it run out of units, and the steps before it fill whatever conveyor sits between them and stop too. Within a few minutes every counter on the line reads stopped, and only one of them caused it. The timestamps carry the answer. A counted step reads stopped once no unit has passed for longer than its *downtime filter*, the longest normal gap between units. Date each stop to its last unit, then sort: the earliest stop is the step to walk to first. Figure: Four timelines from 10:10 to 10:20 turn from running to stopped. The metal detector stops first at 10:14:20; the packer infeed follows at 10:15:05, the checkweigher at 10:16:10 and the bagger at 10:16:40. *Sorted by the last unit counted, the stops point at the metal detector. Sample data.* In the figure, the metal detector's last bag passes at 10:14:20. The packer infeed runs dry 45 seconds later. The checkweigher and the bagger fill their conveyors and stop at 10:16:10 and 10:16:40. The bagger operator sees only that the bagger stopped; the sorted timestamps send maintenance to the metal detector. Set each step's filter from its own normal gaps. A filter shorter than a normal pause, such as a case packer's index between cases, reads every pause as a stop. A filter far past the longest normal gap hides short stops. For fast continuous production, start at 15 to 45 seconds, as the [downtime filter guidance](/docs/hardware/calibrate-beamtracker/#downtime-filter) suggests. ## Add machine state where a count can't see A count says that a point on the line stopped moving. It doesn't say whether a machine with no passing units is running at all. A blow molder, a press feeding the line or a mixer upstream of a filler has a cycle, not a stream of units past one point. For those, mount a vibration sensor on the machine. It decides running or stopped from the machine's own vibration and sound, and derives cycle counts and cycle times from the trace. For example, a sensor on a 200-ton press feeding a packing line counts strokes, so the press reports as its own step even though nothing passes a beam there. > **Counter, machine sensor or both?** > > Use a counter at a step when units travel single file past a fixed point and you need yield or rate. Use a machine sensor when the step's output is a machine cycle rather than a passing unit. Put both on one machine only when you need its count and its own running state from the same place. You don't need a sensor on every machine to start. Counters at each step answer yield, rate and first stop. Add machine sensors where a step keeps stopping and the count can't say why. ## When you need controller data after all Outside sensors answer what the line did. Some questions need what only the controller knows. | | Outside sensors | Controller connection | |---|---|---| | Works on any machine age | Yes | No | | Needs a protocol adapter | No | For many machines | | Counts units at each step | Yes | Where the PLC counts them | | Reads alarm codes | No | Yes | | Reads programs and recipes | No | Yes | | Reads process values | No | Yes | | Connects to the machine's control | No | Yes, IT usually reviews it | For line yield, rate and the first stop, default to outside sensors. Choose a controller connection when a question depends on what only the control holds: which alarm stopped a filler, which recipe ran during a bad hour, what a sealer's jaw temperature was. Scope it to those machines and those signals, and have IT review the connection first. On cost, Kentucky's MEP center puts sensor retrofits at a few hundred to a few thousand dollars per machine, with installations usually completed within a few days.[5] A controller integration is scoped machine by machine, so its cost follows the adapters each machine needs. The two approaches combine: sensors on every step, controller data from the few machines where it pays off. The [sensor-based versus PLC comparison](/compare/sensor-based-vs-plc-machine-monitoring/) explains MTConnect and OPC UA in plain words. ## Monitor a line from outside in IoTFlows IoTFlows puts a [BeamTracker](/products/beamtracker/) at each step: an IP67 laser counter with ±2% count accuracy and a range up to 8 m that bolts on in 10 to 20 minutes. Group the steps into a cascade and every step after Step 1 shows its first pass yield, the units lost and its rate difference against Step 1, live. A SenseAi on a machine adds that machine's running and stopped state from its vibration and sound. Neither device connects to a PLC, and [the cascade reference](/docs/monitoring/asset-groups/#fpy) shows how each step reads. [Altium Packaging](/customers/altium-packaging/) counts every bottle this way on ten bottling lines in Memphis, at 20 to 140 bottles a minute. > Now we can talk through issues, help our operators and adjust operations in real time. We used to wait days or weeks for reports, then hold meetings and hope the team knew exactly what had happened. > > Steve Petti, Plant Manager, Altium Packaging ([story](https://www.iotflows.com/customers/altium-packaging/)) ## Roll it out on one line 1. **Pick one line with a known loss.** Choose a line whose yield or output your team already argues about, so the first numbers answer a real question. 2. **List the steps in order.** Write down every machine a unit passes through, Step 1 first. Step 1 is the reference for every FPY figure on the line. 3. **Choose a count point per step.** Place each counter after the step's last reject point, where units run single file and nothing else crosses the beam. 4. **Set each downtime filter.** Watch each step's normal unit-to-unit time, then set its filter a little longer than the longest ordinary pause. 5. **Validate each count.** Count units by hand at each step over a fixed window and compare. If a count reads exactly double or half, fix the quantity per cycle, as [troubleshooting part counts](/docs/production/troubleshoot-part-counts/#start) explains. 6. **Review the line every day.** Read the lowest-FPY step, the largest loss and the first stop of each long stoppage in the daily production meeting. Once one line reads correctly, copy its setup to the next. More guides on getting data off machines are under [machines and connectivity](/blog/topics/machines-and-connectivity/). ## Questions ### Can a laser counter see clear bottles or film? Clear glass and clear film may not break the beam reliably. Aim the beam at an opaque feature instead, such as the closure, the label band or the filled body of the container, or move the count point downstream and count cases rather than single units, with the case quantity set as the count per beam break. ### Can a sensor on the outside change how a machine runs? No. A sensor mounted on the frame or aimed across a conveyor has no connection to the controller, so it cannot change a setting, a program or a recipe. It reads the machine's vibration and sound, or the units passing a point, and the machine runs exactly as it did before. ### Do I need a sensor on every machine as well as a counter at every step? No. Counters at each step give line yield, units lost, rate and the step that stopped first. Add a vibration sensor to a machine when its output is a cycle rather than a passing unit, or when a step keeps stopping and you need that machine's own running and stopped state. ### How do I check that a step's count is right? Count units by hand at the step for a fixed window, then compare with the recorded count for the same window. A small difference is normal. A count that is an exact multiple or fraction of the real one, such as double or half, points to the quantity per cycle setting rather than to the sensor. ## Sources 1. [SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security](https://csrc.nist.gov/pubs/sp/800/82/r3/final), National Institute of Standards and Technology, accessed Oct 16, 2026 2. [Industrial network market shares report 2026](https://www.hms-networks.com/news/news-details/15-06-2026-annual-hms-report-2026), HMS Networks, accessed Oct 16, 2026 3. [Digital Manufacturing for Legacy Equipment Using a Standards-Based Approach: An MTConnect Use Case](https://www.amtonline.org/article/digital-manufacturing-for-legacy-equipment-using-a-standards-based-approach), AMT, The Association For Manufacturing Technology, accessed Oct 16, 2026 4. [OPC Unified Architecture](https://opcfoundation.org/about/opc-technologies/opc-ua/), OPC Foundation, accessed Oct 16, 2026 5. [Enhance Your Existing Equipment with Machine Monitoring](https://louisville.edu/servicecenters/news/enhance-your-existing-equipment-machine-monitoring), University of Louisville Service Centers (Kentucky MEP), accessed Oct 16, 2026 --- # How to run a weekly downtime review that fixes causes Source: https://www.iotflows.com/blog/downtime-root-cause-review/ Put five blocks on one page, take the top reason down to a cause someone can change, and check each fix against a target set in advance. Worked example inside. > Question: What goes on the weekly downtime report, and how do we turn it into fixes that stick? ## Key takeaways - A weekly downtime report needs five blocks: headline, reason Pareto, leading reason split, open actions and a fix check. - A reason code names what the operator saw; the review still has to find the cause behind it. - Ask why until the answer is a method, schedule or condition someone can change, not a person to blame. - Write the expected result on every countermeasure before the change, so the fix check has a number to beat. - Judge a fix on four weeks before and four after, per shift start or per scheduled hour, never on raw minutes. The weekly downtime report fits on one page with five blocks: stopped time against scheduled time, the reasons ranked by hours, the leading reason split by shift and machine, the open actions, and a check on earlier fixes. Fixes stick when the review takes one reason down to a cause someone can change, sets a numeric target before the change, and reads that reason for four weeks after. This guide is for plant managers whose operators already put a reason on most stops. If yours don't yet, start with [which reason codes to log](/blog/downtime-reason-codes/). ## What a downtime review is > **Definition.** **Downtime review** is a fixed weekly meeting where production, maintenance and shift leads read the past week's stopped time by reason, choose the one or two reasons to work on, assign each an owner and a target, and check whether earlier fixes held. The report is the input and the meeting is the method. A chart emailed on Monday that nobody acts on changes nothing on the floor. The trap the review exists to break is old. NASA's maintenance guide puts it plainly: when equipment fails repeatedly, maintenance personnel often fix only the symptoms and keep doing the same repairs.[1] The same guide sets four goals for root cause analysis: find the cause quickly and economically, correct the cause and not only its effect, help prevent recurrence, and instill a mentality of "fix forever".[1] A weekly review applies those goals to production downtime, and it drives any [plan to reduce machine downtime](/blog/reduce-machine-downtime/). For example, a plant that restarts a jammed infeed conveyor 20 times a week has a repair habit. The review asks why it jams. ## What goes on the one-page report? The A3 report, a practice Toyota pioneered, puts the problem, the analysis, the corrective actions and the action plan on a single sheet of paper.[4] The weekly downtime report is a lighter version of the same idea: five blocks, one page, read in order. Figure: A one-page weekly report for six lathes on two shifts. Headline: 40.0 of 480 scheduled hours stopped, 8.3%. Pareto led by Start of shift at 9.0 h, of which 8.4 h fall on second shift, spread over all six lathes. Then open actions and a fix check. *The five blocks of a weekly downtime report, read top to bottom. Sample data.* | Block | What it shows | Question it answers | |---|---|---| | 1. Headline | Stopped share of scheduled time | Is the week better or worse? | | 2. Pareto | Stopped hours by reason, longest first | Where did the time go? | | 3. Leading reason, split | Top reason by shift, machine and day | Is it spread out or concentrated? | | 4. Open actions | Cause, fix, owner, due date, target | Who is doing what, by when? | | 5. Fix check | Closed actions, before vs after | Did last month's fixes hold? | Rank the Pareto by hours, not by count of stops. Rank by dollars instead when one reason stops a constraint machine. Three rules keep the page honest: - **Show the stopped share, not only hours.** A four-day week shrinks hours with nothing improved. 40.0 stopped hours out of 480 scheduled is 8.3%, and that is the number to compare. - **Show unclassified time in the headline.** If Unclassified is one of the top three bars, the Pareto ranks missing reasons. Fix classification before you read anything else. - **Keep the fix check on the page.** Without block 5, the review keeps opening actions and never learns whether any worked. A *Pareto chart* ranks reasons by the time they cost, with a cumulative line, see the [glossary entry](/docs/get-started/glossary/#pareto-chart). To rank by money instead, price an hour first with [the cost-of-downtime method](/blog/cost-of-downtime/). ## Run the review in 30 minutes Hold the review at the same slot each week, Monday morning for the week before. Build the report before the meeting, so the 30 minutes go to decisions. 1. **Check classification, 5 minutes.** Read the unclassified share. If it rose, find the shift or machine where the habit slipped and fix that first. [Tracking every stop and its reason](/blog/how-to-track-machine-downtime/) covers the daily check that prevents this. 2. **Read open actions, 5 minutes.** Each owner gives one line: done, on track, or blocked and why. Blocked actions get a decision in the room, not next week. 3. **Check fixes that are due, 10 minutes.** For each action whose four-week check window has closed, compare the reason before and after against its target. Close it, or reopen it with a new countermeasure. 4. **Pick the next reason, 10 minutes.** Take the leading reason that has no open action. Assign one person to find its cause by next week, with a date. Limit the work to two new reasons a week. NASA's guide ranks recurring problems with Pareto analysis, then matches them to the people and money available.[1] Two actions that get finished return more running time than ten that stall. > **Weekly review or monthly review?** > > Run both. Use the weekly review to pick reasons, assign actions and catch slipping habits. Use a monthly review to read the cumulative effect of fixes, find problems that need engineering work or capital, compare shifts and set next month's targets. > > You don't need a daily root cause meeting. Deal with today's stops at the machine. Datwyler's injection molding plant in Ontario, California, runs this pattern on more than 20 machines: it reviews the Downtimes report week over week and month over month, with the reports emailed on a schedule. Week over week, the reports showed Tuesday shift transitions adding 8 to 10 minutes of downtime every week. Within six months the plant cut shift-changeover downtime by 50% and material-changeover downtime by 30%, as [Datwyler's story](/customers/datwyler/) describes. > By tracking downtime categorization week to week and month to month, we could see exactly where our biggest problems were and track whether our fixes actually worked. The 50% reduction in shift changeover time came directly from acting on patterns we saw in the historical reports. That's not luck; that's discipline meeting data. > > Brien Stevenson, Site Director, Datwyler ([story](https://www.iotflows.com/customers/datwyler/)) ## Find the cause behind the reason A reason code records what the operator saw: Start of shift, Waiting for material, Changeover. It doesn't say why. The person who owns the reason has a week to get from the code to a cause. ### Narrow the reason first Split the leading reason by machine, by shift and by day of the week before you ask why. [Drilling into the leading Pareto bar](/blog/downtime-pareto/#drill) works this through for a week of changeovers. The split tells you what kind of cause to look for: - **Concentrated on one machine:** look at that machine's condition, tooling or setup. - **Concentrated on one shift or day:** look at staffing, handovers and schedules. - **Spread across every machine and shift:** look at a shared method, policy or supply. Then read the operator notes on the stops. Make notes required on vague codes such as Other, using the [required-note setting on a downtime category](/docs/monitoring/downtime-categories/#note). Then go to the machine at the time the stops happen and watch one. ### Ask why until you can change something The Lean Enterprise Institute defines *5 Whys* as asking why repeatedly whenever a problem is encountered, to get beyond the obvious symptoms to the root cause.[2] Its example, from Taiichi Ohno, starts with a stopped machine and a blown fuse. It ends five answers later at a missing strainer that let metal scrap into a lubrication pump.[2] Replacing the fuse would have fixed the symptom, and the machine would have stopped again. The number five isn't the rule; the stopping point is.[2] Stop when the answer is something a person can change: a method, a schedule, a design, a setting or a supply. > **Definition.** **Root cause** is the earliest condition in a chain of causes that a team can change, and that, once changed, stops the same downtime reason from recurring instead of shortening the next repair. NASA's guide groups failure causes into general categories for further analysis: machinery, people, methods, materials, policies, environment and measurement error.[1] Use the list as a prompt when a why-chain stalls. #### Worked example: Start of shift on six lathes - Plant: six CNC lathes, two 8-hour shifts, five days a week, so 30 second-shift starts a week. - Week 4: Start of shift cost 9.0 hours, 8.4 of them on second shift, spread over all six lathes at 1.2 to 1.6 hours each. - Second shift lost 504 minutes ÷ 30 starts = 16.8 minutes per start. Weeks 1 to 4 together averaged 2,016 ÷ 120 = 16.8 minutes too. - On the floor: the inspector spends the first 10 minutes in the quality handover, then checks first parts one lathe after another, about 2 minutes each. - The k-th lathe waits 10 + 2 × k minutes. Averaged over k = 1 to 6, that's 10 + 2 × 3.5 = 17.0 minutes, close to the 16.8 measured. **Result:** The cause is the handover time, set when the plant ran one shift, not the operators Figure: Second-shift lathes sit 16.8 min per start because each waits for a first-part sign-off, one inspector checks all six in turn, and the 3:00 pm handover takes the first 10 min. Countermeasure: move it to 2:45 pm. *Four whys take the Start of shift code to a schedule someone can change. Sample data.* > **Is operator error your root cause?** > > Ask one more why. If a capable operator made the mistake, the method allowed it: a missing check, an unclear setup sheet, a fixture that fits two ways. Blame ends the analysis without changing anything, and the reason comes back next week. ## Write the countermeasure with a target > **Definition.** **Countermeasure** is the specific change a team makes to remove a root cause, written with an owner, a due date and the result it should produce, so the change can be checked against that result afterward. NASA's process asks for the expected improvement in performance when a problem is assigned, as the standard by which to measure possible solutions.[1] Write that number down before anything changes. Without it, any drop looks like success. Derive the target from the cause where you can. In the lathe example, moving the handover removes its 10 minutes and leaves the sequential checks: 2 × 3.5 = 7.0 minutes per start. That's the target. | Field | Lathe example | |---|---| | Reason | Start of shift, second shift | | Root cause | 3:00 pm quality handover delays checks | | Countermeasure | Move the handover to 2:45 pm | | Owner and due | Quality lead, Friday | | Target | ≤ 7.0 min per shift start | | Check window | 4 weeks after the change | Separate containment from the fix. *Containment* limits the loss this week, such as a lead operator checking first parts while the inspector is in the handover. The countermeasure removes the cause. Log both, and close the action only on the countermeasure. When the cause is equipment, the countermeasure is [maintenance work](/blog/what-is-a-cmms/#origins). [Open the work order from the stop itself](/blog/work-orders-from-downtime/), so it carries the machine, the reason and the operator's note: see [creating a work order from a stop](/docs/monitoring/classify-downtime/#work-order). ## Check that the fix held The PDCA cycle calls this step Check: evaluate the results against the targets. Then Act: standardize the change, or begin the cycle again.[3] Most reviews skip Check. The fix check block exists so they can't. Use four rules: 1. **Compare equal windows.** Four weeks before against four weeks after. One good week proves nothing. 2. **Normalize the reason.** Divide by shift starts, changeovers or scheduled hours, so a short week doesn't flatter the result. 3. **Compare against the target written before the change.** Not against whatever the after-number turns out to be. 4. **Check the neighbors.** If Start of shift falls and Waiting for inspection rises by the same minutes, the loss moved codes. Nothing was fixed. #### Worked example: Did moving the handover work? - Before, weeks 1 to 4: 516, 498, 498 and 504 minutes over 120 starts, so 16.8 minutes per start. - After, weeks 5 to 8: 204, 168, 174 and 162 minutes. Week 6 was a four-day week, so 24 starts, and 114 starts in all. - Per start after: 708 ÷ 114 = 6.21 minutes, and each week at or under the 7.0-minute target. - Raw minutes fell (2,016 − 708) ÷ 2,016 = 64.9%. Per start, they fell (16.8 − 6.21) ÷ 16.8 = 63.0%; the short week flatters the raw number. - Time back: (16.8 − 6.21) × 30 = 317.7 minutes a week, 5.3 hours of second-shift running time. **Result:** Target met: 63.0% less Start of shift loss per start, so the new handover time becomes the standard Figure: Weekly bars of minutes lost per second-shift start. Weeks 1 to 4 sit at 16.6 to 17.2 min. After the handover moved, weeks 5 to 8 read 6.8, 7.0, 5.8 and 5.4 min, at or under a dashed 7.0 min target: 6.2 min average, 63.0% less. *Four weeks before and four after, per shift start, against the target set before the change. Sample data.* Act on the result. A met target becomes the standard: update the shift schedule and the handover procedure, so the next quality lead inherits the fix. A missed target reopens the action with the next why. Either way, the reason stays in the fix check block for one more month, to catch drift. ## Build the report automatically IoTFlows detects every stop from a sensor on the machine, and operators put a reason on it in a tap. The Downtimes report ranks the reasons by hours and splits them [by interval and by machine](/docs/monitoring/downtimes/#trends), with filters for shift, category and notes, which covers blocks 2 and 3. Set the report to **Last 7 days** and [schedule it to email weekly](/docs/monitoring/share-and-schedule-reports/#schedule), so every attendee has the same page on Monday morning. Download the PDF for the meeting, or the CSV, one row per stop, when you build the before-and-after fix check. See [available exports](/docs/monitoring/exports-reference/). See how [downtime tracking](/solutions/downtime-tracking/) works from the sensor to the report. ## Start the review this week 1. Pick a fixed 30-minute slot and name who attends. 2. Build the five-block report for last week, and check that unclassified time is small. 3. Pick the leading reason, split it by machine, shift and day, and assign one owner to find its cause. 4. Write the countermeasure with an owner, a due date and a numeric target before anything changes. 5. Four weeks after each change, run the fix check per shift start or per scheduled hour, and standardize or reopen. ## Questions ### How long should a weekly downtime review take? Thirty minutes is enough when the report is built before the meeting. Spend the time on decisions, not on reading charts: check classification, read last week's actions, check fixes that are due, and pick at most two reasons to work on. A review that runs past an hour usually means the report was assembled in the room. ### Who should attend the downtime review? The production manager, the maintenance lead and the shift leads, because the leading reason usually crosses all three. Add the process or quality engineer when the reason under study sits in their area. Keep it under eight people; owners of open actions attend whether or not their reason leads the chart that week. ### What if the same downtime reason leads the Pareto every week? Then either the countermeasures are aimed at the symptom, or the reason code is too broad to point at one cause. Split the leading reason by machine, shift and day, read the operator notes, and check whether earlier fixes moved the minutes to another code. A reason that leads for months often needs an engineering change, not a procedure. ### Should every downtime event get a root cause analysis? No. Work the one or two reasons that cost the most hours and recur week after week. A one-off stop, such as a power cut, gets a note and a containment action. Spending the meeting on rare events leaves the large, repeating losses untouched, and those are the ones the Pareto exists to show. ## Sources 1. [Reliability-Centered Maintenance Guide for Facilities and Collateral Equipment](https://www.nasa.gov/wp-content/uploads/2023/06/nasa-rcmguide.pdf), National Aeronautics and Space Administration, accessed Oct 16, 2026 2. [Lean Lexicon: 5 Whys](https://www.lean.org/lexicon-terms/5-whys/), Lean Enterprise Institute, accessed Oct 16, 2026 3. [Lean Lexicon: PDCA](https://www.lean.org/lexicon-terms/pdca/), Lean Enterprise Institute, accessed Oct 16, 2026 4. [Lean Lexicon: A3 Report](https://www.lean.org/lexicon-terms/a3-report/), Lean Enterprise Institute, accessed Oct 16, 2026 --- # What is a CMMS, and why start it from the machine? Source: https://www.iotflows.com/blog/what-is-a-cmms/ A CMMS tracks work orders, PM schedules, assets and spare parts. See what it does for a plant, why hand-entered history misleads, and how to judge floor fit. > Question: What does a CMMS do for a production plant, and what makes one fit the floor? ## Key takeaways - A CMMS holds four records: work orders, assets, preventive maintenance schedules and spare parts inventory. - A work order is the unit of everything in a CMMS, so where work orders start decides how current the system is. - Work orders opened from machine stops and events carry the real stop time, which hand entry loses. - In a NIST case study, 93% of 21,107 work orders were closed on a Friday, so their recorded durations did not reflect the work. - Judge a CMMS by how fast an operator can file a request and how many work orders the machines open on their own. A CMMS (computerized maintenance management system) is the software where a plant requests, plans, records and reviews maintenance work. For a production plant it does four jobs: it turns machine problems into work orders, brings preventive tasks due, tracks spare parts and keeps each machine's repair history. It fits the floor when work orders start from what the machines report, with the stop time attached, instead of from somebody remembering to file one. This guide is for maintenance leads and plant managers choosing a CMMS or fixing one nobody uses. It covers what the system holds, where work orders should come from, why hand-entered history misleads, and how to judge fit. ## What is a CMMS? > **Definition.** **CMMS (computerized maintenance management system)** is software that records maintenance work orders against each machine, brings preventive maintenance due on a calendar or run-time schedule, tracks spare parts, and keeps the repair history that maintenance decisions are made from. The US Department of Energy’s operations and maintenance guide describes a CMMS as management software that supports managing and tracking maintenance activities. It adds that a CMMS makes no decisions: it gives the maintenance manager the information to make them.[1] Under every screen, a CMMS holds four records. | Record | What it holds | Question it answers | |---|---|---| | Work orders | One job: machine, people, parts, status | What needs fixing, and who has it? | | Assets | Machines and components, with manuals | What do we maintain, and where? | | PM schedules | Recurring tasks by date or run time | What comes due this week? | | Parts inventory | Stock by location, reorder points | Is the bearing on the shelf? | Everything else is a view of those four. The backlog is a filtered list of open work orders. A machine’s history is every closed work order that names it. A reorder list is the parts whose stock fell below their reorder point. ### CMMS, MES and machine monitoring Plants often confuse three systems that answer different questions. | System | Question it answers | Main record | |---|---|---| | Machine monitoring | What are the machines doing? | Run time, stops and part counts | | CMMS | What needs fixing, with which parts? | Work orders | | MES | What to make, and how did the run go? | Production orders and quality records | They meet at one point: a machine stop is a monitoring event, and the repair it needs is a CMMS work order. The side-by-side, with where each sits in ISA-95, is in [machine monitoring vs MES vs CMMS](/compare/machine-monitoring-vs-mes-vs-cmms/). ## What a CMMS does for a production plant The DOE guide lists the functions a CMMS covers, depending on the system.[1] Here they are with a plant example for each. | Function | Plant example | |---|---| | Work orders by machine and priority | Spindle fault on Haas VF-2 #3, high | | Searchable work order history | Every repair on Press 4, by date | | Calendar or run-time PM | Grease the spindle every 500 run hours | | Labor and cost by machine | Hours and parts spent on Molder 7 | | Time to close, by component | Median and worst repair on a gearbox | | Parts inventory with reorder | Reorder V-belts at 4 on the shelf | Choosing which PM goes on a date and which on run hours is its own decision, covered in [how to choose a maintenance strategy](/blog/maintenance-strategies/). A large share of that work doesn’t start as a plan. In NIST’s survey of US manufacturers, an average of 45.7% of machinery maintenance was reactive.[3] Each of those jobs starts with a failure that has to reach the CMMS, so where work orders come from decides whether the CMMS is current. The DOE guide frames the need as a set of questions.[1] Consider a CMMS when you can’t answer these from records: - When was this machine last serviced, by whom, and what did they find? - Which work is open right now, and who has it? - Are you waiting on parts, or carrying stock nobody uses? - Where are the manual and the lockout procedure for this machine? You don’t need one yet if one technician does every job on a handful of machines and keeps a log current. Move when a second person needs the same history, or when [PM tasks start slipping](/blog/preventive-maintenance-schedule/#compliance). > **Check the year on benefit claims** > > The DOE guide relays a survey by A.T. Kearney and Industry Week of 558 companies already using a CMMS. They reported an average 20.1% less equipment downtime and a 14.5-month payback.[1] The guide cites the survey from a 1994 CMMS product guide, so treat these as old, self-reported figures, not a forecast for your plant. ## Where work orders come from > **Definition.** **Work order** is one unit of maintenance work on one machine: what needs doing, who does it, which parts it uses, when it is due and what status it is in, from the moment it is opened until the work is signed off. A CMMS is only as current as its [work orders](/docs/get-started/glossary/#work-order). A work order can start in six ways, and each one fits a different kind of work. | Origin | Starts when | Fits | |---|---|---| | A planner | Someone fills in the form | Rebuilds, projects, one-off jobs | | An operator request | An operator reports a problem | Leaks, noises, loose guards | | A classified stop | A stop gets a maintenance reason | Breakdowns, tool crashes | | A machine event | Shock, health or heat crosses a limit | Faults with one obvious response | | A meter | Run hours or parts reach a trigger | Wear that follows use | | A recurrence | A date comes due | Inspections owed on a date | Pick the origin by who knows first. The machine knows first about a stop, a shock or its run hours. An operator knows first about a leak or a smell. A planner knows first about a rebuild. The DOE guide gives the machine-first pattern for an air filter. A pressure sensor reports when the filter needs changing, the CMMS opens the work order on that need instead of every three months, and the filter comes out of stock with a reorder if needed.[1] The same logic works for a spindle, a die or a mold. > **Which machine events should open work orders?** > > Open a work order automatically for events with one obvious maintenance response: a [shock above the crash threshold](/blog/cnc-tool-crash-detection/), a bearing health score past its limit, a motor over temperature. Keep a machine stopping or a sensor going offline as alerts only. They fire on every changeover, jam and network drop, and a backlog full of them hides the real work. The difference shows most on a night shift. On paper, a tool crash at 22:12 becomes a work order the next morning, with a start time somebody guesses. From the machine, the stop is on record to the second and the work order carries it. Figure: Two timelines for one tool crash at 22:12. The paper path runs through the operator, the supervisor and a note to day shift, reaching a work order at 06:40. The machine path records the stop at 22:12:04 and opens the work order at 22:15. *The same night-shift tool crash, reported by hand and from the machine. Sample data.* RNPSA, a mining equipment manufacturer in Matehuala, Mexico, describes its old path the same way: an operator told the shift supervisor, who wrote a note, which the next shift supervisor read before calling maintenance. Now the operator who classifies a stop opens the work order in the same step, and RNPSA halved its maintenance response time. > Continuous vibration monitoring gave us eyes we never had before. We can see tool crashes that would have been invisible, identify the exact moment and severity, and pull historical data to understand what went wrong. Add in Maintain, and suddenly operations and maintenance aren't working in silos, we're collaborating on the same data in real-time. That's transformed how we manage these critical machines. > > Miguel Silva, Systems Engineer, RNPSA ([story](https://www.iotflows.com/customers/rnpsa/)) ## Why hand-entered maintenance history misleads A CMMS computes response time, repair time and backlog age from timestamps. When people type those timestamps after the fact, every report built on them inherits the error. NIST researchers studied ten years (2009 to 2019) of HVAC work orders from a mixed laboratory and office site. Work orders opened across the whole working week, between 13% and 24% on each weekday. Yet 19,597 of 21,107, about 93%, were closed on a Friday.[2] Figure: Paired bars by weekday. Work orders opened at 22%, 24%, 21%, 19% and 13% from Monday to Friday, while 93% were closed on Friday and 3% or less on any other day. *Work orders opened all week and closed in Friday batches. Data from NIST’s HVAC case study.* The closings fell on only 520 days in ten years, about one close-out a week. The authors conclude that the closing dates almost certainly don’t match when the work finished, so durations computed from them can’t be trusted.[2] The dataset also lacked the timestamps needed for time to dispatch, one of the measures the authors ranked most important.[2] The site was a building, not a production line, but the cause transfers. The authors note that maintenance staff type work orders by hand, often under time pressure, into systems that fit their needs poorly.[2] Here is what a Friday batch does to mean repair time on a hypothetical CNC cell. #### Worked example: Five repairs, closed in one Friday batch - Five breakdowns are logged at Monday 09:00, Tuesday 14:00, Wednesday 08:00, Thursday 11:00 and Friday 07:00. - The technician closes all five at Friday 16:00. - The machines’ stop logs show each repair took 40, 90, 25, 60 and 35 minutes from stop to running again. From the CMMS dates, the five repairs take 103, 74, 56, 29 and 9 hours: 271 hours in all, or 54.2 hours each. From the stop logs, they take 250 minutes in all, or 50 minutes each. **Result:** The batch-closed history overstates mean repair time about 65 times: 54.2 h against 50 min. Take the start of a breakdown from the machine’s stop and its end from when the machine ran again. Then a late close-out changes the paperwork, not the repair time. That needs stop reasons that tell a breakdown from a changeover, which is what [downtime reason codes](/blog/downtime-reason-codes/) are for. ## What makes a CMMS fit the floor A CMMS fits the floor when the people and machines closest to a problem can put it on record in seconds. Check these in a trial, on your own machines. | Criterion | Ask the vendor, then test it | |---|---| | Work orders from stops | Does a classified stop open one? | | Work orders from signals | Which events and meters open one? | | Requests from the floor | How fast can an operator file one? | | Usage meters | Machine-counted, or typed in? | | Parts tied to the job | Does a job hold its parts? | | Pricing | Can every operator log in? | The last row matters more than it looks. Per-user pricing pushes plants to ration logins, and an operator with no login files no requests. The problem then travels by word of mouth, as on the paper path above. The DOE guide names the common ways a CMMS fails: the wrong system for the site, too little training for the staff who enter data, and no commitment to implement it and keep using it. It adds that feature overload is a common complaint, and that most successful installations have a champion who keeps people using it.[1] Choose a standalone CMMS when most of your work is facilities and building upkeep, or when your machines already report stops into a system you will connect. Choose a CMMS built on [machine monitoring](/blog/what-is-machine-monitoring/) when breakdowns and wear on production machines drive most of the work, because the stop, the run hours and the part count are already recorded. ## Start maintenance from the machine with IoTFlows IoTFlows Maintain is a CMMS built on machine monitoring. A work order is its only object: a request, a planned job and a preventive schedule are the same record with different fields filled in. Work orders open from [five places](/docs/maintain/overview/#origins): by hand, from a classified stop, from a machine event rule on health, shock or temperature, from a meter, or from an operator’s request in the job runner or on a phone. A [meter](/docs/maintain/meters/) counts runtime hours or parts, emails at 85% and opens the work order at 100%. A work order holds the parts it needs in Inventory, and marking it Done [moves the stock](/docs/inventory/how-work-orders-move-stock/). As of October 2026, [Maintain](/platform/maintain/) starts at $500 a month with unlimited users, on top of machine monitoring. Device plans are on the [pricing page](/pricing/). ## Roll out a CMMS your floor will use 1. **Load the machines that matter first.** Rank machines by what an hour of downtime costs, using [how to calculate the cost of downtime](/blog/cost-of-downtime/). Enter the top 10 with their manuals, lockout procedures and critical spares. 2. **Agree which stop reasons mean maintenance.** Mark the reasons that need a technician, such as tool crash, hydraulic leak and spindle fault, apart from changeovers and material waits. 3. **Give every operator a way to request work.** Put the request one step from the machine: on the operator screen, the job screen or a phone. Ask for a photo instead of a long description. 4. **Move recurring tasks in, and meter the wear items.** Enter each calendar PM as a recurrence. Move tasks on parts that wear with use to run hours or part counts, as in [usage-based maintenance](/blog/usage-based-maintenance/). 5. **Turn on machine-opened work orders one type at a time.** Start with shock events on CNC machines or health alerts on your most critical motor. Add the next type once the team triages the first within a shift. 6. **Read the history every month.** Count closings by weekday. If most work orders close on one day, your durations are batch close-outs, and repair times should come from the machine’s stops instead. ## Questions ### What is the difference between a CMMS and an EAM system? A CMMS manages maintenance work: work orders, preventive schedules, spare parts and repair history. An EAM (enterprise asset management) system covers the whole life of an asset across sites, adding purchasing, depreciation and replacement planning to the maintenance work. A single plant that needs work orders and parts control needs a CMMS. A company planning capital spending across many sites looks at EAM. ### Can a spreadsheet do the job of a CMMS? For one technician and a handful of machines, a shared spreadsheet can hold the work list and the service dates. It breaks when several people edit it at once, when preventive tasks need to come due on run hours, and when parts must be held for a job. It also records only what someone types, so its history inherits every late and missing entry. ### Who should be able to create work orders? Anyone who sees the problem first. Operators file requests at the machine, technicians open follow-up work, and planners write the scheduled jobs. A planner then reviews new requests, sets the priority and assigns them. Limiting work order creation to the maintenance office means every problem waits for somebody to walk over and report it. ### What is the difference between a work request and a work order? A work request is a report that a machine needs attention, filed by whoever sees the problem first, often an operator. A work order is the job maintenance agrees to do, with an assignee, a priority, parts and a due date. Some systems keep the two as separate records. Others treat a request as a work order with fewer fields filled in, which a planner completes. ## Sources 1. [Operations & Maintenance Best Practices: A Guide to Achieving Operational Efficiency, Release 3.0 (PNNL-19634), Chapter 4](https://www.osti.gov/servlets/purl/1034595), Pacific Northwest National Laboratory for the US Department of Energy, accessed Oct 16, 2026 2. [The Impact of Data Quality on Maintenance Work Order Analysis: A Case Study in HVAC Work Durations](https://papers.phmsociety.org/index.php/phme/article/download/2814/1781), National Institute of Standards and Technology (Conte, Bolland, Phan, Brundage, Sexton), PHM Society European Conference 2021, accessed Oct 16, 2026 3. [Economics of Manufacturing Machinery Maintenance: A Survey and Analysis of U.S. Costs and Benefits (NIST AMS 100-34)](https://nvlpubs.nist.gov/nistpubs/ams/NIST.AMS.100-34.pdf), National Institute of Standards and Technology, accessed Oct 16, 2026 --- # Add a shift, buy a machine or recover lost hours? Source: https://www.iotflows.com/blog/add-a-shift-or-buy-a-machine/ Recover lost hours first, add a shift when you can staff it and buy a machine when you can’t. Each route priced per good part on one CNC lathe, by hand. > Question: Should I add a second shift or invest in another machine? ## Key takeaways - Size a capacity gap in hours of planned production time at measured OEE before you price any option. - Recovered hours inside existing shifts are the cheapest capacity, and every later shift or machine inherits the higher OEE. - Overtime pays time and a half on wages and suits a small, temporary gap, not a lasting one. - A second machine that needs its own operator carries the same wages as a second shift, so capital and staffing decide between them. - Buy the machine when you can’t staff more hours, one operator can tend two machines, or demand outgrows the calendar. Add a second shift when the machine is your constraint, you can staff the hours and its measured availability already sits near what that machine type can reach. Buy another machine when you can’t staff more hours or demand outgrows the calendar. Before either, measure how much of its scheduled time the machine actually runs: recovered hours are the cheapest capacity, and every later shift or machine inherits them. The worked example below sizes a capacity gap in hours, prices four ways to close it on one CNC lathe, and ends with a decision guide. It’s for owners and plant managers who want the arithmetic before they sign a purchase order or post a job ad. ## Four ways to add capacity Every option adds good parts in one of two ways. It adds hours, or it makes more good parts in the hours you already pay for. The second way raises *OEE* (overall equipment effectiveness): availability × performance × quality, the share of planned time that turns into good parts at the ideal rate. | Option | What changes | What you pay for | |---|---|---| | Recover lost hours | OEE inside existing shifts | Engineering time, small tooling | | Overtime | Longer weeks for the same crew | Time and a half on wages | | Add a shift | Planned hours on the same machine | Wages, differential, supervision | | Buy a machine | Machines on the same shifts | Capital, install, floor, an operator | > **Definition.** **Capacity gap** is the difference between the good parts demand calls for in a period and the good parts the current schedule makes at measured OEE, expressed in hours of planned production time at that OEE. > **Definition.** **Recovered hours** are hours of planned production time that a machine already has on the schedule but loses to stops, slow cycles or scrap, and that it gets back as good output once those losses shrink. Measured hours come first because every option is priced against them. A plant that guesses its machines run 85% of the shift prices a new machine against hours that don’t exist. ## Size the gap in hours first Good parts per week follow from three numbers: the hours you schedule, the ideal rate and OEE. Turn the formula around to get the hours a demand needs. **Good parts per week** = Planned production hours × Ideal rate × OEE **Hours needed** = (Demand in good parts) ÷ (Ideal rate × OEE) The [OEE calculation](/blog/how-to-calculate-oee/) explains each factor. The example below uses one machine throughout the article. #### Worked example: One CNC lathe on one shift - Shift: 8.5 hours on site with an unpaid 30-minute lunch, 5 days, so planned production time is 40 hours a week. - Ideal cycle time: 2.4 minutes, so the ideal rate is 25 parts an hour and 1,000 parts a week. - Measured: availability 50%, performance 90%, quality 96%, so OEE is 0.50 × 0.90 × 0.96 = 43.2%. - Today: 1,000 × 0.432 = 432 good parts a week, or 10.8 good parts an hour. - A new order lifts demand to 648 good parts a week, 216 more than today. Hours needed at today’s OEE: 648 ÷ 10.8 = 60 hours. **Result:** The gap is 20 hours a week of planned production time at 43.2% OEE The operator loads and unloads every part, so the job needs a person at the machine for every hour it runs. That detail decides the labor cost of every option below. The same lathe shows why the calendar matters. *TEEP* (total effective equipment performance) is OEE multiplied by utilization, where utilization is planned production time over all time.[1] One 40-hour shift fills 40 ÷ 168 = 23.8% of the week, so TEEP here is 0.432 × 0.238 = 10.3%. The other 128 hours exist; the question is which ones you can buy cheapest. The [TEEP guide](/blog/utilization-uptime-oee-teep/) works the shift-pattern arithmetic in full. ## Recover lost hours first A machine that looks busy all shift can run far less than that. On a semi-automatic CNC, where an operator loads and unloads each part, measured uptime (availability) lands between 50 and 70%, and a goal of 60 to 75% is reasonable, as the [utilization ranges by machine type](/blog/utilization-goals-by-machine-type/#cnc) explain. The [CNC expectations table](/docs/production/cnc-machines/#expectations) gives the ranges for manual, semi-automatic and automatic machines. The lathe in the example sits at the bottom of its range, so it has hours to give back. Recovered hours come from three places: - **Changeovers.** Move setup work outside the stop and standardize it, see [how to measure changeover time](/blog/measure-changeover-time/). - **The top stop reasons.** Rank stopped time by reason and fix the first two bars, see [the downtime Pareto](/blog/downtime-pareto/). - **Short stops.** Pauses of a minute or two add up across a shift and hide inside performance, see [micro-stops](/blog/micro-stops/). Breaks add hours rather than recover them. A relief operator who covers the 30-minute lunch keeps the machine cutting, which adds 2.5 planned hours a week on this shift for the cost of the relief operator’s time. #### Worked example: Raise availability on the same lathe from 50% to 62.5% - New OEE: 0.625 × 0.90 × 0.96 = 54.0%, or 13.5 good parts an hour. - One shift now makes 40 × 13.5 = 540 good parts, 108 more than today. - Hours needed for 648 good parts: 648 ÷ 13.5 = 48 hours. - The improvement work (a setup cart, preset tools and an engineer’s time) costs $6,000 once in this example. **Result:** Recovery adds 108 of the 216 parts; the other 108 take 8 hours a week at 54% OEE, down from 20 Figure: Good parts a week on one lathe: 432 today, 540 after raising availability to 62.5%, 648 with recovery plus 8 overtime hours or with 20 overtime hours alone, and 864 with a second shift or a second machine. Demand is 648. *Each route to a 648-part weekly demand on one CNC lathe, at today’s 43.2% OEE unless marked. Sample data.* > **Count only recovery you have measured** > > An estimate of lost time is not a plan. Put a number on the recovered hours from a month of measured stops before you subtract them from the gap, or the order arrives and the hours don’t. ## What overtime, a shift and a machine cost Price each option per week, with the same assumptions for all four. Wages come from BLS; the differential, overhead and machine price are example values to replace with your own. Material, tooling and power cost the same per part on any route, so they drop out. - **Wage:** $30 an hour. Production and nonsupervisory workers in manufacturing averaged $30.21 an hour in September 2026 (preliminary).[2] - **Loaded cost:** 1.5 times wage, or $45 an hour. Manufacturing employers paid $48.62 an hour in total compensation against $32.50 in wages in June 2026, a ratio of 1.50.[3] BLS measures these costs per hour worked.[4] - **Overtime:** time and one-half on the regular rate for hours over 40 in a workweek, for covered nonexempt employees.[5] That is $45 in wages per overtime hour. Per-person benefits such as health insurance don’t grow with the extra hours, and this example leaves payroll taxes out. - **Shift differential:** $2 an hour. The FLSA requires no extra pay for night work; it is a matter of agreement between employer and employee.[6] Use your own rate. - **Second-shift overhead:** $300 a week as this machine’s share of a supervisor, maintenance cover and lighting for the added hours. - **Machine:** $180,000 installed, spread over 10 years of 50 working weeks, or $360 a week before financing. ### Overtime Twenty overtime hours cost 20 × $45 = $900 a week, and the operator works 60 hours. In US workers followed from 1987 to 2000, jobs with overtime schedules carried a 61% higher injury hazard rate than jobs without, and 60 or more hours a week a 23% higher rate.[7] Use overtime as a bridge while you recover hours or hire, not as the plan for a lasting order. ### A second shift A second operator on the lathe from 4:30 PM costs 40 × ($45 + $2) + $300 = $2,180 a week. The shift adds 40 planned hours and 432 good parts at today’s OEE, twice what this order needs, so half of it waits for the next order. ### A second machine A second lathe on the day shift needs its own operator, because this job keeps a person at the machine for every cycle. It costs 40 × $45 + $360 = $2,160 a week and also adds 432 good parts. It also brings its own empty calendar: 128 unscheduled hours a week on a machine you now own. Price that before you sign, see [the cost of idle machines](/blog/cost-of-idle-machines/). The labor term is what moves this result. If a bar feeder lets one operator tend both lathes, the second machine costs about $360 a week plus the time to load bar stock. That is the price of 8 overtime hours, for 432 more good parts. ## Compare the options side by side Put the four routes side by side, all closing the same 216-part gap. Each cost per part divides the weekly cost by those 216 parts. #### Worked example: Four ways to make 648 good parts a week - Overtime only: $900 a week, or 900 ÷ 216 = $4.17 per added good part. - Recover, then 8 overtime hours: 8 × $45 = $360 a week, or $1.67 per added part, plus $6,000 once. - Second shift: $2,180 a week, or $10.09 per added part, with 216 parts of spare capacity. - Second machine with an operator: $2,160 a week, or $10.00 per added part, with 216 parts of spare capacity. Recovery saves $900 − $360 = $540 a week against overtime alone, so the $6,000 pays back in 6,000 ÷ 540 = 11.1 weeks. **Result:** Recover first: $360 a week and an 11.1-week payback beat every other route for this order Figure: Weekly cost to reach 648 good parts: $360 for recovery plus 8 overtime hours (with $6,000 once), $900 for 20 overtime hours, $2,160 for a second machine with an operator and $2,180 for a second shift. *Weekly cost of each route to the same 648 good parts; the shift and the machine also buy 216 spare parts. Sample data.* The answer changes when demand reaches twice today’s output. At 864 good parts a week, overtime alone would need 864 ÷ 10.8 = 80 hours, and recovery plus overtime would need 64-hour weeks. A second shift and a second machine both make 1,080 good parts at the recovered 54% OEE, so both cover the order. Their weekly costs differ by $20, so the choice turns on staffing, capital and how long the demand lasts. | | Recover hours | Overtime | Second shift | Second machine | |---|---|---|---|---| | Good parts added here | 108 | 216 | 432 | 432 | | Weekly cost here | None | $900 | $2,180 | $2,160 | | One-time cost here | $6,000 | None | Hiring and training | $180,000 | | Needs new hires | No | No | Yes | Yes, unless tended | | Ends with the order | Gain stays | Yes | Yes | No | | Lifts later options | Yes | No | No | No | One CNC lathe, one 40-hour shift, demand of 648 good parts a week. Sample data. ## Why measured availability changes the answer The input that moves every hour above is availability, and it’s the one input a plant can’t read off the routing. Hold performance at 90% and quality at 96%, change only availability, and the hours needed for 648 good parts move by 20. | Availability | Good parts an hour | Hours for 648 | Fits one shift | |---|---|---|---| | 50% | 10.8 | 60.0 | No | | 62.5% | 13.5 | 48.0 | No | | 70% | 15.12 | 42.9 | No | | 75% | 16.2 | 40.0 | Yes | Ideal rate 25 parts an hour, performance 90%, quality 96%, 40 planned hours a week. Sample data. A planner who assumes 75% sees an order that fits one shift. The measured 50% says it needs 60 hours. Either number leads to a confident decision, and only one of them matches what the floor produces. The same arithmetic catches a common mistake. A second machine run the same way as the first inherits the same losses, so it adds 432 good parts, not the 540 the first machine could reach. Fix the losses on one machine and both shifts or both machines carry the gain. Measured [utilization](/docs/get-started/glossary/#utilization) depends on the denominator you choose. The [machine utilization guide](/blog/what-is-machine-utilization/) works through four of them. Use the one that matches planned production time here. ## Measure the hours before you decide IoTFlows puts a SenseAi sensor on each machine. It reads vibration and sound from the outside and decides running or stopped every second, with no PLC connection. The Advanced Report gives each machine’s utilization over a month or a quarter. Its **Shifts** filter counts only the hours inside the shifts you tick, so you can [set the period and filters](/docs/monitoring/advanced-report/#filters) to compare a day shift with a trial second shift. Storm Power Components doubled machine utilization, met growing demand with its existing equipment and now schedules on real utilization data. Read the [Storm Power story](/customers/storm-power-components/). [Production Scheduler](/platform/production-scheduler/) plans jobs on the same machines the sensors monitor, so a schedule uses the real part count. ## Choose shift, machine or recovery Work through the options in this order. Each one is cheaper to try and easier to undo than the next. Recover lost hours first when: - measured availability sits below the range for that machine type; - a few stop reasons or changeovers hold most of the stopped time; - the order starts more than a few weeks out, so the fixes have time to land. Use overtime when: - the gap is a few hours per person per week; - the order is temporary, or it bridges the weeks until a hire starts. Add a shift when: - the machine is your constraint and its availability sits near the top of its range; - you can hire and train operators for the added hours; - the demand looks lasting but not certain, since a shift can be dropped. Buy a machine when: - you can’t staff more hours; - one operator can tend two machines, so the labor term disappears; - demand exceeds what a full calendar makes at the recovered OEE; - one machine is a single point of failure for a product line. > **Not sure the demand will last?** > > Choose the shift. It costs about the same per week as a machine in this example, and you can end it when the order ends. A machine stays on the books for its full life whether the order repeats or not. Before you sign either, run this check: 1. Measure a month of availability, performance and quality on the machine. 2. Compute the gap in hours at measured OEE, not at the rate on the routing. 3. Subtract only the recovery you have measured from the gap. 4. Price the remaining hours four ways with your own wage, differential and machine quote. 5. Plan the order on measured run rates, see [production scheduling on real run rates](/blog/production-scheduling-on-real-run-rates/). ## Questions ### Is overtime cheaper than hiring for a second shift? Per hour the two land close. Overtime pays time and a half on wages, while a new hire costs wages plus benefits, about 1.5 times wages in manufacturing. Overtime adds no shift differential and no extra supervision, so it wins for a small gap that lasts a few weeks. It loses once hours per person climb toward 60 a week, where reported injury rates rise. ### Does a second machine need a second operator? Only when the job needs a person at the machine for every cycle. A lathe with a bar feeder or a mill with a pallet changer can keep cutting while one operator tends two machines, and then the new machine adds its ownership cost and little labor. Time one full cycle and count the minutes the operator is busy before you price the purchase. ### How much should utilization rise before I buy a machine? Compare measured uptime with the range for that machine type, not with 100%. A semi-automatic CNC, where an operator loads and unloads every part, runs 50 to 70% uptime, so a machine at 50% has hours to recover and one at 70% has few. Buy when the machine sits near the top of its range and the gap remains. ### Should I add a third shift or a weekend crew instead? Run the same arithmetic. A third shift or a weekend crew adds planned production time on machines you already own, so it carries wages, any differential your agreement sets and the overhead of covering those hours, but no capital. Check how long it takes you to fill a night or weekend opening before you count on those hours in a quote. ## Sources 1. [TEEP: Calculate Total Effective Equipment Performance](https://www.oee.com/teep/), Vorne Industries (OEE.com), accessed Oct 16, 2026 2. [Industries at a Glance: Manufacturing, NAICS 31-33](https://www.bls.gov/iag/tgs/iag31-33.htm), US Bureau of Labor Statistics, accessed Oct 16, 2026 3. [Employer Costs for Employee Compensation, Table 4: private industry workers by occupational and industry group](https://www.bls.gov/news.release/ecec.t04.htm), US Bureau of Labor Statistics, accessed Oct 16, 2026 4. [Employer Costs for Employee Compensation, June 2026 (news release)](https://www.bls.gov/news.release/ecec.nr0.htm), US Bureau of Labor Statistics, accessed Oct 16, 2026 5. [Overtime Pay](https://www.dol.gov/agencies/whd/overtime), US Department of Labor, Wage and Hour Division, accessed Oct 16, 2026 6. [Night Work and Shift Work](https://www.dol.gov/general/topic/workhours/nightwork), US Department of Labor, accessed Oct 16, 2026 7. [The impact of overtime and long work hours on occupational injuries and illnesses: new evidence from the United States (Dembe et al., 2005)](https://doi.org/10.1136/oem.2004.016667), Occupational and Environmental Medicine 62(9):588–597, accessed Oct 16, 2026 --- # How to build a preventive maintenance schedule that holds Source: https://www.iotflows.com/blog/preventive-maintenance-schedule/ A PM schedule holds when every task has an owner, a time estimate and a booked stop. Build the task list, level the weekly hours and track PM compliance. > Question: How do I set up recurring PM so it actually gets done? ## Key takeaways - A preventive maintenance schedule holds when every task has one owner, a time estimate, a parts kit and a booked machine stop. - Add up each task’s hours per year and divide by 52 to see the weekly PM load before you set any dates. - Stagger first due dates so no week carries more PM hours than your technicians have left after reactive work. - Fixed intervals keep the number of services a year; floating intervals lose services every time a job runs late. - PM compliance counts tasks done inside their window against tasks due, and every miss needs a named cause. You set up recurring PM that actually gets done by giving each task an owner, a time estimate, a parts kit and a booked machine stop, then spreading the due dates so every week fits the hours your technicians have. A schedule breaks on load before it breaks on intent: forty tasks all due the first week of the month can’t be finished by two technicians, so they slip, and the slips pile up. This guide is for maintenance leads building or rebuilding a calendar PM program. Tasks that should fall due on run hours or part counts have their own guide: [usage-based maintenance](/blog/usage-based-maintenance/). ## What is a preventive maintenance schedule? > **Definition.** **Preventive maintenance (PM) schedule** is the set of recurring maintenance tasks for a plant’s machines, each with an interval, a time estimate, an owner and its next due date, so the work is planned and staffed before anything fails. NASA’s reliability-centered maintenance guide defines PM as regularly scheduled inspection, adjustment, cleaning, lubrication, parts replacement, calibration and repair, set at predefined intervals of time, operating hours or cycles, and done regardless of the equipment’s condition.[1] In IoTFlows, [preventive maintenance](/docs/get-started/glossary/#preventive-maintenance) is that schedule stored as a recurrence rule on a work order. PM pays when it’s done. The US Department of Energy’s O&M guide estimates that a preventive program saves 12% to 18% in cost over a purely reactive one, and lists its costs plainly: it’s labor intensive and includes maintenance the equipment didn’t need.[2] A schedule that holds keeps the savings and trims the second list. ## Build the task list from the machines A PM schedule starts as a list of machines, not a list of dates. Build it in this order. 1. **List every machine by name and ID.** One row per machine, with the identifier the floor uses: `CNC-04 Haas VF-2`, `PR-02 200-ton press`. A task that names “the mills” has no single owner and gets done on none of them. 2. **Rank each machine by what a failure costs.** Ask whether a failure stops shipments or the line’s slowest machine, creates a safety hazard, or leaves no backup to take the work. A press with no twin that feeds two assembly cells ranks above a third saw in a cell of three. [Pricing an hour of downtime](/blog/cost-of-downtime/) puts a number on each. 3. **Pull tasks and intervals from the manual.** Copy each task and interval from the manufacturer’s maintenance section. NASA’s guide adds that intervals should reflect the machine’s location, application and operating environment, and that schedules need adjusting where parts and service are hard to get.[1] 4. **Add every task a regulation dates.** OSHA requires each mechanical power press the standard covers to be inspected and tested at least once a week for the condition of its clutch/brake mechanism, antirepeat feature and single-stroke mechanism, unless the press meets the standard’s control-reliability and brake-monitoring requirements. The standard also requires a record of each maintenance task, with its date, the signature of the person who did it and the press’s identifier.[4] 5. **Cut tasks that prevent nothing.** Delete tasks nobody can tie to a failure mode. NIST relays an estimate that preventive maintenance is applied unnecessarily up to 50% of the time in manufacturing.[3] ### Decide which machines get PM Not every machine needs a PM task. NASA’s guide reports that more than 90% of the hardware analyzed showed no adverse age-reliability relationship, and that an arbitrary preventive task often raises the failure rate by restarting early-life failures.[1] The [failure patterns behind each maintenance strategy](/blog/maintenance-strategies/#failure-patterns) explain why. > **Which machines get a PM task?** > > Put a machine on PM when its failure is costly and the task prevents a wear failure the manual describes, such as lubrication, filters or belt tension. Watch its condition instead when it fails at random but gives a measurable warning first. Let it run to failure, with a spare on the shelf, when a breakdown costs less than a year of PM labor: a $150 bench fan doesn’t need a quarterly task. ### Write each task so anyone can do it A task that only its author can do gets skipped when the author is out. Write each one as a card, or as a work order in a [CMMS](/blog/what-is-a-cmms/), with these fields. | Field | What to write | Example | |---|---|---| | Asset | One machine, by name and ID | CNC-04 Haas VF-2 | | Steps | A checklist, with a limit on each check | Way lube between MIN and MAX | | Estimate | Minutes, from the last three services | 60 min | | Machine state | Running, stopped or locked out | Stopped and locked out | | Parts | The kit, staged before the day | 1 coolant filter, 4 L way oil | | Owner | One named person or team | Second-shift technician | | As-found | Like new, borderline or worn past limit | Borderline | The estimate is the field most schedules leave blank, and it’s the one the rest of this guide depends on. Record it as minutes on the work order, as the [time estimate field](/docs/maintain/create-a-work-order/#estimate) does, and correct it from what the job takes. ## Size the workload before you set dates Before any task gets a date, add up how many technician hours the whole list needs in a year. Divide by 52 for the average week. **Weekly PM hours** = Sum of (hours each × services a year) ÷ 52 Take a hypothetical job shop with 10 CNC machines, 2 mechanical presses and 2 air compressors. Its PM list after the steps above looks like this. | Task | Machines | Interval | Hours each | Hours a year | |---|---|---|---|---| | Clutch and brake inspection | 2 presses | Weekly | 0.5 | 52 | | Way lube, coolant and filters | 10 CNC | Every 4 weeks | 1 | 130 | | Drain and filter check | 2 compressors | Every 4 weeks | 0.5 | 13 | | Inspection and adjustment | 10 CNC | Every 12 weeks | 3 | 130 | | Lube system and gib check | 2 presses | Every 12 weeks | 1.5 | 13 | | Spindle, ballscrew and level | 10 CNC | Annual | 6 | 60 | | Compressor service | 2 compressors | Annual | 4 | 8 | Sample data. A task every 4 weeks runs 13 times a year; a task every 12 weeks runs 52 ÷ 12 = 4.33 times. The list needs 406 hours a year, or 406 ÷ 52 = 7.8 hours a week. Now compare that with the time you have. Two technicians give 80 hours a week, and if reactive work averaged 55 hours a week last quarter, 25 hours are left for planned work. At 7.8 hours a week, the list fits with room to spare. It still fails if the hours land in the wrong weeks. ## Level the load across the weeks The quickest way to build a PM schedule is to enter every task on the day you build it. Every interval then starts on the same date, and every task with a shared interval comes due together, forever. #### Worked example: The same PM list, due all at once and spread out - Annual tasks aside, every task first due in week 1: week 1 carries 1 hour of press inspections, 11 hours of 4-week tasks and 33 hours of 12-week tasks, 45 hours in all. - Weeks 5 and 9 carry 12 hours each. The other nine weeks carry 1 hour each. - Spread out: two or three CNC lube tasks a week, one CNC inspection a week in weeks 1 to 10, each in a week that machine’s lube task is due, the compressor drains in the lighter weeks, and the 12-week press checks in weeks 11 and 12. **Result:** Peak week: 45 hours unleveled, 7 hours leveled, for the same 78 hours over 12 weeks Figure: Two bar charts of PM hours over 12 weeks. With every task first due in week 1, week 1 needs 45 hours against 25 available, and weeks 5 and 9 need 12. With due dates spread out, no week needs more than 7 hours. *The same 78 PM hours over 12 weeks, due all at once and spread across the weeks. Sample data.* Week 1 needs 20 hours more than the technicians have. Those 20 hours roll into weeks that are already full of reactive work, and by week 5 the next wave arrives on top of them. That’s how a schedule stops holding in its first month. Three rules keep a schedule level: - **Stagger first due dates.** Give each machine’s task a different first date. The interval carries the stagger forward on its own. - **Nest the intervals.** Use intervals that are multiples of each other: 1, 4 and 12 weeks. Start a machine’s 12-week inspection in a week its 4-week task is due, and the two land together every time, so both happen in one stop. - **Cap the week, not the month.** Check the busiest week against the hours left after reactive work, not the monthly total. An annual task doesn’t nest into a 4-week cycle, so place it by hand. Ten 6-hour spindle checks in one week is 60 hours; one a month is 6. ## Fixed or floating intervals? Every PM schedule makes one more choice, often without knowing it. A *fixed* interval counts each due date from the first one, so a late job doesn’t move the next. A *floating* interval counts the next due date from the day the last job was finished. #### Worked example: A 4-week lube task, done 1 week late every time - Fixed: due in weeks 0, 4, 8 and so on to 48. Each job is done a week after its due date, and the next due date stays put. That’s 13 services in 52 weeks. - Floating: each next due date is 4 weeks after the last service, so every cycle takes 5 weeks. Services land in weeks 1, 6, 11 and so on to 51: 11 in the first year, then 52 ÷ 5 = 10.4 a year. **Result:** Floating: 10.4 services a year instead of 13, 20% fewer Figure: Two 52-week timelines for a 4-week task done 1 week late each time. On fixed dates, 13 services fit in the year; on floating dates, each cycle stretches to 5 weeks and 11 services fit. *Floating dates turn every late job into a longer interval; fixed dates keep the count. Sample data.* A fixed interval has a smaller cost: a job done a week late leaves only 3 weeks to the next one. The technician services a part that has worn less, and the year keeps all 13 services. | | Fixed interval | Floating interval | |---|---|---| | Next due date counted from | The first due date | The last completion | | Late jobs | Shorten the next gap | Push every later date | | Services a year | Kept | Lost with each late job | | Grouping tasks into one stop | Yes | No | Choose fixed when a regulation or contract dates the task, when tasks share a stop, or when you [book stops with production](/blog/pm-vs-production-schedule/) weeks ahead. Choose floating only when what matters is the time since the last service, such as a lubricant with a service life measured from the day it’s applied. When what matters is how much the machine ran, you don’t need either: put the task on a run-hour or part-count meter, which floats on usage by design. ## Book the stop with production A PM that needs the machine stopped needs a slot on the production schedule. Without one, the technician arrives, finds a job running, and the task waits for a stop that never comes. Book the stop when the machine is already down or lightly loaded: - **A planned changeover.** A 3-hour inspection on a Haas VF-2 fits beside a fixture change that already stops the machine. - **An unscheduled shift.** A machine that runs two shifts has a third with nobody waiting on it. - **The last hours before a weekend**, when a missed restart costs the least. Give the planner the dates a week or more ahead, with the estimate from each task card, so the [production schedule](/blog/production-scheduling-on-real-run-rates/) loads around them. Then log the stop under a reason code marked as [planned downtime](/docs/monitoring/downtime-categories/#planned), so the PM doesn’t show up as a breakdown in your downtime reports. ## Measure PM compliance and adjust A schedule holds when you can see that it holds. The number that shows it is PM compliance. > **Definition.** **PM compliance** is the share of preventive maintenance tasks due in a period that were completed within their allowed window, with late and skipped tasks both counted as misses. **PM compliance** = (PM tasks completed within their window) ÷ (PM tasks due in the period) Decide the window before you measure, and write it down. For example, a task every 4 weeks might allow 3 days either side of its due date. A regulation-dated task allows nothing past its date: a weekly press inspection is due within the week. #### Worked example: Weeks 1 to 4 of the leveled job shop schedule - PM tasks due: 24. That’s 8 press inspections, 10 CNC lube tasks, 2 compressor drains and 4 CNC inspections. - Done within the window: 18. Done late: 4. Not done: 2. **Result:** PM compliance = 18 ÷ 24 = 75.0% > **Don’t count late work as done** > > Counting the 4 late tasks as completed reports 22 ÷ 24 = 91.7% for the same four weeks. It hides the slippage the measure exists to show. The 6 misses matter more than the percentage. Give each one a cause from a short list: no stop booked, part missing, estimate too short, technician pulled to a breakdown, or task not needed. Each cause has a different owner. A missing part goes to whoever stocks the shelf, and a short estimate goes back onto the task card. ### Adjust intervals from what you find The as-found field on each task card is the evidence for changing an interval. When three services in a row find the part like new, lengthen the interval one step. When one finds it worn past its limit, shorten it. Don’t set an interval from MTBF. NASA’s guide notes that MTBF is often the starting point for PM intervals, but it gives only the average age at failure, not the most likely one, and says nothing about whether failures rise with age.[1] ## Schedule PM in IoTFlows In Maintain, a PM is a recurrence rule on a work order. The rule takes an interval, a weekday set, an optional end date and a timezone, and counts every date from the first due date, so intervals stay fixed. Set the [rule’s timezone](/docs/maintain/preventive-maintenance/#timezone) to the plant’s, so a 6:00 AM Tuesday task lands on first shift wherever the planner sits. A weekday set lets one rule cover a Monday, Wednesday and Friday greasing round. Each work order carries what this guide puts on a task card: the machine, an assignee, a time estimate, a checklist and required parts, which Inventory reserves when the work order is created. Usage-driven tasks go on a meter. [Altium Packaging](/customers/altium-packaging/) inspects its Slide Knife that way, every 100,000 bottles, with the work order opened automatically. See how [Maintain](/platform/maintain/) ties every PM to the machine it serves. ## Before you call the schedule done - Every task names one machine, one owner, a time estimate, a parts kit and the machine state it needs. - Every task traces to the manual, a regulation or a failure you have seen. - The weekly PM hours fit inside the time left after reactive work, in the busiest week, not on average. - First due dates are staggered, and intervals nest so tasks on one machine share a stop. - Each task’s interval is fixed unless the time since the last service is what matters. - Stops are booked with production at least a week ahead, under a planned reason code. - PM compliance is measured against a written window, with a cause recorded for every miss. - Intervals change only from as-found records, never from MTBF. ## Questions ### How often should preventive maintenance be done? Start each task at the interval the machine’s manual gives, and at any interval a regulation sets, such as the weekly clutch and brake inspection OSHA requires on many mechanical power presses. Then adjust from what technicians find: lengthen the interval after several services find the part like new, and shorten it when one finds the part worn past its limit. ### What is the difference between a PM schedule and a PM checklist? The schedule says when each task is due, on which machine and who does it. The checklist is the list of steps inside one task, such as lock out, drain, replace the filter, refill and run for 10 minutes. A schedule without checklists gets done differently by every technician, and checklists without a schedule get done when someone remembers. ### Should operators do part of preventive maintenance? Daily checks such as lube levels, air pressure, leaks and unusual noise suit operators, because they are at the machine every shift and the checks take minutes. Keep tasks that need tools, lockout or a measurement against a limit with trained technicians. Writing operator checks as their own daily task keeps them out of the technicians’ weekly hours. ### What should happen when a PM is missed? Do the work as soon as you can, record it as late, and on a fixed schedule leave the next due date where it was. Then find out why it slipped: no machine stop booked, a missing part, an estimate that was too short, or a technician pulled to a breakdown. Each cause has a different fix, and compliance only rises when you fix the cause. ### How many PM tasks is too many? There are too many when the weekly PM hours exceed the technician time left after reactive work, because the overflow turns into late and skipped tasks. There are also too many when tasks keep finding nothing. Review any task whose last several services found the part like new, then lengthen its interval or drop it. ## Sources 1. [Reliability-Centered Maintenance Guide for Facilities and Collateral Equipment](https://www.nasa.gov/wp-content/uploads/2023/06/nasa-rcmguide.pdf), National Aeronautics and Space Administration, September 2008, accessed Oct 16, 2026 2. [Operations & Maintenance Best Practices: A Guide to Achieving Operational Efficiency, Release 3.0](https://www.osti.gov/servlets/purl/1034595), Pacific Northwest National Laboratory for the US Department of Energy, August 2010, accessed Oct 16, 2026 3. [The Costs and Benefits of Advanced Maintenance in Manufacturing (NIST AMS 100-18)](https://doi.org/10.6028/NIST.AMS.100-18), National Institute of Standards and Technology, D. Thomas, April 2018, accessed Oct 16, 2026 4. [29 CFR 1910.217, Mechanical power presses](https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.217), Occupational Safety and Health Administration, accessed Oct 16, 2026 --- # Manufacturing KPIs with formulas and worked examples Source: https://www.iotflows.com/blog/manufacturing-kpis/ 21 production KPIs, each with one formula, one unit and a worked example from the same lathe shift, plus the denominator traps that make two reports disagree. > Question: Which production KPIs should a plant track, and how is each calculated? ## Key takeaways - A KPI is usable only when its formula, unit, denominator and period are written down beside the number. - OEE multiplies availability, performance and quality, and good count × ideal cycle time ÷ planned time checks the product. - To check whether a machine meets demand, compare takt time with planned time per good part, not with its ideal or actual cycle time. - First pass yield counts reworked parts as failures, and a line’s rolled yield is the product of its step yields. - Roll KPIs up by adding minutes, parts and orders before you divide, never by averaging percentages. A plant should track the production KPIs that answer its own questions about time, speed, quality and delivery: uptime and downtime, the three OEE factors, cycle time against takt, first pass yield and scrap, and schedule attainment and OTIF. You calculate each one as a ratio of measured minutes, parts or orders, and two reports agree only when both write the denominator down. This reference gives 21 KPIs one formula, one unit and one worked example each. Every example uses the same lathe shift, so you can check each number against the others. ## What a KPI definition must state > **Definition.** **Manufacturing KPI (key performance indicator)** is a ratio of measured shop-floor quantities, such as minutes, parts or orders, tracked against a target over a fixed period, with its formula, unit and denominator written down so that every report computes it the same way. A KPI with a name and no written formula drifts. Two supervisors who both report “availability” can divide by different times and both be right. Write four things beside every KPI: - **Formula:** the ratio, in words, with each term defined. - **Unit:** %, minutes, seconds per part, parts per hour or orders. - **Base:** what sits in the denominator and what is left out, such as lunches, changeovers or offline time. - **Period:** the shift, day, week or month the ratio covers. The base is where plants split. Even OEE has no single published form: an academic review found that the versions in the ISO 22400 standard diverge from each other and from Nakajima’s original TPM formulation.[6] This article follows one written convention and states it in each section. #### Worked example: The shift every example uses - Machine: a Haas ST-20 CNC lathe on one 8-hour shift, 480 minutes, with a 30-minute lunch. - Stops: an 18-minute coolant pump fault, a 22-minute changeover and 10 minutes waiting for bar stock, 50 minutes in all. - Ideal cycle time: 54 seconds (0.9 minutes) per part. - Count: 400 parts made. 388 passed inspection the first time, 4 were reworked and passed, and 8 were scrapped. - Demand: the customer needs 375 parts a day, and the lathe runs one shift a day. Every KPI below comes from six measured inputs. If an input is missing, the KPIs that need it can’t be computed, no matter what the software shows. | Input | KPIs that use it | |---|---| | Shift calendar and planned stops | Every time-based KPI | | Running and stopped state | Uptime, downtime, availability | | Total part count | Performance, cycle time, throughput | | Good, reworked and scrapped count | Quality, FPY, scrap rate | | Ideal cycle time per operation | Performance, OEE, TEEP | | Due dates, orders and completions | Schedule attainment, OTIF | MTBF and MTTR use the same running and stopped log, filtered to failures and their repair times. > **Add minutes before you divide** > > Never average percentages across shifts or machines. A day shift at 360 of 400 planned minutes (90%) and a short night shift at 100 of 200 (50%) average to 70.0%, but the machine ran 460 of 600 minutes, which is 76.7%. Add the numerators, add the denominators, then divide once. ## Time KPIs: uptime, downtime and utilization Time KPIs need only a running or stopped signal and the shift calendar. They are the first numbers you can trust, because no part count or cycle time feeds them. | KPI | Formula | Unit | Lathe shift | |---|---|---|---| | Uptime | Running ÷ (running + stopped) | % of shift | 400 ÷ 480 = 83.3% | | Downtime | Sum of stopped time | Minutes | 80 min, 30 of it lunch | | Utilization, calendar | Running ÷ calendar time | % | 400 ÷ 1,440 = 27.8% | Uptime here counts the lunch as stopped time inside the shift. Sample data. *Uptime* is the share of shift time a machine spends running. It counts every stop inside the shift, planned or not, so the 30-minute lunch pulls the lathe down to 83.3%. Track downtime as minutes, a count of stops and a reason for each. The lathe lost 50 minutes to three stops inside planned time, and the 22-minute changeover is the largest. A minute total with no reasons tells you how much time went, but not where to look. To put a price on those minutes, follow the method in [what an hour of downtime costs](/blog/cost-of-downtime/). *Utilization* has the most meanings of any word here. Calendar utilization divides running time by every hour in the period, so a one-shift lathe that runs well still reads 27.8%. The [machine utilization guide](/blog/what-is-machine-utilization/) works one machine through four denominators. National capacity utilization is a different measure again. The Federal Reserve reports US manufacturing at 75.7% for August 2026, output against sustainable capacity across the whole economy, against a 1972–2025 average of 78.2%.[9] It says nothing about how long any one machine ran. ## OEE, its three factors and TEEP OEE multiplies three factors: availability, performance and quality.[1] Each factor removes one kind of loss, so a single OEE number hides which loss is largest. Report the factors beside it. **OEE** = Availability × Performance × Quality *Planned production time* is the shift minus time with no intention to produce, such as breaks. Under the convention this article follows, changeovers stay inside planned production time and count as stop time, so they lower availability.[1] | KPI | Formula | Unit | Lathe shift | |---|---|---|---| | Availability | Run time ÷ planned production time | % | 400 ÷ 450 = 88.9% | | Performance | Ideal cycle × total count ÷ run time | % | 360 ÷ 400 = 90.0% | | Quality | Good count ÷ total count | % | 388 ÷ 400 = 97.0% | | OEE | Availability × performance × quality | % | 77.6% | | TEEP | OEE × planned time ÷ calendar time | % | 0.776 × 0.3125 = 24.3% | Planned production time is 480 minutes minus the 30-minute lunch. Run time is 450 minus 50 minutes of stops. Sample data. #### Worked example: OEE for the lathe shift, computed two ways - Availability: 400 ÷ 450 = 0.8889. - Performance: 400 parts × 0.9 min = 360 ideal minutes, and 360 ÷ 400 = 0.900. - Quality: 388 ÷ 400 = 0.970. - Product: 0.8889 × 0.900 × 0.970 = 0.776. - Check: good count × ideal cycle time ÷ planned production time = 388 × 0.9 ÷ 450 = 349.2 ÷ 450 = 0.776. **Result:** OEE = 77.6% both ways, with availability the lowest factor at 88.9% Always run the short form as a check. It uses only the good count, the ideal cycle time and planned production time, so an arithmetic slip in any factor shows up as a mismatch.[1] The [step-by-step OEE method](/blog/how-to-calculate-oee/) covers each factor in more depth. Two quality rules decide whether OEE means anything. Good parts are parts that pass the first time, so the 4 reworked parts count as losses. And performance above 100% doesn’t mean the machine is fast: it means the [ideal cycle time](/blog/ideal-cycle-time/) is set too slow.[1] *TEEP* (total effective equipment performance) multiplies OEE by planned production time over all calendar time; some references call that second term utilization.[2] The lathe’s 450 planned minutes are 31.25% of the day, so TEEP is 24.3%. That is a one-shift schedule, not a failing machine, and the [TEEP and calendar breakdown](/blog/utilization-uptime-oee-teep/) shows how the shift pattern sets its ceiling. ## Flow KPIs: cycle time, takt and throughput Flow KPIs ask whether the machine keeps pace with demand. Three of them are durations per part, and one is a rate. | KPI | Formula | Unit | Lathe shift | |---|---|---|---| | Actual cycle time | Run time ÷ total count | s per part | 24,000 s ÷ 400 = 60 s | | Takt time | Available time ÷ customer demand | s per part | 27,000 s ÷ 375 = 72 s | | Time per good part | Planned time ÷ good count | s per part | 27,000 s ÷ 388 = 69.6 s | | Throughput | Good count ÷ shift hours | Parts per hour | 388 ÷ 8 h = 48.5 | Run time is 400 minutes and planned production time is 450 minutes. Sample data. *Cycle time* is the time to produce a part or complete a process, as timed by actual measurement.[4] The lathe’s actual cycle is 60 seconds against a 54-second ideal. That 6-second gap per part is the 10% performance loss, made of slow cycles and the [micro-stops](/blog/micro-stops/) too short to log. > **Definition.** **Takt time** is the available production time divided by customer demand: the pace at which a process must finish one unit to meet the demand exactly, set by the customer and the schedule rather than by the machine. A plant that runs 480 minutes a day for a demand of 240 widgets has a takt time of 2 minutes.[3] For the lathe, 450 available minutes and 375 parts give 72 seconds. **Takt time** = (Available production time) ÷ (Customer demand) To check whether the lathe meets demand, compare takt with planned time per good part, not with a cycle time. The 54-second ideal and the 60-second actual both look comfortable against 72 seconds, but neither counts stops or scrap. Planned time per good part counts both: 69.6 seconds, 2.4 seconds inside takt, with 13 parts to spare on the day. Figure: Three bars against a dashed 72 s takt line: ideal cycle time 54 s, actual cycle time 60 s, and planned time per good part 69.6 s, highlighted as the figure to compare with takt, 2.4 s inside it. *The lathe meets takt by 2.4 seconds once stops and scrap are counted, not by 18. Sample data.* Machines that load by hand need one more adjustment. The *effective machine cycle time* adds load and unload time and the changeover spread over the batch: a 20-second cycle with 30 seconds of load and unload and a 30-second changeover every 30 pieces runs at 51 seconds a part.[4] Write the unit beside throughput every time. The same lexicon uses *throughput time* as another name for production lead time, a duration, while throughput on a shop floor usually means a rate in parts per hour.[4] ## Quality KPIs: first pass yield, scrap and rolled yield Quality KPIs count parts, not time. The question each one answers is which parts you count as good, and when. > **Definition.** **First pass yield (FPY)** is the share of units that come through a process step right the first time, with no rework and no scrap: good-first-time units divided by units started at that step. The IoTFlows glossary entry for [first pass yield](/docs/get-started/glossary/#fpy) applies the idea down a line: each step’s good count against Step 1’s, so the last step reads how much of Step 1’s output reached the end of the line. FPY is the quality factor OEE uses, because rework counts as a loss in OEE quality.[1] | KPI | Formula | Unit | Lathe shift | |---|---|---|---| | First pass yield | Good first time ÷ units started | % | 388 ÷ 400 = 97.0% | | Final yield | Good after rework ÷ units started | % | 392 ÷ 400 = 98.0% | | Scrap rate | Scrapped ÷ units started | % | 8 ÷ 400 = 2.0% | | Rolled throughput yield | Product of every step’s FPY | % | 0.970 × 0.960 × 0.990 = 92.2% | The rolled yield row adds two later steps: a mill at 96.0% FPY and an inspection station at 99.0%. Sample data. Final yield and scrap rate leave rework out of sight. The lathe’s 98.0% final yield hides 4 parts that took a second pass of labor and machine time. Report FPY when you want to see that cost, and final yield when you want to see what ships. The [first pass yield guide](/blog/first-pass-yield/) works through why OEE quality and the scrap rate disagree. *Rolled throughput yield* (RTY) is the probability that a unit passes every step of a process the first time, calculated by multiplying the yield of every step together.[5] In iSixSigma’s example, four steps that each fail 15% of units first time give an RTY of 52.2%.[5] **Rolled throughput yield** = FPY step 1 × FPY step 2 × … × FPY step n Add a mill at 96.0% and an inspection station at 99.0% after the lathe. Each step reads 96% or better, yet the line’s RTY is 92.2%: of 1,000 bars started, about 922 come out without rework or scrap. Figure: 1,000 units start; about 970 pass the lathe first time at 97.0% FPY, 931 pass the mill at 96.0% and 922 pass inspection at 99.0%, so the line's rolled throughput yield is 92.2%. *Three steps at 96% or better still lose about 78 of every 1,000 units first time. Sample data.* ## Delivery KPIs: schedule attainment and OTIF Delivery KPIs count jobs and orders against dates. No standard fixes their formulas, so pick a unit and write it down. | KPI | Formula | Unit | Example week or month | |---|---|---|---| | Schedule attainment, jobs | Jobs done by due date ÷ jobs due | % | 21 ÷ 24 = 87.5% | | Schedule attainment, units | Units done by due date ÷ units due | % | 8,880 ÷ 9,600 = 92.5% | | OTIF | Orders on time and in full ÷ orders | % | 102 ÷ 120 = 85.0% | The schedule rows cover one week in the lathe cell. The OTIF row covers one month of shipped orders. Sample data. *Schedule attainment* is the share of scheduled work finished by its due date. The same week reads 87.5% by jobs and 92.5% by units, because the three late jobs were small. Measure by jobs when each job is a separate customer promise, and by units when the cell runs a few long orders. A schedule built on programmed cycle times misses before the first job starts. Plan on the measured rate instead, as covered in [scheduling on real run rates](/blog/production-scheduling-on-real-run-rates/). *OTIF* (on time, in full) is the share of orders delivered both on time and in full. Count the orders that meet both conditions. Don’t multiply the two rates. #### Worked example: One month of shipped orders - Orders: 120. On time: 108 (90.0%). In full: 111 (92.5%). Both on time and in full: 102. - Late or short: 18 orders. 12 were late and 9 were short, so 3 orders were both. - Wrong: 0.900 × 0.925 = 83.3%. Multiplying assumes late orders and short orders are unrelated, which would predict about 1 order that was both, not 3. **Result:** OTIF = 102 ÷ 120 = 85.0% Check your customer’s rulebook before you report OTIF. Customers define “on time” differently, for example against a requested date or a promised date, and inside different delivery windows. ## Reliability KPIs: MTBF and MTTR Reliability KPIs come from the same stop log as downtime, filtered to failures. Decide first what counts as a failure: the coolant pump fault does, but the changeover and the wait for bar stock don’t. | KPI | Formula | Unit | Lathe quarter | |---|---|---|---| | MTBF | Operating time ÷ number of failures | Hours | 420 ÷ 4 = 105 h | | MTTR | Repair time ÷ number of repairs | Hours | 6 ÷ 4 = 1.5 h | | Inherent availability | MTBF ÷ (MTBF + MTTR) | % | 105 ÷ 106.5 = 98.6% | One quarter on the lathe: 63 shifts of 400 running minutes, or 420 operating hours, with 4 failures and 6 hours of repair. Sample data. MTBF (mean time between failures) applies to equipment you repair and return to service. MTTF (mean time to failure) is the same ratio for parts you replace, and the two aren’t interchangeable.[7] A 105-hour MTBF doesn’t mean the lathe can count on 105 hours between failures. Under a constant failure rate, the chance of reaching the MTBF without a failure is about 37%.[8] The same model gives a 93.8% chance of getting through one shift’s 400 running minutes with no failure, since e^(−6.67 ÷ 105) = 0.938. Report the longest repair beside MTTR. A quarter of four 1.5-hour repairs and a quarter of three 30-minute repairs and one 4.5-hour repair share a 1.5-hour mean, but only the second quarter had a machine down for most of a shift. ## Measure production KPIs from the machine IoTFlows puts a sensor on each machine that decides running or stopped every second and counts parts from the machine’s own cycle, with no PLC connection. Uptime is running time over running plus stopped inside your shifts, and time the sensor was offline stays out of both terms. With lunch set to None severity and **Exclude None** on in the Advanced Report, uptime reads on the availability base. Performance reads against the ideal cycle time, and quality comes from the scrap your team logs with a reason, so you read [OEE factor by factor](/solutions/oee-tracking/). Each formula is in the [metrics reference](/docs/monitoring/metrics-reference/). On a line, a [cascading group](/docs/monitoring/asset-groups/#fpy) reads each step’s count against the first step’s. [Altium Packaging](/customers/altium-packaging/) reads first pass yield and the bottles lost at every step of its ten bottling lines as they happen. Production Scheduler [Insights](/docs/production/production-insights/#kpis) reports which scheduled work finished by its due date. ## Which KPIs to track first Start from the question you need answered this month, then take the KPI that answers it and the inputs it needs. | Your question | Start with | Inputs you need | |---|---|---| | Are the machines running? | Uptime and downtime | Run and stop signal, shifts | | Where did the time go? | Downtime by reason | A reason on each stop | | Do we keep up with demand? | Time per good part against takt | Good counts, daily demand | | How well do scheduled hours run? | Availability, performance, quality | Counts, ideal cycle times | | Where are parts lost? | FPY by step and RTY | Counts at every step | | Will we ship on time? | Schedule attainment and OTIF | Due dates, completions | > **Uptime first or OEE first?** > > Start with uptime and downtime by reason when you don’t yet know how often each machine runs, because both need only a run signal and your shifts. Add performance once parts are counted against an ideal cycle time, and quality once scrap is logged. You don’t need TEEP or MTBF on a daily report: compute TEEP when you plan capacity, and MTBF once the stop log holds enough failures to average. Before any KPI goes on a wall or into a customer report: - **Write the base** beside the number: “77.6% OEE on 450 planned minutes”, not “77.6%”. - **Name the convention** for changeovers, planned maintenance and rework, and keep it the same in every trend. - **Show the factors** beside OEE, and FPY beside final yield. - **Roll up by adding** minutes, parts and orders, then divide once. - **Keep offline time out** of every time-based KPI, and fix the connection that caused it. ## Questions ### How many production KPIs should a plant track? Track as many as you have decisions for, and no more. Start with uptime and downtime by reason, add the three OEE factors once parts are counted against an ideal cycle time, and add first pass yield and schedule attainment when quality and delivery are the questions. A KPI nobody acts on in a weekly review is a number to drop. ### What is the difference between uptime and availability? Both divide running time by a slice of the shift. Uptime divides by everything inside the shift, so a lunch counts as stopped time. OEE availability divides by planned production time, which leaves the lunch out. On the same lathe shift, 400 running minutes give 83.3% uptime over 480 minutes and 88.9% availability over 450. ### Is utilization one of the OEE factors? No. The three OEE factors are availability, performance and quality. Utilization in the TEEP sense is planned production time divided by calendar time, and it multiplies OEE to give TEEP. On shop-floor reports, utilization often means running time over available time, which is a fourth meaning, so always write down the denominator. ### Why does my OEE differ from another plant’s? Two plants rarely define planned production time, changeovers, ideal cycle time and good parts the same way. Take the changeover out of planned production time and count the 4 reworked parts as good, and the same lathe shift reads 82.4% OEE instead of 77.6%. Compare a machine with its own history under one written convention before you compare plants. ## Sources 1. [OEE Calculation: Definitions, Formulas, and Examples](https://www.oee.com/calculating-oee/), Vorne Industries (OEE.com), accessed Oct 16, 2026 2. [TEEP: Calculate Total Effective Equipment Performance](https://www.oee.com/teep/), Vorne Industries (OEE.com), accessed Oct 16, 2026 3. [Takt Time (Lean Lexicon)](https://www.lean.org/lexicon-terms/takt-time/), Lean Enterprise Institute, accessed Oct 16, 2026 4. [Cycle Time (Lean Lexicon)](https://www.lean.org/lexicon-terms/cycle-time/), Lean Enterprise Institute, accessed Oct 16, 2026 5. [What is Rolled Throughput Yield (RTY)?](https://www.isixsigma.com/dictionary/rolled-throughput-yield-rty/), iSixSigma, accessed Oct 16, 2026 6. [Overall Equipment Effectiveness: consistency of ISO standard with literature (Schiraldi and Varisco, Computers & Industrial Engineering 145, 106518, 2020)](https://art.torvergata.it/handle/2108/280082), University of Rome Tor Vergata institutional repository, accessed Oct 16, 2026 7. [Maintenance and Reliability KPI Reference](https://reliamag.com/guides/maintenance-reliability-kpi-reference/), Reliamag, accessed Oct 16, 2026 8. [MTBF: Misinterpreted and Misused](https://reliabilityweb.com/mtbf-misinterpreted-and-misused), Reliabilityweb, accessed Oct 16, 2026 9. [Industrial Production and Capacity Utilization, G.17 (release of September 18, 2026)](https://www.federalreserve.gov/releases/g17/current/default.htm), Federal Reserve, accessed Oct 16, 2026 --- # How to know mid-shift whether you will hit target Source: https://www.iotflows.com/blog/production-monitoring-shift-goal/ Compare the count with the goal to now, project the shift at its current pace, and use the stop budget to see whether a gap can still be recovered. > Question: How do I know during the shift whether we will hit target? ## Key takeaways - Compare the good-part count with the goal prorated to this moment, not with the full-shift goal. - Project the end of the shift at the pace the machine holds now, and use the ideal rate only as a ceiling. - Convert a shortfall into minutes of running at the ideal cycle time to see what recovering it takes. - A gap can be closed by removing stops only while it is smaller than the stops still expected this shift. - Hourly bars show when the parts were lost; the cumulative count only shows whether the shift is behind. You know during the shift whether you will hit target by comparing the good parts made so far with the goal prorated to this moment, then projecting the hours left at the pace the machine holds now. Convert any gap into minutes of running at the ideal cycle time. When that number is larger than the stops you still expect this shift, removing stops can’t close it, and you add time or move work now. This guide is for supervisors, plant managers and line leads who own a shift’s output. It works one hypothetical lathe shift through each calculation and ends with a mid-shift check and what to do when the shift is behind. ## What is a shift goal? > **Definition.** **Shift goal** is the number of good parts an operation should finish in one shift: the planned production time, less the downtime the machine is expected to have, divided by the ideal cycle time. The goal is built from the machine’s own numbers, so a normal shift can reach it. The [shift goal glossary entry](/docs/get-started/glossary/#shift-goal) shows how IoTFlows derives it from the same inputs. **Shift goal** = (Planned production time − expected downtime) ÷ (Ideal cycle time) *Planned production time* is the shift less its scheduled breaks. *Expected downtime* is the stopped time this machine averages on this operation: tool changes, gauging, waiting for material. Planned time comes from your [shift definitions](/docs/admin/shifts-and-timezone/), and expected downtime from the machine’s history. The ideal cycle time decides the rest. An ideal set 10% too fast raises the goal by 11% on a shift where nothing changed, so check it first: [how to set ideal cycle time](/blog/ideal-cycle-time/) covers who owns it and how to time it. #### Worked example: The shift used in this guide - Machine: a Haas ST-20 lathe turning a brass hydraulic fitting, with an ideal cycle time of 45 seconds. - Shift: 6:00 AM to 2:30 PM with lunch from 10:30 to 11:00, so 480 planned minutes. - Expected downtime: 60 minutes, the machine’s average on this operation. Expected running time is 480 − 60 = 420 minutes, or 25,200 seconds. At 45 seconds a part, that is 25,200 ÷ 45 = 560 parts, or 70 for each planned hour. **Result:** Shift goal = 560 good parts A shift goal is not takt time. Takt time is available production time divided by customer demand.[2] Use takt to check whether the machine’s [capacity covers demand](/blog/find-the-bottleneck/#takt). Use the shift goal to judge whether this shift ran as well as this machine normally runs. ## Why the end-of-shift count is too late At 2:30 PM the count is a record, not a decision. A shift that finishes 30 parts short has no time left to make them, and the stops behind the shortfall happened hours ago. The same 30 parts at 10:00 AM are 22.5 minutes of running at the ideal cycle, with four planned hours still ahead. That is a problem a supervisor can solve before lunch. Comparing planned with actual output at the machine is an old lean practice. The Lean Enterprise Institute describes andon displays that show “the number of units planned versus actual output.”[1] An automatic count changes the practice: when a sensor or a counter records every part, the comparison is live every minute instead of written on a sheet once an hour. ## Compare the count with the goal to now > **Definition.** **Goal to now** is the part of the shift goal a machine should have made by this moment: the shift goal multiplied by the planned time elapsed, divided by the shift’s planned production time. **Goal to now** = Shift goal × elapsed planned time ÷ planned production time At 10:00 AM the lathe has used 240 of its 480 planned minutes, so the goal to now is 560 × 240 ÷ 480 = 280 parts. The count reads 250. The shift is 30 parts behind, at 89.3% of the goal to now. Compare with the goal to now, not with the full-shift goal. The same 250 parts are 44.6% of the shift goal, a number that climbs all day whether the machine is on pace or not. Treat a gap smaller than the normal swing between hours as noise. This lathe made 66, 71 and 61 parts in its first three hours, a spread of 10. A gap of 5 parts says nothing, and a gap of 30 says a lot. > **Is the goal line always straight?** > > A straight line assumes expected downtime is spread evenly across the shift. When a 40-minute changeover is planned for noon, the machine runs ahead of a straight line all morning and drops back during the changeover. Build the goal-to-now line hour by hour instead, with the changeover in the hour it happens, so a planned stop never reads as a gap. ## Project the end of the shift The goal to now says where you are. A projection says where you will land if nothing changes. **Projected count** = Count so far + pace × planned time remaining The answer depends on the pace you project with. The lathe has 250 parts and four planned hours left: | Pace to project with | Choose it when | Projected count | |---|---|---| | Goal pace, 70 an hour | The cause of the gap is fixed and gone | 530 | | Shift average, 62.5 an hour | Losses are spread across the shift | 500 | | Last hour, 52 an hour | The last hour’s problem is still there | 458 | | Ideal, 80 an hour | Only as a ceiling: zero further stops | 570 | Hypothetical shift. Projected count is 250 plus the pace × 4 planned hours. Two rows matter most. The goal-pace row shows that a shift running to plan from here still finishes 30 short: a gap never closes on its own. The ideal row is the ceiling. When even the ceiling falls short of the goal, no effort on this machine saves the shift, and you go straight to the [decision guide](#behind). Default to the last hour’s pace until you know the cause of the shortfall is fixed. On this lathe it is also the lowest realistic pace, and a supervisor who acts on it early loses less than one who waits for the average to recover. Figure: Cumulative good parts on a lathe shift: 250 made after 4 of 8 planned hours against 280 due by now. Projected at the last hour's pace of 52 an hour, the shift ends at 458 against a goal of 560. *At 10:00 AM the shift is 30 parts behind, and the last hour’s pace lands it 102 short. Sample data.* ## Turn the gap into minutes of running Parts behind are hard to act on. Minutes are not: a supervisor can find 20 minutes on the floor, and can’t find “30 parts”. **Required rate** = (Shift goal − count so far) ÷ (Planned time remaining) The lathe needs (560 − 250) ÷ 4 = 77.5 parts an hour for the rest of the shift, against a goal pace of 70 and an ideal ceiling of 80. The rate is possible, but it leaves almost no room to stop. > **Definition.** **Stop budget** is the number of minutes a machine can still stop during a shift and make its goal: the planned time left, less the running time the remaining parts need at the ideal cycle time. **Stop budget** = Planned time remaining − parts still needed × ideal cycle time #### Worked example: Stop budget at 10:00 AM - Planned time remaining: 240 minutes. - Parts still needed: 560 − 250 = 310. At 45 seconds, they need 310 × 45 = 13,950 seconds, or 232.5 minutes, of running. - Stops expected for the rest of the shift at the usual rate: 60 × 240 ÷ 480 = 30 minutes. The stop budget is 240 − 232.5 = 7.5 minutes, against the 30 minutes of stops the machine usually has in that time. The difference, 22.5 minutes, is the 30-part gap expressed as running time: 30 × 45 seconds. **Result:** Stop budget = 7.5 min, 22.5 min below the usual stops Figure: The last 240 planned minutes split into 232.5 minutes of running needed for 310 parts and a 7.5-minute stop budget. The machine usually stops 30 minutes in that time, 22.5 minutes more than the budget allows. *The 30-part gap is 22.5 minutes of stops the machine can’t afford before 2:30 PM. Sample data.* Compare the stop budget with the stops you still expect, then read the status from the table. | Stop budget | Status | What it means | |---|---|---| | At or above expected stops left | On track | Keep the hourly check | | Above zero, below expected stops | Recoverable | Remove stops or add time, now | | Zero or below | Not recoverable here | Move work, add time or replan | The lathe sits in the middle row. It makes 560 only if 22.5 minutes of the stops it usually has don’t happen. ## Find the hour that lost the parts The cumulative count tells you whether the shift is behind. Hourly bars tell you when it fell behind, and the when leads to the cause. Figure: Four hourly bars against an hourly goal of 70: 66, 71, 61 and 52 parts. The 9 to 10 AM bar is 18 short, 13.5 minutes of running, and accounts for more than half of the 30-part gap. *The cumulative gap is 30 parts, and the last hour lost 18 of them. Sample data.* The lathe’s hourly goal is 70. Its hours ran 66, 71, 61 and 52: 4 short, 1 over, 9 short and 18 short, which adds to the 30. The last hour lost 18 parts, or 13.5 minutes of running at 45 seconds. Open the stop record for that hour next. - **A stop explains it**, for example a 12-minute insert change that cost 16 of the 18 parts. Decide whether that stop will come back before the shift ends. - **No stop explains it.** The loss is slow cycles or stops too short to log, and [micro-stops](/blog/micro-stops/) covers how to find them. The latest hour carries the most weight. A bad first hour that recovered is history; a bad last hour is the pace you are projecting with. If stops aren’t recorded with reasons yet, [tracking machine downtime](/blog/how-to-track-machine-downtime/) comes first, because the hourly bars find the hour and the stop record names the cause. ## Run the mid-shift check 1. **Read the count and the goal to now.** Take good parts only. Scrap counted as output makes a shift look closer to goal than it is. 2. **Convert the gap into minutes.** Multiply the parts behind by the ideal cycle time. For example, 30 parts at 45 seconds is 22.5 minutes. 3. **Project at the last hour’s pace.** If the projection reaches the goal, stop here and check again next hour. 4. **Work out the stop budget.** Subtract the running time the remaining parts need from the planned time left, and compare the result with the stops you still expect. 5. **Find the worst recent hour.** Match it with the stop record to name the cause. 6. **Choose one action and write it down.** Pick from the decision guide below and note what you changed, so the end-of-shift review can see whether it worked. Each role checks at its own interval: | Role | When | What they read | |---|---|---| | Operator or line lead | Every hour | The last hour against its goal | | Supervisor | 2 hours in and at mid-shift | Gap in minutes, stop budget | | Plant manager | Mid-shift | Machines with a negative stop budget | Timing matters because the same gap gets harder to close as the shift runs out. At 10:00 AM the lathe’s 22.5-minute gap faces 30 minutes of expected stops still ahead, so removing stops can close it. At 1:30 PM, with one planned hour left, only 7.5 minutes of stops are expected, and the gap needs added time or another machine. If your area paces work in *pitch*, the time needed to make one container of product, each container is a natural checkpoint. Pitch is takt time × pack-out quantity, so a 1-minute takt and 20 pieces a container give a pitch of 20 minutes.[3] ## Track the shift goal automatically [Production monitoring](/solutions/production-monitoring/) in IoTFlows counts every part from a SenseAi or a BeamTracker on the machine, with no PLC. The calculated goal is the shift duration less the expected downtime, the historical average for that operation and machine, divided by the ideal cycle time. [Shift Production](/docs/production/shift-production/#hourly) shows good parts against that goal, the pace as Ideal, Goal and Actual, and one bar per clock hour, amber when the hour fell short. [Operator View](/docs/monitoring/operator-view/#part-count) shows the count at the machine, with the shortfall marked Behind. Hilco Vision’s production rose more than 20% once the team analyzed and adjusted in real time instead of waiting days for reports. > Before IoTFlows, we'd set a target and hope we hit it. Now we know by mid-afternoon exactly where we'll land and whether we need to adjust. That shift from hoping to knowing is everything. It turns production management from firefighting into orchestration. > > Swapnil Rane, Engineering Manager, Hilco Vision ([story](https://www.iotflows.com/customers/hilco-vision/)) ## Decide what to do when the shift is behind Pick the action from the stop budget and the cause, not from how far behind the shift looks. - **Remove a stop that is still ahead.** Choose this when the stop budget is above zero but below the stops expected. For example, stage the inserts and the next bar at the lathe before the noon tool change, so a 16-minute stop takes 4 and wins back 16 parts. - **Fix the loss in the worst hour** while it is still happening. Choose this when the last hour’s pace is below the shift average, as on the lathe at 52 an hour against 62.5. - **Add planned time.** Choose this when the gap in minutes is larger than the stops still expected. Running the lathe through a staggered 30-minute lunch adds 40 parts at the ideal cycle, more than the 30 it is behind. - **Move the remaining quantity** to another machine that runs the same operation. Choose this when the stop budget is zero or below and a second machine has free time. - **Tell planning** when the gap is larger than anything the shift can add. The shortfall becomes a schedule input, and [scheduling on real run rates](/blog/production-scheduling-on-real-run-rates/) shows how to plan the next run on what the machine really makes. You don’t need to act on a gap smaller than the normal swing between hours. Chasing a 5-part gap pulls people off work that matters more. > **Keep the goal fixed during the shift** > > Lowering the goal after a breakdown turns a 30-part shortfall into a green shift and erases the record of what the breakdown cost. Keep the goal, log the stop with its reason, and let the weekly [downtime Pareto](/blog/downtime-pareto/) show whether the loss is a pattern worth fixing. ## Questions ### How do I read the goal when a machine runs two parts in one shift? Give each operation its own goal for the planned time it is scheduled to run, from its own ideal cycle time, and count the changeover between them as expected downtime. Read each operation’s count against its own goal to now, because parts with different cycle times do not add into one meaningful total. ### Does the shift goal count good parts or every part? Good parts. A shift that makes 560 fittings with 20 scrapped has made 540 toward a 560 goal and is 20 short. Counting scrap as output hides a quality loss inside an on-target shift, and the next operation receives fewer parts than the count promised. ### What does it mean when a machine beats its goal every shift? The goal is too easy. Either the ideal cycle time is slower than the machine really runs, or the expected downtime is higher than the machine now has. Retime the ideal on a good day and check the downtime average against recent weeks. A goal that is always met hides the speed the machine could be adding. ### Can one goal cover two machines running the same operation? Only as a total. Each machine needs its own goal from its own ideal cycle time and its own downtime history, because an older lathe and a newer one rarely run the same part at the same speed. Read each machine against its own goal to find the one pulling the total down. ## Sources 1. [Andon: What Is It?](https://www.lean.org/lexicon-terms/andon/), Lean Enterprise Institute, accessed Oct 16, 2026 2. [Takt Time](https://www.lean.org/lexicon-terms/takt-time/), Lean Enterprise Institute, accessed Oct 16, 2026 3. [Pitch](https://www.lean.org/lexicon-terms/pitch/), Lean Enterprise Institute, accessed Oct 16, 2026 --- # How to reduce machine downtime, one cause at a time Source: https://www.iotflows.com/blog/reduce-machine-downtime/ Cut unplanned downtime in four steps: record every stop, rank reasons by hours, split each into how often and how long, then fix it. Worked CNC example inside. > Question: What is a practical plan to cut unplanned downtime? ## Key takeaways - Record four weeks of stops from the machine before you change anything, so every fix has a baseline to beat. - Rank downtime reasons by the hours they cost, then split each one into how many stops and how long each lasts. - Frequent stops need their cause removed, while rare long stops need a faster response, spares on hand and prevention. - Check each fix against the same four-week window on the same machines, as a share of planned production time. - Plants in a NIST survey attributed about a third of their downtime to reactive maintenance, so a maintenance-only plan misses most stopped time. A practical plan to cut unplanned downtime has four steps. Record every stop from the machine, put a reason on each one, rank the reasons by the hours they cost, then fix the leading reason with the lever that matches its pattern: fewer stops, or shorter ones. Check the result against the same window a month later, then move to the next reason. This guide is for plant managers and maintenance leads. It takes one four-week stop log from an eight-machine CNC cell through the whole plan, from 9.0% unplanned downtime to 7.0%. ## What counts as unplanned downtime? > **Definition.** **Unplanned downtime** is the time a machine is stopped during planned production time for a reason nobody scheduled, such as a breakdown, a wait for material or an operator, or a program problem, counted from the moment the machine stops until it runs again. [Downtime](/docs/get-started/glossary/#downtime) is all stopped time, planned or not. *Planned production time* is the time a machine is scheduled to run, after breaks and other time nobody meant to run it come out. Planned stops are breaks, scheduled maintenance and planned changeovers. They stay out of the rate below, so a busy month of preventive maintenance doesn't look like a reliability problem. Changeovers still take capacity. Shortening them is its own project, with its own start and stop rules: see [how to measure changeover time](/blog/measure-changeover-time/). **Unplanned downtime rate** = (Unplanned stopped time) ÷ (Planned production time) For context, NIST surveyed US discrete manufacturers on their 2016 operations.[2] Downtime averaged 7.8% of planned production time across the sample.[1] Respondents attributed 31.7% of that downtime to reactive maintenance, meaning unplanned maintenance and repair, which leaves about two thirds to other causes.[1] That split shapes the plan. A program that only targets repairs leaves most of the stopped time alone. Material, staffing and programs belong on the same list as breakdowns. ## Measure a baseline before you change anything A fix you can't compare with a before number is a guess. Record four weeks of stops on every machine in the area first, and change nothing while you do. Take the stops from the machine signal, not from memory. A paper log catches the 40-minute breakdown and misses the 90-second jams, because nobody writes those down. The full method is in [how to track machine downtime](/blog/how-to-track-machine-downtime/). Each stop needs four fields: the machine, the start, the end and a reason. Keep the reason list short enough that operators pick the right one in seconds. A starter list is in [which downtime reason codes to log](/blog/downtime-reason-codes/). > **Classify before you rank** > > If Unclassified is larger than your third-ranked reason, the ranking can't be trusted yet. Spend a week getting reasons on stops before you pick a fix. #### Worked example: Baseline on an eight-machine CNC cell - Two shifts a day, 7.5 hours each after breaks, five days a week: 75 hours of planned production time per machine per week. - Eight machines over four weeks: 8 × 75 × 4 = 2,400 hours. - The sensors record 1,094 unplanned stops totaling 216 hours. **Result:** Unplanned downtime rate = 216 ÷ 2,400 = 9.0% ## Rank the reasons by hours Sum the hours under each reason and sort from largest to smallest. Rank by hours, not by number of stops, because the question is which reason takes the most capacity. | Reason | Stops | Minutes per stop | Hours | Share | |---|---|---|---|---| | Waiting for material | 64 | 45 | 48 | 22.2% | | Breakdown | 8 | 300 | 40 | 18.5% | | Tool change | 160 | 12 | 32 | 14.8% | | Waiting for operator | 90 | 20 | 30 | 13.9% | | Program prove-out | 20 | 78 | 26 | 12.0% | | Short stops | 720 | 2 | 24 | 11.1% | | Unclassified | 32 | 30 | 16 | 7.4% | Sample data for a hypothetical cell. Shares are of 216 hours and are rounded. By count, short stops lead with 720 and breakdowns come last with 8. By hours, waiting for material and breakdowns lead, and together they carry 88 of the 216 hours. Those two get the first fixes. Pick two reasons, not five. Each fix needs an owner, a target and a month of follow-up, and a team that runs five at once can't tell which one worked. To build the chart and its cumulative line, see [how to build a downtime Pareto](/blog/downtime-pareto/). To weigh reasons by dollars instead, see [how to price an hour of downtime](/blog/cost-of-downtime/). ## Split each reason into how often and how long Every reason's hours are the product of two numbers you can attack separately. **Hours lost to a reason** = Stops × average minutes per stop ÷ 60 The two leading reasons cost about the same, in opposite ways. Breakdowns are 8 stops of 300 minutes each. Waiting for material is 64 stops of 45 minutes each. A faster repair crew does nothing for the material waits, and better material staging does nothing for the breakdowns. Figure: Seven downtime reasons plotted by stops and minutes per stop, log scales. Breakdown: 8 stops of 300 min (40 h), top left. Waiting for material: 64 of 45 min (48 h), center. Short stops: 720 of 2 min (24 h), bottom right. *The two leading reasons cost similar hours from opposite corners: few long stops against many medium ones. Sample data.* Read the chart by position. A reason near the top is a duration problem: each stop lasts too long. A reason far to the right is a frequency problem: the machine stops too often, and each stop is too short for a faster response to matter. ## Match the fix to the pattern Once you know whether a reason is frequent, long or both, the lever follows. | Pattern | Example reason | Lever | Track | |---|---|---|---| | Rare and long | Breakdown | Faster response, spares, diagnosis | Minutes per stop | | Rare, long, same failure mode | Spindle bearing failure | PM on hours or condition | Stops per 1,000 run hours | | Frequent, medium length | Waiting for material | Stage material before the job | Stops per week | | Frequent, medium length | Waiting for operator | Staffing and machine assignment | Stops per shift | | Frequent and short | Jams, sensor trips | Fix the mechanism | Stops per shift | | Frequent and predictable | Tool change | Tool life plans, presetting | Minutes per change | | Clustered at shift edges | Start of shift | Handover procedure | Minutes per shift change | Track the number the lever moves. A frequency fix shows in the stop count before it shows in the hours. ### Cut how often it stops A frequency fix removes the cause, so the stop never happens. Ask what the machine was waiting for, and change the step upstream that made it wait. In the example cell, the material waits come from jobs released before their bar stock reaches the machine. Suppose the cell starts staging material at the machine one job ahead. Stops fall from 64 to 24, and each still lasts 45 minutes: 24 × 45 = 1,080 minutes, or 18 hours. The reason drops from 48 hours to 18, saving 30. Short stops need the same approach at a smaller scale: the jam, misfeed or sensor trip behind them. The cutoff and the OEE effect are in [micro-stops](/blog/micro-stops/). When the same failure mode keeps returning, prevention belongs here too: see [how to choose a maintenance strategy](/blog/maintenance-strategies/) for when a PM on run hours or on machine condition beats the calendar. ### Cut how long each stop lasts A duration fix accepts that the stop will happen and shortens it. Split one long stop into the time spent on each step, then cut the waiting steps first, because waiting adds minutes without adding repair. Figure: One breakdown split into steps. Before: 45 min for a technician, 60 diagnosing, 120 for parts, 60 repairing, 15 restarting, 300 min. After an alert and spares at the cell: 15, 60, 15, 60, 15, or 165 min, saving 18 h over 8 breakdowns. *Most of a 300-minute breakdown is waiting. Cutting the two waits saves 135 minutes a stop. Sample data.* In the example, 165 of the 300 minutes are waits: 45 for a technician to arrive and 120 for parts. Two changes take most of that out: - **An alert at 10 minutes** to the technician on shift, so nobody has to walk to the maintenance shop. The technician arrives 15 minutes after the stop instead of 45. - **The two parts that fail most** held at the cell, so the parts wait falls from 120 minutes to 15. Each breakdown now lasts 165 minutes. Over eight breakdowns that is 1,320 minutes, or 22 hours, down from 40. Set the alert above the machine's normal changeover and tool-change length. An alert that fires on every planned stop gets ignored within a week, and then it doesn't shorten the breakdowns either. > **Prevent the stop or shorten it?** > > Prevent it when the same failure mode repeats and the wear tracks run hours, part counts or a condition you can measure. Shorten it when the causes vary from stop to stop, or when the failure gives no warning. Most leading reasons need both: shorten first, because a faster response pays off in weeks while prevention takes a few failure cycles to prove. You don't need a predictive maintenance program to start. The first two fixes in most plants come from a stop log with reasons, a weekly look at the top of the ranking and an owner for each fix. ## Set a target and check that it held Set the target on the reason, not on the plant total. "Waiting for material under 20 hours in four weeks" can be checked. "Less downtime" can't. Compare the same four-week window, on the same machines, as a share of planned production time. A short week with a holiday has fewer stops and proves nothing. #### Worked example: The cell four weeks after both fixes - Waiting for material: 48 hours to 18 hours, saving 30. - Breakdown: 40 hours to 22 hours, saving 18. - Every other reason unchanged: 216 − 30 − 18 = 168 hours of unplanned downtime. **Result:** Unplanned downtime rate = 168 ÷ 2,400 = 7.0%, down from 9.0% The cell gets 48 machine hours back every four weeks, 12 hours a week. If a reason doesn't move, check whether the fix ran on every shift before you drop it. Small, repeating losses only show up in the weekly view. At Datwyler's injection molding plant, week-over-week reports showed that Tuesday shift transitions added 8 to 10 minutes of downtime every week. Acting on patterns like that, the plant cut shift-changeover downtime by 50% and material-changeover downtime by 30% within six months ([Datwyler story](/customers/datwyler/)). To run that review in 30 minutes with a one-page report, see [how to run a weekly downtime review](/blog/downtime-root-cause-review/). ## Run the plan with IoTFlows A SenseAi sensor on each machine detects every stop in seconds, with no PLC connection. Operators add the reason in a tap, and four automatic rules classify routine stops such as short downtimes and shift starts and ends. The [Downtimes report](/docs/monitoring/downtimes/#trends) ranks reasons by the hours they cost and trends them by week and by machine, which is your before-and-after check. A Machine Down alert reaches the right person at a warning time and a critical time. A classified stop [opens a work order](/blog/work-orders-from-downtime/) in [Maintain](/platform/maintain/) from the same dialog, with the machine and reason filled in. Within the first month, Sorinex achieved 60% faster issue identification and resolution, with real-time downtime categorization ([Sorinex story](/customers/sorinex-exercise-equipment/)). ## Your first 90 days 1. **Weeks 1–4: record the baseline.** Capture every stop on every machine in the area, with a reason on each. Change nothing yet, and write down the planned production time. 2. **End of week 4: rank and pick two.** Rank reasons by hours and pick the top two. Check that Unclassified is smaller than the third reason. 3. **Split each reason.** Write down the stop count and the minutes per stop for each of the two. Decide whether each is a frequency fix, a duration fix or both. 4. **Weeks 5–8: run one fix per reason.** Give each fix an owner and a target in hours for the next four weeks. Track the number the lever moves: stops for frequency, minutes for duration. 5. **Weeks 9–12: compare and decide.** Compare the reason with its baseline on the same machines and the same window length. Keep the fixes that held, make them standard work, and pick the next reason from the new ranking. ## Questions ### What is a normal unplanned downtime rate? In a NIST survey of US manufacturers using 2016 data, downtime averaged 7.8% of planned production time, and the quarter of plants that relied most on reactive maintenance reported 13.0%. Treat those figures as context, not targets. Your own four-week baseline, measured the same way every month, is the number to beat. ### Should changeovers be part of a downtime reduction plan? Keep planned changeovers out of the unplanned rate, so the number stays comparable from month to month. Changeovers still take capacity, so measure them on their own from last good part to first good part, and run a separate project to shorten them once the leading unplanned losses are under control. ### How long before a downtime fix shows up in the numbers? Compare the four weeks after a fix with the four weeks before it, on the same machines and as a share of planned production time. Frequent stops, such as waiting for material, show a change within a week or two. Rare, long stops such as breakdowns need the full window, because one breakdown more or less can swing a single week. ### Is preventive maintenance enough to cut unplanned downtime? Not on its own. In the NIST survey, plants attributed about a third of their downtime to reactive maintenance, which leaves about two thirds to other causes. Preventive work cuts failures that repeat with use or time. A ranked stop log shows which of your losses are failures and which are waits for material, operators or programs. ## Sources 1. [Economics of Manufacturing Machinery Maintenance: A Survey and Analysis of U.S. Costs and Benefits (NIST AMS 100-34)](https://nvlpubs.nist.gov/nistpubs/ams/NIST.AMS.100-34.pdf), National Institute of Standards and Technology, accessed Oct 16, 2026 2. [Manufacturing Machinery Maintenance](https://www.nist.gov/el/applied-economics-office/manufacturing-machinery-maintenance), National Institute of Standards and Technology, accessed Oct 16, 2026 --- # How to track machine downtime and its causes Source: https://www.iotflows.com/blog/how-to-track-machine-downtime/ Let a machine signal record every stop and ask operators only for the reason. A worked shift, rules that name routine stops, and a first-week checklist. > Question: How do I capture every stop and its reason without slowing production? ## Key takeaways - A machine signal should record when each stop starts and ends, so operators only supply the reason. - Paper logs miss stops of 1 to 3 minutes and round the long ones, so they understate downtime. - Rules can name short stops, shift edges and breaks, leaving operators only the stops that need judgment. - Give operators 8 to 12 reason codes, each named for something a person can fix and marked planned or unplanned. - Check the unclassified share daily and rank reasons by minutes weekly, with an owner for each of the top three. You capture every stop and its reason without slowing production by splitting the work. A machine signal records when each stop starts and ends, rules name the routine stops, and operators add a reason only to the stops a rule can't explain, in one tap at the machine. Nobody writes times down, so the record catches the two-minute stops a paper log misses. This guide is for plant managers and maintenance leads setting up downtime tracking on a cell or a whole floor. It works one shift by hand, shows which stops a rule can name, and ends with a checklist for the first week. ## What a downtime record holds > **Definition.** **Machine downtime** is the time a machine is stopped during scheduled production, from the moment it stops until it runs again. A stop counts in full whether or not anyone has recorded why it happened. The second half of that definition is the one plants get wrong. A stop with no reason is still downtime, as the [downtime glossary entry](/docs/get-started/glossary/#downtime) puts it. A reason changes what you can say about stopped time, not how much of it there is. Each stop becomes one record with a handful of fields. The trick is to ask each field from whoever already knows it. Figure: Three sources feed one stop record. The machine signal supplies start 10:30:12, end 10:52:40 and 22 min 28 s; rules name routine stops; the operator adds the reason Breakdown and a note. The record feeds a weekly Pareto. *One stop on a Haas VF-2: the machine supplies the times, and a person supplies only the reason. Sample data.* The machine knows when it stopped and restarted, to the second. A rule knows that a 90-second pause is a short stop, or that a stop inside the lunch window is lunch. Only a person knows that the coolant pump tripped. ## Why paper logs miss most stops Many plants estimate downtime rather than measure it. NIST's Machinery Maintenance Survey asked US discrete manufacturers what percent of planned production time is unplanned downtime, and NIST estimates the share at 7.8% across the sector.[1] NIST adds that the survey asks about issues that, "for many firms, are not formally tracked."[1] A paper log fails in a predictable way. It records the stops someone had time to walk over and write down, and it rounds them. A two-minute jam cleared at the machine never reaches the log sheet. #### Worked example: One shift on a CNC machining center - Shift: 06:00 to 14:00 with a 30-minute lunch, so planned production time is 450 minutes. - The machine signal records 27 stops: a 38-minute changeover, a 22-minute coolant pump fault, a 14-minute wait for material and 24 short stops of 1 to 3 minutes that add up to 48 minutes. - Measured downtime: 38 + 22 + 14 + 48 = 122 minutes. - The paper log shows three stops, written as 40, 20 and 15 minutes, for 75 minutes. The three long stops are on the log, rounded. None of the 24 short stops is. **Result:** Downtime missing from the log = 122 − 75 = 47 min, 38.5% of the shift’s downtime Figure: Two bars cover one shift from 06:00 to 14:00. The machine signal shows 27 stops totaling 122 min, including 24 short stops of 1 to 3 min. The paper log shows 3 stops totaling 75 min, so the log comes up 47 min short. *The same shift, recorded twice: the signal sees 27 stops and the log sees three. Sample data.* Whether those 48 short-stop minutes count against availability or performance depends on your short-stop cutoff, as [where micro-stops show up in OEE](/blog/micro-stops/#oee) explains. Either way, a paper log can't put them anywhere, because it never saw them. [Where the missing minutes come from](/blog/manual-vs-automatic-oee-tracking/#missing-minutes) breaks a paper log's gap down by source: rounded times, the shift start and short stops. ## Record the stop automatically Four methods can record when a machine stops. They differ in what they catch and in how much they ask of the operator. | | Paper log | Operator button | Machine sensor | Controller connection | |---|---|---|---|---| | Records stops under 2 minutes | No | Rarely | Yes | Yes | | Start and end times | Rounded, from memory | When someone presses | To the second | To the second | | Operator work per stop | Times and reason | Two presses and a reason | Reason only | Reason only | | Works on any machine age | Yes | Yes | Yes | No | | Reads alarm codes | No | No | No | Yes | | IT review | None | Network only | Network only | Yes, IT usually reviews it first | A button depends on someone pressing it at both ends of every stop. The two automatic methods don't. > **Sensor or controller signal?** > > Default to a machine sensor for the start and end of every stop, especially when your machines span brands and ages. Add a controller connection where you need what only the control knows, such as alarm codes and the running program. A connection to the controls is a security concern for many plants, so plan for an IT review. You don't need a controller connection to track downtime. Start time, end time and a reason are the whole record, and a sensor on the outside of the machine supplies the times on any machine. The [sensor and PLC comparison](/compare/sensor-based-vs-plc-machine-monitoring/) covers what each one sees. Two settings decide how clean the record is: - **Separate a stop from a pause in the cycle.** A machining center that pauses 20 seconds to change a tool between parts is running, not down. Set the stop threshold above the longest pause that belongs to the cycle, then check it against a stopwatch over 10 cycles. - **Keep missing data out of downtime.** When a sensor loses power or its connection, record that time as unknown, not as stopped. Otherwise a sensor unplugged over a weekend reads as 48 hours of downtime. The metrics reference calls this [unknown time](/docs/monitoring/metrics-reference/#unknown). ## Keep the reason list short > **Definition.** **Downtime reason code** is a short label that an operator or a rule puts on a stop to say why the machine stopped, such as Changeover or Waiting for material, so stopped minutes can be totaled and ranked by cause. The list decides whether the data is worth reading. An operator facing 40 codes on a touchscreen in the middle of a shift picks the first plausible one. The chart then ranks the order of your list, not the losses on your floor. Four rules keep a list usable: - **8 to 12 codes that operators pick**, each named for something a person can fix. `Machine problem` names nothing and wins every month. - **A planned flag on every code**, set when you build the list, so changeovers and preventive maintenance read apart from failures. - **A required note only where the code alone says nothing actionable**, such as `Breakdown` and `Other`. - **An owner for every code**, the person who acts when that code tops the chart. Split the list by who assigns each code. Rules assign `Short stop`, `Start of shift`, `End of shift` and `Lunch break`. Operators pick the rest, such as `Changeover`, `Waiting for material`, `Tool problem` and `Breakdown`. A full starter list with severities is in [which reason codes to log](/blog/downtime-reason-codes/#starter-list). Keep `No job scheduled` apart from the failure codes. A machine with no work is [idle rather than down](/blog/cost-of-idle-machines/#idle-vs-downtime), and the fix lives in the schedule, not on the floor. ## Get a reason without slowing the line The goal is fewer questions, not faster answers. In the example shift, 24 of the 27 stops were short stops. A rule that labels every stop under a 5-minute cutoff leaves the operator three stops to explain in 8 hours. Figure: Of 27 stops and 122 min recorded in one shift, a short-stop rule names 24 stops worth 48 min. The operator explains 3 stops worth 74 min: the changeover, the coolant pump fault and the wait for material, 60.7% of stopped minutes. *The rule takes the many short stops, so the operator answers three questions that hold most of the minutes. Sample data.* Those three stops hold 74 of the 122 stopped minutes, 60.7%. The operator spends attention where the time is, and the rule handles the rest with no one touching it. 1. **Classify short stops by rule.** Set a cutoff below the shortest stop you want a person to explain, such as 5 minutes. Every stop under it gets `Short stop` from one of the [automatic classification rules](/docs/monitoring/auto-downtime-rules/). 2. **Classify shift edges and breaks by schedule.** Stops at the start and end of a shift, and inside a lunch window, take their reason from the shift calendar. Turn these rules on only after the shifts in your system match the floor, or real downtime gets filed under `Lunch break`. 3. **Ask at the machine while the stop is open.** Put the reason picker at the machine, on a tablet or the machine's own screen. A reason chosen during the stop beats one reconstructed at the end of the shift. 4. **Classify a run of stops at once.** When five stops share one cause, such as a mold wash, select them together and [classify them in bulk](/docs/monitoring/classify-downtime/#bulk). Never clear a backlog by labeling it all `Other`. 5. **Split a stop that holds two causes.** A 90-minute stop where a changeover ran into a breakdown at minute 30 is two records: 30 minutes of `Changeover` and 60 minutes of `Breakdown`. 6. **Alert on stops that run long.** Set a warning above your normal changeover and a critical time well past it, for example 15 and 45 minutes. Someone then walks to the machine while the cause is still in front of them. [Machine Down alerts](/docs/alerts/asset-event-rules/#machine-status) take both thresholds. You probably don't need an end-of-shift review form. When the picker sits at the machine and rules cover the routine stops, the supervisor's job shrinks to the handful of stops still open at shift change. ## Check the record every day A downtime record can look complete and still be wrong. Three numbers tell you whether to trust it, and each takes a minute to read at the start of the day. | Check | What it tells you | Act when | |---|---|---| | Unclassified share of minutes | Whether reasons keep up with stops | It stays above 5% after week one | | Unknown time per machine | Whether the sensor stayed online | Any machine shows unknown time | | Share of minutes under Other | Whether the list fits the floor | Other passes 10% for a week | These thresholds are starting points, not standards. Tighten them once the record is stable. For example, on a 450-minute shift with 122 stopped minutes, 5% is about 6 minutes. If the morning report shows 30 unclassified minutes on one machining center, ask that shift's operator today, while they still remember. Read the notes under `Other` once a week: a cause that repeats there is the next code to add. ## Review the stops every week A *downtime Pareto* ranks reasons by the minutes they cost, longest first, with a running total. It shows how few reasons make up most of the loss. Rank by minutes, not by count. In the example shift, `Short stop` is 24 of 27 stops, 88.9%, so a chart by count shows little else. Ranked by minutes, `Short stop` holds 48 of 122, 39.3%, and the 38-minute changeover sits close behind it. One changeover costs nearly as much as two dozen jams, and only the chart by minutes shows it. > **Is Unclassified your tallest bar?** > > Then the chart ranks missing reasons, not causes. Fix the code list or the rules before you read anything else into it. Review the chart at a [fixed weekly slot](/blog/downtime-root-cause-review/#agenda), with production, maintenance and the shift leads in the room. Take the top three reasons, give each an owner and a date, and check last week's three against this week's chart. [Building a downtime Pareto](/blog/downtime-pareto/) works a full week through. The IoTFlows docs show how to read [the Pareto and trend charts](/docs/monitoring/downtimes/#pareto). Datwyler's injection molding plant in Ontario, California, runs this pattern on more than 20 machines. Automatic rules classify short downtimes and stops at the start and end of each shift, and operators and supervisors classify the rest. Week over week, the reports showed that Tuesday shift transitions added 8 to 10 minutes of downtime every week. Within six months the plant cut shift-changeover downtime 50% and material-changeover downtime 30%, as [Datwyler's story](/customers/datwyler/) describes. ## Track downtime automatically A SenseAi sensor mounts magnetically on the outside of each machine and reads its vibration and sound, with no PLC connection. It decides running or stopped every second, so every stop is on the machine's timeline within seconds and no one writes anything down. Operators put a reason on a stop in a tap, at the machine, in Operator View or in the iOS app. Reason codes sit under severity headings, with required notes and planned flags. Four automatic rules classify short downtimes, shift starts and ends, and a machine down for a whole shift, and break windows cover lunch and breaks. The Downtimes report ranks reasons by the hours they cost, with trends by interval and by machine. A classified stop can open a Maintain work order from the same dialog. See how the pieces fit on [downtime tracking](/solutions/downtime-tracking/). ## Start tracking downtime this week 1. Enter your shifts and time zone before you read any number, because shift-edge and break rules depend on them. 2. Pick one cell to start, ideally the one that limits output. 3. Record start and end times from a machine signal, and check one shift against a stopwatch. 4. Load 8 to 12 operator reason codes, each with a planned flag and an owner. 5. Turn on the short-stop rule on day one, and the shift-edge rules once the shifts match the floor. 6. Set long-stop alerts above your normal changeover time. 7. Read the three daily checks each morning. 8. After one week, read the Pareto and give the top three reasons an owner and a date. You don't need OEE to start. Stopped minutes by reason are the input to availability, so a clean stop log makes [calculating OEE](/blog/how-to-calculate-oee/) arithmetic later. ## Questions ### How short a stop should I record? Record every stop the signal sees, then decide which ones need a person. Pauses that belong to the cycle, such as a tool change, are not stops at all. Set a short-stop cutoff below the shortest stop you want a person to explain, such as 5 minutes, and let a rule label everything under it. Review the short-stop total each week, because hundreds of brief stops can add up to hours. ### Should I track planned downtime too? Yes. Record changeovers, preventive maintenance and breaks as stops with a planned flag, so you can read them apart from breakdowns. Planned stops still cost hours. A changeover can be the largest single reason on the chart, and shrinking it returns capacity the same way fixing a breakdown does. ### Does an unclassified stop still count as downtime? Yes. A stop counts in full from the moment the machine stops until it runs again, whether or not anyone has given it a reason. Classifying a stop changes what you can say about the time, not how much of it there is, so a large unclassified share hides causes but never shrinks the total. ### Who should classify a stop, the operator or the supervisor? The operator at the machine, while the stop is open, because that person saw what happened. Give supervisors the stops left unclassified at the end of the shift and the stops that need a second opinion, such as a breakdown note that names no part. A reason added the next morning is a guess. ## Sources 1. [Economics of Manufacturing Machinery Maintenance: A Survey and Analysis of U.S. Costs and Benefits (NIST AMS 100-34)](https://nvlpubs.nist.gov/nistpubs/ams/NIST.AMS.100-34.pdf), National Institute of Standards and Technology, accessed Oct 16, 2026 --- # Usage-based maintenance from run hours and part counts Source: https://www.iotflows.com/blog/usage-based-maintenance/ Usage-based maintenance makes PM due on run hours or parts made, not dates. Pick the unit, set the first interval, size the warning and keep dates where needed. > Question: How do I trigger maintenance from hours run or parts made instead of the calendar? ## Key takeaways - Usage-based maintenance makes a task due when run hours or parts made reach its interval, not on a date. - Put a task on a meter when the wear builds up with use and the machine’s load changes week to week. - Count what the wear item sees: running hours for a spindle, strokes for a die, shots for a mold. - Early warning time equals the run hours or parts left at the warning point, divided by daily usage. - Reset the meter on the day the work is done, and adjust the interval from the condition found. You trigger maintenance from hours run or parts made by giving each task a usage meter instead of a date. The meter adds up the machine’s run hours or part count, warns the maintenance team as the total nears the task’s interval, and opens the work order when it gets there. When the job is done, a reset starts the next cycle, so every service lands after the same amount of work. This guide is for maintenance leads moving tasks off the calendar. It covers which tasks belong on a meter, which unit to count, how to set the first interval and how early to warn. ## What is usage-based maintenance? > **Definition.** **Usage-based maintenance** is preventive maintenance that falls due when a machine has done a set amount of work, counted in run hours, cycles or parts made, instead of on a date. Each task carries an interval in that unit, and the running total decides when the task is owed. It isn’t a separate strategy. NIST describes preventive maintenance as work scheduled on predetermined units, and names machine run time and cycles as the examples.[1] NASA’s reliability-centered maintenance guide defines preventive maintenance as work at predefined intervals of time, operating hours or cycles.[2] The record that does the counting is a *meter*: a running total on one machine that rises with use and returns to zero only when someone resets it. A *trigger point* is the reading at which the task is due. The [glossary entry for a meter](/docs/get-started/glossary/#meter) uses the same terms. | Trigger | The task is due when | Example | |---|---|---| | Calendar | A date arrives | Weekly press clutch and brake check | | Usage | Run hours or parts reach an interval | Spindle grease every 500 run hours | | Condition | A measurement crosses a limit | Vibration above a set velocity | ## Why the calendar drifts when the load changes A calendar interval is a usage interval with a usage rate baked in. “Monthly” on a grease task means “about as many hours as the machine ran in a month when someone wrote the plan.” When the machine runs more or less than that, the work lands late or early. For example, take a CNC lathe with a 250-hour grease interval, scheduled every 4 weeks on the assumption that it runs about 62.5 hours a week. Over 12 weeks, its load follows the order book. #### Worked example: 12 weeks on one CNC lathe, 250-hour grease interval - Weeks 1–4: 40, 40, 35 and 45 run hours, 160 in all. - Weeks 5–8: 80, 85, 80 and 75 run hours, 320 in all. - Weeks 9–12: 40, 20, 30 and 40 run hours, 130 in all. On the calendar, the lathe is greased at 160 hours (64% of the interval), then at 320 hours (128%), then at 130 hours (52%). On a 250-hour meter, it is greased in week 6 and again in week 9, at 250 hours each time. **Result:** 610 run hours: 3 calendar services, 2 early and 1 late; 2 meter services, both on interval Figure: Weekly run hours on a CNC lathe over 12 weeks, from 20 to 85 hours. Calendar greasing every 4 weeks lands at 160, 320 and 130 run hours; a 250-hour meter greases it twice, at 250 hours each time. *The same 12 weeks of run hours, serviced by date and by meter. Sample data.* The two early services spend labor and grease the bearing didn’t need yet. The late one runs it 70 hours past its interval in the busiest month, when a failure costs the most. [Altium Packaging](/customers/altium-packaging/) met the same problem with a Slide Knife that needs inspecting every 100,000 bottles. A line that ran fast reached the count early, a slow one reached it late, and a date-based schedule was always early or overdue. How far the calendar drifts depends on how much a machine’s hours swing, which is what [machine utilization](/blog/what-is-machine-utilization/) measures. ## Which tasks belong on a meter? Put a task on a meter when the wear it prevents builds up with use. NASA’s RCM guide notes that simple items subject to metal fatigue or mechanical wear, and items designed as consumables, often show a direct link between age and reliability. For those items, it says, an age limit based on operating time or stress cycles can work.[2] Most equipment doesn’t behave that way, as [how failures behave](/blog/maintenance-strategies/#failure-patterns) explains. In the three studies NASA summarizes, drawn from airline, Swedish and US Navy data, 77% to 92% of failures were random rather than age-related.[2] The same guide warns that timed maintenance can be unnecessary and sometimes harmful. NIST relays an estimate from a 2016 paper that preventive maintenance is applied unnecessarily up to 50% of the time in manufacturing.[1] A meter fixes when a task happens. It can’t make the task worth doing. | | Calendar | Run hours | Part count | Condition | |---|---|---|---|---| | Wear builds with | Elapsed time | Running time | Cycles or parts | Not tied to age | | Machine load | Steady | Varies | Varies, speed too | Any | | Example task | Press clutch and brake check | Spindle or gearbox grease | Die sharpening | Bearing with rising vibration | | Due date known ahead | Yes | Forecast from usage | Forecast from usage | No | > **Meter, calendar or condition?** > > Choose a run-hour meter when the wear happens while the machine runs and its hours change from week to week. Choose a part-count meter when the wear happens per cycle, so a faster run should bring the service sooner. Keep the calendar when a regulation or the manual dates the task: OSHA requires the clutch/brake mechanism of a mechanical power press to be inspected and tested at least weekly, whatever its stroke count, unless the press meets the standard’s control-reliability and brake-monitoring requirements.[3] You don’t need a meter on a part that fails at random. Watch its [condition](/solutions/predictive-maintenance/) instead, or let it run to failure if a breakdown costs little. ## Choose what the meter counts Pick the wrong unit and every interval you set on it is wrong too. Count what the wear item experiences, not whatever number happens to be on the screen. ### Run hours Decide which hours count before you set an interval. Power-on hours include a machine sitting idle between jobs; running hours count only while it works. For wear on a spindle, a gearbox or a pump, count running hours. A Haas VF-2 left powered on through a two-hour wait for material adds two hours to its power-on clock and nothing to the spindle’s wear. ### Parts, cycles and strokes A part count and a cycle count differ whenever one cycle makes more than one part. A [four-cavity mold](/blog/monitor-injection-molding-machines/#double-half) makes four parts per shot, but its ejector pins move once per shot. A meter counting parts reaches a shot-based interval four times too early unless you multiply the interval by the cavities. The multiplier is the [quantity per cycle](/docs/get-started/glossary/#quantity-per-cycle). Check the count against a hand count over ten parts before you trust a meter with it. A count that reads double or half points to that multiplier, not to the sensor, as the [part count troubleshooting guide](/docs/production/troubleshoot-part-counts/#start) explains. | Wear item | Count | Why | |---|---|---| | Spindle or gearbox grease | Running hours | Wears while turning | | Coolant and way-lube filters | Running hours | Loads while the pumps run | | Stamping die | Strokes | Edges dull with every hit | | Mold ejector pins | Shots | One movement per shot | | Bottling-line wear part | Bottles | Wears with every bottle passed | ## Set the first interval 1. **Start from the manual’s unit.** Use the interval the manufacturer gives in hours, cycles or strokes as it stands. If the manual gives both an hours limit and a time limit, keep both and do the work at whichever comes first. 2. **Convert dated tasks from measured hours.** For a task you only have as a date, take the run hours the machine averaged per period while that task kept it healthy. A monthly task on a machine that averaged 230 run hours a month becomes a 230-hour trigger point. 3. **Don’t use MTBF as the interval.** *Mean time between failures (MTBF)* is the average run time between breakdowns. It gives the average age at failure, not the most likely one, and says nothing about whether failures rise with age. NASA’s guide notes that MTBF is often the starting point for preventive intervals and names exactly that weakness.[2] 4. **Record the as-found condition.** At every service, have the technician note what they found: worn past the limit, borderline or like new. That record is your evidence for changing the interval. 5. **Adjust the interval in steps.** If three services in a row find the part like new, lengthen the interval one step, for example from 230 to 260 hours. If one finds it worn past the limit, shorten it. NASA calls this *age exploration*: adjusting a task’s interval until you know the rate at which the part’s resistance to failure declines.[2] ## Warn early enough to stage the job A meter that acts only at 100% opens the work order the moment the task is due. That is too late when the job needs a part you don’t stock. Give the meter an early warning, and size it from how fast the machine uses up the interval. **Warning lead time (days)** = (1 − warning point) × trigger point ÷ usage per day #### Worked example: An 85% warning on a 500-hour grease meter - Trigger point: 500 run hours. Warning at 85%: 425 run hours, which leaves 75 hours. - One shift, 8 run hours a day: 75 ÷ 8 = 9.4 days of warning. - Two shifts, 16 run hours a day: 75 ÷ 16 = 4.7 days. - Around the clock, 22 run hours a day: 75 ÷ 22 = 3.4 days. **Result:** With a 5-day lead time on the grease kit, the 85% warning comes too late at 16 or 22 run hours a day Figure: A 500-hour meter with an email at 425 hours leaves 75 hours of warning: 9.4 days at 8 run hours a day, 4.7 days at 16 and 3.4 days at 22. Only the one-shift rate clears a 5-day part lead time. *The same 85% warning gives less notice the harder the machine runs. Sample data.* The same arithmetic applies to part counts, and it shrinks fast on a quick line. On a 100,000-bottle meter, the last 15% is 15,000 bottles: about 107 minutes at 140 bottles a minute, and 12.5 hours at 20 a minute. On a line that fast, the warning is a cue to stage the kit and book the stop, not to order parts. When the warning can’t cover a part’s lead time, keep the part on the shelf instead of ordering it per job. One spare with a reorder point covers every machine that uses it. ## Reset on the work, not the work order A meter measures the work since the last service, so the reset has to mark the service. Reset when the technician finishes the job, and date the reset to the day the work was done. Resetting when the work order opens starts the next cycle before the grease is in. Every day the order waits in the backlog then comes out of the next interval, and nobody sees it. Three more rules keep the count honest: - **Reset early work too.** A technician who greases the lathe at 210 hours during a changeover resets the meter then, so the next service lands 250 hours after the real one. - **Leave skipped work unreset.** The meter keeps counting past the trigger point, and the overrun records how late the job is. - **Keep a dated task beside the meter** when the manual also sets a time limit, on the same [preventive maintenance schedule](/blog/preventive-maintenance-schedule/) as your calendar work. A meter on an idle machine stops counting, and a time limit doesn’t. ## Run usage-based maintenance in IoTFlows In Maintain, a meter counts a machine’s runtime hours or parts toward a trigger point from the machine’s own data, so nobody types a reading in. Each meter has three behaviors you switch on separately: an email at 85%, an email at the trigger point and an automatic work order at 100%. The meter card forecasts the time left at the rate the machine has run since its last reset. A reset, which you can backdate to the day of the job, starts the next cycle. Altium Packaging inspects its Slide Knife this way, every 100,000 bottles, with the work order opened automatically. See how to [set up a meter](/docs/maintain/meters/), or how [Maintain](/platform/maintain/) ties work orders to the machines that need them. ## Before you move a task to a meter - The wear the task prevents builds up with use, not with time and not at random. - The unit matches what the wear item sees: running hours, cycles, strokes or parts. - The count matches a hand count over ten parts. - The trigger point comes from the manual or from measured hours, never from MTBF. - The warning leaves more time than the job’s lead time at your busiest usage rate. - Resets are dated to the day the work was done, with the as-found condition recorded. - Any time limit from the manual or a regulation stays on a dated task. ## Questions ### What is the difference between usage-based and condition-based maintenance? Usage-based maintenance makes a task due when the machine has run a set number of hours or made a set number of parts, whatever state the part is in. Condition-based maintenance makes it due when a measurement, such as vibration or temperature, crosses a limit. Use usage for wear that tracks the work done, and condition for failures that give a measurable warning first. ### Is usage-based maintenance a kind of preventive maintenance? Yes. The task is planned in advance and done whether or not the part shows wear, which is what makes it preventive. Only the clock changes, from the date to the hours the machine ran or the parts it made. NIST and NASA both list run time and cycles as ways to schedule preventive work. ### How do I convert a monthly PM into a run-hour interval? Take the run hours the machine averaged per month over a period when the monthly task kept it healthy, and use that figure as the trigger point. A machine that averaged 230 run hours a month gets a 230-hour trigger. Then lengthen or shorten it in steps from the condition the technician records at each service. ### What happens to a usage meter when the machine sits idle? It stops counting, so the task stops coming due. That is correct for wear that only happens while the machine runs. If the manual also sets a time limit, or a regulation dates the inspection, keep a calendar task beside the meter and do the work at whichever comes due first. ### Should a meter count parts or machine cycles? Count whatever the wear item experiences. The ejector pins on a four-cavity mold move once per shot, while a trimmer downstream handles every part. If the meter counts parts but the interval was written in shots, multiply the interval by the cavity count, or the task comes due four times too early. ## Sources 1. [The Costs and Benefits of Advanced Maintenance in Manufacturing (NIST AMS 100-18)](https://doi.org/10.6028/NIST.AMS.100-18), National Institute of Standards and Technology, D. Thomas, April 2018, accessed Oct 16, 2026 2. [Reliability-Centered Maintenance Guide for Facilities and Collateral Equipment](https://www.nasa.gov/wp-content/uploads/2023/06/nasa-rcmguide.pdf), National Aeronautics and Space Administration, September 2008, accessed Oct 16, 2026 3. [29 CFR 1910.217, Mechanical power presses](https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.217), Occupational Safety and Health Administration, accessed Oct 16, 2026 --- # What is machine utilization, and how do you calculate it? Source: https://www.iotflows.com/blog/what-is-machine-utilization/ Machine utilization is running time divided by the time a machine could have run. Learn the four denominators, work one week by hand and pick the right one. > Question: How do I calculate machine utilization, and which denominator should I use? ## Key takeaways - Machine utilization is running time divided by available time, and the figure means nothing until you state the denominator. - One lathe’s 48 running hours in a week read 28.6%, 60.0%, 64.9% or 61.5%, depending on the denominator. - Use measured shift time to run the plant, planned production time for OEE and calendar time for capacity decisions. - Keep time the sensor was offline out of the figure, because missing data is not downtime. - Roll up shifts and machines by adding hours and dividing once, never by averaging percentages. You calculate machine utilization by dividing the hours a machine ran by the hours it could have run, and the denominator you choose decides what the number means. Use running plus stopped time inside your shifts to run the plant and compare machines, planned production time when the figure feeds OEE, and all calendar time when you decide whether to add a shift or buy a machine. This guide is for plant managers and owners who want a utilization figure they can defend. It works one lathe’s week through four denominators, then shows how to roll machines and shifts up without distorting the result. ## What machine utilization measures > **Definition.** **Machine utilization** is the share of available time a machine spends running: running time divided by the time the machine could have run, where available time is calendar time, scheduled shift time, planned production time or measured shift time, named beside the figure. The IoTFlows [utilization glossary entry](/docs/get-started/glossary/#utilization) uses measured shift time: running time over running plus stopped time, inside your shifts. That is one valid choice of several. The rest of this guide shows where each one belongs. **Machine utilization** = (Running time) ÷ (Available time, with its definition stated) ### What counts as running The numerator needs a definition too. *Running* means the machine is in its cycle: a spindle working through a program, a press stroking, a molding machine cycling. | Numerator | What it counts | Where it comes from | |---|---|---| | Powered on | Every hour the main switch is on | Hour meter or current draw | | In cycle | Hours the machine is doing work | Vibration, controller state or counts | | In cut | Hours the tool is in the material | Spindle load or controller data | Use in-cycle running time as the default. Powered-on hours overstate utilization, because a machine left on through lunch counts as busy. For example, a lathe left powered on for a 16-hour day that cycled for 9 of those hours reads 100% on a power meter and 56.3% in cycle. In-cut time answers a narrower machining question. It belongs in a spindle study, not in a plant report. ## Four denominators, four different numbers The same running hours give four utilization figures, depending on what you divide by. None of them is wrong. Each answers a different question, so the mistake is quoting a number without its denominator. | Denominator | What it includes | Question it answers | |---|---|---| | All calendar time | Every hour, 24 × 7 | How much of the week does it run? | | Scheduled shift time | Every staffed hour | How busy are the staffed hours? | | Planned production time | Shift time minus time scheduled off | What is OEE availability? | | Measured shift time | Running plus stopped, offline out | How did each machine run? | *Planned production time* is the time a machine is scheduled to produce: shift time minus the time nobody intends to run it, such as breaks and maintenance windows with the machine scheduled off. Running time over planned production time is availability, the first factor of OEE, and [planned vs unplanned downtime](/blog/planned-vs-unplanned-downtime/#availability) sets out which stops stay in. *Measured shift time* is the running and stopped time a monitoring system recorded inside your shifts. It leaves out any stretch with no data, so a dead network link doesn’t count as a stopped machine. Calendar time needs one more step. Vorne defines utilization as planned production time divided by all time, the factor TEEP multiplies OEE by: two 8-hour shifts, five days a week, give 80 of 168 hours, or 47.62%.[1] That measures how much of the week you schedule. Multiply that schedule figure by availability and you get running time over calendar time. For the same two shifts, a machine that runs 48 of its 80 planned hours runs 28.6% of the week. Equipment standards split the term too. SEMI E10, the semiconductor industry’s specification for equipment time, defines two utilization metrics: total utilization and operational utilization.[4] > **Which denominator should you quote?** > > Use measured shift time to run the plant, set shift goals and compare machines. Use planned production time when the figure goes into OEE. Use calendar time when you decide whether to add a shift, run weekends or buy a machine. > > You don’t need all four on one report. Pick the one that matches the decision, and print its name beside the number. ## Work one week by hand Take one machine and one week, then divide the same running hours four ways. #### Worked example: One week on a Haas ST-20 lathe - Calendar: 168 hours. - Schedule: two 8-hour shifts, five days, so 80 scheduled hours. - Planned stops: a 30-minute lunch in each of the 10 shifts (5 hours) and a 1-hour preventive maintenance window with the lathe scheduled off, so 6 hours. Planned production time is 80 − 6 = 74 hours. - Sensor offline: 2 hours on Tuesday after a Wi-Fi drop, so 78 hours were measured. - Running: 48 hours. Stopped: 30 hours, including the 6 planned hours. Calendar time: 48 ÷ 168 = 28.6%. Scheduled shift time: 48 ÷ 80 = 60.0%. Planned production time: 48 ÷ 74 = 64.9%. Measured shift time: 48 ÷ (48 + 30) = 61.5%. **Result:** The same 48 running hours read 28.6%, 60.0%, 64.9% or 61.5% Figure: Four bars share one 48-hour running segment. Against 168 calendar hours the lathe reads 28.6%, against 80 scheduled hours 60.0%, against 74 planned production hours 64.9%, and against 78 measured shift hours 61.5%. *One lathe’s week: the running hours stay fixed while the denominator changes the figure. Sample data.* The spread runs from 28.6% to 64.9% for one machine in one week. A manager who reads 60% on one report and 29% on another is looking at the same machine through two denominators, not at two performances. The 3.4 points between the measured and the planned figures come from two opposite moves. The planned figure removes the 6 hours of lunches and maintenance, and it keeps the 2 offline hours, because a calculation from the schedule can’t tell them from a stop. ## What to count, and what to leave out Every hour of the week falls in one bucket. The table shows which buckets each denominator includes. Running hours are always the numerator. | Hours that were | Calendar | Scheduled | Planned | Measured | |---|---|---|---|---| | Running | Yes | Yes | Yes | Yes | | Stopped while meant to run | Yes | Yes | Yes | Yes | | Idle, no job scheduled | Yes | Yes | Plant’s choice | Yes | | Breaks, maintenance scheduled off | Yes | Yes | No | Yes | | Sensor offline | Yes | Yes | Yes | No | | Outside the shifts | Yes | No | No | No | Yes means the hours are in the denominator. Measured shift time is the default for running the plant. Three buckets need a written rule. - **Offline time.** Keep it out of a day-to-day figure. A sensor unplugged over a weekend produces 48 hours with no data, not 48 hours stopped. See how a monitoring system reports [unknown time](/docs/monitoring/metrics-reference/#unknown). - **Breaks.** Decide once, for the whole plant. Leave breaks in when you ask where the shift went, and remove a legally required break when you compare machines or hold a team to a goal. - **Idle hours.** A machine with no job inside a staffed shift is stopped, and measured shift time counts it. Whether idle hours belong in planned production time is a plant decision, and the [cost of idle machines](/blog/cost-of-idle-machines/) shows what those hours cost you. > **Don’t change the rule mid-trend** > > A trend line is only valid while its denominator stays the same. If January counts lunches as stopped and February removes them, February’s utilization rises by the length of the lunches with no change on the floor. Note the rule on the report, and restate old months when you change it. ## Roll up shifts and machines by hours Add the running hours and the available hours across shifts or machines, then divide once. Averaging the percentages gives a 6-hour shift the same weight as a 10-hour one. #### Worked example: Two shifts of different lengths on one machine - First shift: 10 measured hours, 8.5 running. Utilization is 8.5 ÷ 10 = 85.0%. - Second shift: 6 measured hours, 2.4 running. Utilization is 2.4 ÷ 6 = 40.0%. - Average of the two percentages: (85.0% + 40.0%) ÷ 2 = 62.5%. **Result:** Pooled utilization = (8.5 + 2.4) ÷ (10 + 6) = 10.9 ÷ 16 = 68.1% Figure: A 10-hour first shift at 85% and a 6-hour second shift at 40%. Averaging the two percentages gives 62.5%. Pooling the hours gives 10.9 running hours of 16, or 68.1%. *Averaging percentages undercounts the longer shift; pooling hours weights each shift by its length. Sample data.* The 5.6-point gap is the shorter shift getting a vote it didn’t earn in hours. The same rule holds across a fleet: a cell figure built from pooled hours lets the machine with the most hours carry the most weight. A pooled figure still hides which machine is losing the hours. Place [each machine against the range for its type](/blog/utilization-goals-by-machine-type/#diagnose) before you decide what to fix. ## Utilization, capacity utilization and OEE Five metrics share the word or the inputs, and they measure different things at different scales. | Metric | Formula | Scale | |---|---|---| | Machine utilization | Running time ÷ available time | One machine or cell | | Availability | Run time ÷ planned production time | One machine or line | | OEE | Availability × performance × quality | One machine or line | | TEEP | OEE × planned time ÷ all time | One machine, whole calendar | | Capacity utilization | Output ÷ sustainable capacity | Plant, industry or economy | > **Definition.** **Capacity utilization** is output divided by sustainable capacity: what a plant, an industry or an economy produced as a share of what the same assets could produce at a sustainable pace, measured in units of output rather than hours of machine time. The Federal Reserve computes capacity utilization for US industry as a seasonally adjusted output index divided by a capacity index.[3] US manufacturing ran at 75.7% in August 2026, against a 1972–2025 average of 78.2%.[2] That is an output measure across an industry, so don’t hold one machine’s running hours against it. For example, a line that can make 10,000 units a week on its normal schedule and makes 7,800 runs at 78.0% capacity utilization. If it ran 100 of its 120 scheduled hours, its time-based utilization is 83.3%. The rest of the loss is in the rate the line ran at. Utilization inside your shifts, with breaks removed, is the availability factor of [OEE](/blog/what-is-oee/). OEE also multiplies in performance and quality, so a machine can post 90% utilization while running at half its ideal speed. TEEP goes the other way and adds the calendar. In Vorne’s example, a 65% OEE on two shifts, five days, gives a TEEP of 30.95%.[1] The [guide to utilization, uptime, OEE and TEEP](/blog/utilization-uptime-oee-teep/) works one week through all of them, OOE included. ## What is a good machine utilization rate? No single rate fits every machine. Mike Lynch, writing in Modern Machine Shop, describes shops that can justify almost any effort to pass 95% spindle run time and others satisfied below 20%, and advises improving the [machines that cause bottlenecks](/blog/find-the-bottleneck/).[5] A machine that isn’t the constraint can sit idle for long stretches and still be used correctly.[5] For example, a deburring station that keeps up with three mills at 35% utilization needs no improvement project. A low figure there is information about the schedule. How much of the cycle an operator carries sets the ceiling. For example, the IoTFlows [CNC machine guide](/docs/production/cnc-machines/#expectations) expects 40–60% uptime inside shifts on a manual, operator-intensive CNC and 75–85% on a fully automatic one. The [utilization ranges by machine type](/blog/utilization-goals-by-machine-type/) cover presses, molding machines and lights-out cells. Use those ranges for planning only. Set the first goal from your own baseline: 1. **Measure a full quarter.** Collect running and stopped time on every machine for one complete quarter, with the same denominator throughout. 2. **Read each machine’s figure.** Use the per-machine result as that machine’s baseline, not the plant average. 3. **Set the goal a few points above.** A machine at 48% gets a goal of 55%, not 85%. A goal the machine has never met teaches operators to ignore the number. 4. **Hold it for a quarter.** Leave the goal alone for a quarter, then raise it when the machine gets there. The [goal-setting guide](/docs/monitoring/oee-goals/#choosing) walks through it. ## Measure utilization from the machine IoTFlows puts a sensor on each machine that [decides running or stopped](/blog/how-sensors-detect-machine-state/) every second from vibration and sound, with no PLC connection. Utilization is measured inside your shifts: running time over running plus stopped, with offline time reported separately as unknown and kept out of both. Set your [shifts and time zone](/docs/admin/shifts-and-timezone/) first, because they bucket every number as it arrives. The Advanced Report then shows any period by machine, and its **Exclude None** switch removes stops of severity None, such as a mandated lunch, from both terms. See [what the number includes](/docs/monitoring/advanced-report/#switches). Storm Power Components doubled machine utilization with SenseAi on its CNC machines, lasers and presses, and now schedules on real utilization data. Read the [Storm Power story](/customers/storm-power-components/). See how the sensor, shifts and reports fit together on [machine utilization tracking](/solutions/machine-utilization/). ## Before you report a utilization figure Run this list against any utilization number before it goes on a wall, into a meeting or into a capacity plan. - **Name the denominator** beside the figure: “61.5% of measured shift time”, not “61.5%”. - **Match it to the decision:** measured shift time to run the plant, planned production time for OEE, calendar time for a shift or machine purchase. - **Count in-cycle time** as running, not powered-on time. - **Keep offline hours out,** and fix the connection that caused them. - **Fix the rule for breaks and idle hours** once, plant-wide, and note it on the report. - **Pool hours** across shifts and machines, never average percentages. - **Set goals** from each machine’s last full quarter, then read the machines one by one. ## Questions ### Is machine utilization the same as uptime? When utilization is measured inside your shifts as running time over running plus stopped time, it is the same percentage as uptime. Remove breaks and other time nobody meant to run the machine from the denominator and it becomes OEE availability. Utilization against calendar time is a different number, because it also counts every hour with no shift scheduled. ### Should breaks count against machine utilization? Decide once for the whole plant and write the rule down. Leave breaks in when you want the figure to add up to the length of the shift. Remove a legally required break when you compare machines or hold a team to a goal, since nobody is accountable for that time. Never change the rule partway through a trend. ### Can machine utilization be over 100%? Not when the running hours sit inside the denominator. A figure above 100% means the machine ran outside the time you divided by, for example Saturday overtime counted against a Monday to Friday schedule. Add the extra hours to the denominator, or report them on their own line. ### How is spindle utilization different from machine utilization? Spindle utilization narrows the numerator to the time the tool is cutting, so tool changes, rapid moves and probing inside the cycle drop out. On the same machine it reads lower than in-cycle utilization. Use it to study cutting efficiency on a machining center, and in-cycle running time for plant reports and goals. ## Sources 1. [TEEP: Total Effective Equipment Performance](https://www.oee.com/teep/), Vorne Industries (OEE.com), accessed Oct 16, 2026 2. [Industrial Production and Capacity Utilization, G.17 (release of September 18, 2026)](https://www.federalreserve.gov/releases/g17/current/default.htm), Federal Reserve, accessed Oct 16, 2026 3. [About the Industrial Production and Capacity Utilization release (G.17)](https://www.federalreserve.gov/releases/g17/About.htm), Federal Reserve, accessed Oct 16, 2026 4. [SEMI E10: Specification for Definition and Measurement of Equipment Reliability, Availability, and Maintainability (RAM) and Utilization](https://store-us.semi.org/products/e01000-semi-e10-specification-for-definition-and-measurement-of-equipment-reliability-availability-and-maintainability-ram-and-utilization), SEMI, accessed Oct 16, 2026 5. [Judging Acceptable Spindle Run Time](https://www.mmsonline.com/columns/judging-acceptable-spindle-run-time), Modern Machine Shop, accessed Oct 16, 2026 --- # What utilization to expect by machine type Source: https://www.iotflows.com/blog/utilization-goals-by-machine-type/ A manual CNC runs 40–60% of the shift, a coil-fed press 65–80% and a lights-out cell 80–90%. See why loading sets the ceiling and how to set each goal. > Question: What uptime is realistic for a manual CNC, a coil-fed press or a lights-out cell? ## Key takeaways - A manual CNC runs 40 to 60% of the shift, a coil-fed press 65 to 80% and a lights-out cell 80 to 90%. - Handling time inside each cycle caps uptime before a single breakdown happens, so the loading method sets the ceiling. - A lights-out figure only means something when the measured window includes the unattended hours. - Spindle in-cut time and welding arc-on time use narrower numerators, so they read far below machine uptime. - Use the ranges to check a baseline, then set each goal at the machine’s own baseline plus 5 to 10%. A manual CNC runs 40 to 60% of the shift, a [coil-fed stamping press](/blog/how-to-monitor-stamping-presses/) 65 to 80%, and a lights-out cell 80 to 90%, because how much of each cycle a person carries sets the ceiling on uptime. These are the planning ranges IoTFlows publishes for uptime measured inside your shifts. Use them to check that a machine’s number is plausible, then set its goal from its own history. This guide is for plant managers and owners who have been handed one utilization target for every machine on the floor. It explains where each range comes from, works three CNC shifts and a press shift by hand, and ends with a goal-setting method you can run on your own data. ## What uptime measures here Every range in this guide uses one definition, so state it before comparing anything. > **Definition.** **Uptime** is the share of a measured window a machine spends running: running time divided by running plus stopped time inside your shifts, with any stretch that has no data left out of both terms. IoTFlows reports the same percentage as **Utilization** on the Assets page and the Advanced Report, and as **Uptime** on a machine card. The [uptime glossary entry](/docs/get-started/glossary/#uptime) gives the full definition. Other definitions divide by calendar time or by planned production time and give different numbers for the same machine. The guide to [machine utilization and its four denominators](/blog/what-is-machine-utilization/) works one week through all of them. ## Uptime ranges by machine type The table collects the ranges IoTFlows publishes in its machine setup guides. Each range is for uptime measured inside your shifts, and each row is a loading method, not a machine brand. | Machine | How it is loaded | Uptime to expect | |---|---|---| | CNC machining center | Manual, operator-intensive | 40–60% | | CNC machining center | Operator loads and unloads | 50–70% | | CNC machining center | Fully automatic | 75–85% | | Injection molding machine | Operator loads inserts or removes parts | 60–75% | | Injection molding machine | Fully automatic | 75–85% | | Injection molding machine | Lights-out, unattended | 85–90% | | Stamping press | Hand-fed, operator places each blank | 50–65% | | Stamping press | Coil-fed | 65–80% | | Stamping press | Lights-out automation | 80–90% | Ranges from the IoTFlows setup guides for CNC machines, injection molding machines and stamping presses. Use them for planning, not as goals. Figure: Range bars for nine machine and loading combinations. CNC climbs from 40–60% manual to 75–85% automatic, molding from 60–75% tended to 85–90% lights-out, and presses from 50–65% hand-fed to 80–90% lights-out. *On every machine type, the range climbs as people leave the cycle.* The pattern is the same on all three machine types. Each step that takes a person out of the cycle lifts the bottom of the range by 10 to 25 points. A manual CNC and an automatic one differ by more than a CNC and a press with the same loading method. Each row comes from one setup guide: - **CNC machining centers:** the [CNC setup guide](/docs/production/cnc-machines/#expectations). - **Injection molding machines:** the [injection molding guide](/docs/production/injection-molding/#expectations). - **Stamping presses:** the [stamping press guide](/docs/production/stamping-presses/#expectations). All three guides add the same instruction: start from your own baseline plus 5 to 10%, not from the table. ## Why loading sets the ceiling A machine an operator loads is stopped while the operator works. Loading, unloading, deburring and measuring with the spindle off all count as stopped time, even on a shift with no breakdowns. > **Definition.** **Handling time** is the time inside each part’s cycle when the machine is stopped so a person can load, unload, inspect or adjust, as distinct from the machine time when it cuts, strokes or cycles. Handling time sets a ceiling on uptime before setups, tool changes or failures take their share. **Uptime ceiling** = (Machine time per part) ÷ (Machine time per part + handling time per part) For example, a part that cuts for 9 minutes and takes 3 minutes to unload, deburr and reload caps the machine at 9 ÷ 12 = 75%. Every setup and stop then comes out of that 75%, which is why an operator-loaded CNC lands at 50 to 70% rather than 75%. ### CNC machines The three CNC ranges follow from three ways of running the same kind of machine. Work one 450-minute shift on each, with lunch already removed. #### Worked example: One shift on three CNC machines - **Manual mill in a job shop.** Two setups at 50 minutes each take 100 minutes. In the remaining 350 minutes each part needs 4 minutes of cutting and 3 minutes of loading and measuring, so the mill makes 350 ÷ 7 = 50 parts and runs 50 × 4 = 200 minutes. Uptime is 200 ÷ 450 = 44.4%. - **Operator-loaded production mill.** One 45-minute setup and 45 minutes of other stops (a first-article check, two insert changes) leave 360 minutes. Each part takes 9 minutes of cutting and 3 of loading, so the mill makes 360 ÷ 12 = 30 parts and runs 270 minutes. Uptime is 270 ÷ 450 = 60.0%. - **Bar-fed lathe running automatically.** Nobody loads parts. Six bar reloads at 5 minutes (30), four insert changes at 5 minutes (20) and one 30-minute alarm add up to 80 minutes stopped, so the lathe runs 370 minutes. Uptime is 370 ÷ 450 = 82.2%. **Result:** Same shift, same plant: 44.4%, 60.0% and 82.2% uptime Figure: Three 450-minute bars. The manual mill runs 200 minutes, with 150 minutes of loading and 100 of setup, for 44.4%. The operator-loaded mill runs 270 minutes for 60.0%. The bar-fed lathe runs 370 minutes for 82.2%. *Handling time, not breakdowns, separates the three machines. Sample data.* None of the three machines is performing badly. The manual mill sits inside its 40 to 60% range, the production mill inside 50 to 70% and the lathe inside 75 to 85%. A fleet ranking that puts the manual mill last tells you about its loading method, not its losses. The [guide to monitoring CNC machines](/blog/how-to-monitor-cnc-machines/) reads a mixed fleet the same way. ### Stamping presses On a press, how material reaches the die sets the ceiling. A hand-fed press stops whenever its operator does: to restack blanks, swap a full parts tote or check a part. A coil-fed press keeps stroking until the coil runs out, the strip jams or the die comes out. #### Worked example: One coil-fed shift on a progressive die - Shift: 450 minutes. The press runs a progressive die at 40 strokes a minute, and one coil makes 6,000 parts, so each coil runs 6,000 ÷ 40 = 150 minutes. - Stops: two coil changes at 20 minutes (40), one 45-minute die change for the next job, and 25 minutes of misfeeds and strip jams. That is 110 minutes stopped. - Running: 450 − 110 = 340 minutes, or two full coils and 40 minutes of a third, for 340 × 40 = 13,600 parts. **Result:** Uptime = 340 ÷ 450 = 75.6% That press sits inside its 65 to 80% range. The same press hand-fed, with the same die change and 120 minutes of blank restocking, tote changes, part checks and waiting on the shear, runs 285 minutes for 63.3%. The loading method alone moves it 12.2 points. ### Injection molding machines A [molding machine](/blog/monitor-injection-molding-machines/#cycle-signal) times its own cycle: inject, hold, cool, open, eject. An operator who removes parts or loads inserts adds handling time to every shot, which is why a tended machine runs 60 to 75%. Without a person in the cycle, the losses that remain are mold changes, color and material changes and process faults, and the range rises to 75 to 85%. ## What lights-out uptime depends on *Lights-out* means a machine or cell runs through hours when nobody is on the floor. The ranges for it are 80 to 90% on a press and 85 to 90% on a molding machine. IoTFlows’ CNC guide suggests a goal of 85 to 90% for a CNC with lights-out automation. Two things decide whether a lights-out figure reaches that range. - **The window.** Measure the cell across the unattended hours it is scheduled to run. A window that covers only the staffed shift captures the loading, setup and restarts people do there, and none of the hours where the cell runs best. - **When it stops.** With nobody to reset a fault, a stop lasts until someone arrives. For example, a cell scheduled from 22:00 to 06:00 (480 minutes) that alarms out at 04:40 runs 400 minutes, or 83.3%. The same alarm at midnight leaves it at 120 minutes, or 25.0%. The second point means a lights-out cell’s uptime swings from night to night more than a staffed machine’s. Read it over a month, and work on the faults that stop it early in the night first, because each one costs the rest of that night. > **Is your cell lights-out or automatic?** > > Use the lights-out range only when the cell runs a scheduled block with no one present, such as an overnight shift, and you measure that block. A machine that runs unattended between operator visits during a staffed shift is fully automatic, so hold it to 75 to 85%. ## Why published figures disagree A utilization figure without its definition can’t be compared with anything. Most of the disagreement between published numbers comes from a different numerator, a different denominator or a different kind of machine. **In-cut time is narrower than uptime.** Makino, a machine tool builder, reports a survey of more than 100 US plants in which the average vertical machining center spindle was in cut 34% of the time, against the 70% of in-cycle time Makino says it should reach.[2] Makino attributes the gap to setup, loading and unloading, tool maintenance and chip clearing.[2] In-cut time drops rapid moves and tool changes that uptime counts as running, so a 34% in-cut figure and a 60% uptime can describe the same machine. **Arc-on time is narrower still.** Miller Electric puts the average arc-on time in a semi-automatic welding operation at 10 to 12%, and excludes fit-up, material preparation and post-weld cleaning from it.[3] That figure describes a welder’s time at the station, not a machine’s running state. Never hold it against a CNC’s uptime. **Acceptable run time depends on the work.** Mike Lynch, writing in Modern Machine Shop, notes that high-volume work can justify almost anything to pass 95% spindle run time, while some companies are satisfied below 20%.[1] A machine in a cell, he notes, can sit idle for long periods and still be appropriately utilized.[1] | Figure you read | What it counts as running | Compare it with uptime? | |---|---|---| | Machine uptime | Any time in cycle | Yes, same machine type | | Spindle in-cut time | Tool in the material only | No, it reads lower | | Welding arc-on time | Arc lit only | No, it reads far lower | | Capacity utilization | Output against capacity | No, it measures output | ## Is your machine below, inside or above its range? Measure the machine for at least a few weeks, then place its baseline against the range for its type and loading method. Where it lands tells you what to do next. | Baseline | What it usually means | What to do | |---|---|---| | Below the range | Stops nobody has explained yet | Rank stops by hours lost | | Inside the range | The machine runs as its loading allows | Set the goal 5 to 10% above | | Above the range | Measurement or category is off | Check the setup, then the row | **Below the range.** Put a reason on every stop, then rank the reasons by the hours they cost on the [downtime Pareto chart](/docs/monitoring/downtimes/#pareto). Setup is often the largest single loss on a CNC. A short list of [downtime reason codes](/blog/downtime-reason-codes/) keeps operators classifying stops instead of skipping them. **Inside the range.** The machine runs as well as its loading method allows. Further gains come from cutting handling time or setup time, or from changing how the machine is loaded, not from pushing the operator harder. **Above the range.** Check the measurement before celebrating. A short-stop setting that counts every gap under a few minutes as running moves loading time into uptime. Check [how short stops are handled](/docs/hardware/calibrate-senseai/#short-stops) on that machine, then check the category: a mill with a pallet changer that you filed as operator-loaded belongs in the automatic row. > **Does a non-bottleneck need a high goal?** > > Hold the [constraint](/blog/find-the-bottleneck/), the machine that limits the plant’s output, to the top of its range. A machine with spare capacity can sit inside or below its range and still be scheduled correctly, so give it a goal that tracks its baseline rather than a stretch target. ## Set a goal for each machine type The ranges tell you whether a baseline is plausible. The goal comes from the baseline itself. 1. **Group machines by loading method.** Sort every machine into a row of the table: manual, operator-loaded, automatic or lights-out. Group by how the machine is loaded, not by brand or age. 2. **Measure a full quarter.** Collect uptime for one complete quarter with the same shifts and the same rule for breaks throughout. A few weeks gives a first read, and a quarter covers the job mix. 3. **Set the plant goal from the largest group.** Take the baseline of the group with the most machines and add 5 to 10%. For example, a shop where most mills run at 52% sets 57% to 62%, not 85%. 4. **Override only the groups that differ.** Give a machine its own goal only when its loading method puts it in a different range, such as a lights-out cell in a shop of manual mills. When every machine carries its own goal, a green gauge no longer means the same thing on two machines. 5. **Hold each goal for a quarter.** Leave goals alone for a quarter, then raise them when the machines get there. A goal a machine has never met teaches operators to ignore the number. You don’t need a separate goal for every machine type in the plant. Two or three goals cover most shops: one plant goal, and an override for each group whose range sits well above or below it. The [goal-setting guide](/docs/monitoring/oee-goals/#machine) shows where an override applies. ## Track uptime against each machine’s goal IoTFlows puts a sensor on each machine that reads running or stopped from the machine’s own vibration, with no PLC or controller connection. A manual mill from the 1990s and a new lights-out cell report uptime the same way, so their figures sit side by side on one fleet view. One organization goal colors every gauge green at or above it and red below it, and you override it per machine where the loading method sets a different ceiling. The [Advanced Report](/docs/monitoring/advanced-report/) gives each machine’s baseline over a quarter. Storm Power Components doubled machine utilization with SenseAi on its CNC machines, lasers and presses, as told in the [Storm Power story](/customers/storm-power-components/). For the full product, see [machine utilization tracking](/solutions/machine-utilization/). ## Questions ### Is 85% uptime a realistic goal for every machine in a plant? No. 85% sits at the top of the range for a fully automatic CNC or molding machine and above the range for any machine an operator loads by hand. Give the whole plant one goal set from its most common machine type, then override it only on the machines whose loading method puts them in a different range. ### Why does my lights-out cell read lower than 85%? Check the window first. A cell measured only during the staffed shift shows the hours people spend loading, setting up and restarting it, and leaves out the unattended hours where it runs best. Then check the alarms: one fault early in an unattended night stops the cell until someone arrives, and that single stop can halve the night. ### Is machine uptime the same as spindle utilization? No. Uptime counts every minute the machine is in its cycle. Spindle in-cut utilization counts only the minutes the tool is in the material, so rapid moves, tool changes and probing drop out. The same machining center reads lower on in-cut time than on uptime, so never compare one with the other. ### Does a pallet changer or bar feeder put a CNC in the automatic range? Yes, when the operator loads the next part while the spindle cuts. Loading then leaves the cycle, so the machine belongs in the 75 to 85% row. Keep it in the operator-loaded row when the spindle still waits for a person between pallets or bars, for example when one operator tends three machines. ## Sources 1. [Judging Acceptable Spindle Run Time](https://www.mmsonline.com/columns/judging-acceptable-spindle-run-time), Modern Machine Shop, accessed Oct 16, 2026 2. [Vertical Machining Centers: Increasing Shop Profitability Through Machine Choice and Deployment (2021)](https://www.makino.com/getmedia/dd42e0d3-d9bc-4f08-88e3-b3bb6b5bb400/VMC-Machine-Choice-and-Deployment-(2021).pdf), Makino, accessed Oct 16, 2026 3. [What Is Welding Arc-on Time and Are You Overestimating It?](https://www.millerwelds.com/resources/article-library/what-is-welding-arc-on-time-and-are-you-overestimating-it), Miller Electric, accessed Oct 16, 2026 --- # Counting parts and cycle times on CNC mills and lathes Source: https://www.iotflows.com/blog/cnc-cycle-time-and-part-counts/ Count CNC parts and time each cycle from outside the control: what one cycle is, one operation per job, parts per cycle, and a hand count that proves it. > Question: How do I get accurate part counts and cycle times from a CNC without the control? ## Key takeaways - A vibration sensor on the spindle housing counts one cycle each time the trace falls back to idle, and times it. - Count detected cycles on a CNC instead of dividing run time by an average cycle, because the job mix changes the error. - Cycle time is stated per cycle, and quantity per cycle turns a cycle count into a part count. - Set the ideal cycle time from cycles you timed on the machine, not from a CAM estimate or a padded quote. - Validate every new setup against a hand count; an exact 2x or 0.5x error is a setting, not the sensor. You get accurate part counts and cycle times from a CNC without the control by reading each cycle from outside the machine. A vibration sensor on the spindle housing sees cutting as a burst, counts one cycle each time the trace falls back to idle, and times it. Then you set one operation per thing the machine does, enter how many parts each cycle makes, and prove the count against ten hand-counted parts. This guide is for manufacturing engineers and leads who already see when their mills and lathes run and now need counts they can put in front of a production meeting. For run state and stops across a whole fleet, start with [how to monitor CNC machines](/blog/how-to-monitor-cnc-machines/). ## What counts as one cycle on a CNC? > **Definition.** **Cycle time (CNC)** is the time one machining cycle takes, from the start of the cut to the machine's return to idle, measured on the machine rather than estimated. One cycle can make one part or several, so cycle time is stated per cycle, never per part. The [glossary entry for cycle time](/docs/get-started/glossary/#cycle-time) uses the same per-cycle rule. The Lean Enterprise Institute adds the part that matters most: cycle time is the time required to produce a part or complete a process “as timed by actual measurement”.[1] A number from a quote or a CAM printout is a target, not a cycle time. Three different figures go by the name on a shop floor. Know which one a report shows before you compare it with anything. | Figure | What it includes | Use it for | |---|---|---| | Machine cycle time | One complete cycle, cut to idle | Counting, performance | | Effective machine cycle time | Cycle, load and unload, setup share | Quoting, capacity | | Ideal cycle time | The best sustainable cycle you enter | Shift goals, the parts gauge | Machine cycle time and effective machine cycle time follow the Lean Enterprise Institute's definitions. *Effective machine cycle time* is the machine cycle plus load and unload time, plus the changeover time divided by the pieces made between changeovers.[1] LEI's own example is a 20-second cycle with 30 seconds of loading and a 30-second changeover over 30 pieces, which comes to 51 seconds a piece.[1] **Effective machine cycle time** = Machine cycle + load and unload + (setup time ÷ batch size) #### Worked example: A bracket on a vertical mill - Machine cycle: 4 min 20 s (260 s), timed at the machine. - Load and unload: 1 min (60 s). - Setup: 45 min (2,700 s) for a batch of 30, so 90 s a part. Effective cycle time is 260 + 60 + 90 = 410 s. At a batch of 120, the setup share falls to 22.5 s and the effective cycle to 342.5 s. **Result:** Effective machine cycle time = 410 s, or 6 min 50 s, at a batch of 30 The machine cycle is what a sensor measures. The other two are calculated from it, which is why it has to be right first. ## How a sensor reads a cycle from outside A CNC that is cutting vibrates well above its idle level. A sensor mounted on the spindle housing or the main motor casting reads that vibration, and a *running threshold* splits it in two: above the line the machine is running, below it the machine is idle. Each time the trace crosses back below the threshold and stays there, one cycle ends. The time from crossing up to crossing down is the cycle time. Figure: A vibration trace on a vertical mill rises above a dashed threshold for one 4 min 20 s cycle, dips briefly for a tool change that is merged into the cycle, then falls to idle for a 1 min load before the next cycle. *One cycle read from outside: the tool-change dip stays inside the cycle, and the part load ends it. Sample data.* Two things in a cut drop the trace for a moment without ending the part: a tool change and a probe move. A counting rule that merges short dips back into the cycle they interrupted keeps those as one part. A rule that counts every burst on its own splits the part in two, which is right on a press and wrong on a mill. The [counting algorithm guide](/docs/production/choose-an-algorithm/#discrete) draws both rules on the same trace. Where you mount decides how clean the trace is. A sheet-metal guard door rings on its own and hides the cut. Mount on flat ferrous metal tied to the spindle or the driveline, then run the machine cutting and idle and confirm the two read differently. ## Count cycles instead of dividing run time There are two ways to turn running time into a part count. You can divide running time by a cycle time you entered. Or you can count the cycles the sensor detects. Division works on a machine that runs one steady cycle all day. A CNC changes its cycle with every part, so division is right only on the days the job mix happens to match the average you typed. #### Worked example: One machining center, two days, one entered average - The machine runs two parts: a bracket at 3 min and a housing at 6 min. The operation is set to an average of 4 min. - Monday: 60 brackets (180 min) and 20 housings (120 min), 300 running minutes, 80 parts. - Tuesday: 20 brackets (60 min) and 40 housings (240 min), 300 running minutes, 60 parts. Division gives 300 ÷ 4 = 75 parts on both days. Monday reads 75 ÷ 80 = 93.75% of the truth, Tuesday 75 ÷ 60 = 125%. **Result:** Division error: 6.3% low on Monday, 25% high on Tuesday Figure: Two days of 300 running minutes on one machine. Monday made 80 parts and division by a 4 min average reports 75, 6.3% low. Tuesday made 60 parts and division reports 75, 25% high. *Same running time, same entered average, a different error each day. Counting cycles gets both days right. Sample data.* Counting detected cycles gives 80 and 60, because it never assumes the cycles are equal. On a CNC, default to counting cycles. > **Count cycles or divide run time?** > > Count detected cycles when cycle times vary with the part and the machine falls back to idle between parts, which describes most mills, lathes and machining centers. Divide running time by a measured cycle only when the trace never returns to idle between parts, such as a bar-fed lathe running one job unattended. ## Set up one operation per thing the machine does An *operation* is one thing a machine does to a part, with its own cycle time. Every count, goal and cycle-time figure belongs to an operation, so how you split them decides what your reports can tell apart. Create one operation per thing the machine does differently, not one per line on the router. Split two steps only when the cycle time, the counting rule or the machine differs. The [parts and operations model](/docs/production/parts-and-operations/#model) sets out the same rule. | Situation on the machine | Operations to create | |---|---| | A lathe turns side one, then side two | Two: OP10 and OP20 | | Two router steps, same rate, same machine | One | | One part, run on two different mills | One, assigned to both | | A high-mix shop, every job new | One general operation per machine | With cycle counting, a general operation counts correctly. Its goal runs against an average cycle, so treat goals on it as approximate. For example, a lathe that faces and turns side one in 2 min 40 s, then side two in 1 min 50 s after a flip, needs two operations. One operation at an average of 2 min 15 s would put every gauge on the wrong target. You don't need a separate operation for every program revision. A new revision that runs at the same cycle on the same machine is the same operation. ## Set parts per cycle for fixtures and pallets A cycle count and a part count are different numbers. The MTConnect standard keeps them as separate data items: a cycle count is the “accumulation of the number of times a cyclic function has attempted to, or is planned to attempt to execute”, and a part count is an “aggregate count of parts”.[3][2] > **Definition.** **Quantity per cycle** is the number of finished parts one machine cycle produces, such as four for a four-station vise fixture or one for a lathe parting off a single part. A part count is the detected cycle count multiplied by the quantity per cycle. Keep the cycle time per cycle and put the multiple in [quantity per cycle](/docs/get-started/glossary/#quantity-per-cycle). Dividing the cycle time by the number of stations gets nothing right when the system counts cycles: the count still reads one part per cycle, and the parts gauge falls to a quarter. #### Worked example: A four-station vise fixture on a vertical mill - One cycle machines four parts in 12 min. - The machine runs 360 minutes in the shift, so it completes 360 ÷ 12 = 30 cycles. Set up correctly, with a 12 min cycle and a quantity of 4, the count is 30 × 4 = 120 parts. Left at a quantity of 1, it reads 30 parts, exactly 25% of the truth. **Result:** Part count = 30 cycles × 4 parts per cycle = 120 parts Leave quantity per cycle at 1 unless one cycle yields more than one part, from a multi-station fixture, a pallet or a bar. It is the only setting that scales every count, so it is the first one to check when a count comes out at a clean multiple of the truth. The [quantity per cycle settings](/docs/production/cycle-times-and-filters/#qty) show where it lives. ## Measure the ideal cycle time The ideal cycle time does not change the count when the system counts cycles. It sets the target everything else is measured against: the shift goal, the hourly goal and *performance*, the share of the running time the parts made would have needed at the ideal cycle. [Setting the ideal cycle time](/blog/ideal-cycle-time/) covers who owns the number and what a wrong one does to OEE. **Performance** = (Parts made × ideal cycle time) ÷ (Running time) 1. **Pick a part you run often.** Choose a part with a settled program, not a first article. 2. **Time 10 to 20 consecutive cycles.** Time each cycle on a good day, from part load to part unload. For example, ten cycles of 4:15, 4:30, 4:10, 4:25, 4:20, 4:20, 4:15, 4:25, 4:20 and 4:20. 3. **Average them and note the range.** The ten cycles above average 4 min 20 s, with a 20-second range. Enter the average as the ideal. 4. **Watch the measured cycle for a week.** Compare the measured cycle time with the ideal before you change either one. The source of the ideal moves performance more than the machine does. Take one shift where a mill made 60 brackets in 270 running minutes, an actual average of 4 min 30 s. | Source of the ideal | Ideal cycle | Performance | |---|---|---| | CAM estimate | 3 min 30 s | 210 ÷ 270 = 77.8% | | Timed at the machine | 4 min 20 s | 260 ÷ 270 = 96.3% | | Padded quote | 5 min | 300 ÷ 270 = 111.1% | Hypothetical shift. Performance is parts made × ideal cycle ÷ running time. A CAM estimate comes from the toolpath. The machine adds acceleration, tool changes and probing on top, so the CAM ideal makes a good shift look slow. A padded quote does the reverse, and a performance figure above 100% means the ideal is set too slow, not that the machine outran itself. [How to calculate OEE](/blog/how-to-calculate-oee/) works performance through with availability and quality. A measured cycle that creeps up over days is often the machine telling the truth. Tool wear lengthens a cycle. Watch it for a week before you move the ideal to meet it, and use the corrected figure in your quotes and in [a schedule built on real run rates](/blog/production-scheduling-on-real-run-rates/). ## Validate against a hand count A count that looks about right is not validated. Compare it with parts counted by hand over the same window, and read the ratio, not the difference. **Count accuracy** = (System count) ÷ (Hand count) 5. **Run the machine normally for two to four hours.** Use a part the operation is set up for, with no special handling. 6. **Hand count the same window.** Count at least ten finished parts. Twenty parts made should read 20, give or take one or two. 7. **Divide and read the band.** At 95 to 105%, leave it alone. Between 90 and 95%, or 105 and 110%, tune the running threshold or the sensor mount. Outside 90 to 110%, something is set wrong. 8. **Change parts and check again.** Run a part with a different cycle time and repeat the count. A setup that only works on one part is not finished. Figure: A scale of system count over hand count from 40% to 210%. The 95 to 105% band is working and 90 to 110% needs tuning. Exactly 50% or 200% points to parts per cycle; uneven low readings mean missed cycles, uneven high mean tool changes read as cycles. *Read the ratio, not the difference: a clean multiple is a setting, an uneven miss is detection.* The shape of the error tells you where to look: - **Exactly 2.00 or 0.50.** Quantity per cycle is wrong. No threshold change fixes a multiplier. - **High by an uneven amount.** Tool changes or probe touches are reading as cycles. Raise the running threshold, or recalibrate against full cycles. - **Low by an uneven amount.** Short, light cycles are not separating from idle, or two fast cycles merge. Move the sensor closer to the spindle, or lower the threshold. The [part count troubleshooting guide](/docs/production/troubleshoot-part-counts/) works through each symptom. You don't need to chase a count already inside 95 to 105%. Moving a setting to win back one part replaces a right number with a wrong one. ## Count CNC parts with IoTFlows IoTFlows puts a SenseAi on each mill or lathe. It attaches magnetically near the spindle and reads vibration and sound from outside the machine, with no PLC or controller access. Discrete Analysis counts each detected cycle and merges short pauses back into the cycle they interrupted, so every part the machine runs reports its own count and cycle time. The [CNC setup guide](/docs/production/cnc-machines/) covers mounting, one operation per thing the machine does and the hand-count check. Shift Production then shows each count against a goal calculated from the ideal cycle time. See [CNC machine monitoring](/solutions/cnc-machine-monitoring/) for the full picture. > I use the dashboard every day to compare and validate actual cycle times against the times listed in our bills of material. This has helped improve accuracy, highlight deviations early, and support more informed decision-making across our manufacturing processes. > > Pete Gonella, Director of Manufacturing, Jesel ([story](https://www.iotflows.com/customers/jesel/)) ## When the control's counter is the better source The control knows things a sensor cannot feel: which program ran, which part number it was cutting and how many times the program reached its end. On a high-mix machine, the program name splits counts by job with nobody touching a screen. A connection to the control is also a security concern for many plants, and IT usually reviews it first. [Some older controls have no network port at all](/blog/monitor-old-machines-without-a-plc/). The [sensor versus PLC comparison](/compare/sensor-based-vs-plc-machine-monitoring/) lays out what each approach sees, with its sources. | | Sensor on the machine | Control counter | Operator tally | |---|---|---|---| | Works on any brand or age | Yes | No | Yes | | Times every cycle | Yes | Yes | No | | Names the program per count | No | Yes | No | | Needs an IT review | No | Yes | No | Neither the sensor nor the control knows which parts were scrap. The good count is the total less the scrap your team logs with a reason. Default to a sensor on every machine for counts and cycle times, because it reads every control the same way. Add the control's counter on the machines where a recurring question needs the program name, such as a high-mix cell where operators forget to switch jobs. Keep the operator tally for the hand-count check, not as the record. ## Questions ### Can a vibration sensor count parts on a lathe with a bar feeder? It depends on whether the vibration trace falls back to idle between parts. If it does, count the detected cycles. A bar-fed lathe running one job unattended may never return to idle, and then dividing running time by a carefully measured cycle time fits better. Watch the trace over a few cycles before you choose. ### Should the ideal cycle time come from the CAM estimate? No. A CAM estimate is calculated from the toolpath and leaves out time the machine adds, such as acceleration, tool changes and probing. Time 10 to 20 consecutive cycles on the machine on a good day, from part load to part unload, and enter that figure instead. ### Does a tool change split one part into two counts? Not with a counting rule that merges short dips back into the cycle they interrupted. A rule that counts every burst on its own can split one part into two. If the count runs high by an uneven amount, check whether tool changes or probe moves are dropping the trace below the running threshold. ### How many parts should I hand count to validate a CNC count? Count at least ten parts against the same window the system reports, and repeat the check after changing to a part with a different cycle time. A count that matches part for part over ten parts is right; a shift total that lands near the truth can hide two errors that cancel. ## Sources 1. [Cycle Time, Lean Lexicon](https://www.lean.org/lexicon-terms/cycle-time/), Lean Enterprise Institute, accessed Oct 16, 2026 2. [PartCount, MTConnect SysML Model V2.5](https://model.mtconnect.org/Version2.5/ObservationInformationModel/ObservationTypes/EventTypes/PartCount/), MTConnect Institute, accessed Oct 16, 2026 3. [CycleCount, MTConnect SysML Model V2.5](https://model.mtconnect.org/Version2.5/ObservationInformationModel/ObservationTypes/EventTypes/CycleCount/), MTConnect Institute, accessed Oct 16, 2026 --- # When to replace a spreadsheet production schedule Source: https://www.iotflows.com/blog/replace-spreadsheet-schedule/ An Excel schedule fails once one change has effects nobody sees. Learn the five signs, what each replacement checks, and how to move your open jobs across. > Question: When does an Excel schedule stop working, and what replaces it? ## Key takeaways - A spreadsheet schedule stops working when one change has effects the planner can’t see, such as a shared fixture running short. - Replace it when a tool or fixture limits the plan, several people edit it, or floor progress is retyped after the fact. - In an audit of 50 operational spreadsheets, 43 held at least one error that produced a wrong result. - ERP planning works from fixed lead times, so a finite-capacity scheduler is what checks machines and tools on every move. - Move off the spreadsheet in order: list what each column means, build routings, model shared tools, load jobs, then archive the sheet. An Excel schedule stops working when one change has effects the planner can’t see: a shared fixture runs short, a successor starts before its predecessor ends, or two people edit different copies. Replace it with a finite-capacity scheduler, which checks every machine, tool and dependency each time a job moves. Keep the spreadsheet while one planner owns it and the machine is the only thing that limits what runs next. This guide is for plant managers and planners who rebuild the week in a spreadsheet every Monday. It works one schedule change through by hand, compares what can replace the sheet, and lays out the move. ## What a spreadsheet schedule does well A spreadsheet earns its place as a first scheduler. It costs nothing extra, everyone can read it, and the planner can add a column the day a new constraint appears. > **Definition.** **Spreadsheet schedule** is a production plan kept in Excel or Google Sheets, one row per job or operation, with machines and dates typed or calculated cell by cell and no built-in check that two rows claim the same machine or tool. The last clause is the one that matters. A row knows its own dates, and nothing else. A *job* is an order for a quantity of a part, and a *task* is one operation of that job on one machine; the [glossary entry for jobs and tasks](/docs/get-started/glossary/#job-and-task) uses the same split. A spreadsheet holds tasks as rows but has no idea which rows depend on each other. You don’t need to replace the sheet if all of these hold: - One planner owns it and makes every change. - The machine is the only constraint: no shared fixtures, molds, tool sets or certified operators. - The mix repeats week to week, and a moved job rarely moves another. - Progress arrives at a daily meeting, and that is fast enough. For example, a 6-machine job shop with one planner, repeat orders and a dedicated fixture on each machine can run on a spreadsheet for years. ## Five signs the spreadsheet has stopped working Each sign below is a check the planner does in their head because the sheet can’t. One sign is a nuisance. Two or more mean the plan depends on what one person remembers. ### A shared resource decides what runs next The machine is free, but the fixture, mold, die or tool set it needs is on another machine. A spreadsheet has no column that counts how many are free at 14:00 on Wednesday, so the planner tracks it from memory or a second tab. ### One moved job breaks rows you can’t see A customer pulls an order forward, and the planner changes its row. Every row typed from the old date (its next operation, the job queued behind it on the same machine) is now wrong, and nothing turns red. ### More than one person edits the plan The night supervisor swaps two jobs, sales promises a date, and the planner works from Monday’s copy. Files named `Schedule_wk42_v7_FINAL` are the symptom. ### The floor reports after the fact Operators [write counts on a sheet](/blog/manufacturing-data-collection/#manual), and someone types them in the next morning. By then the plan and the plant have drifted for a whole shift, so every date downstream is a guess. ### Planning takes hours every week The planner rebuilds the week each Monday instead of adjusting it. When the person who understands the sheet is on vacation, the schedule stops changing. Formula errors make every sign worse. Powell, Baker and Lawson audited 50 operational spreadsheets and found errors in 47 of them; 43, or 86%, held at least one error that produced a wrong result.[1] The most common type was *hard-coding*, a number typed into a formula instead of referenced, at 37.7% of error instances.[1] Most hard-coded numbers gave no wrong result on the day of the audit; the authors class them as a risky practice that can lead to errors in later use.[1] In a schedule, an end date written as `=B4+30`, with the 30 hours typed into the formula, is hard-coding. Double the job’s quantity and the end date still sits 30 hours after the start. The study covered business spreadsheets in general, not schedules, and a sheet built from typed dates and durations is exposed to the same errors. ## Work one schedule change through by hand A pulled-in order shows how a spreadsheet fails. The shop below has three mills and one fixture that two of them share. #### Worked example: Pulling job 1052 into Wednesday on Mill 3 - Three Haas VF-2 mills. The shop owns 4 sets of soft jaws for part BR-210, and each BR-210 job holds 2 sets while it runs. - Job 1041 runs on Mill 1 from Mon 06:00 to Wed 14:00 and holds 2 sets. Job 1047 runs on Mill 2 from Tue 06:00 to Thu 22:00 and holds 2 sets. - A customer asks for job 1052, BR-210, 30 hours on Mill 3, to start Wed 06:00. Mill 3 is free, so the sheet accepts it. - From Wed 06:00 to Wed 14:00, three jobs need 2 + 2 + 2 = 6 sets. The shop owns 4, so it is 2 sets short for 8 hours. - The earliest start with sets free is Wed 14:00, when job 1041 returns its 2. Job 1052 now ends Thu 20:00 instead of Thu 12:00. - Two rows were typed from the old end time: 1052 OP20 on Lathe 1 at Thu 12:00, and job 1060 on Mill 3 at Thu 12:00. **Result:** One move costs 8 hours and leaves two rows 8 hours wrong: OP20 starts before OP10 ends, and Mill 3 is double-booked Figure: A four-day plan for three mills. Jobs 1041 and 1047 each hold 2 of 4 jaw sets. Pulling job 1052 into Wednesday 06:00 drops free sets to minus 2 until 1041 ends at 14:00, the earliest start with sets free. *Mill 3 is free on Wednesday morning, but the jaw sets it needs are not. Sample data.* The planner can catch the shortage, but only by checking every BR-210 row by eye. Then the fix itself breaks two rows nobody touched. A spreadsheet stores each row’s dates on their own, while a scheduler stores the links between rows, so it re-checks them when one row moves. Figure: Left, a spreadsheet where moving 1052 OP10 to Wed 14:00 changes one cell while OP20 and job 1060 keep Thu 12:00. Right, a schedule where the same task links to its successor, the next job on Mill 3 and the two jobs sharing jaw sets. *A spreadsheet changes only the cell you edit, while a schedule re-checks every task linked to it. Sample data.* ## What replaces a spreadsheet schedule? Two tools replace a spreadsheet schedule: the ERP’s planning run and a finite-capacity scheduler, which can also read live data from the machines. They answer different questions, and a plant can run both side by side. > **Definition.** **Finite-capacity scheduling** places each task only in a time slot where its machine and every other limited resource it needs, such as a fixture, mold or tool set, are free, so the plan never claims more capacity than the plant owns. The ERP plans at a different level. ISA-95 places ERP at Level 4, “all the activities related to running a business”, and manufacturing execution systems at Level 3.[3] The ERP’s planning run is material requirements planning (MRP), and standard MRP “lacks capacity constraints by decoupling fixed planned lead times from time-dependent department workloads”, which can produce plans the floor can’t run.[2] The [comparison of machine monitoring, MES and CMMS](/compare/machine-monitoring-vs-mes-vs-cmms/) maps the same levels onto plant software. | | Spreadsheet | ERP MRP run | Finite-capacity scheduler | |---|---|---|---| | Flags two tasks on one machine | No | No, plans by lead time | Yes | | Counts shared tools and fixtures | No | No | Yes | | Keeps successors in order | Only with formulas | Yes, by lead time | Yes, by each task’s end | | One plan for every editor | Only when co-edited | Yes | Yes | | Shows floor progress | When someone types it | When transactions post | Live, when fed machine data | | Best for | One planner, repeat mix | Orders, material, due dates | Shared tools, daily replans | A scheduler fed with run times and counts from the machines also shows where its planned durations differ from what the floor ran. > **ERP, scheduler or both?** > > Keep the ERP as the source of orders, material and due dates in every case. Add a finite-capacity scheduler when a shared resource limits the plan or the week is replanned more than once a day. You don’t need a separate scheduler if the ERP’s dates hold and nobody keeps a spreadsheet beside it. The ERP also needs data back from the floor: the hours and counts each job took. [Connecting machine data to your ERP](/blog/connect-machine-data-to-erp/) covers that direction. A scheduler is only as good as its durations. If your planned times come from ideal cycle times, the plan will still run late; [plan on measured run rates](/blog/production-scheduling-on-real-run-rates/) to size each job from what the machine has done. ## Make the spreadsheet safer while you decide If you keep the sheet for now, remove the error type the audit found most often, numbers typed into formulas, along with its schedule form: dates typed where a formula belongs. - **Calculate every end date.** End = start + the duration cell, as a formula. Never type an end date or a number into the formula. - **Chain successors.** The next operation’s start is a formula on the previous operation’s end, not a typed date. - **Give shared tools a row each.** Add a tab that counts each fixture in use per shift, and highlight any count above what the shop owns. - **One owner, one file.** Store it in one place, let one person edit, and give everyone else view access. - **Freeze the next 48 hours.** Changes inside the frozen window need the planner’s sign-off. These rules close the knock-on gap in the example: with OP20’s start chained to OP10’s end, moving 1052 moves OP20 too. They don’t close the double booking on Mill 3, and the sheet still can’t see the floor. ## Move your open jobs off the spreadsheet The move is mostly data. A scheduler needs routings, shared resources and open jobs, and most of that already sits in the sheet or in the planner’s head. 1. **List what every column means.** Write down each column and the unwritten rules beside it: which parts share a fixture, which machine never runs part BR-210, which jobs a customer has been promised. The rules in the planner’s head are the constraints a scheduler has to model. 2. **Build a routing for each part.** Give every part its operations in order, each with a machine and a cycle time. For example, BR-210 is OP10 on a VF-2 mill at 4.5 minutes, then OP20 on Lathe 1 at 2.0 minutes. The guide to [parts and operations](/docs/production/parts-and-operations/) shows the fields a routing carries. 3. **Model each shared resource as a count.** Enter each fixture, mold or tool set with how many the shop owns: 4 sets of BR-210 soft jaws. Attach it to the operations that need it, with the quantity each one holds. 4. **Load the open jobs.** Export the sheet as CSV with one row per task and import it. When there are only a few dozen open jobs, [create each job](/docs/production/create-a-job/) by hand instead. Map columns as in the table below. 5. **Retire the sheet.** Keep the spreadsheet read-only for one or two weeks to compare dates, then archive it. From then on, every change goes through the schedule. | Spreadsheet column | Scheduler field | Note | |---|---|---| | Order # | Job number | Required: rows sharing it form one job | | Op description | Task name | Required: each row becomes one task | | Part # | Part | Matched by part number, then name | | Op | Operation | From the part’s routing | | Machine | Machine | One machine per task | | Qty | Quantity | Good parts to make | | Hours | Time estimate | Cycle time × quantity, or measured | | Ship date | Due date | The date promised to the customer | | Notes: “needs jaws” | Tool on the operation | Set once in the routing, not per row | Column names vary by plant. Map the order number and task name first: every row needs both, and every other field hangs off them. > **Don’t import a typo as a new part** > > An importer that meets a part number it doesn’t know may create a new part. BR-210 and BR210 then become two parts with two routings. Clean the part numbers in the sheet before the first import. ## Plan jobs in one live schedule The [Production Scheduler](/platform/production-scheduler/) holds every open job in one schedule, in list, table, Gantt, Kanban and calendar views. Fixtures and tool sets are reusable items a task reserves. The [capacity lane](/docs/production/scheduler/#capacity) under the Gantt draws how many are free at every moment, in rose when a move would leave them short. [Schedule issues](/docs/production/schedule-issues/) lists double-booked machines and tooling with no units free, and the optimizer proposes a plan that writes nothing until you apply it. The six-step [schedule importer](/docs/production/import-erp-schedule/) reads a CSV or Excel export, a hand-built spreadsheet included. [Hugo Benzing](/customers/hugo-benzing/) built its jobs directly in the scheduler with no ERP import and retired a stack of complex Excel sheets. It went from kickoff to planning live in under two weeks, and its planners save more than 10 hours a week. ## Checklist: is it time to switch? Score your schedule against each sign. Replace the spreadsheet when two or more are true. | Sign | True when | What to do | |---|---|---| | Shared resource | A fixture or mold limits the plan | Model it as a count in a scheduler | | Knock-on moves | A moved job shifts others weekly | Link successors and machine queues | | Several editors | More than one person changes dates | One schedule, one owner | | Late progress | Counts arrive the next morning | Feed the schedule from the floor | | Planning hours | The week is rebuilt every Monday | Adjust a live plan instead | One true sign: apply the safer-spreadsheet rules first. Two or more: start the routings this week. If you switch, start with the routings for the parts that run on your [most contested machine](/blog/find-the-bottleneck/). Most knock-on moves start there, so that is where a scheduler shows its first conflict. ## Questions ### Does a shared Google Sheet or a co-authored Excel file fix the problem? It fixes one of the five. Co-editing gives everyone the same copy, so versions stop forking. It adds no checks: two people can still book the same machine, a moved row still leaves its successors behind, and a fixture is still a note in a cell. Use co-editing as a stopgap while you build the routings a scheduler needs. ### Can the ERP replace the spreadsheet schedule? For orders, material and promise dates, yes. Standard MRP plans each operation with a fixed planned lead time and doesn't check how loaded each machine is at that hour, so it can produce dates the floor can't hit. Keep the ERP as the source of orders and due dates, and sequence the machines in a finite-capacity scheduler fed from it. ### How long does it take to move a schedule off a spreadsheet? Most of the time goes into routings, because every part needs its operations, machines and cycle times before a scheduler can size a job. Once routings exist, open jobs load from a CSV export of the sheet. Hugo Benzing went from kickoff to planning live in the IoTFlows Production Scheduler in under two weeks. ### Should the planner keep the old spreadsheet as a backup? Keep it read-only for one or two weeks so you can compare dates, then archive it. Two live plans are worse than one, because the floor follows whichever copy it saw last. Name one owner for the new schedule and send every change through that person or that tool. ## Sources 1. [Errors in Operational Spreadsheets, Journal of Organizational and End User Computing 21(3), 24–36 (2009)](https://mba.tuck.dartmouth.edu/spreadsheet/product_pubs_files/Errors.pdf), IGI Global (Powell, Baker and Lawson, Tuck School of Business at Dartmouth), accessed Oct 16, 2026 2. [Enhancing Rolling Horizon Production Planning Through Stochastic Optimization Evaluated by Means of Simulation](https://arxiv.org/html/2402.14506), arXiv (Schlenkrich, Seiringer, Altendorfer and Parragh), accessed Oct 16, 2026 3. [ISA-95 Standard: Enterprise-Control System Integration](https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard), International Society of Automation, accessed Oct 16, 2026 --- # Connecting machine data to your ERP Source: https://www.iotflows.com/blog/connect-machine-data-to-erp/ Get machine hours and part counts into Epicor, SAP or JobBOSS: what the ERP needs per job, how to match runs to jobs, and which integration path fits. > Question: How do I get machine hours and part counts into Epicor, SAP or JobBOSS? ## Key takeaways - The ERP needs setup hours, run hours, good quantity and scrap for each job operation, not raw machine signals. - Machine data becomes job data only after each run is matched to a job, an operation and a machine. - Use a file import for weekly costing, an API for a developer-built feed, and a two-way connector to cost every job. - Post the hours a machine was committed to a job, and use running and stopped time to explain the variance. - Reconcile gross cycle counts with declared good parts plus scrap before the integration posts anything. You get machine hours and part counts into Epicor, SAP or JobBOSS by turning machine signals into job actuals first: match each run to a job, an operation and a machine, then post setup hours, run hours, good parts and scrap against that operation. Move them with a file import, an API feed your team builds, or a two-way connector, depending on how many machines you cost and how often. This guide is for plant managers and engineers whose ERP job costs still come from hand-keyed time tickets. ## What the ERP needs from the machines An ERP does not store machine signals. It stores jobs, the operations on each job's routing, and the *actuals* posted against each operation once it runs. > **Definition.** **Machine-to-ERP integration** is the link that moves what machines did on the floor, such as run hours, stop hours, cycle counts and scrap, into the ERP record of each job operation, and moves the job list from the ERP back to the floor. A *job* is an order for a quantity of a part, and a *task* or operation is one step of that job on one machine. The [glossary entry for job and task](/docs/get-started/glossary/#job-and-task) uses the same split. Each ERP names the transaction differently, but the fields line up. SAP's production order confirmation records yield, scrap and rework quantities, the actual start and finish of the operation, and its setup, machine and labor time.[2] JobBOSS²'s data collection app has an employee scan to start or stop a job and the routing step, track setup time, and enter good and scrapped pieces.[3] | ERP actual | Machine-side source | Note | |---|---|---| | Setup hours | Job start to first good part | Test pieces count as setup | | Run or machine hours | Elapsed job time after setup | Includes stops inside the job | | Labor hours | Operator sessions on the job | Never from machine time | | Good quantity | Cycles × parts per cycle, less scrap | Gross count minus logged scrap | | Scrap quantity | Scrap logged with a reason | Entered by the operator | | Operation status | Job completed at the machine | Closes the operation | Field names differ by ERP. Map each row to your ERP's own labor or confirmation fields before you build anything. ISA-95, the standard for enterprise-control integration, places ERP at Level 4 and manufacturing operations at Level 3, and deals mainly with the interface between the two.[1] That interface is what you are building: a schedule flows down, and a record of what was produced flows back up. The [machine monitoring vs MES vs CMMS comparison](/compare/machine-monitoring-vs-mes-vs-cmms/) shows where each system sits. Figure: ERP at the top, machines at the bottom, and a highlighted step between them that matches machine time to jobs. Jobs and quantities flow down; cycle counts, then hours, good parts and scrap, flow up to the ERP. *Jobs flow down, actuals flow up, and the match in the middle turns machine time into job time.* ## Match machine time to jobs A sensor knows the machine and the time. The ERP knows the job and the operation. Nothing reaches the ERP until something joins the two. There are three ways to make that join: - **The operator starts the job at the machine.** Every minute between start and complete belongs to that job. This is the most reliable join, because the person at the machine knows what is running. IoTFlows calls one run from start to pause or complete a [work session](/docs/production/run-a-job/#start). - **The schedule says which job runs where.** Machine time inside the window the schedule gave job 24-1187 on mill VF2-03 goes to that job. This breaks the moment the floor runs jobs out of order. - **The controller reports the program or part number.** A CNC control can name the program it is running, so the join needs no operator. It needs a connection to the control, which is a security concern for many plants, so IT usually reviews it first. The [guide to machine communication protocols](/blog/machine-communication-protocols/) covers MTConnect and OPC UA. Choose the operator start when jobs change during a shift or more than one job queues on a machine. Use the schedule window when each machine runs one long job a day. Add the controller join when your CNC fleet already exposes MTConnect and IT has approved the connection. Whichever join you use, both systems must spell the same things the same way. Build one cross-reference before the first sync, with the ERP as the master: | ERP field | Machine-side field | Example | |---|---|---| | Job or production order | Job | 24-1187 | | Operation sequence | Operation | OP20 | | Work center or resource | Machine | VF2-03 | | Part number | Part | BRK-2210 | > **One hyphen makes a second part** > > A part your ERP writes as `Y841070` and the machine system holds as `Y-841070` does not match. The sync creates a second part, and every hour and count posted against it lands on the wrong record. Clean the part list on both sides before you connect them. ## Three ways to connect Once runs carry a job, the actuals have to travel. Three paths cover the options, and they differ in who builds them and how fresh the ERP stays. | | File import | API or webhooks | Two-way connector | |---|---|---|---| | Who builds it | A planner, with no code | Your developer or integrator | The integration vendor | | Direction | One way per file | One way per feed | Jobs down, actuals up | | ERP is current | After each import | After each event | After each event or sync | | Where IDs match | In the saved mapping | In your code | In the connector | | Upkeep on ERP upgrade | Check the column mapping | Your developer | The connector owner | | Fits | Weekly or monthly costing | A developer on staff | Every job costed live | A file import is two files in practice: the ERP's job export into the floor system, and an actuals export back into the ERP's own import tool. Choose a **file import** when you cost jobs weekly or monthly and a planner can run the export and import by hand. Choose an **API or webhook feed** when you have a developer who already writes to the ERP's interface. Event payloads from the monitoring system, such as [webhooks to your own endpoint](/docs/alerts/webhooks/), arrive as they happen. Choose a **two-way connector** when every job needs its hours posted without anyone exporting a file, or when the ERP's job list should appear at the machine on its own. You do not need a two-way connector to start. A weekly file import on one machine group shows whether your IDs and conventions hold, and everything you learn carries over to the connector. ## Work one job through by hand The numbers below show what the integration posts, and why the convention you pick changes the job cost. #### Worked example: Job 24-1187, OP20 on a Haas VF-2 - Routing standard: 1.0 h setup and 2.4 min a part. For 250 parts, run time is 250 × 2.4 = 600 min = 10.0 h, so the standard is 11.0 h. - The operator starts the job at 06:00. The first good part comes off at 07:30, so setup took 1.5 h. - The run phase lasts 12.5 h on the machine. The sensor records 10.5 h running and 2.0 h stopped inside it. - The machine counts 258 cycles at one part per cycle. The operator logs 8 scrap, so the good quantity is 258 − 8 = 250. Actual machine time is 1.5 + 12.5 = 14.0 h, against 11.0 h standard. The 3.0 h gap breaks down as 0.5 h of extra setup, 2.0 h of stops, and 0.5 h of extra running time: 10.5 h is 630 min against the 600 min the standard allows for 250 good parts. Of those 30 min, 8 scrapped parts × 2.4 min = 19.2 min, and slow cycles take the other 10.8 min. **Result:** Post setup 1.5 h, machine 12.5 h, good 250, scrap 8: 3.0 h (27.3%) over standard At a [machine rate](/blog/cost-of-idle-machines/#idle-hour) of $85 an hour, the standard costs 11.0 × $85 = $935 and the actual costs 14.0 × $85 = $1,190, so the job ran $255 over. Figure: Two bars. The routing standard is 11.0 h: 1.0 h setup and 10.0 h run. The measured job is 14.0 h: 1.5 h setup, 10.5 h running and 2.0 h stopped. A bracket marks the 3.0 h over standard. *The same job against its routing standard: stops inside the job explain two of the three extra hours. Sample data.* > **Elapsed hours or running hours?** > > Post elapsed hours, the time the machine was committed to the job, as the ERP's machine time. Posting only the 10.5 running hours would show the job 0.5 h over on run and hide the 2.0 h of stops it really consumed. Keep running and stopped time in the monitoring system to explain each variance. For the cost side of the same numbers, the [Production Insights cost model](/docs/production/production-insights/#cost-model) prices labor hours and machine hours at two hourly rates and compares them with the job budget. ## Which way data flows, and how often Give every field one owner. When two systems can both edit the same field, the last write wins and nobody knows which number is right. - **Down from the ERP:** job number, part, operation, quantity and due date. The ERP owns them. - **Up from the floor:** setup hours, machine hours, good quantity, scrap and completion. The monitoring system owns the clock and the count. - **Labor hours:** from the operator's sessions, posted with the operation. The person owns them. Post once per completed operation, or once per shift for long jobs. An ERP records transactions, and a posting per cycle floods it with rows nobody reads. You probably do not need event-by-event posting if you cost jobs at month end. Post on every event when the ERP's schedule or customer promise dates depend on completions. A job that closes at 14:10 should free the next operation in the ERP before the next shift plans its work. Planning from those real completions is covered in [production scheduling on real run rates](/blog/production-scheduling-on-real-run-rates/). ## Reconcile counts before you post them The first comparison between a machine count and an ERP quantity almost never matches. That gap is not a fault until you confirm that both systems count the same thing. | Difference | Why it happens | |---|---| | Gross vs good | Cycles counted, good parts declared | | Scrap not deducted | Logged scrap sits beside the count | | Event vs declaration | A part at 23:58 is declared the next day | | Setup and test pieces | Counted by the machine, not by the ERP | | Different day boundaries | Plant calendar vs shift schedule | Compare gross against gross, for one shift, on one machine, on one operation. If the machine count equals the ERP's declared quantity plus its scrap and setup pieces, both are right. The [checklist for counts that do not match the ERP](/docs/production/troubleshoot-part-counts/#erp) walks through what to do when a gap survives that. Do not tune either system to make the two agree to the part. A machine count and a hand declaration never agree exactly, and a setup adjusted until they do is tuned to paperwork rather than to the machine. ## Connect IoTFlows to your ERP IoTFlows works on all three paths. On every plan, the Production Scheduler imports jobs from any ERP's CSV or Excel export in six steps. Webhooks send machine events to your own endpoint, and a REST API lets your code read the same records. For Enterprise plants, IoTFlows engineers build two-way connectors to Epicor, SAP, Oracle, JobBOSS, ProShop and others as a [custom integration](/platform/custom-integrations/). Each runs in five steps, from scoping and data mapping to build, validation and handover, in one week to a month depending on the machines. MiRus, an implant maker in Marietta, Georgia, runs its jobs in Epicor. A two-way connector built in about a month ties every job to its machining and labor hours. > The real-time visibility has been amazing for optimizing our operations. With the ERP integration, I see the numbers and where every job stands, without digging for them in our ERP. > > Dennis Moreno, Vice President of Manufacturing and Operations, MiRus ([story](https://www.iotflows.com/customers/mirus/)) ## Run the project in five steps Start small, prove the conventions, then widen. Each step below is one decision or one check. 1. **Pick one machine group and one transaction.** Choose four to six machines that run the same part family, and post one ERP transaction, such as the labor or confirmation entry for each operation. 2. **Build the cross-reference.** List every job, operation, work center and part number on both sides, with the ERP spelling as the master. The [ERP import column reference](/docs/production/import-erp-schedule/#columns) shows which export columns map to which job fields. 3. **Write down the conventions.** Decide elapsed or running hours, gross or good quantity, and which day a run that crosses midnight belongs to. Put the answers where the planner and the cost accountant both read them. 4. **Run in parallel for two weeks.** Keep the operators' time tickets and compare them with the machine actuals every day. Every gap should trace to a convention, a missing job start or a bad ID. 5. **Switch on posting and review weekly.** Stop the hand entries for that group, then read the variance by job each week. Add the next machine group once a full week posts with no manual fixes. Before you add machines, check what else is worth collecting from them in the [guide to manufacturing data collection](/blog/manufacturing-data-collection/). ## Questions ### Do I need an MES between my machines and my ERP? Not for hours and counts. A monitoring system that records machine state and cycle counts, plus a reliable way to tie each run to a job, supplies what the ERP labor and production entries need. Choose an MES when routings, traceability and quality records are the bottleneck, rather than machine time. ### Should machine data replace operator labor entries in the ERP? Replace machine hours and counts, and keep labor hours tied to the operator. A sensor measures the machine, not the person, so an operator running two machines would be charged twice if labor came from machine time. Take labor from the operator sessions on each job and machine time from the machine record. ### How long does an ERP integration take? A file import works the day you save its column mapping. A custom API feed takes as long as your developer needs to learn the ERP interface. IoTFlows delivers Enterprise custom integrations in one week to a month depending on the machines, and the two-way Epicor connector for MiRus took about a month. ### What if the ERP part numbers do not match the machine system? Fix the mapping before the first sync. Build one cross-reference of part numbers, work centers and operation codes, and make the ERP spelling the master. A part written Y841070 in one system and Y-841070 in the other becomes two records, and every hour posted against the second one lands on the wrong part. ## Sources 1. [ISA-95 Standard: Enterprise-Control System Integration](https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard), International Society of Automation, accessed Oct 16, 2026 2. [Confirming Production Orders (Exploring Business Processes in SAP S/4HANA Discrete Shopfloor Control)](https://learning.sap.com/courses/exploring-business-processes-in-sap-s4-hana-discrete-shopfloor-control/confirming-production-orders_d5811bf4-fb07-411d-8bdb-0f9cec11e4db), SAP Learning, accessed Oct 16, 2026 3. [JobBOSS² Data Collection (App Store listing)](https://apps.apple.com/us/app/id1213396029), Shoptech Industrial Software Corp, accessed Oct 16, 2026 --- # Production scheduling on real run rates Source: https://www.iotflows.com/blog/production-scheduling-on-real-run-rates/ Schedule from the rate each machine really runs, not its ideal cycle time. Turn measured OEE factors into job durations, pick a rate and load machines safely. > Question: How do I build a schedule that matches what the machines actually do? ## Key takeaways - Size each job from the effective cycle time a machine has measured, not from its ideal cycle time. - Effective cycle time is the ideal cycle time divided by availability, performance and quality for that operation on that machine. - Plan with the median of recent runs, and use a slower percentile when the due date is a customer promise. - Load each machine below its planned hours, because queue time climbs steeply as the load approaches 100%. - Compare logged run time with planned time every week, and update a rate once it drifts more than 10%. You build a schedule that matches what the machines actually do by sizing every job from the rate each machine has measured on that operation, not from its ideal cycle time or the ERP routing standard. Divide the ideal cycle time by the availability, performance and quality you measured, plan with the median of recent runs, load each machine below its planned hours, and correct the rates every week from what was logged. This guide is for plant managers and planners whose schedule says Tuesday while the floor delivers Thursday. It works one job through by hand, then shows which rate to plan with and how to keep the rates current. ## Why a schedule drifts from the floor A schedule drifts because it plans each job at a speed the machine never holds for a whole run. Three different numbers carry the name cycle time, and only one of them includes the stops, slow cycles and scrap that every real run contains. | Number | Where it comes from | What it leaves out | Use it for | |---|---|---|---| | Ideal cycle time | The best sustainable cycle | Every stop, slow cycle and scrap | OEE performance, never durations | | Routing standard | A time study or the first quote | Drift since it was written | Quoting and costing | | Effective cycle time | Logged time and good parts | Nothing those runs went through | Durations and due dates | Measure effective cycle time per machine and operation, from the runs that machine logged. > **Definition.** **Effective cycle time** is the planned production time a run took divided by the good parts the run made. Effective cycle time equals the ideal cycle time divided by the product of availability, performance and quality, so every loss the machine had on that operation is inside the figure. The *ideal cycle time* is the best cycle the operation sustains in good conditions, the figure you enter on the operation, as [setting the ideal cycle time](/blog/ideal-cycle-time/) explains. The [glossary entry for cycle time](/docs/get-started/glossary/#cycle-time) separates it from the actual cycle time measured on the machine. For example, a bracket operation on a Haas VF-2 with a 90-second ideal cycle time can still average 135 seconds per good part once stops, short pauses and scrap are counted. The Lean Enterprise Institute's *effective machine cycle time* adds load and unload time to the machine cycle, plus the changeover time divided by the pieces between changeovers. A 20-second cycle with 30 seconds of load and unload and a 30-second changeover every 30 pieces is 51 seconds.[3] Effective cycle time extends the same idea to every stop, slow cycle and scrapped part. Routing standards drift for a different reason. They belong to the business planning layer: ISA-95 describes Level 4 as all the activities of running a business, ERP included, and places manufacturing execution systems at Level 3.[2] A standard written at Level 4 for a quote is rarely revisited when the machine, the fixture or the operator changes. ## Turn a measured rate into a job duration A job's duration is its setup time plus the good quantity multiplied by the effective cycle time. Measure the three OEE factors for the operation on the machine that will run it, as the [OEE factor calculations](/blog/how-to-calculate-oee/#factors) describe, then divide them out of the ideal cycle time. **Effective cycle time** = (Ideal cycle time) ÷ (Availability × performance × quality) **Job duration** = Setup time + good quantity × effective cycle time The quality factor turns the order quantity into the quantity you must start. The availability and performance factors stretch the run from ideal to real. #### Worked example: 1,200 brackets on a Haas VF-2, operation OP20 - Order: 1,200 good parts. Ideal cycle time: 90 s. Setup: 1.5 h, measured on its own. - Measured on this operation over recent runs: availability 80%, performance 85%, quality 98%. - Parts to start: 1,200 ÷ 0.98 = 1,224.5, so 1,225. - Run time at the ideal rate: 1,225 × 90 s = 110,250 s = 30.625 h. - Real run time: 30.625 h ÷ (0.80 × 0.85) = 30.625 ÷ 0.68 = 45.04 h. - The naive plan is 1.5 h + 1,200 × 90 s = 1.5 h + 30.0 h = 31.5 h. At 15 planned hours a day from Monday, that finishes early Wednesday; the real job runs into Thursday. **Result:** Job duration = 1.5 h + 45.04 h = 46.5 h, 47.7% longer than the 31.5 h naive plan The shortcut gives the same answer within rounding. Effective cycle time is 90 ÷ (0.80 × 0.85 × 0.98) = 90 ÷ 0.6664 = 135.05 s, and 1,200 × 135.05 s = 45.02 h of run time. > **Don't count setup twice** > > If your availability figure already counts changeovers as stops, don't add setup time on top. Either measure availability on the production run alone and add setup separately, or use availability with setups in it and skip the setup term. ## Which rate should you plan with? Plan with the median effective cycle time of recent runs of the same operation on the same machine. One run is noisy, the best run is a target rather than a forecast, and a plant-wide OEE hides the slow machine and part pairs. For example, the last eight runs of OP20 on the Haas VF-2 took 118, 124, 129, 133, 137, 142, 150 and 171 seconds per good part. The median is (133 + 137) ÷ 2 = 135 s. The 80th percentile, the seventh of the eight, is 150 s. Figure: Four bars for the same 1,200-part job: 31.5 h at the 90 s ideal cycle time, 40.8 h at the 118 s best run, 46.5 h at the 135 s median and 51.5 h at the 150 s 80th percentile, against a due date at 45 h. *The same job planned at four rates: only the ideal and the best run beat a Wednesday due date. Sample data.* | Rate | Duration with setup | Use it when | |---|---|---| | Ideal cycle time, 90 s | 31.5 h | Never, for a duration | | Best run, 118 s | 40.8 h | Setting an improvement target | | Median of recent runs, 135 s | 46.5 h | Default for every job | | 80th percentile, 150 s | 51.5 h | The date is a customer promise | > **Median or 80th percentile?** > > Use the median for internal sequencing, because over many jobs the early finishes and late finishes cancel out. Use the 80th percentile for the date you give a customer, because a single late shipment costs more than a few hours of slack. You don't need a percentile for parts with fewer than ten runs: use the median until you have them. Keep one rate per machine and operation pair. If night shift runs OP20 at 150 s and day shift at 128 s, keep a rate for each shift, or plan with the slower one on any job that spans both. ## Load each machine below its planned hours Load each machine below its planned hours, even when every duration is right. Run times vary, jobs arrive unevenly, and a machine scheduled to 100% has no room to absorb either, so the queue in front of it grows. > **Definition.** **Schedule load** is the planned work on a machine in a period divided by the hours the machine is scheduled to be available in that period, with every job sized at its effective cycle time. Queueing theory gives the shape of the problem. Kingman's approximation for a single machine estimates the average wait in queue as load ÷ (1 − load), multiplied by a variability term and by the average job time.[1] When the gaps between job arrivals and the job times each have a coefficient of variation of 1, as in a purely random process, the variability term is 1. Figure: A curve of load divided by one minus load rises slowly from 1 times the job time at 50% load to 2.3 at 70% and 5.7 at 85%, then climbs to 19 at 95%. *Average wait in queue rises slowly up to 85% load, then more than triples by 95%.* #### Worked example: One machine, 75 planned hours a week, 8-hour average job - At 70% load, 52.5 h of work: wait ≈ (0.70 ÷ 0.30) × 8 h = 18.7 h. - At 85% load, 63.75 h of work: wait ≈ (0.85 ÷ 0.15) × 8 h = 45.3 h. - At 95% load, 71.25 h of work: wait ≈ (0.95 ÷ 0.05) × 8 h = 152.0 h. **Result:** Adding 7.5 h of work a week, from 85% to 95% load, adds 106.7 h to the average wait Load the [bottleneck](/blog/find-the-bottleneck/#load) to about 85% of its planned hours and keep other machines lower, then adjust from your own lead times. The ideal-rate trap compounds here. A schedule built on ideal cycle times that looks 85% loaded is really 0.85 × (135 ÷ 90) = 127.5% loaded on the machine in the example above. Spare hours are not free either. An idle hour still carries the machine's fixed costs, so check [what an idle machine costs](/blog/cost-of-idle-machines/) before you add a shift or a machine to protect the margin. ## Check the plan against the floor every week A rate is only right until the process changes. A new insert grade, a second fixture or a new operator moves the effective cycle time, so check it every week against what the machine logged. 1. **Collect each finished task.** Take every task that finished last week: its start, its end, its setup time and its good parts. Use machine data where you have it, because a hand log rounds a 7-minute stop to zero and the stop drops out of availability. 2. **Compute each task's effective cycle time.** Divide the planned production time the task took, setup excluded, by the good parts. A task that took 49.5 h for 1,200 good parts ran at 148.5 s per part. 3. **Compare it with the planned rate.** Divide actual by planned for each machine and operation pair. A ratio of 1.10 means the job took 10% longer than the schedule allowed. 4. **Update rates that drift.** When the median of the last five runs sits more than 10% from the planned rate, replace the rate. For example, five runs of OP20 at 148, 152, 139, 155 and 150 s have a median of 150 s, 11.1% above 135 s, so OP20 moves to 150 s. 5. **Track schedule attainment.** Divide the jobs finished by their due date by the jobs due in the week. For example, 34 of 40 jobs on time is 85.0%. Measure in jobs or in hours, and keep the same unit every week. Read the two numbers together. Rising attainment with stable rates means the schedule is learning. Falling attainment with rates that keep slowing means the process is losing ground, and that is a job for the [downtime and performance losses](/blog/what-is-oee/#six-losses), not for the schedule. ## Schedule on live machine data SenseAi reads running and stopped time from the outside of each machine and counts parts from its cycle, so every run carries its own availability, performance and [actual cycle time](/docs/monitoring/metrics-reference/#cycle-time). The [Production Scheduler](/platform/production-scheduler/) runs on those same machines, so the schedule uses the real part count. A new task's [time estimate](/docs/production/create-a-job/#estimate) starts from the ideal cycle time times the quantity; replace it with the quantity times the effective cycle time. With [Working hours](/docs/production/scheduler/#working-hours) on, durations consume shift time only. The [optimizer](/docs/production/optimize-the-schedule/) packs against the same estimates, and a strip under each Gantt bar shows what operators logged. If your schedule still lives in a spreadsheet, [when to replace a spreadsheet production schedule](/blog/replace-spreadsheet-schedule/) helps you decide when to move it. [Hugo Benzing](/customers/hugo-benzing/) plans coiling, heat treatment and packing in the Production Scheduler, with SenseAi counting coils on its coilers while each run is going. Planning its tubes, racks and boxes as tooling brought a 20% efficiency increase, and its planners save more than 10 hours a week. ## Checklist for your next schedule Run these checks before you release a week's schedule to the floor. | Check | Why it matters | |---|---| | Durations use effective cycle time | Ideal times make every job look short | | One rate per machine and operation | A plant-wide OEE hides the slow pairs | | Setup counted once | Twice inflates every changeover job | | Start quantity covers scrap | Good parts ship, not starts | | Durations consume shift hours only | Else the plan runs through nights | | Bottleneck load near 85% or below | Queues grow fast past that point | | Rates checked against last week | Stale rates drift a little each month | The percentages are starting points from the worked examples. Set your own from the lead times your plant measures. If a job is late with a correct rate and a sensible load, the schedule is not the problem. Look at the stops on that machine, starting with the [downtime reasons that cost the most hours](/blog/downtime-pareto/). ## Questions ### Should I plan with the ERP routing standard or the measured rate? Plan durations and due dates with the measured rate once a part has run on that machine a few times. Keep the routing standard for quoting and costing until your finance team agrees to update it, and review the gap between the two each quarter, because a large gap usually means the standard was written for a different machine or method. ### How many runs do I need before I trust a measured rate? Five runs of the same operation on the same machine give a usable median, and ten give a usable 80th percentile. With fewer, plan with the routing standard plus the average gap you see on similar parts on that machine, and replace it with the measured median once the fifth run is logged. ### What rate do I use for a part that has never run? Start from the ideal cycle time and divide it by the availability and performance that machine shows on similar parts. A new bracket on a mill that runs other brackets at 80% availability and 85% performance gets the same factors. Replace the estimate with the measured rate after the first few runs. ### Does planning on measured rates hide the losses I should fix? No. The schedule uses the measured rate so that dates are honest, and OEE keeps measuring each run against the ideal cycle time so the losses stay visible. When an improvement lifts availability or performance, the measured rate follows within a few runs and the schedule frees the hours. ## Sources 1. [The single server queue in heavy traffic, Mathematical Proceedings of the Cambridge Philosophical Society 57(4), 902–904 (1961)](https://www.cambridge.org/core/journals/mathematical-proceedings-of-the-cambridge-philosophical-society/article/abs/single-server-queue-in-heavy-traffic/81C55BC00A68FE6D5385638AA0B0AF37), Cambridge University Press, accessed Oct 16, 2026 2. [ISA-95 Standard: Enterprise-Control System Integration](https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard), International Society of Automation, accessed Oct 16, 2026 3. [Cycle Time](https://www.lean.org/lexicon-terms/cycle-time/), Lean Enterprise Institute, accessed Oct 16, 2026 --- # What IoT machine data adds to an MES Source: https://www.iotflows.com/blog/manufacturing-excellence-with-mes-and-iot/ An MES is only as accurate as its machine data. Measured stops and part counts replace typed-in ones, so its downtime and OEE factor split come out right. > Question: How does IoT machine data improve an MES? ## Key takeaways - An MES plans and records production, but its downtime, performance and OEE figures are only as good as the machine data feeding it. - Operator-entered stops miss short stops, which moves lost time from availability into performance and points the team at the wrong problem. - Machine data reaches an MES three ways: operator entry, a controller connection, or a sensor mounted on the outside of the machine. - Use controller data where you need alarms and program names, and sensors to cover machines with old, closed or unnetworked controls. - Agree on one definition of running, one shift calendar and one owner for downtime reasons before connecting machine data to the MES. IoT machine data improves an MES by replacing the machine facts people type in with facts measured on every machine: when it ran, when it stopped and how many cycles it completed. The MES keeps doing its own job, dispatching orders and recording each run. Its downtime, performance and OEE figures then rest on measured time instead of an end-of-shift estimate. This article is for plant managers and engineers who run an MES, or are choosing one, and want to know what sensors and machine connections add. It works through one shift on a hypothetical CNC mill, logged both ways. ## What an MES does > **Definition.** **MES (manufacturing execution system)** is software that runs manufacturing operations on the shop floor: it dispatches orders to work centers, tracks each job through its routing, and keeps the record of what was made, when, by whom and to what quality. ISA-95, the standard for connecting business systems with plant control, places MES at Level 3, manufacturing operations.[1] PLCs and other controls sit below it at Level 2, and the ERP sits above it at Level 4. The standard primarily deals with the interface between Levels 3 and 4: orders going down and results coming up.[1] [Connecting machine data to your ERP](/blog/connect-machine-data-to-erp/) covers the same interface without an MES. That interface is where the machine data question starts. The ERP sends the MES an order for 200 brackets, and the MES has to know which machine is free, how fast it runs and why it stopped. ISA-95 defines the activities at each level, not the technology that carries data between them.[1] ## Where an MES gets its machine data Every MES screen that shows machine state draws on one of three paths. Each one starts at the same machine and ends at Level 3. Figure: A stack from the machine at Level 0 to the ERP at Level 4. Three paths carry machine data up into the MES at Level 3: operator entry, a controller read over a protocol, and a sensor mounted on the outside of the machine, which is highlighted. *Three paths carry machine data into the MES; the ERP exchanges orders and results with it.* - **Operator entry.** The operator records job start, stops and counts on a terminal. It works on any machine, and its resolution is what a person notices and remembers. - **Controller connection.** The MES or a gateway reads the machine's control over a protocol such as MTConnect or OPC UA, a platform-independent architecture the OPC Foundation released in 2008.[3] Most legacy machines, those built without MTConnect output, need a computer to act as the adapter that translates their data to the standard.[2] - **Sensor on the machine.** A sensor mounted on the outside reads vibration, sound or a beam broken by each part, and decides running or stopped from that physical signal. It needs no connection to the control. [MTConnect, OPC UA and Modbus compared](/blog/machine-communication-protocols/) explains what each protocol carries and when a machine needs one. ## What typed-in machine data misses [Operator entry](/blog/manufacturing-data-collection/#manual) captures the stops long enough to remember: a tool that wasn't ready, a pallet of blanks that hadn't arrived. It misses the two- and three-minute stops between them, because nobody walks to a terminal to log a 150-second wait for a crane. #### Worked example: One shift on a Haas VF-2, logged two ways - Shift: 480 minutes with a 30-minute break, so planned production time is 450 minutes. - Logged by the operator: a 25-minute wait for a tool and a 20-minute wait for material, 45 minutes in all. - Measured by a sensor: the same two stops, plus 18 short stops of 2.5 minutes each, another 45 minutes. - Ideal cycle time: 4 minutes. Parts made: 85, of which 83 are good. From the operator log, run time is 450 − 45 = 405 minutes. Availability is 405 ÷ 450 = 90.0% and performance is (85 × 4) ÷ 405 = 84.0%. From the sensor, run time is 450 − 90 = 360 minutes. Availability is 360 ÷ 450 = 80.0% and performance is (85 × 4) ÷ 360 = 94.4%. Quality is 83 ÷ 85 = 97.6% either way. **Result:** OEE = (340 ÷ 450) × (83 ÷ 85) = 73.8% in both records Figure: Two timelines of the same 450-minute shift. The operator log shows two stops totaling 45 minutes and 90.0% availability. The sensor record shows those two stops plus 18 short stops, 90 minutes in all, and 80.0% availability. *The same shift, logged by hand and measured by a sensor. Sample data.* OEE is the same in both records, because availability times performance always equals ideal output over planned time. What changes is the split. The typed record says the machine runs 16% slow when it runs; the measured record says it runs close to its ideal cycle and stops 18 more times a shift. > **Same OEE, different problem** > > A team reading the typed record works on feeds, speeds and programs. A team reading the measured record goes after the 18 short stops, such as waits for the crane. Only the second team recovers the hidden 45 minutes, so check the factor split before you assign the work. The factor definitions behind this example are in [how to calculate OEE](/blog/how-to-calculate-oee/). In a monitoring system, availability is reported as [uptime](/docs/get-started/glossary/#uptime), running time over running plus stopped time. ## Controller data or a sensor? Both measured paths remove the guesswork from stops. They differ in what else they can tell the MES, and in what it takes to connect them. | | Operator entry | Controller connection | Sensor on the machine | |---|---|---|---| | Works on any machine age | Yes | No | Yes | | Records every short stop | No | Yes | Yes | | Counts parts automatically | No | Yes | Yes | | Reads alarm codes and programs | No | Yes | No | | Connects to the machine's control | No | Yes, IT usually reviews it first | No | Most legacy machines built without MTConnect output need an adapter computer before an MTConnect connection works. Choose controller data when: - you need alarm codes, program names or process values in the MES, not only running and stopped; - the machines have networked controls and IT has approved the connection, since a connection to the control is a security concern for many plants. Choose a sensor on the machine when: - the fleet mixes brands and ages, and some controls are old, closed or not on the network; - you need every machine reporting within days rather than after a connection project. For a mixed fleet, default to a sensor on every machine and add controller data where the extra signals pay for themselves. Whichever you use, write down what "running" means for each machine type. A control reports what it is executing; a sensor reports what the machine physically does. ## Cover every machine, not only the networked ones An MES that reads only the machines with modern controls has a partial picture, and the gaps fall in the wrong places. Older machines are often the ones feeding everything else. For example, take a cell with five networked CNC mills fed by a bandsaw and two manual lathes. The MES reads the mills and nothing else. When the saw stops for 40 minutes, all five mills run out of blanks, and the MES logs five 40-minute stops on the mills with no cause it can see. [Measured on every machine](/blog/production-line-monitoring-without-plcs/#first-stop), the same morning reads differently: one 40-minute stop at the saw, and five mills waiting on it. The fix moves from the mills to the saw. You don't need more controller connections on the mills to see this; you need any machine signal at all from the saw. ## Connect machine data to the MES Machine data reaches an MES as events: a stop started, a stop ended with its reason, a part counted. Map each MES function to the events it needs before choosing how to send them. | MES function | Machine data it needs | Without it | |---|---|---| | Dispatching | Which machines are running now | Dispatch by phone or a walk | | Performance analysis | Run time and part counts | End-of-shift estimates | | Downtime analysis | Every stop, with start, end and reason | Only stops someone logged | | Job and labor tracking | Run time matched to each job | Clock time stands in for run time | | Maintenance hand-off | Stops and alarms per machine | Requests by word of mouth | 1. **Define running for each machine type.** Agree whether a mill with the spindle turning and no cut counts as running, and apply the same rule in both systems. 2. **Use one shift calendar.** Load the same shifts, breaks and timezone into the monitoring system and the MES, so a stop at 06:58 falls in the same shift in both. 3. **Map machines to work centers.** Give each machine one identifier and map it to its MES work center, so a Haas VF-2 in the monitoring system is the same Haas VF-2 in the MES. 4. **Choose push or pull.** Push events over a webhook or MQTT when the MES reacts within seconds, as dispatching does. Pull totals from a REST API when the MES needs a shift rollup. 5. **Pick one owner for downtime reasons.** Let operators classify stops in one system and send the reason with the stop, instead of asking for it twice. 6. **Check counts against a hand count.** Count ten parts by hand and compare. A count that is exactly double or half points to a quantity-per-cycle setting, as the [part count troubleshooting guide](/docs/production/troubleshoot-part-counts/#double) shows. ## Feed an MES from every machine with IoTFlows A [SenseAi](/products/senseai/) attaches magnetically to each machine and reads its vibration and sound, with no PLC and no wiring into the controls. It decides running or stopped every second on the device, and the cloud derives uptime, downtime, part counts and cycle times from that record. [How IoTFlows works](/docs/get-started/how-iotflows-works/#on-device) shows where each decision is made. Operators classify stops in a tap, and an automatic rule classifies [short downtimes](/docs/monitoring/auto-downtime-rules/#short-downtimes). To reach your MES, IoTFlows posts machine events to your own endpoint as [signed webhooks](/docs/alerts/webhooks/#secret), and a REST API returns the same records the dashboard shows. On Enterprise, the [edge device](/docs/get-started/glossary/#edge-device) brings in controller data from the controls you choose to connect. [MiRus](/customers/mirus/) ties every Epicor job to the machining and labor hours behind it through a two-way connector that went live in about a month. ## Do you need an MES at all? Machine data makes an MES more accurate, but it doesn't make an MES necessary. You probably don't need one yet if your daily questions are what ran, why it stopped, what to fix and what to make next. You need an MES when a customer or regulator asks for a complete record of every run, every operator and every inspection. [Machine monitoring vs MES vs CMMS](/compare/machine-monitoring-vs-mes-vs-cmms/) compares the three systems and which one to put in first. ## Questions ### Does an MES need a PLC connection to get machine data? No. An MES can take machine state and part counts from operator entry, from a controller connection, or from sensors mounted on the outside of each machine. Many plants mix them, with controller data where alarms and program names matter and sensors on machines whose controls are old, closed or not on the network. ### Which system should own downtime reasons? Pick one. If operators classify stops at the machine in the monitoring system, send the reason to the MES with the stop instead of asking for it a second time. Two places to enter a reason produce two different answers, and someone then spends every Monday reconciling them. ### Does sensor data change the OEE number in the MES? Often not the total. Availability times performance equals ideal output over planned time, so short stops the MES never saw move from availability into performance while OEE stays the same. What changes is which factor looks low, and so which problem the team spends its week on. ## Sources 1. [ISA-95 Standard: Enterprise-Control System Integration](https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard), International Society of Automation (ISA), accessed Oct 16, 2026 2. [Digital Manufacturing for Legacy Equipment Using a Standards-Based Approach: An MTConnect Use Case](https://www.amtonline.org/article/digital-manufacturing-for-legacy-equipment-using-a-standards-based-approach), AMT, The Association For Manufacturing Technology, accessed Oct 16, 2026 3. [OPC Unified Architecture](https://opcfoundation.org/about/opc-technologies/opc-ua/), OPC Foundation, accessed Oct 16, 2026 --- # Manual vs automatic OEE tracking in the first week Source: https://www.iotflows.com/blog/manual-vs-automatic-oee-tracking/ Machine-reported stops move lost minutes from performance into availability. OEE itself moves only if part counts, ideal cycle times or planned time were off. > Question: What happens to my OEE when I stop writing stops on paper and let the machine report them? ## Key takeaways - Machine-reported stops lower availability and raise performance, because short and rounded stops move from one factor to the other. - OEE equals good count times ideal cycle time divided by planned production time, so run time and stop logs cancel out. - OEE itself changes in the first week only when part counts, ideal cycle times, planned time or scrap records were wrong. - Performance above 100% on the new data means the ideal cycle time is set too slow, not that the machine got faster. - Automatic capture still needs people to set ideal cycle times, log scrap and give unexplained stops a reason. When you stop writing stops on paper and let the machine report them, your availability drops and your performance rises to match. The short stops, rounded durations and shift-start gaps the paper missed were already in your OEE, hidden as slow running. OEE itself moves only if your [part counts](/blog/part-counting-methods/), ideal cycle times or planned production time were wrong, and the first week is when you find out. The sections below work one shift both ways, list the inputs that do change OEE and give a five-day plan for the switch. They’re written for plant managers who need the new numbers believed on the floor. ## Manual and automatic tracking defined > **Definition.** **Manual OEE tracking** is the practice of recording stops, part counts and scrap by hand, on a shift sheet, whiteboard or spreadsheet, and calculating availability, performance and quality from those records after the shift ends. > **Definition.** **Automatic OEE tracking** is the practice of recording run state and part counts from a signal on the machine, every second and every cycle, so availability and performance are calculated without anyone writing a stop down; scrap and stop reasons still come from people. OEE multiplies three factors. Availability is run time over planned production time, performance is ideal cycle time × total count over run time, and quality is good count over total count.[1] The [OEE glossary entry](/docs/get-started/glossary/#oee) gives the same factors in IoTFlows’ terms. Neither method changes the formula. They change who records each input and when, as the figure shows. Figure: A map of six OEE inputs. Run state, part count and total count come from the machine, every second or every cycle. Planned production time, ideal cycle time and scrap with its reason are entered by people. *Run state and counts come from the machine; planned time, ideal cycle time and scrap still come from people.* ## Why the stop log can’t change OEE Multiply the three factors and run time cancels out. It sits in the numerator of availability and the denominator of performance, so what’s left is a ratio with no stops in it: **OEE** = (Good count × ideal cycle time) ÷ (Planned production time) This is the single most useful fact for the first week. Every stop the machine finds that the paper missed takes minutes from run time. Availability falls, performance rises by the same factor, and OEE stays where it was. #### Worked example: One shift on a 150-ton injection molding machine, recorded two ways - Shift: 480 minutes with a 30-minute lunch, so planned production time is 450 minutes. - Ideal cycle time: 30 seconds (0.5 minutes) for a single-cavity mold. Total count: 690 parts, 669 good. - Paper log: a material wait written as 20 minutes and a nozzle freeze-off written as 15, so 35 minutes stopped. - Machine record: the same two stops at 27 and 18 minutes, a 12-minute start-of-shift gap and 24 short stops averaging 1.5 minutes, so 93 minutes stopped. From the paper log, run time is 415 minutes. Availability is 415 ÷ 450 = 92.2% and performance is (690 × 0.5) ÷ 415 = 83.1%. From the machine record, run time is 357 minutes. Availability is 357 ÷ 450 = 79.3% and performance is 345 ÷ 357 = 96.6%. Quality is 669 ÷ 690 = 97.0% either way. **Result:** OEE = (669 × 0.5) ÷ 450 = 74.3% both ways Availability fell 12.9 points and nothing on the floor changed. If you report availability on its own, warn the team before the first shift report goes out. For each factor worked step by step, see [how to calculate OEE](/blog/how-to-calculate-oee/). ## Where the missing minutes come from The paper log in the example held 35 of the 93 stopped minutes. The other 58 came from three places, and each one has its own fix. Figure: A waterfall of stopped minutes. The paper log holds 35 minutes in 2 stops. Rounded times add 10, the shift start adds 12, and 24 short stops add 36, the largest share, for 93 minutes in the sensor record. *The 58 stopped minutes the paper missed, by source; short stops are the largest share. Sample data.* - **Short stops.** A *minor stop* is one that lasts a minute or two and needs no maintenance technician, and most companies don’t track them accurately.[2] Here, 24 jams and clears cost 36 minutes nobody wrote down. - **Rounded durations.** An operator writes the stop when it’s over, from memory, in round numbers that run short. The 27-minute material wait became 20 and the 18-minute freeze-off became 15. - **Shift edges.** The warm-up and the restart after the handover rarely reach the sheet, because the machine never “broke”. Here they cost 12 minutes. The split between availability and performance depends on a cutoff. One published example policy gives every stop longer than 2 minutes a reason, which files it under availability; shorter stops stay in performance.[2] Pick a cutoff, write it down and keep it, so the same jam lands in the same factor every week. For how short stops behave and how to cut them, see [micro-stops](/blog/micro-stops/). ## What does change OEE in the first week? OEE moves only when an input in the formula above changes. The first week of machine data tests each one, and most plants find at least one that was off. | Input | How paper gets it wrong | What machine data shows | |---|---|---| | Part count | Tallied or copied from the traveler | A count every cycle | | Ideal cycle time | The quoted standard, with allowances | Actual cycles faster than the ideal | | Planned production time | Warm-up left out of the shift | Stops at both shift edges | | Good count | Reworked parts counted as good | Nothing: scrap still needs a person | A part that needs rework is not good in OEE quality, which counts only parts that pass the first time. Quality is the factor automation helps least. A molding machine runs the same cycle for a short shot as for a good part, so someone at the machine or an inspection step decides which parts were scrap. The ideal cycle time causes the largest surprises. It should be the [best cycle the operation sustains](/blog/ideal-cycle-time/) in good conditions, so performance above 100% means the ideal is set too slow.[1] #### Worked example: The same shift with the routing’s 36-second standard - The paper sheet used the routing’s 36-second standard (0.6 minutes) as the ideal cycle time. - Paper performance: (690 × 0.6) ÷ 415 = 99.8%, which looks plausible. - Machine performance: 414 ÷ 357 = 116.0%, which is impossible. - Correcting the ideal to the 30 seconds the machine sustains at its best brings performance to 96.6%. **Result:** OEE falls from (669 × 0.6) ÷ 450 = 89.2% to 74.3%, a measurement fix Figure: Three performance bars against a dashed 100% line. Paper log with a 36-second ideal reads 99.8%. Sensor record with the same ideal reads 116.0%, past the line. Sensor record with a 30-second ideal reads 96.6%. *Unlogged stops inflate run time and hide a slow ideal cycle time; the machine record exposes it. Sample data.* The paper record hid the error, because unlogged stops padded run time and pulled performance under 100%. The machine record exposed it on day one. > **Don’t pad the ideal cycle time** > > Set the ideal cycle time from the best cycle the machine sustains, timed over 10 to 20 consecutive cycles, not from the quoted standard. A padded ideal raises performance and OEE, and it hides the speed losses OEE exists to show. Fix it once, per operation, in the first week. ## Manual and automatic capture compared Each method records the same inputs with different precision. The difference is widest for stops and counts, and nil for scrap. | | Paper or spreadsheet | Machine-reported | |---|---|---| | Stop start and end | Written from memory | Recorded to the second | | Stops under 2 minutes | Rarely written down | Every one, with its duration | | Stop reason | Written by the operator | Picked by the operator or a rule | | Part count | Tallied at shift end | Counted every cycle | | Ideal cycle time | Set by an engineer | Set by an engineer | | Scrap and rework | Logged by a person | Logged by a person | | Numbers arrive | After the shift | While the shift runs | Use paper when you’re proving the habit on one machine for two or three weeks, before you spend anything. Use machine-reported data once you need short stops, more than one machine or numbers during the shift. ## Automatic capture still needs your definitions Switching the capture method doesn’t fix the inputs people set. A study from Chalmers University of Technology shows what happens when nobody does. The researchers analyzed six months of data from 23 Swedish manufacturers and 884 machines, all running the same automatic OEE system.[3] Median OEE was 70% and the average 65%.[3] - **Performance at the default.** 702 of the 884 machines reported 100% performance, the system’s default value, which suggests no cycle times were measured.[3] - **Quality at the default.** 796 of the 884 machines reported 100% quality, also the default.[3] - **Losses with no reason.** Unclassified losses took about 19% of scheduled production time, more than half of all recorded loss time.[3] With performance and quality left at their defaults, the authors question whether those companies measured OEE at all, or only availability.[3] Their conclusion: when measurement is automated, managing the details of each process matters more, not less.[3] Three tasks in your first week prevent each of these failures: set an ideal cycle time per operation, log scrap at the machine, and give every unexplained stop a reason. A short reason list gets used; see [which downtime reason codes to log](/blog/downtime-reason-codes/). ## A five-day plan for the switch Run the paper log and the machine record side by side for one week on the machines you switch first. Paper stays the reference for reasons and scrap; the machine becomes the reference for minutes and counts. 1. **Define shifts and breaks before day one.** Enter the plant’s timezone, shifts and scheduled breaks so planned production time matches the floor. Shifts sort data as it arrives, so set them before the first machine reports; see [shifts and timezone](/docs/admin/shifts-and-timezone/). 2. **Check the count against ten parts.** On day one, count ten parts by hand as they come off and compare them with the machine’s count. A four-cavity mold set to one part per cycle reads a quarter of its real output; the [ten-part check](/docs/production/quickstart/#validate) says how close is close enough. 3. **Correct each ideal cycle time.** On day two, check performance for each operation. Performance above 100% means the ideal cycle time is set too slow, so enter a faster one; see [set the ideal cycle time](/docs/production/cycle-times-and-filters/#ideal). 4. **Classify routine stops by rule.** On day three, set rules that classify short stops and stops at the shift edges, so operators explain only the stops in the middle of a shift. [Automatic downtime rules](/docs/monitoring/auto-downtime-rules/) covers each one. 5. **Log scrap at the machine.** From day three, operators log each bad part when it happens, with a reason, instead of tallying the bin at shift end. The [scrap logging steps](/docs/production/log-scrap/#log) show the entry. 6. **Reconcile the week factor by factor.** On day five, put the paper and machine figures side by side for each shift. Explain the stopped-minute gap by source: short stops, rounding, shift edges and offline time. [Reconcile with a manual calculation](/docs/monitoring/troubleshoot-monitoring/#manual-check) lists the differences that remain. After day five, retire the paper log and mark the switch date on every trend chart. Set the first goal a few points above the new baseline, never the old paper figure; [choose an OEE goal](/docs/monitoring/oee-goals/#choosing) explains why. ## Track OEE from the machine A SenseAi sensor mounts magnetically on the outside of each machine and detects every stop in seconds, with no PLC connection and no operator input. IoTFlows reports [OEE factor by factor](/solutions/oee-tracking/): availability as uptime, performance as parts counted against the ideal cycle time, and quality from the scrap operators log with a reason. Data lands in the shifts you define as it arrives. The Short Downtimes rule classifies stops under a per-machine cutoff, 5 minutes by default, and the shift-start and shift-end rules cover the edges. Operators put a reason on what’s left in a tap. [Sorinex](/customers/sorinex-exercise-equipment/) installed SenseAi sensors across its critical production equipment in under 5 days, and its story reports an 87% improvement in root cause visibility within the first month. ## When manual tracking is enough Choose manual tracking when: - **You track one machine** for a few weeks to prove the habit before spending anything. - **Your stops are long and rare,** such as a machine that runs a 6-hour cycle and stops twice a shift. - **You haven’t set ideal cycle times yet,** since performance means nothing without them on either method. Choose automatic tracking when: - **Short stops are frequent,** because no operator can write down 24 jams in a shift. - **You run more than one machine or shift,** and the numbers need to match from one to the next. - **You need the numbers during the shift,** while there is still time to recover the loss. Whichever you choose, fix the inputs first. A correct count, an honest ideal cycle time and a trusted shift schedule matter more to your OEE than the method that records the stops. ## Questions ### How long should I keep the paper log after switching to automatic tracking? Keep it for one week on the machines you switch first. The paper log is your reference for stop reasons and for the scrap count while operators learn the new entry, and the week gives you enough shifts to reconcile both records. Retire it once the reasons and scrap appear in the new system every shift. ### Do operators still enter anything once OEE tracking is automatic? Yes, two things. They give a reason to each stop no rule has classified, and they log scrap at the machine with its cause. Run state and part counts come from the machine, but no signal can tell a good part from a bad one or say why a machine was waiting. ### Should I restate last year’s OEE after switching to automatic tracking? No. Mark the date the capture method changed on every trend chart and treat the first full week of machine data as a new baseline. Old paper figures and new machine figures measure different things, so a drop at the switch date reflects the measurement, not the machine. ### Why did availability fall while output stayed the same? The machine record found stops the paper log never held: short stops, the minutes lost to rounding and the gaps at the start and end of the shift. Those minutes were already lost, so output does not change. They move from performance, where they hid as slow running, into availability. ## Sources 1. [OEE Calculation: Definitions, Formulas, and Examples](https://www.oee.com/calculating-oee/), Vorne Industries, accessed Oct 16, 2026 2. [OEE Six Big Losses](https://www.oee.com/oee-six-big-losses/), Vorne Industries, accessed Oct 16, 2026 3. [Analysis of Critical Factors for Automatic Measurement of OEE (Procedia CIRP 57, 2016)](https://research.chalmers.se/en/publication/246913), Chalmers University of Technology, accessed Oct 16, 2026 --- # Utilization, uptime, OEE, OOE and TEEP on one calendar Source: https://www.iotflows.com/blog/utilization-uptime-oee-teep/ OEE, OOE and TEEP divide the same good output by ever larger slices of the week. Work one week through all five metrics and see why shifts cap TEEP. > Question: How do utilization, uptime, OEE, OOE and TEEP fit together, and why is TEEP so far below OEE? ## Key takeaways - OEE, OOE and TEEP share one numerator, good parts at the ideal rate, and differ only in the time they divide by. - OEE divides by planned production time, OOE by staffed shift time and TEEP by every hour on the calendar. - TEEP equals OEE multiplied by loading, the share of the calendar you schedule, so the shift pattern sets its ceiling. - Uptime measured inside shifts becomes OEE availability once planned stops such as lunches leave the denominator. - Use OEE to improve a machine, OOE to price planned stops and TEEP to choose between a new shift and a new machine. Utilization, uptime, OEE, OOE and TEEP fit together as one stack of time. OEE, OOE and TEEP divide the same good output by a larger slice of the week each time, and uptime and utilization are the time-only ratios underneath them. TEEP sits far below OEE because it divides by all 168 hours of the calendar, so every hour with no shift counts as a loss. One machining center, one week and one set of counts carry all five metrics below. The worked numbers are for plant managers and engineers who see 30% on one report and 68% on another and need to know which number to act on. ## Five metrics, one stack of time Every hour of a week belongs to exactly one layer. Peel the layers off in order, and each metric is a ratio between two of them. | Time layer | What it holds | Removed at this step | |---|---|---| | Calendar time | Every hour, 24 × 7 = 168 h | Nothing | | Operating time | Staffed shift hours | Hours with no shift | | Planned production time | Operating time minus time scheduled off | Lunches, time scheduled off | | Run time | Planned production minus stops | Breakdowns, changeovers, waiting | | Fully productive time | Good count × ideal cycle time | Slow cycles and scrap | *Operating time* is the time a plant is staffed and intends to produce: your shifts. *Fully productive time* is the time the good parts would have taken at the ideal cycle time, so it carries every loss of speed and quality. OEE, OOE and TEEP all put fully productive time on top. Vorne’s shortest form of OEE is good count × ideal cycle time ÷ planned production time.[2] Ray Harkins, writing for Accendo Reliability, defines OOE and TEEP the same way against operating time and calendar time, and notes that TEEP ≤ OOE ≤ OEE as a matter of scope, not performance.[3] **OEE** = (Fully productive time) ÷ (Planned production time) **OOE** = (Fully productive time) ÷ (Operating time) **TEEP** = (Fully productive time) ÷ (Calendar time) > **Definition.** **TEEP (total effective equipment performance)** is the share of all calendar time a machine spends making good parts at its ideal cycle time: fully productive time divided by every hour in the period, equal to OEE multiplied by loading, the share of the calendar scheduled for production. > **Definition.** **OOE (overall operations effectiveness)** is the share of operating time, the hours a plant is staffed and intends to produce, that a machine spends making good parts at its ideal cycle time, with lunches and other time scheduled off inside a shift counted as losses that OEE leaves out. > **State your convention before you compare** > > None of these metrics has one universal definition. The ISO 22400 standard gives two versions of OEE that diverge from each other and from Nakajima’s original.[5] > > Vorne counts changeovers as stop time inside OEE,[2] while Harkins lists changeovers and preventive maintenance as planned downtime that OEE leaves out.[3] One published OOE variant even adds time that was scheduled and later removed for lack of orders.[4] The week below follows the common TPM convention that [planned vs unplanned downtime](/blog/planned-vs-unplanned-downtime/#availability) sets out: only lunches leave planned production time, and changeovers and in-shift planned maintenance count as stops, so they lower all three. ## Work one week through every metric Take one machine, one week and one set of counts, then compute every metric from them. #### Worked example: One week on a Haas VF-2 machining center - Calendar: 168 hours. - Shifts: two 8-hour shifts, Monday to Friday, so operating time is 80 hours. - Planned stops: a 30-minute lunch in each of the 10 shifts, so planned production time is 80 − 5 = 75 hours. - Stops: 15 hours of breakdowns, changeovers and waiting for material, so run time is 60 hours. - Ideal cycle time: 3 minutes. Parts made: 1,080, of which 1,026 were good the first time. Availability is 60 ÷ 75 = 80.0%. Performance is (1,080 × 3 min) ÷ 60 h = 54 h ÷ 60 h = 90.0%. Quality is 1,026 ÷ 1,080 = 95.0%. Fully productive time is 1,026 × 3 min = 3,078 min, or 51.3 hours. OEE is 51.3 ÷ 75 = 68.4%, which matches 0.80 × 0.90 × 0.95. OOE is 51.3 ÷ 80 = 64.1%. TEEP is 51.3 ÷ 168 = 30.5%. **Result:** OEE 68.4%, OOE 64.1% and TEEP 30.5%, all from the same 51.3 good hours Figure: Six bars shrink from 168 calendar hours to 80 shift hours, 75 planned, 60 run, 54 ideal and 51.3 hours of good parts. Dividing 51.3 hours by each base gives TEEP 30.5%, OOE 64.1% and OEE 68.4%. *One machining center’s week, layer by layer: the three metrics share a numerator and differ only in the base. Sample data.* For the factor-by-factor method behind these numbers, see [how to calculate OEE](/blog/how-to-calculate-oee/). The table puts every ratio from the week side by side. | Metric | Numerator | Denominator | Result | |---|---|---|---| | Uptime, lunches as stops | Running, 60 h | Running + stopped, 80 h | 75.0% | | Availability | Run time, 60 h | Planned production, 75 h | 80.0% | | OEE | Fully productive, 51.3 h | Planned production, 75 h | 68.4% | | OOE | Fully productive, 51.3 h | Operating time, 80 h | 64.1% | | Loading | Planned production, 75 h | Calendar, 168 h | 44.6% | | TEEP | Fully productive, 51.3 h | Calendar, 168 h | 30.5% | | Utilization, calendar | Running, 60 h | Calendar, 168 h | 35.7% | One machine, one week, one set of counts. Sample data. Seven figures run from 30.5% to 80.0%, and none of them is wrong. When two reports disagree, ask which base each one divides by before you ask which machine got worse. ## Why is TEEP so far below OEE? TEEP is OEE scaled by how much of the calendar you schedule. Vorne writes it as TEEP = OEE × utilization, where utilization is planned production time divided by all time.[1] Other references call the same term *loading*: the share of calendar time a machine is scheduled to operate.[4] **TEEP** = OEE × Loading **Loading** = (Planned production time) ÷ (Calendar time) In Vorne’s own example, a 65% OEE on two 8-hour shifts, five days a week, gives 80 of 168 hours, a utilization of 47.62% and a TEEP of 30.95%.[1] The machine runs well. The gap comes from the calendar. The VF-2 week shows the same thing in hours. Of the 168 hours, 51.3 made good parts, so 116.7 hours were lost. Here is where they went. | Loss | Hours | Share of lost hours | |---|---|---| | No shift scheduled | 88 | 75.4% | | Lunches | 5 | 4.3% | | Breakdowns, changeovers, waiting | 15 | 12.9% | | Slow cycles | 6 | 5.1% | | Scrap | 2.7 | 2.3% | | Total | 116.7 | 100.0% | Three quarters of TEEP’s gap is the shift pattern. No improvement project on the machine touches those 88 hours: only a schedule change does. The shift pattern also sets TEEP’s ceiling. Hold OEE at 68.4% and change only the schedule: | Shift pattern | Planned production time | Loading | TEEP at 68.4% OEE | |---|---|---|---| | 1 shift, 5 days | 37.5 h | 22.3% | 15.3% | | 2 shifts, 5 days | 75 h | 44.6% | 30.5% | | 3 shifts, 5 days | 112.5 h | 67.0% | 45.8% | | 3 shifts, 7 days | 157.5 h | 93.8% | 64.1% | Each 8-hour shift carries a 30-minute lunch. OEE is held at 68.4% in every row. Sample data. Figure: At a fixed 68.4% OEE, TEEP rises with the schedule: 15.3% on one shift five days, 30.5% on two shifts, 45.8% on three shifts five days and 64.1% on three shifts seven days. *The same machine at the same OEE: only the shift pattern moves TEEP. Sample data.* Two things follow from the table. On a 24/7 schedule, operating time equals calendar time, so TEEP and OOE become the same number. And even a perfect machine can’t pass loading: at 100% OEE, the 24/7 pattern with lunches tops out at 93.8% TEEP. A low TEEP is therefore not a failing grade. A plant that runs one shift by choice posts a low TEEP by design. Mike Lynch, writing in Modern Machine Shop, notes that some companies are satisfied with machines under 20% spindle run time, and that a CNC machine already meeting its required volume needs no improvement.[6] ## Where uptime and utilization fit Uptime and utilization are time-only ratios. They count hours running, with no part count, no ideal cycle time and no scrap. > **Definition.** **Uptime** is the share of measured shift time a machine spends running: running time divided by running plus stopped time inside your shifts, with any stretch that has no data left out of both terms. The IoTFlows glossary defines [uptime](/docs/get-started/glossary/#uptime) the same way. In the VF-2 week, uptime is 60 ÷ (60 + 20) = 75.0%, because the 5 hours of lunches count as stopped. Take the lunches out of the denominator and it reads 60 ÷ 75 = 80.0%, which is OEE availability. So uptime with lunches left in is the time share behind OOE, and uptime with lunches removed is the first factor of OEE. The difference between the two is a rule you set once: which stops come out because nobody meant to run the machine. Offline time needs the same rule. A calculation from the schedule treats an hour with no data as an hour stopped. A [measured uptime](/docs/monitoring/metrics-reference/#uptime) leaves that hour out of both running and stopped, so a dropped network link doesn’t read as a breakdown. *Utilization* is the word with the most meanings. | Where you see utilization | What it divides | Same as | |---|---|---| | TEEP formula | Planned production ÷ all time | Loading | | Shop-floor reports | Running ÷ running + stopped | Uptime | | Calendar-time reports | Running ÷ calendar time | Availability × loading | The third row checks out on the VF-2: 0.80 × 0.446 = 35.7%, the same as 60 ÷ 168. The [machine utilization guide](/blog/what-is-machine-utilization/) works one lathe through four denominators if you need the full set. Utilization is not an OEE factor. OEE multiplies availability, performance and quality. Utilization in the TEEP sense sits outside OEE, as the loading term that turns OEE into TEEP. ## Which metric answers which question? Each metric answers one question. Pick the question first. | Question | Metric | Why this one | |---|---|---| | Is the machine running this shift? | Uptime | Time only, live, no counts needed | | How well does it run when scheduled? | OEE | Breaks and empty hours are out | | What do lunches and planned work cost? | OOE | Planned stops inside shifts count | | How much of the week makes good parts? | TEEP | Every calendar hour counts | | Add a shift or buy a machine? | TEEP and loading | Shows the hours nobody scheduled | > **Which one goes on the daily report?** > > Track uptime first if you don’t yet know how often each machine runs, since it needs no part counts. Move to OEE once parts are counted against an ideal cycle time. You don’t need TEEP or OOE on a daily report: compute TEEP when you plan capacity or quote a large order, and OOE when you review break and maintenance policy. ## Use TEEP to choose a shift or a machine TEEP earns its place when demand outgrows the schedule. It shows how many hours are still unscheduled before you spend capital on another machine. #### Worked example: Demand rises to 1,500 good parts a week on the VF-2 The 3-minute ideal cycle gives an ideal rate of 20 parts an hour. Good parts a week = planned production time × OEE × 20. - Today, two shifts: 75 h × 0.684 × 20 = 1,026 good parts. - Raise OEE to 80% on two shifts: 75 h × 0.80 × 20 = 1,200 good parts, still 300 short. - Add a third shift at today’s OEE: 112.5 h × 0.684 × 20 = 1,539 good parts. TEEP rises to 45.8%. - Buy a second machine on two shifts: 150 h × 0.684 × 20 = 2,052 good parts. Each machine stays at 30.5% TEEP. **Result:** Two shifts reach 1,500 only at 100% OEE; a third shift makes 1,539 OEE work alone can’t close this gap, because 75 hours at the ideal rate is exactly 1,500 parts. The 88 unscheduled hours can. Vorne makes the general point that reclaiming time from the hidden factory is often a faster and less expensive alternative to buying equipment.[1] The [shift-or-machine guide](/blog/add-a-shift-or-buy-a-machine/) prices each option per extra good part. Add a shift when: - the machine is the constraint and you can staff the extra hours; - the extra volume fits in the hours a third shift adds. Buy a machine when: - you can’t staff another shift, or the premium for night hours costs more than the machine; - demand exceeds what even a 24/7 schedule could make at your OEE. A second machine also brings its own unscheduled hours. On two shifts it carries ownership cost through 88 idle hours a week, the same as the first, so price the [cost of idle machines](/blog/cost-of-idle-machines/) before you sign. ## Measure the layers inside your shifts IoTFlows puts a sensor on each machine that decides running or stopped every second, with no PLC connection. Your [shifts and time zone](/docs/admin/shifts-and-timezone/) bucket every number as it arrives, so they define operating time. Time the sensor was offline is reported as unknown and kept out of both uptime and downtime. Give lunches and other mandated breaks the None severity, then turn on **Exclude None** in the Advanced Report. Uptime then drops those stops from its denominator, as [what the number includes](/docs/monitoring/advanced-report/#switches) explains. Performance and quality report on their own, so you read OEE factor by factor. Storm Power Components doubled machine utilization and now schedules on real utilization data. Read the [Storm Power story](/customers/storm-power-components/), or see [machine utilization tracking](/solutions/machine-utilization/). ## Before you compare two of these numbers Run this list before a utilization, OEE or TEEP figure goes into a meeting or a capacity plan. - **Name the base** beside the figure: “68.4% OEE on 75 planned hours”, not “68.4%”. - **Check the numerator.** Uptime, utilization and loading count hours. OEE, OOE and TEEP count good parts at the ideal rate. - **Confirm the order.** For one machine and one period, TEEP ≤ OOE ≤ OEE. If it isn’t, the figures use different definitions. - **Write down where changeovers and planned maintenance sit,** and keep the rule the same across every trend. - **Keep offline hours out** of every layer, and fix the connection that caused them. - **Compare TEEP with loading,** not with OEE: loading is TEEP’s ceiling. - **Add hours before you divide** when you roll up shifts or machines: never average the percentages. ## Questions ### What is a good TEEP score? No benchmark holds across shift patterns, because TEEP can never exceed loading, the share of the calendar you schedule for production. Compare TEEP with that ceiling instead. A one-shift plant with 22.3% loading that posts 15% TEEP converts most of its scheduled time into good parts, and its remaining headroom sits in the hours it doesn’t schedule. ### Can OOE be higher than OEE? No. OOE divides the same good output by operating time, which holds planned production time plus the time inside shifts nobody meant to run the machine, such as lunches. The larger denominator keeps OOE at or below OEE, and TEEP at or below OOE. If a report shows OOE above OEE, the two figures came from different periods or different definitions. ### Is TEEP the same as machine utilization? No. TEEP multiplies OEE by loading, so it counts slow cycles and scrap as well as lost hours. Vorne calls the loading term utilization, planned production time divided by all time, which is why the words get mixed up. Machine utilization on a shop-floor report, such as the IoTFlows Advanced Report, is running time over running plus stopped time, with no speed or quality factor. ### Does planned maintenance lower TEEP? Yes, when it takes hours that could have made good parts. TEEP divides by every hour on the calendar, so planned and unplanned losses count the same. OEE counts maintenance during a scheduled run against availability, and leaves it out only when the machine is scheduled off for the window. OOE counts it whenever it falls inside a staffed shift. Maintenance done on a weekend with no shift lowers none of the three, because TEEP already counts those hours as lost. ## Sources 1. [TEEP: Calculate Total Effective Equipment Performance](https://www.oee.com/teep/), Vorne Industries (OEE.com), accessed Oct 16, 2026 2. [OEE Calculation: Definitions, Formulas, and Examples](https://www.oee.com/calculating-oee/), Vorne Industries (OEE.com), accessed Oct 16, 2026 3. [Defining TEEP, OOE, and OEE (Ray Harkins, adapted from Measuring Manufacturing Effectiveness)](https://accendoreliability.com/defining-teep-ooe-and-oee/), Accendo Reliability, accessed Oct 16, 2026 4. [Overall equipment effectiveness](https://en.wikipedia.org/wiki/Overall_equipment_effectiveness), Wikipedia, accessed Oct 16, 2026 5. [Overall Equipment Effectiveness: consistency of ISO standard with literature (Schiraldi and Varisco, Computers & Industrial Engineering 145, 106518, 2020)](https://art.torvergata.it/handle/2108/280082), University of Rome Tor Vergata institutional repository, accessed Oct 16, 2026 6. [Judging Acceptable Spindle Run Time](https://www.mmsonline.com/columns/judging-acceptable-spindle-run-time), Modern Machine Shop, accessed Oct 16, 2026 --- # Which OEE factor is costing you the most time? Source: https://www.iotflows.com/blog/which-oee-factor-loses-most/ Compare availability, performance and quality in lost minutes, check the inputs behind each factor, then weigh each loss by its cost to see where to look first. > Question: Where do I look first when OEE is low? ## Key takeaways - Compare OEE factors in lost minutes, because each factor’s percentage sits on a different base of time. - A point of availability costs more minutes than a point of performance, and a point of performance more than a point of quality. - Check the ideal cycle time, the short-stop cutoff and the scrap log before you trust which factor looks weakest. - Weigh each loss by its cost: scrap wastes material as well as time, and a minute matters most on the bottleneck. - Split the leading factor into its six big losses and work on the largest bucket first. When OEE (overall equipment effectiveness) is low, look first at the factor that loses the most minutes of planned production time, not the factor with the lowest percentage. Convert availability, performance and quality into lost minutes, check the inputs behind each one, then weigh the minutes by what they cost on that machine. The largest loss that survives those checks is where you start. One week on a CNC mill runs through every step below. If you need the formulas first, [How to calculate OEE](/blog/how-to-calculate-oee/) works one shift by hand. ## Why the lowest percentage misleads OEE multiplies three factors, and each one is a ratio of a different amount of time. *Availability* divides run time by planned production time. *Performance* divides the ideal time for the parts made by run time, and *quality* divides good parts by all parts.[1] *Ideal cycle time* is the best cycle the operation sustains in good conditions, timed at the machine rather than taken from a quote. Total count × ideal cycle time is the ideal time for the parts made: the least time they could have taken. Because the base shrinks from one factor to the next, a percentage point is worth less time at each step. A point of availability is 1% of planned production time. A point of performance is 1% of run time, and a point of quality is 1% of the ideal time for the parts made. > **Definition.** **OEE loss in minutes** is the planned production time a factor took away from good output at the ideal cycle time. The availability, performance and quality losses add up to planned production time minus good count × ideal cycle time. For example, a mill with 2,250 planned minutes, 1,800 run minutes and 1,400 ideal minutes of output loses 22.5 minutes per point of availability, 18 per point of performance and 14 per point of quality. The glossary entry for [performance](/docs/get-started/glossary/#performance) gives the second factor’s full definition. ## Convert each factor into lost minutes Each factor’s loss is the planned time it took away from good output. Three subtractions give the minutes. **Availability loss** = Planned production time − run time **Performance loss** = Run time − (total count × ideal cycle time) **Quality loss** = (Total count − good count) × ideal cycle time The three add up to planned production time minus good count × ideal cycle time. That is the gap the short form of OEE measures: good count × ideal cycle time ÷ planned production time.[1] #### Worked example: One week on a Haas VF-2 vertical mill - Five 8-hour day shifts with a 30-minute lunch each give 2,250 minutes of planned production time. - Stops total 450 minutes, so run time is 1,800 minutes. - Ideal cycle time is 2.5 minutes. Total count is 560 parts: 532 good and 28 scrapped. Availability is 1,800 ÷ 2,250 = 80.0%. Performance is (560 × 2.5) ÷ 1,800 = 77.8%. Quality is 532 ÷ 560 = 95.0%. Availability lost 2,250 − 1,800 = 450 minutes. Performance lost 1,800 − 1,400 = 400 minutes. Quality lost 28 × 2.5 = 70 minutes. **Result:** OEE = (532 × 2.5) ÷ 2,250 = 59.1%, with 920 minutes lost | Factor | Percentage | Base | Minutes lost | |---|---|---|---| | Availability | 80.0% | 2,250 planned min | 450 | | Performance | 77.8% | 1,800 run min | 400 | | Quality | 95.0% | 1,400 ideal min | 70 | | All three | 59.1% OEE | 2,250 planned min | 920 | Figure: Three bars of lost minutes for one week on a mill. Availability at 80.0% loses 450 minutes, performance at 77.8% loses 400 and quality at 95.0% loses 70. The lowest percentage is not the largest loss. *Performance has the lowest percentage, but availability loses 50 more minutes. Sample data.* A team that chases the lowest percentage starts on the smaller loss here. Minutes put all three factors on one scale, so you can rank them. ## Split the leading factors into their losses A factor tells you the kind of loss. The *six big losses* tell you the cause, and each one belongs to exactly one factor.[2] | Factor | Loss | What it looks like on a mill | |---|---|---| | Availability | Equipment failure | A broken tap, a spindle alarm | | Availability | Setup and adjustments | Changeovers, first-part checks | | Performance | Idling and minor stops | Chip clearing, door opens | | Performance | Reduced speed | Cycles slower than the ideal | | Quality | Process defects | Out-of-tolerance bores | | Quality | Reduced yield | Rejects while a new job settles | Loss names and factor mapping follow the six big losses of TPM. Minor stops last a minute or two and need no maintenance visit.[2] Where they land depends on the cutoff your plant sets for logging a stop: shorter stops stay inside run time and lower performance. The post on [micro-stops](/blog/micro-stops/#oee) shows how that cutoff moves minutes between availability and performance while OEE stays the same. Split the mill’s 920 minutes into buckets and rank them. You need a reason on each stop for availability, and a stop record that keeps short stops for performance. | Loss | Factor | Minutes | Where the number comes from | |---|---|---|---| | Reduced speed | Performance | 250 | 400 − 150 short-stop minutes | | Setup and adjustments | Availability | 210 | Four changeovers | | Idling and minor stops | Performance | 150 | 180 stops averaging 50 s | | Waiting for material | Availability | 120 | Two waits for bar stock | | Equipment failure | Availability | 80 | A broken tap, a spindle alarm | | Reduced yield | Quality | 45 | 18 startup rejects × 2.5 min | | Unclassified stops | Availability | 40 | Stops with no reason | | Process defects | Quality | 25 | 10 rejects × 2.5 min | Sample data. The six big losses count any unplanned stop, including material waits and stops with no reason, as equipment failure. Those stay separate here because each needs a different fix. The rows add up to 920 minutes. Reduced speed leads at 250 minutes, ahead of changeovers at 210. Before you start a speed project, check the number that produced it. To rank stop reasons over a longer window, build a [downtime Pareto](/blog/downtime-pareto/) on minutes, not counts. ## Check the inputs before you trust the result Every factor rests on a number someone entered or a record someone kept. A wrong input moves minutes into the wrong factor, or invents them. Performance depends on the [ideal cycle time](/blog/ideal-cycle-time/) more than on anything the machine does. Suppose the mill’s 2.5-minute ideal came from the job quote. Timing 20 consecutive good cycles gives 2.8 minutes as the best the process sustains. With 2.8 minutes, the 560 parts are worth 1,568 ideal minutes. Performance rises to 1,568 ÷ 1,800 = 87.1%, and its loss falls from 400 to 232 minutes. Of the 250 minutes booked as reduced speed, 168 were a gap between the quote and the machine, and 82 remain. Figure: Two bars of performance loss on the same week. With a 2.5-minute ideal from the quote, the loss is 400 minutes and performance 77.8%. With a timed 2.8-minute ideal, the loss is 232 minutes and performance 87.1%. *A quoted ideal cycle time put 168 minutes into performance that the machine never lost. Sample data.* Changeovers now lead at 210 minutes, so [measure changeover time](/blog/measure-changeover-time/) before you plan that project. OEE becomes (532 × 2.8) ÷ 2,250 = 66.2%. Quality’s loss grows to 28 × 2.8 = 78.4 minutes, because each scrapped part carries more ideal time. Keep 2.5 minutes only if a different program or tooling sustains it on this machine, since the ideal is the best cycle the operation sustains. Then the 168 minutes are a real performance loss with a known cause. Otherwise set the number from timed cycles, as the guide to [setting the ideal cycle time](/docs/production/cycle-times-and-filters/#ideal) describes. Measured cycles also test the times you plan with. Jesel, a valvetrain manufacturer, compares measured cycle times against the times in its bills of material every day, as its [customer story](/customers/jesel/) describes. | Factor | Input that misleads | Check | |---|---|---| | Availability | Breaks counted as stops | Remove breaks from planned time | | Availability | Sensor offline read as stopped | Look for gaps with no data | | Performance | Ideal cycle time from a quote | Time 20 good cycles | | Performance | Parts per cycle set wrong | Hand count 10 parts | | Quality | Rejects never logged | Compare the log with the scrap bin | | Quality | Rework counted as good | Count first-pass good parts only | Quality counts only parts that pass the first time, so a reworked part is a reject.[1] The guide to [first pass yield](/blog/first-pass-yield/#rework) explains why. A quality factor at 100% for weeks deserves a check against the scrap bin before anyone reads it as a result. Give each reject a reason when you [log scrap](/docs/production/log-scrap/), so quality minutes appear beside the stops. ## Rank the losses by what they cost A lost minute isn’t worth the same everywhere. Two things set its price: what the loss consumes besides machine time, and whether the machine limits the plant’s output. The *bottleneck* is the machine whose capacity limits what the whole line can ship. The Lean Enterprise Institute describes it as the weak link in the system, the one constraint that stops the next unit from being made with current resources.[3] A minute lost on the bottleneck is a minute of output lost for the line, while a minute lost on another machine is absorbed by its spare time. To prove which machine that is, see [how to find the bottleneck](/blog/find-the-bottleneck/#definition). #### Worked example: Pricing the mill’s week after the ideal cycle time check - The mill is the bottleneck of its cell. Each minute of it is worth $2.50 of contribution margin. - Each scrapped part also wastes a $40 blank of 4140 steel. Availability costs 450 × $2.50 = $1,125. Performance costs 232 × $2.50 = $580. Quality costs 78.4 × $2.50 + 28 × $40 = $196 + $1,120 = $1,316. **Result:** Quality costs the most, $1,316, with the fewest lost minutes Figure: Two panels for the same week. In lost minutes, availability leads with 450, then performance 232 and quality 78.4. In cost, quality leads at $1,316, then availability $1,125 and performance $580, because each reject also wastes a $40 blank. *Priced in dollars, quality moves from the smallest loss to the largest. Sample data.* Now suppose the mill has spare capacity and finishes the week’s work by Thursday. Its lost minutes cost little until demand rises, and the $1,120 of scrapped blanks is the only cash that leaves. The first project is the 18 startup rejects, and the stop and speed work moves to whichever machine is the bottleneck. > **Rank by minutes or by cost?** > > Rank by minutes when the machine is the bottleneck and each reject wastes little material. Rank by cost when a reject wastes material worth more than the machine time it took. When the machine has spare capacity, start with quality, and spend the stop and speed effort on the bottleneck. ## Read the pattern across shifts and machines One week on one machine gives you a ranking. The same ranking across shifts, part numbers and machines points at the cause before you walk to the floor. | Pattern | Likely cause | First check | |---|---|---| | Availability low on one shift | Slow starts and handovers | Stops in the first 30 min of the shift | | Availability low on changeover days | Setup length | Changeover minutes per job | | Performance low on one part number | That operation’s ideal cycle time | Time 20 cycles of that part | | Performance falls through the week | Tool wear or a slowing feed | Cycle time trend by day | | Performance low, few logged stops | Short stops under the cutoff | Count stops under 2 minutes | | Quality low after each changeover | Startup rejects | Scrap in the first hour of a job | | Quality at 100% for weeks | Rejects not logged | Logged scrap against the scrap bin | Each row compares the same factor across shifts, parts or days on one machine. Look at the factor before you look at the people. Low performance on one part number points at that operation’s cycle time on every shift that runs it, not at the operator who happened to run it last. ## See each factor on its own IoTFlows reports [OEE factor by factor](/solutions/oee-tracking/), so the weakest factor is on screen without a calculation. A SenseAi on each machine decides running or stopped every second and counts parts from the machine’s own signal, with no PLC connection. Each machine’s card shows Uptime, which is availability, and the parts gauge, which is performance against the ideal cycle time set on each operation. Quality reads on Shift Production as good parts over everything counted, from the scrap your team logs with a reason. The [metrics reference](/docs/monitoring/metrics-reference/#performance) defines each number. For a month or a quarter, sort the [Advanced Report](/docs/monitoring/advanced-report/#rows) by **Worst Performing** to put the machine with the lowest uptime at the top. Open that machine, and its **Downtime Classifications** card ranks its stop reasons by hours lost. ## Find your biggest loss this week 1. **Pick one machine and one week.** Choose the machine that limits output, or the one with the most scheduled hours. 2. **Convert each factor to minutes.** Subtract run time from planned time and ideal output from run time, then multiply rejects by the ideal cycle time. 3. **Check the inputs.** Compare the ideal cycle time with timed cycles, and the scrap log with the scrap bin. 4. **Split the losses into buckets.** Rank stop reasons, short stops, slow cycles and rejects by minutes. 5. **Price the top three losses.** Multiply minutes by what a minute of the machine earns, and add the material in each reject. 6. **Fix one loss and remeasure.** Work on the largest bucket, then compare next week’s minutes with this week’s. ## Questions ### Should I fix the OEE factor with the lowest percentage first? Not by default. Each factor is a percentage of a different base, so the lowest percentage can lose fewer minutes than a higher one. Convert each factor into lost minutes of planned production time, then weigh those minutes by what they cost on that machine, before you choose a project. ### Why does my quality factor read 100%? Quality reads 100% when no rejects were recorded, which is not the same as no rejects made. Compare the scrap logged over a week with what went into the scrap bin and the rework area. Count reworked parts as rejects, since OEE quality counts only parts that are good the first time. ### Do short stops count against availability or performance? It depends on the cutoff your plant sets for logging a stop. Stops shorter than the cutoff stay inside run time and lower performance, and longer stops lower availability. OEE is the same either way, but the cutoff decides which factor carries the loss, so keep it fixed when you compare weeks. ### Can improving one OEE factor lower another? Yes. Running a machine faster can raise performance and add scrap, and skipping a warm-up can raise availability and add startup rejects. Check all three factors and the total lost minutes after any change, so a gain in one factor is not paid for by a larger loss in another. ## Sources 1. [OEE Calculation: Definitions, Formulas, and Examples](https://www.oee.com/calculating-oee/), Vorne Industries, accessed Oct 16, 2026 2. [Six Big Losses in Manufacturing](https://www.oee.com/oee-six-big-losses/), Vorne Industries, accessed Oct 16, 2026 3. [What’s Your Company’s Bottleneck? (Brent Wahba, 2014)](https://www.lean.org/the-lean-post/articles/whats-your-companys-bottleneck/), Lean Enterprise Institute, accessed Oct 16, 2026 --- # How to find the bottleneck machine, with numbers Source: https://www.iotflows.com/blog/find-the-bottleneck/ The bottleneck is the machine with the least spare time for its load. Calculate load, check busy time and queues, and prove it with lost hours. Worked example. > Question: Which machine limits output, and how do I prove it? ## Key takeaways - The bottleneck is the machine whose busy hours come closest to, or past, its available hours for the work you give it. - Load is demand times measured cycle time, plus the machine’s own stops such as setups, divided by available hours. - The machine with the most downtime hours can be the one with the most spare time, because waiting counts as downtime. - Proof is in shipments: hours lost at the bottleneck cost output, while hours lost elsewhere are absorbed by spare time. - Recalculate load whenever the product mix changes, because a different mix can move the bottleneck to another machine. The machine that limits output is the one with the least spare time for the work you give it: its busy hours come closest to, or past, its available hours. You prove it in three steps. Calculate each machine’s load from demand and [measured cycle times](/blog/what-is-cycle-time/), confirm it is busy while its neighbors wait, and show that hours lost there, and only there, cost shipments. This guide is for plant managers and engineers in job shops and machining cells. It works one hypothetical four-machine cell through every step, from the load calculation to the week the bottleneck moves. ## What is a bottleneck? > **Definition.** **Bottleneck** is the resource whose capacity limits how much a whole line or plant can ship. An hour lost at the bottleneck is an hour of output lost for the plant, while an hour lost at any other machine is absorbed by that machine’s spare time. The Theory of Constraints starts every improvement here: identify the constraint before you change anything.[4] The rest of this guide is the identify step, done with numbers instead of opinions. The whole method rests on two measurements per machine: how many hours it ran, and why it stopped when it didn’t. The first is its [utilization](/docs/get-started/glossary/#utilization); the second is the reason on each stop. ### Why the obvious suspects mislead Three machines get blamed first, and each can be the wrong one. - **The machine with the most downtime.** A band saw that cuts a week’s blanks in 20 hours shows 55 stopped hours. It isn’t broken; it is waiting. A [downtime Pareto](/blog/downtime-pareto/) by machine ranks it first and points you away from the problem. - **The machine with the longest cycle time.** Cycle time leaves out setup, tool changes and repairs. For 600 parts, a lathe at 5.5 minutes with 12 hours of setups is busy 67 hours, while a mill at 6.0 minutes with 2 hours of setups is busy 62. - **The machine with the biggest pile in front of it.** A deburr station that runs in baskets of 120 always has a basket waiting. The pile measures its batch size, not its capacity. ## Calculate each machine’s load Load compares the hours a machine needs this week with the hours it has. Required hours include everything the machine does for its own reasons, not only cutting time. **Load** = ((Demand × cycle time) + own stops) ÷ (Available hours) *Own stops* are the stops a machine causes itself: setups, tool changes, breakdowns and adjustments. Waiting for material, an operator or a free spot downstream is not an own stop. Take cycle times and own stops from what the machine logged over recent weeks, never from the quote or the nameplate. Here *cycle time* is running minutes per part, because own stops are counted on their own; a [schedule load](/blog/production-scheduling-on-real-run-rates/#load) folds both into one effective cycle time instead. #### Worked example: One week in a four-machine bracket cell - Demand: 600 brackets a week, routed band saw, CNC lathe, CNC mill, deburr. - Available time: two 8-hour shifts with a 30-minute break each, five days. That is 2 × 450 × 5 = 4,500 minutes, or 75 hours per machine. - Measured per part: saw 2.0 minutes, lathe 5.5, mill 6.0, deburr 0.8. | Machine | Run hours | Own stops | Busy hours | Load | |---|---|---|---|---| | Band saw | 600 × 2.0 = 20 h | 2 + 1 = 3 h | 23 h | 30.7% | | CNC lathe | 600 × 5.5 = 55 h | 4 + 3 = 7 h | 62 h | 82.7% | | CNC mill | 600 × 6.0 = 60 h | 6 + 5 = 11 h | 71 h | 94.7% | | Deburr | 600 × 0.8 = 8 h | 0.5 + 0.5 = 1 h | 9 h | 12.0% | Own stops are setup hours plus tool changes, repairs and adjustments. Sample data. The mill has 75 − 71 = 4 spare hours. Its most output in a week is (75 − 11) × 60 ÷ 6.0 = 640 brackets. **Result:** The CNC mill is the bottleneck: 94.7% loaded, 4 spare hours, a ceiling of 640 brackets a week Figure: Busy hours against 75 available hours for four machines: band saw 30.7% with 52 hours spare, CNC lathe 82.7% with 13, CNC mill 94.7% with 4, deburr 12.0% with 66. The mill is highlighted. *The mill has the least spare time, so it sets the cell’s output. Sample data.* If demand rises to 700 brackets a week, the mill falls 60 short of its 640 ceiling, while the lathe could still make 741. Buying a second lathe would add nothing. ### Load and takt time are the same test *Takt time* is available production time divided by customer demand.[3] For the cell that is 4,500 ÷ 600 = 7.5 minutes a bracket. Divide each machine’s busy hours by demand and you get its busy minutes per part: the mill needs 71 × 60 ÷ 600 = 7.1 minutes. Load is that number over takt, 7.1 ÷ 7.5 = 94.7%. Use takt when you talk to a line team and load when you compare machines that make different parts. ## Confirm it with measured busy time The calculation says which machine should be the bottleneck. Measured time says which one is. > **Definition.** **Busy time** is the time a machine spends running plus the time it is stopped for its own reasons, such as setups, tool changes and repairs. Time a machine spends waiting for a part, an operator or room downstream is not busy time. Researchers at Toyota Central R&D Labs drew the same line: a machine is active when working, in repair, changing tools or being serviced, and inactive when it waits on another machine.[1] The bottleneck is the machine with the most busy time and the least waiting time. *Uptime* is the share of available hours a machine ran. A sensor reads running and stopped, so it sees a waiting machine as stopped. The [downtime reasons](/docs/monitoring/downtime-categories/) operators attach are what split a machine’s stopped hours into own stops and waiting. | Machine | Uptime | Own stops | Waiting | Busy | |---|---|---|---|---| | Band saw | 26.7% | 3 h | 52 h | 30.7% | | CNC lathe | 73.3% | 7 h | 13 h | 82.7% | | CNC mill | 80.0% | 11 h | 4 h | 94.7% | | Deburr | 10.7% | 1 h | 66 h | 12.0% | Uptime alone ranks these machines correctly here, but not always. A press that runs 50% of its shift and spends another 44% in its own setups and breakdowns has low uptime and 6% spare time. Close figures can’t separate two machines either. In one simulated seven-machine system, the confidence ranges of two machines’ utilization, 89% and 94%, overlapped, so utilization alone could not name the primary bottleneck.[1] Break the tie with the shift timeline. At any moment, the bottleneck is the machine with the longest uninterrupted busy stretch.[1] Measured that way, the 94% machine was the sole bottleneck 45.1% of the time and the 89% machine 1.2%.[1] ## Read the queue in front of each machine Work piles up in front of the bottleneck, because every machine upstream can make parts faster than it can take them. Measure the pile in days, not parts. **Time in queue** = (Parts waiting) ÷ (Parts processed per day) This is Little’s Law, L = λW, rearranged: work in process equals throughput times the time each unit spends in the system.[2] The cell ships 600 ÷ 5 = 120 brackets a day. | Queue | Parts waiting | Days of work | |---|---|---| | Before the lathe | 60 | 60 ÷ 120 = 0.5 | | Before the mill | 240 | 240 ÷ 120 = 2.0 | | Before deburr | 120 | 120 ÷ 120 = 1.0 | The mill’s two days of queue agree with its load. The deburr basket doesn’t: it waits a day because the station runs in batches of 120, not because it is short of hours. > **When the queue lies** > > A queue is a hint, not proof. It misreads machines with no room for a queue, plants where every queue is already full, and stations that run different batch sizes.[1] Check the queue against load and busy time before you act on it. ## Prove it: hours lost there cost shipments The test that settles an argument is what happens to shipments when a machine loses time. A machine absorbs lost hours up to its spare hours. Past that, output falls. #### Worked example: A 6-hour breakdown on two machines - The mill makes 60 ÷ 6.0 = 10 brackets an hour and has 4 spare hours a week. - The lathe has 13 spare hours, and the mill has 240 brackets, 24 hours of work, queued in front of it. A 6-hour mill breakdown uses its 4 spare hours and costs 2 more. That is 2 × 10 = 20 brackets the cell doesn’t ship this week, without overtime. A 6-hour lathe breakdown fits inside its 13 spare hours. The mill keeps cutting from its queue, and the lathe catches up later in the week. **Result:** A mill hour past its spare time costs 10 brackets; a lathe hour costs nothing until its 13 spare hours are gone Run the same test on your history: 1. **Pick four to six weeks.** Use weeks with the same shift pattern and a similar product mix, so the weeks compare. 2. **List the long stops on each candidate.** Take every own stop over an hour on the two or three machines with the highest load. 3. **Line them up with shipments.** Set each week’s good output beside those stops, machine by machine. 4. **Find the machine output follows.** The bottleneck is the machine whose lost hours past its spare time match the weeks output fell. Stops on other machines line up with nothing. The forward version is faster: run only the candidate through its breaks for a week, and measure output the same way. If it is the bottleneck and demand exceeds its ceiling, weekly output rises by its parts per hour times the hours added. For the mill, two 30-minute breaks a day for five days add 5 hours, or 50 brackets. ## When the bottleneck moves The bottleneck belongs to a mix, not to a machine. Change what the cell makes and the load moves with it. #### Worked example: Half the week switches to part B - Part B needs 9.0 minutes on the lathe and 3.0 on the mill. Setups and own stops stay the same. - Week 2 makes 300 of part A and 300 of part B. Lathe: (300 × 5.5 + 300 × 9.0) ÷ 60 = 72.5 run hours, plus 7, is 79.5 hours. Mill: (300 × 6.0 + 300 × 3.0) ÷ 60 = 45 run hours, plus 11, is 56 hours. **Result:** The lathe is now 106.0% loaded and the mill 74.7%: the lathe is 4.5 hours, or 30 of part B, short Figure: In week 1 with 600 of part A, the CNC lathe is 82.7% loaded and the CNC mill 94.7%. In week 2 with 300 each of parts A and B, the lathe is 106.0% loaded and the mill 74.7%. *A different mix moves the bottleneck from the mill to the lathe. Sample data.* The bottleneck also shifts from moment to moment, as stops come and go. In a simulated four-machine line where one machine ran at 88% and the others at 80%, the busiest machine was the sole bottleneck 32.5% of the time and part of a shifting bottleneck another 29.3%.[1] The first machine in the line, at 80%, was a sole or shifting bottleneck 33.1% of the time, so a secondary bottleneck matters too. So recalculate load each time you release a week of work, and read the measured busy time weekly. A bottleneck that moves every few days is a scheduling question: plan the mix so no machine is loaded past its available hours. ## Find the bottleneck from machine data IoTFlows puts a SenseAi sensor on each machine that decides running or stopped every second from vibration and sound, with no PLC connection. That gives every machine the same clock, whatever its brand or age. The [Advanced Report](/docs/monitoring/advanced-report/#rows) lists each machine’s uptime and downtime hours over any period, sorted Top Performing, so the machines that ran most sit at the top. The Downtimes report’s [Downtimes by Asset](/docs/monitoring/downtimes/#trends) chart splits each machine’s stopped hours by reason, which separates its own stops from waiting. On a packaging line, a BeamTracker at each machine shows which one [stopped the line first](/blog/how-to-monitor-a-packaging-line/#first-stop). See [machine utilization tracking](/solutions/machine-utilization/). ## What to do once you’ve found it The Theory of Constraints orders the work in five steps: identify the constraint, exploit it, subordinate everything else to it, elevate it, and prevent inertia from becoming the constraint.[4] Spend the cheap steps before the expensive one. | Step | What it means at the mill | Cost | |---|---|---| | Exploit | Run it through breaks and shift changes | Labor only | | Exploit | Keep a queue in front so it never waits | Some work in process | | Exploit | Inspect parts before the mill, not after | None | | Exploit | Preset tools and stage setups offline | Fixtures and tooling | | Subordinate | Release work at the mill’s pace | None | | Elevate | Overtime, outsourcing, a second mill | Capital or premium | Each hour you recover at the mill is worth 10 brackets while demand exceeds its ceiling. An hour recovered at the saw is worth nothing until the saw becomes the constraint. Value the bottleneck’s hours with the [cost of downtime](/blog/cost-of-downtime/) method, using the output the plant loses, not the machine’s rate. Setup is the mill’s largest own stop, 6 of its 71 busy hours. [Measure changeover time](/blog/measure-changeover-time/) at the bottleneck first. > **Where to aim utilization goals** > > Push for high utilization only at the bottleneck. Choose a lower, steady goal for every other machine, because running the saw and lathe harder only builds a bigger queue in front of the mill and ships nothing extra. Set each goal from the machine’s role and its [own baseline](/blog/utilization-goals-by-machine-type/). You probably don’t need a new machine if the bottleneck still loses hours to waiting, breaks or long setups. [Buy capacity](/blog/add-a-shift-or-buy-a-machine/) when its busy time sits near 100% after those fixes and demand still exceeds its ceiling. ## Questions ### Can a machine with low uptime be the bottleneck? Yes. A press that runs 50% of its shift and spends another 44% in its own setups and breakdowns is busy 94% of the time and has almost no spare hours. Uptime counts only running time, so add the machine’s own stops back in before you compare it with its neighbors. ### What is the difference between a bottleneck and a constraint? A constraint is anything that limits how much a plant ships, such as a machine, a skill, material supply, or customer orders. A bottleneck is a constraint that is a resource inside the plant, most often one machine or one cell. When every machine has spare hours and work still ships late, the constraint is outside the machines. ### Should every machine run at high utilization? No. Only the bottleneck needs to run every available hour. A machine upstream of it that runs faster than the bottleneck only builds work in process in front of it, which lengthens lead time without shipping a single extra part. Set utilization goals by role, not one goal for the whole floor. ### How often should I check which machine is the bottleneck? Recalculate load each time you release a week of work, and whenever the product mix, a cycle time or the shift pattern changes. Read measured busy hours and queues weekly. A bottleneck that moves every few days points at the mix and the schedule rather than at any one machine. ## Sources 1. [Shifting Bottleneck Detection, Proceedings of the 2002 Winter Simulation Conference](https://www.informs-sim.org/wsc02papers/145.pdf), Christoph Roser, Masaru Nakano and Minoru Tanaka, Toyota Central R&D Labs; Winter Simulation Conference, accessed Oct 16, 2026 2. [OR Forum: Little’s Law as Viewed on Its 50th Anniversary, Operations Research 59(3), 536–549](https://ideas.repec.org/a/inm/oropre/v59y2011i3p536-549.html), John D. C. Little, INFORMS (record on RePEc IDEAS), accessed Oct 16, 2026 3. [Takt Time](https://www.lean.org/lexicon-terms/takt-time/), Lean Enterprise Institute, accessed Oct 16, 2026 4. [The Five Focusing Steps (POOGI)](https://www.tocinstitute.org/five-focusing-steps.html), TOC Institute, accessed Oct 16, 2026 --- # Why reworked parts don’t count in first pass yield Source: https://www.iotflows.com/blog/first-pass-yield/ Reworked parts aren’t good parts in first pass yield or OEE quality. Work FPY, final yield and scrap rate on one batch, and see why quality and scrap disagree. > Question: Should reworked parts count as good, and why does my OEE quality not match my scrap rate? ## Key takeaways - Reworked parts are not good parts in first pass yield or in OEE quality, even when they ship. - First pass yield, rework rate and scrap rate add up to 100% when all three divide by units started. - OEE quality reads below 100% minus the scrap rate whenever parts are reworked, because quality also loses every reworked part. - Rolled throughput yield multiplies the step yields, so three steps near 95% deliver about 87% of parts untouched. - Count each part once, log every reject with a reason and a disposition, and write down every denominator. Reworked parts should not count as good. In first pass yield and in OEE quality, a part is good only if it passed every check the first time, so a part that needed rework is a loss even after it ships. That is also why OEE quality reads lower than 100% minus your scrap rate: the scrap rate counts only the parts you threw away, and quality also loses every part that took a second pass. This guide is for engineers who report yield and plant managers who have to explain why two reports disagree. It works one batch through every yield figure, the same week through OEE both ways, and a three-step line. ## What is first pass yield? > **Definition.** **First pass yield (FPY)** is the share of units that pass a process step, or a whole process, the first time, with no rework, repair or retest: units good the first time divided by units started. The IoTFlows glossary entry for [first pass yield](/docs/get-started/glossary/#fpy) applies the same idea down a line of machines, comparing each step’s count with the first step’s. Either way, the numerator should hold only parts that never left the normal path. > **Definition.** **Final yield** is the share of units started that end up good after every repair, rework and re-inspection: units passed as good at the end, however many tries they took, divided by units started. Three ratios describe one batch. Each has the same denominator here: **First pass yield** = (Units good the first time) ÷ (Units started) **Final yield** = (Units good after rework) ÷ (Units started) **Scrap rate** = (Units scrapped) ÷ (Units started) Write the denominator down. Some plants divide scrap by units produced, some by good units and some by units started, and each gives a different number for the same batch. This article uses units started for every ratio, so the figures add up. ## Work one batch through every yield Take a week of one part on one machine and sort every part by what happened to it at inspection. #### Worked example: One week of a hydraulic fitting on a CNC lathe - 1,000 fittings machined and sent to inspection. - 920 pass the first time. - 80 fail. 50 are reworked at the deburr bench, re-inspected and pass. 30 are scrapped. FPY is 920 ÷ 1,000 = 92.0%. Final yield is (920 + 50) ÷ 1,000 = 97.0%. Scrap rate is 30 ÷ 1,000 = 3.0%, and rework rate is 50 ÷ 1,000 = 5.0%. **Result:** FPY 92.0% = 100% − 3.0% scrap − 5.0% rework Figure: A bar of 1,000 fittings splits into 920 passed first time, 50 reworked then passed and 30 scrapped. Brackets beneath mark first pass yield at 92.0%, final yield at 97.0% and scrap rate at 3.0%. *One batch, three yields: the 5 points between first pass yield and final yield are the rework. Sample data.* Each figure answers a different question about the same 1,000 parts: | Metric | Counts as a loss | Fitting batch | Answers | |---|---|---|---| | First pass yield | Scrap and rework | 92.0% | How well does the process run? | | Final yield | Scrap only | 97.0% | How many parts can we ship? | | Scrap rate | Scrap only | 3.0% | How much material is lost? | | Rework rate | Rework only | 5.0% | How much work is done twice? | All four divide by units started. FPY, rework rate and scrap rate add up to 100%. The 5-point gap between FPY and final yield is the rework. Final yield never shows it, and neither does a scrap report. ## Why reworked parts don’t count as good OEE counts good parts from the first pass. Vorne’s OEE reference defines good parts as parts that pass through the manufacturing process the first time without needing rework.[1] NIST’s guide to collecting manufacturing data lists OEE’s quality factor as the first pass yield rate.[3] The same rule covers both quality losses among the six big losses. Process defects in stable production and reduced yield from startup to stable production each include parts that can be reworked as well as parts that are scrapped.[2] The rule holds outside OEE too, for three reasons: - **Rework spends capacity.** A reworked fitting used its machine cycle, then bench time, then a second inspection. For example, 50 reworks at 8 minutes each is 400 minutes, about 6.7 hours of labor that final yield records as nothing. - **Rework hides the cause.** A step that makes 5% rework and no scrap looks clean in a scrap report, and the defect keeps coming. - **Rework adds handling.** A repaired part is moved, measured and logged again, and each touch is a chance to damage it or mix it into the wrong lot. Rolled throughput yield takes the same view: it screens out any unit that fails once along the way, even if it is fixed later.[4] Final yield still has a job, which the [decision table](#choose) at the end covers. ## Why OEE quality doesn’t match your scrap rate With a 3.0% scrap rate, you might expect OEE quality of 97.0%, but on the fitting batch quality is 92.0%. The 5 points are the rework. Rework and five other causes split the two numbers: | Cause | What happens | Fix | |---|---|---| | Rework | Quality loses it, scrap rate doesn’t | Report rework rate beside scrap | | Denominator | Scrap ÷ started, ÷ made or ÷ good | Use one denominator, in writing | | Timing | Scrap is logged at the end of the week | Log rejects when you find them | | Scope | Downstream scrap is booked to the line | Log the step that made the defect | | Startup rejects | Left out of the scrap report | Count them in both numbers | | Units | Scrap in pounds, output in parts | Convert with the part weight | The rework gap moves OEE by the same proportion as it moves quality, because OEE multiplies the three factors. The [OEE calculation guide](/blog/how-to-calculate-oee/) works each factor in full. #### Worked example: The same week on the lathe, quality counted two ways - Availability is 90.0% and performance is 85.0%. - Quality from first pass yield is 92.0%. Quality from final yield is 97.0%. OEE with first pass quality is 0.900 × 0.850 × 0.920 = 70.4%. OEE with final yield as quality is 0.900 × 0.850 × 0.970 = 74.2%. **Result:** Counting rework as good adds 3.8 points of OEE Figure: Two OEE bars for the same week on the lathe. With quality from first pass yield at 92.0%, OEE is 70.4%. With quality from final yield at 97.0%, OEE is 74.2%, and the extra 3.8 points are highlighted as rework counted as good. *Same week, same parts: counting reworked parts as good lifts OEE by 3.8 points. Sample data.* Quality in the IoTFlows glossary is the [share of parts made that were good](/docs/get-started/glossary/#quality), and a quality figure means the same thing across machines only when every machine uses first-pass good parts. > **Count a reworked part only once** > > When a reworked part runs through the machine again, the machine counts a second cycle but no new part. Keep the total count at one per part, on its first pass, and log the rework cycle on its own. Otherwise the total grows and quality reads as if the batch were bigger than it was. ## Yield across a line of steps When a part passes through several steps, each step has its own FPY, and the line’s first pass yield is their product. *Rolled throughput yield* (RTY) is the probability that a unit makes it through the entire process without a single defect.[4] **Rolled throughput yield** = FPY step 1 × FPY step 2 × FPY step 3 #### Worked example: 5,000 fittings through three steps - OP10, turn: 5,000 start and 4,800 pass the first time, so FPY is 96.0%. - OP20, mill: 4,800 start and 4,560 pass, so FPY is 95.0%. - OP30, inspect: 4,560 start and 4,332 pass, so FPY is 95.0%. The average step FPY is 95.3%. RTY is 0.960 × 0.950 × 0.950 = 86.6%, and 4,332 ÷ 5,000 gives the same 86.6%. **Result:** RTY 86.6%: 668 of 5,000 fittings left the normal path at least once Figure: Three steps in a row: OP10 turn at 96.0% first pass yield, OP20 mill at 95.0% and OP30 inspect at 95.0%. The average step yield is 95.3%, but rolled throughput yield is 86.6%, with 4,332 of 5,000 parts passing every step the first time. *Every step looks close to 95%, and the line delivers 86.6% of its parts untouched. Sample data.* The loss compounds quickly. iSixSigma’s example of four steps, each with a 15% first-pass failure rate, gives an RTY of 52.2%: about half the units reach the end without a defect.[4] Start with the one or two steps with the lowest FPY, where iSixSigma places the largest opportunity to raise RTY.[4] [A counter after every step](/blog/production-line-monitoring-without-plcs/#every-step) measures this directly, with no multiplication: the count after the last step divided by the count entering the first. That works when rejected parts leave the line at the step that caught them, as on a bottling line where each machine ejects its own rejects. See [how to monitor a packaging line](/blog/how-to-monitor-a-packaging-line/) for where to put the counters. Return reworked parts after the last counter, or log them apart, so a repaired part never reads as a first pass. ## Log scrap and rework so the numbers agree Most yield disputes are logging problems, not math problems. These five habits make FPY, final yield, scrap rate and OEE quality reconcile: 1. **Count every part once, at the machine.** Take the total count from the machine’s own cycle, not from a tally sheet. Check a new count against a hand count of 10 parts, and if it reads double or half, look for a parts-per-cycle setting before blaming the counter. See [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/). 2. **Log every reject when you find it.** Record the reject against the job and the step that made the defect, with a reason, during the shift. A reason list works best short, with one cause per code, the same rules that make [downtime reason codes](/blog/downtime-reason-codes/) useful. 3. **Record the disposition.** Mark each reject as scrap or rework. Without the disposition, you can calculate scrap rate or FPY, but not both. 4. **Keep rework cycles out of the total.** Log a rework pass as rework, not as a new part, so the total count stays one per part. 5. **Report the yields side by side.** Show FPY, final yield and scrap rate in one table, each with its denominator. A reader who sees all three never has to ask why they differ. ## Measure yield at every step IoTFlows counts every part at every step of a line, with a BeamTracker on each step and no PLC connection. Grouped into a cascade, each step after Step 1 reports FPY as its count over Step 1’s count, with the parts lost and the rate difference beneath it, live during the shift. See [FPY across a cascade](/docs/monitoring/asset-groups/#fpy). Quality reads as good parts over everything counted, from the [scrap operators log](/docs/production/log-scrap/) with a reason against the job. Altium Packaging reads first pass yield, bottles lost and rate difference on every step of its ten bottling lines this way. See [production monitoring](/solutions/production-monitoring/). > Now we can talk through issues, help our operators and adjust operations in real time. > > Steve Petti, Plant Manager, Altium Packaging ([story](https://www.iotflows.com/customers/altium-packaging/)) ## Which yield to report Each yield answers one question. Pick the one that matches the decision in front of you: | Yield | Use it for | Don’t use it for | |---|---|---| | First pass yield | Improving a step; OEE quality | Planning material | | Final yield | Material and shipment planning | OEE or process improvement | | Scrap rate | Costing lost material | Judging a step that reworks | | Rolled throughput yield | Comparing whole lines | Finding the failing step alone | Default to FPY in any report about how the process runs, and put final yield beside it when the same report plans shipments. Use RTY when a part passes through two or more steps. You don’t need RTY for a single-machine cell: there it equals FPY. When your OEE quality and your scrap rate disagree, check the gap against your rework rate first. If rework explains it, both numbers are right, and the report needs a third row. ## Questions ### Is first pass yield the same as OEE quality? Close, with a difference in scope. OEE quality is the good count over the total count for one machine or line, where good means right the first time, so it is first pass yield measured at that machine. A plant-level first pass yield can also include steps OEE never sees, such as final inspection or a customer test. With the same counts and the same rule for good, the two match. ### Do startup rejects count against first pass yield? Yes. Parts made between a startup or changeover and stable production are a quality loss in OEE, whether you scrap them or rework them. Leaving them out of the count raises quality and hides what each changeover costs. Log them under their own reason so you can see them apart from the rejects made in stable running. ### Should a part that fails a test and passes a retest count as good? Not for first pass yield. A retest pass with no repair still means the first check failed. Count it as a first-pass failure and log retest passes under their own reason. A high retest pass rate often points at the gauge or the test method rather than the process, which is worth knowing before anyone adjusts the machine. ### What is a good first pass yield? No single benchmark is worth chasing, because first pass yield depends on how strict each inspection is and how many steps it covers. Compare each step with its own history and with what your customer requires, and watch the trend. A step whose first pass yield falls week over week needs attention, whatever the absolute number. ## Sources 1. [OEE Calculation: Definitions, Formulas, and Examples](https://www.oee.com/calculating-oee/), Vorne Industries (OEE.com), accessed Oct 16, 2026 2. [Six Big Losses in Manufacturing](https://www.oee.com/oee-six-big-losses/), Vorne Industries (OEE.com), accessed Oct 16, 2026 3. [NIST AMS 300-11: Recommendations for Collecting, Curating, and Re-Using Manufacturing Data (Helu and Hedberg, 2020)](https://nvlpubs.nist.gov/nistpubs/ams/NIST.AMS.300-11.pdf), National Institute of Standards and Technology, accessed Oct 16, 2026 4. [Rolled Throughput Yield (RTY): Make Sure Your Production Is Making the Grade](https://www.isixsigma.com/dictionary/rolled-throughput-yield-rty/), iSixSigma, accessed Oct 16, 2026 --- # How to monitor a packaging line and count every unit Source: https://www.iotflows.com/blog/how-to-monitor-a-packaging-line/ Count output after the last reject, take the ideal rate from the slowest machine, and find which filler, capper or labeler stopped first. With a worked shift. > Question: How do I count output and find stops across fillers, cappers, labelers and case packers? ## Key takeaways - Count a packaging line’s output once, after the last reject point, where units run single file and pass the beam once. - A line never runs faster than its slowest machine, so take the ideal rate from that machine’s rated speed for the container. - Buffers between machines absorb short stops, so a counter at the end of the line misses stops that a counter at each machine sees. - When a line stops, the machine whose count stopped first is the cause; the others are waiting on it. - Classify a line stop once, on the machine that caused it, so one jam does not appear four times in the Pareto. You count a packaging line’s output with one counter after the last reject point, and you find its stops by counting at each machine and reading which count stopped first. Take the line’s ideal rate from its slowest machine, and give every stop a reason on the machine that caused it, so one jam reads as one stop, not four. This guide is for plant managers running filling, bottling, bagging and case-packing lines. It works one hypothetical 500 mL water line through, from the count point to one shift’s numbers. ## What to monitor on a packaging line > **Definition.** **Packaging line monitoring** means recording, for a line of connected machines such as a filler, capper, labeler and case packer, how many good units leave the line, how fast they leave, when each machine stops and why, so losses are traced to the machine that caused them. Five numbers answer most of what a line review asks. Each comes from a different place, so decide where each one is measured before you mount anything. | Number | Question it answers | Where it is measured | |---|---|---| | Good count | How much did the line ship? | One point after the last reject | | Rate | How fast is it running now? | The same point, in units a minute | | Stops | When and how long did it stand? | Each machine, or the discharge | | Stop reason | Why did it stop? | The operator, on the causing machine | | Rejects | How many units were thrown out? | Each reject or divert station | Downtime is the number [OEE tools](/blog/top-oee-monitoring-tools-for-manufacturing/) are built around. In a PMMI survey of 35 suppliers, run from May 2025 to June 2026, downtime was the most commonly tracked [KPI](/blog/manufacturing-kpis/) in respondents’ current OEE offerings, at 93.8%.[3] A sample of 35 is a signal, not a census. ## Where to count the line’s output Count once, at a point where every good unit passes and nothing else does. On a packaging line that point is after the last reject or divert station, so the number is what the line produced, not what it attempted. Three rules pick the exact spot: - **Single file.** A beam across a conveyor two units wide counts neither lane reliably. - **Off the accumulation table.** A bottle that backs up, drifts forward and backs up again crosses the beam more than once. - **On an opaque feature.** Clear PET and glass may not break a beam. Aim at the closure, the label band or the filled body, or count cases downstream instead. The [count point checklist](/docs/production/packaging-lines/#count-point) covers mounting distance, brackets and wash-down. When you count cases, one beam break is a case, so a 24-count case counts as 24 units. The setting that carries that multiplier is the [quantity per cycle](/docs/production/parts-and-operations/#units). Count rejects separately from good units. *PackML* (Packaging Machine Language) is a standard set of machine states and data tags for packaging machines. It counts the same way: its `ProdProcessedCount` includes good and defective products, and `ProdDefectiveCount` holds the defective ones.[1] Good count over processed count is the line’s quality. ## Why the slowest machine sets the line rate Units leave a line no faster than its slowest machine can handle them. A labeler rated at 300 bottles a minute, fed by a filler rated at 200 and followed by a case packer that handles 150, runs at 150. Figure: Rated speeds on a 500 mL water line: filler 200, capper 220, labeler 300 and case packer 150 bottles a minute. A dashed line at 150 per minute marks the line rate, set by the case packer. *The case packer is the slowest machine, so the line runs at 150 bottles a minute. Sample data.* The faster machines are not wasted. After a stop, the extra speed is what lets the filler and capper refill the buffers between machines. A line where every machine is rated at the same speed can never refill a buffer that a stop drained. Express the rate the way the line is quoted. PackML expresses a machine’s speed setpoint in primary packages per minute.[1] A gauge that reads 150 bottles a minute can be checked against the rating plate; a cycle time of 0.4 seconds cannot. ### Set the ideal rate from the constraint OEE [performance](/docs/get-started/glossary/#performance) compares what the line made with what its ideal rate allows. On a line, the ideal rate is the slowest machine’s rated speed for the container you are running. > **Don’t use the labeler’s nameplate** > > Using the fastest machine’s rating as the ideal halves performance on the water line, because 300 a minute was never possible. Using last month’s average hides the loss you want to find. Use the slowest machine’s rated speed, and re-enter it when the container changes. The ideal rate sets the performance figure. The goal you hold the line to is a separate number: set it from the line’s own baseline, as the [OEE goals guide](/docs/monitoring/oee-goals/) describes. ## How buffers hide short stops > **Definition.** **Accumulation (buffer)** is the conveyor length or table between two packaging machines that holds units, so a short stop at one machine does not stop its neighbors until the buffer fills or runs empty. Buffers change what a stop looks like from each point on the line. A jam at the capper stops the capper at once. The filler keeps filling until the conveyor in front of the capper is full. The labeler and case packer keep running until the bottles between them and the capper run out. #### Worked example: A 120-second capper jam on the water line - The line runs at 150 bottles a minute, 2.5 bottles a second. - The conveyor between filler and capper has room for 50 more bottles. The accumulation between capper and labeler holds 90. The conveyor between labeler and case packer holds 60. - The capper jams at 0 seconds and restarts at 120 seconds. - Transit time between machines is left out of the arithmetic. The filler fills its 50 spaces in 50 ÷ 2.5 = 20 seconds, then stops. The labeler empties 90 bottles in 90 ÷ 2.5 = 36 seconds, then stops. The case packer empties its 60 bottles in another 24 seconds, so it stops at 60 seconds. **Result:** The case packer stands 60 seconds, so the line loses 60 × 2.5 = 150 bottles, not 300 Figure: Four timelines over 150 seconds. The capper stops at 0 s, the filler at 20 s, the labeler at 36 s and the case packer at 60 s. All four run again at 120 s. *One capper jam stops four machines at four different times, and the earliest stop is the cause. Sample data.* Two lessons follow. A stop costs line output only when it reaches the slowest machine, here the case packer. And a counter at the discharge sees the jam 60 seconds late and 60 seconds short. Shorter jams vanish entirely. A capper jam under 36 seconds never stops the labeler, and the filler and capper refill the accumulation afterward, because both run faster than 150. Those stops cost nothing while the buffers hold. When they repeat 40 times a shift, they show up as a rate below ideal rather than as downtime. The [micro-stops guide](/blog/micro-stops/) covers where those losses land in OEE. Set the end-of-line counter’s downtime filter past the longest normal gap between units, such as the pause while a case packer indexes. The [downtime filter settings](/docs/hardware/calibrate-beamtracker/#downtime-filter) start fast continuous lines at 15 to 45 seconds. ## Find which machine stopped the line When every machine on the line reads stopped, only one of them caused it. Put a counter at each machine, date each stop to the last unit that machine counted, and sort. The earliest stop is the machine to walk to. In the capper example, the sort reads capper at 0 seconds, filler at 20, labeler at 36 and case packer at 60. The case packer operator sees only that the case packer stopped. The timestamps send the technician to the capper. PackML names the difference. A machine is *Held* when it pauses for a condition internal to it, such as low material or an operator service. It is *Suspended* when it pauses for a condition external to it, such as a fault upstream or downstream.[1] In the example, the jam is internal to the capper. The filler, labeler and case packer are all Suspended, waiting on it. > **One counter or one per machine?** > > Start with one counter after the last reject when you need the line’s output, rate and uptime and you run several lines. Add a counter at each machine when line stops are frequent and nobody agrees which machine causes them, or when you need the units lost at each step. You don’t need a counter on every machine of a line that rarely stops. The [first-stop method in the line monitoring guide](/blog/production-line-monitoring-without-plcs/#first-stop) works the same sort on a four-step bagging line. ## Give packaging stops a reason A stop length says how much time a line lost. A reason says what to fix. Packaging stops repeat, so a short list covers most of them. | Reason | Where it starts | Who acts on it | |---|---|---| | Bottle jam | Conveyors, starwheels, guides | Line operator | | Cap feed | Capper, cap sorter | Line operator | | Label roll change | Labeler | Line operator | | Film splice | Shrink wrapper, bagger | Line operator | | Changeover | The whole line | Setup lead | | Waiting on bottles | Upstream supply | Materials | | Mechanical fault | Any machine | Maintenance | | Quality hold | Any machine | Quality | A starting list for a filling and packing line. Add a code only when the same reason keeps landing in other. Classify each line stop once, on the machine that caused it. If all four machines in the capper example log “cap feed”, the Pareto shows one 120-second jam as four stops totaling 364 seconds. Code the waiting machines as waiting on the line, so the jam counts once. Build each code by [creating a downtime category](/docs/monitoring/downtime-categories/#create). Routine stops at shift start, shift end and breaks can be [classified automatically](/docs/monitoring/auto-downtime-rules/), so operators classify only the stops worth fixing. The [reason codes guide](/blog/downtime-reason-codes/) covers how to keep the list short. Changeovers deserve their own code. A product change is two jobs: change the line over, then tell the counter which product it now counts. A size change, such as 500 mL to 2 L, also changes what the beam sees, so re-check the count point at every size change. ## One shift on a bottling line The numbers below follow the hypothetical water line through one shift, so you can see what each number is for. #### Worked example: One 8-hour shift on a 500 mL water line - Shift: 480 minutes with a 30-minute break, so planned production time is 450 minutes. - Ideal rate: 150 bottles a minute, the case packer’s rated speed. - Stops at the discharge counter: changeover 25 minutes, bottle jams 15, label roll changes 12, waiting on bottles 8. Total 60 minutes, so run time is 390 minutes. - Good count after the last reject: 52,650 bottles. Rejects: 600 bottles, so 53,250 were processed. Availability is 390 ÷ 450 = 86.7%. Performance is 53,250 ÷ (390 × 150) = 53,250 ÷ 58,500 = 91.0%. Quality is 52,650 ÷ 53,250 = 98.9%. **Result:** OEE = 52,650 ÷ (450 × 150) = 52,650 ÷ 67,500 = 78.0% The performance gap is 58,500 − 53,250 = 5,250 bottles, or 35 minutes at the ideal rate. That time never appeared as a stop at the discharge. It is the short jams the buffers absorbed and the minutes the line ran below 150. With the labeler’s 300 a minute as the ideal, performance would read 53,250 ÷ 117,000 = 45.5%, and the 35 minutes would drown in a loss that does not exist. Packaging lines can start far lower. A NIST MEP case at a snack maker’s plant in Horseheads, New York, found one packaging line at 20 to 30% OEE. After cross-functional teams worked on changeovers and sanitation, it ran above 50%, with $400,000 in annual savings.[2] The [OEE calculation guide](/blog/how-to-calculate-oee/) works each factor through on its own. ## Count a packaging line with IoTFlows IoTFlows counts a line with a [BeamTracker](/products/beamtracker/), an IP67 laser counter that bolts beside the conveyor after the last reject point. It counts each unit that breaks its beam, with no PLC, and reports the count, the rate in the line’s own unit, such as bottles a minute, and every stop with its reason. A BeamTracker at each step shows which machine stopped the line. Grouped as a cascade, the steps report [first pass yield at every step](/docs/monitoring/asset-groups/#fpy). Altium Packaging counts every bottle on [ten bottling lines in Memphis](/customers/altium-packaging/), at 20 to 140 bottles a minute, and inspects its Slide Knife every 100,000 bottles. Criollos Foods [increased bagging-line productivity 35%](/customers/criollos-foods/) by coaching operators who ran below its 30 bags a minute target. ## Roll it out on one line 1. **Write down each machine’s rated speed.** List the filler, capper, labeler, case packer and anything between, with each rated speed for the container you run most. The slowest one sets the ideal rate. 2. **Count after the last reject.** Mount one counter where units run single file past the last reject station, off any accumulation table. Name the unit, such as bottles, so the rate reads in units a minute. 3. **Validate against a hand count.** Run the line for one to two hours, then compare the recorded count with a count at the discharge over the same window. A count that reads an exact multiple of the real one is the quantity per cycle, not the counter. 4. **Set the downtime filter past normal gaps.** Find the longest normal pause between units, such as a case packer’s index, and set the filter past it. Otherwise every normal pause reads as a stop. 5. **Start a short reason list.** Load eight codes or fewer, and ask operators to classify only stops on the machine that caused them. 6. **Add a counter at each machine.** Once the line count is trusted, add counters at the machines where stops start, so the earliest stop names the cause. After two to four weeks, rank the classified minutes and work the largest reason first. More machine-by-machine guides are under [machines and connectivity](/blog/topics/machines-and-connectivity/). ## Questions ### Should I count bottles or cases on a packaging line? Count single units where they run single file after the last reject, because that count matches the line’s rate in bottles a minute. Count cases when the units are clear glass or film that a beam may not see, or when the case packer discharge is the only clean single-file point. Then set the quantity per beam break to the pack count, such as 24. ### What is the difference between Held and Suspended in PackML? Both are paused states in the PackML state model. A machine is Held when it waits for a condition inside the machine to clear, such as low material or an operator service. A machine is Suspended when it waits for a condition outside it, such as a fault in upstream or downstream equipment. The split separates a machine’s own pauses from waits caused by its neighbors. ### Why does my line never reach the labeler’s rated speed? Because the labeler is not the slowest machine on the line. Units leave a line at the rate of its slowest machine, often the filler or the case packer, so a labeler rated at 300 a minute on a line capped at 150 a minute runs at 150 a minute. Its extra speed is still useful: it lets the labeler clear a buffer after a stop upstream. ### How short a stop can a counter at the end of the line see? A counter at the discharge sees a stop upstream only when the stop outlasts every buffer between that machine and the counter, plus the counter’s own downtime filter. On a line with 60 seconds of buffer between the capper and the case packer and a 30-second filter at the discharge, a capper jam shorter than 90 seconds never reaches the end-of-line count as a stop. ## Sources 1. [OPC 30050: OPC UA for PackML, Common Object Model, version 1.01](https://reference.opcfoundation.org/specs/OPC-30050/full), OPC Foundation, accessed Oct 16, 2026 2. [Taking Action Against Productivity Losses](https://www.nist.gov/mep/successstories/2022/taking-action-against-productivity-losses), NIST Manufacturing Extension Partnership, accessed Oct 16, 2026 3. [Overall Equipment Effectiveness QS 2026](https://www.pmmi.org/report/overall-equipment-effectiveness-qs-2026), PMMI, The Association for Packaging and Processing Technologies, accessed Oct 16, 2026 --- # How to choose a maintenance strategy for each machine Source: https://www.iotflows.com/blog/maintenance-strategies/ Match each machine to reactive, preventive, usage-based, condition-based or predictive maintenance with a four-question test, survey data and worked examples. > Question: Which maintenance strategy fits which machine? ## Key takeaways - Choose a maintenance trigger for each failure mode, not one strategy for the whole plant. - Run cheap, non-critical or redundant items to failure on purpose, with the spare already on the shelf. - Service parts that wear with use on run hours, strokes, shots or parts made, because calendar intervals drift when run hours vary. - Watch critical machines whose failures come at random for a measured change, and open the work when a limit is crossed. - In a NIST survey, the most reactive quarter of plants had 13.0% downtime against 4.0% for the least reactive quarter. The maintenance strategy that fits a machine depends on how its parts fail and what a failure costs. Run cheap, non-critical items to failure, and service parts that wear with use on run hours, strokes or parts made. Keep calendar PM for work owed by date, and watch critical machines whose failures come at random for a measured change. Most plants need all five strategies at once, one per failure mode. This guide gives a four-question test for choosing, the survey numbers behind each approach, and a sample plan for CNC mills, presses and molds. ## The five maintenance strategies Each strategy answers one question: what starts the work? | Strategy | What starts the work | Plant example | |---|---|---| | Reactive | A failure | Replace a fan motor when it stops | | Time-based preventive | A date on the calendar | Quarterly gearbox inspection | | Usage-based | Run hours, cycles or parts made | Grease a spindle every 500 run hours | | Condition-based | A measured limit is crossed | Pump vibration passes its alarm level | | Predictive | A trend projected toward failure | Bearing swap planned from a rising trend | > **Definition.** **Preventive maintenance (PM)** is maintenance done at fixed intervals of calendar time, operating hours or cycles to lower the chance of failure, whatever condition the equipment is in when the interval comes due. A calendar PM is a [recurrence rule on a work order](/docs/get-started/glossary/#preventive-maintenance): a quarterly gearbox inspection comes back every 13 weeks. *Usage-based maintenance* is the preventive variant that counts use instead of days: hours run, strokes, shots or parts made. > **Definition.** **Condition-based maintenance (CBM)** is maintenance triggered when a measured indicator of equipment condition, such as vibration, temperature or oil quality, crosses a set limit, so work happens only when the machine shows it needs it. > **Definition.** **Predictive maintenance (PdM)** is condition-based maintenance with a forecast: measurements are trended over time to estimate when a component will reach its limit, so the repair can be planned before the failure and around production. References draw these lines differently. The US Department of Energy’s guide counts a schedule based on machine run time as preventive, and NASA’s reliability guide treats predictive maintenance and condition monitoring as two names for one practice.[2][3] This article separates them by trigger, because the trigger is what you set up. ## How failures behave decides the trigger A calendar or hour interval works only when a part fails at a predictable age. Many parts don’t. NASA’s guide cites three studies, of United Airlines aircraft in 1968, Swedish equipment in 1973 and US Navy equipment in 1982, in which random failures made up 77% to 92% of all failures and age-related failures the remaining 8% to 23%.[3] Those studies covered aircraft and naval equipment, not your plant, so treat the split as a warning rather than a measurement of your machines. The pattern behind it transfers. NASA notes that simple, single-piece items such as tires, brake pads and compressor blades wear in step with age or stress cycles, while most complex items show no marked wear-out age.[3] On a plant floor, that sorts components into two groups: - **Parts that wear with use:** cutting tools, die punches, mold vents and ejector pins, slide knives, belts, filters and grease. A count of use predicts their end well, so a usage-based interval fits. - **Complex assemblies that fail at random:** spindle bearings, gearboxes, main drive motors and hydraulic pumps. A fixed interval is early for some units and late for others, so measure their condition instead. Opening a complex machine on a schedule carries its own risk. NASA reports that scheduled overhaul can raise the overall failure rate by adding early-life failures to an otherwise stable system.[3] A spindle rebuilt every two years because the calendar said so can fail sooner than the one left alone. ## What the survey data says NIST’s Machinery Maintenance Survey of US manufacturers, with 2016 figures, measures how plants split their maintenance work. On average, 45.7% of maintenance was reactive, 31.8% preventive and 17.3% predictive.[1] The share barely moved with size: plants with 1 to 19 employees and plants with 100 or more both averaged 43.8% reactive.[1] The most reactive quarter of plants, at 81.5% reactive work, had 13.0% of planned production time as downtime. The least reactive quarter, at 14.4% reactive, had 4.0%.[1] Figure: Three bars of downtime as a share of planned production time: 13.0% for the most reactive quarter of plants, 6.8% for the middle half and 4.0% for the least reactive quarter, from NIST’s survey of US plants with 2016 data. *The most reactive quarter of surveyed plants had about 3.3 times the downtime share of the least reactive quarter.* Read three caveats into those numbers: - **It’s an association.** NIST notes that the groups are small and many differences aren’t statistically significant. Downtime due to maintenance issues, 6.7% against 0.9% of planned time, is one of two gaps that were, at the 10% level.[1] - **Less reactive plants spent more.** Maintenance cost was 3.0% of shipments in the least reactive quarter against 1.9% in the most reactive.[1] Planned work costs money up front, and it buys back running time. - **Predictive adds less than its headlines.** Among plants under 50% reactive, the top half in predictive work had 15% less downtime than the bottom half.[1] That gain is real, and it’s far smaller than the gap between reactive and planned work. The DOE guide sizes the steps the same way. It estimates that a preventive program saves 12% to 18% in cost over a reactive one, and that a well-run predictive program saves a further 8% to 12% over preventive alone.[2] > **Check which number a vendor quotes** > > The DOE guide also lists survey averages for predictive programs, such as 70% to 75% fewer breakdowns, without naming the surveys.[2] Plan on the 8% to 12% estimate over a good preventive program, and treat the larger figures as an upper bound. ## Match each strategy to the machine Run every failure mode on a machine through four questions, in order. The first yes sets the trigger. Figure: Four questions in order. Owed on a date: time-based preventive. Cheap, safe failure: reactive. Wears with predictable use: usage-based. Measurable warning: condition-based. No to all four: redesign or stock a spare. *Four questions per failure mode, asked in order. The first yes picks the maintenance trigger.* The DOE guide gives the same sorting as a table, adapted from NASA.[2] | | Reactive | Preventive | Predictive | |---|---|---|---| | Equipment | Small parts, non-critical items | Subject to wear, consumables | Critical equipment | | Failure pattern | Unlikely to fail | Known failure pattern | Random failure pattern | | Also fits | Redundant systems | The maker’s recommendation | Failures that PM itself can cause | Adapted from Table 5.5.1 of the DOE O&M Best Practices Guide, Release 3.0. Preventive here includes usage-based intervals. Choose **reactive** when a failure is cheap, safe and quick to fix, the machine isn’t a bottleneck, and the spare is in stock. NASA’s examples are non-critical motors under 7.5 HP, comfort cooling and restroom exhaust fans.[3] Choose **time-based preventive** when the work is owed by date whatever the machine did: an inspection a regulation, insurer or warranty sets on the calendar. [Building a PM schedule that holds](/blog/preventive-maintenance-schedule/) covers the calendar side. Choose **usage-based** when a part wears with use and the machine’s hours change from week to week. Choose **condition-based** when a failure is costly, comes at no predictable age and gives a measurable warning first. Choose **predictive** only when that warning trend is steady enough to plan parts and labor around. You don’t need a forecast on a machine with slack capacity or a standby unit: a limit and a work order cover it. Here is a sample plan for a plant with mills, a press and molding machines. Replace the intervals with the maker’s or your own history: | Machine and part | Strategy | Trigger | |---|---|---| | CNC mill spindle bearings | Condition-based | Vibration leaves its baseline | | CNC way lube and spindle grease | Usage-based | Every 500 spindle run hours | | Progressive die on a 350-ton press | Usage-based | Strokes since last sharpening | | Injection mold vents and ejectors | Usage-based | Shots since last service | | Overhead crane | Time-based preventive | The inspection date on file | | Chip conveyor motor, spare in stock | Reactive | The motor stops | The reactive and condition-based rows come from pricing the failure, not from the part’s name. The same arithmetic sorts any pair of failure modes. #### Worked example: Run to failure or watch it? Two failure modes, priced Sample numbers on two hypothetical machines, counting lost production only: - Chip conveyor motor on a Haas VF-2 with slack capacity: it fails about once every 2 years, a swap from the shelf takes 1.5 hours, and an hour of the mill’s downtime costs $150. Each failure costs 1.5 × $150 = $225, or $112.50 a year. - Spindle bearings on the bottleneck 5-axis mill: an unplanned failure stops it for 40 hours while the spindle is rebuilt, and an hour of its downtime costs $600. Each failure costs 40 × $600 = $24,000. Caught early, the same rebuild fits a planned weekend stop and costs no production. Monitoring the conveyor motor pays only if it costs less than $112.50 a year. Monitoring the spindle pays if it costs less than $24,000 for each failure it catches. **Result:** Conveyor motor: $112.50 a year at risk, run it to failure. Spindle: $24,000 a failure at risk, watch it. ## Usage-based or calendar PM? Choose a usage interval when a part wears only while the machine runs and the machine’s hours change from week to week. Keep the calendar for work that ages whether or not the machine runs, and for any inspection owed on a date, such as the overhead crane in the plan above. A calendar interval assumes a run rate. For example, greasing every four weeks on a 500-hour interval assumes 125 run hours a week. In a slow month of 320 hours, the grease goes in 180 hours early. In a busy month of 640 hours, it goes in 140 hours late. A [meter](/docs/get-started/glossary/#meter) on run hours or parts calls for the work at 500 hours every time. Part counts work the same way. Altium Packaging’s Memphis plant inspects the Slide Knife on a bottling line every 100,000 bottles, because a date-based schedule was always either early or overdue. See the [Altium Packaging story](/customers/altium-packaging/). [Usage-based maintenance](/blog/usage-based-maintenance/) covers which unit to count, how to set the first interval and how early to warn. ## Condition-based or predictive? Both start from a measurement against a baseline: what this machine looks like healthy. Condition-based work fires when a reading crosses a limit. Predictive work trends the readings and estimates when the limit will be reached, so the repair lands in a planned stop. The measurement can come from a route or from a sensor that stays on the machine. On a route, the interval matters. NASA advises cutting the monitoring interval to between a third and a quarter of the previous one once a reading passes its alert limit, so a quarterly vibration route becomes one every three to four weeks.[3] A sensor that reports continuously removes the interval question, and leaves the limit as the setting that matters. How much warning you get depends on the failure mode and on how often you measure. A bearing that wears slowly shows a rising trend you can plan around. A [CNC tool crash](/blog/cnc-tool-crash-detection/) gives no trend at all: it’s a single shock, and the useful response is a work order the moment it happens. You don’t need a remaining-life forecast to get most of the value. A limit, a baseline and a work order that opens on its own cover most machines. NASA notes that predictive testing doesn’t suit every type of equipment or failure mode, and shouldn’t be the only maintenance a site practices.[3] ## Trigger work orders from the machine IoTFlows Maintain opens maintenance work from the same machine data that runs your monitoring. A [meter](/docs/maintain/meters/) counts runtime hours or parts toward a trigger point. It can email the maintenance team at 85% and open the work order at 100%. For condition-based work, a [machine event rule](/docs/alerts/asset-event-rules/#work-order) opens a work order when a health, shock or temperature event fires. Health alerts fire as the vibration health score falls past 60, 40 and 20. Calendar PM is a [recurrence rule](/docs/maintain/preventive-maintenance/) on a work order. An operator who classifies a stop can open a work order from the same Classify Downtime panel, which is how [RNPSA](/customers/rnpsa/) halved its maintenance response time. See [predictive maintenance in IoTFlows](/solutions/predictive-maintenance/). ## Build a mixed maintenance plan 1. **Rank machines by what a failure costs.** Price an hour of downtime on each machine, using the method in [how to calculate the cost of downtime](/blog/cost-of-downtime/). Bottlenecks and machines with no standby go to the top. 2. **List the failure modes on the top machines.** For each of your top ten machines, write down the ways it has failed and the ways the maker warns it can fail. Your stop history ranked by hours, as in a [downtime Pareto](/blog/downtime-pareto/), shows which ones cost the most. 3. **Run each failure mode through the four questions.** Owed by date, cheap to fix, wears with use, measurable warning. The first yes sets the trigger. 4. **Set up each trigger.** Write a recurrence for calendar work, a meter for usage-based work and a limit for condition-based work in your [CMMS](/blog/what-is-a-cmms/). For each reactive item, stock the spare. 5. **Review the plan every quarter.** Read the work orders each trigger produced. Move a calendar task to a meter when its findings track run hours, and drop a task that keeps finding nothing. ## Questions ### Is predictive maintenance the same as condition-based maintenance? Many references treat them as one practice, and NASA’s reliability guide uses predictive maintenance and condition monitoring as two names for it. A useful split for planning is the trigger. Condition-based work starts when a measurement crosses a limit. Predictive work starts from a trend projected forward to estimate when the limit will be crossed, so the repair can be scheduled around production. ### What share of maintenance work should be reactive? The US Department of Energy’s operations and maintenance guide describes top-performing facilities as under 10% reactive, 25% to 35% preventive and 45% to 55% predictive. Treat that as a direction, not a target to hit next quarter. NIST’s survey of US manufacturers found an average of 45.7% reactive, so most plants have a long way to go and should start with their critical machines. ### Can preventive maintenance cause failures? Yes. Every time a technician opens a stable machine to replace a part that was working, the new part and the reassembly can fail early. NASA’s reliability guide notes that scheduled overhauls can raise the failure rate of complex equipment this way. Replace on a schedule only parts that wear out with age or use, and inspect or monitor the rest. ### Should every machine get condition monitoring? No. Monitoring pays where a failure is expensive, comes without a predictable age and gives a measurable warning first: spindles, gearboxes, main drive motors and pumps on bottleneck machines. A small motor with a spare on the shelf, on a machine with slack capacity, costs less to run to failure than to monitor. Rank machines by what an hour of downtime costs before you choose. ## Sources 1. [Economics of Manufacturing Machinery Maintenance: A Survey and Analysis of U.S. Costs and Benefits (NIST AMS 100-34)](https://nvlpubs.nist.gov/nistpubs/ams/NIST.AMS.100-34.pdf), National Institute of Standards and Technology, accessed Oct 16, 2026 2. [Operations & Maintenance Best Practices: A Guide to Achieving Operational Efficiency, Release 3.0 (PNNL-19634)](https://www.osti.gov/servlets/purl/1034595), Pacific Northwest National Laboratory for the US Department of Energy, accessed Oct 16, 2026 3. [Reliability-Centered Maintenance Guide for Facilities and Collateral Equipment](https://www.nasa.gov/wp-content/uploads/2023/06/nasa-rcmguide.pdf), National Aeronautics and Space Administration, accessed Oct 16, 2026 --- # How to monitor injection molding machines Source: https://www.iotflows.com/blog/monitor-injection-molding-machines/ Count shots, multiply by working cavities and keep mold-open pauses out of downtime. Learn why a molder's count reads double or half, and how to check it. > Question: How do I count shots, cavities and stops on a molding fleet, and why does a count read double or half? ## Key takeaways - A molder's part count is its shot count multiplied by the number of working cavities in the mold. - Mold open, eject and close happen inside every shot, so a filter window keeps those pauses out of downtime. - A count that reads exactly double, half or a quarter is a cavity setting, not a sensor fault. - Every mold change needs its own shot time and cavity count, while a material change keeps both and needs a reason. - Validate each new setup against a hand count and the machine's shot counter before anyone acts on the number. To count shots, cavities and stops on a molding fleet, you count each machine's shots, multiply every shot by the working cavities in its mold, and filter the few seconds of mold open and eject so they never read as stops. A count that reads exactly double or half is a cavity setting, not a sensor fault: fix the multiplier, then check the count against a hand count. This guide is for plant managers and process engineers running a fleet of molding machines. It follows one hypothetical 4-cavity mold on a 24-second shot, from the vibration trace to a validated part count. ## What to monitor on a molding machine > **Definition.** **Shot** is one complete cycle of an injection molding machine: the mold closes, the screw injects and packs the melt, the part cools, and the mold opens and ejects. One shot makes one part per working cavity. A molder's output follows from three numbers: how many shots it ran, how many cavities each shot filled and how many of those parts were good. Its losses are the stops between runs of shots, and shots that ran slower than the mold's set cycle. > **Definition.** **Quantity per cycle** is the number of parts one machine cycle produces. On an injection molding machine it equals the number of working cavities in the mold, so a 4-cavity mold makes 4 parts per shot, and 3 with one cavity blocked off. The glossary entry for [quantity per cycle](/docs/get-started/glossary/#quantity-per-cycle) uses the same meaning. Multiply it by the shot count and you have the part count. **Parts** = Shots × working cavities | Number | What it tells you | Where it comes from | |---|---|---| | Shot count | How many cycles the machine ran | Sensor or machine controller | | Shot time | How long each cycle took | Sensor or machine controller | | Working cavities | Parts per shot | The mold, set once per mold | | Stops | When and how long it stood | Sensor or machine controller | | Stop reason | Why it stood | The operator | | Scrap | Parts made but not good | The operator or inspection | Count *working* cavities, not the number on the mold drawing. For example, a 4-cavity mold running with one cavity blocked for a damaged insert makes 3 parts a shot. Left at 4, every shot from that moment overcounts by one part in three. The count is gross output. Startup shots after a mold change, purge shots and rejects are all shots, so log scrap separately and compare good parts with good parts. ## How a molding cycle looks to a sensor A shot has four phases: fill, pack and hold, cooling, then mold open, eject and close. In one published example, fill took 0.26 seconds, pack and hold 8.0 seconds and cooling 10.0 seconds, inside a 21.43-second cycle.[1] That leaves about 3.2 seconds for everything else, including opening the mold, ejecting the parts and closing it again. A vibration sensor on the injection unit or near the hydraulic power unit feels the clamp, the screw and the pump through every phase. The trace stays above the *running threshold*, the vibration level calibrated to separate running from idle, for most of the shot. It dips for a few seconds as the mold opens and ejects, then climbs again. Figure: A vibration trace over 3 minutes on a 4-cavity mold with a 24 s shot: four shots, each with a 3 s mold-open dip below the threshold, then a 60 s stop that runs past a 48 s filter window, then a fifth shot. *Mold-open dips fall inside the filter window and count as running; the 60-second stop does not. Sample data.* That shape decides how you count. The dips last only a few seconds and the machine never rests between shots, so a detector that looks for one burst per shot can miss or merge shots. Divide running time by the measured shot time instead. At a 24-second shot, 1 hour of running is 3,600 ÷ 24 = 150 shots, or 600 parts from 4 cavities. > **Divide run time or count bursts?** > > Divide running time by the shot time when the machine cycles on its own and the shot repeats to the second. Count each burst as a shot when the machine waits between cycles, for example when an operator loads inserts by hand or takes parts off before the next cycle starts. That molder behaves like a machining center, which [counts cycles one by one](/blog/how-to-monitor-cnc-machines/#count). Dividing by the shot time makes that number the accuracy of the count. Once the machine is at temperature, time 10 consecutive shots with a stopwatch, from shot start to shot start, and average them. Never copy the shot time off the setup sheet, and never time a part instead of a shot. ## Keep mold-open pauses out of downtime Every mold-open dip is a fall below the threshold. Without a filter, a monitoring system records each one as a stop, so a 24-second shot produces 150 three-second "stops" an hour. The downtime list fills with pauses nobody on the floor would call a stop. The count suffers too. Those 150 dips take 450 seconds of running time out of every hour, so a count built from running time reads 3,150 ÷ 24 = 131 shots instead of 150, about 12.5% low. > **Definition.** **Downtime filter** is a window, set as a percentage of the cycle time, inside which a stop is counted as running time instead of downtime, so the brief pauses inside every cycle of a continuously cycling machine never reach the downtime record. Read the percentage as a length of time. At a 24-second shot, 200% is a 48-second window and 50% is a 12-second window. Because the window scales with the shot, re-timing the shot moves the window with it. | Filter | Window at a 24 s shot | Counted as running | Kept as downtime | |---|---|---|---| | 0% | None | Nothing | Every mold-open dip | | 50% | 12 s | Mold-open dips | A 20 s robot fault and longer | | 200% | 48 s | Dips and a 40 s material hiccup | A 60 s stop and longer | The wider the window, the fewer stops anyone has to explain, and the more short problems disappear into running time. For example, a dryer alarm that holds the screw for 40 seconds reads as production at 200% and as a stop at 50%. > **A wide window inflates the count** > > When running time drives the count, every stop the filter absorbs is credited with shots. Three absorbed 40-second stops an hour add 120 ÷ 24 = 5 phantom shots, which is 20 phantom parts on a 4-cavity mold. Start wide, then narrow the window once you see which short stops recur. Stops longer than a mold-open dip but shorter than the window are micro-stops: they cost shots without ever reaching the downtime list. The [guide to micro-stops](/blog/micro-stops/) covers how to find them. ## Why a count reads double or half Divide the monitored count by a hand count over the same shots, and read the ratio rather than the difference. A clean ratio is a multiplier: exactly 2, 4, 0.5 or 0.25 means each shot is credited with the wrong number of parts. No change to the sensor or the counting method fixes a multiplier. An uneven ratio, such as 0.93 or 1.08, is a timing problem. The shot time is off, or the filter window is too narrow or too wide. Figure: A ratio scale of monitored count divided by hand count. Clean ratios of 0.25 and 0.5 mean the cavity count is set too low, 2 and 4 mean it is set too high, and a ratio within 5% of 1 needs no change. *A clean multiple of the hand count points at the cavity setting first; an uneven ratio points at timing.* | Ratio | Likely cause | Fix | |---|---|---| | Exactly 0.25 or 0.5 | Cavities left at 1 | Set the working cavities | | Exactly 2, 3 or 4 | Cavities set above the working count | Set the working cavities | | A multiple, cavities correct | Per-part time entered as shot time | Enter the full shot time | | Wrong since a mold change | The old mold's settings still apply | Apply the new mold's settings | | Uneven, below 1 | Shot time too long, or dips as stops | Re-time, or widen the window | | Uneven, above 1 | Shot time too short, or stops absorbed | Re-time, or narrow the window | The per-part row catches a common timing mistake. A 2-cavity mold on a 22-second shot makes a part every 11 seconds, and entering 11 seconds as the shot time doubles every count. The [part-count troubleshooting guide](/docs/production/troubleshoot-part-counts/#half) works through the same checks for every counting method. #### Worked example: A 4-cavity mold that reads a quarter - Mold: 4 working cavities. Shot time: 24 seconds, averaged over 10 timed shots. - The machine runs a full hour with no stops, so it makes 3,600 ÷ 24 = 150 shots and 150 × 4 = 600 parts. - The monitoring system shows 150 parts for the hour. Counting the parts from 10 shots at the press gives 40. The ratio is 150 ÷ 600 = 0.25, a clean quarter: quantity per cycle is still 1. Set it to 4. Over the next hour, the monitored count reads 600. The shot counter on the machine's own screen moves from 18,240 to 18,388, which is 148 shots or 592 parts. **Result:** Accuracy = 600 ÷ 592 = 101.4%, inside the 95 to 105% band ## Handle mold and material changes A mold change and a material change look alike on the downtime list: the machine stands for a while. They are not alike for the count. A mold change replaces the shot time and the cavity count, so the settings must change with the mold. Skip that, and every shot of the new mold is counted with the old one's numbers. For example, swapping a 4-cavity clip mold on a 24-second shot for a 2-cavity housing mold on a 30-second shot, without changing the settings, reads (30 ÷ 24) × (4 ÷ 2) = 2.5 times the real output. Set up one entry per mold, not one per part number. The same clip run in a 2-cavity and a 4-cavity mold needs two entries, because the cavity count differs. A material or color change keeps the mold, the shot time and the cavities, so nothing in the count changes. The stop is the number worth tracking, so give it its own reason and [time it by one rule](/blog/measure-changeover-time/#start-stop). | Reason | What it covers | Who acts on it | |---|---|---| | Mold change | Pulling and hanging a mold, hookups | Setup lead | | Material change | Resin swap and purge | Process technician | | Color change | Colorant swap and purge | Process technician | | Startup | First shots until parts pass | Quality | | Waiting on material | Empty hopper or dryer not ready | Materials | | Auxiliary equipment | Robot, conveyor or chiller fault | Maintenance | | Mold problem | Stuck part, flash or blocked cavity | Tooling | | Shift change | Handover between crews | Supervisor | A starting list. Split a reason only when it grows large enough to hide two different causes. Keep the list short enough that an operator picks a reason in one tap. The [starter list of reason codes](/blog/downtime-reason-codes/) holds the reasons operators pick to 8 to 12. ## Read the controller or use a sensor? Many molding machines can report their own shots. EUROMAP 63, the older interface between molding machines and central computers, works by transferring text files. EUROMAP 77 is the OPC UA interface written to replace it.[2] Its first version was released on 4 May 2018, and release 1.01 is identical to OPC 40077.[3] The OPC UA model gives a molder's data names. Each running job reports `JobCycleCounter`, the number of finished cycles in the job, and `LastCycleTime`, the duration of the most recent cycle, beside counters for good, bad and test-sample parts.[4] The job information can carry `NumCavities`, the number of cavities in the mold used for production. That property is optional, so check that your machine fills it in before you trust a part count built on it.[5] The interface is more than a feed of numbers. The OPC Foundation says EUROMAP 77 provides no direct control functions or functions needed for safe operation,[2] but its use cases include sending jobs from the MES to the machine and releasing production.[6] A connection to the controller is a security concern for many plants, and IT usually reviews it first. Choose the controller connection when: - the machines support EUROMAP 77 and IT has approved the connection; - you need process values, such as temperatures and pressures, beside the shot count; - you want the machine's own good and bad part counters per job. Choose a sensor on the outside of the machine when the fleet mixes builders and decades, when some machines have no interface, or when you need shots and stops this month rather than after an IT review. The [protocol guide](/blog/machine-communication-protocols/) explains OPC UA alongside MTConnect and Modbus. The [sensor-based versus PLC comparison](/compare/sensor-based-vs-plc-machine-monitoring/) sets out what each approach sees. ## Monitor molders with IoTFlows IoTFlows puts a magnetic SenseAi on the injection unit or near the hydraulic power unit of each molder, with no PLC connection. Each mold is its own operation on Continuous Analysis, which divides running time by the shot time you timed. QTY/OP holds the cavity count, and a Downtime Filter of 0 to 200% keeps mold-open pauses out of the downtime record, as the [downtime filter settings](/docs/production/cycle-times-and-filters/#filter) describe. Datwyler runs more than 20 injection molding machines in Ontario, California. With SenseAi on every machine and a reason on every stop, it cut shift-changeover downtime by 50% and material-changeover downtime by 30% within six months, as [Datwyler's story](/customers/datwyler/) tells. [Injection molding machine monitoring](/solutions/injection-molding-machine-monitoring/) shows what each machine reports. ## Roll it out across the fleet 1. **Start with one machine of each kind.** Pick one fully automatic molder and one an operator tends. They count differently, so each needs its own check. 2. **Time ten shots at temperature.** Average 10 consecutive shots from shot start to shot start. Write the result next to the mold's cavity count. 3. **Set up one entry per mold.** Enter the shot time and the working cavities for each mold, not for each part number. 4. **Start the filter wide.** Begin at a window of about twice the shot time, run a shift, then narrow it if short stops worth seeing disappear into running time. 5. **Check the ratio against a hand count.** Count the parts from 10 shots to catch a multiplier, then compare an hour against the machine's shot counter to catch timing. The [accuracy bands](/docs/production/choose-an-algorithm/#validate) set the line: 95 to 105% is a working setup. 6. **Recheck after every mold change.** Confirm the new mold's shot time and cavities are in place before the first good part, and count one more set of 10 shots. 7. **Set goals from each machine's baseline.** After a week, set each machine's uptime goal at its own baseline plus 5 to 10%. The [molding uptime ranges](/docs/production/injection-molding/#expectations) show where tended, automatic and lights-out machines land. Once the first two machines read correctly, copy their setup to the rest of the fleet. More machine-by-machine guides are under [machines and connectivity](/blog/topics/machines-and-connectivity/). ## Questions ### What is the difference between a shot and a part? A shot is one complete cycle of the molding machine: the mold closes, fills, cools, opens and ejects once. A part is one molded piece. A shot makes as many parts as the mold has working cavities, so a 4-cavity mold makes 4 parts a shot, or 3 with one cavity blocked off. ### Should mold-open time count as downtime? No. Opening the mold, ejecting the parts and closing it again happen in every shot and last a few seconds. Count them as running time, and treat only stops longer than a set window, such as twice the shot time, as downtime. Check the window against your real stops so a short material problem is not hidden. ### What uptime should an injection molding machine reach? It depends on how much of the cycle a person carries. As a guide, a machine where an operator loads inserts or takes parts off runs 60 to 75% of the time, a fully automatic one 75 to 85% and a lights-out cell 85 to 90%. Set each goal from that machine's own baseline plus 5 to 10%. ### Can I read shot counts from the molding machine's controller? Often, yes. Machines with EUROMAP 77 report a job cycle counter and the last cycle time over OPC UA, and can also report the number of cavities in the mold. Older machines may use EUROMAP 63, which exchanges text files. A connection to the controller is a security concern for many plants, so IT usually reviews it before it goes live. ## Sources 1. [Injection Molding Cooling Time: A Breakdown](https://www.designworldonline.com/injection-molding-cooling-time-a-breakdown/), Design World, accessed Oct 16, 2026 2. [Plastics and Rubber Machinery (EUROMAP 63 and EUROMAP 77)](https://opcfoundation.org/markets-collaboration/plastics-and-rubber-machinery/), OPC Foundation, accessed Oct 16, 2026 3. [EUROMAP 77: Data exchange between injection moulding machines and MES](https://www.euromap.org/euromap77), EUROMAP, accessed Oct 16, 2026 4. [OPC 40083, OPC UA for Plastics and Rubber Machinery, General Type Definitions: 18.4.7 ActiveCyclicJobValuesType](https://reference.opcfoundation.org/specs/OPC-40083/18.4.7), OPC Foundation, accessed Oct 16, 2026 5. [OPC 40083, OPC UA for Plastics and Rubber Machinery, General Type Definitions: 18.2.11 CyclicJobInformationType](https://reference.opcfoundation.org/specs/OPC-40083/18.2.11), OPC Foundation, accessed Oct 16, 2026 6. [OPC 40077, Data exchange between injection moulding machines and MES: 5 Use cases](https://reference.opcfoundation.org/specs/OPC-40077/5), OPC Foundation, accessed Oct 16, 2026 --- # How to calculate the cost of an hour of downtime Source: https://www.iotflows.com/blog/cost-of-downtime/ Price an hour of downtime from your own margin, crew and repair costs, with a formula, a worked bottling-line example and the test for when lost output counts. > Question: How do I price an hour of downtime in my own plant? ## Key takeaways - Price a stop as an hourly rate times the hours stopped, plus the one-off costs the stop brings with it. - Lost margin counts only when the output is gone for good, as on a bottleneck with orders waiting. - When the crew makes the parts back on overtime, the overtime pay replaces the lost margin and idle crew lines. - Short stops cost the most per hour, because replacement parts and restart scrap do not shrink with the stop. - Survey figures such as $2.3 million an hour describe large plants, not your margin, crew or bottleneck. You price an hour of downtime by adding the margin on the parts you never make, the pay of a crew that can’t work, the repair, and the one-off costs of the stop, such as replacement parts and restart scrap. Which of those count depends on one fact: whether the lost output is gone for good or made back later. This guide is for plant managers and owners who need a number they can defend. It builds the formula from your own margin and labor, works one bottling line through by hand, and shows why a survey figure from large plants won’t describe yours. ## What an hour of downtime costs > **Definition.** **Cost of downtime** is the money a plant loses while a machine or line is stopped: the margin on output it never recovers, the pay of people who cannot work, the cost of the repair, and the one-off costs of the stop such as parts, restart scrap and penalties. *Downtime* is any time a machine is stopped, whatever the reason, as the [glossary entry for downtime](/docs/get-started/glossary/#downtime) defines it. A stop costs money only through what it takes away or adds. Siemens’ 2024 True Cost of Downtime report counts five elements: lost revenue, wages for staff who can’t work, salaries of the people fixing the problem, emergency replacement parts, and penalties such as contractual compensation.[1] Use the same elements with two changes. First, count lost margin rather than lost revenue, because you don’t buy material for parts you don’t make. Second, separate the costs that grow with every minute from the ones a stop brings once. *Contribution margin* per part is the selling price less the costs that vary with each part made: material, direct labor, packaging and energy. Fixed costs stay out of it. Rent, depreciation and salaried overhead run by the calendar, so a stop doesn’t add to them. It spreads them over fewer parts, which is a separate calculation, covered in [the cost of idle machines](/blog/cost-of-idle-machines/). | Cost | Grows with minutes stopped? | Where the number comes from | |---|---|---| | Lost contribution margin | Yes | Price less variable cost per part | | Idle crew pay | Yes | Crew size × loaded hourly rate | | Repair labor | Yes | Technicians × their hourly rate | | Replacement parts | No, once per stop | Work order or parts invoice | | Restart scrap | No, once per stop | Scrap logged after the restart | | Expedite freight and penalties | No, once per stop | Customer contract, freight invoices | Costs in the first three rows make up the hourly rate. The last three are event costs. ## The downtime cost formula Price a stop in two parts: an hourly rate for the costs that grow with time, and a fixed amount for the costs the stop brings with it. **Cost of a stop** = Hourly rate × hours stopped + event costs **Hourly rate** = Units per hour × margin per unit + idle crew pay + repair labor Units per hour is the rate the machine or line holds when it runs, not its nameplate speed. For example, a bottling line rated at 150 bottles a minute that holds 120 in practice loses 7,200 bottles an hour, not 9,000. Use a *loaded labor rate*: wages plus benefits, the full hourly cost of a person to the employer. US manufacturing employers paid $48.62 an hour in total compensation in June 2026, of which $32.50 was wages and salaries.[3] Your own payroll figure is the one to use; the national number is a check on it. > **Count the crew’s pay only once** > > The idle crew line assumes your contribution margin already subtracts direct labor. If your margin is price less material only, drop the idle crew line, because the crew’s pay is already inside that margin. ## Is the output lost or made back? The largest term in the formula, lost margin, applies only when the parts are gone for good. A stop’s output goes one of three ways, and each one changes what you count. | What happens to the output | What you count | When it applies | |---|---|---| | Lost for good | Margin, idle crew, repair, events | Bottleneck with orders waiting | | Made back on overtime | Overtime pay, repair, events | Extra hours open, customer can wait | | Absorbed by spare capacity | Repair, events | Machine catches up in its own hours | When the crew makes the parts back on overtime, the margin isn’t lost, because the parts still ship. The idle crew line drops out too: you would have paid those hours with or without the stop. What the stop adds is the extra hours. Under the Fair Labor Standards Act, non-exempt employees earn at least time and a half for hours over 40 in a workweek.[4] When a machine that isn’t the bottleneck has spare hours, a stop costs its repair and its event costs, because the machine catches up before anyone downstream waits. That changes the moment it starves the [bottleneck](/blog/find-the-bottleneck/), which then loses margin of its own. > **Which case is this stop?** > > Price a stop as lost for good when the machine is the bottleneck and orders are waiting. Price it as made back when the plant can add hours and the customer can wait for the parts. Price it as absorbed only when the machine has idle hours that week and nothing downstream stopped. ## A worked example on a bottling line #### Worked example: A 90-minute capper fault on a bottling line - The line holds 120 bottles a minute, 7,200 an hour. It is the plant’s bottleneck, with orders waiting. - Contribution margin after material, direct labor and packaging: $0.30 a bottle, so 7,200 × $0.30 = $2,160.00 an hour. - Crew: 5 operators at $48.62 loaded,[3] so $243.10 an hour. - Repair: 2 technicians at $60.00 loaded, so $120.00 an hour. - Hourly rate: $2,160.00 + $243.10 + $120.00 = $2,523.10. - Event costs: a $650 replacement part, plus 300 bottles of restart scrap at $0.40 of material each ($120), so $770.00. - Stop: 1.5 hours, so 1.5 × $2,523.10 = $3,784.65 before event costs. **Result:** One 90-minute stop = $3,784.65 + $770.00 = $4,554.65, or $3,036.43 an hour Now change one fact. Suppose the plant makes the 10,800 lost bottles back on Saturday, with the same 5 operators working 1.5 hours of overtime. At time and a half on the $32.50 BLS wage,[3] an overtime hour costs $48.75 in wages. The margin and idle crew lines drop out, and the stop costs 5 × 1.5 × $48.75 = $365.63 of overtime, $180.00 of repair and $770.00 of event costs: $1,315.63. If the line had idle hours that week and caught up without overtime, the same stop would cost $950.00: the repair and the event costs. Figure: Three bars price one 90-minute stop: $4,554.65 when the output is lost for good, $3,240 of it lost margin; $1,315.63 when the bottles are made back on overtime; and $950.00 when spare capacity absorbs it. *The same 90-minute stop costs $4,554.65 when the bottles are lost and $950.00 when spare hours absorb it. Sample data.* The ratio is the point. The same fault on the same line costs nearly five times as much when the line is the bottleneck. Price the stops on your bottleneck first. ## Short stops cost more per hour Event costs don’t shrink with the stop. A 10-minute stop on the example line with the same $770 of parts and scrap costs $770 + (10 ÷ 60) × $2,523.10 = $1,190.52. That is $7,143.10 an hour, against $3,036.43 an hour for the 90-minute stop. Figure: A line rises from $770 at zero minutes to $5,816.20 at 120 minutes. A 10-minute stop costs $1,190.52, or $7,143 an hour; a 90-minute stop costs $4,554.65, or $3,036 an hour. *Every stop on the example line starts at $770 before the first minute, so short stops cost most per hour. Sample data.* So price each downtime reason per stop, not with one hourly figure for the line. A jam that throws away 300 bottles each time can cost more per minute than a breakdown that runs for an hour. Short stops are also the first ones a paper log misses, so measure them before you price them. [Micro-stops](/blog/micro-stops/) covers where the cutoff sits and where those stops land in OEE. ## Rank downtime reasons by dollars A downtime Pareto ranks reasons by hours. Multiply each reason’s hours by its hourly rate, add its event costs, and the order can change. Here is one month on the example line. | Reason | Hours | Stops | Event cost each | Month cost | |---|---|---|---|---| | Changeover overrun | 12 | 20 | None | $28,837.20 | | Waiting for material | 8 | 10 | None | $19,224.80 | | Capper jam | 6 | 90 | $120 restart scrap | $25,218.60 | | Filler breakdown | 4 | 2 | $1,500 in parts | $13,092.40 | Sample data, from the worked example. The breakdown is priced at $2,523.10 an hour; the other reasons need no technician, so they drop the $120 repair line and cost $2,403.10 an hour. Rows are in order of hours. By hours, the capper jam ranks third. By dollars, it ranks second, because each of its 90 restarts throws bottles away. The changeover overrun still leads, and all of its cost is hours, with no parts or scrap behind it. Its fix is a procedure, not a part. Ranked by hours alone, the same list is a [Pareto chart](/docs/get-started/glossary/#pareto-chart). When to rank by hours, by count or by cost is covered in [building a downtime Pareto](/blog/downtime-pareto/#measure). Planned stops cost capacity too: price them at the same rate when they fall on the bottleneck, then decide which to shorten. Mark those reasons as [planned downtime](/docs/monitoring/downtime-categories/#planned) so they stay apart from breakdowns in every report. [Planned vs unplanned downtime](/blog/planned-vs-unplanned-downtime/) covers which stops belong in each group. ## Why your number won’t match the headlines Published figures answer different questions, so none of them prices an hour in your plant. - **Siemens’ 2024 report** puts a lost hour at $36,000 in fast-moving consumer goods and $2.3 million at a large automotive plant.[1] It rests on 181 online interviews with maintenance, engineering and IT staff at large industrial organizations, from April 2019 to March 2023.[1] - **NIST’s survey of US discrete manufacturers** found unplanned downtime averaged 7.8% of planned production time in 2016.[2] NIST valued the downtime caused by maintenance issues at $18.1 billion, as the labor, energy and capital that sat idle, and counted $100.2 billion of lost sales from delays and defects separately.[2] Use a published figure to check your order of magnitude, never as an input. A survey of large plants knows nothing about your margin, crew or bottleneck. Before you quote any figure, check who was surveyed, how many, and what the number counts. ## Price downtime from measured stops The formula needs two inputs from the floor: hours stopped by reason, and the number of stops. A SenseAi sensor on each machine detects every stop in seconds from vibration and sound, with no PLC connection, and operators put a reason on it in a tap. Routine stops, such as short stops and shift starts and ends, can be classified by [automatic rules](/docs/monitoring/auto-downtime-rules/). The [Downtimes report](/docs/monitoring/downtimes/#pareto) ranks reasons by the hours they cost, by machine and by interval, and exports one row per stop to CSV, which is the input for the table above. Datwyler’s injection molding plant reviews the report week over week and month over month, and cut shift-changeover downtime by 50% in six months, as [Datwyler’s story](/customers/datwyler/) describes. See how it works on [downtime tracking](/solutions/downtime-tracking/). ## Price your first hour this week 1. **Pick the bottleneck.** Start with the machine or line whose stops delay shipments. Its stops are the ones that lose margin. 2. **Get margin per unit from finance.** Ask for contribution margin per part, and ask whether it subtracts direct labor. The answer decides whether the idle crew line belongs in your formula. 3. **Measure the real run rate.** Count units over a full shift of running time and divide by the running hours. Use that rate, not the nameplate speed. 4. **Add crew and repair rates.** Multiply the crew on the line, and the technicians on a typical repair, by their loaded hourly rates. 5. **List event costs by reason.** For each of your top reasons, note the parts and restart scrap one stop costs. Most reasons carry none, and a few carry most of it. 6. **Multiply by a month of stops.** Take the hours and stop counts for each reason from your downtime records, price each reason, and rank them by dollars. Then use the hourly rate to [price a fix](/blog/reduce-machine-downtime/#levers) before you buy it. For example, a $1,500 spare filler part kept on the shelf pays for itself the first time it saves a 36-minute wait for a delivery on the example line, because 0.6 × $2,523.10 = $1,513.86. ## Questions ### Should fixed overhead go into the cost of downtime? No, not when you price a stop. Rent, depreciation, insurance and salaried overhead run by the calendar, so a stop adds nothing to them. They answer a different question, what a machine costs to own, and they belong in the shop rate you quote. Adding them to the hourly downtime figure counts the same dollars twice. ### What if I don’t know my contribution margin per part? Start from price less material and packaging, which purchasing records hold, and leave the idle crew line out, because that margin still contains the crew’s pay. The two methods give nearly the same answer. Replace the estimate with your finance team’s figure when you have it, and ask whether that figure subtracts direct labor. ### Does planned downtime have a cost? Yes, on a bottleneck. A planned changeover or preventive maintenance job takes hours the line could have run, and on a machine with orders waiting those hours cost margin. Price them with the same hourly rate, then weigh that cost against what skipping the work would cause, such as longer breakdowns or more scrap. ### What is the average cost of downtime per hour? No average transfers to one plant. A Siemens survey of large industrial organizations reports $36,000 an hour in fast-moving consumer goods and $2.3 million in large automotive plants. Your figure depends on your margin per unit, run rate, crew and whether the machine is the bottleneck, so calculate it with the formula instead. ## Sources 1. [The True Cost of Downtime 2024](https://assets.new.siemens.com/siemens/assets/api/uuid:1b43afb5-2d07-47f7-9eb7-893fe7d0bc59/TCOD-2024_original.pdf), Siemens, accessed Oct 16, 2026 2. [Economics of Manufacturing Machinery Maintenance: A Survey and Analysis of U.S. Costs and Benefits (NIST AMS 100-34)](https://nvlpubs.nist.gov/nistpubs/ams/NIST.AMS.100-34.pdf), National Institute of Standards and Technology, accessed Oct 16, 2026 3. [Employer Costs for Employee Compensation, Table 4: Private industry workers by occupational and industry group, June 2026](https://www.bls.gov/news.release/ecec.t04.htm), U.S. Bureau of Labor Statistics, accessed Oct 16, 2026 4. [Overtime Pay](https://www.dol.gov/agencies/whd/overtime), U.S. Department of Labor, Wage and Hour Division, accessed Oct 16, 2026 --- # Measure changeover time before you try to cut it Source: https://www.iotflows.com/blog/measure-changeover-time/ Time changeovers from last good part to first good part, log internal and external work, and compare by type and median. A worked mold change shows how. > Question: How do I measure changeovers so the numbers are fair and comparable? ## Key takeaways - Changeover time runs from the last good part of the old run to the first good part of the new one. - A machine restart doesn't end a changeover, because run-up and first-article approval still belong inside it. - Log each element as internal or external, since moving internal work outside the stop shortens a changeover without new tooling. - Compare changeovers only within one type and direction, using the median of at least 10, never the mean or the best run. - Report the median per changeover, the number of changeovers and the weekly total together, because shorter changeovers can bring more of them. You measure changeovers fairly by timing each one from the last good part of the old run to the first good part of the new one, logging every element as internal or external, and comparing only changeovers of the same type by their median. Those three rules turn a stopwatch reading into a baseline you can compare across shifts, machines and months before you change anything. This guide is for plant managers and process engineers starting a changeover reduction project, or running one and unsure whether it worked. It times one mold change element by element, then builds the comparison and the weekly loss from it. To see where changeover ranks against your other losses first, build a [downtime Pareto from real minutes](/blog/downtime-pareto/). ## What counts as changeover time? > **Definition.** **Changeover time** is the time elapsed between the last piece of the run just completed and the first good piece after the changeover, so it includes the swap, the adjustments and every trial part made before one passed. The wording follows the Lean Enterprise Institute's lexicon, which treats *changeover* and *setup* as one thing: switching a machine or a line from one part number to another by changing parts, dies, molds or fixtures.[1] The definition matters for what it includes. The clock doesn't stop when the machine restarts. It stops when a part passes, so purge shots, first-article inspection and the adjustments between them all sit inside it. OEE counts those two halves in different places. Setup and adjustment time is an availability loss, and defective parts made between startup and stable production are a quality loss, most often tracked after changeovers.[3] The [OEE calculation guide](/blog/how-to-calculate-oee/) works through both factors on one shift. Figure: A timeline of one mold change. The machine is stopped for 72 minutes after the last good part, then runs for 14 minutes of purge and trial shots before the first good part, so changeover time is 86 minutes. *The machine restarts at minute 72, but the changeover ends at minute 86. Sample data.* In this example the machine stands still for 72 minutes, then runs for 14 more before a part passes. A machine monitor records the 72 minutes as downtime. The changeover took 86. ## Choose a start and a stop rule Write down where the clock starts and stops before the first measurement, and use the same rule on every machine of a type. Four rules are in common use, and each one hides something. | Rule | Clock starts | Clock stops | What it leaves out | |---|---|---|---| | Stopped time | Machine stops | Machine restarts | Run-up and first-article approval | | Last good to first good | Last good part, old run | First good part, new run | Nothing on the machine | | Back to full rate | Last good part, old run | Machine reaches full rate | Nothing, but adds slow running | | Job clock | Operator clocks off old job | Operator clocks on new job | Anything outside the clock-ins | Use last good part to first good part as your changeover time. Record the restart as well, so every changeover splits into stopped time and run-up. The split tells you where to work: a long stopped time is a swap problem, and a long run-up is a settings or first-article problem. The stop and the restart come from machine data or a stopwatch. The first good part comes from whoever approves it: the first-article sign-off, the quality technician's release, or the first part logged as good. Name that event for each machine type, since a molder's first good shot and a CNC's approved first article are signed off by different people. > **When to time back to full rate** > > Add back-to-full-rate as a second number when a machine ramps up slowly after a changeover, such as a filler that restarts at half speed and climbs to 120 bottles a minute over 20 minutes. Report it beside changeover time, never in place of it. You don't need it on a CNC mill, which runs at full rate from the first approved part. ## Log each element as internal or external > **Definition.** **Internal setup** is changeover work that can be done only while the machine is stopped, such as unclamping a die, while external setup is work done while the machine is still running, such as staging the next die beside the press. Separating the two, then moving internal work outside the stop, is the first move of SMED (single-minute exchange of die). Its target is a changeover in single-digit minutes, under 10.[2] You can't separate work you haven't logged, so the timing sheet comes first. Observe a typical changeover, film it if the crew agrees, and finish with a table of the steps, their sequence and their duration.[4] An *element* is one piece of work with a clear start and end, such as "disconnect water lines". With more than one person on the changeover, add a column for who does each element, so two people working side by side aren't counted as twice the machine time. #### Worked example: A mold change on a 300-ton injection molding machine, before | Element | Minutes | Machine state | Could it be external? | |---|:---:|---|---| | Fetch next mold from storage | 18 | Stopped | Yes, stage it before the stop | | Disconnect water and heaters | 6 | Stopped | No | | Unclamp and lift out old mold | 9 | Stopped | No | | Hang and clamp new mold | 12 | Stopped | No | | Connect water and heaters | 7 | Stopped | No | | Heat mold to temperature | 20 | Stopped | Yes, preheat it off the press | | Purge and trial shots | 14 | Running, no good parts | No | | Return old mold to storage | 10 | Running, good parts | Already external | Stopped time is 18 + 6 + 9 + 12 + 7 + 20 = 72 minutes. Run-up adds 14, and it counts as internal, because the press runs but makes no good parts. The old mold goes back to storage after the first good part, so its 10 minutes are external. **Result:** Changeover time = 72 + 14 = 86 min The sheet shows two elements that don't need a stopped machine. Stage the next mold beside the press and preheat it before the stop, and both leave the changeover. Internal time falls to 6 + 9 + 12 + 7 + 14 = 48 minutes. Figure: Two bars of 96 minutes of changeover work. Before, 86 minutes are internal and 10 external. After staging and preheating the mold, 48 are internal and 48 external, so changeover time is 44.2% shorter. *The crew still does 96 minutes of work; only 48 of them now stop the machine. Sample data.* That 44.2% cut is invisible in a single stopwatch total, because the crew's work stayed at 96 minutes. Only the element log shows which minutes moved. The counting side of a mold change, re-picking the operation so shots land on the new part, is covered in [monitoring injection molding machines](/blog/monitor-injection-molding-machines/). ## Compare like with like A changeover number compares only with changeovers of the same type. A 15-minute color change and a 90-minute mold change averaged together describe neither. Put every changeover under a type before you compare anything. | Type | Example | Compare it with | |---|---|---| | Shift changeover | Crew handover at 2 pm | Same machine, same shift pair | | Material change | Resin color change on a molder | Same from and to material | | Mold or die change | Die swap on a 350-ton press | Same die family | | Size or format change | Bottle size change on a filler | Same from and to size | | Job change on a CNC | New fixture on a Haas VF-2 | Same fixture type | A *shift changeover* changes the crew, not the part. Track it as its own type, because its fix is the [handover](/blog/downtime-root-cause-review/#five-whys), not the tooling. Give each type its own reason code so the minutes never mix, using a [short list of downtime reason codes](/blog/downtime-reason-codes/). Inside a type, direction matters. A molder going from black resin to white purges longer than one going from white to black, so log the from and the to as well as the type. Then use the median, not the mean, and never the best run. One changeover that ran into a breakdown drags the mean for weeks. Split that stop at the moment the breakdown began, so the changeover keeps its minutes and the breakdown keeps its own, as in [splitting a downtime](/docs/monitoring/classify-downtime/#split). #### Worked example: Ten die changes on one 350-ton press - Minutes: 42, 45, 47, 48, 50, 51, 53, 55, 58 and 131. - The 131-minute stop held a die crack: 52 minutes of changeover, then 79 minutes of breakdown. Before the split, the mean is 580 ÷ 10 = 58.0 minutes and the median is (50 + 51) ÷ 2 = 50.5 minutes. After the split, the ten changeovers total 501 minutes, so the mean is 501 ÷ 10 = 50.1 minutes. The median stays at 50.5. **Result:** One mixed stop moves the mean by 7.9 min and the median by 0 Figure: Ten die change times from 42 to 131 minutes on one axis. The median sits at 50.5 minutes and the mean at 58.0, pulled right by a 131-minute stop that held a die crack. *One stop that held a breakdown pulls the mean 7.5 minutes past the median. Sample data.* Collect at least 10 changeovers of a type before you call it a baseline, and report the range beside the median. Ten die changes from 42 to 58 minutes say the method is steady. Ten from 20 to 90 say there's no standard method yet, and that's the first thing to fix. > **Don't rank crews on one changeover** > > A changeover time measures the method, the tooling and the crew together. Compare crews only on the same type and direction, over 10 or more changeovers each. Share the element sheet with the crew before you share the numbers: a crew that helped time the elements rarely disputes the result. ## Turn changeovers into a weekly loss The weekly loss adds up every changeover minute, overruns included, so it uses the mean. The median judges the method; the mean prices it. **Weekly changeover loss** = Changeovers per week × mean changeover time #### Worked example: The 350-ton press over one week - Changeovers: 12 die changes a week at a mean of 50.1 minutes, after splitting out breakdowns. - Scheduled time: 2 shifts × 5 days × 8 hours = 80 hours. Weekly loss is 12 × 50.1 = 601.2 minutes, or 10.02 hours. As a share of scheduled time, that is 10.02 ÷ 80 = 12.5%. **Result:** Changeovers take 10.0 h a week, 12.5% of scheduled time State the loss as a share of scheduled hours whenever you compare weeks. A four-day week has fewer changeovers and fewer hours, and only the share tells you whether anything improved. Marking changeovers as [planned downtime](/docs/get-started/glossary/#planned-downtime) labels them; it doesn’t take them out of this loss. Under the common OEE convention, which [planned vs unplanned downtime](/blog/planned-vs-unplanned-downtime/#changeovers) sets out, a scheduled changeover still counts against availability, and it still takes 10 hours the press could have run. ## Prove a fix with before and after Compare the same type, the same direction and the same start and stop rule, with at least 10 changeovers on each side. Then report three numbers, not one: the median per changeover, the number of changeovers and the weekly total. The three can move in different directions. Shorter changeovers make smaller lots affordable, and smaller lots mean more changeovers. #### Worked example: Shorter changeovers, smaller lots - Before: 12 die changes a week at a mean of 50 minutes, so 12 × 50 = 600 minutes. - After staging dies and preheating them: a mean of 30 minutes. The planner halves lot sizes, so the press runs 24 die changes a week: 24 × 30 = 720 minutes. Per changeover, the change is (50 − 30) ÷ 50 = 40.0% shorter. Per week, changeover takes 720 − 600 = 120 minutes more. **Result:** 40.0% shorter per changeover, 20.0% more changeover minutes per week Neither number is wrong. The shorter changeover bought smaller lots and less inventory, and the plant chose to spend it that way. Judge the method by the median per changeover, and judge capacity by the weekly total and its share of scheduled hours. Keep measuring after the fix. A changeover that falls from 86 to 48 minutes in week one and drifts back to 70 by week eight has lost its new standard, not its method. Watch the weekly median for at least eight weeks after any change. ## Measure changeovers automatically A sensor on each machine records the stopped part of every changeover without a stopwatch. IoTFlows [downtime tracking](/solutions/downtime-tracking/) detects each stop from that sensor, with no PLC connection, and the operator tags it with a changeover reason in a tap. Turn on the shift-edge rules, and stops at the start and end of a shift [classify themselves](/docs/monitoring/auto-downtime-rules/#start-of-shift). Assign every part a machine runs, so counts [move to the new part at the changeover](/docs/production/auto-detect-operations/). The Downtimes report trends each reason by week. Its CSV [export carries one row per stop](/docs/monitoring/downtimes/#csv), so you compute the median and range per type in a spreadsheet. Datwyler's injection molding plant classifies stops this way and reviews the report weekly and monthly. It cut shift-changeover downtime by 50% and material-changeover downtime by 30% within six months, as [Datwyler's story](/customers/datwyler/) describes. [Criollos Foods](/customers/criollos-foods/) cut average product setup and changeover time by 20 minutes. ## Set up your first baseline 1. **Write the rules down.** Use last good part to first good part, name who signs off the first good part on each machine type, and post both at the machines. 2. **Create one reason per type.** Add a reason for each changeover type in the comparison table, and nothing broader than that, so no two types share minutes. 3. **Time two changeovers by element.** Fill in the timing sheet on your most frequent type, filmed if the crew agrees, and mark each element internal or external. 4. **Log every changeover.** For each one, record the stop, the restart, the first good part, the type, the from and the to, and anything else that went wrong inside the stop. 5. **Split and compute.** Split any changeover that ran into a breakdown. Once a type has 10 changeovers, compute its median, range and weekly total. 6. **Raise alert thresholds above the median.** Set each machine's downtime alert above the median of the changeover type it runs most, so a normal changeover pages nobody. See [setting the alert threshold](/docs/alerts/quickstart/#threshold). 7. **Pick the first type to cut.** Choose the type with the largest weekly total, not the longest single changeover, and start moving its internal elements outside the stop. ## Questions ### Does changeover time count against OEE? Yes, in two places. The stopped part of a changeover is an availability loss, and the parts scrapped during run-up are a quality loss. A plant that marks changeovers as planned downtime and removes them from planned production time reports a higher availability, so state your convention whenever you compare OEE between plants or machines. ### Is a stopwatch enough, or do I need video? A stopwatch gives you the total and the restart. Video gives you the elements, which is where the savings are, because you can replay a step and see the walking, waiting and searching nobody remembers afterward. Film one or two changeovers of each type with the crew's agreement, then time the rest with a stopwatch or machine data. ### How many changeovers do I need for a baseline? Collect at least 10 changeovers of one type, timed with the same start and stop rule, and report the median with the range. Fewer than 10 lets one unusual changeover set the baseline. A wide range, for example 20 to 90 minutes, says the crew has no standard method yet, and that is the first thing to fix. ### Should changeover time include cleaning and sanitation? Include it when the cleaning happens with the machine stopped between two products, because it takes the same capacity as the mechanical swap. Log it as its own element or its own changeover type, so a food plant can see cleaning minutes apart from swap minutes and shorten each with its own method. ## Sources 1. [Changeover](https://www.lean.org/lexicon-terms/changeover/), Lean Enterprise Institute, accessed Oct 16, 2026 2. [Single Minute Exchange of Die (SMED)](https://www.lean.org/lexicon-terms/single-minute-exchange-of-die/), Lean Enterprise Institute, accessed Oct 16, 2026 3. [Six Big Losses](https://www.oee.com/oee-six-big-losses/), Vorne Industries (OEE.com), accessed Oct 16, 2026 4. [SMED 2.0: A Changeover for the Changeover](https://www.allaboutlean.com/smed-2-0/), AllAboutLean (Christoph Roser), accessed Oct 16, 2026 --- # How to monitor an old machine with no network port Source: https://www.iotflows.com/blog/monitor-old-machines-without-a-plc/ A sensor on the frame reads running, stopped and every cycle from outside, so a 30-year-old machine with no port reports uptime and part counts like a new one. > Question: Can I get uptime and part counts from a 30-year-old machine? ## Key takeaways - Uptime and part counts come from what a machine physically does, so a 30-year-old machine can report them like a new one. - A vibration sensor on the frame or a beam counter at the part exit needs no wiring into the machine. - Calibrate against the machine powered on and idle, because old pumps and flywheels keep vibrating between cycles. - Validate the count against a hand count before you trust a shift total, and fix a double or half count with the parts per cycle. - Connect the control only for what it alone knows, such as alarm codes, and plan an IT review before you do. Yes, you can get uptime and [part counts](/blog/part-counting-methods/) from a 30-year-old machine, because both come from what the machine physically does, not from its control. A sensor on the frame feels every cycle and every stop. A 1994 punch press with relay logic and no network port then reports the same running, stopped and count data as a press built last year. This guide is for owners and plant managers whose oldest machines carry the most hours and report nothing. It covers where a signal can come from, where to mount on four common old machines, one worked shift on a 1994 press, and when the control is worth connecting. ## What an old machine can report without a port > **Definition.** **Legacy machine** means production equipment built before machines shared data over a network, such as a relay-logic press, a manual knee mill or an early CNC with only a serial port, which still runs parts but has no interface a monitoring system can read. Plants keep these machines for a reason. A 2018 study in the Transactions of the JSME notes that legacy machines without network capability stay in use because the average useful life of machine tools is more than 20 years.[2] Most of what a plant manager asks about a machine never needed the control in the first place. Whether it runs, how long it stopped and how many cycles it made are physical events. The control only adds what it alone holds. | | Sensor outside | Control connection | |---|---|---| | Running or stopped | Yes | Yes | | Uptime and downtime | Yes | Yes | | Cycle and part counts | Yes | Where the control counts | | Cycle time per part | Yes | Yes | | Alarm codes | No | Yes | | Program or recipe name | No | Yes | | Works with no network port | Yes | No | Kentucky's MEP center describes the same split for legacy machines. Basic monitoring uses sensors that show whether machines are running, idle or stopped, and intermediate monitoring adds throughput and cycle counts.[3] > **Definition.** **Uptime** is the share of a time window a machine spent running: running time divided by running time plus stopped time. Time with no data, such as a sensor that lost power, counts in neither term. Uptime is availability, the first factor of OEE, and the [glossary entry for uptime](/docs/get-started/glossary/#uptime) gives the exact calculation. Part counts feed the second factor, performance. ## Why machine age doesn't change the signal A running machine vibrates and makes sound, and every cycle repeats a pattern. A spindle under load, a ram hitting a die and a clamp closing on a mold each leave a signature on the frame. A sensor on the outside reads that signature whatever sits in the cabinet: relays, a 1990s PLC or a modern control. Purdue's MEP makes the same point for older equipment: monitoring the amperage a device draws, or its vibrational noise during operation, lets algorithms determine a machine's status and track production automatically.[4] A 2016 NIST paper on low-cost ambient sensors puts it more plainly: older machines can be retrofitted with new sensors.[6] Here is what that looks like on a hypothetical 1994 mechanical press, coil-fed at 30 strokes a minute. Figure: A vibration trace over 20 minutes on a 1994 press: off for 2 min, flywheel idle for 3 min, strokes for 6 min, a 4 min coil change at idle, then strokes for 5 min. The threshold sits above idle, so 330 strokes count in 11 running minutes. *Each stroke rises above the running threshold; the flywheel turning on its own stays below it. Sample data.* Each stroke is a sharp burst well above the rest of the trace. Count the bursts and you have the stroke count. On a press, one stroke is one cycle, so the stroke count is the cycle count. The part to get right on an old machine is the idle level. A mechanical press keeps its flywheel turning between strokes, and an old hydraulic machine runs its pump whenever it is powered. Both vibrate when nothing is being made. > **Calibrate against powered idle, not off** > > Set the stopped level with the machine powered on and not working, not switched off. A threshold set slightly above a dead machine reads a turning flywheel or a running pump as production, and the machine shows as running all shift. The [stopped baseline steps](/docs/hardware/calibrate-senseai/#stopped) walk through the capture. Between two strokes the trace dips back toward idle for about a second. *Short-stop handling* counts any stop under a cutoff as running time. Set the cutoff above that gap and below the shortest stop you want in the record, such as 2 minutes on this press, or a normal stroke rhythm logs as hundreds of one-second stops. ## Four ways to read an old machine A machine with no port gives you four places to read it. Two sit outside the machine and two sit inside its cabinet or controls. Figure: A 1994 machine with four tap points. Inside: a current clamp on the motor feed and a wired stack-light signal at the relay panel. Outside: a vibration sensor on the frame and a beam counter across the part exit. *Two taps open the cabinet or the controls; the two outside taps attach with no wiring into the machine.* | Method | Attaches to | Wiring into the machine | What it reads | |---|---|---|---| | Vibration sensor | Frame, near the drive | None | State, cycles, cycle times | | Beam counter | Part exit or chute | None | Parts, rate, state from gaps | | Current clamp | One motor conductor | Cabinet opened | State, cycles on many machines | | Wired signal | Stack light or relay contact | Wired into the controls | State, cycles if a relay marks them | Every method above reads the machine without its control. None of them reads alarm codes or program names. ### Outside the machine A *vibration sensor* mounts magnetically on a steel casting tied to the drive and reads running, stopped and each cycle from the trace. A *beam counter* aims a laser or light beam across the part exit and counts each part that breaks it; the gap between parts says whether that point is moving. Both come off with no trace left on the machine. On a line, a counter at every step gives yield and the step that stopped first, as [production line monitoring without PLCs](/blog/production-line-monitoring-without-plcs/) shows. ### Inside the cabinet or controls A *current clamp* closes around one conductor of the motor feed, and the current it measures rises when the motor works. Research supports the method: a 2025 paper counted CNC parts from total current alone at about $40 per machine, with 96.2% overall accuracy against manually logged production data.[5] The clamp sits in the electrical cabinet, beside live conductors. OSHA allows only qualified persons to work on electric circuit parts or equipment that have not been deenergized.[7] In practice that means an electrician's visit or a machine shut down for the install. Current also varies with the job: the JSME study found that a fixed threshold must be reset often in a high-mix shop, because the drill and the cut change with each order.[2] A *wired signal* takes a contact from the stack light or a relay that closes on each cycle. It reads exactly what the machine's own logic reports, no more. A stack light that only shows green for "power on" tells you nothing about cycles. ### Which method fits Default to a vibration sensor on the frame. It reads state and cycles on most machines, needs no electrician and comes off in seconds. - **Choose a beam counter** when parts leave single file down a chute or conveyor and you want parts made, not cycles run. - **Choose a current clamp** when the frame is quiet compared with the machine's surroundings and an electrician is already scheduled in the cabinet. - **Choose a wired signal** when the machine already has a relay that closes once per cycle and your maintenance team is comfortable wiring into its controls. You don't need a [control adapter](/blog/machine-communication-protocols/#mtc-flow) to answer uptime and part counts. AMT's MTConnect use case notes that for most legacy machines you will need a computer to translate machine data to the standard, and that devices designed without MTConnect in mind will always require a custom adapter.[1] That is a project per machine; mounting a sensor on the frame takes minutes. ## Where to mount on four common old machines The rule is the same on every machine: flat ferrous metal, mechanically tied to the parts that move, out of the way of chips and the operator. A guard door holds a magnet but rings on its own, so the trace looks the same running and stopped. The [mounting guide](/docs/hardware/install-senseai/#mounting) covers the spots that fail. | Machine | Mount on | What to count | Watch for | |---|---|---|---| | Mechanical punch press | Frame beside the ram | Each stroke | Flywheel idle; double ring | | Hydraulic press or molder | Near the pump or injection unit | Each cycle | Pump runs at idle | | Manual knee mill or lathe | Head casting or headstock | Running time first | Operator pauses mid-part | | Early CNC, serial port only | Spindle housing | Each machining cycle | Guard door mounts | How a cycle turns into a count depends on the trace's shape. A press stroke is one sharp event, a [CNC cycle](/blog/cnc-cycle-time-and-part-counts/#from-outside) is one burst with quiet either side, and a molder holds its signal through the whole cycle. The [algorithm guide](/docs/production/choose-an-algorithm/#choose) settles it in one question: does the signal fall back to the stopped level between parts? A manual machine needs a different expectation. The spindle runs or it doesn't, so uptime is reliable from the first shift. A part is whatever the machinist does, so count from the trace only on repeat work where every part follows the same pattern of cuts. Two checks catch a bad mount early. Run the machine working, then idle, and confirm the two read differently. Then compare one hour's cycle count with the machine's own mechanical counter or a tally, before anyone reads a report. ## One shift on a 1994 press The numbers below follow a hypothetical 1994 mechanical press through one shift. It stamps steel brackets from coil with a two-out die, so each stroke makes two parts. #### Worked example: One 8-hour shift on a coil-fed press at 30 strokes a minute - Shift: 480 minutes with a 30-minute lunch, so the machine is scheduled for 450 minutes. - Stops read by the sensor: a 40-minute die change, three 10-minute coil changes and 65 minutes of jams and waiting for material, 135 minutes in all. - Running time: 450 − 135 = 315 minutes. - Strokes counted: 9,135. At 30 strokes a minute, 315 running minutes allow 315 × 30 = 9,450. Uptime is 315 ÷ 450 = 70%. The press made 9,135 ÷ 9,450 = 96.7% of the strokes its running time allows. With 2 parts per stroke, output is 9,135 × 2 = 18,270 brackets. **Result:** Uptime 70%, 9,135 strokes, 18,270 brackets At 70%, this coil-fed press sits inside the 65 to 80% band that the [press uptime table](/docs/production/stamping-presses/#expectations) gives for auto feed from coil. The bigger finding is the 65 minutes of jams and waiting. Nobody logged those minutes before, because nobody stood at the press timing them. Validate the count before anyone acts on it. Over a 10-minute window, the press's mechanical stroke counter advanced 296 and the sensor counted 294, which is 294 ÷ 296 = 99.3%. If the report had shown 9,135 brackets instead of 18,270, the sensor would still be right. A count at exactly half or double the real output is the parts-per-cycle setting, not the detector, and [troubleshooting part counts](/docs/production/troubleshoot-part-counts/#start) covers the fix. ## When the control is worth connecting An outside sensor answers what the machine did. A few questions need what only the control holds: which alarm stopped the machine, which program ran slow, what a hydraulic pressure read during a bad hour. On a 30-year-old machine, the control may hold none of it in a form anyone can read. AMT's use case says it directly: if there is no way to extract data from the equipment, implementing the MTConnect standard would be impractical.[1] On a machine whose control can share data, a connection to it is a security concern for many plants, so plan an IT review into the project. Connect the control when a recurring question depends on it, on the machines where it does, and keep a sensor on every machine for the common numbers. For CNC fleets that mix old and new controls, [monitoring CNC machines of any age](/blog/how-to-monitor-cnc-machines/) covers what MTConnect adds. The [sensor-based versus PLC comparison](/compare/sensor-based-vs-plc-machine-monitoring/) sets out what each approach reads, with its sources. ## Monitor old machines with IoTFlows IoTFlows puts a SenseAi on each machine: a magnet-mount sensor that reads vibration and sound from the outside and decides running or stopped every second on the device. It attaches magnetically in seconds and calibrates in under five minutes, with no wiring and [no connection to the PLC](/docs/get-started/faq/#plc), and lifting it off undoes the install. Old and new machines then report the same uptime, downtime and part counts, as [retrofit machine monitoring](/solutions/retrofit-machine-monitoring/) shows. [Sorinex](/customers/sorinex-exercise-equipment/) installed SenseAi sensors across its critical production equipment in under 5 days. > The speed of implementation was remarkable. We went from limited visibility to complete operational transparency in less than a week. We're now identifying inefficiencies we didn't even know existed. IoTFlows has fundamentally changed how we approach manufacturing optimization. > > Kyle Simpson, Operations Manager, Sorinex ([story](https://www.iotflows.com/customers/sorinex-exercise-equipment/)) ## Start with your oldest machine 1. **Pick the machine with the least data.** Choose the old machine that carries the most hours and that nobody can answer questions about, such as the press everyone says runs “most of the shift”. 2. **Find a mount point.** Look for flat steel on the frame, tied to the drive, away from guards, chips and the operator's reach. 3. **Calibrate running and powered idle.** Capture the machine working through several full cycles, then powered on and idle, and set the stopped level above the idle floor. 4. **Decide how a cycle becomes a count.** Match the count method to the trace's shape, and set the parts each cycle makes, such as 2 for a two-out die. 5. **Validate against a hand count.** Compare the count with the machine's mechanical counter or a tally over a fixed window, and fix any exact double or half. 6. **Read a week of stops.** After five shifts, rank the stopped time by cause, and start with the largest block nobody was logging before. ## Questions ### Does mounting a sensor on the outside change anything on the machine? No. A magnet-mounted sensor sits on the frame with no connection to the control, the relays or the wiring, so it cannot change a setting, a sequence or a program. Lifting it off leaves the machine exactly as it was, which makes it a safe first step on a machine you cannot afford to modify. ### What if there is no steel surface near the drive? A magnet needs ferrous metal, so aluminum covers, plastic guards and rubber pads give it nothing to hold. Look for another steel casting tied to the drive, such as the motor mount, the headstock or the base. When none is reachable, count parts at the exit with a beam counter, which needs no surface on the machine at all. ### Can I count parts on a manual lathe or knee mill? Running time is reliable from the first day, because the spindle either turns or it does not. Part counts depend on whether each part repeats the same pattern of cuts. On a repeat job the cycle shows in the vibration trace and can be counted; on one-off work, log the count at the machine and let the sensor carry the time. ### Do I need Wi-Fi at the machine? The sensor needs a way to reach the internet from where it is mounted. Old machines often sit at the far end of a building where plant Wi-Fi is weak. A cellular router placed near the cell gives the sensors their own network and keeps them off the plant network. Check the signal at the mount point before you commit to it. ## Sources 1. [Digital Manufacturing for Legacy Equipment Using a Standards-Based Approach: An MTConnect Use Case](https://www.amtonline.org/article/digital-manufacturing-for-legacy-equipment-using-a-standards-based-approach), AMT, The Association For Manufacturing Technology, accessed Oct 16, 2026 2. [Method for recognizing operation statuses of metal cutting machine tools using spindle motor current](https://www.jstage.jst.go.jp/article/transjsme/84/860/84_17-00432/_article/-char/en), Transactions of the JSME (Japan Society of Mechanical Engineers), J-STAGE, accessed Oct 16, 2026 3. [Enhance Your Existing Equipment with Machine Monitoring](https://louisville.edu/servicecenters/news/enhance-your-existing-equipment-machine-monitoring), University of Louisville Service Centers (Kentucky MEP), accessed Oct 16, 2026 4. [Is Legacy Equipment Slowing You Down?](https://mep.purdue.edu/news-folder/is-legacy-equipment-slowing-you-down/), Purdue Manufacturing Extension Partnership, accessed Oct 16, 2026 5. [Part fingerprinting-based productivity monitoring of CNC machines with low-cost current sensors](https://par.nsf.gov/biblio/10632342), The International Journal of Advanced Manufacturing Technology, via NSF Public Access Repository, accessed Oct 16, 2026 6. [Machine Condition Detection For Milling Operations Using Low Cost Ambient Sensors](https://www.nist.gov/node/1268861), National Institute of Standards and Technology, accessed Oct 16, 2026 7. [1910.333, Selection and use of work practices](https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.333), Occupational Safety and Health Administration, accessed Oct 16, 2026 --- # How to set ideal cycle time, and what it does to OEE Source: https://www.iotflows.com/blog/ideal-cycle-time/ The ideal cycle time sets OEE performance and the shift goal. Learn who should own it, how to time it, and what a 10% error does to every number built on it. > Question: Who sets the ideal cycle time, and what happens to OEE if it is wrong? ## Key takeaways - Ideal cycle time is the best cycle an operation sustains in good conditions, set per operation and per machine. - OEE moves in direct proportion to the ideal cycle time, so an ideal 10% too fast cuts OEE by 10%. - An ideal set too fast lowers performance and raises the shift goal; one set too slow hides real speed loss. - Time 10 to 20 consecutive cycles on a good day and enter the average of the uninterrupted ones. - Change an ideal cycle time only when the process changes, never to make a goal reachable. The manufacturing or process engineer who owns the operation should set the ideal cycle time, from [cycles timed at the machine](/blog/what-is-cycle-time/) on a good day. When it is wrong, OEE is wrong by the same proportion: an ideal 10% too fast cuts reported performance and OEE by 10% and raises the shift goal by 11%, on a shift where nothing on the floor changed. This guide is for engineers and plant managers who set these numbers or inherit them. It works one hypothetical shift through four different ideals, compares the bases you can set an ideal from, and ends with an audit you can run this week. ## What is ideal cycle time? > **Definition.** **Ideal cycle time** is the time one cycle of an operation takes when the machine runs at the best speed the process sustains in good conditions, set separately for each operation on each machine as the yardstick for OEE performance. A *cycle* is one repeat of the operation, from the same point to the same point. One cycle can make more than one part: a 4-cavity mold makes four parts per shot, so its ideal is stated per shot and the parts per cycle are a separate number. The [glossary entry for cycle time](/docs/get-started/glossary/#cycle-time) lists the three cycle-time figures a monitoring system shows. Vorne’s OEE primer defines the ideal as the fastest cycle time your process can achieve in optimal circumstances.[1] The word that matters is *process*: the ideal belongs to one operation on one machine, not to the part or the machine alone. For example, the same bracket can have a 90-second ideal on a 5-axis machining center and a 140-second ideal on an older 3-axis mill. Four different numbers get called a cycle time on the shop floor, and each one has a different job. | Number | Where it comes from | What it is for | |---|---|---| | Ideal cycle time | Set by engineering, per operation | The yardstick for performance and goals | | Actual cycle time | Measured at the machine, every cycle | What the machine really did | | Routing standard | The router, BOM or quote | Costing, quoting and planning | | Takt time | Available time ÷ customer demand | The pace demand requires | The Lean Enterprise Institute defines cycle time as the time to produce a part or complete a process, as timed by actual measurement,[3] and takt time as available production time divided by customer demand.[4] Keep the four apart. A plant that types its routing standard into the ideal field measures the machine against its own quote, and a plant that types takt measures it against demand. ## What the ideal cycle time decides Four numbers are calculated from the ideal, and none of them can be more accurate than it. The first is *performance*, the OEE factor for speed: **Performance** = (Total count × ideal cycle time) ÷ (Run time) Vorne gives this form, along with a short form of OEE that skips the three factors entirely:[1] **OEE** = (Good count × ideal cycle time) ÷ (Planned production time) Read the second formula slowly. Good count and planned production time are facts about the shift, so OEE moves in exact proportion to the ideal. Change the ideal by 10% and OEE changes by 10%, with no change on the floor. The third number is the *shift goal*, the part count a shift is expected to finish. It divides the time the machine is expected to run by the ideal: **Shift goal** = (Shift duration − expected downtime) ÷ (Ideal cycle time) The fourth is the planned length of a job, which multiplies the other way. For example, 500 parts at a 90-second ideal is 12.5 hours of machine time. Figure: An ideal cycle time cut from 90 s to 81 s feeds four boxes: performance falls from 90.0% to 81.0%, OEE from 78.0% to 70.2%, the shift goal rises from 280 to 311 parts, and a 500-part job estimate drops from 12.5 h to 11.25 h. *An ideal set 10% fast moves every number calculated from it, with no change on the floor. Sample data.* Every second between the ideal and the actual cycle is booked as *reduced speed*, a performance loss in OEE’s six big losses.[2] Vorne lists dirty or worn equipment, poor lubrication, substandard material and operator inexperience among its common causes.[2] A wrong ideal adds a loss to that list that doesn’t exist, or deletes one that does. ## What a wrong ideal does to OEE Work one shift through with the ideal it should have, then change only the ideal. #### Worked example: One shift on a CNC machining center - Planned production time is 450 minutes. Run time is 400 minutes, so availability is 400 ÷ 450 = 88.9%. - Total count is 240 brackets, 234 of them good, so quality is 234 ÷ 240 = 97.5%. - While running, the machine averaged 100 seconds a part: 400 minutes × 60 ÷ 240. - The timed best sustainable cycle is 90 seconds, or 1.5 minutes. Performance is (240 × 1.5) ÷ 400 = 90.0%. **Result:** OEE = (234 × 1.5) ÷ 450 = 78.0% Now keep every fact about the shift and swap in the ideals a plant might have on file instead: | Ideal cycle | Source of the ideal | Performance | OEE | |---|---|---|---| | 80 s | Nameplate or CAM estimate | 80.0% | 69.3% | | 90 s | Timed, best sustainable | 90.0% | 78.0% | | 95 s | Timed, padded by 5 s | 95.0% | 82.3% | | 105 s | Routing standard | 105.0% | 91.0% | Hypothetical shift. Performance is total count × ideal ÷ run time. OEE is good count × ideal ÷ planned production time. Figure: Bars show performance for one shift under four ideal cycle times: 80 s gives 80.0% and OEE 69.3%, 90 s gives 90.0% and 78.0%, 95 s gives 95.0% and 82.3%, and 105 s passes the 100% line at 105.0% with OEE 91.0%. *The same 400 minutes of cutting reads 69.3% to 91.0% OEE, depending only on the ideal. Sample data.* The same shift reads anywhere from 69.3% to 91.0% OEE. Three things follow from the table. - **A too-fast ideal invents a speed loss.** At 80 seconds the shift shows 10 points of performance loss that nobody can find, because no cycle on this machine runs that fast. People chase it for a week, then stop trusting the gauge. - **A too-slow ideal hides one.** The 95-second ideal reads a plausible 95.0%, and nobody questions a 95. Only the 105-second row gives itself away by passing 100%, which Vorne says means the ideal cycle time is set incorrectly.[1] - **Availability and quality don’t notice.** The whole error lands in performance, so a plant comparing factors across machines with mixed bases sends its improvement effort to the [wrong factor](/blog/which-oee-factor-loses-most/#check-inputs). [How to calculate OEE](/blog/how-to-calculate-oee/) works all three factors through for a full shift, including the planned-time choices that move availability. ## What a wrong ideal does to the shift goal The goal moves the opposite way to performance, which is what makes a fast ideal expensive. Take an 8-hour shift with 60 minutes of expected downtime, so 420 minutes, or 25,200 seconds, of expected running. The machine from the example makes a part every 100 seconds, or 252 parts in that time. | Ideal cycle | Shift goal | Machine makes | Share of goal | |---|---|---|---| | 80 s | 315 parts | 252 parts | 80% | | 90 s | 280 parts | 252 parts | 90% | | 105 s | 240 parts | 252 parts | 105% | Hypothetical shift. Shift goal is 25,200 seconds ÷ the ideal cycle time. With an 80-second ideal, the goal is 315 and the machine falls behind from the first hour, every shift. Operators learn that the number is never green and stop looking at it. With a 105-second ideal, the machine reaches its goal of 240 with 20 minutes of running time to spare, and the last 12 parts feel like a bonus. Nobody looks for the 10 seconds a cycle that the machine loses against its real 90-second best. A fast ideal lowers performance and raises the goal at the same time, so the machine is penalized twice for one wrong number. Fix the ideal before you discuss the goal with anyone on the floor or [track the shift against it](/blog/production-monitoring-shift-goal/). The [shift goal reference](/docs/production/shift-production/#goals) shows how a monitoring system derives the goal from the ideal and the machine’s own downtime history. Planning uses the same number. A 500-part job planned at the 80-second ideal books 11.1 hours, and at the 100 seconds the machine really averages it needs 13.9. [Production scheduling on real run rates](/blog/production-scheduling-on-real-run-rates/) covers which rate to plan with. ## Which basis should you set it from? Four sources supply ideal cycle times, and each one errs in a predictable direction. | | Nameplate rating | Program or CAM time | Routing standard | Timed best sustainable | |---|---|---|---|---| | Comes from | The machine’s rated speed | The toolpath or program | Router, BOM or quote | Cycles timed at the machine | | Usual error | Too fast | Too fast | Either way | Small | | Performance reads | Low, the full gap to design speed | Low | Can pass 100% | Close to the real speed loss | | Fits | Fixed-rate lines and presses | Not an ideal | Costing and quotes | CNC, molding, manual cells | A program or CAM time leaves out acceleration, tool changes and probing, so the machine can’t match it. Vorne’s convention is the theoretical fastest time to make one part, the inverse of the speed it calls the ideal run rate or nameplate capacity.[2] That choice shows the full gap to design speed, which suits a line whose speed is set by a dial. On a machine whose cycle depends on the program, a theoretical ideal reports a performance loss nobody can act on. > **Nameplate rate or timed cycle?** > > Use the nameplate rate when the machine sets the pace and the rating is achievable: a filler rated at 120 bottles a minute, or a press run at a fixed stroke rate. Use a timed best sustainable cycle when the program, the mold or the operator sets the pace, which covers most CNC, molding and manual cells. Whichever you choose, use the same basis on every machine you compare. You don’t need a separate ideal per operator or per shift. The ideal describes the process, and the differences between operators are exactly what performance should show. ## Who should own the ideal cycle time? One person owns each ideal: the manufacturing or process engineer responsible for the operation. Others supply data or use the number, and none of them should edit it. | Role | Part in the ideal cycle time | |---|---| | Process or manufacturing engineer | Sets, approves and records each ideal | | Operator | Times cycles and flags a changed process | | Supervisor | Reads performance against it every shift | | Planner or estimator | Plans on measured rates | | Plant manager | Picks one basis for every machine | The ideal changes when the process changes, and only then. Use this table when someone asks to edit one. | Event | Change the ideal? | |---|---| | New program, toolpath or feeds | Yes: re-time after it settles | | New fixture, mold or die | Yes: re-time on the new tooling | | Operation moved to another machine | Yes: give that machine its own ideal | | Tool wear lengthens the cycle | No: the gauge is right, change the tool | | A mold cavity blocked off | No: change parts per cycle instead | | Performance reads over 100% | Yes, once a hand count checks out | | Goal missed for a week | No: find the speed or stop loss first | Record every ideal with its basis, the date it was timed and who approved it. A number with no history gets edited by whoever is closest to the keyboard. ## Set the ideal cycle time step by step 1. **Pick one operation on one machine.** Choose a part with a settled program or mold, not a first article. For example, OP20 on a bracket, run on one machining center. 2. **Choose a good shift.** Pick a shift with sharp tools, good material and an experienced operator, and start after warm-up. 3. **Time 10 to 20 consecutive cycles.** Time each cycle from the same point to the same point, such as door close to door close. Include load and unload when they happen on every cycle. 4. **Drop cycles with a stop inside them.** A cycle with a chip clear or a jam inside it is a stop plus a cycle. Leave it out, because the stop belongs to availability or to the [micro-stop](/blog/micro-stops/) count. 5. **Average the rest and enter it per cycle.** Enter the average as the ideal, per cycle and not per part. A 4-cavity mold keeps its shot time and records four parts per cycle. 6. **Compare with the measured cycle for a week.** Read the actual cycle time against the new ideal before anyone acts on the performance figure. #### Worked example: Timing OP20 on a machining center - Twelve uninterrupted cycles: 89, 90, 88, 91, 92, 90, 89, 92, 90, 88, 91 and 90 seconds. - A thirteenth cycle ran 141 seconds with a chip clear inside it, so it is left out. - The twelve add up to 1,080 seconds, with a range of 88 to 92 seconds. **Result:** Ideal cycle time = 1,080 ÷ 12 = 90.0 s The fastest of the twelve was 88 seconds. Using it would set the ideal 2.2% fast and charge every shift for a cycle the machine hit twice. > **Never move the ideal to hit a goal** > > Slowing the ideal until the goal is reachable turns the gauge green and deletes the speed loss you were trying to find. A goal out of reach means a speed or stop problem, or an ideal timed under conditions that no longer exist. Re-time the ideal; don’t negotiate it. Check the count before you trust any performance figure. A count matched to ten parts counted by hand, as in [validating a production count](/docs/production/choose-an-algorithm/#validate), rules out a doubled or halved count posing as a cycle-time problem. [Counting parts and cycle times on CNC mills and lathes](/blog/cnc-cycle-time-and-part-counts/) covers the CNC case. ## Set ideal cycle times in IoTFlows In IoTFlows, the ideal is the **Ideal Operation Cycle Time** on each operation in the Parts List. You enter it per cycle, with parts per cycle in its own [QTY/OP field](/docs/production/parts-and-operations/#units). The parts gauge measures performance against it. The **Calculated Goal** on Shift Production is the shift duration less the expected downtime for that operation and machine, divided by the ideal, so you move a goal by fixing the ideal. The [cycle-time setup guide](/docs/production/cycle-times-and-filters/#ideal) walks through each field. The sensor measures the actual cycle from the machine’s own signal, and the **Production Rate** column on Shift Production shows the ideal, goal and actual cycle side by side. [OEE tracking](/solutions/oee-tracking/) reports availability, performance and quality factor by factor, so an ideal that is off shows up in performance alone. ## Audit the ideals you have now Run these checks on your five highest-volume operations this week. - **Performance over 100% on any shift.** The ideal is too slow, or the count is wrong. Hand-count ten parts, then re-time. - **Performance that never moves.** A figure pinned between 97% and 99% shift after shift points to an ideal copied from a typical shift rather than timed. - **A goal that is never met.** Compare the ideal with the best actual cycle from the last month. If no shift came within 5% of it, the ideal is too fast. - **One ideal shared by different machines.** Unless the machines are identical, at least one of them is measured against the wrong number. - **An ideal nobody can explain.** With no basis, date or owner on record, re-time it. Jesel, a valvetrain manufacturer in Lakewood, NJ, runs a version of this check every day on its CNC machines, comparing actual cycle times with the times in its bills of material. > I use the dashboard every day to compare and validate actual cycle times against the times listed in our bills of material. > > Pete Gonella, Director of Manufacturing, Jesel ([story](https://www.iotflows.com/customers/jesel/)) A deviation in either direction is worth a look. A cycle running long points at tooling or setup, and one running consistently short points at a standard that needs re-timing. ## Questions ### Should the ideal cycle time be the nameplate speed? Use the nameplate rate when the machine sets the pace and the rating is achievable, such as a filler or a press run at a fixed rate. When the part program, the mold or the operator sets the pace, a nameplate ideal reports a speed loss nobody can recover. Use a timed best sustainable cycle there, and keep one basis across every machine you compare. ### Is ideal cycle time the same as takt time? No. Takt time is available production time divided by customer demand, so it states the pace the customer needs. Ideal cycle time states the pace the process can sustain. A machine whose ideal cycle is slower than takt cannot meet demand even with zero downtime, which is a capacity problem, not a performance one. ### Should the ideal cycle time include load and unload? Include load and unload when they happen on every cycle and the machine waits for them, as on an operator-loaded mill. Leaving them out books every load as a speed loss. Keep changeovers out of the ideal: a changeover is a stop between runs, and it belongs to availability, not to the cycle. ### Does every machine need its own ideal cycle time? Every machine that runs an operation at a different speed needs its own. The same bracket can cut in 90 seconds on a newer machining center and 140 seconds on an older mill. One shared ideal makes the older machine look slow every shift and the newer one look perfect, and neither number helps anyone. ## Sources 1. [OEE Calculation: Definitions, Formulas, and Examples](https://www.oee.com/calculating-oee/), Vorne Industries (OEE.com), accessed Oct 16, 2026 2. [Six Big Losses in Manufacturing](https://www.oee.com/oee-six-big-losses/), Vorne Industries (OEE.com), accessed Oct 16, 2026 3. [Cycle Time](https://www.lean.org/lexicon-terms/cycle-time/), Lean Enterprise Institute, accessed Oct 16, 2026 4. [Takt Time](https://www.lean.org/lexicon-terms/takt-time/), Lean Enterprise Institute, accessed Oct 16, 2026 --- # Planned vs unplanned downtime and what counts against OEE Source: https://www.iotflows.com/blog/planned-vs-unplanned-downtime/ Breaks, changeovers and planned maintenance are all downtime. See which count against OEE availability, with one shift worked three ways and a decision table. > Question: Do breaks, changeovers and planned maintenance count as downtime, and do they count against availability? ## Key takeaways - Breaks, changeovers and planned maintenance are all downtime, because the machine is stopped and makes no parts. - Planned or unplanned says whether you chose a stop; whether the machine was meant to run decides availability. - Under the common OEE convention, idle breaks leave planned production time, while changeovers and in-shift maintenance stay in as losses. - The same shift can read 71.9%, 76.7% or 88.5% availability, depending on which stops leave the denominator. - Write your convention under every OEE report, and compare plants only when they draw the line in the same place. Breaks, changeovers and planned maintenance all count as downtime, because the machine is stopped, but they don’t all count against availability. Under the common OEE convention, a break with nobody meant to run the machine comes out of planned production time first. A changeover or a maintenance job inside a scheduled shift stays in and lowers availability, even though you planned it. One test decides where each stop goes, and a decision table applies it to the stops plants argue about. One shift on a molding press, worked three ways, shows how far the convention moves the number. ## Planned vs unplanned downtime > **Definition.** **Planned downtime** is a stop decided before it happened and written into the schedule, such as a changeover, a preventive maintenance job or a lunch break. The machine is stopped and makes no parts, so planned downtime is still downtime. > **Definition.** **Unplanned downtime** is a stop the schedule did not account for, such as a breakdown, a broken tool, a jam, a missing operator or material that did not arrive. It also covers the part of a planned job that runs past its scheduled slot. NIST’s maintenance survey report puts the first point in one line: “PM is planned downtime which is still downtime.”[3] The [planned downtime glossary entry](/docs/get-started/glossary/#planned-downtime) shows how IoTFlows marks those stops. Planned or unplanned answers one question: did you choose this stop? Availability asks a different one: was the machine meant to be making parts at the time? Keep the two questions apart and most arguments about planned time settle quickly. ## What counts against availability? *Availability* is run time divided by planned production time. *Planned production time* is the shift minus any time with no intention of running production, and Vorne’s OEE primer names breaks as the usual example.[1] **Availability** = (Run time) ÷ (Planned production time) *Stop time* is the rest of the time the machine was meant to run and didn’t. It includes unplanned stops, such as breakdowns, and planned stops, such as changeovers.[1] The six big losses file planned stops under setup and adjustments, an availability loss: setups, changeovers, cleaning, warm-up, planned maintenance and quality inspections.[2] That leaves one test. Take time out of planned production time only when nobody intended to run the machine. Keep it in when the machine was scheduled to run and didn’t, whatever the reason and whoever chose it. Figure: A 480-minute shift on a molding press: 345 minutes running, a 30-minute lunch outside planned production time, a 45-minute mold change and 15-minute PM counted as planned stops, and 45 minutes of unplanned stops. Availability is 345 ÷ 450 = 76.7%. *Lunch leaves planned production time; the mold change and the PM stay in, next to the breakdown. Sample data.* For example, the press above runs a 480-minute day shift with a 30-minute lunch, so planned production time is 450 minutes. The mold change and the lubrication PM were both on the schedule, and both stay in. The guide to [calculating OEE from one shift](/blog/how-to-calculate-oee/) carries the same structure through performance and quality. ## Where each stop goes The table covers ten stops that plants argue about. Read each row with the one test: was the machine meant to run? | Stop | Planned? | In availability? | Why | |---|---|---|---| | Lunch with the machine left idle | Yes | No | Nobody meant to run it | | Covered lunch, relief operator absent | No | Yes | The machine was meant to run | | Changeover on the schedule | Yes | Yes | It takes scheduled run time | | Changeover swapped in for a rush job | No | Yes | It was not on the schedule | | Changeover running past its slot | Slot yes, overrun no | Yes | Split the record in two | | PM during a scheduled shift | Yes | Yes | It takes scheduled run time | | PM on a weekend with no shift | Yes | No | No production was planned | | Breakdown or broken tool | No | Yes | The classic availability loss | | Waiting for material or an operator | No | Yes | Machine ready, nothing to run | | No orders, machine scheduled off | Yes | No | Outside planned production time | Convention from Vorne’s OEE primer and six big losses. Your plant decides what counts as planned production time, so write it down. ### Breaks and meetings A break comes out only when the machine sits idle by plan. If a relief operator is meant to cover lunch, the machine was scheduled to run, and every stop in that slot is unplanned downtime. A 10-minute shift-start meeting follows the same test. Take it out when the machine is meant to sit through it, and keep it in when the machine was meant to run. ### Changeovers A changeover written into the schedule is planned and still counts. Vorne calls changeovers the usual largest source of setup and adjustment time,[2] so taking them out of the denominator hides the loss you most want to shrink. A changeover swapped in mid-shift for a rush job is unplanned. When you have to think about whether a stop was scheduled, it was not. ### Planned maintenance Preventive maintenance inside a scheduled shift is a planned stop, and it lowers availability. The same job moved to a Saturday with no shift sits outside planned production time, so it costs OEE nothing. That’s a reason to move PM into non-production hours where your plant has them. It isn’t a reason to relabel in-shift PM as excluded time. ### Overruns A 45-minute mold change that takes 70 minutes is two records: 45 planned minutes and 25 unplanned ones. Both stay in availability. The split tells you whether the plan was too tight or the changeover went wrong. ## Work one shift three ways The convention is a choice, and on one shift it moves availability by 16.6 points. Here is the shift from the figure above, with three different denominators. #### Worked example: One 8-hour shift on a 350-ton molding press - Shift: 06:00 to 14:00, 480 minutes, with a 30-minute lunch and the press left idle. - Planned stops: a 45-minute mold change and a 15-minute lubrication PM, 60 minutes in all. - Unplanned stops: a 30-minute heater band failure and 15 minutes waiting for resin, 45 minutes in all. - Run time: 480 − 30 − 60 − 45 = 345 minutes. | Convention | Denominator | Availability | |---|---|---| | Whole shift | 480 min | 345 ÷ 480 = 71.9% | | Breaks out | 450 min | 345 ÷ 450 = 76.7% | | Breaks and planned stops out | 390 min | 345 ÷ 390 = 88.5% | **Result:** The same 345 run minutes read anywhere from 71.9% to 88.5% availability. Figure: Three availability bars for the same 345 run minutes: 71.9% over the whole 480-minute shift, 76.7% with breaks removed (450 minutes), and 88.5% with breaks and planned stops removed (390 minutes). *One shift, three denominators: a 16.6-point spread with no change on the floor. Sample data.* The middle row follows the common OEE convention. The bottom row answers a different question, how much of the time you meant to produce went to stops nobody chose, and it isn’t OEE availability. That reliability question has its own ratio: unplanned downtime as a share of planned production time. NIST’s survey of US discrete manufacturers asked for exactly this, and the average answer was 7.8%.[3] On this press it’s 45 ÷ 450 = 10.0%. Standards don’t settle the line either. ISO 22400 gives two definitions of OEE, and a 2020 review found they seem to diverge from each other and from Nakajima’s original TPM formulation.[4] SEMI E10, written for the semiconductor and related industries, defines six mutually exclusive equipment states and names unscheduled downtime as the failed one.[6] Hours with no shift belong to a different metric. TEEP multiplies OEE by utilization, planned production time over all time, so it is the one that counts the weekend.[5] The guide to [utilization, OEE and TEEP on one calendar](/blog/utilization-uptime-oee-teep/) lines these metrics up hour by hour. > **Compare plants on one convention** > > Before you compare two plants’ availability, check what each removes from planned production time. A plant that removes changeovers reports 88.5% for the same shift another plant reports as 76.7%, and neither number is wrong. ## Why keep planned stops in availability? Planned stops cost the same minutes as unplanned ones. A 45-minute mold change is 45 minutes the press made no parts, whether you scheduled it or not. Keeping planned stops in the denominator keeps them on the list of losses you work on. [Datwyler’s injection molding plant](/customers/datwyler/) shows why. With a reason on every stop, it cut shift-changeover downtime in half and material-changeover downtime by 30% within six months. Both are stops a plant plans for, and both gains would be invisible on an availability figure that left them out. > **Which basis should you report?** > > Report availability with idle breaks out and every other stop in when you track OEE, set goals or compare machines. Report unplanned downtime as a share of planned production time when the maintenance team needs a reliability number. You don’t need a third basis that removes planned stops from availability: it raises the number without saving a minute. ## Track planned and unplanned stops automatically IoTFlows detects every stop from a sensor on the machine, with no PLC connection, and sorts it into the shift it fell in. Set your [shifts and timezone](/docs/admin/shifts-and-timezone/) first, since they decide which hours count at all. Mark each downtime category planned or unplanned once, with the **Planned downtime** toggle. Operators then see a calendar icon on planned reasons when they classify a stop, and changeovers and maintenance rank by hours next to breakdowns. A [scheduled break window](/docs/monitoring/auto-downtime-rules/#breaks) classifies every stop in your lunch slot automatically. Give that break category the [None severity](/docs/monitoring/metrics-reference/#none), and **Exclude None** on the Advanced Report takes it out of both uptime and downtime, matching the convention above. See how [downtime tracking](/solutions/downtime-tracking/) works. ## Set your plant’s convention 1. **List what leaves planned production time.** Write down every kind of time with no plan to run: unstaffed breaks, hours with no shift and days with no orders. Everything else stays in. 2. **Flag every reason code.** Mark each reason planned or unplanned when you build the list, then set its severity separately. The [starter list of reason codes](/blog/downtime-reason-codes/#starter-list) shows both settings on every code. 3. **Split overruns from the plan.** Record a changeover’s scheduled minutes as planned and the rest as unplanned. Cut the stop record in two at the end of the scheduled slot and give each half its own reason. 4. **Print the convention on the report.** Put one line under every OEE number saying what came out of planned production time. A reader in another plant can then compare like with like. 5. **Shrink the planned stops too.** Rank planned stops by hours next to breakdowns and start on the largest. [Measure changeover time](/blog/measure-changeover-time/) before you try to cut it. ## Questions ### Is a lunch break counted as downtime? On the machine, yes: it is stopped, and a sensor records the stop. In OEE, a lunch with the machine left idle comes out of planned production time, so it lowers neither availability nor OEE. If a relief operator is meant to keep the machine running through lunch, any stop in that slot is unplanned downtime and counts against availability. ### Does a changeover that runs long count as planned downtime? Only the scheduled part. Record the minutes the schedule allowed under a planned changeover reason and the overrun under an unplanned reason, such as waiting for a mold or a failed first article. Both parts still lower availability, and the split shows whether the plan was too tight or the changeover went wrong. ### Does maintenance done on a weekend lower OEE? No, when no production shift is scheduled that weekend. OEE measures only planned production time, so hours with no plan to run sit outside it. TEEP divides by every hour on the calendar, but it already counts those weekend hours as unscheduled, so maintenance in them lowers TEEP no further. Maintenance inside a scheduled shift lowers both. ### Why do some plants report availability with planned stops removed? Removing changeovers and planned maintenance from the denominator isolates the stops nobody chose, which suits a maintenance team tracking breakdowns. The cost is a higher number that hides capacity lost to setups. Report that view under its own name, such as unplanned downtime as a share of planned production time, rather than calling it OEE availability. ## Sources 1. [OEE Calculation: Definitions, Formulas, and Examples](https://www.oee.com/calculating-oee/), Vorne Industries, accessed Oct 16, 2026 2. [Six Big Losses in Manufacturing](https://www.oee.com/oee-six-big-losses/), Vorne Industries, accessed Oct 16, 2026 3. [Economics of Manufacturing Machinery Maintenance: A Survey and Analysis of U.S. Costs and Benefits (NIST AMS 100-34)](https://nvlpubs.nist.gov/nistpubs/ams/NIST.AMS.100-34.pdf), National Institute of Standards and Technology, accessed Oct 16, 2026 4. [Overall Equipment Effectiveness: consistency of ISO standard with literature (Schiraldi and Varisco, Computers & Industrial Engineering 145, 2020)](https://art.torvergata.it/handle/2108/280082), University of Rome Tor Vergata institutional repository, accessed Oct 16, 2026 5. [TEEP: Total Effective Equipment Performance](https://www.oee.com/teep/), Vorne Industries, accessed Oct 16, 2026 6. [SEMI E10: Specification for Definition and Measurement of Equipment Reliability, Availability, and Maintainability (RAM) and Utilization](https://store-us.semi.org/products/e01000-semi-e10-specification-for-definition-and-measurement-of-equipment-reliability-availability-and-maintainability-ram-and-utilization), SEMI, accessed Oct 16, 2026 --- # How to build a downtime Pareto from real minutes Source: https://www.iotflows.com/blog/downtime-pareto/ Rank downtime reasons by the minutes they cost: sum each stop under its reason, sort, add a cumulative line. A worked week of stops shows where to act first. > Question: How do I rank downtime reasons by the hours they cost? ## Key takeaways - Rank downtime reasons by minutes stopped, not by number of stops, because one long breakdown outweighs a hundred short pauses. - Sum each reason's minutes, sort the totals from largest to smallest and add a running cumulative percentage. - Act on the reasons to the left of where the cumulative line flattens, and give each one an owner. - Split the leading reason by machine and by shift, because one reason often lives on one or two machines. - Compare periods as a share of scheduled time, so a shorter week doesn't look like a fix. You rank downtime reasons by the hours they cost by adding up the minutes of every stop under its reason, sorting the totals from largest to smallest and drawing a running cumulative percentage over them. That chart is a downtime Pareto. The first two or three bars, before the cumulative line flattens, are where an hour of improvement work returns the most. This guide is for plant managers and maintenance leads. It builds one week of stops into a Pareto by hand, then shows how to drill into the leading bar and compare periods fairly. To decide which reasons to log in the first place, see [which downtime reason codes to log](/blog/downtime-reason-codes/). ## What a downtime Pareto shows > **Definition.** **Downtime Pareto chart** is a bar chart of downtime reasons ranked by the total minutes each one cost, longest first, with a line for the cumulative percentage of stopped time, so the few reasons that carry most of the loss stand out. The IoTFlows docs define the same chart in the [glossary](/docs/get-started/glossary/#pareto-chart). A *stop log* is the list it is built from: one row per stop, with the machine, start, end and reason. Joseph Juran named the principle behind it after the economist Vilfredo Pareto, and coined the terms “vital few” and “useful many” for the two ends of the ranking.[1] The 80/20 split is a shape, not a law. In the Juran Institute guide's own examples, the vital few carry anywhere from 65% to 86% of the total.[1] ## Count, minutes or cost: what should you rank by? Rank by minutes. A Pareto by count answers “what interrupts us most often”, which favors short pauses, since they happen dozens of times a shift. A Pareto by minutes answers “what takes the most capacity”, which is the question a plant manager asks. For example, one week on six CNC machines produced 281 stops. By count, Short downtime leads with 186 stops. By minutes, Changeover leads, and Breakdown moves from last place to third. Figure: The same eight downtime reasons ranked two ways. By number of stops, Short downtime leads with 186 and Breakdown is last with 3. By minutes, Changeover leads with 1,260 and Breakdown rises to third with 610 minutes. *Ranked by count, Breakdown is last; ranked by minutes, it is third. Sample data.* Each measure answers a different question, so pick the one that matches yours: | | Stops | Minutes | Cost | |---|---|---|---| | Answers | What interrupts most often | What takes the most capacity | What costs the most money | | Use it for | Operator nuisance, short stops | Availability and capacity | Budget and capital requests | | Misleads when | Stops differ in length | A minute isn't worth the same everywhere | The rates are guesses | | Data needed | A reason on each stop | Start, end and reason | Minutes plus a rate per reason | Start with minutes. Add the count and cost views beside it, never in place of it. Weight by cost only when a minute on one reason costs more than a minute on another. A weighted Pareto can point at different problems than a count-based one: in Minitab's clothing example, a defect type that made up 9% of defects was the second most costly.[3] The same thing happens with downtime when one reason also burns parts or outside labor. #### Worked example: Weighting the same week by cost - Capacity rate: $90 per machine hour, the same for every reason (a hypothetical rate). - Changeover: 21 h × $90 = $1,890. - Waiting for material: 14 h × $90 = $1,260. - Breakdown: 610 min is 10.17 h × $90 = $915, plus $2,400 of parts and outside repair = $3,315. **Result:** By cost, Breakdown leads at $3,315, ahead of Changeover at $1,890 Keep the cost view as a second chart. Its rates are estimates, and the minutes view is the one everyone can check against the stop log. To set a rate per reason, see [how to rank downtime reasons by dollars](/blog/cost-of-downtime/#by-reason). ## Build the Pareto from a stop log You need one row per stop, with a duration and a reason. Any monitoring system or a paper log typed into a spreadsheet will do, as long as the minutes come from the clock and not from memory. 1. **Fix the window and the machines.** Pick the date range, the shifts and the machines before you look at any numbers. For ranking, use four weeks or more; the worked example uses one week so the arithmetic stays short. 2. **Export one row per stop.** Each row holds the machine, start, end, duration and reason. If your stops come from IoTFlows, the [Downtimes CSV](/docs/monitoring/exports-reference/#downtimes-csv) carries these columns, with the duration in seconds. 3. **Clean the rows.** Fix spellings, clip stops at the window edges and split stops that hold two reasons. The rules are in the next section. 4. **Sum the minutes per reason.** A pivot table that sums duration by reason does it in one step. In a formula, `=SUMIFS(F:F, G:G, A2)/60` sums column F (seconds) for the reason in A2 and converts it to minutes. 5. **Sort and add the cumulative share.** Sort the totals from largest to smallest. Divide each by the total stopped minutes, then keep a running sum of those shares down the list. 6. **Draw the bars and the line.** Draw the minutes as bars against the left axis and the cumulative share as a line against a right axis from 0% to 100%. **Share of stopped time** = (Minutes for one reason) ÷ (Total stopped minutes) **Cumulative share** = Share of this reason + shares of every reason ranked above it ### Clean the stop log first A Pareto is only as honest as the rows under it. Check these before you sum anything: - **Sort on seconds, not on formatted text.** A text duration such as `9m 12s` sorts above `1h 4m` in a spreadsheet. - **Clip stops at the window edges.** A stop from 23:00 Sunday to 01:30 Monday puts 60 minutes in last week and 90 in this one. - **Decide where an overnight shift's minutes land.** Charge a shift that crosses midnight to the day it began or split it at midnight, and use the same rule every week. IoTFlows calls the first choice [shift islands](/docs/admin/shifts-and-timezone/#overnight-hours). - **Split a stop that holds two reasons.** A 90-minute stop where a changeover ran into a breakdown at minute 30 is 30 minutes of Changeover and 60 of Breakdown. [Split the downtime](/docs/monitoring/classify-downtime/#split) at the minute the reason changed. - **Merge spellings of one reason.** `Matl late`, `No material` and `Waiting for material` are one bar, not three short ones. - **Keep Unclassified as its own bar.** Never spread its minutes across the other reasons in proportion. That hides how much of the chart is a guess. ### A worked week on six CNC machines #### Worked example: One week on six CNC machines - Six machines, two 8-hour shifts, five days: 6 × 16 × 5 = 480 scheduled hours, or 28,800 minutes. - Breaks and shifts with no job scheduled are left out; every other stop is in. - Stopped time: 4,000 minutes across 281 stops, so 4,000 ÷ 28,800 = 13.9% of scheduled time. - Top three reasons: Changeover 1,260 min, Waiting for material 840 min, Breakdown 610 min, for 2,710 min. **Result:** Top three share = 2,710 ÷ 4,000 = 67.8% of stopped minutes | Reason | Stops | Minutes | Share | Cumulative | |---|---|---|---|---| | Changeover | 14 | 1,260 | 31.5% | 31.5% | | Waiting for material | 22 | 840 | 21.0% | 52.5% | | Breakdown | 3 | 610 | 15.3% | 67.8% | | Short downtime | 186 | 465 | 11.6% | 79.4% | | Waiting for inspection | 18 | 330 | 8.3% | 87.6% | | Tool change | 25 | 300 | 7.5% | 95.1% | | Unclassified | 9 | 135 | 3.4% | 98.5% | | Other | 4 | 60 | 1.5% | 100.0% | Sample data. Cumulative shares are computed from the minutes, then rounded, so they can differ from the sum of the rounded shares by 0.1. Figure: A downtime Pareto of 4,000 stopped minutes. Changeover 1,260, Waiting for material 840 and Breakdown 610 minutes reach 67.8% cumulative. The cumulative line reaches 79.4% at the fourth reason, Short downtime, then flattens toward 100%. *Three reasons carry 67.8% of the week's stopped minutes; the line flattens after them. Sample data.* ## Where do the vital few end? Read the cumulative line, not the 80% mark. The vital few end where the line's slope flattens, which is how Juran reads the chart.[1] In the worked week, each of the first three bars adds 15 to 32 points. From the fourth bar on, each adds 12 points or fewer, and the chart flattens. Sometimes the line has no clear break, and Juran calls the bars around the bend the awkward zone.[1] In the worked week the bend is gentle: Breakdown adds 15.3 points and Short downtime 11.6, so both sit near it. Put a bar from that zone in the vital few only when someone can act on it this month. So three reasons out of eight carry 67.8% of the stopped minutes. That isn't 80/20, and it doesn't need to be. Act on those three, give each one an owner and a date, and leave the useful many for later. Four bars change how you read the rest: | Bar | What it means | First move | |---|---|---| | Unclassified in the top three | The chart ranks missing reasons | Fix the classifying habit first | | Other in the top three | The reason list is missing a code | Read the Other notes and add a code | | Short downtime | Many short pauses under one code | Split it by machine before acting | | A planned reason leads | Planned stops still take capacity | Shorten it; don't stop logging it | Check Unclassified and Other before the rest: when either ranks in the top three, fix it first. Minitab gives the same advice for any Pareto that isn't useful: make sure the categories are meaningful and that Other isn't too large.[2] Short downtime needs a second look because it is one code for hundreds of stops. In the worked week it holds 186 stops averaging 2.5 minutes. Vorne describes minor stops as usually well under five minutes and not needing maintenance staff.[4] Split the code by machine to see where they cluster before you give it an owner. Where the short-stop cutoff sits decides how many stops land in this bar, see [how to set the short-stop cutoff](/blog/micro-stops/#cutoff). > **Planned stops on the chart or off?** > > Keep a planned stop on the chart when someone could shorten it: changeovers, tool changes and preventive maintenance. Leave it off when nobody intends to shorten it: lunch, breaks and shifts with no job scheduled. Vorne groups any planned stop under setup and adjustments, an availability loss, which is why a planned changeover still belongs on a downtime Pareto.[4] ## Drill into the leading bar A reason on the Pareto is a starting point, not a cause. The next move is a second Pareto of the leading reason's minutes, split by another factor. Juran's guide lists ways to classify the data that can reveal a vital few, among them type, time of day, week or month, and the place where the work is done.[1] For downtime, place means the machine. Figure: Changeover minutes in one week split by machine. Lathe 2 has 520 of 1,260 minutes, 41.3%, across 4 changeovers. Mill 3 follows with 310 minutes, then Mill 1, Mill 2, Lathe 1 and Mill 4 at 60 minutes. *Lathe 2 carries 41.3% of changeover minutes at 130 minutes a changeover. Sample data.* The split changes the job. Lathe 2 ran 4 of the week's 14 changeovers and took 520 minutes, 130 minutes each. The other five machines averaged 740 ÷ 10 = 74 minutes. The problem is Lathe 2's setup, not changeovers in general, so [measure its changeovers](/blog/measure-changeover-time/) before anyone redesigns them. Cut the leading reason this way, in this order: 1. By machine, to see whether the reason is spread or concentrated. 2. By shift, to see whether one crew or one handover drives it. 3. By day of the week, to catch a pattern a single day hides. 4. By the operator's notes, to group causes inside the reason. Stop cutting once a slice names a person who can act on it. The [weekly downtime review](/blog/downtime-root-cause-review/) takes it from there. For Lathe 2, that is the process engineer who owns its setup. ## Compare two periods without fooling yourself Compare each reason as a share of scheduled time, not as raw minutes. A short week, a holiday or a machine that sat with no job all shrink the minutes without anything getting better. **Share of scheduled time** = (Minutes for one reason) ÷ (Scheduled minutes in the period) #### Worked example: Did the Lathe 2 setup fix work? - Week 1: 480 scheduled hours, or 28,800 minutes. Changeover: 1,260 min. - Week 2: a four-day week, 384 scheduled hours, or 23,040 minutes. Changeover: 900 min. - Raw minutes fell (1,260 − 900) ÷ 1,260 = 28.6%. - Share of scheduled time went from 1,260 ÷ 28,800 = 4.4% to 900 ÷ 23,040 = 3.9%. **Result:** Changeover's share of scheduled time fell 10.7%, not 28.6% The fix worked, but most of the raw drop came from the shorter week. Report the normalized number. It uses the same denominator as [availability](/blog/how-to-calculate-oee/#availability): the time the machine was meant to run. Watch the ranks as well as the bars. A reason that falls from first to third may have shrunk, or another reason may have grown past it. Read both periods' totals before you call a win. ## Get the Pareto without a spreadsheet A SenseAi sensor on each machine detects every stop in seconds, with no PLC connection, and operators put a reason on it in a tap. Automatic rules classify short downtimes, shift starts and ends, and breaks. The [Downtimes report](/docs/monitoring/downtimes/#pareto) draws the Pareto as **Downtimes by Category**, ranked by duration with a cumulative line. Two stacked charts split the same minutes by time interval and by machine, which covers the drill-down above. Filters cover shifts, categories and severity, and the CSV and PDF exports keep the filters you set. [Datwyler's injection molding plant](/customers/datwyler/) reviews this report week over week and month over month, and cut shift-changeover downtime by 50% within six months. The full workflow is on [downtime tracking](/solutions/downtime-tracking/). ## Checklist before you act on the chart Run these checks each time you build a downtime Pareto: - **The window is four weeks or more** for ranking, and the scheduled hours are written beside the chart. - **The bars are minutes,** with the count and cost views kept as separate charts. - **Unclassified and Other sit outside the top three,** or fixing them is the first action. - **Planned stops you can shorten are on the chart,** and breaks and empty shifts are off. - **The vital few end where the line flattens,** with one owner and a date named for each. - **The leading bar is split** by machine and shift before anyone starts a fix. - **The next period is compared as a share of scheduled time,** not as raw minutes. To see where each reason sits in OEE, map it to [the six big losses](/blog/what-is-oee/#six-losses). ## Questions ### Should planned downtime appear on a downtime Pareto? Keep planned stops you can shorten, such as changeovers and preventive maintenance, because they take capacity whether or not you scheduled them. Leave out stops nobody intends to shorten, such as lunch breaks and shifts with no job scheduled. When you are unsure, build the chart twice, once with planned stops and once without, and compare the top three reasons. ### How long a window should a downtime Pareto cover? Rank on four weeks or more, so rare long stops such as breakdowns are counted fairly. In a single week, one breakdown more or less can change a reason's rank. Use weekly charts to watch a reason you are already fixing, and keep the scheduled hours beside each chart so periods of different length compare fairly. ### What if no reason stands out on the Pareto? A flat chart means the grouping hides the pattern, not that there is none. Sort the same stops by another factor, such as machine, shift, day of the week or part number, and look for a bar that leads. Check the size of Unclassified and Other as well, because a large share in either spreads the real causes thin. ### Can I build a downtime Pareto in a spreadsheet? Yes. Put one stop per row with the machine, start, end, duration in seconds and reason. A pivot table that sums duration by reason, sorted from largest to smallest, gives the bars. A running sum divided by the total gives the cumulative line, and a combo chart with a secondary axis draws both on one chart. ## Sources 1. [Pareto Principle (80/20 Rule) & Pareto Analysis Guide](https://www.juran.com/blog/a-guide-to-the-pareto-principle-80-20-rule-pareto-analysis/), Juran Institute, accessed Oct 16, 2026 2. [Pareto chart basics](https://support.minitab.com/en-us/minitab/help-and-how-to/quality-and-process-improvement/quality-tools/supporting-topics/pareto-chart-basics/), Minitab, accessed Oct 16, 2026 3. [Example of a weighted Pareto chart](https://support.minitab.com/en-us/minitab/help-and-how-to/quality-and-process-improvement/quality-tools/how-to/pareto-chart/before-you-start/example-of-a-weighted-pareto-chart), Minitab, accessed Oct 16, 2026 4. [Six Big Losses](https://www.oee.com/oee-six-big-losses/), Vorne Industries (OEE.com), accessed Oct 16, 2026 --- # Do micro-stops count as downtime? Source: https://www.iotflows.com/blog/micro-stops/ Micro-stops are downtime, but standard OEE definitions book them as a performance loss. See where they land, why OEE holds steady and how to set the cutoff. > Question: Do micro-stops count as downtime, and where do they show up in OEE? ## Key takeaways - A micro-stop is a stop of a minute or two that the operator clears without calling maintenance. - Plants that log reasons only above a cutoff book shorter stops as a performance loss, not an availability loss. - The short-stop cutoff moves the loss between availability and performance, and OEE stays the same either way. - Let a rule label every stop under the cutoff, and ask operators only about the longer stops. - Track micro-stops by count per hour, because their causes are chronic and repeat shift after shift. Micro-stops are downtime: the machine stopped, and every minute of it costs output. Standard OEE definitions book them as a performance loss instead of an availability loss, because reasons are logged only for stops longer than a cutoff of a few minutes. The cutoff moves the loss from one factor to the other, and OEE stays the same either way. Operators shouldn’t classify a 30-second stop; a rule should. This guide, for plant managers and the operators who classify stops, works one shift both ways, sets the cutoff from a week of stops and covers the settings that decide which stops anyone sees. ## What is a micro-stop? > **Definition.** **Micro-stop (minor stop)** is a stop of a minute or two, well under five minutes, that the operator clears at the machine without calling maintenance, such as a material jam, a misfeed or a blocked sensor. Vorne’s OEE primer lists the usual causes: misfeeds, material jams, obstructed product flow, incorrect settings, misaligned or blocked sensors and periodic quick cleaning.[1] It also notes that most companies don’t track these stops accurately, and that the underlying problems are often chronic: same problem, different day.[1] A micro-stop is still a stop. The machine record counts it in full whether or not anyone gives it a reason, as the glossary entry for [downtime](/docs/get-started/glossary/#downtime) puts it. ### Where the line sits No standard fixes the duration. Each plant draws its own line, and published sources differ by more than a factor of seven. | Source | Where a short stop ends | |---|---| | Vorne’s six big losses | Two minutes, given as an example policy | | Bottling-line study, Zennaro et al. | Under 15 minutes | | IoTFlows short-downtime rule | 5 minutes per machine, by default | Vorne describes minor stops as a minute or two, and usually well under five minutes. The bottling study defines micro downtime as any stop under 15 minutes. The line matters more than its exact value. In that bottling study, micro downtime under 15 minutes covered 57% of the inefficiency on the least efficient line the authors analyzed.[3] Short stops are rarely a rounding error. ## Do micro-stops count as downtime? Yes, on the machine’s record. A machine that sits still for 40 seconds produced nothing for 40 seconds. The open question is which bucket of your OEE calculation that time lands in, and that depends on how you book it. You have two choices: - **Book it as downtime.** The stop counts against availability. A rule gives it one reason, such as `Short downtime`, so nobody has to. - **Book it as running time.** The stop never reaches the downtime record. The parts it cost still go missing, so the loss shows up in performance instead. Vorne’s definitions follow the second choice. Availability covers stops long enough that a reason is worth tracking, and performance covers slow cycles and small stops.[2] Vorne lists idling and minor stops as one of the six big losses, and as a performance loss.[1] [What is OEE?](/blog/what-is-oee/#six-losses) maps all six losses to their factors. ## Where micro-stops show up in OEE The cutoff decides which factor carries a micro-stop. It never decides whether the loss counts. OEE reduces to good output measured in ideal time over planned time:[2] **OEE** = (Good count × Ideal cycle time) ÷ (Planned production time) Run time appears nowhere in that formula. Moving a stop from running time to downtime lowers availability and raises performance by exactly the same factor. #### Worked example: One shift on a cartoner rated at 60 cartons a minute - Planned production time: 450 minutes. Ideal cycle time: 1 second. - Logged stops: a 25-minute changeover and a 15-minute jam, 40 minutes in all. - Micro-stops: 90 stops averaging 30 seconds, 45 minutes in all. - The line ran 450 − 40 − 45 = 365 minutes, at 57 cartons a minute, 95% of rated speed. Count: 365 × 57 = 20,805 cartons. Assume all are good. **Cutoff at 2 minutes, micro-stops booked as running time.** Run time is 410 minutes. Availability is 410 ÷ 450 = 91.1%. Performance is 20,805 ÷ (410 × 60) = 84.6%. **Every stop booked as downtime.** Run time is 365 minutes. Availability is 365 ÷ 450 = 81.1%. Performance is 20,805 ÷ (365 × 60) = 95.0%. **Result:** OEE = 20,805 ÷ (450 × 60) = 77.1% under both bookings Figure: One 450-minute cartoner shift drawn twice. Booked as running time, 45 minutes of micro-stops sit inside a 410-minute run: availability 91.1%, performance 84.6%. Booked as downtime: availability 81.1%, performance 95.0%. OEE is 77.1% both times. *The same 45 minutes of micro-stops booked two ways. The factors trade places and OEE stays at 77.1%. Sample data.* The number holds, but the story changes. Under the first booking, a supervisor reads 84.6% performance and concludes the line runs slow. It doesn’t: it runs at 95% of rated speed between 90 interruptions. A stop record lets you [split the performance loss](/blog/which-oee-factor-loses-most/#six-losses). The 20,805 cartons are 346.75 minutes of output at 1 second each, so performance lost 410 − 346.75 = 63.25 minutes under the first booking. Of those, 45 are micro-stops and 18.25 are slow cycles. A faster speed setting recovers the 18.25; it does nothing for the 45. Those 45 minutes are 2,700 cartons at the rated speed. > **Without a stop record, the split is invisible** > > A paper log or an end-of-shift count can’t separate micro-stops from slow cycles, because nobody wrote the stops down. Both blur into one low performance number with no cause attached. [How to track machine downtime](/blog/how-to-track-machine-downtime/) compares a paper log with a machine signal on the same shift. ## Should operators classify a 30-second stop? No. A 30-second stop has a cause, but asking the operator for it every time costs more than the answer is worth. In the cartoner shift, 92 stops would each ask for a reason: one about every five minutes, mostly from the person who cleared the jam seconds ago. Classify by duration instead. *Auto-classification* is a rule that puts a reason on a stop without anyone choosing it; the glossary defines [auto-classification](/docs/get-started/glossary/#auto-classification) the way IoTFlows uses it. With a short-stop rule, the operator in that shift explains two stops, and the rule labels 90. | Stop length | Who supplies the reason | Example | |---|---|---| | A pause inside the cycle | Nobody: it isn’t a stop | A 4-second index between cycles | | Under the short-stop cutoff | A rule, with one code | A 30-second carton jam | | Over the cutoff | The operator, from the list | A 15-minute jam that needed a tool | | Long enough to need help | The operator, plus an alert | A 40-minute drive fault | You still need the causes of micro-stops. Get them by studying one machine for one shift, not by asking about every stop on every machine. [Reduce micro-stops](#reduce) covers the study. The reason-code guide’s [starter list](/blog/downtime-reason-codes/#starter-list) shows which codes a rule assigns and which an operator picks. ## How do you set the short-stop cutoff? Set it from a week of real stops, not from a number someone quotes. Stop durations on most machines split into two groups: a large pile of short, routine stops and a thinner spread of longer ones. The cutoff belongs where the pile ends. Figure: Bars count one week of case packer stops by length: 260 under 30 seconds, 140 from 30 to 60 seconds, 50 from 1 to 2 minutes, then 14, 8 and 6 above. A dashed line at 2 minutes separates 450 short stops from 28 longer ones. *One week of stops on a case packer, by length. The count drops sharply after 2 minutes, so the cutoff goes there. Sample data.* 1. **Record every stop for a week.** Use a machine signal, not a log sheet, so stops of a few seconds are in the data. One week covers each shift and the usual product mix. 2. **Count the stops by length.** Bucket them: under 30 seconds, 30 to 60 seconds, 1 to 2 minutes, 2 to 5, 5 to 15 and over 15. Count stops, not minutes, because the cutoff is about how many questions you ask. 3. **Find where the count drops.** In the case packer week, 450 of 478 stops are under 2 minutes, and only 14 fall between 2 and 5. The drop at 2 minutes is the edge of routine jam-clearing. 4. **Set the cutoff at the drop.** Put the cutoff where routine stops end. Every stop under it gets one automatic reason, and every stop over it asks the operator. 5. **Check the cutoff after a month.** If operators still classify dozens of stops a shift, the cutoff sits inside the pile. If the short-stop code’s total climbs on one machine, study that machine. Choose a shorter cutoff when stops are rare and each one is worth explaining, such as on an operator-loaded CNC mill. Choose a longer one on a high-speed automatic line, such as a [packaging line](/blog/how-to-monitor-a-packaging-line/#buffers), where dozens of short jams a shift are normal and the operator has no time to answer for each. ## Label short stops or convert them to running time? Once you have a cutoff, decide what happens to the stops under it. You can label them as downtime or convert them to running time. | | Label as short downtime | Convert to running time | |---|---|---| | Counts against availability | Yes | No | | Stays in the downtime record | Yes | No | | Shows up in performance | No | Yes | | Keeps a growing total visible | Yes | No | | Fits pauses built into the cycle | No | Yes | Default to labeling. The stops stay in the record under one reason, so a machine whose short-stop total doubles still stands out on the [downtime Pareto](/docs/monitoring/downtimes/#pareto). Convert to running time only when the pause belongs to the cycle and counting it buries the record. A [stamping press](/blog/how-to-monitor-stamping-presses/) between strokes is the usual case: [the gaps between strokes](/docs/production/stamping-presses/#short-stops) would otherwise fill a shift with hundreds of one-minute rows. Remember what a converted threshold says: anything under it is not worth reporting, including a jam one minute shorter than the cutoff. ### Settings that decide which stops you see Four other settings sit near the cutoff and get confused with it. Only two of them change the numbers. | Setting | What it decides | Changes the numbers | |---|---|---| | Detection resolution | Shortest pause read as a stop | Yes | | In-cycle filter | Pauses counted as running time | Yes | | Status-color thresholds | When a stopped machine changes color | No | | Alert delay | When someone is notified | No | A status color is a display choice. A 4-minute stop is 4 minutes of downtime whether the machine showed green, orange or red. An alert decides who walks over, not what the report says. Tune each one for its own job, and don’t move the cutoff to make a screen look calmer. ## Reduce micro-stops Micro-stops respond to the same method as any other loss, measured by count instead of minutes. - **Count stops per hour.** The cartoner’s 90 stops in 7.5 planned hours is 12 an hour. Compare machines and weeks on that rate, since a longer shift has more stops. - **Look at when they happen.** A cluster after each changeover sends you to the setup. A rise late in the shift sends you to material supply or cleaning. - **Study one machine at a time.** Pick the machine with the most stops per hour, watch it for one shift and tally each cause by hand. Chronic causes repeat, so one shift of tallies shows which ones lead. - **Fix one cause, then measure.** Compare stops per hour for a week before and after. At 30 seconds each, cutting 12 stops an hour to 6 returns 3 minutes every hour. ## Track micro-stops automatically A [SenseAi](/products/senseai/) on the outside of the machine decides running or stopped every second on the device, with no PLC connection, so a 30-second stop is in the record with its start and end time. Calibration sets how long a reading must stay across a threshold before the state flips, which keeps a 4-second idle between cycles from becoming a stop, as [what the sensor decides](/docs/get-started/how-iotflows-works/#on-device) explains. The [short downtimes rule](/docs/monitoring/auto-downtime-rules/#short-downtimes) labels every stop under each machine’s cutoff, 5 minutes by default, or converts it to running time. Continuous processes add a [downtime filter](/docs/production/cycle-times-and-filters/#filter) for in-cycle pauses. [Status colors](/docs/monitoring/status-colors/#colors) change the screen without changing a number. Datwyler’s injection molding plant runs the short-downtime rule beside the shift-start and shift-end rules, and operators and supervisors classify the rest, as its [customer story](/customers/datwyler/) describes. ## Questions ### Are micro-stops the same as reduced speed? No. Both are performance losses in OEE, but a micro-stop means the machine stopped, and reduced speed means it ran slower than its ideal cycle time. Without a record of every stop the two blend into one performance number. With a stop record you can subtract the micro-stop minutes and see how much of the gap is slow cycles. ### What is a good short-stop cutoff? There is no standard value. Vorne gives two minutes as an example policy, a published bottling study used 15 minutes, and IoTFlows sets 5 minutes per machine by default. Pick the shortest duration your routine pauses never reach, write it down, and keep it fixed so this month compares with last month. ### Can a short-stop cutoff hide real problems? Yes, when stops under the cutoff are converted to running time instead of being labeled. A 10-minute cutoff that converts stops also converts a 9-minute jam, so the jam never reaches the downtime report. Labeling short stops with one reason keeps them in the record, where a growing total still shows up. ### How do you reduce micro-stops? Pick the machine with the most short stops per hour, then watch it for one shift and tally each stop’s cause by hand. Micro-stops tend to repeat the same few causes, such as misfeeds, jams and misaligned sensors. Fix the most frequent cause, then compare the stops per hour for a week before and a week after. ## Sources 1. [Six Big Losses in Manufacturing](https://www.oee.com/oee-six-big-losses/), Vorne Industries (OEE.com), accessed Oct 16, 2026 2. [OEE Calculation: Definitions, Formulas, and Examples](https://www.oee.com/calculating-oee/), Vorne Industries (OEE.com), accessed Oct 16, 2026 3. [Micro downtime: data collection, analysis and impact on OEE in bottling lines, the San Benedetto case study](https://www.emerald.com/insight/content/doi/10.1108/IJQRM-11-2016-0202/full/html), International Journal of Quality & Reliability Management (Emerald), Zennaro et al., 2018, accessed Oct 16, 2026 --- # Which downtime reason codes to log, and how many Source: https://www.iotflows.com/blog/downtime-reason-codes/ Log 8 to 12 reasons operators pick by hand, plus a few that rules assign to routine stops. Get a 15-code starter list, rules for each code and a worked Pareto. > Question: Which downtime reasons should we log, and how many is too many? ## Key takeaways - Keep the list operators pick from to 8 to 12 reason codes, so the right one is visible without scrolling. - Let rules classify routine stops such as short pauses, shift starts and ends, breaks and shifts with no job. - Name each code after what the operator saw and the fix it leads to, not after a suspected root cause. - Set severity and the planned flag separately, because a scheduled four-hour rebuild is planned and still costly. - Rank stopped hours by reason every month, and give each of the top three reasons an owner and a date. Log a reason for every stop someone would act on, and keep the list operators pick from to 8 to 12 reasons. Add four or five reasons that rules assign to routine stops, such as short pauses and shift starts, and the whole list stays under 20. A list is too long when operators scroll to find a reason, or when its biggest Pareto bar names no fix. This guide is for plant managers and the operators who classify stops. It gives a 15-code starter list, the rules for writing each code, and one month of stops ranked by reason, worked by hand. ## What a downtime reason code is > **Definition.** **Downtime reason code** is a short label that says why a machine stopped, such as Changeover or Waiting for material, picked from a fixed list so that every stop with the same cause is counted under the same name. The fixed list is the point. A free-text box collects “down”, “dwn” and “machine down” for the same stop, and none of them can be added up. A code can: 40 stops coded `Waiting for material` sum to an hour total you can rank. The IoTFlows docs call a reason code a *downtime category*, defined in the [glossary](/docs/get-started/glossary/#downtime-category). Three settings on each code make it more than a name: | Setting | Question it answers | Example | |---|---|---| | Severity | How much does this stop cost? | Breakdown is High; Lunch break is None | | Planned | Did we schedule this stop? | Preventive maintenance is planned | | Required note | Is the code enough to act on? | Breakdown needs a note; Changeover doesn’t | [Severity](/docs/get-started/glossary/#severity) and planned are separate questions. A four-hour rebuild you scheduled is planned and still High, because it takes four hours of capacity whether or not you chose it. ## How many reason codes is too many? Keep the codes operators pick by hand to 8 to 12. Operators classify mid-shift, often on a touchscreen at the machine. When the list scrolls, the first plausible code wins, and the ranking then measures the order of the list rather than the plant. A longer list doesn’t buy more detail. With 40 codes, one cause ends up split across `Material late`, `No material` and `Waiting for forklift`, and each of the three looks too small to fix. Merged, they make one bar that tops the chart. Your list is too long when: - Operators scroll or search to find a code. - Two codes lead to the same fix, as staging material fixes both `No material` and `Waiting for forklift`. - A code has collected no stops in three months. Your list is too short when: - The tallest bar names no action. `Machine problem` wins every month and tells you nothing to fix. - `Other` ranks among your top three reasons. Add a code only when someone would act differently because of it. Remove or merge one each time you add one, so the operator list stays at 12 or fewer. > **Split a code or keep it whole?** > > Split a code when its stops have different owners or different fixes. `Breakdown` and `Jam or misfeed` stay apart because maintenance fixes one and the operator clears the other. Keep a code whole when one person would make the same fix for every stop under it. ## A starter list of 15 reason codes Start from this list and rename codes to your plant’s words. It has 5 codes that rules assign and 10 that operators pick, under four severity levels: None for stops that are nobody’s loss, Low for routine planned work, Medium for avoidable waits and High for stops that need someone now. ### Codes a rule assigns | Code | Severity | Planned | Rule that assigns it | |---|---|---|---| | Lunch break | None | Yes | Stop inside a break window | | No job scheduled | None | Yes | Machine down for a whole shift | | Start of shift | Low | Yes | Stop running into a shift start | | End of shift | Low | Yes | Stop running into a shift end | | Short downtime | Low | No | Stop shorter than the cutoff | ### Codes an operator picks | Code | Severity | Planned | Note required | Six big losses | |---|---|---|---|---| | Changeover | Low | Yes | No | Setup and adjustments | | Preventive maintenance | Low | Yes | No | Setup and adjustments | | Tool change | Low | Yes | No | Setup and adjustments | | Waiting for material | Medium | No | No | Equipment failure | | Waiting for operator | Medium | No | No | Equipment failure | | Waiting for inspection | Medium | No | No | Equipment failure | | Quality adjustment | Medium | No | Yes | Setup and adjustments | | Jam or misfeed | Medium | No | No | Equipment failure | | Breakdown | High | No | Yes | Equipment failure | | Other | Medium | No | Yes | Any | The last column maps each code to the six big losses as Vorne groups them. Vorne puts major adjustments under setup and adjustments. Any other unplanned stop that needs a reason counts as equipment failure, and stops under the cutoff are minor stops. The [six big losses](/blog/what-is-oee/#six-losses) are the classic grouping of OEE losses. Vorne treats equipment failure as any unplanned stop, including a lack of operators or materials, and setup and adjustments as any planned stop, including cleaning, warm-up and quality inspections.[1] Mapping your codes to them once lets you read the Pareto and OEE in the same terms. The names hold across machine types, so one list serves the whole plant. `Changeover` is a die change on a 350-ton press, a mold change on an injection molding machine and a fixture swap on a Haas VF-2. `Jam or misfeed` is a coil misfeed on the press and a fallen bottle on a filler. Put the machine-specific detail in the note. ## Which stops should a rule classify? A rule should classify every stop whose cause you already know from the clock: short pauses, shift edges, breaks and shifts with no job. These stops make up most of the rows, and nobody needs to explain them. Leaving them to operators fills the queue with stops nobody wants to explain, and the stops that matter get skipped. Figure: An 8-hour shift with eight stops. Rules classify six, 69 min: start of shift, three short downtimes, lunch and end of shift. The operator picks reasons for two, 65 min: a 40-min changeover and a 25-min wait for material. *Rules take six of the shift’s eight stops; the operator explains the two that need a person. Sample data.* In that shift the machine stopped eight times for 134 minutes. Rules classified six stops, 69 minutes. The operator classified two, 65 minutes, and those two are the ones a person can explain. ### Set the short-stop cutoff Vorne describes minor stops as usually well under five minutes, and gives a policy of requiring a reason for any downtime longer than two minutes as an example.[1] The cutoff is a choice, not a standard. IoTFlows sets it per machine, at 5 minutes by default (see [short downtimes](/docs/monitoring/auto-downtime-rules/#short-downtimes)). Set the cutoff just above the machine’s normal pause. For example, on a mill where loading a part takes 90 seconds, a 2-minute cutoff keeps every load out of the operator’s queue, and a 4-minute stop still asks for a reason. Short stops below the cutoff still count as downtime. They collect under one code, so watch that code’s total. For where those stops land in OEE, see [micro-stops](/blog/micro-stops/#cutoff). ### Turn the rules on in order 1. Short downtimes first. They remove the most rows and hide the least. 2. Start and end of shift next, once your shift times match the floor. 3. Break windows, one per lunch wave. 4. Whole-shift stops last, only after you trust the shift calendar. A holiday the calendar calls a working shift reads as a full shift of downtime, and the rule files it under `No job scheduled`. ## Write codes that point at a fix A code is only as good as the decision it leads to. These rules keep each one actionable. - **Name what the operator saw.** `Waiting for material` is a fact at the machine. `Poor scheduling` is a conclusion, and it belongs in the review. - **Require a note where the code alone can’t be acted on.** `Breakdown`, `Quality adjustment` and `Other` earn one. `Changeover` doesn’t: 40 notes that say “changeover” add nothing. - **Set the planned flag when you build the list.** Going back later means rereading weeks of stops. - **Split a stop that holds two reasons.** A 90-minute stop where a changeover ran into a breakdown at the 30-minute mark is 30 minutes of `Changeover` and 60 of `Breakdown`, see [split a downtime](/docs/monitoring/classify-downtime/#split). - **Rename a code rather than delete it.** Deleting a code can unclassify every past stop that used it, and the history loses its reasons. - **Classify at the machine, during the shift.** A [tablet assigned to each machine](/docs/monitoring/operator-stations/) puts the list where the stop happens, while the reason is fresh. ## How do you read the reasons once they’re logged? You rank them. A Pareto chart sorts contributors from largest to smallest and adds a running cumulative percentage, which shows where the few reasons that carry most of the loss end. Joseph Juran called them the “vital few”.[2] For downtime, rank by hours, not by the number of stops: 30 short pauses cost less than one 4-hour breakdown. The full method, from stop log to chart, is in [how to build a downtime Pareto](/blog/downtime-pareto/). #### Worked example: One month on six CNC machines - Six machines, two 8-hour shifts, 22 working days: 6 × 16 × 22 = 2,112 scheduled hours. - Stopped time, with Lunch break filtered out because nobody acts on it: 240 hours, so 240 ÷ 2,112 = 11.4% of scheduled time. - Top three reasons: Changeover 62 h, Waiting for material 48 h, Breakdown 30 h, for 140 h. - Unclassified: 12 h, so 12 ÷ 240 = 5.0% of stopped time. **Result:** Top three share = 140 ÷ 240 = 58.3% of stopped time Figure: A Pareto of 240 stopped hours in one month. Changeover 62 h, Waiting for material 48 h and Breakdown 30 h reach 58.3% cumulative. Seven smaller reasons follow, from No job scheduled at 26 h to End of shift at 5 h. *Three reasons carry 58.3% of the month’s stopped hours; the other seven share the rest. Sample data.* Read it from the top, and match each bar to its fix: | Leading bar | First move | Owner | |---|---|---| | Changeover, planned | Move setup work outside the stop | Process engineer | | Waiting for material | Stage the next job before this one ends | Materials lead | | Breakdown | Read the notes, open the repairs | Maintenance | | Unclassified or Other | Fix the list or the habit first | Shift supervisor | Sample data. Check Unclassified and Other before the rest: when either ranks in the top three, the chart is ranking missing reasons. The leading bar is planned, and that matters. Planned doesn’t mean free: 62 changeover hours are 2.9% of the month’s scheduled time, and the fix is to shorten them, not to stop logging them. Give each of the top three bars an owner and a date, then compare next month’s chart to this one. The [rollout plan’s downtime phase](/docs/get-started/roll-out-plan/#phase-3) uses the same gate. For the rest of the loss picture, the same reasons feed availability, see [how to calculate OEE](/blog/how-to-calculate-oee/#availability). ## Track reason codes automatically A SenseAi sensor on each machine detects every stop in seconds, with no PLC connection or operator input. Operators put a reason on it in a tap, at the machine, in Operator View or in the iOS app, from categories under severity headings with required notes and planned-downtime flags. Four automatic rules classify short downtimes, the start and end of a shift, and a machine down for an entire shift. Break windows add a reason for lunch and breaks. The [Downtimes report](/docs/monitoring/downtimes/#pareto) ranks reasons by the hours they cost, and a classified stop can open a Maintain work order from the same dialog. Datwyler’s injection molding plant runs three of those rules, for short downtimes and the start and end of each shift, and its operators and supervisors classify the rest. Within six months it cut shift-changeover downtime by 50%, see [Datwyler’s story](/customers/datwyler/). See how it works on [downtime tracking](/solutions/downtime-tracking/). ## Prune the list every month A reason list drifts. New codes get added for one-off stops, and old ones stop being used. Fifteen minutes a month keeps it honest. 1. **Read the Other notes.** Group last month’s `Other` notes by cause. When one cause shows up in several notes, give it its own code. 2. **Merge codes that share a fix.** Fold two codes into one when the same person would make the same fix for both, for example `No material` into `Waiting for material`. 3. **Retire unused codes.** Rename a code that has collected no stops in three months into one still in use, rather than deleting it, so history keeps its reasons. 4. **Check the unclassified share.** Compare unclassified hours with last month’s. A rising share means the classifying habit is slipping, not that the plant runs better. 5. **Recount the operator list.** Count the codes operators pick by hand. If the count is above 12, merge before the next month starts. To set up the list in IoTFlows, see [design a category list](/docs/monitoring/downtime-categories/#design). For what the rest of the stop record should hold, see [what manufacturing data to collect](/blog/manufacturing-data-collection/). ## Questions ### Should micro-stops get their own reason codes? Not one code each. Stops shorter than your cutoff, often two to five minutes, go under one automatic code such as Short downtime. Watch that code’s total hours machine by machine. When it grows on one machine, study that machine’s short stops on the floor, then add a specific code only for the cause you find. ### Who should classify a stop, the operator or the supervisor? The operator at the machine, during the shift, because the operator knows whether the machine waited for material or for a program. The supervisor reviews unclassified stops at the end of each shift and corrects codes that look wrong. A reason added days later from memory is a guess, and it tilts the ranking toward whatever people remember. ### Is a changeover planned or unplanned downtime? A changeover written into the schedule is planned. One nobody scheduled for that shift, such as a rush job swapped in mid-run, is unplanned. Planned does not mean free: a changeover still takes running time away, and changeovers are usually the largest part of setup time, which makes them a good target for setup reduction. ### What should we do with the Other code? Keep it, require a note on it, and read those notes every month. When the same cause shows up in several notes, give it its own code and merge or retire one nobody uses, so the list stays the same length. If Other ranks among your top three reasons, the list is missing a code. ### Can every machine in the plant share one reason code list? Yes, and one shared list puts every machine on the same Pareto. Choose names that hold on every machine type: Changeover covers a die change on a press, a mold change on a molding machine and a fixture swap on a mill. Keep machine-specific detail in the note, so no operator faces more than about a dozen codes. ## Sources 1. [Six Big Losses](https://www.oee.com/oee-six-big-losses/), Vorne Industries (OEE.com), accessed Oct 16, 2026 2. [Pareto Principle (80/20 Rule) & Pareto Analysis Guide](https://www.juran.com/blog/a-guide-to-the-pareto-principle-80-20-rule-pareto-analysis/), Juran Institute, accessed Oct 16, 2026 --- # How to monitor CNC machines of any brand or age Source: https://www.iotflows.com/blog/how-to-monitor-cnc-machines/ Put a sensor on every CNC for run state, cycles and stops on any brand or age, then read the control over MTConnect where it pays. Includes a worked shift. > Question: How do I see run state, cycles and stops on a mix of old and new CNC machines? ## Key takeaways - A sensor on the outside of each CNC reports running, stopped, cycles and part counts the same way on every brand and age. - The control adds what only it knows, such as alarm codes, program names and feed hold, on machines that can share it. - MTConnect is read-only by design, and a machine built without it needs a custom adapter before it reports anything. - CNC uptime depends on how much of the cycle an operator carries, so compare each machine with its own type and baseline. - Ask for a stop reason only above a short-stop cutoff, so setup and waiting time stand out from chip clearing. You see run state, cycles and stops on a mixed CNC fleet by putting a sensor on the outside of every machine, so a 1998 vertical mill and a 2023 five-axis report the same running, stopped, cycle and part-count data. Then read the control directly only on the machines where you need what the control alone knows, such as alarm codes and program names. This guide is for plant managers and owners running mills, lathes and machining centers from several builders and decades. It works one hypothetical three-machine shift through, from the signal on the machine to the reason behind each stop. ## What to monitor on a CNC > **Definition.** **CNC machine monitoring** means recording, for every mill, lathe and machining center, when it runs and when it stops, how many cycles it completes, how long each cycle takes and why each stop happened, so machines of any brand or age are compared on the same numbers. Four numbers answer most of what a production meeting asks about a CNC. *Run state* is whether the machine is cutting right now. *Uptime* is the share of the shift it spent running, as the glossary entry for [uptime](/docs/get-started/glossary/#uptime) defines it. Cycle count and [cycle time](/blog/what-is-cycle-time/) say how much it made and how fast. The fifth number, the reason for each stop, comes from people. A machine can tell you it stood for 14 minutes. Only the operator knows it was waiting for a fixture. | Signal | Question it answers | Outside sensor | Control | |---|---|---|---| | Run state | Is it cutting now? | Yes | Yes | | Cycle count | How many cycles ran? | Yes | Yes | | Cycle time | How long did each take? | Yes | Yes | | Stop length | How long did it stand? | Yes | Yes | | Stop reason | Why did it stop? | From the operator | From the operator or an alarm | | Alarm code | Which fault fired? | No | Yes | | Program name | Which job ran? | No | Yes | | Feed hold | Did someone pause the axes? | No | Yes | The first four rows are the same in both columns. That is the point a mixed fleet turns on: run state, cycles and stops do not need the control at all. ## Why a mixed fleet is hard to read A shop that bought machines over 25 years runs three kinds of control at once. [Some have no network port](/blog/monitor-old-machines-without-a-plc/). Some have a builder's own interface. The newest ship with an MTConnect agent, software that serves the control's data in a shared vocabulary. Each older control needs its own translation layer first. AMT's MTConnect use case for legacy equipment says devices designed without MTConnect in mind “will always require a custom adapter”, and that where no data can be extracted from a machine, implementing the standard would be impractical.[4] The result is a fleet where the newest machines report and the oldest stay dark. For example, a shop with eight machines might get live data from the three bought since 2020 and nothing from the five that carry the most hours. Any comparison across the fleet then rests on the machines that happen to talk, not the ones that matter. A connection to a control is also a security concern for many plants, and IT usually reviews it first. Plan that review into any project that reaches the controls. ## Read every machine from the outside An outside sensor reads what the machine does, not what the control says. A [vibration sensor](/blog/how-sensors-detect-machine-state/) on the spindle housing feels cutting as a burst of vibration well above the idle level. When the trace crosses a *running threshold*, the vibration level calibrated to separate cutting from idling, the machine reads as running. Each fall back below the threshold ends one cycle. Count the falls and you have a cycle count. Time them and you have cycle times, which vary with the part on a CNC. Figure: A vibration trace over 30 minutes on a vertical mill rises above a dashed running threshold for three cycles of about 4 min 20 s, separated by 1 min part loads, then stays at idle for an 11 min stop before a fourth cycle starts. *Three counted cycles, three part loads and one 11-minute stop, all read from outside the machine. Sample data.* The figure shows what that looks like on a mill. Three cycles of about 4 minutes 20 seconds are counted, each ended by a 1-minute part load. The 11-minute flat stretch is a stop, and it is the one worth a reason. ### Mount where the cutting is Mount the sensor as close as you can to the spindle, the tool changer or the main motor housing. Pick flat ferrous metal tied to the parts that move, and keep it out of the coolant spray. The [mounting guide](/docs/hardware/install-senseai/#mounting) covers the spots that fail. > **The guard door is the wrong spot** > > A magnet holds on a sheet-metal guard door, but the door rings on its own and passes little of the driveline's vibration. Mount on the casting instead, then run the machine cutting and idle and confirm the two read differently. Calibrate against 5 to 10 complete machining cycles, not a spindle warm-up, so the threshold sits between real cutting and real idle. ### Count cycles that change with the part A CNC runs a different cycle for every part, from 30 seconds to 30 minutes. Dividing run time by one fixed cycle time breaks the moment the job changes. Count the cycles the sensor detects instead, which is how [Discrete Analysis](/docs/production/choose-an-algorithm/#discrete) works, so the count stays right across a changeover. You still record an ideal cycle time for each part. The count doesn't need it, but the shift goal and the performance figure do. The guide to [counting parts and cycle times on CNC mills and lathes](/blog/cnc-cycle-time-and-part-counts/) covers the setup in full. ## Read the control where it has more to say The control knows things no sensor can feel: which program is loaded, which alarm fired, whether the operator pressed feed hold. On a machine with an MTConnect agent, those arrive as named data items. MTConnect is read-only by design. The standard says its REST API “is read-only and does not produce any side effects on the agent or the equipment”.[1] A client reads the machine; it cannot load a program or clear an alarm. > **Definition.** **Execution state (MTConnect)** is the operating state a CNC control reports through MTConnect, such as ACTIVE while it executes an instruction, READY while it is idle and ready to run, or FEED_HOLD when axis motion is commanded to stop. MTConnect defines these execution values, among others:[2] | Execution value | What the control is doing | |---|---| | ACTIVE | Executing an instruction | | READY | Idle, ready to execute | | FEED_HOLD | Axes commanded to stop in place | | INTERRUPTED | Suspended by an external signal | | OPTIONAL_STOP | Paused by a command in the program | | PROGRAM_STOPPED | Stopped by the program; needs action | | PROGRAM_COMPLETED | Program finished | | STOPPED | Program not ready to execute | Values from the MTConnect ExecutionEnum, model version 2.5. WAIT, added in version 1.5, pauses execution for a secondary operation. The values explain why a sensor's “stopped” sometimes needs a second look. A sensor sees the spindle quiet. The control can say whether it is quiet because the program finished, because the operator held the feed, or because the program is waiting at an optional stop for a measurement. *Controller mode* adds the other half, with values such as AUTOMATIC, MANUAL, MANUAL_DATA_INPUT, SEMI_AUTOMATIC and EDIT.[3] A machine reading READY in MANUAL for the first hour of a shift points to setup. The [protocol comparison](/blog/machine-communication-protocols/) covers MTConnect, OPC UA and Modbus side by side. > **Sensor, control or both?** > > Default to a sensor on every machine for run state, cycles and stops, because it reads every control the same way. Add control data on a machine when a recurring question depends on what only the control holds: which alarm stops it, which program runs slow, or how often feed hold interrupts a cycle. You don't need control data to find out where the shift's hours went. The [sensor-based versus PLC comparison](/compare/sensor-based-vs-plc-machine-monitoring/) lays out what each approach sees, with its sources. ## One shift on a mixed fleet The numbers below follow three hypothetical machines through one shift, so you can see what a common data source makes comparable. #### Worked example: Three CNCs, one 8-hour shift - Shift: 480 minutes with a 30-minute lunch, so planned production time is 450 minutes per machine. - 1998 vertical mill, manual loads: running 243 minutes. Its job has an ideal cycle time of 4 minutes 20 seconds, and it made 50 parts. - 2012 lathe with a bar feeder, running automatic: running 351 minutes. - 2023 five-axis machining center, operator-loaded: running 270 minutes. Uptime is 243 ÷ 450 = 54.0% on the mill, 351 ÷ 450 = 78.0% on the lathe and 270 ÷ 450 = 60.0% on the five-axis. The mill's ideal output time is 50 × 4 min 20 s = 216.7 minutes, so its performance is 216.7 ÷ 243 = 89.2%. **Result:** Fleet uptime = 864 ÷ 1,350 running minutes = 64.0% Figure: Three shift timelines of 450 planned minutes: a 1998 mill runs 54.0% with a 96 min setup stop and 50 min of short stops, a 2012 bar-fed lathe runs 78.0% and a 2023 five-axis runs 60.0%. Fleet uptime is 64.0%. *Each machine sits inside the range its loading method allows, and the mill's longest stop is setup. Sample data.* Read each machine against its own type, not against the others. A manual machine runs 40 to 60% of a shift, an operator-loaded one 50 to 70% and an automatic one 75 to 85%, per the [CNC setup guide's ranges](/docs/production/cnc-machines/#expectations). All three machines sit inside their range. Ranking the mill last because 54% is below 78% would send effort to the wrong place. The useful question is where the mill's 207 stopped minutes went. In this shift, setup took 96 of them, short stops 50, waiting on material 25, first-article inspection 20 and tool changes 16. Setup is the largest single loss, and it was invisible until each stop carried a reason. Performance at 89.2% is a separate question, which [how to calculate OEE](/blog/how-to-calculate-oee/) works through factor by factor. Don't chase a fleet-wide spindle target either. Modern Machine Shop's Mike Lynch notes that some large-lot shops can justify almost anything to pass 95% spindle run time, while others accept under 20%.[5] Unless a CNC is the constraint for its cell, and the cell is the constraint for the company, there is no need to improve its productivity.[5] ## Give every stop a reason Stop lengths say how much time you lost. Reasons say what to fix. Start with a short list built for machining, and add codes only when a reason keeps appearing as “other”. | Reason | What it covers | Who acts on it | |---|---|---| | Setup and changeover | Fixtures, offsets, first program run | Setup lead | | First-article inspection | Measuring the first good part | Quality | | Tool change or breakage | Unplanned tool swaps, broken tools | Tooling | | Waiting on material | No stock or blanks at the machine | Materials | | Waiting on program | No released program or revision | Programming | | Waiting on operator | Operator at another machine | Supervisor | | Maintenance | Repairs and alarms needing a technician | Maintenance | A starting list for machining. Add a code only when the same reason keeps landing in other. Set a short-stop cutoff before you ask anyone to classify anything. Below the cutoff, stops such as part loads, chip clearing and gauging are still recorded but never reach the operator's list. For example, the mill's 50 minutes of short stops were 50 stops under 2 minutes, nearly all of them part loads. A 2-minute cutoff keeps all 50 off the list, so the operator classifies four stops instead of 54. You don't need operators to classify every stop. You need them to classify the ones long enough to fix. The [short-stop settings](/docs/hardware/calibrate-senseai/#short-stops) show where the cutoff lives. Build the reason list by [creating a category](/docs/monitoring/downtime-categories/#create) for each code. ## Monitor CNC machines with IoTFlows IoTFlows puts a [SenseAi](/products/senseai/) on each CNC. It attaches magnetically in seconds near the spindle, calibrates in under five minutes and reads vibration and sound from outside the machine, with no PLC or controller access. Discrete Analysis counts every cycle, so each part a machine runs reports its own count and cycle time. Where coolant is unavoidable, the IP67 SenseAi Embedded mounts at the spindle motor. On Enterprise, the IoTFlows edge device adds controller data over MTConnect and other protocols as a [custom integration](/platform/custom-integrations/). It reads only the controls you choose to connect. Jesel, a valvetrain manufacturer in Lakewood, New Jersey, reviews OEE daily and validates actual cycle times against its bills of material. It [responds to an issue in seconds or minutes](/customers/jesel/), down from hours or days. ## Roll it out across the shop 1. **List every machine and how it runs.** Write down each CNC with its control, its age and whether it runs manual, operator-loaded or automatic. The loading method sets the uptime range you compare it with. 2. **Set shifts before reading a number.** Enter the plant's timezone and shifts first, because they decide which minutes count as planned. The [shifts and timezone guide](/docs/admin/shifts-and-timezone/) explains why they come first. 3. **Mount and calibrate one machine of each type.** Start with one mill, one lathe and one machining center. Calibrate each against 5 to 10 real cutting cycles. 4. **Validate the count by hand.** Run two to four hours, then compare the recorded count with a hand count over the same window. A count that reads exactly double or half is a quantity-per-cycle setting, as [troubleshooting part counts](/docs/production/troubleshoot-part-counts/) explains. 5. **Set each goal from its own baseline.** After a week, set each machine's uptime goal at its own baseline plus 5 to 10%. A goal a machine has never met teaches operators to ignore the number. 6. **Rank the stops after two to four weeks.** Read the classified stops off a [Pareto of downtime reasons](/docs/monitoring/downtimes/#pareto), and work the largest reason down first. 7. **Add control data where a question needs it.** Pick the machines whose recurring stops need an alarm code or a program name to explain, have IT review the connection, and connect only those. Once the first three machines read correctly, copy their setup to the rest of the fleet. More machine-by-machine guides are under [machines and connectivity](/blog/topics/machines-and-connectivity/). ## Questions ### Can MTConnect change a program or setting on a CNC? No. The MTConnect standard defines its REST API as read-only, with no side effects on the agent or the equipment. A client can read execution state, controller mode, part counts and alarms, but it cannot load a program, edit an offset or clear an alarm through MTConnect. ### What uptime should a CNC machining center reach? It depends on how much of each cycle an operator carries. A manual, operator-intensive machine often runs 40 to 60% of the shift, an operator-loaded one 50 to 70% and a fully automatic one 75 to 85%. Set each goal from that machine's own baseline plus 5 to 10% rather than from a fleet average. ### Do I need a network port on an old CNC to monitor it? No. A vibration sensor mounted on the spindle housing or the main motor casting reads running, stopped, cycle counts and cycle times from outside the machine. It needs power and a wireless connection of its own, and it never connects to the control, so the age of the control does not matter. ### How do I check that a CNC part count is right? Let the machine run normally for two to four hours, then compare the recorded count with a hand count over the same window. Twenty parts made should read 20, give or take one or two. A count that reads exactly double or half points to the quantity per cycle setting, not to the sensor. ## Sources 1. [MTConnect Standard Part 1.0: Fundamentals, Version 2.5.0](https://docs.mtconnect.org/MBSD_MTConnect_Part_1_2-5-0.pdf), MTConnect Institute, accessed Oct 16, 2026 2. [ExecutionEnum, MTConnect SysML Model V2.5](https://model.mtconnect.org/Version2.5/Profile/DataTypes/ExecutionEnum/), MTConnect Institute, accessed Oct 16, 2026 3. [ControllerModeEnum, MTConnect SysML Model V2.5](https://model.mtconnect.org/Version2.5/Profile/DataTypes/ControllerModeEnum/), MTConnect Institute, accessed Oct 16, 2026 4. [Digital Manufacturing for Legacy Equipment Using a Standards-Based Approach: An MTConnect Use Case](https://www.amtonline.org/article/digital-manufacturing-for-legacy-equipment-using-a-standards-based-approach), AMT, The Association For Manufacturing Technology, accessed Oct 16, 2026 5. [Judging Acceptable Spindle Run Time](https://www.mmsonline.com/columns/judging-acceptable-spindle-run-time), Modern Machine Shop, accessed Oct 16, 2026 --- # The true cost of idle machines Source: https://www.iotflows.com/blog/cost-of-idle-machines/ An idle machine keeps costing you depreciation, floor space, idle power and any operator waiting at it. Price an idle hour, and learn when it costs output too. > Question: What does a machine cost when it sits idle with no job scheduled? ## Key takeaways - An idle machine still costs its depreciation, financing, floor space and insurance, because those costs run by the calendar. - Fixed cost per running hour doubles when utilization halves, so idle hours raise the cost of every part the machine makes. - Idle power and an operator waiting at the machine are the cash costs that an idle hour adds. - Count lost margin only when the idle machine is a bottleneck or the plant is turning work away. - A sensor reads idle time and downtime alike as stopped, so a reason code is what tells them apart. An idle machine costs you what you pay to own it, plus the power it draws and the pay of anyone waiting at it. Depreciation, financing, floor space and insurance run by the calendar, not the spindle, so every idle hour raises the cost of each hour the machine does run. Lost output is a cost only when you had work the machine could have made. This guide is for owners and plant managers deciding whether idle hours are worth chasing. It prices one hypothetical machining center's idle hour, then shows how to measure idle time and cut the hours that cost the most. ## Idle time is not downtime > **Definition.** **Idle time** is scheduled time when a machine is ready to run but has no job to run. A stop during a job, including a wait for an operator, material or a program, is downtime instead, because the plant meant the machine to be making parts. The difference decides which costs apply. A downtime hour breaks a promise the schedule made, so it costs output, recovery and often overtime. An idle hour breaks no promise, so its cost is quieter: the machine's fixed costs, carried by fewer parts. *Utilization* is the share of scheduled time a machine runs, so idle time and downtime both lower it, see the [utilization glossary entry](/docs/get-started/glossary/#utilization). OEE treats them differently. Time with no production scheduled comes out of [planned production time](/blog/what-is-oee/#availability) before availability is calculated, so a machine can post a strong OEE while it sits idle for whole shifts. Figure: A bar divides one machine's 8,760-hour year into 2,000 h running, 800 h downtime, 1,200 h idle with no job and 4,760 h with no shift. OEE sees 2,800 h, the shifts cover 4,000 h at 50% utilization, and fixed costs run on all 8,760 h. *One machine's year, bucket by bucket: OEE sees 2,800 hours, utilization sees 4,000 and fixed costs see all 8,760. Sample data.* The worked example below uses these hours: two 8-hour shifts, five days a week, 50 weeks a year, for 4,000 scheduled hours. The machine runs 2,000 of them, is stopped during jobs for 800, and sits idle with no job for 1,200. ## What an idle machine still costs An idle machine stops consuming cutting tools and coolant, and almost nothing else. NIST prices unplanned downtime from maintenance issues in US discrete manufacturing on the same logic: as the share of labor, energy and capital left idle, because "if there was less downtime, then lower levels of energy, labor, and capital would be, in general, needed to produce the same goods."[1] Of NIST's $18.1 billion total for 2016, labor made up $12.1 billion to $13.8 billion and energy $1.1 billion to $1.3 billion.[1] | Cost | Stops when the machine idles? | When it counts | |---|---|---| | Depreciation and financing | No | Keep, sell or buy decisions; shop rate | | Floor space and insurance | No | Keep, sell or buy decisions; shop rate | | Idle power | No, unless switched off | Every idle hour it stays on | | Operator waiting at the machine | No | Every hour someone waits | | Material bought ahead of the job | No | Cash tied up until the part ships | | Lost margin | Not applicable | Only with work it could have made | Fixed costs are spent whether the machine runs or not. Idle hours change how many parts share them. The first two rows don't grow when the machine idles. They grow per part. For example, a machine that runs half its shifts charges each running hour twice the depreciation it would charge running every shift. The material row matters when stock arrives before the machine is free to use it. The bar stock, castings or resin sit on the floor as cash, at whatever carrying rate your finance team uses, until the part ships. ## Price an idle hour Price an idle hour in two parts: the fixed cost it fails to absorb, and the cash it spends. Work out each machine's annual fixed cost first, because both the shop rate and the keep-or-sell decision start from it. **Fixed cost per running hour** = (Annual fixed cost) ÷ (Hours the machine runs in a year) > **Definition.** **Fixed cost per running hour** is a machine's annual ownership cost divided by the hours the machine actually runs: the share of depreciation, financing, floor space and insurance that each running hour must recover through the parts made in it. #### Worked example: Idle hours on a vertical machining center, one year - Purchase: $180,000 with tooling and installation, depreciated straight-line over 10 years, so $18,000 a year. - Financing: 8% on the $90,000 average book value, so $7,200 a year. - Floor space: 400 sq ft at $12 a sq ft a year, so $4,800. Insurance and the service contract: $2,000. - Annual fixed cost: $18,000 + $7,200 + $4,800 + $2,000 = $32,000, or $8.00 per scheduled hour over 4,000 hours. - Running 2,000 hours (50% utilization): $32,000 ÷ 2,000 = $16.00 of fixed cost per running hour. The 1,200 idle hours carry 1,200 × $8.00 = $9,600 that no part pays for directly. - Idle power: the control, hydraulic unit, coolant pump and conveyor draw 4 kW with the spindle stopped. At the US industrial average of 9.77 cents per kWh in July 2026,[3] an idle hour costs 4 × $0.0977 = $0.39, and the 1,200 idle hours cost $468.96. - Left on outside shifts as well: 4 kW × 4,760 hours = 19,040 kWh, or $1,860.21 a year. - Operator waiting: private manufacturing employers paid $48.62 an hour in wages and benefits in June 2026.[2] An operator who waits at the machine for 200 of the idle hours costs 200 × $48.62 = $9,724. **Result:** One idle hour = $8.00 unabsorbed + $0.39 power, plus $48.62 if an operator waits = $57.01 Labor dwarfs power, the same pattern NIST found nationally. The power bill outside shifts is almost four times the bill for idle hours inside them, so a power-down routine at the end of the last shift saves more power than trimming idle minutes inside shifts. Figure: A curve of fixed cost per running hour against utilization for $32,000 a year over 4,000 scheduled hours: $32.00 at 25%, $16.00 at 50%, $10.67 at 75% and $8.00 at 100%. *The same $32,000 a year costs each running hour twice as much at 25% utilization as at 50%. Sample data.* The curve is steepest at low utilization. Moving from 25% to 50% takes $16.00 off every running hour, while moving from 75% to 100% takes $2.67. Chase idle hours hardest on the machines that run least, provided there is work for them. ## When idle time costs you output An idle hour costs margin only when demand exceeds what the plant can make. If the machine has no work because there is no work, the hour costs its fixed share and its cash and nothing more. > **Is this idle hour lost margin?** > > Count lost margin when the machine is the bottleneck, when orders are late or turned away, or when you run overtime or send out work it could do. Count only fixed cost and cash when the machine finishes its share of the plan with hours to spare. For example, suppose the machining center is the bottleneck for a part with $22 of contribution margin after material and direct labor, and it makes 12 an hour. An idle hour then also loses 12 × $22 = $264, for $321.01 in all with an operator waiting. If your margin figure is price less material only, drop the $48.62, or you count the operator twice. The bottleneck test matters because idle time on other machines is often correct. Writing in Modern Machine Shop, Mike Lynch puts it plainly: "A CNC machine in the cell may sit idle for long periods of time and still be appropriately utilized."[4] Making a non-bottleneck machine run more only builds inventory in front of the bottleneck. ## How much idle time is normal? No universal figure exists. Lynch notes that shops with large lot sizes may justify more than 95% spindle run time, while others accept less than 20%.[4] The right number depends on lot sizes, how much of the cycle an operator carries, and whether the machine is the bottleneck. National data gives context, not a target. US manufacturing used 75.7% of its capacity in August 2026, 2.5 points below its 1972–2025 average of 78.2%.[5] That figure compares output with sustainable capacity across whole industries, so it won't match a single machine's run time. For a CNC machining center, IoTFlows' [CNC setup guide](/docs/production/cnc-machines/#expectations) expects 40 to 85% uptime depending on how much of the cycle an operator carries. Set each machine's goal from its own baseline plus 5 to 10%, not from a published range, see [utilization goals](/docs/monitoring/oee-goals/). ## Measure idle time apart from downtime A running-or-stopped signal can't tell idle from downtime: both are a stopped machine. The reason code on the stop is what splits them, so the measurement is half sensor and half operator. 1. **Define your shifts.** Idle time exists only against a schedule. Enter the hours each machine is meant to be available, including any shift that crosses midnight, see [shifts and time zone](/docs/admin/shifts-and-timezone/). 2. **Record running and stopped automatically.** Use a sensor or a controller signal, not a paper log. A hand log rounds a 7-minute wait to zero and a 50-minute gap to an hour, and [manual data collection](/blog/manufacturing-data-collection/#manual) misses short stops the same way. 3. **Add reason codes for idle time.** Create `No job scheduled` and `Waiting for next job` beside your downtime reasons. Mark a code as planned only when the schedule left the machine open on purpose, see [planned downtime](/docs/monitoring/downtime-categories/#planned). 4. **Have operators classify at the machine.** The operator knows whether the machine is waiting for a job or for a forklift. A reason entered at the machine, in the moment, beats one reconstructed at the end of the week. 5. **Alert on stops that run long.** Set a Machine Down alert at a warning time above your normal changeover and a critical time well past it, for example 15 and 45 minutes, see [machine status alerts](/docs/alerts/asset-event-rules/#machine-status). The alert is a duration rule: it tells a lead that a machine has been stopped too long, so someone loads the next job. 6. **Read a full quarter by machine and shift.** Filter the utilization report by shift to read scheduled hours only, see [report filters](/docs/monitoring/advanced-report/#filters). Then rank the idle and downtime reasons by hours on a [downtime Pareto](/docs/monitoring/downtimes/#pareto). ## Cut the idle hours that cost the most Start with the machines where an idle hour costs the most: the bottleneck first, then the machines with the lowest utilization and the highest fixed cost. The reason codes tell you which fix applies. | Why there is no job | First fix | |---|---| | Not enough orders for its work | Quote work that fits it | | Work routed to a favorite machine | Route by measured capacity, not habit | | Gap between two jobs | Release the next job before this ends | | Next job not ready | Stage material, prove programs offline | | Kept as backup capacity | Keep it, and count its cost as insurance | Three decisions follow from the numbers: - **Power down outside shifts** when the machine doesn't need a warm-up to hold tolerance. In the example, that is $1,860.21 a year from one machine. - **Sell or consolidate** a machine that sits idle most of a year and covers no bottleneck. Its fixed cost is the saving, $32,000 a year in the example. - **Measure before you buy.** A request for another machine is a request for hours. Check whether the machines you own have idle hours that a better schedule could fill. ## Track idle hours automatically A SenseAi sensor mounts magnetically on each machine and reads its vibration and sound from the outside, with no PLC connection. It decides running or stopped every second, so every stop shows up without anyone writing it down. Operators put a reason on a stop in a tap, which is what splits idle time from downtime. The Advanced Report totals utilization by machine and shift over any period, and the Production Scheduler plans on the same machines the sensors monitor, so the schedule uses the real part count. Storm Power Components runs CNC machines, lasers and presses in Decatur, Tennessee. It doubled machine utilization and now schedules on real utilization data, see [Storm Power's story](/customers/storm-power-components/). See how it works on [machine utilization tracking](/solutions/machine-utilization/). ## Questions ### Should I switch machines off when they sit idle? Switch off what you can between shifts and over weekends, because on a two-shift machine those hours outnumber the idle hours inside shifts. Inside a shift, a short idle spell rarely justifies a shutdown when the machine needs a warm-up to hold tolerance. Ask the builder which subsystems, such as coolant pumps and chip conveyors, can stop on their own. ### How should idle time change my shop rate? Spread a machine's fixed costs over the hours you expect it to run, not over the hours it is scheduled. A rate built on 90% utilization for a machine that runs 50% of its shifts recovers a little over half of the fixed cost, and every quoted job carries the gap. ### Does idle time lower OEE? Only partly. Time with no production scheduled comes out of planned production time before availability is calculated, so a machine with no orders for half its shifts can still show a high OEE. Waiting for material or an operator during a scheduled job does count against availability. ### Should I sell a machine that sits idle most of the year? Compare what it costs to own each year with what it does for you when it runs. A machine that covers the bottleneck during breakdowns, takes rush jobs or protects a customer's delivery dates can justify its fixed cost while idle. If it does none of those, selling it frees the capital and the floor space. ## Sources 1. [Economics of Manufacturing Machinery Maintenance: A Survey and Analysis of U.S. Costs and Benefits (NIST AMS 100-34)](https://nvlpubs.nist.gov/nistpubs/ams/NIST.AMS.100-34.pdf), National Institute of Standards and Technology, accessed Oct 16, 2026 2. [Employer Costs for Employee Compensation, Table 4: Private industry workers by occupational and industry group, June 2026](https://www.bls.gov/news.release/ecec.t04.htm), U.S. Bureau of Labor Statistics, accessed Oct 16, 2026 3. [Electric Power Monthly, Table 5.6.A: Average price of electricity to ultimate customers by end-use sector](https://www.eia.gov/electricity/monthly/epm_table_grapher.php?t=epmt_5_6_a), U.S. Energy Information Administration, accessed Oct 16, 2026 4. [Judging Acceptable Spindle Run Time](https://www.mmsonline.com/columns/judging-acceptable-spindle-run-time), Modern Machine Shop, accessed Oct 16, 2026 5. [Industrial Production and Capacity Utilization, G.17 (release of September 18, 2026)](https://www.federalreserve.gov/releases/g17/current/default.htm), Federal Reserve System, accessed Oct 16, 2026 --- # What manufacturing data to collect, and how to collect it Source: https://www.iotflows.com/blog/manufacturing-data-collection/ Collect machine state, part counts, stop reasons and scrap first. See what sensors, controllers and operators each capture, and what to ask a vendor. > Question: What shop-floor data is worth collecting, and what should I ask a vendor? ## Key takeaways - Start with four records on every machine: when it runs and stops, how many parts it makes, why it stopped and what was scrapped. - A sensor records when a machine stopped and for how long, but only a person at the machine can record why. - Paper logs miss short stops, so availability on paper reads higher than the machine’s real availability. - Controller data adds alarms, programs and process values, and IT usually reviews that connection before it goes live. - Ask a vendor which records arrive with no typing, how counts are validated and how you get every record back out. The shop-floor data worth collecting first is four records per machine: when it runs and stops, how many parts it makes, why each stop happened and which parts were scrapped. When you evaluate a data collection system, ask which of those records it captures with no typing, how it reads machines of every age, and how you check and export what it records. Owners and plant managers deciding where to start get three things here: what sensors, controllers and operators each capture, why paper logs undercount, and a checklist to take into a vendor call. ## What manufacturing data collection means > **Definition.** **Manufacturing data collection** is the capture of what each machine and its operators did during a shift: when the machine ran and stopped, how many parts it made, why it stopped and which parts were scrapped, recorded with timestamps as each event happens. The machine record sits at the bottom of every other system in the plant. ISA-95, the standard for connecting plant-floor systems to business systems, puts “the collection of data and the manipulation of physical processes” at Level 1, manufacturing execution systems (MES) at Level 3 and the activities of running the business, such as ERP, at Level 4.[1] For example, an ERP that reports the cost of a job needs the machine hours that job used. If those hours come from an operator’s estimate at the end of the shift, the job cost inherits the estimate. ## Why manual collection falls short Most plants already collect data, on paper travelers, whiteboards or a spreadsheet filled in at the end of the shift. Manual records fail in three ways: - **Short stops go unrecorded.** Nobody writes down a two-minute jam, and a busy machine has many of them in one shift. - **Times are estimates.** A stop logged as “about 20 minutes” at 3 p.m. was written from memory. - **The data arrives late.** A sheet read the next morning can’t help the shift that produced it. *Minor stops* are short interruptions, often a minute or two long, that operators clear without calling maintenance staff.[2] Vorne’s rule of thumb is to set the line between a minor stop and a logged stop by your policy for tracking reasons, for example a reason on any stop longer than two minutes.[2] Anything shorter rarely reaches a paper log. #### Worked example: One shift on a CNC lathe, logged two ways - Shift: 480 minutes, with a 30-minute break, so planned production time is 450 minutes. - Sensor record: 17 stops. Three long ones (25, 18 and 12 minutes) add up to 55 minutes, and 14 short stops of 2 minutes add 28 more, for 83 minutes stopped. - Paper log: the three long stops, 55 minutes. Availability from the paper log is (450 − 55) ÷ 450 = 87.8%. Availability from the sensor record is (450 − 83) ÷ 450 = 81.6%. A third of the stopped time (28 of 83 minutes) never reached the paper. **Result:** Logged availability 87.8%, measured availability 81.6% Figure: Two timelines of the same 480-minute shift. The sensor record shows 17 stops totaling 83 minutes; the paper log shows only the 3 long stops, 55 minutes. 28 minutes of short stops are missing from the log. *The same shift, recorded by a sensor and by hand: the short stops disappear from the paper. Sample data.* The missing 28 minutes don’t vanish from your results. The paper log counts them as run time, and in OEE minor stops count as a performance loss, so the machine looks slow instead of stopped and nobody looks for the cause.[2] [What is OEE?](/blog/what-is-oee/) explains how the three factors split those losses. ## What data is worth collecting Each record answers one question, and each has a natural source. Collect the first five on every machine before you add anything else; cycle time comes from the count at no extra cost. | Record | Question it answers | Where it comes from | |---|---|---| | Machine state | When did it run, and how long did it stop? | Sensor or controller | | Part count | How many parts, at what pace? | Sensor, laser counter or controller | | Cycle time | How long does one part take? | Derived from the count | | Stop reason | Why did it stop? | Operator, or an automatic rule | | Scrap and its reason | How many were bad, and why? | Operator | | Vibration and temperature | Is the machine wearing? | Sensor on the motor or spindle | | Alarms and programs | What did the control see? | Controller connection | | Job and order | What was it supposed to make? | ERP or the schedule | Each role reads the same records at a different level: - **Operators** need the count against the shift goal and the stops still waiting for a reason, at the machine. - **Plant managers** need the fleet: which machines are down now, and which reasons cost the most hours this week. - **Engineers and maintenance** need history: cycle times by part, the step that limits a line, and vibration trends on critical machines. You don’t need vibration data on every machine. Add it where a breakdown stops a line or a repair costs days, for example on the spindle of the one 5-axis machining center that every job passes through. ## Machine data and human context A machine record tells you when a machine stopped and for how long. It can’t tell you why. A spindle that sits still for 14 minutes looks the same in the data whether the operator was waiting for material, changing a tool or refilling coolant. The reason comes from the person at the machine. A *downtime category* is a reason code an operator puts on a stop, such as Tool change or Waiting for material; the [glossary entry](/docs/get-started/glossary/#downtime-category) lists what each one carries. The best stop record combines all three sources: the time from the sensor, the alarm from the controller where one is connected, and the reason from the operator. Figure: A sensor, a controller and an operator each feed one stop record for a Haas VF-2: stopped 14 minutes from 10:42 to 10:56 (sensor), alarm low coolant level (controller), reason coolant refill and a note (operator). *Each source fills the fields it can see, and the stop record holds all of them. Sample data.* Reasons pay off over weeks, not on the day. Datwyler’s injection molding plant found that “Tuesday shift transitions turned out to add 8 to 10 minutes of downtime, every week”, a pattern that showed up week over week once every stop carried a reason. The [Datwyler story](/customers/datwyler/) shows how three automatic rules classify routine stops and operators classify the rest. Keep the reason list short enough to fit on one screen. An operator facing a long list picks whatever sits at the top. ## Three ways to get data off a machine You can read a machine from the outside with a sensor, from the inside through its controller, or by having a person write it down. Most plants combine at least two. | | External sensor | Controller connection | Manual entry | |---|---|---|---| | Works on any machine age | Yes | No | Yes | | Needs access to the control | No | Yes | No | | Records short stops | Yes | Yes | No | | Records why it stopped | No | No | Yes | | Reads alarms and programs | No | Yes | No | | Usual IT review | Network access only | The controller connection | None | Stop reasons come from operators in every setup. A controller alarm can suggest a reason but doesn’t replace one. An external sensor reads vibration, sound or a passing part, and decides from that signal whether the machine is running. It works the same on a 1985 manual-load lathe and a new machining center, because it never touches the control. A controller connection reads what the control already knows, over standards such as [MTConnect for CNC machines and OPC UA](/blog/machine-communication-protocols/). OPC UA, released in 2008, includes message encryption, message signing and certificate-based authentication.[3] Even so, a connection to a [PLC](/docs/get-started/glossary/#plc) or CNC control is a security concern for many plants, and IT usually reviews it first. [Sensor-based vs PLC machine monitoring](/compare/sensor-based-vs-plc-machine-monitoring/) compares what each method sees, signal by signal. > **Sensor or controller connection?** > > Default to a sensor on every machine. It covers mixed brands and ages, needs no access to the control and records state, counts and stops from day one. Add a controller connection where you need alarm codes, program names or process values such as spindle load, and where IT has approved it. ## How often to record Record machine state as events, not snapshots. A *state change event* is a record written the moment a machine starts or stops, with its timestamp. For example, a system that polls a machine every 15 minutes sees “running” at 10:30 and at 10:45, and misses a 9-minute stop in between. An event log records the stop at 10:34 and the restart at 10:43. Ask where and how the running-or-stopped decision is made. A device that decides on the machine, every second, against settings fixed at calibration catches the stops a poll misses; [how IoTFlows works](/docs/get-started/how-iotflows-works/#on-device) shows that path for one system. Every metric downstream is built from that stream, so ask how calibration is checked too. Counts and scrap can then be summed by hour or by shift from the same events. Vibration for machine health is the exception: a vibration spectrum is computed from the raw signal, sampled far faster than any state change. ## A buyer’s checklist for a data collection system Take these questions into a vendor call. The right column is what a good answer sounds like. | Question to ask | A good answer | |---|---| | Which records arrive with no typing? | State, counts and stop times | | Does it work on our oldest machine? | Yes, with no wiring into the control | | Where is running or stopped decided? | On the device, from calibrated settings | | How does an operator add a reason? | One tap, at the machine or on a phone | | How are part counts validated? | Against a hand count of ten parts | | What does IT need to approve? | HTTPS on port 443, or a cellular router | | Does it connect to controllers? | Only the ones you choose to connect | | Which systems does it feed? | ERP, CMMS and chat, both ways if needed | | Can we get the raw records out? | CSV export and an API | | How long until the first data? | The same day for the first machine | Ask the vendor to show each answer on a live machine, not on a slide. Leave out questions about features the machine record doesn’t need. Payroll rules, supplier scoring and demand forecasting belong to other systems; a data collection system should feed them, not replace them. ## Collect machine data automatically IoTFlows records state, part counts and stop times with a sensor on each machine, and operators add reasons and scrap. A [SenseAi](/docs/get-started/glossary/#senseai) attaches with a magnet, reads vibration and sound from the outside and decides running or stopped every second on the device, with no PLC connection. Part counts and cycle times come from the same signal. Operators classify a stop in a tap at the machine, in Operator View or in the iOS app, and automatic rules classify routine ones such as short stops and shift starts. On Enterprise, the IoTFlows edge device brings in PLC, robot and CNC data through [custom integrations](/platform/custom-integrations/), and reads only the controls you choose to connect. [MiRus](/customers/mirus/) runs a two-way Epicor connector that ties every job to the machining and labor hours behind it, and the connector went live in about a month. ## Where to start 1. **Pick one area.** Start with the machines that limit output, not the whole plant. The [rollout plan](/docs/get-started/roll-out-plan/) walks through a first line, then operator adoption, then reasons. 2. **Set shifts before you read any number.** Every figure is bucketed by shift as it arrives, so set the timezone and [shifts](/docs/admin/shifts-and-timezone/) first. 3. **Write a short reason list.** Give operators reasons they can choose in a tap, grouped by how much each costs. 4. **Validate the count.** Run ten parts, count them by hand and compare. The [production quickstart](/docs/production/quickstart/#validate) walks through the check. 5. **Review stops every week.** Rank reasons by the hours they cost with a [downtime Pareto](/docs/monitoring/downtimes/#pareto), fix the top one, and check the next week whether it shrank. ## Questions ### Do I need to connect to the PLC to collect machine data? No. A sensor mounted on the outside of a machine records running and stopped time, part counts and vibration with no access to the control. Connect to the controller when you need data only it holds, such as alarm codes, the active program or spindle load, and plan for an IT review of that connection. ### How often should machine data be recorded? Record machine state as events with timestamps, not as periodic snapshots. A reading taken every 15 minutes cannot see a two-minute stop, while a state change logged the second it happens catches every stop. Counts and scrap can then be summed by hour or by shift from the same record. ### How is data collection different from an MES? Data collection captures what happened at each machine: state, counts, reasons and scrap. An MES uses records like these to manage production orders, routings and execution across the plant. Collect machine data first when you don’t yet know how your machines run, because every MES function depends on an accurate machine record. ### Can operators still log data by hand? Yes, and they should for the things only they know: the reason for a stop, the cause of a scrapped part and notes for the next shift. What changes is that the machine records the time and duration of each stop on its own, so the operator adds the reason instead of writing down the clock. ## Sources 1. [ISA-95 Standard: Enterprise-Control System Integration](https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard), International Society of Automation, accessed Oct 16, 2026 2. [Six Big Losses in Manufacturing](https://www.oee.com/oee-six-big-losses/), Vorne Industries, accessed Oct 16, 2026 3. [Unified Architecture](https://opcfoundation.org/about/opc-technologies/opc-ua/), OPC Foundation, accessed Oct 16, 2026 --- # What Industry 4.0, IIoT and digital twins mean Source: https://www.iotflows.com/blog/industry-4-0-iot-and-digital-twin/ Industry 4.0 is the goal, IIoT carries the machine data and a digital twin is a live copy that also acts. See what each means for a small plant, with numbers. > Question: What do Industry 4.0, IIoT and digital twin mean for a 50-person plant? ## Key takeaways - Industry 4.0 is a German strategy for connected production, set out in 2013, not a standard a plant can be certified against. - The Industrial Internet of Things (IIoT) is the sensors, networks and software that carry machine data to the people who act on it. - A digital twin exchanges data with its machine automatically in both directions; a copy fed only one way is a digital shadow. - A small plant can start with a digital shadow: live machine state, part counts and the reasons machines stopped. - Old machines join with a sensor on the outside, so a plant can start without new equipment or a controller connection. For a 50-person plant, Industry 4.0 means running production on live data from your machines. The Industrial Internet of Things (IIoT) is the sensors, networks and software that carry that data, and a digital twin is a software copy of a machine that exchanges data with it automatically in both directions. A small plant can start one step short of a twin, with a live digital shadow of every machine. Each term below comes with its source, a shop-floor example and a rule for when you need it. ## What Industry 4.0 means > **Definition.** **Industry 4.0** is a strategy for connected production that Germany set out in 2013: machines, products and software exchange data so a plant can see and adjust its operations while they run, instead of after the shift ends. The name comes from Germany’s Industrie 4.0 program. Its working group handed recommendations to the German Chancellor at Hannover Messe on 8 April 2013, and the BITKOM, VDMA and ZVEI industry associations founded the Plattform Industrie 4.0 the next day.[1] The “4.0” frames the program as a fourth industrial revolution. On the floor, the change is concrete. Without connected machines, a supervisor walks the floor at 2 p.m. and learns that a Haas VF-2 has waited on material since 11:40. With them, the stop shows up as it happens, with a reason attached. Industry 4.0 isn’t a standard, and no body certifies a plant against it. The closest document is RAMI 4.0, the Reference Architecture Model Industrie 4.0, published as DIN SPEC 91345 in April 2016 and free to download.[2] It’s a three-dimensional layer model that shows at which level, and in which phase of its life, each Industry 4.0 component plays a role. > **Ask which data they mean** > > When a customer audit or a vendor asks whether your plant is “Industry 4.0”, ask which data they want to see. For example, a customer who wants proof of on-time capacity needs machine run time and part counts, not a certificate. ## How IIoT differs from IoT > **Definition.** **IIoT (Industrial Internet of Things)** is the network of sensors, machine controllers and software that collects data from industrial equipment and delivers it to the people and systems that run a plant, such as dashboards, maintenance software and production schedules. The Internet of Things (IoT) covers any connected device. IIoT is the industrial subset, and the difference is what sits at the end of the wire. A connected thermostat that drops offline costs a few degrees of comfort. A monitor on a 350-ton press that drops offline hides every stop until someone walks past the press. IIoT also touches *operational technology* (OT): programmable systems and devices that interact with the physical environment, detecting or causing a direct change by monitoring or controlling devices, processes and events.[3] A CNC control and the PLC on a packaging line are OT. The ERP server in the office is IT. | | Consumer IoT | Industrial IoT | |---|---|---| | What it connects | Thermostats, watches, speakers | Machines, lines, utilities | | Cost of a failure | An inconvenience | Lost output or a safety risk | | Data it sends | Settings and usage | State, part counts, alarms | | Who approves it | The device owner | Plant IT and operations | ### Two ways to get machine data Machine data leaves a machine by one of two paths. A sensor on the outside reads a physical signal, such as vibration, sound, current or a laser beam, and infers whether the machine is running and how many parts it made. A connection to the machine’s controller, over a protocol such as [MTConnect or OPC UA](/blog/machine-communication-protocols/), reads what the control already holds: program name, alarms, axis positions and process values. The [PLC glossary entry](/docs/get-started/glossary/#plc) explains what a controller is. Choose a sensor when you need the same data from every machine, old or new. Add a controller connection when you need alarms, programs or process values, and bring IT in early, as the [security section](#security) explains. ## What a digital twin is > **Definition.** **Digital twin** is a software representation of a physical machine, line or process that exchanges data with its physical counterpart automatically in both directions, so a change in either one shows up in the other. NIST describes digital twin technology as electronic representations of real-world entities that let you view their states and the transitions between those states.[4] The word gets stretched. A CAD file, a status dashboard and a closed-loop controller can all carry the label, and only the controller fits the definition above. A 2018 review of digital twin research in manufacturing sorted these uses into three levels with one test: which way data flows automatically between the machine and its copy.[5] ### Digital model, digital shadow and digital twin - **Digital model:** no data flows automatically in either direction. People type values in and carry decisions out, as with a CAD model or a capacity spreadsheet. - **Digital shadow:** data flows automatically from the machine to the copy, so changes on the floor appear without anyone typing them. A car’s dashboard showing live speed and mileage is the standard example,[6] and a screen showing each machine’s live status works the same way. - **Digital twin:** data also flows automatically back, so a change in the copy changes the machine. A controller that adjusts a setpoint from a model’s output closes that loop. Figure: Three rows compare a machine and its digital copy. A digital model has manual data flow both ways, a digital shadow has automatic flow from machine to copy and manual flow back, and a digital twin is automatic both ways. *The three levels differ only in which direction data flows automatically between machine and copy.* In decision support, such as predictive maintenance, the return path runs through people. A technician carries out the maintenance action, so that half of the loop isn’t fully automatic; control applications are the ones that need both directions automatic.[7] On a job-shop floor, the live view is where the value starts. ## How the three terms fit together The three terms describe layers of one system. Industry 4.0 is the goal of running a plant on live data. IIoT is the plumbing that moves the data, and a digital shadow or twin is what the data builds at the end of the path. Figure: A loop runs from the machine to a sensor or controller, a network and a platform that forms the digital shadow, then to your team, whose actions return to the machine. IIoT spans the sensing, network and platform steps. *IIoT carries data from the machine to the shadow; the return path runs through your team.* For example, a stamping press stops at 9:12 with a misfed strip. The sensor records the stop, the network carries it, and the platform shows the press as stopped. The supervisor sends a setter, and that action is the return path. Automating that last step would turn the shadow into a twin. A misfed strip has no automatic fix, so the press stays a shadow, and loses nothing by it. ## What each one is worth to a small plant The value of each level shows up in hours. Take a hypothetical shop with 10 CNC machining centers. #### Worked example: A digital shadow on 10 CNC machines - Schedule: two 8-hour shifts, 5 days a week, so each machine has 80 planned hours a week and the fleet has 800. - The shadow measures fleet [uptime](/docs/get-started/glossary/#uptime) at 45%, so the machines run 0.45 × 800 = 360 hours. - The team uses the stop reasons to cut time spent waiting for material and first-article checks, and uptime rises 5 points to 50%. At 50%, the fleet runs 0.50 × 800 = 400 hours a week. That’s 40 more running hours, half of one machine’s 80 planned hours. **Result:** 40 hours a week × 50 weeks = 2,000 more running hours a year, with no new machine A digital model earns its keep before you commit capacity. Say a customer asks for 600 parts a week at an 8-minute cycle: 600 × 8 = 4,800 minutes, or 80 hours of cutting. At the measured 50% uptime, those 80 hours need 160 planned hours, two machines’ full weeks. The spreadsheet is the digital model, and the shadow’s measured uptime is what makes its answer trustworthy. A full digital twin pays off where software can safely change the process on its own, such as a controller holding a temperature setpoint on a continuous line. In a job shop running mixed parts on mixed machines, the return path stays with people. ## Common obstacles and how to handle them ### Old machines Many plants run machines older than their network. A 1998 lathe has no Ethernet port, and its control speaks no modern protocol. A sensor on the outside gets state and counts from it anyway, because it reads the machine rather than the control. The same approach scales to a whole line: [production line monitoring without PLCs](/blog/production-line-monitoring-without-plcs/) shows how. ### Too much data, too few answers Collecting every signal is the quickest way to stall. Start with three things every machine can report: whether it’s running, how many parts it made and why it stopped. The guide to [manufacturing data collection](/blog/manufacturing-data-collection/#what-to-collect) ranks what to add after them. For example, 10 machines that report their state once a second produce 10 × 86,400 = 864,000 readings a day. The useful output is a short list of stop reasons ranked by hours lost, the [Pareto view of downtime](/docs/monitoring/downtimes/#pareto). ### Security Every connected device adds a path for data, so ask where the data goes before anything ships. A sensor that reads the machine from the outside never touches the control. A controller connection is a security concern for many plants, and IT usually reviews it first. Bring IT in at the start with three questions for any vendor: where the data goes, which port it leaves on and whether the device touches the control. ### People and skills Data changes nothing until someone acts on it, and skilled people are scarce. Deloitte and the Manufacturing Institute estimate that US manufacturing could need as many as 3.8 million more employees between 2024 and 2033, and that 1.9 million of those jobs could go unfilled if the skills and applicant gaps aren’t addressed.[8] So pick tools an operator can use at the machine without training, and put one person in charge of the stop reasons. A 15-minute Monday review of last week’s top three reasons is enough to start. ## See machine state live IoTFlows builds the digital shadow from a sensor on the outside of each machine. SenseAi mounts with a magnet, reads vibration and sound, and decides running or stopped every second on the device, with no PLC connection. The [data path from sensor to dashboard](/docs/get-started/how-iotflows-works/#on-device) shows where each decision is made. Every machine then reports its status, uptime, downtime with reasons and part counts in [machine monitoring](/platform/machine-monitoring/). Where a plant wants controller data too, the IoTFlows edge device on Enterprise reads only the controls the plant chooses to connect. [Hilco Vision](/customers/hilco-vision/) runs SenseAi and BeamTracker on its floor and increased production more than 20% by analyzing and adjusting in real time instead of waiting days for reports. ## Where a small plant should start Match the level to the question you need answered. | | Digital model | Digital shadow | Digital twin | |---|---|---|---| | Machine to copy | Manual | Automatic | Automatic | | Copy to machine | Manual | Manual | Automatic | | Use it for | Testing a decision first | Seeing what runs right now | Closed-loop control | | Needs a controller connection | No | No, a sensor can feed it | Yes, to write changes | Levels follow the Kritzinger et al. classification. A shadow can also be fed from a controller. 1. **Pick your costliest machines.** Choose five to ten machines whose stops cost the most, such as the bottleneck cell. 2. **Capture state and counts.** Put a sensor on each machine, or connect a controller where IT has approved it. 3. **Name the stops.** Give operators a short list of stop reasons and have them tag each stop at the machine. 4. **Review every week.** Rank last week’s stops by hours lost and fix the top one. 5. **Feed your model.** Put the measured uptime into your capacity spreadsheet before you quote the next job. > **Which level do you need first?** > > Start with a digital shadow when you can’t say right now which machines are running and why the others stopped. Build a digital model when you need to test a decision, such as a new job or a third shift, before you commit. You don’t need a full digital twin unless software can safely adjust the process with no person in the loop. If you’re weighing a monitoring system against an MES or a CMMS, [machine monitoring vs MES vs CMMS](/compare/machine-monitoring-vs-mes-vs-cmms/) sets out the question each one answers. ## Questions ### Is Industry 4.0 a standard? No. Industry 4.0 is the name of a German strategy for connected production, presented to the German government in April 2013. The closest document to a standard is RAMI 4.0, a reference architecture model published as DIN SPEC 91345 in 2016. No body certifies a plant as Industry 4.0 compliant, so treat the label as a direction rather than a requirement. ### Is a live machine dashboard a digital twin? By a widely used classification in manufacturing research, from Kritzinger and colleagues in 2018, no. A dashboard fed automatically by sensors is a digital shadow, because data flows on its own only from the machine to the software. It becomes a digital twin only when the software also changes the machine automatically, for example by adjusting a setpoint on the controller. ### Do I need new machines to start with IIoT? No. A sensor mounted on the outside of a machine reads vibration, sound, current or a laser beam and turns that signal into running or stopped and a part count. That works on any brand and any age of machine and never connects to the controller. Controller data can be added later on machines with a usable interface. ### What is the difference between IoT and IIoT? IoT covers any connected device, including thermostats, watches and speakers. IIoT is the industrial subset: sensors, controllers and networks on machines, lines and utilities, where a failure costs output or creates a safety risk. IIoT also sits next to operational technology, so plant IT and operations both have a say in how a device connects. ## Sources 1. [Industrie 4.0](https://en.acatech.de/project/industrie-4-0/), acatech, National Academy of Science and Engineering, accessed Oct 16, 2026 2. [DIN SPEC 91345:2016-04 Reference Architecture Model Industrie 4.0 (RAMI4.0)](https://www.dinmedia.de/en/technical-rule/din-spec-91345/250940128), DIN Media, accessed Oct 16, 2026 3. [Operational technology, glossary entry (definition from NIST SP 800-82 Rev. 3)](https://csrc.nist.gov/glossary/term/operational_technology), NIST Computer Security Resource Center, accessed Oct 16, 2026 4. [NIST IR 8356: Security and Trust Considerations for Digital Twin Technology](https://csrc.nist.gov/pubs/ir/8356/final), National Institute of Standards and Technology, accessed Oct 16, 2026 5. [Digital Twin in manufacturing: A categorical literature review and classification (Kritzinger et al., IFAC-PapersOnLine 51, 2018)](https://doi.org/10.1016/j.ifacol.2018.08.474), IFAC-PapersOnLine, Elsevier, accessed Oct 16, 2026 6. [Towards a Unifying Reference Model for Digital Twins of Cyber-Physical Systems (Pfeiffer et al., 2025)](https://arxiv.org/html/2507.04871v1), arXiv, accessed Oct 16, 2026 7. [A Comprehensive Review of Digital Twin, Part 1: Modeling and Twinning Enabling Technologies (Thelen et al., 2022)](https://arxiv.org/html/2208.14197), arXiv, accessed Oct 16, 2026 8. [Manufacturers Need as Many as 3.8 Million New Employees by 2033](https://themanufacturinginstitute.org/manufacturers-need-as-many-as-3-8-million-new-employees-by-2033/), The Manufacturing Institute, accessed Oct 16, 2026 --- # How to calculate OEE from one shift’s numbers Source: https://www.iotflows.com/blog/how-to-calculate-oee/ OEE is availability × performance × quality. Work one shift through by hand, check the result in lost minutes and avoid the mistakes that skew the number. > Question: How do you calculate OEE? ## Key takeaways - OEE multiplies availability, performance and quality, so three factors at 90% give 72.9%, not 90%. - Remove breaks and other time nobody planned to run before you calculate availability; changeovers and breakdowns stay in. - Performance divides the ideal time for the parts made by run time, never by planned production time. - Check any result with the short form: good count × ideal cycle time ÷ planned production time. - Convert each factor into lost minutes to see which loss costs the machine the most time. You calculate OEE by multiplying three factors: availability, performance and quality. Remove breaks and other time nobody scheduled to run from one shift to get planned production time, then divide run time by it, compare the parts made with what the ideal cycle time allows in that run time, and divide good parts by all parts. The product is the share of planned time that made good parts at full speed. The example below follows one shift on a CNC lathe from the raw numbers to the result, then checks the answer a second way. ## The OEE formula > **Definition.** **OEE (overall equipment effectiveness)** measures how much of a machine’s planned production time made good parts at the ideal speed: the product of availability, performance and quality, each a ratio between 0% and 100%. Each factor captures one kind of loss, and the [OEE glossary entry](/docs/get-started/glossary/#oee) lists how IoTFlows names each one. If you want the background first, [What is OEE?](/blog/what-is-oee/) covers what the number is for. **OEE** = Availability × Performance × Quality | Factor | Formula | Loss it captures | |---|---|---| | Availability | Run time ÷ planned production time | Breakdowns, changeovers, waiting | | Performance | (Total count × ideal cycle time) ÷ run time | Slow cycles and short stops | | Quality | Good count ÷ total count | Scrap and rework | Formulas from the standard OEE calculation. Your plant decides what counts as planned production time. The formulas follow the standard OEE calculation.[1] Multiply the factors; never add or average them. For example, a machine at 90% on all three factors has an OEE of 0.9 × 0.9 × 0.9 = 72.9%, not 90%. ## Find planned production time first > **Definition.** **Planned production time** is the part of a shift when a machine is scheduled to make parts: the shift length minus breaks, meetings and any period with no work scheduled. Every factor starts from this number, so settle it before you calculate anything. Breaks come out of the shift because nobody intended to run the machine during them.[1] A changeover stays in, because the machine was scheduled to produce. The *six big losses*, the standard breakdown of OEE losses, list setup and adjustments as an availability loss.[2] Take a stop out of planned production time only when nobody intended to run the machine during it. Keep it in when the machine was scheduled to run and didn’t, whatever the reason. Planned and excluded are different things. A planned changeover is on the schedule, but it still costs production time, so it stays in. The glossary entry for [planned downtime](/docs/get-started/glossary/#planned-downtime) shows how to label those stops so you can report them apart from breakdowns. Plants don’t all draw this line in the same place. The ISO 22400 standard itself gives two definitions of OEE, and a 2020 review found they seem to diverge from each other and from Seiichi Nakajima’s original formulation.[3] Write your rules down once, then apply them to every machine and every shift, so this month’s number compares with last month’s. ## Calculate each factor The example machine is a CNC lathe turning a steel shaft on an 8-hour day shift. The numbers are hypothetical and round, so you can recompute each step by hand. | Input | Value | Where it comes from | |---|---|---| | Shift length | 480 min | The shift calendar | | Breaks | 30 min | One lunch break | | Unplanned stops | 45 min | Broken insert 25 min, bar stock 20 min | | Ideal cycle time | 1.0 min per part | The operation’s set cycle time | | Total count | 360 parts | Parts off the machine | | Good count | 342 parts | Parts that passed inspection first time | ### Availability *Run time* is planned production time minus every stop inside it, changeovers included. Here, 480 − 30 = 450 minutes of planned production time, and 450 − 45 = 405 minutes of run time. **Availability** = (Run time) ÷ (Planned production time) Availability is 405 ÷ 450 = 90.0%. The lathe was scheduled for 450 minutes and turned for 405 of them. ### Performance > **Definition.** **Ideal cycle time** is the time one cycle of an operation takes when the machine runs at the best speed the process sustains in good conditions, not a one-off record and not a quoted estimate. Performance compares the ideal time for the parts you made with the time the machine actually ran. **Performance** = (Total count × ideal cycle time) ÷ (Run time) The lathe made 360 parts at an ideal of 1.0 minute each, so they were worth 360 minutes at full speed. It ran for 405 minutes, so performance is 360 ÷ 405 = 88.9%. The missing 45 minutes went to cycles slower than ideal and to short stops nobody recorded as downtime. If one cycle makes several parts, divide the cycle time by the parts per cycle. For example, a 4-cavity mold with a 20-second cycle has an ideal of 5 seconds per part. Performance should never exceed 100%. A reading above it means the ideal cycle time is set too slow.[1] To set the number, time 10 to 20 consecutive cycles on a good day and use the best sustainable cycle, as the guide to [setting the ideal cycle time](/docs/production/cycle-times-and-filters/#ideal) describes. ### Quality **Quality** = (Good count) ÷ (Total count) Quality is 342 ÷ 360 = 95.0%. The *good count* is the parts that passed the first time. A part that needs rework is not good, even if it ships after the rework.[1] The glossary entry for [quality](/docs/get-started/glossary/#quality) shows how good and bad counts appear on a shift report. ### Multiply the factors #### Worked example: One 8-hour shift on a CNC lathe - Shift: 480 minutes, with a 30-minute lunch break, so planned production time is 450 minutes. - Unplanned stops: 45 minutes, so run time is 405 minutes. - Ideal cycle time: 1.0 minute. Total count: 360 parts, 342 good. Availability is 405 ÷ 450 = 90.0%. Performance is (360 × 1.0) ÷ 405 = 88.9%. Quality is 342 ÷ 360 = 95.0%. **Result:** OEE = 0.900 × 0.889 × 0.950 = 76.0% Figure: Bars fall from a 480-minute shift to 450 planned minutes, 405 run minutes (availability 90%), 360 minutes of ideal output (performance 88.9%) and 342 good minutes (quality 95%). OEE is 342 ÷ 450 = 76.0%. *One shift on a CNC lathe, loss by loss: each factor removes its share of planned time. Sample data.* ## Check the answer in lost minutes OEE has a short form that skips the three factors: good count × ideal cycle time ÷ planned production time.[1] On the lathe, 342 × 1.0 ÷ 450 = 76.0%, the same answer. If the two forms disagree, one of the factors has an error. **OEE, short form** = (Good count × ideal cycle time) ÷ (Planned production time) The short form also says what OEE means in time. The lathe spent 342 of its 450 planned minutes making good parts at full speed. The other 108 minutes are losses, and each one belongs to exactly one factor. | Loss | Factor | Minutes lost | Calculation | |---|---|---|---| | Unplanned stops | Availability | 45 | 450 − 405 | | Slow cycles and short stops | Performance | 45 | 405 − 360 × 1.0 | | Scrap | Quality | 18 | 18 rejects × 1.0 | | All losses | OEE | 108 | 450 − 342 | Availability reads 90.0% and performance 88.9%, yet both lost 45 minutes. The percentages sit on different bases: availability on 450 minutes, performance on 405. Compare losses in minutes when you decide what to fix. ## Mistakes that change the result The most common error divides performance by planned production time instead of run time. On the lathe, that gives 360 ÷ 450 = 80.0% and an OEE of 0.900 × 0.800 × 0.950 = 68.4%. The 45 stopped minutes already lowered availability, so dividing by 450 counts them a second time. Figure: Two bars compare performance on the same shift. Divided by 405 run minutes, 360 minutes of ideal output gives 88.9% and OEE 76.0%. Divided by 450 planned minutes, the 45 stopped minutes count twice: 80.0% and OEE 68.4%. *Divide performance by run time, or the stopped minutes count against two factors. Sample data.* Each row below changes one thing on the same shift and leaves the rest as it was. | Mistake | Result on the lathe | Fix | |---|---|---| | Performance divided by planned time | Performance 80.0%, OEE 68.4% | Divide by run time | | Lunch break counted as downtime | Availability 84.4%, OEE 71.3% | Remove breaks first | | 10 reworked parts counted as good | Quality 97.8%, OEE 78.2% | Count first-pass good parts | | Factors averaged, not multiplied | 91.3% instead of 76.0% | Multiply the three factors | | Ideal cycle time set at 1.2 min | Performance 106.7% | Re-time the best sustainable cycle | Every row uses the example shift: 450 planned minutes, 405 run minutes, 360 parts, 342 good, 1.0-minute ideal cycle. > **Let the short form catch it** > > The short form never uses run time, so it can’t inherit a wrong performance denominator. On the lathe it gives 76.0% while the wrong denominator gives 68.4%. When the two disagree, check what performance was divided by. ## Which factor should you fix first? Start with the factor that loses the most minutes, not the one with the lowest percentage. - **Work on availability first** when unplanned stops lead. Give every stop a reason and rank the reasons by total minutes. - **Work on performance first** when the machine runs but output lags. Look for short stops nobody records and cycles slower than the ideal, and confirm the ideal cycle time is current. - **Work on quality first** when scrap minutes lead, or when each reject wastes material worth more than the machine time it took. You don’t need a combined OEE number to act on any of these. The factor with the most lost minutes tells you where to look. On the lathe, stops and slow cycles tie at 45 minutes each, so check which one is easier to cut this week. Compare a machine with its own history before you compare it with a benchmark. Vorne notes that 85% is often called world class, and advises against comparing dissimilar processes with external benchmarks.[4] Set the first goal a few points above the machine’s recent baseline, as the guide to [choosing an OEE goal](/docs/monitoring/oee-goals/#choosing) recommends. ## Track the factors automatically A hand calculation covers one shift. Over a month, the inputs drift: short stops go unrecorded, counts get rounded and the ideal cycle time stays at whatever someone typed a year ago. A SenseAi sensor on each machine records when it runs and stops, so availability arrives with no operator input. It counts parts against the ideal cycle time set on each operation, which gives performance. Quality comes from the good parts and the scrap your team logs with a reason. IoTFlows reports [OEE factor by factor](/solutions/oee-tracking/), so each lost minute shows up under the factor that lost it. The [metrics reference](/docs/monitoring/metrics-reference/#performance) gives the definition behind each number. Measured cycle times also test the numbers you plan with. Jesel, a valvetrain manufacturer, compares measured cycle times against the times in its bills of material, as its [customer story](/customers/jesel/) describes. ## Calculate OEE for your own shift 1. **Find planned production time.** Subtract breaks, meetings and periods with no work scheduled from the shift length. 2. **Measure run time.** Subtract every stop inside planned production time, changeovers included. 3. **Look up the ideal cycle time.** Use the best sustainable cycle for the operation, divided by the parts each cycle makes. 4. **Count total and good parts.** Count every part off the machine, then the parts that passed inspection the first time. 5. **Multiply the three factors.** Calculate availability, performance and quality, then multiply them. 6. **Check with the short form.** Divide good count × ideal cycle time by planned production time, then list the lost minutes by factor. ## Questions ### What is a good OEE score? Vorne notes that 85% is often thought of as world class and traces the world-class figures to Seiichi Nakajima, who set them as minimums for plants to strive for. Vorne also advises against comparing dissimilar processes with external benchmarks. Set a target a few points above the machine’s own recent baseline, and raise it when the machine improves. ### Can OEE performance be over 100%? Not when the ideal cycle time is right. Performance above 100% means the machine made parts faster than its ideal cycle time allows, so the ideal cycle time is set too slow. Time 10 to 20 consecutive cycles on a good day, enter the best sustainable cycle and recalculate. ### Do changeovers count against OEE? Yes. A changeover is planned, but the machine was scheduled to make parts during it, so the time stays in planned production time and lowers availability. The six big losses list setup and adjustments as an availability loss. Only breaks and periods with no work scheduled come out before you calculate. ### Should reworked parts count as good parts? No. Quality counts only the parts that pass the first time. A part that needs rework is a quality loss even if it ships later, because the machine spent its cycle on a part that was not right. Counting reworked parts as good raises quality and hides the loss. ## Sources 1. [OEE Calculation: Definitions, Formulas, and Examples](https://www.oee.com/calculating-oee/), Vorne Industries, accessed Oct 16, 2026 2. [Six Big Losses in Manufacturing](https://www.oee.com/oee-six-big-losses/), Vorne Industries, accessed Oct 16, 2026 3. [Overall Equipment Effectiveness: consistency of ISO standard with literature (Schiraldi and Varisco, Computers & Industrial Engineering 145, 2020)](https://art.torvergata.it/handle/2108/280082), University of Rome Tor Vergata institutional repository, accessed Oct 16, 2026 4. [World-Class OEE: Set Targets To Drive Improvement](https://www.oee.com/world-class-oee/), Vorne Industries, accessed Oct 16, 2026 --- # How SCADA differs from IIoT and cloud monitoring Source: https://www.iotflows.com/blog/scada-vs-newer-manufacturing-technologies/ SCADA supervises and controls a process from PLC data. IIoT collects machine data for analysis. Learn what each does, where they meet and when to run both. > Question: What is the difference between SCADA and IIoT? ## Key takeaways - SCADA supervises and controls a process: it reads the PLCs, shows operators the live state and writes setpoints back. - IIoT monitoring moves machine data to software that analyzes it over shifts, weeks and sites, often in the cloud. - ISA places SCADA at Level 3 of ISA-95, beside MES and above the PLCs and DCS at Level 2. - IIoT does not replace SCADA: a plant can keep SCADA for control and add monitoring for the machines it never reached. - A run bit in a SCADA historian gives you uptime, but it records no reason for any stop. The difference between SCADA and IIoT is the job each one does. SCADA supervises and controls a process: it reads the PLCs on a line, shows operators the live state and sends setpoints and commands back. IIoT collects machine and process data for analysis, often in the cloud, and answers questions about shifts, weeks and whole fleets. A plant that runs SCADA can keep it and add IIoT beside it. This guide is for plant and controls engineers deciding whether to extend SCADA, add IIoT monitoring or run both. It works one press shift through by hand to show what each system can tell you. ## What is SCADA? > **Definition.** **SCADA (supervisory control and data acquisition)** is a system of software, controllers and networks that gathers data from a process, shows it to operators in one place and sends commands and setpoints back to the equipment that runs the process. NIST's definition stresses distance: SCADA was designed to gather data and apply controls over long distances, in uses such as power transmission and pipelines.[1] Inside a factory the same idea runs over a plant network instead of phone lines, microwave or satellite links. A SCADA system has four parts: - **Controllers.** A *PLC* (programmable logic controller) is the computer that runs a machine; the [PLC glossary entry](/docs/get-started/glossary/#plc) says more. A *remote terminal unit* (RTU) does the same job at a remote site, such as a pump station. - **A network** that carries tag values between the controllers and the SCADA servers. A *tag* is one named value, such as a tank level or a motor's run state. - **HMI screens.** A *human-machine interface* (HMI) is the screen where operators watch the process and change setpoints. - **A historian**, the database that stores every tag value with its timestamp. For example, on the water-treatment skid of a food plant, the SCADA screen shows tank level, pump state and chlorine dose. An operator in the control room can stop a pump or raise the dose without walking to the skid. ISA's description of ISA-95 places SCADA at Level 3, beside [manufacturing execution systems (MES)](/blog/manufacturing-excellence-with-mes-and-iot/), above the PLCs and distributed control systems (DCS) at Level 2.[2] The figure shows the five levels and the path IIoT monitoring takes beside them. Figure: Five ISA-95 levels stacked from Level 0 machines to Level 4 ERP, with MES and SCADA at Level 3. A solid line from Level 1 sensors and a dashed line from Level 2 controllers feed an IIoT monitoring box beside the stack. *SCADA sits at Level 3; IIoT monitoring takes data from Levels 1 and 2 to analytics beside the stack.* ## What is IIoT? > **Definition.** **IIoT (industrial internet of things)** means connecting machines, sensors and controllers to software outside the control system, so their data can be stored, combined and analyzed across machines, shifts and sites, often in the cloud. The data gets in two ways. Sensors added to the outside of a machine read what it physically does, such as vibration, sound or units breaking a laser beam. Connections to a machine's controller read what the control reports, such as the program name, alarms and the part count. Both ways rely on protocols built for this traffic. *MQTT* is a lightweight publish-and-subscribe messaging protocol and an OASIS standard for the internet of things.[4] OPC UA runs on anything from an embedded microcontroller to cloud infrastructure.[5] The [MQTT glossary entry](/docs/get-started/glossary/#mqtt) covers how live data travels. For the controller side, [machine communication protocols](/blog/machine-communication-protocols/) explains MTConnect, OPC UA and Modbus and when you need each. For where IIoT sits beside Industry 4.0 and digital twins, read [what Industry 4.0, IIoT and digital twins mean](/blog/industry-4-0-iot-and-digital-twin/). IIoT monitoring is not a control system: it reads the machine and leaves control with the PLC. Sensors on the outside also let it measure machines that SCADA never connected. ## SCADA and IIoT side by side The two overlap at the edges: a SCADA historian stores weeks of data, and an IIoT dashboard shows live status. The rows below show what each one is built around. | | SCADA | IIoT monitoring | |---|---|---| | Main job | Supervise and control a process | Measure and analyze machines | | Data direction | Reads and writes | Reads; control stays in the PLC | | Where it runs | Plant control network | Cloud, often with an edge device | | Data comes from | PLCs and RTUs | Sensors, controllers and the ERP | | Time scale | Seconds: the live process | Shifts, weeks and months | | Main users | Operators at an HMI | Managers, engineers, maintenance | | Adding a machine | Tags, PLC logic and screens | A sensor or a connector | | Typical question | Is the tank at setpoint? | Why did Press 4 stop at 10:14? | An IIoT system can also write to a controller when it is built to; the data direction row shows the monitoring case. ## Reading data vs controlling a process The deepest difference is which way the data flows. SCADA reads values from the PLC and writes setpoints and commands back, so it changes how the process runs. Sensor-based monitoring reads from the outside of the machine and has no path to the controller at all. Figure: Two panels. In SCADA, arrows run both ways between the HMI, the PLC and the machine: values read up, setpoints written down. In sensor-based monitoring, arrows run one way, from the sensor on the machine to the cloud to the dashboard. *SCADA reads from the PLC and writes back; sensor-based monitoring only reads, from outside the machine.* That direction decides who signs off on the project. A connection to a controller is a security concern for many plants, and IT usually reviews it first. NIST's guide to operational technology security, SP 800-82 Rev. 3, covers programmable systems that interact with the physical environment, and it names SCADA systems, DCS and PLCs among them.[3] Controller connections sit between the two: they read only, or read and write, depending on how they are set up. OPC UA can sign and encrypt each message, and it identifies every client and server with an X.509 certificate.[5] Even a read-only connection opens a new path into the control network, so plan it with IT. [Sensor-based vs PLC machine monitoring](/compare/sensor-based-vs-plc-machine-monitoring/) compares what each path can see, row by row. ## Is IIoT replacing SCADA? No. The two do different jobs, and at least one newer standard is written to serve both. The Sparkplug specification, which defines topics, payloads and session state for MQTT, targets the IIoT market and is written to meet the requirements of real-time SCADA and control HMI solutions.[6] The common claim that SCADA "doesn't scale" points at something narrower: the work of adding one machine. To bring a machine into SCADA you need a controller that can be read, a tag map, PLC logic and screens, which is a controls engineering job per machine. A [1990s lathe with no network port](/blog/monitor-old-machines-without-a-plc/) gives SCADA nothing to read. IIoT monitoring changes that unit of work. A sensor reads the same lathe from the outside, so the number of machines you can measure no longer depends on the number of controllers you can reach. The useful framing is coverage, not replacement: SCADA covers the process you control, and IIoT covers the machines and questions SCADA was never set up for. ## Uptime from a SCADA historian If a machine's PLC already sends a *run bit* to SCADA, a tag that reads 1 while the machine runs, the historian holds enough to calculate [uptime](/docs/get-started/glossary/#uptime). Count the samples where the bit was 1, then divide by the samples in planned production time. That count works when the historian stores the bit at a fixed rate. If your historian stores a value only when it changes, add up the time from each change to 1 until the next change to 0 instead. #### Worked example: Hypothetical: one shift on a 350-ton press - Shift: 480 minutes with a 30-minute break, so planned production time is 450 minutes. - The historian logs the run bit once a second: 450 × 60 = 27,000 samples. - The bit reads 1 in 20,250 samples, which is 337.5 minutes of running. - The other 6,750 samples are 112.5 minutes stopped, across four stops. Availability is 20,250 ÷ 27,000. **Result:** Availability = 75.0%, with 112.5 minutes of stops and no reason for any of them Remove the break before you count. The run bit reads 0 during the break too, and counting it as a stop would put availability at 337.5 ÷ 480 = 70.3%. That 75% is the first OEE factor, and [how to calculate OEE](/blog/how-to-calculate-oee/) works through the other two. What the historian can't tell you is why the press stopped: the run bit drops to 0 the same way for a coil change, a jam and a missing operator. Figure: Two bars for the same 450-minute shift. The run bit shows four unexplained stops totaling 112.5 minutes. With reason codes they read material wait 40 min, changeover 35 min, jam 25 min and coil change 12.5 min. Availability is 75%. *The same four stops, with and without a reason on each. Sample data.* [Reasons](/blog/downtime-reason-codes/) come from people at the machine. A monitoring system asks the operator to tag each stop, so the 112.5 minutes become 40 minutes of material wait, 35 of changeover, 25 of a jam and 12.5 of a coil change. Now the morning meeting knows to start with material flow. ## Monitor machines beside your SCADA IoTFlows adds [machine monitoring](/blog/what-is-machine-monitoring/) without touching the control system. A SenseAi sensor mounts on each machine with a magnet and reads vibration and sound from the outside, with no connection to the PLC. It decides running or stopped every second on the device, and part counts and cycle times come from the machine's own cycle. Devices connect out over HTTPS on port 443, or stay off the plant network on the [4G/LTE router](/docs/hardware/lte-router/). Operators [put a reason on each stop](/docs/monitoring/classify-downtime/) in a tap, which fills in the column the historian was missing. Where you want alarms or process values too, the IoTFlows edge device on Enterprise reads only the controls you choose to connect, over OPC UA, Modbus TCP, MQTT and other protocols. See [machine monitoring](/platform/machine-monitoring/) for the views. ## Choose SCADA, IIoT or both Extend your SCADA when: - you need to change the process from a central screen: setpoints, recipes, starts and stops; - operators must act on process alarms within seconds; - the machines in question already have PLCs on the SCADA network. Add IIoT monitoring when: - the question is about utilization, downtime reasons or OEE across many machines; - some machines have no readable controller, or a controller connection is waiting on IT review; - managers and maintenance need the numbers on phones and in weekly reports, off the control network. Run both when SCADA controls one process, such as compounding or utilities, and standalone machines make parts elsewhere on the floor. [Production line monitoring without PLCs](/blog/production-line-monitoring-without-plcs/) shows the IIoT half for a whole line. > **Already running SCADA?** > > Keep it for control. Start IIoT monitoring on the machines SCADA doesn't reach, then compare a week of stops against the historian on one machine both systems can see. You don't need a SCADA system to measure machine utilization or downtime. You don't need to remove a working one to add monitoring either. ## Questions ### Is an HMI the same as SCADA? No. An HMI is the screen an operator uses to watch and adjust one machine or one process. SCADA is the wider system behind many HMIs: it gathers data from controllers across a plant or a site, stores it, raises alarms and sends commands. A standalone machine can have an HMI on its control panel with no SCADA system at all. ### Can IIoT monitoring control a machine? That depends on how it connects. A sensor mounted on the outside of a machine only reads, so it cannot change a setting, a program or a recipe. A connection to the controller can carry commands as well as readings when it is set up to, which is why IT usually reviews a controller connection before it goes live. ### Do I need SCADA to measure OEE? No. Availability and performance need a reliable running or stopped signal and a part count, and either a sensor on the machine or a controller connection can supply both. Quality needs the scrap count, which operators log. SCADA helps only where it already holds those signals for the machines you want to measure. ### Can SCADA data be sent to the cloud? Yes, when the plant chooses to. A historian or a gateway can publish selected tags to cloud software over a protocol such as MQTT or OPC UA. Plan the path with IT before you build it, since the data crosses from the control network to the internet, and send only the tags the analysis needs. ## Sources 1. [Supervisory Control and Data Acquisition (SCADA), glossary entry from NIST SP 800-82r3](https://csrc.nist.gov/glossary/term/supervisory_control_and_data_acquisition), National Institute of Standards and Technology, accessed Oct 16, 2026 2. [ISA-95 Standard: Enterprise-Control System Integration](https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard), International Society of Automation, accessed Oct 16, 2026 3. [SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security](https://csrc.nist.gov/pubs/sp/800/82/r3/final), National Institute of Standards and Technology, accessed Oct 16, 2026 4. [MQTT: The Standard for IoT Messaging](https://mqtt.org/), mqtt.org, accessed Oct 16, 2026 5. [OPC Unified Architecture](https://opcfoundation.org/about/opc-technologies/opc-ua/), OPC Foundation, accessed Oct 16, 2026 6. [Sparkplug Specification](https://sparkplug.eclipse.org/specification/), Eclipse Foundation, accessed Oct 16, 2026 --- # MTConnect, OPC UA and Modbus compared Source: https://www.iotflows.com/blog/machine-communication-protocols/ MTConnect reads machine tools, OPC UA models and secures plant data, and Modbus moves bare registers. See how each one works and when your machines need it. > Question: What are MTConnect, OPC UA and Modbus, and when do you need each? ## Key takeaways - MTConnect gives machine tools a shared, read-only vocabulary that an agent serves over HTTP, so a client cannot change the machine. - OPC UA models, reads and writes industrial data, with certificates, signing and encryption built into the protocol. - Modbus moves bare 16-bit registers, so every device needs its maker’s register map before the numbers mean anything. - Plain Modbus TCP carries no authentication; the Modbus/TCP Security variant wraps the same messages in TLS on port 802. - Run state, uptime and part counts need no protocol at all, because a sensor can read them from outside the machine. MTConnect, OPC UA and Modbus are three standards for reading data from a machine’s control, and each one does a different job. MTConnect gives machine tools a shared, read-only vocabulary; OPC UA models, reads, writes and secures data from almost any industrial device; Modbus moves bare 16-bit registers whose meaning lives in the device’s manual. You need one only when the data you want lives inside the control. This guide is for engineers and plant managers deciding how to get data off a mixed fleet. It explains how each protocol works, where machine connections stall, and how to choose. ## What a machine protocol defines A protocol for machine data answers three questions: how bytes move between two devices, what each value means, and who may read or change it. The three standards in this guide answer them differently, which is why one can’t stand in for another. | Layer | Question it answers | Example | |---|---|---| | Transport | How do the bytes move? | TCP port 502, HTTP, RS-485 serial | | Data model | What does a value mean? | “Spindle speed in rpm” or register 201 | | Access | Who can read or write? | Read-only agent, or permissions per user | For example, a spindle turning at 1,200 rpm reaches your software as the number 1200 in all three. Modbus sends only the number. MTConnect and OPC UA send the number with its name and unit, so the software knows what it is looking at. Figure: The same 1200 rpm spindle speed read three ways: Modbus returns register 201 as hex 04 B0 with no name or unit, MTConnect returns RotaryVelocity in REVOLUTION/MINUTE, and OPC UA returns a typed Spindle.Speed node in rpm. *Modbus sends a bare number; MTConnect and OPC UA send the number with its name and unit. Sample data.* Each protocol talks to the machine’s controller: the [PLC](/docs/get-started/glossary/#plc) or CNC control that runs it. That makes it the right tool for data only the control holds, and more than you need for data a sensor can see from outside. ## How MTConnect works > **Definition.** **MTConnect** is an open, royalty-free standard from the MTConnect Institute that defines a shared vocabulary for machine tool and other manufacturing equipment data, such as execution state, spindle speed and part count, and serves that data read-only over HTTP from software called an agent. The specification describes MTConnect as a data and information exchange standard built on a dictionary of terms for manufacturing operations, open and royalty-free for anyone to implement.[1] The dictionary is the point. A measured spindle speed is a `RotaryVelocity` sample with the subtype `ACTUAL`, in `REVOLUTION/MINUTE`.[2] Software written against the standard reads that item the same way on any builder’s control that implements it. ### Adapter, agent and client Three pieces of software sit between the machine and your dashboard: - An *adapter* is optional hardware or software that turns what the equipment provides into a form the agent can receive.[1] A control that doesn’t speak MTConnect natively needs one. - An *agent* collects data from one or more machines, organizes it, and answers requests from client software.[1] - A *client* is your monitoring or analytics software, which asks the agent for data. An agent must answer four requests: `probe` for the machine’s structure, `current` for the latest value of every data item, `sample` for buffered history, and `asset` for the assets the agent tracks.[1] The Institute’s reference agent also takes input over [MQTT](/docs/get-started/glossary/#mqtt) and can publish to an MQTT broker.[3] ### Read-only by design The MTConnect REST API is read-only and produces no side effects on the agent or the equipment.[1] A client can’t start a program, change an offset or clear an alarm through MTConnect. If you need to write back to a machine tool, MTConnect isn’t the path. ### Security in MTConnect MTConnect defines what the data means and how to request it. Protecting the connection falls to the transport and the network. The reference agent supports TLS, so it can serve its data over HTTPS with certificates.[3] The OPC UA companion specification for MTConnect, released in September 2019, expresses the MTConnect model in OPC UA and brings OPC UA’s end-to-end security to it.[4] The two standards cooperate rather than compete. ## How OPC UA works > **Definition.** **OPC UA (Open Platform Communications Unified Architecture)** is a platform-independent framework from the OPC Foundation, released in 2008, for modeling industrial data and exchanging it securely between clients and servers, with reads and writes governed by access permissions. OPC UA runs on anything from a microcontroller to a cloud server, PLCs included.[5] A device or gateway runs an OPC UA server. Your software connects as a client, browses what the server offers, and reads, writes or subscribes to values based on the permissions it holds.[5] ### Information models Where Modbus has registers, OPC UA has a typed model that a client can browse. For example, a press might expose a node for its main motor, a variable for motor current with a data type and an engineering unit, and a method that resets a counter. The modeling framework is extensible, so industry groups publish companion specifications that fix the model for one kind of machine.[5] The MTConnect companion specification is one of them.[4] ### Transports OPC UA is often described as an HTTP or MQTT protocol, but that isn’t accurate. Its main client and server transport is OPC UA TCP, which runs directly on TCP/IP and whose endpoints use the `opc.tcp` URL scheme.[6] IANA registers port 4840 for it, and port 4843 for OPC UA over TLS.[8] HTTPS, WebSockets and SOAP over HTTP are alternative mappings in the same specification.[6] The separate publish-subscribe model, PubSub, defines mappings for UDP, raw Ethernet and MQTT.[7] PubSub is built for many-to-many traffic.[5] Choose it when one device feeds many consumers, and choose client and server when your software asks for data on demand. ### Security in OPC UA Security is part of the OPC UA protocol. Each client and server is identified by an X.509 certificate, messages can be signed and encrypted, users authenticate, and activity is logged as an audit trail.[5] Because OPC UA can write as well as read, the permissions a client receives are a decision for the plant. Connecting software to a controller is a security concern for many plants, and IT usually reviews it first. ## How Modbus works > **Definition.** **Modbus** is a request-and-reply messaging protocol, published by the Modbus Organization, in which a client reads or writes numbered bits and 16-bit registers on a server device over Ethernet or a serial line. The specification calls it an application layer messaging protocol for client and server communication across different buses and networks, run over TCP/IP on Ethernet or over serial links such as EIA/TIA-485.[9] Older documents call the client a master and the server a slave. ### Four tables of numbers Modbus organizes a device’s data in four primary tables.[9] | Table | Size of each item | Access | |---|---|---| | Discrete inputs | 1 bit | Read-only | | Coils | 1 bit | Read and write | | Input registers | 16-bit word | Read-only | | Holding registers | 16-bit word | Read and write | Each table addresses up to 65,536 items, and function code 03 reads 1 to 125 holding registers in one request.[9] Nothing in Modbus says what register 108 holds. The device maker’s register map does, so every new device model means a new map to load and check. > **Register numbers start at 1, addresses at 0** > > The specification addresses registers from zero, so registers numbered 1 to 16 are sent as addresses 0 to 15.[9] When a value reads as its neighbor’s, check for this offset before you suspect the device. ### Read a temperature and a counter #### Worked example: Reading a barrel temperature and a cycle counter over Modbus TCP A hypothetical injection molding machine publishes this register map in its manual: - Register 108: barrel zone 1 temperature, in tenths of a degree Celsius. - Register 109: active alarm code, 0 for none. - Registers 110 and 111: cycle counter as one 32-bit value, high word first. Your client sends function 03, starting address 107 (hex 006B), quantity 4. The device answers `03 08 08 FC 00 00 00 01 86 A0`: the function code, a byte count of 8, then four registers of two bytes each, high byte first. - Register 108 is hex 08FC = 2,300, so the barrel reads 230.0 °C. - Register 109 is 0, so no alarm is active. - Registers 110 and 111 are 1 and hex 86A0 = 34,464, so the counter is 1 × 65,536 + 34,464. **Result:** Cycle counter = 100,000 cycles at 230.0 °C, with no alarm The specification defines only 16-bit registers, so how two registers combine into a 32-bit value is the device maker’s choice. Read the same counter with the words swapped and you get 34,464 × 65,536 + 1 = 2,258,632,705 cycles. The register map, not the protocol, tells you which word comes first. ### Security and current use Plain Modbus TCP, on port 502, has no authentication or encryption.[10] The Modbus/TCP Security protocol carries the same messages inside TLS on port 802, adding encryption, integrity checks, certificate-based authentication and roles for authorization.[10] Where a device supports only plain Modbus, protect it with the network: keep it on a segment that only the systems that need it can reach. Modbus is old, but it isn’t retired. HMS Networks’ 2026 analysis of newly installed nodes in factory automation puts Modbus TCP at 5% and Modbus RTU at 3%.[11] The Modbus Organization describes Modbus/TCP as widely deployed in industrial control systems.[10] Meters, drives, temperature controllers and older PLCs are where you meet it most. ## Compare MTConnect, OPC UA and Modbus The biggest practical difference is direction. MTConnect only reads, while OPC UA and Modbus clients can also write to the device. Figure: Three data paths. MTConnect flows one way from machine control to adapter to agent to client. OPC UA and Modbus clients send reads and writes to a server in the device and get values back, over port 4840 and port 502. *MTConnect only reads; OPC UA and Modbus clients can also write, so access needs a decision.* | | MTConnect | OPC UA | Modbus | |---|---|---|---| | Maintained by | MTConnect Institute | OPC Foundation | Modbus Organization | | Built for | Machine tools and other shop equipment | Any industrial device | Any device with registers | | What a value carries | Name, unit and timestamp | Name, data type and unit | A bare bit or 16-bit number | | Read or write | Read-only | Read and write | Read and write | | Security in the protocol | None; relies on the transport | Certificates, signing, encryption | None; TLS variant on port 802 | | Main transport | HTTP from the agent | OPC UA TCP, port 4840 | TCP port 502, or serial | Each row comes from the standard’s own specification. Your device’s documentation says which of them it supports. ## Why machine connections stall A protocol on the spec sheet doesn’t mean the data reaches your dashboard. Connection projects stall at five points, and each one has a fix you can plan for. - **A mixed fleet.** A 2005 lathe, a 2019 machining center and a hydraulic press can speak three different protocols, or none. Each protocol is a separate connector to build, test and keep running, so list every machine’s protocol before you budget the project. - **No data path.** A control with no network port, or with no MTConnect support, needs an adapter before an agent can read it. Budget the adapter per machine, not per plant. - **No meaning.** Modbus values arrive without names. For example, 40 meters and drives across six models means six register maps to load and verify against a hand reading. - **The security review.** A controller connection puts a new device on the machine and on the plant network. That is a security concern for many plants, so IT usually reviews it first. Bring IT in before the project starts, not after the hardware arrives. - **More data than you need.** Reading 30 values a second from each of 20 machines is 600 values a second, or 51.8 million a day. Decide which values answer a question before you poll them all, and use a [data collection plan](/blog/manufacturing-data-collection/) to rank them. ## Get machine data with or without a protocol IoTFlows reads machines both ways. [SenseAi](/docs/get-started/glossary/#senseai) mounts on the outside of any machine and reads vibration and sound, so it reports running, stopped, part counts and cycle times with no connection to the control. The sensors [never connect to your PLC](/docs/get-started/faq/#plc). On Enterprise, the IoTFlows [edge device](/docs/get-started/glossary/#edge-device) reads PLCs and controls over MTConnect, OPC UA, Modbus TCP, EtherNet/IP, Profinet and MQTT, and it reads only the controls you choose to connect. Its signals feed the same dashboards and alerts as the sensors, so a controller alarm can open a Maintain work order. IoTFlows engineers scope, build and validate each [custom integration](/platform/custom-integrations/), and it goes live in one week to a month, depending on the machines. [Stanley Black & Decker](/customers/stanley-black-decker/) used the edge device to pull every welding data point from the robotic welding machines on a major automotive customer’s production lines. ## Which protocol do you need? Start from the data you need, not from the protocol. The first two rows need no connection to the control at all. | Data you need | What reads it | |---|---| | Running or stopped, uptime, downtime | A sensor on the machine | | Part counts and cycle times | A sensor, or the control’s counter | | Program name, alarms, feed override | The control, over MTConnect or OPC UA | | Process values from a PLC | OPC UA, or Modbus TCP if that’s all it has | | Meters, drives, temperature controllers | Modbus TCP or Modbus RTU | | Setpoints written back to a machine | OPC UA, with write permissions agreed | Use that table with these rules: - **Choose MTConnect when** your machines are CNC machine tools whose controls support it and you only need to read. It gives every builder’s control the same names, which suits [CNC machine monitoring](/solutions/cnc-machine-monitoring/) across brands. - **Choose OPC UA when** you connect PLCs, robots or mixed equipment, need a typed model, need security in the protocol, or need to write back. - **Use Modbus when** a device offers nothing else. Load and verify its register map, and keep it on a protected network segment. - **You don’t need any of them if** your questions are about run time, stops and counts. A sensor answers those from outside the machine, and the [sensor vs PLC comparison](/compare/sensor-based-vs-plc-machine-monitoring/) sets out what each path sees. For a whole line, see [production line monitoring without PLCs](/blog/production-line-monitoring-without-plcs/). > **Specifying a new machine?** > > Ask the builder three questions before the order: which protocols the control supports, whether each one is a paid option on the control, and for the data item list or register map. The answers decide whether the machine connects on delivery or needs an adapter project. ## Questions ### Is MTConnect the same as OPC UA? No. MTConnect is a vocabulary for machine tool data with a read-only HTTP interface. OPC UA is a general framework that models, reads and writes data from any industrial device and secures the connection itself. The two organizations released a companion specification in 2019 that carries the MTConnect model over OPC UA, so one machine can offer both. ### Can MTConnect change settings on a machine? No. The MTConnect specification defines a read-only interface with no side effects on the agent or the equipment. A client can request the machine’s structure, its current values and buffered history, but it cannot start a program, change an offset or clear an alarm through MTConnect. ### Which ports do MTConnect, OPC UA and Modbus use? Modbus TCP uses port 502, and its TLS variant uses port 802. OPC UA TCP uses port 4840, and IANA also registers 4843 for OPC UA over TLS. An MTConnect agent serves HTTP on the port set in its own configuration, so read the agent’s settings before a firewall review. ### What is the difference between Modbus RTU and Modbus TCP? Both carry the same function codes and the same four data tables. Modbus RTU runs over serial lines such as RS-485, and Modbus TCP runs over Ethernet on port 502 with an extra header in front of each message. A gateway can translate between the two, so a serial device can still answer a TCP client. ### Do I need a protocol to monitor machine uptime? No. Uptime, downtime, part counts and cycle times can be read from outside the machine with a vibration or current sensor, with no connection to the control. A protocol adds what only the control knows, such as program names, alarm codes and feed overrides, so connect one when you need that data. ## Sources 1. [MTConnect Standard Part 1.0: Fundamentals, Version 2.5.0](https://docs.mtconnect.org/MBSD_MTConnect_Part_1_2-5-0.pdf), MTConnect Institute, accessed Oct 16, 2026 2. [RotaryVelocity.Actual, MTConnect SysML Model V2.5](https://model.mtconnect.org/Version2.5/ObservationInformationModel/ObservationTypes/SampleTypes/RotaryVelocityActual), MTConnect Institute, accessed Oct 16, 2026 3. [MTConnect C++ Agent (cppagent) README](https://github.com/mtconnect/cppagent), MTConnect Institute, accessed Oct 16, 2026 4. [OPC Foundation and MTConnect Institute announce release of the OPC UA Companion Specification for MTConnect](https://opcfoundation.org/news/press-releases/opc-foundation-and-mtconnect-institute-announce-release-of-the-opc-ua-companion-specification-for-mtconnect/), OPC Foundation, accessed Oct 16, 2026 5. [Unified Architecture](https://opcfoundation.org/about/opc-technologies/opc-ua/), OPC Foundation, accessed Oct 16, 2026 6. [OPC 10000-6 UA Part 6: Mappings, section 7 TransportProtocols](https://reference.opcfoundation.org/Core/Part6/v105/docs/7), OPC Foundation, accessed Oct 16, 2026 7. [OPC 10000-14 UA Part 14: PubSub, section 7 PubSub mappings](https://reference.opcfoundation.org/Core/Part14/v105/docs/7), OPC Foundation, accessed Oct 16, 2026 8. [Service Name and Transport Protocol Port Number Registry](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.csv), Internet Assigned Numbers Authority (IANA), accessed Oct 16, 2026 9. [MODBUS Application Protocol Specification V1.1b3](https://www.modbus.org/file/secure/modbusprotocolspecification.pdf), Modbus Organization, accessed Oct 16, 2026 10. [MODBUS/TCP Security Protocol Specification](https://www.modbus.org/file/secure/modbussecurityprotocol.pdf), Modbus Organization, accessed Oct 16, 2026 11. [Annual HMS report 2026: Industrial network market shares](https://www.hms-networks.com/news/news-details/15-06-2026-annual-hms-report-2026), HMS Networks, accessed Oct 16, 2026 --- # OEE monitoring tools for manufacturing, compared Source: https://www.iotflows.com/blog/top-oee-monitoring-tools-for-manufacturing/ OEE monitoring tools differ in where their data comes from: an operator, a wired signal, a sensor, the controller or an MES. Compare five types and pick one. > Question: What are the best OEE monitoring tools for manufacturing? ## Key takeaways - OEE monitoring tools differ mainly in where their data comes from: an operator, a wired signal, a sensor, the controller or an MES. - Run time and part counts can come straight from the machine, but quality almost always needs scrap logged by a person or an inspection step. - Filing short stops differently moves losses between availability and performance, while a wrong part count or ideal cycle time changes OEE itself. - Rockwell Automation says FactoryTalk Metrics will be discontinued after September 2028, and AVEVA now sells Wonderware MES as AVEVA MES. - Test any OEE tool against a hand count of ten parts before you trust its numbers. The best OEE monitoring tool for your plant is the one that measures availability, performance and quality from the machines you already run, with no one retyping numbers after the shift. Tools differ mainly in where the data comes from: an operator’s log, a wired signal, a sensor on the outside of the machine, the machine’s controller, or a manufacturing execution system (MES) above all of them. The sections below compare the five types, show what five named tools read as of October 2026, and work one shift through to show what the data source changes. They’re for engineers and plant managers choosing a first tool or replacing a spreadsheet. ## What an OEE monitoring tool measures > **Definition.** **OEE monitoring tool** is software that collects run time, stops, part counts and scrap from production machines and reports overall equipment effectiveness and its three factors, availability, performance and quality, for each machine and shift. OEE multiplies the three factors, and each factor needs different data.[1] Every tool on this page works the same formula, so the [OEE glossary entry](/docs/get-started/glossary/#oee) covers the terms once. **OEE** = Availability × Performance × Quality | Factor | Data the tool needs | Where it can come from | |---|---|---| | Availability | Run time and every stop | Sensor, signal, controller or operator | | Performance | Part count and ideal cycle time | Sensor, signal or controller count | | Quality | Good count and scrap | Operator entry or an inspection step | Run time and part counts can come straight from the machine. Quality rarely can: a mill that cuts a bad bracket runs the same cycle as one that cuts a good one, so a person or an inspection station decides which parts were scrap. The *ideal cycle time* is the best cycle the process sustains for one part, and you enter it once per operation, as [setting the ideal cycle time](/blog/ideal-cycle-time/) explains. For example, 1.6 minutes for a bracket on a Haas VF-2. For the arithmetic of each factor, see [how to calculate OEE](/blog/how-to-calculate-oee/). ## Five types of OEE monitoring tool Each type taps the machine at a different point. The tap decides what the tool sees on its own, and what your IT team reviews before anyone installs it. The ISA-95 standard places PLCs and other control devices at Level 2 and the MES at Level 3, above them.[2] The figure uses those levels. Figure: Three stacked boxes: the MES at ISA-95 Level 3, the PLC or CNC control at Level 2, the machine below. An MES module reads the MES, a controller connection reads the control, and a wired signal and an external sensor read the machine. *Where each type of OEE tool gets its data, from the MES down to the outside of the machine.* ### Paper and spreadsheets An operator writes down stops, counts and scrap, and someone types them into a spreadsheet. It costs nothing to start and works on any machine. [It sees only what someone records](/blog/manual-vs-automatic-oee-tracking/#missing-minutes). A 2-minute jam that happens 15 times a shift adds up to 30 minutes nobody stops to log, and the numbers arrive after the shift ends. ### Wired signals and counters A cable from a machine output, such as a cycle-complete relay or the stack light, feeds a counter or display that works out run time and counts. It reads any machine with a usable signal. An electrician wires it into the machine. It sees only what that one signal carries, so a stack light tells you running or stopped but not why. ### External sensors A sensor on the outside of the machine reads vibration, sound, motor current or a light beam, and turns the signal into running, stopped and parts made. It needs no controller access and no wiring into the controls. A [1990s knee mill](/blog/monitor-old-machines-without-a-plc/) and a new 5-axis machining center then report the same metrics, with nothing connected to either control. ### Controller connections Software reads the CNC control or PLC directly over a protocol such as MTConnect, FANUC FOCAS or OPC UA. A control with no network port needs a wired signal instead, which carries cycles and state but none of the controller’s internals. Controller data adds alarms, program numbers and process values such as spindle load to state and counts. Connecting to a control is a security concern for many plants, so IT usually reviews it first. ### MES performance modules An MES runs production orders, and its performance module computes OEE from data that PLCs, [SCADA systems](/blog/scada-vs-newer-manufacturing-technologies/) and historians already collect. It ties OEE to the order, the product and the batch. It works best where the controls and supervisory systems are already connected, since that’s where it gets its data. The project is scoped like any MES rollout, not like a sensor install. ## Five tools and what each reads The 2023 version of this article listed five tools. Here is what each one reads and where it stands as of October 2026, taken from each vendor’s own pages. | Tool | Type | Data source | Status, October 2026 | |---|---|---|---| | IoTFlows | External sensor | Vibration and sound from outside | Available | | MachineMetrics | Controller connection | MTConnect, FOCAS, OPC UA, digital I/O | Available | | FactoryTalk Metrics | MES performance module | Not published | Discontinued after September 2028 | | AVEVA MES | MES | AVEVA System Platform | Renamed from Wonderware MES | | TrakSYS | MES | Equipment, PLCs, SCADA, historians | Available | From each vendor’s own product pages, read 2026-10-16. Not published means the product page doesn’t name a data source. **FactoryTalk Metrics.** Rockwell Automation describes FactoryTalk Metrics as data collection and analysis for plant equipment that reports OEE and finds the root causes of downtime and loss. Its product page also says the product will be discontinued and no longer available after September 2028, and points customers to Plex MES.[4] If you run it today, plan the migration before you extend it to more lines. **AVEVA MES.** If you know it as Wonderware MES Performance, AVEVA now says Wonderware InTouch, System Platform, Historian and MES are AVEVA solutions, and lists AVEVA Manufacturing Execution System as formerly known as Wonderware MES.[5] Its MES page describes measuring OEE KPIs and schedule adherence in real time, with native integration for AVEVA System Platform.[6] **TrakSYS.** Parsec Automation describes TrakSYS as a modular MES that connects to equipment and PLCs, and to ERP, SCADA, LIMS and historians.[7] Its performance solution tracks OEE, yield and downtime in real time.[8] **MachineMetrics.** Its connectivity page lists native connections over MTConnect, FANUC FOCAS, OPC UA, EtherNet/IP and other protocols, and digital I/O for equipment with outdated controls or no network interface. The same page says OEE runs on that data feed.[3] **IoTFlows.** SenseAi reads the machine from the outside, described in [the section on sensors](#automatic) below. For a vendor-by-vendor scorecard, see the [IoTFlows alternatives comparison](/compare/iotflows-alternatives/). ## Same shift, two data sources The data source changes which factor a loss lands in more often than it changes OEE. Vorne’s definitions put small stops in performance and stops long enough to warrant a reason in availability.[1] Where your tool draws that line depends on what it records. #### Worked example: One 8-hour shift on a Haas VF-2, recorded two ways - Shift: 480 minutes, with a 30-minute break, so planned production time is 450 minutes. Ideal cycle time: 1.6 minutes. Total count: 200 brackets, 194 good. - The operator logs two stops: a 25-minute wait for material and a 15-minute fixture repair, 40 minutes in all. - A per-second stop record also finds 18 short stops of 2 minutes each, 36 minutes the log missed. From the operator log, run time is 410 minutes. Availability is 410 ÷ 450 = 91.1%, and performance is (200 × 1.6) ÷ 410 = 78.0%. From the stop record, run time is 374 minutes. Availability is 374 ÷ 450 = 83.1%, and performance is 320 ÷ 374 = 85.6%. Quality is 194 ÷ 200 = 97.0% either way. **Result:** OEE = (194 × 1.6) ÷ 450 = 69.0% in both cases The 36 minutes don’t vanish. The operator log hides them inside slow running, where nobody can find them. The stop record shows them as 18 [short stops](/blog/micro-stops/) you can count, classify and fix. Figure: Two bars of 450 planned minutes each give 310.4 minutes of good output and OEE of 69.0%. The same 36 minutes of short stops count as performance loss in the operator log and as availability loss in the per-second stop record. *The same 36 minutes of short stops, filed as slow running or as stops. OEE doesn’t change. Sample data.* > **What actually changes OEE** > > Filing a stop differently moves loss between availability and performance. A wrong part count, ideal cycle time or planned time changes OEE itself. For example, a count that registers each bracket twice reports 400 parts. Against 374 minutes of run time, that’s a performance of 171%, and a result over 100% is the tell. ## What to check before you choose Run these checks on the machines you know best before you trust any tool’s OEE. | Check | Why it matters | How to test it | |---|---|---| | Part count | It drives performance and quality | Hand-count ten parts against the tool | | Short stops | They decide the availability split | Time a few pauses with a stopwatch | | Ideal cycle time | Too slow a value hides losses | Time 10 to 20 good cycles yourself | | Planned time | Breaks in or out change availability | Enter shifts and breaks first | | Scrap entry | Quality needs a reason at the machine | Log a scrap part from the floor | | Offline time | Offline must not read as running | Unplug a device and read the report | | Controller access | IT reviews any control connection | Ask what the tool connects to | A count off by exactly 2× or 0.5× is usually a quantity-per-cycle setting, not a faulty detector. The part count matters most, because it feeds two of the three factors. Count ten parts by hand at the machine and compare them with the tool’s count for the same ten cycles. If the count is off, the [part-count troubleshooting checks](/docs/production/troubleshoot-part-counts/#start) find the usual cause in IoTFlows. ## Track OEE with a sensor on every machine [SenseAi](/products/senseai/) mounts magnetically on the outside of a machine, reads vibration and sound, and decides running or stopped every second, with no PLC or controller access. It counts parts from the machine’s cycle, so IoTFlows reports OEE factor by factor: availability as uptime, performance as parts made against the ideal cycle time, and quality from the scrap operators log with a reason. The [Short Downtimes rule](/docs/monitoring/auto-downtime-rules/#short-downtimes) settles the split from the example above. Stops under a per-machine cutoff, 5 minutes by default, get a category or count as uptime, as you choose. On Enterprise, the IoTFlows edge device adds controller data from the controls you choose to connect. [Jesel](/customers/jesel/), a valvetrain maker in Lakewood, New Jersey, reviews OEE daily and validates actual cycle times against its bills of material. ## Which type to choose Pick by the machines you run and the data you need beyond OEE. - **Choose a spreadsheet** when you’re proving the habit on one machine for a few weeks, before you spend anything. - **Choose a wired signal** when one line has a clean cycle signal and you want a count display beside it. - **Choose an external sensor** when your machines span brands and decades, or when controller connections are still under IT review. - **Choose a controller connection** when the machines are networked CNCs and you need alarms, program numbers or spindle load, not only state and counts. - **Choose an MES performance module** when you already run that vendor’s MES or SCADA and need OEE tied to orders, batches and genealogy. You don’t need an MES to measure OEE. Start with the machines that limit output, read the three factors for a month, and add controller data or an MES once a question needs alarms, programs or order data. Many plants combine types: a sensor on every machine, plus controller data on the CNCs that need it. To see what each controller protocol carries before you scope that second layer, read [machine communication protocols](/blog/machine-communication-protocols/). ## Questions ### Do I need an MES to track OEE? No. An MES runs production orders and records how they went, and OEE is one of many reports it produces. A plant that only wants OEE can start with a machine monitoring tool, fed by a sensor or a controller connection, and add an MES later when it needs order genealogy, batch records or electronic work instructions. ### Can OEE software read machines that have no network port? Yes, when the tool doesn't depend on the controller. An external sensor reads vibration, sound, motor current or a light beam from the outside, and a wired input reads a cycle signal or the stack light. Both work on machines decades old, because neither talks to the control. ### Is a spreadsheet good enough to calculate OEE? For one machine over a few weeks, yes. A spreadsheet works the formula as well as any software. It can't record the stops nobody wrote down, so short stops end up hidden inside performance, and the numbers arrive after the shift instead of while the loss is happening. ### Why do two OEE tools report different numbers for the same machine? They define the inputs differently. One tool may count breaks as planned production time and another may not, the ideal cycle times may differ, and the cutoff between a short stop and an availability stop varies. Align planned time, ideal cycle time and the short-stop cutoff before you compare results. ## Sources 1. [OEE Calculation: Definitions, Formulas, and Examples](https://www.oee.com/calculating-oee/), Vorne Industries, accessed Oct 16, 2026 2. [ISA-95 Standard: Enterprise-Control System Integration](https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard), International Society of Automation, accessed Oct 16, 2026 3. [CNC Machine Connectivity Software](https://www.machinemetrics.com/machine-connectivity), MachineMetrics, accessed Oct 16, 2026 4. [FactoryTalk Metrics](https://www.rockwellautomation.com/en-us/products/software/factorytalk/operationsuite/metrics.html), Rockwell Automation, accessed Oct 16, 2026 5. [Wonderware Solutions Are Now AVEVA Solutions](https://www.aveva.com/en/solutions/operations/wonderware/), AVEVA, accessed Oct 16, 2026 6. [AVEVA Manufacturing Execution System (MES)](https://www.aveva.com/en/products/manufacturing-execution-system/), AVEVA, accessed Oct 16, 2026 7. [TrakSYS MES Platform](https://parsec-corp.com/), Parsec Automation, accessed Oct 16, 2026 8. [Performance Management Software for Manufacturers](https://parsec-corp.com/solutions/by-function/performance), Parsec Automation, accessed Oct 16, 2026 --- # What is OEE? Source: https://www.iotflows.com/blog/what-is-oee/ OEE measures how much planned production time becomes good parts made at full speed. Learn the three factors, the formula, one worked shift and what it hides. > Question: What does overall equipment effectiveness measure, and what are its three factors? ## Key takeaways - OEE measures how much of a machine’s planned production time becomes good parts made at the ideal cycle time. - OEE multiplies three factors, availability, performance and quality, and each factor captures a different kind of loss. - Planned production time leaves out breaks and other time with no intent to run, but changeovers stay in as availability loss. - Two machines with the same OEE can need opposite fixes, so read the three factors on their own. - The 85% world-class figure is a target set within TPM practice, not a measured average across plants. OEE (overall equipment effectiveness) measures how much of a machine’s planned production time turns into good parts made at full speed. It multiplies three factors: availability asks whether the machine ran when it was scheduled to, performance asks whether it ran at its ideal cycle time, and quality asks whether each part was good the first time. The definitions below follow the common TPM calculation that most plants use. One shift on a CNC lathe is worked through by hand, and two presses show what a single OEE number hides. ## What OEE measures > **Definition.** **OEE (overall equipment effectiveness)** is the share of planned production time in which a machine makes good parts at its ideal cycle time. OEE equals availability × performance × quality, so a score of 100% means no stops, no slow cycles and no scrap. OEE came out of total productive maintenance (TPM), the program Seiichi Nakajima led in Japan from the early 1970s.[3] The [glossary entry for OEE](/docs/get-started/glossary/#oee) gives the same three factors in IoTFlows’ terms. **OEE** = Availability × Performance × Quality The product collapses into one ratio. *Fully productive time* is the time a machine would need to make only its good parts, at the ideal cycle time, with no stops.[1] **OEE** = (Good count × ideal cycle time) ÷ (Planned production time) For example, a CNC lathe that makes 170 good parts on a 2-minute ideal cycle has produced 340 minutes of fully productive time. Over 450 planned minutes, its OEE is 75.6%. The rest of this article explains where the other 110 minutes went. ## The three OEE factors Each factor isolates one kind of loss, so each one points to a different fix. | Factor | Question it answers | Formula | Loss it captures | |---|---|---|---| | Availability | Did it run when scheduled? | Run time ÷ planned production time | Breakdowns, changeovers, waiting | | Performance | Did it run at full speed? | (Count × ideal cycle time) ÷ run time | Slow cycles and short stops | | Quality | Were the parts good first time? | Good count ÷ total count | Scrap and rework | Formulas follow the common TPM calculation. Your plant decides what counts as planned production time. ### Availability *Availability* is run time divided by planned production time.[1] *Planned production time* is the shift less the time nobody intends to run the machine, such as breaks, meetings, a maintenance window with the machine scheduled off or a shift with no orders. Changeovers and setups stay in. A changeover is a planned stop, but the machine was meant to be producing during it, so it counts against availability.[1] For example, a 20-minute die change on a 450-minute shift costs 4.4 points of availability on its own. Planned maintenance is where plants draw the line differently. The six big losses count planned maintenance as a planned stop inside availability.[2] Take it out of planned production time only when the machine is scheduled off for the whole window, the way a weekend preventive maintenance slot is. > **Keep changeovers inside availability** > > Taking changeovers out of planned production time hides the loss that changeover work exists to cut. Remove only time with no intent to run. If your plant excludes changeovers anyway, say so beside every OEE figure, because the number no longer compares with a plant that counts them. Write the rule down once and apply it to every machine. A breaks-only rule on one machine and a breaks-and-changeovers rule on another make their OEE impossible to compare. ### Performance *Performance* compares the parts a machine made with the parts its ideal cycle time allows in the time it ran.[1] The *ideal cycle time* is the best cycle the process sustains in good conditions: not the fastest cycle ever recorded, not the shift’s average and not the quoted one. Performance catches what availability misses: slow cycles and stops too short for anyone to log. For example, a press running 40 strokes a minute against an ideal of 60 runs at 66.7% performance while its status light stays green all shift. Performance above 100% means the ideal cycle time is set too slow.[1] Fix the [ideal cycle time](/docs/get-started/glossary/#cycle-time), not the result: time 10 to 20 consecutive cycles of each operation on a good day and use the best sustainable cycle. ### Quality *Quality* is good parts divided by total parts. A good part passes the first time, so a part that needs rework counts as bad even when it ships.[1] For example, a molding cell that makes 2,000 parts, scraps 30 and reworks 50 has quality of 96.0%, not 98.5%. Counting reworked parts as good raises OEE and hides what the rework costs. ## Work one shift through Take one shift on a hypothetical CNC lathe and calculate each factor in order. #### Worked example: One 8-hour shift on a CNC lathe - Shift: 480 minutes, with 30 minutes of breaks, so planned production time is 450 minutes. - Stops: a 36-minute setup and an 18-minute breakdown, 54 minutes in all, so run time is 396 minutes. - Ideal cycle time: 2 minutes. Total count: 176 parts, of which 170 are good. Availability is 396 ÷ 450 = 88.0%. Performance is (176 × 2) ÷ 396 = 88.9%. Quality is 170 ÷ 176 = 96.6%. **Result:** OEE = 0.880 × 0.889 × 0.966 = 75.6% The short form gives the same answer: 170 good parts × 2 minutes = 340 minutes of fully productive time, and 340 ÷ 450 = 75.6%. Figure: Bars shrink from 450 planned minutes to 396 run minutes (54 min of stops, 88.0% availability), 352 minutes at ideal speed (88.9% performance) and 340 minutes of good parts (96.6% quality), for OEE of 75.6%. *One lathe shift, factor by factor: each loss removes minutes until 340 good minutes remain. Sample data.* Read the losses in minutes, not points. Stops cost 54 minutes, slow cycles 44 and scrap 12. The 36-minute setup is two thirds of the stopped time, so a faster changeover is the first project on this lathe, and the 44 slow minutes are the second. For more shifts worked step by step, see [how to calculate OEE](/blog/how-to-calculate-oee/). ## The six big losses TPM sorts every lost minute into six losses, two for each factor.[2] Assign each minute to exactly one loss, never two, so the three factors still multiply to the right result. | Loss | OEE factor | Examples | |---|---|---| | Equipment failure | Availability | Breakdowns, unplanned maintenance | | Setup and adjustments | Availability | Changeovers, tooling adjustments | | Idling and minor stops | Performance | Jams, misfeeds, blocked flow | | Reduced speed | Performance | Worn equipment, substandard material | | Process defects | Quality | Wrong settings, handling errors | | Reduced yield | Quality | Rejects while warming up after a change | Loss names and factor mapping follow the six big losses of TPM. Decide where a minor stop ends and a logged stop begins, for example at 2 minutes, and keep that line fixed.[2] Otherwise the same jam moves between availability and performance from one week to the next. ## What OEE tells you, and what it hides A single OEE percentage tells you how much time a machine lost. The three factors tell you what kind of time it lost, and that decides the fix. Figure: Two presses both score 65.8% OEE. The first has 70% availability, 95% performance and 99% quality; the second has 95% availability, 70% performance and 99% quality. *Two presses with the same OEE lose their time in different places and need different fixes. Sample data.* For example, two 200-ton presses each read 65.8% OEE. The first runs at 70% availability, 95% performance and 99% quality, so it loses its time to stops. The second runs at 95% availability, 70% performance and 99% quality, so it loses its time to slow strokes and jams. The first press needs reasons on its stops; the second needs a look at its feed and its ideal cycle time. The multiplication also compounds small losses. Three factors at 90% each give an OEE of 72.9%, not 90%.[3] Use OEE to: - **Find the largest loss on each machine,** first by factor and then by the six losses. - **Find the machines that limit output.** A point of OEE lost on the bottleneck costs the whole line, while the same point on a machine with spare capacity may cost nothing. - **Check whether a change worked,** by comparing the same machine before and after. Leggett & Platt Aerospace lifted OEE on the most problematic CNC lathe in a cell from 39% to 45% after a TPM program that included training its maintenance crew.[5] - **Price quality in machine time.** Scrap shows up as lost minutes beside stops and slow cycles, so you can rank all three on one scale. > **Utilization or OEE?** > > Utilization measures how much of the time a machine ran, and nothing about how fast it ran or how many parts were good. Track utilization first when you don’t yet know how often each machine runs. Move to OEE once parts are counted automatically and each operation has an ideal cycle time, because performance needs a reliable count. The glossary defines [utilization](/docs/get-started/glossary/#utilization) the way IoTFlows measures it, from the sensor alone. ## Benchmarks and world-class OEE An OEE of 85% is often called world class.[3] Nakajima set his world-class figures from practical experience as minimums for companies to strive for, not as a measured average across plants.[3] Reaching 85% takes high marks on every factor. For example, 90% availability, 95% performance and 99% quality multiply to 84.6%. Definitions differ too. Schiraldi and Varisco found that the ISO 22400 standard gives two definitions of OEE that appear to diverge from each other and from Nakajima’s original formulation.[4] Two plants can report different OEE for the same line, depending on whether changeovers sit inside planned production time and how each sets its ideal cycle times. Compare a machine with its own history before you compare it with a benchmark. Set the first goal a few points above your own baseline, as the guide to [choosing an OEE goal](/docs/monitoring/oee-goals/#choosing) describes, and raise it when the machine improves. ## Track OEE factor by factor IoTFlows measures availability and performance from a magnet-mount SenseAi on each machine, with no PLC connection. The sensor decides running or stopped every second, and Uptime, running time over running plus stopped inside your shifts, gives availability. The parts gauge gives performance: parts counted against what the ideal cycle time allows in the running time. Quality reads on Shift Production as good parts over everything counted, from the scrap operators log with a reason. One OEE goal colors every gauge green or red. The [metrics reference](/docs/monitoring/metrics-reference/) defines each number, and [OEE tracking](/solutions/oee-tracking/) shows the screens. > I use the dashboard every day to compare and validate actual cycle times against the times listed in our bills of material. > > Pete Gonella, Director of Manufacturing, Jesel ([story](https://www.iotflows.com/customers/jesel/)) ## Start measuring OEE You don’t need software to calculate OEE for one machine. You need a clear rule for planned time, an ideal cycle time and an honest count. 1. **Choose the first machine.** Start with the machine that limits your output, because its losses cost the whole line. 2. **Define planned production time.** Write down which time comes out, such as breaks, meetings and maintenance windows with the machine scheduled off, and keep changeovers in. Use the same rule on every machine. 3. **Set an ideal cycle time per operation.** Use the best cycle the machine sustains on each part, timed at the machine, not the quoted cycle time. 4. **Capture run time and part counts.** Record stops and counts by hand or from a sensor. A paper log holds the stops someone wrote down; a sensor records every one. The guide to [manufacturing data collection](/blog/manufacturing-data-collection/#methods) compares the ways to get them. 5. **Log scrap with a reason.** Record each bad part at the machine when it happens, with the reason, so quality and its causes come from the same entry. 6. **Review the factors every week.** Rank the week’s losses by minutes, fix the largest, and check the same machine’s factors the following week. ## Questions ### Does OEE include planned maintenance? Only when the machine was meant to be running. Time with no intent to produce, such as breaks or a maintenance window with the machine scheduled off, comes out of planned production time. Maintenance done during scheduled production counts as a planned stop inside availability, as do changeovers. Unplanned repairs always stay in. ### What is the difference between OEE and machine utilization? Utilization measures how much of the time a machine ran. OEE starts from the same running time and also asks how fast the machine ran against its ideal cycle time and how many of its parts were good the first time. A machine can show high utilization and low OEE. ### Can OEE be higher than 100%? No. A result above 100% comes from the performance factor, and it means the ideal cycle time behind it is set slower than the machine really runs. Set the ideal cycle time from the best cycle the process sustains in good conditions, timed over 10 to 20 consecutive cycles, then recalculate. ### Who created OEE? OEE comes from total productive maintenance, the program Seiichi Nakajima led in Japan from the early 1970s. His 1984 book Introduction to TPM set out the target figures that are still quoted as world-class OEE. ## Sources 1. [Calculate OEE](https://www.oee.com/calculating-oee/), Vorne Industries, accessed Oct 16, 2026 2. [The Six Big Losses](https://www.oee.com/oee-six-big-losses/), Vorne Industries, accessed Oct 16, 2026 3. [World-Class OEE](https://www.oee.com/world-class-oee/), Vorne Industries, accessed Oct 16, 2026 4. [Overall Equipment Effectiveness: consistency of ISO standard with literature (Computers & Industrial Engineering 145, 106518, 2020)](https://art.torvergata.it/handle/2108/280082), M. M. Schiraldi and M. Varisco, University of Rome Tor Vergata repository, accessed Oct 16, 2026 5. [Total Productive Maintenance Reduces Equipment Downtime and Lost Capacity](https://www.nist.gov/mep/successstories/2022/total-productive-maintenance-reduces-equipment-downtime-and-lost-capacity), NIST Manufacturing Extension Partnership, accessed Oct 16, 2026