תזמון והספק

הקושחה קובעת setMaxSpeed(500) ו־setAcceleration(200) (מ־config/control-params.json, אותו מקור של חוק הבקרה), ודגימת חיישנים כל 2000 ms. מהלך 20° הוא משולש קצר שלא מגיע ל־500 צעד/שנייה — הדגימה, לא המנוע, היא השהיית המפעל. באותו זמן handleClient() יכול להרעיב פולסים. למטה: למה סלילי NEMA17 הם המוצר, וה־ESP32 הוא עיגול.

פרופיל תנועה

מעטפת מהירות

—

זווית ומספרים מהקושחה

מ־ (°): 0 אל (°): 40

—סוג פרופיל

—צעדים

—שיא מהירות

—זמן מנוע

—בוהק→הגעה (הטוב)

—בוהק→הגעה (גרוע)

—

תקציב לולאה שיתופית

loop() קורא handleClient() ואז stepper.run(). AccelStepper חייב לרוץ לפני מועד הצעד הבא. אין esp_task_wdt בקושחה. תקיעת I²C יכולה להרעיב גם פולסים וגם את ה־WDT של הליבה.

handleClient (ms): 8

קריאת I²C (ms): 2

—מרווח צעד בשיא

—slack

—פולסים

—WDT 5s (לא מחומש)

—

חסימת WiFi ב-setup

עד 10 שניות של delay(200) לפני loop(). המנוע לא רץ. אחרי timeout האוטו המקומי ממשיך — זה בקושחה, ונבדק.

חיבור אחרי (ms, 10000 = timeout): 10000

—setup חסום

—איטרציות delay(200)

—

לולאת בקרה

גנט של loop() אחד

handleClient כל איטרציה. I²C + החוק רק כל 2 שניות. calcOptimalAngle הוא עשרות µs — העיגול ליד HTTP.

הלולאה הזו דוגמת חיישנים

—עסוק בלולאה

—עד הדגימה הבאה

שרשרת השהיה + הבזק שמתפספס

פאזת דגימה (1 = מגיע עכשיו): 0 משך הבזק שמש (ms): 400

—בוהק → הגעה

—P(פספוס הבזק)

—צוואר בקבוק

—המתנה לדגימה

—

תקציב הספק

סלילים מול לוגיקה — לא מדידה

החזקת מנוע: 2 × I²R ל־1.5 A ו־1.5 Ω — רצפה מדף-נתונים, בלי הפסדי מנהל. ESP32 + WiFi ≈ 180 mA @ 3.3 V. USB 5 V / 500 mA = 2.5 W — מתחת להחזקה.

יום עבודה

הטיות ביום: 24 נעילה עצמית / כיבוי סלילים ב-idle WiFi דלוק תמיד (כמו הקושחה)

—החזקת סלילים

—לוגיקה (ESP32+חיישנים)

—אנרגיה ל־24 שעות

—USB 5V/500mA

—

כיבוי סלילים בלי תולעת חוסך ואטים ומשחרר את המסך — ראו מחשבון המומנט. פירוט זרם וסוללה: תקציב הספק. אנרגיה זולה ≠ בטיחות.