Vous avez déjà un temps de cycle — extrait du G-code, sorti du CAM, ou fourni par un outil de suivi. Le problème n'est pas d'obtenir un chiffre ; c'est que ce chiffre ne correspond pas à ce qui se passe réellement en atelier. Ce guide ne vous apprend pas à construire un pipeline d'extraction de temps de cycle depuis zéro — voir notre guide en 7 étapes pour cela. Il vous aide plutôt à diagnostiquer pourquoi votre estimation actuelle est fausse, en utilisant la forme même de l'écart comme premier indice.
En bref :
La forme de l'écart — uniforme, limité aux pièces courtes, variable d'une exécution à l'autre, apparu soudainement, désaccord CAM/contrôleur, ou spécifique à une machine — pointe vers une cause différente, avant même de toucher au modèle de calcul.
La plupart des équipes relancent tout leur modèle d'extraction alors qu'une seule donnée est en cause ; un test de tri de 10 minutes isole généralement la cause plus vite qu'un ré-audit complet.
Une fois le motif identifié, la correction se résume presque toujours à l'une de ces quatre actions : modéliser l'override, modéliser l'accélération, séparer les événements déterministes des événements stochastiques, ou réconcilier le programme exécuté avec le fichier de référence.
Commencez ici. Faites correspondre ce que vous observez à la ligne la plus proche, puis passez directement à la section correspondante.
| Ce que vous observez | Cause la plus probable | Premier test à effectuer |
|---|---|---|
| Le temps réel est plus long sur chaque job, à peu près dans les mêmes proportions | Feed override, montée en régime de la broche ou déplacement rapide non modélisés | Comparer le feed override moyen relevé en télémétrie à l'hypothèse de 100 % programmé |
| L'écart n'apparaît que sur les programmes à segments courts ou petites pièces | Modèle géométrique simple qui ignore l'accélération/le jerk | Isoler un segment court, le simuler avec et sans profil cinématique |
| Même programme, résultat différent à chaque exécution | Événements stochastiques (tâches opérateur, sondage variable) mélangés à des événements déterministes | Exécuter 5 à 10 cycles, comparer médiane et écart-type |
| L'écart est apparu soudainement, il n'était pas là avant | Dérive de révision du programme, usure/offset d'outil, mise à jour du contrôleur ou du post-processeur | Comparer le programme exécuté au fichier de référence |
| Le CAM et le contrôleur ne s'accordent pas, même en marche à vide sans opérateur | Post-processeur insérant des temporisations/rampes invisibles, ou expansion de cycles fixes différente | Comparer la sortie posted du CAM au programme réellement chargé sur la commande |
| Le même programme est juste sur une machine, faux sur une autre | Profil cinématique non spécifique à ce modèle de machine ou à cette version de firmware | Comparer les profils machine enregistrés aux caractéristiques réelles de la machine physique |
Si plusieurs lignes s'appliquent à la fois, travaillez du haut vers le bas — les causes à effet uniforme sont les plus rapides à confirmer ou écarter et expliquent souvent une partie d'un écart plus complexe.
Quand chaque job — long ou court, simple ou complexe — dure un peu plus longtemps que prévu, à peu près dans le même pourcentage, la cause est généralement quelque chose qui s'applique uniformément sur tout le cycle plutôt qu'un problème isolé dans un déplacement précis.
Feed override en usage courant. Les opérateurs ou les planificateurs font souvent tourner la production à un pourcentage différent de 100 % de l'avance programmée. Cela n'apparaît jamais dans le texte du G-code, seulement dans la télémétrie du contrôleur.
Montée en régime de la broche. Atteindre le régime programmé prend quelques secondes à chaque changement d'outil ; sur des programmes avec de nombreux changements d'outil, cela s'accumule vite et est rarement modélisé.
Hypothèses sur les déplacements rapides. Traiter les déplacements G0 comme instantanés, ou appliquer la vitesse rapide d'un seul axe à un déplacement multi-axes, sous-estime le temps de déplacement rapide.
Récupérez le pourcentage moyen de feed override depuis la télémétrie du contrôleur sur un échantillon représentatif de runs, et comparez-le à l'hypothèse de 100 % utilisée dans votre estimation. Si la moyenne se situe entre 85 et 95 % plutôt qu'à 100 %, vous avez probablement trouvé l'essentiel de l'écart. Si les overrides semblent normaux, vérifiez ensuite la montée en régime de la broche et la gestion des déplacements rapides.
Visualisez exactement le feed override réellement appliqué sur vos machines, en temps réel, sans dépendre d'une déclaration manuelle des opérateurs.
Découvrir le suivi de production JITbaseSi les usinages longs et réguliers correspondent bien à l'estimation, mais que les petites pièces ou les trajectoires riches en arcs sont systématiquement sous-estimées, c'est le modèle géométrique lui-même — distance divisée par avance programmée — qui pose problème, pas une donnée manquante isolée.
Le calcul simple distance/avance suppose que la machine atteint instantanément sa vitesse programmée. En réalité, les limites d'accélération des axes, les filtres de limitation du jerk et le comportement en virage font que les segments courts passent une part significative de leur temps à accélérer et décélérer plutôt qu'à couper à vitesse stable. Plus le segment est court, plus l'erreur est grande — souvent 10 à 30 % sur les programmes denses en déplacements courts. Pour la méthode complète de construction d'un modèle cinématique plutôt que géométrique, voir notre guide d'extraction du temps de cycle à partir du G-code.
Isolez un segment court représentatif. Calculez son temps de deux façons : la formule géométrique simple, et une simulation cinématique qui tient compte de l'accélération des axes et du comportement de raccordement de la machine. Si les deux résultats divergent de plus de 10 % environ, le programme a besoin d'une modélisation cinématique plutôt que d'une approximation géométrique — pas seulement pour ce segment, mais pour toute cette famille de jobs.
Une certaine variabilité entre les runs est normale. La question diagnostique est de savoir si cette variabilité est du bruit aléatoire, ou si elle masque un événement déterministe que vous n'avez pas isolé.
Les tâches liées à l'opérateur — chargement/déchargement, inspection en cours de production, ébavurage, sondage occasionnel — sont parfois déterministes (se produisent à chaque cycle, avec une durée à peu près constante) et parfois stochastiques (se produisent occasionnellement, ou avec une durée variable selon la pièce ou l'opérateur). Traiter un événement déterministe comme s'il faisait partie du temps d'usinage fixe, ou noyer un événement stochastique dans la moyenne, produit un temps de cycle techniquement correct en moyenne mais faux pour n'importe quel run pris individuellement.
Exécutez ou récupérez 5 à 10 cycles du même job et calculez la médiane et l'écart-type. Une dispersion serrée autour de la médiane indique un processus majoritairement déterministe — l'écart avec votre estimation est alors une valeur fixe qui vous manque. Une dispersion large indique un événement stochastique ; isolez-le et modélisez-le comme une allocation ou une probabilité plutôt que comme un ajout fixe.
C'est le motif le plus urgent à investiguer, car il signifie généralement qu'un changement a eu lieu — et ce qui a transformé une estimation juste la semaine dernière en estimation fausse cette semaine mérite d'être identifié avant que cela n'affecte d'autres jobs.
Dérive du programme. Le programme réellement exécuté sur la machine n'est pas celui contre lequel vous chronométrez — une modification a été faite directement à la commande et n'a jamais été resynchronisée avec le fichier de référence.
Usure ou changement d'offset d'outil. Un outil usé ou un offset ajusté peut modifier le comportement d'usinage réel sans que le texte du programme change.
Mise à jour du firmware du contrôleur ou du post-processeur. Une mise à jour firmware peut changer le lookahead, le raccordement ou le comportement des cycles fixes ; une mise à jour du post-processeur peut silencieusement modifier la façon dont les temporisations ou les rampes sont insérées dans les prochains posts.
Comparez le programme réellement exécuté sur le contrôleur à votre fichier de référence enregistré. S'ils correspondent, vérifiez le journal de maintenance et d'outillage sur la période concernée avant de chercher ailleurs — une mise à jour firmware ou post-processeur est un événement à l'échelle de l'atelier, pas d'un seul job ; vérifiez donc si d'autres jobs sur la même machine ou la même cellule montrent un décalage similaire.
Si une marche à vide sur le contrôleur — sans intervention manuelle, sans variabilité opérateur — ne correspond toujours pas au temps estimé ou posted par le CAM, le désaccord se situe entièrement dans le logiciel, et il vaut la peine de le résoudre avant de valider quoi que ce soit d'autre par rapport à ce programme.
Insertions cachées du post-processeur. Certains post-processeurs ajoutent des temporisations, des rampes de broche ou des déplacements de sécurité qui apparaissent dans le fichier posted mais ne sont pas évidents à la lecture rapide.
Différences d'expansion des cycles fixes. Les contrôleurs Fanuc, Siemens et Heidenhain peuvent développer le même cycle fixe en séquences de déplacements et de temporisations différentes ; le logiciel CAM peut supposer un comportement alors que le contrôleur en exécute un autre.
Comparez le fichier de sortie posted du CAM, ligne par ligne, au programme réellement chargé et exécuté sur le contrôleur. S'ils sont identiques et que les temps divergent toujours, la différence se situe dans le comportement d'interpolation ou d'expansion de cycles fixes du contrôleur — cela vaut la peine d'être signalé au fabricant du contrôleur si ce n'est documenté nulle part.
Arrêtez de deviner la variabilité d'un run à l'autre. Visualisez les interventions opérateur, les changements d'outil et le temps d'usinage détaillés séparément, par cycle, sans étude de temps manuelle.
Découvrir le suivi machine JITbaseQuand un programme donne un temps correct sur la Machine A mais pas sur la Machine B — même G-code, même outillage — ce n'est pas l'estimation elle-même qui pose problème. C'est le profil machine qui la sous-tend.
Un modèle cinématique ou temporel construit autour de l'accélération des axes, de la vitesse rapide ou du mécanisme de changement d'outil d'une machine ne se transpose pas automatiquement à un autre modèle de machine, même du même fabricant, et encore moins d'une version de firmware de contrôleur à une autre. Réutiliser un seul profil générique sur un parc mixte est un raccourci courant qui fonctionne jusqu'à ce qu'il cesse de fonctionner.
Ouvrez le profil machine enregistré utilisé pour l'estimation et comparez ses valeurs d'accélération, de déplacement rapide et de durée de changement d'outil aux caractéristiques réelles de la fiche technique de la machine physique et à une mesure fraîche en marche à vide. Versionnez les profils machine par modèle et par version de firmware du contrôleur, plutôt que par atelier.
Quel que soit le symptôme qui vous a amené sur cette page, la boucle sous-jacente reste la même : isoler la plus petite partie de l'écart que vous pouvez tester isolément, simuler de deux façons (avec et sans la cause suspectée), capturer la télémétrie réelle du contrôleur plutôt qu'un chronomètre, et ajuster uniquement le paramètre de modèle spécifique que le test met en évidence — pas tout le pipeline. Relancer entièrement un processus d'extraction alors qu'une seule donnée était fausse fait perdre le temps que vous cherchiez justement à gagner.
Versionnez vos profils machine. Suivez les hypothèses d'accélération, de vitesse rapide et de changement d'outil par modèle de machine et par version de firmware du contrôleur, avec une date de modification, afin qu'un futur écart puisse être retracé jusqu'à une mise à jour précise.
Associez un score de confiance à l'estimation de chaque programme. Un programme validé sur 10 runs réels mérite plus de confiance qu'un programme estimé uniquement par géométrie — rendez cela visible aux planificateurs. C'est le même facteur de Performance qui alimente directement votre calcul du TRS, donc une donnée de temps de cycle peu fiable fausse discrètement un KPI bien au-delà de la planification.
Fixez une cadence de revalidation. Trimestrielle pour les jobs stables et inchangés ; immédiate après tout changement d'outillage, de firmware ou de post-processeur ; dès le premier lot pour tout job nouvellement programmé.
Si vous vous retrouvez à répéter cette boucle de diagnostic toutes les quelques semaines sur des jobs différents, le problème sous-jacent n'est généralement pas l'un des symptômes ci-dessus pris isolément — c'est que vos données de temps de cycle reposent sur des vérifications manuelles périodiques plutôt que sur une réconciliation continue et automatique entre le programme et ce que la machine fait réellement. À ce stade, la solution la plus durable est une télémétrie en direct qui capture automatiquement le feed override, l'état de la broche et le chronométrage par événement, afin qu'une dérive apparaisse dès qu'elle se produit plutôt qu'après qu'un planificateur ait constaté une livraison manquée.
Calculez ce que ces écarts récurrents de temps de cycle coûtent réellement à votre atelier en plannings manqués et en marges de sécurité.
Calculez votre RSIUn écart de temps de cycle est une information diagnostique, pas seulement un désagrément — la forme de l'écart vous indique où chercher avant même de toucher à votre modèle d'extraction. Un écart uniforme pointe vers des overrides ou du temps auxiliaire non modélisés ; un écart limité aux segments courts pointe vers une modélisation cinématique manquante ; une variance d'un run à l'autre pointe vers des événements stochastiques non isolés ; une apparition soudaine pointe vers une dérive de programme ou de firmware ; un désaccord CAM/contrôleur pointe vers des différences de post-processeur ou de cycles fixes ; et un écart spécifique à une machine pointe vers un profil à construire par machine, pas par atelier. Diagnostiquez d'abord le motif, la correction est généralement précise et rapide.
Effectuez une marche à vide sur le contrôleur sans intervention opérateur et comparez-la à votre estimation. Si elles ne correspondent toujours pas, l'écart vient de votre modèle ou du traitement CAM/post-processeur/contrôleur — pas de la variabilité opérateur ou de production. Si la marche à vide correspond à votre estimation mais que la production réelle non, l'écart provient de quelque chose qui se produit pendant l'opération réelle, comme les feed overrides ou les tâches opérateur.
Utilisez-le comme point de référence, pas comme réponse définitive. Les estimations rapportées par le contrôleur supposent souvent des conditions idéalisées — pas de feed override, changements d'outil instantanés, accélération parfaite — donc elles ont tendance à être optimistes par rapport à la production réelle. Validez avec quelques runs réels mesurés avant de considérer une estimation du contrôleur comme votre temps standard.
Un écart d'environ 5 à 10 pour cent par rapport au temps mesuré est typique pour une estimation bien validée et ne mérite généralement pas d'investigation supplémentaire. Un écart au-delà d'environ 15 pour cent mérite d'être diagnostiqué avec les motifs ci-dessus, car il pointe généralement vers une cause précise et corrigible plutôt que vers une variabilité ordinaire.
Oui. La plupart des tests ci-dessus utilisent des données que vous pouvez extraire de la télémétrie existante du contrôleur ou de quelques runs de production déjà planifiés, plutôt qu'un cycle de test dédié. La seule exception est la marche à vide de comparaison CAM/contrôleur du Symptôme 5, qu'il vaut mieux effectuer pendant une fenêtre de réglage ou de changement déjà planifiée plutôt qu'en cours de production.