Svenska ElektronikForumet

Hej

Jag är lite ny på ladder logic och förstår inte riktigt hur rising edge fungerar.

Säg att jag har en ingång på en PLC som blir TRUE när någon trycker på en knapp. Detta knapptryck vill jag ska starta en räkning av revCount tills revCountMax har blivit uppnåd och skickar en TRUE till revCountDone
Om pushButton inte hade haft en rising-edge till &-modulen så hade den blivit FALSE så fort knappen släppts. Vad blir skillnaden med rising-edge? Kommer ingången till &-modulen vara TRUE trots att knappen släppts? När återställs detta till FALSE?
Det jag vill är alltså att pushButton skall fortsätta vara TRUE, så att när revCount också blir TRUE (vid ett fullgånget varv) så skickar den en puls (TRUE) till räknarens CU-ingång.
(> = rising-edge) MVH Niclas

Jag är inte helt hundra, men en kvalificerad gissning.

I en PLC så sker ju inte saker i realtid. Det är ett program som snurrar i cykler, för varje cykel så läser loopen av ingångar, tillämpar logik och ställer om utgångar.

Det innebär att en ingång måste ligga på ett stabilt värde under minst en programcykel för att bli korrekt avläst.

Men är det en ingång som har stöd för rising edge så har den kanske en vippa, så om ingången blir hög under en kort stund så ligger den kvar hög under hela nästa programcykel.

Alternativt är det tvärtom, en sån ingång räknas bara som hög under den första programcykeln efter att den blivit hög, sen blir den "internt" nollställd (så sätter du ingången hög blir det i logiken ändå bara en kort puls).

Jag misstänker att mitt första alternativ är rätt, eftersom det andra går ju att lösa med egen logik i PLCn om den funktionen behövs, men det första skulle kräva externa komponenter för att lösa om inte PLCn har stöd för det.

Att ingången inte ändras under programcykeln hanteras av IO-kopieringen. En PLC jobbar (normalt) inte direkt mot IO utan mot minne. Det finns undantag men det är ovanligt.

"Rising Edge" ger en puls som varar exakt ett programvarv.

Det där är inte vad jag skulle kalla för Ladder utan snarare Funktions Blocks programmering men det gör ju det samma.
Är det en Mini-PLC du håller på med typ LOGO, Millenium, Alpha mm?

Rising edge betyder att vilkoret är sant under tiden signalen växlar från låg till hög, i ditt fall borde det bli en puls just när du trycker in knappen. Falling edge ger en puls när du släpper knappen.

Tips, titta lite på Set block.
Något i den här stilen:
Knappen sätter ett Set-block, set + RevCount ger signal till räknaren tills räknaren räknat klart. När den räknat klart återställer den set-blocket.

Ok, tack för svaren, då var det som jag ändå hade befarat.
Ladder-logic är det mer på en linje då? typ: ------[ ]----[/]----
Det är en BoschRexroth MLC/PLC som jag kikar på, bara av ren nyfikenhet om jag kan rätta till en "bugg" i ett befintligt system

Så jag får alltså lov att skapa en ny variabel, typ pushButtonWasPushed och göra följande:
=SET, [R]=RESET I mitt huvud så kommer följande ske när man trycker in knappen:
pushButtonWasPushed blir TRUE
Villkoret för &-blocket skickar TRUE när även revCount blir TRUE
Detta läggs till på räknare tills den nått revCountMax och skickar TRUE till revCountDone samt gör reset (blir FALSE) på pushButtonWasPushed.

Korrekt uppfattning av mig?
MVH Niclas

Jan Almqvist skrev:Att ingången inte ändras under programcykeln hanteras av IO-kopieringen.

Det jag menade var att om ingången är en puls som är kortare än en programcykel så detekteras den inte.

I min värld är Ladder så som du skrev men det finns ju programmeringsspråk med blandad Ladder och funktionsblock så...

Inte hållit på med just BoschRexroth Plc så kan tyvärr inte svara på hur man gör exakt men principen har du fått till rätt.

Kan ev gå att göra i denna stilen beroende på hur räknaren fungerar:
PushButton sätter ett Minne högt som först inverteras och sätter RST på räknaren låg,
Revcount sätter CU på räknaren högt och RevCountDone sätter RST på Minnet högt som
då återställer minnet så räknarens RST blir högt (pga inverterad signal) och stoppar räknaren.

Du får läsa in dig på funktionerna eller bara testa lite om du har möjlighet.

Nerre skrev:Jag är inte helt hundra, men en kvalificerad gissning.

I en PLC så sker ju inte saker i realtid. Det är ett program som snurrar i cykler, för varje cykel så läser loopen av ingångar, tillämpar logik och ställer om utgångar.

Det innebär att en ingång måste ligga på ett stabilt värde under minst en programcykel för att bli korrekt avläst.

Men är det en ingång som har stöd för rising edge så har den kanske en vippa, så om ingången blir hög under en kort stund så ligger den kvar hög under hela nästa programcykel.

Alternativt är det tvärtom, en sån ingång räknas bara som hög under den första programcykeln efter att den blivit hög, sen blir den "internt" nollställd (så sätter du ingången hög blir det i logiken ändå bara en kort puls).

