ThomasHej Skrevet April 12, 2014 Rapporter Share Skrevet April 12, 2014 Hej folkens, Er der nogle som har dybere information omkring regelsættet omkring afvikling af IHC function-Blocks? Spørgsmålet er lidt kryptisk, man hvad jeg mener er svar på en række spørgsmål som f.eks. 1) Hvis jeg i en FB tænder en udgang som nu vil trigge 2 events (FB'ere) som skal afvikles. Under afvikling af FB 1, sætter jeg en anden udgang som trigger endnu et event... Hvad er nu rækkefølgen? Generelt er der 3 muligheder: Når man fra en FB trigger et ny event, kan dette (a) eksekveres med det samme og derefter returneres til original FB. Det triggerede event kan lægges i kø til eksekvering når indeværende FB er færdig - I så tilfælde kan det lægges ( forrest i køen, © bagerst i køen. Dernæst: Hvis man inden man når til dette event i køen, ændrer udgangen tilbage så det ikke længere er relevant med triggeren, hvad sker så? Igen er der flere muligheder: (a) Hvert triggered event lægges i kø med værdien på det tidspunkt triggeren skete - i så fald vil der i ovenstående situation blot blive lagt en ON efterfulgt af en OFF senere. Men man kunne også have en mekanisme som udryddede disse events som går "mod hinanden". 2) Sammenhæng mellem FB indgange/udgange og fysiske porte - Cirkulære referencer Forestiller man sig, at man gerne vil lave en "gruppe-kip" (lad os blot glemme scenarier et øjeblik). Altså en FB som skal kunne tænde og slukke (on/off) for 3 lamper. 1.version er nem: Vi laver en simpel Kip og forbinder blot de 3 lamper til udgangen. - så langt så godt. Nu kommer der desværre et krav om en status indikering som skal kunne vise: ON, OFF eller "midt i mellem". Med det sidste menes den situation, at man efter at have tændt de 3 lamper via gruppe-kip FB'en, slukker en af lamperne via et andet tryk eller funktion. Vi er nu i den situation at 2 af de 3 lamper er tændt. Dette leder til et par spørgsmål: a) Når man har en udgang hvortil der er linket flere fysiske og/eller logiske enheder, og disse tændes/slukkes fra ekstern side, hvad er så værdien af den udgang i min gruppe-kip FB? Altså, GruppeKip.Udgang = ON. -> 3 lamper ON. (Forventeligt)Ekstern event, Lampe 2 OFF -> GruppeKip.Udgang = ? Det leder til adskillige spørgsmål omkring sammenhængen mellem logiske udgange (f.eks. GruppeKip.Udgang) og så de fysiske. Hvilken vej er flowet i IHC systemet og hvordan håndteres cirkulære referencer? (jeg ved de stoppes, men på hvilket niveau? Samme event eller blot et event i samme FB? eller noget tredje?) Nå, tilbage til GruppeKip. Uanset hvad svaret er på ovenstående, kan GruppeKip.Udgang ikke være 66% on, så vi er nødt til at lave vores FB om, så vi kan "se" de enkelte lamper en ad gangen. Altså: GruppeKip.Udgang1 er forbundet til lampe1GruppeKip.Udgang2 er forbundet til lampe2GruppeKip.Udgang3 er forbundet til lampe3 Et enkelt event responderer på samtlige ændringer af de 3 udagnge og kan derefter sætte status til ALLE ON, ALLE OFF, MIDT-I-MELLEM Problemet er blot, at når man fra ekstern kilde (lad os sige en simpel kip direkte til lampe 2), ændrer denne, bliver mit event ikke kaldt. Altså: SimpelKip.Udgang = OFF -> Lampe2 = OFF -> GruppeKip.Udgang2 = OFF Det sidste sker ikke. GruppeKip.Udgang2 bliver i serviceview vist som OFF, men event som responderer på GruppeKip.Udgang2's ændringer kaldes ikke i denne situation. Alt dette leder mig til at spørge... Er der nogle som har "regel-sættet" omkring hvilke actions som kalder hvilke events, og hvilke som ikke trigger FB'ere... Thomas Link til kommentar Del på andre sites More sharing options...
ihcJesper Besvaret April 12, 2014 Rapporter Share Besvaret April 12, 2014 1)Trigger event eksekveres med det samme, hvorefter den vender tilbage og fortsætter med oprindelig FB.Jeg ved ikke om der er nogen grænse for hvor dybt der kan kaldes.Man skal dog lige være opmærksom på at rekursive kald virker fint i simulatoren, men ikke i controlleren.Dette er jo nok for at sikre mod deadlock og stack overflow, men hvis man nu tænker at man har styr på sin exit betingelse, og ville udnytte det til at lave en for-loop eller while-loop, som jo heller ikke findes, så kan man altså godt glemme alt om det.... 2)Jeg ville tage de 3 lampers udgange (på produktet i venstre side) tilbage til input på din FB, og bruge denne tilbagemelding til at opdatere status. Link til kommentar Del på andre sites More sharing options...
Lars Jacobsen Besvaret April 12, 2014 Rapporter Share Besvaret April 12, 2014 På dit oprindelige spørgsmål:Nej, og jeg tror heller ikke vi skal forvente at kunne få informationen fra LK.1: prøv at lave en test, hvor der skrives til et statusflag. Måske kunne det give en indikation2a: uændret med mindre du har en eller anden form for tilbagemelding.Øvrige spørgsmål, tjaaaa. Men det leder mig til en mine kæphæste nemlig, at stille det "dumme" spørgsmål, hvorfor ? Hvad er årsagen og hvor vil du hen ?Hvis det blot er fordi du har "problemer" med at få logikken i en FB til at opføre sig som du gerne vil, så prøv at uploade den, så kan det være vi kan komme på en "workaround". At stille så "store" spørgsmål som at forstå hvordan den bagved liggende Linux kerne på Arm processoren afvikler kald er nok lige at tage munden fuld, selv i dette forum ;-) Link til kommentar Del på andre sites More sharing options...
TorbenSørensen Besvaret April 12, 2014 Rapporter Share Besvaret April 12, 2014 Jeg vil også sige at det er et svært spørgsmål at svare på, uden et vedhæftet eksempel i form af et ihc program. IHC er hændelsesbaseret, og når der sker en hændelse høvler den programmet igennem for at udføre handlinger. Det foregår selvfølgelig lyn hurtigt. Rækkefølgen i logikken er absolut ikke ligegyldig, da den render fb. igennem fra en ende af, så når man laver en fb. skal man selvfølgelig være opmærksom på, om nogle af kommandoerne skal komme før andre, for at give den ønskede funktion. Med hensyn til dit spørgsmål med 3 udgange som styres af hhv. en fælles og hver sin kip, forstår jeg det som om at du har flere fb., der styrer samme udgang?? Hvis det er tilfældet, er man nærmest sikker på at der kommer rod i status. Man bør altid kun have 1 fb. som styrer en udgang direkte. Hvis man har behov for at flere fb. skal styre samme udgang, bør det foregå ved at lade de fb. styre den "primære" fb. i stedet. Så undgår man mange problemer med styring og forkert status, hvilket der også er utallige eksempler på herinde. Link til kommentar Del på andre sites More sharing options...
ThomasHej Besvaret April 12, 2014 Forfatter Rapporter Share Besvaret April 12, 2014 Takker for svar so far... Jeg er temmelig godt hjemme i programmering (kodede mit første program i 1975, og arbejder i dag for Microsoft), og er samtidigt gammel nok til at have lavet Windows programmer dengang vi ikke havde MFC, Delphi, .NET eller hvad ved jeg. Dengang (og stadig i dag) var det blot en state-machine med messages. IHC er blot en simpel version med et message loop, men reglerne er åbenbart ikke kendte... :-) Jeg spurgte netop - som Torben også skriver - at rækkefølgen absolut ikke er ligegyldig og on messages SEND'es eller POST'es er absolut også relevant. Opgaven jeg var i gang med er ganske simpel. En gruppe-kip som kan tænde og slukke - lad os sige 5 - lampesteder samtidigt give en status (ON/OFF/MIDDLE). Dette med så få indgange/udgange som muligt og samtidigt skal FB'en kunne "opdage" at man "udenoms" har ændret en eller flere af de 5 og så automatisk opdatere status korrekt. Fremkald scenarie har denne "tryk som piller indgang" men det er sgu snyd. Det må være muligt at lave det så det virker uden at man skal huske at forbinde tryk til ren info. Desuden er status ikke korrekt hvis man "manuelt udenom" fremkalder et scenarie... Thomas Link til kommentar Del på andre sites More sharing options...
ihcJesper Besvaret April 12, 2014 Rapporter Share Besvaret April 12, 2014 Delphi !!! Du er min ven... Prøv vedhæftet gruppe kip FB 20140412 Thomas Toggle5.zip Link til kommentar Del på andre sites More sharing options...
ThomasHej Besvaret April 12, 2014 Forfatter Rapporter Share Besvaret April 12, 2014 Ikke tosset... Slet ikke tosset. Men, igen, hvad er rækkefølgen her. Lad os sige at jeg sender en puls på Ingang Toggle, hvilket nu sætter udgang lamper til ON, hvilket (via indgangene) beregner status. Men hvis udgange lamper laver noget andet som regner med at status allerede er sat, så burde man vel sætte intern status før man sætter udgangen... Men løsningen er helt fin, jeg havde ikke lige tænkt indgang men i stedet flere udgange... Thomas Link til kommentar Del på andre sites More sharing options...
ihcJesper Besvaret April 12, 2014 Rapporter Share Besvaret April 12, 2014 Nope.Den vil ikke lave rekursive kald. Og ændringer med event triggers, eksekveres med det samme. Se vedhæftet.Prøv at læse programmet for toggle, og se debug status for inputs under FB instillinger.20140412 Thomas Toggle5 Debug.zip Link til kommentar Del på andre sites More sharing options...
ThomasHej Besvaret April 13, 2014 Forfatter Rapporter Share Besvaret April 13, 2014 Hej Jesper, Tak for dit svar - med dit lille eksempel fik du faktisk svaret på mit originale spørgsmål. (Triggers ekseveres med det samme). Jeg tror dog stadig der er et issue... Værdi af udgang og status følges ikke ad. Jeg ville mene at man savner en "atomic operation" som kunne sætte udgang til ON og status til XXX, før events blev kaldt. Som det er lige nu, kaldes events så snart udgang sættes til ON (på dette tidspunkt er status ikke opdateret). Hvis en anden komponent har udgang og status som indgang vil han nu få en inkonsistent tilstand. Sagt anderledes: Da det er en trigger på udgang som indirekte ender med at opdatere status, SKAL denne udgang's trigger kaldes først før status igen er opdateret. Hvis man har flere ting på udgang som måtte være afhængige af status har man et problem. Løsningen er vel at lave et enkelt flag som "trigger". Inden da, sætter man alle udgange og status korrekt (hvilket ikke udløser triggere), og til sidst kip'per man sit flag som alle eksterne komponenter så har deres trigger sat op på. Nu er status/udgang konsistent. Men det er til gengæld nok meget besværligt, og nok totalt overkill... Jeg synes man ender i en situation hvor det er svært at vide "hvor master-info" er. Normalt arbejder jeg altid med én master og flere afledte værdier. Det er ikke helt nemt at definere hvad som er master og hvad som er afledt i IHC systemet. Og hvis først man har tabt hvor master-info er henne, har man tabt slaget... I et rum som f.eks. køkken-alrum som mange lamper, ind- og udgange samt dioder for status af andre ting, føler man sig fristet til at skrivet en "RumKontrol" FB som håndterer hele dette rum, og internt have fuldstændig styr på master-data. Er jeg den eneste som har det sådan? Thomas Link til kommentar Del på andre sites More sharing options...
ihcJesper Besvaret April 13, 2014 Rapporter Share Besvaret April 13, 2014 Ren faktisk havde jeg jo svaret allerede i første indlæg... IHC er singlethreaded, og uden mulighed for interrupt, så jeg synes ikke at det er noget problem at status opdateres efterfølgende. LK standard "Bolig kocept" er i nogen grad lavet med 1 stor rumstyring FB, og enumerator til at distribuere global status, så nej - du er ikke den eneste... Link til kommentar Del på andre sites More sharing options...
Recommended Posts