CNC-Harrastus

Olen tässä jonkun kuukauden hautonut ideaa sähköisestä
syöttövaihteistosta sorviin. Noissa pienissä sorveissa kun
ei ole kunnollista syöttövaihtestoa, eikä rattaiden remppaaminen
varmaan kovin montaa kiinnosta, ellei omaa reipasta S&M-henkisyyttä.

Idea olisi seuraava: karalle tulee inkrementaalinen enkoderi ja
syöttöruuville stepperi. Koko homman aivoina toimii mikrokontrolleri
PIC24, 8051 tai ARM... Hiukan hakusessa vielä mitä tuossa käyttäisi,
ainakaan ARMiin perustuva Coridium oli aika pettymys, eli varmaan
PICillä mennään ja assemblerilla ohjelmoituna ( ainakin nuo kriittisimmät
kohdat ).

Kone- ja kierresyötöt valitaan tuossa aparaatissa kiertokytkimin
( ehkä voisi joku halpa LCDkin olla vaihtoehto ), joten ylimääräisiä
osia ei tulisi ainakaan liikaa. Mahdollsesti voisi ohjelmoida myös
kartiosyötön X-akselille...

Tarkoitus tästä olisi tehdä avoimenkoodin-projekti, kytkentäkaavaa
sun muuta kivaa lisään tähän topiciin kunhan ehdin.

Ehdotuksia saa esittää ja mieluusti saa tulla ohjelmointitalkoisiin,
myös joo-joo -miehet.

Mieluiten tehtäisiin homma konekielisenä ja Basicilla ( BASCOMin
käännin on oikein näppärä AVRille ), tuo C ei oikein ole hanskassa,
eikä tässä mitään tekoälysovellusta ollakaan tekemässä.

Ja tiedän, tämä on keksitty varmaan noin kymmenen kertaa,
jenkeistä löytyy muistaakseni ELS-nimelllä kaupallista versiota,
mutta nyt voitaisiin tehdä simppeli, jämäosista koottava
variaatio.

Ideoita ja ehdotuksia, kiitos!

Terve

Prosessoriksi 8bit avr xmega(atmel).
Xmegassa on HW pohjainen quadrature decoder, eli lukee suoraan sisälle incrementtaali anturit.
Ohjelmointi kieleksi ehdottomasti C.
GCC kääntäjä ja kehitys alustaksi eclipse.

Kaikki ilmaisia työkaluja.

Xmegan kanssa voin laittaa projektin alkuun, löytyy pöydältä yksi koekortti.

Mä ajattelin käyttää niin törkeän tehokasta kontrolleria,
että voi tehdä laiskaa koodia...

Hiukan kiehtoo tuo PIC24 ja Mikroelektronikan Basic-käännin.
Mahdollistaa konekielensotkemisen sekaan tai kirjastojen
tekemisen. Muistaakseni tuo PIC24 pystyy 40 MIPSiin, joten
ei jää tehosta kiinni. Tosin keskeytyksihän tuo encoderin luku
toteutetaan, 6502:nen ( tuttu C64:sta ) riittäisi aivan vallan
mainiosti.

Tsekaas nuo Mikroelektronikan kääntäjät. Älytön määrä kirjastoja
mukaan vaikka mihin kivaan: http://www.mikroe.com/ (http://www.mikroe.com/)

Toinen muuten hiukan helpottava tekele enkoderin asennon
mittaamiseen löytyy US-digitalilta, tsekkaas piirit:

http://usdigital.com/products/interfaces/ics/ (http://usdigital.com/products/interfaces/ics/)

CuBlocia ei noilla ihan valjasteta reaaliaikaiseen kierresyöttöön,
mutta jonkin asteisen paikoitustiedon saamiseen kylläkin.

Olenkin pari vuotta sitten tehnyt aloituksen jo aiheesta ( tosin
vain enkodereista, mutta kuitenkin )

http://www.cnc-tekniikka.com/CNC-forum1/index.php?topic=197.0 (http://www.cnc-tekniikka.com/CNC-forum1/index.php?topic=197.0)

Terve

Xmegan 32 MIPS rittää tuollaiseen hommaan valan mainiosti.
Mitään keskeytyksiä encoderin lukuun ei tarvita koska se toiminto on sisäänrakennettu.
Ainoastaan rekisteristä tarvitsee lukea pulssien määrän.

Jussi

Pitääkin tutustua tuohon Xmegaan, vaikuttaa mielenkiintoiselta. Mikäs on
tarkka tyyppi MCU:lle?

Vaikkapa ATXMEGA128A1.

Lainaus käyttäjältä: Jonne - 26.10.09 - klo:22:38
Olen tässä jonkun kuukauden hautonut ideaa sähköisestä
syöttövaihteistosta sorviin. Noissa pienissä sorveissa kun
ei ole kunnollista syöttövaihtestoa, eikä rattaiden remppaaminen
varmaan kovin montaa kiinnosta, ellei omaa reipasta S&M-henkisyyttä.

Idea olisi seuraava: karalle tulee inkrementaalinen enkoderi ja
syöttöruuville stepperi. Koko homman aivoina toimii mikrokontrolleri
PIC24, 8051 tai ARM... Hiukan hakusessa vielä mitä tuossa käyttäisi,
ainakaan ARMiin perustuva Coridium oli aika pettymys, eli varmaan
PICillä mennään ja assemblerilla ohjelmoituna ( ainakin nuo kriittisimmät
kohdat ).

Kone- ja kierresyötöt valitaan tuossa aparaatissa kiertokytkimin
( ehkä voisi joku halpa LCDkin olla vaihtoehto ), joten ylimääräisiä
osia ei tulisi ainakaan liikaa. Mahdollsesti voisi ohjelmoida myös
kartiosyötön X-akselille...

Tarkoitus tästä olisi tehdä avoimenkoodin-projekti, kytkentäkaavaa
sun muuta kivaa lisään tähän topiciin kunhan ehdin.

Ehdotuksia saa esittää ja mieluusti saa tulla ohjelmointitalkoisiin,
myös joo-joo -miehet.

Mieluiten tehtäisiin homma konekielisenä ja Basicilla ( BASCOMin
käännin on oikein näppärä AVRille ), tuo C ei oikein ole hanskassa,
eikä tässä mitään tekoälysovellusta ollakaan tekemässä.

Ja tiedän, tämä on keksitty varmaan noin kymmenen kertaa,
jenkeistä löytyy muistaakseni ELS-nimelllä kaupallista versiota,
mutta nyt voitaisiin tehdä simppeli, jämäosista koottava
variaatio.

Ideoita ja ehdotuksia, kiitos!

Tämä lähti kiinnostamaan kun itsellä sattuu olemaan juurikin tuollainen kiinalainen halpissorvi, mikälie power craft. Jonkun verran tullut sillä kierteitä sorvattua ja Jonnen pointti osuu kohdalleen; niiden rattaiden kanssa pelaaminen on syvältä, eikä niillä edes saa kaikkia tarvittavia jengoja aikaan. Lisärattaiden hankkimisellekin pistää kynnystä niiden ihmemoduuli joka on jotain 1,25 tms.
Systeemi jossa napista painamalla saisi sopivan kierteen olisi meikän mieleen.

Lainaus käyttäjältä: Jussik - 27.10.09 - klo:23:01
Vaikkapa ATXMEGA128A1.

Jos tuommoisella lähdetään tekemään niin sitten minuakin kiinnostaa osallistua. Atmelin AVR:ien sisäinen arkkitehtuuri on ...hmm... "oikein" toteutettu - syy miksi olen tehnyt niillä enkä PIC:eillä joille sinänsä kaikki kunnia. AVR:t vaan sopivat erinomaisesti C:llä ohjelmoitaviksi ja XMegassa riittää potku tällaiseen ihan varmasti.

Jonnen toimintalistaan kertausta ja jatkoa:

- Kierteen nousun syöttö,
- jos X-akseli CNC:llä, kartiokulman syöttö
- Kierteen alku- ja loppukohtien osoittaminen
- Kierteen ajon käynnistys ja pysäytys
- Törmäyksenesto (ainakin pakkaan, kärkipylkkään ja teränpitimellä työkappaleeseen)
- Automaattinen palautus alkukohtaan(, tai kokonaan automaattinen työkierto)
- Terän offsetin asetus per ajokerta (+ X-suunnan syöttö jos X-akselin ohjaus CNC:llä)
- Terägeometrian/kierregeometrian syöttö ja valinta (jos vaikka haluaa ajaa acme/iso -ruuveja tms)
- Virhetilanteiden valvonta / hätäseislogiikka
- Konekinematiikan parametrien syöttö (pulssit/kierros, johderuuvien nousut, jne)
- Lähdöt askelmoottoreille ja servoille + mahdollista takaisinkytkentää varten pulssianturitulo (ainakin servo tarvitsee tämän, ei olisi huono askelmootorillekaan)
- Relelähdöt ja kosketintulot tarvittaville ristiinlukituksille

- Käyttöliittymäksi LCD-tekstinäyttö + muutama näppäin. Esim HD44780-yhteensopiva 4*16 merkkinen tekstinäyttö ei paljoa maksa.

Farnellilla tuo XMEGA128A1 versio maksaa siinä kympin ja A3 ja muut riisutummat jonkun euron vähemmän. Ei siis kannattane miettiä säästäisikö mitään optimoimalla. XMEGA128A1 olisi siis kelpo peli tähän hommaan.
Olisiko porukassa muita aiheesta oikeasti kiinnostuneita? Voisin lähteä toteuttamaan systeemi- ja ohjelmistonsuunnittelua sekä koodausta mutta en huolisi ottaa koko toteutusta omaan piikkiin. Eikä se olisi idean mukaistakaan jos tästä oli tarkoitus tulla avoin projekti. Mekaniikkaa ja motoriikkaa pitää suunnitella vaikka sorvissa jo peruskilkkeet onkin, ja elektroniikkaosuus täytyy suunnitella ja toteuttaa. Voin olla mukana molemmissa (hyvä käsitys kuinka Atmelilla toteutetaan elektroniikka) mutta noita saisi vetää joku muu.
Minulla on STK500 -lauta jolla olen koodaillut AVRStudiolla Mega-sarjalaisia. XMegaakin tuolla pystyy hyvin koodaamaan mutta ei enää debuggaamaan kun 500:nen ei tue pintaliitospakkauksia suoraan. Pitänee hommata joko adapteri tai sitten STK600. Jos tämä siis lähtee liikkeelle.

Olishan tuollainen hupaisa peli. Kuka tietää mitä siiihen vielä keksisi lisää.

Noniin

Joko niitä saa?

Multa saa protoihin noita LCD-näyttöjä jos haluaa. Elektroniikkasuunnitteluun osallistun mielelläni, sillä sulautettuja on tullut suunniteltua. Myös piirilevysuunnittelu on aika hyvin hanskassa ja EMC asiat osaan ottaa piirilevyjäkin suunnitellessa huomioon. Elektroniikkakin kannattaa suunnitella niin, ettei satunnaiset valokaaret tuulipuvusta pakkaskeleillä kukista koko konetta.

NC koneiden kanssa olen pelannut myös jo vuosia, mutta niistä en kyllä vieläkään mitään ymmärrä. Eli en voi esittää juurikaan mitään ominaisuuksia laitteen toimintaan.

Sanoppa nyt Jonne, mitä prossaa ajattelit käyttää? Ja mitä IO:ta siihen haluat?
Sitten alkaa skema syntymään. Protopiirilevynhän kaikki tällä foorumilla pystyvät jyrsimään minä mukaanluettuna.

Tämä viestiketju sai minut rekisteröitymään tälle keskustelupalstalle.

Olen miettinyt vaihdelaatikon tekemistä pieneen manuaalisorviini kun ei tuo rattaiden vaihtaminen oikein innosta, mutta tämä vaihtoehto tuntuu paljon paremmalta ja monipuolisemmalta.
Tämä taitaa olla jo moneen kertaan ratkaistu, netistä löytyy esim. ELS-rakennussarja (electronic lead screw). Onko nuo valmiit ohjaimet liian kalliita vai ominaisuuksiltaa vajaavaisia kuten muutamasta aikaisemmasta tässä ketjussa olevasta viestistä ymmärsin.

Mielenkiinnolla odotan eteneekö tämä projekti vai ostanko ELS-sarjan. Sen jälkeen tarvitsen vielä paljon hyviä neuvoja askelmoottorien yms. kytkennäistä ja asennuksista.

Tääll' kirjoittaa "sepänpoika", hän tietää kaiken hammasrattaista ja vaihteista...Kannattaa kysyä vaikka suoraan.

Tässä melko "kriitinen" postaus ELS:istä.

http://www.cncathome.com/els.html

Kieltämättä EMC tai vastaava laskee helposti sähköisen vaihdelaatikon tarvitsemat ohjaukset. En tunne EMC:tä ihan niin tarkkaan, että tietäisin osaako se toteuttaa yhdelle akselille (teränpitimen X) toisen akselin (karan C) seurannan käyttäen jälkimmäistä ohjearvona. Mikäli osaa, ei ole pakottavaa tarvetta lähteä miettimään omaa ratkaisua koska se on jo siinä.
Taloudellisessa mielessa ehkä ei ylipäänsä kannata keksiä tätä pyörää uudestaan koska toimivia systeemejä löytyy maailmalta. Niiden jotka haluavat nopeaa ratkaisua ehkä kannattaa turvautua jo toimiviksi tiedettyihihn toteutuksiin kuten vaikka ELS.

Lainaus käyttäjältä: Pete2 - 31.12.09 - klo:20:10
Tässä melko "kriitinen" postaus ELS:istä.

http://www.cncathome.com/els.html

Kaveri on oikeilla jäljillä, joskin hänen tekeleensä on huomattavasti yksinkertaisempi kuin mistä tässä säikeessä on keskusteltu. Tuota kannattaa kyllä miettiä jos ainoa kiinnostus aiheeseen on se lopputulos, eli varsinainen laite.
Minä kiinnostuin tästä ihan asian harrastuspohjalta. Aikataulua tai lopullisia ominaisuuksia on hankalaa tietää ennenkuin nähdään onko muita oikeasti lähdössä mukaan. Ainakin ram on jo ilmoittautunut elektroniikan suunnitteluun, joten hommassa päästään kyllä liikkeelle, pitää vaan organisoitua jotta rupeaa tapahtumaan.

Jos joku haluaa vain koneellisen syötön ilman kierrenousutarkkuutta eli riippuvuutta kara/johtoruuvi, niin ehdotan miettimään mahdollisuutta käyttää halpaa ruuvinväännintä tai akkuporakonetta pyörittämään akselia mikä liikuttaa kelkkaa. Akseli on vapautettava karayhteydestä. Rakenna sopivä välityssuhde ruuvivääntimestä/porakoneesta akseliin.
tarvittaessa erota kytkin ja nopeudensäädin parempaan paikkaan. Nopeudensäätönappula on parempi korvata potentiometrillä, johon on helppo laatia asteikko. Pienellä ajattelulla voi laatia käyrästön minkä avulla määrittelet syötön mm/kierros. Tuommoisen portaattoman syötön etuna on muunmuassa vähäisemmät värähtelyherätteet ja mahdollisuus helposti lisätä/vähentää syöttöä jos alkaa esiintyä värähtelyä. Pyörimisnopeudenmäärittelyyn voinee soveltaa aiemmin esittelemääni polkupyörän nopeusmittaria.

Tietokoneen pulttaaminen sorvin kylkeen oikeastaan pilaa alkuperäisen idean,
samallahan voi sitten tehdä sorvista CNC:n. Eli alkuperäinen oli mahdollisimman
minimalistinen käyttö.

Minulla olisi ehkä hiukan "parempi" idea tuon näytön tilalle, 2x16 LCD on
hyvin epäinformaativinen. Jospa jätetään näyttö pois ja laitetaan kiertokytkimet.
Yhdellä kytkimellä valitaan kierre/konesyöttö(/kartio), ja kolmella kymmenasentoisella
itse nousu (tai kulma). Näytön voisi lisätä näyttämään akselin asentoja ja mahdollisesti
parametrien asettamiseen, mutta senkin voisi hoitaa RS-232:n kautta tavallisella
tekstitiedostolla.

Voisin kysäistä Sylvanian kiertokytkimiä HUSTilta mitä ne maksaisivat, tuskin kovin paljoa.
Ja onhan noita halpoja kiertokytkimiä vaikka missä myynnissä, nuo Sylvanian ovat vain
kunnollisia metallirunkoisia, mitkä kestää vaikka ydinsodan...

Tämä olisi kiinnostava projekti !

Nyt kun jyrsin on cnc-muunnettu niin eikun sorvin kimppuun seuraavaksi. Mulla on Quantum D250 ja kierteiden teko kiinnostaisi mutta käytännössä se on tyssännyt alkukokeilujen jälkeen siihen että nousun valintaprosessi vastaa pienen vaihdelaatikkoremontin tekoa jonka jälkeen kädet on viikon vaseliinissa.

Noiden kierrenousujen osaltahan tuo systeemi on kai periaatteessa yksinkertaisimillaan "pulssikertoja" (tai jakaja). Eli karalla oleva enkooderi tuottaa pulsseja suhteessa karan pyörimisnopeuteen ja nämä kerrotaan sopivasti (vastaten haluttua nousua) ja tuupataan syöttöruuvia pyörittävälle askelmoottorille. Näin syntyy karan ja syöttöruuvin välille vaste joka seurailee karan pyörimisnopeutta automaattisesti. Jos tuon toteuttaisi askelmoottorilla niin tuohan ei paljon ohjauslaitteelta älyä vaadi. Kiertokytkin riittäisi nousun valintaan. Joku tapa tietenkin pitää olla syöttää ohjauslaitteelle sopivat kertoimet jotka riippuvat askelmoottorin välityksestä ja syöttöruuvin noususta yms.

Tuon kierrenousutoiminnon lisäksi ainakin mulle riittäisi se, että syöttöruuvia voisi ajaa eteen- ja taaksepäin muutamalla kiinteällä valinnaisnopeudella. Eli vaikkapa 3-5 karan pyörintänopeudesta riippumatonta nopeutta riittäisivät mainiosti.
Tätä varten ohjauslaitteen tarvitsee vain generoida askelpulsseja halutun mukaisesti. Joku yksinkertainen pulssigeneraattori tarvitaan tuota varten vai osaako prossut itse generoida tuota varten taajuuden. Varmaankin osaavat.

Minunkaan mielestäni tämä koko härveli ei välttämättä tarvitse mitään näyttöä, kiertokytkimet riittäisivät.

Tuo syöttöruuvihan ei mitenkään hurjaa vauhtia pyöri, joten askelmoottorin ja sen välille voisi laittaa alennusvaihteen vaikka hammashihnalla. Mitä arvelette, onko tuossa mitään väliä sillä käytetäänkö servoa vai askelmoottoria ? Luulisi että askelmoottorin "askellus" ja "värinä" hukkuvat tuohon välitykseen eikä niillä ole työstöjälkeen mitään vaikutusta.

Eli lähinnä noille ohjelmoitaville pikkuprossuille jäisi tuossa tehtäväksi toimia pulssikertojina sen mukaan miten kiertokytkimet on asetettu. Yksi kytkin vaihtaa lisäksi suunnan. Onkos noita kiertokytkimiä "digitaalisina" siten että sieltä irtoaisi suoraan joku binäärikoodi jonka prossu helposti lukisi ? 2 potenssiin 4 on esimerkiksi jo 16 eri asentoa ...

- JuhaV

Ei kannata ruveta tekemaan pulssijakajaa, käy homma helpoimmin mikrokontrollerilla.
Askelmoottori riittää vallan mainiosti ruuvin käyttöön.

Itselläni oli idea noista digitaalisista bitti-koodetuista kiertokytkimistä, että jokaisella desimaalille olisi
omansa. Eli ensimmäisellä valitaa millit, seuraavalla kymmenesosat ja viimeisellä sadasosamilit.

Parametrit olisi helppo asettaa tekstitiedostolla (ruuvinnousu, askelmoottorin pulssit,
karan pulssit) sarjaportin kautta, ei tarvisi erillisiä ohjelmistoja asettamiseen, eikä myöskään
näyttöä. Ohjainboxin sisään paperilapulle minkälainen teksitiedoston sisältö on. Voisi olla jotain
tämän kaltaista:

&
1000 ; karan encoderi
400  ; Z-askelmoottori puls/kierros
5000 ; Z-ruuvin nousu 0.001
;(kartion ajamiseen)
400  ; X-askelmoottori puls/kierros
3000 ; X-ruuvin nouse 0.001
%

Helppo tedä "Muistiolla" parametritiedosto ja lykätä se terminaaliohjelmalla
koneeseen. Voihan nuo arvot vaikka näpyttää terminaalista suoraan
ohjaukseen, ohjain voisi vastata vaikka terminaaliin että on ymmärtänyt jokaisen
parametrin.

Kiihdytys- tai jarrutusramppeja ei tarvitse, mikäli kierteytys
tehdään ihan perinteiseen tyyliin, pyörimisnopeus on sen verran
hidas, ja ramppia syntyy jo karan käynnistyksessä ja sammutuksessa.
Normaalilla syöttöliikkeellä ei edes tarvitsisi muuta kuin loivan kiihdytysrampin.

Automaattinen kierteytyssysteemi on turhan hankala toteuttaa (offsetit, kierrekulmat,
sun mu skeida...) ja lisäksi koneesta tulisi enemmän NC-kone kuin manuaali.

En halua muuttaa sorviani kokonaan CNC-sorviksi, vaan kierteiden ja kartioiden tekemistä haluaisin helpottaa ja muuten pitää myös manuaalikäyttöisenä.
Siis tuo minimalistinen toteutus ilman PC:tä on se mitä minä etsin.

Pieni vaihteisto toki olisi yksi vaihtoehto ja Sepän poika jo melkein sen lupautui tekenään. Epäilen kuitenkin että hintaa sille kertyy äkkiä enemmän kuin sähköiselle systeemille.

Prosessorilla ilman muuta kaikki laskenta. Muuta ei kannata miettiäkään.

Tuollaisia paneelikäyttöön tarkoitettuja kvadratuurienkoodereita, joissa on vielä painokytkin mukana saa Partcolta parillakympillä. Mulla on niitä jokunen hyllyssä.

Parametrien asetus sarjaportin kautta onnistuu kyllä, mutta mutta. En oikein ymmärrä miksi kytkimiin verrattuna näyttö on mielestäsi "epäinformatiivinen", infomaation välittämiseenhän ne on tehty. Käyttöliittymän voi toki suunnitella huonosti tai hyvin, mutta eihän me huonoa olla tekemässä...

Tässä minun ajatuksiani miksi en kannata sarjaporttia:
- Prosessista tulee mutkikkaampi: aina kun pitää muuttaa parametria, pitää kantaa PC sorvin ääreen ja alkaa virittelemään piuhoja. Toimii kyllä mutta onko "kätevää"?
- Parametrit on jossain PC:n tiedostossa, mutta ei ole mitään keinoa varmistua siitä, mitä oikeasti on ohjaimessa (jos sattuu vaikka olemaan eri versioita PC:llä, ja varmaan on vähän ajan kuluttua :) )
- LCD-moduli on lapsellisen helppo liittää prosessoriin, yhtään lisäkomponenttia ei tarvita (no joo, kontrastinsäätötrimmeri ehkä). Sarjaportti on vähän hankalampi (kts seuraava).
- Sarjaportti tarvitsee +/-12V jännitteen jota ei tarvitse mikään muu tässä virityksessä. MAX232-sarjan sovittimet osaavat nuo kyllä tehdä varauspumpulla, mutta tulee vieläkin lisää komponentteja.
- Liittimineen yms ei hintaeroa sarjaportin ja lcd-näytön välille paljoa jää, Partcolla Displaytechin 2*16 näyttö maksaa parikymppiä ja 4*16 merkkinenkin vain kympin lisää.
- Uusimmista läppäreistä rupeaa sarjaportit olemaan jo vähissä. Aina voi tietty kehittää jotain sovittimia, mutta hankalammaksi vaan menee...

Jos jokaiselle syöttöparametrin dekadille olisi oma kiertokytkin, niin niille tulisi enemmän hintaa kuin näytölle. Minä en pidä tuota ratkaisua mielekkäänä, eikä sellaiseen oikein missään törmääkään juurikin siksi, että halvat näytöt ovat niin halpoja. Tuo pikku lcd on saman hintainen kuin 1kpl enkooderikykimiä. Vaikka tässä ollaan simppeliä vehjettä miettimässä, niin käyttöergonomian saa näytöllä paremmaksi uhraamatta oikein mitään yksinkertaisuudessa. Näyttö, pari painiketta ja painike-enkooderi riittävät oikein hyvin kelpo käyttöliittymän toteuttamiseen.
Ihan heittona vaan: tuollaisella on helppo nakki syöttää kierteen nousu lennossa vaikka tuumina jos haluaa tehdä jotain whitvorttia brittivehkeisiin. Parametreihin vaan syöttöyksiköt valittaviksi ja tuumamitat päälle niin lukemat on tuumia (tai virstoja tai ihan mitä haluaa). Eikä ole yhtään sen vaikeampaa. Kiinteillä kytkimillä joutuu tekemään päässälaskut itse. En tiedä haluaako kukaan juuri tuollaista, mutta noin esimerkkinä joustavuudesta.

Näytössä on vielä toinenkin puoli joka minulle ainakin tuntuu tärkeältä: sen avulla voi toiminnan aikana näyttää laitteen tilaa ja mahdollisesti havaittuja häiriöitä. Näin laite ei ole pelkkä taikalaatikko joka joko toimii tai ei, ja jos ei niin mistään ei tiedä miksi. En tähän hätään osaa sanoa mitä kaikkea informaatiota tuon pitäisi antaa, mutta ainakin noita yllämainittuja. Aikaa voittaen varmasti keksitään jotain lisää.

Niin vielä:
Varmaan se onkin jo selvää kaikille, että semmoista laatikkoa jossa olisi vain muutama kytkin jolla asetetaan kierteen nousu eikä sitten mitään muuta, ei voi tehdä. Jollain on sorvin parametrit saatava sisälle, koska ne ovat kuitenkin joka miehellä erilaiset.

Taikalaatikko olisikin se juju, ei mitään ylimääräistä.

Toki parametrit voisi asettaa myös DIP-kytkimien kauttakin,
jos ei sarjaportit nappaa. Tohon taas palaa turhaan I/O:ta, mutta olisi ainakin
idioottivarma systeemi. Näppistyylin luettava DIP-matriisi olisi suhteellisen
säästeliäs I/O:n käytöltä.

En oikein ymmärrä mitä informaatiota näytöllä voitaisiin esittää, kiertokykimien
asennosta näkee suoraan mikä syöttö/tila on käytössä. Ledit voisivat ilmoittaa
viasta. Tosin LCD ei ole kallis, eikä niistä tarvi edes parikymppiä maksaa, järkkään
kyllä halvemmalla tarvittaessa. Tuon voi minun puolesta laittaa optioksi.

No joo, onhan tuo totta RS232:sta, mutta voitaisiin ottaa joku mikrokontrollerin
kehitysalusta pohjaksi, jossa olisi RS-232:nen ja muu roju valmiina.

Muuten tuo tuumaisten kierteiden asetukset olisivat noilla kiertokytkimillä
aivan looginen juttu. Kun käännät tuumapuolen päälle, kiertokytkimillä
asetetaan "kierrettä tuumalle", ekalla kympit, tokalla ykköset. Simppeliä?

Lainaus käyttäjältä: Jonne - 01.01.10 - klo:17:46
Taikalaatikko olisikin se juju, ei mitään ylimääräistä.

Joo kun joku vaan keksisi idioottivarman taikalaatikon ;)

Lainaus käyttäjältä: Jonne - 01.01.10 - klo:17:46
Toki parametrit voisi asettaa myös DIP-kytkimien kauttakin,
jos ei sarjaportit nappaa. Tohon taas palaa turhaan I/O:ta, mutta olisi ainakin
idioottivarma systeemi. Näppistyylin luettava DIP-matriisi olisi suhteellisen
säästeliäs I/O:n käytöltä.

DIP-kytkimet ja kiertokytkimet (siis sellaiset absoluuttiaseman antavat) ovat sähköisesti sama juttu, eli molemmat vaativat jonkinlaisen dekoodausmatriisin tai sitten paljon I/O:ta. Samalla matriisilla saisi kyllä näppäimistönkin, mikä olisi ergonomisin vaihtoehto (tai siis se on minun mielipiteeni).

Lainaus käyttäjältä: Jonne - 01.01.10 - klo:17:46
En oikein ymmärrä mitä informaatiota näytöllä voitaisiin esittää, kiertokykimien
asennosta näkee suoraan mikä syöttö/tila on käytössä. Ledit voisivat ilmoittaa
viasta.

Kytkimistä toki näkee asetetun nousun, mutta vain sen.
Näytölle siis: (* = täytyy olla, + = voisi olla jos halutaan)
* Ensinnäkin ne koneen perusparametrit, kierteen nousu, kierteen ajopituus.
* Johtoruuville turvarajat ajamalla sen ääriasentoihin joita ei sovi ohittaa. Toimintona helppo tehdä eikä vaadi yhtään lisäkomponenttia jos käyttöliittymä on näyttöpohjainen.
+ metrit / tuumat
+ jos toteutetaan kartiosorvaus niin sitten kaikki sen parametrit
+ Käyttöönotossa olisi varmaan ihan näppärää jos diagnostiikkatilassa näytöltä suoraan näkisi kaikkien liitettävien signaalien tilat ja karan enkooderin toiminnan - suunta, pulssilaskuri, kanavien tilat (tasot 1/0).

Näiden lisäksi kaikki se mitä ei juuri nyt tule mieleen mutta myöhemmin osoittautuu tarpeelliseksi. En minäkään ole miettinyt mitä kaikkea, mutta jotenkin sitä vaan tuppaa aina tulemaan. Näyttöratkaisussa ei ole rajoituksia mitä ja kuinka paljon voidaan esittää.Joku paniikkiledi ei välttämättä olisi huono ajatus, mutta on taas lisäkomponentti, tosin varsin helppo ottaa mukaan.

Lainaus käyttäjältä: Jonne - 01.01.10 - klo:17:46
No joo, onhan tuo totta RS232:sta, mutta voitaisiin ottaa joku mikrokontrollerin
kehitysalusta pohjaksi, jossa olisi RS-232:nen ja muu roju valmiina.

Niin, miksipä ei. Mulla on tuossa pöydällä esim. Atmelin STK500 jossa olisi tähän tarvittavat kilkkeet valmiina. Lähtöjä riittää vaikka tekisi molemmat, sekä näytön että sarjaportin. Saisi sitten kukin valita mieleisensä. Lapsellisen helppo ladata sovelluskin lennossa sisään niin voi tehdä vaikka eri softaversiot molemmille (jos ei muisti esim riitä pitää molempia yhtäaikaa tms). Hintaa tosin rupeaa äkkiä kertymään enemmän kuin tarkoitukseen tehdyllä lankulla. Mikään minisarjan protoalusta ei nimittäin välttämättä riitä.

Lainaus käyttäjältä: Jonne - 01.01.10 - klo:17:46
Muuten tuo tuumaisten kierteiden asetukset olisivat noilla kiertokytkimillä
aivan looginen juttu. Kun käännät tuumapuolen päälle, kiertokytkimillä
asetetaan "kierrettä tuumalle", ekalla kympit, tokalla ykköset. Simppeliä?

Onpa kyllä, mutta nyt sinulle tuli taas yksi kytkin lisää jolla tuon valinnan voi tehdä. Näyttöön perustuva käyttöliittymä on sillätavalla yleiskäyttöinen, ettei tarvita rautamuutoksia kun pitää saada lisää toimintoja.

Katsoin että Quantumissa näyttää syöttöruuvin nousu olevan 2 mm.

Eli 0.1 mm per karan kierros liikenopeudella (joka vastaa jollain tavalla normaalia työstönopeutta meikäläisen hommissa) kun kara pyörähtää 10 kertaa niin syöttoruuvi pyörähtää 1/2 kierrosta.  Tai toisin sanottuna kara pyörähtää 20 kierrosta yhtä syöttöruuvin kierrosta kohti.

Sitten kun hypätään kierteitysnopeuksiin liikkeessä niin 1 mm liike per karan kierros (kierteitys 1 mm nousulla) tarkoittaa että karan pyörähtäessä kaksi kierrosta niin syöttöruuvi tekee yhden kokonaisen kierroksen.

Tuosta saa vähän arviota sille millä nopeudella pulsseja tulee jos vaikka karalta saisi 200 pulssia per kierros. 600 rpm:llä kierroksia tulee silloin 10 sekunnissa. Eli 2000 pulssia sekunnissa anturilta. 1.8 asteen askelmoottoria (200 askelta per kierros) pitäisi siis 1 mm nousua varten tässä esimerkissä askeltaa 1000 Hz taajuudella kokonaisin askelin. Meniköhän tämä nyt oikein ?

Karan nopeus jos vaihtelee vaikka 100 - 2000 rpm ja nousut 0.1 - 5 mm työstöliikkeenä, niin siitä voi arvioida millaisissa rajoissa pulssimäärät liikkuvat. Eli sadoista  pulsseista sekunnissa aina muutamaan kymmeneen kilohertsiin (pikaliikkeet) ?

Millainen tuo anturi karalla tulisi olla ? Simppeli pulssianturi, jonka pulssit lasketaan prosarin avulla ? Vai fiksumpi inkrementaalianturi ? Vaiko absoluuttianturi ?

Anturin valinta vaikuttaa kaiketi aika lailla siihen millainen laskentalogiikka prosarilla tarvitaan.

Tämä oli ääneen pohdiskelua kun koetin hahmottaa sitä että se prosari toimisi ikäänkuin yksinkertaisen "ohjelmoitavana" pulssikertojana, johon kertoimet olisi ohjelmallisesti tökätty ja sopiva kerroin valittaisiin digitaalisella kiertokytkimellä (joka toimii dip-kytkimen tapaan).

Itselleni kelpaisi hyvin sellainen systeemi, jossa nousu valitaan kiertokytkimellä johon on "kullekin" positiolle ohjelmoitu haluttu nousu. Tuskin tarvitsen enempää kuin 4-6 erilaista nousua. Tuo esiohjelmointi voisi tapahtua sitten vaikka tietokoneella tai näppiksellä. Jos valinnan voi tehdä nuolinäppäimillä ja arvon näkee näytöllä niin sekin käy vallan mainiosti.

Sen olen huomannut että jos lukuarvon syöttää näppäimistöltä suoraan niin ennemmin tai myöhemmin tulee se "pilkkuvirhe" ja rajakytkimille käyttöä ;) Esivalitun " taulukon" selaaminen nuolinäppäimin tai kiertokytkimellä vähentää virheen riskiä.

- JuhaV

Lainaa
DIP-kytkimet ja kiertokytkimet (siis sellaiset absoluuttiaseman antavat) ovat sähköisesti sama juttu, eli molemmat vaativat jonkinlaisen dekoodausmatriisin tai sitten paljon I/O:ta. Samalla matriisilla saisi kyllä näppäimistönkin, mikä olisi ergonomisin vaihtoehto (tai siis se on minun mielipiteeni).

