Kilka sterowników na jednym porcie Ethernet

[tuxcnc]

Witam
dobrze by było żeby jednak pin wejściowy indeks był jako opcja przyszłościowo chociażby
dobry byłby też pin zerujący od strony hal , można wtedy zerować jak ktoś tam sobie chce i kiedy chce
z homingiem czy w zależności od potrzeby, + enable w hal i więcej nic nie trzeba
+ jakiś pin przepełnienia

Też tak myślałem, ale to chyba nie jest takie proste.
Oczywiście o przepełnieniu mowy nie ma, pozycja to zmienna typu float (nie to żeby nie przepełnić, tylko HAL oczekuje takiego typu, no to musi dostać).
Natomiast z tym zerowaniem to jest taki problem, że co prawda można zrobić bazowanie na 0,0,0, ale obowiązku nie ma... Maszyna po bazowaniu może stanąć na dowolnej pozycji i wtedy wyzerowanie liniałów nie ma sensu. myślałem o G53 G0 X0 Y0 Z0 i wtedy wyzerować, ale taki ruch nie zawsze może być wykonalny... No i jeszcze można zbazować bez krańcówek, czyli w przypadkowym miejscu...
Myślę, że to trzeba przemyśleć...

Dodane 1 godzina 4 minuty 42 sekundy:

Podłączyłem tę drugą chińszczyznę i klęska totalna. Można powiedzieć, że nie działa w ogóle

