prob de boucle dans un sous programme

[Julien]

Bonjour,

un petit mystère que je n'ai pas réussi à résoudre:

J'ai un fichier qu'on va appeler "fraisage" dans lequel il y a un sous programme appelé "cycle" qui est appelé avec une boucle while. ça ressemble à ça:

Vous devez être connecté pour voir ce contenu.

Jusque la tout marche bien! La boucle while pour répète les passes de fraisage tant que la cote n'est pas atteinte.

Comme j'ai des axes à méplater (2 méplats à 180°, par ex. pour y mettre un clé plate), je le fais avec le diviseur, et j'ai fait un programme principal qui:

Tourne le diviseur (axe A) à 0°
appelle le fichier "fraisage"
tourne à 180°
appelle le fichier "fraisage"

Bien sur pour l'occasion j'ai ajouté dans le fichier "fraisage":
o<fraisage> sub au début
et o<fraisage> endsub à la fin

Hé ben tout marche au détail près que la boucle o101 while n'appelle jamais le "cycle"...

Y a il trop de boucles, ou qqch qui est mal fait?

 

[Julien]

Au passage, je rajoute que le but est de me faire des programmes paramétrés pour pouvoir faire des opérations relativement simples sans passer par la FAO ni devoir écrire à chaque fois un programme en partant de rien.
Surfaçage, poche rectangle ou ronde, fraisage hélicoïdal, rainurage, table de perçages, ...
Mais je pense que je ne suis pas le premier! Existe il de tels programmes qui sont en libre accès?

Je vous en met un en pièce jointe pour voir le principe.

 

[joumpy]

Parce que tu as oublié après le premier cycle de réinitialiser ta valeur de #<nb cycle>
Du coup la deuxième égalité est vrai sans même faire les boucles souhaitées et le programme se termine.
Habituellement, tu as une seule boucle et l'initialisation des variables se fait au début du programme.
Avec 2 boucles imbriquées, il faut faire plus attention...

 

[Lezard]

Et aussi entre deux exécutions du programme dans la même session : je me suis fait eu sur un programme tout bête (une seule boucle) qui tourne une 1ere fois, et ne fait plus rien ensuite, jusqu'à ce que je mette l'initialisation de la variable-compteur...

 

[MegaHertz]

Au passage, je rajoute que le but est de me faire des programmes paramétrés pour pouvoir faire des opérations relativement simples sans passer par la FAO ni devoir écrire à chaque fois un programme en partant de rien.

Bonjour,

Pourquoi donc t'interdire la FAO ?

Si tu veux usiner efficacement la FAO te permet d'indiquer le recouvrement et elle se débrouille pour créer plein de trajectoires pour usiner en maintenant une pression constante sur ton outil.
Par exemple pour usiner une poche avec un outil de 6 et un recouvrement de 2mm sur 6mm de profondeur tu y passerais le mois à la mano alors que la FAO te pondra tout le cycle en moins de 5 minutes.

Vu qu'en FAO c'est l'ordi qui se fade les trajectoires, ça permet d'être moins fainéant sur les passes et de faire plus propre avec une ébauche et une finition qui sont vraiment adaptés.

C'est dommage de t'interdire quelque chose d'efficace et gratuit par dogme.

 

[joumpy]

Il y a des applications pour lesquelles la FAO n'est pas performante par rapport à la mano...
J'en connais bien 1: l'usinage à l'outil diamanté. La prise de passe est de 0.01 maximum, donc pour manger des millimètres, il faut repasser plusieurs centaines de fois au même endroit. La FAO sait faire mais le programme devient d'une longueur hallucinante pour pas grand chose. Une boucle de répétition à la mano et le programme ne fait plus que quelques lignes.

 

[MegaHertz]

C'est vrai que les logiciels de FAO ne sont pas vraiment optimisés de ce côté : ils pissent du code et c'est pas vraiment fait pour être relu.
Sur que dans les années 80 avec un Floppy disk et des ordis à 128K tu passerais pas.

Faut dire qu'avec les clefs USB et un ordi sous Linux on a tout de même de la marge avant d'être hors jeu non ?
J'ai vu pas mal de progs de gravure avec toute petite fraise javelot qui génèrent du code énorme sans aucun problème.

La limite de LinuxCNC c'est combien au juste ?

Ton PC a combien de RAM ?