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
    
   


UCxxx, mozgásvezérlők MACH3-hoz

Polgárdi Balázs fejlesztései Mach3-hoz.

 

Időrend:
Oldal 5 / 26 Ugrás ide:
Sorok:
|◄ Első  ◄ Előző   1  2  3  4  5  6  7  8  9   Következő ►  Utolsó ►|

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

istvan58 | 1765    2016-08-04 15:33:00 [1053]

mindenesetre ezt az XML-t elmentem és össze fogom hasolítani az újal.

Előzmény: istvan58, 2016-08-04 15:32:00 [1052]


istvan58 | 1765    2016-08-04 15:32:00 [1052]

Balázs,
Nem az UC400-at hibáztatom!
Mivel LPT vel is fennáll a dolog. Ugy tűnik valami bekavart a Mach-nak az UC telepítése után.
És mint látod Fa@ is erre gyanakszik, de neki UC100 után.
Valami lett a mach3 al, de csak gyanakszom hogy az UC telepítés után. De nem azonal. Egy telepítés és új XML jó esélyel segítene de jobb lenne rájönni mi is történhetett. De valószinü tényleg semmi köze csak valami megsérült az XML-ben. Végig néztem de nem látok semmit benne ami esetleg a feedhold ra utal

Előzmény: n/a (inaktív), 2016-08-04 14:46:00 [1050]


n/a (inaktív) | 1036    2016-08-04 15:11:00 [1051]

Közben biztos ami biztos ellenőriztük a feedhold-ot Mach3/UC400ETH-val és nálunk működik gond nélkül.

Előzmény: istvan58, 2016-08-04 10:23:00 [1049]


n/a (inaktív) | 1036    2016-08-04 14:46:00 [1050]

Szia István,

Némi háttérinformáció mielőtt esetleg téves következtetést vonnál le:
Az UC-k nem jegyeznek meg semmilyen Mach3 beállítást, adatot. Minden adat, beállítás futás időben töltődik a mozgásvezérlőbe.
Ebből adódik, hogy nem tud olyat megjegyezni, hogy te például letiltottad a Feddhold-ot.
Ezzel szemben a Mach3 megtud jegyezni bármit, eltud menteni bármit az .xml beállítás fájlba és onnan szed minden beállítást.
A másik dolog, hogy az UC mit sem tud arról, hogy a feedhold tiltva van-e vagy sem. Azt tudja csak, ha egy esemény meghívódik. Például a feedhold. Ha meghívódik akkor az UC végrehajtja, ha nem hívódik meg akkor meg nem.

Amit én gondolok az alapján amiket írtál, hogy egy ideig működött a feedhold, most meg nem működik,
hogy valami megváltozott a beállításokban.
Elképzelhető, hogy a Mach3 .xml fájlja sérült meg, ami sajnos egy jól ismert jelenség Mach3-nál.
Ha a PC úgy kerül leállításra, hogy a Mach3 fut, akkor megtud sérülni a fájl.
Én azt javaslom készíts egy vadonat új xml fájlt és nézd meg azzal megy-e a feedhold.


istvan58 | 1765    2016-08-04 10:23:00 [1049]

Szia Balázs,


megnéznétek a #15307 belyegyzést, és néhányat visszafelé a Mach3 topicban?
Érdekes dolgok merültek fel amit én és fa@ fórumtárs is tapasztalt ami valószínü az UC100 és UC400 al kapcsolatos.


Molnár Szabolcs | 498    2016-07-13 17:45:00 [1048]

Szia!
Összetesteltem mindent mindennel.16mm2=Plazmavágó,cnc váz,vágó asztal,pc szekrény,4mm2=alaplap,uc300,vinyó stb.Most elindul a vágás és el is végez pár műveletet,de randomban most is kifagy pilot gyujtást követően. Gondolom ez a nem megfelelő földelésnek köszönhető. Holnap leverek kettő 2m-es szondát egymástól 20m-re. Remélem ez megoldja a jelenséget. A jelenlegi földszondák már kb 40 éve le van verve.

Előzmény: n/a (inaktív), 2016-07-11 22:04:00 [1041]


Pabló | 1529    2016-07-12 22:16:00 [1047]

