59 lines
3.0 KiB
Plaintext
59 lines
3.0 KiB
Plaintext
Final Review: Recommendations & Refinements
|
|
1. Refining Global Context Persistence (Roadblock 1)
|
|
Your initialization logic is good, but one step can prevent potential data skew on a restart.
|
|
|
|
Refinement: Clear Buffer on Production Start.
|
|
|
|
The kpiBuffer should be explicitly cleared when the START button is clicked, regardless of the averaging timer.
|
|
|
|
Reason: If Node-RED restarts during a long production run (context is restored from disk), the kpiBuffer might contain stale data from before the restart. When the machine cycle flow resumes, new data is added, and the average will be skewed.
|
|
|
|
Action: Add a global.set("kpiBuffer", []) into the "Work Order buttons" logic right after global.set("trackingEnabled", true) (Phase 3.3 Backend Update). This resets the history buffer cleanly for the new run.
|
|
|
|
2. Refining the Availability Logic (Roadblock 5)
|
|
The Time-Based Availability is much better, but it relies on a new variable.
|
|
|
|
Refinement: Consolidate State for lastMachineCycleTime.
|
|
|
|
You are introducing global.get("lastMachineCycleTime"). Ensure this value is written only inside the Machine Cycles function, and only when a successful cycle is detected. This separates the machine's "pulse" from the general KPI calculation trigger.
|
|
|
|
Action: Add the following to the Machine Cycles function right before the final return statement:
|
|
|
|
JavaScript
|
|
|
|
if (trackingEnabled && dbMsg) { // dbMsg implies a cycle occurred
|
|
global.set("lastMachineCycleTime", Date.now());
|
|
}
|
|
Initial Value: Ensure that global.get("lastMachineCycleTime") is initialized to Date.now() on startup/deploy (Roadblock 1's Init Node) to prevent an immediate 0% availability on a fresh deploy.
|
|
|
|
3. Refining UI Initialization (Roadblock 3 - Option A)
|
|
Your data-driven initialization (Option A) is the strongest choice, but needs a safe fallback.
|
|
|
|
Refinement: Combine Data-Driven with Guaranteed Timeout.
|
|
|
|
If no production is running, no KPI messages flow, and the charts will never initialize.
|
|
|
|
Action: Keep Option A (data-driven) but wrap the scope.$watch in an initial setTimeout (e.g., 5 seconds) that only initializes the charts if the chartsInitialized flag is still false. This covers the "dashboard loaded, but machine is idle" scenario.
|
|
|
|
JavaScript
|
|
|
|
// In Graphs Template (Simplified logic)
|
|
// ... scope.$watch logic (Option A) ...
|
|
|
|
// ADDED: Safety timer for when machine is idle
|
|
setTimeout(() => {
|
|
if (!chartsInitialized) {
|
|
node.warn("Charts initialized via safety timer (machine idle).");
|
|
initFilters();
|
|
createCharts(currentRange);
|
|
chartsInitialized = true;
|
|
}
|
|
}, 5000); // 5 seconds grace period
|
|
4. Minor Flow/Dependency Note
|
|
Clarity: Ensure the Calculate KPIs function (Phase 3.2) correctly handles the fact that it is now triggered by two sources:
|
|
|
|
Machine Cycles (Continuous/Real-Time)
|
|
|
|
Scrap Submission (Event-based)
|
|
|
|
The logic should execute regardless of the input message's content, as long as it receives a trigger, ensuring the availability calculation runs in both continuous and event-driven scenarios. Your Option A fix for Issue 1 covers this well, but it's a critical dependency. |