W Raspberry Pi 5 (pięć) dokonano kilku zmian sprzętowych, co skutkuje tym, że pewne rzeczy nie działają (albo nie działają na razie, albo nie zadziałają nigdy), więc po prostu nie warto go do do LinuxCNC używać.
Druga sprawa to RAM. Niby wystarczy 1 GB, ale 2 GB kosztuje raptem ~30 PLN więcej, dołożyć pamięci w tym modelu się nie da, więc wersja z 2 GB wydaje się wyborem optymalnym. Oczywiście jak ktoś bogaty, to sobie może kupić bogatszy w pamięć model, ale czy będzie miał z tego korzyść to wątpię...
Trzecia sprawa to wielkość karty SD. 8 GB wystarczy do uruchomienia systemu i korzystania tak jak jest, ale dość szybko można zapełnić kartę i mieć wtedy problem. Dlatego polecam 16 GB albo więcej.
Sama instalacja jest banalna.
Zupełnie przypadkiem znalazłem to: https://forum.linuxcnc.org/9-installing ... =20#307541
Naprawdę warto skorzystać z tego (Pi4 Image) obrazu, bo ma lepszy kernel i mniejszy jitter, niż ten z oficjalnej strony linuxcnc.
Sama instalacja systemu przebiega normalnie i sprowadza się do rozpakowania obrazu na kartę SD, co można zrobić na kilka sposobów i co jest doskonale opisane w necie.
System uruchamia się gotowy do użytku, nazwa użytkownika cnc, hasło użytkownika cnc, sudo bez hasła.
Zasadniczo można używać tego systemu bez żadnych modyfikacji, trzeba tylko wejść do menu Settings/Power i powyłączać oszczędzanie energii przez ekran. Powinno się to zrobić najpierw przesuwając wszystkie suwaki na zero, a dopiero potem odznaczając "główny wyłącznik". Nie będę tego opisywał dokładniej, bo to podstawy obsługi systemu operacyjnego. Powiem tylko, że jak się tego nie zrobi, to można mieć przykrą niespodziankę - nagle ekran się wyłączy a użytkownik zostanie wylogowany...
Mnie jednak system w takim stanie nie zadowala, bo jestem przyzwyczajony logować się jako root. Tak w ogóle, to nikt nie musi logować się jako root jeśli tego nie chce, ale blokowanie programów tak, żeby użytkownik root nie mógł ich uruchomić to skrajny debilizm, wymyślony przez paranoików o osobowości bolszewickiej. Linux to nie Windows, w Linuksie użytkownik root może wszystko, nawet jeśli to będzie głupie, albo niebezpieczne...
W każdym razie ja czuję potrzebę skompilowania LinuxCNC po swojemu, czyli bez tej debilnej blokady. Dodatkowo wyłączam jeszcze jeden komunikat (unexpected_realtime_delay), bo mam podejrzenia, że to opóźnienie generuje sam proces uruchamiania programu, co nie ma wpływu na jego dalszą pracę. Miałem kilka róznych instalacji LinuxCNC sterujących realną maszyną, wszystkie raczyły mnie tym komunikatem i pracowały bez żadnego problemu, więc zdecydowałem to zablokować.
To jest ta łata:
Kod: Zaznacz cały
diff -Naur old/linuxcnc-master/src/rtapi/uspace_rtapi_app.cc new/linuxcnc-master/src/rtapi/uspace_rtapi_app.cc
--- old/linuxcnc-master/src/rtapi/uspace_rtapi_app.cc 2023-05-29 02:22:23.000000000 +0200
+++ new/linuxcnc-master/src/rtapi/uspace_rtapi_app.cc 2023-05-30 18:28:06.312487072 +0200
@@ -512,22 +512,6 @@
}
int main(int argc, char **argv) {
- if(getuid() == 0) {
- char *fallback_uid_str = getenv("RTAPI_UID");
- int fallback_uid = fallback_uid_str ? atoi(fallback_uid_str) : 0;
- if(fallback_uid == 0)
- {
- fprintf(stderr,
- "Refusing to run as root without fallback UID specified\n"
- "To run under a debugger with I/O, use e.g.,\n"
- " sudo env RTAPI_UID=`id -u` RTAPI_FIFO_PATH=$HOME/.rtapi_fifo gdb " EMC2_BIN_DIR "/rtapi_app\n");
- exit(1);
- }
- if (setreuid(fallback_uid, 0) != 0) { perror("setreuid"); abort(); }
- fprintf(stderr,
- "Running with fallback_uid. getuid()=%d geteuid()=%d\n",
- getuid(), geteuid());
- }
ruid = getuid();
euid = geteuid();
if (setresuid(euid, euid, ruid) != 0) { perror("setresuid"); abort(); }
@@ -935,7 +919,7 @@
}
void RtapiApp::unexpected_realtime_delay(rtapi_task *task, int nperiod) {
- static int printed = 0;
+ static int printed = 1;
if(!printed)
{
rtapi_print_msg(RTAPI_MSG_ERR,
Sama kompilacja przebiegła podręcznikowo (np. https://162.243.45.186/9-installing-lin ... t=0#178299) ,
Jednak tym razem postanowiłem zrobić to trochę inaczej.
Kernela oczywiście ruszać nie ma potrzeby, więc ten fragment pomijamy.
Po ściągnięciu źródeł i nałożeniu łaty nie instalowałem żadnych pakietów.
Miałem już takie przypadki, że instalowałem pakiety z listy znalezionej w necie, a potem się okazywało, że czegoś brakuje, a coś jest niepotrzebne...
Dlatego tym razem zacząłem tak:
Kod: Zaznacz cały
apt update
apt-get dist-upgrade
debian/configure uspace
dpkg-checkbuilddeps
Teraz trzeba przed nazwami pakietów dopisać apt-get install i usunąć kilka fragmentów.
Apt potrzebuje składni, w której są tylko prawidłowe nazwy pakietów, a dpkg-checkbuilddeps daje na wyjściu jeszcze dodatkowe informacje o wersji pakietu (w nawiasach) albo możliwości wyboru jednego pakietu spośród kilku podobnych (rozdzielone znakiem | ). To naprawdę nie jest trudne, choć można wybrać spośród proponowanych akurat ten pakiet, którego zainstalować się nie da... No cóż, metodą prób i błędów daje się zrobić to prawidłowo...
Potem kopiuj i wklej do terminala <klawisz shift + prawy klawisz myszy>
Trzeba tylko pamiętać, aby w edytorze tekstu wyłączyć zawijanie tekstu, żeby mieć wszystko w jednej linii.
W ostateczności, jak ktoś ma dużo czasu i uporu, to może instalować po jednym pakiecie i sprawdzać czego jeszcze brakuje...
Kiedy uruchomiony ponownie dpkg-checkbuilddeps wykona się w milczeniu, można uznać ten etap za zakończony.
Teraz uruchamiamy
Kod: Zaznacz cały
debuild -uc -us
Tutaj mała dygresja, że większość instalowanych pakietów i większość zużytego czasu, to budowa dokumentacji. Z jednej strony to jest straszne, z drugiej nie wiadomo czy ta dokumentacja kiedyś się nie przyda. Ja wiem, że można skompilować LinuxCNC bez dokumentacji, ale postanowiłem z tej opcji jednak nie korzystać.
Pomieliło i skompilowało...
W folderze wyżej znajdziemy skompilowane pakiety Debiana, które można zainstalować na różne sposoby. Ja lubię apt-get ./<nazwa pakietu> bo to zawsze mi działa szybko i bez problemów.
Jest jeszcze jeden patent, z którego warto korzystać.
Otóż parametry ładowane do kernela w czasie uruchamiania systemu są zapisane w pliku cmdline.txt Ten plik formalnie jest na partycji BOOT, ale w uruchomionym systemie jest do niego dostęp przez /boot/broadcom.
W tym pliku jest fragment isolcpus=2,3 który odpowiada za wyłączenie dwóch rdzeni z sheduler'a. Skutkuje to tym, że jitter się zmniejsza, ale także tym, że dwa rdzenie spośród czterech nie będą dostępne dla kompilatora. Wtedy kompilacja będzie trwała dwa razy dłużej..
Dlatego warto przed kompilacją większych programów fragment z isolcpus usuwać i restartować system, po czym wpisywać go z powrotem (ja sobie plik cmdline.txt kopiuje w bezpieczne miejsce i kiedy potrzeba nadpisuję oryginałem plik edytowany).
LinuxCNC 2.10 działa na opisywanym systemie, aczkolwiek dokładnie nie testowałem i gwarancji żadnych nie daję.
Powyższy opis można też wykorzystać na PC, choć są oczywiście pewne różnice.
Zasada jest jednak taka, żeby używać najnowszej wersji Debiana Bookworm, bo inaczej 2.10 może się nie skompilować, albo nie działać wcale, albo robić cuda...