Ha fogja tudni az NCT-Fanuc tudását, mi azzal bőven megelégszünk..
Én már hozzá szoktam, mindnek megvan a maga lelkivilága.
Ha kicsit hibázik talán észre se vesszük.

Előzmény: n/a (inaktív), 2016-07-12 21:52:00 [1046]


n/a (inaktív) | 1036    2016-07-12 21:52:00 [1046]

Az, hogy a szerszámkompenzációnak G41/42 hogyan kell működnie azt én úgy láttam, hogy szigorúan definiálva van.
Az oka ennek, pontosan amit írsz, hogy manuális programozáshoz lett ez kitalálva és ott a programozónak pontosan át kell látnia, hogy mi hogyan fog történni. A lényeg annyi, hogy egyetlen mozgás egységgel, szakasszal vagy ívvel néz előre a vezérlés és úgy kalkulál metszéspontot, csatlakozási szöget, eltolt szakaszt, ívet, stb.-t.
Ahhoz hogy minden esetben pontos legyen az eltolt pálya ahhoz viszont olyan távolra előre kéne tekintenie a mozgás kódban a szoftvernek, hogy észrevegye időben, hogy a későbbi kódban már esetleg túlfutott az eltolt és időben előtte álló "jövőbeli" kontúron.
Ez a kézi programozó számára simán átláthatatlanná tehetné a történéseket.
Soronkénti végrehajtásnál tovább bonyolódik a helyzet, na de nem akarok most nagyon belemenni, ha végig gondoljátok akkor szerintem világossá válik.

Majd ha lesz egy kis időm csinálok képernyő képeket egyszerűbb esetlekről némi magyarázattal, amiken jobban látszik és érthető, hogy mi miért történik.

Egyébként már leprogramoztam a G41/G42-t az UCCNC-hez, még finomítások vannak vissza, illesztési dolgok, csak nem akartam még leírni, mert már megtanultam, ha valamit elmondok hogy mindjárt kész és ha mégse készül aztán el időben, akkor jön a számonkérés.

A leprogramozás során pedig elég jól sikerült átlátnom az algoritmus problémáit és a korlátokat, ezért is gondoltam hogy ha már megkérdeztétek, akkor felhívom a figyelmet rá, hogy a szerszámkompenzáció az azért nem csodaszer, klassz dolog, de sokszor nem használható büntetlenül.

És egyetértek, hogy esztergákon lehet komolyabban használni a korrekciót, mert a pályák nem olyan bonyolultságúak általában mint egy komplex maró pálya.

Egyébként nem Mach3-at használtam referenciának, hanem többek közt Fanuc és NCT leírásokat ahol definiálják, hogy hogyan működik a vezérléseiken a G41/42 kompenzáció.
De egyébként Mach3-on is ugyanúgy működik, ellenőriztem.

Előzmény: Béni, 2016-07-12 21:23:00 [1044]


Pabló | 1529    2016-07-12 21:35:00 [1045]

Szia Balázs!
Ismerem hogy mit jelent pontosan a szerszámsugár kompenzáció.
Cnc-n dolgozok napi szinten, és kézi kódírásnál nagyon nélkülözhetetlen, az természetes, hogy sarkot sose lehet maróval kivágni, de viszont ha más maró, vagy élezett kerül kézbe, nagyon hasznos,hogy beírhatom a sugárt, és figyelembe veszi. Azért sokkal komplikáltabb mindig a programot újra generálni, és mindig keresgetni a rajzfájlt hozzá.
Ipari vezérlők sokszor képesek, hogy ezt már nem bírom megcsinálni, le is tiltok.
Azért azt is át lehet cseszni.

Előzmény: n/a (inaktív), 2016-07-12 00:19:00 [1043]


Béni | 1975    2016-07-12 21:23:00 [1044]

(Nem akarok vitát kezdeni, de ez az egész nagyon sántít.)

A rádiusz kompenzáció lehetősége kézi programozásnál fontos minden olyan technológiánál, ahol szerszámsugár értelmezhető.
Ide értve a láng, plazma, lézervágót és még a huzalszikrát is.
Eszterga esetén viszont nélkülözhetetlen.
Az, hogy a mai világban számtalan CAM rendszer elérhető szinte minden elképzelhető programozási feladatra, nem jelenti azt, hogy ez a funkció értékét vesztette volna. Véletlenül sem a kopás kompenzálására lett kitalálva és alkalmazva.
Bizonyos vezérlőknél a kompenzációs tárban külön van kezelve a kopáskorrekció (Wear).
Programoztam és használtam már néhány ipari vezérlőt, de az említett túlfutással és annak dokumentálásával soha nem találkoztam. (Mach3 nem referencia.)