(Chodzi o ten https://www.aliexpress.com/item/1005005990249863.html)
No po prostu nie działał, czasem jakieś urządzenie zobaczył, ale tylko jedno, a reszta jakby nie była w ogóle podpięta.
Stwierdziłem, że więcej "okazji" nie będę próbował, bo w końcu wydam kasę i nie będę miał niczego, więc z bólem serca kupiłem na Allegro Edimax SWITCH GS-1005E za całe 53 PLN, który dzisiaj przyszedł.
Ale tamten PIX-LINK nie dawał mi spokoju. Sprawdziłem w necie, to duża firma, produkują wiele modeli, więc to nie powinno być totalne badziewie.
No i jak przyszedł ten Edimax, to stwierdziłem że ma taki sam zasilacz (5V/1A), więc można by sprawdzić chińszczyznę, czy feler nie tkwił w zasilaczu... Po podłączeniu zasilacza od Edimax, PIX-LINK ożył i pracuje bez zastrzeżeń.
Dysponując dwoma sprawnymi switchami połączyłem je dla testu szeregowo. Nie wpłynęło to na pingi, dalej były takie same.
Urządzenia na W5500 odpowiadają dwa razy szybciej od tego WT32-ETH01 na LAN8720.
Co ciekawe, po uruchomieniu LinuxCNC pingi znacząco spadły (W5500 poniżej 150 ms a LAN8720 poniżej 300 ms).
Tak więc ani podłączenie trzech sterowników, ani dwóch switchy nie wpłynęło na wyniki testów.
Należy więc przyjąć założenie, że jeżeli do jednej karty sieciowej w komputerze będą podłączone wyłącznie sterowniki LinuxCNC, to powinny działać prawidłowo.
Pytanie tylko z jaką prędkością komputer wyrobi. Nie spodziewam się tutaj jakichś problemów, bo współczesne komputery są naprawdę szybkie.
Na tym, którego używam do testów (AMD A10 i frezarka na UDP2HAL) mam wykorzystanie rdzeni rzędu 20% (nawet nie robiłem isolcpus, bo nic nie dawało) i transmisję po sieci rzędu 150 kB/s. Nie sądzę żeby podłączenie kilku sterowników zapchało procesor albo sieć, ale teraz nie mam nastroju na robienie testów.

[qqaz]

Maszyna po bazowaniu może stanąć na dowolnej pozycji i wtedy wyzerowanie liniałów nie ma sensu. myślałem o G53 G0 X0 Y0 Z0 i wtedy wyzerować, ale taki ruch nie zawsze może być wykonalny..

piszesz o zatrzymaniu poza 0,0,0, że przeleciało? Nie potrzeba wracać na zerową pozycje liniału tylko ustawiać liczniki do zgodności. Wtedy ruch jest niepotrzebny.
Albo o coś innego Ci chodzi.

[tuxcnc]

Albo o coś innego Ci chodzi.

Tak, chodzi mi o coś innego.

[drzasiek90]

Natomiast z tym zerowaniem to jest taki problem, że co prawda można zrobić bazowanie na 0,0,0, ale obowiązku nie ma... Maszyna po bazowaniu może stanąć na dowolnej pozycji i wtedy wyzerowanie liniałów nie ma sensu. myślałem o G53 G0 X0 Y0 Z0 i wtedy wyzerować, ale taki ruch nie zawsze może być wykonalny... No i jeszcze można zbazować bez krańcówek, czyli w przypadkowym miejscu...
Myślę, że to trzeba przemyśleć...

Urządzenie powinno mieć po prostu możliwość ustawienia aktualnej wartości pozycji - czyli ustaw aktualną pozycja na wartość.
A odpowiednią logikę trzeba zrobić w halu, w zależności od tego jak się będzie bazować.
Jak ktoś będzie miał dziwne pomysły na bazowanie to będzie musiał pokombinować aby odpowiednią logikę dla siebie zaimplementować.
Swoją drogą, jeśli ma to być moduł obsługi enkoderów/linialow to fajnie gdyby miał typowe w przemysłowce wejścia na enkodery liniały również absolutne. Interfejs Biss/ssi implementuje się bardzo łatwo.
No ale wymaga pracy.

[tuxcnc]

fajnie gdyby miał typowe w przemysłowce wejścia na enkodery liniały również absolutne.

Jak zwykle przeginasz pałę...

Dodane 24 minuty 34 sekundy:

dobrze by było żeby jednak pin wejściowy indeks do mikrokontrolera był jako opcja przyszłościowo chociażby
dobry byłby też pin zerujący od strony hal , można wtedy zerować jak ktoś tam sobie chce i kiedy chce
z homingiem czy w zależności od potrzeby, + enable w hal i więcej nic nie trzeba

Chyba znalazłem.
Uruchomiłem halmeter w działającym LinuxCNC i szukałem na ślepo jakiegoś pinu HAL, który mógłby przypasować...
Zainteresował mnie joint.N.home-state.
Normalnie jest zero, w czasie bazowania skaczą cyferki i znowu jest zero.
Pomyślałem, że chyba bingo i zacząłem szukać w źródłach, bo w dokumentacji jest tylko tajemnicza informacja że to "debug"....
No i znalazłem taką deklarację:

Kod: Zaznacz cały

typedef enum {
  HOME_IDLE = 0,
  HOME_START,// 1
  HOME_UNLOCK,// 2
  HOME_UNLOCK_WAIT,// 3
  HOME_INITIAL_BACKOFF_START,// 4
  HOME_INITIAL_BACKOFF_WAIT,// 5
  HOME_INITIAL_SEARCH_START,// 6
  HOME_INITIAL_SEARCH_WAIT,// 7
  HOME_SET_COARSE_POSITION,// 8
  HOME_FINAL_BACKOFF_START,// 9
  HOME_FINAL_BACKOFF_WAIT,// 10
  HOME_RISE_SEARCH_START,// 11
  HOME_RISE_SEARCH_WAIT,// 12
  HOME_FALL_SEARCH_START,// 13
  HOME_FALL_SEARCH_WAIT,// 14
  HOME_SET_SWITCH_POSITION,// 15
  HOME_INDEX_ONLY_START,// 16
  HOME_INDEX_SEARCH_START,// 17
  HOME_INDEX_SEARCH_WAIT,// 18
  HOME_SET_INDEX_POSITION,// 19
  HOME_FINAL_MOVE_START,// 20
  HOME_FINAL_MOVE_WAIT,// 21
  HOME_LOCK,// 22
  HOME_LOCK_WAIT,// 23
  HOME_FINISHED,// 24
  HOME_ABORT// 25
} home_state_t;

Jeszcze jest tylko pytanie, ile te stany trwają i czy da się je rozpoznać próbkując co milisekundę...
Jak się nie da, to też jest sposób, ale wolałbym uniknąć dodatkowych kombinacji.
Wyłapując odpowiedni stan miałoby się pewność, że maszyna jest na pewno w określonej pozycji.
Powinno to działać nawet przy bazowaniu bez krańcówek...
Są piny z wartościami, które można by było wtedy przepisać do licznika enkodera...

[tuxcnc]

Dzisiaj przetestowałem płytkę znalezioną w szufladzie.
Dawno temu kupiłem z ciekawości, ale jakoś nie znalazłem dla niej zastosowania.
https://www.aliexpress.com/item/1005005770760872.html
To jest shield dla Arduino Nano i podejrzewam, że do niczego innego się nie nadaje z uwagi na wejścia/wyjścia w standardzie 5V.
Oczywiście po Nano cudów się nie spodziewałem, a użycie tego układu w dzisiejszych czasach może mieć sens tylko wtedy, gdy ktoś ten układ dobrze zna, a ESP32 czy STM32 są dla niego czarną magią.
Sam shield jest na układzie ENC28J60, do którego trzeba użyć biblioteki https://github.com/Networking-for-Arduino/EthernetENC
Różnica w stosunku do kodu dla W5500 jest chyba tylko taka, że trzeba napisać #include <EthernetENC.h> zamiast #include <Ethernet.h>...
Wgrałem do Arduino testowy kod:

Kod: Zaznacz cały

#include <EthernetENC.h>
#include <EthernetUdp.h>

// Enter a MAC address and IP address for your controller below.
// The IP address will be dependent on your local network:

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xE1 };
IPAddress ip(10, 10, 10, 88);

