ncel01
17 Jul 2023, 13:26

Dear Spotware team,

Great. Thanks for the prompt action/feedback!

ncel01
17 Jul 2023, 12:55

Dear Spotware team,

Same with Varianse, and probably many other brokers, I have no idea. Please include them all in the calculation.

Thanks.

ncel01
17 Jul 2023, 12:06 ( Updated at: 17 Jul 2023, 12:33 )

Yes, I can confirm that swaps have not been included for indices when backtesting.

Unfortunately, this is just another example where, unlike forex, indices have been overlooked.

@Spotware

Why do you need the cBot code here?

Just run a backtest with any indice and you will get to the same conclusion. As simple as that. 

ncel01
14 Jul 2023, 10:26

Hi Panagiotis,

No, I don't think so. This was the first option I've checked, I guess.

It returns NullReference since no order/position took place. This is the problem here. Apparently, there is no way to access to the operation parameters when trade result is not successful.

ncel01
14 Jul 2023, 09:49

firemyst,

Thanks for your reply.

What I really need is to identify the respective trade operation when trade result is not successful.

I have an auxiliary variable aux[i] that will be set to true before ExecuteMarketOrderAsync(), and I want it to be false in case trade result is not successful. However, I need to exactly know what is the applicable index "i", which can only be taken from the operation label.

I am affraid that the only way to get this done is to create several callback functions from 0 to i_max, and define multiple ExecuteMarketOrderAsync() inside a switch case, each of these with its own callback function as argument.

ncel01
13 Jul 2023, 20:13

firemyst,

Not really. That's simply the error description.

What I want is to access to the trade operation ExecuteMarketOrderAsync() parameters, in this case to the label.
The goal is to know, exactly, which operation has failed: "Position #1" vs "Position #2".

ncel01
30 Jun 2023, 19:34

Hi,

That should be related to the instructions you're providing inside the conditionals.

It is hard to help without looking at the remaining code.

ncel01
30 Jun 2023, 18:54

Hello,

The most likely reason why no trades are being placed:

When there are no open positions, Account.MarginLevel == null, which has a logic value eqivalent to !Account.MarginLevel.HasValue, as it assumes an infinite (NaN) value, therefore, both the conditionals Account.MarginLevel >= MarginRequirement and Account.MarginLevel.HasValue are false.

Try one of the following options, they must be equivalent:

if (Account.MarginLevel >= MarginRequirement || Account.MarginLevel == null)
  // place a trade
}
else
{
  // do not place a trade
}

Alternative:

if (Account.MarginLevel >= MarginRequirement || !Account.MarginLevel.HasValue)
  // place a trade
}
else
{
  // do not place a trade
}

ncel01
28 Jun 2023, 16:39

RE:

Dear Spotware team,

That was not expected but it's clear.

Thanks for informing!

Spotware said:

Dear ncel01,

At the moment market hours and margin are not consider. Both features will be added in a future release. In the meanwhile, please add manual checks before placing a trade.

Best regards,

cTrader Team

ncel01
28 Jun 2023, 10:28

firemyst,

That doesn't answer to my question.

The above has nothing to do with my cBot code. It is only meant to report the issues described.

why aren't you testing margin levels in your code _before_ sending the execute order?

I could also always check if market is open before I place a trade, however that's not the point here.

The order execution is instantaneous when backtesting, but not in real time, while dynamics apply to both cases. However, in the last case, a position will never open if the calculated account margin level after it opens is <100% and, the same should apply to the backtesting.

The requirements to place an order, among other, when backtesting should be exactly the same as when you're running your code in real time. Uniformity between these cases is not something you must code.

In fact, margin and market hours are the most basic requirements in training when it comes to open a trade. Therefore, it gets hard to understand why these are dismissed when backtesting.

ncel01
23 Jun 2023, 09:23

Dear Spotware team,

Kind request to advise on the above or, alternatively, to share any available documentation regarding this.

Thank you.

ncel01
22 Jun 2023, 14:34

Hello,

1. The limits are per trader connection.

Per cTrader ID (user) or, per cTrader running instance/account? This is not clear to me.

2. The limits have not been imposed on live trading accounts yet but they might be imposed if deemed necessary.

Right. In such a case will this be explicitly announced? In advance?

As far as I can see, restrictions are completely unbalanced with regard to their the purpose, where the allowed rate for very likely operations is only 5% ( max. of 100 vs 2000 requests per min.) of that for not so likely operations.

Example:

ModifyPendingOrder(): Very likely to be used more that 100x/min. when managing multiple pending orders OnBar()/OnTick() to avoid any market orders.

