Panie PiotrzeJub - ile taki sterownik będzie kosztował i jakim programem sterującym będzie go można obsługiwać?
A może będzie można dostać specyfikację protokołu WE i samemu napisać własny driver?

A jakiś PIC18 nie wystarczy? Za mała moc obliczeniowa? Poza tym USB jest fajny, ale potrzebne jest napisanie drivera...

Ja niestety w C jestem słaby - programuję w Delphi, a na PICe jest bardzo dobry
microPascal.

jarekk pisze:Wysłałem PW ale chyba nie dotarła.

Rzeczywiście nic nie przyszło...

jarekk pisze:Taki sterownik można kupić - prawie gotowy kit za około 180zł. Do tego dołożyć nieco pamięci RAM , i mamy maszynkę opartą na ARM7 ( o wydajności 66MIPS ) po USB do naszej dyspozycji. Faktyczna cena takiego zestawu ( po cenach wykonawczych) sięga pewnie połowy....

No to super! Chętnie ten sterownik bym obejrzał. Gdzie to można zrobić?

jarekk pisze:To nie sterownik jest problemem - tu pracy jest stosunkowo niewiele. To głównie oprogramowanie - to na PC oraz sterownik zajęło by dużo czasu.
(myślę że udział pracy SW/HW byłby tak około 10:1)

Dla mnie problemem nie jest oprogramowanie na PC, tylko na sterownik. Jeśli dla Ciebie jest odwrotnie proponuję współpracę. Myślę, że napisanie oprogramowania sterującego nie powinno zająć więcej niż 2-3 miesiące. Interpretację G-kodów mam już napisaną, współpraca z portem to tylko kwestia odpowiedniego protokołu, który trzeba ustalić. Do tego graficzna interpretacja ruchów, parę innych wodotrysków... Poza wszystkim można przecież zrobić to w wersji open source, jeśli się znajdą chętni.

Na programowaniu ARM7 nie znam się. W jakim języku się go programuje?

jarekk pisze:Co do buforowania i zapisywania danych - szeregowe pamięci FLASH są już bardzo tanie np. 32Mbity - 25zł, pamięć RAM 512kB to 12zł ( ceny z 1 sztukę w bardzo drogim miejscu)

Znajdźmy kogoś, kto programuje ARMy i robimy!!!

Adalber pisze:Kilka pytań do Piotra Rakowskiego .
Wytłumacz bliżej ,co właściwie miałby robić ten mikroprocesor pośredniczący. Jak wiele ma mieć autonomi. Czy np. na podstawie wysyłanych współrzędnych ma sam liczyć przyspieszenie i prędkość dla każdego silnika ?, czy też być tylko swoistym buforem który gromadzi nadchodzące nieregularnie dane i przesyła je dalej regularnie ? Z jakim programem będzie on współpracować - całkiem nowym ?

1. To, czy procesor będzie sam aproksymował, czy dostawał dane w postaci np. oś, ilość impulsów, kierunek - nie ma specjalnie znaczenia, bo to jest sprawa drugorzędna. Istotą sprawy jest przejęcie przez procesor sterowaniem maszyną - jako taką. Wszystkie dane wejściowe mają wychodzić z komputera, a mikroprocesor np. co 250 ms będzie podawał dane wyjściowe o tym, w którym miejscu wykonania programu jest. Obsługa krańcówek i wszelkiego typu innych urządzeń WE także będzie po jego stronie.

Bardzo ważne jest buforowanie danych wejściowych, ba może nawet eprom do którego będzie można "zapaciakować" kilka najczęściej wykonywanych programów np. frezowania. Dzięki temu dodatkowo uniezależnimy sterownik mikroprocesorowy od komputera. To byłoby genialne rozwiązanie w "pracach polowych", np. wycinaniu formatek ze styropianu w czasie ocieplania domów (są takie "polowe" wycinarki drutowe).

2. Oczywiście, że z całkiem nowym. Nie znam programu ogólnego zastosowania, który współpracowałby ze sterownikiem mikroprocesorowym w opublikowany sposób. Zwykle firmy zachowują sposób komunikowania z własnym sterownikiem dla siebie. Co innego znane firmy śwatowe (Fanuc), ale o nich zapominamy ze względu na koszty. Protokół komunikacji z naszym procesorem oczywiście upublicznimy, aby każdy mógł się do niego podłączyć dowolnym, napisanym przez siebie programem sterującym.

E nie, nie będę bronił TurboCNC. Jak to mówią przyzwyczajenie jest drugą naturą człowieka. Mnie lepiej pracuje się na TCNC, a Tobie (pit202) na Machu. Ot, jeden lubi blondynki inny woli te o szerokich biodrach.

Mnie chodziło raczej o pokazanie wyraźnych różnic w sposobie pracy programu DOSowego a windowsowego i wynikających z tego problemów (np. nierównomiernej pracy, czy tzw. gubienia kroków) i stwierdzenie - masz problemy z programem pod windozą - sprawdź jak to jest pod DOSem. A czy to będzie TCNC, Stepster czy inne badziestwo - nie ma znaczenia.

