EMC2+chipset i815+kernell 2.6.24-16-rtai = bugs graphiques

  • Auteur de la discussion Auteur de la discussion Fred8
  • Date de début Date de début
F

Fred8

Compagnon
Hello les linuxiens !
Je vais être des vôtres... je vais recevoir 4 drivers G201, la carte Pico Sytem Stepper et la carte Gecko servo interface, arrachés aux enchères sur ebay

Ayant un vieux PC de bureau compaq (Deskpro EN, PIII 1GHz, chipset i815 vidéo intégrée, 512Mo de ram et HDD 20Go 7200tr/min), j'ai installé Ubuntu 8.04.3 avec le kernell temps réel 2.6.24-16 rtai.

EMC2 se lance (si on choisit le bon Kernell au boot), mais l'affichage devient illisible (voir copie d'écran). Je pensais au départ que le driver vidéo était seul en cause, mais le fait d'avoir une copie d'écran avec les artéfacts m'indique (mais je ne suis pas encore linuxien) que l'image est calculée ainsi, et que la vidéo ne fait que la retranscrire.
J'ai essayé en 800x600, 1024x768, 1600x1200, différentes fréquences de raffraichissement, idem.
Je ne trouve de plus aucun driver pour le i815, ou bien des procédures de compilation qui me laissent encore un peu de marbre (ouah, linux pour tous...).
EMC2 est inutilisable ainsi.

