Guia Técnico: Limite Operações por Período no MQL5

Quando você tenta proteger um Expert Advisor contra sobre‑trading, a primeira dor de cabeça costuma ser: “Como impedir que ele abra mais de X ordens em 5 minutos?”. No MQL5 isso não é automático; você tem que montar o controle temporal na própria lógica. A seguir, mostro passo a passo o que realmente funciona no mercado real, onde latência, gaps e reconexões podem quebrar a contagem.

Controle temporal com TimeCurrent()

• Armazene o timestamp da última operação. Use uma variável estática ou global — por exemplo datetime lastTradeTime = 0;.
• Compare antes de abrir. Se TimeCurrent() - lastTradeTime < PeriodSeconds (onde PeriodSeconds = 300 para 5 min), bloqueie a ordem.
• Atualize somente após confirmação. Só depois que OrderSend() retornar TRADE_RETCODE_DONE você grava lastTradeTime = TimeCurrent();.

Gestão de múltiplas ordens

Um único timestamp não basta quando o EA pode abrir posições em símbolos diferentes. Crie um std::map que associe ticket ao horário de abertura. Assim, ao chegar ao limite, basta percorrer o mapa e contar quantas entradas ainda estão dentro da janela.

Exemplo prático

int MaxOps = 3; int WindowSec = 300; // 5 minutos static std::map trades; bool CanOpen() { datetime now = TimeCurrent(); int cnt = 0; for(auto it = trades.begin(); it != trades.end(); ) { if(now - it->second > WindowSec) // expira entradas antigas it = trades.erase(it); else { ++cnt; ++it; } } return cnt < MaxOps; } 

Chame CanOpen() antes de cada OrderSend(). Se retornar false, registre o motivo no log e aguarde o próximo tick.

Armadilhas comuns

• Dependência de TimeCurrent() – em servidores com horário desajustado o cálculo falha. Verifique TimeGMT() ou sincronize via NTP.
• Requisições assíncronas – se usar OrderSendAsync(), a resposta pode chegar depois da verificação, permitindo duas ordens quase simultâneas. A solução é bloquear a thread até o retorno.
• Reabrir após stop‑out – o ticket desaparece, mas o timestamp permanece no mapa, contaminando a contagem. Remova entradas de tickets inexistentes com HistorySelect().

FAQ relâmpago

• Posso usar EventSetTimer()? Sim, mas o timer introduz latência extra; o método acima já filtra em tempo real.
• E se eu precisar de limites diferentes por símbolo? Crie um std::map de limites e ajuste MaxOps dinamicamente.
• O que fazer quando o servidor reinicia? Salve trades em um arquivo .csv e recarregue no OnInit().

Implementar esse controle pode parecer detalhe, mas na prática ele impede que um algoritmo faminto “engula” todo o capital em segundos. Se quiser aprofundar, veja a documentação oficial de MQL5 sobre timers e eventos – vale a leitura para fechar as brechas restantes.

Primeiros passos após a compra

1. Baixe o arquivo .mq5 do fornecedor.

2. Abra o MetaEditor (Ctrl+F4) e importe o script via File → Open.

3. Compile. Erros de sintaxe interrompem a criação da classe PeriodLimiter. Corrija imediatamente antes de prosseguir.

Configuração inicial

Defina os parâmetros essenciais no cabeçalho do EA:

Altere os valores no Inputs da janela de propriedades do EA. Salve e anexe ao gráfico desejado.

Checklist operacional – rotina recomendada

• Verificar horário de mercado: o script só inicia após MarketInfo(Symbol(), MODE_TRADE_TIME).
• Reset diário: inclua if(TimeDay(TimeCurrent())!=TimeDay(last_reset)) ResetCounters(); no OnTick().
• Contagem de ordens: use int total=OrdersTotal(); e filtre por OrderSymbol() e OrderMagicNumber().
• Log de eventos: Print("Limite diário atingido – trade bloqueado") para auditoria.
• Teste em conta demo: execute 48 h antes de migrar para produção.

Fluxograma simples de decisão

O fluxo abaixo resume a lógica de bloqueio:

Início → Horário permitido? → Sim → Limite diário atingido? → Não → Limite horário atingido? → Não → Executa trade → Atualiza contadores → Fim

