Lars1

Jeg vil ringe til en elektriker ASAP. Noget kan tyde på at du har en afbrudt 0V ledning et eller andet sted i din tavle, og det kan føre til overspænding de forkerte stedder hvilket kan brænde elektronik incl. LK IHC af.

Hvordan fik du hentet programmet ned på din computer? Kunne Visual godt forbinde via USB? Hvad sker der hvis du skriver ping usb i en komando line på din PC?

Hvilken controller har du og hvad sker der når du forsøger http://usb?

For at programmer Visual 3 skal de glemme alt om hvordan IHC term programmeres. Det er 2 vidt forskellige metoder. Visual 3 programmering ligner mere alm. programmering end det ligner IHC term programmering. Når det er sagt, så vil jeg personligt ikke kaste mig ud i at lave mit første visual program lige inden en ferie. Dertil er der for mange faldgrupper i Visual, og en justering af antal pulser eller timer kræver nogle uger med trial and error. Det skulle jo nødig være sådan at tyven kan bryde ind og løbe med dine ting før alarmen går i gang. Den simpleste metode (IMHO) er at lave en forsinkelse FB for hver PIR hvor indgangen starter og stopper nedtællingen som beskrevet før. Hvis timeren går i 0 skal alarm udgangen på FB'en aktiveres. Denne forbindes så til PIR indgangen på alarm FB'en. Dette kan laves på et par min. når man kender Visual. Desværre har jeg pt. ikke adgang til Visual, så jeg kan ikke lave det for dig, og jeg kan ikke checke om ovenstående ikke allerede findes i en standard forsinket ON FB. Du må ikke forbinde flere PIR til den samme forsinkelse FB. Dette skyldes at LK IHC er event styret, så hvis 2 PIR går ON og 1 sek. senere går den ene OFF, så vil indgangen på FB'en være OFF selvom den ene PIR er ON og den anden OFF. Det er med andre ord, den sidste ændring som bestemmer status på indgangen.

Eftersom det virker bortset fra de periodiske fejl alarmer, så er det ikke inverteringen som er problemet, men nærmer følsomheden. Det er ikke ualmindeligt at der er forskel på følsomhed på PIR af forskellig fabrikater. Hvis du ikke kan sænke følsomheden mere på dine PIR's kan du prøve at øge antallet af pulser før alarmen går, men som Lars Jacobsen skriver, sørg for at gøre det over tid således at 4 pulser over 1 time ikke ender med at trigge alarmen. Alt efter puls tiden på din PIR skal det være 4 pulser inden for 10 sek. eller noget i den stil. En anden metode kan være at starte (med initial værdi) en nedtællings timer når PIR'en bliver aktiveret, og stoppe når PIR'en ikke længere er påvirket. Når timeren at løbe ud skal alarmen aktiveres. Hvilken metode der er bedst afhænger af puls tid/mønster etc. på din PIR.

Grunden til at en alm. PIR ikke kan bruges som alarm PIR er at en alarm PIR har udgange ON når den ikke er påvirket, mens en alm. PIR har udgangen OFF når den ikke er påvirket. At udgangen er ON i upåvirket tilstand for en alarm PIR skyldes at alarmen så også vil gå hvis nogen klipper kablet til alarm PIR'en eller forsøger at saboter den ved at fjerne strømmen til den. Mange alm. PIR har også en vis forsinkelse fra ON til OFF, ligesom følsomheden i en alarm PIR ofte er højre end en alm. PIR, men dette kan dog ofte justeres i de moderne udgave af begge. Sålænge du tager højde for at puls signalet er inverteret på en alarm PIR så bør der ikke være nogen forskel i resten af programmet ved et skifte fra alarm PIR til alm. pir.

