241 lines
9.2 KiB
Plaintext
241 lines
9.2 KiB
Plaintext
================================================================================
|
||
WORK ORDER PERSISTENCE - IMPLEMENTATION SUMMARY
|
||
Implementation Date: November 29, 2025
|
||
Node-RED Location: /home/mdares/.node-red/
|
||
Backup Location: flows.json.backup_ALL_PHASES_COMPLETE
|
||
================================================================================
|
||
|
||
OVERVIEW
|
||
--------
|
||
Successfully implemented all 7 phases of the work order persistence system.
|
||
The system now ensures work order progress is preserved across Node-RED restarts,
|
||
provides resume/restart functionality, and maintains database as source of truth.
|
||
|
||
|
||
PHASES IMPLEMENTED
|
||
------------------
|
||
|
||
✅ PHASE 1: Database Schema Verification & Updates
|
||
- Verified work_orders table has required columns
|
||
- Confirmed: cycle_count, good_parts, scrap_parts, progress_percent columns exist
|
||
- Status: COMPLETE (already had correct schema)
|
||
|
||
✅ PHASE 2: Add Cycle Persistence to work_orders Table
|
||
- Added 4th output to Machine Cycles function
|
||
- Initially implemented with 5-second throttling
|
||
- UPDATED: Changed to immediate write (every cycle) for accuracy
|
||
- SQL: UPDATE work_orders SET cycle_count, good_parts, scrap_parts, progress_percent
|
||
- Database now updates on EVERY cycle (no lag)
|
||
- Files Modified: flows.json (Machine cycles function)
|
||
|
||
✅ PHASE 3: Implement Resume/Restart Prompt on Load
|
||
- Modified start-work-order to query DB for existing progress
|
||
- Added Progress Check Handler node to evaluate progress
|
||
- Created resume-work-order action handler
|
||
- Created restart-work-order action handler
|
||
- Added Resume/Restart prompt dialog to Home template UI
|
||
- Fixed: Added scrap_parts to queries and resume logic
|
||
- Files Modified: flows.json (Work Order buttons, Progress Check Handler, Home Template)
|
||
|
||
✅ PHASE 4: Fix Complete Button to Persist Final Counts
|
||
- Modified complete-work-order handler to capture final values
|
||
- SQL: UPDATE work_orders SET status='DONE', cycle_count, good_parts, scrap_parts, progress_percent=100
|
||
- Final production counts now permanently saved before marking DONE
|
||
- Files Modified: flows.json (Work Order buttons)
|
||
|
||
✅ PHASE 5: Update Session Restore to Set RUNNING Status
|
||
- Modified restore-query handler in Back to UI
|
||
- Automatically sets work order status back to RUNNING on Node-RED restart
|
||
- User must still click Start button to begin counting (safety feature)
|
||
- Fixed: Corrected start handler bug (removed undefined dbMsg reference)
|
||
- Files Modified: flows.json (Back to UI function)
|
||
|
||
✅ PHASE 6: Load Work Order Data from Database (Not Session)
|
||
- Updated Progress Check Handler to use DB values as source of truth
|
||
- Even when progress is 0, values are loaded from database (not hardcoded)
|
||
- activeWorkOrder object now includes all DB fields (cycle_count, good_parts, scrap)
|
||
- Files Modified: flows.json (Progress Check Handler)
|
||
|
||
✅ PHASE 7: Add Tab Switch State Refresh (Optional Enhancement)
|
||
- Added tab refresh polling (every 2 seconds when Home tab visible)
|
||
- Added currentState message handler to Home template
|
||
- UI now refreshes with latest data when switching back to Home tab
|
||
- Files Modified: flows.json (Home Template)
|
||
|
||
|
||
KEY IMPROVEMENTS & FIXES
|
||
-------------------------
|
||
|
||
1. SCRAP TRACKING FIX
|
||
- Issue: Resume showed wrong good_parts count (calculation: cycles × cavities - scrap)
|
||
- Root Cause: scrap value not loaded from database on resume
|
||
- Fix: Added scrap_parts to all DB queries and resume/restart handlers
|
||
- Result: Resume now shows accurate good_parts count
|
||
|
||
2. DATABASE LAG FIX
|
||
- Issue: Database was one cycle behind (5-second throttle)
|
||
- User Feedback: Loading work order showed stale data
|
||
- Fix: Removed throttle, now writes to DB on every cycle
|
||
- Result: Database always current, Load shows exact progress
|
||
|
||
3. LOAD BUTTON BUG FIX
|
||
- Issue: After Phase 5, Load button stopped working (no UI update, no RUNNING status)
|
||
- Root Cause: start handler referenced undefined dbMsg variable
|
||
- Fix: Changed return [dbMsg, homeMsg, null, null] to [null, homeMsg, null, null]
|
||
- Result: Load button works perfectly
|
||
|
||
|
||
TECHNICAL DETAILS
|
||
------------------
|
||
|
||
Modified Nodes:
|
||
1. Machine cycles (function) - Immediate DB persistence
|
||
2. Work Order buttons (function) - start/resume/restart/complete handlers
|
||
3. Progress Check Handler (function) - NEW node for progress evaluation
|
||
4. Back to UI (function) - resume-prompt and restore-query handlers
|
||
5. Home Template (ui_template) - Resume/Restart dialog and tab refresh
|
||
|
||
Database Updates:
|
||
- work_orders table: cycle_count, good_parts, scrap_parts, progress_percent updated on every cycle
|
||
- Status transitions: PENDING → RUNNING → DONE
|
||
- Session restore sets status back to RUNNING
|
||
|
||
Flow Connections:
|
||
- Machine cycles → Output 4 → DB Guard (Cycles) → mariaDB
|
||
- Work Order buttons → Progress Check Handler → Back to UI → Home Template
|
||
- All database writes use parameterized queries (SQL injection safe)
|
||
|
||
|
||
USER WORKFLOWS
|
||
--------------
|
||
|
||
1. START NEW WORK ORDER
|
||
- Click Load on work order with no progress
|
||
- Status changes to RUNNING in database
|
||
- Click Start button to begin production
|
||
- Each cycle updates database immediately
|
||
- Progress visible in UI and database
|
||
|
||
2. RESUME EXISTING WORK ORDER
|
||
- Click Load on work order with progress (e.g., 60/200 parts)
|
||
- Resume/Restart prompt appears
|
||
- Click "Resume from 60 parts"
|
||
- Status changes to RUNNING
|
||
- Production continues from 60 parts
|
||
- Click Start to begin counting
|
||
|
||
3. RESTART WORK ORDER
|
||
- Click Load on work order with progress
|
||
- Resume/Restart prompt appears
|
||
- Click "Restart from 0"
|
||
- Confirmation dialog appears
|
||
- After confirm: cycle_count, good_parts, scrap_parts reset to 0
|
||
- Status changes to RUNNING
|
||
- Click Start to begin counting from 0
|
||
|
||
4. COMPLETE WORK ORDER
|
||
- Click Done button
|
||
- Final cycle_count, good_parts, scrap_parts persisted to database
|
||
- progress_percent set to 100
|
||
- Status changes to DONE
|
||
- All state cleared
|
||
|
||
5. NODE-RED RESTART (SESSION RESTORE)
|
||
- Node-RED restarts (crash or maintenance)
|
||
- System queries for work orders with status='RUNNING'
|
||
- Restores activeWorkOrder with cycle_count, good_parts, scrap
|
||
- Status remains RUNNING (or is set back to RUNNING)
|
||
- UI shows work order loaded
|
||
- User must click Start to resume production
|
||
|
||
6. TAB SWITCHING
|
||
- User on Home tab with production running
|
||
- Switches to Graphs tab
|
||
- Production continues in background
|
||
- Switches back to Home tab
|
||
- Within 2 seconds, UI refreshes with latest data
|
||
|
||
|
||
TESTING CHECKLIST
|
||
-----------------
|
||
|
||
✓ New work order start (0 progress)
|
||
✓ Resume existing work order (with progress)
|
||
✓ Restart existing work order (with progress)
|
||
✓ Complete work order (final counts persisted)
|
||
✓ Node-RED restart with running work order
|
||
✓ Tab switching shows fresh data
|
||
✓ Database updates on every cycle
|
||
✓ Load button shows current progress (not stale)
|
||
✓ Scrap tracking accurate on resume
|
||
✓ Resume/Restart prompt appears when expected
|
||
✓ Start button enabled/disabled correctly
|
||
|
||
|
||
BACKUP FILES
|
||
------------
|
||
|
||
flows.json.backup_phase3 - After Phase 3 (Resume/Restart)
|
||
flows.json.backup_phase3_complete - Phase 3 complete with scrap fix
|
||
flows.json.backup_phase5_complete - After Phase 5 (Session Restore)
|
||
flows.json.backup_phase6_complete - After Phase 6 (DB source of truth)
|
||
flows.json.backup_phase7_complete - After Phase 7 (Tab refresh)
|
||
flows.json.backup_ALL_PHASES_COMPLETE - FINAL BACKUP (all phases complete)
|
||
|
||
To restore a backup:
|
||
cd /home/mdares/.node-red
|
||
cp flows.json.backup_ALL_PHASES_COMPLETE flows.json
|
||
# Restart Node-RED
|
||
|
||
|
||
KNOWN BEHAVIOR
|
||
--------------
|
||
|
||
1. Production must be started manually (safety feature)
|
||
- After Load: Status = RUNNING, but production not started
|
||
- User must click Start button
|
||
- This prevents accidental production during debugging
|
||
|
||
2. Database writes on every cycle
|
||
- Originally throttled to 5 seconds
|
||
- Changed to immediate for accuracy
|
||
- Performance impact: negligible (1 query per cycle ~30-120s)
|
||
|
||
3. Maximum data loss on crash: 1 incomplete cycle
|
||
- Database updates after each complete cycle
|
||
- If Node-RED crashes mid-cycle, that cycle is lost
|
||
- Session restore recovers all complete cycles
|
||
|
||
4. Tab refresh polls every 2 seconds
|
||
- Only when Home tab is visible
|
||
- Minimal performance impact
|
||
- Ensures UI stays fresh
|
||
|
||
|
||
SUCCESS CRITERIA MET
|
||
--------------------
|
||
|
||
✅ Work orders persist progress across Node-RED restarts
|
||
✅ Resume/Restart prompt prevents accidental data loss
|
||
✅ work_orders table always reflects current production state
|
||
✅ Tab switches don't lose data
|
||
✅ Multi-day work orders can be interrupted and resumed
|
||
✅ Maximum data loss: 1 cycle on crash (acceptable)
|
||
✅ Database is single source of truth
|
||
✅ UI always shows current, accurate data
|
||
|
||
|
||
IMPLEMENTATION NOTES
|
||
--------------------
|
||
|
||
- All SQL queries use parameterized statements (safe from SQL injection)
|
||
- Database is source of truth (not session/memory)
|
||
- UI updates use Angular scope watchers
|
||
- Error handling includes node.warn() logging for debugging
|
||
- Flow connections verified and tested
|
||
- No backwards compatibility issues
|
||
|
||
|
||
FINAL STATUS: ✅ ALL PHASES COMPLETE AND TESTED
|
||
================================================================================
|