modbus (rs485) ongelmia

[kurre orava]

Olen tuossa pidemmän ajan koittanut naittaa Vexven AM40 lämmönsäätöyksikkö muuhun kotiautomatioon, siinä kuitenkaan onnistumatta.

Olen yrittänyt etupäässä OpenHab:ssa ja mielestäni kaikki ohjelmalliset palikat ja sidokset löytyvät tuolla nyt. Mutta dataa en saa näkymään. Koitin myös Home Assistantissa vastaavaa temppua, yhtä laihoin tuloksin.

Sain Vexven propelliosastolta modbusrekisterit ja väyläliitännässä käytettävät pinnit. Heidän mukaan tuota pitäisi ajaa 38400 baud:n nopeudella, 8bit, non parity ja 1 stopbit. Kun kokeilen 38400 nopeudella en saa oikeastaan mitään järkevää näkyviin Puttyssa jos katson liikennettä suoraan muuntimesta. Nopeuden kun tiputtaa 9600 niin tulee jo jotain tolkkua mutta ei mitään mistä saisi tuloksia.

Olen ajanut tuota hyvin lyhyellä välikaapelilla väyläliitännän ja muuntimen välillä, kokeilin tuohon myös parikaapelia ja vastusterminointia väylän päähän mutta tulokset eivät juurikaan tuosta parantuneet.

Foorumilla kun on monenlaista tietäjää ja muutama aktiivinen modbus käyttäjäkin niin neuvot otetaan kiitollisuudella vastaan, mistä rupean etsimään parannuksia tilanteeseen? Voiko olla esimerkiksi maapotentiaalin eroista johtuva ongelma? Vai onko kyseessä kuitenkin ristiriita järjestelmän eri osien välillä.

Liitteenä kuva miltä tuo Putty:n vastaanotto näyttää 9600:lla. Jos ajan vaikkapa 38,4 niin tulee lähinnä vaan noita "viivallisia" neliöitä pitkä rivi mitkä tuossa alla ovat merkkien välissä.

 

[TopiR]

Ensimmäinen selvitys, tiedätkö onko kyseessä modbus Ascii vaiko modbus RTU?

-Topi

 

[TopiR]

Onko sulla oskilloskooppia käytössä, sillä näkisi helpohkosti mikä on bitttinopeus?

-Topi

 

[kurre orava]

On modbus RTU. Ei ole omaa oskilloskooppia mutta saan kyllä lainattua sellaisen.

Muoks: viestittelin vielä Vexven tuen kanssa ja sain heiltä hiukan kuvakaappauksia siitä kun olivat itse tehneet vastaavaa. Niisä oli kyllä tuota 38,4 kbps käytetty. Kai siinä väylällä täytyy olla kaikilla laitteilla sama nopeus?

 

[jmaja]

Ei RTU:n pidä näyttääkään järkevältä ASCII-muotoisena.

 

[kurre orava]

Ei RTU:n pidä näyttääkään järkevältä ASCII-muotoisena.

Eli eikö tuota siis pystykään terminaaliohjelmalla monitoroimaan?

Lähinnä koitan haarukoida sitä onko minun ongelmani softassa ja asetuksissa vai onko väylän ulosannissa joku perustavanlainen vika. Ja kuvittelin et esim Puttylla olisi voinut katsoa miltä tuo väylän liikenne näyttää. Joskus laivapuolella kun puuhasin enemmän NMEA väyläpohjaisten laitteiden kanssa niin niissä se onnistui ongelmitta ainakin vanhan 0183 vNMEA:n osalta.

 

[jmaja]

Eli eikö tuota siis pystykään terminaaliohjelmalla monitoroimaan?

Lähinnä koitan haarukoida sitä onko minun ongelmani softassa ja asetuksissa vai onko väylän ulosannissa joku perustavanlainen vika. Ja kuvittelin et esim Puttylla olisi voinut katsoa miltä tuo väylän liikenne näyttää. Joskus laivapuolella kun puuhasin enemmän NMEA väyläpohjaisten laitteiden kanssa niin niissä se onnistui ongelmitta ainakin vanhan 0183 vNMEA:n osalta.

Pystyy HEX-moodissa. Eli sitten sinun pitää tulkita noita. Varmasti löytyy joku softa, joka tulkkaa HEX:t MODBUS RTU:na.

