چرا ربات معامله می‌بندد ولی باز نمی‌کند

یکی از ابهام‌های رایج در کار با ربات معامله‌گر (Trading Robot) این است که اکسپرت معامله‌های موجود را به‌درستی می‌بندد، اما پس از بسته‌شدن آن‌ها هیچ معامله جدیدی باز نمی‌کند. این رفتار در نگاه اول متناقض به نظر می‌رسد؛ زیرا بسته‌شدن موفق معامله نشان می‌دهد که ربات به بازار متصل است، سفارش‌ها را می‌شناسد و دست‌کم بخشی از منطق اجرایی آن درست کار می‌کند. با این حال، منطق بستن و منطق بازکردن معامله معمولا دو مسیر کاملا جداگانه در برنامه هستند و موفقیت یکی، صحت دیگری را تضمین نمی‌کند.

در متاتریدر (MetaTrader)، چه در محیط MQL4 و چه در MQL5، ربات ممکن است برای خروج از معامله تنها به یک شرط ساده مانند رسیدن قیمت به حد سود، حد ضرر یا سیگنال معکوس نیاز داشته باشد، اما برای ورود جدید مجموعه‌ای از شرایط هم‌زمان را بررسی کند. فیلتر روند، وضعیت اندیکاتورها، فاصله قیمت از سطوح، اسپرد، ساعت معاملاتی، تعداد معاملات باز، حجم مجاز، مارجین آزاد و وضعیت نماد همگی می‌توانند در مسیر ورود قرار بگیرند. کافی است یکی از این شرط‌ها برقرار نباشد تا سفارش جدید ارسال نشود؛ حتی اگر بخش مدیریت معاملات بدون خطا عمل کند.

بنابراین عبارت «ربات معامله را می‌بندد ولی باز نمی‌کند» به‌تنهایی یک خطای مشخص را توصیف نمی‌کند. این وضعیت می‌تواند ناشی از طراحی عمدی استراتژی، سخت‌گیری بیش از حد فیلترها، محدودیت‌های بروکر، خطای محاسباتی، ناسازگاری حساب یا یک اشکال واقعی در کد باشد. تشخیص درست زمانی ممکن است که فرآیند تولید سیگنال، اعتبارسنجی شرایط ورود، ارسال درخواست معامله و پاسخ سرور به‌صورت جداگانه بررسی شود.

تفاوت اساسی منطق خروج و ورود

در بسیاری از اکسپرت‌ها، منطق خروج با داده‌های مستقیم و قابل پیش‌بینی اجرا می‌شود. برای مثال، اگر قیمت فعلی به حد سود برسد، ربات فقط باید شناسه معامله را پیدا کند و درخواست بستن آن را ارسال کند. در مقابل، منطق ورود ممکن است به ترکیبی از ده‌ها شرط وابسته باشد. به همین دلیل، ممکن است ربات در هر تیک قیمت وضعیت معامله موجود را مدیریت کند، اما ساخت سیگنال جدید را فقط در شرایط بسیار محدود انجام دهد.

یک اشتباه رایج این است که برنامه‌نویس تصور می‌کند چون تابع مدیریت پوزیشن اجرا شده، تابع ورود نیز باید در همان چرخه اجرا شود. در کدهای MQL4، تابع‌هایی مانند بررسی معاملات باز، انتخاب سفارش و بستن معامله ممکن است مستقل از بخش تولید سیگنال باشند. در MQL5 نیز مدیریت پوزیشن از ارسال درخواست جدید با ساختارهای معاملاتی جداست. اگر شرطی مانند وجود معامله با مجیک نامبر مشخص برقرار باشد، ممکن است بخش ورود عمدا متوقف شود؛ اما بخش خروج همچنان فعال بماند.

سناریوی متداول دیگر زمانی رخ می‌دهد که ربات پس از بسته‌شدن معامله، هنوز وضعیت قبلی را در متغیری مانند وضعیت پوزیشن نگه می‌دارد. در این حالت، سیستم داخلی اکسپرت تصور می‌کند معامله‌ای همچنان فعال است و از ورود دوباره جلوگیری می‌کند. این مشکل در مدیریت وضعیت پوزیشن (Position State Management) به‌خصوص زمانی دیده می‌شود که معامله به‌وسیله حد سود یا حد ضرر بسته شده باشد و کد فقط در صورت بسته‌شدن دستی وضعیت را به حالت بدون معامله برگرداند.

