HobbyCNC fórum
FTP tárhely: http://cnctar.hobbycnc.hu v0.9.6 Régi HobbyCNC oldal: http://archiv.hobbycnc.hu

Új regisztráció / Átregisztráció a régi fórumról
    
   


Épül a gépem ::: KisKZ

xxx

 

Időrend:
Oldal 12 / 26 Ugrás ide:
Sorok:
|◄ Első  ◄ Előző   8  9  10  11  12  13  14  15  16   Következő ►  Utolsó ►|

  Fórum főoldal  |  A lap aljára

KisKZ | 6456    2010-08-13 15:00:00 [719]

Nagyon köszönöm Keri!

Az első részét nagyjából ismertem, de igy a biztos.
Viszont amit amásodik részében mondasz az nagyon érdekes a lentiekkel kapcsolatban.
ha egy megszakítást tud csak kezelni a pic. akkor a DIR és a STEP olvasása mindenképpen egy cilusba kell hog ykerüljön, méghozzá szekvenciálisan.

Jól gondolom?

Előzmény: keri, 2010-08-13 14:19:00 [718]


keri | 14049    2010-08-13 14:19:00 [718]

Ha valamien esemény bekövetkeztére kell várni. Pl hogy a bemeneten van e jel, vagy nincs, akkor két lehetőséged van. Fut a programod, csinálja a dolgát, amibe beleírod hogy időnként nézze meg mi van az adott bemeneten. Vagy sokkal hatékonyabb, ha rábízod a megszakítás vezérlőre hogy figyelje ő. Neked nem kell vele foglalkozni, futhat a programod, de amikor bekövetkezik, akkor a megszakítás vezérlő megállítja a program futását és elindít egy másikat ami kezeli az eseményt. Amikor ez a program lefutott, akkor a megszakítás vezérlő folytatja az eredeti programot.

A fejlettebb megszakítás vezérlők több eseményt is tudnak kezelni, vagyis az egyik bemenetre egyik programot, a másik bemenet jelére a másik programot indítják el. PIC esetén azonban csak egy darab ilyen megszakítás létezik, bármilyen esemény is következik be ugyan az az alprogram indul el. Ezen belűl neked a régi módszerrel kell kiválogatni hogy vajon mi okozta a megszakítási eseményt, vagyis végig kell ellenőrizni a bemeneteket, hogy melyikre került rá a megszakítást okozó jel.
Általában persze nem az eredeti bemeneteket kell végignézni, hanem mindegyikhez tartozik egy "flag" regiszter a memóriában. Ezeket kell ellenőrizni, mert ezek a jel eltünése után is úgy maradnak.

Előzmény: KisKZ, 2010-08-13 13:53:00 [717]


KisKZ | 6456    2010-08-13 13:53:00 [717]

Bármiben!
Az elvet mondd el összefaglalva, röviden!
Csak hogy valamit konyítsak a miért és mikéntjéről.
Vannak ugyan sejtéseim, de az igazából semmi.

Előzmény: elektron, 2010-08-13 13:39:00 [716]


elektron | 15859    2010-08-13 13:39:00 [716]

A PIC-ben ?

Előzmény: KisKZ, 2010-08-13 11:49:00 [715]


KisKZ | 6456    2010-08-13 11:49:00 [715]

Közben csak mellékesen:
Mondanál tömören néhány szót a megszakításkezelés lényegéről?

Előzmény: elektron, 2010-08-12 18:12:00 [709]

KisKZ | 6456    2010-08-12 19:20:00 [714]

Ezt is köszönöm elektron!
Mivel nem ismerem a megszakításkezelés mikéntjét, nem mertem belekeverni a gondolkodásomba.
Igy pedig az semmit nem ért.

De ez most tisztázott megint néhány alapdolgot. Köszönöm!

Előzmény: elektron, 2010-08-12 18:12:00 [709]


KisKZ | 6456    2010-08-12 19:19:00 [713]

Húú! Ezt köszönöm. Én még mindig a PDF leírást böngészem és abban nekem még a 20 és 5 van, igaz a MACH2-höz.

Nagyon köszönöm!

Előzmény: Amatőr, 2010-08-12 18:34:00 [710]


KisKZ | 6456    2010-08-12 19:18:00 [712]

Szia Bodi!
Nagyon nem akarom, csak tudod milyen vagyok.. Jó lenne tudni mi miért hogyan.
De ugyis észbekapok és abbahagyom időben.
Nem szabad hozzáértés nélkül túl sokat belefeccölni ilyesmibe.

Adok is magamnak mindjárt egy pofont és inkább az egyszerűbb dolgokat folytatom.

Mondjuk akkor sem megmagyarázható, hogy miért nem a beállított frekit és az alapján a beállított sebességértékeket adja vissza a MACH.

ez van.

De hátha valaki aki ért hozzá, mond majd rá valamit.

