Reversal strategy using Rithmic connection

[joehanus]

I have a very simple strategy that functions appropriately when using a Sim account in a live market, but as soon as I use my Rithmic connection I encounter the same problems as other do on this forum (i.e. the Modification rejected by the order management system error). So I have been been trying to adapt the "Rithmic/IBFriendlyExamples.zip" files to my strategy, yet I can't figure out how to apply my conditions where I always want to be in either a long or short position (see my basic strategy below). I get that OnExecution update I need to apply my stops and targets, but my stop in the case of my strategy would be to exit my current position and then enter into a reverse position. Furthermore, that position would be changing as my limit price (determined by a ParabolicSAR indicator) would be changing. Do I change the target/stop prices on OnBarUpdate?

Thank you for any help you can provide!

Using calculate.onEachTick:

protected override void OnBarUpdate()
if (IsFirstTickOfBar)
{
TradeTaken = false;
}

if (GetCurrentAsk() > ParabolicSAR[1] && TradeTaken == false)
{
EnterLongLimit(0,true,(DefaultQuantity), ParabolicSAR[1], "myLongEntry");
TradeTaken = true;
}

if (GetCurrentBid() < ParabolicSAR[1]&& TradeTaken == false)
{
EnterShortLimit(0,true,(DefaultQuantity), ParabolicSAR[1], "myShortEntry");
TradeTaken = true;
{​​

[NinjaTrader_ChelseaB]

Hello joehanus,

If you are wanting to reverse using a limit order while there are working exit stop and limit orders using the managed approach, this would violate the internal order handling rules and the entry would be ignored.

https://developer.ninjatrader.com/docs/desktop/managed_approach#internal-order-handling-rules-that-reduce-unwanted-positions

It would be necessary to cancel the working stop and limit first, before the limit can be submitted in the opposite direction.

The managed approach will automatically submit a 'Close position' order to close the existing position, when the entry limit in the reverse direction fills.

[joehanus]

Thank you, Chelsea, for your response, although I don't think I'm asking the question very clearly. From what I understand, while using a Rithmic connection, OnBarUpdate, OnOrderUpdate, and OnExecutionUpdate don't necessarily run in any timed sequence, which is why we use event based methods to trigger the different "Update" states. So in the Rithmic/IB friendly examples, stops and targets are submitted OnExecutionUpdate after an entry order is filled. So say after entering a long position, I would like to create a trailing stop based off of the PSAR indicator. So under OnExecutionUpdate, I could create a stop loss order at the PSAR value. But on each subsequent bar, I want to change my stop exit to the new PSAR value since it is a trailing stop. The problem I'm having, however, is that if I change my stop order price OnBarUpdate, my stop order at the previous bar can become filled before I change my stop to the new PSAR value due to how Rithmic handles orders, then I keep getting the Modification rejected by the order management system error. Is there a work around where I can prevent this from happening? Thank you very much for all your help.

[NinjaTrader_ChelseaB]

Hello joehanus,

This is correct, Rithmic updates do not come in a specific sequence.

Below is a link to an example of custom trailing behavior, and is designed safe for rithmic.

https://support.ninjatrader.com/s/article/Profit-Chase-Stop-Trail

[joehanus]

Thank you Chelsea for the examples, they helped with setting my trailing stop loss. Now say I would like to change my entry limit order. The problem I'm having with a Rithmic connection is that I'm calling ChangeOrder() using OnBarUpdate(), but in fast moving markets my order gets filled before I try to change it, so I get the "Modification rejected by the order management system." Is there a better way to call ChangeOrder(). Thank you!

[NinjaTrader_ChelseaB]

Hello joehanus,

In a fast moving market that is near the order price there is always the risk the order will be filled before an in-flight change order or cancel order request is received.

It is recommended to check the order.OrderState of the order before supplying the order to ChangeOrder() or CancelOrder().

You can also use RealtimeErrorHandling.IgnoreAllErrors if you would like the strategy to continue running after a change or cancel fails if the order actually filled instead.

[joehanus]

Thank you for the response. I have IgnoreAllErrors set and make sure my order.OrderState is in the "Working" condition before I change the limit order entry price. I also update my orders to null within onOrderUpdate once filled or cancelled. I also don't attempt to change an order unless it's not equal to null within onBarUpdate. However, after looking at my trace files, I think what's happening is that the order, "myLongEntry" becomes filled. Then immediately "onExecutionUpdates" and I am in a long position, then I assume "onBarUpdates" before "onOrderUpdates," which usually nulls my long order, and so the strategy is attempting to modify an already filled order. So within onExecutionUpdates, I also set my orders to null once filled, but that also isn't doing the trick. Here are my trace files:

2025-03-19 03:11:50:658|1|32|Order='2139132039/APEX-xxxx' Name='myLongEntry' New state='Filled' Instrument='MNQ 03-25' Action='Buy' Limit price=19509.5 Stop price=0 Quantity=1 Type='Limit' Time in force=GTC Oco='' Filled=1 Fill price=19509.5 Error='No error' Native error=''

2025-03-19 03:11:50:659|1|8|Execution='1785940|2139132039|213 9132039' Instrument='MNQ 03-25' Account='APEX-xxxx' Exchange=Globex Price=19509.5 Quantity=1 Market position=Long Operation=Operation_Add Order='2139132039' Time='03/19/2025 03:11:50'

2025-03-19 03:11:50:693|1|32|Order='2139132039/APEX-xxxx' Name='myLongEntry' New state='Filled' Instrument='MNQ 03-25' Action='Buy' Limit price=19509.5 Stop price=0 Quantity=1 Type='Limit' Time in force=GTC Oco='' Filled=1 Fill price=19509.5 Error='Unable to change order' Native error='Modification rejected by the Order Management System - Order is complete.'

[NinjaTrader_ChelseaB]

Hello joehanus,

"then I assume "onBarUpdates" before "onOrderUpdates,""

No, these are separate threads and there is no sequence of when these update. OnBarUpdate() runs when the bar updates. OnOrderUpdate() runs when the order updates.
You should not rely on these updating in a specific sequence as either could update first.

The script should not be attempting to change or cancel an order that has filled.

[joehanus]

Okay thank you, but in my example trace file, I'm gathering that the order executes and is filled before trying to change it under onOrderUpdate. So if I null the order after filled under onExecutionUpdate, and then only change the order if it is not null (i.e. active) under onBarUpdate, shouldn't I prevent the last "Modification rejected by the Order Management System - Order is complete" error from occurring? Because that's not what I have happen.

[NinjaTrader_ChelseaB]

Hello joehanus,

You should be checking the order state is working one line above where the order is supplied to ChangeOrder() or CancelOrder().

No, it is not guaranteed that OnExecutionUpdate() will run before or after OnOrderUpdate() so no, it's not guaranteed that the variable would be set to null before you attempt to change the order.

You should never rely on these methods to update in a specific sequence.

[joehanus]

Thanks, Chelsea, I've tried checking to make sure the orderState is working right before modifying my order, but no luck - I still get the error. But maybe I'm still not understanding the system correctly, so maybe my code isn't right:

If I understand correctly with Rithmic, OnExecutionUpdate, OnBarUpdate, and OnOrderUpdate don't run in any sequence, but does that mean they also run in parallel, or does each event run to completion before calling the next event? Say for example, I have the following code (using the condition that my order is working before changing it):

OnBarUpdate()

if (longEntry == null && entryCondition)
EnterLongLimit(0,true,quantity, limitPrice,"myLongEntry");

// **Can my longEntry order become not equal to null here? i.e., can OnOrderUpdate be called from here? Or does the OnBarUpdate() event run to completion before another event occurs?

if (longEntry != null && changeOrderCondition)
{
if (longEntry1.OrderState == OrderState.Working)
ChangeOrder(longEntry,quantity,newPrice,0)
}

OnOrderUpdate()
​
if (order.Name == "myLongEntry")
                longEntry = order;
​

As you can see, my question is commented within the code. Thanks for all your help!

[NinjaTrader_ChelseaB]

Hello joehanus,

It looks like you are checking the state of an order assigned to the longEntry1 variable but calling ChangeOrder() on an order assigned to the longEntry variable.

OnBarUpdate() and OnOrderUpdate() run asynchronously and are event driven. When you call an order method in OnBarUpdate() it will take time for the order to be initialized and update in OnOrderUpdate(), while OnBarUpdate() will continue running to completion.

[joehanus]

Ah I get it, thank you Chelsea (and that was a typo on the longEntry1 in my post). So now after using prints right after the OnOrderUpdate and OnExecutionUpdate to track the order Ids, names, and timing, and from looking at my log files, it seems like my error is occurring when my prints are the following:

Time: 2025-03-20 21:43:56.514_ONORDERUPDATE name Close position_execution order number: 2144395826_order state is ChangeSubmitted
Time: 2025-03-20 21:43:56.514_ONORDERUPDATE name Close position_execution order number: 2144395826_order state is Filled
Time: 2025-03-20 21:43:56.514_ONEXECUTIONUPDATE name Close position_execution order number: 2144395826
Time: 2025-03-20 21:43:56.514_ONORDERUPDATE name Close position_execution order number: 2144395826_order state is Filled

Is it usual behavior for OnOrderUpdate to run twice when there appears to be no update to my "Close position" order after it is "Filled" the first time? Which maybe why I am receiving the "order cannot be modified" error above?

[NinjaTrader_ChelseaB]

Hello joehanus,

If the ChangeSubmitted request is rejected because the order is filling at the exact same time, it would update again with the rejection and it's current state of Filled.

What was the state of 'Close position_execution' before the Change was requested?

The order cannot be modified because it's filled before the change request can be received.