Idea olisi hiukan siinäkin, että sitä voisi käyttää hanskat käsissä, näppäimistöt eivät sovellu lastujen sekaan. Eikä tuota I/O:ta mene kuin 4 per kiertokytkin, eli 12 kolmeen plus "mode"-kytkin, yhteensä 16. Ja onhan noita julman isolla I/O:lla varustettuja mikrokontrollereita, joten ei se DIP-kytkin hommakaan vaadi kuin jonkun 8/16 I/O:ta (8 kpl  16-bit parametria), lisäelektroniikkaa ei
tarvita.

LainaaKytkimistä toki näkee asetetun nousun, mutta vain sen.
Näytölle siis: (* = täytyy olla, + = voisi olla jos halutaan)
* Ensinnäkin ne koneen perusparametrit, kierteen nousu, kierteen ajopituus.
* Johtoruuville turvarajat ajamalla sen ääriasentoihin joita ei sovi ohittaa. Toimintona helppo tehdä eikä vaadi yhtään lisäkomponenttia jos käyttöliittymä on näyttöpohjainen.
+ metrit / tuumat
+ jos toteutetaan kartiosorvaus niin sitten kaikki sen parametrit
+ Käyttöönotossa olisi varmaan ihan näppärää jos diagnostiikkatilassa

Pieni näyttöisestä ja painonapein käytettävästä käyttöliittymästä ei kyllä omasta mielstäni ole soveltuva koneistusympäristöön, homman pitää toimia kuin "fast food", silloin singahtaa, eikä tarvi ihmetellä.

Lisäksi tuo automaattinen kierteytys ei ollut ihan alkuperäinen idea, tarkoitus oli saada sähköinen syöttövaihteisto, ei muuta, ei edes DRO:ta ( koska on suhteellisen turhaa mitata terän sijaintia trapetsiruuvillisessa koneessa ilman
mittasauvoja, pitäisi olla välyskompensoinnit ja etc.). Lisäksi tuohon
kiertetystyökiertoon pitää ottaa huomioon niin monta asiaa, että voisi sen
jättää NC-koneiden hommiksi.

Kartiosorvaukseen olisi kyllä tarvetta saada joku toinen systeemi, mutta yhden kiertokytkimen lisäämällä saisi sadasosa-asteen tarkkuuden (koska yli 90 astetta ei pysty sorvaamaan, ellei nyt ole selkäpuolella toista pidintä).
Minuuttien ja sekuntien saaminen lisäisi huomattavasti kytkimien määrää,
joten se ei onnistu kyllä minun ideallani.

Lainaa
Onpa kyllä, mutta nyt sinulle tuli taas yksi kytkin lisää jolla tuon valinnan voi tehdä. Näyttöön perustuva käyttöliittymä on sillätavalla yleiskäyttöinen, ettei tarvita rautamuutoksia kun pitää saada lisää toimintoja.

Ei välttämättä, katso liite, tuollainen on ideani. Mitä tykkäät?  ;D

Lainaa
Millainen tuo anturi karalla tulisi olla ? Simppeli pulssianturi, jonka pulssit lasketaan prosarin avulla ? Vai fiksumpi inkrementaalianturi ? Vaiko absoluuttianturi ?

Inkrementaaliset anturit ovat halpoja, eli niitä...

Olen kirjoittanut jutun niistä, eli täällä voit tutustua aiheeseen:

http://www.cnc-tekniikka.com/CNC-forum1/index.php?topic=197.msg453#msg453 (http://www.cnc-tekniikka.com/CNC-forum1/index.php?topic=197.msg453#msg453)

Lainaa
Tämä oli ääneen pohdiskelua kun koetin hahmottaa sitä että se prosari toimisi ikäänkuin yksinkertaisen "ohjelmoitavana" pulssikertojana, johon kertoimet olisi ohjelmallisesti tökätty ja sopiva kerroin valittaisiin digitaalisella kiertokytkimellä (joka toimii dip-kytkimen tapaan).

Jeps, cpu kyttää karan asentoa ja puskee sen mukaan pulssia askelmoottorille.

Tämän koko systeemin voisi toteuttaa konekielellä ilman keskeytyksiä, koodia ei paljoa tulisi, jos aparaattiin ei laiteta mitään ylimääräistä.

Anteeksi sillisalaatti, koetan näköjään vastailla useampaan viestiin kerralla.

JuhaV: Näyttivät uskottavilta nuo laskelmasi, suurinpiirtein tuollaisista luvuista kaiketi puhutaan.

Karan anturiksi sopisi tämänhetkisen ymmärrykseni mukaan parhaiten simppeli pulssianturi joka siis on juurikin inkrementaalianturi, eli antaa tiedon etenemästä mutta ei absoluuttisesta kiertymäkulmasta (ei tarvita liikkeen suuntatietoa kun ei se kara yllättäen kai suuntaansa vaihda). Indeksipulssi kerran kierroksella on välttämätön jotta saadaan liikkeet synkattua. Kierteen ajohan pitää aloittaa aina samasta karan kiertymäkulmasta joka siivulle.

Anturin valinta toki vaikuttaa laskennan toteutustapaan, vaikka ei minusta muuta koodaustapaa kannata oikein miettiä. Karan pyörimisnopeuden laskennassa sen dynamiikka-alue vaikuttaa laskentalogiikkaan. Hyvin hidas pyörintä (<<100 RPM) yhdistettynä harvaan pulssianturiin edellyttää vähän eri tapaa mitata kuin nopea pyörintä ja tiheä pulssitus. Pitää kuitenkin vielä vähän laskeskella miten homma sorvin tapauksessa menee, kun se on eri juttu kuin paperikone tai teräsvalssi.

Tuo on hyvä havainto, että joku näppäilyvirheiden minimointisysteemi olisi hyvä olla. Mikään ei estä tallettamasta parametrimuistiin listaa vakiokierteistä jotka saa nopeasti valittua. Minulla on ollut tässä mielessä kiertovalitsimen (siis paneelienkooderin) käyttöön perustuva käyttöliittymä jollon pikavalinta menisi esim jotenkin siten, että kooderin painikkeesta tökkäämällä siirrytään valikkoon, kiertämällä ja tökkäämällä valitaan nousun asetus, kiertämälllä ja tökkäämällä valitaan haluttu nousu listalta. Tuo voisikin olla ehkä kaikkein kätevin tapa, koska numeronäppäimistöä ei kai ollut tarkoitus kuitenkaan laittaa. Esiohjelmoinnin voi hyvin tehdä samoilla eväillä, koska senhän ei tarvitse olla käyttöön verrattuna erityisen nopeaa eikä kätevää.

Ohjelmiston toteutuksessa pulssien välinen kerroin karapulssit -> muunnoskerroin -> askelpulssit on oikeastaan se yksinkertainen osa, eikä sekään ihan niin yksinkertaista ole kun kaikki vaatimukset on huomioitu. Omat haasteensa tulee systeemin ajotilan hallinnasta (jonkinlainen alkeellinen turvalogiikkakin tarvittanee), liikkeiden tahdistuksesta ja työkiertojen ohjauksesta tai opastuksesta, jos/kun tarvitaan koneenkäyttäjän apua sekä käyttöliittymästä. Nuo jälkimmäiset ovat 95% ohjelmistosta ja tuo nopeussuhteen laskenta vain 5% jos sitäkään. Että ei tästä älyttömän simppeliä lopulta saa millään.

Itse asiassa alan olla sitä mieltä, että merkkivalo tai pari voisi olla poikaa ihan siitä riippumatta onko kapineessa näyttöä vai ei ja miten eri asiat sille syötetään. Vaikka tässä puolustankin LCD-näyttöä niin onhan sen jatkuva tihrustaminen työskentelyn aikana hankalaa. Perusviestit käyttäjälle saisi parilla-kolmella erivärisellä ledillä menemään hyvin perille, esim "kone valmis" - "kone työstää" - "odottaa käyttäjän toimenpidettä" - "työstää" ... Kun systeemi on käytössä tullut tutuksi niin nuo aistii silmänurkasta eikä tarvitse erikseen käydä lukemassa mitä asiaa vehkeellä olisi.

Lainaus käyttäjältä: Jonne - 02.01.10 - klo:00:14
Idea olisi hiukan siinäkin, että sitä voisi käyttää hanskat käsissä, näppäimistöt eivät sovellu lastujen sekaan. Eikä tuota I/O:ta mene kuin 4 per kiertokytkin, eli 12 kolmeen plus "mode"-kytkin, yhteensä 16. Ja onhan noita julman isolla I/O:lla varustettuja mikrokontrollereita, joten ei se DIP-kytkin hommakaan vaadi kuin jonkun 8/16 I/O:ta (8 kpl  16-bit parametria), lisäelektroniikkaa ei
tarvita.


Pieni näyttöisestä ja painonapein käytettävästä käyttöliittymästä ei kyllä omasta mielstäni ole soveltuva koneistusympäristöön, homman pitää toimia kuin "fast food", silloin singahtaa, eikä tarvi ihmetellä.

Lisäksi tuo automaattinen kierteytys ei ollut ihan alkuperäinen idea, tarkoitus oli saada sähköinen syöttövaihteisto, ei muuta, ei edes DRO:ta ( koska on suhteellisen turhaa mitata terän sijaintia trapetsiruuvillisessa koneessa ilman
mittasauvoja, pitäisi olla välyskompensoinnit ja etc.). Lisäksi tuohon
kiertetystyökiertoon pitää ottaa huomioon niin monta asiaa, että voisi sen
jättää NC-koneiden hommiksi.

Kartiosorvaukseen olisi kyllä tarvetta saada joku toinen systeemi, mutta yhden kiertokytkimen lisäämällä saisi sadasosa-asteen tarkkuuden (koska yli 90 astetta ei pysty sorvaamaan, ellei nyt ole selkäpuolella toista pidintä).
Minuuttien ja sekuntien saaminen lisäisi huomattavasti kytkimien määrää,
joten se ei onnistu kyllä minun ideallani.

Kierto/tökkäyskytkintä voi käyttää hanskat kädessä oikein hyvin, ruuvaa vaan akselin päähän tarpeeksi ison nupin  :D Sellainenhan se sinunkin kiertovalitsimesi olisi.
Minusta parinkin kokonaisen prosessoriportin "tuhlaaminen" pelkästään dippikytkinten lukuun on hirmu haaskausta. Ja vaatii aika ison sirun koska mikrokontrollerien portit tuppaavat olemaan monikäytössä, eli ajastimet ja keskeytykset, uartit ja muut syövät portteja. Toki löytyy piirejä jossa I/Ota on tarpeeksi, mutta jos tämä on ainoa syy moisen valintaan niin hankaloittaako turhaan elektroniikan toteutusta?

Jos tehdään systeemi jolla onnistuu kartiosorvaus niin ei se kierteityskään sitten enää ole juuri sen haasteellisempaa. Suunnilleen samat synkkausvaatimukset tullee kummassakin. Terän aseman mittaaminen ei minusta ole mitenkään kierteityksen edellytys (korjatkaa jos olen väärässä). Olin ajatellut että käyttäjä ruuvaa säteen suuntaisen syötön ja sivuoffsetin jne kelkan käsipyöristä ja automaatti ajaa vain sitä peruskiertoa.

Lainaus käyttäjältä: Jonne - 02.01.10 - klo:00:14
Ei välttämättä, katso liite, tuollainen on ideani. Mitä tykkäät?  ;D

Jostain syystä en löydä liitettä viestistäsi?

Lainaus käyttäjältä: Jonne - 02.01.10 - klo:00:29
Jeps, cpu kyttää karan asentoa ja puskee sen mukaan pulssia askelmoottorille.

Tämän koko systeemin voisi toteuttaa konekielellä ilman keskeytyksiä, koodia ei paljoa tulisi, jos aparaattiin ei laiteta mitään ylimääräistä.

Kaunis ajatus, mutta koetapa toteuttaa se käytännössä. Einsteinilla (johon en itseäni vertaa) oli hyvä toteamus: asiat pitää tehdä niin yksinkertaisiksi kuin mahdollista, mutta ei sen yksinkertaisemmiksi. Muistaen, että asiat riitelevät, ei miehet, väitän että tuo on liiallista ongelman yksinkertaistamista. Keskeisen perusajatuksen voi saada toimimaan noinkin mutta kun ei se käytännössä kuitenkaan riitä.
Meidän varmaan olisi hyvä suunnilleen tässä vaiheessa hakea keskusteluun osallistujien kesken yhteisymmärrys siitä, mitä laitetta ollaan tekemässä jos tosissa lähdetään tekemään. Pelkkä kelkan koordinoimaton sivuliike menisi kai aiemmin ehdotetulla akkuporakoneella, tarviiko siihen sen vaikeampaa systeemiä? Jos sorvataan kartioita niin tarvitaan koordinoitu liike kahden akselin ja karan kesken. Kierteytys ei enää tuo lisää vaatimuksia vai tuoko?
Jos tästä tehdään vähänkään semmoinen laite jota jotkut muutkin ehkä toteuttaisivat niin ainakin silloin pitää uhrata ajatus työturvallisuudellekin - minä ainakaan en halua olla suunnittelemassa mitään automaattisilpojaa. Tähän on muuten koneturvallisuusdirektiiveilläkin sanottavaa näinä päivinä, ihan riippumatta siitä onko tämä harrastus vai työ itse kullekin.

Lainaus käyttäjältä: Jonne - 02.01.10 - klo:00:14
Ei välttämättä, katso liite, tuollainen on ideani. Mitä tykkäät?  ;D

No nyt tuo jostain syystä alkoi näkymään.
Ei minulla tuohon ole ajatuksen puolesta mitään huomauttamista, selkeähän se on kuin mikä. Tuollaista suunnilleen ajattelinkin sinun tarkoittavan. Edelleen kuitenkin viittaan aiemmin kirjoittamaani mitä tulee kaiken muun syöttämiseen.
Itse en mitenkään vastusta ajatusta, että laitteessa olisi tuollaiset valintanupit LCD-näytön *lisäksi*.
Jos mennään ihan yksityiskohtiin niin tuohon varmaan tarvittaisi vielä jokin keino vahvistaa tehty valinta. Tuo erillinen kiertokytkinhän määrää mitä ollaan asettamassa, mutta jollain pitää vielä vahvistaa numerokytkinten asetus otettavaksi sisään, muuten menee hankalaksi. Ellei tällaista vahvistusta ole eriksen, kierettäessä asetuskytkintä menee numerokytkinten luku saman tien asetukseksi jokaiseen kohtaan jossa valintakytkin on käynyt (prosessorilla ei ole muuta mahdollisuutta tulkita tilannetta). Se kai ei ole tarkoitus? Eli valintakytkin ensin siihen asentoon mitä ollaan säätämässä. Numerokytkimistä kierretään haluttu lukema. Jostain napista jota nyt ei näy, kuitataan lukema sisään. On tässäkin siis näkökohtia.

Noniin...

Kun kerran mielipiteitä kysyitte, niin tässä tulee jotain.

1. Kun kerran tulee kartion sorvaus, niin laitetaan saman tien se kierteytys. Kysehän oli alun perin kai siitä (siis mikä minua kiinalaisen sorvin omistajana innostaa), että vaihderemontin sijaan saisi tehtyä jotain hyödyllistä.

2. LCD ja muutama statusvalo sekä pieni painettava pulssipyörä inputtilaitteena olisi todella hyvä käyttöliittymä. Olen käyttänyt useampaakin laitetta, joiden hyvin monimutkainen ohjelmointi toteutetaan pelkästään tällaisella pulssipyörällä sen onnistuessa erittäin helposti. Tämä tietysti asettaa vaatimuksia käyttöliittymän tekemiseen, mikä ei ole herkkua assemblerilla.

3. Inkremettaalienkooderin tilalle kukaan tuskin mitään muuta on tosissaan miettinytkään.

Omasta mielestäni raudan puolella ei ole oikeastaan enää muuta mietittävää kuin nuo esiin tuodut turvafeaturet?? Mitä ne olisivat ? Näistäkään ei tietty rautaa piirtäessä minun tarvitse hirveästi välittää, kunhan vaan varaan niille muutaman IO:n

Ja tietty jos joku jo päättäisi millä prossalla homma tehdään. Voin piirtää raudan vaikka kahdelle tai kolmelle eri prossalle, niin saadaan homma käyntiin. Voin tietty valita sen itsekkin, mutta softamiehet voi ruveta ryppyilemään.

PS. Mulla on 300 freescalen DSP:tä turhan panttina laatikossa.
PS2. Myös kaikenlaisia FPGA chippejä on nurkissa. Kukaanhan ei ole vielä ehdottanut laitetta FPGA:lla toteutettavaksi  ;)

Kakkoskohtaan voi sanoa semmoisen "lohdutuksen" että tätä ei varmasti kukaan täysjärkinen enää tänä päivänä lähde tekemään assemblerilla. Tai sitten on vahvaa masokismin käryä ilmassa  :P. Kyllä C tai C++ rulettaa.

Prosessoriksi joku ehdotti ATXMEGA128A1:tä ja se saa minun ääneni. Ihan jo siksikin kun minulla on AVR:n kehityskilkkeet mutta ei muiden. Ja prosessorinahan tuo on varsin tehokas ja arkkitehtuuriltaan tähän hommaan aika lyömätön. Muilla valmistajilla ei ole samanlaista tapahtumanreititysväyläsysteemiä jolla laskentakuormaa voi helpottaa huomattavasti. Harmi sinänsä jos sinulla on kasoittain kelpo prosessoreita joutilaina, mutta kun niille pitäisi olla kehitysvälineet ja osaaminen/kokemus. Mahtaako keltään löytyä? Ja mahtaako DSP olla kuitenkaan paras valinta tämmöiseen hommaan jossa tarvitaan aika paljon "general purpose"-tietojenkäsittelyä. Varsinaista signaaliprosessointia tässä sovelluksessa lienee lopulta aika vähän. No, en tunne noita freescalen tuotteita joten voisivat ne sopiakin. FPGA:lla yrittäminen voi olla itsensä kiusaamista... :P

Turvapiirteistä sen verran, että ainakin tämän on reagoitava hätäseis-komentoon. Tavalla tai toisella sellainen on mukaan viritettävä eikä sen toiminta oikeastaan saisi olla vain softan varassa. Toimiva ajatus voisi olla piiri joka katkaisee moottorinohjauksilta enable-signaalin samalla kun aktivoi prosessorille hätäseis-inputin. Päätyrajakytkimille olisi hyvä olla ainakin tuloliitännät, käytti niitä tai ei. Liitännän teko kortillehan ei paljoa kustanna. Eipä juuri muuta tule nyt mieleen piirikortin osalta.

Ei ole vielä keskusteltu aiheesta, mutta eikö olisi kätevintä laittaa moottorinohjain (-ohjaimet) samalle piirikortille ja piirtää moottorisyötön jännitelähde samalla. Jos näin tehdään niin pitäisi varmaan valita ohjainpiirit. Oma ehdotus on L6506 + 2*L6203 per moottori. Tuo H-silta 6203 kestää 48V ja jaksaa painaa 4A RMS-virtaa joten varmaan riittää tuotto isommallekin johderuuville. Sekvensserinä voisi tietty käyttää myös L297:aa joka olisi simppelimpi ohjattava, mutta kun siitä saa vain puoli- ja kokoaskeleet ulos. L6506 ei puutu sekvensointiin, mutta toteuttaa PWM-virranrajoituksen samoin kuin L297. Sekvenssit saa hyvin tehtyä prosessorillakin. Virranrajoituksesta semmoinen huomio, että sense-vastusten referenssi-inputti pitää sitten tulla prosessorin A/D-muuntimen lähdöstä, eikä vastusjaosta kuten komponenttien datalehdillä yleensä näytetään. Jollei prosessorilla ole kahta D/A-muunninkanavaa (ATXMEGA:lla on kaksi) niin sitten pitää tyytyä ohjelmoitaviin vastuksiin mutta XMEGAlla ei tarvitse. Tämä kytkentä mahdollistaa paikallaan seisovan moottorin pitomomentin alentamisen lämpöhäviöiden vähentämiseksi.

Olen vähän tuuminut tuota karan nopeusmittausta. Tarkan pulssianturin virittäminen ontolle kara-akselille on hankalaa, mutta voisiko selvitä helpommallakin? Mitä jos ottaisi pelkän indeksipulssin ja ajastaisi liikkeet sen perusteella? Karahan saa kai pyöriä asetellulla nopeudellaan ennekuin teräkelkan liike aloitetaan? Karan pyörimisnopeus on "vakio" joten sopivasti laskettu liukuva keskiarvo indeksipulssien perusteella voisi hyvinkin olla riittävän tarkka tieto pyörinnästä. Näin vältettäisi kokonaan yksi suuri mekaaninen kanto kaskessa.

Jotain tällaista ehkä.

Lainaa
Karan anturiksi sopisi tämänhetkisen ymmärrykseni mukaan parhaiten simppeli pulssianturi joka siis on juurikin inkrementaalianturi, eli antaa tiedon etenemästä mutta ei absoluuttisesta kiertymäkulmasta (ei tarvita liikkeen suuntatietoa kun ei se kara yllättäen kai suuntaansa vaihda). Indeksipulssi kerran kierroksella on välttämätön jotta saadaan liikkeet synkattua. Kierteen ajohan pitää aloittaa aina samasta karan kiertymäkulmasta joka siivulle.

Tottakai inkrementaalisesta anturista nähdään kumpaan suuntaan se pyörii, vai tarkoitatko nyt jotain muuta..?

Lainaa

Turvapiirteistä sen verran, että ainakin tämän on reagoitava hätäseis-komentoon. Tavalla tai toisella sellainen on mukaan viritettävä eikä sen toiminta oikeastaan saisi olla vain softan varassa. Toimiva ajatus voisi olla piiri joka katkaisee moottorinohjauksilta enable-signaalin samalla kun aktivoi prosessorille hätäseis-inputin. Päätyrajakytkimille olisi hyvä olla ainakin tuloliitännät, käytti niitä tai ei. Liitännän teko kortillehan ei paljoa kustanna. Eipä juuri muuta tule nyt mieleen piirikortin osalta.

Ei mitään enable-signaaleja, vaan rele mikä pystyy katkaisemaan kaiken. Sähköt eivät saa tulla takaisin hätäpysäytyspainiketta nostamalla, vaan pitää olla myös erillinen kuittauspainike. Enable-signaalin voi kyllä ohjaus vetää ylös käynnistyksessä, ja pudottaa alas, jos huomaa jotain epänormaalia. Lisäksi isommat koneet tarvitsevat erillisen turvareleen. Näin sanoo laki.


Itse en ole vieläkään innostunut kierteen sorvauksesta automaattisesti, trapetsi ei kauan käryä moista käyttöä, jos vauhdit ovat riittävät... Ja miten hallitaan työkalun mitta? Vedetään ensin yksi kierre ja todetaan kierteen menneen yli, otataan uusi aihio, ja nollataan hiukan kauemmas terä? Eiks mene hiukan manuaalisorvin idea?

Luulen ettei kaikki ole nyt ihan ymmärtänyt omaa ideaani kierteytyksestä, se toimii aivan kuin oikeassa sorvissa, eli trapetsipyörii karan mukana molempiin suuntiin. Eli missään vaiheessa ei irroteta yhteyttä karan ja trapetsin välillä, kierteen alkuun päästään vaihtamalla karan suuntaa.


Lisäksi haudoin parametri-ideaa pidemmälle. Kiertokytkimillä pystyisi nekin asettamaan, kytkimillä haluttu arvo, ja kyseisen parametrin kuittauspainikkeella kuittaus.

Lisäksi karan enkoderi voisi olla 2500 pulssinen, niitähän nykyään nurkat pursuaa, ja saan niitä TECOlta aika kohtuulliseen hintaan. http://www.cnc-tekniikka.com/CNC-forum1/index.php?topic=970.msg5048#msg5048  (http://www.cnc-tekniikka.com/CNC-forum1/index.php?topic=970.msg5048#msg5048)

Ei konekieli ole masokismia, se on tehokasta  ;). Konekielellä saa aikaiseksi mukavan elegantteja ratkaisuja. Itse olen näköjään tehnyt pari vuotta sitten enkoderinlukuun konekoodin x86-prossuille, ilman sen kummempaa kokemusta (silloin):

http://www.cnc-tekniikka.com/CNC-forum1/index.php?topic=197.msg453#msg453 (http://www.cnc-tekniikka.com/CNC-forum1/index.php?topic=197.msg453#msg453)

Lainaa086-VERSIO:

;
; Esimerkki inkrementaalisen enkooderin luku A ja B kanavista
; Koodi x86-yhteensopivaa, tehty ja testattu emu8086:lla
;
; Johannes Thelen 2.2.2007
;

org 100h                                                   ; jatetaan hutia, ei oleellista
                                                               ; maarittetaan muuttujat
nykyinentilaX dw 0000 0000b                            ; näihin voit laittaa bittejä
edellinentilaX dw 0000 0000b                              ; testataksesi ohjelman toimivuutta
koordinanttiX dw 0h                                          ; esim. nykyinenX 0000 0001 ja edellinenX 0000 0010
                                                                    ;
LPT equ 378h                                            ; printteriportin osoite, en ole varma,
                                                               ; osoite vaihtelee koneesta riippuen
                                                              ; eli onko portti PCI-vaylassa vai
                                                              ; suoraan emolla...


paaohjelma:

;mov [378h],0000 0001b                            ;tama on testausta varten...           
;.                     
;.                                                           tahan tulee itse paaohjelma
;.
;.
;   
push bx                                                  ; pistetaan talteen rekistereiden arvot
push cx                                                 ;
push dx                                                    ;
mov dx,[LPT]                                         ; kopioidaan printteriportista nykyinentila
mov nykyinentilaX,dx ;       
call xasento                                            ; hypataan aliohjelmaan muutosten maaritykseen
pop bx                                                   ; palautetaan rekisterit mita tarvittiin
pop cx                                                    ;
pop dx                                                       ;
;.
;.                                                taalla jatkuu paaohjelma ...
;.
;.
;hlt                                               ; tamakin on testausta varten
jmp paaohjelma                                    ; ehdoton hyppy alkuun


xasento:
mov bx,edellinentilaX           ; edellinentilax kopio bx:aan
mov cx,nykyinentilaX          ; nykyinentilax  kopio cx:aan
and bx,0000 0011b           ; hukkaa ylimaaraiset loogisella AND:lla bitit,
and cx,0000 0011b            ; tarvitaan vain 0 & 1
cmp bx,cx                      ; vertaa muutoksia
jne suunta                    ; on, hypataan suunnan maaritykseen
ret                                ; ei, palataan

suunta:
mov dx,nykyinentilaX       ; kopioidaan nykyinentila
mov edellinentilaX,dx       ; edelliseksi koska muutos on huomattu
and bx,0000 0001b          ; hukataan edellisesta A-pulssi
and cx,0000 0010b         ; ja nykyisesta B-pulssi
sar cx,1                       ; rullataan yksi bitti oikealle, etta saadaan bitit vertailuun                       
xor bx,cx                      ; poissulkeva TAI
je lisaa                        ; tulos yhtasuuri, hyppaa lisaa
sub koordinanttiX,1         ; erisuuri X-1
ret                              ; paluu paaohjelmaan

lisaa:
add koordinanttiX,1          ; tulos yhtasuuri X+1
ret                                ; paluu

Taisinpa keksiä aika yksinkertaisen tavan koko homman toteuttamiseen... Haluatte varmaan kuulla?

Tuon maahan TECOn servokäyttöjä ja niissä on mm. A&B-pulssiohjaus sekä ModBus-väylä.

Homman nimi on seuraava:

Karan encoderi laitetaan suoraan TECOn A&B-sisään tuloon, jolla ohjataan servon liikeita. TECO käyttää 2500ppr koodereita, joten jos karalla on samanlainen, servo seuraa karaa suhteessa 1:1.

Nyt tulee se parempi osuus. TECOssa on myös sähköinen välityssuhde, eli sillä voi vaihtaa suoraan encoderin vaikutusta pyörimiseen. Ja tämä voidaan tehdä lennossa ModBusin kautta.

Ja CuBloc tukee ModBusia, joten... Alatko jo arvaamaan? Koko paska pystytään toteuttamaan tuolla yhdistelmällä!

Lisäksi, jos halutaan nuo automaattiset kierrenousut, voi servoa käskyttää ModBusin kautta miten lystää. Lisäksi saadaa vielä DRO encoderin lähdöstä, sen luku onnistuu CuBlocilla, kun välissä on I2C:t tukeva U.S. Digitalin laskuri.
By to way, CuBlociin saa sitten niitä näyttöjä...

Se on sitten eri juttu, kuinka monella on vara TECOn servopakettiin (hinnat kylläkin huomattavasti halvempia kuin mulla, ja servot Yaskawan valmisteita), mutta voidaan katsoa hintoja kohdalleen harrastajille... Tosin minulla on tulossa servokäyttösarja harrastajaystävällisillä hinnoilla, samoin ominaisuuksin.


Muokattu:

Ja TECOlta löytyy servoja planeettavaihteisena, joten ei tarvitse rakentaa erillistä välitystä... Lisäksi nuo ohjaimet ovat automaattisäätöisiä, eli ei tarvi säätöjen kanssa leikkiä...

Linkki manuaaliin: http://www.tedmotors.com/rimages/552/PDF/TSTA-user-manual.pdf (http://www.tedmotors.com/rimages/552/PDF/TSTA-user-manual.pdf)

Ja missä hintaluokassa tämä TECO-servopaketti tulisi olemaan?

Minulla on jo sorvissa DRO joten sitä en tarvitse härpäkkeen ominaisuuslistalle. Ehkä kannattaa koettaa pitää jalat maassa ja pyrkiä toteuttamaan yksinkertainen vaihdelaatikon korvaaja ja pelkkää plussaa jos vielä samaan saa helposti x-akselin syötön niin saisin ehkä elämäni ensimmäisen kerran sorvattua oikean mittaisen morse-kartion.

Lainaus käyttäjältä: Jonne - 02.01.10 - klo:12:59
Tottakai inkrementaalisesta anturista nähdään kumpaan suuntaan se pyörii, vai tarkoitatko nyt jotain muuta..?

Tarkoitin että yksinkertainen pulssianturikin on inkrementaalianturi. Niin on myös kvadratuurienkooderi, mutta vain siitä näkee pyörimissuunnan. Tähän sovellukseen riittänee yksinkertainen pulssijono josta ei selviä pyörimissuunta. Sehän taas selviää siitä, kumpaan suuntaan karan on käsketty pyöriä, eikä kai edes sillä ole väliä (no, ehkä on). Mutta oikeasti saattaa rittää pelkkä indeksipulssi josta pyöriminen lasketaan.

Lainaa
Ei mitään enable-signaaleja, vaan rele mikä pystyy katkaisemaan kaiken. Sähköt eivät saa tulla takaisin hätäpysäytyspainiketta nostamalla, vaan pitää olla myös erillinen kuittauspainike. Enable-signaalin voi kyllä ohjaus vetää ylös käynnistyksessä, ja pudottaa alas, jos huomaa jotain epänormaalia. Lisäksi isommat koneet tarvitsevat erillisen turvareleen. Näin sanoo laki.

Turvapiirteitä voidaan hyvin kehitellä tässä ajan kanssa. Ehdotuksesi kuullostavat järkeenkäyviltä ja niillä voi minun puolesta jatkaa etenpäin.

Lainaa
Itse en ole vieläkään innostunut kierteen sorvauksesta automaattisesti, trapetsi ei kauan käryä moista käyttöä, jos vauhdit ovat riittävät... Ja miten hallitaan työkalun mitta? Vedetään ensin yksi kierre ja todetaan kierteen menneen yli, otataan uusi aihio, ja nollataan hiukan kauemmas terä? Eiks mene hiukan manuaalisorvin idea?

Luulen ettei kaikki ole nyt ihan ymmärtänyt omaa ideaani kierteytyksestä, se toimii aivan kuin oikeassa sorvissa, eli trapetsipyörii karan mukana molempiin suuntiin. Eli missään vaiheessa ei irroteta yhteyttä karan ja trapetsin välillä, kierteen alkuun päästään vaihtamalla karan suuntaa.

Miten se kartion sorvaus ja kierteen sorvaus kuluttavat trapetsia (johderuuvia?) eri tavalla? Vai ymmärränkö jotain väärin. Minulle kierteitys on ollut tämmöinen ajatus:
1. ajetaan kelkka kierteen aloituskohtaan ja merkataan se ohjaimelle.
2. ajetaan kelkka kierteen lopetuskohtaan ja merkataan se ohjaimelle.
3. komennetaan kelkka aloituskohtaan. Ohjaimen merkkivalo ilmoittaa kun asemassa
4. käynnistetään karan pyörintä
5. veivataan kelkan käsiruuvista terän syöttösyvyys halutuksi
6. annetaan ohjaimelle ajolupa jolloin se käynnistää kelkan liikkeen seuraavasta karan indeksin ohituksesta
7. ohjain seuraa karaa kunnes saavutaan lopetuskohtaan jolloin kelkka pysähtyy ja merkkivalo pyytää käyttäjää peruuttaman terän ulos.
8. käyttäjä kuittaa kun terä peruutettu jolloin ohjain ajaa kelkan takaisin alkuasemaan.
9. siirrytään kohtaan 5 tai kuitataan kierre ajetuksi jolloin ohjain palautuu alkutilaan.

Kartion ajaminen edellyttää tietenkin X-akselin koordinoitua liikettä jolloin sekin ohjataan siivun otossa samoin kuin kelkan liike. Jos niin halutaan, voi ohjain tieysti ohjata kierteityksessäkin nuo syötöt, mutta ei se välttämätöntä ole.
Sitä en vielä ymmärrä, miten tämä olisi automaatisesti tehtynä sen kuluttavampaa koneelle kuin manuaalisestikaan. Jos ajetaan hirmu kierroksilla ja syötöillä niin se on tietysti toinen juttu, mutta eihän se sinänsä liity automatiikkaan mitenkään. Ja joka sitä pelkää niin eihän hänen tarvitse ajaa kierteitä tällä  :P.

Lainaa
Lisäksi haudoin parametri-ideaa pidemmälle. Kiertokytkimillä pystyisi nekin asettamaan, kytkimillä haluttu arvo, ja kyseisen parametrin kuittauspainikkeella kuittaus.

Tämähän on jo aika lähellä minunkin ehdotustani, nyt keskustellaan enää kiertokytkimien lukumäärästä :)

Lainaa
Lisäksi karan enkoderi voisi olla 2500 pulssinen, niitähän nykyään nurkat pursuaa, ja saan niitä TECOlta aika kohtuulliseen hintaan. http://www.cnc-tekniikka.com/CNC-forum1/index.php?topic=970.msg5048#msg5048  (http://www.cnc-tekniikka.com/CNC-forum1/index.php?topic=970.msg5048#msg5048)

Aika kiinnostava laite jolla voisi olla monenkinlaista käyttöä. Oliko sinulla ajatusta siitä, miten mekaaninen kytkentä karaan onnistuisi parhaiten? Toisaalta edelleen mietin sitä, että tässä sovelluksessa pelkkä indeksi voi hyvin riittää. Prosessori pystyy sen perusteella laskemaan karan kierrokset matemaattisesti oikein, kysymykseksi vain jää horjuuko karan nopeus kierroksen aikana niin paljon että sitä pitäisi seurata nopeammin kuin kerran kierroksella.

