Pierwsze podejście do EMC2

vitro pisze: Emc2 uruchomiony na VMware

jądro czasu rzeczywistego na żywym sprzęcie jest się w stanie miarodajnie samo-testować...
ale na virtualu... to już wyniki pewnie nie wiele mają wspólnego z rzeczywistością...

mój lapcio jest starutki travelmate5320 celeron 1.86GHz/3GB ramu/500GB
to raczej sprzęt dedykowany do grupopisarstwa i biurwienia...

natomiast blaszanka której używam do sterowań to jakiś stary athlon64 z 1gb... i jittera ma ok. 12us
i czyściutko steruję...

miałem kiedyś w ręku maszynę marzenie do emc2... jitter ok. 8us
ale to dziś trudne do zdobycia
PIII 1000 + troszeczkę ramu (nie trzeba wiele)

Naczytałem się na wielu forach o nieprzydatności laptopa do sterowania frezarką i co?
Próbowałem podłączyć się do blaszaka z nienajgorszym pokładem i szybko zrezygnowałem. Może to EMC2, Ubuntu, Compaq i moja frezarka z silnikami od MARKcomp'a i sterownikami z łódzkiej fimy to najlepszy skład jaki można sklecić. Frezuje w drewnie egzotycznym ramy do luster, wycinam litery z plexi, pcv i dibondu, od kilku miesięcy maszyna pracuje po kilka godzin dziennie i nie pamiętam kiedy popełniła błąd. Nie zamienię EMC2 na żadnego macha czy inny program sterujący pod windowsami.
Pozdrawiam

vitro pisze:Nie zamienię EMC2 na żadnego macha czy inny program sterujący pod windowsami.

a wszystko dlatego, że EMC2 może działać z jądrem czasu rzeczywistego...
silnik podczas sterownia z EMC2 nie zmienia brzmienia gdy użytkownik zbliża się do komputera
podczas frezowania można dla rozrywki puścić nawet odtwarzanie filmu na ekranie...
---

ale istnieją dalsze zalety systemów unix (linuks takim jest) które można dla naszej wygody zastosować...

np. praca zdalna...

tzn. ładujemy płytę główną (lub całą blaszankę) do szafki sterowniczej... i....
i łączymy ją z komputerem zdalnym za pomocą kabla sieci lokalnej (ethernet np)
lub... jeśli umieścimy w naszej blaszance sterownia kartę bezprzewodową wifi - kontakt i zawiadowanie sterowaniem będzie możliwy po sieci (w wersji wifi - bezprzewodowo)

to wymaga jedynie skonfigurowanie usługi zdalnego logowania... hehehe... przy szybkim łączu internetowym (i odwadze, że nikt nam się nie włamie z sieci do naszej frezarki) - pozwoli to nam mieć ekran sterownia EMC2 baaardzo daleko

markcomp77, wymaga jedynie zdalnego logowania? Pracuje głównie na ubunciakach i irytuje mnie ciągłe ganianie...:]

vitro pisze:Nie zamienię EMC2 na żadnego macha czy inny program sterujący pod windowsami.

Po kilku dniach prób i zabawy zaczynam mieć podobne odczucia. Nie mam wprawdzie porównania do Mach-a, o którym wiele ludzi wypowiada się pozytywnie. Kiedyś próbowałem go pojąć,ale szybko się zniechęciłem do tego programu.Jeżeli macie koledzy porównanie-napiszczie.
Kolego vitro- zmiana rozszerzenia pomogła-pliki stały się widoczne dla emc2,choć i tak nic nie zrobiłem. Chyba muszę w kodzie pozmieniać przecinki na kropki.
Oświećcie mnie jeszcze co oznaczają skróty DRO oraz MDI oraz do czego się ich używa. I może słówko o zastosowaniu funkcji G 54 (offset?)i jak z niej korzystać.
Z góry dzięki i pozdrawiam.
Tomek.

syntetyczny pisze:markcomp77, wymaga jedynie zdalnego logowania?

nie wymagam...
a jedynie zaznaczam istnienie takiej możliwości

a dlaczego?

ano po to aby w bardzo wielkich maszynach kable do silników mogły by być krótsze... aby nie poniewierały się w nie wiadomo jak długich prowadnikach

jeśli umieścimy kontroler ruch w szafce sterowniczej... a szafkę na ruchomej bramie 10m maszyny... to w prowadniku wzdłuż maszyny (10m) nie będą musiały znaleźć się kable wszystkich silników, a jedynie zasilanie + ew. kabel ethernet

