Az AXBB-E csak az 1.2109 UCCNC verzióval működik, ami a legutolsó development release (fejlesztői verzió). Itt letöltheted, a 3. pont a listában: http://cncdrive.hu/UCCNC.html
Ha nem látod az oldalon a linket amit mondok, akkor nyomj egy F5 gombot a böngészőben, mert akkor régi tartalmat látsz, a böngésző cache-ből szedi az adatokat, amit az F5 frissítés meg fog oldani.
A probléma az, hogy az UC400ETH nem kompatibilis az UCBB elosztó panellal. Az UC400ETH-nak ugyanis 2db normál LPT port lábkiosztású portja van, míg az UCBB-nek egy normál és egy bemeneti kiosztású portja. (2...9.pinek bemenetek) Szóval a 2 kártya nem fog jól együttműködni, legalábbis az UCBB bemeneti portján biztosan nem fognak működni azok az I/O-k, amiknek az iránya nem megfelelő.
Az UCBB az UC300ETH-5LPT-hez lett kifejlesztve és azzal kompatibilis. Az UC300ETH-5LPT vezérlőhöz max. 2db UCBB csatlakoztatható.
Az UC400ETH vezérlőhöz pedig az UCSB elosztópanel használatát javasoljuk. Max. 2 darabot lehet rácsatlakoztatni.
Sajnos nincs a közelemben olyan ember aki ilyennel foglalkozna vagy ért hozzá. (Kaposvár)
Nekem 2db UCBB1-em van. Az egyik egy régebbi javított, egy optokapu lett cserélve. A másik egy vadonat új, ami ezt a hibát produkálja. Igazából a javított is és a zsír új UCBB1 ugyan úgy működik, szóval sehogy.
Ebből az következne, hogy az UC400ETH a hibás.
Nem tudom az természetes-e, hogy az UC400ETH 24voltról működtetve tűzforró. A 2db elko forró, valamint a rajt lévő 2db proci is, annak ellenére, hogy egy alulapon van hűtve a nyák.
Én sajnos ennyit tudok megállapítani...
Tudsz ajánlani nekem az UC400ETH helyett egy másik fajta mozgásvezérlőt amivel tudom tesztelni? Laptopom van, USB és ETH csati az elérhető. Megveszem ami kell, aztán ha kiderül, hogy tényleg rossz vmi, akkor visszaküldöm cserére a forgalmazónak...
Hümm. Az én UC400 doksimban a másik az egyes port és a tapasztalat is ezt támasztja alá. Ettől függetlenül nem igazán értem a jelenséget, csak küldd el nekem azt a .pro file-t, belenéznék.
Nos, kikötöttem az enablet, es az egyes portot kötöttem be csak. Az UC400ETH-n nincs a nyákra írva, de a leírásban szerepel, hogy az egyes port a 24Volt tápfesz felől eső port.
Az UCBB1-en pedig rá van írva, hogy: CN1 normal port, erre kötöttem a szalagkábelt.
reset után is a helyzet változatlan, a motor nem vezérelhető.
UCBB1:
- 5 voltos kimenő táp kék státusz led világít - 24volt táp státuszled világít - 01-től 017-ig világítanak a piros ledek, 016-os kivételével.
UCCNC beállítás: csak AXIS X Step pin:1 Dir pin:2, mindkettő 1-es porton.
-x +x irány nyomogatásakor gyorsan villognak: 04 07 014 kialszik, vagy olyan gyorsan villog, hogy nem látszik: 08
az érdekes az, hogy egyiken sincs bekötés, és nincsenek is beállítva a programban
- kikötöm az enablet - kikötöm a második port szalagkábelét - leresetelem gyári beállításokra az UC400ETH-t jel elosztó nélkül - leresetelem UC400ETH-t csatlakoztatott jel elosztóval
- átconfolom az UCCNC programot
Ha ezek után sem ok, akkor jelentkezem a pontos bekötés leírásával, és az UCCNC profillal.
Van valami rajzod, hogy hogy van az egész összekötve? A profil file-odat (Profiles\profilneve.pro) küldd el, megnézem. Első körben annyit, hogy az Enable jelet nem szokás bekötni, a motorvezérlődön az amúgy is disable, tehát ha nem kötöd be, akkor engedélyezve van a motor. Azt ugye tudod, hogy az UCBB-nek csak az 1-es portját használhatod az UC400-zal?
Technikai segítséget szeretnék kérni, valószínűleg UCCNC programmal lehet a gondom. Nem a programnak van gondja, hanem lehetséges, hogy én értek valamit félre:)
Épülő gépem configja:
- Encoderes léptetőmotorok: 4db 86HSE12N-BC38 - Léptetőmotor vezérlő: HSS86 PA SETTINGS: 1|OFF, 2|OFF, 3|ON, 4|OFF, 5|ON, 6|ON ( = motor beállítás, valamint Dir: CCW és 1600pulse/rev) - UCBB1 jel elosztó panel, 24Volt betáp, 5voltos kimenetét használom, így nem szükséges ellenállás közbeiktatása - UC400ETH mozgásvezérlő
Hibaleírás: az UCCNC program AXIS X Y Z -t ha beállítom, a jel elosztó panel ledjeinek állapota nem fedi a valóságot, az UCCNC programban beállítottakat.
Program licenszet, és mindent a Variometrumtól vásároltam, a licenszelt program felismeri a mozgásvezérlőt, és megfelelően, hiba nélkül indul.
Mivel hiába állítom be 1,2,3 -as portra mondjuk az X motorom, 1-esre stepet, 2-esre dirt, 3-asra enabledet, és hiába kötök is mindent be a megfelelő módon, sajnos a jel elosztó nem ezeket vezérli. Így a motor nem forog.
Köszönöm ha valaki tudna segíteni, mit ronthatok el! Mit csináljak helyesen.
Eddig robot manipulátorok és jigek tervezésével, autóipari gyártókészülékek tervezésével, sortervezéssel, fröccsöntő szerszámok tervezésével, 3D nyomtatással foglalkoztam, a CNC új terület számomra, de előbb utóbb ezt is megtanulom.
:)
dezsoe | 2934
2019-03-11 17:12:12
[6633]
Szia!
Nincs javított g-kódom: a kép nem az UCCNC-ben készült, hanem egy olyan nézegetőben, ami tudja az abszolút IJK-t (G90.1). A kép jobb szélén azért van pirossal az UCCNC ikonja, mert jelzi, hogy nem fog lefutni. Ahogy Balázs is írta: minden G2 és G3-nál az I-ből kivonod az X-et, az eredmény lesz az új I, majd ugyanezt a J-Y párossal is elvégzed.
Koszi! Lehet szoftverhamisitas aldozata lettem. Na jo, nem, valoszinuleg egy regiebbi verziot toltottem le, mert nekem az nincs a listaban. Illetve a user manualt is megtalaltam a telepitett mappaban.o
A G2 és G3 körív kódoknál az I és a J inkrementális kell legyen nem pedig abszolút. Vagyis nem abszolút koordinátát kell megadnod az I és J-nek, hanem a kezdőponthoz képest hogy milyen távolságra van a középpont koordinátája az I az X tengelyen értendő, a J pedig az Y tengelyen.
át tudnád küldeni a javított G kódot, hogy egyszerűbben megértsem a hibámat, mert egyenlőre nem jövök rá a hibámra. Sehogyan sem tudom leprogramozni a koordinátákat. Előre is köszönettel
A szoftvernek van valamilyen manualja? Az uj controller eseten mit kellene kivalasztani a szotver inditasakor?
CNCdrive | 449
2019-03-11 12:21:36
[6626]
Az nem Mach3-ban lévő kitételek, hanem matematikai kitétel, hiszen ha a kezdő és a végpont ugyanaz (teljes kör), akkor a rádiusz információ megadása végtelen számú kör középpontot és így végtelen számú kört definiál, más szóval meghatározhatatlan a kör. Félkört lehet marni, viszont a rádiusz tolerancián belül kell lenni a sugárnak ami a rádiszból ered. Ha a kezdő és a végpont távolabb van mint 2xradius, akkor már nem definiálható a kör, ismét matematikai/geometriai probléma. Illetve UCCNC-ben van egy arc radius tolerance paraméter amivel be tudod állítani, hogy némileg nagyobb távolságot elfogadjon, ilyenkor átszámolja a rádiuszt, ha távolabb van a vég és kezdőpont, viszont ilyenkor értelemszerűen torzul, nagyobb lesz a kör. Ami vagy gond, vagy nem. A rádiusz tolerancia paraméter éppen ezért lett bevezetve, mert a CAM programok gyakran kerekítési hibák miatt egy picivel elszámolják a rádiuszt és hogy ez ne generáljon matematikai hibát, definiálhatatlan félkört.
Ahogy Dezsoe is írta, az UCCNC-ben szabványosan működik, a Mach3-ban pedig szabványtól eltérően is tud működni, ahogy te is próbáltad abszolút megadási módban. UCCNC-ben csak az RS274NGC szabványnak megfelelően relatív módban van lehetőség az IJK megadására. A CAM programban úgy kell beállítani a post processort, hogy relatív módban generálja ezeket.
Valóban nincs külön kiemelve, hogy csak a relatív IJK és a sugár (R) működik, viszont az le van írva, hogy ahol lehet, ott az RS274 szabványt követi a program. Az RS274-ben pedig nincs benne az abszolút IJK, ezeket egyértelműen a kezdő pont ofszetjeként említi. A Mach3-ban létezik a G90.1 (abszolút IJK) és G91.1 (inkrementális IJK), amivel át lehet kapcsolni és ezt a beállításoknál meg is lehet határozni, hogy melyik legyen az alapértelmezett.
de a kézikönyvben ez hol van leírva, hogy az I és J értékét relatívban kell megadni? A Mach 3 simán kezeli az abszolút koordináta rendszert. A kontúr tényleg ez lett volna. Ha az R értéket adom meg, akkor lehet teljes kört így marni, mert a Mach 3-ban fél és egész kört így nem lehetett készíteni?
A probléma abból adódik, hogy a körközéppont megadásnak legalább 4 módja van. (Ebből 2 módszer az elterjedt.) A kódod az abszolút megadás példája, amíg az UCCNC a kezdőponthoz relatívat szereti. (Kézikönyvben erről nem találtam említést.)
Ha a mellékletben látható kép a cél, akkor a kód generátorát kell rábeszélni, hogy ne használjon abszolút I és J értéket az íveknél. (Szabvány szerint az I, J és K az aktuális pozícióhoz képest relatív.) Ezt a legtöbb posztprocesszor tudja kezelni, illetve lehet még sugár mód is, ahol nem I, J, K a középpont, hanem R a sugár.
most állok az előtt, hogy szeretnék vásárolni egy UCCNC licencet, és első körben feltelepítettem a demo verzió módban. Betöltöttem néhány Mach3 alatt futó programot, amelyek ott jól futottak, és a G2, és G3 parancsok teljesen fordítva működnek. (ahol csak kis rádiuszt kellene csinálni, ott a másik irányba a kört csinálja meg) Lehet, hogy az én hibám, de nem értem.
Nem, nem lenne bonyolult, sőt eredetileg úgy volt megcsinálva. A probléma az vele, hogy a régi webáruházat szereti nagyon a Google, az újat meg nem. Ennek az eredménye az lett, hogy lecsúsztunk a találati listában a google-ön amikor beüzemeltük az új webáruházat, ami végzetes probléma hiszen a vevők nem találnak meg bennünket, ha hátul kullogunk a találatok közt. Ezért csináltuk meg egyelőre úgy ahogy most van, hogy ha beraksz valamit a kosárba, akkor átirányít az új webáruházba. Nem egy túl elegáns megoldás, de egyelőre így tudtuk csak megoldani.
Egy feliratot majd megpróbálok felrakni a főoldalra, hogy át tudjanak menni a vevők rögtön egy link-el. Illetve amint tudjuk megpróbálunk majd valami jobb megoldást találni erre a problémára.
Azt bonyi lenne megoldani, hogy a régi CNCdrive-os weboldalak átirányítsanak egyből az új aktuálisra? Vagy legalább figyelmeztetés lenne rajtuk, hogy "Van mááásik!.."
Reklámozgatom mindenkinek ezt új vezérlőt, de nem találják meg a magamfajta lúzer mókusok.
Van itt segítség, csak kérdezned kell. A válaszhoz viszont kevés pár fotó, konkrét típusok kellenek és az, hogy mit szeretnél elérni. Az látszik, hogy egy UC300ETH_5LPT és egy UCBB van a vezérlés oldalán, de a másik oldalból semmit nem tudok kinézni.
Üdv! Olyan kérdéssel (kéréssel) fordulnék hozzátok, hogy van e köztünk olyan uccnc felhasználó aki vagy Komárom Esztergom Megyében, vagy Győr Moson Sopron-ban tartózkodik és megszánna egy kis segítséggel, akár telefonon vagy ami még jobb lenne személyesen tudna segíteni!
Elértem a gépítésének abba a szakaszába, ahol ismeretlen területre értem! Sajnos nem vagyok olyan jártas az uccnc és a servo vezérlés összeállításában mint amennyire ti! Ezért is lenne jó ha találnék egy segítőkész kollégát akinek igénybe tudnám venni a szakértelmét, és a környéken tartózkodik! Én Komárom Esztergom Megye, Ászáron vagyok fellelhető, aki esetleg készséget érez magában kérem jelezzen vagy itt a fórumon, vagy megadnám az elérhetőségem szívesen visszahívom! Köszönöm a figyelmet!
Tel:06203260054 Lengyel Tamás Pár kép a jelenlegi állapotról
CNCdrive | 449
2019-03-07 18:34:28
[6608]
Szia,
Igen, jól gondoltad és sajnos ilyenekkel kell egyre többet foglalkoznunk mostanában (régen nem nagyon voltak ilyen gondok), ami már csak amiatt sem jó dolog, hogy az ilyen vírusirtó bug-ok más programoknál is ugyanúgy problémát okozhatnak és egy átlag felhasználó nem is tudja eldönteni hogy most akkor mi van és mit kéne tennie.
Hmm, ezek szerint egyre "jobb" lesz ez a Defender. Nemrég a régi 1.20xx verziókra kezdett vak-riasztani, amit megoldottunk némi extra nem használt kód beiktatásával az UCCNC.exe-be. Akkor valami Zpevdo vírust riasztott. Akkor ezek szerint most meg valami másik vírust vél felfedezni... Na, én ezért nem használok se antivírust, se Defendert már vagy 10 éve.
Egyébként az UCCNC zárt környezetben kerül lefordításra forráskódból minden kiadásnál. Zárt környezet alatt azt értem, hogy egy olyan PC-n fordítom le, amin semmi mást nem csinálok, semmi nincs rajta telepítve sem és internet sincs rajta, ráadásul le is van butítva, hogy csak a Visual Studio-t és néhány más a fordításokhoz szükséges programot tudjon futtatni. Szóval abszolút kizárt, hogy vírus kerüljön a kiadásokba.
Egyébként most gyorsan megnéztem Virustotal-al és az 1.2108-ra ma már valóban vírust jelez a Microsoft (Defender) vírusirójával. Legutóbb lefuttattam akkor még nem volt semmi gondja. Megnéztem az 1.2109-es verziót is és arra nem jelez semmit. Szóval gyors megoldás lehet az 1.2109-es verziót használni, bár egyik sem vírusos, de ha gondot okoz a Defender...
Sziasztok, Defender mai riasztása : Trojan:Win32/Azden.A!cl és azt mind az uccnc re gondolom most frissült és ezt dobta
azt írja hogy Érintett elemek: file: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\CNCdrive\UCCNC software\UCCNC.lnk file: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\CNCdrive\UCCNC software\UCCNCplasma.lnk file: C:\UCCNC\UCCNC.exe file: C:\Users\Public\Desktop\UCCNC.lnk regkey: HKLM\SOFTWARE\Wow6432Node\MICROSOFT\WINDOWS\CURRENTVERSION\UNINSTALL\UCCNC_is1 startup: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\CNCdrive\UCCNC software\UCCNC.lnk startup: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\CNCdrive\UCCNC software\UCCNCplasma.lnk uninstall: HKLM\SOFTWARE\Wow6432Node\MICROSOFT\WINDOWS\CURRENTVERSION\UNINSTALL\UCCNC_is1
remélem semmi komoly csak a win defender baromkodása, mert pár napja nem telepítettem semmi warez-t csak olyat ami digitálisan aláírt nagy gyártóktól származik...
De azért kíváncsi lennék másnak is beugrott e ilyen... R.
CNCdrive | 449
2019-03-07 07:20:50
[6602]
Szia Svejk,
Azt nem tudtam, hogy a világ végén is szoktál járni, ahol még a 4G és a wifi sem jár.
Igen, annál a verziónál változott .NET 4.0-ra és az 1.21xx széria még mindig csak teszt verzió, bár remélhetőleg hamarosan át tud majd menni hivatalos kiadásba.
A .NET 4.0 egyébként fut ugyanazokon az OP rendszereken mint a .NET 2.0, vagyis Windows XP,8,8,8.1 és 10. Sőt Windows 10.-en alapból telepítve van a .NET 4.x keretrendszer, ahol az x helyén bármilyen szám állhat. Ebben az a jó, hogy az x helyén bármilyen szám van az kompatilis az UCCNC-vel. Szóval Windows 10-en egyáltalán nem kell telepíteni a .NET framework-öt, mert alapból benne van, az OP rendszer része. És még egy jó dolog, hogy a .NET 4.0 képes .NET 2.0 dll-eket is betölteni és futtatni, ezért a régebbi UCCNC pluginok is gond nélkül futnak az új .NET 4.0 alapú UCCNC-vel. Na és egy harmadik jó dolog, ami ugyan kevesebb embert érint, hogy .NET 4.0-ban lehet hozzá plugin-t fejleszteni, ami azért jó, mert több library áll rendelkezésre, például a LINQ, ami a .NET 2.0-ban még nem volt és egy sok esetben hasznos könyvtár.
Bocs mindenkitől! (Amikor a hülye okoskodik.) Benéztem a hosszkorrekciót a sugár korrekcióval. Nem használom, ezért nem eléggé automatikus. Szóval a hozzászólásom ezen része tárgytalan.
Viszont a többi részén talán érdemes elmélázni, mert a Cam programok valóban hibáznak.
Mivel igen kis átmérőjű szerszámról van szó, és szerszám sugár korrekciót a jelenlegi tudásom szerint még nem hajt végre az UCCNC, az idézett mondatban szereplő munkadarabot érdemes lenne tolómérővel ellenőrizni. Ez szemmel nem feltétlenül észrevehető eltérés, azonban más esetben okozhat még meglepetést.
Zsoltyfm [6497]-es hozzászólásában közölt progiban van egy érdekes mondat:
N160G00G43Z5.000H1
Arra gondolok, hogy a Cam programok által generált G kódok bizonyos feldolgozó gépekre vannak optimalizálva. Amikor Cam-elést tanultunk, feladat volt, hogy a feldolgozó gép (Pl.: Fanuc akármi marógép) szempontjából nézzük át a teljes programot, mivel a Cam-elés elején hiába állítottuk be az adott gépet, vagy a leginkább hasonlót, a generált kódban minden alkalommal voltak hibák. Tehát a Cam programok által létrehozott kódokat szerintem nem szabad tökéletesként kezelni. Legrosszabb esetben olyan kódot ír be, ami mást jelent az egyik gépen, mint a másikon, és ilyen esetben szerszámtörés a vége. Természetes, hogy minden mindennel nem lehet 100%-ig kompatibilis.
Szóval az idézett mondatot jó esetben figyelmen kívül hagyja az UCCNC, de ha nem tévedek arra mindenképpen utal, hogy nem optimális a Gkód. A többi részét is érdemes talán átnézni. Vagy ha nem, akkor is érdemes tudni a jelenségről.