unsigned int localPort = 58418;      // local port to listen on

// buffers for receiving and sending data
char packetBuffer[255];  // buffer to hold incoming packet,

EthernetUDP Udp;

void setup() {
  Ethernet.begin(mac, ip);
  Udp.begin(localPort);
}

void loop() {  

  // if there's data available, read a packet
  int packetSize = Udp.parsePacket();
  if (packetSize) {
    // read the packet into packetBufffer    
    Udp.read(packetBuffer, 255);
    // send the packet back
    Udp.beginPacket(Udp.remoteIP(), Udp.remotePort());
    Udp.write(packetBuffer, 255);
    Udp.endPacket();
  }
}

Robi on tylko tyle, że odbiera pakiet i odsyła go z powrotem, ale do testów to wystarcza.
Układ odpowiada na pingi w czasie mniejszym niż 1,5 ms. To oczywiście jest kiepski wynik, ale do sprawdzenia czy osłona jest zamknięta albo włączenia chłodziwa i tak o rząd wielkości lepiej niż by wystarczyło.
Co ciekawe, mam taką "kartę" https://www.aliexpress.com/item/33055363055.html, która oczywiście jest zbyt wolna żeby na niej uruchamiać sterowanie obrabiarki, ale niewiele wolniejsza od opisywanego układu, który odpowiada na niej na pingi w czasie poniżej 2 ms.
Dwie milisekundy to pięćset razy na sekundę, więc do czegoś da się tego użyć...
Więcej testów robić nie będę, bo mam szybsze układy, ale może komuś też w szufladzie zalega, to może się pobawić...

[kszumek]

Witam
czy testowałeś lub jesteś w stanie określić do jakiej częstotliwość płyta odczyta poprawnie impulsy enkodera ?
i czy ktoś ma remorę w środowisku wysokozakłóconym , czyli spore styczniki i spory falownik
czy wyszło coś po czasie?
i może durne pytanie ale czy da się teoretycznie 2 płyty ec 500 pod jeden linuxcnc?

[tuxcnc]

płyta

Która płyta?

i może durne pytanie ale czy da się teoretycznie 2 płyty ec 500 pod jeden linuxcnc?

