A 1.2047-be nem tudjuk belerakni, mert a folyamatos fejlesztés miatt már 1.2102-nél tartunk, és visszafelé nem dolgozunk (nem azért, hogy bosszantsunk, hanem mert átláthatatlan lenne). A tengelyenkénti Current On/Off már elkészült pár tesztverzióval ezelőtt, szóval az is benne van már.
Direkt megnyitottam a 20.47 et és rákukkantottam mielőtt föltettem volna a current es kérdést . Hát nem láttam . Most hogy írod rájöttem hogy lenni kell egy korábbi ( eggyel kisebb számú ) teszt verziónak . Biztos van ha ez kettesre végződik . Pont ettől félek , teszt verziót teszt verzió követ és egyszer eléri azt az evolúciós állapotot amikor már hivatalossá válik . No akkor szoktam én megnyugodni
Nem tudom, nálam megy a letöltés, most próbáltam. Félig mondom csak viccből: XP-t, ugye, már nem használunk, a Win7-ben a frissítések között ott van, Win8-tól be van építve.
Nagy falat lesz ez nekem és jobban is szeretem a teszt verzió helyett a hivatalosan kiadottat .
Nem tudod megcsinálják a jelzett hiba javítását " Menetfúrás vagy -vágás néha kihagyta a szinkron mozgást." a hivatalos 20.47 re is ? Szóban mintha mondtad volna hogy a tengelyenkénti current on/ off is benne lesz . Sikerült beletenni és csak a felsorolásból hiányzik?
Valami ok miatt nem tudom letölteni a 1.2047 verziót és ezt az újat sem. A letöltés legvégén megáll. Ugyanez van a linkről és közvetlen a helyről is. Mi lehet a megoldás?
Más: Talán érdemes lett volna belinkelni a net 4 letöltőhelyét is az egyszerűsítés érdekében.
A program mostantól nem .NET 2.0, hanem .NET 4.0 keretrendszerben fut. Ez azt jelenti, hogy már nem a .NET 2.0-t (vagy 3.5-öt) kell hozzá telepíteni, hanem .NET 4.0-t, vagy azzal kompatibiliset. A .NET 4.0 továbbra is be tudja olvasni a .NET 2.0 alá írt pluginokat, így azok továbbra is használhatók maradnak. Az összes .NET 4.x verzió futtatja a 4.0 alá írt programokat, így ha a gépen az éppen aktuális 4.7-es verzió van, akkor az rendben is van. Windows 8-tól felfelé ez alapból a rendszer része, így nem is kell vele foglalkozni, Windows 7-re lejön a frissítésekkel, XP-re fel kell telepíteni.
Plugin fejlesztőknek csak annyit kell tenni, hogy a cél .NET verziót át kell állítani 4.0-ra a Visual Studio-ban a projekt tulajdonságainál. Természetesen, ehhez Visual Studio 2010 vagy újabb verzióra van szükség.
A .NET 4.0 keretrendszer használata azt is jelenti, hogy sokkal több harmadik féltől származó könyvtárat használhatnak az új plugin-ok.
- Új: kapcsoló, hogy a G41/G42 a sarkokon ívben forduljon - G91 inkrementális mozgásokkal probléma volt bekapcsolt szerszámsugár-kompenzáció esetén. Javítva - Íves Z mozgás hibás volt G91-ben, ha makróból futott és a Z-nek nem volt érték megadva. Javítva - Új: Részletes szerszámtábla ablak - Új: Szerszám hossz és átmérő adatok beíráskor azonnal érvényre lépnek - Új: Szerszámtábla mentése gomb (Save tooltable) - Új: Kapcsoló, hogy a programból kilépéskor automatikusan mentse a szerszámtábla adatait - Új: G10 L1 R paraméter, ami a szerszámtáblába a megadott szerszám sugarát viszi fel g-kódból - Frissített Console plugin - Új: a megjelenítési beállításoknál kapcsolható, hogy betöltéskor alaphelyzetbe álljon-e a szerszámpálya nézet - Új: Additemtolistbeginning függvény a plugininterface-ben (státusz ablak írásához kell) - Menetfúrás vagy -vágás néha kihagyta a szinkron mozgást. Javítva - Getcurrgcodelinetext néha nem az aktuális sor tartalmát adta vissza. Javítva - Új: Getcurrentgcodelinenumber függvény makróban és pluginban az aktuális g-kód sor számát adja vissza - Jog panel érzékelés kikapcsolása, ha valamilyen gyermek-ablak van fókuszban, így nem tűnik el az ablak, ha az egérrel a jog panel felé mennénk
Sziasztok! A segítségeteket szeretném kérni, bekötéssel kapcsolatban A CNC gépemhez vásároltam egy uc300ETHt amit a léptetőmotor vezérlőhöz szeretnék csatlakoztatni (elötte cncusbm volt) Mellékelek egy képet amin megjelöltem a feltételezett bekötést. a kék "vezetékben" nem vagyok biztos. Segítségeteket előre is köszönöm!
Bozso777 | 529
2018-01-24 07:22:30
[4992]
Veri postprociba az még sikerült, hogy az M10-M11 beleírjam, de a tudásom kB ennyivel ki is merült :D
Találtam egy beállítást, ami okozhatja a problémádat. A Probing Altitude beállítás nálad 0, ami nem jó, mert a felületről indítaná a mérést. Ha pontos a mérőkéd, akkor ilyenkor már bejelez. Kicsit meg kéne emelni, én pl. 2mm-ről indítanám.
"D Ha pl nem marógép lenne hanem könnyi kis lézergép, durva gyorsításokkal, máris jobb eredményt hozna."
Erről beszélek régóta...:) Ott kezdődnek a lézeres csalódások, mikor a súlyos(lézerhez kimondottan túlsúlyos) hidakra, úgymond a marómotor mellé, alternatívaként fölkerülnek a kis 2-3-5W-os lézerfejek.
Igazad van.Ha kicsit tovább menne, mint pl a képégetésnél, máris megoldódna ez is...persze ezt hogyan lehetne megoldani azt nem tudom :D Ha pl nem marógép lenne hanem könnyi kis lézergép, durva gyorsításokkal, máris jobb eredményt hozna.
Korrekt! De, azért látszik a csíkok végén, hogy ott le kellett lassítania a tengely(ek)nek: egy picit határozottabb lett a végük. Talán azzal lehetne elkerülni, hogy a lézer kikapcsol és a tengely megy még egy picit, hogy már kikapcsolt lézerrel lassítson le. (Persze, ez már megint szőrszálhasogatás, csak most az én részemről... )
Nem feltétlenül kll álljon az egyik tengely, erre elég jó példa volt mikor egy 360°skálát égettem vele gkódból.Mivel a 360 vonalból csak 4 vonalnál van 1 tenglymozgás elég jól mutatja megy ez több tengellyel, gyors irányváltásokkal is...természetesen M10-M11 kapcsolgatja. Videó nem túl jó kamerával készült, de a lényeg látszik...alul az elkészült skáláról kép.
Sajnálom, hogy engem nem tud lázba hozni, hogy a 0 az a valóságban hány ms. Nem hiszem, hogy egyedül vagyok ezzel. Gondolom nem is azonos idő minden gép esetében(uc.../pc). Én is szőrszálhasogatásnak érzem.
dezsoe | 2934
2018-01-22 22:28:12
[4983]
Értem! Erre a Balázsok tudnának autentikus választ adni, de véleményem szerint az X megállásakor illene végrehajtódnia, mivel a cél az, hogy a két másik sor végrehajtása között kapcsoljon. Egyébként, az X5 még az egyszerűbb, mert pl. egy Y10 esetében már bejönnek a buliba a CV és exact stop beállítások és ezek paraméterei. Szerencsére, ez ritkán fordul elő, mivel alapvetően arra lett kitalálva, hogy egyik tengely áll, a másik pedig megy egyenletesen és közben a lézer megfelelő helyen és időben kapcsoljon ki vagy be. Ritkán szokás cikkcakkban lézerezni, gondolom én.
Én azért egyszer bemérném, hogy az "azonnal" az mit takar a valóságban, mert nyilván nem nulla.
Van egy olyan teszt kód listám, ami csak százezer M3,M5-ből áll. Kérdés: mennyi idő alatt futna ez le UCCNC esetén? Ebből már szépen meg lehet állapítani a rendszer teljes G kód feldolgozó rendszerét.
Sajnos a matematikában a nulla veszélyes szám, ha komolyan vesszük. Így azt gondolom, a műszaki életben is ha egy adat megadható, beírható, akkor annak a valóságban is annak kell lenni, mert egyébként csak szép csili-vili, de nem igaz, azaz virtuális valóság szerepel itt tényként. Szerintem módosítsátok, és ne lehessen nullát megadni, csak annyit amit tud is a vezérlőprogram rendszer.
Az X5 esetre mi a magyarázat, ilyenkor nem igaz a gyors működés az M10, M11-re?
Az M3/4 delay paraméterrel 1ms felbontással késleltetés adható meg, azaz amikor a program oda ér, hogy akkor most be/ki kéne kapcsolni az M3/4-et, akkor elkezdi mérni a megadott időt. 0-nál értelemszerűen nem várakozik, hanem azonnal kiadja a jelet.
Ez már egy kicsit szőrszálhasogatás... De ezek a delay értékek nem is erről szólnak, hanem arról, hogy az M3/M4 stb. kiadása után mennyit várjon a program, mielőtt tovább menne. Ez ugyanis arra való, hogy legyen a motornak ideje felpörögni vagy leállni.
Ezt értem, és tudjuk is, bár itt is van azért némi gond, mert lehetséges olyan kód, amikor irányt kell váltani, pl. ha N130-ban ez lenne: G1 X5
De igazából nem is ez az én gondom, hanem ha a delay 0 is lehet, akkor ez azt jelenti, hogy 0 idő alatt az M3/M5 is reagál, ami nyilván nem lehet igaz, ha a kódlistát élesben futtatjuk. Gondolom van ennek a kódnak végrehajtási ideje, és az biztos nagyobb mint nulla. Akkor lenne korrekt az ablak, ha nullát nem enged ideírni, hanem csak annyi időt, amit tényleg tud a rendszer, pl. 10 mikrosec.
Ahogy Balázs a lézer topikban leírta, az M3/M4/M5 végrehajtásához ki kell ürülnie a mozgáspuffernek, tehát a tengelyeknek meg kell állniuk, míg az M10/M11 az adott mozgásokhoz szinkronizálva fog végrehajtódni. Legyen három sor egymás után:
N10 G1 X10N20 M3 N30 G1 X20
Az N20-ban az M3 akkor fog végrehajtódni, ha az N10 mozgás elkészült, a tengely megállt. N30-ban újra fel kell a tengelynek gyorsulni.
N110 G1 X10N120 M10 N130 G1 X20
Ebben az esetben az N120 sorban a kapcsolás a tengely lassítása nélkül, X=10 pozícióban fog megtörténni, míg a tengely mozog tovább az N130 szerint.
Köszönöm a választ. Az viszont meglepett, hogy lehet nulla is, hiszen akkor mitől lassú kapcsolásúak ezek a kódok? Nincs itt valami ablakocska adat és valóság közti ellentmondás?
A lézer topikban nem kaptam választ arra, hogy az UCCNC esetén az M3, M5 "delay" ablakainak mi a beállítható minimuma? Nulla is lehet? (Lézer topik 14169 setup kép.)
2018-01-24 20:32:33
és jobban is szeretem a teszt verzió helyett a hivatalosan kiadottat . 
No majd csak megbirkózunk vele. 
De, azért látszik a csíkok végén, hogy ott le kellett lassítania a tengely(ek)nek: egy picit határozottabb lett a végük. Talán azzal lehetne elkerülni, hogy a lézer kikapcsol és a tengely megy még egy picit, hogy már kikapcsolt lézerrel lassítson le. (Persze, ez már megint szőrszálhasogatás, csak most az én részemről... 
Szerencsére, ez ritkán fordul elő, mivel alapvetően arra lett kitalálva, hogy egyik tengely áll, a másik pedig megy egyenletesen és közben a lézer megfelelő helyen és időben kapcsoljon ki vagy be. Ritkán szokás cikkcakkban lézerezni, gondolom én. 