w mojej zabawce jest skok 1.5mm.. czyli to dużo mniej niż 4mm (tr16/4)
stąd z silnika 3Nm na osi pojawia się większa siła... zabawowa akceleracja wychodzi dwu cyfrowa (oj nie pamiętam dokładnie.... ale gdzieś z 400..800mm/skw)
to jest oczywiście zabawowa konfiguracja... jednak testuje na niej dobre sterowniki (m542/543/545)
co też może mieć pozytywny wpływ na wyniki...

powiem tak - duże przyśpieszenie daje większą szansę na unikanie obszarów z rezonansami... powolne zmiany prędkości zawsze przyczyniają się do dłuższego czasu przebywania w rezonansach

w mojej zabawce sprzężenie ze śrubami jest bezpośrednie... ale wiem, że paseczek dawał by szansę na manipulowaniem możliwościami silnika - na zmianę prędkości na moment... itd

co zrobić aby zwiększyć moment silnika, nie moment trzymania.... a wyprostować nieco charakterystykę moment/prędkość... i nie zmieniać nic w mechanice
jeśli mamy kiepski sterownik.. to łatwo - wystarczy sterownik zamienić na lepszy
a jeśli mamy już dobry... hehe... to już gorzej
generalnie osiągi można poprawić zwiększając napięcie zasilania (czasem to zmusza nas do zmiany sterownika na akceptujący wyższe napięcie)

jeszcze jeden sposób.. trochę z grupy MAGIA - to koło zamachowe... zwane czasami pochłaniaczem rezonansów

stabilne źródło poprawiające osiągi sygnału taktującego już zostało zastosowane (--->>EMC2)

do realizacji większych przyśpieszeń... a co za tym idzie większych szybkości
trzeba dużo większej siły (momentu) silnika
naprawdę duże przyspieszenia wymagają dużo większego silnika niż to się zazwyczaj wydaje
ale... to nie wszystko
sztywność konstrukcji również musi być lepsza...

jakby do tego przykładu, robiłem ostatnio zamiankę silników malutkich (pewnie ok. 0.5Nm) na większe -> 3.1Nm
udało się zwiększyć trochę prędkości ze 2..3razy... ale przyśpieszenia prawie 10 razy
oś Z może brzmieć na sucho jak maszyna do szycia

hehe... teraz wszystkie pozostałe elementy maszyny okazują się za słabe...
maszynka ma z 5 lat... była robiona do zabawy przy minimum kosztów (prowadnice szyfladowe, śruby skok 1.5mm, płyta meblowa)

jarekk pisze:266MHz, 32-bit ARM9EJ-S core
* Vector Floating Point coprocessor
* Up to 256KB of internal SRAM and 32KB I-cache/32KB D-cache
* External memory controller for DDR and SDR SDRAM, SRAM, and Flash
* Available 10/100 Ethernet MAC
* USB OTG with full-speed host and device capabilities
* Available 24-bit LCD controller supports STN and TFT panels
* Comprehensive set of serial interfaces
* SD memory-card interface

brakuje jedynie na pokładzie z 1GB RAM
+ flash 32GB
no i ewentualnie jakaś wbudowana struktura fpga - do zadań specjalnych

syntetyczny pisze: Bez kitu, na tym forum brakuje takich rozwojowych społecznościowych pomysłów.

no cóż... opracowywanie czegoś takiego - to już nie praca społeczna...
ale można podyskutować społecznie o możliwościach

jarekk pisze: to ciężko o RTAI do ARM'a (

a to poczekamy... a w międzyczasie poćwiczymy na poczciwych PIII (jak się uda znaleźć)

jarekk pisze: LPC3250

The LPC3250 operates at CPU frequencies exceeding 200 MHz. The basic ARM926EJ-S CPU Core implementation uses a Harvard architecture with a 5-stage pipeline. The ARM926EJ-S core also has an integral Memory Management Unit (MMU) to provide the virtual memory capabilities needed to support the multi-programming demands of modern operating systems. The basic ARM926EJ-S core also includes a set of DSP instruction extensions including single cycle MAC operations and native Jazelle Java Byte-code execution in hardware. The NXP implementation has one 32 kB Instruction Cache and one 32 kB Data Cache.

ładne

syntetyczny pisze:mam taki systemik na flashu i jestem bardzo z tego zadowolony. Chodzi szybko, może dzięki temu że pendrak jest szybki.

no to mój flasik jest wolny
tak czy inaczej... ograniczona ilość pewnych zapisów w tej technologii - to raczej argument przeciw stosowaniu jako podstawowy system plików... a zresztą - to nie takie ważne jak się tego PCecika ułoży - byle pewnie działał
--

trochę materiałów na temat zdalnej pracy z emc2 jest na linuxcnc.... poczytam (poczytajmy) - może są tam jakieś nowe pomysły?

[ Dodano: 2010-11-26, 00:42 ]

syntetyczny pisze: te rodzi się to w bólach.

właśnie ten ból - to duży koszt opracowania...choć wydaje się, że wszystko jest gotowe - linux, rtai, emc2 i nawet sprzęt armowy
ale na uczelni - takie walki i boje.... to kwintesencja edukacji
a w życiu... poza frajdą z roboty trzeba mieć muniaki na rachunki (duuużo muniaków)

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 )

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...

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.

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

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)