Előzmény: n/a (inaktív), 2010-08-12 18:12:00 [708]


Amatőr | 2184    2010-08-12 18:36:00 [711]

...vagy nem Mach3-at használsz?

Előzmény: Amatőr, 2010-08-12 18:34:00 [710]


Amatőr | 2184    2010-08-12 18:34:00 [710]

A 20 és 5 beállítás a Mach2-höz tartozott,
Mach3-nál 5 és 5:

H1 leírásánál a szoftveres oldal vége felé.

Előzmény: KisKZ, 2010-08-12 14:39:00 [696]


elektron | 15859    2010-08-12 18:12:00 [709]

A H1 valószínűleg megszakítás rutinjára ugrik, abban a szent minutumban, amint érzékeli a step jel felfutó élét, csak amíg odaér a feldolgozó rutinhoz, addig valahány gépi kódú utasítás végrehajtódik, emiatt van az, hogy a legrosszabb esetet figyelembe véve, van meghatározva, mi az a minimális jel hossz, ami elég ahhoz, hogy a feldolgozó részhez érve ki tudja olvasni, hogy melyik lábon jött a step jel mi van éppen a dir jelen. A másik meg hogy optocsatolás esetén az opto IC-nek is vban egy bizonyos késlekedése a jel változásakor, és kell annak is egy minimális jelhossz, hogy felmenjen a jel 0-ból egybe vagy vissza.

Előzmény: KisKZ, 2010-08-12 16:06:00 [705]


n/a (inaktív)    2010-08-12 18:12:00 [708]

Nagyon beleástad magad a témába!

Előzmény: KisKZ, 2010-08-12 16:09:00 [706]


elektron | 15859    2010-08-12 18:08:00 [707]

"Az logikus, hogy előbb a DIR jel kell."

Magad is megválaszoltad.

Egyébként "Mellékhatások tekintetében..." , a Mach írói valószínűleg tudják ezekre a választ, egyébként magunknak kell kilogikáznunk.

Előzmény: KisKZ, 2010-08-12 15:52:00 [704]


KisKZ | 6456    2010-08-12 16:09:00 [706]

Közbeszúrásképpen:

Egyébként a nagyoktól elnézést kérek az okoskodásért.
Lehet teljesen hülyeségeket mondok, de hátha beleszóltok és elmondja valamelyikőtök azt, hogy hogyan alakulnak a step/dir jelek a MACH-ból kifelé, és hogyan olvassa ezt be a vezérlő.


KisKZ | 6456    2010-08-12 16:06:00 [705]

De.. azt hiszem előbb vissza kell térni a vezérlő jel olvasási módjához......
most az egyszerűség kedvéért feltételezzük, hogy a H1 15us-onként néz ki a step jelért, és 5-önként a dir ért.
Akkor az olvasási cilusideje 15us.

Egyszerre ugye nem tud adatot kezelni, tehát mindenképpen valamilyen módon egymást követve kell ezeknek megtörténni.
mondjuk előbb kinéz a dir-re, majd valamikor utána a stepre.
(vazz! nem emlékszem milyen frekin fut a PIC a H1-ben.... Az valahol támasz lenne talán... vagy mégse?)
Szóval a két jel közötti átfedés mindig megmaradna mert a kinézés gyakorisága eleve többszöröse egymásnak, de amugy is... ha ciklusban kell futni a dolognak, akkor illik mindig ugyanakkora egymáshoz viszonyított időközzel megtörténni a két jel olvasásának.....

Akkor ez van a vezérlő oldalán eddig.

KisKZ | 6456    2010-08-12 15:52:00 [704]

Harmadik kérdés:
Hogy teszi ki a dir és step jelet (mondjuk éppen változás esete van az egyik tengelyen és az elindul, az eddigitől elétrő irányban).

Vagyis hogyan helyezkednek el időben ezek a jelek egy kernelfrekin belül?
Az logikus, hogy előbb a DIR jel kell.


KisKZ | 6456    2010-08-12 15:46:00 [703]

második kérdés:
A kernelfreki csupán az LPT1-re kimenő impulzusok frekvenciájának behatárolására van?
A mach persze közben a PC saját sebességével mint az őrült dolgozik. (már ami marad neki az erőforrásokból).


KisKZ | 6456    2010-08-12 15:44:00 [702]

De nem kellene nekem ebbe belemennem... Ugysem fogom megérteni...
De azért alapkérdés lehet?
először:
A step és a dir jelet akkro is kiteszi a MACH egy kernelfrekin belül, ha azok nem változnak? vagyis méndjuk két egymást követő kernelimpulzus (nem tudom hogy hívjam, ugyhogy most marad ez ha nem baj) alatt mondjuk egy irányban megy a tengely tovább. Akkor kiteszi-e ujra, a jelet vagy hagyja az eredeti állapotban?

Magyarán:
csak akkor nyúl a step és a dir jelhez a MACH ha annak tényleg változtatni kell?