همچنین باید مشخص شود استراتژی اساسا اجازه ورود فوری پس از خروج را می‌دهد یا خیر. بعضی ربات‌ها پس از بسته‌شدن معامله تا تشکیل کندل جدید، پایان یک دوره زمانی یا وقوع سیگنال مستقل بعدی صبر می‌کنند. در چنین شرایطی، نداشتن معامله بلافاصله پس از خروج نشانه خرابی نیست، بلکه بخشی از طراحی استراتژی است.

خطاهای رایج در منطق ورود

مهم‌ترین علت بازنشدن معامله، معمولا در خود منطق ورود (Entry Logic) قرار دارد. برنامه ممکن است بدون آنکه خطایی در متاتریدر ثبت شود، به این نتیجه برسد که شرایط ورود برقرار نیست. برای نمونه، استراتژی می‌تواند تنها زمانی خرید کند که میانگین متحرک کوتاه‌مدت بالاتر از میانگین بلندمدت باشد، شاخص قدرت نسبی در محدوده مشخص قرار گیرد، قیمت بالای یک سطح قرار داشته باشد و کندل قبلی صعودی بسته شده باشد. اگر فقط یکی از این وضعیت‌ها تغییر کند، سفارش ارسال نخواهد شد.

اشتباه در استفاده از کندل جاری نیز بسیار رایج است. مقدار اندیکاتور روی کندلی که هنوز در حال شکل‌گیری است با مقدار همان اندیکاتور روی کندل بسته‌شده تفاوت دارد. ممکن است در زمان بررسی اولیه سیگنال ایجاد شود، اما چند ثانیه بعد از بین برود. اگر ربات فقط در شروع کندل سیگنال را بررسی کند و داده مربوط به اندیس اشتباه را بخواند، ممکن است هیچ‌گاه شرایط ورود را معتبر تشخیص ندهد. در مقابل، بخش خروج که با قیمت لحظه‌ای کار می‌کند، همچنان فعال باقی می‌ماند.

تبدیل نادرست قیمت به مقدار اندیکاتور نیز می‌تواند همین نتیجه را ایجاد کند. در MQL4/MQL5 باید مشخص باشد که مقدار اندیکاتور مربوط به کدام نماد، تایم‌فریم و شیفت زمانی دریافت شده است. اگر ربات روی نمودار پنج‌دقیقه‌ای نصب شده باشد اما داده اندیکاتور را از تایم‌فریم یک‌ساعته بخواند، تأخیر در تشکیل داده یا نبودن تعداد کافی کندل می‌تواند شرط ورود را برای مدت طولانی غیرفعال کند.

اشتباه در جهت معامله نیز باید بررسی شود. ممکن است کد سیگنال خرید تولید کند، اما در مرحله ارسال سفارش حجم، قیمت یا حد ضرر مربوط به فروش استفاده شود. گاهی هم متغیر سیگنال پس از پردازش یک بار، پاک نمی‌شود و در چرخه بعدی با وضعیت نامعتبر وارد می‌شود. چنین خطاهایی اغلب در تست‌های محدود دیده نمی‌شوند و تنها پس از بسته‌شدن معامله در شرایط واقعی خود را نشان می‌دهند.

فیلترهای بیش از حد سخت‌گیرانه

ترکیب چند فیلتر معاملاتی (Trading Filter) می‌تواند استراتژی را از نظر تئوری دقیق‌تر، اما در عمل تقریبا غیرفعال کند. برای مثال، اکسپرت ممکن است ورود را زمانی مجاز بداند که روند در تایم‌فریم روزانه صعودی، روند چهار ساعته صعودی، میانگین‌های متحرک هم‌جهت، نوسان‌سنج در محدوده خاص، اسپرد کمتر از مقدار تعیین‌شده و ساعت نیز در بازه مجاز باشد. احتمال رخ‌دادن هم‌زمان همه این شرایط ممکن است بسیار کم باشد.

