Universal Stepper - Premiers pas, çà tourne...presque

[Fred8]

Bonjour tout le monde.
J'avais déjà crée un sujet il y a quelques mois :
emc2-chipset-i815-kernell-2-6-24-16-rtai-bugs-graphiques-t14396.html
Depuis, par manque de temps, le projet était en stand by. Je profite de mes congés de fin d'année pour relancer la machine et avancer un peu.

Ma config matérielle est la suivante :
PC type Compaq D530SFF (P4 2.8GHz - 768Mo de DDR - HDD Sata 160Go - Chipset i865G)
Breakout board Pico Systems Universal Stepper
Drivers : 4x Gekko G201
Moteur : Vexta PH296-E4.2B (4.2A, 0.46Ohms) 2 phases (4 bobinages) 8 fils (Ce sont des NEMA42, bien trop gros, 1 seul moteur de câblé juste pour l'essai).

Ma config logicielle est la suivante :
OS Ubuntu 10.04 (Lucid)
Noyau 2.6.32-122 RTAI
GNOME 2.30.2
EMC2 2.4.6

Ma carte Universal Stepper communique normalement (vérifié avec l'outil univstediag).
J'utilise la configuration de base pour ma carte fournie avec EMC2
EMC2 se lance normallement.

Je rencontre les problèmes suivants :
- lors de mon précédent essai avec ce même matériel mais Ubuntu 8.04, j'avais dû activer le mode EPP manuellement en lançant un script (pcisetup.c) fournit par PicoSystems. Impossible de réitérer l'opération, ma ligne de commande est systématiquement rejetée.
Je pense toutefois que l'EPP est activé, car je communique avec la breakout board.
- si ma carte universal stepper n'est pas alimentée et connectée lorsque je lance EMC2, ce dernier plante (il doit chercher à communiquer avec). Cela ne se produit pas si le logiciel est lancé après le démarrage du matériel
- lorsque je lance l'usinage du motif d'exemple "EMC - 4 AXIS", mon moteur chante légèrement mais ne bouge pas.
- peu après avoir lancé ou relancé la séquence d'usinage, EMC2 l'arrête en me renvoyant l'erreur "Error joint 3". C'est une erreur de moteur, mais çà ne m'avance pas du tout.
- J'ai essayé de déplacer le moteur en commande manuelle, mais il ne bouge pas plus qu'en automatique. J'ai passé les signaux step/dir à l'oscillo, et j'ai l'impression qu'ils ne sont pas exécutés comme il le faut. Je me pose des questions sur les timings. Mes modifications dans l'outil de config d'EMC2 n'ont pas encore porté leurs fruits.
- Lorsque j'utilise mes propres fichiers de configs (faits avec l'outil d'EMC2), EMC2 plante rapidement, comme si de multiples instances avaient été lancées. Je n'ai pas étudié le contenu des logs d'erreurs.

Je suis un peu dans le brouillard, il se peut que je n'ai pas été très clair.
En résumé : çà ne marche pas encore, et j'aurais bien besoin d'un peu de votre expérience.

Merci.
Fred

PS : bonne année 2011 !

Joint 3 following error

Plantage sur fichier de config perso

 

[Fred8]

Hello la compagnie !

Posons la question différemment : y aurait-il quelqu'un, dans la région d'Orléans, qui sache faire fonctionner EMC2 ?
Si une âme charitable existe, je pense que je gagnerai du temps à faire le voyage avec tout mon matériel...

 

[Fred8]

J'ai passé le sorties step/dir de ma breakout board au scope, et je n'ai pas de signal.
Pas de signal, pas de mouvement moteur.
Je pense encore avoir un souci avec mon port // qui ne passe pas en EPP.

Le concepteur de la carte met à disposition un script pour activer l'EPP :

//cause standard PCI parallel port card to go to EPP mode
#include <asm/io.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
int base_addr, extctrl_addr;
if (argc==1)
printf("must enter parallel port I/O address\n");
if (argc > 1) {
if (1==sscanf(argv[1],"%x",&base_addr)) {
iopl(3) ; //turn on access to all I/O
extctrl_addr = base_addr + 0x402;
outb(0x80,extctrl_addr); // set for EPP mode
printf("wrote 0x80 to 0x%x\n",extctrl_addr);
}
}
return 0;
}

c'est en fait une ligne d'assembleur qui set (via le mot 0x80) le registre de configuration du port //, à l'adresse voulue.

Le script est dispo ici :
http://jelinux.pico-systems.com/codes/pcisetup.c

Pour le compiler : cc -o pcisetup pcisetup.c
Pour créer l'exécutable : sudo chmod u+x pcisetup
Pour l'exécuter : sudo ./pcisetup 378

J'espère que tu vas finir par faire fonctionner ton système (et moi aussi, mais les réponses à mes questions n'attirent pas les foules !)

Edit : je n'arrive pas à compiler le fichier pcisetup.c. Cela se passait bien sous Ubuntu 8.04, mais sous la 10.X, je n'ai que des messages d'erreur :

