RS422 eerste device reageert ook als eerste

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 vrijdag 2 augustus 2024 21:07:46 (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 . 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 dinsdag 6 augustus 2024 15:15:21 (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.

Waar zijn de terminators in deze bus??

Die zullen wel in de nodes zelf zitten...

Assumption is the mother of all f*ck ups

Ts schrijft er niets over en als in zijn sniffers de Terminator aanstaat en in de eerste node dan kan het zomaar zijn dat hij de nodes daarachter niet goed ziet....

En op die andere sniffers hetzelfde..

Doet exact wat TS beschrijft.

@Peter: Je zegt dus dat van 1 NODE (slave) de TX+ links en de TX+ rechts hard aan elkaar hangen? Hetzelfde geld voor TX-, RX+ en RX- aansluitingen?

Lijkt me stug, want dan kan het nooit werken tenzij er een enumeratie protocol aan vooraf gaat en dan zou altijd dezelfde node moeten reageren onafhankelijk waar die in de lus zit.

Ik opteer nog steeds voor een systeem wat domweg TX->RX (node) TX->RX doorlust.
Dan is meteen het mysterie van de terminators opgelost en het feit dat RS422 transmitters niet disabled kunnen worden.

Op woensdag 7 augustus 2024 00:24:09 schreef henri62:
@Peter: Je zegt dus dat van 1 NODE (slave) de TX+ links en de TX+ rechts hard aan elkaar hangen? Hetzelfde geld voor TX-, RX+ en RX- aansluitingen?

Klopt, ik heb zojuist nogmaals gemeten met een multimeter. TX+ links en TX+ rechts van een node zitten hard aan elkaar. Geldt ook voor de overige lijnen. D.w.z. de multimeter piept en geeft nagenoeg 0 Ohm aan.

Ik opteer nog steeds voor een systeem wat domweg TX->RX (node) TX->RX doorlust.
Dan is meteen het mysterie van de terminators opgelost en het feit dat RS422 transmitters niet disabled kunnen worden.

Wat bedoel je met doorlussen? Stel dat de master op de linker kabel van node 1 zit en op de rechter kabel van node 1 zit node 2. De linker kabel is dan de 'inkomende' kabel en de rechter kabel de 'uitgaande' kabel. De master zendt iets vanuit zijn TX op de RX lijnen van de node, in de linker kabel. Dit bericht gaat via de uitgaande kabel, over de RX lijnen, naar node 2.
Het bericht van de master, wat node 1 via zijn RX lijn ontvangt, gaat ook via de RX lijn van de uitgaande kabel naar node 2. Node 1 zendt dus het commando niet door via de TX lijn naar node 2, maar via de RX lijn.

Op dinsdag 6 augustus 2024 22:59:28 schreef High met Henk:
Assumption is the mother of all f*ck ups

Ts schrijft er niets over en als in zijn sniffers de Terminator aanstaat en in de eerste node dan kan het zomaar zijn dat hij de nodes daarachter niet goed ziet....

En op die andere sniffers hetzelfde..

Doet exact wat TS beschrijft.

Wellicht dat ze intern zitten maar dat is inderdaad een aanname. Ik gebruikt een DeLock usb-RS422 converter maar ze reppen met geen woord over een terminator...

Terminators zijn alleen noodzakelijk bij hoge snelheden (>9600) en/of lange lijnen (>10m).
Voorzover ik begrepen heb is het tweede niet van toepassing, de comminicatiesnelheid heb ik in het hele verhaal nog niet kunnen ontdekken.
Ze zullen sowieso NIET in de modules zitten (is vast te stellen door op een losse module tussen TX+ en TX-, RX+ en RX- te meten) omdat het aantal modules in de keten niet vantevoren vaststaat: bij meer dan twee terminators op een lijn gaat de communicatiekwaliteit ook achteruit.

Met een scoop valt misschien een looptijd te bepalen: die kan ín de module kunstmatig verlengd zijn met een filter. Dat zou dan kunnen verklaren waarom ze altijd netjes in volgorde antwoorden...

Ok, ik heb zojuist een kleine ontdekking gedaan
Node 1 schakelt de voeding van de uitgaande kabel uit. Alle node's na node 1 worden dus uitgeschakeld. Dit wetende, is het niet zo gek dat alleen node 1 antwoord geeft.

Dat ik aan het einde van de bus/chain wel de commando's kan zien, is omdat de RX en TX lijnen aan elkaar hangen, zoals al gemeld. Maar de elektronica in de node is dus simpelweg uitgeschakeld.

Als de master het antwoord van node 1 bevestigd (zoals ik in m'n eerste post uitleg) dan schakelt node 1 de uitgaande voeding in, zodat node 2 gevoed wordt. Ik heb het verder niet gecontroleerd, maar ik neem aan dat het voor de volgende nodes allemaal hetzelfde werkt. En dus antwoord er per keer maar 1 node omdat de rest of nog uitgeschakeld is of al geantwoord heeft op het commando.

Het kan soms heel simpel zijn, zo blijkt maar weer.

Dit verklaart alles. Mooi gevonden.

edit: dit geintje werkt alleen als de master aan het begin van een string zit. Wat gebeurd er als de master in het midden zit en je een T vormt? Of heeft de master slechts 1 aansluiting? Dat is dan ook niet volgens de topologie van RS485/RS422. Waar master en node zich bevinden in de bus zou niks mogen uitmaken.

[Bericht gewijzigd door buckfast_beekeeper op woensdag 7 augustus 2024 14:54:09 (82%)

De voedingspinnen hangen dus NIET aan elkaar!

Dat is wel een heel ranzige oplossing. De eerste node zal na het commando dat die zelf ontvangt zichzelf dus dan adres 2 gaan geven. De tweede wordt dan 1 en doet heltzelfde kunstje.
De node die de voeding naar zijn volgende doorlust kan dan zien dat de opvolgende node reageert en zijn eigen nummer elke keer met 1 ophogen. Iedere node doet dus precies hetzelfde kunstje.

Dat gaat door tot alle nodes ge-enumereerd zijn. De laatste node wordt dan uiteindelijk adres 1 want die ziet geen response meer.

Ik had het zo nooit gemaakt als ik het zou moeten ontwerpen: want power van een node eraf gooien is niet echt betrouwbaar. De start tijd van een node kan redelijk wat problemen veroorzaken en evt rommel op de bus zetten tijdens startup en mogelijke latchup van RS485 drivers (alhoewel dat redelijk strict gedefinieerd is dat het niet zou mogen).

@fatbeard: Terminators zijn wel nodig in dit geval, het originele spul is zover ik begrepen heb een aantal intelligente loadcellen. En die zitten vaak best een eind uit elkaar.

Op woensdag 7 augustus 2024 12:27:33 schreef buckfast_beekeeper:
edit: dit geintje werkt alleen als de master aan het begin van een string zit. Wat gebeurd er als de master in het midden zit en je een T vormt? Of heeft de master slechts 1 aansluiting? Dat is dan ook niet volgens de topologie van RS485/RS422. Waar master en node zich bevinden in de bus zou niks mogen uitmaken.

De master heeft inderdaad slechts 1 aansluiting dus je wordt gedwongen om hem als eerste aan te sluiten. Het is wat dat betreft ook niet echt een bus maar een daisy chain (ik moet wel zeggen dat ik de precieze definitie van beide systemen niet precies ken en ik dit topic is daar ook wat discussie over).

De voedingspinnen hangen dus NIET aan elkaar!

Klopt, dit had ik ook niet gezegd toch? Oke, toegegeven, ik had het in mijn post misschien wat duidelijk kunnen formuleren maar de focus lag op de datalijnen en totaal niet op de voedingslijnen.

Dat is wel een heel ranzige oplossing. De eerste node zal na het commando dat die zelf ontvangt zichzelf dus dan adres 2 gaan geven. De tweede wordt dan 1 en doet heltzelfde kunstje.
De node die de voeding naar zijn volgende doorlust kan dan zien dat de opvolgende node reageert en zijn eigen nummer elke keer met 1 ophogen. Iedere node doet dus precies hetzelfde kunstje.

Dat gaat door tot alle nodes ge-enumereerd zijn. De laatste node wordt dan uiteindelijk adres 1 want die ziet geen response meer.

De master deelt de adressen uit. Die houdt bij welke al uitgegeven zijn. De slaves geven zichzelf geen adres. Pas als de master een 'bevestigings-commando' stuurt, schakelt de slave de spanning naar de rest van de bus/chain weer in.

Ten zij ik er over heen heb gelezen: wat eerder is opgemerkt: RS422 is hardware maar welk protocol wordt er eigenlijk gebruikt?

Op vrijdag 9 augustus 2024 12:18:14 schreef Leo-Bolier:
Ten zij ik er over heen heb gelezen: wat eerder is opgemerkt: RS422 is hardware maar welk protocol wordt er eigenlijk gebruikt?

Voor zover ik kan beoordelen een eigen protocol. Het is in ieder geval geen DALI of Modbus ofzo.