http://screencast.com/t/co0bmsBmR
Ajoin tollasen pyöritys-akseli työstön.
Z oli lopussa 1 millin ylempänä kuin alussa,eli siitä tuli ikäänkuin spiraali.
Kysymys kuuluu että onko vika Cs labsin laatikossa vai Deltan servoissa ja ohjaimissa,vai Mach3?
NEUVOKAA MITEN TÄTÄ ONGELMAA PITÄISI SELVITTÄÄ.
Tilanne on se että jotain pitää ruveta kokeilee.
ONKO SE>> Servon vaihto >> Ohjaimen vaihto>>CSLABSin vaihto>>CSlabsiin firmwarepäivitys>> postan vaihto>>Mach3 vaihto
Mikä näistä ensin vaiko kaikki??
Pikku tarkennus: simulaatio menee videon mukaan ok mutta reaalimaailmassa akselit ei olekaan siellä missä pitää ?
Ensin pitää tarkastaa g- koodi. Oletettavasti työstettävän renkaan keskipiste on pyöritysakselilla, siltä ainakin simulaatiossa näyttää. Jos siis g- koodin alussa ja lopussa on sama Z niin mallinnus ja post on todennäköisesti oikein ja vika on laitteen päässä. Jos vika on jo g- koodissa niin silloin mallinus tai post voi olla syyllinen.
Jos Z- akselia ajaa samalla nopeudella kuin ohjelmassa useita kertoja ylös- alas niin pysyykö paikka silloin vai vaeltaako se ?
Jokin saattaa myös olla löysällä (mitä ikinä servon ja liikkuvan massa välissä onkaan, akselikytkin, hihna, kuularuuvi, jne).
Machista ja cslabsista ei ole kokemuksia mutta jos eri palikat pystyy testaamaan yksi kerrallaan mahdollisesti käyttäen toisen akselin servoa tms niin syy pitäisi löytyä.
Mä nyt ylipäänsä lähtisin koneen testauksessa ja pystytyksessä siitä että heittäs tollaset 3d softat ja cam:t jordaaniaan ja hakkais idioottivarman testikoodin käsin alkumäärittelyt ja vaikkapa exel:llä generoisin 1000rivin pistejoukon ja näistä liikevariaatio jossa tiedetään laskennallisesti alku ja loppupiste.
Ensin testaus akseli kerrallaan jostakin inhimillisestä nopeudesta ja lisäten nopeutta kunnes jotain ongelmaa alkaa ilmetä. Ja sitten vasta sirtyisi useamman akselin ajoon.
Idioottivarmasti kun tietää että mekaniikka skulaa niin siitä voi jatkaa softan ihmettelyä
Kaikki ongelmat kun kerää yhtäaikaa klimpiksi cad, cam, post, mach, servot, cs labs, mekaniiikka, käyttäjävirhe etc etc niin on siinä suo seuloa se neula..
Tein uuden koodin ja tossa laitan kuvan ja simun ja gkoodin.
Tossa kuvassa näkyy se 1mm pykälä,eli se nousee millin ylöspäin.
Ihan kuin se saisi jostain komennon tehdä nousu kierroksen aikana.
Siinä on suunnilleen 3000 riviä,eli ei ole iso nousu per steppi,mutta ei tollasta saisi olla.
Simulaatio>>http://screencast.com/t/RXQ39iCc
Lainaus käyttäjältä: Isto - 22.01.15 - klo:19:06
Pikku tarkennus: simulaatio menee videon mukaan ok mutta reaalimaailmassa akselit ei olekaan siellä missä pitää ?
Ensin pitää tarkastaa g- koodi. Oletettavasti työstettävän renkaan keskipiste on pyöritysakselilla, siltä ainakin simulaatiossa näyttää. Jos siis g- koodin alussa ja lopussa on sama Z niin mallinnus ja post on todennäköisesti oikein ja vika on laitteen päässä. Jos vika on jo g- koodissa niin silloin mallinus tai post voi olla syyllinen.
Jos Z- akselia ajaa samalla nopeudella kuin ohjelmassa useita kertoja ylös- alas niin pysyykö paikka silloin vai vaeltaako se ?
Jokin saattaa myös olla löysällä (mitä ikinä servon ja liikkuvan massa välissä onkaan, akselikytkin, hihna, kuularuuvi, jne).
Machista ja cslabsista ei ole kokemuksia mutta jos eri palikat pystyy testaamaan yksi kerrallaan mahdollisesti käyttäen toisen akselin servoa tms niin syy pitäisi löytyä.
Jonne laitto koodin pätkän jossa liike oli Z-10, Z0,, ajoin sen 1000 kertaa
ja toinen testi jossa oli myös X-10 Y-10 Z-10,, X0 Y0 Z0 lisäksi,sen ajoin 1500 kertaa
Muutosta Z korkeuteen ei tapahtunu ollenkaan,eli 2500 kertaa, eikä muutosta.
Konkareille kysymys ,,mistä tää kertoo, sen z ongelman suhteen.
Eli voiko tän perusteella eliminoida joitain syitä pois.
PS
Tuo mittaus on tehty tönärillä, mutta mitä tässä testissä pitäisi olla servo-ohjaimen päädyssä liikkuva lukema?
Näyttäis kuvan perusteella olevan 1mm heitto b-akselilla täyden kierroksen lopussa, kokeile ajaa sama koodi muutettuna niin,ette z-akseli nouse ollenkaan ja pelkkä b-pyörii (eli vähän niinku sorvaisit)
Jotenkin tuntuu ettei se vika voi olla kuin g koodissa :-\
Ja se ei voi oikein tulla muutenkuin että camissa nollapiste on poissa keskiöstä ja koneella se on keskellä.
Oliko sitä g koodia nähtävillä jossain?
Lainaus käyttäjältä: Hiekkaranta_92 - 23.01.15 - klo:13:05
Jotenkin tuntuu ettei se vika voi olla kuin g koodissa :-\
Ja se ei voi oikein tulla muutenkuin että camissa nollapiste on poissa keskiöstä ja koneella se on keskellä.
Oliko sitä g koodia nähtävillä jossain?
Siinä samassa jossa on tuo kuva
Simulaatiossa muuttuu sekä x, y, z koordinaatit. G-koodissa on vain yksi X lauseke ja loput yz tasossa..
Lainaus käyttäjältä: ttontsa - 23.01.15 - klo:17:20
Simulaatiossa muuttuu sekä x, y, z koordinaatit. G-koodissa on vain yksi X lauseke ja loput yz tasossa..
Siitä madcamin simulaattorin x, y, z, 4 ja 5 akselien lukemat näyttää mitä sattuu,se rataviiva pitää paikkansa,
Eli ei ole eka simulaattori,jossa kaikki ei ole yksi yhteen todellista,jos nyt sitten tätä tarkoitit.
Olisi mielenkiintoista kuulla kommentteja sen Z ylös alas testin tuloksista, josta kirjoitin tossa aiemmin,, että onko ne korrekteja vai ei,,ja sen myös että mitä kuuluu olla servo ohjaimen päässä olevat lukemat.
Täytyykö ne pysyä samana vai saako ne vaihtua?
Lainaus käyttäjältä: Kai - 23.01.15 - klo:19:08
Siitä madcamin simulaattorin x, y, z, 4 ja 5 akselien lukemat näyttää mitä sattuu,se rataviiva pitää paikkansa,
Eli ei ole eka simulaattori,jossa kaikki ei ole yksi yhteen todellista,jos nyt sitten tätä tarkoitit.
?
eikö akseleita ja nollapisteitä saa vastaamaan todellisuutta? Vähän kuin ajaisi autokoulussa vasemmanpuoleista rallisimulaattoria käännetyllä ratilla ja seuraavaksi lähdettäisiin liikenteeseen...
tossa sun simulaattorivideossa http://screencast.com/t/RXQ39iCc siis muuttuu sekä x y ja z koodit tossa txt tiedostossa ei ole kuin 1 ainut X käsky. Mistäs simulaattori X käskyt taikoo?
Sähläsin siihen väärän editorin
Tässä on oikea.
sorry, siis tässä simulaatiossa (vähän puhelimen kanssa veivaaminen tuskallista linkityksen kanssa):
http://screencast.com/t/co0bmsBmR
etenkin ton x arvon juoksu ihmetyttää kun tossa txt tiedostossa ei ole kuin yksi x-rivi
Lainaus käyttäjältä: Kai - 23.01.15 - klo:15:08
Siinä samassa jossa on tuo kuva
Ota silmä käteen ja katso :DD
Noniin koodissa ei pitäs suurta vikaa olla kympin luokkaa se keksii arpoa jostain syystä ztaa, mutta lienee meshin tarkkuus asetuksista kiinni...
Minun järjen mukaan tuota ei pitäisi tapahtua... no pari juttua mitä kannattaa kokeilla
-kokeileppa laittaa tuola alussa tuo G40.1 -> G40.0
-tarkista terän kiinnitys, jos joku kartioholkki niin kireämälle... Terä voi tollasessa työstössä vetää itseään pidemmäksi, kun tulee äkillisiä kuormituksen muutoksia terälle.
Lainaus käyttäjältä: ttontsa - 23.01.15 - klo:00:26
Mä nyt ylipäänsä lähtisin koneen testauksessa ja pystytyksessä siitä että heittäs tollaset 3d softat ja cam:t jordaaniaan ja hakkais idioottivarman testikoodin käsin alkumäärittelyt ja vaikkapa exel:llä generoisin 1000rivin pistejoukon ja näistä liikevariaatio jossa tiedetään laskennallisesti alku ja loppupiste.
Ensin testaus akseli kerrallaan jostakin inhimillisestä nopeudesta ja lisäten nopeutta kunnes jotain ongelmaa alkaa ilmetä. Ja sitten vasta sirtyisi useamman akselin ajoon.
Idioottivarmasti kun tietää että mekaniikka skulaa niin siitä voi jatkaa softan ihmettelyä
Kaikki ongelmat kun kerää yhtäaikaa klimpiksi cad, cam, post, mach, servot, cs labs, mekaniiikka, käyttäjävirhe etc etc niin on siinä suo seuloa se neula..
Oletko tehnyt tuon.! Alku ja loppu piste on oltava sama.
Tai voit vaan helposti toistaa saman ajon uudelleen irroittamatta jo työstettyä kappaletta, senkin voi sitten vetää muutaman kerran läpi ja tutkia
millaista siirtymää tulee.
En tiedä noista työstö hommista juurikaan mitään mutta sen olen oppinut jos kokeneemmat viitsii neuvoa heitä kannattaa nöyränä kuunnella.
Minä koittaisin jollain muulla camillä tehtyä koodia ,mutta kun mulla ei ole sellasta camia joka tajuaisi G-koodia.
Rolandin omaa koodia on turha tarjota,niitä camejä löytyy.
Kun tolla Madcamillä niitä ratoja tulen tekemään niin,sen takia teen sen radan sillä.
Jos joku tekisi tollasen pyöritys akseli koodin niin voisin koittaa, tekeekö saman virheen ,kun koodi on tehty jollain muulla camillä.
Kai
Lainaus käyttäjältä: Hiekkaranta_92 - 24.01.15 - klo:00:16
Ota silmä käteen ja katso :DD
Noniin koodissa ei pitäs suurta vikaa olla kympin luokkaa se keksii arpoa jostain syystä ztaa, mutta lienee meshin tarkkuus asetuksista kiinni...
Minun järjen mukaan tuota ei pitäisi tapahtua... no pari juttua mitä kannattaa kokeilla
-kokeileppa laittaa tuola alussa tuo G40.1 -> G40.0
-tarkista terän kiinnitys, jos joku kartioholkki niin kireämälle... Terä voi tollasessa työstössä vetää itseään pidemmäksi, kun tulee äkillisiä kuormituksen muutoksia terälle.
Ton näköset mesh asetukset>>http://screencast.com/t/qI70cA1H6Y4
Et sitten lukenut noita edellisiä juttuja.Lue uudelleen!
Et tarvii mitään cam ohjelmaa testataksesi konetta.
Toistoa:Aja viallista akselia edestakaisin työkierto, nopeuttaen ja kuormittaen joka kerran jälkeen ja katso paikoituksen toistotarkkuus ,muuta keinoa ei ole.
Siihen riittää paperi ja tasainen pinta jota vasten ajat paperi tietysti väliin.
Jos camilla nyt välttämättä haluat leikkä niin kirjoita käsin sinne coodin väliin testi ztalle joka käydään tarkistamassa jossain tunnetussa korkeudessa vaikka tolla paperi
tempulla ööö turhan vaikeeta.Tällä voi elimnoida muiden akselien viat pois.
Tai ota A akselista sähköt pois ja anna Z vatkata siinä ja katso muuttuuko paikka.
FL 2mm.txt ,
Muutin tuossa G40.1 ->G40.0 , G50 pois en tiedä miks vaati ton Emc herjas.
B akseli poistettu // merkillä koko rivi. Käy käteväsi editorilla.
A akseli poistettu kokonaan.
Noilla annoin Z vatkata omaa paikkaansa ei mitään ongelmaa Z pysyi paikallaan tietenkin, mitään siirtymää ei tullut kun se ei G tiedostossakaan muutu.
Jos tuo onnistuu sulta niin että Z paikka ei muutu.
Sitten otat B akselin käyttöön jos se muuttaa Z suhteessa kääntymiseen niin sitten on edessä koneen ohjaus softan parametrien ronkkiminen.
Ehkä myös koneen rihtaus joka on kyllä epätodennäköinen koska z muutos on jyrkkä täyden pyörähdyksen kohdalla.
Elä kose mihinkään Cämmiin ennen kuin saat koneen toteuttamaan sitä mitä G tiedostossa lukee kopio vaikka teksti editorilla joku tiedosto pätkä ja aja sitä.
Koodin alussa näyttää olevan myös G64, mach3:n mielestä se on "constant velocity mode" ja emc/linuxcnc "Path Blending", pitää ottaa pois Emc- testissä.
Koodissa on myös M6 T12 eli ensin tool change ja sitten tool prepare, tietääkseni nuo pitäisi olla toisin päin eli T12 M6.
Jos työkalulle on määritetty offsetteja niin G43 vielä perään tai ei toimi oikein. Saattaa olla edellisen työkalun offsetit käytössä.
Olen samaa mieltä muiden kanssa, kannattaa ensin kokeilla käsin kirjoitetulla g-koodilla. Ja myös tutustua käytetyn ohjaimen tunnistamiin G- koodeihin ja mitä ne tarkoittavat, säästää paljon ihmettelyaikaa.
Jos ajat tämän tyyppisellä koodilla (TARKASTA ENSIN!) eli vain B- akselin pyöritys samalla Z korkeudella niin tuleeko kappaleeseen tasainen ympyrä vai muuttuuko Z korkeus ajossa ?
Jos muuttuu niin koneen 0 ei ole B:n keskellä.
G17 // XY plane
G21 // mm
G80 // cancel motion
G49 // cancel tool length offset
G40 // cancel cutter radius compensation
G64 // constant velocity mode
G90 // absolute distance mode
G50 // reset all scale factos to 1.0
T12 M6
M03 S8000
G0 Z23.500
G0 X0.000 Y0.866 A0.000 B-90.000
Z13.500
G1 Z12.200 F200
Y1.048 F300
B0.000
B90.000
B180.000
B270.000
G0 Z23.500
M5 M9
M30
Vaikka ei olisikaan aivan keskellä niin ei siihen rappua tulisi, lastun vahvuus vain muuttuu erikohdilla kehää, mutta ei synny rappusta. Jonnen testin jälkeen minua en usko että koneen liikemekaniikassa olisi vika.
Mutta varsinki kovametalli terilä voi käydä niin että terän nousu vetää terää pidemmäksi... Ja minusta alkaa vaikuttaa että tässäköhtaa on siitä kyse.
Kirjoitin aiemmin että epäilen postaa syylliseksi,kun mulla on kokemus saman firman postasta Rolandin jwx10 koneelle,joka ei toiminu,mutta sain sen pienellä muokkauksella tekemään sen mitä halusin.
Piirsin Rhinolla uuden renkaan,ja tein siihen 3mm tapilla radan joka näkyy tässä>>http://screencast.com/t/aGHlU9ZTdk
Sitten Madcamillä koodi josta video >> http://screencast.com/t/ttJ6Gwc6
Kuvasta jossa terän alla on alku ja loppu,, ei enää näe mitään pykälää,eli se ongelma ratkesi väliaikaisesti muokkaamalla postaa.
Olen ajanu ton testipalan 5 kertaa,ja täytyy tehdä erilaisia ratoja varmistukseksi,ettei tule nuolastua ennen kuin tipahtaa.
Pitää tehdä oikeaan sormukseen toi rata ja kattoo onko alku ja loppu samassa paikassa.
Et sitten pysty antamaan periksi ja testaamaan konettasi kunnolla esim onko Z ja B akselit jotenkin naimisissa keskenään koneen ohjaus softassa oliko se nyt Mach.
Katso Iston postaus siinä oli asiaa selkeässä muodossa.
Älä leiki millään postprosessorillakaan ennen kuin olet tehnyt nuo em. jutut.
Jos tosiaan et kuuntele niin älä sitten huuda ja paru että kukaan ei auta.
Lainaus käyttäjältä: ttontsa - 23.01.15 - klo:22:59
sorry, siis tässä simulaatiossa (vähän puhelimen kanssa veivaaminen tuskallista linkityksen kanssa):
http://screencast.com/t/co0bmsBmR
etenkin ton x arvon juoksu ihmetyttää kun tossa txt tiedostossa ei ole kuin yksi x-rivi
Siinä madcamin simussa ei ne x y z kirjaimet pidä paikkaansa, ja se on asia mihin mä en voi vaikuttaa, eikä tekijät vastaa yhtään mitään kun sitä kysyy.
X= oikeasti Z:n liike
Y= oikeasti Bakseli pyöriminen
Z= oikeasti Y:n liike
http://screencast.com/t/tcLxaVnfcYJ
Tossa mun laittamalla videolla näkyy paremmin mitä tarkoitan.
Lainaus käyttäjältä: Kai - 24.01.15 - klo:17:10
Kirjoitin aiemmin että epäilen postaa syylliseksi,kun mulla on kokemus saman firman postasta Rolandin jwx10 koneelle,joka ei toiminu,mutta sain sen pienellä muokkauksella tekemään sen mitä halusin.
Piirsin Rhinolla uuden renkaan,ja tein siihen 3mm tapilla radan joka näkyy tässä>>http://screencast.com/t/aGHlU9ZTdk
Sitten Madcamillä koodi josta video >> http://screencast.com/t/ttJ6Gwc6
Kuvasta jossa terän alla on alku ja loppu,, ei enää näe mitään pykälää,eli se ongelma ratkesi väliaikaisesti muokkaamalla postaa.
Olen ajanu ton testipalan 5 kertaa,ja täytyy tehdä erilaisia ratoja varmistukseksi,ettei tule nuolastua ennen kuin tipahtaa.
Pitää tehdä oikeaan sormukseen toi rata ja kattoo onko alku ja loppu samassa paikassa.
Mikä postassa oli vialla?
Edellisessäkään kappaleessa ei olis pitäny olla G-koodin mukaan mitään vikaa, joten postan muokkauksestakaan ei merkittävää apua pitäisi olla?
Mutta jos eriterällä samaa ongelmaa ei esiinny voisin väittää että se toinen terä luisti...
Ei kai siinä postassa mitään vikaa ole,poistin vaan sieltä kaikki G alkukomennot,ja sitten koitin yhtä pientä juttua,mutta ei se mitään auttanu.
Ja olen tässä odotellu jo useamman päivän camin ja postan tekijältä Joakim Mölleriltä,neuvoja voisiko sille postalle tai camille tehdä jotain,hän on vaan niin kiireinen että vastaus kestää.
Ajoin ton Iston ehdottaman koodin,ja tulee täysin pyöreää palikka, niinkuin olisi sorvattu,Z pysyy siinä mikä on ohjelmassa oleva arvo.
Servo ohjaimen päästä näkee saman eli luku ei z suhteen muutu mihinkään.
Ps tässä kohtaa aihe-otsikko ei ole korrekti,Z pysyy.
Hyvä kun koitit tota nyt on sitten suljettu pois Z ja B akselin naimisisissa olo virheen muodossa koneen ohjaus softassa.
Älä nyt vaan luovuta, muokkaa se tiedosto missä virhe tuli FL 2mm.txt , alkuun ja loppuun sellaiset referenssi pisteet että pystyt tarkistamaan
koneen fyyfisen paikan niissä kone pysäytettävä näihin.
Mikä nyt helpoimmalta tuntuu mittakellotkin on hyvä vaihtoehto.
Ja myös ohjauksen ilmoittamat paikkatiedot pitää täsmätä näiden referennssi pisteiden kanssa.
Tästä näet luistaako mekaniikka ,esim. terän kiinitys .
vai pettääkö ohjaus pulssianturi ,softa pullssitus epäonnisttuu servoille miten takaisin kytkentä hoidettu, pystyykö korjaamaan.
Käytä tota samaa sulla siirtymän aiheuttavaa tiedostoa koko ajan älä tee yhtään uutta ennen kuin olet sevittänyt tuon mistä tuo siirtymä johtuu.
Tohon menee vartti.
Se ongelma Z suhteen taisi ratketa :D päivittämällä CS labsin boxi,eli siihen viimeisin firmware,ja tuloksen voitte kuvista katsoa itse.
Se eka kuva on koneen alta,toinen on mikroskoopin läpikuva 20 kertaa suurennettu,,se mitta-asteikko pitää tossa suunnilleen paikkansa,eli ne pienet krapit (.3mm halk) tulee
timantin ympärille, viimenen on huono kuva, mutta siinä näkyy kun ne on vierekkäin se sama kolo,joka oli aikaisemmin tulos.
Kun ajelin tota ja kattelin kesken ajon servo-ohjaimen päästä lukemaa joka pysyi koko ajan samana niin olin melko luottavainen siihen että lopputulos on hyvä,ja nyt toi työstöjälki on parempi mihin Roland pystyy.
Siinä on mulla 0.1 steppi,joka näkyy mikroskooppikuvassa,ja jos sitä haluan paremmaksi niin olen käyttäny 0,04 tai kun tehdään vielä pienempiä osia voi sen laittaa vaikka 0.01
Siinä vaan työstöaika tulee pitkäksi,joten en tossa kohtaa viitsi laittaa tarkempaa,kuin tuo.
Alimman kuvan reunassa työstöälueen ulkopuolella on pieni reikä,siinä on aloitus ja lopetus.
Tässä samalla voin antaa ISOT KEHUT Mikalle joka on jeesannu minua niin paljon että ei paremmasta väliä,niin ja samassa kiitos muillekin,,jotka ootte ollu hengessä mukana :D
Aika paha firmware- bugi. Hyvä että selvisi.