pcisetup.c 10 : warning : incompatible implicit declaration of built-in function 'printf'
pcisetup.c 12 : warning : incompatible implicit declaration of built-in function 'sscanf'

J'ai essayer de compiler en intégrant stdio.h, mais dans ce cas, j'ai un probleme pour trouver la lib io.h.

Cà me passe très au dessus. Help !

 

[coredump]

Vous devez être connecté pour voir ce contenu.

Voila ca compile chez moi, ca devrait aussi passer sur une ubuntu 10.04

 

[Fred8]

Merci Coredump.

Je vois que tu as ajouté la lib stdio.h pour gérer les printf et scanf.
Je n'avais pas pensé au chemin d'accès à io.h (incompétence notable).

Je vais compiler çà ce soir.

 

[gerard06190]

Bonjour,
Merci Fred 8 pour le script. Je l'essaierai dès que possible.
En fait, il faudrait aussi savoir si quelqu'un a réussi à faire fonctionner EMC2 avec Ubuntu 10.04.

 

[Fred8]

De rien pour le script.
Je l'ai compilé, exécuté. Encore merci Coredump.
Mais çà ne marche pas mieux, voir même pire, ma carte Universal Stepper me dit maintenant qu'elle s'appemme DAC-16.
Je contacte John Elson, le concepteur.

Je mets ici la suite de mail, çà pourra servir à d'autres.

----------------------------------------------------------
Hello Jon,

We were in contact last year, in february, because I encountered some problems to make a Universal Stepper Board working.

I had no free time up today to make it working completely. I used some holiday days to work again on it.

- I am still on the same PC (HP Compaq D530SFF - P4 2.8GHz - 768Mo DDR, chipset Intel 865G).
- I am still using Gecko G201 stepper drivers.
- The IEEE1284 is about 1.5m long and was validated in february 2010.
- The USC board is powered via 9Vdc voltage (laboratory power supply - 3A/channel).
- The red led is blinking about 500ms after power, showing the EEPROM program is read by the FPGA.
- The green E-Stop led is lighting continuously.
- DIP switches 1, 2, 3, 4 are OFF (no coders).
- DIP switches 5, 6, 7, 8, 9, 10 are ON (all outputs active, board adress in the 0-31 range).

- I passed from Ubuntu 8.04 to 10.04 and EMC 2.4.3 (format, and install from the live CD+EMC 2.4.3).

- Before launching EMC2, I used univstepdiag tool to check communication with the USC.

sudo ./univstepdiags 378 bus - The USC respond :
Board Addr = 0
Type = Univ. Stepper
Ver. = 3

sudo ./univstepdiags 378 commtest - The USC respond :
1000
2000
...
10000 test cycles, 0 errors.

-I was happy to have the same behaviour as last year's, and I tried with EMC (with the Universal Stepper standard configuration file at first).
The G-code is executed, but there is no activity on the Step/Dir ports (I checked with my scope).

- I tried with a personnal configuration file for my motors and drivers. Same problem.

- I tried with the latest 2.4.6 EMC2 version. Same problem.

- I used your pcisetup script to force the // port to EPP :

Compile : cc -o pcisetup pcisetup.c
Create executable : sudo chmod u+x pcisetup
Execute : sudo ./pcisetup 378
- I tried again with EMC 2.4.6. Same problem, no activity on the Step/Dir lines.

- used univstepdiag tool to check communication with the USC.

sudo ./univstepdiags 378 bus - The USC respond :
Board Addr = 0
Type = DAC-16
Ver. = 4

Oupssss...it won't work...

- I restarted the PC and made the same test : same problem.

I worry about 3 things :

- The USC may have charged the DAC-16 program, and the hardware can not run with the bad program, and I don't know when the problem appeared exactly. I am not sure that it is the consequence of the EPP forcing. I may have been like this prior to the EPP forcing.

- There is no activity on the 4 Step/Dir ports, maybe it is because of the DAC-16 config. But my motor never turned, even when the USC was responding as a Univ Stepper.

- I don't know if I must use physical home switches to make the USC running properly, or if it is optionnal. I will have such switches on my machine, but I haven't now on my desk.

I am sorry for the long mail Jon, but I tried to be as accurate as possible.
Thank you for your answers.
Best regards

Fred

----------------------------------------------------------
OK, if EMC2 stays running, then it is communicating with the board. If
it can't establish communication, then it will shut down with an error message.

OK, well that is a problem, then. If EMC2 was seeing ONLY a DAC-16
board, it would not continue, as that is not enough to set up a motion system. So, do you get this DAC-16 report ONLY if you use pcisetup, or
does it do this after running EMC2.4.6?

If you are using an EMC configs file set for the USC, then it will attempt to connect signals in HAL to some of the USC pins such as ppmc.0.stepgen.00.velocity which will only appear if the driver hal_ppmc.c) has identified a USC board.
If this pin is not exported by the driver, you will get a specific message from the hal file that requests it, in this case univstep_motion.hal

