Jó példát hoztál mert még a Siemens S7 fejlesztő környezetének is meg vannak a maga hibái, szóval az is a fejlesztő gárda hiányossága, ettől azért még nagy duzzogva használjuk páran

Főleg, ha 2x2=5 jön ki végeredménynek!

Igazad van, mindenben vannak hibák, de ezeket nem szabad felemlíteni, véleményt formálni?
Azonkívül itt egy PIC perifériát gyakorlatilag kihagytak a szórásból. Egy PLC-ben ilyen blődli nincs. A hibák más jellegűek...

Szeretném leszögezni, hogy nekem semmi bajom nincs a folyamatleíró nyelvekkel, a FlowCode is tetszik! Sajnálom, hogy ilyen alapvető hibák vannak benne, nem értem miért fordulhat elő...

Nincs a világon olyan program ami minden felhasználónak minden igényét maximálisan kielégíti, mindegyiknek van olyan hibája ami ez egyik felhasználónak fel se tűnik a másik meg tud rá orvosságot a 3. meg csak dühöng miatta. Ez egy ilyen program a maga korlátaival amit folyamatosan fejlesztenek és előbb utóbb jó lesz majdnem mindenkinek! Az mplab se volt régebben semmire se jó mára kinőtte a hibák túlnyomó többségét de persze akad benne még mindig bőven, ugyanez mondható el szinte minden programról, pl windóz.. 8-as verziónál tart és még mindig van mit csinálni rajta, de a linuxok se kivételek ez alól.

Itt felépíthető a környezet tokkal vonóval, és közben nem csak a PIC működése érthető meg. Mert ez arra való a maga hibáival és hiányosságaival együtt.

Persze szabad véleményt formálni, mindenki tudja, hogy nem tökéletes a program, és vannak benne hibák, csak minek ezt két lapon keresztül taglalni ?

Próbálom megértetni a probléma lényegét.
Egy PLC után, amiben leprogramoztam valamit, szeretnék egy PIC-es áramkört fejleszteni, ami olcsóbb és többet tud, de kell egy fejlesztői környezet, amivel hasonlóan egyszerűen lehet programozni. A PLC környezetében nem volt szükség C-re, azt feltételeztem a hírekből, hogy a FlowCode is ilyen egyszerű nyelv. Tévedtem, csalódtam, meglátom tudják-e használni, akiknek készülne, ennyi...

Komolyan nem értem, miért ne lehetne kitárgyalni a fejlesztőkörnyezet hibáit, lehetőségeit, stb. Mi a bajod ezzel? Személyesen érint, ha kiderül valójában milyen a program? Végül és nem utolsó sorban, vedd észre, hogy a két oldalban te is benne vagy...

PLC és PIC programozás között van egy árnyalatnyi különbség, de PLC-t is csak egy határig lehet tudatlanul programozni. Erre a Flowcode is alkalmas egy határig

watt, tisztában vagyok a program hiányosságaival, és nem fűznek érzékeny szálak hozzá, nem sértődöm meg ha kritikával illeted, mert nekem sem tetszik benne sok minden.
De ez ilyen, méteres blogokat lehetne írni a lehetőségekről is, de sok értelme nincs, mert attól jelen pillanatban nem lesz jobb, csak a topic lényege veszik el.
A programozzunk C, a PIC kezdő, a PIC miértek hogyanok és sorolhatnám még az ősszes topikban lehetne hasonló mi miért nem tetszik, mi legyen helyette stb írni, denem itt fejlesszük a programokat.

Ezek szerint szerinted felesleges egy olyan számláló, ami két megszakítás között megméri az eltelt időt, valamint felesleges egy alapvető perifériát felvenni a modulok közé, viszont minden más sokkal bonyolultabb dologra szükség van a modulok között? Aki ilyet keres és nem érti miért hiányzik az nem kérdezheti meg a fórumban.
Na látod amit most csinálunk, az már tényleg nem ide tartozik, de nem érzem hogy én miattam van!!!

