LinuxCNC workshop op de CNCzone dag

[hainjedaf]

Ik ga vannacht kijken of ik kernel8 kan compileren ivn arm.v8

[hainjedaf]

De Pi 3 heeft een 64-bit processor.
Kun je net zo goed zelf een kernel compileren; veel ingewikkelder is dat nou ook weer niet.

Klopt, heb je eerder ook al naar verwezen hoe dat gaat, maar was kennelijk was dat te ingewikkeld, gezien de vraag.
En het scheelt een hoop tijd.

Nou jand, snerender akn het niet, gezien ik nog ui het 0.97 tijdperk stam, 37 diskettes, een make config met 700 vragen over IRQ en DMA van je hardware en dan een hele nacht stampen. Hopelijk deed 'smorgens je monolytische kernel het, en kon je je wearnes cd gewoon gebruiken. Tot zo ver de wedstrijd ver pissen in Linux.

Qua 64 bit, is het algemeen bekend dat voor LinuxCNC een 32bit realtime kernel wordt geadviseerd.
En het compileren heeft helaas meer voeten in de aarde, ook de achterliggende basistools en het bootsysteem. Dat bij een ARM wezenlijk afwijkt van LILO/EFI/GRUB op de intel/AMD

Qua 'wat moet ik doen voor de Pi'; Die van die driver dabitusb.c had ik nog niet gezien tot het privebericht van DaBit.
Dat is al een ding dat je niet kan googlen. En dan heb ik het verder nog niet over de activering van Gmoccappy_LCD7,
en de eventueel aan te maken desktop link en startup script voor linuxcnc.

Uiteindleijk zal de excersitie opleveren dat ik pi en lap meesleep. De ene voor de ballen om dat het kan, de andere
om niet die eikel te zijn die de hele klas laat wachten.
En ja, gelukkig heeft connexxion me de avond ervoor niet nodig. De verdere week stap ik pas om 02:00 af.

[DaBit]

Tadaa:



Onze spulletjes zijn binnen.


En een wedstrijdje Linuxvaardigheid winnen jullie allemaal wel van mij. Ik gebruik dat spul ook al af en aan sinds 1994 zo'n beetje, maar dan gewoon omdat ik het nodig had. Veel 'engineering-software' was destijds niet onder Windows aan de pruttel te krijgen en onder een POSIX systeem probleemloos. Good old Berkeley SPICE 3F4 bijvoorbeeld. Multitasking was beter, remote-X erg prettig, en de ontwikkelomgeving uitgebreid.
Voor de rest werd je toendertijd al knettergestoord van al dat 'je hebt libSuperDuper.so versie 1.2.4 nodig en je hebt versie 1.2.3'. Wil die die upgraden, heb je weer 10 andere dependencies te vervullen. Vervul je die, krakt er ergens weer wat want libTralala-2.3.9 is incompatibel met libFlubberDieFlup-9.2.11-0. Enzovoorts. Als Linux je hobby is prima, maar ik wil gewoon een werkende springvorm voor m'n lekkere taartje en niet nog eens avonden besteden aan het dicht zien te krijgen van de sluitingen van die springvorm.

