PikoCNC działa pod Wine(API Windowsa pod Linuksem)

mc2kwacz · Post napisał: **mc2kwacz** » 01 paź 2013, 01:43

Cosimo, ile MUSI być minimalnie ramek/s, żeby sterownik działał bez zacięć? Czyli jaki jest margines? Pytałem przy okazji sterowania przez LAN, ale nie odpowiedziałeś.

markcomp77 · Post napisał: **markcomp77** » 01 paź 2013, 10:05

parę obrazków...

Obrazek

i filmiki...

[youtube][/youtube]

[youtube][/youtube]

[youtube][/youtube]

cosimo · Post napisał: **cosimo** » 01 paź 2013, 10:17

może Twórca na zlot zleci?

Chyba, że zapewnisz mu darmowy transport lotniczy

Nawet do niedalekiego Poznania mało kiedy się wybieram...

Cosimo, ile MUSI być minimalnie ramek/s, żeby sterownik działał bez zacięć?

Wszystko zależy od tego z jakiej długości wektorów składa się program i jego prędkości (F) np. przy prędkości 400mm/m i „długich” (powiedzmy 5mm) wektorach to pewnie i jedna ramka/s by starczyła. Inna sprawa, że im szybszy transfer (a raczej „ping”) tym szybsza reakcja na przyciski joga.

Można przyjąć, że w jednej ramce idzie 25 wektorów, zatem łatwo policzyć na ile to starczy przy danej długości wektorów i prędkości jazdy.

ps.
O ku..źba 83 ramki/s - albo linux kiepsko liczy czas albo jest rewelacyjnie

markcomp77 · Post napisał: **markcomp77** » 01 paź 2013, 10:29

ja ustawiłem 8000 krokół/obrót (serwokrokowiec)
posuw na obrót 1
przyśpieszenie 1m/(s*s)
max prędkości 999 mm/min

czyli starałem się wykorzystać te 120KHz

a transfer wychodził ok 4000cooord/s (zmieniał się dynamicznie)

czy jest to wartość budząca zaufanie?... dająca gwarancje płynności w dostawach wektorów?

cosimo pisze:Chyba, że zapewnisz mu darmowy transport lotniczy

ja mam tylko cztery koła...
ale słyszałem o entuzjastach latających spadochronów (z wentylatorami)

cosimo · Post napisał: **cosimo** » 01 paź 2013, 11:10

..a transfer wychodził ok 4000cooord/s (zmieniał się dynamicznie)
czy jest to wartość budząca zaufanie?... dająca gwarancje płynności w dostawach wektorów?

Jeśli to prawda, to są wartości lepsze niż pod windą (gdzie standardem jest 62 ramki i 3000). Można jeszcze wizualnie zerknąć na dwie diody przy gniazdku USB powinny się świecić „nonstop” bez jakiegoś spektakularnego mrugania.

markcomp77 · Post napisał: **markcomp77** » 01 paź 2013, 11:40

cosimo pisze:O ku..źba 83 ramki/s - albo linux kiepsko liczy czas albo jest rewelacyjnie

ja tylko rzuciłem screena... nic nie oszukiwałe

maszyna na której siedzi ten linuks jest baardzo wolna... wołowata -słaby netbook
ale linuks potrafi z niej więcej wyciągnąć powera niż system wcześniejszy...

jedyna różnica w pracy w stosunku do pracy pod XP, polega na konieczności manualnego ustawienia numeru portu COM (link do /dev/ttyUSB0)

i trzeba manualnie przekonać go do połączenia.... ale potem już trzyma łącze

pod XPekiem po włączeniu, program sam zestawia połączenie...

[ Dodano: 2013-10-01, 11:52 ]
faktycznie na XPeku pokazuje niższy transfer.. 62 ramki

[ Dodano: 2013-10-01, 11:53 ]
no cóż... linux+wine to taki lepszy windows

zacharius · Post napisał: **zacharius** » 01 paź 2013, 12:15

hmmm no ciekawe toto. zaczynam się zastanawiać nad tym całym Piko

mc2kwacz · Post napisał: **mc2kwacz** » 01 paź 2013, 14:09

cosimo pisze:
Cosimo, ile MUSI być minimalnie ramek/s, żeby sterownik działał bez zacięć?
Wszystko zależy od tego z jakiej długości wektorów składa się program i jego prędkości (F) np. przy prędkości 400mm/m i „długich” (powiedzmy 5mm) wektorach to pewnie i jedna ramka/s by starczyła. Inna sprawa, że im szybszy transfer (a raczej „ping”) tym szybsza reakcja na przyciski joga.
Można przyjąć, że w jednej ramce idzie 25 wektorów, zatem łatwo policzyć na ile to starczy przy danej długości wektorów i prędkości jazdy.

[/quote]
To bardzo cenna informacja, z ta ilością wektorów na ramkę. Można sobie przeliczyć, jaki ustawić mikrokrok żeby nie było jakiejś hecy...
Ale chyba nie tylko w tym problem. Pamiętasz, robiłem doświadczenie z klikaniem palcem w klawiaturę, i przy o połowę rzadszych ramkach, czyli tylko 30/s czy raczej AŻ, nie przechodziły do sterownika informacje o żądaniu ruchu osi. Wygląda na to, że kliknięcia powyżej pewnej prędkości, i to dużo mniejszej niż częstotliwość ramek, są gubione. To istotna sprawa która należałoby poprawić, żeby zabezpieczyć użytkownika przed potencjalnym chwilowym tąpnięciem transferu. Można śmiało założyć, że średnia częstotliwość ramek na poziomie 60Hz może zostać zakłócona przez jakiś inny proces na pececie, i co wtedy... Jak sądzę, reakcja na przyciski joga byłoby podobnie, albo jeszcze gorzej. tak więc, o ile pewne opóźnienie można uznać za ew dopuszczalne (w końcu to tylko pecet), to zgubienie informacji o sygnale już nie.

markcomp77 · Post napisał: **markcomp77** » 01 paź 2013, 14:24

mc2kwacz pisze:Wygląda na to, że kliknięcia powyżej pewnej prędkości, i to dużo mniejszej niż częstotliwość ramek, są gubione

może to jest prędkość obsługi bufora klawiatury?
czy program pikocnc sam implementuje kolejkę klawiatury?... czy bierze co mu daje system operacyjny?

micges · Post napisał: **micges** » 01 paź 2013, 14:27

62 ramki są ponieważ prawdopodobnie windows ma jakieś ograniczenie komunikacji I/O do ok 64 cykli na sekunde. Nie wiem dokładnie skąd to ograniczenie wynika ale jest również gdy komunikuję się pod windowsem z kartą ethernetową 7i80 z mesanet.com. Linux nie ma takich ograniczeń

PikoCNC działa pod Wine(API Windowsa pod Linuksem)

Szyna liniowa REXROTH 1605-804-31 0225mm

Element mocujący KMA, sztywny, zestaw kompletny 24101.05.12

PikoCNC działa pod Wine(API Windowsa pod Linuksem)

Szyna liniowa REXROTH 1605-804-31 0225mm

Element mocujący KMA, sztywny, zestaw kompletny 24101.05.12

Zaloguj się • Zarejestruj się

Połącz się z kontem sieci społecznościowej