Bj

La ligne 11 renvoie la valeur ‘M3myTrend’ de l”appel’ de ‘Extratrend’. Mais vous définissez immédiatement la ligne 13 ‘M3myTrend’ ‘égal à fermer’. Par conséquent, les conditions “Si” aux lignes 16, 19 peuvent ne pas être remplies correctement.
De plus, vous n’envoyez aucune valeur par défaut à ‘Extratrend’, [,0,0,0,0,0,0] est-ce correct !.
Vous ne savez pas à quelle “timeframe” vous faites référence, graphique, ligne1, ligne6.
2nd…L’instruction de la timeframe doit être égale ou multiple de la timeframe par défaut du graphique.
2ndTF/default=entier = oui
5/1 = 5 =oui
5/3 =1,7 = non

J’ai écrit des trucs de recherche de pannes sur un autre post, vérifiez-le, cela peut aider.

https://www.prorealcode.com/topic/strategy-stop-because-an-index-in-an-array/

Les images trop petites ne pouvaient pas être lues

timeframe(1 minute, default)

myBaseM3=1

//timeframe(1 hour, updateonclose)
timeframe(5 minutes, updateonclose)  // 

if myBaseM3=1 then

// Appel des valeurs d'ExtraTrend
M3myTrend, ignored, ignored, ignored, ignored = CALL "ExtraTrend"[0,0,0,0,0,0](close)
//M3myTrend, ignored, ignored, ignored, ignored = CALL "ExtraTrend"[?,?,?,?,?,?](close)  ??????????????

////M3myTrend=close  //  ?????????????
// Tendance ExtraTrend
if M3myTrend>M3myTrend[1] then
M3tendance=1
endif
if M3myTrend<M3myTrend[1] then
M3tendance=0
endif

endif

return

En supposant que ‘ExtraTrend'(ET) fonctionne sur toutes ces périodes (TF).
J’ai réécrit le code pour découpler ‘myBaseM3’ du 5m TF.
Étant donné que le TF du graphique par défaut (DF) est de 1 m, l’instruction TF de 1 m peut être supprimée.
Il suffit d’utiliser le 5mTF pour générer des données à partir de ‘ET’. Introduisez les instructions ‘IF’ dans DF TF.
Ne savez pas pourquoi vous recevez des messages d’erreur, la logique fonctionne bien, peut-être un problème avec ET et certains TF. Les unités chargées du DF TF doivent être prises en compte lors de l’utilisation de TF supplémentaires plus élevés. Cela n’explique pas l’erreur 3mTF. Peut-être un problème de logique de croisement entre les TF).
Qu’est-ce que cela fait!

En ce qui concerne les images, les deux premières donnent l’impression que l’image est sur plusieurs moniteurs ou ultra larges.
Lorsque vous cliquez dessus, dans un seul moniteur, la taille est réduite pour obtenir la largeur qui convient. Aggravé si le moniteur de visualisation est en orientation portrait. La troisième taille d’image était correcte.

myBaseM3=1

//timeframe(1 hour, updateonclose)  // 1hr=3600units @1mTF
timeframe(5 minutes, updateonclose) // 5m=5units @1mTF
M3myTrend, M3myNeutral, M3myExpansion, M3ignored, M3ignored = CALL "ExtraTrend"[0,0,0,0,0,0](close)

timeframe(default)  // default 524units @1m
if myBaseM3=1 then

// Tendance ExtraTrend
if M3myTrend>M3myTrend[1] then
M3tendance=1
endif
if M3myTrend<M3myTrend[1] then
M3tendance=0
endif

endif

return

Je pensais que votre code était la pointe d’un iceberg avec la variable ‘myBaseM3’.

Les erreurs affichent généralement une boîte laide selon le principe du premier arrivé, premier servi.

Dans cet esprit, isoler ‘ET’ “seul” dans le 5m TF, élimine cela de l’équation, fait-il toujours une erreur avec différents paramètres de TF.
Cela évite que la logique croise les TF, au cas où cela ferait partie de l’erreur. La logique de croisement entre les TF semble être correcte, mais je n’ai pas demandé à ET de faire mes propres tests de différentes combinaisons.

À ce stade, il suffit de trouver ce qui fonctionne et ce qui ne fonctionne pas.

Je comprends que vous le fassiez de cette façon pour certaines raisons, mais même si quelqu’un vous dit exactement pourquoi cela ne fonctionne pas, vous devrez peut-être encore modifier la structure. Mais cela pourrait être un problème facile à résoudre ou à atténuer si l’alternative consiste à demander à PRC ou aux codeurs de l’indicateur de modifier leur code. Pas impossible cependant, cela peut prendre du temps.

Je suis tombé sur un flux de blog, que j’ai pensé à ET, dans la mesure où je l’ai vu utilisé sur les mTF, mais pas jusqu’aux TF que vous proposez, et ET n’avait que 5 paramètres d’entrée, il doit donc s’agir d’une version antérieure.
Vous pourriez trouver quelqu’un là-bas pour demander/tester.

Je ne savais pas que vous ne pouviez publier que 4 images, merci pour cela, pas encore atteint cette limite, je suis sûr que vous pourriez en publier d’autres après dans un 2e message “images supplémentaires”, cela vous donnerait jusqu’à huit.

https://www.prorealcode.com/topic/extratrend-exemples-de-codage-screeners-et-programmation-personnalisee/

Bonjour,

A première vue, je dirais que si on fait appel à une valeur d’un indicateur que l’on sort d’une autre UT et qu’on utilise cette même valeur dans une seconde UT, je dirais qu’il est normal d’avoir une erreur. J’exploiterai chaque valeur en faisant appel à l’indicateur dans chaque UT visée.

En revanche, “erreur inconnue”, je ne pourrai vous aider, sachant que c’est un message côté Prorealtime.

Alex Bj
Ne pas avoir “ExtraTrend” limite ma capacité de recherche de pannes, mais j’ai essayé de recréer des erreurs avec un autre indicateur, ce n’était pas si difficile à faire.

Depuis votre premier message, les erreurs que je vois suivent le schéma que vous avez décrit.

Cela m’amène à pencher vers un problème de PRT.

Dans mon code de test, en utilisant (5 minutes, 3 minutes, 1 heure)
donne le “Erreur: commande inconnue” comme vous l’avez observé avec votre code.

Comme je pouvais recréer les erreurs et les tester, cela m’a rappelé quelque chose que j’avais découvert par accident il y a quelque temps avec l’instruction ‘timeframe’, mais pas du point de vue de l’erreur.

Essayez de remplacer (5 minutes, 3 minutes, 1 heure) par (300 secondes, 180 secondes, 60 minutes). Vous n’aurez peut-être pas à le faire avec tous, mais le message “Erreur : commande inconnue” n’apparaît pas sur mes tests.

Mon indicateur de test semble bien fonctionner après le changement, si cela fonctionne pour vous et “ExtraTrend” nous le ferons “, vous devrez le découvrir et me le dire.