Lars1

Umiddelbart ser det ikke ud til at der er nogen strømforsyning til controlleren på loftet, så mon ikke der allerede ligger et link kabel mellem de 2. Hvis der er en strømforsyning på loftet, så er det vigtigt at du får forbundet 0 mellem de 2 strømforsyninger, så du har samme 0 potentiale når du enten laver sammekoblingen eller nedlægger den ene controller. Hvis du ellers er godt tilfreds med dine controller kan du jo også bare nedlægge den ene, ved at samle alle I/O moduler og programmer på den anden. Du kan stadigvæk lave programmet på forhånd, så det kun er selve omkoblingen af I/O modulerne som giver nedetid.

LK har gennem flere år skrevet at firmware og Visual skal opdateres samtidig. Det er snart 2 år side at de begyndte med versions kontrol i firmware loade og visual. Før da var der ingen kontrol, og det medførte nogle sjove hændelser når man forsøgte at programer noget som en nyer Visual understøtter, men firmwaren ikke understøtter. Et af problemerne er ændringer i Java. Dit problem med unable to load application er kendt, og skyldes at der er ændret sikkerheds settings i de nyer Java versioner, og at man skal sætte dem tilbage, for at kunne starte de gamle Java programmer som LK har i deres gamle firmwares. Alt dette er beskrevet i detaljer i tråden Java problemer igen igen igen.

Det er en Java fejl, som opstår når du opdater Java. Check tråden Java problemer igen igen igen for en workaround. Det er ikke nødvendigt at opdater til firmware 2.8.4, men jeg har gjort det og controlleren køre fortsat uden problemer.

Du er ikke den første som har oplevet LK IHC's ustabilitet, eller at noget pludselig virker efter gentagende genstart. Det er korrekt, men den advarsel kom samtidig med at de droppede supporten af HW 6.1, og som du kan se here på boardet er der flere som har opgraderet uden problemer.

Jeg vil prøve at opgrader den med seneste firmware fra HW 6.2. For at gøre det skal du have fat i en af de ældre firmware loader, som ligger her på boardet. Jeg har selv en HW 6.1 af same årgang, og den blev opgraderet med seneste 2.8.x firmware for ca. en uge siden. Indtil videre ingen problemer og det løste mit problem med at få fat på controlleren over nettet. Jeg ved der er andre som også har opgradert en HW 6.1 controller med firmware til en HW 6.2 controller uden problemer. Jeg har fornylig købt en USB for længer, så jeg kan når controlleren via USB fra min hjemme arbejdsplads. Det er en nød løsning når net forbindelse svigter eller der skal opdateres firmware, men stædigvæk nemmer en at skulle afmonter controlleren , eller balancer med en laptop i bryggerset. Forlængeren kostede 250 kr. incl. fragt fra AV-cables. De har også andre som er billigere.

Prøv at tage strømmen til controlleren, så den slukker helt i mindst 10 sek. Er alle dine wireless enheder batteri drevne?

Jeg har samme problem med windos 7 og Visual/firmware 2.7.x. Efter jeg har opdateret til Visual/firmware 2.8.x er problemet væk. Opdateringen krævede dog en gammel XP pc, da de gamle firmware loader uden versions tjek ikke kunne forbinde til controlleren under windos 7. Jeg fandt aldrig ud af hvad problemet er med windos 7.

Check tråden Java problemer igen igen igen. Der er forskellige workarounds afhængig af kombinationen af Java versions og LK IHC firmware.

Det lyder lidt som en blanding af forkert bruger navn/password og forkerte Java opsætning. Bruger navn/password kan du rette via adminview. Det kan du nå via http://usb når du er tilsluttet controlleren via USB. Der skal ikke bruges password når du logger på admin view, via USB, men hvis du får en login mislykkes, er det sandsynligvis fordi at Java ikke er konfigureret korrekt til den kombination af Java og firmware du køre med. Du kan finde den korrekte opsætning i tråden Java problemer igen igen igen.

Hvilken version er din controller og hvilken SW forsøger du med? Hvis det er admiview, som giver login mislykkedes, kan det være forkert Java opsætning. Check tråden Java problemer igen igen igen, for workarounds for problemer med div. Java versioner.

For 3-6 mdr. siden kunne jeg pludselig ikke længere komme i kontakt med min HW 6.1 controller fra Visual og firmware loaderen. Det var ligegyldigt om jeg forsøgte via USB eller over LAN. Serviceview, adminview etc. virkede fint. Både via USB og LAN. Det samme gjorde firmware loaderen til Visual 2.8.x, men den kan jo som bekendt ikke uploade firmware 2.8.x til en HW 6.1 controller. Jeg havde en mistanke om at m$ kunne have frigivet en patch som blokerede eller fjernede support for et eller andet som Visual/firmware loader 2.7.x og ældre var afhængig af, men jeg havde ikke tid til at undersøge det nærmere. I dag havde jeg så endelig tid til at undersøge det nærmere. Stadigvæk samme problem med windos 7 og Visual/firmware loader 2.7.x og ældre. Men så fandt jeg min gamle windos XP pc frem, og fik børstet støvet af den. Efter installation af Visual 2.7 prøvede jeg så om jeg kunne få forbindelse, og vupti. Forbindelse efter få sek. med firmware loaderen, og ingen problemer med at lægge firmware 2.8.4 i controlleren. Efterfølgende var der heller ingen problemer med at connecte med Visual 2.8 til min HW 6.1 controller. Hvis nogen finder ud af hvad der er ændret i windos 7, som gør at man ikke længere kan forbinde til sin HW 6.1 controller med Visual 2.7.x, høre jeg af ren nysgerighed gerne om det. Men ellers er her en forklaring til jer andre som køre med windos7/10 og har problemer med at forbinde til jeres HW 6.1 controller. Tilbage har jeg kun det irreterende problem at hvergang jeg starter Visual 2.8, så får jeg en user control warning, og skal godkende at Visual 2.8 må køre. Den fik jeg ikke med Visual 2.7, og jeg har ingen idee om hvordan jeg slipper af med den.

