Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/blog/2025/04/what-is-an-oee-dashboard.md
Original file line number Diff line number Diff line change
Expand Up @@ -111,7 +111,7 @@ For this series, we will be building the dashboard at the line-level. In this ca

As mentioned earlier, the dashboard will calculate OEE for a production line, presenting key metrics such as availability, performance, quality, and the overall OEE score. While the overall OEE score provides a quick snapshot of performance, it does not offer enough detail to pinpoint specific areas that need improvement.

To address this, the dashboard will break down the OEE calculation at the machine level as well, enabling managers to identify underperforming machines that affect overall efficiency. Additionally, it will display recent downtime incidents, summarizing this data to uncover trends and identify potential root causes. This breakdown will provide a clearer understanding of where inefficiencies are occurring and allow for targeted corrective actions. The dashboard only displays downtime events, so something has to record them first. If you do not already capture stoppages with a reason attached, our [machine downtime logger](/blog/2026/07/build-downtime-logger/) covers building that: catching stop and start signals over MQTT and letting operators log why the line stopped.
To address this, the dashboard will break down the OEE calculation at the machine level as well, enabling managers to identify underperforming machines that affect overall efficiency. Additionally, it will display recent downtime incidents, summarizing this data to uncover trends and identify potential root causes. This breakdown will provide a clearer understanding of where inefficiencies are occurring and allow for targeted [corrective actions](/blog/2026/09/capa-corrective-preventive-action/). The dashboard only displays downtime events, so something has to record them first. If you do not already capture stoppages with a reason attached, our [machine downtime logger](/blog/2026/07/build-downtime-logger/) covers building that: catching stop and start signals over MQTT and letting operators log why the line stopped.

The dashboard will also track production quality, displaying the number of acceptable versus defective parts to ensure a continued focus on quality control. Additionally, last 30-days OEE trend analysis will be included, offering insights into performance changes over time. This will help managers identify patterns, monitor improvements, and highlight areas requiring attention.

Expand Down
2 changes: 1 addition & 1 deletion src/blog/2025/09/poka-yoke-mistake-proofing.md
Original file line number Diff line number Diff line change
Expand Up @@ -137,7 +137,7 @@ The future of poka yoke increasingly incorporates Industry 4.0 technologies that

Modern smart manufacturing systems integrate digital work instructions that guide operators through complex procedures step-by-step, ensuring consistency while accommodating process variations. Adaptive tooling automatically adjusts parameters based on real-time measurements, preventing specification deviations while maintaining production efficiency.

FlowFuse enables sophisticated poka yoke implementations by connecting IoT sensors, machine data, and quality control systems in real-time workflows. Manufacturing teams can build automated solutions that trigger immediate alerts, stop processes when deviations occur, and guide operators through corrective actions, all without complex programming or expensive custom solutions.
FlowFuse enables sophisticated poka yoke implementations by connecting IoT sensors, machine data, and quality control systems in real-time workflows. Manufacturing teams can build automated solutions that trigger immediate alerts, stop processes when deviations occur, and guide operators through [corrective actions](/blog/2026/09/capa-corrective-preventive-action/), all without complex programming or expensive custom solutions.

## Conclusion

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -83,7 +83,7 @@ Use this simple template to run the analysis, filling in each line with a verifi
- **Why 2:** Why did *that* condition exist?
- **Why 3–5 (as needed):** Keep asking why of the previous answer.
- **Root cause:** The systemic gap you can actually fix.
- **Corrective action:** The specific fix, owner, and deadline.
- **[Corrective action](/blog/2026/09/capa-corrective-preventive-action/):** The specific fix, owner, and deadline.

Each answer should be something you can verify: a physical observation, sensor data, a log, or direct testimony, not speculation. "Probably the operator forgot" isn't an answer; "the feed line was clogged, confirmed by checking oil flow" is. Stop once you reach a process failure or systemic gap you can fix with a clear corrective action, revising a maintenance procedure or adding a training step, rather than "operator error" or "equipment failure," which are symptoms, not causes.

Expand Down
2 changes: 1 addition & 1 deletion src/blog/2026/07/defect-and-quality-monitoring.md
Original file line number Diff line number Diff line change
Expand Up @@ -398,7 +398,7 @@ This is the widget that answers whether defects are being closed fast enough, no
2. Add a change node named "Extract Status Funnel Data": set `payload` to `payload[0].status_funnel` (msg).
3. Add a ui-chart node in the Status Funnel group, chart type Bar, `status` on the x-axis, `defect_count` on the y.

The query orders it by workflow stage (Detected, RCA, Corrective Action, Resolved, Verified), so a pile-up at any stage is visible at a glance.
The query orders it by workflow stage (Detected, RCA, [Corrective Action](/blog/2026/09/capa-corrective-preventive-action/), Resolved, Verified), so a pile-up at any stage is visible at a glance.

![Screenshot: the Status Funnel bar chart, ordered by workflow stage](./images/status-funnel.png)
*The status funnel bar chart, bars in workflow order.*
Expand Down
2 changes: 1 addition & 1 deletion src/blog/2026/07/ishikawa-fishbone-diagram.md
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ meta:
- question: "Who invented the Ishikawa diagram and when?"
answer: "Kaoru Ishikawa (1915–1989), a Japanese engineer and University of Tokyo professor, popularized the diagram in the 1960s while developing quality-management processes at the Kawasaki shipyards, and formalized it in his 1968 book Guide to Quality Control. It is one of the seven basic quality tools and was designed so that ordinary workers, not just specialists, could analyze the causes of quality problems."
- question: "Can I build a fishbone diagram in FlowFuse?"
answer: "FlowFuse isn't a drawing tool for the diagram itself; a whiteboard or diagramming app is quicker for the brainstorming stage. Where FlowFuse helps is the step after: it connects to your PLCs, sensors, and quality systems so you can verify which suspected cause on the fishbone is real, using live production data, and build dashboards that confirm your corrective action actually worked."
answer: "FlowFuse isn't a drawing tool for the diagram itself; a whiteboard or diagramming app is quicker for the brainstorming stage. Where FlowFuse helps is the step after: it connects to your PLCs, sensors, and quality systems so you can verify which suspected cause on the fishbone is real, using live production data, and build dashboards that confirm your [corrective action](/blog/2026/09/capa-corrective-preventive-action/) actually worked."
cta:
type: contact
title: "Turn suspected causes into verified ones"
Expand Down
2 changes: 1 addition & 1 deletion src/blog/2026/08/layered-process-audit.md
Original file line number Diff line number Diff line change
Expand Up @@ -137,7 +137,7 @@ A practical rule is: the higher the layer, the wider the scope and the lower the
4. **Train the auditors.** Auditors should observe the process, ask factual questions, and record evidence rather than opinions.
5. **Perform the audit at the station.** Watch the operation and record answers while standing at the workstation.
6. **Correct immediate issues.** Fix simple problems during the audit whenever possible.
7. **Assign corrective actions.** Give each finding an owner and a due date.
7. **Assign [corrective actions](/blog/2026/09/capa-corrective-preventive-action/).** Give each finding an owner and a due date.
8. **Verify closure.** Confirm that the action was completed and remains effective during the next audit cycle.

Most LPAs take 5 to 15 minutes. If an audit takes much longer, the checklist is usually too large for a routine layered audit.
Expand Down
Loading