Lainaa
Ei konekieli ole masokismia, se on tehokasta  ;). Konekielellä saa aikaiseksi mukavan elegantteja ratkaisuja. Itse olen näköjään tehnyt pari vuotta sitten enkoderinlukuun konekoodin x86-prossuille, ilman sen kummempaa kokemusta (silloin):

http://www.cnc-tekniikka.com/CNC-forum1/index.php?topic=197.msg453#msg453 (http://www.cnc-tekniikka.com/CNC-forum1/index.php?topic=197.msg453#msg453)

Ettei sinussa kuitenkin asuisi pieni masokisti, et vaan ole huomannut?  :P
Olen tienannut jopa leipää pöytään kirjoittamalla assembleria melkein kaikille Intelin prosessoreille pentiumeja lukuunottamatta (niille ei enää pysty jaksamaan). 8080, 8085, 8051,8086,186,286,386,486 ovat tuttuja mutta ei kyllä tule assembleria ikävä  :D. Ainakin Intelin prosessoreille on sitäpaitsi näinä päivinä tosi haaste kirjoittaa tehokkaampaa assya kuin mitä nykyiset koodigeneraattorit suoltavat. Joissakin tarkkaan rajatuissa täsmäoperaatioissa ehkä, mutta silloinkin vain ehkä. Sitäpaitsi esim tuo enkooderilogiikka on jo sisäänrakennettu ATXMEGAan, heität jonkin timerin rekistereihin anturin pulssiluvun ja määrittelet kanavien ja indeksin inputit niin voit suoraan lukea karan kiertymäkulman rekistereistä reaaliajassa. Eikä edes sitä tarvitse välttämättä tehdä kun voit kytkeä toisen timerin orjaksi askeltamaan moottorin sekvenssiä suoraan tapahtumaväylän kautta ilman yhtään käskyä - assembleria tai C:tä. XMEGA:ssa tuli uutena toimintona vielä Advanced Waveform Generation jolla voi suoraan prosessorin rautatasolla generoida mm. juuri stepperin askellussekvenssejä. Atmelin prosessorien arkkitehtuuri on lisäksi erityisesti suunniteltu "C-ystävälliseksi" joten veikkaan AVR_GCC:n ja muiden vastaavien kääntäjien tuottavan keskimäärin tehokkaampaa koodia kuin mihin ihminen pystyy assemblerilla. Minä en ainakaan vaivautuisi yrittämään koska mitalia ei ole luvassa :)

Lainaus käyttäjältä: Jonne - 02.01.10 - klo:13:39
Taisinpa keksiä aika yksinkertaisen tavan koko homman toteuttamiseen... Haluatte varmaan kuulla?

Tuon maahan TECOn servokäyttöjä ja niissä on mm. A&B-pulssiohjaus sekä ModBus-väylä.

Joo kyllä, mutta eikös tässä oltu rakentamassa ohjainlaitetta? Tämä jos mikä alkaa haiskahtaa CNC-systeemin rakentamiselta jos kaikennäköiset Modbussit ja muut astuu kuvaan mukaan... Minä ilmoittauduin koodaajaksi jos ohjainta lähdetään tekemään alusta alkaen ja se on edelleen minun päämotiivini tässä asiassa. Integrointi valmiista palikoista on toki lopputuloksen kannalta hyödyllistä, ehkä helpompaa ja varmasti nopeampaa. Ei kuitenkaan minua samalla tavalla kiinnostavaa. Valmiita ratkaisujahan saa aina kaupasta - jos vain lopputulos kiinnostaa niin onhan se ELS-rakennusarjakin olemassa. Sen saa parilla sadalla.
Jokainen tekee tietty mitä haluaa. Tässä keskustelussa ei varmaan kumminkaan päästä hirveästi eteenpäin ennenkuin päätetään mitä ollaan tekemässä. Onko hanke ohjaimen suunnittelu alusta alkaen, vai integrointi valmiista palikoista?

Kremmenin näkemys siitä miten kierteitys tehdään vastaa täysin minun käsitystä asiasta. Valmis rakennussarja ELS tekee kuta kuinkin tämän saman ja pystyy tarvittaessa myös X-akselin ohjeukseen jolloin käsityönleima jää kokonaan pois.

Minun kokemuksella ohjeuksista ja askelmoottoreista ei juuri voi paukutella henkseleitä. C/C++ -koodaus kyllä tarpeen mukaan onnistuu ja mekaniikan asennus, muuten tarvitsen valmiiksi mietityn ratkaisun. 

Jeps, kyllä tuo kiertetysidea kuullostaa ihan järkevältä, jää pois turhat hömpötykset.
Tarkoitin tuolla stapetsin kulumisella sitä, että jos pyritään vetämään kierteitä kuten NC-kone vetää, strapetsin mutterista ei ole kuin muisto jäljellä, siksi on olemassa kuularuuvit...

Mutta en ajan laskemisesta Z-pulssin perusteella ole innostunut, pienissä koneissa karan inertia on niin pieni, joten nopeus voi muuttua kierroksenkin aikana jo liikaa. Mielummin suora A&B-seuranta, ainakin on viimeisen päälle. Z:lla haetaan vain kierteen alku.

***

Lainaa
Aika kiinnostava laite jolla voisi olla monenkinlaista käyttöä. Oliko sinulla ajatusta siitä, miten mekaaninen kytkentä karaan onnistuisi parhaiten?

Helpointa olisi tuupata karan päähän suoraan, mutta ei saa sitten tankoa karasta läpi. Isompiin koneisiin hammashihnalla välitys, maybe?

LainaaEttei sinussa kuitenkin asuisi pieni masokisti, et vaan ole huomannut?  :P

Voi ehkä muuten ollakin  ::), mutta jotenkin oma luonteeni vaatii aina tietämään miten kaikki toimii ja konekieli on juuri yksi yhteen mitä CPU tekee.

Rakentelin joskus muinoin TTL-logiikasta CPU:n, kun oli pakko tietää miten se toimii...

***


Tuo TECON yhdistäminen CuBlociin olisi vain aika helposti hahmotettava homma, moni ymmärtäisi toiminnan, koska CuBloc ohjelmoidaan BASIC kielellä. Monelle C tai konekieli on täyttä jargonia. Ja on tuossa CuBlocin yhdistämisessä TECOon hommaa ihan kylliksi. Voisin kyllä tehdä viikon-kahden päästä proton tosta hommasta.

CNC-systeemin kanssa homalla ei ole mitään tekemist, koska CuBloc on sen verran hidas, sehän ei muta tekisi kuin vaihtaisi virtuaalista välityssuhdetta ModBusin välityksellä.

Minähän en mistään koneistamisesta mitään tiedä, mutta kun kierteitä olen sorvin tapaisellani tehnyt, olen aina pyöritellyt sorvin pakkaa käsin.. Kyllä se olisi hienoa, jos näin voisi tehdä ja peruuttaa moottorilla takaisin alkuun, terän ilman mekaanista kytkentää seuratessa...

Mutta minäpä alan nyt piirtelemään rautaa.... Teen siitä useamman version eri prosessoreilla ja vaikka erilaisilla käyttöliittymillä niin on sitten jokaiselle mieleinen. Eri versiot kun mahtuvat ihan hyvin tuonne koneeseeni.

Tutkin noita ehdotettuja stepperiohjaimia ja etsiskelen hieman muitakin vaihtoehtoja... Jotenkin houkuttaisi suuremmat jännitteet ja virrat, vaikka suojajänniterajat ylittyisivätkin.

Mihinkäs prosessoriin Jonne olitkaan eniten mieltynyt?

Lainaus käyttäjältä: ram - 02.01.10 - klo:15:45
Minähän en mistään koneistamisesta mitään tiedä, mutta kun kierteitä olen sorvin tapaisellani tehnyt, olen aina pyöritellyt sorvin pakkaa käsin.. Kyllä se olisi hienoa, jos näin voisi tehdä ja peruuttaa moottorilla takaisin alkuun, terän ilman mekaanista kytkentää seuratessa...

Mutta minäpä alan nyt piirtelemään rautaa.... Teen siitä useamman version eri prosessoreilla ja vaikka erilaisilla käyttöliittymillä niin on sitten jokaiselle mieleinen. Eri versiot kun mahtuvat ihan hyvin tuonne koneeseeni.

Tutkin noita ehdotettuja stepperiohjaimia ja etsiskelen hieman muitakin vaihtoehtoja... Jotenkin houkuttaisi suuremmat jännitteet ja virrat, vaikka suojajänniterajat ylittyisivätkin.

Mihinkäs prosessoriin Jonne olitkaan eniten mieltynyt?

Kelkan liikkeen ohjauksessa ei mikään luonnonlaki estä kelkkaa seuraamasta vaikka pakkaa pyöritettäisi käsinkin. Jos siis sellainen toiminto halutaan. Tällöin kyllä tulee tietää kumpaan suuntaan pakka sattuu milloinkin pyörimään, joten tarvitaan kvadratuurienkooderi. Siitä en ole selvillä mitä käyttöturvallisuusmääräykset tämmöisestä sanovat, jos mitään. Ehkä muilla on parempi käsitys asiasta.

Nuo mainitut stepperiohjaimet oli vain ehdotuksia, varmaan löytyy muita yhtä hyviä ja parempiakin. Meinaatko oikeasti ettei 48V*4A = 192W riittäisi johtoruuville? Vaikka saahan sitä potkua olla, kunhan tehdään virranrajoitus ajatuksella niin moottori voi olla pienempikin.

Kainosti edelleen taas mainostan noita Atmelin tekeleitä prosessoria valittaessa, kyllä XMEGA istuu tähän sovellukseen kuin nenä päähän. Jollei ole aiemmin tuttu, niin tietoa löytyy täältä http://www.atmel.com/dyn/products/product_card.asp?PN=ATxmega128A1 (http://www.atmel.com/dyn/products/product_card.asp?PN=ATxmega128A1)

Näyttää tämä aihe lyhyen ajan sisällä saaneen täällä sellaisen innostuksen aikaan, että voisi olla suuremmankin huomion kohde. Tähän saakka käyty keskusteluhan vaikuttaa tuotekehityksen alkuvaiheen ideoinnilta, jossa kaikki ajatukset ovat sallittuja. Aivan kuten asiaan kuuluukin.

Olisiko ideaa siinä, että  perustaisin foorumille oman alueensa, jonka nimi voisi olla esimerkiksi "cnc-tekniikka.com 'in kehitysprojektit" taikka jotakin siihen suuntaan??  Ja tämä puheena oleva asia olisi siellä ensimmäinen projekti, jolle olisi siis oma erotettu paikkansa.

Siis eihän omalla alueella olemisella muuten ole mitään eroa tuolla muualla sijaitsevien juttujen kanssa, mutta ajatuksena olisikin se, että tuolle alueelle siirretyistä keskusteluista pyrittäisiin saamaan aivan oikean tuotekehitysprojektin tyyppisiä, joiden tuloksena on kohtalaisen valmis tuote ja erityisesti myös sen kunnollinen dokumentaatio käyttöohjeita ja CE-merkinnän mahdollistavia teknisiä rakennetiedostoja myöten. Projekteihin voisi ilmoittautua osallistujaksi ja halukkaat voisivat ottaa noista projekteista itselleen tiettyjä asioita tehtäväksi. Esimerkiksi juuri dokumentaation tekeminen muuten aivan liian helposti unohtuu.

Ja jos jotakin kaupallisesti hyödynnettävää noista kehittyy, niin projektiin osallistuvat voisivat poimia sieltä erilaisia osia, joita haluavat ryhtyä kenties valmistamaan. Vapaata kilpailua siis, mutta voisi toimiakin, koska se, joka ehtii ensimmäisenä sieltä saada myytävää aikaiseksi saattaisi pärjätäkin. Sekin on mahdollista, että cnc-tekniikka.com 'iin perustetaan pieni webbikauppa, jonka kautta noita sitten voi myydä, jos ei itsellä ole myyntikanavaa tai halukkuutta siihen. Siis verkostoitunut kehitys- ja myyntikanava, jossa cnc-tekniikka.com toimisi tukena kuten yleensäkin tässä foorumissa on jo vuosia toiminut. CNC-tekniikka.com'in webbikaupan kautta myytäessä cnc-tekniikka.com saisi välistä pienen myyntiprovision, joka mahdollistaisi homman kehittämistä edelleen.

Luonnollisesti työn tulokset olisivat kaikkien vapaasti hyödynnettävissä, mutta tuo "projektialue" voisi olla vierailijoilta suljettu. Siis ei anneta ihan kaikkea täälläkään kaikkien luettavaksi, vaan vaivaa pitäisi nähdä ainakin rekisteröitymisen verran. Tälle foorumille on myös helppo perustaa jäsenryhmiä, joille voi antaa erityisoikeuksia tietyille alueille pääsyyn. Näin ollen kaiken kehittämiskeskustelun ei tarvitse näkyä aivan kaikille.

No... pikainen ideointi oli tuo ilman suurempaa itsekritiikkiä. Mitä mieltä asiasta?

LainaaMihinkäs prosessoriin Jonne olitkaan eniten mieltynyt?

Kyllähän muakin tuo ATMEL kiinnostaa, on siinä sen verran paljon paukkua...

Tuolta saa kivaa kehitysalustaa ATMELille: http://www.mikroe.com/en/tools/bigavr2/ (http://www.mikroe.com/en/tools/bigavr2/)

Lainaa
Ja missä hintaluokassa tämä TECO-servopaketti tulisi olemaan?

Muutamia satasia, riippuu tehosta. Tehot alkavat 50W aina 15000W:hen. Pelkkiä ohjaimiakin saa, jotain 250-300 euroa 750W:nen ohjain. Nuo ohjaimet ottavat suoraan verkkosta sähkönsä, ja sopivat useimpien servojen kaveriksi. Servot ja kaapelit sitten erikseen, mutta eipä nekään kalliita ole TECOlla, hintaa ei tule ihan mahdottomasti per akseli.

Lainaus käyttäjältä: Konemies - 02.01.10 - klo:17:45
Näyttää tämä aihe lyhyen ajan sisällä saaneen täällä sellaisen innostuksen aikaan, että voisi olla suuremmankin huomion kohde. Tähän saakka käyty keskusteluhan vaikuttaa tuotekehityksen alkuvaiheen ideoinnilta, jossa kaikki ajatukset ovat sallittuja. Aivan kuten asiaan kuuluukin.

Olisiko ideaa siinä, että  perustaisin foorumille oman alueensa, jonka nimi voisi olla esimerkiksi "cnc-tekniikka.com 'in kehitysprojektit" taikka jotakin siihen suuntaan??  Ja tämä puheena oleva asia olisi siellä ensimmäinen projekti, jolle olisi siis oma erotettu paikkansa.

Täältä heti 1 peukalo ylös tälle ajatukselle  ;D

Ja jos laitat tuon pystyyn niin ilmoittaudun tähän projektiin ohjelmoijaksi mikäli homma tai jokin osa toteutetaan AVR-prosessoreilla.
Jos projektit tarvitsevat/haluavat "projektipäällikköä" voin olla vapaaehtoinen sellaiseenkin, mitenkään kuitenkaan vänkäämättä jos joku muu tuntee sen homman omakseen.

Lainaus käyttäjältä: Jonne - 02.01.10 - klo:17:51
Tuolta saa kivaa kehitysalustaa ATMELille: http://www.mikroe.com/en/tools/bigavr2/ (http://www.mikroe.com/en/tools/bigavr2/)

Katos perhana en ollut tuommoista linkkiä vielä löytänytkään. Siellähän näyttää olevan mielenkiintoista tavaraa, pitääpä tutustua ajan kanssa.

Lainaa
Katos perhana en ollut tuommoista linkkiä vielä löytänytkään. Siellähän näyttää olevan mielenkiintoista tavaraa, pitääpä tutustua ajan kanssa.

Jos kellään ei ole mitään vastaan, voitaisiin käyttää tuota levyä, hinta ei minusta ole yhtään paha. Lopullinen versio sitten ihan omalle levylle, ylimääräiset pois.

Kuulemma nuo Mikroelektronican kääntäjät ovat hiukan bugisia, ainakin BASIC, mutta eiköhän niillä selviä. Ja kaipa tuon kanssa voi käyttää mitä kääntäjää haluaa.

Mikroelektronican BASIC-kääntäjä mahdollistaa ihanan  :P : konekielen sotkemisen BASICin sekaan. BASIC olisi monelle, kuten myös minulle, huomattavasti selkokielisempää kuin C++, jolloin muutkin tajuaisivat koodin toiminnan kuin C-kielen hallitsevat. Eiköhän tuossa MEGAssa ole sen verran voimaa, jotta sen voi tehdä kökömmilläkin kielillä, encoderien luku ja muut tiukat paikat konekielellä.

Täältä voi tsekata ominaisuuksia:

http://www.mikroe.com/en/compilers/mikrobasic/avr/ (http://www.mikroe.com/en/compilers/mikrobasic/avr/)

Mutta jos yleisesti ollaan sitä mieltä, että se pitää tehdä C:llä, niin ei minulla sitä vastaankaan ole mitään.

No mikä ettei, että homma saisi tällaisen käänteen...

Tuota elektroniikkapuolta voisin edistää tässä projektissa. Pistän sitten vaikka sinne uuteen osastoon tulemaan sitten skemaluonnoksia kommentoitaviksi. Konsensuksen saavutettuamme saisi jyrsittyjä levyjä aika nopeasti softakehitykseen.

Moi
Kannatan tuota atmellia prossuksi.
Itsellä oli joskus konesahassa paikkaa laskemassa joku avr taisi olla 163:monen 6Mhz kiteellä.
Siinä oli pulssianturina 2000/rev ja kaikki reunat laskettiin, jolloinka laskettavaa realiajassa tuli 8000pulssia per kierros.
Testasin porakoneella pyörittäen jotain 1200 r/min hyvin laski ei mitään ongelmia, vaikka vatkasi kierroksia ees taas.
Sisäänmeno oli keskeytys pohjainen.

Se oli silloin vuosituhannen vaihteessa joskus tai vähän jälkeen.
Jos nyt pistää toin 128:n niin on killeri vehje.

Mullakin on laatikon pohjalla jotain valmista korttia jos tarvitaan.
Lähinnä kokeiluihin.

Tuo Jonnen käyttöliittymä  kiertokytkimin  ja sisään syöttönapilla on ihan hyvä,
jotta saadaan simppeli graaffinen näyttö ja näppäimistö.
Painettaessa jotain nappia on isäntä ainakin hiukan hereillä ,mitä nyt tapahtu.
Ensin mietin että kytkinten asento voitaisiin lukea hetken kuluttua niiden muuttamisesta sisään,
mutta ei hyvä, se on silloin jonkin asteen automaatti.



Hannu

Luin tänään ulkomaalaisia CNC forumeita ja ELS:istä
ollaan monta mieltä.Täydellistä toteutusta ei taida
vielä olla kenelläkään.
Itse ajattelin Itx emoa ja

http://www.fricktion.net/~mfrick/lathe/els/ElsDoc_v0_1.pdf

Lainaus käyttäjältä: Jonne - 02.01.10 - klo:18:35
Jos kellään ei ole mitään vastaan, voitaisiin käyttää tuota levyä, hinta ei minusta ole yhtään paha. Lopullinen versio sitten ihan omalle levylle, ylimääräiset pois.

Kuulemma nuo Mikroelektronican kääntäjät ovat hiukan bugisia, ainakin BASIC, mutta eiköhän niillä selviä. Ja kaipa tuon kanssa voi käyttää mitä kääntäjää haluaa.

Mikroelektronican BASIC-kääntäjä mahdollistaa ihanan  :P : konekielen sotkemisen BASICin sekaan. BASIC olisi monelle, kuten myös minulle, huomattavasti selkokielisempää kuin C++, jolloin muutkin tajuaisivat koodin toiminnan kuin C-kielen hallitsevat. Eiköhän tuossa MEGAssa ole sen verran voimaa, jotta sen voi tehdä kökömmilläkin kielillä, encoderien luku ja muut tiukat paikat konekielellä.

Täältä voi tsekata ominaisuuksia:

http://www.mikroe.com/en/compilers/mikrobasic/avr/ (http://www.mikroe.com/en/compilers/mikrobasic/avr/)

Mutta jos yleisesti ollaan sitä mieltä, että se pitää tehdä C:llä, niin ei minulla sitä vastaankaan ole mitään.

Kortti käy kyllä noin periaatteessa mutta kannattaa huomata, että nuo kaikki näyttivät olevan atmega128 ei atXmega128. Yhden X:n ero on tässä aika iso... Luulenpa että onnistuu kyllä mega128:llakin, joskaan niitä Xmegan erityispiirteitä ei sitten pysty soveltamaan.
Jos ram pystyy meille kortit tekemään niin pitäiskö kuitenkin miettiä tuota vielä. Protolautoina nuo kortit ovat hyvinkin kiinnostavia, mutta tähän ohjaimeen niissä on toisaalta aika paljon tarpeetonta ja toisaalta vähän puutteita. Liikahan ei sinänsä haittaa kun ei nuo ole hinnalla varsinaisesti pilattu. Tuota sinun toivomaasi käyttöliittymää ei tuohon taida kyllä saada kun siinä ei noita kiertovalitsimia ole. Mahtoiko olla yhtään kappaletta?

Siitten sorry vaan jos olen taas kovin negatiivinen, mutta mä olen sen verran jotain... omasta mielestä ammattilainen, muiden mielestä varmaan vaan pösilö, että en rupea enää tässä iässä työstämään basicilla. Kun minusta se vaan ei ole C:n veroinen tällaisissa hommissa. Jonnekin kehuu ensin assembleria mutta menee sitten ehdottamaan basiccia, mitäs tästä nyt pitäisi ajatella  :P Tiedän kyllä, että basiccia näkee mutta mitä vetoa että missä sitä on käytetty on liki kaikki muutaman sadan koodirivin kyhäelmiä, ei sen isompia.
Minä olen jo sen verran vanha pieru, että kun on 80-luvulta asti koodattu sitä assya, PL/M:ää, C:tä, C++:aa ja loppuviimeksi jaavaa jotka kaikki on selkeästi sukulaisia niin ei pysty taipumaan enää muuhun. Jos basic on tiukka vaatimus niin sitten minä kiitän ja kumarran. Ellei, niin käviskö että ne jotka koodin kirjoittaa saa valita kielen  ;)?
Jonne olet siinä oikeassa, että koodin toiminta pitää tehdä selväksi. Se, että koodi dokumentoisi itsensä on kuitenkin niin huono periaate, että oikeasti pitää dokumentointi perustaa muuhun kuin siihen, että käytetty kieli on riittävän helppoa ymmärtää. Speksit, ainakin jonkinlaiset, pitää kirjoittaa ihan teksteinä, ja lähdekoodin dokumentoinnissa ilmainen Doxygen http://www.stack.nl/~dimitri/doxygen/ (http://www.stack.nl/~dimitri/doxygen/) on hyvin yleisesti käytetty ja toimii fiksusti sekä linukassa että windowsilla. Ei vaan valitettavasti basicille.
Doxygenistä sanotaan sen helpin esittelyssä näin:

Introduction
Doxygen is a documentation system for C++, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavors), Fortran, VHDL, PHP, C#, and to some extent D.

It can help you in three ways:

It can generate an on-line documentation browser (in HTML) and/or an off-line reference manual (in ) from a set of documented source files. There is also support for generating output in RTF (MS-Word), PostScript, hyperlinked PDF, compressed HTML, and Unix man pages. The documentation is extracted directly from the sources, which makes it much easier to keep the documentation consistent with the source code.
You can configure doxygen to extract the code structure from undocumented source files. This is very useful to quickly find your way in large source distributions. You can also visualize the relations between the various elements by means of include dependency graphs, inheritance diagrams, and collaboration diagrams, which are all generated automatically.
You can even `abuse' doxygen for creating normal documentation (as I did for this manual).

Hups ,nuo mun proto kortit oli ilman tota X:ää.

Jos jyrsimällä ei pääse riittävän pieniin väleihin niin pystyn tekemään esi proton
filmille ja syövyttämään vaikka kaksipuoleisena.

Tuolla tuo PCI_GT:jpg esim. huomaa tuo iso lutikka tinattu onnistuneesti.
http://www.cnc-tekniikka.com/CNC-forum1/index.php?topic=304.15

Lainaa

Painettaessa jotain nappia on isäntä ainakin hiukan hereillä ,mitä nyt tapahtu.
Ensin mietin että kytkinten asento voitaisiin lukea hetken kuluttua niiden muuttamisesta sisään,
mutta ei hyvä, se on silloin jonkin asteen automaatti.

Juu, ja kiertokytkimet voisi lukea aina yksi kerrallaan, sitten tarvitaa vain neljä inputtia ja jokaiselle kytkimelle oma output.

Lainaa
Jonnekin kehuu ensin assembleria mutta menee sitten ehdottamaan basiccia, mitäs tästä nyt pitäisi ajatella  :P

No varmaan sitä, että BASIC on selvätajuisin vaihtoehto. Assemblerkin on helppotajuisempaa kuin C... Konekielen viehätys onkin juurikin siinä yksinkertaisuudessa ja helppotajuisuudessa.

Lisäksi nykyiset BASICit ovat tehokkaita ja jokainen kotikutoinen ohjelmoija (kuten allekirjoittanut) sitä osaa. Itse kyllä opettelisin mieluusti C:n, jos olisi ylimääräistä aikaa, mutta nykyisin se on kortilla. Tietysti nythän olisi tilaisuus opetella....

Eli omasta puolestani sen saa koodata vaikka FORTRANilla, jos tarpeeksi löytyy kiinnostuneita. Tietysti yksi vaihtoehto olisi Coridium ARM, johon löytyy BASIC-käännin, muistaakseni paukutti miljoona riviä sekunnissa BASIC-koodia, ja on ohjelmoitavissa normaalin nettiselaimella ja ethernetin kautta. Protolevy maksaa jotain 50$. I/O:ta ei kamalasti ole, mutta luultavasti tähän lystiin riittävästi... Yritän kaivaa nettisivun esiin Googlella...

Lainaa
Tuota sinun toivomaasi käyttöliittymää ei tuohon taida kyllä saada kun siinä ei noita kiertovalitsimia ole. Mahtoiko olla yhtään kappaletta?

Eipä tainnut olla, mutta siinähän on I/O-portit. DIPeillä voi simuloida kiertokytkimien asentoja, jos ei raaski ostaa.

Sehän löytyikin nopeasti, 60Mhz ARM7, BASIC-kääntäjällä:

http://www.coridiumcorp.com/index.php (http://www.coridiumcorp.com/index.php)

Itselläni on yksi tuossa jemmassa, mutta ei ole juuri tullut testailtua... Pitääkin kokeilla lähiaikoina...


Muokattu:

Ilmoitinkin väärin tuon nopeuden: Coridium pystyy suorittamaan 10 miljoonaa riviä (!!!) BASICiä sekunnissa ja yhteen miljoonaan I/O-suoritukseen sekunnissa. Ja kuka väitti ettei BASICit ole nopeita...

Lainaus käyttäjältä: Jonne - 02.01.10 - klo:21:51
Sehän löytyikin nopeasti, 60Mhz ARM7, BASIC-kääntäjällä:

http://www.coridiumcorp.com/index.php (http://www.coridiumcorp.com/index.php)

Itselläni on yksi tuossa jemmassa, mutta ei ole juuri tullut testailtua... Pitääkin kokeilla lähiaikoina...

No juu, onhan ARMit ihan tehokkaita laitteita. Tällaisessa sovelluksessa ei vaan oikein pääse hyötymään 32-bittisyydestä kun se aritmetiikka nyt ei lopulta ole niin hirveän haasteellista (joissain paikoissa 32 bittiä ja enemmänkin on kyllä tarpeen). Noin periaatteessa turhan leveä arkkitehtuuri tekee ne paljon yleisemmät bittioperaatiot vaan raskaammiksi, vaikka ei tuolla oikeasti varmaan mitään merkitystä ole. Prosessorin vääntö kyllä peittää sen. Onhan Atmelillakin toki vastaavia AVR32-tuoteperheessä mutta taitavat tehdä toteutuksesta työläämmän tuomatta paljoakaan vastapainoksi. Mutta jos kiinnostaa aidoasti sairas vääntö niin otetaan Atmelilta DIOPSIS 940HF moniydinkontrolleri. Vaikka koko verstaan koneiden cnc saadaan laskettua sen signaaliprosessorilla, siitä kun lähtee miljardi liukulukuoperaatiota sekunnissa   ::)

Käytä vaan tilaisuus hyväksi ja opettele C. Eläin ei siihen pysty mutta ihminen kyllä. Ja melkein veikkaan ettei sen jälkeen paluuta basicciin enää ole...

juhannusruusu, kai tässä pitää taipua nykykehityksen alla  ;)

Milloin pystyisit tekemään alustavan C-koodin pohjan kommentoituna (mieluiten siten, että jokainen "VOID" sun muu on selitettynä, miten toimii mikin ja miksi), tässä saataisiin sitten pikakurssi C-kieleen koko porukka. Lisäksi jos saa esittää tyhmiä kysymyksiä C-kielestä projektin aikana, voisin luulla että tuon voisi oppiakin. Kuitenkin, kielihän se vain on muiden joukossa, eikä taida moderneista BASICeistä juuri erota? Mitä joskus C:tä opiskelin (ennen turhautumista), siitä tuli jollain tapaa mieleen konekieli, bittirullausta ja sen sellaista...

Mutta: mitä C(++)-käännintä käytettäisiin? Itseäsi kiinnostaa tuo Mikroelektronikan kääntimet, vaikuttavat erittäin monipuolisilta ja "helpoilta", ilman turhaa jargonia, ohjelmointilaitteita tai muuta skeidaa. Lisäksi saman talon kehityslevy kiinnostaisi jo tulevia projekteja ajatellen. Huomasitko muuten sen firman sivuilta, että siellä on tuota kehityslevyä vaihdettavilla mikrokontrollereilla, joten samaa levyä voi käyttää useamman eri valmistajan kontrollereihin?

Juu... C:tä mielellään opiskelisi. Aika on vaan aina kortilla. C-ohjelmia olen kyllä kirjotellut, kun siirryin Linuxin käyttöön ja siinähän on kaikki kivat editorit ja kääntäjät helposti ulottuvilla. Sillä GCC kääntäjällä tekee koodin kai vaikka PICeille ja atmelleille... kuulemma... ja kai vissiin vaikka millä kielellä... En ole ehtinyt enempää hämmästelemään.

Oppimateriaalejakin tuli haalittua ja olen niitä lueskellut, mutta ei se pelkkä lukeminen riitä. Mihin kaikki aika häviää ??

Eräässä VTT-projektissa jututin heidän ohjelmointigurujaan ja he sanoivat nykyisten C-kääntäjien tuotoksen pärjäävän kirkkaasti assembler-gurujen koodille. Ovat kuulemma sen verran jo hiottuja työkaluja.

Sama vika rahikaisella, että näin rautakeskeisenä miehenä tuo assembleri on jotenkin luonnollista. Kaikki korkeamman tason kielet kun muuttuu abstrakteiksi.

Nimim.. Esittävän taiteen ystävä

Lainaus käyttäjältä: Jonne - 02.01.10 - klo:23:32

Milloin pystyisit tekemään alustavan C-koodin pohjan kommentoituna (mieluiten siten, että jokainen "VOID" sun muu on selitettynä, miten toimii mikin ja miksi), tässä saataisiin sitten pikakurssi C-kieleen koko porukka. Lisäksi jos saa esittää tyhmiä kysymyksiä C-kielestä projektin aikana, voisin luulla että tuon voisi oppiakin. Kuitenkin, kielihän se vain on muiden joukossa, eikä taida moderneista BASICeistä juuri erota? Mitä joskus C:tä opiskelin (ennen turhautumista), siitä tuli jollain tapaa mieleen konekieli, bittirullausta ja sen sellaista...

Varmaan voisi aloittaa silleen, että kasataan ensin porukalla läpikäyden karkealla tasolla toiminnalliset kokonaisuudet omiksi lohkoikseen ja hahmotetaan niiden toiminnallisuus koodin rakenteeksi. Tässä vaiheessa ei vielä edes tarvita varsinaista leipäkoodia vaan voidaan mennä pitkälti modulien rajapintojen esittelyn tasolla. Tämä  siis tapahtuu jo C-kielellä mutta ei vielä kanneta huolta varsinaisesta koodista vaan rakennetaan ensin kunnollinen toimiva "rautalankamalli". Tässä vaiheessa on hyvä järkeillä joukolla läpi koodin toiminta-ajatus ja  dokumentoida se sisään noihin lähdekoodimoduleihin vaikka sitä Doxygeniä käyttäen (ei ole vaikeeta). Siinähän tulee tutuksi samalla sekä koodin ajateltu toiminta että C:n muotokieli. Voisin saada viikon-parin sisään aika uskottavan rungon aikaan. Tässä tietysti tulee jossain vaiheessa se hetki että pitää siirtyä konkretiaan eli on pakko tietää mikä prosessori ja millaiset oheiskomponentit on käytettävissä. Aivan alussa on ehkä parempikin hahmottaa ilman niitä muutta maaliin päästään vasta kun nuo on tiedossa.
Kysymyksiä varmaan joudutaan esittämään kaikki, eikä vain ohjelmointikielistä. Ja onhan täällä muitakin C-taitoisia että vastaukset sille puolelle löydetään kyllä. Mielelläni autan C:n omituisuuksien ymmärtämisessä, vaikka ei me varmaan pyritä kaikkein kummallisimpia rakenteita tähän toteutukseen pesiyttämään. Kuten totesit se on vain kieli muiden joukossa. (Tähän kohtaan pitää muistaa mainita sellainen viisaus, että oikea vanhan liiton koodari pystyy kyllä ohjelmoimaan Fortrania millä tahansa ohjelmointikielellä  ;D).

Lainaa
Mutta: mitä C(++)-käännintä käytettäisiin? Itseäsi kiinnostaa tuo Mikroelektronikan kääntimet, vaikuttavat erittäin monipuolisilta ja "helpoilta", ilman turhaa jargonia, ohjelmointilaitteita tai muuta skeidaa. Lisäksi saman talon kehityslevy kiinnostaisi jo tulevia projekteja ajatellen. Huomasitko muuten sen firman sivuilta, että siellä on tuota kehityslevyä vaihdettavilla mikrokontrollereilla, joten samaa levyä voi käyttää useamman eri valmistajan kontrollereihin?

Sellainen onnellinen tilanne, että voi käyttää vaikka useita eri kääntäjiä. C on kielenä kohtuullisen hyvin standardoitu joten eri kääntäjät tuottavat samasta sorsakoodista samoin toimivaa binääriä. Mikroelektronikan kääntyrit on varmaan ihan kelpoja, mutta ne penteleet maksavat, jotain 250 taalaa. Atmelilla on tämä ilmainen AVR Studio IDE joka käyttää WinAVR-koodigeneraattoria (eli siis AVR_GCC). GNU C++ joka tuossa siis on sisällä on varmasti yksi tehokkaimpia koodigeniksiä mitä löytyy enkä yhtään yllättyisi vaikka Mikroelektronika käyttäisi taustalla sitä myös. AVR Studio on todella helppokäyttöinen ja ilmaisena sen voi ottaa muitta mutkitta käyttöön kaikille jotka haluavat koodaukseen jollain tavalla osallistua. AVR Studio tukee suoraan koodin latausta kohdejärjestelmään käyttäen esim JTAG-liitäntää. Tuollainen noissa Mikoelektronikan laudoissa näytti olevan joten se puoli on kunnossa. JTAGhan on valmistajariippumaton teollisuusstandardi joten varmaan pelittää.
Melkein kääntäjää tärkeämpi kysymys on mitä ajonaikaista kirjastoa käytetään. Kielihän on vasta puoli ratkaisua, kirjastofunktiot ratkaisevat sen toisen puolen. Jos olemme tekemässä tästä edes jollain tasolla avoimen lähdekoodin projektia niin silloin tämä kysymys kannattaa ottaa aika vakavasti. Yhden valmistajan oma tekijänoikeuksin suljettu kirjasto tuntuisi vaaralliselta valinnalta koska silloin ei ole takeita sen käytettävyydestä tai kustannuksista. Ajonaikaisen kirjaston on oltava sama kautta linjan, muuten homma karkaa kädestä heti lähdössä.
Mitenkään epäilemättä Mikroelektronikan tuotteiden kelvollisuutta, ehdotan kuitenkin yllämainituista syistä että valittaisi kääntäjäksi AVR_GCC ja kirjastoksi avr-libc http://www.nongnu.org/avr-libc/user-manual/index.html (http://www.nongnu.org/avr-libc/user-manual/index.html). Nuo ovat vapaasti saatavissa ja käytettävissä, niissä on ei-kaupallinen kehittäjätaho takana ja ne ovat erittäin laajalti käytössä, joten ei ole pelkoa niiden katoamisesta yhtäkkiä. Jokainen koodaukseen osallistuva voi sitten valita itselleen sopivan IDE:n jos tuo AVR Studio ei tunnu istuvan käteen. Esim äärettömän suosittuun Eclipse IDEen saa AVR pluginin jolloin voi koodailla käyttäen Eclipseä. http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin (http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin). Jaava-koodareistahan Eclipseä käyttää ainakin kaikki ellei jopa useampikin.  :P

Tässä pikaohje miten saat heti toimivan koodausympäristön käyttäen WinAVR + AVR Studio -paketteja:

- Hae ensin WinAVR-kääntäjä täältä http://sourceforge.net/projects/winavr/files/ (http://sourceforge.net/projects/winavr/files/) - klikkaa vihreää Download now-nappia. Käynnistä asennus kun paketti on koneella. Asennus puhuu jopa suomea jos niin haluaa, mutta eipä ole isompaa tarvetta. Antaa vaan mennä läpi ehdotetuilla asetuksilla niin asentaja tekee kaiken tarvittavan käsin koskematta. Asennus avaa lopuksi selaimeen käyttäjän manuaalin (lontooksi) jota voi ihmetellä, mutta ei se tässä vaiheessa ole enempää tarpeen.
- Hae Atmelilta AVR Studio täältä http://www.atmel.com/forms/software_download.asp?fn=dl_AvrStudio4Setup.exe (http://www.atmel.com/forms/software_download.asp?fn=dl_AvrStudio4Setup.exe). Vaatii rekisteröitymistietojen antamisen mutta ei sen kummempaa. Sen jälkeen latauksen voi käynnistää sivulla joka tulee näkyviin. Lataustiedosto on aika miehekäs, 117 megaa joten siinä menee hetki. Toisaalta sitten saa kyllä studion helpissä tosi kattavan ohjeistuksen Atmelin kehitystyökaluihin. Asenna paketti taas oletusarvoilla niin asentaja hoitaa hommat toimivaan kuntoon ja löytää WinAVR-kääntäjän ilman apuja. Jos kysyy Jungo.driverin asennuksesta niin anna asentaa. Se on RS232/USB-ajuri muutamille erikseen hankittaville kehitysalustoille ja työkaluille, kuten debuggerit jne.

Kun käynnistät AVR Studion se kysyy haluatko avata olemassaolevan projektin vai luoda uuden. Alussa ei tietty ole entisiä olemassa joten uusi pitää luoda. Vaihtoehtona on C/C++ tai assembler-projekti :) Että sitäkin pääsee kyllä harjoittelemaan jos haluaa. Tässä vaiheessa pitää päättää missä hakemistossa projekti asuu ja mikä on sen käynnistystiedoston nimi. Kun nuo on valittu, saat tyhjän työtilan jossa pääohjelman tiedosto on valmiina muokattavaksi. Jos annoit nimeksi vaikka test niin pääohjelma asuu tiedostossa test.c

Perinteisesti kaikki C-ohjelmat käynnistyvät aina proseduurista jonka nimi on main, eli "pääproseduuri". C-kielinen esittely on perinteisesti:

void main(void); {
...
}

Void tarkoittaa, ettei kyseisessä kohdassa esiinny muuttujaa, eli main ei ota mitään parametreja eikä se palauta mitään. AVR Studio tuntuu kyllä tykkäävän enemmän esittelystä:

int main(void) {

jolloin main palauttaisi integer-tyyppisen muuttujan. Tällä ei ole oikeasti hevon väliä koska jos main ikinä menee loppuun eli muka palauttaisi jotain, koko sovelluksen ajo päättyy.
Mutta tämän nimine proseduuri siis on kirjoitettava ja siitä suoritus lähtee.

"Oikeat" s.o. varsinaisilla tietokoneilla ajettavat sovellukset voivat kyllä ottaa sisään komentoriviltä annettuja parametrejä eli komentoriviargumentteja, jolloin perinteinen esittely olisi

void main(int argc, char *argv[]) {

Ensimmäinen argumentti on integer-tyyppiä (prosessorin luontaisen pituinen kokonaisluku) ja sisältää komentoriville kirjotettujen erillisten sanojen lukumäärän. Sana on tässä mikä tahansa jono merkkejä jonka 1 tai useita välilyöntejä erottaa seuraavasta sanasta (merkkijonosta).
Toinen argumentti on osoitin kyseisten sanojen listaan. C-kielessähän stringi eli merkkijono esitetään puskurina jossa merkit peräkkäin ja viimeisenä heksanolla (C-tyyliin 0x00 eli null [tuo 0x tarkoittaa jäljessä tulevan numerovakion olevan heksadesimaalimuodossa]). Käytössä puskuriin viitataan sen osoitteella. Tuo konstruktio menee näin
char    = kirjaimia
       * = osoitin edellisen tyyppiseen muuttujaan
         argv = muuttujan nimi
                [] = arrayn eli jonomuuttujan esittely. Kun sulkujen välissä ei ole mitään, se tarkoittaa ettei jonon jäsenten lukumäärää tiedetä tässä vaiheessa (se on muuttujassa argc). Tästä syystä ajonaikainen kirjasto rakentaa muistiin himmelin, jossa jokainen merkkijono on peräkkäin (nullilla päätettynä) ja vielä viimeisen merkkijonon jälkeen on toinen null. Näppärä kaivaa tästä esiin kaikki käyttäjän kirjoittamat sanat ohjelman käyttöön.

No, kun olet saanut studion käyntiin niin toimivuuden voi kokeilla vaikka tämmöisellä typerällä koodinpätkällä (tämä ei siis tee mitään älykästä, kunhan työllistää koodigeneraattoria jotta nähdään kaiken toimivan).



/* typerä koodinpätkä joka ei saa mitään hyödyllistä aikaan */

int main(void) {  // perinteinen esittely

int i, x, y;       // esitellään kolme kokonaislukumuuttujaa nimeltä i, x ja y. C-kielessä muuttujat on aina esiteltävä etukäteen

   x = 0;   // nollataan ne (jotkin kääntäjät takaavat että muuttuja on nolla mutta ei kannata luottaa)
   y = 0;

   for (i=0; i<10; i++) {   // C-tyylinen silmukka laskurina i; aloitetaan nollasta, jos i alle 10 niin mennään silmukkaan, lopuksi kasvatetaan i:tä yhdellä (se on tuo i++)
      x = i;     // jotain aivottomia laskutoimituksia
      y += (x * i); // += on pikakirjoitusta ja sama kuin y = y + ...
   }    // silmukan lohko päättyy
}   // main lohko päättyy ja samalla koko suoritus

// oikeassa sovelluksessa main ei koskaan pääty, vaan ajetaan jonkinlaista ikuista silmukkaa.



Luento päättyy   ;)

Täältä kans ääni tuolle c- kielelle ja winavr:lle. varsin kiinnostava aihe jo pelkästään oppimis mielessä. laitanpa tuohon yhden vaihtoehdon. tuolle kun tekee emokortin voi käyttää muihinkin projekteihin.

http://www.olimex.com/dev/avr-hx128a1.html (http://www.olimex.com/dev/avr-hx128a1.html)

Lainaus käyttäjältä: jussi - 03.01.10 - klo:02:59
laitanpa tuohon yhden vaihtoehdon. tuolle kun tekee emokortin voi käyttää muihinkin projekteihin.
http://www.olimex.com/dev/avr-hx128a1.html (http://www.olimex.com/dev/avr-hx128a1.html)

Tuollainen helpottaa kovasti elämää jos meillä on haasteita saada jyrsimällä riittävän tiheää piirikorttia aikaan. Vähänhän tuo maksaa mutta onneksi varsin vähän kun siinä on jo prosessorikin mukana. Ja tuon 32 kHz kiteen avulla siihen saisi vielä rakennettua oikean verstaskellonkin. Lähtisi isäntäkin kahville ajallaan :)

... jatkuu
Debuggauksesta AVR Studiolla:

Jos kuka pisti tuon koodinpätkän Studioon, niin tässä ohjeita perustason simulointiin ja debuggaukseen. Aloita siten, että projekti on auki studiossa.
Ellet jo tehnyt sitä, valitaan mille prosessorille koodi generoidaan ja millä optioilla. Avaa studion päävalikosta kohta Project - Configuration options. Projektin optioikkuna aukeaa. Jos nimesit projektin "test" niin Output File Name on test.elf ja siihen ei tarvitse koskea. Valinta Device määrää mikä prosessori. Valitse joku, minulla on kehityslaudassa kiinni atmega32 joten ota vaikka se niin ohjeet pätee tarkasti. Ainoa muu mistä välitetään tällä hetkellä on kohta Optimization. Tällä määrätään mitä koodinoptimointeja kääntäjä saa käyttää. Debuggaus kaikki optimointi päällä on toivotonta koska kääntäjä säätää niin hirveästi, ettei lopputulos ole lähdekoodista jäljitettävissä kovin hyvin. Valitaan siis vaihtoehto -O0 (ei optimoida). Kuittaa OK-napista ikkuna pois.

Käännetään koodi. Päävalikosta Build - rebuild all. Käsketään kääntäjän työstää koko projekti. Käännös lähtee ja työtilan alakehyksessä pitäisi kohta näkyä tällaista:

Build started 3.1.2010 at 11:13:04
avr-gcc  -mmcu=atmega32 -Wall -gdwarf-2 -std=gnu99 -O0 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT test.o -MF dep/test.o.d  -c  ../test.c
avr-gcc -mmcu=atmega32 -Wl,-Map=test.map test.o     -o test.elf
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature  test.elf test.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex test.elf test.eep || exit 0
avr-objdump -h -S test.elf > test.lss

AVR Memory Usage
----------------
Device: atmega32

Program:     226 bytes (0.7% Full)
(.text + .data + .bootloader)

Data:          0 bytes (0.0% Full)
(.data + .bss + .noinit)


Build succeeded with 0 Warnings...

Aina pitää pyrkiä siihen, ettei kääntäjä anna yhtään varoitustakaan. Jos koodissa on suoranaisia virheitä, ei binääriä ole edes tuotettu joten koodi ei ole käytettävää. Varoitukset eivät estä koodin käyttöä joten sen voi harkiten viedä eteenpäin. Jokainen varoitus tulee kuitenkin joko hieroa pois tai sen syy tarkkaan ymmärtää jotta tietää onko se vahingollinen vai ei. Useimmat varoitukset ovat aiheellisia. No, tässä niitä ei tietenkään tullut kun tämä on näin yksinkertainen pätkä. Mega 32:lle näköjään generoitui 226 tavua koodia joka nielaisi 0,7% koodimuistin määrästä. Tässä on sitten mukana kaikki aloituskoodi eli nuo ohjelman muutama koodirivi ovat vain murto-osa. Onneksi aloituskoodi ei kasva ohjelman koon kasvaessa.
Studion builderi kertoo mitä se on tehnyt ja tässä tapauksessa siinä ylempänä näkyy, että avr-gcc on käynnistetty kahdesti - ekalla kerralla tuottamaan test.c-tiedostosta objektitiedosto test.o ja toisella kertaa objektista muistikartta ja latauskelpoinen test.elf. Tästä on sitten väännetty vielä heksamuotoinen tiedosto test.hex jonka studio pystyy lataamaan esim JTAG-rajapinnan läpi kohdeprosessorille.
Ketä kiinnostaa niin projektihakemistoon on viimeistään nyt ilmestynyt alihakemisto "default" jossa nuo tulostiedsostot makoilevat. Tarkka muistikartta löytyy tiedostosta test.map ja sieltä näkee miten kääntyri on prosessorin muistia käyttänyt. Tottumattomalle tuo ei paljoa sano, mutta kun oppii ymmärtämään mitä mikin tarkoittaa, siitä näkyy lopullinen totuus.
Samoin tuolta löytyy tiedosto nimeltä Makefile. C-koodareille tämä on jokapäiväistä leipää. Komentorivikääntäjän käyttäjät joutuvat tutustumaan ohjelmaan nimeltä make jolla sovelluksen kääntäminen ja kasaus siinä ympäristössä ohjataan. Meillä on helpompaa kun Studio generoi makefileet automaattisesti sen mukaan mitä me olemme ottaneet mukaan projektiin.

No nyt on koodinpätkä käännetty ja pitäisi nähdä mitä se tekee. Meillä ei todennäköisesti ole mitään oikeaa rautaa kytkettynä studioon tällä hetkellä, joten simuloidaan. Studion valikosta auki valinta Debug ja aika alhaalta vielä Select Platform and Device. Debug platformiksi "AVR Simulator" ja prosessoriksi ATmega32 jollei se ollut jo valittu. Finish-napista kuittaus.
Aloitetaan debuggaus Debug - Start Debugging. Studio puhkuu hetken ja sitten pitäisi pääohjelman esittelyrivillä näkyä keltainen nuoli. Tuo on kontrollin kulkukohta ohjelmassa, joka on nyt pysähtyneenä odottamassa askelluslupaa. Askelletaan tämä simppeli ohjelma läpi rivi riviltä. Sitä ennen kuitenkin avataan muuttujien tarkkailuikkuna jotta nähdään mitä arvoja muuttujat saavat ohjelman edetessä. Sitä varten päävalikosta View - Watch ja meille aukeaa watch-ikkuna. Tuplaklikkaus name-sarakkeen ruutuun niin voit kirjoittaa tarkkailtavan muuttujan nimen siihen. Laita i, x ja y omille riveilleen. Älä välitä siitä, että Value-ruudussa lukee hälyyttävästi "invalid location". Ohjelman suoritus ei vaan tällä hetkellä vielä ole noiden muuttujien näkyvyysalueella. Tästä lisää myöhemmin. Siirrä watch-ikkuna johonkin niin, että näet lähdekoodin kunnolla. Stepataan yksi rivi. Joko valikosta Debug - Step Into tai helpommin funktionäppäin F11. Nyt kaikille muuttujille pitäisi ilmestyä arvo watch-ikkunaan koska olemme saapuneet niiden näkyvyysalueelle. Huomaa, että askellus ohitti rivin jolla muuttujat esitellään. Tämä rivi ei generoi koodia joten sitä ei ajon aikana voi "suorittaa". Eli nyt ollaan rivillä jossa lukee x = 0; Tätä riviä ei vielä ole suoritettu vaan se on seuraavana vuorossa. F11 ja nyt watch-ikkunassa näkyy, että x sai arvon 0 kuten tietty pitikin.
Steppailemalla F11 avulla ohjelma jatkaa kulkuaan ja veivaa tuon for-silmukan läpi päättyen lopulta kun pudotaan ulos main-proseduurista. Debug - Reset valmistaa simuloinnin uudelle kierrokselle.
Työtilan vasemmassa laidassa näkyy prosessori-ikkuna jossa yksityiskohtaiset tiedot keskusyksikön tilasta kullakin hetkellä. Oikealla taas I/Olaitteiden tilanne. Huomaa, että simuloinnissa voi esin porttien tilaa muuttaa käsin ja näin simuloida ulkoisia kytkimiä tms.

Debugatessa vähänkään isompaa koodimassaa, ei single steppaus koodin läpi oikein toimi. Se on kuin maalin kuivumista katselisi, eikä varsinkaan oikeaa rautaa debugatessa ajoitukset toimi oikein. Tätä varten on breakpointit eli katkopisteet. Tehdään sellainen: Debug - Stop Debugging jotta päästään ulos tilanteesta. Klikkaa kursori riville josa lukee x = i; ja valitse Debug - Toggle brakpoint tai helpommin F9 (toggle tarkoittaa, että breakpointin tila vaihtuu joka valinnalla; päälle-pois-päälle). Nyt riville ilmestyi punainen pallo aktiivisen breakpointin merkiksi. Debug - Start Debugging. Kun nuoli näkyy, Debug - Run tai F5. Nuoli hyppää samalle riville kuin pallo. Simulaattori ajoi koodia täyttä vauhtia kunnes tultiin katkoriville johon suoritus taukoaa. Nyt voit watch-ikkunasta todeta, että muuttujien arvot on samat kuin edellisellä simulointikerralla tultaessa tähän ekaa kertaa. Painele F5 niin huomaat arvojen hyppivän ylöspäin. Ohjelma kiertää silmukkaa ja pysähtyy joka kierroksella tähän breakpointtiin. Lopulta suoritus karkaa silmukasta ja putoaa ulos pääohjelmasta.
Vielä yksi hyvin tehokas breakpoint-tyyppi: data breakpoint. Kun bugit menevät hankaliksi, on joskus tosi arvokasta nähdä, missä muuttujaa on käsitelty. Tehdään yksinkertainen data breakpoint joka keskeyttää kun muuttuja x saa arvon 5. Data breakpointteja määriteltäessä studion pitää olla debug-tilassa jotta sillä on pääsy aktiiviseen muistikarttaan. Siis tarvittaessa Debug - Start Debugging. Ensin poistetaan kaikki mahdolliset vanhat breakpointit hämäämästä: Debug - Remove all breakpoints. Sitten: Debug - New Breakpoint > Data Breakpoint ja meille aukeaa data breakpoint-ikkuna.
Täytä seuraavasti:
Break when: Location is equal to a value
Location [...] napilla haetaan test.c / main / x ja kuitti OK
Value: 5
Muut saa olla. Nyt meillä on data breakpoint joka laukeaa missä vaan kun X:n arvona nähdään 5. Kuitti OK:lla ja ikkuna sulkeutuu. Nyt työtilan alareunassa näkyy "Breakpoints and tracepoints" -listalla juuri määrittelemämme breakpointti ja täppä ruudussa näyttää sen olevan aktiivinen (sen voi sillä täpällä kääntää pois päältä). Riuhtaistaan suoritus taas liikkeelle F5 ja nuoli stoppaa heti riville y += (x * i); Muistetaan että tämä on seuraavaksi suoritettava rivi, joten viimeinen jo suoritettu on se edellinen, eli x = i; Watch-ikkunasta nähdään x:n olevan 5 kuten pitikin ja tuo juuri suoritettu rivi siis on syyllinen. Data breakpoint on kova työkalu - kuten huomasit sitä määritellessä, ehtoja on vaikka kuinka.
Kaikki määritellyt breakpointit näkyvät työtilan alaosan listalla ja niitä voi kääntää päälle ja pois lennossa aina tarpeen mukaan. Studio muistaa breakpointit jopa istuntojen välillä kunnes niitä erikseen muutetaan.
... jatkuu ...

Joo  22 eksuu maksaa, ja sitä pohjana käyttäen olisi aika helppo edetä protorautaan. Lopullesesta levystähän tulee sitten aika hyvä kehitysalusta. Kaikki IO:t tietty siihen helposti käsille. Kyllähän siitä ihan varmasti joku koodaa myöskin servodriven yms.

No niin... näyttää innostuksenne asiaan jatkuvan kiitettävästi. Ja kun tuli kaksi myönteistä eikä yhtään kielteistä kannanottoa oman alueen perustamiseksi, niin tehdäänpä niin.  Foorumille olen perustanut uuden pääotsikon, johon tämä ketju siirtyy ihan kohta. (Katso liite). 

Siellä on myös (vähän niinkuin varalta) jo pari alakategoriaa, joita saa käyttää, jos on tarvetta erotella tästä yleisestä keskustelusta esimerkiksi vaihtoehtoisten ratkaisuehdotusten äänestyksiä. Itse asiassa suosittelenkin niiden tekemistä sinne, jotta sen tyyppiset jutut eivät rikkoisi varsinaista kehityskeskustelua. Ja projektin suuntautumispäätökset olisi myös helppo löytää.  Äänestyksiähän tänne saa perustaa kuka tahansa rekisteröitynyt, mutta parastahan olisi, jos yhteisymmärrys syntyisi keskustelussa.

Voitte tietenkin tehdä äänestyksen - jos haluatte - myös tämän homman projektipäälliköstä, jos juttu sellaista kaipaa ja haluatte asiasta äänestää.  Projektipäällikköhän on sellainen tyyppi, jonka tehtävänä on saada projektista ulos mahdollisimman hyvä lopputulos riippumatta siitä, että mikä on projektipäällikön oma mieltymys teknisiin yksityiskohtiin. Tällaisessa projektissahan ei projektipäällikön tarvitse vahtia tuotekehityksen työmääriä eikä kustannuksia, mutta lopputuloksen (tuotteen??) kustannustekijät ovat kyllä tärkeitä.

Ja sitten siellä on myös alakategoria dokumentointia varten, jotta ne löytyvät helposti. 

Konemies voi toimia tässä projektissa jonkinlaisena apumiehenä, mutta ei päällysmiehenä. Teen toivomustenne mukaisia asetuksia ja alakategorioita tälle alueelle, jne. Lisäksi varmaan voisin kommentoida silloin tällöin projektin kehittymiseen liittyviä erilaisia asioita, mutta muuten ei ole minun hommani ohjata asiaa. Projekti on siis teidän ja sen hyödyntäminen kunkin omassa vallassa.

Mukava kokeilla tällaista täällä; toivottavasti projekti yhdistää eikä erota porukkaa toisistaan.

Tuo uusi alue on sitten suljettu vierailta....

----
EDIT:  Siis nyt on siirretty...  Kannattaa klikkailla suoraan noita alakategorioita, koska menee väkisinkin muutaman ylätason kautta, mutta omiin linkkeihin voi laittaa tietenkin ketjun osoitteen suoraan... Jos on ongelmia oikeuksien kanssa, niin YV:tä konemiehelle....

Lainaus käyttäjältä: ram - 03.01.10 - klo:12:42
Joo  22 eksuu maksaa, ja sitä pohjana käyttäen olisi aika helppo edetä protorautaan. Lopullesesta levystähän tulee sitten aika hyvä kehitysalusta. Kaikki IO:t tietty siihen helposti käsille. Kyllähän siitä ihan varmasti joku koodaa myöskin servodriven yms.

Niin kannattaa tietenkin saman tien laittaa kaikki kortin ja prosessorin liitynnät käyttökelpoisen kuosiin, se ei maksa mitään ja joku on varmasti kiitollinen myöhemmin.

Tässä artikkeli on interpolaatioiden tekoon, ei tarvi keksiä pyörää uudelleen, muutenkin erittäin mielenkiintoista luettavaa...

Lainaus käyttäjältä: Jonne - 03.01.10 - klo:18:25
Tässä artikkeli on interpolaatioiden tekoon, ei tarvi keksiä pyörää uudelleen, muutenkin erittäin mielenkiintoista luettavaa...

Kiitos, hyvä artikkeli. Sinänsä tämä on tuttu juttu - olennaisesti tällä samalla algoritmilla ohjearvonseurantaa tuli laskettua Strömbergillä jo ennenkuin sitä kutsuttiin Bresenhamiksi. Taisi yksi Variksen Pekka tehdä dippatyönsä osanakin jotain tuohon about vuonna -80 kun kyhättiin Valmetin tuplaviirakoneen moottorisäätöjä prosessorilla. Oli muuten varmasti maailman eka atk:lla säädetty paperikonekäyttö. Bresenhamhan kehitti sen myöhemmin nopeaan viivan ja kaarenpiirtoon näytöille missä se kai nykyisin on parhaiten tunnettu. Tämän algoritmin erästä versiota siis ehdottomasti tarvitaan stepperin ohjauksessa.
Pitääkin tutustua tuohon ajatuksella kun se on tehty juuri cnc-koneen näkövinkkelistä. Tähän syöttöruuvin ohjaukseen ei varmaan tarvita varsinaista trajectory planneria jossa tuo olisi erityisen hyvä, mutta jossain muodossa tulee olemaan välttämätön.
Niin, ja kartion sorvauksessahan me käytetään tietysti alkuperäistä suoran viivan  Bresenhamia joka näyttää olevan tuossa suoraan sorsakoodina.

Toi Bresenham on minulle tuttu joista omista projekteista, lähinnä pelien tekoon liittyen, mutta eihän noita muista enää ulkoa... En ole montaa artikkelia NC-koneiden matematiikasta nähnyt, ainakaan ilmaisjakelussa, eli aika helmi tuo artikkeli.

Mitäs prossua käytitte -80, Intelin 8088, DECin LSI:tä vai Motorolan (silloin) uutukaista 68000:aa? Vai oliko teillä nitä MikroMikkoja I:n 80188:lla?

Lainaus käyttäjältä: Jonne - 03.01.10 - klo:21:28
Toi Bresenham on minulle tuttu joista omista projekteista, lähinnä pelien tekoon liittyen, mutta eihän noita muista enää ulkoa... En ole montaa artikkelia NC-koneiden matematiikasta nähnyt, ainakaan ilmaisjakelussa, eli aika helmi tuo artikkeli.

Mitäs prossua käytitte -80, Intelin 8088, DECin LSI:tä vai Motorolan (silloin) uutukaista 68000:aa? Vai oliko teillä nitä MikroMikkoja I:n 80188:lla?

Me rakenneltiin Strömbergin SELMA1 ja SELMA 2 räkkikontrollereita joihin meni euro1 ja -2 kokoiset kortit. Prosessoreina niissä oli 8085 ja 80188 muistaakseni, vai olisko SELMA 2:ssa ollut jo 186:kin. AMD:n aritmetikkaprosessoreita käytettin apuna liukulukulaskennassa ja AMD:llä oli myös hyvä erillinen timer/counter-piiri jota sovellettiin moneen kohtaan. Hires-nopeudenmittauskortissa oli muistaakseni peräti 3 kpl noita laskureita räknäämässä aikaa ja enkooderipulsseja. SELMA 2:een oli tarkoitus vielä tehdä Intelin iAPX432-systeemin keskusyksikkö. Siinä olisi ollut rautakiihdytys moniajokäyttikselle, mutta ei Intel sitten oikein saanut sitä pelaamaan ja siitä luovuttiin. SELMA 2 oli kumminkin Multibus-laite joten sillä pystyi tekemään yhteen räkkiin moniprosessoritoteutuksia jo silloin. Joka tapauksessa tuplaviirakoneeseen meni kaikkiaan 37 prosessoria tai vähän ylikin riippuen miten valvontamonitorointi ja vikahälytykset oli toteutettu. Kaukaan tehtaan kakkoslinjassa Lappeenrannassa oli muistaakseni juuri 37 prosessorin toteutus. Erilaisia I/O-modulikortteja paperikoneen ohjaukseen meni kolmisensataa ellei enemmänkin, ei enää jaksa muistaa tarkasti näin pitkän ajan päästä. Sen kuitenkin muistan hyvin, että muutamat kohdat paperikoneen ja päällystyskoneen ohjauksessa vaativat supertarkkaa nopeuksien synkkausta ja laajaa dynamiikka-aluetta tarkalle mittaukselle. Siinä tuo Bresenhamiinkin kuuluva diskreettisuureiden jäännöserotuksen käsittely oli avainasemassa.

Noniin

Mitäs toivomuksia raudalle esitetään?

Esim. Itse laittaisin encooderille ruuviliittimen jne. mutta kun en ole vain itselleni tekemässä... Eli jos joku haluaa kolmikulmaisia saabin osia käyttää niin ehdotuksia ainakin kuunnellaan.

Nyt vaan rohkeasti esittämään toivomuksia ;)

Lainaus käyttäjältä: ram - 04.01.10 - klo:22:20
Noniin

Mitäs toivomuksia raudalle esitetään?

Esim. Itse laittaisin encooderille ruuviliittimen jne. mutta kun en ole vain itselleni tekemässä... Eli jos joku haluaa kolmikulmaisia saabin osia käyttää niin ehdotuksia ainakin kuunnellaan.

Nyt vaan rohkeasti esittämään toivomuksia ;)

Toivomuksia on kovastikin :) Voisin koota ne kunnolliseksi listaksi ja koettaa saada omalta osaltani kasaan loppiaisen tiimoilla. Tällä hetkellä työt häiritsee vähän harrastusta, mutta kohtapuoliin taas on aikaa.
Atmelilla on noita applikationootteja nettisivuillaan, sieltä kannattaa kaivaa ainakin vinkit elektroniikkasuunnittelijoille. AVR042 olisi yksi esimerkki http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf (http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf). Ei tuossa kokeneelle suunnittelijalle mitään ihmeitä tule vastaan, mutta ehkä maksaa vaivan vilkaista.
Perästä kuuluu sanoi torventekijä...

Enpä ole aikaisemmin kuullutkaan tuollaisesta ihmeestä kuin iAPX432, oli pakko käydä hiukan tutkimassa Googlella moista kapistusta, ja on kyllä erikoinen.

Itse keräilen noita vanhoja piirejä ja tietokoneita, olen tässä odottanut milloin joltain asiakkaalta saisi Fanuc 2000C/3000C:n (Yaskawakin tehnyt samaa ohjausta lisenssillä) 70-luvulta, sieltä löytyy Intelin 2-bitin viipaleprosessorit...
http://www.cpu-world.com/CPUs/3002/index.html (http://www.cpu-world.com/CPUs/3002/index.html) (eli jos joltain löytyy vanhaa elektroniikkamatskua, niin sitä vaihdetaan laadukkaisiin Alkon "liuotin"-pulloihin  ;) )


Mutta asiaan...

Tuo C-kielen esimerkki kyllä vaikutti ihan järkevältä,  tuo tolkuton symbolimerkkien käyttö hämää aika lailla.

Olen tossa näperrellyt muutaman tunnin AVRStudion kanssa, ja kyllä tuo C alkaa pikkuhiljaa aukeamaan... Aikansa vie noiden symbolien merkityksen (tai oikeastaan niiden järjestyksen merkityksen) opettelu. Muutoinhan tuo vaikuttaa aika selvältä puurolta  ::)

Nyt kun pääsisi eroon samalla hyppy-hyppy-fetissistä, voisi alkaa käyttämään funktioita... Olen aina tykännyt käyttää globaaleja muuttujia ja paljon hyppykäskyjä, mutta se on aika old-skoolia...

Lainaus käyttäjältä: Jonne - 04.01.10 - klo:23:22
Mutta asiaan...
Tuo C-kielen esimerkki kyllä vaikutti ihan järkevältä,  tuo tolkuton symbolimerkkien käyttö hämää aika lailla.

C on yksi niitä kieliä joilla on pitkä tarina ja historia takanaan. Se on aina ollut erittäin portattava kieli, mikä siis tarkoittaa, että koodin saa toimimaan mitä erilaisimmissa ympäristöissä. Aika jännää ajaella, että sekin koodi mitä tässä tullaan kyhäämään kääntyy käytännössä muuttamattomana melkein kaikilla alustoilla joihin C tai C++ -kääntyri löytyy, mikroista supertietokoneisiin. No, ei meille siitä paljoa iloa ole, mutta tuo pitkä historia ja superlaaja käyttö osaltaan selittää miksi jotkin C:n piirteet vaikuttaa omituisilta. Syntaksi sinänsä ei ole vaikea mutta sinä näkyy joidenkin muinaisten tietokonearkkitehtuurien sormenjäljet edelleen. Kernighan ja Ritchie muistaakseni väänsivät ensimmäisen tunnistettavan C-kielen ajettavaksi Multics-käyttöjärjestelmässä jonka osoitteidenkäsittely näkyy C:n pointterisyntaksissa vieläkin.
Sitten tuon historian myötä on kielen oheen liimaantunut iso joukko vakiintuneita käytäntöjä ja nimeämistapoja kuten alaviivojen käyttäminen nimissä. Näissä menee alkuun sormi suuhun kun kaikki tulee kerralla syliin, mutta kyllä se vähitellen aukeaa.

Lainaa
Olen tossa näperrellyt muutaman tunnin AVRStudion kanssa, ja kyllä tuo C alkaa pikkuhiljaa aukeamaan... Aikansa vie noiden symbolien merkityksen (tai oikeastaan niiden järjestyksen merkityksen) opettelu. Muutoinhan tuo vaikuttaa aika selvältä puurolta  ::)

Juuri näin, ei C ole kieliopiltaan yhtään vaikeampi kuin basic. C++ sitten jo on kyllä huomattavasti toinen juttu, mutta ei me tässä ahtassa mikrokontrolleriympäristössä sen kanssa lähdetä pelleilemään.

Lainaa
Nyt kun pääsisi eroon samalla hyppy-hyppy-fetissistä, voisi alkaa käyttämään funktioita... Olen aina tykännyt käyttää globaaleja muuttujia ja paljon hyppykäskyjä, mutta se on aika old-skoolia...

Ai tuo on paha juttu. Vähän niinkuin tupakanpoltto, se tappaa hitaasti mutta varmasti. Onneksi ei ole koskaan liian myöhäistä lopettaa :)
Globaalimuuttujille on paikkansa mutta aina sellaista esitellessä pitää tarkkaan miettiä onko se välttämätöntä. Pitää muistaa, että lokaalit (siis ei-globaalit) muuttujat käsitellään pinomuistissa ja niiden tila vapautetaan muuhun käyttöön heti kun muuttuja poistuu näkyvyysalueelta. Näin pitää ollakin koska siten kontrollerin vähäinen rammitila saadaan riittämään ihan eri tavalla kuin pitämällä kaikki globaaleina.
Heitänkin tähän kohtaan sulle tämmöisen haasteen: "oikeassa" ohjelmassa ei sitten ole yhtään hyppykäskyä. Teepä ohjelma joka laskee kaikkien kahden peräkkäisen kokonaisluvun summien summan välillä 1 - 1000. Eli (1+2) + (2+3) + ... + (999 + 1000). Tee ohjelmasta mahdollisimman selkeästi hahmotettava niin, että tuo toimeksianto on siitä tunnistettavissa. Käytä jokaiseen yhteenlaskuun tällaista funktiota apuna (eli älä laske suoraan yhteen):

int32_t sum ( int32_t a, int32_t b ) {

    return (a + b);

}

Olen tuossa käytänyt C99-standardin mukaisia kokonaislukutyyppien nimiä http://en.wikipedia.org/wiki/C99 (http://en.wikipedia.org/wiki/C99). Se olisi hyvin suositeltavaa noin yleisesti ja sääntö on helppo. Tyypinnimi on (u)intx_t, missä "u" tarkoittaa "unsigned" eli etumerkitön ja "x" ilmoittaa nimenomaisesti käytettävien bittien määrän. Tuo "_t" on taas perinnettä ja voidaan lukea "-tyyppinen". int16_t on näinollen täsmälleen 16-bittinen etumerkillinen kokonaislukutyyppi. Nuo tyypit on sisäänrakennettu GCC-kääntyriin ja ovat voimassa kun kääntäjälle on annettu direktiivi -C99 (Studio antaa ellet erikseen kiellä).

Kun saat mielestäsi oikean lopputuloksen niin pistä tänne näkyviin. Minä voin laittaa oman ehdotukseni vierelle niin voidaan keskustella niiden olemuksesta. (Lonkalta heitin tuon haasteen. En ole vielä sen kummemmin miettinyt ratkaisua joten melkein samalta viivalta lähdetään).

Lainaus käyttäjältä: Jonne - 04.01.10 - klo:23:22
Tuo C-kielen esimerkki kyllä vaikutti ihan järkevältä,  tuo tolkuton symbolimerkkien käyttö hämää aika lailla.

Aikansa vie noiden symbolien merkityksen (tai oikeastaan niiden järjestyksen merkityksen) opettelu. Muutoinhan tuo vaikuttaa aika selvältä puurolta  ::)

C ja C++ -kielet pyrkivät lyhyeen ja ytimekkääseen teksti-ilmaisuun. Onko se hyvä vai huono on makuasia. Varmaan alussa huono kun kaikki näyttää hieroglyfeiltä, mutta vähän ajan kuluttua kivaa kun ei tarvitse hakata näppistä yhtä paljon kuin joissain muissa kieliopeissa. No, makuasia varmaan kuitenkin. Nuo kääntäjät sisältävät aina myös ns. esiprosessorin joka laventaa ja muutenkin huomioi käyttäjän antamat ohjeet kuinka käännös pitää suorittaa. Tämä on erittäin tehokas keino tuottaa erilaisiin tilanteisiin ja toimintaympäristöihin mukautuvaa koodia, ja se on ammattimaisessa koodintuotannossa täysin elinehto.
Esiprosessorin "kieli" ei siis ole varsinaista C:tä vaikka se onkin upotettu samaan tiedostoon. Esiprosessorille osoitetut käskyt tunnistetaan # -merkistä.
Vielä yksi alussa helposti hämäävä asia, varsinkin jos tutkii kokeneen koodarin tuotamaa esimerkkikoodia on useinkin esiintyvät ihmeellisen näköiset muutujannimet  kuten __jotakin tai __jotainmuuta__ Nämä ovat perinteisesti "implementaatiolle" varattu tapa esittää muuttujanimiä. Käytännössä se tarkoittaa, että kääntäjä tai käännösympäristö ylläpitää noiden muuttujien arvoja. Näiden tarve valkenee sitten aikanaan kun pääsee niin pitkälle, siihen asti tuollaiset voi sivuuttaa.
Muutama linkki jotka toivottavasti selventävät tätä puolta:
http://www.gamedev.net/reference/programming/features/orgfiles/ (http://www.gamedev.net/reference/programming/features/orgfiles/)
http://en.wikipedia.org/wiki/C_preprocessor (http://en.wikipedia.org/wiki/C_preprocessor)
http://www2.it.lut.fi/kurssit/07-08/CT20A0210/oppaat/C-ohjelmointiopas_LTY.pdf (http://www2.it.lut.fi/kurssit/07-08/CT20A0210/oppaat/C-ohjelmointiopas_LTY.pdf)

Sitten toinen asia mikä kannattaa ottaa haltuun aika varhaisessa vaiheessa, kun tuo ekan linkin ajatus on ensin sisäistetty: C-kääntäjän ajonaikaiset kirjastot. Kieli itsessään on varsin yksinkertainen eikä tarjoa sisäänrakennettuna paljoakaan ominaisuuksia. Käytännössä kaikki yleisesti hyödylliset mutta vähän työläämmin toteutettavat jutut löytyvät joko ajonaikaisesta vakiokirjastosta tai siten jostain sovellusspesifisestä funktiokirjastosta.
WinAVR-kääntäjä jota AVRStudio siis käyttää taustalla, puolestaan käyttää avr-libc -kirjastoa, jonka nettisivut löytyvät täältä: http://www.nongnu.org/avr-libc/ (http://www.nongnu.org/avr-libc/). Tämä kirjasto on jokaisen AVR-koodarin syytä tuntea kuin taskunsa.

No niin, siinäpä oli tiiviissä muodossa C-kielen pikakurssi. Ja varsin hyvä sellainen.

Mutta sitten varsinaiseen asiaan. Minulle tuli mieleen että laittaisin sorviini trapetsiruuvin lisäksi kuularuuvin. Näin sorvin alkuperäinen rakenne säilyy ja samalla saisi hieman tarkemman liikkeen kuularuuvilla. Ongelmana on toki kelkan kiinnitys kuularuuvin mutteriin joka pitää pystyä irrottamaan manuaalityöskentelyä varten. Kommentteja tästä onko tässä mitään järkeä?

Sitten vielä aikataulu, antakaapa hyvä arvaus milloin homma voisi olla siinä vaiheessa että olisi jotain asennettavaa. Nämähän valmistuu joskus kun varsinaista dead linea ei ole, mutta kun vaihtoehtona on esim. ELS:in rakentaminen niin jokin ennuste olisi positiivinen yllätys. Mielellään kyllä näkisin ja toteuttaisin tässä suunnitelmissa olevan ratkaisun.

tuli tilattua toi olimexin kortti 34.58€ kotiin kannettuna.
sitten kysymys avr studiosta saako i/o wievistä näkyviin kerrallaan enempää kuin esim. yhden portin tai timerin debukkauksen yhteydessä.

Lainaus käyttäjältä: jussi - 05.01.10 - klo:22:54
tuli tilattua toi olimexin kortti 34.58€ kotiin kannettuna.
sitten kysymys avr studiosta saako i/o wievistä näkyviin kerrallaan enempää kuin esim. yhden portin tai timerin debukkauksen yhteydessä.

Ei ollut pahan hintainen. Mihin meinaat istuttaa sen?

Kyllä tuon I/O viewin pitäisi näyttää koko prosessorin rekisterimuistin tila eli kaikki portit jne mukaanluettuna. Käytännössä voi olla vaihtelua jos debuggaa JTAGin läpi - siinä voi esiintyä jotain rajoitteita. Simulaattorilla tämmöisiä ei kyllä pitäisi olla.

Lainaus käyttäjältä: Kremmen - 05.01.10 - klo:09:00
Teepä ohjelma joka laskee kaikkien kahden peräkkäisen kokonaisluvun summien summan välillä 1 - 1000. Eli (1+2) + (2+3) + ... + (999 + 1000). Tee ohjelmasta mahdollisimman selkeästi hahmotettava niin, että tuo toimeksianto on siitä tunnistettavissa. Käytä jokaiseen yhteenlaskuun tällaista funktiota apuna (eli älä laske suoraan yhteen):

int32_t sum ( int32_t a, int32_t b ) {

    return (a + b);

}


Kun saat mielestäsi oikean lopputuloksen niin pistä tänne näkyviin. Minä voin laittaa oman ehdotukseni vierelle niin voidaan keskustella niiden olemuksesta. (Lonkalta heitin tuon haasteen. En ole vielä sen kummemmin miettinyt ratkaisua joten melkein samalta viivalta lähdetään).

Kun kerta lupasin, niin tässä minun ehdotukseni

#include <stdint.h>

int32_t sum ( int32_t a, int32_t b ) {
    return (a + b);
}

int main () {   // peräkkäisten kokonaislukuparien summa 1...1000
            // (1+2) + (2+3) + ... + (999 + 1000)

   int32_t sigma;
   int16_t i;

   sigma = 0;

   for (i = 1 ; i < 1000 ; i++ ) {
      sigma = sum(sigma, sum( i, sum(i,1)));
   }
}

Lainaus käyttäjältä: Tauru - 05.01.10 - klo:22:31
Mutta sitten varsinaiseen asiaan. Minulle tuli mieleen että laittaisin sorviini trapetsiruuvin lisäksi kuularuuvin. Näin sorvin alkuperäinen rakenne säilyy ja samalla saisi hieman tarkemman liikkeen kuularuuvilla. Ongelmana on toki kelkan kiinnitys kuularuuvin mutteriin joka pitää pystyä irrottamaan manuaalityöskentelyä varten. Kommentteja tästä onko tässä mitään järkeä?

Eikös isommissa sorveissa ole tuollaisia ratkaisuja? Mekaniikkagurut ottakoot tähän kantaa paremman tiedon perusteella.

Lainaa
Sitten vielä aikataulu, antakaapa hyvä arvaus milloin homma voisi olla siinä vaiheessa että olisi jotain asennettavaa. Nämähän valmistuu joskus kun varsinaista dead linea ei ole, mutta kun vaihtoehtona on esim. ELS:in rakentaminen niin jokin ennuste olisi positiivinen yllätys. Mielellään kyllä näkisin ja toteuttaisin tässä suunnitelmissa olevan ratkaisun.

Näin aikaisessa vaiheessa aikataulun antaminen on kuin ensi syksyn sään ennustamista. Oikeasti tällaisessa hankkeessa - vaikka onkin ajatuksen tasolla helposti ymmärrettävä - on niin monta liikkuvaa osaa, että se on kyllä ihan oikea tuotekehitysprojekti. Aikataulu on hyvässäkin tapauksessa ilman muuta kuukausia, eikä vain 1 tai 2. Nythän hankkeessa on 2 - 2½ sitoutunutta henkilöä - minä, ram ja Jonne. Jos lisää saadaan niin se tietenkin nopeuttaa riippuen siitä miten kaverien osaaminen on hyödynnettävissä. Kuitenkin sanon suoraan että jos nyt polttelee kiire päästä sorvaamaan niin kannattaa kyllä katsoa valmiita ratkaisuja. Mutta tervetuloa jouduttamaan hanketta, jos siltä tuntuu :)

 pistämpä näkyviin oma viritykseni.    tuohon olimexiin ei ole vielä valmiina mitään jonkinlainen emokortti tarvii siihen tehdä. i/o wievistä mulla sammuu aina auki oleva kun avaa toisen.


#define u16 unsigned int
  #define u32 unsigned long int

  unsigned long int summa (u16 A,u16 B); //protyyppi
  unsigned long int summa (u16 A,u16 B)  //määrittely yhteenlasku funktio

   {
     u32 C = 0;                          //muuttuja C nollaus
     C = A+B;                            // yhteenlasku
     return C;                             //tulos palautetaan
   }   


   int main(void)                            // perinteinen esittely
     {
      u16 A = 1;                         //
     u16 B = 2;                         //
     u32 C = 0;                         //
      u32 tulos = 0;                     //muuttujat A,B,C,tulos

      while(1)                         

     {
        
       C = summa(A,B);                 //funktion kutsu
       tulos = tulos + C;              //  summataan tulos
       A++;                            //
       B++;                            // lisätään muuttujiin seuraavaa laskua varten
      
       if(B==1000)                    //1000 täyteen nollataan muuttujat
       {
       A=1;
       B=2;
       C=0;
       tulos = 0;
       }
     }
      
    }

Lainaus käyttäjältä: jussi - 05.01.10 - klo:23:55
pistämpä näkyviin oma viritykseni.

OK. Näyttää laskevan oikein. Haluatko kommentteja?

Ammattilaisen kommentit tervetulleita esim.  muistin käytöstä ja"tehokkuudesta"

Lainaus käyttäjältä: jussi - 06.01.10 - klo:01:28
Ammattilaisen kommentit tervetulleita esim.  muistin käytöstä ja"tehokkuudesta"

Okei, rakentavassa hengessä sitten tämmöisiä havaintoja:

unsigned long int summa (u16 A,u16 B)  //määrittely yhteenlasku funktio

   {
     u32 C = 0;                          //muuttuja C nollaus
     C = A+B;                            // yhteenlasku
     return C;                             //tulos palautetaan
   }   

Tässä funktiossa muuttuja C on todellisuudessa tarpeeton. Sama toiminta saadaan kirjoittamalla vain "return A+B;" sillä return ei välttämättä tarvitse yksittäistä muuttujaa (vaikka sekin toki käy), sille kelpaa mikä tahansa mikä kelpaa tavallisen sijoituslauseen oikealle puolelle (ns. "rvalue").
Tässä ei tapahdu mitään vahinkoa, koska jokainen moderni kääntäjä joka tapauksessa optimoi muuttujan C pois, eli syntyvä konekoodi lienee sama molemmissa tapauksissa.

Semmoinen kauneusjuttu mihin voi kiinnittää huomiota on, että funktion tyypiksi on määritelty "unsigned long int" ja palautettava tyyppi on "u32" (muuttuja C on tätä tyyppiä). Tässä kääntäjä saattaa suorittaa implisiittisen tyyppimuunnoksen mikäli nuo määritykset eivät ole identtisesti samat (tai se siis varmasti suorittaa muunnoksen mutta se on todennäköisesti null operaatio tässä). Kulissien takana tapahtuvat tyyppimuunnokset (typecast) ovat aina vähän riski koska pahassa tapauksessa bittejä lentää avaruuteen. Tässä ei varmaankaan käy niin ja yleensä kääntyri kyllä varoittaa jos näin näyttäisi käyvän.

Pääohjelmassa sijoitukset riveillä:
    u32 C = 0;                         //
    u32 tulos = 0;                     //muuttujat A,B,C,tulos
ovat myös tarpeettomia. Noita nolliahan ei käytetä mihinkään ja ne ylikirjoitetaan heti while-silmukan alussa. Ei nollauksesta mitään haittaa ole, mutta kun ei ole hyötyäkään niin ohjelma olisi yksinkertaisempi ilman niitä. Tässäkin riitävän aggressiivinen optimoija kyllä perkaa nuo pois tarpeettomina.

Ehkä kuitenkin kohta johon eniten kiinnittäisin huomiosi on tapa miten olet rakentanut varsinaisen silmukan 1...1000. Koodi toimii kyllä oikein, mutta olethan samaa mieltä, että avaamalla pelin rakenteella while(1) ei lukijalle anneta liikoja vinkkejä siitä, että meinataan lopettaa tuhanteen? Kaikki koodia lukeneet orientoituvat tässä vaiheessa siten, että nyt on kädessä päättymätön silmukka, niinkuin se onkin. Ymmärrettävyyden kannalta isoin haaste on löytää rivi if(B==1000) ja keksiä, että se katkaisee ylöspäin iteraation ja muuttujassa C siksi on tähän mennessä kertynyt summa. Haastetta ei helpota se, että while-silmukka on täysin tunteeton tälle tapahtumalle ja jatkaa suoraan seuraavalle kierrokselle. Hyvä kuitenkin, että muuttujat on alustettu uutta kierrosta varten joten sekin lähtee kyllä laskemaan oikein.
Pääohjelmallahan ei tehtäväksiannon mukaan ollut mitään muuta tekemistä, joten se saa joko kiertää ikuista silmukkaa tai päättyä - siinä mielessä päättymätön silmukka on OK.
Jos olisit vielä kirjoittanut tulos = summa(tulos,C) niin se yhteenlaskukieltokin olisi toteutunut 100% :)

Arvaan ettet kirjoita koodia ammatiksesi. Se huomioiden tässä toteutuksessa ei ole mitään varsinaista vikaa. Kaikille muillekin lukijoille voi heittää sellaisen mietittäväksi, että koodin kirjoitus on kuin shakin peluuta: se että osaa siirrot ei vielä tee suurmestaria.
Ketä ohjelmointi noin muuten kiinnostaa niin suosittelen lukemaan jos käsiinne saatte: McConnell: "Code Complete 2" ja toinen kuolematon Ranade & Nash: "The Elements of C Programming Style". Noiden lukemisen jälkeen koodieditorin läpi aukeaa ikkuna toisennäköiseen maailmaan.

juu ammatikseni en koodaa. Onneks vois tulla nälkä :D olen tosiaan jotain pikkujuttuja tehny noilla avr:illä niihinkih koodit on suurimmaksi osaksi muokattu/yhdistelty valmiista esimerkeistä. Niissä on aina toi while silmukka. Jääny takaraivoon ;)

Lainaus käyttäjältä: jussi - 06.01.10 - klo:11:56
...  niihinkih koodit on suurimmaksi osaksi muokattu/yhdistelty valmiista esimerkeistä. Niissä on aina toi while silmukka. Jääny takaraivoon ;)

Joo, tällaisissa mikrokontrollerisovelluksissa on käytännössä aina pääohjelman uloin runko jonkinlainen päättymätön silmukka. Eihän jossain sulautetussa systeemissä kerta kaikkiaan ole mitään sellaista laajempaa ympäristöä johon suoritus voisi palata jos pääohjelma sattuisi ajamaan itsensä loppuun asti. Laskenta vaan tyssäisi ja kapine mykistyisi. Kyllä Windowsinkin syvimmissä uumenissa on jonkinlainen päättymätön silmukka.  :P

Toimivaksi tiedetyn esimerkkikoodin tarkastelu on usein erinomainen tapa saada selville miten jokin toimii tai miten sen pitäisi toimia. Kannattaa vaan aina pitää mielessä, että esimerkkejä ei välttämättä ole mietitty "oikeaksi" koodiksi joten niiden anti pitää sovittaa omaan näkemykseen. Se taas puolestaan kehittyy ajan kanssa ihan niinkuin shakinpeluun taito johon viittasin. Koodaaminen on yksi niitä taiteen ja tieteen välimaastossa häälyviä asioita joissa tyyli on enemmän kuin vain hienostelua. Sillä on aika suora korrelaatio ohjelmiston laatuun ja sitä kautta toimivuuteen.
Muutaman rivin esimerkkikoodin pätkässä tätä ei huomaa kun ongelma ja sen ratkaisu on kerralla silmien edessä ja helposti hahmotettavissa. Sitten kun koodia on satojatuhansia tai miljoonia rivejä, juttu on ihan toinen. Mullekin maksoi liksan melkein 14 vuotta Nokia Data / ICL / Fujitsu ja siellä kyllä käytettiin paljon aikaa ja vaivaa koodaamisen tyylin kehittämiseen juuri sen takia, että se on olennainen osa ohjelmiston elinkaarta laatumielessä. No, ehkä me päästään vähemmällä kun ei nämä ympyrät ole ihan verrattavissa...

Tuo debukkaus esimerkki, mitä kokeilin nyt ihan ensimmäistä kertaa aukaisi ihan uuden maailman noihin esimerkki koodien tutkimiseen.Paljon helpompi seurata koodia noin. Varsinkin jos on käytetty paljon vakioita voi tuolla wiewillä seurata muuttujia.

Lainaus käyttäjältä: jussi - 06.01.10 - klo:13:46
Tuo debukkaus esimerkki, mitä kokeilin nyt ihan ensimmäistä kertaa aukaisi ihan uuden maailman noihin esimerkki koodien tutkimiseen.Paljon helpompi seurata koodia noin. Varsinkin jos on käytetty paljon vakioita voi tuolla wiewillä seurata muuttujia.

Jep. Kunnollinen debuggeri on vähän niinuin patologian laitos poliisille. Lopullinen totuus selviää siellä.

Ne ei tässä tunneista tai päivistä ole kysymys, välillä tuppaa nuo omatkin aikataulut hiemen venymään. Teen nyt ensin jyrsimen tuunausta jonkin aikaa ja sitten jatkan taas sorvin parissa.

En tiedä onko minusta mitään apua tässä projektissa, C-koodi kyllä onnistuu, mutta elektroniikan suunnittelu ei. Ja voin toki tehdä jos jotenkin pystyn auttamaan.

Lainaus käyttäjältä: Tauru - 06.01.10 - klo:21:14
Ne ei tässä tunneista tai päivistä ole kysymys, välillä tuppaa nuo omatkin aikataulut hiemen venymään. Teen nyt ensin jyrsimen tuunausta jonkin aikaa ja sitten jatkan taas sorvin parissa.

En tiedä onko minusta mitään apua tässä projektissa, C-koodi kyllä onnistuu, mutta elektroniikan suunnittelu ei. Ja voin toki tehdä jos jotenkin pystyn auttamaan.

Avusta on aina apua :)
Jos olet koodaustaitoinen niin kyllä tässä projektissa tekemistä löytyy. Oletko tutustunut tälle alueelle toisessa viestiketjussa laittamaani RTOS-demoon? Mikäli katsot ymmärtäväsi demon ilman suurempia haasteita, sekä pystyväsi tuottamaan suunnilleen samantasoista koodia demossa käytettyyn ympäristöön, niin tervetuloa remmiin.
Heittelen tällaista haastetta sen takia, että tässä ollaan toteuttamassa laitetta joka saattaa päätyä vakavasti otettavaan käyttöön oikeassa tuotannossa, ja joka tapauksessa sen on oltava henkilöturvallinen. Jos ikinä liha kohtaa nopeasti liikkuvan metallin, niin en haluaisi olla keskustelemassa, täyttikö koodi minimilaatuvaatimukset. Samaa pohdiskelua suosittelen kaikille jotka tarjoutuvat vapaaehtoisiksi. Tämä ei ole kuitenkaan tarkoitettu pelotteluksi, vaan jotta pysyisi totuus kirkkaana mielessä.
Ellei vieläkään arveluta niin toistan - tervetuloa remmiin. Niin, ja hommaa siis löydetään tehtäväksi ihan varmasti, vaikka koodaamisen haluaisitkin jättää väliin. Mutta kerro tähän väliin millä mielellä niin jatketaan siitä.

Jep, luin koodia läpi, mutta en kääntänyt vielä. Pitää kokeilla kääntämistä VS2008:lla kun aikataulut antaa periksi.
Eipä tuossa koodissa ollut mitään ihmeellistä (eikä pidäkkään olla ylläpitämisen takia) joten saman tasoista koodia pystyn tuottamaan. Tarvittaessa voit kysyä jotain muutakin hommaa minulle tehtäväksi, vaikka kyllä tuo koodaaminen on varmasti lähimpänä omaa aluetta.

Lainaus käyttäjältä: Tauru - 08.01.10 - klo:14:59
Jep, luin koodia läpi, mutta en kääntänyt vielä. Pitää kokeilla kääntämistä VS2008:lla kun aikataulut antaa periksi.
Eipä tuossa koodissa ollut mitään ihmeellistä (eikä pidäkkään olla ylläpitämisen takia) joten saman tasoista koodia pystyn tuottamaan. Tarvittaessa voit kysyä jotain muutakin hommaa minulle tehtäväksi, vaikka kyllä tuo koodaaminen on varmasti lähimpänä omaa aluetta.

Hyvä juttu, päästään eteenpäin. Demo oli suunnilleen niin yksinkertaista kuin ylipäänsä on mahdollista tuottaa, joten kyllä projektiin oikeaakin haastetta saadaan.
Kääntäminen VS:llä voi kyllä olla aika turhauttava harjoitus. C-koodiosuus tietysti kääntyy, mutta tätä projektia tuskin saa kasaan järkevästi Visual Studiolla. Ei ole tullut mieleeni itse kokeilla tuota, mutta veikkaan että VS nikottelee viimeistään törmätessään AVR:lle portattuun RTOS-ytimen inline-assembleriin. Eikä se ainakaan emittoi siitä mitään järkevää :(.
Joka tapauksessa tämä projekti on ehdottomasti tuotettava yksillä ja samoilla työkaluilla, joten avoin gnu toolchain on harkittu valinta ja sen avr-gcc on kääntäjänä tässä projektissa. Jokainen koodaukseen osallistuva voi toki oman mieltymyksensä mukaan käyttää mitä tahansa IDEä tai olla käytämättä jos perinteinen tapa miellyttää enemmän.

Olisiko käyttöliittymä sinua kiinnostava aihealue? Siinä olisi vielä koodaamisen lisäksi paljon konseptointi- ja rakennesuunnittelua. Itse asiassa sitä hommaahan ei ole oikeasti edes aloitettu vielä. Samoin tarjolla olisi EEPROM-muistin käyttö ja sarjaporttiliitynnän miettiminen. Jos sarjaportti toteutetaan (miksipä ei toteutettaisi kun resursseja on), sitä voisi käyttää myös diagnostiikkaan.

Yksi koodaamiseen liitymätön tehtävä kaipaa myös tekijää. Jonkun olisi nimittäin hyvä toimia kustannuspoliisina. Tähän mennessä emme ole asettaneet valmiillee tuotokselle mitään tavoitehintaa. Siitäkin pitäisi muodostaa jokin käsitys ja sen jälkeen valvoa kustannusten kehittymistä osa-alueittain. Joillakin komponenttivalinnoilla saattaa olla merkitävää kustanusvaikutusta, samoin toimittajavalinnoilla. Kun päästään pidemmälle, voidaan ruveta pelaamaan hankintapolitiikoilla kun tiedetään enemmän toimitajakandidaateista ja volyymeista. Kuka vaan tuntee kiinnostusta tällaiseen, saa siitä äkkiä homman itselleen.

Visual Studio on koneella valmiina niin siksipä sillä ajattelin ensin kääntää. Taitaa olla parasta kuitenkin pudottaa nuo työkalut joita aikasemmin ehdotit. Eclipse on tuttu vuosien takaa kun olin tovin Javan ihmemaailmassa mukana. Ja siinä olet oikeassa että kaikilla pitää olla samat kilkkeet käytössä.

Käyttöliittymä voisi olla minulle sopiva osa. Onko mitään mitä pitäisi huomioida ennen kuin alan miettimään ratkaisua? Pieni näyttö ainakin ja tuskin qwerty-näppäimistö on käytettävissä. Numeronäppäimistö ja muutamia muita toimintonäppäimiä joilla pitää tulla toimeen.

On tämä ainakin vaihtelua web- ja windows-sovellusten käyttöliittymien tekemiseen.

Lainaus käyttäjältä: Tauru - 09.01.10 - klo:18:49
...
Käyttöliittymä voisi olla minulle sopiva osa. Onko mitään mitä pitäisi huomioida ennen kuin alan miettimään ratkaisua? Pieni näyttö ainakin ja tuskin qwerty-näppäimistö on käytettävissä. Numeronäppäimistö ja muutamia muita toimintonäppäimiä joilla pitää tulla toimeen.
On tämä ainakin vaihtelua web- ja windows-sovellusten käyttöliittymien tekemiseen.

Hyvä, erinomaista.
Huomioitavaa on paljonkin ennekuin päästään koodaamaan. Oikeastaan koko käyttöliittymä pitää ensin konseptoida loppuun, suunnitella ja vasta sen jälkeen päästään koodaamaan.
Syöttölaitteina ei tosiaan ole mahdollista ajatella qwerty-näppäimistöä (hmm, tarkkaan ottaen miksipä ei, prosessorissa ainakin riittää sarjaliikennekapasiteetia :) ), numeronäppäimistökin pitää vielä selvittää. Tähän mennessä keskustelu on liikkunut erilaisten koodikytkinten ja paneelipulssipyörien ympärillä. Näyttöpuolella tarvittanee joitakin signalointiledejä ja varmaankin LCD-näyttö. Keskustelua on käyty erilaisista merkkipohjaisista ja (semi)graafisista vaihtoehdoista.

Ottaisitko koko tämän osa-alueen haltuusi? Toimeksianto olisi silloin osapuilleen seuraava:
- Kaikkien käyttöliittymän käyttötapausten konseptointi ja perustason dokumentointi toiminnallisella tasolla.
- Käyttötapausten vaatiman käyttöliittymän suunnittelu laitteistotasolle yhteistyössä elektroniikkamestarimme ramin kanssa.
- Käyttötapausten prosessien suunnittelu ja toteuttaminen ohjelmistoksi. Tässä osassa sitoudun olemaan tukena ja koordinoimaan yhdessä kytkentää muuhun ohjelmistoon.

Kaikki päätökset ovat siis vielä ainakin jonkin verran auki. Ottaisitko sinä ajaaksesi ne maaliin ja tekisit meille veret seisauttavan käyttöliittymän?
Tämä vaatii melko aktiivista otetta ja rekisteröityneen, aiheesta kiinnostuneen jäsenkunnan haastamista keskusteluun mukaan. Jonkin verrankin duunia ja haastetta tässä siis on luvassa, mutta haastetta hyvässä harrastuksessa kai pitää ollakin. Minusta ainakin.

Käytännön kysymyksiä: onko sinulla esim Microsoft Office-paketin työkaluja käytössä ja jos on niin mitä ja mitä versioita? Powerpoint ja/tai Visio olisivat aika hyviä/helppoja käyttöliittymän mock-upien tekoon joskin muitakin toimivia on. Nuo yleiset mockup-työkalut vaan eivät oikein sovellu tämmöiseen ympäristöön kun tässä ei ole mitään GUI.ta käytettävissä. Kuitenkin - jonkinlainen demo kannattaa tehdä vaikka paperille ja "ajaa" sitä kunnes se vaikuttaa riittävän toimivalta.
No, ehkä nämä ovat sinulle jo tuttuja juttuja joten en jauha sen enempää. Jos edelleen vaikuttaa kiinnostavalta niin sitten ei kai muuta kuin menoksi.

LainaaKäytännön kysymyksiä: onko sinulla esim Microsoft Office-paketin työkaluja käytössä ja jos on niin mitä ja mitä versioita? Powerpoint ja/tai Visio olisivat aika hyviä/helppoja käyttöliittymän mock-upien tekoon joskin muitakin toimivia on. Nuo yleiset mockup-työkalut vaan eivät oikein

Jep, kaikki mahdolliset versiot löytyy, ehdottaisin käytettäväksi 2007:aa.

Minä ryhdyn miettimään käyttöliittymää. Sen pitää olla niin yksinkertainen että sitä voi käyttää ilman käyttöohjeita.
Syöttölaitteina saattaa riittää napit ENTER, ESC, <, >,  ^, v ja yksi pyörivä säädin. Mahdollisesti pari lisää mutta melko vähillä pärjätään.

Koetan saada viikolla mietettyä ensimmäisen version toiminnoista ja UI:n toiminnasta, palaan asiaan kun on jotain näytettävää.

Sellainen asia tuli vielä mieleen että kun tästä pitäisi saada idioottivarma ettei esimerkiksi terää voi ajaa pakkaan kiinni, niin miten se pitäisi toteuttaa? Rajakytkimillä vai näytetään ensin liikkeiden äärireunat? Tuo jälkimmäinen ei vain ole varma menetelmä jos kelkan irrottaa trapetsista.

Lainaus käyttäjältä: Tauru - 10.01.10 - klo:18:27
Jep, kaikki mahdolliset versiot löytyy, ehdottaisin käytettäväksi 2007:aa.

Mielestäni kannattaa käyttää vanhempaa talletusformaattia esim 2003 tai 97, kaikilla ei ole välttämättä uusimipia versioita käytettävissä.

Sauli

Lainaus käyttäjältä: Tauru - 10.01.10 - klo:18:27
Jep, kaikki mahdolliset versiot löytyy, ehdottaisin käytettäväksi 2007:aa.

Lainaus käyttäjältä: saulij - 10.01.10 - klo:19:23
Mielestäni kannattaa käyttää vanhempaa talletusformaattia esim 2003 tai 97, kaikilla ei ole välttämättä uusimipia versioita käytettävissä.
Sauli

Itsekin mielelläni käyttäisin 2007:aa, mutta saulij on siinä oikeassa, että ei pitäisi aiheuttaa hankaluuksia niille joilla ei noita versioita ole. 2007 tallentaa myös 2003-formaatissa joten se voisi olla sopiva minimi. Windows 97 ehkä on jo niin historiaa, että rajoittaa liikaa.
Tosin, onhan olemassa Open Office joka on ihan napakka paketti sekin. Sen voi kuka vaan hakea itselleen ilmaiseksi ja sen jälkeen on kaikilla varmasti yhteensopivat vehkeet. En ole tätä vaatimassa, mutta minulle se kyllä sopisi. Juuri nyt ei ole OO:ta asennettuna omallakaan koneella, mutta eipä siihen kauaa mene.

Lainaus käyttäjältä: Tauru - 10.01.10 - klo:18:27
Minä ryhdyn miettimään käyttöliittymää. Sen pitää olla niin yksinkertainen että sitä voi käyttää ilman käyttöohjeita.
Syöttölaitteina saattaa riittää napit ENTER, ESC, <, >,  ^, v ja yksi pyörivä säädin. Mahdollisesti pari lisää mutta melko vähillä pärjätään.

Koetan saada viikolla mietettyä ensimmäisen version toiminnoista ja UI:n toiminnasta, palaan asiaan kun on jotain näytettävää.

Sellainen asia tuli vielä mieleen että kun tästä pitäisi saada idioottivarma ettei esimerkiksi terää voi ajaa pakkaan kiinni, niin miten se pitäisi toteuttaa? Rajakytkimillä vai näytetään ensin liikkeiden äärireunat? Tuo jälkimmäinen ei vain ole varma menetelmä jos kelkan irrottaa trapetsista.

Turvarajajuttua ei ole keskusteltu loppuun asti, tuskin oikein vielä aloitettukaan. Eri yhteyksissä olen itse kirjoitellut siihen tyyliin, että ohjaimessa olisi molemmat, eli turvarajakytkintulot joita voi käyttää tai ei, sekä liikkeiden rajojen näyttö ajamalla. Opetettavia rajoja pitää olla ehkä useampi setti, äärirajoille yhdet ja työkierron ääripäille toiset. Esim. kierteen ja kartion ajossa kelkan aloitus- ja lopetuskohta sekä kartiolle vielä terän syötön aloitus ja lopetuskohta (hmm... kartio kai ehkä kuitenkin lasketaan, joten sille kai vain toinen).

Jonnelle huomioksi, että kohta on kädessä ensimmäinen versio käyttöliittymästä. Nyt olisi aika antaa evästystä niistä kiertokytkimistä jos vielä meinaat saada ne kyytiin ;)

Office 2003 lienee sopiva kompromissi. Ehdottaisin että pysytään MS Officessa ja siirrytään Open Officeen jos tulee liikaa yhteensopivuusongelmia. Tietääkseni OO lukee ja kirjoittaa Office 2003 formaattia

Sopii hyvin. Office 2003 on virallinen formaatti kunnes toisin päätetään.

Ehdottaisin yhtä, max kahta kiertokytkintä. Hoidetaan homma valikkopohjaisesti eli ensin valitaan mitä tehdään, esim. kierteen nousu ja sitten syötetään numero kiertokytkimellä. Jos jossain tilanteessa pitää antaa useampia numeroita (moninumeroinen luku) niin niiden syöttäminen kiertokytkin + enter onnistuu nopeasti. Näin vältetään numeronäppäimistön tarve.
Mielestäni kotelo saisi olla mahdollisimman pieni joten turhat näppäimet pois, mutta ei kuitenkaan käytettävyyden kustannuksella.
Tee pian ehdotuksen käyttöliittymän toiminnasta johon voitte sitten kommentoida sen toimivuutta.

Joku, nyt en enää muista kuka, ehdotti että paneelienkooderilla kiertämällä voitaisi pikavalita esiasetettuja arvoja. Noiden arvojen työttäminen saisi olla vähän hitaampaakin, koska kerran syötettyinä niitä lähinnä vain valitaan käyttöön.
Minulla on semmoinen ohjelmoitava labravirtalähde, jonka käyttöliitymä on tehty tuohon tyyliin.
Jännitten ja virtarajan yms asetukset tehdään parilla napilla joilla osoitetaan dekadi ja kooderilla pyöritetään lukuarvo. Käy yllättävän näppärästi. Arvot voi tallettaa muistiin pikavalittaviksi.

Varmasti kannattaa tehdä vakiokierteille esiasetukset kuten myös MT1-MT5 -kartioillekin. Hyvä ehdotus, toteutetaan se heti.

Moro,

Täältä myös ääni esivalinnoille, jotka voi valita kiertokytkimellä ja joihin esivalintoihin kukin voisi ohjelmoida omat tarpeelliset parametrinsä.

Mitenkäs se nyt on, tuleeko tähän kaksi moottoriohjausta eli toinen ajamaan sitä kelkan syöttöruuvia eli "sähköinen syöttövaihteisto" ja vielä toinen siirtämään terää radiaalisesti (kiinni ja irti kappaleeseen esim. kierteen aloittamiseksi ja lopettamiseksi sekä kartioita varten) ?  Ilmeisesti siis molemmat jotta tuo kartiohomma on myös mahdollinen.

Käyttöliittymää ajatellen tässä hieman pohdintaa ääneen. En oikein ole vielä hahmottanut miten tämä voisi mennä eikä minulla ole pitkää sorvaajakokemusta estämässä tälläistä vapaata ideointia :)

En tiedä tarvitaanko tuossa lainkaan numeronäppäimistöä, jos noiden parametrien ohjelmoimisen muistipaikkoihin voisi tehdä vaikkapa kierrettävällä kooderilla jossa olisi vielä painotoiminto "enterinä". Tai sitten syöttää ne sinne tietokoneelta.

Eli vehkeessä voisi olla :

* näyttö
* mode-kiertokytkin, jossa asennot "KIERTEET", "KARTIO", "VAPAA LIIKE", "ASETUKSET" (tuosta näkisi heti kiertokytkimen asennosta missä moodissa ollaan)
* pyöritettävä kooderi jossa painamalla "ENTER" ja jolla valitaan kulloisessakin moodissa toiminto valikkoa selaamalla ja jolla myös voi syöttää parametreille numeroarvoja sitä pyörittämällä
* kaikissa valikoissa vehkeen pitäisi muistaa sinne aikaisemmin ohjelmoidut toiminnot, jotka löytyvät sitten kulloisestakin mode-valikosta eli esim. vakiokierteet ja vakiokartiot
* erillinen (?) "kauko-ohjain", jossa nappulat jolla operaattori käytännössä "ajaa" sorvia eli käynnistää ja pysäyttää mode:n avulla valitun toiminnon (tai osoittaa esim. kierteen aloitus ja lopetuspaikkaa)

Tässähän on sitten tarve käyttää sorvia myös manuaalisesti siten että käsiohjauksessa ajaa tuota syöttöruuvia, eli toimia moodissa "VAPAA LIIKE". Tähän esittäisin sellaista ratkaisua, jota käytetään noissa ShuttlePro-ohjaimissa eli niissä tuo pyöreän säätimen ulompi kehä on jousikuormitteinen potentiometri, jota voi kääntää n. 30-40 astetta kumpaankin suuntaan mutta joka palautuu nollaan kun siitä päästää irti. Se sisempi kehä on sitten perinteisempi MPG-pulssipyörä. Eli esimerkiksi : http://retail.contourdesign.com/?/products/22

Eli tuo ulompi kehä toimii kuin analoginen joystick. Nimittäin käytän tuota jyrsimessäni ja sillä on todella helppo ajaa valittua akselia manuaalisesti halutulla nopeudella ja paikoittaa se myös tarkasti. Tuskin koskaan tulee käytettyä sitä sisempää MPG-pyörää. Kun käännät ulompaa pyörää vähän niin mennään hitaasti. Kun käännät enemmän mennään kovempaa ja nopeussäätö on mukavast portaaton. Ja eri suuntiin kääntämällä vaihtuu suunta. Ja mikä parasta, sillä on todella helppo ajaa akselia manuaalisesti vakionopeudella eli kääntää pyörää tietyn verran ja pitää se siinä kohtaa koko työstön ajan. Eli tuollaisella sopivasti sijoitulla nupilla olisi mukava ajaa sitä syöttöruuvia ja mikä ettei myös ehkä sitä radiaaliliikettä. Tuollaisen potikan voinee ostaa jostain erikseen niin ei tarvitse ostaa mitään ShuttlePro-tuotetta sinänsä.

Eli oletteko pohtineet sitä onko tuo näyttöosa ja "kauko-ohjain" erillisiä laitteita vai ovatko kaikki nupit ja napit samassa laatikossa ?

Terv. JuhaV

Kiitos ideoinnista, siinä oli paljon juttuja mietittäväksi. Teknisesti kaikki lienee mahdollisia toteuttaa. Varmaan pitää kohta ruveta ylläpitämään jotain määrämuotoisempaa listaa haluista, tarpeista ja vaatimuksista niin, että toteutukset voidaan perustaa kunnolla päätettyihin juttuihin. Nämä ajatukset otetaan sinne listalle mukaan.

Tällä hetkellä olen ohjelmiston osalta miettinyt kahden akselin mukaantuloa, ei se kartion sorvaus muuten onnistu. Tai no onnistuu pylkkää siirtämällä. mutta tuskin sillä konstilla mitään Morseja saa tehtyä, ainakaan ei meikäläisen kiinalaismysteerillä.
Se on sitten vähän toinen juttu, miten cnc-koneen omaiseksi tuo säteen suuntainen syöttö pitää saada. Jos kelkan liikkeet näytetään koneelle ja sanotaan, että aja vaikka kartiota 1:20 tms miten nyt halutaan syöttää, niin kyllä liikkeet voidaan ohjata jo tuon perusteella, vaikka ei todellisesta säteestä olekaan tietoa. Käyttäjä voi sitten itse mittailla kappaleen säteet ja ajaa terää sopivaan alkusäteeseen siivun aluksi. Tai jotain. Kyllä numeerinenkin syöttö toisaalta onnistuu yhtä hyvin, ei sinä mitään.
Analogisesta ohjauksesta Jonnella oli kommentti aikaisemmin.
Kauko-ohjainta ei ole mietitty, mutta voidaan kyllä laittaa listalle. Elektroniikkaan se tuo vähän lisää, mutta ei mitään elämää suurempaa. Toimintona minä ostaisin sen kyllä, muilla on omat mielipiteensä.

Hyvä Hyvä... Pikkuhiljaa alkaa muotoutua raja-arvot raudalle. Mulla pukkaa taas lyhyttä Kiinan keikkaa, mutta sen jälkeen aikaa onkin enempi harrasteisiin. Kun sieltä noin kuukauden päästä palaan, pääsen varmaan tekemään rautaa jo aika valmiin konseptin pohjalta? Yleensä, kun rupean rautaa suunnittelemaan, muuttuu se matkalla aika paljon. Jospa nyt pääsisi tekemään kerralla valmista  ;D

Lainaus käyttäjältä: ram - 12.01.10 - klo:18:14
Jospa nyt pääsisi tekemään kerralla valmista  ;D

Jaa sen kun näkis niin piirtäis ristin seinään  :P :P :P

Meinasin jo aikaisemmin vastata JuhaV:n kommentteihin varsin kriittisesti, mutta sitten kun hetken mietiskelin niin kyllä hänen ajatuksissaan on paljon asiaan.

Lainaamode-kiertokytkin, jossa asennot "KIERTEET", "KARTIO", "VAPAA LIIKE", "ASETUKSET" (tuosta näkisi heti kiertokytkimen asennosta missä moodissa ollaan)

Tästä innostuin alkujärkytyksen jälkeen, mutta sitten taas rupesin miettimään asiaa uudelleen. Jos kiertokytkimestä näkee heti mitä on tekemässä, niin mitä tapahtuu sitten kun kesken kierteytyksen joku päättää vaihtaa vahingossa tai tahallaan kytkimen KARTIO-asentoon? Kiertokytkin on hyvä ja havainnollinen, mutta olisin kuitenkin edelleen sitä mieltä että valikko-pohjainen ratkaisu toiminnon valintaan on parempi ja riittävän selkeä. Ja sen laajentaminen jatkossa uusilla toiminnoilla onnistuu varmasti helpommin.

Lainaapyöritettävä kooderi jossa painamalla "ENTER" ja jolla valitaan kulloisessakin moodissa toiminto valikkoa selaamalla ja jolla myös voi syöttää parametreille numeroarvoja sitä pyörittämällä

Varmasti toimiva ja hyvä ratkaisu, olin jo itsekin miettinyt tätä.

Lainaa
* kaikissa valikoissa vehkeen pitäisi muistaa sinne aikaisemmin ohjelmoidut toiminnot, jotka löytyvät sitten kulloisestakin mode-valikosta eli esim. vakiokierteet ja vakiokartiot

Tämä OK

Lainaa* erillinen (?) "kauko-ohjain", jossa nappulat jolla operaattori käytännössä "ajaa" sorvia eli käynnistää ja pysäyttää mode:n avulla valitun toiminnon (tai osoittaa esim. kierteen aloitus ja lopetuspaikkaa)

Kauko-ohjain on hyvä lisä varsinkin jos laitteen kotelosta tulee valtavan kokoinen (siis suurempi kuin mitä minä saan sopivasti sijoitettua omaan sorviini sopivasti hollille.

Jos kartiosorvauksessa on mukana nollakulmaisen kartion (== lieriö) ajaminen niin sitten tankojen ohennukset onnistuvat helposti.

LainaaTässähän on sitten tarve käyttää sorvia myös manuaalisesti siten että käsiohjauksessa ajaa tuota syöttöruuvia, eli toimia moodissa "VAPAA LIIKE". Tähän esittäisin sellaista ratkaisua, jota käytetään noissa ShuttlePro-ohjaimissa eli niissä tuo pyöreän säätimen ulompi kehä on jousikuormitteinen potentiometri, jota voi kääntää n. 30-40 astetta kumpaankin suuntaan mutta joka palautuu nollaan kun siitä päästää irti. Se sisempi kehä on sitten perinteisempi MPG-pulssipyörä. Eli esimerkiksi : http://retail.contourdesign.com/?/products/22

Tämä on hyvä ajatus, ehdottomasti pitää pystyä ajamaan konetta manuaalisesti ja mielellään molempiin suuntiin. Tämä oli minulla omalla toivelistalla mukana.

Minä koetan kasata alustavan listan toiminnoista ja ensimmäisen ehdotuksen valikoista. Sitä sitten saa kommentoida ja jos jollain on jo nyt toiveita niin kannattaa laittaa viestiä. Muutamalla iteraatiolla saadaan varmasti hyvä lopputulos.

Minulle kaikki kuullostaa hyvältä, ei tarvetta kommentointiin. Kuittaan vain tuon yhden kohdan, eli "nollakulmaisen" kartion ajaminen on luonnollisesti tulossa mukaan. Sehän ei "maksa" mitään.

Tähän liittyen kysymys niille joilla on vankempi näkemys itse sorvaustyöstä: Kartiotahan on mahdollisuus ajaa kaikkiaan neljällä eri tavalla: siivun ajo joko oikealta vasemmalle tai päinvastoin, ja kummassakin tapauksessa kartion säde joko pienentyen tai suurentuen. Onko kaikki vaihtoehdot a) yhtä todennäköisiä ja b) syytä ottaa mukaan?
Ainakin milloin säde siivunotossa kasvaa, kelkan (X) johderuuvi pyörii niinpäin, että mutterin välys pyrkii auki ja teräpaine työntää sitä taas kiinni. Tämä voi teoriassa aiheuttaa terän tärinää, mutta onko oikeasti riski?
Jos taas ajetaan säde pienentyen, ei tätä riskiä ole, mutta silloin on teoriassa mahdollista, että teränpidin osuu kappaleseen terän leikkussärmän takana jos kartiokulma on liian jyrkkä käytetylle terälle. Pitääkö huomioida ja miten. Yksi mahdollisuus olisi, että jonkin raja-arvon jälkeen ohjain varoittaa tästä ja käyttäjä joutuu erikseen vahvistamaan teränpitimen asetuksen turvalliseksi. Tai jotain muuta.

Lainaus käyttäjältä: Kremmen - 14.01.10 - klo:09:07

Tähän liittyen kysymys niille joilla on vankempi näkemys itse sorvaustyöstä: Kartiotahan on mahdollisuus ajaa kaikkiaan neljällä eri tavalla: siivun ajo joko oikealta vasemmalle tai päinvastoin, ja kummassakin tapauksessa kartion säde joko pienentyen tai suurentuen. Onko kaikki vaihtoehdot a) yhtä todennäköisiä ja b) syytä ottaa mukaan?
Ainakin milloin säde siivunotossa kasvaa, kelkan (X) johderuuvi pyörii niinpäin, että mutterin välys pyrkii auki ja teräpaine työntää sitä taas kiinni. Tämä voi teoriassa aiheuttaa terän tärinää, mutta onko oikeasti riski?
Jos taas ajetaan säde pienentyen, ei tätä riskiä ole, mutta silloin on teoriassa mahdollista, että teränpidin osuu kappaleseen terän leikkussärmän takana jos kartiokulma on liian jyrkkä käytetylle terälle. Pitääkö huomioida ja miten. Yksi mahdollisuus olisi, että jonkin raja-arvon jälkeen ohjain varoittaa tästä ja käyttäjä joutuu erikseen vahvistamaan teränpitimen asetuksen turvalliseksi. Tai jotain muuta.

Tämä välysasiahan tässä tulee vastaan.  Ainakin pinnanlaatu saattaa tulla kehno, vaikka sorvaus muuten onnistuisikin, jos akseli liikkuu epämääräisesti. Yleensä pyritään sorvaamaan pakkaan päin eli vasemmalta oikealle. Silloin yleisimmän kartion sorvauksessa X-akseli kulkee poispäin, eli välys on väärällä puolella. Jos kartio ajetaan pakasta poispäin, tarvitaan toisenkätinen terä.  Tässä asiassa on niin paljon muuttujia: koneen kunto, koko, kartion mitat, työstöarvot jne... että niitä kaikkia ei voi ottaa huomioon ohjainta suunniteltaessa.  Nämä asiat täytynee vain hyväksyä, manuaalikoneissa on omat puutteensa. Testien perusteella voisi tietysti käyttöohjeeseen laittaa joitakin vinkkejä, joilla näitä haittoja voi minimoida.

Mielestäni tähän ei kannata kehittää stepperin tai servon ohjaimia. Erilaiset koneet vaativat erilaiset moottorit, mihin vetää raja? Stepperi- ja servo-ohjaimia on saatavilla melko edullisesti jokalähtöön. Pitäydytään vain step/dir lähdössä, ainakin aluksi. Siinäkin lienee jo haastetta pitkäksi aikaa.

Sauli

Terve

Mun eka postaus täällä joten jos kirjoittelen ihan omiani, niin ylläpito voi poistaa tän postauksen jos havaitaan liian asiantuntemattomaksi. En saa sieluun pipiä. Ymmärrän että cnc on asia josta en juuri ymmärrä mitään.

Minua kiinnostaa lähinnä manuaalikone, pieniä metallisorveja (30 - 160 kg) löytyy autotallista kolme + pikkurelvolverin raato. Ja toki pikkuien metallivannesaha sekä 1.5 tonnia painava vanha universaalipäällä/vaaka jyrsin. Periaatteessa cnc ei ole mun 1. kiinnostuskohde, mutta joku ELS-tyylinen juttu kylläkin.

Yritin lukea langan huolella läpi, mutta huomasin hyvin vähän substanssia lukituksista ja turvallsitamisesta. Muistaakseni siellä oli yksi viite missä mainittiin että EU-tason turvallisitaminen koskisi tätäkin projektia. Mihin tämä perustuu? Jos tehdään myyntiin tai saatetaan muuten markkinoille, niin silloin toki kuuluu, mutta jos tekee itselleen (ei siis myyntiin) harrastuslaitetta jota käyttää itse, niin silloin itse saa päättää minun tietääkseni turvallisuustason.

Tarkoituksenani ei ole viisastella, vaan käytännössä minusta tälläisiin projekteihin kannattaa raja vetää suunnilleen eletroniikan kohdalle. Toki on erittäin ystävällistä kertoa jäännösriskit ja kertoa esmerkinomaisesti miten "eräs" loppukäyttäjä on saanut laitteesta "riittävän" turvallisen omaan käyttöön.

Jos rakentaisin jotain tätä itselleni, niin mulle riittäis manuaalikoneessa hätä-seis piiri, joka olis kahdennettu ja sen perässä kontti. Jos olis suojuksia, niin nekin samaan piiriin.

Jos taas pitäis tehdä ihan kaupalliseen käyttöön valmis sovellus, niin riskianalyysien ja vikaantumisvälitarkastelun jälkeen päästään vasta tarvittavan kategorina ja sitä kautta komponenentteihin, suojauksiin ja muihin piirteisiin. Käytännössä koko vehje pitää aidata ja/tai koteloida, kaikkiin avattaviin luukkuihin mekaaniset rajakytkimet, kaikki turvapiirit kahdennettu, kaikki turvakomponentit valmsitajan luokittelemat ja turvallisesti vikaantuvia jne. Jopa tämän dokumentointi asiallisesti on kohtalainen urakka.

Olisiko sopiva keskitie tehdä "avoimen koodin" projektista sellainen että jokainen voi kovolangoittaa hätä-seis-piirin ja erotuksen kuten haluaa ja "elektroniikka" on liitetty tähän turvallsitavaan systeemiin vain muutamalla tilasta kertovalla inputilla ja ehkä jollakin ennable tai watchdog lähdöllä pääkonteille? Olisi varmaan aika työlästä tehdä näin pientä juttua kahdennetusti ja "turvalogiikalla".

Eli minun ehdotus on lyhyesti se että erotetaan "vaarallinen/monimutkainen/todentamaton" ja itsetehty ohjauselektroniikka helposti syöttöpuolelta erotuskytkimellä (vira pois/åäälle) ja toisesta päästä releellä/kontilla jota ohjataan langoitetulla (pelkästään kovo ja mielellään sähköisesti kahdennettulla) hätä-seis-piirillä.

Lisäksi ohjaimelle pitää saada tilatieto että hätä-seis-piiri on päällä/pois ja vaikka yksi inputti että kaikki suojukset kiinni (jos ei ole suojuksia jne, niin jomppi).

Onko ollut tapana liittää joku ulkopuolinen watchdog rele tms. jolla valvotaan että ohjaimessa on kaikki kotona? Ja/tai ennable lähtö että ohjain on omasta mieletään kaikissa SW/HW voimissa ja valmis ohjaamaan ja jos valmius katoaa, niin pääkontilata (tai sitä ohjaavalta piiriltä poistuu pitovirta)?

Ymmärsinkö totaalisesti väärin?

PekkaNF

Lainaus käyttäjältä: saulij - 14.01.10 - klo:10:50
Tämä välysasiahan tässä tulee vastaan.  Ainakin pinnanlaatu saattaa tulla kehno, vaikka sorvaus muuten onnistuisikin, jos akseli liikkuu epämääräisesti. Yleensä pyritään sorvaamaan pakkaan päin eli vasemmalta oikealle. Silloin yleisimmän kartion sorvauksessa X-akseli kulkee poispäin, eli välys on väärällä puolella. Jos kartio ajetaan pakasta poispäin, tarvitaan toisenkätinen terä.  Tässä asiassa on niin paljon muuttujia: koneen kunto, koko, kartion mitat, työstöarvot jne... että niitä kaikkia ei voi ottaa huomioon ohjainta suunniteltaessa.  Nämä asiat täytynee vain hyväksyä, manuaalikoneissa on omat puutteensa. Testien perusteella voisi tietysti käyttöohjeeseen laittaa joitakin vinkkejä, joilla näitä haittoja voi minimoida.

Kannattaisiko sitten miettiä oletusarvoksi tuota perustapaa ja ehkä erikseen asetuksista muuttamalla sille vaihtoehtoisia tapoja. Liikkeenohjauksen kannalta kaikki vaihtoehdot ovat samanarvoisia, mutta ei tietysti kannata tehdä toiminnoista turhaan mutkikkaita.

Lainaa
Mielestäni tähän ei kannata kehittää stepperin tai servon ohjaimia. Erilaiset koneet vaativat erilaiset moottorit, mihin vetää raja? Stepperi- ja servo-ohjaimia on saatavilla melko edullisesti jokalähtöön. Pitäydytään vain step/dir lähdössä, ainakin aluksi. Siinäkin lienee jo haastetta pitkäksi aikaa.

Ei tästä haastetta tule puuttumaan, se on varmaa. Omana mielipiteenäni esitän, että perustason ratkaisu pitäisi saada yhteen purkkiin. Muuten ollaan kehittämässä modulijärjestelmän yhtä komponenttia eikä toimivaa kokonaisuutta. Alkuperäinen idea oli "yksinkertainen" johderuuvin ohjaus. Yksinkertaisuuskin saadaan toki katoamaan ellei olla maltillisia ja onhan totta, että isompi kone vaatii isommat moottorit. Stepperin ohjaus on kumminkin sen suhteen aika joustava. Minua houkuttelee mahdollisuus tehdä hitailla nopeuksilla juoheasti pyörivä systeemi ja integroidussa ratkaisussa sen saa halvimmalla.
Mutta laitetaan ram töihin suunnittelemaan meille sopiva lähtömoduli jossa voi olla kokonainen moottorinohjaus (stepperi tai servo) tai sitten vain askel/suuntaohjaus. Vielä ohjelmallisesti havaittavissa millainen moduli on kytkettynä niin ei tarvitse kertoa ohjaimelle mitään erikseen. Voidaan sitten vaikka aloittaa sillä askel/suuntavaihtoehdolla joka on helpoin tehdä, ja jos tarvetta tuntuu olevan niin jatketaan vaikeammilla vaihtoehdoilla.

Lainaus käyttäjältä: PekkaNF - 14.01.10 - klo:13:56
Terve

Mun eka postaus täällä joten jos kirjoittelen ihan omiani, niin ylläpito voi poistaa tän postauksen jos havaitaan liian asiantuntemattomaksi. En saa sieluun pipiä. Ymmärrän että cnc on asia josta en juuri ymmärrä mitään.

Huonompia on nähty paljon  :P Tässähän oli kovasti asiaa.

Lainaa
...
Yritin lukea langan huolella läpi, mutta huomasin hyvin vähän substanssia lukituksista ja turvallsitamisesta. Muistaakseni siellä oli yksi viite missä mainittiin että EU-tason turvallisitaminen koskisi tätäkin projektia. Mihin tämä perustuu? Jos tehdään myyntiin tai saatetaan muuten markkinoille, niin silloin toki kuuluu, mutta jos tekee itselleen (ei siis myyntiin) harrastuslaitetta jota käyttää itse, niin silloin itse saa päättää minun tietääkseni turvallisuustason.

Tarkoituksenani ei ole viisastella, vaan käytännössä minusta tälläisiin projekteihin kannattaa raja vetää suunnilleen eletroniikan kohdalle. Toki on erittäin ystävällistä kertoa jäännösriskit ja kertoa esmerkinomaisesti miten "eräs" loppukäyttäjä on saanut laitteesta "riittävän" turvallisen omaan käyttöön.

Keskustelua juuri tämän sähköisen vaihdelaatikon tai johderuuvin kohdalla ei ole sen enempää käyty, jäänee nähtäväksi käydäänkö. Minusta rajanveto juurikin noin olisi hyvin lähellä tarkoituksenmukaista. Olen itse toistaiseksi suhtautunut ajatukseen siten, että ohjaimeen tulee riittävä määrä tuloja ja lähtöjä joilla sen ajotilaa voidaan hallita niin, että siitä saadaan turvallinen. Kukin rakentaa ohjaimen omaan koneeseensa juuri kuten esität ja päättää siis omalta osaltaan mihin riskitasoon tyytyy. Tärkeintä on, että ohjaimeen ei rakenneta sellaisia "yllätyksiä" ettei siitä edes periatteessa voi saada turvallista.

Lainaa
Jos rakentaisin jotain tätä itselleni, niin mulle riittäis manuaalikoneessa hätä-seis piiri, joka olis kahdennettu ja sen perässä kontti. Jos olis suojuksia, niin nekin samaan piiriin.

Siihen aikaan kun olin itse mukana koneautomaatiota tekemässä, hätäseispiirit rakennettiin sarjaankytketyillä avautuvilla koskettimilla. Mitenkäs sen oikein kahdentaisi? Kytkin auki mikä auki niin piiri on poikki. Muuten ajatuksena kyllä juuri noin.

Lainaa
Jos taas pitäis tehdä ihan kaupalliseen käyttöön valmis sovellus, niin riskianalyysien ja vikaantumisvälitarkastelun jälkeen päästään vasta tarvittavan kategorina ja sitä kautta komponenentteihin, suojauksiin ja muihin piirteisiin. Käytännössä koko vehje pitää aidata ja/tai koteloida, kaikkiin avattaviin luukkuihin mekaaniset rajakytkimet, kaikki turvapiirit kahdennettu, kaikki turvakomponentit valmsitajan luokittelemat ja turvallisesti vikaantuvia jne. Jopa tämän dokumentointi asiallisesti on kohtalainen urakka.

Tämä viritys kai olisi enempi manuaalinen kone jossa automaattisia liikkeitä, siis ei varsinainen cnc. Silloin ei tarvitse kokonaan umpioida. Mutta taitaa olla turhaa jossittelua. Joka tästä tekee kaupallisen koneen osan tietää kyllä mitä turvajuttuja vaaditaan. Jossei aluksi niin ainakin heti kohta :)

Lainaa
Olisiko sopiva keskitie tehdä "avoimen koodin" projektista sellainen että jokainen voi kovolangoittaa hätä-seis-piirin ja erotuksen kuten haluaa ja "elektroniikka" on liitetty tähän turvallsitavaan systeemiin vain muutamalla tilasta kertovalla inputilla ja ehkä jollakin ennable tai watchdog lähdöllä pääkonteille? Olisi varmaan aika työlästä tehdä näin pientä juttua kahdennetusti ja "turvalogiikalla".

Juuri tuo on ollut ajatus.

Lainaa
Eli minun ehdotus on lyhyesti se että erotetaan "vaarallinen/monimutkainen/todentamaton" ja itsetehty ohjauselektroniikka helposti syöttöpuolelta erotuskytkimellä (vira pois/åäälle) ja toisesta päästä releellä/kontilla jota ohjataan langoitetulla (pelkästään kovo ja mielellään sähköisesti kahdennettulla) hätä-seis-piirillä.
Lisäksi ohjaimelle pitää saada tilatieto että hätä-seis-piiri on päällä/pois ja vaikka yksi inputti että kaikki suojukset kiinni (jos ei ole suojuksia jne, niin jomppi).

Jep. Hätäseis-piiriin ei saa ottaa mukaan mitään ohjelmallisia osuuksia, sen täytyy olla pomminvarma katkaisemaan toiminnot. Mekaaniset äärirajakytkimetkin saisivat mielestäni olla sellaisia, että estävät rautatasolla ajamisen päin (tai "läpi"), eli siis vain peruutus rajalta on mahdollista. Nähtäväksi jää miten käytännössä onnistuu.
Ja siis kaikista noista tilatiedot myös ohjaimelle, jotta ajotilan ohjaus saadaan johdonmukaiseksi. Ellei ohjain tiedä koneen olevan esim. hätäseis-tilassa vaan jatkaa steppereiden pulssitusta niin voi käydä huonosti kun käyttäjä vapauttaa hätäseis-kytkimen. Tähän liittyviä juttuja täytyy vielä miettiä jota saadaan varma ja juoheasti pelaava systeemi.

Lainaa
Onko ollut tapana liittää joku ulkopuolinen watchdog rele tms. jolla valvotaan että ohjaimessa on kaikki kotona? Ja/tai ennable lähtö että ohjain on omasta mieletään kaikissa SW/HW voimissa ja valmis ohjaamaan ja jos valmius katoaa, niin pääkontilata (tai sitä ohjaavalta piiriltä poistuu pitovirta)?

Tapana on ollut :). Prosessorilla on oma vahtikoiransa jota käydään taputtelemassa aika tarkkaan määrätyin minimi- ja maksimivälein jotta se uskoo ohjelman olevan järjissään (eikä esim vahtikoiran nollaussilmukassa jumissa). Jos vahtikoira haukahtaa niin kontrolleri tekee välittömän resetin. Tähän tilanteeseen liitetään sitten pätkä koodia joka analysoi miten systeemi nousi ylös - normaalikäynnistyksellä vai vahtikoiraresetillä. Jälkimmäisessä tapauksessa saattaa riippua ohjaimen vallinneesta ajotilasta mitä tehdään seuraavaksi, mutta aika herkästi vedetään hätäjarrukahvasta. Voipi olla ettei paljon muuta lähdetä edes miettimään.
Releohjauksiin sisältyy tietenkin valmiustilan ohjaus jota voidaan käyttää enabloimaan sähköt ja ohjaukset loppukoneelle, sekä aktiivisesta ajotilasta ehkä vielä oma lähtönsä jolla saa käynnistettyä teränesteen kiertoa tms.

Lainaa
Ymmärsinkö totaalisesti väärin?

PekkaNF

Aika totaalisesti oikein :)

OK. Otan tässä vähän takaisin tosta 2-langoitetusta Hätä-seis-piiristä. Ajatteln täsä siis vaan oman autotalliprojektin pohjilta, joten se tulee omaan käyttöön ja sivullisilta pääsy estetty. Tämä sovellus ei mitenkään oleellisesti poikkea mekaanisesti kytketystä johtoruuvista, joten ehkä konetta ei tarvitse suojata erikseen. Riittää että sama hätä-seis-painike erottaa karan ja 1-2 akselin moottorit ohjaimesta ja syötöistä. Tämä antaa vapauksia. Jos lähtökohta olis se että kara pitää pysäyttää hallitusti rampilla ja tehdä jotain muuta ennekun kontti aukeaa, niin silloin systeemi olis vähän vaikeempi.


Jos tykkää standardeista, niin lukemista voi yrittää vaikka tästä:
http://www.lpc-uk.com/siemens/sensors/switoff.htm
http://www.lpc-uk.com/siemens/sensors/swioff7.htm
Vähän huonoa kieltä, mutta kyllä siltä jotain saa selville.

Tietääkseni tilanne on hyvin erilainen jos on vain YKSI katkaistava syöttö, kuten manuaaliset porajyrsimet tai sorvit, Näille riittää kytkentä joka ei kytke virtoja päälle jos syöttö katkeaa ja SEIS/Hätä-seis painike pakotetusti katkaisee virrat. Hyvin yksinkertainen katkaisin.

Jos systeemi on yhtään laajempi, niin käytännössä on pakko käyttää releitä.

Eka vaihtoehto, oikein perinnemallinen:

1-piirinen (siis vain yksi langoitettu piiri, toinen on yleensä ohjaukselle) H-seis:

• Avautuvat ja auki lukkiutuvat "tatit" Hätä-seis-painikkeina. Kiertämällä pompaa ylös. Tässä mallissa on erityisen tärkeätä että avautuva kontakti on mekaanisesti pakotettu aukeamaan. Tämän kanssa voi laittaa sarjaan aukeavan kontaktin suojuksislta ja logiikalta.
• Tatit sarjassa ja yhden tatin painaminen avaa normaalin releen, jonka kärkien kautta katkaistaan syöttö vaarallisille laitteille.
• Erillinen kuittauspainike hälytyksen kuittaamiseen logiikalle
• Logiikkaohjelmiin "reset" puolelle tulo, jotta ei myöskään ohjata mitään toimilaitetta päälle kun tatti on pohjassa.
• Erillinen kuittauspainike hälytyksen kuittaamiseen logiikalle olisi hyvä idea

Hyvä esimerkki on tossa viimeisellä sivulla:
http://www.ab.com/support/abdrives/other/1336/3004.pdf

Tämä olisi minulle aika perustellusti riittävä. Erityisesti jos ohjeistan itselleni testata H-seis piirin toiminta joka kerta ennenkuin aloittaa työskentelyn, jotta viallinen piiri ei jää huomaamatta. Tässähän ei ole oikeesti reduntanttisuutta eikä itsediagnostiikkaa.

Aika harvinain tilanne on sellainen että pääkontti hitsaa kiinni ja ohjaus tai päteaste päättää käyttää moottoria.

Tällä takuulla hukatan pulssit akseleilta ja kappale hylkyyn. Pieni hinta turvallisuudesta. Ei kai sitä joudu turvautumaan hätä-seissiin usein.

Tarvitaanko erilliset START/STOP painikkeet joilla voidaan käynnistää ja pysäyttää hallitusti tämä kierteytys/syöttö?

Rähmä kun se olis hyvä viellä "kouluttaa" tai asentaa mikrokytkin rajoittimet joiden välillä kierteytys tapahtuu ja ja kierteen päässä pysähtyy kara tai valinnaisesti kierre loppuu uraan. Mun pitää kurkata käyttöliittymää.

OT:
2. piirisiä langoitettuja hätä-seis-piirejä on n+1 erilaista, alkaen kahdesta erillisestä piiristä, jossa havaitaan vain painikkeen viallinen toiminto (joka poltaa sulakkeen ja poistaa virrat releiden ohjauspiireiltä) päättyen yllättävän monimutkaisiin, kahdennettuihin ja vian havaitseviin systeemeihin.

Tämä on mun mielestä vähän vaikea lähestymistapa, koska sellaisen oikeanlainen suunnittelu ja toteutus vaatii todella paljon osaamista ja on vaikea toistaa erilaisissa sovelluksissa. Toki, jos on vaan yksi "tatti" niin hätä-seis-piiri on helpohko tehdä kahdella piirillä ja yleensä turvallisesti vikaantuvaksi. Mutta siitä tulee helposti paljon vaikeenpi jos siihen samaan pitää saada liitettyä suojuksia kahden käden hallintaa tai valvottuja releitä.


Toinen vaihtoehto olis käyttää turvarelettä:
Tateissa kahdennetut kontaktit, kytketty molemmat omiin piireihinsä.

Näitä on maailma turvoksissa, jotain näistä on käytetty:
http://www.rockwellautomation.com.au/applications/gs/ap/gsau.nsf/files/MSR19E_23872_1B.pdf/$file/MSR19E_23872_1B.pdf

Nämä yleensä havaitsevat tattien ja ohjattavan releen vikaantumisen ja melkoisne joukon vikoja joita ei tule edes ajatelleeksi. Ne on kytkettävä huolellisesti, koska jos kytket esim. tattien piirit: ristiin, plusssan, miikkaan, yhteen tms. väärin niin yksikkö polttaa aina sisällä olevan sulakkeen. Nämä sulkkeet olivat ainakin vielä muutama vuosi sitten himpan erikoisia ja niitä kannatta tilata samalla 10 kpl, eikä niitä saa R-kioskeista.

Tollaista on käytetty viimeaikoina USA:an päin ja toimii täälläkin:
http://www.ab.com/en/epub/catalogs/3377539/5866177/5985760/4444281/4444293/6636286/

Etuna se että tämän kaltaisten turvareleiden lisäksi ei pienessä syteemissä juuri tarvitse muuta kun syötön, tatit ja releet ja takulla on oikein käytettynä riittävän turvallinen. Haittana se että hintaa on turvareleillä helposti 150€/kpl.

Turvalogiikat yms. raskaat ratkaisut on tarpeettoman monimutkaisia/vaikea/kalliita tälläiseen projektiin mielestäni.

PekkaNF

Ei kierteen tekemistä tarvita mikrokytkimiä. Riittää kun siirtää kelkan aloituskohtaa ja syötetään kierteen pituus tai näytetään kelkalla myös lopetuskohta. Rakennettava purkki kyllä tietää milloin askelmoottorilla on kelkkaa ajettu oikea pituus.

Lainaus käyttäjältä: Tauru - 15.01.10 - klo:13:42
Ei kierteen tekemistä tarvita mikrokytkimiä. Riittää kun siirtää kelkan aloituskohtaa ja syötetään kierteen pituus tai näytetään kelkalla myös lopetuskohta. Rakennettava purkki kyllä tietää milloin askelmoottorilla on kelkkaa ajettu oikea pituus.

OK. Meni mulla ajatus sekaisin. Pitää lukea postaukset vielä kerran.

PekkaNF

PekkaNF on aivan oikeilla jäljillä. Hätäpysäytyksen pitää nimenomaan katkaista sähköt ohjaimilta (toki on turvastandartit täyttäviä ohjaimia, joille voi antaa signaalilla hätäpysäytyksen, mutta ovat hinnaltaan kaukana harrastajan pussista).

Tässä tuleekin sitten seuraava ongelma: jos kone tekee automaattisia kierteytysliikkeitä, tarvitaanko koneeseen suojat ympärille? Laki vaatii automaattisia liikkeitä tekevälle koneelle suojat, joko kaappi tai valoverho (ainakin jos keksintöä käytetään firmassa, jossa on töissä muita kuin osakkeenomistajia), miten tämä sitten luokitellaan, vaikea sanoa.
Turvarele menee pakolliseksi joka tapauksessa.

Tietysti pienissä koneissa ei tule ongelmaa, jos kone on niin hengetön, ettei se pysty aiheutamaan kuolemaa tai pysyvää vammaa. Sinne riittää yksipiirinen hätäpysäytys, vaikka suoraan mallia 220VAC on/off/hätäpysäytys-yhdistelmäkytkin.

Mutta jokainen on omista tekeleistään itse vastuussa...

2-piirisiä turvareleita saa muuten noin 100 euroa kpl nykyisin, suhteellisen siedettävä hinta.

Lainaus käyttäjältä: Jonne - 15.01.10 - klo:14:22
Tässä tuleekin sitten seuraava ongelma: jos kone tekee automaattisia kierteytysliikkeitä, tarvitaanko koneeseen suojat ympärille? Laki vaatii automaattisia liikkeitä tekevälle koneelle suojat, joko kaappi tai valoverho (ainakin jos keksintöä käytetään firmassa, jossa on töissä muita kuin osakkeenomistajia), miten tämä sitten luokitellaan, vaikea sanoa.
Turvarele menee pakolliseksi joka tapauksessa.

Tietysti pienissä koneissa ei tule ongelmaa, jos kone on niin hengetön, ettei se pysty aiheutamaan kuolemaa tai pysyvää vammaa. Sinne riittää yksipiirinen hätäpysäytys, vaikka suoraan mallia 220VAC on/off/hätäpysäytys-yhdistelmäkytkin.

Standardit sanoivat ainakin pari vuotta sitten jotenkin hämärästi tai epämääräisesti että jos voima on niin pieni ettei se riitä tekemään pysyvää vammaa tai haittaa, niin matala voima on riittävä. Joisakin vehkeissä matala voima on muistaakseni 100N tms. mutta pienempikin voima riittää siirtämään käden kohti karaa...

Mutta minusta tämä ei ole heikennys alkuperäisen koneen turvallisuuteen. Siinähän on kohtuullisen voimakas toimilaite siirtämässä terää johtoruuvilla ja tässä ollaan lähinnä korvaamassa mekaaninen yhteys sähköisellä yhteydellä. Eikkä tämä välttämättä vaikuta työtapoihin siten että ko. työvaihe tulee tehtyä ainakaan vaarallisemmin. Joten koska aluperäisiä ei ole suojattu niin miten tästä syntyy suojaustarvetta?

Noissa kategorioissa on helppo mennä sekaisin, vaikkapa pysäytyskategoria on mielestäni tässä 0 eli riittää hallitsematon pysäytys (virrat vaan pois) eikä 1, joka vaatisi hallitun ja valvotun pysäytyksen suuren nopeuden, suurten massojen jne takia. Ja vastaavasti voidaan miettiä sähköisen toteutuksen kategoriaa, ehkä tässä ei tarvitse mennä kovin pitkälle, koska tätä käyttää rakentaja itse, joka myöskin testaa turvatoiminnon säännöllisesti. Tehtaassa tosiaan tarvitaan itsediagnostiikkaa ja viat pitää havaita sekä käyttäjän ennakoitu väärinkäyttö ja turvalaitten ohitus pitää ottaa huomioon suunnittelussa.

PekkaNF

Miten olisi turvanopeus.
Standardi varmaankin kertoo millä nopeudella kelkka saa liikkua ihmisten ollessa lähellä.
Yksi mahdollisuus olisi kai joku 'kuolleenmiehen'-kytkin, vai onko tarkoitus jättää sorvi jauhamaan ja lähteä kahville?
Jos kone pyörii yksinään, niin sitten varmasti kysellään muitakin suojalaitteita ympärille.

-Jussi-

 
Yksiero on mekaanisella vaihteistolla ja sähköisellä yhteydellä. Sähköinen versio voi seotessaan
tehdä aivan mitä tahansa, mekaaninen ei.

Toinen pointti on kierteytyksen automaattisuus. X&Z-kelkat liikkuvat itsestään, joten käsitääkseni se
luokitellaan ainakin jokin asteiseksi NC-koneeksi (X-irroittaa itsensä pinnasta kierteen lopussa,
Z-palaa alkuun). Mutta jos tuohon laitetaan vielä automaattisia rouhintyökiertoja, se tarkoittaa
takuulla kaappia ympärille.

Ehkä tätä koko vehjettä kannattaa suositella vain pöytäkoneisiin, jolloin riskit putoavat, samoin turvavaatimukset. Isoihin sorveihin on turha oikeastaan tätä keksintöä asentaa, niissähän on mekaaniset syöttövaihteistot joka tapauksessa. Eikös ollut joku karatehorajakin noissa
turvasäännöksissä?

Lainaus käyttäjältä: Jonne - 15.01.10 - klo:14:22

Tässä tuleekin sitten seuraava ongelma: jos kone tekee automaattisia kierteytysliikkeitä, tarvitaanko koneeseen suojat ympärille? Laki vaatii automaattisia liikkeitä tekevälle koneelle suojat, joko kaappi tai valoverho (ainakin jos keksintöä käytetään firmassa, jossa on töissä muita kuin osakkeenomistajia), miten tämä sitten luokitellaan, vaikea sanoa.
Turvarele menee pakolliseksi joka tapauksessa.

Tietysti pienissä koneissa ei tule ongelmaa, jos kone on niin hengetön, ettei se pysty aiheutamaan kuolemaa tai pysyvää vammaa. Sinne riittää yksipiirinen hätäpysäytys, vaikka suoraan mallia 220VAC on/off/hätäpysäytys-yhdistelmäkytkin.

Mutta jokainen on omista tekeleistään itse vastuussa...

Käsittääkseni lait, säädökset ja standardit koneturvallisuudesta koskevat vain myyntiin asetettuja laitteita ja tietysti itsetehtyjä jos niitä käytetään yrityksessä palkkatyövoimalla. Kotona voi jokainen käyttää ihan niin turvattomia vehkeitä kuin uskaltaa, eikä siitä häkki heilu jos jotain tapahtuu. Vahingot tulee omaan nilkkaan.

Lisäksi ne eivät koske laitteita tai niiden osia jotka yksinään eivät ole vaarallisia vaan vaarallisuus tulee vasta toiseen osaan/koneeseen liitettynä. Tällöin lait, asetukset ym koskevat koko laitetta.

Turvallisuus on tärkeä asia  ja se pitää ottaa huomioon. Mielestäni riittää, että tarvittavat liitännät ovat olemassa ja HW/SW osaa niitä käsitellä. Käyttäjän oma asia on sitten ottako ne käyttöön.

Turvallinen nopeus on muistaakseni 30 mm/s

Tämä muistin varassa muutamien vuosien takaa.

Lainaus käyttäjältä: Jonne - 15.01.10 - klo:17:10
Ehkä tätä koko vehjettä kannattaa suositella vain pöytäkoneisiin, jolloin riskit putoavat, samoin turvavaatimukset. Isoihin sorveihin on turha oikeastaan tätä keksintöä asentaa, niissähän on mekaaniset syöttövaihteistot joka tapauksessa. Eikös ollut joku karatehorajakin noissa
turvasäännöksissä?

Jotain tuon suuntaista olen itsekkin miettinyt. Jos halutaan noudattaa koneenrakennusturvallisuuden standardeja niin tuolta on hyvä aloitttaa:
http://www.sfs.fi/julkaisut/newapproach/kone.html

Lainaus käyttäjältä: saulij - 15.01.10 - klo:17:43
Käsittääkseni lait, säädökset ja standardit koneturvallisuudesta koskevat vain myyntiin asetettuja laitteita ja tietysti itsetehtyjä jos niitä käytetään yrityksessä palkkatyövoimalla. Kotona voi jokainen käyttää ihan niin turvattomia vehkeitä kuin uskaltaa, eikä siitä häkki heilu jos jotain tapahtuu. Vahingot tulee omaan nilkkaan.

Samaa mieltä.

Lainaus käyttäjältä: saulij - 15.01.10 - klo:17:43
Lisäksi ne eivät koske laitteita tai niiden osia jotka yksinään eivät ole vaarallisia vaan vaarallisuus tulee vasta toiseen osaan/koneeseen liitettynä. Tällöin lait, asetukset ym koskevat koko laitetta.

Tuo kannattaa tarkastaa direktiivistä, mielestäni siellä on maininta myös koneen osista.

Lainaus käyttäjältä: saulij - 15.01.10 - klo:17:43
Turvallisuus on tärkeä asia  ja se pitää ottaa huomioon. Mielestäni riittää, että tarvittavat liitännät ovat olemassa ja HW/SW osaa niitä käsitellä. Käyttäjän oma asia on sitten ottako ne käyttöön.

Täysin samaa mieltä, mikäli tuotetta ei ole tarkoitus kaupallistaa vaan pitää se "omassa tallissa, omassa käytössä"

Siinä onkin hiukan epäselvyyttä, jos netissä tarjotaan ohjeita koneen rakentamiseen, jolla voi loukata itsensä. Kuka on silloin vastuussa vai riittääkö varoitustekstit tyyliin alá USA? Tietysti netti on puolillaan
ohjeita räjähdysaineiden teosta tesla-kojeisiin, joilla saa hengen takuulla tehokkaammin pois kuin
manuaalisorvilla, mutta eipä yhtään ennakkotapausta ole ollut.

Ehkä riittää jos kaikissa source-koodeissa ja kytkentäkaavoissa selvästi ilmoitetaan riskitekijät ja
käyttäjän omavastuu, sekä ilmoitetaan "keksinnön" sopimattomuus kaupallisiin tarkoituksiin..?

Lainaus käyttäjältä: Jonne - 15.01.10 - klo:18:38
Siinä onkin hiukan epäselvyyttä, jos netissä tarjotaan ohjeita koneen rakentamiseen, jolla voi loukata itsensä. Kuka on silloin vastuussa vai riittääkö varoitustekstit tyyliin alá USA? Tietysti netti on puolillaan
ohjeita räjähdysaineiden teosta tesla-kojeisiin, joilla saa hengen takuulla tehokkaammin pois kuin
manuaalisorvilla, mutta eipä yhtään ennakkotapausta ole ollut.

Ehkä riittää jos kaikissa source-koodeissa ja kytkentäkaavoissa selvästi ilmoitetaan riskitekijät ja
käyttäjän omavastuu, sekä ilmoitetaan "keksinnön" sopimattomuus kaupallisiin tarkoituksiin..?

Tuossa yllä oli puhetta jostain epämääräisistä standardeista/turvallisuusmääräyksistä, siksi laitoin linkin virallisiin EU-standardeihin.
Kuten saulij tuossa yllä jo antoi ymmärtää, terveen maalaisjärjen käyttö olisi enemmän kuin suotavaa turvallisuusnäkökohtia unohtamatta. 

Laitetaan että "race only" ei tieliikennekäyttöön ...

Moro.
Tää on  nyt ensimmäisiä posteja mitä kirjotan tänne joten ensin hieman itsestäni.
Eli pyöreät 10v on kertyny kokemusta teollisuuden koneiden ja laitteiden suunnittelusta, rakentamisesta ja huollosta. Ammattikoulupohjalla mennään, eli itse on tullut opiskeltua töiren lomassa asiasta ja asian vierestä aika reilusti. Kokemusta on suurista pienistä manipulaattoreista romuliikkeen järisyttävän kokoseen rengasmurskaan. Eli kaikenlaista on jo kerennyt tulemaan vastaan ja lakitietoakin koneista löytyy.

Pari kysymystä koskien tätä projektia.
Käsitin että tässä ollaan tekemässä automaattisyöttöä manuaalisorviin kierteytysmahdollisuudella.
Ja että sitä ollaan toteuttamassa mikropiiriohjauksella. Ymmärsinkö oikein?

Tarkoitus ei oo nyt tosiaankaan keulia eikä vinoolla millään lailla, mutta suosittelisin ottamaan mietintämyssyn alle uudelleen tuon ohjauksen toteuttamisen.
Itse tekisin ehdottomasti teollisuuslogiikalla (esim Siemens S200, tai ABB:n ratkaisut olisi suht edullisia) ja kohtuullisen kokoisella kosketusnäytöllä. Toinen vaihtoehto olisi tutkia ABB:n servo-ohjaimia joihin saa nykypäivänä suoraan liitettyä kosketusnäytön, ja I/O:itakin löytyy riittävästi. Toki muillakin valmistajilla varmasti löytyy, mutta ABB on nyt ensimmäinen tätä uutta sukupolvea mihin on tullu vähän tutustuttua.

Myönnetään että lopetin viestiketjun siinä vaiheessa kun joku oli koodia näpytelly pitkän rivin joten ihan kaikkea tietoa projektista ei oo.

Mutta siis..
Tallennetaan ensin vakiokierteiden arvot logiikkaan patterin taakse.
Näytölle "etusivu" johon saa laittaa suoraan syöttönopeuden ja karanopeuden normaalia ajoa varten ja toinen sivu kierteytykselle jossa vakiokierteet valittavissa suoraan. Määritellään vaan kierteen pituus käsin.
Myös muunlaisten kierteiden tiedot voisi tarvittaessa syöttää manuaalisesti.
Logiikka potkii ensin karamoottorin oikeaan asentoon jonka jälkeen siirtää pikaliikkeellä+hidastuksella terän aloituspaikkaan ja aloittaa kierteytyksen.
Tähän on mahdollisuuksia logiikan + näytön hankkimisen jälkeen tehrä melkein mitä vain hienouksia terärikkotunnistimesta lähtien. Tässä nyt vain nopea heitto omasta mielipiteestäni.

Turvallisuusasioitakin joku oli pohtinut mikä oli oikeastaan aika yllättävää.

Kone pitää pystyä pysäyttämään luotettavasti missä tahansa työvaiheessa (hätäseis, ovirajat)
eikä se saa lähteä käyntiin ilman erillistä kuittausta. Käytännössä tämä tarkoittaa turvareleen tai turvaluokitellun logiikan hankintaa.
Liikkuvat osat pitää olla suojattu siten ettei takertumisen/puristumisen/muun vahingon vaaraa ole koneen normaalissa käytössä. Huomiovärin käyttö on suositeltavaa.
Mikäli liikenopeudet on alle XXXmm/min ei osia tarvitse suojata. (En muista tuota nopeutta mutta käytännössä tosi hitaita. Esim CNC-sorveissa oven ollessa auki akselit ei kovin lujaa liiku.)
Fiksut koneenrakentajat asentaa turvalaitteet niin ettei niitä yksinkertaisesti pysty ohittamaan.

Tuollainen kone ei kummonen ole logiikalla toteuttaa ja kitsaat saa kikkailemalla laskettua kustannuksia jos omahan käyttöhön tuloo.
Että tällaista tuli mielehen. Saa kysyä ja kommentoida.

Vaihtoehtoisia toteutustapoja saa ja kannattaa esittää, mutta tämä sinun ehdotus kuulosti amatöörin korviin kovin kalliilta. Minulla ei ole mitään käsitystä mitä servot ja kosketusnäytöt maksavat.

Lainaakitsaat saa kikkailemalla laskettua kustannuksia jos omahan käyttöhön tuloo.

Jäin miettimään miten hintaan vaikuttaa omaan käyttöön tuleminen?

Heitäppäs vielä ehdotuksesi perään jonkinlainen kustannusarvio mitä tällä tavalla toteutus tulee maksamaan ja minkälainen tuon logiikan ohjelmointihomma on.

Hyvä postaus, eikä aivan ilman ansiota. Tervetuloa.

Mulla on jonkin verran kokemusta keskikoisen (suomessa suuren) metallialan konsernin kulina ja mulle on syntynyt sellainen käsitys että teollisuudessa logiikka ja muu sellainen teollisuuselektroniikka on kustannustehokasta, koska täällä on riittävän paljon volyymiä ja projekteilla kestoa.

Harrastepuolella taas sulautetut on melko lyömätön lähestymistapa jos verrataan normilogiikaan (jota joutuu turvallistamaan langoitetulla logilla kuitenkin). Turvalogiikka kaikkinen työkaluineen ja nykymääräysten mukaisilla laskentatavoilla vaatii aika monta osaajaa. Määräyksetkin muuttu koko ajan. Saappa nähdä miten pienemmät puljut pystyy toimittamaan 2012 vuoden vaihteen jälkeen sellaisia teollisuustuotteita että asiakas uskaltaa ostaan.

Lisäksi logiikoiden tuntemus ja ohjelmointi on verraten harvinaista ja etenkin kun ottaa huomioon että niitä on harrastajalle huonosti saatavilla halpaan hintaan. Jos niitä saa jostain firman hintaan ja ohjelmoinnin opettelun on firma maksanut sekä tarjoo työkalut käyttöön, niin yhtälö on hieman erilainen, mutta ei sen varaan voi laskea....ei ainakaan kaikki.

Mun on ollut kokoajan vaikea mieltää miksi harrastan joka tekee laiteta vai omaan käyttöön, eikä käytä sitä elinkeinon harjoittamiseen, eikä saata sitä markkinoille, joutuisi tekemään käytännössä konedirektiivin viimeisimpien määräysten mukaisen laitteen.

Tosin samaan hengenvetoon jos rakentasin itselleni jotain kunnianhimoisempaa, niin kokoisin itselleni teknisen mapin, johon tulis printattuna (ja tietovälineellä) kaikki ko. laitteeseen kuuluvat tiedot.

Tälläisessä pohdiskelussa ja osien/ohjeiden/omien koodien julkaisemisessa netissä ei mun ymmärtääkseni ole mitään vaaraa, koska yksittäisistä osista ei tule vielä konedirektiivin tarkoittamaa koneta ennen kun joku sen kokoo!

PekkaNF

Rahan suhteen on kaikki aina suhteellista.
Kysymys kuuluu kuinka paljon se saa maksaa?
Hyvää käytettyä tavaraa kannattaa käyttää niin pääsee järkeviin hintoohin.

Kosketusnäyttöjen hinnat on viimevuosina tullut niin alas että ei enää kovin montaa nappia tarvi koneeseen tulla niin ollaan samoissa hinnoissa pienien näyttöjen kanssa. Käytettävyydessä/muokattavuudessa ei olla edes samalla hehtaarilla.

Ebayssa siemens simatic panel 199$ käytettynä. Aivan perus paneli.. vähän ehkä pieni mutta jostainhan on persaukisen tingittävä.
siemens S7 226:nen logiikka (eli tällä mennään jo vaikka puuhun, tai ohjataan kolmea tuollaasta suunnitteilla olevaa konesta ja kahvinkeitintä samaan aikaan.) buy it now -hinta 275$
Logiikkaan tarvitsee ostaa vielä lisäpalikka jonka kautta se osaa jutella servo-ohjaimien kanssa.
Hintaa en tiedä sanoa, mutta 100-150e ei varmaan kauaksi heitä.

Mielummin vaikka vähän isompi/kalliimpi näyttö ja pienempi logiikka.

Nämä siis mitä äkkiseltään bongasin ebaystä.
Omronin panelit on myös hyväksi havaittuja joskin ebayssa olleet käytetyt näytti olevan samoissa hinnoissa kun hyllynreunahinta omronilta suoraan tilattaessa.. (WTF!?)  o.O

Mutta siinä olisi siis täysin muokattava ja uudelleenkäytettävä ohjauspuoli kokonaisuudessaan ~600e
Loppu on kiinni tekijästä, mutta mikäli yhtään oon kuusalla siitä minkälaasta porukkaa tälläkin foorumilla pyörii niin en usko millään etteikö täälä osaamista olisi.
Ei tuo logiikkaohjelmointikaan oo mitää rakettitiedettä. Ihmiset vaa niitäki teköö, joskin tuollaisessa paikoituksessa pitää jo kyllä vähän tietää mitä kaikkea siinä tuloo vastaan...
mutta kaikki olemassa oleva tieto on olemassa.. ja näinollen saatavilla.
Mielenkiinnosta on kaikki kiinni. :)
Mutta se kaveri, tai kaverin kaveri on varmasti ikänsä noiren kanssa pelannu.

Tuolla saataisiin jo erittäin monipuolinen ja pätevä kones tehtyä.
Olisi vähän helpompaa jos tietäisi mitä kaikkea koneen halutaan tekevän, ja kuinka automaaginen siitä halutaan mutta tuolla logiikalla jo periaatteessa rakentaisi tankoautomaatin ohjauksen samaan pakettiin, ja lisä I/O-palikan oston jälkeen manipulaattorityylisen purkulaitteen.

jos taas halutaan vain manuaalisesti näpyttää esim kierteen nousu/syvyys/pituus joka kerralle, niin silloin voitaisiin selvitä jollain ohjelmoitavalla releellä esim. Siemensin LOGO!:lla.
Pieni näyttö ja tuo perusmallin logo maksaa uutena 350e:n paikkeilla. Tosin en oo aivan 100 -varma saako tuohon servo-ohjainpalikkaa.. voisi tarkistaa jossain välissä.

Logiikan ostoa/käyttöä harrastepuolella puoltaa omasta mielestäni eniten se kuinka joustava laite se on. Ääritapauksissa voitaisiin napata ohjausboxi koneesta 1 irti ja laittaa koneeseen 2 kiinni ja valita vain toinen ohjelma, tai aliohjelma käyttöön. Tällöin voisi yhdellä Logiikalla/ohjauksella käyttää kahta konetta.
Sulautetut järjestelmät on monesti niin räätälöityjä ettei ne oikein sovellu kuin siihen alkuperäiseen tarkoitukseen mihin ne on suunniteltu.
Teollisuuslogiikka siirtyy hyvin nopeasti paikasta toiseen ja uudelleenohjelmoinnin jälkeen on valmis käyttöönottoon.

PekkaNF: En nyt oikein saanut kiinni tuosta mitä tarkoitit tuolla että turvalogiikka työkaluineen ja laskentatapoineen vaatii monta osaajaa? Voisitko selventää?
Mitäs vuodenvaihteen jälkeen tapahtuu sellaista mikä veisi pienempien puljujen kyvyn valmistaa lain silmissä turvallisia laitteita?

Harrastajalle kun on kaikki laillista niin esim ohjelmointityökalut löytyy netistä, piuhat maksaa jonku kympin. Ja mitä tuohon ohjelmoinnin opetteluun tuloo, niin kuten aikaisemmin mainitsin se ei ole mitään rakettitiedettä.. ja kaikkeahan ei välttämättä kannata tehdä itse.
Mutta jos haluaa tehdä eikä tiedä, pitää kysyä hältä joka tietää. :)

Mutta että sellaista taas tähän kellonaikaan.
Onko tää projekti muuten vielä edennyt nettijauhantaa pitemmälle?

Terv. Peukalovammanen

Lainaus käyttäjältä: micic - 12.06.10 - klo:00:27

PekkaNF: En nyt oikein saanut kiinni tuosta mitä tarkoitit tuolla että turvalogiikka työkaluineen ja laskentatapoineen vaatii monta osaajaa? Voisitko selventää?
Mitäs vuodenvaihteen jälkeen tapahtuu sellaista mikä veisi pienempien puljujen kyvyn valmistaa lain silmissä turvallisia laitteita?

Terv. Peukalovammanen

Edellä oli paljon tekstiä eikä mulla ole tarvetta lähteä kumoamaan omista lähtökohdista sellaisia mieleipiteitä jotka lähtevät ihan eri lähtökohdista. Minusta logiikan käytölle kuitenkin kipupisteitä ovat: valmistajasidonnaisuus, kohtalaisen vaikeet työkalut lähtee pystymetsästä (toki verraten moni asia on triviaali jos on parikymmentä vuotta puljannut niiden kanssa) enkä minä tykkää kosketusnäytöistä.

Mulla tulee kipukynnys vastaan jos tarvitaan ohjelmoitavaa logiikkaa näyttöineen jne. satanen ja siihen turvarelettä yms. kaksi lisää. Ei onnistu.

Mitä tulee koneturvallisuuteen niin lyhyesti sanottuna kahden vuoden siirtyäaika on umpeutumassa vuoden 2012 alusta ja sitten joutuu todentamaan koko mahdollisesti vaarallisen tilanteen aiheuttavan rakenteen käyttäytymisen. Ei se nyt kyykkyn laita, mutta jonkinlainen ponnistus.

Ei siis pelkästään ohjausjärjestelmän perusteella kuten vanhan EN 954-1 mukaisesti kuten on kategorioista tässäkin threadissa jauhettu. Ohjausjärjestelmän näkökulmasta saa jonkinlaisen kuvan vaikka tästä linkistä (koskee lähinnä Sistemä-työkalun käyttöä):
http://www.metsta.fi/ipubs/docs/machinery/articles/2010_nro_004.pdf

Parempi:
http://www.vtt.fi/inf/pdf/tiedotteet/2009/T2485.pdf

PekkaNF

* Lisätty VTT-linkki

Terve

Tämä syöttövaihdekeskustelu lähti vähän väärille urille eli keskityttiin liikaa vain turvallisuusaspekteihin.

Onko vielä kiinnostusta jatkaa tätä?

Minua kiinnostaa edelleen ja mulle riiittää vaikka aluksi vaikka toimiva look-and-feel tai proof-of-concept laite jolla testaillaan toiminta sekä käyttäliittymä. Jos sitten on aihetta jatkaa, niin "tuotteistetaan" valmiiksi julkaistavaksi ohjeeksi?

Työn perkule haittaa, mutta eiköhän tästä välissä löydy aikaa.

Löytykö keneltäkään pikkusorvia elinluovuttajaksi tähän?

Mulla on yksi pikkusorvi vähällä käytöllä, mutta sen poikkikelkka pitää rakentaa uusiksi näinkin vaativaan projektiin. Pituussyöttö siinä on pelkästään trapetsiruuvilla ja toiseen päähän siihen saa helposti kiinni askelmoottorin. Tällä vois tietysti testailla. Siihen pitäis pultata kiinni ainakin seuraavaa:
* Askelmoottorit (onnistuu)
* Rajakytkimet (onnistuu)
* PSU + Relekaappi (karan käynnistys/pysäytys)

Mulle toi ohjain/HMI jne. härpäke on sitten vieraampi. Olisko kätevää tehdä se protoon omaan koteloonsa ja sopiva joku käytettävä liitin välille? Käytetäänkö enää D-25 tms. liittimiä vai sovinolla joku sikakallis militaaribajonetti?

Miten jatketaan vai jatketaanko?

Onko ketään mukana?

Kiitos,
PekkaNF

Olen edelleen mukana projektissa ja taisin lupautua tekemään koodausta käyttöliittymän osalta.
Pitäisiköhän keskittyä ensi tekemään proto ja sitten sen perusteella vasta varsinainen 'tuote'.
Onko muut mukana?

Mukana ollaan. Nythän on se "syksymmällä" jolloin asiaan piti palata. Olen edelleen valmis vääntämään tuon ohjainosuuden koodin aiemmin sovituissa puitteissa. Meillä oli alussa suunnittelija myös elektroniikalle. En tiedä onko enää?
Proto toki ensin. Pieni haastehan tässä on kaikkien tuotosten yhdessä labraaminen ja testaus. Parasta tietysti olisi jos sen voisi tehdä yhdellä koneella, mutta saattaa olla käytännössä hankala järjestää.

Mites tässä kävi ? Hoisiko mpr tuon hommaan kotiin Deltan logiikalla ?

Jussi

Joo noilla logiikoilla saa todella kätevästi tehtyä monenlaisia juttuja, hinnaltaankin ne alkavat olla jo harrastelu budjettiin sopivia. Parasta niissä on luotettava toiminta vuosikausia, Deltasta ei itsellä ole pitkää kokemusta mutta en epäile etteikö sekin kestä siinä kuin muutkin.

Tuossa omassa projektissa sähköinen syöttövaihde toimii todella hienosti. Siinä on nyt 8 "syöttövaihdetta" mutta vaihtamalla toisenaisen kytkimen vaihteita saa vaikka miten paljon, tietokoneella "välitykset" on myös muokattavissa.

Olisikohan mahdollista saada tuosta sydeemistäsi enemmän inffoa, sillä puuhapajakin olisi kiinnostunut moisesta.

Lainaus käyttäjältä: olli henttonen - 25.03.13 - klo:21:18
Olisikohan mahdollista saada tuosta sydeemistäsi enemmän inffoa, sillä puuhapajakin olisi kiinnostunut moisesta.

Muutamalla sanalla periaate:
Sorvin karalta nopeustieto pulsseina logiikalle, valintakytkimestä haluttu kerroin (logiikan muistissa) logiikka laskee näiden tulon pulsseina ja se pulsssimäärä syötetään askelmoottoriohjaimen pulse-tuloon ja askelmoottori pyörittää pitkittäiskelkan trapetsiruuvia.
Kun karannopeus muuttuu, muuttuu kertolaskun tulo ja kun kerrointa eli syötönvalinta kytkintä muutetaan muuttuu myös tulo.
Tälläinen toiminta kaikessa yksinkertaisuudessaan.

Tein tänään muutaman empiirisen kokeen Deltan kamoilla liittyen tähän syöttövaihteeseen.
Kokoonpanona oli Delta SV28-II -logiikka, Deltan 10" HMI-näyttö, 24VDC 1024ppr enkoderi
ja 24VDC 100ppr MPG-pyörä.

Meni muutama tunti näpertäessä, mutta toimii  8) ! Tässä tulokset:

- oikea takaisinkytkentä, seuraa orjallisesti karaa riippumatta nopeudesta tai suunnanmuutoksesta
- nousuvirhe on nolla riippumatta kooderista, ruuvista, servosta/stepperistä tai kuun asennosta
- mikä tahansa kuviteltava nousu on toteuttavissa, vaikka muuttuvanousuinen kierre tarvittaessa
(taitaa olla aika vähän käyttökohteita ;) )
- karan astekulmanäyttö
- käsipyörällä voi asettaa myös halutun nousun (tarvittaessa käsipyörillä voi käyttää kaikki toimintoja)
- ei rajoituksia Z- (tai X-) ruuvinnousujen suhteen tai enkoderitarkuudella / askelmoottorin askeleilla
- ei rajoituksia karan enkooderin tarkkuudelle (astenäyttö kuitenkin vain binääriluvuilla jaolliselle kooderille)
- lukunopeus 200kHz, noin 3000rpm 1024ppr x4 kertojalla (4096 pulssia per kierros)
- käsipyörät 10kHz (X & Z)
- pulssit ulos 200kHz (X & Z)


Pääsiäspyhinä vien tätä ideaa eteenpäin tässä mitä luvassa:

- kartionsorvaus asteina ja suhdelukuna (esim. 1:10)
- kartiokierteensorvaus
- nousu- ja kierrekirjasto
- automaattinen 55 / 60 / xx astetta siirtymä kierteen syvyyden mukaan
- analogiohjaus taajuusmuuttajille (X & Z) ja takaisinkytkentä
- samaan purkkiin mittalaitteet ja työkalukirjasto
- vakiolastuamisnopeus
- toisen karan tuki (kellään tarvetta..?)


Laitan kuvia ja videoita myöhemmin, kunhan saan parsittua keksinnön esittelykelpoiseen
kuntoon (nyt se on iso kasa johtoja...)

Lopullinen version teen hiukan edullisemmin kamoin, todennäköisesti kahtena eri versiona,
kaksi akselisena täysvärisellä kosketusnäytöllä ja toinen versio yksi akselisena kaksi värisellä
pikku näytöllä.

Jos joku haluaa koekaniiksi, niin laittaa poistia. Allekirjoittaneella kun ei ole nyt sopivaa sorviaihiota...

Millaisessa kustannusarviossa liikutaan noiden edullisimpien kikkareiden kanssa ?
Jos ajatellaan esimerkiksi tuollaista kiinalaista 250x700 sorvia ja sen muutoksen hintaa, pelkkänä yhden akselin ja karan yhteensovituksena ?

Jussi

Ja minkäkokoisen sorvin tarvitset aihioksi? Minulla on aika joutavana pikkusorvi (googlaa 7x12 tai 7x14) mutta toisaalta se laadullisesti on kovin kehno tähän.
Vielä pienempi emcon cnc-5 löytyy myös.
Varsinainen sorvi jota normaalisti käytän on Bernardo, mitat 250x500. Tätä kokoluokkaa olevia sorveja on varmaan useimmalla.
Jos manuaalikäyttö ei katoa ja ehkäpä jopa paranee niin tämä minun kone on ehdolla koekaniiniksi.

Hienoa Jonne  :)

Eikös deltalla ole logiikka joka ymmärtää myös G-koodia, muistan nähneeni deltan sivuilla sellaisen videon.
Tällaisen ympärille kun tuon rakentaisi niin voisi ehkä cam-ohjelmia syöttää sorville.

Tuosta koekaniini sorvista: Parhaiten soveltuisi sellainen sorvi jossa ei olisi omaa syöttövaihteistoa (ei tarvisi purkaa) ja aina parempi jos z- liike olisi trapetsilla.

Puuhapajakin olisi kiinnostunut moisista wärkeistä jos vain saisi budjetille sopivaksi.... meiltäkin löytys pari sorvia jota voisi ajatella koekaniiniksi( 150 ja 50 kg luokkaa), mutta taurin taitaisi olla paras siihen hommaan, hän voi sitten käydä puuhapajalla sorvailemassa.

Kiitoksia kaikille kiinnostuneille!

Mietin tätä hommaa hiukan ja teen kaksi versiota, sillä jos tehdään kaikilla syöttövaihteisto
kaikilla herkuilla, tulee hintaa hiukan erilailla... Logiikkana on käytettävä SV28:a, muissa
ei ole tarvittavaa dynaamista PWM-käskyä, jolla saa tuon suljetun loopin kooderiseurannan
toimimaan 100% varmuudella. Jos keksin jonkun ratkaisun, ilmoitan siitä kyllä.


1. Halpa versio

- Logiikka DVP-SV28-III
- 200kHz tulo kooderille
- 10kHz tulot käsipyorille
- 200kHz lähdöt steppereille / askelmoottoreille
- ei näyttöä, kiertokytkimet matriisi-IO:lla (noilla kytkimillä valitaan syötöt: milliset/tuumaiset nousut)

* optiona X-akselituki
* optiona 3" kosketusnäyttö


Tämä mokkula voi toimi myös ns. hölmönä vaihteistona, eli siis ihan pelkkänä vaihteistona.
Teen tuohon vielä "catch-up":n, eli hakee edellisen kierteen vauhdissa kohdalleen
omatoimisesti.

Harrastehintaa kyseiselle logiikalle ohjelmoituna tulee pari sataa verollisena ensimmäisille koekaniineille.
Loput romppeet pitää erikeen hankkia, Alibabasta sen kun tilaamaan ;) ...toki voin jostain järjestää isomman
mällin kerralla, niin saadaan nuokin sopivammin.

Kytkimien merkitys ja järjestys olisi seuraava:

(http://i215.photobucket.com/albums/cc21/jonne_photo/Sieppaa.png)



...toisin sanoen kytkimien asennolla saa pikana tarvittavat nousut/syötöt, mutta myös on mahdollista
käyttää täysin vapaata syöttöä.


***********

2. Kallis versio

- Logiikka DVP-SV28-III
- 200kHz tulo kooderille
- 10kHz tulot käsipyörille
- 200kHz lähdöt steppereille/servoille
- vakiolastuamisnopeus (0...10V taajuusmuuttajan)
- 7" tai 10" kosketusnäyttö (DOP-B07Sxxx tai DOP B10Sxxx)
- X-akselituki kartiosorvauksella ja kartiokierteillä (asteet, suhdeluku, radiaanit)
- mittalaitteet samassa, työkalukirjasto ja muut himmelit mitä nyt sattuu keksimään ;)

* optiona suljetun loopin +/-10V nopeuskomento servoille

Tämän hinta menee kyllä noilla osilla 500...1000 euron väliin, ehkä ylikin...

Tässä jo osittain toimivasta muutama ruudunkaappaus:

(http://i215.photobucket.com/albums/cc21/jonne_photo/Sieppaa2.png)

(http://i215.photobucket.com/albums/cc21/jonne_photo/Sieppaa3.png)



Mutta muutama pointti molemmista systeemeistä... Karankooderin on oltava binäärijaollinen, siis toisin sanoen
256, 512, 1024.... -pulssinen. Ylivuotavan laskurin matematiikan hierominen logiikaan
ei mielestäni ole kovinkaan järkevää, kun kooderit ovat nykyään sen verran halpoja.
Lisäksi kooderin on oltava 24VDC (HTL)...tai sitten 5V kooderin tulot on optoilla nostettava
24 volttiin. Sama koskee käsipyörää. Tuollaisen optokortin joku voisi tehdä, taitaa noita
muutenkin olla tarjolla ja eikä tuollaisen tekeminen iso homma ole, käytännössä opto
ja yksi vastus per kanava.

Tuo ensimmäinen vaikuttaa varsin kohtuulliselta... Tuo jälkimmäinen onkin jo täysverinen cnc :D

Minullakin olisi tuollainen 10x30 sorvi, ilman virallista syöttövaihteistoa.
Syötöt on mutta hammaspyöriä vaihtamalla.

Mitäs tuo catch-up tarkoittaa ?

Jussi

Projekti on taas hiukan edennyt. Nyt on molempien akselien syötöt kunnossa, käsipyörät, karan astekulmanäyttö ja
kierroslukumittari. Enkoderin binäärijaollisuudellakaan ei ole enää merkitystä.

Seuraavaksi pitää leipoa kasaan kartiosorvaus, ei pitäisi olla ongelma vaikka laskisi floatteina, sillä tuo
SV28-logiikka on hämmentävän nopea ohjelmansuorituksessa; reilu 1200 askelmaa ohjelmaa, ja syklin pituus 1ms! Tarkoittaa
toisin sanoen sitä, että akselisynkkaa korjataan 1000 kertaa sekunnissa (ei kuulosta paljolta CPU-miehille, mutta kyseessä
on TIKAPUULOGIIKKA ;) ...ja ohjelmaa ei ole optimoitu vielä yhtään, kaikki luvutkin lasketaan vielä 32-bittisinä, joten luulisin
saavani tuon syklin alle 1 millisekunnin.

Teoriassa voisin ympyräinterpolaationkin ympätä tuohon keksintöön, mutta katsotaan nyt... Hyödyllisempi voisi olla
puuttuvahampaisen kooderin tuki (tekniikka tuttu kampiakselin asennontunnistimista).

LainaaTuo jälkimmäinen onkin jo täysverinen cnc :D

Itseasiassa ei ole CNC, se on vain mittalaitenäyttö ja sähköinen syöttövaihteisto. Logiikalla voi toki tehdä sekvenssejä,
löytyy sieltä "drum sequencer"-käskykin, mutta kyllä se silti "oikeasta" CNC:stä jäisi kauas ;) ...toki jonkinlaisen
muodonseurannan voisi rakennella, esim. nokkien ja kampien sorvaamiseen. Tosin tuo vaatii jo aika hyvää
suorituskykyä X-akselin moottorilta...

LainaaMitäs tuo catch-up tarkoittaa ?

Käytännössä sitä, ettei koskaan tarvitse miettiä mistä kohtaa aloittaa seuraavan lastun kierrettä sorvatessa.
Syötön kun on irroittanut ja ajaa pikaliikkeellä kierteen alkuun, vaihteisto hakee kierteennousun omatoimisesti
ja kiihdyttää mukaan synkkaan karan kanssa entisen uran päälle.

LainaaEikös deltalla ole logiikka joka ymmärtää myös G-koodia, muistan nähneeni deltan sivuilla sellaisen videon.
Tällaisen ympärille kun tuon rakentaisi niin voisi ehkä cam-ohjelmia syöttää sorville.

Se G-koodilogiikka on aika tarkkaan sidottu ajamaan vain G-koodia ja siinä ei ole samoja käskyjä kuin näissä
muissa. Tiettävästi PM-sarjan logiikka ei ole tuo mm/r-syöttöä, joka osaltaan rajoittaa sorvin ohjaimena käyttöä,
harmi sinällään...


Palailen kun on taas jotain kerrottavaa!

Lisää edistystä!

Nyt syöttövaihde pystyy kartionsorvaukseen ja aika fiineillä ominaisuuksilla.
Syötön voi haluamalla suhdeluvulla siirtää Z --> X tai X--> Z. Esim. syöttö
2.5mm/r ja kartion suhdeluku 1/5, tarkoittaa että Z syöttää 2.5mm/r ja X syöttää 0.5mm/r.

Mutta samaan aikaan voi käsipyörillä korjata liikettä syötön aikana. Jos esim. syöttö on
Z:lla päällä ja kartionsorvaus, voi Z:n käsipyörällä muuttaa Z:n asemaa
nähden nousuun ja X:n käsipyörällä halkaisijaa kesken syötön. Homma toimii yhden akselin
syötöllä ( vaikka vanhaa kierrettä hakiessa ) aivan samoin, kuten myös X--> Z
kartiosyötöllä ( = Z seuraa X:ää ).

Kuten aiemmin mainitsin, voi kartiota sorvata suhdeluvulla ( esim. 1 / 5 ), mutta
myös asteina. Tarkkuus astekulmassa on 0.0001mm / m luokkaa, johtuen liukulukulaskuista.
mutta varmasti riittävä ;)

Ilmoittelen taas projektin etenemisestä...

Mistä ja millä mitataan z ja x paikkatieto, voiko esim. mittasauvoista saada tiedon logiikalle.

Lainaus käyttäjältä: mpr - 31.03.13 - klo:08:16
Mistä ja millä mitataan z ja x paikkatieto, voiko esim. mittasauvoista saada tiedon logiikalle.

Käytännössä logiikka kyttää ulosmenneiden pulssien rekisteriä
ja vertaa sitä haluttuun kohteeseen. Näiden erotus kerrottuna vahvistuksella on suoraan
pulssitustaajuus. Pulssirekisterin voi korvata mittasauvatiedolla, ei ongelmaa.

SV28:ssa pulssirekisterit ovat D1336 ja D1338, SA/SS/SC ne muistaakseni ovat D1020 ja D1022

Tässä pari ideaa karankooderiin. Logiikka kun lukee 24V-signaalia, voi kooderin
toteuttaa induktiivisen anturein. Samalla jää hammashihnan tarve pois.

(http://i215.photobucket.com/albums/cc21/jonne_photo/Kooderi.png)

Antureiden pitää olla toisiinsa nähden noin 90-asteen vaihe-erolla nähden hampaisiin.
Hampaiden lukumäärä saisi olla noin 16 tai 32, enempää ei tarvitse sillä logiikka pystyy
nostamaan teoreettista kooderitarkkuutta, syöttöliike pysyy sulavana vaikka pyörimisnopeus
olisi hidas.

Jos tuota kooderia haluaa vielä yksinkertaistaa, voi hammaspyörän sijaan käyttää reikälevyä.

Lainaus käyttäjältä: Jonne - 01.04.13 - klo:14:58

Jos tuota kooderia haluaa vielä yksinkertaistaa, voi hammaspyörän sijaan käyttää reikälevyä.

Hyvältä näyttää varmasti tulee tarpeeksi pulsseja ja vaihe-erosta logiikka tietää pyörimissuunnan.
Mutta jos kierteytystä ajattelee mistä logiikka tietää pakan asennon ja kierre uran, yksi pidempi pulssi vai kuinka?

Tuossa omassa yksinkertaisuus on viety huippuunsa yksi ruuvinkanta josta pulssi "inkkarille" mitä logiikka lukee ja sekin toimii.

Lainaus käyttäjältä: mpr - 01.04.13 - klo:16:32
Hyvältä näyttää varmasti tulee tarpeeksi pulsseja ja vaihe-erosta logiikka tietää pyörimissuunnan.
Mutta jos kierteytystä ajattelee mistä logiikka tietää pakan asennon ja kierre uran, yksi pidempi pulssi vai kuinka?

Tuossa omassa yksinkertaisuus on viety huippuunsa yksi ruuvinkanta josta pulssi "inkkarille" mitä logiikka lukee ja sekin toimii.

Helpoin tapa on käyttää binäärijaollista kooderia, silloin täysi kierros on esim. yksi tavu. Tällöin nollapiste voi olla mikä tahansa
arvo tuossa tavussa, sillä laskurin vuotaessaan yli, se nollautuu. Laskurin voi siivota aina ANDilla (8-bittinen = laskuri AND 255),
huomion arvoista on että ensin kopioi laskurin rekisteriin ja sitten siistii sen rekisterissä, koska laskuri on saattanut mennä yli
juuri siistimisen aikana. Toki mielivaltaista kooderiakin voi käyttää, mutta tällöin on on laskettava erotusta edellisen ja nykyisen
laskuriarvon välillä ja lisättävä se virtuaalikooderiin (rekisteriin).

Asia ei tietenkään käytännössä ole ihan noin yksinkertainen, sillä logiikan kiertoaika ei riitä esim. 1000 pulssisen kooderin
jokaisen arvon muutokseen, eli tässä tapauksessa pitää laskea erotus edellisen ja nykyisen logiikan kierron välillä, huomioida
lagi ja  korjata se kierretahdistuksen kanssa (...joka on sitten aivan oma lukunsa, mutta yksinkertaisuudessaan se tapahtuu
etsimällä lähin oikea kierre halutulle nousulle ja verrattava sitä nykyiseen asentoon, huomioitava karan lagi ja asento, laskettava
suhde-ero näiden välillä ja lisättävä se Z/X:n kohderekisteriin...)

Tuon lagin laskeminen on tärkeää, sillä muuten kierrosnopeuden muuttaminen vaikuttaisi seuraavan kierteen aloituskohtaan.

Olen tuon "catch-up":in testannut jo paperilla, huomenna testaan sitä oikealla raudalla. Katsotaan mitä käy...

Juu ja ei ole yhtään huono tapa käyttää yksittäistä pulssijonoa! Siihenkin saa synkan tehtyä "aika" helposti puuttuvan hampaan
metodilla, idea on kytätä pulssijaksoja ja kun pulssijakso kaksinkertaistuu, on puuttuva hammas mennyt ohi. Loppu
pulssijonosta luodaan mitattuun nopeuteen perustuen (esim, hampaan välillä luodaan kymmenen pulssia nopeudella perustuen
edellisiin mittauksiin nopeudesta). Mutta tuossakin pitää ottaa huomioon muutama pointti, kuten miten menetellään, jos
puuttuva hammas onkin käynnistyshetkellä kohdallaan...

Teoriassa suunnankin voisi tulkita kahden epäsymmetrisesti asetellun puuttuvan hampaan välillä, mutta siinä on sitten
omat ongelmansa...

Miten tuossa halvemmassa vaihtoehdossa ilmoitetaan kierteen pituus jos sitä käytetään kierteen tekemiseen?

Lainaus käyttäjältä: Tauru - 05.04.13 - klo:20:06
Miten tuossa halvemmassa vaihtoehdossa ilmoitetaan kierteen pituus jos sitä käytetään kierteen tekemiseen?

Kiertokytkimet olivat alkuperäinen idea, mutta saattaa löytyä yksi halpa/hyvä ratkaisukin, TP04-"tekstipaneeli" (oikeasti se on
graafinen...) http://www.delta.com.tw/product/em/control/tp/control_tp_product.asp?pid=3&cid=3&itid=2 (http://www.delta.com.tw/product/em/control/tp/control_tp_product.asp?pid=3&cid=3&itid=2) ...toinen vaihtoehto on sitten 3" täysvärinen DOP-sarjan kosketusnäyttö, joka julkaistiin viikko sitten.

Itse pidän enemmän kytkimistä, nopeampi tapa käyttää (kun oppii) ja muistuttaa käytöltään "oikeaa" syöttövaihteistoa.
Kytkimiä voisi tuosta minun alkuperäisestä suunnitelmasta karsia aika paljon pois, pari kymmenasentoista kytkintä riittäisi, toisella mitä tehdään / mikä alue, toisella itse syöttöarvo. Noilla saisi jo 100 eri  syöttöä / toimintoa. Kukaan tuskin tarvitsee
1.051mm nousua...

Kartiokulman valinta tulee vähän ongelmaksi tuolla järjestelyllä, joten ideoita otetaan vastaan. Käsipyörää voisi
hyödyntää kulman asettamisessa. Esim. 7-segmenttinäyttö (logiikasta löytyy valmis käsky moisen ohjaamiseen IO:n
kautta) näyttäisi astekulman ja käsipyörällä sen voisi veivata mieleisekseen.

Kunhan ehdin nyt saada ohjelman perusmekaniikan pelaamaan (vielä pitää säädettävät rampit tehdä steppereitä varten), niin
sitten voi kehitellä käyttöliittymiä. Tuohon saa liitettyä RS232/RS485:n kautta kolmannen osapuolenkin kamoja, teen jonkin
asteisen dokumentaation aiheesta mitä pitää renkuttaa rekistereistä, että alkaa tapahtumaan ;)

Btw, saan tuon toimimaan todennäköisesti halvemmalla DVP-SA2 -logiikallakin, mutta max. kooderitaajuus on sitten 50kHz,
riittänee 256ppr kooderilla 3000rpm:ään.

Lainaus käyttäjältä: Tauru - 05.04.13 - klo:20:06
Miten tuossa halvemmassa vaihtoehdossa ilmoitetaan kierteen pituus jos sitä käytetään kierteen tekemiseen?

Tarvitseeko sitä välttämättä ilmoittaa, sehän menee cnc:ksi. Jos tuota pelkkää syöttövaihteistoa ajattelee niin eikö riitä että z-akseli ja kara on syncronissa toisiinsa. X-akselista ja kierteen pituudesta huolehtii huolehtii sorvari niin kuin manuaalikoneessakin.

Ei se nyt vielä aivan CNC:tä ole jos voi määritellä Z-akselin syötön pituuden.
Alkuperäinen keskustelu sähköisestä syöttövaihteesta lähti muistaakseni liikkeelle ELS-projektin innoittamana (http://www.autoartisans.com/ELS/ (http://www.autoartisans.com/ELS/)) ja ko. vermeessä voi syötön pituuden säätää.

Minun pitäisi omaan sorviin saada moottori Z-akselille että päästäisiin sitten Jonnen kanssa jatkamaan prototyyppiä. Ensin pitäisi tehdä päätös askelmoottorin ja servon välillä. Molemmissa ratkaisuissa lienee omat etunsa.

Lainaus käyttäjältä: Tauru - 06.04.13 - klo:13:49
Ei se nyt vielä aivan CNC:tä ole jos voi määritellä Z-akselin syötön pituuden.
Alkuperäinen keskustelu sähköisestä syöttövaihteesta lähti muistaakseni liikkeelle ELS-projektin innoittamana (http://www.autoartisans.com/ELS/ (http://www.autoartisans.com/ELS/)) ja ko. vermeessä voi syötön pituuden säätää.

Minun pitäisi omaan sorviin saada moottori Z-akselille että päästäisiin sitten Jonnen kanssa jatkamaan prototyyppiä. Ensin pitäisi tehdä päätös askelmoottorin ja servon välillä. Molemmissa ratkaisuissa lienee omat etunsa.

Oho, luin viestisi hiukan huolimattomasti... Kierteen pituus ei mielestäni ole kovinkaan merkittävä asia, sillä kyseessä
on manuaalinen sorvi, säästyy melko monelta kolarilta jos joutuu tarkkailemaan mitä kone tekee...yksi kämmi asetuksissa
ja wha-tam! ;)

Toisaalta, päättymispisteen esittäminen ei sinällään ole vaikea juttu toteuttaa, sillä käyttäjä voisi siirtää Z-kelkan
päättymispisteeseen ja painaa namiskaa, joka pistää muistiin kyseisen kohdan. Tämän jälkeen Z-syöttö päättyy aina
kyseiseen pisteeseen (mahdollinen X:n irroitus pinnasta 2x kierteen nousu?). Toinen vaihtoehto on tehdä homma siten, että
ohjain muistaa pisteen, jossa syöttö viimeksi irroitettiin.

Voin tuollaisen toiminnon ympätä samaan systeemiin, no problem!

Jos toiminnon saa helposti toteutettua niin oikein hyvä.
Siinä olen samaa mieltä että valppaana kannattaa ja pitääkin olla sorvin äärellä. Mutta kolari on myös aidossa maluaalisorvissa aivan mahdollinen jos kierrettä tehdessä ahnehtii ja ajaa kierrettä hieman liian pitkälle.
Pidetään minun puolestani tämä projekti sähköisenä syöttövaihteistona niillä ominaisuuksilla jotka tuova lisäarvoa manuaalisorviin.

Lainaus käyttäjältä: Jonne - 06.04.13 - klo:16:20

Toisaalta, päättymispisteen esittäminen ei sinällään ole vaikea juttu toteuttaa, sillä käyttäjä voisi siirtää Z-kelkan
päättymispisteeseen ja painaa namiskaa, joka pistää muistiin kyseisen kohdan. Tämän jälkeen Z-syöttö päättyy aina
kyseiseen pisteeseen (mahdollinen X:n irroitus pinnasta 2x kierteen nousu?). Toinen vaihtoehto on tehdä homma siten, että
ohjain muistaa pisteen, jossa syöttö viimeksi irroitettiin.

Voin tuollaisen toiminnon ympätä samaan systeemiin, no problem!

Tuo on hyvä toiminto sekä normaalisorvauksessa olakkeen teossa ja kierteen teossakin, ei ole kiirettä veivata terää irti jos terä ei mene yli pääteuran tai siis syöttö katkeaa pääteuraan.

Lainaus käyttäjältä: Tauru - 06.04.13 - klo:17:23
Jos toiminnon saa helposti toteutettua niin oikein hyvä.
Siinä olen samaa mieltä että valppaana kannattaa ja pitääkin olla sorvin äärellä. Mutta kolari on myös aidossa maluaalisorvissa aivan mahdollinen jos kierrettä tehdessä ahnehtii ja ajaa kierrettä hieman liian pitkälle.
Pidetään minun puolestani tämä projekti sähköisenä syöttövaihteistona niillä ominaisuuksilla jotka tuova lisäarvoa manuaalisorviin.

Lisään tuon toiminnon molemmille akseille. Pitää miettiä miten niitä sitten käytetään... Alan vähän kallistumaan
3" HMI-paneelin puoleen käyttöliittymänä, sille saisi rajattoman määrän nappuloita ja toimintoja kylvettyä useammalla
sivulle. Toinen hyvä puoli on, että Deltan DOP-sarjan paneeilla voi kirjoittaa makro-ohjelmia. Tällöin logiikkalta
jäisi "turhat" ei-reaaliaikaiset laskutoimitukset pois, paneeli voisi hoitaa ne (esim. astekulman laskemisen,
koneparametrien suhdelukujen laskemisen, jne).

LainaaTuo on hyvä toiminto sekä normaalisorvauksessa olakkeen teossa ja kierteen teossakin, ei ole kiirettä veivata terää irti jos terä ei mene yli pääteuran tai siis syöttö katkeaa pääteuraan.

Hyvä pointti. Ohjelmallisille stoppareille on varmastikin tarvetta...

Saa laittaa ehdotuksia miten tehtäisiin. Mielestäni osoittaminen kelkkaa siirtämällä olisi
toimivin ratkaisu? Ainakaan ei tulisi perinteisiä tulkintakämmejä koordinaatistosta ;)

Pitää hiukan tulla hämmentämään.
Oletko jo kaaret ohjelmoinut? Kai tuollaisella syntyy näppärästi päiden ja sisäkulmien pyöristykset?

-Jussi-

Taas mennään kohti cnc:tä  :D, varmasti toteutettavissa mutta vaatii moottorin myös x-akselille...
Sen olen oppinut tässä vuosien varrella että jos projekteille ei laita "rajoja" ne paisuvat ja eivät tule ikinä valmiiksi.
Itsellä paja täynnä aloitettuja keskeneräisiä juttuja, pakko tehdä jotain valmiiksi astikin muuten ei sovi sekaan.

Ja jos tuolle cnc-linjalle haluaa lähteä, kannattaa harkita machia tai jotain muuta valmista ohjausta joka ymmärtää myös G-koodia.

Juu. Kunhan piruuttani kyselin.
Ihan erilainen konehan tuo olisi. Paikkatieto Z-akselilta ja moottori X-akselilla.
Onnistuisi ne kartiot tuollaisellakin järjestelyllä.  ;)

-Jussi-

Miksi se tarvitsisi moottorin toisella akselille? Jos on anturitiedot kerran molemilla akseleilla ei liene mitään väliä millä toinen akselipyörii? Kaaressa  X toimisi määrävänä ja liikuttaisi Z:taa sen mukaan. Ja jos olisi joku vanhempi vehje jossa on ollut kierteen sorvausta varten johtoruuvvi ja sorvaus syötöt hammastangolla saisi sähköisen syöttövaihteen johtoruuvville ja koneellisen syötön X:älle. Näin saisi halvalla sen kartion sorvauksen yhdellä moottorilla myös....

Lapasestahan tuokin lähtisi. Sorvattava profiili pitäisi saada tuotua taulukkona sisään, jolloin saisi kopiosorvin ja yhtenäiset kahvat takkasarjaan näppärästi.  ;D

-Jussi-

Palatakseni vielä tähän projektiin... Miten tuo askelmoottorin kiihtyvyys on hoidettu logiikan ulostulossa ? Jos askemoottori laitetaan ilman ramppia täyteen nopeuteen, niin voi olla että se stallaa ja ei kerkee mukaan pulssitukseen...

Jussi

Tuossa deltan pikkulogiikassa on ramppikäsky tai paremminkin rappuset, syötetään kiihdytysaika ja logiikka itse jakaa sen 10 portaaseen ja kiihdyttää portaittain. Toimii ainakin tuossa omassa koneessa, vaikka siinä ei syötettyjä pulsseja lasketakaan muttei moottori ainakaan sakkaa.
Niin ja kun valitsee "vaihteen" myös kiihdytysaika muuttuu samalla kertoimella.

Tämä aihe on ollut paitsiossa tovin mutta ennakkovaroituksena että muutaman viikon sisällä esitellään Jonnen kanssa mitä ollaan saatu aikaan. Tulee olemaan aivan über-hyvä.
Ensimmäiset savut ja koeajot on jo otettu.
Palaamme asiaan, pysykää kuulolla.

Ihme, kun kukaan ei ole hihkunut innostuneisuuttaan. Minä ihan joudun pidättelemään, etten paljasta lapsellista innokkuuttani ja rupea utelemaan pieniä naurettavan tuntuisia detaljeja. Isommistahan nyt on kyse. ODOTELLAAN!!!

Saa kysellä, mutta kannattaa odotella ensin että saadaan dokumentaatiota esille.

Ai sun kanssa se Jonne on sitä ollut vääntämässä... Tiesin kyllä että se painii asian parissa mutten kysynyt kenen kanssa....

Niin ne asiat paljastuu toisinaan ihan kysymättäkin. Muistanko oikein että sinun kautta sai hankittua Rollcolta kuularuuveja? Vai myykö Rollco myös tavalliselle kuluttajalle? Onhan noita kuularuuveja varmasti monella toimittajalla ettei se siitä jää varmaankaan kiinni.
Kunhan saan homman toimimaan niin varmaan pitää vaihtaa trapetsit hieman liukkaamin toimiviin ja vähemmän välyksellisiin ruuveihin.

Taas homma etenee, tässä pari kuvaa missä ollaan menossa:

 ???  Onpahan ainakin massavirrasta poikkeava kone  ;D
Lievästi haiskahtaa hifistelyltä mutta kukin tavallaa...
MUTTA HIENO ON EI VOI MUUTA SANOA.

Automaatio lienee maksanut x2-3 aihioon verrattuna.

Ei voida puhua hifistelystä sinun Deckeliin verrattuna, toki joiltakin osin käytettävyys paranee. Esimerkiksi kierteiden nousun asettelu rattaita vaihtamalla alkoi nyppiä, jatkossa teen kierteitä ja kartioita vaikka en niitä edes joka projektissa tarvitsisikaan.
Tämä on edullisempi paketti kuin voisi arvata, hinnoista kuitenkin vastaa Jonne.

Eihän Deckel ole suhteessa läheskään yhtä "PIMPATTU"
Sen uskon kyllä että hinnat saa kohdilleen sopimalla. Mutta normi hinnoin aika oksettava sijoitus kuten olisi Deckelkin.
Tuossa sun projektissa on porauduttu juurikin ongelman varsinaiseen ytimeen. Noiden pikkusorvien suurin puute/ vika on juurikin käyttöergonomiassa ja eteenkin tuossa ainaisessa rattaiden vaihdossa...

Otsikoksi voisi vaihtaa vaikka slouganin... "JONNE PLEASE PIMP MY LATHE"

tosin en tiedä paljonko on tunteja tullut kummallekkin

No niin, nyt on taas hieman projekti edennyt. Johdotuksien siistiminen alkaa olla valmista, enää käsiohjaimen kiinnitys ja x-akselin servojen johtojen niputus.
Toki pitää vielä tehdä X-akselin hihnan suojus mutta sen puuttuminen ei estä mitenkään sorvaamista, pitää vain olla tarkkana että pitkät lastut eivät mene väärään väliin.

Minä aloitan 'dokumentoinnin' oman toteutuksen osalta. Jonne varmaan tarkentaa ohjauksen ja servojen osalta mitä on tehty ja mitä muita vaihtoehtoja on olemassa.
Aloitan ensin yhdellä kuvalla ja sitten pikkuhiljaa lisää kuvia, vaihteiston toiminnot kuvattuna, videoita yms. niin että kaikille tulee pakottava tarve tuunailla omat sorvinsa.

Kaiken kaikkiaan lopputulos on hyvä jo nyt ja kun softaan Jonne ehtii tehdä vielä pari pientä parannusta niin sitten tilanne on loistava.

Dokumentointi on välillä vaikeaa ja olen tovin pohtinut miten ja mitä tästä sähköinensyöttövaihde-projektista kannattaa kirjoittaa. Kun muuten ei tunnu syntyvän tekstiä niin keksin että lähden etenemään väärinpäin. Yleensä rakennusprojektia kuvataan alusta loppuun, tällä kertaa teenkin niin että näytän mitä lopputuloksella tehdyn kappaleen ja lähden purkamaan sitä kautta asiaan.

Puuhapajan tasohiomakoneesta puuttui hiomalaikan kiinnitysholkki. Holkissa on 1:10-kartioreikä ja laikan kiinnitysmutteriin päätin tehdä M32x1 kierteen. Sekä kierre ja varsinkin kartio ovat haasteellisia tehdä perinteisellä pienellä manuaalisorvilla. Kierteessä ei toki ole muuta kuin sopivan nousun vaatimien rattaiden vaihtaminen edestakaisin. Minä sitten lupasin holkin tehdä Ollille kunhan saan tuunattua sorviani riittävästi.

Sähköinen syöttövaihteisto tekee helpoksi kierteiden ja kartion sorvaukset.
Kartion suhteet naputellaan kosketusnäytön kautta logiikalle ja sitten vain automaattisyötöllä ajamaan lastua. 30mm syvä kartio onnistui ekalla kerralla sen verran hyvin että kun tökkäsin holkin akselin kartioon niin en meinannut saada sitä irti näppivoimin.

Normaalisorvauksessa syötön voi valita 0.001mm tarkkuudella (eihän kiinapaskasorvi oikeasti ihan tuohon tarkkuuteen pääse) ja syöttöä voi muuttaa aivan vapaasti kesken sorvauksen. Kierteen sorvaus menee samalla tavalla eli asetetaan sopiva nousu, laitetaan automaattisyöttö päälle ja kara pyörimään. Toistaiseksi pitää kelkka ajaa takaisin pyörittämällä karaa takaperin, Jonnella on mietinnässä tähän vielä parannuksia.
Tuon kierteen tekemiseen meni pari minuuttia kun aikaisemmin aikaa olisi kulunut rattaita vaihtamalla puoli tuntia + tovi manailua rattaiden vaihdon hankaluudesta. Karalla on enkooderi jonka perusteella servo pyörittää trapetsiruuveja syötössä joten karan nopeuden muutokset eivät vaikuta nousuun per kierros.

Lyhyesti todettuna sähköinen syöttövaihteisto parantaa pienen vaihteettoman manuaalisorvin käyttöominaisuuksia todella paljon.

Kosketusnäyttöpaneelin kautta määritellään syöttö ja kartio. Logiikan kannalta input voi tulla muualtakin kuin näytöltä, esimerkiksi kiertokytkimiltä mutta tästä Jonne voinee kertoa tarkemmin kiinnostuneille. Näytössä on positioiden lisäksi karan kulma- ja nopeusnäyttö.

Sorvaaminen tapahtuu MPG-käsipyörien avulla jotka siis ohjaavat servomoottoreiden kautta z- ja x-akseleita. Joystickillä saa automaattisyötön kaikkiin suuntiin ja lisäksi pikaliikkeen tikun päässä olevalla napilla. En löytänyt mistää sopivan kokoista lukkiutuvaa joystickiä niin piti se sitten tehdä itse, rahallinen säästä muutamia kymppejä mutta aikaahan tuohon paloi useita tunteja. Käsipyörien toimintanopeus voidaan säätää kosketusnäytöstä ja jatkossa tulee vielä erillinen kytkin ohjausboksiin. Kytkin on jo paikoillaan mutta kytkentä puuttuu ja softaankin se pitää rakentaa.

Tämä ei ole vielä kovin kummoinen dokumentointi joten kysykää tarkennuksia yms. niin minä vastaan ja toivottavasti tämä rohkaisee muitakin tuunaamaan omia sorvejaan. Jonne on aika pätevä kaveri tekemään näitä. Servot, logiikka, softa ja sähkökytkennät on Jonnen tekemää, minulle jäi mekaaniset asennukset ja laitteiston kehuminen. 

Mukava nähdä että projekti on maalissa.
Pistäppä kuvia kokonaisuudesta missä näkyy koko sorvi ja kosketusnäyttö ym. käyttö laitteet.
Videon pätkä tositoimista olis kanssa mielenkiintoinen nähdä.
Onko vakiolastuamis nopeus toiminto eli karan kierrokset nousee kun mennään keskiötä kohti?
Myös kustannus puoli kiinnostais.

Jep,
laitan lisää kuvia ja videotakin on luvassa jollain aikataululla.
Toistaiseksi vakiolastuamisnopeutta ei ole mutta en usko että se on kovinkaan monimutkaista lisätä softaan. Nythän ollaan softassa vasta versiossa 1.0 eli aivan varmasti lisää ominaisuuksia tulee.
Kustannuspuolesta taitaa olla parempi että Jonne ottaa tähän kantaa koska vaihtoehtoisia kokoonpanoja on aika paljon.

Mites tällä pelillä onnistuisi tällainen?

http://cnc-tekniikka.com/CNC-forum1/index.php?topic=6984.0 (http://cnc-tekniikka.com/CNC-forum1/index.php?topic=6984.0)

Tuo on todella hieno.

Tosin aika kaukana alkuperäisestä ELS:tä.

Olisi kiva tietää miten monta pulssia tulee karalta ja mikä on servosysteemin resoluutio johtoruuvilla.

Pekka

Pekka:
karalta tulee 1024 pulssia ja resoluutio on riittävä, tarkemmin en osaa sanoa. Kellotin liikkeitä ja pystyy alle 0.01mm tarkkuuteen.
Laitan tästä vaikka videota kunhan ehdin sen tekemään.

Kytkijä: kierteen nousu toki onnistuu, mutta ennen kuin lupaan mitään niin laita tarkempi piirustus.

Täällä on ollut hieman hiljaista mutta koetan elvyttää keskustelua. Tarkoituksena on tehdä pari videota joissa näkyy hieman paremmin vaihteiston ominaisuudet. Ensin pitää vain tehdä teline puhelimelle ja sitten vielä opetella videon editointia.

Moro!
Minulla Jonnelta saatu ohjelma tallessa Delta releelle ja näytölle.
Mutta en osaa kytkeä Mitsubisin servomoottoriin,2 kpl.

Sorviin.
Onko joku joka osaisi ja jaksaisi opastaa tätä todella tarpeellista projektia?

Perussähköt ja juotin on käsissä.

M.B

Jaha.
Olipa apuja, jotta kirjaudun ulos ja lopetan tilin.