Nikolaj_K

Hej Jesper, Pin 2-3 på CON1 på Nilan printet er A/B, dvs. de databærende signaler i RS485-bussen. Så hvis Vislity/LK's PLC kobler på disse ben, og kobler betjeningspanelet på sig selv, så er det fordi de laver en proxy for at komme uden om 1-master-only problematikken. Når du kommer dertil så prøv at læse de protokol analyser igennem jeg har lavet længere oppe i tråden... det skulle nok få dig hurtigere i gang :-) Læg iøvrigt mærke til den del hvor jeg fortæller om hvordan betjeningspanelet og anlæget kommunikerer. Anlæget sender sine svar i form af skærmbilleder, således at betjeningspanelet udelukkende fungerer som en framebuffer... det er en lidt anderledes (klodset imho) dataudveksling end jeg er vant til at se. Hvis du vil lave løsningen med en indskudt proxy så husk at du skal have 2x USB-RS485 convertere, eller brug de 10$ det koster at få produceret et lille PCB til det som kan kobles direkte på BeagleBones headere. /Nikolaj

Hej Jesper, Der skal skabes en forbindelse mellem 2 inputs på Nilans styreprint. Du kan se hvilke på det medfølgende diagram fra Nilan. Når forbindelsen skabes bliver funktionen "Brugervalg" aktiveret. Hvad selve brugervalg funktionen skal udføre sættes op i forvejen via betjeningspanelet. /Nikolaj

Siden jeg skrev ovenstående indlæg har jeg implementeret en anden løsning, da der var flere ting der irriterede mig. 1) Idet protokollen mellem Nilan anlæget og vægbetjeningen er Modbus RTU som pr. definition er et master-slave forhold med max 1 master, er det ikke lige til at sætte en Beaglebone (eller andet embedded udstyr) ind som en ekstra master. Det kan dog lade sig gøre hvis man sørger for at Beaglebone ikke bruger bussen når vægbetjeningen taler med anlæget (hvilket den gør et par gange i sekundet). Alternativt kan man sætte Beaglebone ind mellem vægbetjeningen og anlæget og lade Beaglebone fungere som en proxy der sørger for at der ikke kommer kollisioner. 2) Så vidt jeg kunne analysere mig frem ved at dumpe registrene, virkede det som om man er begrænset til at sætte en PWM værdi til at styre motorerne direkte, hvilket jeg ikke bryder mig om da jeg ikke ved om man så bypasser noget funktionalitet inde i anlæget. Jeg ville foretrække om man istedet kunne sætte motorhastigherne som 1-4 ligesom via vægbetjeningen. Istedet fandt jeg ud af at jeg egentlig kun har brug for at køre anlæget på 2 hastigheder: 2 (=normal hastighed), og 4(= højeste hastighed). Derfor har jeg lavet et lille print med en MCU, et relæ og en sensor til at måle luftfugtigheden i badeværelset. Hvis den bliver for høj, trækker MCU'en relæet og Nilan sætter hastigheden op indtil luftfugtigheden er normaliseret. Desuden kan jeg via et serielt interface mellem MCU'en og min Linux box, dels holde øje med luftfugtigheden, forcere en tilstand, indstille tærskelværdier, og programmere en ugeplan. Jeg har endnu ikke interfacet det via openhab (mangler timer i døgnet) men det kommer nok en dag hvor jeg får tid... som det er lige nu kører det fint af sig selv :-) God fornøjelse med projektet. /Nikolaj