There is no way that EMC or the driver can tell the USC to report that it is a DAC-16 board.
The only way this can happen is if the port is set to some incorrect mode where it is not correctly communicating with the board. If the parallel port doesn't conform to the Microsoft register standards for parallel ports, then the command to set it to EPP mode by writing 0x80 to the I/O address 0x402 higher than the port base address (0x378) could do something different.

There is a command option (which I'm afraid I don't know how to use) that can set the port to ignore the upper control register, or not write the 0x80 to it. But, if the diags program worked correctly before using the pcisetup program, then you ought to be able to get back to that behavior. You may have to power off both the computer and USC board. Don't just reboot the computer, I have seen cases where a reboot did NOT clear settings in the par port chip.

The sensing of home switches is configurable in the file univstep_io.hal. The default configs files work with nothing connected to the inputs. If you want to use normally-closed switches, then you need to invert the polarity by changing which HAL pin is connected.
You will see lines like :

linksp Xhome <= ppmc.0.din.00.in
If you change this to :
linksp Xhome <= ppmc.0.din.00.in-not
the sensing of the switch will be reversed. (The driver exports pins with both polarities,
you can choose which ones you want.

You can see the immediate condition of these inputs with the Halshow program, available from the machine menu in Axis. This is also useful to see what pins are being exported by the PPMC driver, so you can tell what board it is sensing on the port.

I hope this is enough info so you can solve this problem.

Jon

 

[gerard06190]

Bonsoir,

As tu jeté un oeil là :

http://cuteminds.com/index.php/en/linux ... blems.html

 

[Fred8]

Merci, ce tuto est un des plus imagés que j'ai pu rencontrer.
Mais comme d'hab, j'ai une config qui diffère trop de la norme (je vais expliquer) et ce tuto me correspond uniquement jusqu'à la config de Linux.

Ma carte de pilotage des pas à pas n'est pas une "simple" breakout board, elle communique avec EMC2 et génère elle-même les signaux step et dir, ce qui permet de bien monter en fréquence sur les pas à pas (200 à 300kHz), et ce sur les 4 axes. Cette cartes est un peu la SmoothStepper connue sur Mach, ou une Mesa dont le FPGA aurait été personnalisé.

La difficulté que cela engendre, c'est que la carte et EMC2 utilisent un driver (couche hal) pour pouvoir communiquer. Ceci implique de ne pas utiliser le Stepconf Wizard.

C'est d'ailleurs le StepConf Wizard qui me déconfigurait les registres de contrôle de mon port //, et qui faisait que ma carte n'était plus reconnue.

C'est exactement là où je bloque encore, malgré l'aide du concepteur Jon Elson. Mes moteurs tournent, très (trop) lentement, et toujours dans le même sens anti-horaire. Au scope, je ne vois pas de signaux dir valides passer. J'ai beaucoup de pas en revanche.
Je n'arrive pas à modifier un paramètre dans les fichiers HAL qui soit satisfaisant et qui change quoi que ce soit à ce comportement.

Notamment, je dois passer en mm plutôt qu'en inch : facile à dire, facile à faire, mais cela se termine systématiquement en planté d'EMC2.
Restons en inch, et essayons d'ajuster les paramètres de "Scale" et de "Scale output", qui vont définir le nombre de pas à appliquer pour parcourir 1 inch. Et bien je peux mettre ce que je veux comme valeurs de 10 à 4000, çà ne change pas la face du monde (de mon monde).
Sans oublier que la démo d'EMC2 s'arrête très souvent pour des "Joint error" sans que j'en sache pourquoi.

Bref, je reste désapointé, mais pas encore découragé.

 

[xi]

Hello la compagnie !

Posons la question différemment : y aurait-il quelqu'un, dans la région d'Orléans, qui sache faire fonctionner EMC2 ?
Si une âme charitable existe, je pense que je gagnerai du temps à faire le voyage avec tout mon matériel...

Salut,

Bon je suis pas franchement dans la région d'orléans (nord de paris), mais j'utilise EMC2 si tu as besoin ... Par contre moi je commande des moteurs pas à pas par l'intermédiaire de L297, donc c'est beaucoup plus simple que ton système ...
A noter que je n'ai _jamais_ vu EMC2 planter, donc tes problèmes de plantage à répétition me semblent très étranges ... Il marche bien ton PC ?

 

[Fred8]

Oui, le PC n'a pas de pb de fonctionnement au niveau matériel.
Il est de plus dédié à EMC2, et je n'ai rien installé d'autre dessus.

Merci pour la proposition d'aide, effectivement, çà fait un peu loin, mais si vraiment je n'y arrive pas, je sais que je peux te demander.

Cela fait presque une semaine que je n'ai pas pu y toucher. Je vais réessayer ce WE, notamment au niveau des fichiers de config .hal.