Linux + ModbusRTU

begin eens met het uitpluizen van modbus.

je stuurt een aantal bytes. je krijgt een aantal bytes terug.

klopt dit? wat stuur je, wat ontvang je?

(tip, het verwachtte aantal bytes staat zelfs in het foutbericht!)

modbus is ongelofelijk simpel, en het lijkt erop dat je niet de juiste data ontvangt.

n de code heb ik 1 ingevuld, maar ik weet niet zeker of ik daarmee het ID voor de RaspberryPi instel, of het ID van de energiemeter aangeef.

dit wordt ook snel duidelijk als je modbus snapt.

leesvoer:
http://www.simplymodbus.ca/FAQ.htm

mijn vraag is:
welke bytes vormen het antwoord, en is dit een geldig modbus bericht?

Progger, bedankt!

Modbus is zeer zeker nieuw voor mij.
Ga direct met je leesvoer aan de slag.

Als ik er (al dan niet op basis van deze suggestie) uit kom, dan plaats ik uiteraard de oplossing erbij.

Het eerste dat je moet uitvinden als je communicatie hebt is waar beide apparaten beginnen met tellen. Modbus is amerikaans en die beginnen traditioneel bij 1 met tellen. Dat betekend dat je dus nooit bij een adres 0 terecht kunt komen en dat in heel veel gevallen de adressering één geheugenadres verschuift.

Ik heb het leesvoer van Progger doorgenomen samen met de Modbus Application Protocol Specification.

Te versturen data
De opbouw van het Modbus bericht om één register uit te lezen is dus:
ID (1 byte), Functiecode (1 byte), Register start adres (2 bytes), Aantal uit te lezen registers (2 bytes), checksum

ID is de energiemeter, die heb ik ID 1 gegeven (0x01)

Op 17 maart 2020 15:29:23 schreef GJ_:
Het eerste dat je moet uitvinden als je communicatie hebt is waar beide apparaten beginnen met tellen. Modbus is amerikaans en die beginnen traditioneel bij 1 met tellen. Dat betekend dat je dus nooit bij een adres 0 terecht kunt komen en dat in heel veel gevallen de adressering één geheugenadres verschuift.

Ik heb adres 1 toegewezen aan de energiemeter. Dat heb ik ter controle nogmaals op het display uit te lezen.
Volgens de handleiding van de energiemeter kan het Modbus ID 001 t/m 247 zijn. (Zie eerste zin in §7.12, bovenaan pagina 18.) Inepro is een Nederlands bedrijf, maar het lijkt mij dat ze de telwijze van het Amerikaanse Modbus aanhouden en dus dat het tellen bij 1 begint, net zoals in de handleiding staat.
Of heb ik je bericht dan verkeerd begrepen, GJ_?

Functiecode = 3 (Read Holding Registers) (0x03)
Register start adres = 5002 = 0x138A (opgesplitst in twee bytes: 0x13 en 0x8A)
Aantal uit te lezen registers = 1 = 0x00/0x01

Het te versturen bericht zo ver is: 0x01/0x03/0x13/0x8A/0x00/0x01.

De CRC checksum heb ik berekend met de tool uit

Op 17 maart 2020 14:50:58 schreef Progger:
leesvoer:
http://www.simplymodbus.ca/FAQ.htm

Door bovenstaande 6 bytes in te vullen kom ik uit op een crc van 0xA1/0x64.

Het totale te verzenden bericht is dan: 0x01/0x03/0x13/0x8A/0x00/0x01/0xA1/0x64.
Dat klopt ook met wat er verzonden wordt. Dat lijkt dus goed te gaan. Al vindt ik dat de crc bytes gek getoond worden in de output: "\xa1d".

Te ontvangen data
Ik ga er voor nu vanuit dat de waarde in register 5002 (L1 Voltage) = 230,1V.

Volgens de protocol specification heeft de response dezelfde functiecode, gevolgd door een bytecount en de bijbehorende waarde(n). De bijbehorende waarden worden per register verdeeld over twee bytes

De functiecode is dan wederom 3 = 0x03.
Er wordt in dit geval maar één register uitgelezen, dus twee bytes met inhoud. De bytecount wordt dan 0x02.

