TorbenSørensen

Har du husket, at forbinde Lysindikering fra dimmeren, til indgang Lysindikering i fb. 1.2.03.d.?

Enig... Det er Conson Concept 2000 >>>LINK<<<

Så skal du bare trække Udgang_Sol_Nede over på dit lampeudtag. Hvis lampen derimod styres fra en anden fb., bør du ikke gøre det sådan, men i stedet for styre den fb., ved eksempelvis at bruge pulsudgangene til tænd/sluk - det afhænger dog helt af hvilken fb. der bruges, for hvordan det gøres mest hensigtsmæssigt.

Bruger ikke selv denne fb., men jeg kan se, at du i dit tilfælde skal indstille den som på vedhæftede... Hvilke udgange du skal bruge, afhænger så helt af, hvad du kobler den sammen med.

Når den er placeret udenfor, og du vil bruge den flere steder med forskellige niveauer, kunne man jo f.eks. også lave en fb. med et antal udgange (evt. 1 udgang pr. rum), der bliver styret af de forskellige niveauer du ønsker. Så kan man derfra føre dem op til indgange for skumring i de forskellige fb. du har i hvert rum.

Ja, det er en lidt dum fejl de har lavet dér. Det er så (desværre) absolut ikke den eneste funktionsblok, der er udgivet, hvor der ikke er helt styr på, hvad der egentlig sker ved powerup. Fordelen ved IHC er jo så, at man selv har mulighed for at rette i funktionsblokkene eller lave dem selv.

Ja, så kan man evt. indsætte en indgang til lux-måling, og så lave settingværdi for hvornår der er mørkt nok. Så skal der nok laves en offset/hysterese-værdi for hvornår der er lyst igen, så det ikke sker, så snart lyset tændes i rummet, eller evt. lave spærring så længe Pir-timer tæller ned. Alternativt kan det også laves i en separat fb., hvor en udgang styret af lux-føleren, så trækkes op på den indgang for skumringsrelæet.

Du skal gemme fb. under dit funktionsblokbibliotek.. Lav gerne en ny mappe, som f.eks. hedder 07. Mine egne fb., hvis den ikke allerede er der i forvejen. Derefter skal du genstart Visualprogrammet, og så skulle den gerne kunne findes blandt de funktionsblokke du kan vælge iblandt i Visual.

Så prøv denne i stedet. Der er indsat valgmulighed under indstillinger, så du kan vælge om lyset må tændes, når der er lyst eller ej. Pir styring med konstant slukket_1.vis

Er det noget i stil med vedhæftede du søger? Du har godt nok indsat et skumringsrelæ under input, men har ikke lige beskrevet funktion for det, så det har jeg ikke lavet funktion for?? Pir styring med konstant slukket.vis

Der er fejl i fb. fra LK under powerup... De har lavet kommandoer til udgangene Alarm tilkoblet og Alarm frakoblet ens, ligemeget om PGM input er ON eller OFF ved powerup.

Du kan prøve om vedhæftede løser problemet, eller om der lige skal skrues lidt mere i funktionsblokken. 6.5.01.ifb

Er det med dit gamle program fra Visual 2, at det ikke fungerer i din Visual 3 controller, eller er det fordi du har indsat nye varme-funktionsblokke og nye temperaturfølerprodukter i produktsiden i Visual i forbindelse med opgraderingen?

Jeg har også en endnu ældre firmwareloader 1.1.93 kan jeg se.. Den er dog helt tilbage fra en gammel Visual ver. 2.01, så om den overhovedet kan bruges, tør jeg ikke gætte på. FirmwareLoader.exe

Kan se at Søren B som startede denne tråd, også har en uden viewer, og at det for ham lykkedes at opdatere til 2.8.4., så det er åbenbart ikke det som er problemet.. Så har jeg desværre ingen gode bud.. De få 6.1 controllere jeg har opdateret, alle med viewer, kørte også lige igennem med fw 2.8.4 uden problemer.

Har vedhæftet firmwareloader 1.3.3 Er din controller med eller uden viewer? Ved ikke om det har noget at sige, eller om det måske kun er dem med viewer som kan opgraderes.. Det kan være, at der er nogle af dem, som ejer en controller uden viewer, kan oplyse om det kan lade sig gøre. FirmwareLoader1.3.3.exe

Er du 100% sikker på, at det er firmwareloader 1.3.3 du forsøger med? Hvis jeg starter firmwareloader 1.3.3 får jeg nemlig et LK-logo i øverste venstre hjørne, og ikke et Schneider-logo, men det gør jeg nu godt nok heller ikke med de nyere firmwareloadere? Prøv lige at trykke på About oppe i højre hjørne, for lige at verificere at det rent faktisk er 1.3.3. Lyder godt nok helt usandsynligt, men mon de få herinde, som ikke er lykkedes med at opgradere deres 6.1 controller med fw2.8.4, kan være fordi det ikke er den danske version af firmwareloaderen de bruger?? Mindes at der også var en person fra Brasilien, som heller ikke lykkedes med at opdatere sin 6.1 controller, og tror måske også at den stoppede ved 74% hver gang.. Hmm??? Har vedhæftet billede af hvordan min firmwareloader 1.3.3 ser ud.

Der findes nok ikke en standard fb. der lige passer, men det er jo det smarte ved IHC - at man kan bygge sine egne fb. som passer lige nøjagtigt til de specifikke behov man har.

Så kan du prøve om vedhæftede fungerer efter hensigten. lamelgardin.vis