Ahogy elnézem a fejlesztés úgy zajlik, hogy van a fórumuk és a beérkező kéréseket oldják meg először úgy hogy amit a legtöbben szeretnének azt veszik előre. Az általad hiányolt ccp2-t nem kérték sokan valószínűleg ezért nincs még benne, a hibákat is ilyen módon javítják, mivel ők nem tesztelnek le minden picen minden funkciót, idő és kapacitás hiányában. Írsz nekik és lehet hogy a következő frissítéskor már az is benne lesz ami neked kell vagy megmondják hogy lehet megoldani.

Watt ne haragudj nem tudok tovább részt venni ebben a parttalan vitában.
Senki nem mondta, hogy minden tökéletes és a flowcode használók 100% elégedettek a program működésével, de itt nem tudunk ezen segíteni.
Itt tudnak segíteni

Én flowban pont egy ilyen számlálón agyalok.
Simson gyújtás vezérlése lenne. Fordulatszámot mér egy fogazott keréken, és figyelné az időt a bejövő jelek közt, ami RB0 megszakítás. Amit mindig az előtte lévőhöz kell hasonlítania, és ha nagyobb akkor elindít egy számlálót ami a fordulatszám alapján, megadott értéken tartja az előgyújtás szögét. Ha nem nagyobb akkor újra méri az időt.

Sajnos eddig sokra nem jutottam, de bele döglök is megoldom... Időm nincs rá az a nagyobb baj.

Mennyi igazság van abban amit mondasz...
Talán abból ered, hogy sokan megküzdöttek, hogy megtanulják a különböző nyelveket, írnak egy programot, aztán jön egy amatőr és 1-2 hét alatt megcsinálja ugyan azt flowban. Aztán jön a fikázás.. Minek tanuljak nyelvet.. stb.

Holott mint most kiderült, akár mennyire is küzdene, flowban nem tudná megoldani amit a program nyelvet ismerő megold C-ben. Ilyenkor meg jön a "de szar ez a program" féle megjegyzés a másik oldalról.

Sehol nincs építő jellegű gondolkozás.... Valljuk be, még a magyar mentalitás hatása alatt vagyunk... ha nekem nem jó, ne legyen a másiknak se jó.

Szerintem túl irigyek az emberek, és mindenki nagyra van a saját tudásával, holott mindig van okosabb, tapasztaltabb másik ember. Lefelé pedig mindenki vetít.
Tisztelet a kivételnek, hál istennek egyre többen vannak.

Bocs az off-ért.

Sziasztok ismét nekifutottam a szabályzoprojektnek, szerintetek ez igy már akár müködhet.
Ugyebár 0,8 és 2,2 ms között kellene mérnem az impulzutst.
Egy nem teljesen ide tartozo dolog de sokunknak segithetpic kapcsolások és programok

Sajnos nem vágom mi a lényeg, csinálsz egy frekit aztán a kitöltést meg a nyomó gombal állítod. Mi a cél ?
0,8ms jelet hogyan mérsz 1KHz timerben ?

Ha jol sejtem RC szervo idejet szeretned merni. Valami olyan megoldast kellene csinalni, hogy pl egy INT EXT csatornat felkonfiguralsz hogy pozitiv elre jojjon a megszakitas, majd mikor beut a megszakitas, nullazod a TMR1 idozitot, valamint beallitod, hogy a megszakitast lefuto elre kerje legkozelebb. A kovetkezo megszakitasnal kiolvasod a TMR1 erteket, es maris kapsz egy erteket, ami ugye a ket megszakitas kozott eltelt idovel aranyos. Ugye ismert a TMR1 CLK periodusideje, ismert a TMR1 erteke, ebbol szamithato az impulzus szelessege. Persze most ujra be kell allitani a felfuto elre valo megszakitast, es a kovetkezo elnel kezdodik elolrol az egesz. Masik megoldas, hogy egy bemenetet felkonfiguralsz hogy valtozasra IT jojjon, majd az IT beutesekor megnezed, hogy H vgy L ertek van a bemeneten. A H erteknel inditod a TMR1 szamlalasat, L erteknel olvasod ki az erteket. A tovabbiakban hasonlo az eljaras az elobbihez. Lenyeges, hogy el kell donteni, melyik labon lehet megszakitas, es ugy allitani a IOC regisztert, hogy csak ezen a labon legyen megszakitas.

