Miért van az, hogy Mach3 mill-ből szépen dolgozik a gép loaderből pedig nem látják egymást?

Nagyon ügyes vagy Csaba, köszönjük!

Előzmény: dezsoe, 2015-01-23 15:05:00 [1691]

Sziasztok!
Ha valaki használ Eagle -> pcb-gcode -> Autoleveller -> UCCNC kvartettet, akkor tapasztalhatja, hogy nem zökkenőmentes az együttműködésük. Ezen próbáltam egy kicsit segíteni, használjátok egészséggel!
(A billentyűzet projekt nem halt el teljesen, csak nem volt időm foglalkozni vele. Ha minden igaz, akkor az lesz a következő.)
Letöltés és doksi

Szia Gábor,

A működési elvből fakadóan bizonyos keretek közt nagyjából mindegy az encoder felbontás, szóval nagyjából ugyanannyi számítást kell végezni kisebb és nagyobb encoder frekivel is. Az encoder felbontás csökkentése számottevően nem csökkent a processzoridő igényen, mondhatnám úgy is, hogy nem ez a szűk keresztmetszet.

Előzmény: ANTAL GÁBOR, 2015-01-22 12:56:00 [1689]

Szia ! azt hiszem félreértesz : Óvatosan szerettem volna a másik Balázst presszionálni hogy az Uc 100 zal is foglalkozzon menetvágás ürügyén . Ha gyengébb a proci akkor ha lassabban forgatjuk a főorsót valamint kisebb felbontású encóderrel szereljük az egységet Ennek szellemében valószínű hogy lenne elég idő a számolásra.
Én sok menetet vágok : 600 1/ min fölött szinte sohasem . Átlagban 320 1/ min nel . Újabban a rotary és laposmenetek kapcsán 120 1 / min nel .
Biztos emlékszel de nálam megy egy 30-120 1/min as tartomány is .

Előzmény: n/a (inaktív), 2015-01-22 11:04:00 [1687]

Meglehetne csinálni, persze kérdés, hogy mennyi értelme van. Arra gondolok, hogy bármelyik CAM szoftver post processzorában állítható az, hogy az I és J paramétereket abszolút vagy relatív koordinátaként generálja-e le.

A Mach3-nak a cam-je amit említesz az hogyan csinálja? Gondolom csak nem random jelleggel?! Mert az azt jelentené, hogy önmágával a Mach3 is kimpatibilitási problémák vannak, hiszen akkor mindig állítgati kell, kikell találnod, hogy éppen hogyan generálta az I, J-t. Gyanítom, hogy ez csak nem így van?! Ha pedig nem így van, akkor pedig állítható kell legyen azt alapul véve, hogy néha jót generál...

Előzmény: nagaoka, 2015-01-21 21:13:00 [1686]

Gábor,

Nem feltétlen szükséges az 576 encoder felbontás, bármennyi lehet. A frekvencia korlát 50kHz lesz. Ha jól számolom, akkor például 100-as encoderrel 4x módban az 400 impulzus per fordulat és ezzel a felbontással 7500 /min fordulatnál van az 50kHz-es korlát.

A videón sem 576 a felbontása az encodernek, hanem az encoder a motor hátsó tengelyén van és van némi lassító áttétel. Az index pedig egy tárcsa a főorsó tengelyén és azon egy résoptika.

Előzmény: ANTAL GÁBOR, 2015-01-21 20:20:00 [1685]

Balázs !
Lehet,hogy csak nekem okoz problémát,de ha Mach3-al generálok G kódot ami I, J paramétereket tartalmaz 1-2 esetben nem tud értelmezni az UCCNC .Ez főleg AutoCAD-ben rajzolt ívek esetében fordul elő
A Mach3 esetében mód van átállítani az I J-t abszolút ill. inc állapotra. Ezt a "kis kapcsolót" nem lehetne beépíteni az UCCNC-be is?

