Announcement

Collapse
No announcement yet.

Partner 728x90

Collapse

Time[][] not aligning with exit

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Time[][] not aligning with exit

    I'm running a 15m backtesting strategy using 1m a the second period for granularity.

    The entries and all trades are occurring on the 1m.

    What's confusing me is that when IOrder fires on the exit the Time[1][0] (current time) is not correct (it's correct at entry). Here's is the system output:

    1. ENTRY: ORDER STARTED (STATE: Filled) on Bar 07/01/2014 19:12:00(TF 03-158020015221555)
    1B. EXECUTION: Price = 1150.53121677109 Name = TF 03-158020015221555
    MarketPosition = Long at Bar 07/01/2014 19:12:00(TF 03-158020015221555)

    4. PROFIT TARGET FILLED (STATE: Filled) at 07/01/2014 19:12:00(TF 03-158020015221555) <<<<------ 19:12 not correct

    However the actual fill occurred at 19.27 on the 1m (at price 1151.5 - confirmed as the exit in the S.A. which could only have occured at 19.27). (n.b. The 15m output in the S.A shows the fill time at 19.15).

    Can someone explain how that discrepancy could occur?

    #2
    Hello darrentate,

    Thank you for your post.

    What time is the fill of the order in the Executions tab of the Control Center?

    I am suspicious that you are looking at the time of the order on the chart and it is showing on the next bar.

    When NinjaTrader is running with Calculate on bar close (COBC) as true, orders are placed after the bar closes using logic calculated from that bar.

    Below is a link to the help guide on Calculate on bar close.


    This means that any orders that are triggered from that bar are submitted after the bar closes as the new bar opens. As the order is placed as the new bar opens and the timestamp of the order is within the time of the next bar, the order will show on the next bar.

    If the strategy were running with COBC as false, or if the script has intra-bar granularity and submitted orders on a smaller timeframe, this would cause the timestamp of the order to be within the bar it is triggered on as the order may be submitted intra-bar. This order would show on the same bar as the bar that triggered the order submission.

    This is outlined in the help guide Discrepancies: Real-Time vs Backtest.



    May I have a screenshot of the Executions tab of the Control Center with the Time column expanded enough we can see the actual fill time of the order.
    Chelsea B.NinjaTrader Customer Service

    Comment


      #3
      Please see attachment.

      The orders are being taken in code appertaining to (BarsInProgress) == 1 (the second time frame being 1m). The granularity is created here.

      A parameter is set when the order is taken. It's possible that the order may fill sometime after another call to BarsInProgress == 0 has occured (so after 15m i.e. primary series); however the calls are only made via the 1m series code and not the 15m.
      Attached Files
      Last edited by darrentate; 02-27-2015, 05:15 PM.

      Comment


        #4
        To clarify is IOrder only going to run on the primary series?

        Even though I'm running an EnterLong on the secondary series it's entering at the correct price on the secondary series but when I then check the BIP on OnOrderUpdate is shows 0 (so the order is only filling at the primary series).

        Therefore if I were to have multiple trade entries on the secondary series with an associated profit target the order can only be filled once in essence due to the restrictions enforced by IOrder running when BIP = 0?

        I can use a get round using a variable that would stop multiple trades occurring on a single 15m candle (not ideal) but that still leaves this problem: I've attached a single trade example of what I believe is occurring on the 1m.(against a 15m). So BIP == 1 as the first 15 1m bars are processed, a trade is detected (when price crosses the MA) during the period, profit target setup etc. The profit target is 10 ticks; and would only have filled at 9am. However because the 15m bar is then processed AFTER the 15 1m secondary series bars are processed because the IOrder processing only appears to work for the primary series it thinks that the target has been reached as it processes that bar when in fact it hadn't. Is there a recommended get around for this? Say using a more accurate fill time and ensure it's now happened prior to the entry (though again do we run into problems because the time series is 15m on the primary series right)?!
        Attached Files
        Last edited by darrentate; 02-28-2015, 11:25 AM.

        Comment


          #5
          Hello,

          Are you placing a buy market order and this is not filling when you place the order?

          Or is this a limit order that is being filled by the first bars in progress that has a price that can fill the order?

          What is the exact issue?

          Is the price wrong? Was is the execution price? What should the execution price have been?

          Is the time of the fill wrong? When was the order submitted? What type of order was it? What time did the order fill?


          An order can fill on any BarsInProgress. When placing an order to an IOrder object this does not change the order in any way. It does give you the ability to find the status of the order though.

          What restrictions are you referring to? Are you placing an order in BarsInProgress 0 and the order is not filling in the other BarsInProgress?

          Please be specific about the issue that you are running into. Prints, or screenshots of the executions tab may be helpful.
          Chelsea B.NinjaTrader Customer Service

          Comment


            #6
            Chelsea,

            The current issue is that when I place an order (be it a limit order or market order) even though the order is being placed when BarsInProgress = 1 when IOrder runs BarsInProgress always = 0.

            The time stamp (Times[1][0]) shows the correct 1m entry time in IOrderUpdate, but the BIP is always 0 when IOrder runs and therefore any profit target setup when BIP = 1 is only being filled afterwards when BIP = 0.

            The result of this happening is that while my orders have the correct entry / execution time stamp, the exit time in executions is on the 15m bar (and sometimes that will have already occurred) (see previous attachment).

            To be clear the order of events is:

            1) I have a 15m primary series (BIP == 0). The secondary series is 1m and added for granularity (BIP == 1).

            2) BarsInProgress(0) doesn't so very much apart from work out some variables. It doesn't create any entries or set targets.

            3) The entries and profit targets / stops are only set when BIP == 1 occurs. As mentioned it doesn't matter whether it's a limit order or market order. I've tried specifying the bararray when I take the entry (EnterLong("1",.....") but that makes no difference.

            If this isn't clear still I'll post some pictures of everything as it occurs including the code thanks.

            Darren

            PS. On a small side note - for late 2014-15 I can set the second series to tick data and get results; however for the start of 2014 selecting a second series with tick data produces nothing - only minute data (1m +) produces results. I've tried downloading the tick data again for the period but to no avail.
            Last edited by darrentate; 03-01-2015, 07:02 PM.

            Comment


              #7
              Hello darrentate,

              What are your referring to when you say "when IOrder runs BarsInProgress always = 0".

              IOrder is not a method or a function. IOrder is a variable type that holds an order that has been made.

              Are you saying that OnOrderUpdate is running and somehow this is involved with BarsInProgress 0?

              Are you saying that the order, placed with BarsInProgress 1, is filling in BarsInProgress 0?

              If so, if BarsInProgress 1 and BarsInProgress 0 are the same instrument, either data series will be able to fill the order. The order will fill on whichever BarsInProgress uses that same instrument as in a real market the order fills based on the price in real time not based on a specific bars in progress. By introducing data that the order can fill on, it will use that data to fill. The same is true with exits.

              In other words, BarsInProgress doesn't mean when the instrument is the same on each bars in progress except for when you want your logic to trigger. The fill, happens on any price hit with that instrument in any BarsInProgress.
              Chelsea B.NinjaTrader Customer Service

              Comment


                #8
                Yes sorry I meant OnOrderUpdate. BarsInProgress is always zero when the trade fills - even though the trade enters and price then hits the profit target while BarsInProgress is still 1 (so processing the 1m second series).

                The trade is created during the 1m second series (BIP = 1). A profit target and stop loss is then set. Before the completion of that 1m 15 bar cycle price hits the profit target (or stop loss). My issue is that's instead of just filling at the given time instead the target appears to be getting filled after the completion of that 1m cycle (and when the 15m primary series bar is being processed instead i.e. BIP = 0). I need it to behave like in real time and fill the target / stop during the processing of the secondary series.

                Bottom line - how can I get the targets to fill on the 1m series and not every 15m as it's currently doing.
                Last edited by darrentate; 03-02-2015, 12:17 PM.

                Comment


                  #9
                  Hello darrentate,

                  I want to make sure I understand.

                  BIP means BarsInProgress.

                  The primary series (BIP 0) is 1 minute. The secondary series (BIP 1) is 15 minute.

                  An entry order is submitted to BIP 0, the 1 minute series. The order fills on BIP 1 and not BIP 0, even though there have been 14 1 minute bars that have had a price that can fill the order, is this correct?


                  Or is the issue with SetStopLoss? The Entry order is placed on BIP 0, the 1 minute series and the associated stop loss does not full unless BIP 1 is is processed in OnBarUpdate?

                  When it comes to OnOrderUpdate(), this is triggered when the order fill or changes, BarsInProgress will not mean anything in this method.


                  Attached is a test script I've made to test this. Test this on a 1 minute chart.

                  The secondary series is a 60 minute series. This means that if the stop loss can only be filled by the secondary series, you will only see exits once per hour and not more than once per hour. I am not finding this is the case.
                  Attached Files
                  Last edited by NinjaTrader_ChelseaB; 03-02-2015, 12:47 PM.
                  Chelsea B.NinjaTrader Customer Service

                  Comment


                    #10
                    No the primary series is 15M. The secondary series 1m (though I am also sometimes using tick data for more precision).

                    BIP = 0 on the 15m and 1 on the 1m.

                    I went down this road as the SampleInstrabarBacktest states the secondary series needs to be smaller than the primary series and all the information on the forum has people making the secondary series the smaller time frame for granularity.

                    Therefore my understanding is that (say) 4.00 - 4.15 pm the 15 1m candles are processed first and then the primary series (4.00 - 4.15pm) same period 15m candle is then processed after. My issue is that during the 15 1m series the targets and not filling - it sets up the trade entry at the right time; but then fills it either immediately (the exact same second) or when the 15m candle then is processed. Obviously if price has already hit the target PRIOR to the entry on the 1m then it thinks the target was filled even though it wasn't.
                    Last edited by darrentate; 03-02-2015, 12:45 PM.

                    Comment

                    Latest Posts

                    Collapse

                    Topics Statistics Last Post
                    Started by judysamnt7, 03-13-2023, 09:11 AM
                    4 responses
                    59 views
                    0 likes
                    Last Post DynamicTest  
                    Started by ScottWalsh, Today, 06:52 PM
                    4 responses
                    36 views
                    0 likes
                    Last Post ScottWalsh  
                    Started by olisav57, Today, 07:39 PM
                    0 responses
                    7 views
                    0 likes
                    Last Post olisav57  
                    Started by trilliantrader, Today, 03:01 PM
                    2 responses
                    21 views
                    0 likes
                    Last Post helpwanted  
                    Started by cre8able, Today, 07:24 PM
                    0 responses
                    10 views
                    0 likes
                    Last Post cre8able  
                    Working...
                    X