Erros comuns e como evitá‑los

• Contadores não resetam: assegure que a variável last_reset seja atualizada ao mudar de dia.
• Trades fora do horário: verifique a zona de tempo do servidor (GMT) e ajuste reset_time conforme necessário.
• Conflito de MagicNumber: use um identificador único por estratégia para que a contagem não inclua ordens de outros EAs.

Sinais de progresso – mini dashboard textual

Adicione ao final do OnTick() um bloco de impressão resumido:

 PrintFormat("Dia %d – Trades: %d/%d (horário %d/%d)", TimeDay(TimeCurrent()), daily_counter, max_trades_per_day, hourly_counter, max_trades_per_hour); 

Monitorar esse output no Experts permite validar rapidamente se os limites estão sendo respeitados.

Ferramentas complementares

Para automatizar a visualização dos limites, integre o EA ao MetaTrader 5 Dashboard. Ele cria um painel de indicadores que mostra os contadores em tempo real, reduzindo a necessidade de abrir o log.

Com esses passos, a limitação de operações por período deixa de ser um conceito e passa a ser um mecanismo robusto, pronto para ser testado, ajustado e escalado.

Perfil ideal e limites práticos de “Como limitar operações por período utilizando MQL5”

Se você busca disciplina automática na sua estratégia, este recurso pode ser a peça que faltava; se prefere ajuste manual em tempo real, ele será mais um obstáculo.

Quem deve considerar

• Traders que operam em múltiplos timeframes e precisam evitar overtrading nas sessões de alta volatilidade.
• Desenvolvedores que já trabalham com MQL5 e desejam incorporar regras de tempo sem reescrever a lógica de entrada.
• Gestores de fundos pequenos que impõem políticas de “max trades per hour” para controle de risco.

Quem provavelmente não terá bom aproveitamento

• Iniciantes que ainda não dominam o básico de eventos de mercado; a camada extra de tempo pode confundir.
• Operadores de scalping puro que dependem de execução a cada tick; a restrição temporal pode cortar oportunidades críticas.
• Quem usa plataformas alternativas (MT4, cTrader) – o código não é compatível sem adaptação completa.

Limitações contextuais

O módulo assume que o calendário de mercado está sincronizado ao servidor da corretora. Em corretoras com atraso de feed, a contagem pode divergir da expectativa.

Não há verificação automática de eventos macro (federais, anúncios de taxa). Se o período bloqueado coincidir com um calendário econômico importante, a estratégia ficará “cego”.

O bloqueio de operações ocorre apenas no nível de ordem. Se você usa hedging interno que abre múltiplas posições simultâneas, cada ordem será considerada separadamente, potencializando o limite.

FAQ contextual

Checklist rápido antes da implementação

• Confirmar horário do servidor da corretora (GMT+0?)
• Mapear sessões críticas que deverão ser excluídas da contagem
• Testar em conta demo com histórico de ao menos 3 meses
• Adicionar logs de Print() para validar o reset diário
• Garantir que o código de limite rode no OnTick() e não apenas no OnInit()

Parecer editorial equilibrado

O recurso entrega o que promete: uma camada de controle temporal robusta para quem já domina MQL5. Não é um “plug‑and‑play” que salva traders de decisões ruins; é um filtro disciplinar que só funciona se a lógica subjacente for sólida. Em ambientes com feeds estáveis e estratégias que toleram pausas programadas, ele reduz significativamente o risco de execuções excessivas.

Mini cenários reais

Cenário A: Um trader de EUR/USD faz 12 trades por hora durante o horário de Londres. Ao limitar a 6, ele reduz o drawdown em 30 % nos testes, mantendo a mesma taxa de acerto.

Cenário B: Uma estratégia de breakout na sessão asiática perde 40 % das oportunidades porque o limitador foi configurado para 2 trades/hora – neste caso, a disciplina supera a necessidade de captura.

Próximos passos recomendados

Implemente o módulo em um Expert Advisor de teste. Monitore a geração de logs por 48 h e ajuste o “offset” de início de sessão conforme o horário de sua corretora. Quando os números estabilizarem, considere combinar com filtros de volatilidade para evitar o efeito “corte” durante eventos econômicos.

Quer aprofundar? Acesse a página oficial