Hvis det er wireless tryk kan batteriet i trykkene været gået død. Du kan se i Visual programmet om det er wireless tryk eller ej. Hvad sker der når du skriver http://usb? Får du webforsiden på controlleren eller får du en Java fejl når du forsøger at starte administrator eller service view. Hvis du bare får "siden findes ikke" eller noget tilsvarende når du skriver http://usb, så er det driveren som af en eller anden grund ikke er installeret korrekt så USB ikke bliver oversat til en IP adr. Du kan enten prøve at lægge "10.18.93.2 usb" (uden ") ind i C:\Windows\System32\drivers\etc\hosts eller du kan prøve at bruge IP addressen direkte isteddet for usb i http://usb. Hvis det er en Java fejl, så brug enten java starteren fra LK's support site eller søg efter tråden Java problemer igen igen igen. Der i er der workarounds for div Java problemer alt efter hvilken firmware level du er på.

Problemet er højst sandsynligt er at dine lampe udtag ikke er hardware version 2, men den ældre version 1.x. Såvidt jeg husker står der HW ver 2.0 eller noget i den stil under dækslet på de nyer lampe udtag. De gamle står der ofte ikke noget om HW version. Halogen pære på min. 20W vil 99% sikkert løse problemet, men det er en stakket frist, da de også snart udgår, og så er der kun LED's tilbage. Den rigtige løsning er at få skiftet loft udtagene til den nye model. De kan dog ikke bare skiftes. De skal også linkes til dine tryk hvilket kan være lidt omstændigt. Enhver elektriker som skriver LK IHC på deres website bør kunne fortage udskiftningen. Selv med nye loftudtag kan du fortsat opleve at LED's flimmer ved lav lysstyrke, dog ikke så slemt som ved de gamle loftudtag. Men du skulle ikke længere have summe lyden, samt du burde ikke have problemer med at tænde/slukke og reguler op/ned.

De deler ikke resourcer. Man forbinder bare 16 udgange på den ene controller med 16 indgange på den anden controller. E.g. Data linie udgang 15 på den ene controller forbindes til data linie indgang 8 på den anden controller. Grundet den måde som LK IHC controllerne kommuniker med I/O modulerne bliver der overført 16 udgange, selvom der normalt kun er 8 udgange på et output modul. Skulle man få forbundet data linie udgang 16 isteddet for 15, bliver kun de sidste 8 udgang overført. Hvis du skulle lave noget data overførsel mellem 2 eller flere controller, så ville det være dejligt hvis man kunne overføre temperatur, counter, timer etc. hvilket man ikke kan idag.

Jeg kun haft 4-5 controller i hænderne, så nej det er ikke noget jeg har set før, og vil betragte det som en klar produktions fejl. Men det er nok forsent at klage over. Kan du få forbindelse til controlleren via Visual, ServiceView, AdminView etc? Mellem en ubrugt indgang og 0V skal du kunne måle 24V. Kan du ikke det er der noget som er forkert. Prøv at dobbelt checke at modulerne er forbundet korrekt. Input modulerne får 0V via dataline ledningerne. Bemærk at der kun er 1 0V terminal per 2-3 input modul terminal på controlleren. 24V skal forbindes direkte til input modulerne modulerne. Output modulerne får ligeledes 0V via dataline ledningerne, og skal ligeledes have 24V tilsluttet direkte. Der er samme udfordring med at der kun er 1 0V terminal per 2-3 output modul på controlleren. Derudover har de seperate terminaler for forsyning til udgangene.

Igen. Jeg kender ikke Visual 1, men det vil undre mig om en FB i Visual 1 er afhænging af specifike produkter så længe disse har nogenlunde samme ind/udgange. Prøv at tilføje FB 1.24 til dit Visual 1 program, og se om du ikke kan linke dine produkter til den nye FB.

Du kan enten bare fjerne FB'en helt, eller du kan fjerne linket mellem udgangene på FB'e og div. udgange eller andre FB's. Har du prøvet at hente den seneste Visual 1 fra LK's support website. Mon ikke de nyeste FB's følger med den.

