Sähköinen syöttövaihteisto

[Kremmen]

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.

[Jonne]

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?

[Kremmen]

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.

[ram]

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 ;)

[Kremmen]

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. Ei tuossa kokeneelle suunnittelijalle mitään ihmeitä tule vastaan, mutta ehkä maksaa vaivan vilkaista.
Perästä kuuluu sanoi torventekijä...

[Jonne]

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 (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...

[Kremmen]

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.

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.

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. 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).

[Kremmen]

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://en.wikipedia.org/wiki/C_preprocessor
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/. Tämä kirjasto on jokaisen AVR-koodarin syytä tuntea kuin taskunsa.

[Tauru]

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.

[jussi]

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ä.

[Kremmen]

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.

[Kremmen]

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)));
   }
}

[Kremmen]

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.

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 :)

[jussi]

 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;
       }
     }
      
    }

[Kremmen]

pistämpä näkyviin oma viritykseni.

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