Szerintem elég fordulatonként egyszer megmérni a fordulatszámot ebből kiszámolni a gyújtás időpontot. Ehhez csak az kell, hogy a gyújtási pont előtt időben kell megmérni a fordulat értékét, majd a holtidőkkel is számolva(a számításokkal töltött időt ki kell vonni) egy Timert feltölteni a kiszámolt idővel arányos értékkel és elindítani. A Timer megszakításában kell kiadni a gyújtás impulzust, leállítani a számlálót és kezdeni előről az egészet. Ha jól sejtem alsó holtponton elég elhelyezni a detektort(HALL?). Szerintem ezt le lehet programozni FlowCode-ban is, de az jó kérdés, hogy C-ben kell-e kontárkodni benne!

Na pont erre való a CCPx Capture módja. Minden bejövő impulzus megszakítást okoz és a hozzá rendelt Timer(1, vagy 3) értéke benne lesz a CCPxL és H regiszterekben. Két impulzus közötti idő arányos lesz a két méréskor a CCPxL és H korábbi és mostani értékeinek különbségével.

CCP interrupt

Nem a megoldás okoz gondot, hanem hogy nem lehet szimulálni és C-t kell használni. Írtam, hogy valóságban fut a kód, csak nem lehet szemléltetni. De azért köszi!

Jól sejted csak nekem igazábol azzal van a problémám hogy nem tudom megvalositani a müködést.

Ez is jól működhet. Ha jól értem azt nem kezeled le, ha a Timer2 túlcsordul két impulzus között, de ez részletkérdés...

De hol akadsz el? Fel kell konfigolni a mondjuk a CCP1-et, hogy a Timer1 legyen hozzá rendelve és be kell állítani, hogy milyen gyorsan számoljon, hogy jó legyen a felbontás, de ne csorduljon túl 2,2ms esetén se. Ezután a CCP1-et be kell állítani, hogy felfutó élre okozzon megszakítást. Ha ez megtörténik, el kell tárolni, a CCP1H&L-t. Át kell állítani a CCP1-et lefutó élre. Amikor ez megérkezik, ki kell vonni a mostani CCP1H&L ból az eltároltat és visszaállítani a megszakítás élét felfutóra. Az érték arányos lesz az impulzus szélességével. Ezzel már azt csinálsz amit akarsz. Érdemes megnézni a PIC adatlapját, minden benne van.

Számold meg a Timer2 megszakításban, hogy hányszor történt meg és amikor bejön az RB0, akkor ezzel is számolj.
Én nem szoktam a timereket leállítani, elindítani, mert kivonáskor az eredmény mindig jónak adódik. Viszont a timer megszakítás előtti és utáni(amikor a második impulzus jön) értékeket össze kell adni és ehhez hozzá még a megszakításokból összegyűlt értéket. Ennek az az előnye, hogy nagy felbontással lehet mérni elég nagy intervallumban.

Relativ értem mit irtál csak a kivitelezéssel vagyok megakadva. Felfutó él,lefutó él, necsorduljon tul, stb. Na ezek magasak nekem mint halando, ledet tudok villogtatni, feszültséget tudok mérni de ezzel az idő cuccokkal nem vagyok kibékülve (gondolom tanulmányi hiányosság) de köszönöm a segiteni akarást igérem potolom hiányosságomat hogy végre megértsem miröl beszéltek, mert sokszor csak olvasom de nem értem, és ez böven zavar, hogy tudom mit irtok csak nem tudom kivitelezni.
Üdv Kovács G

