Wireless Jalousi Standard

[ThomasHej]

Hej Folkens,

Jeg har 2 markiser, som først blev leveret med "intelligente" motorer, forbundet til 230v 3-leder (jord,nul,fase) og en fjernbetjening (en til hver) - ikke nemt at forbinde til IHC.

Jeg har nu fået byttet motorerne til 2 Becker motorer, som er forbundet med 4-leder kabel (jord,nul,fase ud,fase ind) og så er sagen jo lige til.  

Jeg kan naturligvis styre dette med 4 stk 230v output porte eller 4 stk wireless relæer, og så selv kode det nødvendige.  ELLER (tænkte jeg), jeg kan købe 2 wireless jalousi standard og så er det jo nemt.

Problemet er, at disse wireless jalousi standard er helt "døde" når de forbindes korrekt.  De er jo også lidt specielle idet de ikke har nul forbundet og dermed lever at "krybestrøm" hele tiden.  Jeg tror motoren har en elektronisk cut-off (endestop) som gør at der ikke kan løbe "krybestrøm".  

Jeg er helt blank her.  Hvad har i andre gjort?  Kan man lave et lille kredsløb som kan forsyne jalousi relæerne med strøm?

 

Thomas

[ThomasHej]

Nå, ingen svar.

Jeg endte med at opsætte 4 IHC relæer, som styrer mine 2 markiser.  Hver markise styres så af 2 relæer, et som "kører ud" og et som "kører ind".

Jeg kodede en lille funktions-blok, som med et enklet tryk per markise, kan:
1) Kort tryk, markises kører ud (ved næste tryk køres modsat retning) til enden. Trykkes igen mens den kører, stoppes der på nuværende position.
2) Langt tryk, markisen kører ud (ved næste tryk køres modsat regning) men stopper når tasten slippes.

Desuden er der indgang for 2-knaps betjening, hvor den ene tast altid kører ud, og den anden altid ind.
Der kører i maksimalt 45 sekunder (kan ændres), så stoppes markisen.
Funktionsblokken kan aldrig tænde begge relæer samtidigt, og der er mindst 0.4 sekunds pause imellem forskellige operationer/retninger.

Det virker perfekt.

 

Markisestyring.ifb

[Lars1]

Hvis du søger her i forummet vil du se at der er flere som har stået i din situation, og dit spørgsmål er blevet besvaret flere gange. Såvidt jeg husker er anbefalingen at bruge 1 IHC udgang, som trækker et dobbelt relæ med både NC og NO kontaktsæt. Der sættes en fast fase (afbrudt af endestop hvis det eksister) på indgangen til relæet, og de 2 ledninger for køre ud og køre ind tilsluttes hver sin relæ udgang. IHC udgang ON = køre ud, OFF = køre ind.

Årsagen til denne løsninger at det er besværligt at kode en FB, så man er 100% sikker på at der aldig vil være spænding på begge retninger på samme tid. Specielt efter en controller genstart ser man ofte at status ikke er hvad man forventer, og så starter problemerne.

[ThomasHej]

Tak Lars,

Jeg søgte skam en helt masse, men fandt ikke det svar du kommer med foroven.  Nu har jeg købt og monteret mine 4 relæer, og med den blok jeg har skrevet, skulle det absolut ikke kunne lade sig gøre at sende strøm på begge på samme tid.  I en genstarts-situation stopper markisen hvis den skulle være i bevægelse.

Har du et link til disse NC/NO relæer, til en anden god gang... ?

 

Thomas

[Lars1]

Hvis du fra dette indlæg eller tråd søger på Jalousi vil du får en del links. Du kan også prøve at søge på rulle gardin eller gensidig spæring. De giver alle en del links til tråde om dette emne.

Der findes nok 100 forskellige relæer du kan bruge.

Jeg har rodet med LK IHC i over 20 år nu, og jeg bliver fortsat sommetider overrasket over hvad der sker i et program når en IHC controller genstarter. Problemet er at IHC controlleren er event baseret, og det betyder bl.a. at under genstart kan du ikke altid være sikker på at udgangen rent faktisk står som du ser den i serviceview etc.

På et tidspunkt var der en firmware version, hvor det var muligt at have en status på en udgang på et produkt, og en anden på den linkede udgange i FB'en. Jeg ved ikke om LK har fået udryddet denne mulighed helt, men den gav mig en del problemer på et tidspunkt, og siden har jeg ikke stolet på IHC controllerens status på udgange etc. Hvis jeg har en situation, hvor jeg skal bruge gensidig blokering, så laver jeg det via fysiske relæer.

[ThomasHej]

Hej Lars,

Missede lige dit svar, men tak for det anyways.

Jeg har selv rodet med IHC i mange år efterhånden (dog ikke 20), men jeg har programmeret hvad-som-helst i ca 40 år, men er til gengæld totalt rookie når det kommer til "rå elektronik".  Det er derfor jeg gerne ville have et helt konkret link til et relæ som jeg ville kunne bruge.  "Det findes 100 forskellige" hjælper mig ikke rigtigt :-)

Jeg er helt med på din betragtning omkring opstart af controller.  Dog er jeg rimelig sikker på, at jeg aldrig kommer til at sende strøm på begge relæer.  Udgangspunktet er, at markisen kunne være i bevægelse under opstart, men det første som opstart-eventen gør er at stoppe alt bevælgelse, slukke alle relæer og sætte intern state.  Ved enhver relæ ændring, startes desuden en timer, som sørger for at der ikke kan foretages endnu en ændring før "things have settled".