مشکل زمانی جدی‌تر می‌شود که هر فیلتر بدون ثبت دلیل ردشدن سیگنال اجرا شود. در این حالت، معامله‌گر فقط می‌بیند که معامله بسته شده و معامله بعدی باز نمی‌شود، اما نمی‌داند کدام شرط مانع ورود بوده است. راهکار مناسب این است که هر فیلتر نتیجه خود را به شکل قابل مشاهده ثبت کند؛ برای نمونه مشخص شود «سیگنال خرید ایجاد شد، اما به‌دلیل اسپرد بالا رد شد» یا «روند تایم‌فریم بالاتر تأیید نشد».

باید تفاوت میان فیلتر ضروری و فیلتر محافظتی نیز روشن باشد. فیلترهایی مانند بررسی مارجین، معتبر بودن حجم و فعال‌بودن نماد معمولا برای جلوگیری از خطای عملیاتی لازم هستند. اما فیلترهایی که بر اساس چند آستانه نزدیک به هم طراحی شده‌اند، ممکن است بیش از اندازه فرصت‌های ورود را حذف کنند. آزمایش هر فیلتر به‌صورت جداگانه روی داده تاریخی و سپس بررسی نرخ حذف سیگنال‌ها می‌تواند نشان دهد کدام شرط عملا بیشترین محدودیت را ایجاد می‌کند.

تایم‌فریم و نماد معاملاتی

یکی از دلایل مهم خطای باز نشدن معامله (Trade Not Opening Error)، ناسازگاری میان نماد و تایم‌فریمی است که ربات برای آن طراحی شده است. ممکن است اکسپرت روی نمودار یک نماد نصب شده باشد اما در کد، داده‌ها یا سفارش‌ها برای نماد دیگری بررسی شوند. در این صورت ربات شاید معاملات قبلی را که با مجیک نامبر یا نماد مشخص پیدا می‌کند ببندد، اما سیگنال ورود را از داده‌ای دریافت کند که به‌روز نیست یا اصلا وجود ندارد.

در برخی حساب‌ها نام نماد شامل پسوند یا پیشوند است؛ برای مثال نماد طلا یا جفت‌ارز ممکن است با پسوندهایی مانند پسوند مخصوص نوع حساب نمایش داده شود. اگر کد نام ثابت یک نماد را در درخواست معامله قرار دهد، ممکن است اطلاعات قیمت از یک نماد خوانده شود و سفارش برای نمادی ارسال شود که در حساب وجود ندارد یا قابل معامله نیست. استفاده از نماد جاری نمودار و بررسی ویژگی‌های آن، به‌خصوص در MQL5، از بروز این ناسازگاری جلوگیری می‌کند.

تایم‌فریم نیز باید در تمام اجزای ربات یکسان و آگاهانه استفاده شود. اگر منطق ورود بر اساس بسته‌شدن کندل یک‌ساعته باشد اما تابع بررسی سیگنال در هر تیک نمودار یک‌دقیقه‌ای اجرا شود، ممکن است وضعیت سیگنال بارها تغییر کند یا به‌علت کنترل نادرست زمان کندل اصلا اجرا نشود. کنترل زمان تشکیل کندل جدید، تعداد کندل‌های در دسترس و همگام‌بودن تاریخچه قیمت از بررسی‌های ضروری است.

محدودیت اسپرد و کیفیت قیمت

بسیاری از ربات‌ها برای جلوگیری از ورود در شرایط نامناسب، محدودیت اسپرد (Spread Limit) دارند. این محدودیت معمولا با مقایسه اختلاف قیمت خرید و فروش با مقدار مجاز اعمال می‌شود. در بازارهای کم‌نقدشونده، هنگام انتشار خبر یا در زمان بازگشایی بازار، اسپرد ممکن است برای مدت کوتاهی افزایش یابد. اگر ربات در همین زمان معامله قبلی را ببندد، اما برای ورود جدید شرط اسپرد را رد کند، رفتار مشاهده‌شده کاملا طبیعی است.