Nu ook weer op mijn laptop. Gek word je ervan:
- Laptop is een UEFI-ding en wat er aan Windows op staat moet gewoon blijven staan want daar verdien ik centen mee. Verder heeft dat ding een in de processor ingebakken grafische kaart en een NVidia kaart met Optimus technologie erlangs. Dus je hebt een recente distro nodig die de Windows-bootloader niet verkracht en die weet heeft van dat Optimus gebeuren. Prima, pakken we Ubuntu 16.04
- Voor Ubuntu 16.04 is geen realtime kernel beschikbaar in de standaard repositories, en er zijn geen patches voor de kernel die Ubuntu gebruikt. Prima, op kernel.org staan de sources en de patches, we bouwen zelf wel een kernel. So far, so good, maar je bent wel weer een avondje verder.
- Eclipse. Gezeik met Java, daarna gezeik met de GTK+3 in 16.04, moet je een of andere SWT_GTK3=0 setting doen en dan werkt het. Argl. Dat wil ik helemaal niet uitzoeken en weten, ik wil gewoon code kloppen.
- Geluid. Wel geluid vanuit Chrome en audacity, niet vanuit FireFox. Niet goed te klikklakken in een venstertje. Klooien met alsa-mixer en co, maar de analoge output is niet als default te krijgen. Pffffff. Nouja, 'valt mee te leven'.
- LinuxCNC. Uiteraard niet zomaar beschikbaar voor Ubuntu 16.04, nee, die moet je downloaden en compileren na een hele waslijst aan dependencies opgelost te hebben.
- En kunnen we dan ook ontwikkelen voor LinuxCNC? Dachtut niet, want je moet de GTK2 variant van Glade hebben ipv GTK3, en glade-gtk2 staat niet meer in de repositories. Zucht, gaan we weer.
- Een GTK2-compatible versie van Glade eindelijk aan de gang. Maar wel verdomd, waar zijn de LinuxCNC-specifieke widgets nou? Kun je weer een uurtje googelen en proberen tegenaan gooien. Uiteindelijk blijkt dan dat je toch nog de package 'python-gtk2' en wat environment-variabelen nodig had. Allemaal keisimpel als je eenmaal weet hoe het werkt.
- Dan probeer je of een 2e scherm aan je laptop ook nog wil werken. Helaas, dan krijg je een 'link training error' met de opensource videokaart-driver (nouveau). Naaah, geen probleem, installeer je toch gewoon de driver van NVidia zelf? Dat kan zelfs met klik-klak-klaar. Joehoe!
- Nou, dachtut niet, want die probeert modules te compileren, en herkent de realtime-kernel niet als een ondersteunde. Patsboem. Maar na een reboot blijkt de bende wel voor de helft geinstalleerd te wezen, want het scherm blijft mooi pikzwart.
- Reboot in recoverymode. Rootfs remounten als read-write. Nvidia spul verwijderen vanaf de command prompt. Xorg.config herstellen. Reboot. Jippie, weer beeld.
- Dan de driver maar downloaden bij NVidia. Proberen te installeren. En toen zakte mijn broek helemaal af: dat kan niet want een of andere kernelfunctie is geexporteerd met EXPORT_SYMBOL_GPL, dus alleen opensource-dingen mogen die functie aanroepen en closed-source dingen niet. Waaaaaaaaaaaaaaat?????
- Het boefje uitgehangen en in de broncode van NVidia een aantal MODULE_LICENSE dingen op 'GPL' gezet ipv NVIDIA. Installeren, reboot, enkel 1024x768. Adem-in, adem-uit.

En toen kwam het stoom onderhand wel uit m'n oren. Echt waar, waarom moeten de simpelste klussen die niet door een ander ooit voorgekauwd zijn toch altijd weer zo achterlijk lastig uitvallen onder Linux?

Als je dat soort exercities ooit doet snap je heel goed dat die LinuxCNC-meneren en mevrouwen niet alleen het pakket leveren maar een compleet systeem inclusief OS waar alles kant en klaar is. Dan heeft iemand anders al die ellende al gehad, en dan werkt het gewoon.

Nee, Windows op de desktop is zo vies nog niet. Je download wat of koopt iets in de winkel, je installeert het, en tadaa, meestal werkt het dan gewoon. Best fijn zo af en toe.

[hugo stoutjesdijk]

Nou, ik dacht dat je ons enthousiast ging maken voor LinuxCNC.

Goed, spulletjes zijn er, laptop, VMware, downloads van Dabit doen het ook.
Wat verwacht je nog van ons, hoe gaan we die printjes aan elkaar knopen, moet er gesoldeerd ( is 1 aanwezige bout voldoende?), draadjes, kniptangetjes. Misschien een breadbordje of USB kabeltje meenemen?

En het is 9:30 beginnen? geworden als ik me niet vergis.

[DaBit]

