Varje objektklass representerar en bestämd funktion eller metod. En objekt klass han
uppträda på ett sätt i utvecklingsmiljön, t.ex. i form av en symbol med vissa attribut,
och på ett annat sätt i målmiljön. Generellt består en klass av data och kod.
Exekverbar kod existerar endast i målmiljön.
Data för klassen är uppdelad i huvud och kropp. Objekts-huvudet, som har samma utseende
i alla objektsklasser, finns beskriven i Designer's Guide.
Objektklassens attribut, som används för att beskriva enskilda instansers aktuella
tillstånd, finns i objektkroppen. Det är inte säkert att hela kroppen lagras i rtdb.
Beskrivningen av en objektklass inleds med klassens namn följt av en kort beskrivning
av funktionen. Därefter kommer klassens grafiska representation och objektkroppens
attribut.
Beskrivning av objektklasser med grafisk representation inleds med objekt klassens
symbol sådan den ter sig då samtliga in- och utgångar visas. In- och utgångar visas
endast om de är markerade "Used". Vill användaren i den enskilda instansens symbol
dölja icke använda in-/utgångar används Attribute Editor för att manipulera instansens
"Used"-markeringar för aktuella attribut. Ingångar som lämnas öppna resulterar i
varningar vid kompilering av PLC program, för övrigt är det ingen skillnad i funktion
jämfört med ingångar markerade som icke använda.
Objektklasser med grafisk representation har (med undantag för Grafcet-objekt m fl) det allmänna utseendet:
Objektklassens namn framgår av symbolens huvud. Ingångar finns samlade på symbolens
vänstra sida; utgångarna på den högra. In- och utgångar avsedda för logiska signaler
betecknas med små bokstäver och analoga (=kontinuerliga) signaler med stora.
Tabell 1-1 anger hur logiska signaler tolkas.
Table 1-1 specifies
how logical signals is interpreted.
|
Logic input signal |
|
TRUE
|
?0 |
|
Till ingångar ansluts insignaler av motsvarande typ. Analoga signaler till analoga
ingångar och logiska signaler till logiska ingångar.
Då ett objekt erfordrar ett ingångsvärde som inte är en signal läggs värdet lämpligen
i ett Av- eller Dv-objekt som knyts till ingången med hjälp av en GetAv eller GetDv.
Detta värde kan sedan hanteras med med hjälp av objekts-bilden för Av- resp. Dv-objekt.
Har insignal knutits till ingång läses vid exekvering nytt signalvärde in och lagras
normalt i instansen. Det finns dock objektklasser där inläst signalvärde används utan
föregående lagring. Så är fallet för And-, Or-, Xor-, Timer-, Wait-, Waith-, Pulse-,
SR-vippor, ASup-, DSup- m. fl. objektklasser. Dessa objektklasser kan därför inte
använda öppna ingångar. Lämnas en sådan ingång öppen resulterar PLC Editorns
SYNTAX-kontroll resp COMPILE-funktion i varning.
Ska en insignals värde läsas explicit är principen att aldrig hämta värdet från
ingången utan att läsa från motsvarande utgång, dvs den utgång som ingången är
kopplad till. Flaggorna, InRtdb respektive NoRtdb , se tabell See Input Attribute
Flags, visar om en insignal lagras i rtdb eller ej.
Öppna ingångar får som standard signalvärde (default värde) enligt objekt klassens
typobjekt. I objektbeskrivningen anges defaultvärde för de flesta attributen.
För vissa attribut gäller att värdet kan ändras med Objekts Editorn både i utvecklings- och målmiljön medan andra attribut bara kan ändras i utvecklingsmiljön.
Överst i symbolen står klassens namn och underst återfinns objektets sista namnled;
standardmässigt slutar denna med en siffra.
En tjock vertikal linje indikerar att ett underliggande 'sub-window' knutits till
objektet.
Objektkroppens attribut har i förekommande fall delats upp i:
·
Input Attributes Attribut som i objekt symbolen har ingångar för grafisk
anslutning av signaler.
· Output Attributes Attribut som i objektsymbolen har utgångar för grafisk
koppling till andra objekt.
Varje attribut beskrivs på formen:
Graph name:
Type: attribute data type
Flags: attribute flags
Default value:
Ingångar resp. utgångar i objekt med grafisk symbol har namn som anges av
Graph
name .
Type
anger attributets data typ
Av Flags
Av Flags framgår i vilken situation attributet används, t.ex. huruvida ett ändrat attributvärde beaktas eller ej i målmiljön.
Default
value
anger vilket värde attributet åsätts som standard vid konfigureringen.
Type anger den förväntade datatypen på den storhet som ska knytas till attributet.
Table 1-1 lists traditional
standard data types.
Note! Attributes of the type pwr_tFloat32 are precise
to 7 digits. It is worth to remember this, especially in the use of objects as
Timint, Sum etc. where the output can be very large numbers.
Description
|
||
pwr_tObjid...:
Objid |
Flagg-attribut vars namn börjar med 'Open' avser öppna ingångar.
Antag att vi editerar ett PLC program i PLC Editor. En godtycklig ingång i ett
ospecifierat objekt xxx är antingen kopplad (connected) till ett objekt eller
också lämnas den öppen.
Detta fall hanteras i målmiljön på två helt skilda sätt beroende på var pekaren till
det kopplade objektet finns.
·
Pekaren finns i rtdb , dvs i objektets datadel. Lämnas ingången öppen pekar pekaren
på ett attribut som också finns i rtdb. ändrade värden beaktas. Om istället ingången
är kopplad används det attribut i det kopplade objektet som pekaren anger. Ingånger
av denna typ flaggas OpenParam.
·
Om pekaren inte finns i rtdb utan i objektets koddel (exe-modul) flaggas
ingången OpenCompileFixParam.
Output and Internal
Attribute Flags
Utsignaler speglar objektets tillstånd. De hanteras som parametrar frånsett att de kan göras åtkomliga i den grafiska PLC Editorn.
Attributet får som standard värde enligt (objekt)klassens typobjekt om inget annat
anges. I förekommande fall anges defaultvärdet i objektbeskrivningen.
Med tick avses här PLC-jobbets bascykeltid, dvs den nominella tiden, i sekunder,
mellan två successiva exekveringar av PLC-jobbets basfrekvens tråd.
Ett tick ska vara 0.02 sekunder eller heltalsmultipel av 20 millisekunder.
Vissa objekt använder s.k. timerstyrning. Ett objekt med aktiv timerstyrning reagerar efter en bestämd tid, angiven av objektets TimerTime , med att t.ex.
·
sätta eller ta ned binär signal som hanteras av timerstyrningen
TimerTime räknas från en given händelse; t.ex. positiv flank på en av objektets ingångar.
Timerstyrning exekverar alltid med samma period som PLC-jobbets basfrekvenssubprocess.
Det betyder förbättrat uppförande för objekt med timerstyrning och som tillhör
PLC program som inte exekverar varje tick. å andra sidan ger timerstyrningen
ingen fördel till sådana objekt om de tillhör PLC program som exekverar varje tick.
Att ändra värde på aktiv timer
Om en timer som håller på att räknas ned ska ändras görs detta genom att värdet på objektets TimerCount ändras enligt följande:
·
För att öka löptiden med t.ex. 600 sekunder ska TimerCount ökas med 600 sekunder / PLC-jobbets bascykeltid.
·
Genom att sätta TimerCount = 0 eller TimerFlag till FALSE avbryts en pågående timerstyrning.
Sett från en viss nod kan objekt som enbart tillhör den aktuella noden betecknas som lokala objekt. Från noden sett betecknas då övriga objekt som icke- lokala.
Läsning av attribut i icke-lokala objekt görs med hjälp av prenumeration. En lokal kopia av objektet skapas och denna uppdateras periodiskt. Läsningen görs i den lokala kopian.
Uppdatering av attribut kan endast göras i lokala objekt. Ska värdet till icke- lokalt objekt måste läsning görs från den aktuella noden.
Lokala och icke-lokala signaler
Varje process nod kan hantera viss mängd fysiska signaler. Dessa kan vara anslutna
till kort på nodens buss (lokalt I/O-system) s.k. lokala signaler eller till kort i
distribuerade I/O-system (icke-lokala I/O-system) s.k. icke-lokala signaler.
IO-jobbet (se IOHandler ) hanterar bl. a. datautbytet med de distribuerade I/O-systemen
i form av seriell kommunikation. Icke-lokala signaler av typen:
- Ai hanteras med perioden ScanInterval CycleTimeSerial
- Ao, Di, Do och Co hanteras med perioden CycleTimeSerial
Både för lokala och icke-lokala signaler görs signalomvandlingarna i processnoden.
The time specified by TimerTime in such
objects as Pulse , Timer"Snabba" PLC program
Antag att PLC programmet innehåller ett objekt med attributet TimerTime och
att cykeltiden är 20 millisekunder. Eftersom kvoten TimerTime / 0.02 avkortas
till närmast lägre heltal kommer TimerCount att få värdet 1, både när
TimerTime = 0.025 och 0.035 sekunder, dvs. TimerTime bör anges som en
heltalsmultipel av PLC programmets basperiod.
.
Antag PLC program med ScanTime = 1 sekund och Pulse objekt med TimerTime = 2 sekunder.
PLC-jobbets bascykeltid = 20 ms
Om fördröjningen d1 är större än fördröjningen d2, kommer 100 ticks fördröjningen
inte att ha gått ut vid den 3:e exekveringen. Det betyder att den effektiva
fördröjningen blir ca: 3 sekunder trots att den nominella fördröjningen är
2 sekunder, eftersom Pulse objektets utgång inte tas ned förrän förrän vid
4:e exekveringen.
Den verkliga tiden kan i praktiken bli både kortare och längre jämfört med den
nominella TimerTime .
.