LinuxCNC + Mesa7i96S

[bartL]

Ik was vanmorgen toch even benieuwd en heb de PC even aangezet en gek genoeg werkt hij nu ineens wel stabiel. Ik kon de as nu via Linux ook laten bewegen (eindelijk).
Ik kreeg bij het opvoeren van de snelheid wel vrij snel een joint following error, op zich al opmerkelijk bij een step/dir systeem zonder terugkoppeling naar de controller maar dat schijnt in de instellingen te zitten. Heeft iemand een idee wat een beetje redelijk waardes voor FERROR en MIN_FERROR zijn als vertrekpunt?

[bbg]

Ter referentie, ik gebruik de volgende waardes:

Op de X en Z as (beide openloop aangestuurd met step/dir):
FERROR = 10.0
MIN_FERROR = 1.0

Op de Y1 en Y2 assen die beide gesloten lus (met encoder) worden aangestuurd gebruik ik:
FERROR = 2.0
MIN_FERROR = 1.0

FERROR is de toegstane volgfout bij hoge snelheden en MIN_FERROR bij lage snelheden (http://wiki.linuxcnc.org/cgi-bin/wiki.p ... wing_Error).

Van die website:

Following Error and Stepper Driven Machines
The concept of a following error is funny when talking about stepper motors. Since they are an open loop system, there is no position feedback to let you know if you actually are out of range.

Following errors usually have two causes on steppers
1. too little ferror or min_ferror
2. the RT pulsing can't keep up with the speed needed
2.a. BASE_PERIOD set incorrectly or (requested step rate is not possible at this BASE_PERIOD)
2.b. max velocity too high
2.c. max acceleration too high

[bartL]

Toch nog even wat input gevraagd.

Inmiddels heb ik de NUC welke uiteindelijk ook in de machine moet komen aan de MESA kaart geknoopt. In eerste instantie had ik met deze pc exact dezelfde problemen als met de andere. Uiteindelijk besloten om een nieuwe Linux installatie uit te voeren en maar eens helemaal opnieuw te beginnen.
Toen ik internet erop had draaien heb ik allereerst nm-tray eraf gegooid en er een andere op gezet, dit werkt gelukkig heel wat aangenamer. Het adres instellen is nu dan ook gelukt via deze network manager.

Vervolgens voor de zekerheid ook de /etc/network/interfaces aangepast naar:

Code: Selecteer alles

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eno1
iface eno1 inet static
	address 10.10.10.11/8
	hardware-irq-coalesce-rx-usecs 0
	metric 10
#	gateway 10.10.10.1
	dns-nameservers 10.10.10.1

De kaart kan in nu pingen met ongeveer 0.2ms, is dit snel/langzaam?

Vervolgens de GUI opgestart maar helaas, vrijwel direct een watchdog error. Servo_period opgehoogd -zelfs even naar 5000000- maar zonder succes. Ergens zit er dus iets niet goed.
Nu blijkt er iets aan de hand te kunnen zijn met intel netwerk kaarten wat eruit te halen zou kunnen zijn met de ethtool. Dus met

Code: Selecteer alles

Sudo apt install ethtool

de tool geinstalleerd. En vervolgens met

Code: Selecteer alles

sudo ethtool -C eno1 rx-usecs 0

De boel uitgeschakeld.
Helaas... ook zonder succes.
Ping tijden blijven hetzelfde en wederom vrijwel direct komt de hond uit zn hok als ik hem opstart.

Nu heb ik met Dabit afgesproken om hem 1 dezer dagen even met teamviewer mee te laten kijken dus als er nog heldere ingevingen zijn dan zou ik dat graag horen dan kunnen we dat nog meenemen.

Bij voorbaat dank!

[hfjbuis]

De kaart kan in nu pingen met ongeveer 0.2ms, is dit snel/langzaam?

met 2 ms over wifi ben ik al blij. Voor een bekabeld netwerk is 0.2 ms goed en om wat gcodes rond te sturen meer dan genoeg.

[bbg]

Met mijn systeem zit ik ook ergens tussen de 0.2 en 0.3ms met een servothread periode van 1ms. Dat moet genoeg zijn. De watchdog heb ik wel op 5ms staan trouwens.

Dit is het stukje uit mijn ini file.

Code: Selecteer alles

[EMCMOT]
EMCMOT = motmod
COMM_TIMEOUT = 1.0
SERVO_PERIOD = 1000000

En dit stukje uit mijn hal file:

Code: Selecteer alles

setp    hm2_7i76e.0.watchdog.timeout_ns 5000000

Twee opmerkingen:
(1) Er worden geen gcodes verstuurd maar de netwerkverbinding zit in de "loop". (Vertaling gcodes naar stepper posities wordt op de PC gedaan. Generatie van steppulses op de mesa kaart). Ik vind zelf wel dat het een ping redelijk on de 1ms moet blijven (1khz regelfrequentie). De bandbreedte van de mechanica heb ik nooit gemeten maar zal wel een stuk lager liggen.

(2) Op mijn PC zitten meerder netwerk kaarten. De "ping tijd" lijkt dan afhankelijk van de volgorde waarin de verbindingen gemaakt worden. Direct na het booten levert ping 10.10.10.10 consequent een tijd meer dan 1ms. Ik weet niet precies hoe dit zit maar lijkt te maken hebben met de routing table of zoiets. Nooit uitgezocht wat er nu precies aan de hand is (als iemand suggesties heeft hoor ik het graag). Maar ik gebruik de volgende work around (die voor mij werkt). Elke keer na booten doe ik:

Code: Selecteer alles

/usr/sbin/ifdown enp2s0
/usr/sbin/ifup enp2s0

En dan geeft ping weer tussen de 0.2 en 0.3 ms (zolang de PC aan blijft).

Je hebt goede voortgang gemaakt! Dus met een teamviewer sessie met Dabit moet je er wel zijn.

[DaBit]

is 0.2 ms goed en om wat gcodes rond te sturen meer dan genoeg.

Dat is nou net niet wat LinuxCNC doet. In LinuxCNC draait alles op de PC, en is de hardware 'dom'; die maakt alleen maar stapjes of telt encoderpulsen.
Uitgaande van een SERVO_PERIOD van 1ms word elke milliseconde, strak elke milliseconde, alles geevalueerd. De trajectplanner berekent zijn volgende positie, alle logica word geeevalueerd, alle PIDS worden geevalueerd, bla. En ook alle communicatie met hardware word gedaan.

Dat betekent dus dat binnen die milliseconde alle communicatie met de hardware gebeurd moet zijn. Zowel LinuxCNC->hardware als hardware->LinuxCNC.

0.2ms heen, 0.2ms terug, en je bent al een redelijk deel van je 1ms periode kwijt. Als die 0.2ms de worst-case is dan is er niks aan de hand. Is dat de average en zitten er excursies naar boven in, dan kom je in de problemen. Als er wat powermanagement-spul op de PC in de weg zit waardoor die 'systick' niet strak 1.000ms is maar jittert, dan kom je in de problemen.

Voordeel van deze aanpak is schier oneindige flexibiliteit. Als je een paar Ethernet-kaarten en een parallelle poort wil mixen, dat kan. Heb je een werkstukwisselaar die met een knikkerbaan het product van de tafel af kegelt, ga je gang en leef je uit. Enzovoorts.
Nadeel is dat er wat basisvoorwaarden in orde moeten zijn, waaronder dus het realtime-gedrag van het hele systeem. Niet elke PC en Ethernetkaart is daar even goed in; ze worden niet ontwikkeld op goed realtime-gedrag.

En verder is de keerzijde van 'schier oneindig flexibel' vrijwel altijd 'stijle leercurve', want dan mag je zelf verzinnen wat goed is voor je in plaats van dat een ander dat al voor je uitgekauwd heeft. Dat geld voor Solidworks vs TinkerCAD net zo goed, om maar eens wat te noemen.

Met mijn systeem zit ik ook ergens tussen de 0.2 en 0.3ms met een servothread periode van 1ms.

Ik hoorde BartL zeggen dat de standaard servothread-periode 200000ns was (5kHz), klopt dat?

[bartL]

Ik hoorde BartL zeggen dat de standaard servothread-periode 200000ns was (5kHz), klopt dat?

Ik denk dat ik daar mis zat. Na de nieuwe installatie stond hij op 1000000.

[hfjbuis]

0.2ms heen, 0.2ms terug, en je bent al een redelijk deel van je 1ms periode kwijt.

In de ping tijd zit ook het opzetten van de verbinding. Als de verbinding is opgezet, gaat e.e.a. sneller. Bij gebruik zal het "streamen" wel sneller gaan.

Uitgaande van een SERVO_PERIOD van 1ms word elke milliseconde, strak elke milliseconde, alles geevalueerd.

Bij GRBL is "dat" standaard 5 ms. In grbl kan het dan ook 5 ms duren voordat een software commando zoals het stoppen van een JOG Move uitgevoerd wordt. Andere triggers zoals deur en Limit switch, worden door de controller meteen afgehandeld.
In hoeverre die 1 ms bij linux CNC (standaard waarde) echt nodig is, kan ik niet beoordelen.

Ik gebruik de ping alleen maar om te controleren of de ping tijd "constant" is en er geen ping gemist wordt. 2 "dure" TP-link routers heb ik, na een jaar van "problemen" om die reden vervangen door Linksys routers. TP-link maakt eigen chips die ook door andere merken (Zyxel) gebruikt worden.

[DaBit]

Het spul is verbindingsloos; er worden UDP pakketjes heen en weer geslingerd.
(ik heb de code er niet op nagekeken, maar ik geef je op een briefje dat meneer Wallace van Mesa de minimale IP-stack die daarvoor nodig is kneiterhard als statemachine in de FPGA geimplementeerd heeft. Zijn PCI-core in de 5i25/6i25 is ook maar een regel of 200 aan VHDL en vreet maar een klein stukje van een Spartan 6 LX9. Best indrukwekkend als je net zoals ik een nerd bent)

De enige vertraging die je hebt is de eerste keer dat je het IP van de Mesa-kaart probeert te bereiken; dan komt er nog een 'Who has 10.10.10.10?' ARP request bij.

In hoeverre die 1 ms bij linux CNC (standaard waarde) echt nodig is, kan ik niet beoordelen.

Hangt van de machine af. Als je met 100m/minuut assnelheid op de micron nauwkeurig wil positioneren dan is een 1kHz servorate waarschijnlijk niet genoeg. Draai je net zoals ik de complete servolussen in LinuxCNC in plaats van in de drive, dan is 1kHz ook onvoldoende.
Heb je daarentegen een machine die het hebben moet van op lage snelheid doorploegen met de 125mm mantelkopfrees, dan zal 100Hz ook al wel voldoen.

De default 1kHz is een uit de duim gezogen waarde. Mooi rond getalletje, langzaam genoeg om op de meeste hardware te werken, snel genoeg om op de meeste machines niet aan nauwkeurigheid in te boeten.

Je hoeft overigens ook niet alles op te krikken als je sneller wil. Heb je voor bepaalde taken nog een snellere thread nodig, dan kun je die gewoon aanmaken, zoveel als je PC aan kan. En als je aangeeft dat je geen floating-point gaat gebruiken in die thread (FP state save/restore is een kostbare operatie) dan kan-ie best vlot lopen. Zo doet LinuxCNC softwarestepping via de printerpoort; dan maken ze nog een extra 'base'-thread aan op zeg 50kHz, en daar laten ze de stepgens op draaien. Die kunnen dan met 50kHz pulsen produceren.

Deur, limitswitch, Estop, noem het maar op word overigens op die servofrequentie afgehandeld. Zeker met zaken als 3D-tasters iets om rekening mee te houden.

[bartL]

Vanmiddag nog even wat tips van het internet geplukt over de BIOS settings van Linux.
In die omgeving begint het mij al snel te duizelen maar het is me gelukt de Intel Virtualization Technology en de VT-D te disablen en de Primary power settings van "Balanced" naar "Max performance" te zetten.
Helaas heeft dit ook niet het gewensde effect.....

[hfjbuis]

(ik heb de code er niet op nagekeken, maar ik geef je op een briefje dat meneer Wallace van Mesa de minimale IP-stack die daarvoor nodig is kneiterhard als statemachine in de FPGA geimplementeerd heeft. Zijn PCI-core in de 5i25/6i25 is ook maar een regel of 200 aan VHDL en vreet maar een klein stukje van een Spartan 6 LX9. Best indrukwekkend als je net zoals ik een nerd bent)

De "eerste betrouwbare" 3com netwerk kaart had ook een FPGA. Dat was indertijd een "revolutie" en een enorme verbetering. Minder compenenten is minder kans op defecten.

Het spul is verbindingsloos; er worden UDP pakketjes heen en weer geslingerd.

UDP is supersnel en op een betrouwbare ethernet verbinding niet verkeerd.

[DaBit]

Technische zaken, soms zit het mee, meestal niet.

BartL had last van serieuze jitter. Volgens mij heb ik een keer 14 milliseconden langs zien komen. Ja, dan bijt de watchdog. Om dat op te lossen moest de hele trukendoos open. In de BIOS alle slimmigheid afzetten die er af te zetten was, Linux kernel-commandline naar "quiet intel_idle.max_cstate=0 processor.max_cstate=0 idle=poll isolcpus=1", en de CPU governor op 'performance'.

En dan is de latency nog niet geweldig, maar voorlopig kan hij wel vooruit.

[bartL]

Als ik het zo lees lijkt het net of het in 5min opgelost was

Maar nogmaals... mijn dank is groot! Ik heb het nog niet kunnen testen met een servo eraan maar tot nu toe lijkt alles beter te kloppen. De hond blijft in ieder geval in zijn hok. Hopelijk morgen even in het eggie testen!

[DaBit]

Als je de oplossing eenmaal hebt is het allemaal knap simpel. Alleen die weg naar de oplossing, die is meestal niet recht