Fogalmam sincs, hogy milyen algoritmussal és hogyan szokás ezt megoldani. Ha nekem kéne, akkor egy előfordítóval a forrás beolvasásakor elvégezném a párhuzamos "szerkesztését" és nem lenne a végrehajtásban semmi különbség a kompenzálatlan kódhoz képest. (Esetleg a kijelzéshez kellene egy módosított rutin.)

Előzmény: n/a (inaktív), 2016-07-12 00:19:00 [1043]


n/a (inaktív) | 1036    2016-07-12 00:19:00 [1043]

Szia,

Igen, tervezzük, hogy előbb utóbb belekerüljön, bár a szerszámsugár kompenzáció azért sokszor nem optimális megoldás. Arra szokott megfelelő lenni, hogy a szerszám kopást kompenzáljuk mondjuk, vagyis amikor a sugár korrekció nagyságrendileg sokkal kisebb mint a szerszám átmérő,bár ilyenkor is okozhat pontatlanságot a G41/G42 használata, de nagyságrendileg elég kicsit, hogy ne legyen gond.
Ez egyébként azért van, mert a kompenzáció működéséből adódóan nem lesz pontos az eredeti pálya követése, az algoritmus működéséből adódik a pontatlanság. Például ha egy pálya sok kis szakaszból áll és jön mondjuk egy 90 fokos töréspont, akkor a szerszám túl fog futni az eredetitől eltolt pályáról és utólag tud csak visszatérni, vagyis belemar az anyagba ott ahol nem kéne.
Szóval a szerszám sugár kompenzáció hasznossága eléggé limitált és észnél kell lenni, hogy az ember hogyan és mikor használja, a használata nem olyan egyszerű és egyértelmű ahogy első gondolatra tűnik.
CAM programmal újragenerálni a pályát a kompenzált értékkel az jóval pontosabb megbízhatóbb megoldás.

Berakok ide 2 képet Mach3 szerszámkompenzációs képei, a fehér vonal 2mm-el kompenzált pálya.
A második képen kinagyítottam a sarkot, ahol látható, hogy túlfut a pályán.
Ez nem a kompenzációs algoritmus hibája, utánaolvastam több ipari vezérlő adatlapjában is és az algoritmusból adódik, abból ahogyan működik, ahogy működnie kell.
Na szóval a képek:



Előzmény: Pabló, 2016-07-11 22:58:00 [1042]


Pabló | 1529    2016-07-11 22:58:00 [1042]

Akkor ezért nincs a szerszám tárban sugár érték.
Ez valamikor bele fog kerülni?

Előzmény: n/a (inaktív), 2016-07-11 22:04:00 [1041]


n/a (inaktív) | 1036    2016-07-11 22:04:00 [1041]

Sziasztok:

Molnár Szabolcs: Nincs mit, remélem sikerül elhárítanod mihamarabb a problémát.
Azt is megpróbálhatod, ha nem sikerül normális földelést kialakítani, hogy az UC300 felső kis panelkáján van 4 darab d=3.5mm furat, az egyiket egy csavarral és egy minél rövidebb és vastagabb vezetékkel összekötni a számítógép házának egy fémes részével, pl. a ház egy csavarjával.
Ezzel a zaj nem fog ugyan megszűnni, de nagyrészt közös módúvá válik a zaj az UC300 és a PC között, ezzel kevésbé lesz valószínű, hogy problémát okoz.

Pabló: G41/42-t egyelőre nem ismeri az UCCNC, a G43-t azt ismeri.

Előzmény: Molnár Szabolcs, 2016-07-11 21:05:00 [1039]


Pabló | 1529    2016-07-11 21:06:00 [1040]

Szia Balázs.
It az UCCNC-ben hova lehet beírni a szerszám sugár kompenzációt?
Vagy ismeri a progi a g41-g42 kódot?
G43 hossz korrekció kell? Gondolom.