Hej igen, Hermed registerdump. Jeg har dumpet registrene i pakker á 32 bytes (16 registre á 2 bytes). De pakker der udelukkende indeholdt 32 bytes med 0x00 har jeg udeladt. Payload er markeret med bold Reading Output Regs:Dump reg 00 to 0F: 03 03 20 00 10 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6F C8 Markeret med rødt = indblæsning/udblæsning. Skifter jeg mellem de 4 hastigheder ser jeg en ændring her. Om det dirkete en en værdi til PWM ved jeg ikke. Dump reg 100 to 10F: 03 03 20 00 00 00 00 00 01 00 00 00 66 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 98 32 Markeret med rødt = Display codepageMarkeret med grønt = SW version Dump reg 200 to 20F: 03 03 20 00 56 00 41 00 52 00 4D 00 45 00 20 00 20 00 20 00 00 00 00 00 3E 00 34 00 3C 00 20 00 32 00 30 76 64 Markeret med rødt = Ascii encoding af display: "varme \n<4> 20" Dump reg 210 to 21F: 03 03 20 00 DF 00 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6A F8 Markeret med rødt = Ascii encoding af display: "*c" Reading Input regs:Dump reg 00 to 0F: 03 04 20 00 00 00 00 00 1D 00 C2 00 00 00 00 00 34 00 F5 00 00 00 60 00 00 00 00 00 00 00 00 00 1C 00 00 F5 32 Markeret med rødt = temperaturværdier. Umiddelbart ser jeg ingen direkte sammenhæng mellem de målte værdier og temperaturen. Måske det bare er en A/D måling direkte fra NTC'erne? Sidste værdi (0x001C) repræsenterer måleværdien fra betjeningens temeraturføler. Dump reg 20 to 2F: 03 04 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F0 00 00 00 00 00 00 00 00 00 00 BA CB Markeret med rødt = A/D count fra betjening (temperatur). Bruges i beregningen af ovennævnte værdi fra betjening. Dump reg 100 to 10F: 03 04 20 00 00 00 00 00 02 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 63 Markeret med rødt = Reset årdag og status Dump reg 110 to 11F: 03 04 20 00 39 00 07 00 16 00 04 00 20 00 12 00 12 00 20 00 39 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2E C4 Markeret med rødt = Tidspunktet (16:07: 39 - 20/12/12 - 4=4.dag=torsdag) Som sagt ville jeg gerne styre ind/udblæsning samt læse temperatur. Jeg kunne forsøge at sætte hastigheden direkte (hvis det altså er PWM værdier), men jeg ved ikke om der er andet man skal tage højde for så man ikke roder i styringens tilstandsmaskine. Alternativet er at man laver ændringerne ved at navigere rundt i menusystemet ved at sende tastaturkommandoer til styringen og parser det returnerede skærmdump(har prøvet og det virker ok)... det er en lidt øv løsning, men det er måske den mindst invasive? /Nikolaj