Bocsánat, de én csak ilyen kisléptékű kérdésekkel tudok közeledni.


KisKZ | 6456    2010-08-12 15:31:00 [701]

közben akkor most énb elkezdek számolni...
Soha nem gondolkodtam el ezen.
Még azt sem számolgattam hogy ennyi meg ennyi KHz mennyi idő/impulzus.
Na akkor most elgondolkodok.
Síri csend és némaság. Remélem nem a fejemben.


KisKZ | 6456    2010-08-12 15:29:00 [700]

Miért is kell két vonal között lennie akár csak egy tengely két jelének?
Miért is nem lehet akár több volnalra szétosztva??

Mennyi is a minimális szükséges idő???

Továbbra sem cikizés, hanem tényleg kérdések ezek...
Hátha felépül valami kép bennem.

Előzmény: elektron, 2010-08-12 14:49:00 [699]


elektron | 15859    2010-08-12 14:49:00 [699]

Persze úgy, és ah két vonal közt nincs annyi ideje, akkor nem állítható valamelyik többre, kevesebbre.

Előzmény: KisKZ, 2010-08-12 14:47:00 [697]


elektron | 15859    2010-08-12 14:48:00 [698]

Gyorsabban attól impulzust legalábbis nem tud kiadni, mint a minimáis szükséges idő.

Előzmény: KisKZ, 2010-08-12 14:32:00 [695]


KisKZ | 6456    2010-08-12 14:47:00 [697]

Én ugy képzelem el, hogy a kernelfreki a volanak sűrűsége egy kockás füzetben.
Erre fog a MACH írni, de kifejezetten csak a volanak mentén.

Azt még nem tudom, hogy mit. Érdekes lenne tudni, bár nem életbevágó ugyan.

Előzmény: elektron, 2010-08-12 14:12:00 [694]


KisKZ | 6456    2010-08-12 14:39:00 [696]

Egyébként a H1 tulajokat kérdezném:
Az István által igényelt impulzusszélesség értékek: 20-és 5.
De max 15-öt lehet állítani.
Ezt állítjátok Ti is?


KisKZ | 6456    2010-08-12 14:32:00 [695]

15+5 most.
Ugy gondolod, hogy egy kernelfrekvencia időtatramban kell megtörténnie egy step és dir impulzusnak?

Jó lenne tisztázni, hogy mire van hatással a kernekfreki....
Hova és hogyan osztja el a számításokat, a feldolgozás folymatát a MACH??
Vagy a kernelfreki csakis a kimenő impulzusok elosztására van hatással?

És mi van ha nem egy tengelyt veszünk hanem többet? És ha nem szinkronban mozognak? Akkor is egy kernelimpulzusba erőlteti a három kimenő jelet? Egyszerre, Sorban? hogyan is alakul, hogyan is működik ez???
Ha a vezérlőd egyfajta freki fogadására van optimalizálva (saját feldolgozási sebesség és a program adottságai) akkor attól eltérő, különböző kernelfrekikhez kötött sebességgel érkező jelek között elég sok elveszhetne nem?
De ha igy lenne ahogy mondod, akkor mi értelme az impulzusszélesség állításnak a MACH-on belül??? Ez nem lenne logikus!!!



Nehogy cikizésnek vedd! Ez kérdés ,mert nem értem még a működést.

Előzmény: elektron, 2010-08-12 14:12:00 [694]

elektron | 15859    2010-08-12 14:12:00 [694]

Ha a kernel freki túl nagy és a step dir impulzusok nem férnek bele , akkor lehet nem tetszik neki ? pl. 15+15 us= 30 us ezáltal a kernel freki nem lehet csak max 33kHz. pl.

Előzmény: KisKZ, 2010-08-12 13:55:00 [693]


KisKZ | 6456    2010-08-12 13:55:00 [693]

Sziasztok!

Tegnap folytattam a küzdelmemet a PC-vel.
Elvileg lesz helyette más gép kézél, de azért szeretek utánajárni a dolgoknak, már amennyire tőlem

az kitellik.

Bocsánat hogy szokás szerint terjengősen írom le a dolgot, de hátha lesz aki elolvassa és hasznois

lesz a jövőben a számára.


Szóval nekiestem és ujratettem mégegyszer a gépet. Most már eternity V2-vel.
Felment szépen, majd feltettem az alaplapi és a videókártya drivert.
Utána kipucoltam az indítópultot, valamint a kezelésnél letiltottam egy pár szükséhgtelen

processzt, hogy ezek se zavarjanak a működésben.

Utána fel MACh és már kezdtem is a tesztelgetéseket, csak így, maró és vezérlő nélkül.

Érdekes dolokon mentem ét. Lehet hogy ezek a számotokra már ismertek, vagy nálatok elő sem jönnek,

de azért leírom.

a drivertest-tel keztdtem a dolgot.