ClosePosition()/ModifyPosition(): Not likely at all to be called 2000x/min.

3.

Is in Spotware's plans to effectively improve it's applications performance in parallel with such restrictions?

I believe that such restrictions can remediate any existing problem but will not solve it.

Thanks for informing.

ncel01
21 Jun 2023, 16:55 ( Updated at: 21 Jun 2023, 16:59 )

Dear Spotware team,

Thanks for arranging this info. It is important for traders to be aware of such limitations.

As far as I can see, these limits are only applicable to demo accounts.

1. Are these the overall (cTrader ID) limits or, are these the limits per trading account?

2. Do any limits apply to live accounts?

Thank you.

ncel01
20 Jun 2023, 10:56

Dear Spotware team,

Could you please provide further details as this seems to be a high limitation regarding automated trading?

Why are cBots treated as "hackers" by the server(s) and how to prevent this?

Thank you.

ncel01
19 Jun 2023, 13:11

Hi firemyst,

I suppose that your account currency is AUD and that's for currency conversion purposes.

ncel01
19 Jun 2023, 10:17

Dear Spotware team,

You're welcome!

Please be aware that, most probably, this is not the only case for which visual and non-visual backtest are providing different results.

Question:

What priority is given, by the the API, to the events when this occur at the exact same moment?

In my case, I need to be aware of this so that the correct cBot logic can be implemented.

Thanks.

ncel01
16 Jun 2023, 14:07

Dear cTrader team,

Any feedback on this issue?

ncel01
15 Jun 2023, 20:35

Panagiotis,

After investigating further what could be the reason for this issue, I was able to generate a simple cBot sampe that will allow anyone to reproduce it, I believe (comments included):

using System;
using cAlgo.API;

namespace cAlgo.Robots
{
    [Robot(AccessRights = AccessRights.None)]
    public class SamplecBot : Robot
    {
        // --> STEP NOT WORKING PROPERLY ( A step of 0.1 instead of 0.01 is being applied to this parameter ! )
        [Parameter("Volume in lots :", DefaultValue = 0.01, MinValue = 0.01, Step = 0.01)]
        public double VolumeInLots { get; set; }

        protected override void OnStart()
        {
            Positions.Opened += Positions_Opened;
            PlacePendingOrder();
        }

        private void Positions_Opened(PositionOpenedEventArgs obj)
        {
            if (Positions.Count < 10)
                PlacePendingOrder();
        }

        private void PlacePendingOrder()
        {
            var direction = TradeType.Buy;
            var volume = Symbol.QuantityToVolumeInUnits(VolumeInLots);
            var distanceInPips = 50;
            var entryPrice = direction == TradeType.Buy ? Symbol.Ask - distanceInPips * Symbol.PipSize : Symbol.Bid + distanceInPips * Symbol.PipSize;
            var stopLossInPips = 50;
            var takeProfitInPips = 50;

            PlaceLimitOrder(direction, SymbolName, volume, entryPrice, null, stopLossInPips, takeProfitInPips);
        }

        protected override void OnTick()
        {
            // Below is the reason why visual and non-visual mode deliver different results when backtesting
            // It seems like there is an overlap of the trading events ( Positions_Opened() and OnTick() ) when not in visual mode
            // It also seems that OnTick() is called multiple times and that this value is increasing by 1 each time 
            // Multiple pending orders are being placed : the number of "same" positions is getting cumulative ( see Entry Time in history tab )
            // Entry Time A: 1 position is opened
            // Entry Time B: 2 positions are opened
            // Entry Time C: 3 positions are opened
            // Entry Time D: 4 positions are opened
            // Etc.
            if (PendingOrders.Count == 0)
                PlacePendingOrder();
        }
    }
}

ncel01
15 Jun 2023, 15:09 ( Updated at: 15 Jun 2023, 15:10 )

Hi Panagiotis,

Yes, I understand.

I am still trying to figure out what can be the problem but it should not be related to my code.

I suspect this is related to the way the trading events are handled.

Are you aware how priority on execution is assigned to the events in case these are triggered at the exact same moment? For instance: OnBar(), Positions_Opened(), Positions_Closed(), etc.

I still can try to create a bot sample that reproduces this behaviour so this can be further checked.

Thank you!

ncel01
06 Jun 2023, 12:16

firemyst,

I understand.

Unfortunately, unlike Forex, min. trading quantities on indices are not standardized among all the brokers, making it a real "salad".

However, some (few) brokers allow quantities as from 0.01 lots/units on these instruments. Still far below 0.1.