RS422 eerste device reageert ook als eerste

idd Daisy chain, dat is meer dan gewoon "RS422"..

Op vrijdag 2 augustus 2024 11:03:23 schreef Arco:
Daisy-chaining (rx-tx-rx-tx...) wordt vaker toegepast om simpel controle te hebben over alle nodes. (je weet dan ook dat alle nodes nog 'leven')
(node x+1 krijgt pas data als node x 'tevreden' is met de ontvangen data)

DMX (RS485) doet dat maar heeft wel als nadeel dat als er 1 apparaat "overlijdt" alles wat er achter hangt ook niet meer te bereiken is en naar zijn "default" stand springt.

Op vrijdag 2 augustus 2024 10:57:04 schreef mel:
Moet de bus aan het eind niet afgesloten worden door een afsluitweerstand?Ik stel me voor dat er anders reflecties kunnen optreden.

Staat wel in mijn tekeningetje (rechts).

Maar: Is eigenlijk helemaal niet nodig want er hangt aan de laatste nodig toch niks meer aan. ;)
Dus alles is plug and play.
In de master zit waarschijnlijk de terminator voor het RX pad.

-edit-
Als je toch aan het reverse engineeren bent kun je ook de pluggen even doorpiepen en kijken wat 'hard' aan elkaar hangt.
Ik verwacht minimaal een GND een RX- en R+ pair wat doorgelust is.
En als het device geen eigen voeding heeft misschien ook die 5V?

Op vrijdag 2 augustus 2024 11:33:54 schreef kris van damme:
idd Daisy chain, dat is meer dan gewoon "RS422"..

RS422 is geen protocol het is een electrische definitie van de signalen (=physical layer) en heeft even, puur sec, gezien niks met de topologie of de data definitie te maken.

Wat zijn het voor apparaten?

De definities van RS422 en RS485 zijn niet overal hetzelfde. Er heerst nogal verwarring.

Voor mijn gevoel is RS422 een 4-draads bus waar alleen de master kan zenden en meerdere slaves tegelijkertijd ontvangen waarbij 1 ontvanger een antwoord terug kan sturen naar de master.

En RS485 is dan een 2-draads bus waar alle nodes alles ontvangen en ook antwoord kunnen sturen (maar niet tegelijk).

Zoals bijv hier beschreven :
https://www.analog.com/en/resources/technical-articles/guide-to-select…

Maar TI houdt er heel andere definities op na:
Zie https://www.ti.com/lit/an/slla070d/slla070d.pdf
Daar is een RS422 een 2-draads bus met 1 transmitter en 1 of meer receivers. Terwijl RS485 ook een 2-draads bus is waar elke node kan zenden en ontvangen.

Ook het begrip Daisy-chaining krijgt hier een heel andere uitleg dan wat je zou verwachten.

DMX512 is weer een geval apart. Daar is feitelijk geen sprake van een bus, maar van een point-to-point verbinding die maar in 1 richting werkt. De master stuurt data naar node 1, die stuurt het door naar node 2 etc. Dat wordt dan RS485 genoemd omdat het een 2-draads bus is.

En dan heeft Texas-instruments ook "full-duplex RS485" drivers in het assortiment. En dan hebben ze het over een 4-draads bus

Dus je moet heel goed opletten. De naam alleen zegt niet heel veel. Typisch weer een geval van een onvolledige definitie die je op allerlei manieren kunt toepassen.

Op vrijdag 2 augustus 2024 12:36:25 schreef deKees:
De naam alleen zegt niet heel veel. Typisch weer een geval van een onvolledige definitie die je op allerlei manieren kunt toepassen.

Dat is ook het probleem, de RS-xxx definitie definieert alleen de fysieke laag en niet met protocol wat er overheen gaat.

Kijk dat RS-232 overal gebruikt wordt voor seriele communicatie wil nog niet zeggen dat als je een RS-232 buffer ergens ziet zitten dat het ook meteen serieel is. Alhoewel bij RS232 het heel uitzonderlijk is om er bijvoorbeeld een drukknop aan te hangen en aan de andere kant weer te ontvangen, maar het kan wel.

Bij RS-422 en RS-485 is het al een eens veel troebeler, dat kan echt vanalles zijn. Waarbij RS-485 vaak gebruikt wordt door het modbus protocol of profibus of DMX en noem maar op.

In tegenstelling tot hierboven genoemd definieert CAN-bus WEL de fysieke laag EN het low-level framing protocol, dat hebben die jongens wel goed gedaan.

