AVR- PLC

[vajk fekete]

A prell-t nem lehet ugy kezelni, hogy a nyomogomb allapotvaltozas az kivalt egy IT-t. Az IT kezelo letarolja az uj allapotot valahol memoriaba, es felirja melle egy rendszerora szamlalorol hogy mikor tarolta le. Viszont ha a szamlalo alapjan meg nem telt el x ms az elozo letarolas ota, akkor inkabb nem csinal semmit. Igy az IT rutin kelloen rovid, a prell miatt meg fog hivodni 10-20szor, de csak elsore csinal valamit.

szerintem egy csomo cucc igy mukodik, mert nem lehet adott sebessegnel gyorsabban nyomogatni a gombokat, nem veszi eszre.

vajk

----- Original Message ----
From: Szlifka Tibor <eltib at monornet.hu>
To: Sztrikó János <elektro at tesla.hu>
Sent: Tuesday, 7 August, 2007 3:46:24 PM
Subject: Re: AVR- PLC


> Az omron.hu-n találhatsz magyar nyelvű leírásokat, pl. a CQM1 vagy a CJ
> sorozatnál. Nekem nagyon bejön az ő szintaktikájuk, nagyjából azt követem.

Köszi, megsasolom.

> Néha jól jön a fix ciklusidő, de ennél az egyszerűbb megoldásnál az a
> jó, ha a ciklusban nincsen időtag, a végrehajtások várakozás nélkül
> követik egymást. De ahogy gondolod.

Magyarán nálad végigmegy a teljes PLC ciklus, majd kezdődik előről. Én sem várakozási ciklust szerettem volna, hanem úgy gondolkodtam, hogy 10ms-ba mindenképp bele kell férnie a ciklusnak, és akkor megszakításból mindig el lehet újra indítani - pontosan 10ms-onként. Ezzel a számlálók pontos futása is adott. Persze ha nem sikerül belepréselni, ott kezdődik a varia. Ezek szerint te nem foglalkozol ezzel, lesz amekkora lesz, és ciklikusan fut, a számlálók meg valami időalapon ketyegnek.

> Egy feltételbe befűzött számláló is tiszta logikai elem: vagy elérte a
> beállított értéket (nullát/maximumot), vagy nem. Egyébként ezeket 
> leggyakrabban összehasonlítja az ember valamivel (CMP), így kerül be a
> feltételbe (kisebb, nagyobb, egyenlő).

Ez igaz.

>> Az sem fér el a fejemben, hogy pl. a bemeneti nyomógomb prellt hogy 
>> szedi ki, hiszen ez nem fér bele 10ms-ba.
> Ez már (PLC) programozás, de a bemenetek fizikai kialakításával is
> megoldhatod. Az értelmező írásakor ez nem kérdés, illetve nem feladat.

A fizikai megoldásnak szerintem mindenkép maradnia kell, egy nyomógomb képes tökölni 10ms-on túl a prellel. Értelmezni valóban nem kell, de végrehajtáskor figyelembe kell venni. Mondjuk egy RC tag megoldja..

> Az értelmező lefut -> temp i/o memória írása a fizikai kimenetekre -> ha
> van adat a bemenetei pufferban, akkor feldolgozás, ha van adat a
> kimenetei pufferban*, akkor kiküldés -> ciklus tovább.

Aham, én is így gondoltam, csak elvetettem, mert a kiküldés belekavarhat a 10ms-ba. De ha a számlálóknak külön fut megszak, és valóban folyamatosan megy a ciklus, akkor van idő kiküldeni, hogy 5ms vagy 15ms alatt végez a ciklus, az nem számottevő. Okos. Ráadásul neked ARM-el lesz idő mindenre:)

> Ha ezek működnek (de fogok örülni :-)), akkor persze írni kell egy jó 
> létraszerkesztőt, de ez már egy másik felvonás...

Akkor csak kell az:)

Köszi a segítséget, akkor nem ragaszkodom az eredeti elképzeléshez, jobb lesz folyamatos ciklus, a számlálók meg hadd menjenek a háttérben, a kommunikáció és fizikai kimenetek billentése is lehet a ciklus végén  - pufferek kiürítése alapon. Így már könnyebb a feladat, bár nekem még nagy falat, de legalább átláthatóbb, tisztul a dolog..


-- 
 tib

-----------------------------------------
          elektro[-flame|-etc]







      ___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/