In het bericht worden geen decimalen verzonden. 230,1 wordt dus 2301 = 0x08FD. Werderom wordt dit over twee bytes verdeeld: 0x08 en 0xFD.

Het bericht is dan: 0x03/0x02/0x08/0xFD
De checksum over een bericht van 4 bytes: 0x67/0xE1
Totale te ontvangen bericht: 0x03/0x02/0x08/0xFD/0x67/0xE1.
Edit: Voor het te ontvangen bericht staat natuurlijk nog wel het slaveID (0x01). Daarom wordt de CRC ook anders. Het te ontvangen bericht is dus: 0x01/0x03/0x02/0x08/0xFD/0x7E/0x05.

Conclusie
Het verzonden bericht lijkt goed. Het ontvangen bericht niet.
Het ontvangen bericht is allereerst te kort. Het systeem verwacht 7 bytes, ik kom uit op 6 bytes, maar ik ontvang er 5.
Edit: Ik kwam uit op 6 bytes omdat ik vergeten was het slave-ID voor het antwoord te zetten (0x01).

Ik denk dat het bericht dat ik ontvang onvolledig is. De checksum uit het ontvangen bericht (0x04/0x00) is namelijk niet de checksum die je verwacht bij een bericht van 0x00/0x01/0x81. Dan verwacht ik namelijk een checksum van 0xB0/0x30. Dat komt niet overeen met wat minimalmodbus verwacht, maar ik weet dan ook niet waar minimalmodbus dat op baseert. Minimalmodbus weet immers nog niet wat het antwoord gaat zijn.
Ik neem aan dat het zelf de checksum uitrekent over het ontvangen bericht, net zoals ik dat net heb gedaan.

Daarnaast vindt ik ook het begin van het ontvangen bericht niet logisch. Ik verwacht eerst dezelfde functiecode terug (0x03), maar die is in het hele bericht niet terug te vinden.
Ook de verwachtte inhoud van het register zie ik niet terug.

Mijn conclusie is dat de ontvangen data niet klopt. Dat is nu gelijk aan de conclusie van Progger.

Maar waarom klopt het ontvangen bericht dan niet?
Ik heb eerst de hardware aansluiting laten verifieren bij een oud collega van mijn stagebedrijf uit mijn tweede leerjaar. Zij werken immers veel met deze exacte energiemeters en modbus. De hardware klopt: de polen van de communicatie zijn juist aangesloten op zowel de meter als de USB-adapter. Ook de 120 Ohm eindweerstanden zijn aan beide kanten juist geplaatst. Helaas hebben zij geen ervaring met de minimalmodbus library, of überhaupt modbus via Linux. Dus zij konden mij helaas niet verder helpen.

De vraag die mij rest is dus: Hoe kom ik er achter waar het terugsturen van de info fout gaat?
Het is lastig te controleren of de energiemeter het bericht juist ontvangt/interpreteert. De enige communicatiemogelijkheid met de meter is namelijk Modbus . Dat maakt het ook lastig om te controleren of het antwoord juist verzonden wordt of niet.

Ik las wel dat sommige USB-adapters te maken hebben met echo. De minimalmodbus library kan daarmee omgaan als de USB-adapter dat zelf al niet doet. Ik kon niet vinden of mijn USB-adapter daar last van heeft, maar als ik de software dit laat doen komt er nogsteeds geen goed bericht terug.

Dank voor de moeite zo ver!

P.S. Als mijn toelichting te uitgebreid is, geef het aan. Ik geef graag zo veel mogelijk info omdat ik begrijp dat het op afstand lastig kan zijn om te kijken waar het fout gaat.

Je kan nooit te veel info geven !

Op 18 maart 2020 14:05:16 schreef GerritStof:col_V1_1b3.pdf"]Modbus Application Protocol Specification[/url].

Te versturen data
De opbouw van het Modbus bericht om één register uit te lezen is dus:
ID (1 byte), Functiecode (1 byte), Register start adres (2 bytes), Aantal uit te lezen registers (2 bytes),

...maar het lijkt mij dat ze de telwijze van het Amerikaanse Modbus aanhouden en dus dat het tellen bij 1 begint, net zoals in de handleiding staat.
Of heb ik je bericht dan verkeerd begrepen, GJ_?

