Initial commit, 90% there
This commit is contained in:
mdares
@@ -0,0 +1,342 @@
|
||||
# 🚨 CRITICAL ISSUES DIAGNOSIS & FIX PLAN
|
||||
## For Tomorrow's Presentation
|
||||
|
||||
---
|
||||
|
||||
## 📊 ISSUE 1: Availability Starting at 100% Then Dropping
|
||||
|
||||
### Root Cause
|
||||
**The calculation is CORRECT, but the time accumulation logic is flawed.**
|
||||
|
||||
#### How It Works Now:
|
||||
1. Machine cycles function runs every time it receives input (sensor polls)
|
||||
2. When `trackingEnabled = true`:
|
||||
- If machine state = 1: adds time to `operatingTime`
|
||||
- If machine state = 0: adds time to `downtime`
|
||||
3. Availability = operatingTime / (operatingTime + downtime)
|
||||
|
||||
#### Why It Starts at 100%:
|
||||
- Initially: operatingTime = 10s, downtime = 0s
|
||||
- Availability = 10/10 = 100% ✓
|
||||
|
||||
#### Why It Drops to 50%, 40%, etc.:
|
||||
- Machine state = 0 (idle between cycles, or actual stops)
|
||||
- Downtime accumulates: 10s, 20s, 30s...
|
||||
- Availability = 10/(10+30) = 25% ❌
|
||||
|
||||
### The Problem:
|
||||
**Every idle moment (state=0) counts as downtime**, even if it's just waiting for the next cycle. This is technically accurate if you want to track "machine utilization", but NOT accurate for OEE availability.
|
||||
|
||||
### Correct OEE Availability Formula:
|
||||
**Availability = Run Time / Planned Production Time**
|
||||
|
||||
Where:
|
||||
- Run Time = time actually producing (cycles completing)
|
||||
- Planned Production Time = total time MINUS planned stops (breaks, maintenance)
|
||||
|
||||
### Current Implementation Error:
|
||||
We're treating ALL state=0 time as downtime, but we should ONLY count:
|
||||
1. Unplanned stops (machine malfunction, material shortage, etc.)
|
||||
2. NOT idle time between cycles
|
||||
3. NOT planned stops (lunch, breaks, maintenance)
|
||||
|
||||
---
|
||||
|
||||
## 📊 ISSUE 2: START Button Doesn't Affect Work Order Progress
|
||||
|
||||
### Root Cause
|
||||
**The START button IS working, but the complex session logic might be interfering.**
|
||||
|
||||
#### Flow Trace:
|
||||
1. User clicks START in Home dashboard
|
||||
2. Home Template sends `{ action: "start" }`
|
||||
3. Message goes: Home Template → link out 2 → link in 2 → Work Order buttons
|
||||
4. Work Order buttons case "start" executes
|
||||
5. Sets `trackingEnabled = true` ✓
|
||||
6. Creates new session in database ✓
|
||||
|
||||
### Potential Issues:
|
||||
1. **Session creation might be failing** (database error silently swallowed)
|
||||
2. **trackingEnabled is being set, but then immediately cleared** somewhere
|
||||
3. **Machine cycles isn't receiving proper input** to trigger cycles
|
||||
|
||||
### Diagnosis Needed:
|
||||
Check if:
|
||||
- `trackingEnabled` global variable is actually `true` after clicking START
|
||||
- Machine cycles function is being triggered (check debug log)
|
||||
- Cycles are being counted (check `cycleCount` global variable)
|
||||
|
||||
---
|
||||
|
||||
## 📊 ISSUE 3: Stop Prompt Not Showing
|
||||
|
||||
### Root Cause
|
||||
**WIRING ERROR: Stop prompt message not reaching the UI.**
|
||||
|
||||
#### Current Flow (BROKEN):
|
||||
1. User clicks STOP
|
||||
2. Work Order buttons case "stop" executes
|
||||
3. Sets `msg._mode = "stop-prompt"`
|
||||
4. Returns on output 2
|
||||
5. Output 2 is wired to: `f6ad294bc02618c9` (MySQL node) ❌
|
||||
|
||||
#### Should Be:
|
||||
1. User clicks STOP
|
||||
2. Work Order buttons case "stop" executes
|
||||
3. Sets `msg._mode = "stop-prompt"`
|
||||
4. Returns on output 2
|
||||
5. Output 2 should go to: Stop Reason UI Template ✓
|
||||
|
||||
#### Additional Issue:
|
||||
The Stop Reason UI Template (ID: `94afa68639264697`) is wired to output back to Work Order buttons, BUT Work Order buttons output 2 doesn't go to it!
|
||||
|
||||
**This is a circular dependency that wasn't properly wired:**
|
||||
- STOP button → Work Order buttons → Stop Reason UI → Work Order buttons (with reason)
|
||||
|
||||
---
|
||||
|
||||
## 🎯 COMPREHENSIVE FIX PLAN
|
||||
|
||||
### Priority 1: Fix Stop Prompt (CRITICAL for presentation)
|
||||
**Impact: HIGH | Complexity: LOW | Time: 5 minutes**
|
||||
|
||||
#### Actions:
|
||||
1. Add a Switch node after Work Order buttons output 2
|
||||
2. Route `_mode == "stop-prompt"` to Stop Reason UI
|
||||
3. Route other messages (refresh, etc.) to existing MySQL node
|
||||
4. Ensure Stop Reason UI output goes back to Work Order buttons
|
||||
|
||||
#### Side Effects:
|
||||
- None - this is just fixing broken wiring
|
||||
|
||||
#### Roadblocks:
|
||||
- None anticipated
|
||||
|
||||
---
|
||||
|
||||
### Priority 2: Fix Availability Calculation (CRITICAL for presentation)
|
||||
**Impact: HIGH | Complexity: MEDIUM | Time: 15 minutes**
|
||||
|
||||
#### Option A: Track Only Unplanned Downtime (RECOMMENDED)
|
||||
**Pros:**
|
||||
- Accurate OEE calculation
|
||||
- Planned stops don't affect availability
|
||||
- Aligns with industry standard
|
||||
|
||||
**Cons:**
|
||||
- Requires stop categorization to work (Priority 1 must be done first)
|
||||
|
||||
#### Implementation:
|
||||
1. Modify Machine cycles to NOT accumulate downtime during state=0
|
||||
2. ONLY accumulate downtime from stop_events where `affects_availability = 1`
|
||||
3. Query database in KPI calculation:
|
||||
```javascript
|
||||
// Get unplanned downtime from database
|
||||
const unplannedDowntime = await getUnplannedDowntime(workOrderId);
|
||||
availability = operatingTime / (operatingTime + unplannedDowntime);
|
||||
```
|
||||
|
||||
#### Option B: Ignore State=0 Between Cycles (SIMPLER but less accurate)
|
||||
**Pros:**
|
||||
- Quick fix
|
||||
- No database queries needed
|
||||
|
||||
**Cons:**
|
||||
- Won't track actual unplanned stops accurately
|
||||
- Defeats the purpose of stop categorization
|
||||
|
||||
#### Implementation:
|
||||
1. Remove downtime accumulation from Machine cycles
|
||||
2. Set availability = 100% while tracking is enabled
|
||||
3. (Not recommended - loses valuable data)
|
||||
|
||||
#### Side Effects:
|
||||
- Historical data won't be affected (already in database)
|
||||
- Going forward, availability will be calculated differently
|
||||
|
||||
#### Roadblocks:
|
||||
- None, but requires database queries (Option A)
|
||||
|
||||
---
|
||||
|
||||
### Priority 3: Simplify START/STOP Logic (MEDIUM priority)
|
||||
**Impact: MEDIUM | Complexity: LOW | Time: 10 minutes**
|
||||
|
||||
#### Current Issue:
|
||||
The START/STOP cases have complex session management that might be causing issues.
|
||||
|
||||
#### Actions:
|
||||
1. Keep the complex logic BUT add better error handling
|
||||
2. Add debug logging to track what's happening
|
||||
3. Ensure `trackingEnabled` is set correctly
|
||||
|
||||
#### OR (simpler):
|
||||
1. Strip out session management from START/STOP
|
||||
2. Make START/STOP ONLY control `trackingEnabled`
|
||||
3. Move session management to work order start/complete only
|
||||
|
||||
#### Recommended Approach:
|
||||
**Keep session management, but add safeguards:**
|
||||
```javascript
|
||||
case "start": {
|
||||
// Simpler version - just enable tracking
|
||||
const now = Date.now();
|
||||
|
||||
if (!global.get("productionStartTime")) {
|
||||
global.set("productionStartTime", now);
|
||||
global.set("operatingTime", 0);
|
||||
global.set("downtime", 0);
|
||||
}
|
||||
|
||||
global.set("trackingEnabled", true);
|
||||
global.set("lastUpdateTime", now);
|
||||
|
||||
node.warn("[START] Tracking enabled");
|
||||
|
||||
return [null, null, null, null, null];
|
||||
}
|
||||
```
|
||||
|
||||
#### Side Effects:
|
||||
- Sessions won't be created on START/STOP (only on work order start/complete)
|
||||
- Simpler = fewer failure points
|
||||
|
||||
#### Roadblocks:
|
||||
- None
|
||||
|
||||
---
|
||||
|
||||
### Priority 4: Fix Work Order Progress Display (LOW priority)
|
||||
**Impact: LOW | Complexity: LOW | Time: 5 minutes**
|
||||
|
||||
#### Issue:
|
||||
User says "START/STOP made no difference on work order advance"
|
||||
|
||||
#### Diagnosis:
|
||||
- Work order progress IS updating (you said cycles are counting)
|
||||
- Likely the UI isn't refreshing to show the update
|
||||
|
||||
#### Actions:
|
||||
1. Check if cycle updates are reaching "Back to UI" function
|
||||
2. Verify Home Template is receiving `activeWorkOrder` updates
|
||||
3. Add forced refresh after each cycle
|
||||
|
||||
#### Side Effects:
|
||||
- None
|
||||
|
||||
#### Roadblocks:
|
||||
- None
|
||||
|
||||
---
|
||||
|
||||
## 🚀 IMPLEMENTATION ORDER FOR TOMORROW
|
||||
|
||||
### Phase 1: CRITICAL FIXES (30 minutes)
|
||||
1. **Fix Stop Prompt Wiring** (5 min)
|
||||
- Add Switch node
|
||||
- Wire stop-prompt to Stop Reason UI
|
||||
|
||||
2. **Fix Availability Calculation** (15 min)
|
||||
- Remove downtime accumulation from state=0
|
||||
- Track downtime only from stop_events
|
||||
- Update KPI calculation to query database
|
||||
|
||||
3. **Simplify START/STOP** (10 min)
|
||||
- Remove complex session logic
|
||||
- Just enable/disable tracking
|
||||
|
||||
### Phase 2: TESTING (15 minutes)
|
||||
1. Test stop prompt shows when clicking STOP
|
||||
2. Test availability stays high (>95%) during normal operation
|
||||
3. Test START/STOP enables/disables cycle counting
|
||||
4. Test unplanned stop reduces availability
|
||||
5. Test planned stop does NOT reduce availability
|
||||
|
||||
### Phase 3: VALIDATION (15 minutes)
|
||||
1. Run full work order from start to finish
|
||||
2. Verify KPIs are accurate
|
||||
3. Document any remaining issues
|
||||
|
||||
---
|
||||
|
||||
## 📋 DETAILED FIX SCRIPTS
|
||||
|
||||
### Fix 1: Stop Prompt Wiring
|
||||
```python
|
||||
# Add switch node between Work Order buttons output 2 and destinations
|
||||
# Route stop-prompt to Stop Reason UI
|
||||
# Route others to MySQL
|
||||
```
|
||||
|
||||
### Fix 2: Availability Calculation
|
||||
```javascript
|
||||
// In KPI Calculation function:
|
||||
// Query unplanned downtime from database
|
||||
const unplannedDowntimeSql = `
|
||||
SELECT COALESCE(SUM(duration), 0) as downtime
|
||||
FROM stop_events
|
||||
WHERE work_order_id = '${activeOrder.id}'
|
||||
AND affects_availability = 1
|
||||
AND resume_time IS NOT NULL;
|
||||
`;
|
||||
|
||||
// Use this instead of global.get("downtime")
|
||||
```
|
||||
|
||||
### Fix 3: Simplified START/STOP
|
||||
```javascript
|
||||
case "start": {
|
||||
const now = Date.now();
|
||||
if (!global.get("productionStartTime")) {
|
||||
global.set("productionStartTime", now);
|
||||
global.set("operatingTime", 0);
|
||||
global.set("downtime", 0);
|
||||
}
|
||||
global.set("trackingEnabled", true);
|
||||
global.set("lastUpdateTime", now);
|
||||
return [null, null, null, null, null];
|
||||
}
|
||||
|
||||
case "stop": {
|
||||
// Show prompt first
|
||||
msg._mode = "stop-prompt";
|
||||
return [null, msg, null, null, null];
|
||||
}
|
||||
|
||||
// Then after prompt response:
|
||||
case "stop-reason": {
|
||||
// Disable tracking after reason selected
|
||||
global.set("trackingEnabled", false);
|
||||
// ... rest of logic
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ RISKS & MITIGATION
|
||||
|
||||
### Risk 1: Database Queries Slow Down KPI Updates
|
||||
**Mitigation:** Cache downtime value, update every 30 seconds instead of every 5
|
||||
|
||||
### Risk 2: Breaking Existing Functionality
|
||||
**Mitigation:** Create backup before changes, test each fix individually
|
||||
|
||||
### Risk 3: Running Out of Time
|
||||
**Mitigation:** Prioritize fixes - do Priority 1 & 2 only if time is short
|
||||
|
||||
---
|
||||
|
||||
## ✅ SUCCESS CRITERIA FOR TOMORROW
|
||||
|
||||
1. **Stop button shows prompt** ✓
|
||||
2. **Availability stays >90% during production** ✓
|
||||
3. **START button enables cycle counting** ✓
|
||||
4. **STOP button disables cycle counting** ✓
|
||||
5. **Unplanned stops reduce availability** ✓
|
||||
6. **Planned stops do NOT reduce availability** ✓
|
||||
7. **Quality affected by scrap** ✓ (already working)
|
||||
8. **OEE calculated correctly** ✓
|
||||
|
||||
---
|
||||
|
||||
**Ready to implement? Let's start with Priority 1.**
|
||||
Reference in New Issue
Block a user