Lehet igazán nem fontos, de azért mégi szeretném valamelyest megérteni, hogy a kernelfreki

változtatásával mit lehet elérni. Ezzel telt a tegnapi estém.


A drivertest-nél elvileg 3 lehetőségem van arra, hogy a paraméter kontorll részen található

értékek közül kiválasszam a vizsgálni való frekvenciát.
Megköszönöm, ha megmondjátok melyik az amelyik a szabályos kellene legyen.

1. A teszt futásának elindulása előtt kiválasztom a megfelelő frekvenciát.
3. A teszt fzutása közben a stop timerrel leállítom a futást, kiválasztom a vizsgálni kívánt

frekvenciát majd a start timerrel futtsatom tovább a tesztet.
2. A teszt futása közben egyszerűen átkattintok a vizsgálni való frekvenciára.

MInd a három esetben voltak problémák.
Az első esetben, ha nem az alapként ajánlott 25KHz-en indul a teszt, többször megesik, hogy az

approach után a teszt indulásakor mégis visszaugrik erre az értékre.

A második esetben szintén megesik, hogy a start timer után visszaugrik az alap 25KHz re magától.

A harmadik esetben sokszor problémát jelez a teszt és hibát ír ki (pulse too dlow vagy pulse too

fast)

De! Ettől függetlenül mind a három eset túlnyomórészt működőképes és rendesen lefut a teszt.

További probléma bármelyik esetre:
megesik az, hogy a beállított frekvencia, és a képernyő fenn középen látható ellenőrző értéke

teljesen eltér. Vagyis pl beállított 35KHz-es frekvenciánál is a 25KHz hez tartozó értéket

mutatja, vagyis gyakorlatilag azon futtatja le a tesztet.


Nem túl tiszta a teszt működése sajnos. Nem tudom a PC-nek köszönhető-e, avagy a teszt működése

ilyen "labilis".


Azokban az esetekben amelyekben a beállított és az ellenőrző értékek bizonyos tűrés mellett (erről

nesokára mert ez fontos!) stimmel, a tesztek szépen lefutnak.
Az impulzius idő diagramm egy- max három ici pici tüske kivételével olyanok mint a vonalzó éle.

Színegyenes!!!

Ha nem bántos semmit, akkor egy ilyen pici tüske van csak a képernyőn jellemzően mindig ugyanazon

időpontban (helyen). Ha az egeret mozgatom ez felugrik 3-ra, amelyek szintén jellemzően egy helyen

jelentkeznek. Mindegyik egészen kicsi.
Az egér USB-s, igy elképzelhető, hogy az USB host és/vagy az egér működését látom ezeken a

helyeken.
Ez ugyan nem rpobléma, de azért meg fogom nézni egy sima PS2-es egérrel is, ha lesz kéznél.


Nos akkor az igazán érdekes dologra térve:
Írtam, hogy a kiválasztott frekvencia és a visszajelzett frekvencia értékei csak bizonyos tűréssel

egyeznek.
It vannak a driverteszt-ből kiolvasható különbségek (mindegyiket többször is futtattam és

ellenőruiztem, ezek a jellemző értékek lettek kijelezve, néhány kivétellel):

A második érték tól-ig, csak a változott helyiértéket írtam már oda.
Ez azt jelenti, hogy itt a kijelzett frekvencia ingadozást mutatott mindenesetben!

25KHz 24088-59
35KHz 34498-502
45KHz 44501-03


Jól látható, hogy van különbség a kiválasztott értékek és a tényleges frekvenciaértékek között.


De tovább léptem és most már a MACH-on belül folytattam a vizsgálatokat.
Itt az egyik motor max sebesség értékét beállítottam 3000 mm/min-re majd folyamatosan futtattam

azt a tengelyt egy irányba. Ekkor néztem, hogy milyen értéket mutat a feedrate visszajelzője.

A MACH-on belül, a diagnostic képernyőn van arra lehetőség, hogy ellenőrizzem a kernelfrekvencia

értékét (jobb közép a képernyőn).

A driverteszttől eltérő értékekkel ugyan, de itt sem stimmeltek pontosan a beállított kernelfreki

és a tényleges frekvencia értékek.
Ugye minden frekvencia állítás után ujraindítás és ellenőrzés.
Minden esetre többször is megtettem ezt a beállítást és ellenőrzést melynek eredményeképpen:


25KHz 25927-28
35KHz 34444
45KHz 44430
60KHz 60665
65KHz 66764
75KHz nuku.... össze vissza... Ez már használhatatlan volt.


Szép....

A még szebb dolog az egészben az volt, hogy amikor gyorsjáratban futtattam a 3000-re beállított

tengelyt, gyakorlatilag soha nem futott a beállított 3000-rel hanem valamivel kisebb vagy nagyobb

sebességgel.

Szépen sorban most már minden:
Remélem olvasható lesz itt mint táblázat!


