Если реал или демо, то по умолчанию выбирается вариант 0 Mode_StopLevelF, и в этом случае возвращается реальный стоплевел.
Но можно выбрать и коррекцию стоплевела спредом, с разным коэффициентом. При этом если стоплевел будет больше чем спред, то будет учитываться стоплевел.
А для тестера, при модерации, выбирается всегда режим не ниже 3 Mode_StopLevelF, в этом случае стоплевел будет больше спреда в 3 раза и больше.
П.С. Как пишет разработчик SymbolInfoTick предпочтительнее чем SymbolInfoDouble для Ask и Bid.
Expert Advisorがminの動きを捉えているので、サーバーを叩いているのですが、1pipのストップロスではなく、通常のminレベル＋スプレッドで、スプレッドが浮いている状態です。そのため、EAは正常なスプレッドに戻るまでサーバーを叩いているのです。
つまり、開いた瞬間にmin stopをチェックし、値を再構築してからサーバーを叩くのです。しかし、10pipsのストップを置く必要がある場合、minのスプレッドを待ってサーバーを叩かなければなりません。
サーバーを叩くのはNG。オートトレードの禁止に遭遇することがあります。(誰が自分のEAによるサーバーへのDDOS攻撃に対処したいと思うだろうか)。
まずリクエストを送る前に、スプレッド、ストップレベルを取得し、ストップを調整し、取引に支障がなければ、リクエストを送る必要があります。停車に納得がいかなかったのであれば、誰にも迷惑をかける必要はないのです。自分のサーバーがあんなに叩かれたら、殺してしまいそうです...。
しかし、許容できるストップサイズでリクエストを送信した後、再びエラー130が 発生した場合（リクエスト送信中にストップレベリング条件が変更された）、ストップサイズを調整して（新たに算出した許容できるストップサイズで）リクエストを送信することができます。このような要望は数に限りがあるはずで、そうでなければ、またくだらないおしゃべりになってしまうでしょう。
あなたが市場に入れない理由がわかりました。
しかし、ここでは少し状況が異なります。
ずっとチマチマやっているつもりはないんですけどね。
当然、エラーの後にはエラーチェック-Slip.がありますが、テスターではうまくいきません。
浮遊拡散のことです。
上に書いたように、リクエストを送信する前に、ストップ・レベルを修正してサーバーに送信し、サーバーがエラー 130 を返すと、Expert Advisor は再度レベルを修正してサーバーに送信します。
といった具合に。
テスターではスリップが効かないので、遅延が発生しないのです。
今のところ、「ストップはサーバーのストップレベル＋スプレッド＋1より低くてはならない」という方法で解決しています。
サーバーからストップレベルが 0と返された場合、どうすればいいのでしょうか？ つまり、フローティングなのでしょうか？
オプション - エラーによる調整 130 - オプションではありません - モデレーターはこの方法を許さないでしょう。
先に提案したように = Error 130 - 1 ずつ増やしていき、サーバーが取引を見逃さないようにします。- は選択肢にない。
フレンズ、問題解決にご協力ありがとうございました。しかし、この問題に対する合理的な解決策を模索することになる。
皆様、ご参加ありがとうございました。
この辺はちょっと事情が違うんです。
ずっとチマチマやっているつもりはないんですけどね。
当然、エラーの後にはエラーチェック-Slip.がありますが、テスターではうまくいきません。
浮遊拡散のことです。
上に書いたように、リクエストを送信する前に、ストップ・レベルを修正してサーバーに送信し、サーバーがエラー 130 を返すと、Expert Advisor は再度レベルを修正してサーバーに送信します。
といった具合に。
テスターではスリップが効かないので、遅延が発生しないのです。
今のところ、「ストップはサーバーのストップレベル＋スプレッド＋1より低くてはならない」という方法で解決しています。
サーバーからストップレベルが 0と返された場合、どうすればいいのでしょうか？ つまり、フローティングなのでしょうか？
オプション - エラーによる調整 130 - オプションではありません - モデレーターはこの方法を許可しません。
先に提案したように = Error 130 - 1 ずつ増やしていき、サーバーが取引を見逃さないようにします。- は選択肢にない。
フレンズ、問題解決にご協力ありがとうございました。しかし、この問題に対する合理的な解決策を模索することになる。
皆様、ご参加ありがとうございました。
原理的には、stoplevel=0 のとき、ユーザにスプレッド乗算係数の手入力を強制することが可能である。すなわち、初期化時（時間枠の切り替えではない）にstoplevelを確認し、0であれば係数の入力を求める表示をする。ユーザーが入力を拒否した場合は、係数を使用します。2（スプレッド*2）、そしてエラー130の場合、係数またはストップサイズを増加させます。もしユーザーがStop Levelの計算方法を知っている場合（例えばテクニカルサポート部門に聞くなど）、そのユーザーが入力した係数を使いますが、130回目のエラーにはストップサイズを大きくして対応することを忘れないでください（まだ表示される場合）。しかし、通常は（何度か遭遇して経験的に覚えた）stop=stopplavel*coefficient+1とすれば、エラーは発生しない。1ポイント加算されないと、エラーが表示されます。
従って、MCサーバーでストプレレベルの計算方法を確認し、必要な係数をEAに入力してください。司会者が係数の手動入力を拒否しても、自動的に入力されます。
ありがとうございます！初期設定の2+1ポイントです。
聞いてみるものですね。 フォームを作って、自分で入力させることにします。
ブローカーは、約20のコマンドが間断なく送信された場合、数分間オートトレードを禁止することがあります。
つまり、注文と注文の間に少なくとも300～500msの間を空けて、たくさんの注文を修正/決済する必要があります。(しかし、このエラーはもはや130ではありません）
皆さん、こんにちは。
Marketplaceの特徴 として、min stopのすべての値をチェックする必要があります。
変数の値がmin-stopより小さい場合は、min-stopを代入し、エラー130が 発生しないようにします。
現在、90％のブローカーがフローティングスプレッドと最小STOP、利回り0を採用しています。
すべての変数をmin stopに代入するコード構成が ある。
しかし、今はどこでもminstop=0なので、マーケットプレイスではもう通用しないのです。
誰がこの問題に取り組んでいるのでしょうか？
こんにちは、Vladislav。私も遭遇した問題を読み、フローティングストップレベルが0または0に近い値を返す場合、閉じるために逆信号を使用することにしました。
この解決策で大丈夫だと思いますか？