Catch the limit

[tonynt]

Hello,

I have no idea this moment how one can catch in a script strategy the limit.
With a limit in the code when conditions true like
{entryOrderSd1a=EnterShortLimit(4,true,1,GetCurren tBid(), "Sd1a");
limitshort=GetCurrentBid();}
I think the limitshort must not be always the limit accurately at the tick.

Therefore I want to ask please how I can assign my variable limitshort the exact "working limit" price (which I need for cancelling purposes)

And when writing this I have another question: when using different dataseries I thought the code above with EnterShortLimit(4,...........) is correct 100%. In my script I have BIP0,1,2,3 for YM and NQ and BIP4 for MYM and MNQ but this week it occurred that the entry was done not in the micro but in the mini! (that caused me also $ 25,- to pay margin violation fee).

How can this occur? Is it more safe to run the script in a chart with micro with BIP0?

Thank you!
Tony

[NinjaTrader_ChrisL]

Hi tonynt, thanks for your post.

I'm not sure what you mean about "variable limitshort the exact "working limit" price " Could you explain this question further?

For your other question, setting the BIP index would be enough to make sure the order gets submitted to the correct instrument. If you have a reduced sample that can reproduce an issue like this I would be happy to test it out.

I look forward to hearing from you.

[tonynt]

Hello,

thank you for your reply.

I showed in the lines in my question how I do assing the limitprice to the "variable double limitshort". But this must not be necessarily the exact same price as the limit I assume. Therefore I ask how I can get the working limit to assing it to a "variable double". Why isnt this clear what I ask for?
It happened with EnterShortLimit(4,...........) that instrument BIP0 was filled and not BIP4. (happened one time of 50 trades maybe)

Thank you!
tony

[NinjaTrader_Jim]

Hello tonynt,

You are assigning the same value that you are giving the EnterShortLimit entry to your limitshort variable. Your code is already doing this. It would be very unlikely that a new bid price is fetched with when GetCurrentBid is called again, but you could assin GetCurrentBid to the the limitshort variable and then submit your EnterShortLimit order method with limitshort. I would suggest printing this value out and comparing it with entryOrderSd1a.LimitPrice to verify. Order.LimitPrice would also be the actual limit price of the Order object.

Order objects - https://ninjatrader.com/support/help...nt8/?order.htm

As for the instrument which the order is placed to, I suggest also printing Instruments[4].FullName to confirm the instrument that the order is submitted to. I would also recommend testing to reproduce the script's behavior in the Playback Connection, and then to comment out sections of code to narrow down the behavior. Debugging steps should also be taken here to verify what instrument each BarsInProgress represents, and where the strategy logic is submitting the orders.

Debugging tips - https://ninjatrader.com/support/help...script_cod.htm

If you have a reduced script that shows an order being submitted to one instrument but is filled on another, please feel free to attach it for our analysis. We will not be able to debug and breakdown your full script, so the script should have other unrelated code removed so it can clearly demonstrate the issue at hand.

Let us know if you have any questions.

[tonynt]

Hello,

thank you for your reply.

This is a solution to assign first to variable and then using this as limit, but every step in fast markets is one too much. I thought its possible to catch the limit from onorderupdate maybe and I would get a reply how to catch it maybe from there as then it would be for sure that bid. "onoderupdate...working(?).... limitshort=order.... etc"

I agree that by the rules it should do the entry with the BIP determined in the order. And it does "usually", therefore its strange that the issue occurred and BIP0 was triggered. A reduced script will be the same as the examples in helpguide, maybe you might test it 9.999 times that it occurs one time. My aproach was different, to exclude probable difficulties and therefore I asked if its better to run it on a chart/dataseries that matches ith BIP4 (which is not necessary then of course)

Thank you!
Tony