Going to cross post this here from General Discussions.
When criteria are met my script places a limit order for one contract, if regression hits the limit order, the order is executes entry for the one contract and it is filled (obvious).
Not obvious = 1-2 times per day the script will decide that instead of entering one contract it will enter multiple, 34 contracts up to 118 the most I have seen yet.
I have always had Position.MarketPosition == MarketPosition.Flat in the script, I added two more “position zero” criteria to prevent this Position.Quantity == 0 and inTrade = true/false flag but it happened again today. I am thinking of adding a “one entry execution” per bar in hopes to eliminate this but there is a risk it could happen at bar close :59 - :00 so I’m not 100% sold on this.
Any idea what “root cause” could be, I’ve never had this happen with any other script - I am at a complete loss on this one ATM.
Seems like some kind of race condition, the order is placed, probably not even reached submitted, and 100 new ticks are still thinking position is Flat, no order is fulfilled yet, and you are going on submitting new orders with every tick…or there could be something else wrong with the code.
Market Popsition is very delayed. And you want to avoid race conditions. You need to use OnOrderUpdate & OnExecution Update to decide that you cannot place other orders till your is accepted or fullfilled depending on your logic.
But even between the point in time the API for placing order is invoked and the time OnOrderUpdate receives a callback with the status submitted, there could be 100 ticks placing new orders, that is why another temporary flag is required locally..atleast in my case where i am placing market orders.
Correct vipnb. Thank you for the clarification. I forgot to mention this. MassGainTrading, The way I do and it works nicely is the following:
Your decision to send an order comes first do you set up a flag.
The wait for the OnOrder and or OnExecution and confirm the order has been accepted and/or filled.
Once it’s filled you may want to check the round trip is completed.
The last one is usually position but you may want to check with executions too.
A suggestion. Execution is very tricky and took me months to get it right (I even question the ATM work flawlessly) to then discover that in futures.io (now https://nexusfi.com) a group of people developed an open source method to implement ATM that are back testable in Ninjatrader8. It’s a work that Ninjatrader seems not to understand the importance of it forcing in my opinion their entire customer base to reinvent the wheel or give up. It would also save a lot of time to their support. You might want to go there and check it out. It will save months of work and frustration. I recently saw this work and it will be few months before I get to it and redesign my code starting from theirs. I like it also because they chose the unmanaged route which is the most flexible and most tricky. If you want to trade on Rithmic even trickier. Feel free to ask questions I will try to respond as my memory serves.
An additional note. What I wrote above is the core logic but things are actually more complex. Also you can only cancel orders that have state Working or Accepted. Additionally you’ll need to add a timer to your checks because the delay you’ll experience varies from few hundred mS to a couple of second unless you are in Chicago or using a dedicated server. In California with Fiber to the house I experience 300/600mS typically.
Good Luck
MassGainTrading or MinimumRiskTrading?
Sounds very interesting, do you have the link to that open source implementation…I could not agree with you more when you say Ninjatrader forcing everyone to reinvent the wheel…