خطای محاسبه اسپرد نیز رایج است. در نمادهای پنج‌رقمی یا سه‌رقمی، تفاوت میان پوینت و پیپ می‌تواند باعث شود مقدار تعیین‌شده بسیار سخت‌گیرانه‌تر از تصور برنامه‌نویس باشد. در MQL4 و MQL5 باید مشخص شود مقدار اسپرد برحسب پوینت، پیپ یا واحد پولی محاسبه شده است. همچنین قیمت خرید و فروش باید از داده‌های جاری و معتبر گرفته شوند؛ استفاده از قیمت قدیمی می‌تواند هم شرط اسپرد و هم اعتبار قیمت سفارش را مختل کند.

گاهی محدودیت اسپرد پس از بسته‌شدن معامله در یک متغیر ذخیره می‌شود و تا اجرای دوباره اکسپرت تغییر نمی‌کند. اگر چنین وضعیتی وجود داشته باشد، ربات حتی پس از عادی‌شدن بازار نیز معامله‌ای باز نمی‌کند. ثبت مقدار اسپرد در هر زمان ردشدن سیگنال، تشخیص این مشکل را ساده می‌کند.

حجم معامله و لات نامعتبر

حتی اگر سیگنال ورود کاملا معتبر باشد، حجم معامله (Trade Volume) ممکن است اجازه ارسال سفارش را ندهد. بروکر برای هر نماد حداقل حجم، حداکثر حجم و گام تغییر حجم تعیین می‌کند. اگر ربات حجمی مانند ۰٫۰۳ را محاسبه کند اما گام مجاز نماد ۰٫۰۱ باشد، سفارش معتبر است؛ اما اگر حجم حاصل ۰٫۰۳۵ باشد، باید بر اساس گام مجاز گرد شود. در غیر این صورت سرور درخواست را رد می‌کند.

محاسبه حجم بر اساس درصد ریسک نیز به مشخصات نماد وابسته است. ارزش هر پوینت، اندازه قرارداد، ارز حساب و فاصله حد ضرر باید در محاسبه لحاظ شوند. فرمولی که برای جفت‌ارز مناسب است ممکن است برای طلا، شاخص یا ارز دیجیتال نتیجه نادرست ایجاد کند. در نتیجه حجم نهایی می‌تواند کمتر از حداقل مجاز، بیشتر از حداکثر مجاز یا از نظر گام معاملاتی نامعتبر باشد.

در MQL5 علاوه بر حجم، باید نوع اجرای سفارش، نوع پرشدن و حالت مجاز معاملات نماد بررسی شود. ممکن است ربات حجم درست محاسبه کند، اما نوع پرشدن انتخاب‌شده توسط بروکر پشتیبانی نشود. بهتر است پیش از ارسال درخواست، ویژگی‌های نماد و حجم نهایی در لاگ ثبت شوند و مقدار محاسبه‌شده با حداقل، حداکثر و گام حجم مقایسه شود.

محدودیت مارجین و قدرت خرید

مارجین آزاد (Free Margin) پس از هر معامله، بسته به حجم و نتیجه معامله تغییر می‌کند. ممکن است ربات معامله قبلی را ببندد، اما در همان لحظه هنوز مارجین آزاد برای سفارش بعدی کافی نباشد؛ به‌خصوص وقتی چند معامله دیگر روی حساب باز هستند یا بسته‌شدن معامله قبلی با زیان انجام شده است. در حساب‌های اهرمی، تفاوت میان مارجین موردنیاز و مارجین آزاد باید به‌صورت دقیق بررسی شود.

برخی ربات‌ها تنها موجودی حساب را کنترل می‌کنند و مارجین آزاد را در نظر نمی‌گیرند. این روش می‌تواند باعث شود سفارش از دید برنامه مجاز باشد، اما سرور بروکر آن را به‌علت کمبود منابع رد کند. در استراتژی‌هایی که حد ضرر بزرگ یا حجم پویا دارند، این خطا بیشتر رخ می‌دهد. در عیب‌یابی باید مقدار مارجین آزاد، مارجین موردنیاز برای نماد و حجم مورد نظر پیش از ارسال درخواست ثبت شود.