Pytanie absolutnie nie jest durne.
Oczywiście da się, ale trzeba pokombinować.
Remora ma na stałe przypisany IP (10.10.10.10) i porty (27181).
Oczywiście nic nie stoi na przeszkodzie, żeby pracowała z innym IP i na innym porcie, ale trzeba znaleźć odpowiednie deklaracje w kodzie źródłowym i samemu wszystko skompilować. Także komponentowi remora-eth-3.0 trzeba nadać inną nazwę, żeby LinuxCNC wiedział do którego urządzenia się odwołuje.
Jak najbardziej jest to do zrobienia, ale trzeba trochę podłubać.
Czy ma to jakiś głębszy sens?
Niekoniecznie.
LinuxCNC obsługuje dziewięć osi, a EC500 sześć, więc 2xEC500 nie obsłuży 12 tylko 9. Oczywiście można sobie wyobrazić maszynę z dziewięcioma osiami, ale zwykle sześć wystarcza do wszystkiego.
Jeśli nie potrzeba więcej niż sześć osi, to większy sens może mieć dodanie innego (tańszego i prostszego) sterownika.
Zauważ, że EC500 nie obsługuje PWM, ma tylko jedno wyjście 0-10V. W konkretnym przypadku może to stanowić problem.

[kszumek]

Witam
płyta to ec 500 na rt1052, wersja pcb chyba ta sama co ty masz chociaż jeszcze nie rozkręcałem swojej ,
to odnośnie pytania o częstotliwość odczytu enokderów

muszę najpierw odpalić i zobaczyć czy w oryginale działa,
osi oczywiście że nie trzeba więcej, bardziej jako dodatkowe IO w drugiej szafie ,
chyba trafiłem na jakaś promocję bo mi wyszła 300 pln
taniej niż kable sygnałowe ekranowane między szafami elektrycznymi
wolałbym dopłacić trochę do kolejnej ec 500 i mieć wszystko w jednym stylu
niż dłubać się przy kolejnej płytce ,chyba że sprawdzony stabilny gotowiec
generalnie to swoje dłubanie muszę podzielić na 2 warianty
wersja 1 stabilna , sprawdzona , do większej frezarki
i 2 DIY tania , czasami jako zabawa , do małych zabawek
gdyby był potrzebny nie dało by się odpalić 2-giego pwma na wyściu zamiast osi c a filtracje już zrobić poza płytką?

[tuxcnc]

odnośnie pytania o częstotliwość odczytu enokderów

Nie mierzyłem, bo mi się nie chciało, ale tak ogólnie, to EC500 nie nadaje się do tokarki.
Co prawda autorzy zaimplementowali sprzętową obsługę enkoderów, ale niewielki z tego pożytek.
Otóż na wejściach są transoptory, które i tak przycięły by pasmo do kilkudziesięciu kiloherców, ale jakby tego było mało, to jeszcze są tam filtry RC do tłumienia zakłóceń, które jeszcze bardziej psują parametry czasowe.
Dodatkowo, albo czegoś nie wiem, albo obsługa indeksu nie działa (może rozbabrane i niedokończone), w każdym razie mi się nie udało z niej skorzystać.
Ja w swojej tokarce mam EC500, ale tam jest taki enkoder-samoróbka z trzydziestoma szczelinami.
Sygnały A i B idą na enkoder w EC500 i mają na tyle małą częstotliwość, że opisane powyżej problemy nie mają znaczenia, natomiast sygnał Z enkodera idzie też na EC500, ale jako zwykłe wejście.
Ponieważ servo_thread mam ustawione na 0,6 ms, to łatwo policzyć, że jeden obrót wrzeciona nie może trwać mniej niż 36 ms, bo inaczej można zgubić impuls indeksu. To tak teoretycznie, bo jak LinuxCNC złapie synchronizację na drugim czy trzecim impulsie, to też nic wielkiego się nie stanie. W praktyce gwintowanie do jakichś 2000 obr/min powinno działać i faktycznie działa.
No ale to nie jest żadna rewelacja, bo jak dasz gotowy enkoder 50 pr, to już możesz mieć problem.
Jest jeszcze taka opcja, żeby sygnału indeksu nie brać z enkodera, tylko z innego czujnika dającego jeden impuls na obrót wrzeciona, wtedy będzie łatwiej poradzić sobie z zależnościami czasowymi.
Tak, czy inaczej, to czym większe obroty, tym większy błąd indeksu i coraz trudniej trafić we wcześniej naciętą nitkę.