Avez-vous déjà rencontré ce problème ? Avez-vous un palliatif ?
Merci de votre aide (j'ai fini d'être sec, je commence à reprendre l'humidité... ).

Fred

C'est moche...
 
Bonjour,
je pense que ton problème vient bien d'une non reconnaissance de ta carte video. Les soucis de drivers sont un des plus grand problème sous linux.Si tu possèdes une autre carte video fait un essai sinon je peux te passer une ancienne petite carte ATI qui tournait bien sous linux
 
Si tu choisi de booter sans RTAI tu as le meme phénomène?

Je pense que ca viens de la carte graphique intégrée. C'est limite sur EMC, surtout qu'elle est ancienne.
Si tu peux tester avec une carte graphique PCI ou AGP.
 
Et oui, c'est de l'intégré. Je n'ai cependant aucun problème sous le Kernell classique, même en 1600x1200.

Je n'ai pas de carte PCI pour essayer autrechose, mais je vais en chercher une, je crois qu'un de mes amis en avait une à une époque...il faudra juste que Linux la reconnaisse.

Papoum, tu tournait avec quelle carte ATI ? RagePro3D (4 ou 8 Mo ?)
 
ok si ca tourne avec le kernel classique, ca vient bien du chipset intégré. La partie temps réelle "casse" le driver de la carte graphique car il prends trop de CPU.

Si il faut je dois avoir une vieille carte PCI qui traine.
 
Je dois pouvoir avoir une S3 Trio en PCI, mais pas de drivers en vue non plus, ou plutôt, "plus de driver" intégré depuis déjà qq temps.

Il demande beaucoup de ressources video EMC2 ? Parce que les cartes PCI, côté performances, ce n'est plus génial...

Au pire, je vais passer sur une config différente et plus actuelle, mais je vais perdre pas mal de temps.

Autre question, s'il y a un utilisateur des cartes Pico systems parmi nous : il faut des drivers spécifiques ? je ne vois pas ma carte stepper dans la liste des cartes gérées de base par EMC2.

En tout cas, merci de vos réponse, çà aide bien...
 
Je ne pense pas que ça résolve le souci mais essaye de voir si tu n'as pas compiz d'activé (Système->Préférences->Apparence->Effets visuels coche aucun)

EMC2 ne demande pas de ressource vidéo mais Axis (l'interface graphique) demande OpenGL pour le suivit d'usinage en 3D.

La meilleure solution est en effet une carte PCI ou AGP (de préférence AGP plus performantes). N'oublis pas de désactiver dans le bios l'ancienne carte vidéo.

Si ta carte stepper accepte les signaux "step/dir" (sur interface parallèle) il ne devrait pas y avoir de problèmes et le "stepconfig wizard" te fera une configuration fonctionnelle sans trop d'efforts. Par contre si ta carte a autre chose qu'une interface parallèle (ou PCI) elle ne va pas marcher avec EMC2 et ne fonctionnera surement jamais.

J'ai mis du temps à comprendre pourquoi EMC2 n'acceptait pas autre chose que du // ou PCI... L'explication se trouve dans la structure d'EMC2, il fait un asservissement numérique de la position et vitesse décrit par le Gcode. En gros le cœur envoie à un "driver logiciel" des commandes de positions (et vitesse) et attend une position en retour (par des capteur).
Dans le cas des moteur pas à pas, ce "driver logiciel" s'appelle "stepgen" c'est lui qui génère les signaux "Step/dir" à partir des commandes. Vu qu'il n'y a pas de capteurs de retour, il renvoi au cœur d'EMC2 le déplacement que devrait occasionner les signaux "Step/dir" qu'il génère... La boucle est bouclée!
Le "soucis" c'est que tout ce petit monde est cadencé par un noyau temps réel et que tout les éléments de la chaine se doivent de l'être. En gros il faut qu'ils répondent rigoureusement "dans les temps" mais pas forcément avec un débit énorme. Les interfaces PCI et parallèles (firewire?) sont des interfaces temps réel. Par contre l'USB, le série, Ethernet TCP UDP ne le sont pas voila pourquoi elles sont de fait exclues.

Les cartes Pico System, Pluto-p ou Mesa sont en fait des générateurs de pulses "hardware" venant avantageusement remplacer le générateur logiciel "stepgen". On passe en fréquence de génération de pulses de 50kHz avec "stepgen" à plus de 300kHz...

Les infos sur comment configurer la carte Pico et EMC2 sont ici :
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Universal_Stepper_Controller
http://jelinux.pico-systems.com/univstep.html

Pour le prix je m'orienterai vers des cartes Mesa PCI 5I20 (199$) ou parallèle 7I43 (89$) avec carte d'extension opto-couplé 7I37 (69$). Ce sont les cartes les plus utilisés (et dont les drivers sont les plus aboutis).

Xavier
 
Merci bcp de ces précisions.
J'ai consulté tes liens, et je t'avoue que le petit windowsien que je suis doit se creuser la tête pour tout saisir.

Je vais vous tenir au courant de mes avancées, j'ai un PC avec un i865 (Intel Extreme Graphic 2) qui traîne, et il a un port AGP de libre, lui, donc de quoi shunter efficacement le chip graphique intégré si nécessaire.
 
horsot a dit:
Je ne pense pas que ça résolve le souci mais essaye de voir si tu n'as pas compiz d'activé (Système->Préférences->Apparence->Effets visuels coche aucun)
Xavier
Cliquez pour agrandir...

Compiz est désactivé par défaut et ne peut pas être activé avec mon chipset graphique (ou dans le Kernell RT ?).
 
Fred8 a dit:
Merci bcp de ces précisions.
J'ai consulté tes liens, et je t'avoue que le petit windowsien que je suis doit se creuser la tête pour tout saisir.
Cliquez pour agrandir...

Avec plaisir!
Si tu débute avec linux et EMC2 à la fois (ça fait beaucoup!), je te conseille de commencer à te faire la main avec une "bête" breakout board (pas Pico ni mesa) et laisser générer les pulses par "stepgen" (en logiciel). Si tu fais comme ça le "stepconf wizard" pourra générer la configuration assez simplement. Si tu décides de partir sur un générateur de pulses externe (matériel) tu devras faire la configuration à la main (il y a des modèles et une doc pour aider).

Pourquoi t'es tu dirigé vers EMC2?

Quels sont tes drivers moteurs?

Xavier
 
[quote="horsot
Pourquoi t'es tu dirigé vers EMC2?
Quels sont tes drivers moteurs?
Xavier[/quote]

Pourquoi EMC2 ? Je suis tombé, comme expliqué dans mon premier post, sur une bonne occas sur ebay :

- 4 drivers Gecko G201 (4x112$=448$ neuf),
- 1 carte Pico Systems Universal Stepper (250$ neuf),
- 1 carte Pico System Geck Servo Interface (100$).

J'ai payé le tout 226€ port compris, ce qui est bien en deçà du prix du neuf. Les G201 ne sont pas le top, au niveau de la fréquence des pulses notamment, mais ils me permettront de commencer. Je vais recevoir tout cela dans la semaine.
Le truc, c'est que Jon Elson, le concepteur des produits Pico Systems, m'a confirmé qu'aucun driver pour Mach3 ou autre soft windowsien n'existe, et ce n'est pas prévu. Donc, passage obligatoire sous distrib Linux.

D'autre part, j'ai qq amis et collègues qui passent leur temps à développer sous linux. Je me suis dit qu'entre le forum et eux, et le net, je trouverai bien de quoi m'en sortir rapidement.

Je bosse en R&D, mais plutôt du côté Hard (en tant que "Chef produits", je viens stresser les softeux...).

Bon, pour le pb vidéo, on en parle plus, j'aurais un autre PC plus à jour dès samedi. Je réinstallerai Ubuntu dessus.

Pour le pb du driver, j'ai contacté Jon Elson chez Pico Systems, qui m'a donné des infos : "The driver is called ppmc, it handles all of the boards I make. But, what you really want is the set of configs files called "univstep", which is included with the EMC2 distribution and source."
Voilà une autre partie qui avance bien.

J'ai fait un test avec la config univstep, et voilà mon prochain point de blocage :

Pb de Kernell rtai ou du driver qui n'a pas de carte à qui parler ?
 
Salut à tous,
J'avance petit à petit.

J'ai changé de machine et réinstallé Ubuntu 8.04 Handy Heron, et mon bug graphique n'est plus. EMC2 se lance correctement pour peu que je ne lui demande pas de charger le driver de ma carte, auquel cas j'obtiens le message d'erreur de mon précédent post.

Il se peut que le driver ppmc attende un retour de ma carte Universal Stepper, qui n'est pas encore connectée physiquement.

Lorsque les connections seront faîtes, j'espère que tout rentrera dans le droit chemin...
 
Tu peux faire un:

sudo insmod hal_ppmc

et si ca plante, les dernieres lignes de la commande:

sudo dmesg

?
 
coredump a dit:
Tu peux faire un:
sudo insmod hal_ppmc

et si ca plante, les dernieres lignes de la commande:
sudo dmesg

?
Cliquez pour agrandir...

Le sudo insmod hal_ppmc pour lancer le driver ?
Et sudo dmsg pour supprimer les messages qui resteraient ?
 
Non en fait c'est le resultat de dmesg qui est interessant (les messages du kernel).
insmod sert a inserer le module dans le kernel, et donc de voir se qui se passe sans pour autant lancer EMC2
 
Bon, la réponse à la ligne de commande sudo insmod hal_ppmc est "No such file or directory". La carte est alimenté et bien reliée au PC.
Le fichier hal_ppmc est bien présent dans le répertoire d'installation de EMC2 ( frederic/emc2-2.3.4/src/hal/drivers ).
Je continuerai demain soir (fermer le circuit AU notamment, cela bloque peut-être la réponse du fpga).
 
Bonjour à tous.
Voilà la suite de mes trubuntulations...J'ai téléchargé les outils de diagnostic qui permettent, sans passer par le driver ppmc, de dialoguer avec la carte Universal Stepper pour en vérifier le fonctionnement.
Selon la fonction lancée (console), on va soit lire l'adresse, la version et confirmer la présence de la carte, soit faire bouger des E/S, soit bombarder la liaison parallèle d'informations connues pour confirmer la qualité de la communication.

Diagnostic : je ne passe même pas la première étape, rien ne sort de mon port // (le câble n'y est pour rien).

Pourtant, lp0 est détecté (378H).

L'un d'entre-vous aurait-il une petite application sous Linux pour faire bouger les lignes du port, pour être certain qu'il ne s'agit pas d'un pb logiciel ? Sous Windows, j'ai ce qu'il faut, mais pas sous Linux (au pire, j'installerai un émulateur de DOS, mais je ne suis pas certain que l'accès aux ports d'E/S soit direct et que mes anciennes applis tournent.).

Décidément, c'est pas du user friendly...
Merci !
 

Dans ce cas, il faut faire un insmod depuis le répertoire ou est le fichier hal_ppmc.ko
D'ailleurs en fait il vaut mieux faire modprobe que insmod, si jamais le module a des dépendances.
 
horsot a dit:
Tu as Parport tester d'EMC2 :http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Parallel_Port_Tester
Xavier
Cliquez pour agrandir...

Merci Bcp Xavier, je vais tester cela ce soir, c'est exactement ce que je cherchais :




Oh que si ! il y a plein de raisons qui m'en empêchent :
- je n'ai pas le temps de tout faire (et l'informatique est très chronophage),
- je n'ai pas les compétences suffisantes (chacun son truc, moi, je suis plutôt hardeux que softeux),
- Je n'ai pas envie de passer mon peu de temps libre à çà (ce n'est pas mon trip),