beáll ell.ért. beall. seb. ell.sebeség
25KHZ 25927 3000 3112.2
35KHz 34444 3000 3952
45KHz 44430 3000 2962,8
60KHz 60665 3000 3033
65KHz 66764 3000 3081,6


A lényeg:
Hiába állítok most be egy feedrate-t, az bármelyik kernelfrekin is nézem nem lesz pontosan a valós

futási érték. Nem nagy a különbség, de hát ugye mégis.... NEm igy ekllene ennek mennie szerintem.

Ami érdekes:
Ha megnézitek, hogy milyen arány van a beállított frekvencia és az ellenprzőtt(leolvasott)

frekvancia között, az ugye egyezik a beállított és az ellenpőrzött sebesség közötti aránynak.
Vagyis a MACH-on belül nincs visszacsatolás a beállított érték és a kivezérlet érték között!!!!!

Ezt jó tudni!

Hát....
Most ennyi.
Bocsánat ha mindez egyértelmű volt a számotokra.



Most már csak azt kellene tudni, hogy miért nem veszi fel a kernel pontosan a beálltott

freklvenciát.

Mindettől függetlenül lehet hogy teljesen jól használható a gép a kivezérlésre, hiszen ez a

probléma max a sebességet befolyásolja (elvileg), a pontosságot a távolságokat nem.


KisKZ | 6456    2010-08-09 12:30:00 [692]

Köszönöm!

Előzmény: elektron, 2010-08-09 12:12:00 [691]


elektron | 15859    2010-08-09 12:12:00 [691]

Ni csak, itt egy jó kis oldal.



CNC szoftverek 1

CNC szoftverek 2

Előzmény: elektron, 2010-08-09 12:09:00 [690]


elektron | 15859    2010-08-09 12:09:00 [690]

DOS-os régebbi verzók

Előzmény: KisKZ, 2010-08-09 11:30:00 [688]


elektron | 15859    2010-08-09 12:06:00 [689]

TurboCNC a neve a DOS on is működőt keresd, de biztos megvan valakinek, aki át tudja küldeni is, ha nem találod. A honlapjuk ez TurboCNC honlapja

A DOS-os verziót keresgéld, az lehet a 3.xx verzió.

Előzmény: KisKZ, 2010-08-09 11:30:00 [688]


KisKZ | 6456    2010-08-09 11:30:00 [688]

Elektron!
Említettél egy DOS alapú vezérlő szoftvert!
MElyik is volt ez, és honnan tudom leltölteni?
Ha jól emléxem azt írtad, hogy ingyenes.
Ugy néz ki, hogy tudok ideiglenesen szerezni egy DOS alapú gépet.
A vezérlő és a mechanika által adott lehetőségeket ezzel talán egyszerűen be tudom határolni, és nem próbálkozok majdan feleslegesen a határok felett máskor sem.

Előre is köszönöm a segítséget!


n/a (inaktív)    2010-08-09 08:00:00 [687]

Szia! Tudsz vele 3d relief marásokat csinálni jó sebességgel és nem lassul le?

Előzmény: Sir-Nyeteg, 2010-08-08 21:08:00 [680]


n/a (inaktív)    2010-08-09 06:00:00 [686]

Elvileg tényleg segít a letiltogatás, de akármi is lehet. A Win egy csomó minden meglétét alapból feltételezi és lehet hogy a hiánya nagyobb zűröket okoz mint a megléte. Szóvak ez szerintem ráér később, nem valószínű hogy ez a fő gond. Letiltani az Eszközkezelőben is le lehet a dolgokat egyébként. A VGA mindenképp tanácsos, mert a megjelenítés folyamatos adatforgalommal jár és ha nincs külső VGA akkor a rendszerbuszon szaladgálnak az adatok. A leggagyibb 1-2000 FT-os vagy ingyé kapható is bőven elég. Már a Geforce 2-ben is komoly gyorsítás van.

Előzmény: KisKZ, 2010-08-08 22:03:00 [685]


KisKZ | 6456    2010-08-08 22:03:00 [685]

Kösz az infót.
Megszakítás lesz.
Előb kússzon fel most szépe na cucc. Utána meglátom mit és hogyan tiltogatok vagy hogyan ne, ugy hogy azzal ne okozzak gondot.
Az ütközések hamar kiugranak ugyis.

Stimmt az IRQ-k és a DMA-k korlátozott száma.
De,
A letiltás (vagyis a lehetséges IRQ igénylők csökkentése) és a lehetséges felhasználható IRQ-k száma nem kellene hogy éppenhogy fordított kapcsolatban legyen?

A VGA egyelőre marad, mert ebben a házban nem fér el akármilyen. Sajnos most felesben csak egy PCI-expresses 7600GS van felesben az pedig igencsak nem menne ugye bele. Hát ez van.
A memória nem jelent gondot, mert annyit bátran elvehet. Semmi komoly igény nem lesz a gépen. Csak a rendszer és a MACH.