0183 NMEA on ihan puhdasta ASCIIta. Sitten kun mennään mittaristojen muuhun kommunikointiin tai NMEA 2000 ei enää ASCIIta ole. ASCII on tolkuttoman hidas kun numerotieto 123 vaatii kolme tavua, kun saman saa sanottua binaarinä yhdellä. Liukuluvuissa ja suuremmissa kokonaisluvuissa ero on vielä paljon suurempi.

 

[jmaja]

Siis otat HEXää talteen ja sitten alat tulkita. Tässä on kerrottu paketin sisältö: https://www.rfwireless-world.com/Terminology/Modbus-message-frame.html

Kun kerran tiedät osoitteet, pitäisi niitä vastaavia lukuja tulla tasaisin välein, jos sellaista tuolla kulkee.

 

[jmaja]

Tuossa väänntetty aika rautalangasta:

Modbus RTU made simple with detailed descriptions and examples

From this article you will learn more about the Modbus RTU protocol, which is widely used in the process control system.

ipc2u.com

 

[kurre orava]

Tuossa väänntetty aika rautalangasta:

Modbus RTU made simple with detailed descriptions and examples

From this article you will learn more about the Modbus RTU protocol, which is widely used in the process control system.

ipc2u.com

Joo, opiskelin tuolta sivulta jo aiemmin, on ihan hyvin esitetty tuolla.

Lähinnä sitä mietin kun tuon näkyvän datan joukosta tulee noita "viivallisia neliöitä" että onko sinä kohden sitten data korruptoitunut jotenkin? Vai mistä nuo johtuvat.

Kokemattoman silmissä nuo tekstit näyttävt kyllä jonkinlaiselta heksadata:lta josta puuttuu palikoita välistä.

Mutta jos tallennan tuolla 38,4kbps mitä tuki neuvoi käyttämään niin saan lähinnä vain noita "viivallisia laatikoita".

 

[puuteknikko]

ASCIIn perusteella et pysty tekemään tulkintaa siitä, onko se korruptoitunutta dataa. Pystyisitkö lukaisemaan rekisterit vaikka jollain pienellä Python-moduulilla kuten https://github.com/riptideio/pymodbus?

 

[BBF]

Onko se RS485 tehty fyysisesti järkevästi ja terminoitu oikein? Pelkästään väärä terminointi voi korruptoida datan.

 

[Arnold]

Ja maadoitus kunnossa?
Tuli vain mieleeni kun viimeksi labrasin EC-puhallinmoottoria pöydällä "kelluvana", ei tullut tolkullista dataa ennen kuin kytki sen suojamaajohtimen.

 

[jmaja]

Noilla nopeuksilla ei terminointia tarvita, ellei kaapeli ole todella pitkä, Eikä maadoituskaan ole ongelma yleensä, mutta voi toki olla.

ASCIIssa on vain 127 merkkiä ja jokainen tavu voi olla 0-255. Eli kaikki 128-255 alueelle sattuvat tulevat terminaalissa joksikin kummalliseksi. Noista 0-127:stäkin vain 32-127 ovat näkyviä merkkejä eli kirjaimia, numeroita ja erikoismerkkejä.

Sitten taitaa terminaalit ottaa kyttyrää ASCII-moodissa joistain tavuista tai niiden yhdistelmistä. Eli kovin vaikeaksi menee ASCIIna tuon lukeminen.

En tiedä saako tuota HEX-moodiin, mutta käyttämäni Tera termin saa (debug modella).

 

[kurre orava]

Onko se RS485 tehty fyysisesti järkevästi ja terminoitu oikein? Pelkästään väärä terminointi voi korruptoida datan.

Olen koittanut terminoituna ja ilman päätevastusta, tulos on jokseenkin yhtä laiha molemmissa tapauksissa.

Ja maadoitus kunnossa?
Tuli vain mieleeni kun viimeksi labrasin EC-puhallinmoottoria pöydällä "kelluvana", ei tullut tolkullista dataa ennen kuin kytki sen suojamaajohtimen.

Maadoitusta mietin minäkin. Mutta tiedä sit miten tuon järkevimmin toteuttaisi. Väyläliittimestä tulee johtimet A, B ja GND. Olen koittanut sekä GND kytkemättä (toisesta päästä tai kummastakin) ja kytkettynä. Vexvessä liitinpaikka on rj12 liittimelle ja kun minulla ei ollut tyhjiä tuollaisia mitä olisin voinut puristaa niin otin lyhyen, noin 30 senttisen pätkän valmiista kaapelista jota kytkin sit sarjamuuntimeen. Tuo kaapeli ei luonnollisesti ole parikaapelia saati suojattua.

 

[jmaja]

