No Status returned when some orders are cancelled

[moscu]

I am seeing a problem that occurs exporadically. When I submit an order and then I cancel it the status is empty. This block me from trading the symbol since I can not find what happened to the order. Attached is an example from the NT logs.

[NinjaTrader_Ben]

Hello,

I do not see the logs attached.

Have you tried using TraceOrders to follow the orders:

http://www.ninjatrader-support.com/HelpGuideV6/helpguide.html

Are you getting any errors in your log tab?

[NinjaTrader_JoshP]

Also, just to confirm: These are manual/ATM strategy trades correct? Or are they NinjaScript Strategy trades?

[moscu]

Here is the log

This are orders sent with the NTDirect.dll from tradestation. I pasted the file below. When I submit the order I keep calling the NtStatus(OrderID). THis is done every tick in the chart. Also when I just submit an order I also get an empty status instead of Pending Submit which is logged in the NT gui logs. It takes couple ticks before the status is not empty. This is a problem because I can not differentiate between "Order just submitted", or "Order cancelled". Anyways the status of a valid order should always be returned. If the order does not exist the status should also say so. I can not guess in my code what is status, it is too dangerous.


9/10/2008 00:59:16,ATI,OIF, 'Cancel;;EURAUD;;0;;0;0;;;BUY-EURAUD-1080910-59-4-STOPLIMIT-1.7552-1.7554;;' order with ID/Name'BUY-EURAUD-1080910-59-4-STOPLIMIT-1.7552-1.7554' does not exist
9/10/2008 00:59:16,ATI,AT, 'Cancel;;EURAUD;;0;;0;0;;;BUY-EURAUD-1080910-59-4-STOPLIMIT-1.7552-1.7554;;' processing
9/10/2008 00:59:13,ATI,OIF, 'Cancel;;EURAUD;;0;;0;0;;;BUY-EURAUD-1080910-59-4-STOPLIMIT-1.7552-1.7554;;' order with ID/Name'BUY-EURAUD-1080910-59-4-STOPLIMIT-1.7552-1.7554' does not exist
9/10/2008 00:59:13,ATI,AT, 'Cancel;;EURAUD;;0;;0;0;;;BUY-EURAUD-1080910-59-4-STOPLIMIT-1.7552-1.7554;;' processing
9/10/2008 00:59:13,ATI,OIF, 'Cancel;;EURAUD;;0;;0;0;;;BUY-EURAUD-1080910-59-4-STOPLIMIT-1.7552-1.7554;;' order with ID/Name'BUY-EURAUD-1080910-59-4-STOPLIMIT-1.7552-1.7554' does not exist
9/10/2008 00:59:13,ATI,AT, 'Cancel;;EURAUD;;0;;0;0;;;BUY-EURAUD-1080910-59-4-STOPLIMIT-1.7552-1.7554;;' processing
9/10/2008 00:59:12,ATI,OIF, 'Cancel;;EURAUD;;0;;0;0;;;BUY-EURAUD-1080910-59-4-STOPLIMIT-1.7552-1.7554;;' order with ID/Name'BUY-EURAUD-1080910-59-4-STOPLIMIT-1.7552-1.7554' does not exist
9/10/2008 00:59:12,ATI,AT, 'Cancel;;EURAUD;;0;;0;0;;;BUY-EURAUD-1080910-59-4-STOPLIMIT-1.7552-1.7554;;' processing
9/10/2008 00:59:06,ATI,OIF, 'Cancel;;EURAUD;;0;;0;0;;;BUY-EURAUD-1080910-59-4-STOPLIMIT-1.7552-1.7554;;' order with ID/Name'BUY-EURAUD-1080910-59-4-STOPLIMIT-1.7552-1.7554' does not exist
9/10/2008 00:59:06,ATI,AT, 'Cancel;;EURAUD;;0;;0;0;;;BUY-EURAUD-1080910-59-4-STOPLIMIT-1.7552-1.7554;;' processing
9/10/2008 00:58:11,Order,Submitting order without strategy...,
9/10/2008 00:58:11,ATI,AT, 'PLACE;DU43199;EURAUD;BUY;0;STOPLIMIT;1.7554;1.755 2;DAY;;BUY-EURAUD-1080910-59-4-STOPLIMIT-1.7552-1.7554;;' processing

[NinjaTrader_JoshP]