Írod hogy kisebb az Uc 100 as processzora ( és a számolási sebessége ) Azért biztatnálak , és rögtön 2 kérdés :
Feltétlenül szükséges az 576 ( körüli) encóder alkalmazása? Egy szinkron menetfúrásnál sem szoktuk őrülten pörgetni a tokmányt . ( mint tudod nálam időnként a Mach-os 96 1/ min os korlát is gondot okozott ( szerencsére annó )

Előzmény: Polgárdi Balázs, 2015-01-21 18:31:00 [1678]

Hogyan állít az UC300 új alaplapja?

Előzmény: Polgárdi Balázs, 2015-01-21 18:38:00 [1680]

Mikor kezdhetünk újra teszteleni?

Előzmény: Polgárdi Balázs, 2015-01-21 18:40:00 [1681]

OK. de én lassabban gépelek ( 1 perc a különbség )

Előzmény: Polgárdi Balázs, 2015-01-21 18:40:00 [1681]

Gábor ! görgesd Te is eggyel följebb az egeret ! (1678)

Előzmény: ANTAL GÁBOR, 2015-01-21 18:32:00 [1679]

Először az UCCNC-re szeretném teljesen befejezni a most készülő módosításokat, újításokat, majd utána a Mach3-ra is akarom módosítani a plugint. A pluginnál majd valahogy meg kell oldanom, hogy szinkron menetvágást nem tud a Mach3, csak az index jelet figyeli, de az teljesen másképp működik. Úgyhogy valahogy ki kell trükköznöm a Mach3-at, hogy működjön vele.

Előzmény: Miki2, 2015-01-21 15:35:00 [1676]

Balázs ! görgesd eggyel följebb ( is ) az egeret ! (1673)

Előzmény: Polgárdi Balázs, 2015-01-21 18:27:00 [1677]

Az UC100-asras is szeretném megcsinálni, csak annyi akadálya van, hogy az UC100-ban kisebb számolási teljesítményű processzor van. Ki kell számolnom, illetve meg kell mérnem, hogy ki bírja-e számolni a szükséges számításokat adott idő alatt. Az UC100-ra átírással a napokban fogok foglalkozni, majd beszámolok az eredményről.

Előzmény: ANTAL GÁBOR, 2015-01-21 11:40:00 [1673]

Habár megoldható lenne, hogy a főorsó forgásirányából kitalálná, hogy milyen menetet akar fúrni, de biztonságosabbnak találtuk, ha külön G kódja van a jobbos és balos menetnek is.

Előzmény: Béni, 2015-01-21 11:22:00 [1672]

Persze az még jobb lenne, ha a MACH3 alatt is működne minden új funkció az UC300-al.

Előzmény: Polgárdi Balázs, 2015-01-20 22:52:00 [1669]

Ezt várom már nagyon régen.
Na meg az esztergályos felületet.

Előzmény: Polgárdi Balázs, 2015-01-20 22:52:00 [1669]

Szerintem az eltérő forgásirányok miatt kell a külön kód.

Előzmény: Béni, 2015-01-21 11:22:00 [1672]

Balázs ! egy nagyon fontos kérdés : Írod hogy ami a videón van az Uc 300-al megy . Az Uc 100 is fogja tudni vagy az " kevés " hozzá? Az Ok hogy leköt 3 bemenetet ( A,B,Ix ) de marad még 2
( Nálam 3db UC100 működik). Kezdjek gyűjteni egy 300ra?

Előzmény: Polgárdi Balázs, 2015-01-20 22:52:00 [1669]

Miért kell a jobbos és balos menetfúrást megkülönböztetni? (Külön kód.)

Előzmény: Polgárdi Balázs, 2015-01-21 10:05:00 [1671]

Igen lesz egymenetes G33-as menetvágás, és ciklusos G76. Továbbá G33.1 és G33.2 jobbos és balos menetfúrás fixen befogott menetfúróval.

Előzmény: Béni, 2015-01-21 06:28:00 [1670]

Az esztergályosok szerintem meg lesznek elégedve.
Lesz egymenetes menetvágó ciklus?
(G32 vagy G33 stílusú.)

Előzmény: Polgárdi Balázs, 2015-01-20 22:52:00 [1669]

Többen érdeklődtetek a napokban, hogy hogyan állnak a fejlesztések. A nagy csend ellenére a háttérben folynak a munkálatok. Az új programverzió kb. 90%-os készültségben van, és sok módosítást hajtottunk végre rajta (legfőképp a belső működésben, ill. tovább lettek csiszolva a már működő funkciók is). Mutatok is két kis videót. Az elsőn egy sima szinkron filccel rajzolás (menetvágás) látható: Menetvágás-1
A másodikon pedig két szinkron menetvágás van összekapcsolva, melyeknek különbözik a menetemelkedése: Menetvágás-2
A videón látható mozgások az UCCNC program új készülő verziójával és UC300-5LPT-vel készültek, a főorsón egy 576 PPR-es inkrementális enkóderrel és Index jeladóval.

Balázs,kűldtem egy email-t.

Elfelejtettem írni, de hiába van nem resetben a gép akkor sem hajlandó az fro-t állítani, vagy legalábbis a képernyőn nem látszik, ugyan akkor mintha lassabban menne a gép, de a kiírás 90%-on marad.
Menet közben két +-al megy fel 90%-ról 100%-ra, tehát valószínű leveszi 80%-ra, csak a képernyőn marad 90%.

Előzmény: n/a (inaktív), 2014-12-18 12:55:00 [1649]

Szia,

Köszi a hibajelzéseket.
Ezt a charge pump frissítéses ref. felvételt megfogjuk vizsgálni. Igaz, minden mást is újra végig kell "zongoráznunk", illeve majd a ti segítségeteket is szeretnénk igénybevenni az új API tesztelésénél, de ahogy írtam ennek már csak Januárban fogunk a végére érni, addig is a türelmeteket kérem.

Előzmény: fektiforg, 2014-12-23 21:47:00 [1665]

Gépem UCCNC -és átalakítását ünnepek miatt hanyagolom, sokat dolgoztam vele…
Tapasztaltam pár nyűgös dolgot.
Pl. Kézikerénél tengelykiválasztásra statikus kapcsolót használok, folyamatosan frissítve
charge pump - LED jelével, sajnos kiválasztott tengelynél nem indul el a referencia pont felvétel.
Márpedig, a megoldás miatt mindig van egy kiválasztott tengely.
Másik nyűgöm - referenciára álláskor másnap már nem állt vissza a gép a próbadarabra, észre vettem nem nullázódik gépi koordináta rendszer referenciakapcsolóra álláskor.

Előzmény: n/a (inaktív), 2014-12-23 20:47:00 [1662]

Akkor nem szóltam, ekkora gyorsulásnál persze hogy látványos a dolog. Én a mechanikára értem, minden gépnél előjön, ez olyan mint egy átfúrt alkatrészbe nútmarás, 1-2 századot de nagyobbat fog vinni a maród ha bármennyi lógás is van a rendszerbe. Na de ez nem a mechanika. 300 mm/sec2 gyorsulásnál/lassulásnál látványos. Nálam a lézernél nagy gyorsulások vannak, át tud lépni a pályatervező a rádiuszos sarkokon, sima saroknál nem, ott jön a gyorsulás/lassulás rész.

Ez látványos a gépemnél mivel jobban égeti a kartont, pont a sarokba át is égeti. Ha rádiusz van a saroknál akkor nem, ott átlibben minimális sebességvesztéssel.

Előzmény: n/a (inaktív), 2014-12-23 20:40:00 [1659]

Köszi, szerintem mindenki nevében!

Előzmény: n/a (inaktív), 2014-12-23 20:47:00 [1662]

Köszi és tudom, hogy várod, én is eléggé elszomorodtam amikor kiderült a dolog nemrég.
De megfogjuk oldani és amint lehet gyártásba rakjuk az ISOBOB-ot, hogy ne kelljen már sokat várnotok rá!

Előzmény: pisti73, 2014-12-23 20:41:00 [1660]

Ja és nincsen semmilyen szíj a rendszerben, mod 2.0 fogasléces hajtás van és 25:1 bolygóműves precíz áttételház, egyiknek sincsen rugalmassága, merev hajtástechnikai elemnek tekinthető mindkettő.

Előzmény: sanyi84, 2014-12-23 16:32:00 [1657]

Sajnálom, azért már nagyon várom, hogy elkészüljön!

Előzmény: n/a (inaktív), 2014-12-23 14:54:00 [1655]

Az uccnc-nek ugyanolyan pályaoptimalizációja van mint a linuxcnc-nek, egy az egyben ugyanúgy működik.

Nem, nincsen ott semmi gondolkodás, csupán addigra áll meg a tengely a sarkon 300mm/sec/sec lassulással.

A videón a példa (a négyzetnél) igen egyszerű, sarkallatos, a két szakaszt bezáró szög derékszög, vagyis 90°, ha a feltétel az, hogy a sarokpontot érinteni kell, akkor nincsen mire optimalizálni, mert egy egyenes szakasz van, aztán megint egy egyenes szakasz úgy, hogy az első mozgás után a tengelynek meg kell állnia (mivel a sarokpontot el kell érni úgy, hogy a másik tengely nem indulhat el, különben nem lesz pontos érintés) a második szakasznál pedig a másik tengelynek el kell indulnia, fel kell gyorsulnia. És ugyebár két pont között az egyenes szakasznál nincsen rövidebb út, szóval nincs optimálisabb út. Ez egyszerű fizika, lehet bármilyen hókuszpókuszokra gondolni, de a fizikát nem lehet legyőzni, akárhogy is szeretné sokszor az ember.
Ja még annyit, hogy megnéztem a beállításokban, hogy 89°-ra volt állítva a szög aminél megáll az optimalizálás, szóval ezért is írtam most, hogy a négyzetnél a sarkon pontosan át kellett haladnia...
Majd Januárban ha lesz egy kis időm, akkor levideózzuk ugyanezt a pályát az optimalizálást kicsit áthangolva.

Előzmény: sanyi84, 2014-12-23 16:32:00 [1657]

Szia Gábor,

Hát igen, ha kicsit nagyobbra tervezünk akkor valóban kikerüljük. A gond ott volt, hogy nem tudtunk a csapdáról, hogy ki kell kerülni.
Vagyis nem tudtam, hogy ez gondot okoz nekik a gyártásnál. Régebben terveztem már olyan panelt aminél powerpad (olyan pad- ami a chip alján lévő pad-en adja át a hőt a panelra.) volt és a gyári ajánlás szerint volt rajta 12-20 via .. ez alapján meg sem fordult a fejemben, hogy egy 0805 padjén egy 0.25mm dia furat fondot okozhat.

Előzmény: ANTAL GÁBOR, 2014-12-23 16:32:00 [1656]

Ok, ez így működik sok vezérlőnél. Ha én bármit írok be a linuxcnc nek G64 P0.01 akkor sem fog durván lassulni, tartja a megadott sebességet gyorsulási görbe szerint, próbálja körív átmenettel átlépni a sok egyedi szakaszból álló íveket és bizonyos szögig működik is a dolog.

Itt viszont gondolkodott és nem fogásvételnél hanem sarkoknál. Sok szerszámgép gyártó csinál már optimalizációt a vezérlőbe, ezáltal jobban tartja a megadott sebességet. Az állandó sebesség és állandó forgácskeresztmetszet feltétele a minőségibb munkának. Én nem tudhatom van-e pályaoptimalizáció ennél de valószínű nincs. Hasonló megoldása lehet például a hurconak mint a linuxcnc nek a pályaoptimalizációra sok kis egyenes szakasznál például amit a cam programok generálnak.

A modell például szeletelve véges egyenes szakaszra oszlik, ha minden pontot mi összekötünk akkor érthetően alacsony átlagsebesség jön ki. Valami trükk van mert mindenre pozitívan hat ki a pályaszerkesztő ezirányú optimalizációs törekvése. Mind szerszáméltartamra, mind felületre, mind végrehajtási időre . Arra mozdul a cam és a vezérlők világa hogy állandó értéken tartsa a szerszámterhelést a lehető legnagyobb pontosság mellett.

Na de gondolkozzunk fizikában, ha lassulni kell és valamely tengely lóg akkor bizony a csökkenő erő miatt a lógó tengelyek el fognak mozdulni-csökken a szerszámra húzó vagy szerszámtól elnyomó erő nagysága, akkor meg aztán a vezérlő pontossága már semmit sem ér-szépen lassul, a rugóerő ami szíj miatt is lehet meg visszarántja az asztalt. Szerintem hobbinál bármely gépet bele lehet küldeni ilyenbe.

Bocsánat a sok sületlenségért.

Előzmény: n/a (inaktív), 2014-12-23 14:47:00 [1654]

Olvasom a beírást ( bár csak a felét értem ) tudom hogy az árképzésnél minden cm2 panelfelület számít de ha kicsit lazábban terveztek ( legyen a panel mondjuk 3 cm2 -rel nagyobb !! ) akkor lehet kikerülitek a csapdát. A minap vettem egy Li Po akku töltő Ic t ( I= 2.5 A ). De nem mélyedtem bele a pdf be. Hát megjött ( chipcad a forgalmazó -microchip a gyártó ). Kibontottam , megnéztem nagyítóval azután egy csipesszel szépen belehelyeztem a kukába ( mottó : 63 évesen még szeretném élvezni az életet ,ezért kerülni kell az idegeskedést )

Előzmény: n/a (inaktív), 2014-12-23 14:54:00 [1655]

Szia,

Köszönjük.
Igen, van előre és hátra lépés is sajnos.
A véglegesnek szánt verzió elkészült, viszont miután egyeztettem az SMD ültetős céggel a gyártásról kiderült, hogy még mindig kell rajta módosítani. A gond az, hogy mivel a panel meglehetősen sűrű, ezért néhány PAD-re tettünk 0.25mm átmérőjű via-t. Ez nem gondoltam, hogy problémát jelenthet, de a nyák ültetős cégnél azt mondták, hogy ők ennek a széria gyártására így nem vállalkoznak, mert szerintük átfolyhat a paszta a furatokon ami bizonytalan forrasztást okozhat. Mondjuk nem nagyon értem, hogy például power PAD-eknél akkor ez miért nem probléma, vitatkoztam is erről velük, de mivel ők ennek a gyártását így nem vállaják, ezért kénytelenek leszünk áttervezni mégegyszer a panelt.
Szóval sikerült megszivatni magunkat elég szépen.

Előzmény: pisti73, 2014-12-23 14:08:00 [1653]

Szia és köszi.

A CV sarok hiba beállítás 0.01mm volt, vagyis a sarkokon a szoftver 0.01mm hibát csinálhat maximum, ezért pontosan ki kell mennie a sarok végéig, nem kerekíthet 0.01mm rádiusznál nagyobbat.
Gondolom belátható, ha a sarokig pontosan ki kell menni, akkor az egyik tengelynek teljesen meg kell állnia mielőtt a másik elindulhatna. Ezzel a beállítással így fizikailag képtelenség gyorsabban bevenni a sarkot, mindegy, hogy linuxcnc vagy más program, a biztos korlát a föld fizikája, amit egy program sem tud áthágni, átverni.
Gyorsabb végrehajtás nagyobb tolerancia megadásával lehetséges, de ezt a teszt eredményt mértük, ezért a toleranciát alacsonyra vettük, hogy szép szögletes sarkok legyenek.
Ugyanez a helyzet az ovális esetében, ott is az alacsony tolerancia miatt lassul le a mozgás.
Ja és két darab 1.5mm-es fogás történt, szóval ahol néha megállni látszik a gép, ott van hogy a Z mélységet növeli a második fogáshoz.

Előzmény: sanyi84, 2014-12-23 13:11:00 [1652]

Boldog Karácsonyt Nektek is!

Egy kérdés azért lenne... Az UC300-ISOBOB ügyében van valami fejlemény?

Előzmény: n/a (inaktív), 2014-12-23 11:28:00 [1651]

Szuper gép, nálam úgy tűnik egyes szakaszok végén megáll a gép. Ez azért nem tetszik, de ténylegesen élőbe kellene látni, nem tudom de olyan mintha valami nem lenne kerek.

Azért egy friss linuxcnc simán "átlépi" ezeket a lassulásos szakaszokat, itt videóról is lejön.

Bocsánat hogy ezt mondom de valami tényleg nem kerek, túl nagy a tengelyek belassulása, forgácskeresztmetszet meg szerintem változik ilyenkor. Azért az össze vissza terhelést nem igen szereti a maró, de ez még talán a jobbik esete, fánál annyira nem érdekes.

Előzmény: n/a (inaktív), 2014-12-23 11:28:00 [1651]

Sziasztok!

Ezúton szeretnék Boldog Karácsonyt kívánni minden kedves fórumtársnak és némi helyzetjelentést is adni nektek!

Az UCCNC átírása sajnos nem készült el karácsonyra, még mindig dolgozunk rajta, van még mit csinálni, bár az API átírás már megtörtént és a G33 szinkron menetvágás is már működik, de még tesztelni kell.
Még vissza van a G76 megírása, illetve a menetfúrás. Az biztos, hogy csak Januárban fogunk elkészülni mindezekkel.

Addig is egy kis videó a gépről, aminek az építésével most készültünk el:

1250x2500 router gép video

Ok. Köszi, nem olyan gáz ha csak a reset alatt csinálja, holnap kipróbálom.

Előzmény: n/a (inaktív), 2014-12-18 12:55:00 [1649]

Szia,

Igen, megnéztem és tényleg van egy olyan hiba, hogy ha a reset aktív, akkor nem engedi állítani az FRO-t. Ha kiveszed reset-ből, akkor igen. Javítani fogjuk...

Előzmény: gulasoft, 2014-12-18 00:20:00 [1648]

Tegnap találkoztam vele először, hogy nem tudtam a sebességet 90% alá venni mikor állt a progi. Amikor ment, akkor már lehetett állítani, de amíg állt addig nem. Ennek mi az oka?

Igen, az 1.0033-as a hivatalos verzió, ami a weboldalunkról letöltődik.

Előzmény: Török Tamás, 2014-12-16 22:22:00 [1646]

A 33-mas van fent az oldalatokon , az a jó?

Előzmény: n/a (inaktív), 2014-12-16 11:02:00 [1637]

"...nekem is inkább sok száz hangfaldoboz előlapot kellett volna gyártanom "

Aztán,mire mentél volna vele?
A 'nagyok' se mindig tudtak...

Volt idő,hogy...azzal fűtöttem ki,több telet is!
Annyi volt belőle!:))
Volt itt a közelben,egy...VIDEOTON.
Aki nem hangfalat buherált/ragasztott össze otthon a sufniban,az....fűtött vele.:)))

Előzmény: svejk, 2014-12-16 21:50:00 [1643]

Persze hogy nem vagyunk mi roszban!!!
Csak nekem kell egy olyan verzió amivel stabilan dolgozhatok, ki is fogom próbálni a 32-est.
A fejlesztésben és hibafeltárásban pedig minden féleképpen részt veszek és jelentem az utolsó ver. két alapfunkciója ( a ref. és a hosszú ideig való munka hiba nélkül) nem mükszik!

Én egy cseppet türelmetlen vagyok....
Meg ha beválalok valamit nem utána akarok vakarózni meg kapkodni fűhöz fához.

Előzmény: svejk, 2014-12-16 21:45:00 [1642]