At finde håndværker som vil røre ved andet end producent supporterede hyldevare synes at være blevet umådeligt besværligt. Jeg har selv i over 6 mdr. ledt efter en køle montør, som kan hjælpe mig med at lave en varmepumpe som kan sættes på mit ventilations anlæg. Både Nilan og Genvex har standard produkter til dette formål, men de skal alle placeres lodret. Mit ventilations anlæg ligger på loftet i et 2 etages hus hvor det ikke er muligt at føre ind og udblæsning gennem 1 sal eller ud gennem væggene. Jeg har ikke selv arbejdet med Visual 1, men at dømme ud fra de screenshots etc. jeg har set, bør det ikke være meget mere besværligt end Visual 2/3. Hvis du med frakoble mener at disable alarmen så den ikke kan gå i gang selvom den er tilsluttet. Ja de kan man sagtens gøre i Visual 1, men så kan du ligeså godt lægge den rigtige FB ind med det samme. Det største problem med Visual 1 er nok at få forbindelse til controlleren. Såvidt jeg husker kræver det en RS232 forbindelse. Det er der ikke mange som kender til idag.

På billedet ser det ud til at være et stikbens relæ i en DIN skinne sokkel. Sådan et kan også monteres uden DIN skinne sokkel.

Er det ikke 230V udgaven som har det med at stå af? Dem havde jeg et par stykker af som blev byttet på garantien.

Når du påvirker et tryk laver du en kortslutning mellem en input indgang og 0V. Eftersom indgangene også bruges til røg alarmer, skal sikring etc. hvor indgangen konstant er kortsluttet er det ikke muligt at brænde en indgang af ved at kortslutte den. En 24V udgang derimod kan max holde til 500mA, og en standard LK IHC strømforsyning kan levere 3A ved 24V, så her er det teknisk muligt at brænde en udgang af, selvom jeg har aldrig har hørt om det før. Vedr. dit garage lys. Hvad er det som ikke virker og hvad virker?

Jeg har aldrig hørt om at fugt i et alarm tastatur kan brænde et LK IHC output modul af, så den forklaring tror jeg ikke så meget på. De fejl jeg ofte ser er løse eller knækkede ledninger. LK IHC ledninger er ikke særlige tykke, og hvis man ikke passer på under afisolering risiker man nemt at de knækker under montage uden man opdager det. Har du prøvet at checke hvad der sker i serviceview når dit garage lys skal tænde/slukke? Det kan være noget så banalt som et flag som står anderledes end du forventer. I serviceview kan du også manuelt ændre på status på ind og udgange, hvilket hjælper meget under fejlsøgning i den fysiske installation.

Du skal nok prøve at finde en elektronik forretning eller søge efter print relæer.

Som jeg skrev. Som udgangs punkt skal man henvende sig hos forhandleren. Hvis denne ikke eksister længere kan man henvende sig til producenten, som dog er berettiget til at henvise til en anden part som håndter reklamationer på deres vegne. Og vedr. LK. Den eneste effektive måde at kontakte dem på er ved at ringe, eller hvis du kender en elektriker som kan kontakte dem for dig. De svare desværre sjældent på henvendelser fra private. Det er meget bedre hvis man kan bruge et firmanavn.

Som ved alle andre reklamationer er udgangs punktet at man skal henvende sig der hvor man har købt produktet, og så længe fohandleren eksister er producenten i sin fulde ret til at henvise dertil.

