Ignored order has invalid price

Desktop SDK - Strategies
1

Hi
I am using the umanaged order framework to create ORB strategies.
Now i keep on getting the “An order has been ignored since the stop price is invalid” this does not really make much sense when you look at my code which is :slight_smile:

   protected override void OnExecutionUpdate(Cbi.Execution execution, string executionId, double price, int quantity, Cbi.MarketPosition marketPosition, string orderId, DateTime time)
    {
        // if the long entry filled, place a profit target and stop loss to protect the order
        if (entryLongOrder != null && execution.Order == entryLongOrder)
        {
            // generate a new oco string for the protective stop and target
            string ocoString = string.Format("profitstoploss" + CurrentBar, DateTime.Now.ToString("hhmmssffff"));

            longStopLoss = SubmitOrderUnmanaged(0, OrderAction.Sell, OrderType.StopMarket, 1, 0, entryLongOrder.AverageFillPrice - StopLoss * TickSize, ocoString, "longStopLoss");
            longProfitTarget = SubmitOrderUnmanaged(0, OrderAction.Sell, OrderType.Limit, 1, (entryLongOrder.AverageFillPrice + ProfitTarget * TickSize), 0, ocoString, "longProfitTarget");
        }

        // reverse the order types and prices for a short
        else if (entryShortOrder != null && execution.Order == entryShortOrder)
        {
            string ocoString = string.Format("profitstoploss" + CurrentBar, DateTime.Now.ToString("hhmmssffff"));

            shortStopLoss = SubmitOrderUnmanaged(0, OrderAction.BuyToCover, OrderType.StopMarket, 1, 0, entryShortOrder.AverageFillPrice + StopLoss * TickSize, ocoString, "shortStopLoss");
            shortProfitTarget = SubmitOrderUnmanaged(0, OrderAction.BuyToCover, OrderType.Limit, 1, (entryShortOrder.AverageFillPrice - ProfitTarget * TickSize), 0, ocoString, "shortProfitTarget");
        }

        // I didn't use Order variables to track the stop loss and profit target, but I could have
        // Instead, I detect the orders when the fill by their signalName
        // (the execution.Name is the signalName provided with the order)

        // when the long profit or stop fills, set the long entry to null to allow a new entry
        else if (execution.Name == "longProfitTarget" || execution.Name == "longStopLoss" || execution.Name == "shortProfitTarget" || execution.Name == "shortStopLoss")
        {
            entryLongOrder = null;
            entryShortOrder = null;
            longStopLoss = null;
            shortStopLoss = null;
            longProfitTarget = null;
            shortProfitTarget = null;
        }
    }

Everything works fine the first time through second time through no matter what the longStopLoss order is rejected with the invalid price.
Can somebody help here as it does not really make sense that you cannot create an stoplossorder 20 ticks away from the price.Preformatted text

2

See if it is related to this: Simulated Stop NT8 Platform Error - Executed price is outside of price bands

3

Hi
Thanks for the input, does not seem to be the same but could be a related bug.

4

Not sure why it’s doing what it’s doing…have you tried using print statements? Even adding them to OnExecutionUpdate could give some clues.

I would probably start with printing the values of ocoString (might as well), StopLoss, entryOrder’s average fill price, ticksize and profit target. Since it works the first time, maybe it’s not resetting the value properly? I typically like the format Print("TickSize: " + TickSize); so when I see it in the output I know what I’m looking at.

Also, probably not related since it works the first time, but there was some code that I needed to add parenthesis to my math because it wasn’t adding up properly. Like averagefillprice + (stoploss * ticksize). I think I didn’t notice it messing up because I would use MYM but it added funny on MES, because the ticksize was in 0.25 increments. Adding prints will confirm if that’s causing any issues or not.

Anyway, try adding prints and get back to us. I’m sure it’s something that can get fixed.

5

Hi
Thanks for the input. For now and as a bandaid for my backtesting i have solved the issue 98% by making an extra check if the ongoing loss is below the stoploss and if it is I conclude the stoploss order has failed and then I am closing the trade. But strange indeed that this can happen.

1 Like
6

The behavior you’re seeing is a limitation of back testing on bar data. You can work around some of these issues by adding a 1-Tick data series to your strategy and placing your orders against that stream instead of the primary data stream (ie: SubmitOrderUnmanaged(TickSeriesBarsArrayIndex,…) instead of SubmitOrderUnmanaged(PrimarySeriesBarsArrayIndex,…))

Discrepancies: Real-time vs Backtest
Understanding Historical Fill Processing

2 Likes