EnterLong ignored

[ATI user]

under what condition can an order be ignored?

my code places several long orders then 2 long orders in a row are ignored

no error messages in the Log or Output Window

replay account balance is 100,000+....no order rejection messages/state

no code limiting entries per direction

I am printing all OrderStates and all position updates

---------------Output Window-------------

Long_1 #35 qty 3 ENTER 2350.5, STOP 2349.5, bar 6931, 11/7/2011 2:16:50 PM
***** PendingSubmit, 11/7/2011 2:16:50 PM
***** Accepted, 11/7/2011 2:16:50 PM
***** Working, 11/7/2011 2:16:50 PM
***** PartFilled, 11/7/2011 2:16:50 PM
*** LONG POSITION: 2, AVGPRICE 2347.34375, 11/7/2011 2:16:50 PM
***** FILLED , 11/7/2011 2:16:50 PM
*** LONG POSITION: 4, AVGPRICE 2347.975, 11/7/2011 2:16:50 PM

Long_2 #36 qty 3 ENTER 2355.25, STOP 2354.25, bar 6942 , 11/7/2011 2:21:37 PM
***** PendingSubmit, 11/7/2011 2:21:37 PM
***** Accepted, 11/7/2011 2:21:37 PM
***** Working, 11/7/2011 2:21:37 PM
***** PartFilled, 11/7/2011 2:21:37 PM
*** LONG POSITION: 5, AVGPRICE 2348.63636363636, 11/7/2011 2:21:37 PM
***** FILLED , 11/7/2011 2:21:37 PM
*** LONG POSITION: 7, AVGPRICE 2349.65384615385, 11/7/2011 2:21:37 PM
Long_2 #36 EXIT 2354.25, bar 6942, 11/7/2011 2:21:44 PM
*** LONG POSITION: 6, AVGPRICE 2349.65384615385, 11/7/2011 2:21:44 PM
*** LONG POSITION: 4, AVGPRICE 2349.65384615385, 11/7/2011 2:21:44 PM

Long_2 #37 qty 4 ENTER 2354, STOP 2353, bar 6944, 11/7/2011 2:22:20 PM

trade ignored

Long_2 #38 qty 4 ENTER 2353, STOP 2352, , bar 6948, 11/7/2011 2:24:08 PM

trade ignored

[NinjaTrader_AdamP]

ATIUser,

If you are using the managed approach, these are the rules used to reduce unwanted positions.


The following rules are true per unique signal name:


Methods that generate orders to enter a position will be ignored if:
• A position is open and an order submitted by an exit method (ExitLongLimit() for example) is active and the order is used to open a position in the opposite direction
• A position is open and an order submitted by a set method (SetStopLoss() for example) is active and the order is used to open a position in the opposite direction
• The strategy position is flat and an order submitted by an enter method (EnterLongLimit() for example) is active and the order is used to open a position in the opposite direction
• The entry signal name is not unique

Methods that generate orders to exit a position will be ignored if:
• A position is open and an order submitted by an enter method (EnterLongLimit() for example) is active and the order is used to open a position in the opposite direction
• A position is open and an order submitted by a set method (SetStopLoss() for example) is active

Set() methods that generate orders to exit a position will be ignored if:
• A position is open and an order submitted by an enter method (EnterLongLimit() for example) is active and the order is used to open a position in the opposite direction
• A position is open and an order submitted by an exit method (ExitLongLimit() for example) is active

Please let me know if I may assist further.

[ATI user]

• The entry signal name is not unique

that got it...thanks

[NinjaTrader_AdamP]

ATI User,

Please let me know if you require additional assistance, or have any other questions.

[Pagey]

signalName and Entries per direction problem

Dear All,

I am getting some peculiar behavior in backtesting when applying different signal names with "Entries per direction" set at 1

Attached you can see 2 test strategies which are identical except for the fact that one sets a different signal name every bar, and the other doesn't set a signal name
both place a long order every bar (1-min bars, on 6j for January 2012)

