Alternativer Til Ihc

[Pergb]

Hej

 

Jeg har kigget lidt i indlæggene her på siden, og ser at det åbenbart ikke kun er mig, der er træt af de begrænsninger, der er i IHC.

Der er nogle kommercielle alternativer, men de er mig bekendt lige så proprietære, som LK.

 

Jeg har derfor spekuleret lidt, på selv at udvikle et system.

 

Et I/O modul med f.eks. 12 digitale indgange, og 8 PWM udgange, som kommunikerer over RS485.

Der skal naturligvis defineres en protokol.

Pointen er, at i en simpel udgave kan modulet være autonomt; hvis man ikke har brug for andet end tænd/sluk og måske ”sluk alt” kan det afvikle det hele selv.

Hvis man har en større installation, tilføjer man moduler efter lyst og behov, og en master. Det kan hvad som helst med en 485 port – En PC, en arduino ting, en Beagle Bone – eller bare et I/O modul, som ikke har så travlt med egne ind- og udgange.

 

Alle diagrammer, printlayouts og all source kode skal naturligvis være frit tilgængelig.

 

Så hvis ”Rikke” syntes at den kode I/O modulet kommer med, er skod, står det hende frit for at skrive noget ny kode. Hvis Brian mener, at det her problem løses bedre med en RasPi, så er det bare at få fyret op under editoren, og skrive noget kode, som understøtter hardware og protokol.

 

I princippet er der ikke noget til hinder for at kunne ”snakke” med IHC modulerne, men det kræver at man dedikerer porte til det i hardware. Der er i princippet heller ikke noget til hinder for at man laver en gateway, så man kan snakke med de trådløse IHC moduler, med Velux vinduer, Grundfoss pumper osv.

 

Mest interessant var det måske at udvikle en gateway, som gjorde alle ens bestående, trådførte IHC moduler styrbare over RS485?

 

Jeg vil meget gerne ha’ lidt feedback fra folk her. Er det et dødfødt projekt, som jeg skal putte ned i skuffen igen. Er der andre, som har gjort sig lignende overvejelser? Hvad savner du, i DIN installation?

 

Per

[Henrik Gundertofte]

Hej.

Det bedste ville være at udvikle en ny controller med datalinje I/O der erstatter den gamle - så kan man genbruge sine Output24/230/400 samt inputmoduler.

Fordelen ved at kunne genbruge i hvert fald output230/400  modulerne, er at det så er nemmere at lave sin installation lovlig - de modulkontaktorer der i givet fald skulle bruges, er dyre & fylder mere end et udgangsmodul med 8 udgange.

Den nye controller skulle så kunne kommunikere via ethernet / rs485 med åbne protokoller, & også gerne med wireless produkterne.

Dernæst muligheden for på en pc at opbygge en grafisk brugerflade (erstatning for sceneview) - i stil med noget scada software, som vi kender fra plc verdenen.

Det kunne evt. afvikles fra en webbrowser - og for guds skyld fri af java !!

 

Så - JA en gateway til styring via rs485 kunne være ganske intessant !

 

Mvh.

Henrik   

[AndersKjergaard]

Hej

 

Det lyder som et rigtig spændende projekt!

 

Jeg er helt enig med Henrik i at det smarteste er at genbruge de gamle I/O-moduler. Man kunne eventuelt lave et samarbejde på baggrund af IHC-Captain?

 

Du må meget gerne holde os opdateret herinde mht. hvad du gør. Jeg kunne muligvis også godt tænke mig at være involveret i projektet, hvis du tænker at det er nemmere at overkomme alene.

 

Vh Anders

[Pergb]

Hej igen

 

Jeg kan godt se pointen i at lave en gateway, så man kan genbruge forhåndenværende I/O moduler. Og Henrik har helt sikkert ret i, at det er svært at lave 8 230V relæudgange på den plads sådan et modul bruger. Og så har vi set bort fra alt det formelle (Godkendelser osv.)

 

Min umiddelbart største anke mod IHC er den totale mangel på integration af analoge størrelser.

Der er et udgangsmodul, og der findes tredjeparts produkter, men det har lidt karakter af "bolt on".

Specielt det analoge udgangsmodul er - IMHO - dyrt og klodset, og fylder datamæssigt som 8 udgange.

 

Det store dyr i åbenbaringen er den protokol, som anvendes mellem controller og moduler. Den er ganske simpel, og stammer fra en for længst udgået IC familie fra Telefunken/Temic. Jeg har vedhæftet databladet. Der er også en tråd på et andet forum, - http://www.tooms.dk/?page=http%3A//www.tooms.dk/forum/topic.asp%3FTOPIC_ID%3D295 - hvor en venlig sjæl har smidt et scop på en dataledning.

 