Op vrijdag 2 augustus 2024 12:36:25 schreef deKees:
En dan heeft Texas-instruments ook "full-duplex RS485" drivers in het assortiment. En dan hebben ze het over een 4-draads bus

Dat heet RS-422 ;)

Dank voor alle reacties tot nu toe. Het lijkt er dus op dat het een daisy chain zou kunnen zijn. Enige vreemde vind ik dan dat het commando wel gewoon door de eerste en tweede device gaan (ik heb op het eind van de bus gemeten). Je zou verwachten dat de eerste dit dan direct tegenhoudt.

Het kan natuurlijk ook zo zijn dat de eerste iets met de TX lijn doet (dus de RX lijn van de master) zodat alleen de eerste antwoord kan geven en het antwoord van de tweede wordt tegen gehouden. Zodra de eerste een adres heeft, hoeft dit niet meer en kan de tweede ook antwoorden.

@henri62: volgens mij heb ik alles al doorgemeten en voor zover ik me kan herinneren zit alles hard aan elkaar maar dat kan ik nog eens dubbel checken.

Het gaat overigens om loadcellen. Er zit een controller bij aan, die de communicatie e.d. doet. Het gaat me eigenlijk niet om de toepassing maar vooral om hoe de communicatie werkt. Op de master staat overigens RS-422 bij de aansluiting vermeld, ik ga er dus vanuit dat het ook echt RS-422 is. Ik gebruik overigens ook usb-RS422 converters om te monitoren, dus het is of RS-422 of RS-485. Maar gezien het 4 draden zijn, ga ik uit van RS-422

Dat is interessant als alles hard aan elkaar zit, wel raar.
Zit er misschien in de "tussen kabels" een "twist" die de pin sets laten verspringen? Heb je een originele kabel die ertussen hoort om die door te piepen?

Ander voordeel van daisy-chaining is dat je dat bijna onbeperkt kunt uitbreiden.
(er hangt altijd maar één node aan de kabel, dus minimale belasting)

Volgens mij gaat het hem om deze: https://www.zemiceurope.com/media/Documentation/ZDY-ZX_Datasheet.pdf

Ik heb eens eerder een Zemic loadcel + versterker in een project gebruikt. Was iets compleet anders.

Op vrijdag 2 augustus 2024 13:47:39 schreef henri62:
Dat is interessant als alles hard aan elkaar zit, wel raar.
Zit er misschien in de "tussen kabels" een "twist" die de pin sets laten verspringen? Heb je een originele kabel die ertussen hoort om die door te piepen?

Ik ga het maandag nog even weer nameten en dubbel checken, ik heb de spullen nu niet bij de hand. Volgens mij zijn alle kabels gewoon recht. Op dit moment gebruik ik geen tussenkabels, ze zitten zeg maar rechtstreeks aan elkaar.

Dat heet RS-422 ;)

Inderdaad, voor mij wel en voor jou ook, maar voor TI dus blijkbaar niet.

Ook daisy-chaining zien ze anders dan wij:

Dus het lijft wel opletten. De termen alleen zeggen niet altijd alles.

Meerdere zenders/drivers op een aderpaar = 485.

Op vrijdag 2 augustus 2024 17:22:00 schreef PE9SMS:
Meerdere zenders/drivers op een aderpaar = 485.

Toch niet helemaal. Het echte verschil is dat bij RS485 elke node zowel kan zenden als ontvangen op hetzelfde aderpaar. Bij RS422 kan een node ofwel zenden ofwel ontvangen.

485 is er in full duplex (tegelijk zenden en ontvangen, 2 aderparen) en half duplex (om de beurt zenden en ontvangen over 1 aderpaar).

Op donderdag 1 augustus 2024 21:51:31 schreef deKees:
Op een echte RS422 bus kan zoiets niet. De master verstuurt data en alle slaves ontvangen alleen die data van de master.

Dat hangt natuurlijk van het protocol af. RS422 is geen protocol, het is alleen hardware.

Klopt, is alleen hardware.

RS422: Alleen de master kan zenden, de rest kan alleen ontvangen.
En op het andere aderpaar kan alleen de master ontvangen en de anderen kunnen alleen zenden.

Op vrijdag 2 augustus 2024 19:48:33 schreef deKees:
Klopt, is alleen hardware.

RS422: Alleen de master kan zenden, de rest kan alleen ontvangen.