Wiem, że Mach wczytuje jakieś niezwykłe skrypty (patrz wątek dotyczący czujnika narzędzia). Może za pomocą tych skryptów da się go zmusić do powyłączania zbędnych procesów. Nie wiem - dla mnie Mach to przerost formy nad treścią. Piszę własny program, a tym czasem używam TurboCNC - który i Wam polecam.

Co do ograniczenia 65KB w DOS 6.22 - ja TurboCNC włączam w okienku Windowsów 98 i "chula jak siemasz", bez żadnych problemów - bo te stare Windowsy przełączały się w tryb rezydentny, a DOS przejmował pracę komputera. To były czasy, aż się łezka w oku kręci...

easy2002 pisze:...A jakby tak zmodyfikować mach2 aby nie obciążały tak pracy kompa

No, ale o to musiałbyś poprosić twórców Macha.

Problem gubienia kroków nie jest jedynie problemem konstrukcji i sterowania (co już było poruszane), a przede wszystkim oprogramowania. I wbrew pozorom nie prędkości pracy komputera. Do mojej maszyny (silniki 1.89, sterowniki 4.2A M542, duża i względnie ciężka rama) mam podłączony bardzo stary komputer PII 266 MHz + Win95. I zabawa jest taka: zawsze, gdy nie jestem pewien zgubionych, bądź nie, kroków zaczynam sterowanie pod DOSem w TurboCNC. To jest program, który jest najlepiej napisanym programem sterującym spośród tych, które są względnie darmowe (czyli np. shareware).

Jak wiecie trochę programuję, sam piszę program sterujący i wiem jak taki program nie powinien pracować. Otóż niektóre programy, np. KCam, moim zdaniem nie przełączają portu LPT na pracę w trybie SPP. Co więcej, sterownik portu nie stara się go "przejąć na wyłączność".

Nie staram się także pracować w Windows powyżej 98. Teoretycznie można wywłaszczyć port LPT, ale mam dziwne wrażenie że windowsy nadal go "pingują", starając się sprawdzić "jakby" jego istnienie.

Na mojej maszynie bez problemu uzyskuję 1m/min bez żadnego gubiebnia kroków (mam ustawiony skok 400 kroków/1mm), choć powiedzmy sobie szczerze mnie się także wydaje, że te silniki są tylko teoretycznie 1.89 NM. Ważne jest, by sterownik rzeczywiście dawał te 3A na wyjściu.

Teraz sprawa Macha i tego typu programów pod Windows. Z programistycznego punktu widzenia sterowanie silnikami (wysyłanie sygnałów do portów) i wyświetlanie pozycji XYZ na ekranie to dwa oddzielne procesy - z resztą jeden zakłóca pracę drugiego. W Machu zrealizowane jest to za pomocą dwóch oddzielnych wątków. Jeden steruje, drugi wyświetla. Ale ponieważ w "tle" windozy zawsze jeszcze chcodzą jakieś procesy (choćby systemowe) co pewien czas jeden z tych procesów może być zakłócony przez inny. A do tego musicie wiedzieć, że pracę może spowolnić marna karta graficzna (tak, tak..). Wyświetlanie wartości XYZ w takim okienku, jak pokazuje to Mach zabiera sporo czasu procesora i jeśli jeszcze tzw. zasoby kontrolki wyświetlającej są zbyt rozbudowane (pamięciożerne) - wyświetlanie pracuje strasznie wolno. Wtedy właśnie może występować gubienie kroków. Radą może być wyłączenie podglądu w Machu lub użycie szybszego komputera.

Sprawę ciekawie ominął kolega "Korinsj" w swoim programie. Sterowanie jest jednym procesem, a wyświelanie pozycji XYZ nie jest procesem oddzielnym, a raczej siedzi na timerze systemowym (przerwaniu) i pozycja na ekranie jest "updatowana" co np. 250 ms. Powoduje to takie śmieszne "pukanie maszyny" w momencie pingu timera, ale komputer nie gubi wysyłania kroków.

Dlatego też ludzie, którzy robią maszyny na sprzedaż, np. "PiotrJub" korzystają z rozwiązań opartych na sterowaniu mikroporcesorowym, polegającym na buforowaniu wysyłanych danych. Program sterujący wysyła procesorowi paczkę ruchów do wykonania, a sam zajmuje się jedynie wyświetlaniem stanu aktualnego na ekranie pobierając (a nie wysyłając) dane z mikroprocesora sterującego. Dodatkowo to sterownik zajmuje się sprawdzaniem stanu krańcówek, wyłącznika awaryjnego etc.

POSTULAT DO ELEKTONIKÓW NA FORUM: Zróbcie taki sterownik - ja napiszę do niego oprogramowanie i problem gubienia kroków przestanie istnieć!