Gewoon LinuxCNC werkt prima. Je download de ISO van de site, installeert 'm, en je kunt aan de slag. Standaard dingetjes toevoegen is ook geen drama; daar is een ander al het grijze-haren stadium voor door gegaan.
Maar als je Hainjedaf of DaBit ofzo heet en je wil allemaal van die gekke dingen omdat je vind dat het maar moet kunnen, ja, dan krijg je de volle lading ellende over je uitgestort


Die printjes gaan we met draadjes aan elkaar knopen door middel van solderen. Spaghetti dus.
Dat is helemaal niet praktisch en voor velen ook helemaal niet eenvoudig om voor elkaar te krijgen, maar als je dat lukt hoef je je over geeneen draad in je toekomstige CNC-machine meer zorgen te maken. Voor jou is het een fluitje van een cent, dus als je klaar bent mag je een ander gaan helpen

Ik zal zorgen dat ik een bosje draad bij me heb. Soldeerbouten hebben we niet eentje per persoon nodig en komen van mij, Hainjedaf en de school af. Maar als je de jouwe ook mee wil nemen: graag uiteraard.

Breadbordjes zijn sneller en handiger dan solderen, als je die eentje hebt mag die mee. Ik heb dat spul simpelweg niet voor iedereen, vandaar draadjes-solderen.

Kwa meenemen: ik had een paar dagen geleden de startpost aangepast, maar volgens mij had ik dat niet hier vermeld

9u30 was een voorstel, en volgens mij staat dat nog steeds.

[DaBit]

Zo, USB-modificatie is gebeurd.
Nog net geen 20 minuten werk. Viel mee.

[hainjedaf]

ik neem mee:

-Labvoeding 2x30V/3A, 5V/3A (kan iemand meeliften op 24V)
-Voeding 24V / 7 A (gewoon zo'n schakelende met een 220V snoer eraan. op eigen risico te leen)
-Soldeerspullen
-2 Breadboards en draden
-Schroevendraaiers, kniptang
-2x micro usb - usb a
-schroefklemmen
-multimeter
-Laptop en de rest...

heeft 0.14mm2 draad zin? we gaan geen megastromen trekken toch?

[DaBit]

Neu, als er 1 ampere loopt is het al veel. Dikker draad is ook veel te lastig met die kleine pinnetjes.

[offtopic]

Code: Selecteer alles

find . -type f -name '*.c' -exec sed -i 's/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/g' {} \;

op de kernelsources, mhuuhaha, ik zal die @#$$%@ wel eens mores leren.
Nvidia driver doet het, DisplayPort uitgang van de laptop ook. Maximale latency neemt wel gruwelijk toe (114460ns).

Mooi, kan ik ook gewoon eigenwijs zijn dus. Gelukkig maar.
[/offtopic]

[hainjedaf]

[offtopic]Nvidia sux. Dat is al bekend sinds voor de buggy implementatie van sata.

Gezien het gebrek aan open source drivers, loop ik om alles Nvidia met ee. Boog heen. Maar ja ik ben ook een amd Power user[/offtopic]

[javanree]

Wow, wat een project is dit aan het worden.
Ik ga helaas de open dag niet redden (dezelfde dag als de HRN open dag in Oudorp bij de RTM...) anders had ik graag meegedaan. Hoewel ik al redelijk ver ben met LinuxCNC had ik dit erg leerzaam gevonden.

En het gekloot herken ik enigszins, Marout's oplossing echter totaal niet... wil je echt geen gekloot onder Linux ben je beter af met Intel ; performance van hun video spul is tegenwoordig voldoende om films te kijken en voor CAD/CAM en het is volledig idiotproof. Maar goed, als je het moet doen met wat je hebt.

[hainjedaf]

Intel werkt idd probleemloos. Zeker als je ol Safe moet spelen zoals in real time.

Amd biedt imho meer bang for the Buck. I.e. de performance van een gelijkgeprijsde amd en Intel wordt door amd ruimschoots gewonnen. Echte zware grafische taken gaat Intel niet redden. Moet er toch een videokaartje naast.

Daarom is de bureau machine een amd maar de frees een intel. Amd is dan wel rap, maar op real time gaat ie toch op zijn bek.

Probleem van. Nvidia is de zeer gesloten structuur en de arrogantie naar de klanten. Ze leveren wel drivers maar uitsluitend als closed source modules. Met hun moederborden was ik gauw thuis. Het heeft 3 of 4 generaties geduurd voordat een aantal hardnekkige hardwarebugs uit hun sata controllers was. Zo erg dat bij Western digital disks er niet mee werkten.
Sta je lekker mee als System integrator en de harddisk lopen gewoon vast door buggy hardware met 0,0 support van de fabrikant.

Ik

[DaBit]

Ze leveren wel drivers maar uitsluitend als closed source modules.

Da's hun goed recht. Van de bakker van het winnende lekkerste worstenbroodje van het jaar verwacht je ook niet dat-ie zijn recept maar gewoon openbaar maakt. Maar als je dan software bakt in plaats van worstenbroodjes moet je dat wel doen?

Het is irritanter dat je na 20 jaar ofzo nog steeds niet een binaire driver kunt downloaden, registreren bij de kernel, en gebruiken. Alle drivers in Linux moeten perse maatpakken zijn die op maat gemaakt zijn voor meneer kernel (en je krijgt bij een Linux-installatie dan ook alle duizenden drivers voor alle apparaten kado).

Dat lost NVIDIA (en bijvoorbeeld VMWare ook) op door een deel van de driver in sourcevorm te leveren en een deel binair. Zeg maar een gewonemensenpak met kleermaker die de boel nog even aanpast. Dat 't uberhaupt nodig is, is eigenlijk al van de zotte. Kost ze ook een hele hoop moeite om dat te laten werken.

En dan nog ontploft het omdat een of andere baardaap verzonnen heeft dat het aanvragen van een bepaald type mutex alleen maar mag door software met GPL licentie. Niet iets heel spannends, nee, iets heel basaals.
Met dat soort ongein moet er toch wel aardig wat geld te verdienen zijn wil je als bedrijf zeggen 'wij ondersteunen actief Linux'...

[DaBit]

We hebben 1 tegenwerping tegen de starttijd van 9u30, en eentje die het graag niet veel later zou zien.

Oftewel, starttijd: 9u30

[javanree]

Het is irritanter dat je na 20 jaar ofzo nog steeds niet een binaire driver kunt downloaden, registreren bij de kernel, en gebruiken. Alle drivers in Linux moeten perse maatpakken zijn die op maat gemaakt zijn voor meneer kernel (en je krijgt bij een Linux-installatie dan ook alle duizenden drivers voor alle apparaten kado).

Dat lost NVIDIA (en bijvoorbeeld VMWare ook) op door een deel van de driver in sourcevorm te leveren en een deel binair. Zeg maar een gewonemensenpak met kleermaker die de boel nog even aanpast. Dat 't uberhaupt nodig is, is eigenlijk al van de zotte. Kost ze ook een hele hoop moeite om dat te laten werken.

En dan nog ontploft het omdat een of andere baardaap verzonnen heeft dat het aanvragen van een bepaald type mutex alleen maar mag door software met GPL licentie. Niet iets heel spannends, nee, iets heel basaals.
Met dat soort ongein moet er toch wel aardig wat geld te verdienen zijn wil je als bedrijf zeggen 'wij ondersteunen actief Linux'...

Voor een heel groot deel van de gebruikers werkt het echter gewoon 'out of the box' en zonder toveren...
Voor de rekenclusters en workstations met nVidia GPU's die ik manage gebruik ik gewoon de nVidia driver repository, die ik lokaal gemirrored heb. Bij iedere driver update doet DKMS op de achtergrond z'n magie en het werkt gewoon out of the box. Ook bij een nieuwe kernel doet DKMS op de achtergrond z'n werk en updates zijn dus redelijk triviaal geworden. Vermoedelijk doet 80-90% van de Linux + nVidia gebruikers ongeveer hetzelfde, want ook die hoor je amper klagen. En je kunt het er wel of niet mee eens zijn, maar nVidia GPU's zijn voor veel wetenschappelijk werk (mede door CUDA!) nu eenmaal een klasse apart, dus heb je weinig keus.