Előzmény: n/a (inaktív), 2016-07-11 19:07:00 [1038]


Molnár Szabolcs | 498    2016-07-11 21:05:00 [1039]

Köszönöm szépen! Elolvastam és érthető a hiba mivolta. Nemrég megnézte két e-on-os ismerős és ők is ezt a hiányosságot állapították meg.(helytelen földelés). Holnap kiépitem és megírom az eredményt. Üdv.

n/a (inaktív) | 1036    2016-07-11 19:07:00 [1038]

Sziasztok,

Molnár Szabolcs: Az UCCNC topikban a #2647 írtam ezzel a problémával kapcsolatban. Többet nem nagyon tudok mondani, ott mindent leírtam.

Gorbi: Akkor az nem .NET probléma biztosan, mert akkor más hibaüzenetet adna, akkor Defective .dll-t írna ki a Mach3.
Légyszi írj egy levelet az info@cncdrive.com e-mail-re a továbbiakról, mert a fórumon lassan fog menni ennek a további tárgyalása, mert nem tudom folyamatosan figyelni a fórumot.

Ftibor: Rákerestem a leveledre és megtaláltam, elnézést, de eddig nem vettem észre. Mindjárt írok választ.


Molnár Szabolcs | 498    2016-07-11 17:39:00 [1037]

Sziasztok. A plazmás topikban leírtam a problémámat. Röviden annyi,hogy mikor a pilot gyújtások kapcsol az uc300 azonnal kifagy. 3 fázisú a plazma vágó. Mi lehet az oka ennek a jelenségnek. A vezérlő egy fém zárható rittal szekrényben van. MAch3 alatt megymenne ) a rendszer. Ha valakinek van valami ötlete és meg is osztja velem azt mélységessen megköszönném.


gorbi | 280    2016-07-11 16:30:00 [1036]

Felugrik egy ablak:
Error!
UC100 not found
Check the connection!

Előzmény: n/a (inaktív), 2016-07-11 10:50:00 [1034]


ftibor | 38    2016-07-11 13:36:00 [1035]

Szia Balázs,

Múlt héte, hétfőn irtam a megrendelésem viszaigozolásával kapcsolatban, de azóta nem kaptam semilyen választ. Kérlek segíts, ha tudsz.
Köszönöm

Fehér Tibor


n/a (inaktív) | 1036    2016-07-11 10:50:00 [1034]

Hibaüzenetet ad a Mach3 induláskor? (Defective dll..)

Előzmény: gorbi, 2016-07-11 00:01:00 [1033]


gorbi | 280    2016-07-11 00:01:00 [1033]

Az 1027-ben leirtaknak megfelel minden, de inditáskor még mindig nem találja az uc-100 -at.
A dot net dolgot ujra lehet telepíteni valahogy?
Melyik részeit takarithatom ki gond nélkül ujra telepítés előtt?

Előzmény: n/a (inaktív), 2016-07-10 23:47:00 [1032]


n/a (inaktív) | 1036    2016-07-10 23:47:00 [1032]

Sziasztok,

Gorbi: Akkor komoly gond nincsen szerintem, azokat nézd/csináld még meg amiket az #1027-ben leírtam.

Pabló: Ezt a letiltást a Mach3 csinálja nem az UC100, illetve akkor tiltja le ha egyszer azt választod indulásnál a Mach3 motion control device selection oldalon, hogy ne mutassa többet az oldalt úgy, hogy a nyomtató portot választod ki. Az UC100 útmutatóba le van írva egyébként meg gondolom a Mach3 adatlapjában is.

Előzmény: Pabló, 2016-07-10 21:03:00 [1031]


Pabló | 1529    2016-07-10 21:03:00 [1031]

Köszi Balázs!
Nekem is ez a Reset device megoldotta a gondot.
Rakhatnátok be erről egy képernyőképet a telepítési útmutatóba. Meg a pdf-et is odarakhatnátok a letöltésbe. Hasznos dolog.

Előzmény: n/a (inaktív), 2016-07-10 18:30:00 [1027]


gorbi | 280    2016-07-10 19:13:00 [1030]

Az usb eszközök között UC100 motion controller néven fenn van igen, már megtaláltam


gorbi | 280    2016-07-10 19:12:00 [1029]