Reménykedek. Mindjárt ugyis fenn van az egész.
Utána meglátom mi a helyzet igy vezérlő és CNC nélkül.
A továbbiakat ugyis csak kinn tudom majd tesztelni.

Előzmény: n/a (inaktív), 2010-08-08 21:54:00 [684]

n/a (inaktív)    2010-08-08 21:54:00 [684]

Megszakítás kell. Szerintem először is állíts mindent alapra a BIOS-ban. A portletiltásokkal vigyázz, mert történelmi okokból kevés megszakítás van, ezért jó párat közösen használnak az eszközök. Az alaplapi VGA helyett mindenképpen tegyél bele akármilyen gagyi külső VGA-t, mert az alaplapi a rendszermemóriából vesz el.

Előzmény: KisKZ, 2010-08-08 21:16:00 [681]


KisKZ | 6456    2010-08-08 21:52:00 [683]

Közben már csak azértis ujra nekifutottam a DELL ujratelepítésénék.
Nem tudom miért, de most minden probléma nélkül átment a hardverteszten és már kúszik fel a cucc.
Mondjuk mindent szépen kiszedtem a gépből és ujra betettem.
Lehet hogy valahol kontakt probléma lehetett.
Legalábbis reménykedem, hogy ez a jelzés, mármint aproblémamentes install, jobb jövőt vetít előre.


Sir-Nyeteg | 1319    2010-08-08 21:26:00 [682]

Sajnos én nem vagyok profi ebben, de azt tudom, hogy pénz hiján lett ez az ősrégi gép
Na meg így utólag végiggondolva azért, mert ennek a drivereit szinte 100%, hogy ismeri a butított XP is

Előzmény: KisKZ, 2010-08-08 21:16:00 [681]


KisKZ | 6456    2010-08-08 21:16:00 [681]

Akkor csak felrakom rá a cuccot és megnézem mit tud.

A DELL-t amit eddig használtam most még egy picit nyaggatom. Éppen most is meghalt a drivertestnél.
Megint az alaplapi INTEL grafikus vezérlő nem kedvelte az együttműködést, 30KHz es tesztnél.

Tudom... Talán nem kell a 30KHz... sem a magasabb, de most a CNC nélkül ez az amivel tudom hasonlítani a régi konfigurációhoz, annak vislekedéséhez.

EGY FONTOS KÉRDÉS!!!:
Kell megszakítás az LPT1-nek????
Mert megvan ugye a lehetőség arra, hogy a rendszer alatt kérjem azt, hogy keressen neki egy szabad IRQ-t, de le is tilthatom.

Sajnos ezt nem tudom, nem értek hozzá, hogy milyen hatása lehet a port működésére.

Előzmény: Sir-Nyeteg, 2010-08-08 21:08:00 [680]


Sir-Nyeteg | 1319    2010-08-08 21:08:00 [680]

:D Nekem 733MHz-es 256Mb RAM-os gépem van... Tutkón megy :D

Előzmény: KisKZ, 2010-08-08 20:47:00 [679]


KisKZ | 6456    2010-08-08 20:47:00 [679]

Sajnos nincs másik kéznél.
Pontosabban éppen most keresek az ADOK VESZEK-ben ATHLON XP-t vagy AMD BARTON-t, ahhoz a géphez amit a gyerek hazahozott.
Sajnos ami benne van az 1.1GHz-es. Ha lehet inkább meghúznám igy az elején és ha belefér akkor egy gyorsabb procit tennék bele.

A mostani gépen természetes már futtattam egy halom tesztet a HIREN's Boot CD-ról DOS módban.
A memória teljesen OK. Az IDE eszközök OK.
A legtöbb dolog eleve le van kapcsollva a BIOS-ban. Még a soros port, a PCI is le van csappintva.

Érdekes....
A teljes tesztél egy helyen jött elő probléma.
Ugyan hol????
A párhuzamos portnál.
Az egyiket még nem tudom pontosan értelmezni, nem olvastam utána, ez a Status mód. Ez a teszt annyit ad vissza, hogy ez a mód nem megy ezen a porton.
A másik már érdekesebb:
Az IRQ teszt. Egyételműen egyszerűen hibát jelez amikor próbálja megkeresni a teszt a port megszakítást. Egy szép FAILED eredmény és kész.

A port ECP-re van állítva, a DMA-ja valamilyen értékre (most éppen nem tudom megmondani milyenre mert éppen szét van kapva a gép).
A memóriacíme a szokásos.
Próbáltam a DMA állítással elérni, hogy valami változzon, de semmi.... Persze nem sok köze van a megszakításhoz tudom.. De nem volt semmi más állítási lehetőségem.

