Advanced Search

Bonjour... Je rencontre un problème avec un servomoteur X dont le mouvement est saccadé (Jog et G1). Le contrôleur d'origine a été mise à jour avec un ordinateur et LinuxCNC V2.8.2-8. La mise en route a été complexe, mais tout fonctionne à nouveau à l'exception du servomoteur X : son mouvement est saccadé et le moteur émet un bruit de grincement (il n'est pas fluide). Il semble y avoir un conflit entre l'accélération et le freinage. J'ai modifié plusieurs paramètres dans le fichier .INI, le mouvement s'est amélioré, mais je suis bloqué. Les variateurs Copley ont été réglés sur mesure en usine spécifiquement pour les servomoteurs Precix. Cependant, Copley ne peut pas m'aider. Quelqu'un a-t-il déjà rencontré ce problème ou sait-il quels paramètres ajuster pour le résoudre ? Le variateur Copley est-il en cause ? Voici un résumé de la CNC :

CNC : Precix 2100 (DC3 BR)
Contrôleur : mis à jour, Linux Mint 19.3, LinuxCNC V2.8.2-8 + Mesa 7i92 + Mesa 7i77
L'axe Y est parfaitement fluide.
Seul l'axe X présente des à-coups.
Le servomoteur semble être un moteur SEM.
L'amplificateur est un Copley 4122CE.

J'utilise LinuxCNC V2.8.2-8. Je joins les fichiers HAL et INI… cela pourrait-il être utile ? Merci d'avance !
 

I am stuck with a X Servo that has a jerky movement (Jog and G1).The original controller was updated with a computer and LinuxCNC V2.8.2-8. Getting it up and running was difficult, but everything is working again except for the X Servo : its movement is jerky, and the motor makes a grinding noise (not smooth). It seems to be a conflict between acceleration and braking. I've changed several parameters in the .INI file, the movement has improved but I'm stuck. Copley drives were custom-tuned at the factory specifically for Precix servos. However, Copley can't help me. Has anyone else experienced this problem or know which parameters to adjust to fix it? Is the Colpley drive the problem? Here's a summary of the CNC :    CNC : Precix 2100 (DC3 BR)
Controler : updated, Linux Mint 19.3, LinuxCNC V2.8.2-8 + Mesa 7i92 + Mesa 7i77
The Y axis is perfectly smooth.
The X axis is the only one that is jerky.
The servo motor appears to be a SEM motor.
The amplifier is a Copley 4122CE.
I am running LinuxCNC V2.8.2-8I am joining the HAL and INI files... if it can help! Thanks in advance!

Hi zusammen,

ich habe mir auch ein Ethercat System aufgebaut. Was die ganzen EMV Probleme angeht empfehle ich auf jeden Fall passende Netzfilter für jede Servo Endstufe und auch (ganz wichtig) für den VFD der Spindel! Hier mal ein Bild von meinem Schaltschrank während der finalen Bausphase. Der Netzfilter für den Delta Ethercat VFD ist noch nicht verbaut, der kommt über die Drossel.

Ansonsten war ich mit dem Testsystem zu frieden! Man hat durch den Ethercat Cycle immer einen Following Error, den konnte ich auch nicht weg tunen! Das ist aber nicht schlimm weil das nur ein Offset ist, LCNC bekommt die Ist-Position vom Drive praktisch um ein bis zwei Ethercat Zyklen später! Da Linux CNC hier aber sowieso nicht regelt (wie bei klassischen Mesa Systemen wo man PID settings nutzt um den Following Error zu minimieren) hab ich mir den DeASDA Treiber etwas modifiziert und gebe mir den realen Schleppfehler der Servo Endstufen aus. Da sieht man, dass dieser extrem klein ist und vernachlässigt werden kann. Die Servos erreichen praktisch immer ihre Sollposition innerhalb eines Zyklus.

Alles in allem wird das, denke ich auf jeden Fall ne deutlich flexiblere Lösung als mit MESA! Verarbeitung von Endschalter, Homing Sensoren und Probes muss man ordentlich machen! Homing/Endschalter kann man über schnelle Beckhoff Klemmen anschließen, damit es hochgenau wird und der Ethercat cycle offset hier nicht reinhaut, am besten den Index Pin der Servo Encoder als finale Position nutzen! Das ist extrem genau und sehr reproduzierbar (genauer als jeder induktiver Sensor und genauer als die mechanische Genauigkeit der Spindeln). Man kann die Sensoren aber auch direkt am Drive anschließen. Die Touch Probe hab ich an einer Klemme die auch Zeitstempel macht wenn ein Eingang geschaltet wird! Leider kann die Ethercat Implementierung in LinuxCNC diesen Zeitstempel nicht auswerten um die exakte Position beim antasten zu ermitteln….da einfach Geschwindigkeit beim zweiten Antasten so weit runter wie nötig um den Fehler im unterm Mikrometern Bereich zu halten. (Kennt jemand  hier einen besseren Weg?)

Beste Grüße 

I am just now picking this project back up again. I'll keep on posting to this thread as I get it figured out.
I think my next hurtle is how to configure the hal file so it knows what to do with the different combination of inputs. I thought I saw something in one of the speed/feed override screens in PncConfig.

Looks like I'll have to swap to the 7i96 board that I have, but I think I can still get this done.

How much of the command/control/status information can I get back over RS422? It would really save a lot of wiring to only send step/direction and RS422, vs all the various control/status wiring that's on CN1.

I am using 5V from the 6i25 card. I had also wondered if there was a wiring error somewhere, but I tested the MPGs with a multimeter found no errors. I double checked the wiring and everything is in the right place....so, this time I unplugged the terminal blocks and -you guessed it- LinuxCNC still crashes. It must have been a sad coincidence that when I plugged in the MPGs things went bad.I am using a Linux 6.1.0 -19-rt-amd64 kernel, which I just updated. That didn't fix the crash issues.I can open and play with everything just fine if I use a simulated machine, just completely crashes as soon as I try a non-virtual machine.I cant make heads or tails of the crash log. 

Outstanding, thank you!

DRO shows identical position at arc entry and exit — LinuxCNC believes the machine returned to the correct point. But probing a fixed reference shows X shifted +9.3mm and Y shifted -12.2mm. HLFB is configured at 20 counts and did NOT trigger. This means every commanded step was executed by the motor. The error is in the arc interpolation — the step path LinuxCNC generates to trace the circular arcs does not sum back to the correct physical position.
LinuxCNC version: Master (2.9), running on Raspberry Pi 5 (4GB), Debian Bookworm, Mesa 7i96s over ethernet (hm2_eth), SERVO_PERIOD = 1000000.

Indeed I Did Wired it
TB1 Pin7 Input A-, B-
TB1 Pin5 Input A+
TB1 Pin3 Input B+

I would check the 7I77s 5V supply, my guess is that it droops
when you connect the MPGs, either from a wiring error or
too much current.

Does the 7I77 have 5V power supplied to TB1?
 

This may not work for you, but I discovered that I had to leave all Power Management stuff ON, but set times to zero.  If I turned off Power Management I still got screen blanks, auto-logouts, and all the other nonsense.

PCW wrote:

Are the drives step/dir connections single ended or differential?  (single ended is suggested for opto-coupled inputs)

 

Clearpath brushless servos use single-ended opto-coupled inputs.  The 'drives' are built in to the motors - there's no separate drive, and they're powered by (up to) 75VDC.

I'll attach the manual this time...

-Set up the THC, any fine tuning without it is useless when THC is active
-25A for 5mm thick is way to low, roughly 10A/mm is OK
-with working THC, you need to fine tune air pressure (exclusively while the air is ON), voltage=cut height, feed rate
-cut quality will vary based on air moisture, material being cut, nozzle type and wear, so use new nozzle for fine tuning and after you have things working properly

DRO shows the error. Probing the same physical reference point before and after the program gives Y 51.252 before and Y 48.583 after — a 2.67mm shift. HLFB is configured in ASG In-Range mode with 20 count threshold and did NOT trigger during the operation. This confirms the motor followed the commanded path accurately — the error is in what LinuxCNC is commanding, not in the motor execution.