---
w normalnej małej maszynce CNC ta komplikacja z dwoma komputerami nie jest potrzebna

[ Dodano: 2010-11-24, 21:08 ]

syntetyczny pisze:wymaga jedynie zdalnego logowania?

można to zorganizować bardziej elegancko...
np. przez pozbawienie komputera-kontolera ruch, twardego.. a nawet flasha
bootowanie z sieci (tak się robi dość często w dużych pracowaniach komputerowych, gdzie wszystkie końcówki są bezdyskowe... robiłem takie coś z 10lat temu... działa)

pixes2 pisze:DRO

digital read out - czyli wyświetlanie pozycji

[ Dodano: 2010-11-24, 21:17 ]

pixes2 pisze:MDI

musiałem odpalić EMCa... i poszukać
to jest tryb pracy pozwalający na wpisywanie instrukcji do wykonania

więcej na stronie linuxcnc.org w dokumentacji
a dokładniej:
http://www.linuxcnc.org/docview/html//c ... intro.html

1.6 Modes of Operation

When an EMC2 is running, there are three different major modes used for inputting commands. These are Manual, Auto, and MDI. Changing from one mode to another makes a big difference in the way that the EMC2 behaves. There are specific things that can be done in one mode that can not be done in another. An operator can home an axis in manual mode but not in auto or MDI modes. An operator can cause the machine to execute a whole file full of G-codes in the auto mode but not in manual or MDI.

In manual mode, each command is entered separately. In human terms a manual command might be "turn on coolant" or "jog X at 25 inches per minute". These are roughly equivalent to flipping a switch or turning the hand wheel for an axis. These commands are normally handled on one of the graphical interfaces by pressing a button with the mouse or holding down a key on the keyboard. In auto mode, a similar button or key press might be used to load or start the running of a whole program of G-code that is stored in a file. In the MDI mode the operator might type in a block of code and tell the machine to execute it by pressing the <return> or <enter> key on the keyboard.

Some motion control commands are available and will cause the same changes in motion in all modes. These include abort, estop, and feed rate override. Commands like these should be self explanatory.

The AXIS user interface hides some of the distinctions between Auto and the other modes by making Auto-commands available at most times. It also blurs the distinction between Manual and MDI because some Manual commands like Touch Off are actually implemented by sending MDI commands. It does this by automatically changing to the mode that is needed for the action the user has requested.

Heh:) sory za bałagan wypowiedzi;)

Czyli komputer-kontroler bootuje się z dysku sieciowego na którym jest zainstalowany linuxCNC i za pomocą zdalnego logowania uruchamiamy na komputerze-kontrolerze program, po czym możemy się wylogować, albo monitorować pracę?
Nasuwa mi się pytanie, czy przesyłanie danych po ethernecie (pomimo 10mb/s prędkości kabla, no chyba że się mylę z tą prędkością) nie powoduje opóźnień wykonywanego programu? Czy nie zwiększy to jittera?

syntetyczny pisze:Nasuwa mi się pytanie, czy przesyłanie danych po ethernecie (pomimo 10mb/s prędkości kabla, no chyba że się mylę z tą prędkością) nie powoduje opóźnień wykonywanego programu? Czy nie zwiększy to jittera?

intensywne wykorzystanie sieci ethernet zazwyczaj nie pogarsza jittera
a zbootowany... a następnie z zasobami zamontowanymi z sieci system jak każdy uniks ma silnie buforowane operacje na zasobach "dyskowych"... więc na użytkownika takiej końcówki (kontoler ruch) dużego wpływu to niema... zresztą zawsze ostateczny wynik leży w szczegółach: ilość pamięcie, wielkość gcodu..itd

ale z racji tego, że jądro tegoż systemu jest czasu rzeczywistego.. to będzie dbało o zachowaniu należytego pierwszeństwa kontroli ruch nad mniej istotnymi operacjami...

trochę wymaga to pracy...bo?
bo gotowe paczki jąder do bootowania po sieci nie są czasu rzeczywistego... więc trzeba sobie samemu przygotować...
właściwie to zastanawiam się, czy koledzy z linuxcnc gdzieś już czegoś nie przygotowali...
ot - trzeba poczytać

ta idea jakby rozdzielenie kontrolera ruchu i konsoli narzuca się przy naprawdę dużych maszynach.... "profesjonalne" kontrolery ruchu są bardzo kosztowne

a tutaj z linuksa można sobie ulepić coś o podobnej funkcjonalności... jeśli nie lepszej