Not sure what you are trying to do. Because of multi-threading you cannot rely on order status to make your trades. The status of the order is returned when it is available. You can have ticks before your order status is available.

Why are you not able to distinguish between PendingSubmit and PendingCancel? If there is an order in place you will receive those states eventually.

[Rocket130713]

Hello,

Josh, what do you mean by your statement in your most recent post, that due to multi-threading OrderState() function cant be relied upon, to handle orders and trades?

Will calling OrderState() always return a string after a certain amount of time (ie eventually, say even after 2 minutes) when it becomes available?

Please explain when this function might fail, or return an incorrect string, or might return a string very late ie after say 10 minutes?

thanks in advance.

regards

Rod

[moscu]

Empty status

I can distinguish between PendingSubmit and PendingCancel the problem is as you mentioned some ticks are not retuning a status. You should always return some string when I submit the order it should be PendingSubmit or if I send a cancel order then PendingCancel. The problem is when I get an empty string. Sometimes I submit an order and I get no status back then before getting PendingSubmit the price has move too much and I need to cancel it. I send a cancel and still empty returned is sent now I do not know if the order is being submitted or being cancelled.

I need a status return ALWAYS. Sometimes the order is submitted and then cancel, I keep inquiring for status and I keep getting empty. My system is totally automatic so the code can not discard the order because it could have been filled so the chart becomes "disabled" because no more orders are send from it.

Moscu

[NinjaTrader_JoshP]

Rod,

By cannot be relied upon I mean you cannot rely on expecting a set sequence of events to come in order.

OrderState() will return whenever the status is available. There is no "time" limitation.

The function will never return an incorrect string. The issue is that the time it takes for your computer to process the order state, the order state may already be something else.

Moscu,

Are you saying you are seeing this sequence of events now?
PendingSubmit
null
null
PendingCancel

or are you having difficulties with this sequence
send order
null
null
PendingSubmit
PendingCancel

[moscu]

I have problem with the second sequence. To put it simply I have problem with a null status string returned.


Moscu

[NinjaTrader_Ray]

Unfortunately this is possible. The reason is that internally, an order goes from Initialize --> PendingSubmit state. I suspect that null string is returned when the order is in the Initialize state. This state is not exposed in the ATI. I don't recall why this decision was made but it is by design and how it currently works. Initialize to PendingSubmit state change happens in a split second.

[moscu]

There should never be a null state. It should always return something specially when null is returned in two instances. One like described before and sometimes when an order does not exist or it is cancelled. There is no way for the client to know for sure what the state of the order is. I am daytrading and sometimes the markets move very fast. This should be fix in the next release just return "Initializing" as a state instead of null. Also if the order does not exist just return an indication of this fact, like unknownOrder.


Moscu

[moscu]

FYI,

My current setup is as follows:

I run tradestation in one computer and TS+IB in another computer. This might explain why you have not seen this scenario. I need to run a large number of charts and I can not run the three applications in one single computer.

Moscu

[Rocket130713]

Mocsu is spot on. and i like Moscu's idea of OrderStatus() returning "Unknown Order" when you first load up the charts and strategies say on a monday morning and the last order was say done on the previous Friday afternoon.

but straight after an order is sent by tradestaion and esignal, NT OrderStatus() should return "initialized". if this could be fixed in the next build that would be great.

[Rocket130713]

Hi Ray,

Regarding your reply in your post below, Im trying to differentiate between 2 different events. event 1 is when there is no record of an order, in this case OrderStatus() returns empty string (this event happens when we close down and re-open NT platform on a daily basis and then call OrderStatus() function). event 2 is an event that occurs straight after an order has been sent, in this case OrderStatus() also returns an empty string. In the case of event 2, it would be much better if calling OrderStatus() returned a string called "initialized", as then my code could differentiate between event 1 and event 2. In your help guide in appendixes, it states that this is what is supposed to happen, both in reality it does not work this way, instead i get an empty string for both event 1 and event 2. this is causing us a very serious problem in that it can cause unwanted trades to fire off as a result.

we are using a unique set-up that splits large orders into many small orders for execution.

Many thanks. look forward to your reply.

regards

Rod

[NinjaTrader_JoshP]

Rod,

Why can't you differentiate the first event with another measure? You can try using some flag variable that is evaluated only at the start.