Realtime Ethernet w EMC2 i CNC

ArturM pisze:'mam syf przy maszynie i lepiej się odsunąć z komputerem/ekranem dalej niż LPT sięgnie'. Tak?

nie... nie tylko o to
przy dużej maszynie
kable do silników, te najdłuższe będą miały kilkadziesiąt metrów (kilkanaście przy mniejszych maszynach)

a co jeśli zamiast krokowców mamy serwa?... to dochodzą do tego kable enkoderów, które nie lubią być długie

markcomp77 pisze:[ czasem dużo kosztuje.... a potrafi być wręcz szkodliwa w razie awarii

Kol.Marku - ile razy przez te lata usuwałeś awarie w naszych (Twoich ) sterowaniach ?

kamar pisze:ile razy przez te lata usuwałeś awarie w naszych (Twoich ) sterowaniach ?

jakoś nie mogę sobie przypomnieć...

markcomp77 pisze: przy dużej maszynie
kable do silników, te najdłuższe będą miały kilkadziesiąt metrów (kilkanaście przy mniejszych maszynach)

a co jeśli zamiast krokowców mamy serwa?... to dochodzą do tego kable enkoderów, które nie lubią być długie

No OK - ja to rozumiem i widzę, że czasem to jest zbawienne rozwiązanie. No ale wygląda na to, że przy normalnej (z sensie rozmiarów ) frezarce czy ploterze to jedyna zaleta jest taka, że omijamy nie-RT Windę przy generowaniu impulsów. A przy Linuchu to gra nie warta świeczki - no bo jakbym faktycznie musiał się 'odsunąć' z kompem to bym raczej uciekał w zabudowanego kompa i klienta Xsów odpalonego zdalnie niż w jakieś zabawy z dodatkową elekroniką.

No ale tak jak ojciec pisał - te nasze sterowania i kompy robią w takim syfie że chyba tylko pod wodą miałyby gorzej
A awarie były przecież:
- 1 spalony sterownik m542 (chyba) - przez skok napięcia w sieci
- 1 spalony przekaźnik
- no i z 10 spalonych biezpieczników
- chyba się kiedyś któryś wypasny Compaq za 100zł spalił (w sensie ze płyta, bo dysk przełozyliśmy i jak to Linuch - wstał i robił dalej )

Sterowań jest chyba 9, najstarsze ma 4 czy 5 lat - więc awaryjność powalająca uwzgledniając, że raczej wszystkie pracują na pełny etat

No dobra - przekonaliście mnie - nawet nie będę googlał o tym Ethernecie

markcomp77 pisze:

kamar pisze:ile razy przez te lata usuwałeś awarie w naszych (Twoich ) sterowaniach ?

jakoś nie mogę sobie przypomnieć...

Ja też
A stoją bezpośrednio przy maszynach, tylko klawiatury na wysięgnikach a długość kabla od klawiatury chyba niewielki ma wpływ.

Mamy rozwiązanie idealne - Sterowanie EMC2 na Linusie steruje poprzez port LPT dodatkowo wychodzi że jest tanie, w dotychczasowej eksploatacji nie mięliśmy problemów .

Jeśli ja będę tym użytkownikiem i takie sterowanie mi wystarcza to ok., podpisuje się pod stwierdzeniem „rozwiązanie idealne”.

Mogę przytoczyć test kolegi faniron-a który przy specyficznej ścieżce narzędzia sprawdza sobie wydajność komputera sterującego maszyną poprzez port LPT. Mówi że jego najlepszy komputer stabilnie pracuje przy tej ścieżce narzędzia (Mach3 + LPT) przy posuwie 3600mm/min (najlepszy jego wynik) ale dodaje ze jak inny komp pracuje przy posuwie 3000mm/min to jest to bardzo dobry wynik.
Dalej dodawał że EMC2 przy tej samej ścieżce narzędzia miał wynik poniżej 500mm/min.
Mach3 + Ethernet miał ten wynik 10.000mm/min bo taki był nastawiony czy można było więcej oczywiście. Kolega Faniron na swoim przykładzie był zawsze orędownikiem Mach3 + LPT.
Dla niego jest to idealne rozwiązanie.

Dlaczego Ethernet - stabilność działania – stąd połączenie z komputerem PC poprzez sieć ETHERNET, a stosowane protokoły zapewniają poprawną i szybką transmisję nawet w trudnym środowisku przemysłowym. Praktycznie żadne inne interfejsy komunikacyjne nie zapewniają ciągłości transmisji i niezawodności na tak wysokim poziomie jak ETHERNET. Z resztą z tego właśnie powodu jest to obecnie światowy standard szybkiej komunikacji cyfrowej.


Rozwiązanie idealne – możliwość sterowania podobno do 9 osi jak koledzy podają ma EMC2 , na pewno więcej niż Mach czyli jak potrzebuje sterowanie 8 osiami osiami idealnym rozwiązaniem będzie program pod Linux-em bo to będzie podstawowe założenie. Od siebie dodam tak, chciałem mieć oczywiście według swoich kryteriów idealny samochód na polowania nie do off-road (mam też mercedesa G-klase i różnice łapię jak by co) taki samochód którym dojeżdżam prawie 100km autostradą dalej 10-20 km bocznymi drogami a w terenie trochę po polach i lasach ze 20 km, żaden ciężki teren potem powrót w odwrotnej kolejności. Wybór padł na subaru, idealnym rozwiązaniem byłby silnik diesla jest jeden problem, dla mnie idealnym rozwiązaniem jest samochód który ma automatyczną skrzynie biegu, a taka jest dostępna tylko z silnikami benzynowymi.
W moim idealnym rozwiązaniu wyżej stawiam automat od diesla, ale ktoś inny może się z tym nie zgadzać, na pewno tak będzie.

Nie ma idealnego rozwiązania dla wszystkich, to co jedni potrzebują innym nie wystarcza. Kiedyś podczas rozmowy z Panem z firmy od cncGraF-a jak rozmawialiśmy aby do programu dołączyli obsługę czujnika pomiaru długości narzędzia odpowiedzieli że maja klienta z Dani który produkuje ponad 50 maszyn rocznie na ich sterowaniu i on im mówi że takiej konieczności nie widzi.

Dalej, mam klienta który wybrał serwonapędy z enkoderami 160 tys. imp/Obr – nawet MACH po Ethernecie max kręcił by nimi 1500obr/min (z uwagi na ograniczenie taktowania 4 Mhz)
Co mu zapewni EMC2 ? 30 obrotów a może wyprujemy sobie bebechy pomodlimy się i … osiągniemy 100 obr/min .

Proponuje po testować różnice w sterowaniu i problem sam się rozwiąże w jedną lub druga stronę.

Piotrjub pisze:Dalej dodawał że EMC2 przy tej samej ścieżce narzędzia miał wynik poniżej 500mm/min.
.

Zdolna bestia - jak on to zrobil. takie to ja mam posuwy robocze na 300kg stole przu obróbce tworzywa



Jeśli reszta testów tez tak wiarygodna to nic tylko do polityki.

Piotrjub pisze: ciach rozwiązania idealne

Czyli jednak konsensus jakiś jest - że nie to ładne co ładne tylko to co się komu podoba

Piotrjub pisze: ciach prędkości i cytat z kolegi któremu EMC chodzi wolniej niż Mach

No widzisz, tu jest pewnie główne ziarno 'niezgody' - bo ja nie bardzo wiem jak szybko te nasze maszyny chodzą - czy mają 5mm/min czy 5000mm/min - one i tak 'na full' chodzą tylko na G0 - przy pracy trzeba zwalniać albo bardzo zwalniać - więc mało mnie raduja jakieś tam cyferki - mnie raduje wielka góra wiórów pod maszyną
Inna sprawa że tak po prostu nie wierzę, że na tym samym komputerze Windows+Mach po LPT będzie miał lepszy wynik niż Linux RT po LPT - bo jeżeli tak to na jaką intencję mądrzy ludzie jądra RT wymyślają?
Te wszystkie 10000mm/min to normalnie o zawrót głowy przyprawiają - no ale jak bierzesz frezem fi40 10 mm aluminium to chyba wolniej trochę jedziesz? czy też te 10000?

Piotrjub pisze: Dlaczego Ethernet - stabilność działania – stąd połączenie z komputerem PC poprzez sieć ETHERNET, a stosowane protokoły zapewniają poprawną i szybką transmisję nawet w trudnym środowisku przemysłowym. Praktycznie żadne inne interfejsy komunikacyjne nie zapewniają ciągłości transmisji i niezawodności na tak wysokim poziomie jak ETHERNET. Z resztą z tego właśnie powodu jest to obecnie światowy standard szybkiej komunikacji cyfrowej.

Hmm, no tak, no tak coś o tym całym Internecie co to cały na protokołach Ethernetowych stoi słyszałem i nawet kiedyś tam bylem...

Widzę, że żartujemy po całej linii - my też mamy komunikację po Ethernecie w 'trudnym środowisku przemysłowym' - jak nagrywam kod na maszynę.

A poważniej:
Masz tak:

Mach->Ethernet->[ ]->Sterownik->Silnik, tak?

To jakie zalety ma to [ ] w stosunku do komputerka z jądrem RT (czy jak Marek proponował - dedykowanego komputerka bez grafy i klawy z jądrem RT i sieciówką))

