RS485 sensor vraag

Onderstaande link geeft je het officiële modbus protocol.
https://www.modbustools.com/modbus.html
Ik meen dat er (onofficieel) ook een broadcast adres is waarop elk aangesloten device moet antwoorden (mits het bericht het juiste formaat en een correcte CRC heeft). Staat me bij dat dat 255 (0FFH) of juist 0 (00H) is.
Modbus devices antwoorden alleen als het bericht een goed adres, de juiste lengte en een correcte CRC heeft. In alle andere gevallen krijg je geen antwoord.
Is aan deze voorwaarden voldaan dan krijg je altijd antwoord, eventueel met een foutmelding als je bijvoorbeeld om een register vraagt wat in dat device niet bestaat of een niet ondersteunde opdracht code geeft.
In jouw geval geldt het RTU protocol.

0 is het broadcast adres maar wordt amper gebruikt omdat je geen respons krijgt en je dus niet zeker weet dat het goed is aangekomen.

Wat een beetje vreemd is in de voorbeelden uit de spec van de sensor dat ze daar zeggen dat 01 het default adres is om vervolgens een voorbeeld te geven hoe dat in 06 te veranderen.
Maar heel duidelijk staat verderop dat het default adres van de sensor 55 (dec) = 37H is.
Als de sensor nieuw uit de doos is dan is die 55 het adres en 9600 nog steeds de baudrate. Het commando om bijv. de temperatuur uit te lezen wordt dan:

37 03 01 00 00 01 xx xx
37 = adres sensor
03 = commando om een register te lezen
01 00 = registeradres van de temperatuur
00 01 = aantal registers = 1 = 2 bytes !
xx xx = crc16 code, die moet je wel correct uitrekenen

Je moet dan terug krijgen:
37 03 02 00 xx yy yy waarbij:
37 = adres van de sensor
03 = het gegeven commando (register lezen)
02 = aantal databytes
xx yy de temperatuur is in 0.1 graden
zz zz de CRC16 van dit bericht die je dan hoort te controleren.

Er is Modbus testsoftware waar je dit kunt invullen en wat dan netjes de CRC voor je uitrekent. Had ik ooit wel maar is bij een nieuwe PC verdwenen.

XX XX = 80 60
Dus:
37 03 01 00 00 01 80 60

Zie:
https://crccalc.com/?crc=37%2003%2001%2000%2000%2001&method=CRC-16…

De CRC16 moet nog naar BIG endian geswapped worden, vooral in je programma niet vergeten.

[Bericht gewijzigd door henri62 op (23%)]

Ik heb ooit een Modbus (ASCII) implementatie geschreven en heb veel info gevonden op: https://www.lammertbies.nl/comm/info/modbus.

Ook iets om rekening mee te houden: soms moet je het gewenste register adres +1 of -1 doen om reden dat Amerikanen niet weten wat "0" is en Modicon van oorsprong natuurlijk een Amerikaans merk was.

Op dinsdag 11 maart 2025 09:15:54 schreef GJ_:
Ook iets om rekening mee te houden: soms moet je het gewenste register adres +1 of -1 doen om reden dat Amerikanen niet weten wat "0" is en Modicon van oorsprong natuurlijk een Amerikaans merk was.

Oh ja, dat klopt. En ooit een keer meegemaakt dat er een offset van, wat was het ook al weer, 4000H(?) bij geteld moest worden. Had iets met de geheugen indeling van Modicon PLC's...
Maar gezien de voorbeelden in het sensordocument verwacht ik niet dat dat hier het geval zal zijn. En zoja, dan hoort de sensor een foutcode terug te sturen met betekenis: ongeldig register adres.

Een offset van 40000 of 30000 kan ook nog ja. Of dus 40001 :-)
Daar zit dan de functiecode bij opgenomen.

Ik ken het vooral van sommige Amerikaanse servodrives van Emerson.

Op dinsdag 11 maart 2025 10:13:54 schreef GJ_:
Een offset van 40000 of 30000 kan ook nog ja. Of dus 40001 :-)
Daar zit dan de functiecode bij opgenomen.

Ik ken het vooral van sommige Amerikaanse servodrives van Emerson.