Jeg tror der er et problem med Windos 7/10 og Visual 2.7.x, men laver lige et en ny tråd om det.

Har du prøvet om wireless rebuild funktionen virker når man skifter fra HW6.1/6.2 til HW7, eller om det kun er ved skrifte fra HW7 til en ny HW7?

Det er såmænd ikke så svært. Man skal bare tænke som man gjorde for 20-30 år siden da LK IHC blev designet. Det er stortset ikke ændret på det grundlæggende design siden.

Store programmer hænger ofte sammen sammen med mange og komplexe FB's, som igen ofte hænger sammen med mange flag og interne parameter, som sættes i et væk, hvilket generer mange events.

Eftersom LK IHC er event styret, og derfor ikke løber hele programmet igennem hvergang, så vil jeg sige den opsætning som generer flest events, og der bliver genereret en event hvergang du sætter et flag, en parameter eller en udgang.

Controlleren gør sådan set kun hvad den får besked på. Problemet er at den er hændelses styret. Det betyder at hvis du har en FB med udgang on, og en anden FB med udgang off, og disse 2 er linket til den samme fysiske udgang. Den fysiske udgang vil nu have den status som sidst er sat, og hvis du checker på udgangs status'en i FB'en vil den være hvad FB'en sidst satte den til, som ikke nødvendigvis er det samme som den fysiske udgang. Kort sagt noget rod, som man ikke rigtigt kan beskylde controlleren for. Det er samme problem som gør at du efter en genstart kan risiker at udgangen i din FB og den linkede udgang har forskellig status. Det kan opstå hvis ikke flaget husk værdi ved genstart er sat ens på de 2, og der ikke er noget som tricker et gennemløb af FB'en under genstart.

Du kan kun linke 1 wireless enhed af gangen, og der skal være belastning på dem når du linker dem. En LED pære er sommetider ikke nok belastning. En halogen eller gløde pære er bedst.

Det vil hjælpe meget hvis du brugte bare 10 min. på at studer den villedning som følger med din controller. Ja der er fejl i den, men ikke nogen graverende, som vil gøre at du ikke forstår det der beskrives.

Gætter på at du ikke bruger Alarm delen. Her kan der nemt gå ged i logikken hvis du har flere røgsensor eller sabotage kredse på samme FB indgang.

Korrekt. 2 PIR på den samme indgang til 1 FB kan ikke anbefales. Hvis du vil have 2 PIR på samme FB, bør du køre dem gennem en OR blok. Det vil virke i 99% af tilfældene, men med LK IHC vil jeg ikke blive forbavset hvis der går kuk i timeren fra tid til anden. Dog næppe mere end at lyset slukker før forventet, men det afhænger af PIR FB'en. Ja.

Hvis du bare vil have en funktionalitet som i TermIHC skulle du have købt et stak kip relæer i steddet. Det vil have været meget billigere. Det er ret tydeligt i dit andet indlæg at du endnu ikke har brugt tid på at sætte dig ind i hvad du kan med Visual, og hvordan Visual programers. Det er også IF muligheder i Visual, men de skal kodes i en FB. Prøv at loade LK's bolig program, og brug lidt tid på at sætte dig ind i hvordan det er bygget op og hvad det kan.

Jeg er også ganske tilfreds med mit, og kunne ikke drømme om at installer IHC NET Basic eller LexCom Home hvis jeg skulle starte fra scratch idag.

Nu er det MEGET sjældent at nogen skriver her bare for at rose LK IHC, så det er ikke unaturligt at du vil se mange indlæg om problemer med Wireless, præcise som du tidligere påstod at eftersom der er mange indlæg om problemer med programering af Visual 2, må TermIHC være meget bedre, da der ingen indlæg er her om problemer med det.

Indgange må forbindes til alle de FB'er du har lyst til. Det er kun udgange, som kun bør forbindes til 1 FB, og det skyldes at LK IHC er event styret. I praktis betyder det at hvis du har 2 FB's tilsluttet en udgang, vil den sidste handling bestemme status på udgangen. Eller med andre ord. Hvis den ene FB sætter udgangen ON og den anden OFF, vil udgangen have den status som sidst blev sat. Dette gælder også indgange på FB's. Du bør ikke forbinde 2 forskellige produkter eller FB'er til samme indgang på en FB. Tryk er dog undtaget, da de normalt kun sender en puls.