Piotrjub pisze: Od siebie dodam tak, chciałem mieć oczywiście według swoich kryteriów idealny samochód na polowania nie do off-road (mam też mercedesa G-klase i różnice łapię jak by co) taki samochód którym dojeżdżam prawie 100km autostradą dalej 10-20 km bocznymi drogami a w terenie trochę po polach i lasach ze 20 km, żaden ciężki teren potem powrót w odwrotnej kolejności. Wybór padł na subaru, idealnym rozwiązaniem byłby silnik diesla jest jeden problem, dla mnie idealnym rozwiązaniem jest samochód który ma automatyczną skrzynie biegu, a taka jest dostępna tylko z silnikami benzynowymi.
W moim idealnym rozwiązaniu wyżej stawiam automat od diesla, ale ktoś inny może się z tym nie zgadzać, na pewno tak będzie.

No jasne że się nie zgadzam ;P Mam LR Discovery (diesel, manual) - i elegancko spełnia Twoje wymagania - na autostradzie lepszy niż G a w błocie niż Subaru A jeżeli chcesz diesla i w automacie to polecam LR Discovery II z silnikiem TD5

Piotrjub pisze: Dalej, mam klienta który wybrał serwonapędy z enkoderami 160 tys. imp/Obr – nawet MACH po Ethernecie max kręcił by nimi 1500obr/min (z uwagi na ograniczenie taktowania 4 Mhz)
Co mu zapewni EMC2 ? 30 obrotów a może wyprujemy sobie bebechy pomodlimy się i … osiągniemy 100 obr/min .

