Komp z PII

Co do tych 65 MB pamieci to sprawdz w biosie czy czasem nie masz wlaczonej dziury pamieci. Bylo cos takiego co ograniczalo pamiec w Biosie i cos mi swita ze wlasnie do okolo 65 MB. A co do Gubienia krokoow o tak dalej czytalem zarowno na tym forum jak i na paru innych niemieckich ze do CNC najlepiej nadaje sie zwykly PC bo na lapach sa prawie zawsze problemy z LPT. Pisze nie z wlasnego doswiadczenia tylko na podstawie tego co wyczytalem.

PZDR

witam !! to raczej nie kwestia biosu - na tych samych ustawiaeniach przy win98 widzi 256 mb . ale to tylko ciekawostka . w końcu w win95/98/itd też jest dos tylko nieco inny ( inne możliwości fdisk itp ) . mam pytanie - czy jak podczas uruchamiania windy wybiorę " tryb DOS " to system pracuje w czasie rzeczywistym czy tak jak w windzie ? . pozdrawiam !!

pukury pisze:czy jak podczas uruchamiania windy wybiorę " tryb DOS " to system pracuje w czasie rzeczywistym czy tak jak w windzie ?

od procesora 386 intel wprowadził tryb REAL PROTECTED
czyli takie "coś" co pozwala na wykonywanie zadań DOS-a pod Win32
(pierwsze procesory z tej linii 8088/6 potrafiły adresować jedynie 1MB... następny z tej linii stosowany w PCetach -> 286 potrafił to co 8086 + wprowadzono tryb protected)

więc istnienie różnica między wykonaniem programu DOSowego pod DOSem... a windows - nawet Win95/8/Me

jednak zadanie DOSa sięgające do pamięci powyżej 1MB musi zrobić to za pomocą "CZEGOŚ" co przełączy nam procesor do trybu w którym wyższa pamięć będzie widoczna

witam !! a to coś nazywa się HIMEM ( extended memory manager ) . jutro ( jako że niedziela i nie wypada - wiercić/piłować/itp. ) uruchomię sobie kompa na " polipa " i zbadam sprawę . ciekawe też jaką ilość pamięci może wykorzystać TCNC. pozdrawiam !!

kiedy byly takie cuda i dziwy jak dos4gw ( dobrze pamietam ? ) pamietam jak przy 4MB RAM musialem wszystko ładowac do pamieci górnej aby odpalić DOOM1 , co do kilobajta sie walczyło - albo się wywalczyło albo gra nie poszła - a teraz ? mamy 100x szybsze procesory , 500x wiekszą pamiec i windows jak chodził wolno to nadal wolno chodzi

witam !! no i doczytałem się - TCNC pracując pod DOS nie chce żadnych sterowników ( EMM386.EXE/HIMEM.SYS/RAMDRIVE.SYS/itp) czyli goły DOS . a co do walki o pamięć to rzeczywiście było śmiesznie oj było . ale na szczęście się skończyło ! . pozdrawiam !!

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.

Piotr Rakowski pisze:
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ć!

Wysłałem PW ale chyba nie dotarła.

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

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 )

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)

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

Jest kilka możliwości:
http://www.mikroprocesor.pl/product_inf ... ucts_id=84
Taki kit ma kolega markcomp77
Ja planuję zakup dla mojego sterownika serwa podobny zestaw z:
http://www.propox.pl/products/t_135.html

Zestawom tym brakuje dla naszych celów tylko dużej ilości RAMu
Należałoby wykonać płytkę z optoizolacją i RAMem - wtedy mamy całkiem sprawny szybki kontroller.
Wszystko programowalne w C ( lub assemblerze , choć nie będzie pewnie potrzeby), narzędzia darmowe GNU

Być może nawet RAMu nie trzeba by dokładać - wszystko zależałoby od zadań narzuconych na ten sterownik ( i prób z USB jak stabilnie pracuje aby wypełniało mu bufor z danymi)

Aha, i parę lat spędziłem programując podobne ARMy Atmela ( rodzinę AT91 )

Fajnie jak by to było open source, wtedy proponowałbym środowisko GTK ( co by mieć i Linuksa)