Allen bradley plc's hadden dat ook.
En verder ben ik ook ooit 8 bit met parity tegengekomen. En ik meen ook dat hi en lo CRC ooit ergens omgedraaid waren. Zoveel fabrikanten, zoveel variaties :-(

Officeel is modbus ook alleen met even parity. Maar ja, iedereen rommelt maar wat aan.

Volgens de "regels" van 2006 is even parity default, "no parity" en "odd" zijn optioneel.

Schakelt je MAX485 wel om naar receive/ontvangen?

Moet een MAX485 omschakelen? Hoe dat dan?

Op woensdag 12 maart 2025 08:30:49 schreef GJ_:
Moet een MAX485 omschakelen? Hoe dat dan?

Van die reactie verschiet ik wel even.

RS(3)485 is half duplex, dus is het heel normaal dat de MAX(3)485 (of gelijkaardig) moet schakelen tussen ontvangen, wat de standaard is, en zenden. Waar denk je dat de ReceiverOutput en ReceiverOutputEnable voor dienen?

Op woensdag 12 maart 2025 08:52:39 schreef buckfast_beekeeper:
[...]
Van die reactie verschiet ik wel even.

Hoeft niet hoor. Ik ben nou eenmaal niet echt deskundig als het om elektronica gaat. Het was echt een vraag, hoe moet je met twee touwtjes omschakelen?

Ik zal de datasheet er eens bij pakken en beter bekijken. Dat had ik misschien beter eerst gedaan ;-)

EDIT: ah, de /RE en DE
Ik heb lang geleden ooit "iets" met een MAX232 gedaan, maar behalve de "MAX" is die natuurlijk heel anders.

[Bericht gewijzigd door GJ_ op (14%)]

Oeps even ook de pennen verkeerd benoemd.

DE of driver output enable hoog maken samen met RE (inverted ingang) maakt dat het IC kan zenden. Maak je beiden laag staat die in ontvangstmodus. Normaal is er 1 master, die doet regelt de communicatie, en die vraagt aan een bepaald adres om iets te doen. Moet daar een antwoord op komen, schakelt de master naar ontvangen door DE en RE laag te maken (bij MAX(3)485 in SOIC of DIL pennen 2 en 3). Aan de andere kant wordt dan het omgekeerde gedaan. DE en RE worden hoog gemaakt en de node kan zenden. Na het zenden gaat die terug naar ontvangen om zo de bus vrij te maken. Er mag altijd maar 1 zenden.

edit: MAX232 is RS232 en dat is full duplex. Het is ook point to point en niet multipoint zoals RS485.

Op woensdag 12 maart 2025 09:11:49 schreef buckfast_beekeeper:

edit: MAX232 is RS232 en dat is full duplex. Het is ook point to point en niet multipoint zoals RS485.

Ik weet het verschil tussen RS232 en RS485. Ik kom niet zo vaak onder de motorkap, maar ben wel een veelvuldig gebruiker.

Nog even over /RE en DE: De pins zitten naast mekaar en zijn ZO gedefinieerd dat je ze aan mekaar kan hangen om danwel te zenden danwel te ontvangen. Maar je mag ze ook los bedienen om speciale dingen te doen.

Bijvoorbeeld: DE laag (niet zenden), /RE hoog (ook niet ontvangen). Ik ben master, de slaves gaan toch niet vanzelf zenden zo bespaar ik wat energie.

Of DE hoog (wel zenden) /RE laag (ook ontvangen): Ter controle je eigen bericht "op de draad" terugluisteren. Zo kan je een harde kortsluiting misschien opmerken.

... of een collision ...

Over de direction: ik ga er vanuit dat die goed is want in de allereerste post van de TS staat op het scoop beeld de trace van dat signaal.
Dus de TS weet ervan anders had ie die er niet bij gezet.

Dat signaal ziet er trouwens ook prima uit.

Op woensdag 12 maart 2025 18:55:53 schreef henri62:
Over de direction: ik ga er vanuit dat die goed is want in de allereerste post van de TS staat op het scoop beeld de trace van dat signaal.
Dus de TS weet ervan anders had ie die er niet bij gezet.

Dat signaal ziet er trouwens ook prima uit.

Mee eens Henri, maar hij kan nog steeds A en B verwisseld hebben staan..
We hebben helaas na het begin niets meer van TS gehoord.

Bedankt voor de reacties weer allemaal.
Ik heb het volgende inmiddels geprobeerd:
-A en B draad omdraaien
-Alle mogelijk bit rates
-Alle mogelijke adressen

En dit in alle mogelijke combinaties.
Helaas nog steeds geen antwoord van de sensor.
Ook de A en B draden tot de connector uit gemeten, die blijken ook goed te zijn.
Sensor krijg ik helaas ook niet open geschroefd omdat alles waterdicht is gemaakt. Had dan nog de 485 transceiver op werking kunnen controleren aan de sensor kant.
Ik ga contact opnemen met de fabrikant, misschien dat dat nog wat oplevert.

Heb een nieuwe sensor gekregen van die fabrikant en hij werkt!
Bleek inderdaad op adres 55 te zitten.

Bedankt voor de reacties allemaal!

Top.

Op woensdag 12 maart 2025 10:36:49 schreef fatbeard:
... of een collision ...

de bus is gedefinieerd met een minimale (of gedefinieerde) zend-impedantie. Volgens mij, meet je dan hoogst waarschijnlijk ook bij een collision terug wat je zelf zond. Maar goed. Als je het verwacht is het allicht te proberen.