همچنین اگر ربات پس از بسته‌شدن معامله بلافاصله سفارش جدید بفرستد، ممکن است حساب یا سرور هنوز وضعیت قبلی را به‌طور کامل به‌روزرسانی نکرده باشد. این موضوع در شرایط تأخیر شبکه یا اجرای کند بروکر اهمیت بیشتری دارد. استفاده از تأیید وضعیت معامله و مدیریت پاسخ سرور، به جای فرض‌کردن موفقیت فوری، ضروری است.

ساعات مجاز معامله و محدودیت‌های زمانی

بخش قابل توجهی از اکسپرت‌ها دارای ساعات مجاز معامله (Trading Session) هستند. این ساعت‌ها معمولا بر اساس زمان سرور بروکر تنظیم می‌شوند، نه ساعت محلی رایانه معامله‌گر. تغییر ساعت تابستانی، تفاوت منطقه زمانی و تغییر زمان سرور در طول سال می‌تواند باعث شود ربات تصور کند خارج از ساعت مجاز قرار دارد.

ممکن است معامله قبلی در پایان جلسه معاملاتی بسته شود و پس از آن ورود جدید تا شروع جلسه بعدی ممنوع باشد. اگر منطق خروج مستقل از فیلتر ساعت باشد، ربات معامله را می‌بندد اما بخش ورود به‌درستی متوقف می‌شود. این رفتار زمانی گمراه‌کننده است که ساعت مجاز در تنظیمات یا لاگ‌ها نمایش داده نشود.

محدودیت‌های زمانی باید با دقت روی بازه‌های عبوری از نیمه‌شب نیز پیاده‌سازی شوند. برای مثال، بازه معاملاتی از ساعت ۲۲ تا ۲ بامداد را نمی‌توان با مقایسه ساده بزرگ‌تر و کوچک‌تر بررسی کرد. خطای منطقی در این بخش ممکن است تمام ساعات را غیرمجاز تشخیص دهد. ثبت زمان سرور، ساعت استخراج‌شده از آن و نتیجه شرط، راه مناسبی برای شناسایی مشکل است.

تداخل بین اکسپرت‌ها و مجیک نامبر

وقتی چند اکسپرت (Expert Advisor) روی یک حساب یا یک نماد فعال هستند، هرکدام باید معاملات خود را با مجیک نامبر (Magic Number) و در صورت نیاز با نماد و کامنت مشخص شناسایی کند. اگر دو ربات از مجیک نامبر یکسان استفاده کنند، یکی ممکن است معامله دیگری را ببندد یا تصور کند معامله‌ای متعلق به خودش باز است. در چنین شرایطی، بخش خروج ظاهرا کار می‌کند، اما منطق ورود به دلیل وجود معامله «فعال» متوقف می‌شود.

تداخل تنها به اکسپرت‌ها محدود نیست. معاملات دستی، ربات‌های مدیریت سرمایه، کپی‌تریدینگ و اسکریپت‌های مدیریت سفارش نیز می‌توانند تعداد معاملات یا حجم موجود را تغییر دهند. اگر ربات شرطی مانند «حداکثر یک معامله برای این نماد» داشته باشد اما معاملات سایر سیستم‌ها را هم بشمارد، ورودهای خود را مسدود خواهد کرد.

در حساب‌های هجینگ، تشخیص معامله باید بر اساس تیکت یا شناسه دقیق پوزیشن انجام شود. در حساب‌های نتینگ، چند معامله روی یک نماد در یک پوزیشن تجمیع می‌شوند و مفهوم «یک معامله متعلق به ربات» با حساب هجینگ یکسان نیست. طراحی نادرست این منطق می‌تواند باعث شود ربات پس از بستن بخشی از حجم، هنوز پوزیشن را باز تلقی کند.

مجوز AutoTrading و دسترسی‌های اجرایی

خاموش‌بودن AutoTrading یا غیرفعال‌بودن مجوز معامله برای اکسپرت، یکی از ساده‌ترین دلایل بازنشدن سفارش است. در برخی شرایط، ربات هنوز می‌تواند اطلاعات بازار را بخواند و حتی وضعیت معاملات را نمایش دهد، اما اجازه ارسال معامله جدید ندارد. بسته‌شدن معامله‌ای که از قبل توسط حد سود یا حد ضرر انجام شده نیز ممکن است این تصور را ایجاد کند که ربات همچنان دسترسی کامل دارد.