Kaapelilla ei ole mitään merkitystä noilla nopeuksilla ja pituuksilla. Sitten eri juttu kun puhutaan 100+m tai reilusti yli 100 kHz. RS485 kulkee ihan missä vaan.

Mutta tuo maadoitus tietysti voi olla ongelma. Ensin kuitenkin selvittäisin onko ongelmaa eli tuleeko sieltä nyt sitä RTU:ta vai jotain satunnaista.

RS485:n maadoitus on hyvin mielipiteitä jakava juttu. Periaatteessa pitää olla maat yhdessä, mutta silloin on ainakin toisen pään syytä olla kelluva. Onko tuo galvaanisesti erotettu? Jos ei läppäri, ilman virtalähdettä nyt ainakin on kelluva.

MODBUS ei ole tavallinen RS485, mutta on sen kanssa pitkälti yhteensopiva. MODBUSissa ei ole maadoitusta, mutta siinä on varsin voimakkaat ylös- ja alasvedot. Ne hoitavat käytännössä saman asian eli keskittävät jännitteen. Sehän on myös tuon maapiuhan tehtävä.

RS485:hän on symmetrinen eli A:n ja B:n välillä on välillä positiivinen ja välillä negatiivinen jännite. Ongelmia tulee, jos absoluuttinen jännite, siis RS485-piirin maa vs. A tai B menee yli sen toiminta-alueen. Tähän tarvitaan se maa, joka nollaa jännite-eron kahden laitteen välillä. Toimiakseen pitää toisen olla kelluva. Yleensä toimii hienosti ilman maata ja usein neuvotaan jättämään maa pois, koska siitä tulee enemmän haittaa kuin hyötyä.

Kyse ei ole siis häiriösuojauksesta, mikä ei yleensä ole ongelma noilla taajuuksilla.

 

[BBF]

Niin Modbus RTU on protokolla ja RS485 on sarjaliikenneväylä, ei ne sen kummemmin ole naimisissa, Modbus kulkee missä sarjaliikenteessä vaan tai Ethernetissä (Modbus/TCP), mikä olisi se paras vaihtoehto. Kaikki sarjaliikenteet vois jo heittää historian romukoppaan, ne on ainaista tappelua...

 

[roots]

Kaikki sarjaliikenteet vois jo heittää historian romukoppaan, ne on ainaista tappelua...

Luulisi nykypäivänä olevan kalliimpaakin laitella noita sarjaliikkujia kuin TCP ja lisäksi Masteritkin enimmäkseen nykyään varmaan TCP kykeneviä suoraan.

 

[mimique]