Het tellen is voor ieder merk een eigen keus. Zelfs per type kan het verschillend zijn. Ik doelde overigens niet op het modbusadres maar het register start adres. Die willen nogal eens één verschoven zijn, dus die 0x138A uit jouw voorbeeld kan net zo goed 0x138B moeten zijn. Of 0x1380. Als je die adressen fout hebt krijg je ook onverwachte antwoorden.

Dit gelezen?
https://minimalmodbus.readthedocs.io/en/stable/modbusdetails.html#byte…

@GJ_
Aha, op die manier. Dat kan kloppen.
Volgens de handleiding zit het zo:

In register 5000 staat Voltage (alleen van toepassing op de enkelfasige modellen)
In register 5002 staat L1 Voltage
In register 5004 staat L2 Voltage

5001 en 5003 lijken dus niet te bestaan. Vanwege de telling heb ik het wel even snel geprobeerd.
Bij beide krijg ik een vergelijkbare foutmelding.

5001:

minimalmodbus.InvalidResponseError: Checksum error in rtu mode: '\x02\x00' instead of '\xb00' . The response is: '\x00\x01\x81\x02\x00' (plain response: '\x00\x01\x81\x02\x00')

5003:

minimalmodbus.InvalidResponseError: Checksum error in rtu mode: '\x00\x00' instead of 'A\xd8' . The response is: '\x00@ \x00\x00' (plain response: '\x00@ \x00\x00')

@K7Jz
Jazeker, in de Inepro handleiding staat zelfs ABCD al aangegeven. (Zie bijlage)

Ik vond dit wel een interessante discussie.
Misschien heb je er wat aan.

https://www.avrfreaks.net/comment/832717#comment-832717

Tim, je posts zijn extreem gedetailleerd, fantastisch!

...
Ik heb adres 1 toegewezen aan de energiemeter. Dat heb ik ter controle nogmaals op het display uit te lezen.

daar ben ik nog niet helemaal zeker van, omdat volgens jouw screenshot deze waarde 8 digits mag bevatten, dat klinkt niet als een modbus adres.
ik zat links te kijken, rechts staat het juiste adres.

Het totale te verzenden bericht is dan: 0x01/0x03/0x13/0x8A/0x00/0x01/0xA1/0x64.
Dat klopt ook met wat er verzonden wordt. Dat lijkt dus goed te gaan. Al vindt ik dat de crc bytes gek getoond worden in de output: "\xa1d".

Klopt. Vergeet niet dat printbare karakters (33-127 ofzo) gewoon geprint worden. zoek voor de grap de kleine letter d eens op in een ascii tabel
http://www.asciitable.com/

Te ontvangen data
Ik ga er voor nu vanuit dat de waarde in register 5002 (L1 Voltage) = 230,1V.

In het bericht worden geen decimalen verzonden. 230,1 wordt dus 2301 = 0x08FD. Werderom wordt dit over twee bytes verdeeld: 0x08 en 0xFD.

nee, volgens de specificatie is het een float van 4 bytes,(register length=2) little endian. Je moet dus register 5002 en 5003 tegelijk uitlezen, de waarden samen nemen en als float terugrekenen.

tip: gebruik de module struct met de "unpack" functie.

Conclusie
Het verzonden bericht lijkt goed. Het ontvangen bericht niet.
Het ontvangen bericht is allereerst te kort. Het systeem verwacht 7 bytes, ik kom uit op 6 bytes, maar ik ontvang er 5.
Edit: Ik kwam uit op 6 bytes omdat ik vergeten was het slave-ID voor het antwoord te zetten (0x01).

je conclusie klopt helemaal!
ergens klopt je ontvangen bericht niet.

die 81 hoort daar niet. 8x getallen kunnen een indicatie zijn van een exception, maar dan moet de exception code 0x83 zijn.
http://simplymodbus.ca/exceptions.htm

ik zie in je eerste screenshot dat je de parity al hebt aangepast, dus dat zal goed zitten.