Elvileg fent van a 2.0 verziótól kezdve a 4.0 extended verzióig mind mármint a net framework

Előzmény: n/a (inaktív), 2016-07-10 18:30:00 [1027]


gorbi | 280    2016-07-10 19:09:00 [1028]

A net framework telepítés hibával áll le, leet hogy ez a gond, de ezt hogy lehet orvosolni?

Előzmény: n/a (inaktív), 2016-07-10 18:30:00 [1027]


n/a (inaktív) | 1036    2016-07-10 18:30:00 [1027]

A Mach3/Plugins könyvtárban pedig ellenőrizd, hogy ot van-e az UC100 plugin dll fájlja?

Illetve a Config Plugins menüben legyen zöld pipálva az UC100 plugin.

Valamint lehet, hogy letiltottad a Mach3-ban a mozgásvezérlők használatát. A Function cfg's menüben a Reset device sel menüpontot nyomd meg és indítsd újra a mach3-at, ezzel kitörli a tiltást.

Előzmény: gorbi, 2016-07-10 18:16:00 [1025]


n/a (inaktív) | 1036    2016-07-10 18:21:00 [1026]

az USB eszközök közt milyen néven van? UC100 motion controller?

Előzmény: gorbi, 2016-07-10 18:16:00 [1025]


gorbi | 280    2016-07-10 18:16:00 [1025]

Szervusz,
Uj eszkoz hang van,megnézem minek jelentkezik be...
Az USB vezérlők közé kerül, de a Mach3 nem látja.

Előzmény: n/a (inaktív), 2016-07-10 17:43:00 [1024]


n/a (inaktív) | 1036    2016-07-10 17:43:00 [1024]

Sziasztok,

Gorbi: Az eszközkezelőben ha megnézed úgy, hogy az UC100 be van dugva az USB portra, akkor sehol nem jelzi ki az eszközt? Sem az USB eszközök közt? Illetve az egyéb eszközöknél sem FTDI vagy hasonló néven?
Azt is nézd meg kérlek, hogy amikor bedugod, ill. amikor kihúzod akkor van-e a szokásos USB-s új eszköz hang lejátszás, vagy pedig az eszközkezelő lista olyankor frissül-e? Mert ha igen, ha a Windows olyankor újraírja a listát azt látod a képernyőn ha folyamatosan nézed és ha igen, akkor ott van az eszköz valahol és akkor valami driver telepítési probléma lesz csak.
Ha egyáltalán ezt sem csinálja, ha az eszközkezelő egyáltalán nem látja akkor valami komolyabb gond lesz.


gorbi | 280    2016-07-10 17:25:00 [1023]

Fent van a gépen minden. és ujra is telepítettem, de fizikailag nem látszik az eszközkezelőben az uc100.


ANTAL GÁBOR | 3847    2016-07-10 13:22:00 [1022]

A dot net van a gépeden ? A Balázsék oldalán van autoinstaller . Én újratelepíteném ....

Előzmény: gorbi, 2016-07-10 11:48:00 [1020]


gorbi | 280    2016-07-10 11:49:00 [1021]

Ja az eszközkezelőben sem jelenik meg.


gorbi | 280    2016-07-10 11:48:00 [1020]

Valami gond van az UC100 vezérlőmmel...
Régebben kipróbáltam ment is rendesen, most ujra elővettem de csak a zöld led világít rajta, nem kapcsolódik a számítógépemhez. két gépen is próbáltam, több usb kábelt is rápróbáltam. Járt már igy valaki? Esetleg tud segíteni valaki?


istvan58 | 1765    2016-06-20 11:09:00 [1019]

Szia Balázs,

értem én hogy WIN7-el teszteltek. Csak azért mondtam az XP-t mert most azzal nincs gondom. És ahogy emailbe is irtad valószínü a HP hardware a gubanc oka. Nyilván azért hogy az én HP gépemen elmenjen WIN7-el nem éri meg a munka befektetést részetekröl. Ha mindenáron WIN7-et akarok kicserélem a vasat. De mint mondom minek ha megy az XP. A mach3 már ugysem lesz felylesztve. Nyilván kihívásnak jó feladat megoldani..

Na és a lényeg, mivel UCCNC licenszen is megvan előb utóbb áttérek, csak kicsit igazítani kell a gép konfigon.