Jag misstänker att mitt första alternativ är rätt, eftersom det andra går ju att lösa med egen logik i PLCn om den funktionen behövs, men det första skulle kräva externa komponenter för att lösa om inte PLCn har stöd för det.

Det första alternativet löser ju PLC't genom I/O-kopieringen när alla insignaler läses in som ett ögonblicksvärde och lagras i en minnesavbild av ingångarna (även annat lagras där). PLC't jobbar sedan mot minnesavbilden så om insignalen ändras påverkar det inte de beräkningar som sker under det cycliska programvarvet. Mera avancerade PLC kan ändra detta mha interupt på de ingångar som behöver snabbare exekvering. Annars jobbar i princip alla PLC med "cyclisk programvarv" och minnesavbild. Börjar med I/O kopiering av ingångarna, sedan exekveras programmet under programvarvet. Status på utgångarna kopieras ut till de fysiska utgångarna innan nästa "cycliska programvarv" börjar med inkopiering av ingångarna.

PLC't jobbar bara mot processavbilden så att insignaler ändras under bearbetningen tas ingen hänsyn till. Ett litet program ger ett snabbare "cycliskt programvarv" än ett stort.

I många av de första PLC'na fanns inte flankavkänning så där skrev man sina egna avkänningar av positiva och negativa flanker när man hade de behoven. Precis som du redan listat ut.

Som sagt var, hur läser PLCn av en ingång som är hög en tid som är kortare än en programcykel?

Det var det jag trodde edge-ingång handlade om, att den gav "hög" under en programcykel även om signalen hinner gå låg innan I/O-kopieringen.

Just eftersom det andra (att bara vara hög under den första programcykeln) kan lösas med logik i "programmet". Det är inget problem att göra en logik som ger en puls från en flank, men att göra en logik som känner av att en signal var hög en stund innan den lästes av är svårare....

I vissa PLC'er (tex Siemens Step7) så kan man läsa direkt från periferienheterna, genom att läsa från tex PIB 0 istället för IB 0 för första igångsbyten.
Då kan man läsa den på fler ställen under programvarvet för att försöka detektera ingången.
Flankavläsning är endast färdiga logikblock, liksom många andra standard PLC funktioner.

Annars ser det ut som såhär

Med risk för att ha pinsamt fel men som jag har fattat efter en del diskussioner med PLC-människor (för mycket länge sedan) så är det så här:

Ingångarna läses i början av cykeln.
Utgångarna skrivs i slutet av cykeln.
En "rising edge" är en signal som har samplats låg i en cykel och sedan samplas hög i nästa cykel.

Rätt eller fel

Visst, man detekterar ju helt enkelt den positiva flanken på ett logiskt uttryck. Att göra detta är ju inte unikt i PLC-sammanhang utan kan förekomma i allt som exekveras cykliskt.

lillahuset skrev:Med risk för att ha pinsamt fel men som jag har fattat efter en del diskussioner med PLC-människor (för mycket länge sedan) så är det så här:

Ingångarna läses i början av cykeln.
Utgångarna skrivs i slutet av cykeln.
En "rising edge" är en signal som har samplats låg i en cykel och sedan samplas hög i nästa cykel.

Rätt eller fel

Har ingen betydelse om skrivning av utgångar sker i slutet av cykeln eller i början.
Rent pedagogiskt känns det kanske bättre att beskriva det som att det sker i slutet av cykeln men i praktiken spelar det ingen roll.
Rising edge är som du skriver en tolkning av när signalen går från låg till hög. Men tolkningen är ju totalt värdelös om den inte ger upphov till något. Så i PLC sammanhang ger rising edge (och falling edge) upphov till en signal som skrivs hög under ett programvarv.

> I en PLC så sker ju inte saker i realtid...

En PLC används då man just *vill* att saker ska ske i realtid.
Det är samtidigt så att "realtid" är ett totalt värdelöst begrepp...

Nu så tror jag att signalen från en tryckknapp i alla fall är längre
än cykeltiden i en normal PLC, så det är kanske inte rellevant här.

Det som var grundfrågan här är väl hur man ska få räknaren att
fortsätta fast man har släppt knappen (?). Man får nog ha en vippa
som knappen "sätter" och en annan signal (t.ex. då räknaren har
"räknat klart") "clearar".

Sen får man hantera sådant som vad som ska hända om knappen
fortfarande är intryckt då räknaren har kommit i mål. Ska den börja
om eller ska det krävas att knappen släpps först?

> bara av ren nyfikenhet om jag kan rätta till en "bugg" i ett befintligt system

Beskriv "buggen". Vad är det för funktion eller egenskap som ska fixas?

Med diskret logik påverkas logiken direkt av en flank eller kort puls.

Men med en PLC så kommer pulser som är kortare än en programcykel inte att detekteras om den kommer mittemellan två I/O-kopieringar.

Att omvandla en flank (där signalen ligger kvar hög) till en puls kan man ju göra med logikelementen (framförallt så har väl i princip alla PLCer ett delay-element, vilket gör att man med en XOR-funktion och en delay kan göra en puls av en flank).