IHC er ganske rigtigt en state-machine, men det forhinder ikke at man stadig kan lave god kode omkring den.  Jeg ville som dig, aldrig stole på output porte, men anvender altid interne variable som "master".  Alle porte er derefter afledt information.  Dette tillader at man i sin funktionsblok aldrig er i tvivl.

Nok om det.

Jeg vil stadig sætte pris på et konkret link som ville kunne have løst ovenstående med et smart relæ. 

 

Thomas

[Lars1]

At programmer IHC kan ikke sammenligned med meget andet programering. Der er så mange faldgrupper i IHC.

Lige præcis timer og LK IHC's genstart skal du passe meget på med. En timer som tæller når controlleren genstarter, vil efter genstart stå stille på den værdi den havde da genstarten blev initieret. Hvis du har en betingelse i dit program, som er afhængig af om en tæller er stoppet, vil nu blive snydt da tælleren burde være igang med at tælle, men den er faktisk stoppet.

At bruge interne variabler som master kan betyde at der efter en genstart er uoverenstemmelse mellem hvad den interne variable stå til og hvad udgangen står til.

Ethvert relæ med 2 dobbelt kontaktsæt (NO/NC) kan bruges. Hvilket der passer til din installation afhænger af hvor det skal sidde, spærnding, strømstyrke etc. Der er vist nok links til relæerne i nogle af de andre tråde.

[ThomasHej]

Mange tak Lars for at du deler din ekspertise.

Jeg er nu helt uenig i at IHC programmering er usammenligneligt med anden programmering - tværtimod.  Vi har med en state-machine at gøre, og der er nu altså mønstre omkring disse som også lader sig anvende på IHC.  Windows-programmering (i gamle dage med WM_Command) mindede meget om IHC.  Forskellen på SendMessage og PushMessage - om en ændring blev lagt "i kø" eller kaldte notifikations-triggeren direkte var ikke altid til at regne ud, da man ikke vidste hvordan koden så ud (ligesom med IHC).

Faldgruberne som du identificerer, er jo blot en anden måde at udtrykke, at IHC ikke altid er konsistent i sin udførsel - men det er IHC absolut ikke ene om.

I mit tilfælde, har min Powerup blok, kode som sætter alle relæer til OFF og sætter desuden intern state til STOP.  Et igangsætter-tryk, vil altid blot sætte intern-state til hvad der nu kræves.  Når intern-state ændres vil relæer igen blive sat til STOP.  Og et enkelt tændes muligvis.  Når et relæ starter movement, kan der ikke startes movement i den anden retning før begge igen har været på stop i et lille stykke tid etc.

Jeg kan dog se en ting hvor det kan gå galt.  Da mine relæer er trådløse, kunne man teoretisk forestille sig, at radio-signalet til at sætte et relæ "off" gik tabt, og min FB derefter - i bedste tro - tændte relæer for modsat retning.  Det vil dog kræve, at mindst 2 pakker gik tabt, men det er velsagtens teoretisk muligt.  Jeg har dog checket at mine motorer ikke brænder sammen hvis de får strøm i "begge retninger".

Det er faktisk sjovt du nævner faldgruber i IHC.  Jeg har aldrig mødt en eneste af dem - men jeg er også meget defensiv i min kode.  Jeg forsøger ALDRIG at "regne med state" efter en powerup - men sætter aktivt intern state (og dermed afledt output-port) til fast værdi (typisk OFF).  Jeg læser ALDRIG en output-port og bruger den som "state".  Der er altid en bagvedliggende "master" som indikerer hvad som ønskes - output porte er blot manifestationen af intentionen.  Dette betyder, at en knap blot sætter f.eks. StueLys = BordOgSofa.  Dette dækker intention.  Derefter er der en trigger på skift i intention som sætter de enkelte output-porte.  På den måde er det meget nemt at ændre og udvide.  Kombinationer af lange tryk dobbelt-tryk osv, er blot også states.  PushAndHold state er min ven... :-)

...og dog - så passer det ikke helt af jeg aldrig er løbet på en faldgrube.  Jeg rendte faktisk på en faldgrube omkring CASE.  Hvis man laver en CASE og retter værdien som evalueres af CASE'en, så risikerer man at ramme flere af program-stumperne, alt efter deres rækkefølge - yikes.  Dette er dog mere sproget som der er noget galt med.  Men under alle omstændigheder, er det velsagtens dårlig stil at ændre den variabel som er genstand for CASE.  Hvis man virkeligt ville udnytte ovenstående, kunne man jo blot lave flere "IF" efter hinanden uden at kode i "ELSE" blokken.  Så ville det være mere klart hvad som sker (men stadig dårligt design).

 

Men så et helt andet spørgsmål.  Efterhånden som ens program bliver større, tager det længere tid at "hente/opdatere kørselsværdier", har du et trick som kan fikse dette?

 

Thomas

...Og endnu en gang tak for dine mange værdifulde inputs og svar her på siden - megen inspiration er fundet her.

[Lars1]

Den eneste måde at reducer tiden der bruges på hente/opdater kørselsværdier, er ved at begrænse bruge af elementer, hvor der er sat kryds i at tilstanden skal bevared ved strømsvigt. Det er disse som bliver henten når man uploader en ny version af det program man hentede tidligere. Hvis der ikke er sat kryds i at tilstanden skal bevares, så bliver de overskrevet med program default værdierne når den nye version bliver uploadet.