Előzmény: n/a (inaktív), 2016-06-20 10:46:00 [1018]

n/a (inaktív) | 1036    2016-06-20 10:46:00 [1018]

Sziasztok,

Svejk: Az UCCNC legújabb verziója (1.2xxx) kevesebb erőforrást igényel mint a régi 1.0 és 1.1.
Egyedüli dolog amiből több kell neki az a videó kártya RAM (VRAM). Amúgy kisebb processzor és lassabb gép is elegendő neki mint a régi verziónak.
A régi verzió Flashplayer-el ment, ami félig meddig megosztva csinálja a videókártyán és a CPU-n a grafikai számításokat, így mindkettőt használja "félgőzzel".
Az új verzió OpenGL-t használ és próbáltuk úgy megcsinálni, hogy amit csak lehet azt közvetlenül a videó kártya, a GPU számoljon, hogy ne a processzort terhelje a szoftver.
Probléma akkor van ha a VRAM túl kicsi és a képek nem férnek be a memóriába, mert ilyenkor az OpenGL hardveresen azt csinálja, hogy elkezdi másolgatni a képeket a videó kártya és a RAM közt oda vissza, mikor éppen melyik képeket kell használnia.
Ez nagyon le tudja terhelni a gépet, mert a képernyő 30Hz-el van frissítve, hogy szép gyors legyen a kijelzés.
A megoldás egy elég nagy VRAM-al rendelkező videókártya. Az UCCNC kb. 50 MB VRAM-ot használ a Default screenset-el, szóval egy 128MB VRAM mérettel rendelkező kártya már OK. Ha biztosra akarunk menni, a bővíthetőség jegyében 256MB-ot szoktunk javasolni.
Ha a videó RAM elég nagy akkor pedig az UCCNC nagyon kis erőforrás használattal elketyeg. Konkréten az én gépemen g-kód futás közben is 0% a folyamat proci terhelése, ugyanezen a gépen a Flash-es verzió 10-12% procit használt.
Egyébként a 256 MB videó RAM se egy extrém érték, 10 éves videókártyák is tudják, a mai videókártyák VRAM-ja a pár gB nagyságrendű.

Egyébként a Flash-ről azért tértünk át OpenGL-re, mert egyrészt a Flash kezd elavulttá válni, másrészt igazán gyors grafikát nem lehet vele csinálni anélkül, hogy a procit ne használná túlzottan, harmadrészt az utóbbi időben egyre durvább bugok voltak a kiadásokban.
2015 December végén például volt egy olyan Flashplayer kiadás amit a Windows automatikus frissítésbe is beleraktak, ami teljesen működésképtelenné tette a Flashplayert minden desktop alkalmazás számára.
Igazából amikor ez történt akkor vált véglegessé a döntés, hogy áttérünk az OpenGL-re, mert már túl sokan használják ahhoz a szoftvert, hogy megengedhessük magunknak, hogy egy Flash frissítéstől megálljon esetleg a szoftver a felhasználóknál.

Az OpenGL pedig a videókártyába van építve és a Windowsba alapból be van építve a támogatása.
Maximum ami szoftver kell neki az a videó kártya driver, azt pedig a videokártya gyártója fejleszti, nem szoftver fejlesztő harmadik fél.
Szóval hosszú távra sokkal jobb alapnak ítéltük meg az OpenGL-t, mint a Flash-t.
Igaz sok meló volt átírni Flash-ről OpenGL-re, 4-5 havi folyamatos munkám van benne, de szerintem megérte megcsinálni.

Az, hogy a Mach-nak pontosan mi a rendszerigénye, azt nem tudom, mert számunkra is valamennyire "fekete-doboz", hiszen a forráskódot nem látjuk.
Mindenesetre a személyes tapasztalatom az, hogy valamiért a HP gépeket nem nagyon szereti a Mach, hogy miért azt nem tudom, de mi akár hány HP gépen próbáltuk régebben, sose működött tökéletesen. Igaz ez már rég volt és nyomtatóporttal próbáltuk abban az időben, nem mozgásvezérlővel.