Touch problemet findes kun på wireless dimmer og kun hvis du går fra en gammel version af Visual 2 til Visual 3. Jeg tror faktisk ikke at det kan lade sig gøre at upload et Visual 2 program med touch dimmer produkter til en Visual 3 controller. Du vil få en fejl med henvisning til de produkter i dit program som ikke er understøttet af Visual 3. Problemet er at der for flere år siden var 2 wireless dimmer produkter i Visual. Et med 1 tast betjening (touch) og et med 2 tast betjening. Et Ø80 wireless dimmer lampeudtag understøttede begge produkter, og du valgt betjenings metoden når du linkede din wireless dimmer til controlleren. De sidste mange år har man ikke kunnet vælge touch produktet når man linkede wireless enheder, men det har fortsat været understøttet i firmwaren. Denne understøttelse er fjernet i Visual 3. Selvom du valgte 2 tast produktet under linkning, er det fortsat muligt at betjene dimmeren via 1 tryk. Det er bare et spørgsmål om hvordan din FB er kodet. Skulle du have wireless dimmer som er linket med touch produktet er problemet ikke større end når du linker dem til din Visual 3 controller, så skal du bruge et 2 tast produkt, og alt efter din FB, skal denne måske omkodes eller udskiftes med en ny. Jeg kan dog ikke huske om LK's dimmer FB's understøtter 1 tryk betjening

Hvis du har lukket brusekabine så vil jeg give dig ret i at ventilatoren hurtigt får klaret fugt problemet, men hvis du har en åben, så breder fugten sig hurtigt i hele badeværelse, og så tager det nemt et par timer eller mere at komme ned på normalt fugt niveau igen. Det er dog ikke et problem som er så stort at jeg personligt vil smide mange penge efter en fugt styret ventilator.

Folk læser dokumentation forskelligt, og nogle ting er svære at beskrive end andre. Udfra overenstående virker det ikke til at du har forstået det grundlæggende princip i scenarier eller LK IHC i det hele taget. Der findes 5 operationer med scenarier. Fremkald Scenarie - Sætter de linkede udgange/dimmer til den værdi, som du angav da du linkede dem til scenarierne. Hvis du linker f.eks. et lampeudtag med værdien ON, så bliver lyset tændt, når du fremkalder det pågældende scenarie Gem Scenarie - Overskriver den værdi du angav da du linkede lampeudtaget eller dimmeren til dit Scenarie. Hvis lampeudtaget blev linket til at tænde når scenariet bliver fremkaldt, men er slukket når du gemmer Scenariet, så vil lyset fremover blive slukket når du fremkalder det pågældende Scenarie. Reguler Scenarie op - Bruges kun på wireless dimmer. Lys styrken bliver reguleret op fra du kalder Reguler Scenarie Op og indtil du enten kalder Reguler Scenarie ned, eller stop regulering af Scenarie. Reguler Scenarie ned - Bruges kun på wireless dimmer. Lys styrken bliver reguleret ned fra du kalder Reguler Scenarie ned og indtil du enten kalder Reguler Scenarie op, eller stop regulering af Scenarie. Stop regulering af Scenarie - Beskrevet oven over. Med andre ord. Hvis du vil bruge Scenarier til at tænde og slukke lyset, så skal hver FB have 2 Scenarier. Et hvor du linker lampeudtagene med status ON og et hvor du linker dem med status OFF. Når du vil tænde lyset fremkalder du scenariet hvor lampeudtagne er linket med status ON, og når du vil slukke fremkalder du scenariet hvor lampeudtagne er linket med status OFF. Der er ikke noget i vejen for at linke lyset i dit vaskerum, fyrrum og værksted til flere forskellige scenarier, og selvom du tænder lyset i alle 3 rum via et scenarie, kan du sagtens slukke det i et af rummene med et andet scenarie. Da LK IHC er event baseret, kan dette også lade sig gøre med alm. udgange. Men pas på. Hvis din funktions blok til lysstyring har et internt flag som holder øje med om der skal tændes eller slukkes for lyset når du næste gang trykker på kontakten, så kan dette flag meget nemt komme ud af sync med den reelle status på lyset, og så vil du skulle trykke 2 gange for at enten tænde eller slukke lyset for at komme tilbage i sync. Forskellen på et scenarie og en alm. udgang er at med en alm udgang i en funktions blok, så bliver lyset sat til det som du angiver i din funktions blok, mens det ved fremkaldelse af scenarier er afhængig af den status du linkede lampeudtaget med, eller den status lampeudtaget havde da du sidst gemte scenariet. Et lampeudtag kan sagtens linkes til flere udgange og scenarier på flere funktions blokke på samme tid, men det anbefales ikke at gøre det da man nemt mister overblikket over hvorvidt lyset er tændt eller slukket i programmet. Dit ønske til lysstyring i vaskerum, fyrrum og værksted kan laves både med og uden Scenarier. Umiddelbart kan jeg ikke se at Scenarier vil gøre hverken til eller fra. Brug FB 1.1.01.d avanceret kip (Visual 2.8.6) i hvert rum, og link så dine tryk som du gerne vil have at de skal tænde og slukke lyset. F.eks. NV på tryk i gang. linkes til en indgang i FB'erne som tænder lyset, mens NØ linkes til en indgang som slukker lyset. ØH og ØV i hvert rum linkes til en indgang på den lokale FB, som kipper lyset i rummene. Om du bruger udgange eller scenarier til at linke lampeudtagne til funktions blokkene gør ingen forskel, men lampeudtaget i hvert rum skal kun linkes til lysstyrings FB'en i det pågældende rum.

