Komponenter och Aggregat
Det här kapitlet handlar om hur man programmerar med hjälp av komponenter och aggregat.
En komponent är ett (eller att antal objekt) som hanterar en komponent i anläggningen. En
komponent kan var t ex en ventil, en kontaktor, en temperaturgivare eller en frekvensomformare.
Eftersom det här är komponenter som förekommer i många olika typer av anläggningar är det idé
att försöka göra ett objekt som innehåller allt som behövs för att styra och kontrollera
komponenten, och som är så generellt att det kan användas i de flesta anläggningar.
En komponent i ProviewR kan vara uppdelat på ett antal objekt:
- ett huvudobjekt som innehåller konfigureringsdata och data som behövs vid övervakning och
drift av komponenten. Det innehåller även signal-objekten för komponenten.
- ett funktionsobjekt som läggs in i plcprogrammet och som innehåller koden för att styra
komponenten.
- ett I/O objekt som definierar eventuell kommunikation med t ex en profibus modul.
- ett simuleringsobjekt för att enkelt kunna testa och simulera systemet.
Dessutom ingår en objektbild, dokumentation, ev trendkurvor mm.
Aggregat är en större del i anläggningen än en komponent, och innehåller ett antal komponenter.
Ett aggregat kan t ex vara en pumpstyrning, som består av komponenterna pump, motor, kontaktor
och säkerhetsbrytare. I övrigt är aggregatet uppbyggt som en komponent med huvudobjekt,
funktionsobjekt, simuleringsobjekt, objektsbild, dokumentation mm.
Objektsorientering
ProviewR är ett objektsorienterat system, och komponenter och aggregat är ett område där man
utnyttjar objektsorienteringens egenskaper fullt ut. I komponenter kan man
se hur man bygger upp objekt av andra objekt, att ett attribut förutom att vara en enkel typ
som en float eller en integer, även kan vara ett objekt som i sin tur består av andra objekt.
Ett attribut som är ett objekt kallas för ett attributobjekt. Det är inte riktigt analog med
ett fristående objekt eftersom det inte har något objektshuvud och inte någon egen
objektsidentitet, men i övrigt innehåller det alla egenskaper som ett fristående objekt har
i form av metoder, objektbilder mm.
Ett exempel på attributobjekt kan vi se i komponentobjektet för en magnetventil. Här ligger
signalobjekten, två Di objekt för gränslägen och ett Do objekt för styrsignal för att
öppna ventilen, intern i objektet som attributobjekt. Vi behöver alltså inte skapa signalerna
separat, utan i och med att ventilobjektet är skapat, har vi även skapat signalerna för detta
objekt. Ett annat exempel på attributobjekt är ett motoraggregat som innehåller komponentobjekt
för frekvensomformare, säkerhetbrytare, motor mm i form av attributobjekt.
En annan viktig egenskap inom objektsorienteringen är arv. Med arv menas att man kan skapa
en subklass utgående från en existerande klass, en superklass. Subklassen som ärver alla
egenskaper från superklassen, men man har möjlighet att lägga till eller förändra en del
egenskaper. Ett exempel på detta är en komponent för en temperaturgivare som är en subklass
till ett generellt givarobjekt för analoga givare. Den ända skilladen mellan temperatur-
givarklassen och dess superklass är objektsbilden, där givarvärdet presenteras i form av en
termometer i stället för en stapel. Ett annat exempel är ett pumpaggregat som subklassar ett
motoraggregat. Pumpaggregatet har utökats med ett pump objekt och har även modifierade
objektsbilder som förutom motorstyrningen även visar en pump.
Fig Objektsbild för subklassen BaseTempSensor med superklassen BaseSensor
En annan egenskap som vi har infört är möjligheten att sätta attribut ur funktion. Orsaken till
detta är att komponentobjekten måste göras så generella att de täcker in alla varianter av
den komponent i anläggningen de ska styra. En magnetventil kan t ex ha ett gränsläge som
markerar att ventilen är öppen, men det finns även ventiler med gränslägen som markerar stängd
ventil, eller ventiler med båda gränslägena eller ventiler helt utan gränslägen. Man skulle
naturligvis ha kunna göra fyra olika komponentklasser, en för varje gränslägesvariant, men
problemen uppstår när man vill bygga aggregat av komponenterna. Antalet varianter av ett
aggregat blir snart ohanterbart om man ska täcka in alla olika varianter av delkomponenterna.
Om vi t ex ska göra ett aggregat som innehåller fyra magnetventiler och varje ventil kan
finnas i fyra varianter, blir det 64 varianter av aggregatet. Vill vi dessutom bygga ett
aggregat som innehåller fyra ventilaggregat är vi uppe i 4096 olika klasser. Lösningen är att
bygga en ventilkomponent med båda gränslägena, där man sedan genom en konfigurering kan sätta
attributen för ett eller för båda gränslägena ur funktion, så den kan hantera alla fyra
gränslägesvarianterna. I det här fallet är det attributobjekt av klassen Di som sätts ur
funktion, vilket innebär att de inte visas i navigatören och ignoreras av I/O hanteringen.
Dessutom tas det hänsyn till detta i koden för ventilkomponenten och i objektsbilder.
Konfigureringen gör i konfiguratören från popupmenyn där man under 'ConfigureComponent' kan
välja en konfigurerring av de olika alternativ som finns.
Fig ConfigureComponent metoden för en BaseMValve.
Baskomponenter
ProviewR innehåller ett antal komponent och aggregat objekt för vanliga element i en anläggning,
t ex temperaturgivare, tryckgivare, tryckvakt, magnetventil, filter, motorstyrningar och
fläktstyrningar. De finns samlade i klassvolymen BaseComponent. En baskomponent kan användas
rakt av, och det är nog det vanligaste sättet att använda dem, men tanken är också att man
utgående från basklasserna skapar klasser och bygger upp bibliotek med för de specifika
komponenter man använder i sina anläggningar.
För magnetventiler finns basklassen BaseMValve. Har man en magnetventil av typen
Durholt 100.103 skapar man en subklass med BaseMValve som superklass, Durholt_Valve_100_103,
och lägger in den konfigurering som gäller för just den här ventilen, dessutom lägger man in
en länk till datablad och fyller i Specification attributet så att man kan identifiera och
beställa reservdelar till ventilen. När man använder ett Durholt_Valve_100_103 objekt behöver
man sedan inte göra så mycket konfigureringar och anpassningar eftersom detta är gjort redan
i klassen. På det här sättet kan man bygga upp komponentbibliotek för de olika typer av
komponenter som man använder i sina anläggningar.
Ett problem uppstår när man använder aggregat. Aggregaten innehåller baskomponenter från
BaseComponent och finns det specifica subklasser för komponenterna, vill man kunna använda
dessa även i aggregaten. Lösningen på problemet är Cast (forma) funktionen. En baskomponent
i ett aggregat kan castas till en subklass, under förutsättning att subklassen har samma
storlek, dvs att subklassen inte har utökats med nya attribut. Castningen innebär att
komponenten hämtar initialvärden, konfigureringar, metoder, objektbilder mm från subklassen,
dvs i alla lägen uppträder som den subklass den är castade till. Castningen utförs från
popupmenyn i konfiguratören, där man i 'Cast' alternativet får upp en lista på de subklasser
som finns att välja på. Genom att välja en subclass castar man komponenten till denna.
Tryckvakt
Låt oss titta på en relativt enkel komponent, en tryckvakt, för att se hur den är uppbyggd och
hur man konfigurerar den. För tryckvakter finns baskomponenten BasePressureSwitch, som är en
subklass till BaseSupSwitch. Eftersom temperatur-, tryck-, och nivåvakter är väldigt lika ur
övervakningssynpunkt har de en gemensam superklass. BaseSupSwitch har i sin tur en superklass,
Component, som är gemensam för all komponentklasser. Klassberoende för tryckvaktsklassen blir
med andra ord
Component-BaseSubSwitch-BasePressureSwitch
Component klassen
Component innehåller attributen Description, Specification, HelpTopic, DataSheet, CircuitDiagram,
Note och Photo som alltså finns i alla komponenter. I Description finns plats för en kort
beskrivning, i Specification lägger man in modelltypen för den komponent det är frågan om, de
övriga används för att konfigurera motsvarande metoder i operatörsmiljön.
BaseSubSwitch
Från superklassen BaseSupSwitch ärvs attributen Switch, AlarmStatus, AlarmText, Delay,
SupDisabled och PlcConnect.
- Switch är Di objektet för tryckgivaren. Detta måste kopplas till
ett kanalobjekt i nodehierarkin.
- AlarmStatus visar larmstatus i runtime.
- AlarmText innehåller larmtexten för det larm som skickas vi larmstatus. Larmtexten har
defaultvärdet "Pressure switch, ", men kan naturnligvis bytas ut mot någonting annat.
Observera att om defaulttexten behålls, kommer denna att översättas om man väljer att
annat språk. Lägger man in en annan text, sker ingen översättning.
- Delay anger larmets fördröjning i sekunder, (default 0 sekunder).
- SupDisabled indikerar att larmet är undertryckt.
- PlcConnect är koppling till funktionsobjekt i plc-koden.
Till huvudobjektet BaseSupSwitch, finns det ett funktionsobjekt BaseSupSwitchFo, och
även detta ärvs av tryckvakskomponenten.
BasePressureSwitch
BasePressureSwitch har inte några attribut utöver de som har ärvts från superklasserna. Det
som är unikt för BasePressureSwitch är den grafiska symbolen,
Components/BaseComponent/PressureSwitch, och objeksbilden, där switch-symbolen innehåller
ett P som markerar tryck.
Konfigurering
Vi öppnar konfiguratören och lägger in huvudobjektet, BasePressureSwitch, i anläggning-
hierarkin. I ett lämpligt PlcPgm lägger vi in funktionsobjektet BaseSupSwitchFo och
kopplar detta till huvudobjektet med connect-funktionen. Välj ut huvudobjektet och klicka med
Shift/Dubbelklick MB1 på funktionsobjektet. Funktionsobjektet innehåller koden för komponenten,
som för en BaseSupSwitch är ett larm skickas vid larmtillstånd.
Fig Huvudobjekt med tillhörande funktionsobjekt
Tryckvakten ska visas för operatören i en Ge bild. Vi öppnar Ge-bilden och hämtar subgrafen
BaseComponent/SupSwitch från paletten. Subgrafen är anpassad till till en BaseSupSwitch, så
det ända vi behöver göra är att koppla den till huvudobjektet. Välj ut huvudobjektet i
planthierarkin och klicka med Shift/Dubbelklick MB1 på subgrafen.
Fig Grafisk symbol, popupmeny med metoder och objeksbild
Det här räcker för att göra komponenten funktionsduglig. Sedan kan man naturligvis forsätta
att konfigura metodattributen med hjälptexter och länkar till fotografier, elschemor och
datablad.
Reglerventil
Nu ska vi titta närmare på en lite mer omfattande komponent, BaseCValve, som styr en
reglerventil. Till skillnad från tryckvakten ovan, måste man använda ConfigureComponent för
att konfigurerar objektet, dessutom finns det ett simuleringsobjekt som används för att
testa systemet.
Antag att vi har en reglerventil, som styrs med en analog utsignal, och som ger positionen
tillbaka i en analog ingång. Här kan vi använda en BaseCValve. Den har den analoga utsignalen
'Order' och den analoga insignalen 'Position', dvs de signaler som vi efterfrågar. Dessutom
finns två digitala insignaler för gränsläge öppen och gränsläge stängd, men dessa kan
elimineras med hjälp av konfigurering.
Konfigurering
Vi lägger in huvudobjektet BaseCValve i planthierarkin och funktionsobjektet BaseCValveFo i
ett PlcPgm, och kopplar ihop dem med Connect funktionen. Funktionsobjektet har en orderingång
som vi kopplar till ett PID objekt. Vi måste även ange att vår ventil inte har några gränslägen,
och det gör vi genom att välja 'ConfigureComponent/PositionNoSwitches' i popupmenyn för
huvudobjektet. När vi nu öppnar huvudobjektet, och i detta Actuator objektet, ska vi hitta
en Position signal, men inga gränslägessignaler.
Fig Huvudobjekt med funktionsobjekt
Fig ConfigureComponent alternativet PositionNoSwiches
Vi lägger även in subgrafen BaseComponent/CValve i en Ge-bild och kopplar denna till
huvudobjektet.
Nu vill vi även kunna simulera ventilen, för att se att den fungerar som vi har tänkt. För
simulering finns funktionsobjektet BaseCValveSim som vi lägger i ett speciellt PlcPgm för
simulering, eftersom det inte ska exekvera i driftsystemet. Funktionsobjektet kopplas till
huvudobjektet med Connect-funktionen.
Fig Simuleringsobjekt för reglerventilen
Konfigureringen är klar och efter att ha byggt simuleringsnoden kan vi testköra och titta på
resultatet.
Pumpstyrning
Nästa exempel är ett aggregat, en pumpstyrning med en frekvensomformare som kommunicerar via
Profibus med protokollet PPO3. Vi kommer att se hur ett komponentobjekt i aggregatet, förutom
huvudobjekt, funktionsobjekt och simuleringobjekt, även omfattar I/O objekt för att hämta och
skicka data via profibus.
Klassen vi använder är BaseFcPPO3PumpAggr, och om vi tittar på klassberoendet är det
Aggregate-BaseFcPPO3MotorAggr-BaseFcPPO3PumpAggr
Alla aggregat har superklassen Aggregate som motsvarar Component classen för komponenter. Nästa
superklass, BaseFcPPO3MotorAggr innehåller all funktionalititet för styrningen. Själva pump
klassen BaseFcPPO3PumpAggr utökar motoraggregatet med ett pumpobjekt som representerar den
mekaniska pumpen, men som inte innehåller några signaler eller någon ytterligare funktionalitet.
Dessutom har pumpaggregats klassen en egen objektbild och en egen grafisk symbol.
Konfigurering
Huvudobjektet BaseFcPPO3PumpAggr läggs i anläggningshierarkin och funktionsobjektet (som ärvts
från motoraggregatet) BaseFcPPO3MotorAggrFo läggs i ett PlcPgm, och de båda kopplas ihop med
Connect funktionen.
Huvudobjektet har inte mindre än 24 olika konfigureringar att välja mellan, beroende på
vilka av komponenterna Fuse, Contactor, SafetySwich, StartLock och CircuitBreaker som finns med
i konstruktionen. I vårt fall har vi bara en kontaktor och en frekvensomformare och väljer
alternativet ConfigureComponent/CoFc.
En del komponenter i ett aggregat kan ha egna konfigureringar. I det har fallet kan kontaktorn
och motorn konfigureras individuellt. Vår kontaktor har två signaler, en Do för order och en Di
för feedback, och det stämmer med default konfigurationen, så denna behöver vi inte ändra på.
Motorn däremot har ett motorskydd i form av en temperaturvakt, därför väljer vi ut motor
komponenten och aktiverar ConfigureComponent/TempSwitch i popupmenyn.
Nästa steg är att koppla ihop signalobjekt med kanalobjekt. Kontaktorn innehåller en Do och en
Di för order resp feedback som kopplas till lämpliga kanalobjekt i nodehierarkin. Motorn,
har en temperaturvakt i form av en Di som också ska kopplas. Frekvensomformaren innehåller
fyra signaler, StatusWordSW (Ii), ActSpeed (Ai), ControlWordCW (Io) och RefSpeed (Ao). Dessa
signaler utbyts med frekvensomformaren via Profibus med protokollet PPO3. Det finns ett
speciellt Profibus modulobjekt för PPO3, BaseFcPPO3PbModule, innehåller kanaler för PPO3
kommunikation. Modulen konfigureras mha Profibus konfiguratorn (see Guide to I/O System),
och kopplas ihop med FreqencyConverter komponenten i pumpaggregatet. Eftersom komponentobjektet
och modulobjektet är anpassade till varandra, behöver man inte koppla signal för signal, utan
man kopplar component med modul istället. Genom att välja ut modulobjektet och aktivera
ConnectIo i popupmenyn for FrequencyConverter komponenten är kopplingen gjord.
Vi lägger även in subgrafen Components/BaseComponents/FcPPO3PumpAggr i en översiktsbild
och kopplar denna till huvudobjektet. Vidare lägger vi in ett simuleringsobjekt
BaseFcPPO3MotorAggrSim i ett speciellt simulerings PlcPgm, och kopplar detta till huvudobjektet.
Mode
PumpAggregatet innehåller ett Mode objekt där man konfigurerar varifrån pumpen styrs. Det
innehåller moderna Auto, Manuel och Local med följande betydelse:
- Auto: pumpen styrs av plc-programmet.
- Manuell: pumpen styrs av operatören från objektsbilden.
- Lokal: pumpen styrs från en pulpet.
I Mode objektet kan man konfigurera vilka moder som är aktuella för den här pumpen.