در تنظیمات متاتریدر باید مجوز کلی معاملات خودکار، مجوز معامله برای همان اکسپرت و دسترسی‌های لازم در تنظیمات آن بررسی شود. در MQL5 تفاوت میان مجازبودن اجرای اکسپرت و مجازبودن معامله‌کردن اهمیت دارد. همچنین حساب یا نماد ممکن است به‌طور موقت در حالت فقط‌بستن قرار گرفته باشد؛ در این وضعیت بستن معاملات مجاز است اما بازکردن معامله جدید رد می‌شود.

بررسی وضعیت ترمینال، پیام‌های تب Experts و Journal و همچنین وضعیت معاملاتی نماد باید هم‌زمان انجام شود. اتکا به ظاهر فعال‌بودن ربات روی نمودار کافی نیست.

تفاوت حساب دمو و ریل

ممکن است اکسپرت در حساب دمو بدون مشکل معامله باز کند اما در حساب واقعی این کار را انجام ندهد. تفاوت حساب دمو و ریل (Demo and Live Account) فقط موجودی نیست. نوع اجرای سفارش، اسپرد، حداقل حجم، قوانین مارجین، محدودیت تعداد سفارش‌ها، سرعت پاسخ سرور و ساعت معاملاتی می‌تواند متفاوت باشد.

در حساب واقعی، بروکر ممکن است برای برخی نمادها حداقل فاصله مجاز از قیمت جاری را بیشتر تعیین کند. در نتیجه حد ضرر یا حد سودی که در دمو پذیرفته می‌شود، در حساب ریل رد خواهد شد. همچنین ممکن است اجرای سفارش به‌صورت بازار انجام شود و قیمت درخواستی ربات قابل قبول نباشد. در این حالت، معامله بسته‌شده قبلی لزوما دلیلی برای پذیرفته‌شدن سفارش جدید نیست.

آزمایش در حساب دمو باید با مشخصات نزدیک به حساب واقعی انجام شود. اگر نماد، نوع حساب، اهرم و قوانین اجرای سفارش متفاوت باشند، نتیجه آزمایش قابل تعمیم نخواهد بود.

خطاهای بروکر و درخواست معامله

در MQL4 تابع ارسال سفارش و در MQL5 ساختار درخواست معامله، پاسخ مشخصی از سرور دریافت می‌کنند. اگر این پاسخ بررسی نشود، ربات ممکن است شکست ارسال سفارش را پنهان کند. عبارت‌هایی مانند خطای قیمت نامعتبر، حجم نامعتبر، بازار بسته، مارجین ناکافی، توقف بیش از حد نزدیک، نماد غیرفعال یا ردشدن سفارش باید به شکل عدد و توضیح قابل فهم ثبت شوند.

در MQL4، پس از شکست تابع ارسال یا بستن سفارش، مقدار خطا باید بلافاصله خوانده شود؛ زیرا اجرای تابع دیگری ممکن است مقدار خطای قبلی را تغییر دهد. در MQL5 نیز تنها بررسی موفقیت ارسال درخواست کافی نیست و باید نتیجه نهایی معامله، کد بازگشتی و توضیح سرور بررسی شود. ممکن است درخواست از نظر ساختاری پذیرفته شود اما معامله در مرحله پردازش رد شود.

سناریوی رایج این است که ربات ابتدا قیمت، حد ضرر و حد سود را محاسبه می‌کند، اما در چند تیک بعد قیمت تغییر می‌کند و فاصله حد ضرر دیگر با حداقل فاصله مجاز بروکر سازگار نیست. سفارش رد می‌شود و چون کد دوباره تلاش نمی‌کند، معامله‌ای باز نمی‌شود. راهکار، دریافت قیمت تازه، نرمال‌سازی اعداد بر اساس تعداد رقم نماد و کنترل حداقل فاصله مجاز پیش از ارسال است.

تفاوت حساب‌های Netting و Hedging