En fait, quand je disais que ce n'est pas user-firendly, c'est en pensant à mes collègues softeux qui ne jurent que par Unix et Linux. Selon eux, n'importe qui peut installer et utiliser une distrib Linux, notamment Ubuntu.
Mais j'ai bien du mal à voir comment. Je n'ai rien voulu faire de plus que sous Windows, et j'ai, dès l'installation d'EMC2, été amené vers la console...et ses lignes de code.

Par contre, rien ne m'empêche de M'améliorer.
 
Linux c'est comme avoir la RTAI de a voiture et faire toi même l'entretien, windows c'est l'emmener au garage, et macos avoir un chauffeur qui s'occupe de tout...
 
Avec plaisir!

Il y a """1000""" façons de l'améliorer et ne sont pas toutes chronophages (mais beaucoup j'avoue!) . Par exemple, ajouter au wiki la façon dont tu vas résoudre ton problème ou déclarer le bug s'il y a ne te prendra pas plus de quelques dizaines de minutes...
Personnellement, je suis plutôt du caractère "remplisseur" de wiki lorsque je rencontre un soucis ça me permet de retrouver la solution lorsque je rencontre de nouveau le problème plus tard (mémoire, mémoire,...)
Je ne veux pas rentrer ou créer un débat mais je pense qu'il ne faut pas se considérer client traditionnel lorsqu'on utilise des logiciels libres. Une raison est qu'être simple utilisateur (gratuit) ne rapporte rien à la communauté (mis à part la fierté d'avoir un grand nombre d'utilisateur). Contrairement aux logiciels propriétaires se sont les contributeurs et non les utilisateurs qui font vivre le logiciel. Je me dis toujours que si ce logiciel a des défauts c'est aussi à cause de moi
Enfin je fais la morale mais je suis simple utilisateur des 99% des logiciels que j'utilise...

