כיצד לבדוק שגיאה 130 ב-MT4 EA? שיטה בת ארבעה שלבים ממרחק סטופ-לוס ועד מגבלות דינמיות
באמצעות תרשים זרימה מקורי בצבע תכלת, בדיקה שלב אחר שלב של ERR_INVALID_STOPS ב-MT4 EA: יומנים, דיוק מחירים, MODE_STOPLEVEL ומגבלות דינמיות, כדי להימנע מהרחבת סטופ-לוס שמסתירה סיכון.
מחבר: תומאס｜פרקטיקה של EA ו-MT4｜20 באוקטובר 2026
כאשר EA כבר מוצמד לגרף ומסחר אוטומטי מופעל, אך בעת שליחת הזמנה מופיע "130", הדבר בדרך כלל גורם לחשוב שהתוכנית מקולקלת לחלוטין. תיעוד ההפניה של MQL4 מפרט את 130 כ-ERR_INVALID_STOPS: סטופ-לוס וטייק-פרופיט בבקשה, מחיר הזמנת לימיט או אופן הנרמול שלהם לא התקבלו על ידי שרת המסחר. זהו רמז לאיתור, ולא סיבה להרשות הרחבת סטופ-לוס באופן עיוור. מאמר זה מסביר בשיטת ארבעה שלבים אילו רשומות יש לבדוק.
שלב ראשון: לקבוע תחילה איזו בקשה נכשלה
פתחו את היומן הרלוונטי במסוף MT4 או ביומן התוכנית, ורשמו את זמן השרת של השגיאה, הסימבול, כיוון ההזמנה, האם הפעולה הייתה OrderSend או OrderModify, ואת קוד השגיאה שהוחזר. אם ביומן מופיע רק "שליחת הזמנה נכשלה", תחילה יש לגרום ל-EA לרשום את מחיר הבקשה, סטופ-לוס, טייק-פרופיט וערך ההחזרה, מבלי להפיק נתונים רגישים כגון סיסמאות. יש להבחין תחילה בין כשל בפתיחת פוזיציה, כשל בשינוי סטופ-לוס וכשל בהזמנת לימיט; היחסים בין המחירים שנבדקים שונים בשלושת המקרים.
אין "לנסות מזל" בחשבון בזמן אמת על ידי שליחה חוזרת של אותה בקשה שנכשלה. ניסיונות חוזרים עלולים ליצור עומס נוסף, ואף להצליח לפתע לאחר שינוי בתנאי השוק ולגרום לפוזיציה בלתי צפויה. יש לשחזר תחילה בסביבת דמו, ולשמור את גרסת הפרמטרים ואת המחירים שהפלטפורמה הציגה באותו זמן.
שלב שני: לבדוק Bid, Ask, Point ו-Digits
MarketInfo של MQL4 יכול לקרוא את Bid, Ask, Point ו-Digits של הסימבול הנוכחי. Point מייצג אחת מיחידות התצוגה המינימליות של המחיר, ו-Digits מציין את מספר הספרות העשרוניות; יש לחשב כמה דולרים הם "10 נקודות" לפי ה-Point בפועל של אותו סימבול, ואסור לערבב בין קודי זהב ודיוק של ברוקרים שונים. לפני העברת המחיר יש גם לנרמל אותו לפי מספר הספרות המתאים.
הדוגמה היא להמחשה מתמטית בלבד: אם בסימבול דמו מסוים ה-Point הוא 0.01 והמרחק המינימלי הוא 50 נקודות, המרחק המחושב הוא 0.50 יחידות מחיר; בסימבול שבו ה-Point הוא 0.001 המרחק יהיה 0.05. המספרים אינם מייצגים כללי חוזה אמיתיים של פלטפורמה כלשהי היום. בעת בדיקת היומן יש לשמור גם את מחירי הקנייה והמכירה, כדי להימנע מבדיקת צד שאמור להתייחס למחיר הקנייה באמצעות מחיר המכירה, או להפך.
שלב שלישי: לבדוק MODE_STOPLEVEL וסוג ההזמנה
תיעוד OrderSend הרשמי מסביר שסטופ-לוס וטייק-פרופיט אינם יכולים להיות קרובים מדי למחיר השוק; גם מחיר הפתיחה המיועד של הזמנת לימיט אינו יכול להיות קרוב מדי לשוק הנוכחי. ניתן לשאול את המרחק המינימלי הפומבי באמצעות MarketInfo(Symbol(),MODE_STOPLEVEL), ביחידות point. לאחר מכן, בהתאם לכך שההזמנה היא קנייה, מכירה או סוג מסוים של הזמנת לימיט, יש לבדוק בנפרד את כיוון המחיר, המרחק והנרמול, ולא להחיל היסט קבוע על כל ההזמנות.
התמונה לעיל היא תרשים זרימה מקורי להמחשה, ללא מחירים או פרטי חשבון אמיתיים. המרחק המינימלי הוא רק הגבול הטכני שבו השרת מקבל הזמנה, ואינו שווה למרחק סטופ-לוס סביר מבחינה אסטרטגית. אם מרחיקים את הסטופ-לוס כדי לעקוף את 130, הסיכון המתוכנן לעסקה בודדת יגדל; יש לחשב מחדש את גודל הפוזיציה, ובמידת הצורך לוותר על העסקה.
שלב רביעי: גם החזרה של 0 אינה מוכיחה שאין מגבלה
התיעוד הרשמי של MQL4 לגבי MODE_STOPLEVEL מדגיש במיוחד: החזרה של 0 עשויה לומר שאין מרחק מינימלי קבוע, או שהשרת מיישם מגבלה דינמית שהמסוף אינו יכול להציג ישירות. במקרה האחרון עדיין עשויה לחזור שגיאה 130. לכן "מצאתי 0 ולכן מצמידים את הסטופ-לוס למחיר" אינה מסקנה תקפה. בעת תנודות חדות בשוק, עדכוני מחירים, שינויי ספרד וכללי השרת עלולים גם הם לבטל מרחק שחושב קודם לכן.
אם חישוב הקוד תואם את היומן באותו זמן ובכל זאת מופיעה שגיאה 130, יש לשמור את זמן הכשל, הסימבול, פרמטרי ההזמנה וגרסת הפלטפורמה, לבדוק את מפרטי הסימבול ומגבלות ההזמנה של הברוקר, ולאמת מול התמיכה הטכנית של הפלטפורמה. אין להסיק את כללי החשבון הזה מ-Point ו-StopLevel של פלטפורמה אחרת, ובוודאי שאין להסתיר את הסיבה האמיתית לכשל על ידי מחיקת סטופ-לוס.
סדר האימות לאחר התיקון
תחילה יש להריץ בחשבון דמו מקרה מינימלי שניתן לשחזר: לרשום באותו סימבול את ארבעת פרמטרי המחיר ואת StopLevel, לשלוח בקשת בדיקה בודדת, ולבדוק את תגובת השרת ואת מצב ההזמנה. לאחר מכן יש לבדוק את ההתנהגות בעת שינוי מהיר של מחירים או בשעות מסחר שונות. יש לוודא שלתוכנית יש מנגנון עצירה או צינון לאחר כשל, ושהיא אינה פותחת פוזיציה כפולה בניסיון חוזר. לבסוף יש לבדוק אם תקציב הסיכון, הספרד וההפסד המקובל עדיין תואמים את התוכנית המקורית.
מוקד הבדיקה של שגיאה 130 הוא "מדוע הבקשה נדחתה", ולא "כיצד לכפות שהיא תתבצע". תוצאות ההרצה של EA מושפעות גם מהיגיון האסטרטגיה, מהרשת ומביצוע הפלטפורמה; כל תיקון אינו מבטיח רווח או מונע הפסד. מסחר במינוף עלול לגרום להפסדים משמעותיים.
