Alors selon toi l'OS et la gestion du matériel occuperai tellement le I7 qu'il ne serai pas capable d'être aussi compétitif qu'un méchant micro-controleur a 100MHz ????
Pour info tu connais le gestionnaire de tâches qui permet de vérifier l'occupation processeur par application ? Moi mon logiciel avec environ 200000 racines carrées à la seconde c'est moins de 10% sur un pentium 4 !
Tu mélange tout, c'est la réaction typique d'un pur softeux qui croit tout pouvoir faire par un logiciel sur un PC. Bien sûr que non qu'un microcontrôleur à 100MHz ne fera pas autant de calcul qu'un core I7, tu me prend vraiment pour un idiot et c'est agaçant. Je ne comprends pas tes réactions surtout quand on connait ton savoir faire en la matière, tu a du mal à sortir de ton seul logiciel que tu a créé et qui est le meilleur au monde. Pourquoi ne pas sortir un concurrent à Mach3 si tu as trouvé le moyen de contrôler 2 machines et de faire la FAO sur un P4 le tout en même temps ?
Intéressant ton extrait, d'ailleurs, c'est pas toi qui ne juré que par l'USB ? Ben tient, bizarrement, CSLab écrit la même chose que moi sur la robustesse d'un port USB en environnement industriel.
Tu ne sais pas plus que moi comment Mach3 dialogue avec le contrôleur CSMIO (tu demande le SDK pour le savoir non ?), il y a de forte chance que ce soit une liste de point et que le contrôleur ne fait que linéariser entre les 2 points. C'est bien Mach3 qui interprète le GCODE et qui génère la trajectoire correspondante. Mais la différence c'est que Mach3 ne s'occupe plus en temps réel du contrôle des moteurs, des butées logicielles, des vitesses d'avances etc Tout ça est fait en matériel ce qui permet de décharger le PC de la partie temps réel, la plus difficile à faire et impossible dans certains cas. Surtout ce contrôleur pilote les moteurs en temps réel par FPGA, ce qui permet un traitement 100% parallèle des 6 axes et un parfait synchronisme, ce que d'autre contrôleur ne font pas car ils travaillent avec un seul CPU et donc à temps partagés. Le CSMIO fait également le contrôle en boucle fermé des moteurs en matériel et non par logiciel. D'ailleurs le taraudage rigide par Mach3 ne fonctionne pas avec ce controleur, il faut passer par une macro M84 car cette fonction est assurée par le contrôleur. Le rattrapage de jeu, c'est pareil, ce n'est pas Mach3 qui le fait mais le controleur, c'est ce dernier qui calcule le bon moment pour appliquer le rattrapage de jeu et même si c'est entre 2 point que lui a donné Mach3.
C'est pas parce que tu sais faire 200000 racine carrées à la seconde que tu est capable de faire ces calculs dans un temps déterminés et constant, c'est d'ailleurs impossible avec Windows qui est un OS multitâche. D'ailleurs Linux n'est pas meilleure sur ce point, lui aussi n'est pas déterministe. Pour l'être, il faut un OS déterministe comme QNX, FreeRTOS, Linux RT, Xenomai surement pas Windows ou une distri Linux standard.
Et déterministe ne veut pas dire qu'on peut lui demander n'importe quoi, avec ce genre d'OS, tu ne tiendra jamais la µsec de réaction entre un événement extérieure et la réaction du logiciel.
Exemple hors sujet: un simple BUS CAN à 1Mbps par seconde est capable de mettre à mal un CORE I7 si il devait traiter les trames 100% par CPU. On en a fait les frais avec un dongle USB <-> CAN qui n'a pas de FIFO mais juste un seul buffer, le CPU est incapable de récupérer toutes les trames en temps réels. Chaque trame arrivant toutes les 115µs, des qu'on clic sur un bouton d'un logiciel, l'OS s'occupe de ça et ne fait pas le reste, résultat, quand il revient 10msec plus tard, il a perdu 100 trames !
La seule solution a été de mettre une FIFO matériel avec un PIC à 20MHz, lui n'a aucun mal à dépiler des trames toutes les 115µs. Le PC vient vider la FIFO toutes les 100msec mais il le fait très vite. Les meilleurs solutions sont celles qui mélange du hard et du soft.