Du mangler lige at angive, som Bjarne også nævner, om nogle af udgangene skal kunne/må køre samtidigt, eller om der evt. skal slukkes for igangværende udgange, hvis ny funktion vælges? Eller skal igangværende funktion køre færdig, før ny funktion kan aktiveres? Må man kunne aktivere den samme funktion 2 gange i træk, eller skal den have kørt modsat først?? Når først logikken er på plads, kommer der sikkert et forslag til funktionsblok.

Husk på, at hver gang du ændrer i dit program, opgraderer firmware, skifter controller, flytter tavle osv., laver du jo også en genstart af controlleren. Derved bliver intervallet for hvornår controlleren genstarter næste gang jo "nulstillet", og ud fra dine post her i forum, har du (heldigvis) gjort flittig brug af din IHC installation, hvilket alt andet lige, må have genereret flere genstarter på de par år du har haft din IHC. Hvis ikke jeg selv lavede log på genstart af controller, ville jeg ikke opdage 9 ud af 10 genstarter. Hvis der i programmet er styr på intialværdier, kører programmet jo bare videre som om intet var hændt, efter controlleren er rebooted.

At påstå at en IHC controller ikke genstarter af og til, passer simpelthen ikke. Jeg ved godt at vi har debatteret emnet før, men jeg vil da gå så langt at give dig ret i, at det kunne være dejligt, hvis den ikke genstarter en gang imellem. Der er mig bekendt kun 2 måder, hvor du kan få dig en controller, som aldrig (eller tæt på) vil genstarte.. Den ene måde er er lave sin egen FW til controlleren, hvilket nok ikke er lykkedes for nogle, og den anden er at lave et simpelt program uden automatiseringer, men så kunne man jo ligeså godt have lavet en traditionel elinstallation.. Det er 100% “by design” at controlleren genstarter, bestemt af FW i controlleren. Jeg har såmænd set controllere, som har kørt over 1 år uden genstart, men så har der kun været et helt simpelt program med kip på samtlige udgange, hvor controlleren kun løber programmet igennem, hver gang at der er blevet trykket på et tryk, men hvorfor så vælge IHC? Jeg oplever selv her efter at der er blevet koldt og gulvvarmestyringen kører, at der er kortere mellem genstart i forhold til i sommer. Det er fordi at programmet til gulvvarmestyringen holder controlleren beskæftiget det meste af tiden. Sagt på en anden måde - jo mere avanceret et program du har i controlleren, des oftere vil den genstarte. Jeg kan huske at da jeg brugte FW 2.7.199 kørte min controller ca. 1 måned mellem genstart. Så udkom FW 2.7.220, som stadig ligger til download på LK’s hjemmeside, og med den installeret, genstartede min controller ca. hver 3. dag... INTET var ændret i mit program... Efter en måneds tid med mange genstarter, downgradede jeg FW til 2.7.199, og så genstartede den igen ca. med 30 dages mellemrum og det var stadig med helt samme program i controlleren. Noget helt andet jeg opdagede, da jeg hjalp Jan, var at min egen controller kan genstarte, uden at jeg kunne se det i IHCAdministrator. Jeg havde kopieret nogle af Jans funktionsblokke over i mit eget program, for at teste hvad der skete med dem, når jeg tvang controlleren til at genstarte fra IHCAdministrator. Min controller er sat op til at sende en SMS når den genstarter, hvilket jeg fik hver gang, men det var ikke hver gang, at det fremgik af oppetiden på forsiden i IHCAdministrator, at den rent faktisk var genstartet. Det har jeg aldrig lagt mærke til før.

Det er bare et langt tryk, på det tryk du regulerer lyset med (touch), og det skal selvfølgelig være i det rum som er ude af synk. Når man laver sådan et langt tryk på touch, vil funktionsblokken altid antage at lyset er tændt (reguleret), så derfor vil status i funktionsblokken komme på ret kurs igen, da du ikke kan slukke lysdæmperen med et langt tryk på touch-klemmen.. Set i bagklogskabens klare lys, som du også har læst dig frem til, er de eneste rigtige lysdæmpere at bruge til IHC, en wireless dimmer fra LK. Det er de eneste der kan give status til controlleren om de er tændt/slukket og %-sats på lysstyrken, og hvis man bruger IHCTablet, er styringen derfra også bare langt bedre.

Jeg giver Bjarne ret her.. Det lyder 100% som om, at funktionsblokken var kommet ud af synk. Når funktionsblokken er kommet ud af synk., kan du lave en reguléring af lyset på dit tryk (langt tryk). Så retter status på funktionsblokken, så det igen passer med virkeligheden.

Har lige kigget i dit program.. Det ser ud til at der opstår et problem angående linket, hvor din PIR er trukket over på funktionsblokken med den såkaldte "PIR funktion", som ikke opstår hvis man trækker PIR over som alm. følg-funktion. (se vedhæftede billede) Jeg har lige indsat en powerup-timer, som skulle afhjælpe det problem, så prøv om vedhæftede fungerer. Jeg har lige ændret de 2 links fra dit skumringsrelæ til en "følg med powerupfunktion".. Sådan forbinder man gerne skumringsrelæet til funktionsblokke, da de så antager rigtig status med det samme når programmet uploades eller genstart af controller. Ellers får de funktionsblokke forkert status på skumringsrelæet, hvis man uploader programmet til controlleren imens der er lyst. nib_1.ihc