Szóval...
Most ugye megnéztem a gyerektől cserébe visszakerült régi gépet. Ez egy ABIT-NF7-S2G alaplappal szerelt gép, de egy nagyon régi procival ami 1.1 GHz-es. Szépen sorban összeraktam mindent rajta, most már csak telepíteni kellene, hogy azért meg tudjam nézni mit is csinálna ha menne. Azért csak jó lenne bele egy komolyabb proci.

Szóval eddig ennyi.
Lehet hogy a tegnapi szkópos videót csak összevégom és felteszem megmuttani, de félek ez inkább azt fogja mutatni, hogy nem vagyok tapasztalt, és lehet nem jól csináltam az ellenőrzéseket. Majd elmondjátok legfeljebb, hogy mit lehetne másképpen csinálni.

Előzmény: n/a (inaktív), 2010-08-08 08:02:00 [671]


hostya | 3101    2010-08-08 10:31:00 [678]

Szia!
Én is találkoztam hasonló jelenséggel, és mint ahogy vakegér is írta,(lehet memória,vinyó stb.) én a memóriára gyanakodtam.
Mivel nálam az alaplapon 2x 512-es memóriamodul van,ezért egyszerűen megcseréltem a kettőt,és azóta nincs gond.
Ezt a legegyszerűbb kipróbálni, mielőtt ujra "legyalulnád" a rendszert.


n/a (inaktív)    2010-08-08 10:09:00 [677]

... pc alaplap van összekötve. Az egyiken realtime fut a vezérlés a másikon meg a Win. Számtalanszor előfordul hogy a Win lehal, de a gép dolgozik tovább mert az RT vezérlés már beolvasta kódot.

Előzmény: n/a (inaktív), 2010-08-08 10:07:00 [676]


n/a (inaktív)    2010-08-08 10:07:00 [676]

Végül is igen. Mondjuk ez a Linux előnye. Lehet fordítani egy minimális kernelt, ahol semmi felesleges sincs, nem foglalja a ciklusokat. Bár a cégnél van eyg HSC maró ami úgy van megcsinálva hogy 2

Előzmény: Sir-Nyeteg, 2010-08-08 09:13:00 [675]


Sir-Nyeteg | 1319    2010-08-08 09:13:00 [675]

Legegyszerűbb, ha lehúzunk minden felesleges eszközt az alaplapról? Manapság az USB meg egy pendrive úgyis elég már.

Előzmény: n/a (inaktív), 2010-08-08 09:06:00 [674]

n/a (inaktív)    2010-08-08 09:06:00 [674]

Sajna az optikai olvasó magától is simán képes megakasztani a rendszert. Igazából feltelepítés után célszerű lenne a BIOS-ban minden felesleges vackot kikapcsolni, mert azok ellenőrzése is egy csomó időt vesz el. Ha a Win látja hogy létezik, akkor időnként lecsekkolja.
Ha valami kisebb zűr van velük, akkor egy csomó időt szöszölhet vele. Tegyél egy karcos DVD-t a meghajtóba és az egész rendszer lefagy. Vagy az Intéző megnyitásnál megpróbál tartalomjegyzéket/kötetcímkét olvasni az üres floppy meg DVD meghajtóból.

Előzmény: Sir-Nyeteg, 2010-08-08 08:27:00 [673]


Sir-Nyeteg | 1319    2010-08-08 08:27:00 [673]

Nekem a mostani gépem azt produkálta, hogy 2-3 percenként gondolkodott akár fél percet is. Olyan volt, mint amikor beraksz egy cd-t és amig olvasgat, addig a sajátgép sem tud megnyilni
Munkatársam rakta fel a win-t rá. Neki nem volt gondja vele. Már ott tartottam, hogy újratelepítem, de nem akart bootolni a cd-ről.
Ekkor lehuzigáltam a winyókat, de úgy se. Így újraindítottam, hogy hátha a win-ben tudok állítani valamit... És lám, hibátlan lett, nem gondolkozott többet.
Megoldás: a második winyót lehúzva felejtettem. :D
Biztonsági mentésnek akartam hagyni. Munkatársam nem dugta rá telepítéskor. :D
Olvasni tudta, de nem mindig érte el...
Azóta nincs gondom vele.

Ezt csak azért irtam, mert valószínűleg hogy neked is valami hardveres gondod van. Sajnos bármi lehet. (Láttam már billentyűzetet is, ami kékhalált okozott heti egyszer. Egy ilyen hibánál jöjj rá a megoldásra XD.)


n/a (inaktív)    2010-08-08 08:12:00 [672]

Célszerű lenne lefuttatnod a Memtest86-ot, illetve egy vinyó (Hard Disk Sentinel, HD Tune stb.) illetve egy telepítő/DVD meghajtó ellenőrzést (Nero DiscSpeed).

Előzmény: KisKZ, 2010-08-07 23:51:00 [670]


n/a (inaktív)    2010-08-08 08:02:00 [671]