J'essaie de m'améliorer aussi.

Xavier
 
Voilà la suite (çà ne s'arrête jamais !) :

Test avec l'appli ptest :

frederic@P4-2:~/univstepdiag$ halrun -I -f ptest.hal
insmod: can't read '/usr/realtime-2.6.24-26-generic/modules/rtai_hal.ko': No such file or directory
RTAPI: ERROR: could not open shared memory (errno=2)
HAL: ERROR: rtapi init failed
halcmd: hal_init() failed: -9
NOTE: 'rtapi' kernel module must be loaded
RTAPI: ERROR: could not open shared memory (errno=2)
HAL: ERROR: rtapi init failed
halcmd: hal_init() failed: -9
NOTE: 'rtapi' kernel module must be loaded
RTAPI: ERROR: could not open shared memory (errno=2)
HAL: ERROR: rtapi init failed
halcmd: hal_init() failed: -9
NOTE: 'rtapi' kernel module must be loaded
RTAPI: ERROR: could not open shared memory (errno=2)
HAL: ERROR: rtapi init failed
halcmd: hal_init() failed: -9
NOTE: 'rtapi' kernel module must be loaded
ERROR: Module hal_lib does not exist in /proc/modules
ERROR: Module rtapi does not exist in /proc/modules
ERROR: Module rtai_math does not exist in /proc/modules
ERROR: Module rtai_sem does not exist in /proc/modules
ERROR: Module rtai_fifos does not exist in /proc/modules
/usr/bin/emc_module_helper: Invalid usage with args: remove rtai_ksched

Usage: /usr/bin/emc_module_helper insert /path/to/module.ext [param1=value1 ...]

where module is one of:
rtai_math
rtai_sem
rtai_shm
rtai_fifos
rtai_up
rtai_lxrt
rtai_hal
rtai_sched
rtai_smi
rtai
rt_mem_mgr
adeos
rtl_time
rtl_sched
rtl_posixio
rtl_fifo
rtl
mbuff

the path starts with one of:
/lib/modules
/usr/realtime
and the extension is one of:
.ko
or the module is in the directory /usr/realtime-2.6.24-16-rtai/modules/emc2
OR
/usr/bin/emc_module_helper remove module
where module is one of the modules listed above.

ERROR: Module rtai_hal does not exist in /proc/modules
frederic@P4-2:~/univstepdiag$


Je vois bien un truc qui ne va pas avec rtai.hal qui a l'air manquant, j'aurais tendance à chercher le fichier sur le net et à le copier là où ptest.hal le demande. (pb de lib manquante ?)
 
On dirait que tu utilises un noyau non patché RTAI (temps réel).

Au démarrage, il te faut choisir dans Grub "linux 2.6.24-16-rtai" ou un truc dans le genre. Curieux que tu ais la 2.6.24-26-generic d'installé As-tu fais une mise à niveau vers la 8.10 ou plus?

Peux-tu faire un "uname -a" dans ta console et donner le résultat?

Xavier
 
Le noyau rtai s'est installé avec EMC2.
Je n'ai fait aucune mise à jour vers la 8.10, je suis en 8.04.
Je dois choisir au boot sur quel noyau démarrer (generic ou rtai).
Lors de mes précédents tests de port //, j'étais effectivement sur le noyau generic, car je ne voyais pas l'intérêt du noyau temps réel pour valider le port //...(jl'appli n'aurait été faîte pour vérifier la chaîne logicielle temps reel et uniquement elle ?).
Après démarrage avec le rtai, j'ai réussi à lancer l'appli ptest et à valider le fonctionnement du port (tout est OK du point de vue matériel PC).

J'ai lancé dans la foulée l'appli de diagnostic pour la carte Universal Stepper, et voilà ce qu'il me dit :

frederic@P4-2:~/univstepdiag$ $sudo ./univstepdiags 378 bus
io addr = 378
parport addr 0x378
Erreur de segmentation
frederic@P4-2:~/univstepdiag$

C'est une nouvelle erreur. Mmmm mais c'est quoi cette segmentation ?
 
Ben l'appli en question est un """soft""" reposant sur HAL (Hardware Abstraction Layer) d'EMC2 qui lui a besoin de RTAI. Sinon tu as raison le port // peut marcher sans!

Fred8 a dit:
frederic@P4-2:~/univstepdiag$ $sudo ./univstepdiags 378 bus
io addr = 378
parport addr 0x378
Erreur de segmentation
frederic@P4-2:~/univstepdiag$

C'est une nouvelle erreur. Mmmm mais c'est quoi cette segmentation ?
Cliquez pour agrandir...

Décidément si ça marche, tu l'auras mérité !

Je ne connais pas ta carte mais il semblerait que ce soit un bug du programme de pico-system (indice d'un pointeur en vrac,...). Essaye un "sudo ./univstepdiags bus" voir http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Pico_Systems_Universal_Stepper_Controller
Sinon je te conseille de te tourner vers pico-system pour ça.

Je pense que tu peux quand même essayer de charger l'exemple de config EMC2 pour faire des tests.

Bon courage

Xavier
 
Bon, celle-là, c'est moi qui l'ai trouvée :

il ne faut pas mettre le "$" devant le "sudo". Cà marche mieux, mais ma board ne répond pas.
Je dois contacter Pico Systems.
Merci,
Je vous tiens au jus !
 
En effet sans le $ ça doit mieux marcher mais c'est qd même curieux le segmentation fault...

J'ai vu des problèmes avec les ports parallèles Dell...
A+
Xavier
 
Officiellement, c'est un Compaq D530 SFF...
J'ai essayé sur ce même port une détection d'imprimante par Linux (HP970, listée), et rien, l'OS ne voit rien...
Je vais attendre la réponse de Pico Systems. Je n'ai pas d'autre PC ni de carte LPT sous la main.
 
Pour info, j'y suis encore.
J'ai un problème de commande de mon port // en mode EPP.
J'essaie de résoudre cela, mais pas facile.
Physiquement, mon port // se porte très bien (contrôllé avec Parallel Port Tester). Si j'utilise le driver d'une autre carte, EMC2 me sort bien mes pulses. Mais rien avec le driver de ma carte.

Le concepteur, Jon Elson, m'a donné un lien (http://jelinux.pico-systems.com/codes/) et m'a conseillé d'essayé de forcer le port en EPP avec le fichier pcisetup.

L'un d'entre-vous sait-il comment je dois procéder ? J'ai un fichier pcistep.c et un fichier pcisetup.txt. Le .txt n'est pas lisible par un humain.
Je dois compiler ? remplacer un fichier ?

Si cette manip ne marche pas, je vais devoir me trouver une carte PCI-// qui gère l'EPP, et l'installer.

Si cette manip ne marche pas non plus, je sors le couteau suisse et fais un malheur...
 
Pour répondre, connectez ou inscrivez vous.

Sujets similaires

F
Universal Stepper - Premiers pas, çà tourne...presque
Réponses
10
Affichages
3 962
Fred8
F
Menu
Connexion
S'inscrire