Order Change Delay

[alphatango]

I'm trying to update my strategy to only send an order update every X number of ticks or x number of seconds so I don't freak out Rithmic connections.

I was advised to use OnOrderUpdate() but I'm having trouble integrating it as the syntax is somewhat nebulous to me (I'm admittedly not terribly great with C#-esque languages).

As I understand: my order price is predicated OnBarUpdate for the right price of the order. If I put the entry under OnOrderUpdate, does that change how the order price is gathered?

Current Syntax
protected override void OnBarUpdate()
{
My logic for my strategy along with order (stop loss, and target)
}

I imagine the syntax would be
protected override void OnBarUpdate()
{
My logic for my strategy
}

protected override void OnOrderUpdate()
{
Put my order in this way so as not to freak out Rithmic with successive updates
}


I have a series of checks to make sure things don't go haywire in OnOrderUpdate() how do I pass the "ball" back to OnBarUpdate to update the order after the requisite number or ticks/seconds?

[NinjaTrader_Jesse]

Hello alphatango,

An entry order would commonly go inside OnBarUpdate and not inside OnOrderUpdate or OnExecutionUpdate. To initially drive the trade you need to submit an order which generally is done in OnBarUpdate based on price data. To submit targets based on that orders fill you can do that using OnExecutionUpdate, you monitor for the entry order and then submit targets. There are some examples of submitting targets based on an entry order fill here:

https://ninjatrader.com/support/helpGuides/nt8/onexecutionupdate.htm

If you are using OnOrderUpdate to monitor for orders an assigning them to variables that would be how to communicate between OnOrderUpdate and OnbarUpdate. If an order variable is populated you could do different actions in OnBarUpdate.

There is a full sample of using the order event driven methods here: https://ninjatrader.com/support/help...and_onexec.htm

[alphatango]

I'm somewhat confused. I want to make sure I'm asking the right question and asking for the right thing. I have a couple folks telling me that I'm calculating from order filled. This is not what I'm asking. I want to just make sure I'm not being unclear.

When using the OnBarUpdate() for updating my order entry, it's updating with every tick. That's nice and I like it. Rithmic however throws a tantrum and generates errors which lead to memory leaks on my computer and subsequent crashes if left unattended too long. I need to stop these errors from happening by spacing out the number of orders I'm sending to Rithmic to let their systems catch up and allow Rithmic and NT to synchronize. My algorithm can handle a couple of seconds delay with no problem.

What I have so far.

protected override void OnBarUpdate()
{
if ((LEconditions = true)
}
EnterLongLimit(NumOfPositions,EntryPrice,"MyAlgo-LE");
SetProfitTarget("VolumeSpike-LE", CalculationMode.Ticks, ProfitTarget);
SetStopLoss("VolumeSpike-LE", CalculationMode.Ticks, StopLossInTicks, true);
}
else
{
EnterShortLimit(NumOfPositions,FastAvg,"MyAlgo-SE");
SetProfitTarget("VolumeSpike-SE", CalculationMode.Ticks, ProfitTarget);
SetStopLoss("VolumeSpike-SE", CalculationMode.Ticks, StopLossInTicks, true);
}​
}

(Please forgive any syntax errors. It compiles i just took out a bunch of extra stuff for readability and to keep my question simple. Also called information is indeed referenced elsewhere. again, the code compiles. )

protected void OnOrderUpdate(Cbi.Order order)
{
if (order.Name == "MyAlgo-LE")
entryOrderLE = order;
else if (order.Name == "MyAlgo-SE")
entryOrderSE = order;

// I would have OrderState.Open, but that doesn't exist. sort of unhelpful there...
// Track ticks passed since entry order was Opened
if (entryOrderLE != null && entryOrderLE == order && order.OrderState != OrderState.Filled)
ticksPassedLE++;
else if (entryOrderSE != null && entryOrderSE == order && order.OrderState != OrderState.Filled)
ticksPassedSE++;​

int delayTicks = 5000;

if ((entryOrderLE != null && entryOrderLE == order && order.OrderState != OrderState.Filled && ticksPassedLE >= delayTicks) ||
(entryOrderSE != null && entryOrderSE == order && order.OrderState != OrderState.Filled && ticksPassedSE >= delayTicks))
{
// Update order price or perform actions after the delay
if (order == entryOrderLE)
{
//Update Order Price per OnBarUpdate
}​
else if (order == entryOrderSE)
{
//Update Order Price per OnBarUpdate
}​
}​


}

Upon testing in playback, it seems to ignore any calls to wait for the order update. What I think I'm missing is the ending point where OnOrderUpdate tells OnBarUpdate when it has the authority to send an update to the order price.

[NinjaTrader_Jesse]

Hello alphatango,

If you are getting a rejection for too many updates to the order you should instead use a live until cancelled order and just submit it one time. If you are not updating the entries price there is no reason to call the order again, if you do need to update the price you would call the order one more time with a new price.

EnterLongLimit(int barsInProgressIndex, bool isLiveUntilCancelled, int quantity, double limitPrice, string signalName)

Regarding the code in OnOrderUpdate, that is only called for status changes for order events. If you are doing some kind of tick counting logic that should be inside OnBarUpdate, not OnOrderUpdate.

One other note is that Set methods should always preceed your entry. If the entry were to fill immediately a previous price would be used rather than the ones being supplied. Calling the methods first ensure the price you just calculated is always used.

SetProfitTarget("VolumeSpike-LE", CalculationMode.Ticks, ProfitTarget);
SetStopLoss("VolumeSpike-LE", CalculationMode.Ticks, StopLossInTicks, true);
EnterLongLimit(NumOfPositions,EntryPrice,"MyAlgo-LE");

[alphatango]

I don't know if this helps, but the order price is calculated actively on an EMA. As volatility naturally goes up and down, it adjusts the price which is good. I recognize that this is what is hurting the algorithm due to updates given OnBarUpdate. If I can freeze those updates to process the order update every 100 ticks or 1 second or so, that's what I'm looking for. The simplest way to do that.

I'm strictly trying to account for latency between NT and Rithmic.

I'm not sure how live until canceled would help as it does indeed live until the conditions are false and cancels itself (a desired outcome).

[NinjaTrader_Jesse]

Hello alphatango,

You would need to make that type of logic inside OnBarUpdate and use a live until cancelled order. If you are changing prices on every tick the broker is going to get an order change event for every tick. To keep an order alive without a condition needing to be true constantly you can use a live until cancelled order.

You would need to make some counter logic that executes only when you want it to inside OnBarUpdate, you can use a Print to test different logic to find what works for your goal. Then add the order submission method into that condition and call it to update it at that frequency.

When you initially submit the entry use a live until cancelled order so your entry condition only needs to become true once to submit the order and it will remain active until you change it later or cancel it.

If you wanted to retain the same logic you need to have OnBarUpdate called less frequently meaning you need to not use OnEachTick and instead use OnBarClose or OnPriceChange