در حساب هجینگ (Hedging Account) امکان وجود چند پوزیشن مستقل روی یک نماد وجود دارد. در حساب نتینگ (Netting Account) همه معاملات یک نماد در یک پوزیشن تجمیع می‌شوند. اگر ربات با منطق حساب هجینگ روی حساب نتینگ اجرا شود، ممکن است تیکت یا وضعیت پوزیشن را اشتباه تفسیر کند و ورود جدید را ممنوع بداند.

برای مثال، در حساب نتینگ ارسال سفارش خرید جدید ممکن است حجم پوزیشن موجود را افزایش دهد، نه اینکه یک معامله مستقل ایجاد کند. اگر برنامه به دنبال یک پوزیشن جدید با شناسه جداگانه باشد، نتیجه را اشتباه ارزیابی می‌کند. در حساب هجینگ نیز بستن یک پوزیشن خاص با بستن حجم کلی نماد تفاوت دارد. منطق شمارش معاملات، انتخاب پوزیشن و تشخیص مالکیت سفارش باید مطابق نوع حساب طراحی شود.

اندیکاتورها و سیگنالی که هرگز کامل نمی‌شود

گاهی مشکل از این نیست که ربات سیگنال را اشتباه می‌خواند؛ بلکه شرط اندیکاتوری عملا هیچ‌وقت کامل نمی‌شود. خطای علامت در مقایسه، استفاده از آستانه ناممکن یا ترکیب شرط‌هایی که با یکدیگر ناسازگارند، نمونه‌هایی از این وضعیت هستند. برای مثال، کد ممکن است هم‌زمان از اندیکاتور بخواهد بالاتر از یک مقدار و پایین‌تر از مقدار دیگری باشد، در حالی که این دو بازه هم‌پوشانی ندارند.

نبودن تاریخچه کافی نیز مهم است. میانگین متحرک با دوره طولانی، اندیکاتورهای چندتایم‌فریمی و داده‌های نمادی که تازه در بازار فعال شده‌اند، به تعداد مشخصی کندل نیاز دارند. اگر داده کافی وجود نداشته باشد، مقدار اندیکاتور ممکن است صفر، خالی یا نامعتبر باشد. ربات باید پیش از ارزیابی سیگنال، آماده‌بودن داده و معتبر‌بودن خروجی اندیکاتور را بررسی کند.

روش عیب‌یابی با لاگ‌گیری

بهترین روش تشخیص، تبدیل مسیر ورود به چند مرحله قابل مشاهده است. در هر چرخه مشخص کنید آیا کندل جدید شناسایی شده، داده قیمت معتبر است، سیگنال خام ایجاد شده، فیلترهای روند و اندیکاتور تأیید شده‌اند، ساعت و اسپرد مجاز هستند، حجم اعتبار دارد، مارجین کافی است و درخواست معامله با چه پاسخی مواجه شده است.

لاگ‌گیری باید اطلاعات کافی اما کنترل‌شده داشته باشد. ثبت همه تیک‌ها می‌تواند فایل گزارش را غیرقابل استفاده کند؛ بهتر است پیام‌های مهم فقط هنگام تغییر وضعیت، تشکیل کندل جدید یا ردشدن سیگنال ثبت شوند. برای نمونه، به جای ثبت مداوم قیمت، می‌توان نوشت: «سیگنال خرید ایجاد شد؛ ورود رد شد؛ اسپرد ۳۲ پوینت و سقف مجاز ۲۰ پوینت». چنین پیامی مستقیما علت را مشخص می‌کند.

در متاتریدر، تب‌های Experts و Journal را هم‌زمان با گزارش داخلی اکسپرت بررسی کنید. زمان وقوع خطا، نماد، تایم‌فریم، نوع حساب، حجم، قیمت درخواست، حد ضرر، حد سود، مارجین آزاد و کد پاسخ سرور باید قابل ردیابی باشند. اگر در MQL5 از درخواست معامله استفاده می‌شود، تمام فیلدهای اصلی درخواست و نتیجه برگشتی باید ثبت شوند.

