Did you try …

I didn’t realise till now, that if the code block set both BUY and SELLSHORT   STOP orders, then there both active and the first one the price breaks, is the order taken, with cumulateorder = false.

However, from your 2nd image,  the trigger candle breaks the LO level and enters the short, but it –> EXIT’s <– the trade to get out, and not by a STOP setting.

That EXIT level is the same level as the long entry, it appears that the Buy stop level was still active and when reached EXIT’ed the short and entered the long.

The long order then exited  the buy at a  STOP level, which I believe was the stop level for the short.

I’m not sure, but I think you can only have one active stop level set, and I would think it would be the latter one executed in code, the short one.

The bar which sets the orders only runs once, so the long stop is overridden with the short stop.

I bet this is same for the targets, and the active target is for the short.

If price reverses when in the long, and didn’t hit the short stop level to exit, I wonder if the trade would continue short at a loss till it hit the short target level.

Though its not noted above, if the stopadjuster  = 1, and buffer = 0,  then all the orders are at different levels, the short hits the buy level before the short stop resulting in the X exit.

Also, then the long hits the short stop just above, and maybe there was never a long target set.

If the stopAdjuster = 0, then the entry levels and  stop levels are at HI and LO,  when the short hits the  level of both the short stop and long Buy, the short now STOP’s out, probably by the short stop level.

The long enters, but is immediately stopped out because of the short stop level I guess is still active.

DEFPARAM CUMULATEORDERS = FALSE // to prevent adding to positions
defparam FLATBEFORE = 094500
DEFPARAM FLATAFTER = 160000
 
Once MaxTrades = 2
//Once BUFFER = 0
//Once PT = 40
 
IF IntraDayBarIndex=0 THEN
TradeCount=0
TradeOn=1
HI =0
LO =0
ENDIF
 
If StrategyProfit>StrategyProfit[1] then
TradeOn=0
EndIf
 
If LongTriggered or ShortTriggered then
TradeCount=TradeCount+1
EndIf
 
If NOT ONMARKET and opentime>=094500 and TradeOn=1 and TradeCount<MaxTrades THEN

HI=High
LO=Low
CandleLength=HI-LO
 
 
BUY CON  CONTRACTS AT HI+Buffer  stop
SELLSHORT CON CONTRACTS AT LO-Buffer  stop
SET STOP PLOSS CandleLength *stopadjuster
SET TARGET pProfit PT
EndIf
 
 
//Graph TradeCount as "TradeCount"
//Graph TradeOn as "TradeOn"
//GraphOnPrice HI as "HI"
//GraphOnPrice LO as "LO"

For me it doesn’t work because the condition is triggered only at 9.45, so it works only if the next candle break out. I’ve corrected the time condition and the stop loss

Noted, Moving the HI;LO; and candleLength update outside the IF NOT ONMARKET block and Adding the > to the  opentime = 0945,  allows further entry’s to be made while between FLATBEFORE/AFTER window.

However, this allows, if not in market, stop orders to be  set, every bar till a order is triggered or condition fails.

One addition I have made to the code is with the setting of HI = 0 and LO = 0, in the INTRADAYBARINDEX = 0  IF block.

When these are set to zero, it affects the y-scale auto zoom, this because the CANDLES and GRAPH keyword, with its variable, are  items that the auto y-scale zoom is triggered by.

This making the candles un-readable, since the lower level of the y-scale goes to  ZERO instead of the lowest CANDLE low being displayed. (bigger Y-range in same panel height)

This means manually re-scale the y-axis, which happens a lot when debugging and re-ADDing to chart to update.

Setting, HI = UNDEFINED and, LO = UNDEFINED, help alleviate this drastic re-scale.

The HI and LO lines, when set to there operational levels, are closer to the candle levels, so not crushing the displayed objects in the panel.

Since undefined is not a value like zero, y-scale is not altered, the drawn line appear to stay at there last valid level. Not yet noticed a down side in doing this!

In reference to my earlier comment, having both BUY and SELLSHORT,  allows a choice of order types depending on price direction breaks, the pre defined levels can be pre set.

These levels don’t require an additional break level condition, which would delay positioning to next bar, but which STOP and TARGET are used with them.

Also, in the same bar, if  both are sequentially executed, how they interact, needs a bit more investigation.

But as in the original code, if conditions are added to test a break, then the order is delayed until next bar.

Using STOP/LIMIT orders, I think the direction the price crossing the order level matters, a candle testing the break, could close, and end up on the wrong side of the later placed type order level.

This means the order not being executed, even if the move was correct to the break test, and in a smaller price move, the missed order may execute on the reverse direction part of the move. Getting in too late and in wrong direction.

There maybe other scenarios which may not be ideal!

Having both orders in the same bar, allows a quicker response since, condition not related to a price break and the bar delay, but could run into other issue as mentioned above.

I doubt its possible to check which of the  orders is currently being executed and make change to the stop/target, all within a single bar.

At this time, reducing the timeframe the orders are executed on, would allow these changes, but I don’t think it would eliminate it 100%, there would always be a  possible short term candle which could trigger both orders in a bar, if big enough, however, this will be more of a remote scenario.

Update!

Another few days see an increase.

Both, back-test and proOrder(demo) detailed reports(closed positions) tracked well until Feb 12th.

On the 12th, the proOrder did a entry and then an exit, for reasons unknown as of yet.

The back-test didn’t do this action.

I’m still looking into it, my speculations is that its something to do with,

. The 1 second timeframe, the small or none exist candles on the TF periods

. The entry being triggered very close to entry threshold, within the spread value.

. The spread may be involved, because the loss was halve the spread.

. maybe the order execution, or something.

What I do no is that back-test did something different t o proOrder(demo)

Screenshot-2025-02-13-161638.png Screenshot-2025-02-13-170042.png