Jotkut Modbus RTU/RS-485 -laitteet tuntuvat vaativan bias-vastukset A ja B -letkuihin (https://know.innon.com/bias-termination-rs485-network). Esim. minulla on IME:n IF4C001 S0-pulssilaskuri (https://www.imeitaly.com/en/note-tecniche/if4c001/) kWh-mittarien pulsseja laskemassa. Se antoi sekavia tuloksia kunnes biasoin RS-485 linjat 390 ohmin vastuksilla maihin ja +5-volttiin.

Olen käyttänyt In-Circuitin RS-485 -palikkaa (https://shop.in-circuit.de/product_info.php?cPath=0_92_91&products_id=341) jossa voi DIP-kytkimillä asettaa terminoinnin ja biasoinnit halutessa. Näitähän on toki samanlaisia ja halvempia pilvin pimein.

Yksi näppärä softa Modbus-viestien analysointiin, tai Masteriksi on ollut https://sourceforge.net/projects/qmodmaster/

 

[kurre orava]

Niin Modbus RTU on protokolla ja RS485 on sarjaliikenneväylä, ei ne sen kummemmin ole naimisissa, Modbus kulkee missä sarjaliikenteessä vaan tai Ethernetissä (Modbus/TCP), mikä olisi se paras vaihtoehto. Kaikki sarjaliikenteet vois jo heittää historian romukoppaan, ne on ainaista tappelua...

Olen samaa mieltä mutta tuon Vexven osalta ei ole juurikaan vaihtoehtoja. Järjestelmän palikat keskustelevat keskenään modbus: lla ja väylänä on tuors485. Muita vaihtoehtoisia ei vaan ole. Eikä todennäköisesti ole ollut tarkoitus että loppukäyttäjä kytkeytyisi tuohon väylään ylipäätään.

Sinänsä mietin josko tuota keskusyksikön ja huoneyksikön välistä radioliikennettä pystyisi hyödyntämään. Siitä on tosin vielä vähemmän tietoa, toimii 868MHz alueella mutta muuta en ole tuosta löytänyt. Ja yleensä tuo langallinen on aina helpompi jos siihen vaan pääsee kiinni.

Täytyy koittaa millaista tulosta tulee jos tuohon laittaisi nuo ylösvetovastukset.

 

[siwer]

Jos ajatus "korruptoitumisesta" on peräisin siitä että Puttyssä näkyy neliöitä niin ajatus on väärä. Modbus RTU ei ole tekstiä vaan binääridataa.

Eiköhän se väylä toimi ihan oikein, ei siitä vaan saa ASCIIna mitään irti. Tulee kaikenlaisia hassuja merkkejä, neliöitä ja piippauksia ym.

Helpoin tapa edetä olis varmaan ottaa joku MODBUS-kirjasto haluamalleen kielelle (esim. Python) ja kirjoittaa pieni koodinpätkä joka näyttää halutun datan halutussa muodossa.

 

[BBF]

Millanen se muunnin on jolla liityt väylään? RS485/USB tms? Ja kuten jo tuolla aikaisemmin on todettu, RTU siirtää datan binäärisenä, ei siitä ASCII terminaalilla mitään lukukelpoista saa ulos.

 

[kurre orava]

Jos ajatus "korruptoitumisesta" on peräisin siitä että Puttyssä näkyy neliöitä niin ajatus on väärä. Modbus RTU ei ole tekstiä vaan binääridataa.

Eiköhän se väylä toimi ihan oikein, ei siitä vaan saa ASCIIna mitään irti. Tulee kaikenlaisia hassuja merkkejä, neliöitä ja piippauksia ym.

Helpoin tapa edetä olis varmaan ottaa joku MODBUS-kirjasto haluamalleen kielelle (esim. Python) ja kirjoittaa pieni koodinpätkä joka näyttää halutun datan halutussa muodossa.

Näinhän se asia varmaan onkin. Mutta silti en saa merkintöjä kun epäonnistuneista luennoista tuohon OpenHab:iin. Eli jossain kohtaa minulla tuo homma failaa.

Millanen se muunnin on jolla liityt väylään? RS485/USB tms? Ja kuten jo tuolla aikaisemmin on todettu, RTU siirtää datan binäärisenä, ei siitä ASCII terminaalilla mitään lukukelpoista saa ulos.

Olen käyttänyt tuollaista:

2-CH RS485 HAT - Waveshare Wiki

www.waveshare.com

Mutta tuon ja GPIO:n kanssa oli muitakin ongelmia, herjasi välillä oikeuksien puuttumista niin olen etupäässä yrittänyt tuollaisella:

USB TO RS232/485/TTL - Waveshare Wiki

www.waveshare.com

Muoks: Olisin mieluusti ollut käyttämättä tuota USB väylää kun minulla on jo Nibe yhdellä USB muuntimella kiinni raspissa ja kahdella niin sekoilua tulee helposti käynnistettäessä.

 

[siwer]

Display Hex in PuTTY for Serial

Does anyone know if there is a way to get PuTTY to show the hex values of what it's receiving over a serial connection instead of characters?

superuser.com

Tuon vinkin avulla tallennat Puttystä datan ja sitten lataat minkä vaan heksaeditorin ja tutkit dataa "käsin". Modbus on onneksi aika yksinkertainen protokolla.

Jos tällä saisit vinkkiä siitä miksi OpenHab ei ymmärrä dataa.

 

[pelzi_]

Tietysti biasointi pitää olla yhdessä paikkaa väylää ja terminointi päissä, mutta terminointi ei ole lyhyissä pakollinen. Biasointi on, muuten tulee hyvinkin puppua.

RS485 toimii erinomaisen hyvin, mutta väärin tehtynä ei toimi mikään.

 

[kurre orava]

Tietysti biasointi pitää olla yhdessä paikkaa väylää ja terminointi päissä, mutta terminointi ei ole lyhyissä pakollinen. Biasointi on, muuten tulee hyvinkin puppua.

RS485 toimii erinomaisen hyvin, mutta väärin tehtynä ei toimi mikään.

Kaiken voi tietty aina ryssiä kun tarpeeksi huolimattomasti ja huonosti tekee. Mutta tuntuu tuo olevan kuitenkin aika yksilöllistä tai vähintäänkin tuurista kiinni. Nibe on kiinni rasp:ssa myös rs485 väylällä USB muuntimen kautta ja kyseessä vielä halpa versio ilman galvaanista erotusta tms. Kaapelina tavallinen, one wire verkoissa yleisesti käytetty suojaamaton kolmijohtiminen suora piuha. Ja lähti laakista toimimaan ja on toiminut todella varmasti poislukien itse aiheutettuja katkoksia..

Mutta joo, kokeilen biasoinnilla ensi kädessä, katsotaan onko siitä apua tähän ongelmaan.

 

[pelzi_]

Niin, se on tuurista kiinni onko jossain vehkeessä oletuksena biasointi vai ei. Ei se ole RS485:n vika.

 

[jahonen]

Tuossa kyseisessä RS-485-lankussa näyttää olevan transceiverinä SP3485, joka pärjää kyllä ilman mitään ulkoista biasta ja tuottaa '1'-tilan vastaanotossa (sarjaportin "idle" logiikkatasoisena) vaikka mikään laite ei puhuisikaan langalle:

The SP3485 receiver has differential inputs with an input sensitivity of ±200mV. Input impedance of the receiver is 12kΩ minimum. A wide common mode range of -7V to 12V allows for large ground potential differences between systems. The receiver is equipped with a fail-safe feature that guarantees the receiver output will be in a HIGH state when the input is left unconnected. The receiver of the SP3485 operates up to 10Mbps.

Softana kokeilisin Puttyn sijaan RealTermiä (https://sourceforge.net/projects/realterm/), joka osaa näytää heksaa lennosta.

t. Janne

 

[olli_tr]

Sulla lienee koneessa kiinni joku USB-RS485 sovitin, kuten vaikkapa tällainen: https://www.amazon.com/JBtek-Converter-Adapter-ch340T-Supported/dp/B00NKAJGZM ?

Sitten tarvitsisit jonkun softan, joka osaa ModBUS-RTU:ta kommunikoida. En osaa sanoa Windowsille jotain sopivaa, kun itse olen Linuxin puolella tuota käyttänyt. Mulla on siis Swegonin ilmanvaihtokone, jossa on modbus-palikka, jota nykyisellään luetaan tuollaisella yksinkertaisella skriptillä ja USB-sovittimella. Tarkoitus olisi vaihtaa tuo ratkaisu ESP8266-palikaksi, joka lukisi Modbus-dataa ja lähettäisi sen WiFin yli MQTT-välittäjälle.

 

[pjr]

Jos en ihan väärin muista niin ite taisin käyttää tuon Amitimen pumpun modbus-testailuun QModMaster -nimistä softaa.

 

[kurre orava]

Sulla lienee koneessa kiinni joku USB-RS485 sovitin, kuten vaikkapa tällainen: https://www.amazon.com/JBtek-Converter-Adapter-ch340T-Supported/dp/B00NKAJGZM ?

Sitten tarvitsisit jonkun softan, joka osaa ModBUS-RTU:ta kommunikoida. En osaa sanoa Windowsille jotain sopivaa, kun itse olen Linuxin puolella tuota käyttänyt. Mulla on siis Swegonin ilmanvaihtokone, jossa on modbus-palikka, jota nykyisellään luetaan tuollaisella yksinkertaisella skriptillä ja USB-sovittimella. Tarkoitus olisi vaihtaa tuo ratkaisu ESP8266-palikaksi, joka lukisi Modbus-dataa ja lähettäisi sen WiFin yli MQTT-välittäjälle.

Joo, olen käyttänyt tuota useallakin eri sovittimella mutta toistaiseksi tuloksetta. Väylällä on kyllä liikennettä mutta palikat eivät loksahda vielä kohdalleen jotta tuon saisi järkevästi luettua. Sinänänsä sekä HomeAssistant että OpenHab käsittääkseni tukevat ja lukevat sekä tulkitsevat Modbus RTU:ta kunhan niissä on nuo Modbus lisäosat ladattu.

Nyt sain lainaksi Modbus RTU / Modbus TCP muuntimen josta selaimen kautta näkee väylän liikenteen reaaliaikaisena. En ole vaan kunnolla kerennyt tuota vielä kokeilla, kelit kun ovat olleet lauhoja niin olen tehnyt vielä hiukan perusparannuksia patteriverkkoon.

Mutta kunhan on hiukan aikaa niin teen uuden yrityksen tuon suhteen, tarve olisi kova saada nuo shuntin arvot mukaan kokonaisuuteen.

 

[HotZone]

Itse törmäsin hassuun juttuun ABB kWh mittarin kanssa. Sen A ja B on merkattu väärin päin.

Jos on itsellä tai tutulla yhtään arduinokokemusta niin tota väylää voi "vakoilla" helposti.
Se on perus sarjaliikennettä. Ite tein pienen koodin pätkän mikä avaa ModBus sanomaa sen verran että sain tutkittua mitä kahden laitteen välillä tapahtuu oikeasti. En siis käyttänyt tuohon mitään Modbus kirjastoa vaan vain RS485-kirjastoa ja sitäkin vain lukemiseen. Toki pitää olla RS485 sovitin välissä koska RS485 on differentiaalinen väylä jonka jännitteet aivan jotain muuta kuin 3.3V tai 5V TTL-serial.

Laitteen datalehteen kannattaa tutustua. Sieltä selviää registerit. Ilmeisesti aloittajan laite tomii orjana. Mastereitahan ei voi olla kuin yksi eli se oma viritelmä.

 

[kurre orava]

Laitteen datalehteen kannattaa tutustua. Sieltä selviää registerit. Ilmeisesti aloittajan laite tomii orjana. Mastereitahan ei voi olla kuin yksi eli se oma viritelmä.

Tätä asiaa mietin kokemattomana modbuksen suhteen. Tuo Vexven AM40.han on tuossa järjestelmässä ikään kun masterina ja käskyttää noita shunttiventtiilejä sekä keskustelee sisäyksikön kanssa ja saadun palautteen ja ulkolämpötilan perusteella säätelee sit noita shuntteja. Tuon Vexven keskusyksikön voi kyllä laittaa orjaksi mutta tuntuu että silloin lakkaa järjestelmä toimimasta.

Se mitä haen on järjestely jossa voisi ikään kun vakoilla liikennettä väylällä ja poimia nuo halutut rekisterit liikenteen seasta. Noi shuntithan ei käänny kovinkaan nopeasti joten vaikkei tulisi kun päivitys 5-10 minuutissa niin sekin riiittää mainiosti.

Sain tuon rtu/tcp purkin kytkettyä ja totesin et jotain liikennettä tuolla on mutta en vielä sen koommin tuota tutkinut kun on ollut muita kiireitä.

 

[kurre orava]

Tutkin hiukan tuota liikennettä väylällä, Atop:ista saa nettiselaimessa ulos aika paljon tietoa. Liikennettä on molempiin suuntiin, purkki kyselee noita input rekistereitä (0x04) ja väylällä näkyy kyllä vastaus heti perään mutta se tulee kuitenkin (0x84) statuksella mikä taisi olla joku poikkeamailmoitus. Selkeästihän noissa vastausviesteissä on vaan 5 bytea kun normaalisti on 8. Muoks: Tai vastauksissa on 3 bytea normaalin 5 sijaan. Ja alussa jo tuo poikkeama osoitteessa joka antaa tuo 0x84 0x04 sijaan.

Openhab herjaakin tähän suuntaan:

COMMUNICATION_ERROR
Error with read: org.openhab.core.io.transport.modbus.internal.ModbusSlaveIOExceptionImpl: Modbus IO Error with cause=ModbusIOException, EOF=false, message='I/O exception: IOException CRC Error in received frame: 3 bytes: 01 04 00 ', cause2=null

Vexven antamilla asetuksilla 38,4kbps 8 N 1 nuo tulevat, olen kokeillut myös muita mutta niillä en saa tuonkaan vertaa väylältä ulos.

Liitteenä listaus miltä tyypillinen loki näyttää:

Olen noita nyt pikku hiljaa puljannut mutta rupeaa keinot loppumaan kesken, oma osaaminen loppui jo aikoja sitten. Sitä tuossa mietin että onkohan tuo ilmiö jossa vastausviesti on vajavaista merkki rauta- vai softaongelmista?

Jollei muuten onnistu niin täytyy vielä kokeilla RF liittimen kautta tuota samaa.

 

[mimique]

5 tavun mittainen vastausviesti on Modbus-protokollan mukainen, siinä on virhekoodi 0A (GATEWAY PATH UNAVAILABLE). Mutta kummallinen viesti on ajan hetkellä 14:29:11.240, se ei ole Modbus-standardin mukainen lainkaan. Millä kuuntelet Modbus-liikennettä? Arvelen että AM40 toimii väylällä Masterina, mutta tuo Atop (Gateway) toimii myös masterina, siksi tuo virhekoodi 0A ja ehkä molemmat puhuessaan väylälle aiheuttavat noita kummallisia kahden tavun viestejä. Sinun pitäisi vaan passiivisena nuuhkia liikennettä väylällä. Itse olen käyttänyt tuota ModbusMasteria (https://sourceforge.net/projects/qmodmaster/), siinä on passiivinen Monitor mode, mutta se ei osaa tulkita viestejä, näytää ne vaan hexana. Voisiko Atopin saada tilaan (ns. Modbus RTU Sniffer) jossa se vain seurailee liikennettä? Netistä löytyy avainsanalla "Modbus RTU Sniffer" muutama softa joista voisi olla apua.

 

[VesA]

Ei se ATOP välttämättä masterina ole mitään itse lähettänyt, paisti ehkä noita 84vastauksia - mistäs se olsi ne viestit keksinyt, mutta jotenkin se pitäisi konffata - nyt tuo puuttuva PATH voi tarkoittaa ihan vaan että 'emmä tiedä mihin toi RS-485 modbus-masterin viesti on menossa. Kun kysessä on TCP sen pitäisi muodostaa yhteys kuhunkin sen TCP - puolen vehkeeseen jollain konstilla - sillä pitäisi olla joku lista että laite 4 on osoitteessa 192.168.1.4 tms. - nyt se näyttäisi oletuksena sanovan kaikkeen että emmävaanosaatollemitääntehdä. Snifferimoodi olisi paras, mutta ehkä olemattoman laitteen, esmes 252 konffaaminen ihan mihin vaan osoitteeseen riittää - ehkä se ei siitä mökötä. Pahimmassa tapauksessa se haluaa että sinne saa yhteyden ja kokeilee sitä samantien.

 

[kurre orava]

5 tavun mittainen vastausviesti on Modbus-protokollan mukainen, siinä on virhekoodi 0A (GATEWAY PATH UNAVAILABLE). Mutta kummallinen viesti on ajan hetkellä 14:29:11.240, se ei ole Modbus-standardin mukainen lainkaan. Millä kuuntelet Modbus-liikennettä? Arvelen että AM40 toimii väylällä Masterina, mutta tuo Atop (Gateway) toimii myös masterina, siksi tuo virhekoodi 0A ja ehkä molemmat puhuessaan väylälle aiheuttavat noita kummallisia kahden tavun viestejä. Sinun pitäisi vaan passiivisena nuuhkia liikennettä väylällä. Itse olen käyttänyt tuota ModbusMasteria (https://sourceforge.net/projects/qmodmaster/), siinä on passiivinen Monitor mode, mutta se ei osaa tulkita viestejä, näytää ne vaan hexana. Voisiko Atopin saada tilaan (ns. Modbus RTU Sniffer) jossa se vain seurailee liikennettä? Netistä löytyy avainsanalla "Modbus RTU Sniffer" muutama softa joista voisi olla apua.

Eli olen monitoroinut tuossa liikennettä Atop:in selainyhteyden kautta. Itsekin uskon että ongelmana tuossa on se jos väylälle tulee ikään kun kahta Masteria jolloin hommat menee sekaisin. Tuo Atop:han koostuu kahdesta osasta, TCP ja RS485 osiot. TCP:n täytyisi mielestäni olla slave asennossa jotta Openhab kertoo sille mitä rekistereitä sen kuuluu pollata. Ja RS485 osio pitäisi mielestäni myös olla slave jottei sotkisi tuota laitteen omaa väyläliikennettä. Käytännössä jos laitan asetukset noin niin liikennettä ei synny eli tuntuu ettei tuo osaa pelkästään ”vakoilla”. Mutta täytyy vielä yrittää. Vexveltä saatujen neuvojen mukaan tuohon EXT I/O liitäntään mihin olen nyt kytkeytynyt niin voisi kytkeytä Masterina eli onkohan siinä sit kuitenkin ihan oma, muusta väylästä erotettu osio? RF liitännän kautta pitäisi pystyä kykeytymään slave muodossa väylälle, tuota en ole vielä kokeillut kun sisäyksikkö tulee tuon kautta. Mutta kuulemma molemmat voi huoletta ajaa rinnan.

Ei se ATOP välttämättä masterina ole mitään itse lähettänyt, paisti ehkä noita 84vastauksia - mistäs se olsi ne viestit keksinyt, mutta jotenkin se pitäisi konffata - nyt tuo puuttuva PATH voi tarkoittaa ihan vaan että 'emmä tiedä mihin toi RS-485 modbus-masterin viesti on menossa. Kun kysessä on TCP sen pitäisi muodostaa yhteys kuhunkin sen TCP - puolen vehkeeseen jollain konstilla - sillä pitäisi olla joku lista että laite 4 on osoitteessa 192.168.1.4 tms. - nyt se näyttäisi oletuksena sanovan kaikkeen että emmävaanosaatollemitääntehdä. Snifferimoodi olisi paras, mutta ehkä olemattoman laitteen, esmes 252 konffaaminen ihan mihin vaan osoitteeseen riittää - ehkä se ei siitä mökötä. Pahimmassa tapauksessa se haluaa että sinne saa yhteyden ja kokeilee sitä samantien.

Openhabille on annettu Atopin ip numero ja portti. Openhabin dokumentaatiosta saan sen kuvan että tuo toimii nimenomaan masterina, kertoo väylälle mitä rekistereita pitää hakea ja milloin. Mutta kun laitan Atop:n TCP puolen slave:ksi niin alkaa yhteysongelmat. Atopille kerrotaan silloin masterina toimivan OH:n ip.

Todennäköisesti tässä on vaan kyse kokemattomuudesta ja osaamattomuudesta, rauta tuntuu kyllä toimivan mutta käyttäjä ei osaa conffata niitä oikein. Ja Vexven osalta dokumentaatiota ei hirveästi ole, rekisterikartta ja porttien pinnit, ei juuri muuta kun ei ole ilmeisesti ajateltu kuluttajan sorkittavaksi.

Mutta täytyy kokeilla vielä tuota RF liitäntää ja katsoa mitä sillä väylällä liikkuu.

 

[VesA]

Noilla gateway-vehkeillä voi rakentaa multimaster-setuppejakin - tutkin joskus senverran modbussin käyttöä että se jäi mieleen, mutta kuinka - en muista. Modbussissa on hiukan epämääräinen ajoitus - tavu kuuluu edelliseen viestiin jos välissä ei ole muutaman merkin pituista rakoa - joka toki sotkee vielä lisää. Sitä kuinka multimaster-setuppi voisi moisen väylän kanssa toimia ei voi kuin ihmetellä - ehkä kaikki masterit pitää kytkeä siihen gatewayhin joka sitten annostelee pyyntöjä slavepuolelle esiintyen ainoana masterina.

 

[kurre orava]

ATOP:ssa nuo asetukset saa kätevästi näppäiltyä selaimen kautta. Vielä kun Kurre tietäisi mitä asetuksia tuohon laittaisi niin avot. Mutta olen kokeillut eri variaatioina enkä toimivaa järjestelmää ole saanut vielä aikaiseksi.

Loogisesti ajatellen niin TCP puoli täytyisi olla slave jotta OH kertoo mitä haetaan ja milloin. Silloin tuohon Atopiin olen laittanut tuon OH:n IP:n. Mutta herjaa seuraa:

COMMUNICATION_ERROR
Error with read: org.openhab.core.io.transport.modbus.exception.ModbusConnectionException: Error connecting to endpoint ModbusIPSlaveEndpoint [address=192.168.212.211, port=952]

Minulla tuo OH on osoitteessa 192.168.212.190 ja olen tuossa lähinnä kokeilun vuoksi koittanut tehdä erillisen TCP:n kuvitellulle IP:lle. Sama herja tulee jos käytän tuota toista TCP:ta.

Ja RS485 puolellakin olen noita eri variaatioita kokeillut. Loogisesti tuon täytyisi olla Masterina jolloin kertoo Vexvelle mitä haetaan mutta tuleeko silloin tuo kahden masterin ongelma? Ja jos asetan slave:ksi niin vaikuttaa ettei osaa vakoilla tuota liikennettä.

Täytyy varmaan taas kirjoitella Vexven propellisosastolle, huokailevat jo valmiiksi kun näkevät et taas se yksi toro lähestyy...

 

[kurre orava]

Vai ajattelenko asiat yksinkertaisuudessani "väärin päin" eli asetetaanko tuohon gateway:n asetuksiin se onko linjan toisessa päässä master vai slave eikä se toimiiko gateway moisena?

Jos laitan nuo masterina niin saan liikennettä aikaiseksi mutta OH pysähtyy kuitenkin herjaan:
COMMUNICATION_ERROR
Error with read: org.openhab.core.io.transport.modbus.internal.ModbusSlaveErrorResponseExceptionImpl: Slave responded with error=10 (GATEWAY_PATH_UNVAVAILABLE)

Ja ilmeisesti tuo on juuri sama viesti mitä tuossa modbus liikenteessä oli mukana. Eli onko tuo nyt sen johdosta että väylällä on kaksi masteria. Laitoin Vexvelle kyselyn onko kaikki yksi ja samaa väylää vai onko ulospäin ikään kun omansa.