(lang geleden dat ik hier gepost heb, maar ik heb weer een vraag!)
Ik ben bezig met het ontrafelen van de communicatie tussen een bestaand systeem bestaande uit een controller en meerdere devices die met four wire RS422 onderling communiceren. En nu loop ik tegen iets aan wat in mijn ogen op een bussysteem niet kan.
De controller adresseert namelijk de devices op de bus. De eerste is 1, de tweede 2, enz. De commando's om te adresseren simuleer ik. Effectief heb ik dus eerst de communicatie tussen de controller en devices afgeluisterd om deze vervolgens zelf te gaan sturen. Ik heb de controller afgekoppeld en vervangen door een usb-naar-RS422 converter met daaraan dus twee devices op de RS422 bus.
Als ik nu het commando stuur om te adresseren, krijg ik altijd als eerste antwoord van het eerste fysieke device op de bus. Dat betekent; de eerste device die als eerste na de usb-naar-RS422 converter zit. Het tweede device, dat dus op dezelfde bus zit, antwoord in z'n geheel niet. Het tweede device krijgt het commando wel (heb ik met een andere usb-naar-RS422 converter gecontroleerd). Als ik een acknoledgment commando stuur, krijg ik wederom alleen antwoord van het eerste device. Het lijkt er op dat nu voor de eerste het adresseren klaar is.
Als ik vervolgens opnieuw het commando stuur om te adresseren, krijg ik van het tweede device een antwoord die ik daarna opnieuw acknoledge.
Nu de vraag: hoe kan dat in eerste instantie alleen het eerste device antwoord geeft terwijl het tweede device het commando ook gewoon krijgt? Het lijkt er op dat het eerst device ook echt weet dat het het eerste device op de bus is. Dit kan in een bussysteem toch niet? En hoe kan het dan, dat na het versturen van exact hetzelfde commando, het tweede device reageert omdat klaarblijkelijk het eerste device niet meer hoeft te reageren?
Zijn er mechanismes die zoiets kunnen regelen? Of zie ik iets over het hoofd?
Op donderdag 1 augustus 2024 18:35:48 schreef Aart:
Maar als beide devices van plaats verwisselen is het daadwerkelijk andersom?
Ja, dan is het daadwerkelijk andersom. Dan krijg ik als eerste het serial number van wat dus eerst het tweede device was. Dus stel dat ik in eerste instantie als eerste serial 33 kreeg en daarna 44, na het omdraaien van de devices krijg ik dan eerst 44 en daarna 33.
Op donderdag 1 augustus 2024 18:42:05 schreef Bobosje:
Alle polariteiten van de Tx en Rx draden juist aangesloten?
Ja, anders heb ik uberhaupt geen communicatie.
@Bobosje: ter verduidelijking: het is opzich geen fout. Het systeem werkt, ik snap alleen niet hoe omdat dit volgens mij op een bussysteem niet zou moeten kunnen. Tenzij ik dus iets over het hoofd zie...
[Bericht gewijzigd door Peter op (13%)]
Op donderdag 1 augustus 2024 18:57:27 schreef Bobosje:
Staan de devices parallel op de bus?
Dat denk ik wel. Kan de elektronica niet zien want het is ingegoten. Maar als ik met de multimeter op diodestand aan het begin en eind op de TX+ (bijvoorbeeld) draad meet, is er gewoon een harde verbinding. En een bericht wordt door het eerste device ook gewoon doorgelaten, want ik zie op het eind van de bus (dan is het bericht ook al 'door' het tweede device geweest) dat het bericht daar gewoon aankomt.
Op donderdag 1 augustus 2024 18:57:27 schreef Bobosje:
Staan de devices parallel op de bus?
Ja, want RS422.
Op donderdag 1 augustus 2024 19:19:05 schreef GJ_:
[...]Ja, want RS422.
Was een vraag ter verificatie, kan vanuit het forum niet zien hoe e.e.a. bij TS is aangesloten. 
benleentje
Golden Member
Staan de devices parallel op de bus?
Volgens worden de RS422 modules steeds door gelust. Ik zou dit eerder in serie aansluiten willen noemen.
IK bedoel niet dat het serieel aangesloten is maar fysiek zit de ene module wel na de andere. De eerste op de bus zal de data door looptijden verschillen altijd als eerste ontvangen.
[Bericht gewijzigd door benleentje op (16%)]
Op donderdag 1 augustus 2024 20:57:39 schreef benleentje:
...De eerste op de bus zal de data door looptijden verschillen altijd als eerste ontvangen.
Daar heb ik ook al aan gedacht ja. De eerste keer dat het commando gestuurd wordt reageert het eerste device als eerste omdat die het bericht als eerste ontvangt. Deze reageert dan ook direct. Het tweede device wil ook reageren maar omdat de bus bezet is, kan dit niet. De tweede keer dat het commando verstuurd wordt, heeft het eerste device al gereageerd dus reageert niet meer. En daardoor kan de tweede device reageren.
Zoiets? Voor mijn gevoel is dit net heel robuust of betrouwbaar maar dat is meer een gevoel dan dat ik dat technisch kan onderbouwen.
Maak eens een T-verbinding, zodat beide devices precies evenveel 'tijd' vanaf de controller zitten.
Elektrisch staan ze tóch al parallel.
(Als je denkt dat reflecties dan een probleem vormen, kun je elk van de twee takken dan een afsluiter van de dubbele weerstand geven, dus bijv. 300 ohm.)
benleentje
Golden Member
Zoiets? Voor mijn gevoel is dit net heel robuust of betrouwbaar maar dat is meer een gevoel dan dat ik dat technisch kan onderbouwen.
Ik denk eerder dat je in de aansturing of adressering iets fout doet. Ik probeerde net te zoeken hoe het RS422 protocol zelf werkt maar kon dat even niet zo snel vinden.
PS nog wel iets gevonden
Als u communiceren naar eenheid #1 wilt, stuurt u een opdracht naar de unit #1. Alle eenheden horen de opdracht, maar alleen de geadresseerde eenheid zal reageren.
Als de adressering goed is mag dus alleen het module met dat specifieke adres reageren.
Op een echte RS422 bus kan zoiets niet. De master verstuurt data en alle slaves ontvangen alleen die data van de master.
Alle slave transmitters zitten aan elkaar en alleen de master kan het antwoord ontvangen. De slaves kunnen dus onderling geen data van elkaar ontvangen en kunnen ook niet zien of er een andere slave data verstuurt.
Dus dan moet je extra maatregelen gaan treffen. Het zou kunnen dat het geen echt RS422 bus is, maar dat elke slave fungeert als doorlus-station.
Het kan ook dat de slave stations zijn uitgerust met een collision-detect mechanisme, maar dat is voor RS422 hoogst ongebruikelijk.
Looptijden kunnen het verschil ook niet maken. Die zijn zo kort dat dat nauwelijks meetbaar is, en slaves kunnen sowieso al niet de data van andere slaves ontvangen.
Op donderdag 1 augustus 2024 18:22:42 schreef Peter:
Nu de vraag: hoe kan dat in eerste instantie alleen het eerste device antwoord geeft terwijl het tweede device het commando ook gewoon krijgt? Het lijkt er op dat het eerst device ook echt weet dat het het eerste device op de bus is. Dit kan in een bussysteem toch niet? En hoe kan het dan, dat na het versturen van exact hetzelfde commando, het tweede device reageert omdat klaarblijkelijk het eerste device niet meer hoeft te reageren?
Zijn er mechanismes die zoiets kunnen regelen? Of zie ik iets over het hoofd?
RS422 was als ik me niet vergis tussen één bron en één ontvanger ( een master en een slave, zo je wilt)
zou het hier om RS485 gaan? zelfde hardware, maar meerdere devices kunnen op dezelfde draden.
Nu, er zijn uiteraard mechanismen die conflicten kunnen vermijden/ regelen.
de I²C bus is een van de mooiste en best gedocumenteerde bussen om uit te zoeken hoe zo iets werkt.
Op donderdag 1 augustus 2024 21:43:48 schreef Frederick E. Terman:
Maak eens een T-verbinding, zodat beide devices precies evenveel 'tijd' vanaf de controller zitten.
Elektrisch staan ze tóch al parallel.
Dat zou ik inderdaad een kunnen proberen. Helaas kan ik dat maandag pas doen, ik heb het spul nu niet bij de hand.
Op donderdag 1 augustus 2024 21:46:55 schreef benleentje:
Ik denk eerder dat je in de aansturing of adressering iets fout doet. .
Het hele idee van deze procedure is juist dat de devices een adres krijgen. Ze hebben dus nog geen adres op het moment dat de communicatie zoals ik beschreef aan de gang is.
Op donderdag 1 augustus 2024 21:51:31 schreef deKees:
Alle slave transmitters zitten aan elkaar en alleen de master kan het antwoord ontvangen. De slaves kunnen dus onderling geen data van elkaar ontvangen en kunnen ook niet zien of er een andere slave data verstuurt.
Dat klopt, maar alle slaves zitten wel op dezelfde TX draden. Kan één slave dan niet zien dat de andere aan het zenden is (electrisch is het niet mogelijk voor een tweede slave om te zenden als er al eentje aan het zenden is)?
Op donderdag 1 augustus 2024 21:51:31 schreef deKees:
Dus dan moet je extra maatregelen gaan treffen. Het zou kunnen dat het geen echt RS422 bus is, maar dat elke slave fungeert als doorlus-station.
Maar hoe weet in dit geval de eerste slave dan dat hij de eerste is en dus als eerste moet reageren? Het bericht verschijnt ook bij de tweede, dus het doorlus-station houdt het bericht niet tegen o.i.d.
Op donderdag 1 augustus 2024 21:51:31 schreef deKees:
Looptijden kunnen het verschil ook niet maken. Die zijn zo kort dat dat nauwelijks meetbaar is, en slaves kunnen sowieso al niet de data van andere slaves ontvangen.
Dat lijkt mij eerlijk gezegd ook.
Op donderdag 1 augustus 2024 21:56:02 schreef kris van damme:
RS422 was als ik me niet vergis tussen één bron en één ontvanger ( een master en een slave, zo je wilt)
Je hebt ook multipoint RS422, dus met meerdere slaves. Zijn 4 draden: 2 TX en 2 RX
benleentje
Golden Member
Het hele idee van deze procedure is juist dat de devices een adres krijgen. Ze hebben dus nog geen adres op het moment dat de communicatie zoals ik beschreef aan de gang is.
Volgens mij kan dat niet.
Wat ik net even snel las moet je op elke module met dipswitches een adres instellen. Nu is dat al oud en achter haalt maar nu zal er in de chip zelf al wel een adres zitten. Het kan best dat je over de bus ook nog een adres kan instellen maar zou je dan een link van dat protocol kunnen laten zien hoe dat zou moeten werken.
RS422 was als ik me niet vergis tussen één bron en één ontvanger
Dat is RS232. RS422 is nog wel steeds een soort RS232 maar zijn op deze bus wel meerdere ontvangers mogelijk met nog steeds maar 1 zender.
https://en.wikipedia.org/wiki/RS-422
Maar hoe weet in dit geval de eerste slave dan dat hij de eerste is en dus als eerste moet reageren?
IK denk dat wel alle modules dezelfde data ontvangen en ze allemaal wel te gelijker tijd willen antwoorden maar dat er toch altijd 1 het snelste is om te reageren en dat is dan denk ook de eerste die het bericht ontvangt.
De slaves kunnen dus onderling geen data van elkaar ontvangen en kunnen ook niet zien of er een andere slave data verstuurt.
Als er collison detectie is dan zie ze wel van elkaar dat er tenminste iemand aan het antwoorden is.
Maar eigenlijk zie ik daar geen probleem in. De zender stuurt een bericht en krijgt antwoord. Als uit dat antwoord dan maar duidelijk is welke module heeft gereageerd. Dan geef je die module alsnog het goede adres. Ik bedoel zolang je maar ergens uit kan herkennen of herleiden om wie het gaat is er toch geen probleem?
Als dan na de adresseer sessie daarna alles goed werkt lijkt me dat goed.
[Bericht gewijzigd door benleentje op (12%)]
Op donderdag 1 augustus 2024 22:08:11 schreef Peter:
[...]
Je hebt ook multipoint RS422, dus met meerdere slaves. Zijn 4 draden: 2 TX en 2 RX
RS422 is altijd 4 draden, differentiëel , om lange afstanden te kunnen doen.
Op donderdag 1 augustus 2024 22:27:38 schreef benleentje:
[...]Dat is RS232. RS422 is nog wel steeds een soort RS232 maar zijn op deze bus wel meerdere ontvangers mogelijk met nog steeds maar 1 zender.
.
422 is geen soort 232, de inhoud kan dezelfde zijn, maar transport is differentiëel, om lange afstanden te kunnen doen.
er is blijkbaar een soort substandaard, waar je meerdere slaves op de bus zet (nooit gezien in de praktijk) maar zoals reeds gezegd: ofwel adresseer je de devices, of je implementeert en anticollision protocol.
en het is belangrijk dat alle devices hoogomig zijn, behalve de devices aan het einde van de lijn, kan allemaal, maar lijkt me om problemen vragen 
Bij 422 is er op één aderpaar sprake van één zender en één of meer ontvangers. Als al die slaves terugkletsen over het andere aderpaar zijn dat dus meerdere zenders op één aderpaar en klinkt het mij als 485 in de oren. En wel de full duplex variant, want twee aderparen.
IK denk dat wel alle modules dezelfde data ontvangen en ze allemaal wel te gelijker tijd willen antwoorden maar dat er toch altijd 1 het snelste is om te reageren en dat is dan denk ook de eerste die het bericht ontvangt.
Kan normaal niet. De ontvangers weten niks van elkaar en kunnen dus ook niet op elkaar wachten. Als er meer dan 1 antwoordt dan blijft er van dat antwoord niks bruikbaars over. Collision detect is normaal geen onderdeel van RS422.
TS gaf aan dat de electronica is ingegoten en niet kan zien of de devices daadwerkelijk parallel staan. Het kan zijn dat er nog iets op/in/tussen de bus zit wat we niet weten en dat de communicatie mogelijkerwijs kan beinvloeden.
henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
Mijn mening: Echt parallel kan niet. De looptijden zijn zodanig kort dat het onmogelijk is om de volgorde te onderscheiden.
Wat wel mogelijk is dat de devices de RS422 bus doorlussen via hun eigen controller. (Zoals de die seriele WSxxxx ledjes bijvoorbeeld).
Ik heb het wel eens ergens gezien.
De RS422 (TX differential bus) van de master wordt dan naar de eerste controller gestuurd en die relayed het signaal door naar de 2-de controller. Er zit dus vertraging in van minimaal 1 byte. Intern in het device heb je dus 2 uarts nodig.
Alle RX differential lijnen hangen dan wel aan elkaar. En bij de ontvanger een terminator (master kant dus).
Een beetje een rare constructie maar het kan wel.
Zoiets dus:
/---------------------\ /---------------------\
RS422 TX pair: +===========>| RX (eerste node) TX |=========>| RX (tweede node) TX |==> externe TERMINATOR
| TX | | TX |
\---------------------/ \---------------------/
V V
RS422 RX pair: TERMINATOR <==============================================
Je zou op iedere node dus minimaal 6 aansluitingen moeten hebben (of 8).
TX in -> TX out
RX (of RX in en RX out, vast aan elkaar, is mechanisch makkelijker)
Dat is relatief makkelijk te controleren, pak 1 losse node en meet op de input wire de weerstand van het input signaal, meet je daar 120 Ohm dan is er een grote kans dat het zo is.
-edit- Maak eens een foto van dat ding met de RS422 aansluitingen? Zijn dat klemmen, connector(s) of wat is het?
Op vrijdag 2 augustus 2024 09:17:13 schreef henri62:
Je zou op iedere node dus minimaal 6 aansluitingen moeten hebben (of 8).
TX in -> TX out
RX (of RX in en RX out, vast aan elkaar, is mechanisch makkelijker)...
-edit- Maak eens een foto van dat ding met de RS422 aansluitingen? Zijn dat klemmen, connector(s) of wat is het?
Klopt, er gaat inderdaad een 6 polige ronde connector 'in' en een 6 polige ronde connector weer 'uit'. 1 +5V, 1 ground, 2 RX en 2 TX.
Het concept wat je beschrijft zou dus heel goed kunnen.
Moet de bus aan het eind niet afgesloten worden door een afsluitweerstand?Ik stel me voor dat er anders reflecties kunnen optreden.
Arco
Special Member
Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
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)