Első körben nézd meg a Timer1-et. Aztán a CCP1 Capture módját.

Jobban megnéztem a módszeredet, ez eléggé leterheli a PIC-et, mert a Timer2 megszakítása olyan gyors, hogy mással se foglalkozik a kód, mint belefut. Ha a PIC semmi mást nem kell, hogy csináljon, akkor működik, de ilyen nincsen a való életben. Amit írtam megoldást, az akkor működik, ha a Timer2 lassabban szakít meg. A kivonásos módszerrel kisebb PIC terhelés mellett lehet megoldani ugyanolyan felbontást.
A te megoldásoddal további probléma, hogy a Timer2 értéke nem azonnal kerül kiolvasásra, mert az RB0 megszakítása sem azonnal kerül lekezelésre(pl. akkor, ha éppen egy másik megszakítás kiszolgálása folyik). E miatt némi mérési pontatlanság is keletkezik, ami nem állandó hibát generál.
A CCPx Capture módja pont erre lett kitalálva, miután a Timer1 értéke hardveresen kerül be a CCP1H&L-be, amit később is ki lehet olvasni, nem befolyásolja a megszakítás lekezelésének időpontja.

Lényegében az alapok nálam is ezek, csak ott, 100ms-onként méri a fordulatszámot, (mint Pl a kocsim órája) így azt kijelzésre tudom használni, a felső holtponton mérem a széles jelet, és a 360-x fok idejét számolja szögelfordulásból a fordulatszám alapján.


vissza térve a periódus idő mérés benne a lényeg.
Két RB0-n bejövő jel közt méri az időt de nem megszakításban, hanem a főprogramban.
Amint lesz időm beviszem a gépre. Még papíron van meg. Munka közben eszembe jut valami akkor lerajzolom, és így bővülget.

Lényegében a TMR0 ban csak egy számláló van. T=T+1, Ugyan ez az RB0 megszakításban R=R+1
A főprogramban pedig végtelen ciklusban vizsgálja R állapotát. Segéd változóba teszi a T változóját és közben a TMR0 és az RB0 számlálóját nullázza.

A gyújtás csak annyival bővebb, hogy ahol nagyobb a szünet vagyis ki van törve egy fog, ott 3x hosszabb a bejövő jelek közti idő(szünet-fog-szünet helyett, szünet-szünet-szünet). Így ha másfélszeres timer idejénél többet kell várni két bejövő jel közt, akkor indítja a gyújtáspont számlálóját. És 360 fokból csak kivonja a beállított szöget pl 10 fok 2000 fordulatom akkor 350 fokra számolja a 2000 fordulaton mennyi idő alatt teszi meg.

Abban igazad, van, hogy itt 2-3ms os késés nem mérvadó, és kilép megszakításba, visszalép programba idő veszteség, a te megoldásod ha jól értem a CCP-s hozzászólást sokkal pontosabb. Igen, egy pontos mérésre jobb lenne amit te írsz...

Túlcsordulás kiszűrésére nálam az elv más, mert ha ULONG változót használok akkor jó sokáig számolhat, ha eléri a végértéket kinullázom és ha van fordulatszám akkor a minimális gyújtásszöggel számol, ha nincs(áll a motor) akkor nincs gyújtás.
Egyébként próbáltam az időket számolgatni és 20MHz-el 200 fordulat alatt csordul túl ezzel az átmérőjű fogaskerékkel, de az alap fordulat már sokkal több egy simsonon, és ott még bőven alap gyújtásszög van. Berúgáskor már alapszöggel számol.


De tényleg írd meg a fejlesztőknek, lehet sokan kihasználnák a CCP-t. (autó gyújtásnál már hasznos lenne akár egyedi vezérlő készítésére
injektoros kocsikhoz)

Sziasztok ismét egy kezdö kérdés: az ok hogy hogyan állitom be a PWM-et de azt hogy döntöm el hogy ez melyik lábon jelenjen meg?