a muszę sobie w firmie na stałe (zarazie bez bootowania) połączyć dwa linusie... jeden to sprawdzona blaszanka od sterowań... a drugi to laptuś z linuksem - czyli coś na konsole operatorską

linuks jest tak bogaty... sam proces logowania zdalnego można zrobić na N-sposobów... ale to chyba nic złego?... można zastosować nawet pakiet który konsole operatora zrobi z maszyny pod windowsem (teoretycznie... ciekawe jak by to w praktyce wyglądało... czy opengl z ekranu axis by się właściwie przenosił?)

[ Dodano: 2010-11-24, 22:54 ]

syntetyczny pisze:Czyli komputer-kontroler bootuje się z dysku sieciowego na którym jest zainstalowany linuxCNC i za pomocą zdalnego logowania uruchamiamy na komputerze-kontrolerze program, po czym możemy się wylogować, albo monitorować pracę?

na dysku komputera z którego bootuje się końcówka znajduje się jądro końcówki... ładowane zaraz po początkowej negocjacji bootowania sieciowego... a potem jądro już w końcówce podmontowuje obraz dysku systemu końcówki (ten obraz to zazwyczaj duży plik w którym jest cały system plików linuksa końcówki)

właściwie to można odwrócić role

twardy dysk... i rolę serwera do bootowania końcówek (jednej - konsoli operatora) nadajemy komputerowi w szafce sterownia - czyli kontroler ruchu to server

a system końcówki staje się wtedy mini linuksem którego celem jest jedynie zdalne logowanie na zasobach servera (czyli pełnego normalnego komputera z zupełnie normalnym ubuntu z emc2 do którego doinstalowano pakiety do bootowania klientów-końcówek po sieci)

to rozwiązanie jest zdecydowanie prostsze w realizacji
wada - w szafce która zasuwa po bramie (jak w samochodzie) znajduje się twardy dysk... trzeba by dać jakiś odporny na przeciążenia + dodatkowe zabezpieczenia.... ale top dotyczy również całego sterowania,.. wiec i tak to konieczne

ale zamiast takiej okrojonej końcówki.... przecież i tak możemy dać jakiegoś malutkiego netbooka...

aj... dużo pisaniny... muszę sprawdzić jak by to chodziło pod wifi...

Ja myślałem, o mini atx z pendrivem co pomieści systemik i to podłączyć do sieci. Jedynie 3ba by te konfiguracje pożenić z jądrem czasu rzeczywistego.

Co do połączenia windowsa i linuxa to już się spotkałem z takim rozwiązaniem. Bodajże siemens to preferuje. Cały system sterowania silnikami i interpretator gcode jest na linuxie, a jedynie wizualka procesu i panel operatorski jest na windowsie xp przeznaczonym do przemysłu. I pamiętam, że to rozwiązanie cieszy, gdyż winda ma skłonności do wieszania się(albo krzaczenia), i wtedy wystarczy reset, a maszynka nadal sobie dłubie, gdyż sam linux działa bez zarzutów.

[ Dodano: 2010-11-25, 22:08 ]
btw: Mach mnie odrzucił swoją mega funkcjonalnością. Za dużo tego tam jest na raz;O Nie to co emc2:)

syntetyczny pisze: pendrivem co pomieści systemik

robiłem instalkę na flashdriva - tragicznie wolno to działa
lepiej po prostu dać twardziel od lapcia (2.5") - będzie bardziej odporny na wstrząsy...

kiedyś były na ide przejściówki na SD flash... nawet mam (dos na tym działa)
może to szybciej chodzi.. kto wie

niema co wpuszczać się w długo trwające eksperymenty z kompilacją jąder... ja już nabawiłem się z kompilacjami wiele lat temu (i już starczy!)
jak już na coś przeznacza się czas - to warto aby był jakiś efekt... dlatego trzeba się skupić na budowie (wyborze) optymalnej konfiguracji połączeń...

dość ciekawym tematem jest również wybór jakiejś gotowej platformy ARMowej o bardzo ograniczonych zasobach (ale nie za bardzo) - i na tym posadzić mini dystrybucje linuksa z jądrem czasu rzeczywistego + EMC2... taka dedykowana platforma sprzętowa miała by lepszy jitter... co pozwoliło by na podwyższenie częstotliwości generowanych impulsów na linii STEP... ale to już raczej pomysł dla mocno komercyjnego działania (bo ktoś musi zapłacić za długi czas spędzony przy projekcie.. i potem chce zwrotu funduszy )