Som jeg læser modbus standarden (og nu har jeg aldrig leget med PLC'ere så jeg har ingen domæneviden her), er input registre read-only, og Output registre (holding registre) er read/write, og det var mere dét der forvirrede mig. Jeg forventede at et inputregister var noget som masteren skrev til, og et output register var noget masteren læste fra, men jeg kan godt se at det ikke hænger sådan sammen. Så blev jeg så meget klogere :-) Nå, men lad os komme til sagen. Nedenfor er et udsnit af et dump af trafikken mellem betjeningspanelet og anlæget. Venste kolonne er antallet af microsekunder siden sidste transmission. Det ses således at der normalt er 20ms - 40ms mellem en request fra masteren til svaret er modtaget. Derefter går der ca 960-980 ms inden næste periodiske request bliver sendt fra masteren. 974883: 03 42 01 00 00 01 00 02 00 00 67 F530736: 03 42 02 00 00 05 00 0A 56 41 52 4D 45 20 20 20 00 00 1C FE976920: 03 42 00 2A 00 01 00 02 00 E8 27 BF27811: 03 42 02 0A 00 05 00 0A 3E 31 3C 20 32 30 DF 43 00 00 A1 A3 Dekodes pakkerne fås: 03 42 01 00 00 01 00 02 00 00 67 F5 03 Destination (3=anlæg) 42 CMD = _FC_WI_RO_REGS 01 00 Adresse = 0x0100 00 01 Antal registre 00 02 Antal bytes 00 00 Data (tastetryk ) 67 F5 CRC Svar 03 Destination (3=anlæg) 42 CMD = _FC_WI_RO_REGS 02 00 (adresse = display data) 00 05 Antal registre 00 0A Antal bytes 56 41 52 4D 45 20 20 20 00 00 (Ascii = Varme<spc><spc><spc>) 1C FE CRC 03 Destination (3=anlæg) 42 CMD = _FC_WI_RO_REGS00 2A (adresse = A/D count)00 01 Antal registre00 02 Antal bytes00 E8 A/D count (fra temp føler i betjening)27 BF CRC 03 Destination (3=anlæg) 42 CMD = _FC_WI_RO_REGS 02 0A (adresse = LCD linie 2)00 05 Antal registre00 0A Antal bytes3E 31 3C 20 32 30 DF 43 00 00 (Ascii = "<1> 20*C")A1 A3 Det ses at betjeningspanelet blot fungerer som en framebuffer. Betjeningspanelet har ingen tilstandsmaskine, og den modtager ikke konkrete dataværdier såsom temperatur og hastighed, men derimod komplette skærmbilleder fra anlæget. Når man så trykker på en knap sendes dette til anlæget og et nyt skærmbillede genereres og sendes til betjeningspanelet udfra viden om nuværende tilstand og det indkomne tastetryk. Næste post kommer jeg med registerdump. /Nikolaj

Det er desværre ikke lige til synes jeg. TXX-følerne står som input registre, og ikke output... det er det jeg studser over, men jeg har heller ikke sat mig ned for at læse modbus spec'en som Nilans implementation bygger over, så det kan være at jeg misforstår input/output begrebet. Nå, men jeg må igang med at hacke skidtet. Jeg skal nok melde tilbage hvis der sker nogen form for gennembrud :-) /Nikolaj

Jeps, bortset fra navneforvirringen i starten er vi er helt enige om master/slave forhold og om at systemet generelt følger ModBus RTU. Nej, ikke endnu. Intil videre parser jeg bare beskederne efter bedste evne... jeg synes der mangler lidt i den sparsomme info fra Nilan til at få et helt klart billede. Dog modtager jeg fint de informationer som sendes til skærmen på betjeningspanelet, og også de tastetryk der sendes til anlæget. Ja, hvis betjeningspanelet ikke er koblet på er der ingen problemer i at sende kommadoer... og hvis man venter til slave responset er modtaget af betjeningspanelet så har man ca 900 ms inden betjeningspanelet sender en ny request. Jeg ved dog ikke om betjeningspanelet aktivt styrer bussen i pausen , således at denne og master nr 2 sætter output mod output, men det må jeg jo prøve af (og det var derfor jeg ville sætte en embedded enhed ind som proxy) Jeg har lavet min RPI om til en SousVide controller, så jeg havde planlagt at bruge min BeagleBone. Den styrer i forvejen min alarm, og kører openHab som igen taler med IHC. På den måde er det også let at lave et webinterface til at styre Nilan'en. Det jeg gerne vil opnå er at styre ind/udblæsning, samt at få info fra følerne i anlæget. Jeg synes ikke det fremgår i hvilke registre de ligger i Nilans dokumentation. Jeg overvejer at lave en scanningsroutine der prøver alle registre af - det kan være man kan være heldig at se et mønster i registermap'et. /Nikolaj

Jeg troede egentlig at CTS600 var navnet på selve betjeningspanelet, men som jeg kan forstå så er det betegnelsen for styringen i selve anlæget? Vi er i hvert fald enige om at betjeningspanelet er master og anlæget er slave. Jeg har dumpet trafikken mellem betjeningspanelet og anlæget, og det viser at betjeningspanelet poller anlæget periodisk (hvert sekund), og sender tastetryk on-demand. Anlæget returnerer med bl.a. komplette genererede skærmbilleder til displayet. Så vidt jeg kan se er der er dog ikke 100% overensstemmelse med den udleverede protokol-spec fra Nilan - bl.a. passer antallet af bytes i typeWI_RO_REGS ikke helt. Grunden til at jeg ville lave en proxy og bruge multiple mastere er at jeg ønsker at bibeholde betjeningspanelet, samtidig med at jeg kan styre indblæsning/udsugning via et embedded board som jo også ville være en master. /Nikolaj

Hej, Jeg ved det er et gammelt emne, men jeg ville lige høre om der var andre der havde givet sig i kast med det. Så vidt jeg ved kører betjeningen (CTS600) og styreenheden (placeret i selve anlæget) i ModBus Master/slave, hvor det er CTS600 der er master og styreenheden der er slave. Idet der på serial Modbus kun kan være _en_ master, kan jeg ikke umiddelbart se hvordan man kan sætte flere betjeningspaneler på uden samtidig at udvikle en enhed der sidder mellem styreenheden og betjeningsenhederne som proxy med det formål at opsamle requests og sætte disse i kø så der ikke kommer buskollisioner. Rent programmeringsteknisk kunne man nok komme omkring det med kollisionerne da der er automatisk retransmission indbygget i protokollen, men jeg tænker at der vil være problemer rent elektrisk med 2 mastere der tilgår bussen samtidig hvis der ikke er en proxyenhed imellem? /Nikolaj