No śliczne cyferki - a teraz mi powiedz co jest takiego w tym [ ] że będzie kręciło 1500obr/min wtedy kiedy EMC2 30 obrotów na minutę - może tak sie dogadamy.

Piotrjub pisze: Proponuje po testować różnice w sterowaniu i problem sam się rozwiąże w jedną lub druga stronę.

Jakie różnice w sterowaniu? Że mam postawic u siebie Windowsa + Macha? Nienienie - to już było przerabiane. Dzyt dzyt, zgrzyt zgrzyt, fiuu Winda poleciała, reboot, dzyt dzyt, zgrzyt, zgrzyt, uuu Mach nie odpowiada, i tak dalej do bólu
Żadne 10000mm/min mi nie zrekompresuje sumarycznego czasu rebootów dziennych
Do tego przy awarii komputera nie przełożę dysku do innego, nie zainstaluje systemu spod VirtualBoxa na dysku który postawie na półce żeby czekał na awarię (znaczy postawic postawię - tylko mi potem ten dysk nie wstanie w komputerze na hali)).
Do tego jestem głupi i nie umiem w gcode pod Machem robic pętli, wywoływać podprogramów (z aktualnego pliku albo z plików z biblioteki) itp, itd. - Mach nie wchodzi w grę - ew. w grę wchodzi sterowanie EMC2 po Ethernecie - ale na razie jakoś zalet nie widzę a tylko dodatkowe koszty i dodatkową robotę z konfiguracją.

Zamiast niestety pisać o czymś o czym nie mamy pojęcia i dalej snuć dywagacje
takie to ja mam posuwy robocze na 300kg stole przu obróbce tworzywa
proponuje poczytać ze zrozumieniem i przeanalizować dokładnie słowa

napisałem "przy specyficznej ścieżce narzędzia" - mamy dwa rozwiązania
- jedno to wykonał kolega test który wykonywał kolega faniron i wie na czym on polegał
- drugie rozwiązanie kolega nie wie co pisze - ja nie pisałem że kolega nie może osiągnąć posuwu 500mm/min napisałem że przy konkretnej ścieżce narzędzia EMC2 nie dawał rady.

Może kolega zapytać kolegę faniron-a na czym polegał ten test wygenerować G-kod spróbować puścić go na swojej maszynie z zadaną prędkością, nagrać film z dźwiękiem jak maszyna pracuje i pokazać ekran EMC2 z zadanymi parametrami. Po prostu udowodnić swoje twierdzenie. Ja dopytując się kiedyś kolegi faniron-a na temat EMC2 usłyszałem co napisałem. Poprosiłem kolegów aby zrobili test taki jak kolega faniron na mach3 po Ethernecie dodam że nagrali filmik i umieściłem go na forum.
Czekam na filmik z testów i bardzo chętnie zmienię zdanie na temat EMC2

Piotrjub pisze: Może kolega zapytać kolegę faniron-a na czym polegał ten test wygenerować G-kod spróbować puścić go na swojej maszynie z zadaną prędkością, nagrać film z dźwiękiem jak maszyna pracuje i pokazać ekran EMC2 z zadanymi parametrami.

Wybacz Kolego, aż tak to mi nie zależy. Macie specyficzne kody ,podeślijcie, puścimy i nagramy.