Nem tudom érdemes-e küzdeni vele ha ilyen nyűgös az a PC. Lehet memória, telepítőlemez, vinyó akármi. Ha zűrök lesznek, sohasem tudod hogy mi a hiba.
A Win fut mert tele van hibajavító algoritmusokkal, addig küszködik amíg nem jut valamire, de korrekt futást már nem biztos hogy tudsz garantálni a MACH-nak.

Előzmény: KisKZ, 2010-08-07 23:51:00 [670]


KisKZ | 6456    2010-08-07 23:51:00 [670]

Nos.....
Ma, ahogy tegnap írtam, nekiestem a gép ujrarakásának a standard PC típusra.

Engem nem nagyon szívat meg egy számítógép, legalábbis altalában, de ez valamiért nem szeret engem és folyamatos kitolásokat követ el velem szemben.

Ötször kellett nekimennem, mire feltette a rendszert. A rendszer kiépítésének és az eszközök felsimerésének majd ezek kezelőprogramjainak telepítésekor mindig megállt.
Alőbb a garászban töltöttem el fél órát arra várva, hátha továbblép, majd hazahoztam és itthon ujra nekiestem.
Ujra adtam neki egy fél órát, mert időnként egy egy rovásnyit ment előrébb a folyamatjelző csík a végleges megállásig... De utána megint lekapcs. Próba ujra. Ujra ugyanez.
Visszakapcsolgattam a bioszban az alapeszközöket amelyeket nem tartottam fontosnak a későbbi használatkor (hátha ez nem tetszett neki). Ujra nekifutás, ujra megállás ugyanazon a ponton.....
Ujra nekiugrás, előről, itt egyszerűen ott hagytam a gépet és megpróbáltam volna szunylni egy délutánit... Egy óra mulva szintn semmi....
Kikapcs, de most nem ujra indítottama a telepítést, hanem hagytam, hogy a bekapcsolás után ujra futtassa a már feltett szeközökkel a telepítőt...
Így már sikerült. Átment a kritikus részen és feltelepedett a rendszer.
Chipset driver fel.
Video driver fel.
Ujraindulás.
Ellenőriztem mindet, a gép a megfelelő módban van feltelepítve.
Majd MACH3 fel
Specialdriver ahogy István írta. Elvileg fenn van a cucc.

Drivertest futtat.
Alapértelmezett 25KHz-es kernekfreire gyakorlatilag azt a szintet mutatja amint a telepítés előtt, de most érdekes módon egy két nem vszélyes, de az jratelepítés előtt nem látott nayobb tüske. Elvétve ugyan, de van.... Ez eddig nem volt.

Teszt ujra futtatás, indulás előtt kiválasztom a 20KHz-es frekit, hogy szépen lassan felfelé haladva lásam mit is tudunk most....
Fagyás, kékhalál....
Hiba a videó drivernél (???!!!???)
Ujraindulás,
Ujra driverteszt, 30 KHz ujra, fagyás, kékhalál nincs, de döglött a gép....
Ujraindítás....
Hagyom a tesztet...

A MACH3 alatt a H1 konfigot teljesen ujrageneráltam inkább. Maga a MACH működik, de amit itt benn gép nélkül meg tudtam nézni az az, hogy már 40KHz-es kernelfrekinél is lefogódik a sebesség. Messze alatta marad a teljesen azonos feltételek mellett, de 25 KHz kernelfeki mellett futtatott teszt sebességének.

Ez is rosszabb mint volt.
Fentebbi frekin nem is érdemes próbálkozni.

Elővettem a szkópot..
Ráaggattam az X step jelére és méregettem.
Csinálgattam kis videókat is azzól, hogy milyen jeleket tudtam elkapni.....
De mivel nem vagyok túl erős ebben a témában, még nem mndanám el mit gondolok a dolgoról.
Előbb inkább megkérnélek benneteket, hogy mit ajánlotok, hogyan és mit mérjek, hogy valamilyen módon képet alkothassak, esetleg ellenőrizhessek bármit a mostani működéssel kapcsolatban.

A szkóp ugyan nem túl fényes, de talán tudok vele méregetni valamit.
A mostani méréseknél ott az 5mikrosec környéki osztásra állítva meg tudom találni a jeleket.

Ha jól emléxem azt monstátok, hogy váltóban mérjek ugye?



Persze tudom, a rendes teszt az ha visszaaggatom a maróra és megnézem mi történik.
De megit kicsit elkeserítő, hogy elvileg olyasmit csináltam a géppel, ami miatt annak szebben és biztosabban kellene dolgoznia, de már most látható, hogy biznyos dolgok nehogy jobbá, hanem rosszabbá lettek.


  Fórum főoldal  |  A lap tetejére

Időrend:
Oldal 12 / 26 Ugrás ide:
Sorok:
|◄ Első  ◄ Előző   8  9  10  11  12  13  14  15  16   Következő ►  Utolsó ►|


 ◊ 
[ 0.8578 ]