عیب‌یابی را مرحله‌ای انجام دهید. ابتدا بررسی کنید آیا سیگنال خام تولید می‌شود. اگر خیر، مسئله در داده یا منطق ورود است. اگر سیگنال وجود دارد اما درخواست ارسال نمی‌شود، یکی از فیلترها یا کنترل‌های پیش از ارسال مانع شده است. اگر درخواست ارسال می‌شود اما پذیرفته نمی‌شود، باید پاسخ بروکر، مشخصات نماد، حجم، قیمت، مارجین و محدودیت‌های اجرایی بررسی شوند.

راهکارهای اصلاح و مقاوم‌سازی ربات

برای اصلاح ربات، ابتدا منطق ورود و خروج را از یکدیگر جدا و وضعیت هرکدام را شفاف کنید. پس از بسته‌شدن معامله، وضعیت داخلی باید بر اساس وضعیت واقعی حساب به‌روزرسانی شود، نه فقط بر اساس اینکه کدام تابع در کد اجرا شده است. بررسی مجدد معاملات در هر کندل یا پس از دریافت رویداد معاملاتی می‌تواند از باقی‌ماندن وضعیت قدیمی جلوگیری کند.

تمام مقادیر وابسته به نماد باید از مشخصات همان نماد دریافت شوند. حداقل و حداکثر حجم، گام حجم، تعداد رقم اعشار، اندازه تیک، ارزش تیک، حداقل فاصله سفارش و نوع پرشدن را نباید به‌صورت ثابت و عمومی در کد فرض کرد. این موضوع برای اکسپرت‌هایی که روی چند نماد اجرا می‌شوند اهمیت حیاتی دارد.

فیلترهای ورود را به‌صورت مستقل قابل فعال و غیرفعال‌کردن طراحی کنید تا اثر هرکدام روی تعداد سیگنال‌ها قابل اندازه‌گیری باشد. در محیط آزمایشی، تعداد سیگنال خام، تعداد سیگنال‌های حذف‌شده توسط هر فیلتر و تعداد سفارش‌های پذیرفته‌شده را مقایسه کنید. این کار نشان می‌دهد مشکل از استراتژی کم‌فرصت است یا از محدودیت‌های اجرایی.

برای خطاهای موقت مانند افزایش اسپرد یا ردشدن به‌علت تغییر قیمت، سیاست تلاش مجدد کنترل‌شده تعریف کنید. تلاش مجدد نباید بدون محدودیت انجام شود، زیرا می‌تواند سفارش‌های تکراری ایجاد کند. هر تلاش باید با شناسه چرخه سیگنال، فاصله زمانی مناسب و بررسی دوباره شرایط بازار انجام شود.

در نهایت، ربات باید علت بازنکردن معامله را برای معامله‌گر قابل فهم کند. نمایش وضعیت‌هایی مانند «خارج از ساعت»، «اسپرد بالا»، «مارجین ناکافی»، «سیگنال تأیید نشده» و «معامله در انتظار تشکیل کندل جدید» روی چارت یا در گزارش، زمان تشخیص را به‌طور محسوسی کاهش می‌دهد.

رفتار رباتی که معامله را می‌بندد اما معامله جدید باز نمی‌کند، معمولا حاصل تفاوت میان موفقیت در مدیریت سفارش موجود و عبور از زنجیره پیچیده شرایط ورود است. برای بررسی دقیق، نباید تنها به نتیجه ظاهری روی نمودار نگاه کرد. باید مسیر کامل از داده بازار تا سیگنال، فیلترها، وضعیت حساب، اعتبار سفارش و پاسخ سرور دنبال شود.

در MQL4 و MQL5، استفاده صحیح از مجیک نامبر، تشخیص نوع حساب، کنترل نماد و تایم‌فریم، اعتبارسنجی حجم و مارجین، بررسی مجوز AutoTrading و ثبت خطاهای ارسال معامله، پایه‌های اصلی یک اکسپرت قابل اعتماد هستند. اگر هر مرحله لاگ مشخصی داشته باشد، «باز نشدن معامله» از یک رفتار مبهم به یک علت فنی قابل اندازه‌گیری تبدیل می‌شود. چنین رویکردی علاوه بر رفع خطای فعلی، کیفیت مدیریت سفارش، قابلیت آزمایش استراتژی و پایداری ربات معامله‌گر را در شرایط واقعی بازار بهبود می‌دهد.