István: Mi jelenleg Win7 és az feletti OP rendszerekkel tesztelünk csak. XP-vel már egyáltalán nem, csak akkor ha valami specifikus dolgot muszáj esetleg kipróbálnunk. Az én és P.Balázs fejlesztő gépén is Win7 van. A step/dir számlálást és gyorsítás mérést is Win7-el csinálta Balázs.


istvan58 | 1765    2016-06-20 09:03:00 [1017]

Szia,

azért egy HP DC7800 2x 3Ghz-es procival nem anyira rosz. Itt valami más a bibi.

Előzmény: Kisamotors, 2016-06-19 23:38:00 [1014]


istvan58 | 1765    2016-06-20 08:37:00 [1016]

Szia Balázs,

nekem nem sügős mivel XP-vel teljesen rendben van a dolog. Most azért hogy tudjam win7-el használni nem érdemes munkát ölni bele. Esetleg csak azért hogy tisztán lásatok mert valószínü hogy másnál más PC-vel is előfordulhat.

Előzmény: Polgárdi Balázs, 2016-06-19 23:16:00 [1013]


svejk | 27163    2016-06-20 06:10:00 [1015]

Talán alapvetően azért, mert egyik szoftverfejlesztő sem rágta a szánkba, hogy cserélj vasat, cserélj vasat..., csak ezzel lesz tuti...
A Mach3 is csak szép lassan suttyomban nőtte ki a gépeket. (10 éve még a PIII 450 MHz-es notin is ment)
Az UCCNC-nél is a verzióváltáskor számomra csak a kérdések után derült ki, hogy komolyabb videokártyát igényel.
Ha elolvasod a manuálját akkor láthatod, hogy a minimális konfig 1,8 GHz duo vagy dual core proci. Igaz hogy írja az OpenGL1.3-at is, de én azt sem tudom mit jelent.


Előzmény: Kisamotors, 2016-06-19 23:38:00 [1014]


Kisamotors | 645    2016-06-19 23:38:00 [1014]

Helló Svejk!

Még mindig nem kell komolyan venned, pedig már több hónapos a regem
Épp a #2950 és előtti kérdésem arra utalt, hogy miért 10-15 éves kukázott vasakkal küzdenek sokan, arra akarják optimalizálni a programot.
Nem az xp-vel van bajom, hanem azzal a géppel, amin még az XP-is csak döcög.
Tiszteljük már annyira a fejlesztőt, hogy ne a minimálist épp, (vagy nem) teljesítő gépre telepítjük.
A nagy vas, nem tudom, hogy irónia volt-e, de az én 6-7 éves gépem bőven túlteljesíti az elvárt konfigot, és nem érhet többet egy huszasnál.

Előzmény: svejk, 2016-06-13 10:20:00 [1004]


Polgárdi Balázs | 452    2016-06-19 23:16:00 [1013]

Szia István köszi a rengeteg tesztelést. A tesztjeid alapján lassan kezd körvonalazódni a probléma oka. Nekünk sajnos nem sikerült eddig a beállításaiddal előidézni a hibát, pedig több számítógépen tesztelem már vagy 3-4 hete, ezért is nehéz megfogni mi lehet az oka. Készülőben van már egy kimondottan neked készített teszt plugin, amivel a diagnosztikai adatok alapján remélhetőleg fényt deríthetünk majd a hiba okára. Addig is türelmedet kérem.

Előzmény: istvan58, 2016-06-19 22:55:00 [1012]


istvan58 | 1765    2016-06-19 22:55:00 [1012]

Tegnapi teszteket ma többször lefuttattam.
Tehát a 13000 soros kód, Mach3+UC400ETH+HP DC7800SFF.
Win7 környezet, nem jött be a tegnapi siker. valamiért tegnap egyszer lement véletlenül.
Max 10000 sorig ment el de volt hogy már 300-nál megált lépésvesztés miatt.

XP környezett: itt ma is minden OK, 5x futott le teljesen hiba mentesen. Igy nekem minden OK. Eddig is XP-vel ment a gépem.

Talán csak azért lenne jó kideríteni mi lehet a win7-el mert másnál is előfordulhat és nem csak HP gépen. Sajnos a mostani PC-k mindegyike bonyolult energia gazdálkodással megy, és szerintem innen jönnek a problémák. Sokszor úgy néz ki hogy minden OK, de egyszer csak ugrik egyet és annyi.