Eens.

En op het andere aderpaar kan alleen de master ontvangen en de anderen kunnen alleen zenden.

Een RS422 driver kan niet uitgeschakeld worden (tri state) dus die kan je niet parallel zetten.

Een RS422 driver kan niet uitgeschakeld worden (tri state) dus die kan je niet parallel zetten.

Jawel hoor. Zie

Uit welk document komt dat plaatje?

Zie bijvoorbeeld: https://www.analog.com/en/resources/app-notes/an-960.html

[Bericht gewijzigd door PE9SMS op (53%)]

Uit welk document komt dat plaatje?

Uit : https://www.analog.com/en/resources/technical-articles/guide-to-select…

En dat matcht met wat ik altijd heb gezien als RS422.

Ha, grappig. In mijn linkje in de vorige post doen ze het beter. :)

Ha, inderdaad grappig. Je kunt er alle kanten mee op.

Hoe verder ik zoek hoe meer varianten ik zie, zowel voor RS422 als voor RS485. Point-to-point, multi-drop, half duplex, full duplex;

Het lijkt erop dat RS422 en RS485 niks zeggen over bus topologie, maar alleen de signaal niveaus en impedanties specificeren. Er zijn duidelijke verschillen in het max aantal receivers op de bus, en op het common-mode bereik.

Maar ik kan de standaard zelf er niet op naslaan. Die zit verstopt achter een betaalmuur 8)7 . Jammer.

Ik heb n.a.v. diverse antwoorden nog een aantal dingen gecheckt. Met een multimeter heb ik de aders door gepiept; alle kleuren zitten 'hard' aan elkaar.

Verder heb ik ter verduidelijking even een simpele overzichtstekening gemaakt van het systeem:

Er gaat dus een uitgaande kabel vanaf de controller naar de node (wat voor de node dus de inkomende kabel is) en er komt weer een uitgaande kabel uit de node die door gaat naar de tweede node, en zo verder.
Per kabel zitten er 6 aders in: +12V, GND, TX+, TX-, RX+ en RX-.

Ik heb een simpele test gedaan met één usb-RS422 converter die de controller vervangt en één node, wat schematisch zo aangesloten is:

Als ik een commando verstuur krijg ik zoals verwacht een antwoord.

Dan met twee nodes en een extra usb-RS422 converter als monitor:

De verbinding van node 1 naar node 2 is een originele kabel. De overige 'draadjes' zijn originele kabels maar dan met open eind die op een kroonsteen zitten en met andere draden naar de converters gaan.
Als ik nu een commando verstuur met de 'master', dan krijg ik antwoord van node 1 en dus niet van node 2.
Op de monitor zie ik het verstuurde commando door de master. Dat betekent dat het commando wel 'door' node 2 is gegaan maar er blijkbaar niets mee doet?

Vervolgens nog gekeken op het TX kanaal van de laatste node:

Hier zie ik op de monitor het antwoord van node 1. Ook hier betekent het dus dat het antwoord door node 2 is gegaan, maar dat node 2 dus zelf niet antwoordt.

Als ik het antwoord bevestig van node 1(dit heb ik gezien bij de originele controller) dan krijg ik -als ik nogmaals het commando verstuur- antwoord van node 2. Die kan ik vervolgens ook weer bevestigen, waarna beide nodes geen antwoord meer geven op het commando.

Ik begrijp nog steeds niet waarom node 1 altijd als eerste antwoordt.

Dat hangt van de manier af waarop de firmware is geschreven...
Blijkbaar wil men de nodes sequentieel aanspreken, (n, n+1, n+2,...)

Als je de monitor op de verbinding tussen node1 en 2 aansluit zul je wel meer data zien... (data in hoeft niet gelijk te zijn aan data out)

[Bericht gewijzigd door Arco op (35%)]

Op dinsdag 6 augustus 2024 15:02:04 schreef Arco:
Dat hangt van de manier af waarop de firmware is geschreven...
Blijkbaar wil men de nodes sequentieel aanspreken, (n, n+1, n+2,...)

Als je de monitor op de verbinding tussen node1 en 2 aansluit zul je wel meer data zien... (data in hoeft niet gelijk te zijn aan data out)

Zie de derde afbeelding. Op het eind van de bus zie ik hetzelfde commando als wat ik aan het begin stuur. Feitelijk meet ik al tussen twee nodes, want er kan ook een derde node komen waar nu mijn monitor zit.