Stjernetopologien betyder også at der skal trækkes ekstra mange ledninger mellem controller og moduler.

 

Meget af det er historisk betinget. Da LK engang omkring 1980 fik et vink med en vognstang om at der var et alternativ til almindelige minitangent afbrydere, havde de meget travlt med at lave noget, som de umiddelbart ku’ forklare en elektriker hvordan virkede. Det var slemt nok, at der skulle programmeres, så når det nu skulle være, lagde man sig tæt op af PLC verdenen. Som en LK repræsentant replicerede, da jeg brokkede mig over det klumsy interface, og høfligt bemærkede, at det han brugte adskillige funktionsblokke til, kunne klares med nogle få linjer i c, ”Hvor mange elektrikere kender du, som kan programmere i c”?

Eller da en underviser på et af LK’s IHC kurser forklarede, at ”AND” var loddeabe sprog for en serieforbindelse.

Jeg tror, at et MEGET konservativt fag, - og nogle tilsvarende konservative marketingsfolk/sælgere – har tvunget LK’ udviklere til at lave stærkt simplificeret koncept, som stadigvæk plager konceptet.

 

Tilbage til gateway’en:

 

Jeg kan ikke se nogle større problemer i at lave en gateway. Den kan laves på samme måde som i IHC controlleren, hvor man bruger en håndfuld billige microcontrollere til at skrive til udgangsmodulerne, og læse fra indgangsmodulerne.

Men jeg tror hurtigt man løber ind i problemer med timing. En gateway vil nødvendigvis indføre latency. IHC er interrupt styret. Du generer et interrupt, når du trykker på en knap, eller når du passeret et internt setpunkt. Setpunktet er internt i controlleren, og passerer således aldrig gatewayen. Men det gør trykknappen. Der foregår noget debounce i inputmodulet, hvilket tager tid – sikkert i størrelsen 20 – 30 ms. En gateway med en microcontroller til at håndtere hvert input modul skal også bruge tid. Med udgangspunk i mit oprindelige oplæg om en RS485 halv duplex protokol, så ender vi med at inputs reelt er pollede. Med et robust (konservativt?) design af RS 485 protokollen tager det nok yderligere 30 ms, afhængigt af hvor moduler der skal serviceres. Det vil sige latency omkring 60 ms, før beskeden overhovedet er nået ud på bussen. Derefter skal den læses af masteren, som skal forstå den, ta’ stilling til hvad der skal ske, og få det til at ske. Og når masteren har fået det til at ske, skal vi ud på bussen igen, og skrive til udgangsmodulet. Alt i alt er jeg bange for, at det hele ender på den forkerte side af 100 ms, hvilket betyder at systemet vil føles sløvt.

 

Elektronik er ikke særlig dyrt. Det er udvikling, garanti, godkendelser, overhead osv., som koster penge. Derfor tror jeg at en controller, som den jeg skitserede i mit oprindelige indlæg, kan laves så forholdsvis billig, at det er lige meget om de oprindelige inputmoduler kan bruges. Og det vil være simpelt at lave en gateway, som kan skrive til udgangsmoduler, for der er bestemt en pointe i at genbruge 230V relæmodulerne. Det forudsætter alt sammen, at ting sker i et open source miljø, og at andre deltager.

Jeg kan til enhver tid udvikle den nødvendige hardware og printlayout, men hvis software skal ud over noget forholdsvis simpelt, kræver det at folk med kendskab til (embedded) software udvikling deltager.

 

Per

 

Temic U605xB.pdf

[Lars1]

Hvis du ser på de teknologier og processor krafter der var tilgængelige i 1980, så var IHC faktisk meget avanceret, og protokollen mellem controlleren og I/O modulerne er faktisk med nutidens øjne simpel og effektiv til det som I/O modulerne kan. Mere avancerede I/O moduler bliver koblet på via RS485 bussen, via wireless protokollen eller via netværks API'et.

 

Hvis jeg skulle lave en GW idag, ville jeg gøre det via netværks API'et. Jeg mener også det er den måde som både B&O og Visility boardet (http://www.visility.com/) kommuniker. Såvidt jeg har forstået, så kan et Genvex ventilations anlæg idag styres fra IHC, via Visility boardet, og på en langt mere effektiv og professionel måden end LK's amatør agtige Nilan implementering.

[Dan Nielsen_30707077]

Døde projektet? Kun være så fedt hvis man kunne bruge IHC moduler med SomeSeer.