ten eerste moet je de adressen omrekenen naar het decimale stelsel. in je eerste post lijk je 5002_dec op te willen vragen, maar in de PDF is 5002_hex=20482_dec

mogelijk reageert de meter 'raar' omdat je een halve float probeert uit te lezen. dit mag natuurlijk volgens de standaard (jaren 80 was er nauwelijks genoeg rekenkracht voor floats), maar omdat niemand een halve float ophaalt kan het erin geslopen zijn.

zorg dat je een simpel getal (400B - meter amps) uitleest OF lees steeds 2/4/8 registers.

omdat je een usb adapter hebt, kun je op windows ook dit programma draaien. hang de adapter even aan je laptop en gebruik de demo:
https://www.modbustools.com/modbus_poll.html

Op 17 maart 2020 14:41:42 schreef GerritStof:

voltage = instrument.read_register(5002, 3)

Probeer eens 0x5002.

[edit: Ik heb geen reacties gelezen, alleen de openingspost]

[Bericht gewijzigd door rew op woensdag 18 maart 2020 20:41:28 (15%)

Heel scherp, de registers zijn in hexadecimale getallen...
In eerste instantie heb ik in Linux geprobeerd om het register uit te lezen met als adres 0x5002 en 20482.
Beide helaas geen verschil.

Slim om via ModbusPoll eens te proberen of het versturen van berichten wel goed gaat!
Thx voor de suggestie.
Ik heb de USB-adapter in mijn Windows PC gestoken en de juiste drivers geïnstalleerd.
Aan het andere einde van de Modbus ligt de energiemeter.
ModbusPoll lijkt het juiste bericht te genereren, maar dan: Break Condition.

Volgens de handleiding van Modbus Poll heeft dat te maken met een slechte/geen verbinding met de USB-adapter.
Dat is al een belangrijke aanwijzing. Wellicht is de adapter gewoon foutief?

Op 19 maart 2020 09:49:25 schreef GerritStof:
Wellicht is de adapter gewoon foutief?

Als je iets voor het eerst doet en het werkt niet in 1x, dan is het heel makkelijk om te zeggen: "Misschien zijn de componenten af-fabriek stuk?". Dat is zelden het geval. De kans dat je "iets" verkeerd doet is gewoon veel groter. Het zal iets simpels zijn als de "0x" vergeten. Of Ground niet aangesloten terwijl dat wel had gemoeten. (Ik heb usb-rs485 adapters die hem niet naar buiten voeren! Dan kan je makkelijk denken dat het niet hoeft...).

[Bericht gewijzigd door rew op donderdag 19 maart 2020 10:09:50 (17%)

Ik vind die checksums vreemd:

xA1D zou A1 en 64 zijn maar ook 1 byte?!

Checksum error in rtu mode: '\x04\x00' instead of '\xb00' .

Dat is geen twee bytes! De library berekent de verkeerde crc. De crc gaat ook naar een _num_to_twobytes functie... dit is anderhalve byte.. ik zou de crc er even uitkieperen:

Maak van regel 1548 in "/home/pi/.local/lib/python2.7/site-packages/minimalmodbus.py. eens:

if 1 != 1 :

Edit: het zenden gaat ook al fout:

MinimalModbus debug mode. Will write to instrument (expecting 7 bytes back): '\x01\x03\x13\x8a\x00\x01\xa1d' (01 03 13 8A 00 01 A1 64)

Hij gaat hier al 8 bytes sturen. Wederom omdat de CRC misgaat. Die 13 8A is wel netjes je 5200.

Hier ook veel info. Blijkbaar heeft modbus een eigen CRC16

https://www.lammertbies.nl/comm/info/modbus

K7Jz,

matthijs@pcthijs:~$ python
Python 2.7.17 (default, Nov  7 2019, 10:07:09) 
[GCC 9.2.1 20191008] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print "d"
d
>>> print "\x64"
d
>>> s = "\x64dd\x64"
>>> print s, len(s)
dddd 4
>>> print "je k\x61n ieder k\x61rakter escapen, ook as\x63ii"
je kan ieder karakter escapen, ook ascii

ascii "d" is hex 64! enkel de karakters tussen de 33-126 worden in de \x notatie geprint.

dit is dus niet het probleem, enkel een knullige weergave.

tim, heb je het vinkje "plc mode" al aan gehad?

plaats het verkeer eens hier:
https://www.modbustools.com/poll_traffic.html

Op 17 maart 2020 14:41:42 schreef GerritStof:
Beste forumleden,

....
Terminal 22 (A) heb ik verbonden met de 485+ terminal van de Digitus USB adapter.
Terminal 23 (B) heb ik verbonden met de 485- terminal van de Digitus USB adapter.
..

Tim

Heb je de massa van de terminal ook verbonden met de massa van de Digitus ?

Ik heb de Modbus Poll Break Condition nog niet opgelost.
Wel zie ik nu twee reacties die de ground van de USB adapter benoemen.

Ik heb de +5V en de GND van de USB adapter nergens op aangesloten.
Omdat de energiemeter zijn voeding al uit het net haalt en omdat de energiemeter ook geen aansluiting daarvoor heeft. (Zie bijlage).
Of zie ik dat verkeerd?

Edit: Ter verduidelijking van de break error. Regelmatig als ik Modbus Poll opstart krijg ik de foutmelding "Setting port parameters 5 failed with error 995". Dat zal er vast mee te maken hebben, ik kan alleen op internet niet vinden wat deze error betekent. Alleen van error 4 vond ik dat Modbus Poll de instellingen van de USB adapter niet kan wijzigen.

[Bericht gewijzigd door GerritStof op vrijdag 20 maart 2020 15:27:47 (33%)

Op 19 maart 2020 12:45:21 schreef K7Jz:
Ik vind die checksums vreemd:

xA1D zou A1 en 64 zijn maar ook 1 byte?!

Checksum error in rtu mode: '\x04\x00' instead of '\xb00' .

Dat is geen twee bytes! De library berekent de verkeerde crc. De crc gaat ook naar een _num_to_twobytes functie... dit is anderhalve byte.. ik zou de crc er even uitkieperen:

Maak van regel 1548 in "/home/pi/.local/lib/python2.7/site-packages/minimalmodbus.py. eens:

if 1 != 1 :

Edit: het zenden gaat ook al fout:

MinimalModbus debug mode. Will write to instrument (expecting 7 bytes back): '\x01\x03\x13\x8a\x00\x01\xa1d' (01 03 13 8A 00 01 A1 64)

Hij gaat hier al 8 bytes sturen. Wederom omdat de CRC misgaat. Die 13 8A is wel netjes je 5200.

Hier ook veel info. Blijkbaar heeft modbus een eigen CRC16

https://www.lammertbies.nl/comm/info/modbus

Thx voor de uitleg!
Ik wil eerst via Modbus Poll proberen iets uit de meter te krijgen. Met Windows ben ik bekend maar met Linux ben ik echt nog beginner.
Als ik weet dat energiemeter goed werkt ga ik dit zeker proberen. Ik vond de xA1D al zo gek.

Op 19 maart 2020 12:45:21 schreef K7Jz:
Ik vind die checksums vreemd:

xA1D zou A1 en 64 zijn maar ook 1 byte?!

Checksum error in rtu mode: '\x04\x00' instead of '\xb00' .

Dat is geen twee bytes! De library berekent de verkeerde crc. De crc gaat ook naar een _num_to_twobytes functie... dit is anderhalve byte.. ik zou de crc er even uitkieperen:

Maak van regel 1548 in "/home/pi/.local/lib/python2.7/site-packages/minimalmodbus.py. eens:

if 1 != 1 :

Edit: het zenden gaat ook al fout:

MinimalModbus debug mode. Will write to instrument (expecting 7 bytes back): '\x01\x03\x13\x8a\x00\x01\xa1d' (01 03 13 8A 00 01 A1 64)

Hij gaat hier al 8 bytes sturen. Wederom omdat de CRC misgaat. Die 13 8A is wel netjes je 5200.

Hier ook veel info. Blijkbaar heeft modbus een eigen CRC16

https://www.lammertbies.nl/comm/info/modbus

Op regel 1548 wordt een argument in een functie toegevoegd. Is het de bedoeling dat het argument payloadformat deze voorwaarde krijgt? (Zie bijlage)

---------------

Op 19 maart 2020 19:04:51 schreef Progger:
K7Jz,

matthijs@pcthijs:~$ python
Python 2.7.17 (default, Nov  7 2019, 10:07:09) 
[GCC 9.2.1 20191008] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print "d"
d
>>> print "\x64"
d
>>> s = "\x64dd\x64"
>>> print s, len(s)
dddd 4
>>> print "je k\x61n ieder k\x61rakter escapen, ook as\x63ii"
je kan ieder karakter escapen, ook ascii

ascii "d" is hex 64! enkel de karakters tussen de 33-126 worden in de \x notatie geprint.

dit is dus niet het probleem, enkel een knullige weergave.

tim, heb je het vinkje "plc mode" al aan gehad?

plaats het verkeer eens hier:
https://www.modbustools.com/poll_traffic.html

Duidelijk! Ik heb geprobeerd het vinkje PLC-mode aan te zetten. Dan zoekt hij (logischerwijze) naar register 5001 ipv 5002.
Maar ik heb nogsteeds een break condition in modbus poll. Het verkeer bestaat (daarom) enkel uit verzonden berichten (zie bijlage)

Op 23 maart 2020 10:28:07 schreef GerritStof:
Maar ik heb nogsteeds een break condition in modbus poll. Het verkeer bestaat (daarom) enkel uit verzonden berichten (zie bijlage)

Mbpoll als admin gestart?
Kan jouw configuratieprogramma wel praten over dezelfde adapter? Is de poort wel vrij gegeven?

Voor zover ik weet voldoe ik daar allemaal aan (zie bijlagen)
De pariteit heb ik bewust aangepast naar 'even'. Dit heb ik ook op de energiemeter gedaan.
Dat was om te kijken of dat invloed heeft. Ik krijg nu (in Linux via minimalmodbus) 7 bytes terug van de energiemeter, maar nogsteeds een CRC error.

Ik krijg bij het opstarten van Modbus poll alleen een foutmelding. Ik kan die nog niet verklaren.
Ik vond enkel info over een foutmelding met foutcode 4 i.p.v. 993.

Probeer eens de pc volledig te herstarten (afsluiten op win10 werkt niet) met de adapter niet ingeplugd.

Daarna de adapter inpluggen en mbpoll opstarten.

Start hem anders een in compatibiteitsmodus.

Hallo allemaal,

Eindelijk kan ik de energiemeter uitlezen!
Iedereen erg bedankt voor de reacties. Ik heb er veel van geleerd en het motiveerde mij om steeds verder te zoeken.

De oplossing
Via Modbus Poll bleef ik een Break error krijgen.
Daarna heb ik het programma Commix 1.4 gevonden (Hier te downloaden). Dit programma gaf wel de reactie van de energiemeter, ook al sloeg die reactie soms nergens op. Daarnaast vind ik de interface ook wat duidelijker en hoef je het programma niet elke 10 minuten opnieuw te starten omdat je een demo-licentie gebruikt.
De antwoorden die ik op berichten kreeg waren elke keer anders. Er waren vaak 3 variaties die op willekeurige wijze terugkwamen.

Om uit te zoeken wat de antwoorden betekenden heb ik de Modbus specificaties nog eens grondig gelezen:
In paragraaf 3.4.5 staat informatie over de eindweerstanden.

Ik vond het lastig om te meten of de USB>RS485 adapter al een geïntegreerde weerstand had, omdat mijn multimeter ergens in de kiloOhm meette. Maar omdat bleek dat RS232 zonder weerstanden kan werken, en omdat de USB-adapter eigenlijk een USB naar RS232 adapter is, met een opzetstukje dat RS232 omzet naar RS485, besloot ik om de eindweerstand bij de energiemeter weg te halen.
En zowaar, zonder eindweerstanden bleek het te werken.

Elke keer krijg ik nu het juiste antwoord terug!

Ik vermoed dat de eindweerstanden niet nodig zijn als er maar één master en één slave op de bus aanwezig zijn. Dat moet ik nog testen.
Nu eerst maar eens kijken of ik het ook in Linux werkend kan krijgen.

Nogmaals bedankt!
Tim