Jeg tror du blander en række begreber sammen, og det kan man ikke løse med dokumentation. Tilbagemelding bruges kun på wireless enheder, og er tilbagemelding fra enhederne om status efter en ændring. F.eks. dimmer melder aktuel lys styrke tilbage hvilket er meget praktisk på kombi dimmer som også kan styres via tryk på dimmeren. Som jeg skrev, så virker scenarier ikke meget anderledes end alm. udgange. Forskellen er primært hvad du kan linke til et scenarie. Rute lys kan programmers via scenarier ved at du linker alle de lamper på ruten til samme senarie. Når du vil fremkalde rutelyset starter du med at gemme rutelys status scenariet, præcist som i mit brand alarm eksemple. Herefter fremkalder du et scenarie, som tænder alle lamperne på ruten, og til sidst når du vil slukke rutelyset, fremkalder du det gemte scenarie eller et scenarie, som slukker alle lamperne. De samme lamper som er linket til scenariet, kan også linkes til andre funktioner, herunder sluk alt og dermed også styres individuelt. Anbefalingen er dog at man ikke styre udgange fra flere FB's, da man nemt taber overblikket over status på udgangen grundet den manglende tilbagemelding på alm. udgange. Normalt vil en scenarie ændring af en udgang også kunne ses i andre FB's som er linket til den samme udgang, men der er også tilfælde hvor dette ikke virker. Med andre ord. Dit rutelys børe programmers ved at du har en rutelys indgang i FB'er som styre lamperne som findes på ruten. Sidst men ikke mindst. Den bedste måde at lære noget er ved at prøve sig frem og se hvad der sker når forsøger at linke forskellige ting til f.eks. et scenarie og så lege med fremkaldelse og gem.

Har du prøvet at læse den villedning som findes under hjælp i Visual. Scenarier er godt beskrevet her i såvidt jeg husker. Den største forskel på Scenarier og andre styrings metoder er at du kan bruge scenarier til at styre flere ting på samme tid uden at skulle have flere udgange i din FB. Du kan f.eks. både linke en dimmer og en alm. on/off udgang til det samme scenarie. Det kan du ikke med en alm. udgang. Derudover kan du også linke f.eks. en stikkontakt til at gå ON når scenariet fremkaldes og en anden til at gå OFF når samme scenarie fremkaldes. Det kan du heller ikke med en alm. udgang. Du kan også gemme et scenarie, og fremkalde det igen senere. At fremkalde et gemt scenarie, betyder at du vender tilbage til en tidligere gemt status for alle linkede enheder. Jeg bruger det f.eks. til min brand alarm. Når alamen går gemmer jeg et scenarie før jeg tænder alt lys. Når brand alarmen bliver afstillet, fremkalder jeg scenariet igen og alle linkede lamper går tilbage til den status de havde før alarmen gik. Skulle jeg gøre det samme med alm. udgange, vil jeg skulle have en udgang for hver lampe i min brand FB.