istvan58 | 1765    2016-06-19 01:13:00 [1011]

felélesztést= fejlesztést

Előzmény: istvan58, 2016-06-19 01:06:00 [1009]


istvan58 | 1765    2016-06-19 01:10:00 [1010]

ja még annyi hogy első próbálkozásként lecseréltem az alaplapi videókártyát egy PCIE-re de ez nem segített csak az említett power profil állítások. Holnap kiveszem a kártyát hogy lássam alaplapival is.

Előzmény: n/a (inaktív), 2016-06-19 00:57:00 [1008]


istvan58 | 1765    2016-06-19 01:06:00 [1009]

Végül is úgy néz ki az én problémám megoldódott.
Holnap még lefuttatom néhányszor hogy lássuk mi a helyzett.
De szívesen kipróbálom a teszt plugin-t, talán ezzel támogatom a felélesztést is.

Előzmény: n/a (inaktív), 2016-06-19 00:57:00 [1008]


n/a (inaktív) | 1036    2016-06-19 00:57:00 [1008]

Szia István,

Mi még mindig dolgozunk a neked szánt teszt pluginon amit ígértem, sajnos még nem sikerült befejezni, de nem feletkeztünk meg rólad.

UCCNC-ben a mozgásvezérlő szál egy nagy prioritású önálló szálon fut.

Mach3-ban viszont ezt a részét valahogy nagyon nem jól csinálták meg, mert nem fut magas prioritású szálon és bár a pontos működés nincs dokumentálva, de úgy tűnik a GUI szálon fut a pluginok kezelése is. Ezt abból következtettük le, hogy ha például elkezded a Toolpath nézőkén forgatni a szerszámpályát akkor elkezd akadozni az adatküldés, annak ellenére, hogy a procit a forgatás nem terheli meg szinte semennyire. Szóval olyan mintha a GUI (fő) szálon futtatnák a plugin interface-t is.

Előzmény: istvan58, 2016-06-19 00:25:00 [1007]


istvan58 | 1765    2016-06-19 00:25:00 [1007]

Szia Balázs (...ok)
Úgy néz ki megoldottam a Mach3+UC400ETH+ HP DC7800 rejtélyt. Igaz csak egyszer futtattam le a 13000 soros teszt G kódot de eddig szinte mindig elakadt max a felénél vagy durván hibázott.

Először is feltelepítettem az UC400 at az XP partícióra is amely nem ACPI módban van hanem standard PC módban. Itt hiba nélkül lement egyszer.
Na azután a Win7 partícióban átálítottam a power profilba "balanced" módot "high performance" módra. Kikapcsoltam néhány szerintem szükségtelen szervízt, pl. a windows defendert ami a win7 része.
Ezután egyszer lefutott a teszt kód hibátlanul. Nos nem akarom elkiabálni, holnap még néhányszor lefuttatom.

Volna 2 kérdésem:

1. futás közben a proci használat 0 és max 2% között véltozott, ez igy ok? Miért nem győzte küldeni az adatokat az UC400 nak?

2. Ez a power profil miért zavar be a Mach3 ba és nem az UCCNC-be? Úgy tudom a Mach is egy fő szálon futó progi.


svejk | 27163    2016-06-13 21:39:00 [1006]

No, bumm...

Előzmény: istvan58, 2016-06-13 21:27:00 [1005]


istvan58 | 1765    2016-06-13 21:27:00 [1005]

Szia,
Most kuldtem el Balázsnak a hétvégi tesztek összefoglalóját.
A lenyeg a mach3+uc400 párosal valami nem 100%os.Lenovo laptopal sem.

Előzmény: svejk, 2016-06-13 10:20:00 [1004]


svejk | 27163    2016-06-13 10:20:00 [1004]

Az UCCNC topicban úgy #2950 körül én is rájöttem, hogy komoly vas kell már ezeknek.

Úgy emlékszem ez a HP-d a Mach3-mal is csak valamelyik különleges telepítési móddal fut rendesen...

Előzmény: istvan58, 2016-06-11 18:24:00 [1001]


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

Időrend:
Oldal 5 / 26 Ugrás ide:
Sorok:
|◄ Első  ◄ Előző   1  2  3  4  5  6  7  8  9   Következő ►  Utolsó ►|


 ◊