I attached the output for both these strategies. You will notice that the version that changes the signal name will get a "NULL" order every second bar (when not in position) (e.g. in file output_testsignals_6j_jan2012.txt line 13, or lines 295-301)
this is different than the behavior when the signalName is the same (compare with lines 294-301 in output_testsignalsnosignalnames_6j_jan2012.txt)

It seems that if the signal name is new, it doesn't allow it to be placed in the next bar, perhaps because it wants to make sure there are no over-fills? (perhaps one uses Cancel/Replace and the other doesn't?) Is this the expected behavior or is this a bug?
(rememeber that "Entries per direction" == 1)

Thanks dearly for your quick analysis,

Pagey

[NinjaTrader_AdamP]

Pagey,

What do you have your "EntryHandling" set to? Is it "UniqueEntries" or "AllEntries"?

http://www.ninjatrader.com/support/forum/showpost.php?p=260837&postcount=2

[Pagey]

Pagey,

What do you have your "EntryHandling" set to? Is it "UniqueEntries" or "AllEntries"?

http://www.ninjatrader.com/support/f...37&postcount=2

Adam it's set to AllEntries

[NinjaTrader_AdamP]

Pagey,

With AllEntries it would only allow you to place 1 trade here even with the entrance signal names. Is your question why these two have different behavior when you set the entrance signal names?

[Pagey]

Dear Adam,
Yes, my question is why the behavior is different if I set a signalName compared with not, and specifically why it will not allow me to place an order in two consequtive bars (getting a NULL order back- see logs mentioned in previous post), even though there was NO FILL in any of these bars.
I understand there could be a race condition/overfill/passing of Entries per direction risk in a live trading scenario in such a case, but Why doesn't the historic backtest allow me to enter these orders when there was clearly no fill in the previous bar?
Isn't the position fill checked before the new order /Entries per direction check is made?

Thanks dearly for your help,

Pagey

[NinjaTrader_AdamP]

Pagey,

Thank you for your patience. I am currently doing some testing on this item.

I am not able to replicate this with SampleMACrossover using the same prints you have, and assigning signal names in the same way. But I am using your strategies currently. I will get back to you with updates shortly.

[NinjaTrader_AdamP]

Pagey,

I have found the cause here with the help of our Tech lead.

Essentially, NinjaTrader fills new orders at the opening of the next bar with COBC = true, or similar in backtesting. Using "AllEntries" and "EntriesPerDirection = 1" when you submit an order with a different signal name, it closes the previous order and opens a new order causing what appears to be a 1 bar delay but is an order filling at the open of the next bar. When you submit an order with the SAME signal name, it modifies the existing order in the case of stops/limits.

Signal names are meant to separate entrance conditions, not to separate or name successive orders. In other words, you may have a set of disjoint conditions called "ConditionSet1", and a set of conditions called "ConditionSet2" and each is supposed to enter you into a long limit lets say. You would want to divide these by signal name perhaps so that you could identify which condition set entered which order. However, you would not want to use these to name successive orders on the same condition set.

In conclusion this is to be expected based on the function designed for signal names.

Please let me know if I may assist further.

[Pagey]

Dear Adam- thanks dearly for the explanation

I am wide aware that signal names exist to differentiate between logical conditions and not to enumerate bars, but as you might imagine, one condition could end in one bar and another condition to start in the next bar, and in the scenario described the order to the second condition will not be sent (entry handling = AllEntries, entries per direction set at 1 above the current strategy position)
In my opinion this is not the expected behavior, but this is your software

I also didn't quite follow the explanation about the bar bar delay and the order filling, as there were no fills involved in the problematic scenarios i described (just orders not placed/==NULL) but I believe you understood the problem as I see it

Thanks again and a good weekend to you,

Pagey

[NinjaTrader_Brett]

No problem.

Basically in backtesting we simulate order states as best we can and it takes a bar to update iOrders. Orders are submitted and filled at the open of the next bar.

When it comes to iOrder there is no way not to test in live conditions as live conditions can bring much different results that you need to be ready for as you rely on the servers to return back order state which can come at any time.


-Brett