Differentiell signalering är mer störsäker.
Till exempel:
I ickedifferentiell så kan en etta vara +5V en nolla -5V.
I differentiell signalering använder du tre trådar A,B och gemensam/Signal-noll.
I förhåkllande till signal-noll:
Etta A=+5V, B=-5V
Nolla A=-5V, B=+5V
Sedan kan det finnas mängder av varianter på detta, till exempel att vid en Etta, så går transienten på A först sedan B och Nolla så Går B först sedan A.
Det säger sig själv att den differentiella signaleringen blir mer störsäker, då sannolikheten att störningar genererar oönskade signaler är betydligt mindre än den ickedifferentiella signaleringen.
RS485: Terminering etc
Re: RS485: Terminering etc
Okej! Så rs232 och rs423 är icke differentiella och därmed mer störnings-känsliga!? Vill man implementera en serieport i ett projekt så är det bättre och mer användbart att använda RS485 än något annat!? Speciellt om man tänker sej nåt nätverk! Finns det några nackdelar? Förlåt inhoppet in din tråd Wedge! 
Re: RS485: Terminering etc
Nackdelarna är högre kostnader, samt extra signaler för kontroll, och ingen hårdvaruhandskakning.
En praktisk sak är ju att du inte kan ansluta den till din PC utan speciella adaptrar/konverters, vilka kostar betydligt mer än RS232
En praktisk sak är ju att du inte kan ansluta den till din PC utan speciella adaptrar/konverters, vilka kostar betydligt mer än RS232
Re: RS485: Terminering etc
Bra tabell med skillnader (och likheterPlatis skrev:Vad skiljer egentligen mellan rs422,423 och RS485?
)http://www.lammertbies.nl/comm/info/RS-485.html
M.v.h DanG
Re: RS485: Terminering etc
Ja, men det är ett litet fel, eller snarare stort fel, RS485/422 är full duplex med 2 par, 423 har jag inte en aning om, men gissar att den är full duplex med två trådar.
Med RS485 och måste man ta i beaktande att den är tänkt som Master/Slave, där mastern talar om vilka slavar som skall sända, och när.
Vid 2-par (4-tråd) kan mastern sända kontinuerligt, och en slav i taget kan sända, samtidigt som mastern.
För RS422, kan det bara då finnas en sändande slav.
Med RS485 och måste man ta i beaktande att den är tänkt som Master/Slave, där mastern talar om vilka slavar som skall sända, och när.
Vid 2-par (4-tråd) kan mastern sända kontinuerligt, och en slav i taget kan sända, samtidigt som mastern.
För RS422, kan det bara då finnas en sändande slav.
Re: RS485: Terminering etc
Fick just en idé beträffande min kommande kabeldragning och nättopologin...
Om jag som TomasL föreslog använder TP-kabel så skulle jag kunna använda ett ledarpar för "in, till enhet" och ett par för "ut, från enhet". I kabeländan där enheten finns kopplas bussen tillbaka, från in till ut. Var jag än hittar en kabelända (början eller slut) så finns det in och ut i den, och jag kan lägga till nya enheter/kablar genom att "seriekoppla" in dem där.
Det kommer hela tiden att vara en daisychain helt enligt regelboken, med terminerbar start- och stoppända. Dessutom blir det två par över för strömförsörjning, whee!
Den elektriska vägen blir förstås dubbelt så lång som summan av kabellängderna, men det är inget problem för min lilla heminstallation.
Finns det någon fallgrop jag missat i detta resonemang?
Om jag som TomasL föreslog använder TP-kabel så skulle jag kunna använda ett ledarpar för "in, till enhet" och ett par för "ut, från enhet". I kabeländan där enheten finns kopplas bussen tillbaka, från in till ut. Var jag än hittar en kabelända (början eller slut) så finns det in och ut i den, och jag kan lägga till nya enheter/kablar genom att "seriekoppla" in dem där.
Det kommer hela tiden att vara en daisychain helt enligt regelboken, med terminerbar start- och stoppända. Dessutom blir det två par över för strömförsörjning, whee!
Den elektriska vägen blir förstås dubbelt så lång som summan av kabellängderna, men det är inget problem för min lilla heminstallation.
Finns det någon fallgrop jag missat i detta resonemang?
Re: RS485: Terminering etc
Sidospår: RS232 är formellt inte tänkt att delas till flera mottagare, men vi är nog rätt många som byggt en enkel passiv sniffer bestående av dels en hane-hona som kopplas in i serie med det man vill lyssna på, och dels en bit kabel med två kontakter som kopplas på två serieportar för att lyssna på trafiken åt de båda hållen.
Åtminstone om man bygger egna interfacekretsar, eller väljer färdiga som har bättre data än vad rs485/422-specen säger, så borde det kunna funka acceptabelt med ett stjärnnät med terminering i änden av varje "stjärnben". Problemen är två, dels så blir det tyngre last med fler termineringar och dels så är risken för dålig signalkvalitet större eftersom termineringen aldrig kan bli helt perfekt (om man inte mixtrar med trimpot och kanske till och med trimkonding och mäter med ett antal olika provsignaler, och sen upprepar det varje gång man byter kabel, och dessutom bara har en enda kabeltyp i hela nätet). Jag skulle inte rekommendera att prova ett stjärnnät.
Däremot går det givetvis bra att ha nån slags aktiv "hub/switch" i mitten av ett stjärnnät, men om du kör ett enkelt nät med ett enda par med duplex på det paret så behöver huben/switchen ha intelligens för att styra datariktningarna.
Om du däremot kör två par på varje ställe i nätet och använder ena paret för signal från en "busmaster" och andra paret för signaler till "busmastern" så behöver huben inte vara särskilt intelligent. En ingångskrets från busmastern driver utgångskretsar för alla andra kanaler. En utgångskrets till bussmastern drivs från en grind som helt enkelt grindar ihop signalerna från ingångskretsar för alla andra kanaler. Om huben kan sitta på samma ställe som busmastern så behöver det inte vara rs485/rs422 mot busmastern utan vad du nu redan har för port på den. (Du kan t.ex. ha en USB-FTDI-krets i huben om busmastern är en dator, då kan du ju dessutom mellan busmaster och hubb lätt ha åtminstone de fem meter som USB är specat för).
Wedge: din idé med att "vända" genom varje enhet borde funka, fast det kan bli rätt lång kabel. Du får väl fundera på ifall ledningarna bara ska gå genom varje enhet passivt eller om du ska skicka signalen som i en slinga där enheterna normalt repterar signalen från in till ut, men när enheten själv vill sända något så skickar den ut sin egen data på ut.
Du lär ändå behöva fixa-dona med protokoll för att styra upp vem som ska sända vid vilket tillfälle, så du behöver knappast något avancerat för att styra vidareskickning eller egen sändning för enheterna. Jag skulle nog bara lagt in en vanlig grind som lägger ihop signalerna (så att det blir skräpdata ut ifall det både kommer in data på ingången och enheten själv sänder samtidigt).
Det problemet skulle du ändå få även om du kopplar allt passivt med ett datapar och styr sändning av/på på varje interfacekrets.
En annan variant ifall du bara har några decimeter mellan enheterna och bussen är att sätta drivkretsarna precis vid bussen.
Viktigt att veta är att RS485/RS422/RS423 är bara en elektrisk spec, den säger egentligen inget om eventuellt protokoll. Det finns inte mycket till de-facto-standard heller, mer än att man verkar oftast köra seriedata där överföringen har startbit, databitar, eventuell paritetsbit, stoppbit(ar) på samma sätt som vid RS232. Det finns däremot ingen riktig standard för hur man kommer överens om vem som sänder vid halv duplex eller liknande.
Den enda egentliga standardiseringen som använder detta är DMX512. I övrigt verkar det mest vara rätt så tillverkarspecifika grejer om jag fattat rätt.
Jag håller för övrigt med TomasL om att TP-kabel är en bra idé och att det är en bra idé att köra strömförsörjningen över TP-kabeln.
Åtminstone om man bygger egna interfacekretsar, eller väljer färdiga som har bättre data än vad rs485/422-specen säger, så borde det kunna funka acceptabelt med ett stjärnnät med terminering i änden av varje "stjärnben". Problemen är två, dels så blir det tyngre last med fler termineringar och dels så är risken för dålig signalkvalitet större eftersom termineringen aldrig kan bli helt perfekt (om man inte mixtrar med trimpot och kanske till och med trimkonding och mäter med ett antal olika provsignaler, och sen upprepar det varje gång man byter kabel, och dessutom bara har en enda kabeltyp i hela nätet). Jag skulle inte rekommendera att prova ett stjärnnät.
Däremot går det givetvis bra att ha nån slags aktiv "hub/switch" i mitten av ett stjärnnät, men om du kör ett enkelt nät med ett enda par med duplex på det paret så behöver huben/switchen ha intelligens för att styra datariktningarna.
Om du däremot kör två par på varje ställe i nätet och använder ena paret för signal från en "busmaster" och andra paret för signaler till "busmastern" så behöver huben inte vara särskilt intelligent. En ingångskrets från busmastern driver utgångskretsar för alla andra kanaler. En utgångskrets till bussmastern drivs från en grind som helt enkelt grindar ihop signalerna från ingångskretsar för alla andra kanaler. Om huben kan sitta på samma ställe som busmastern så behöver det inte vara rs485/rs422 mot busmastern utan vad du nu redan har för port på den. (Du kan t.ex. ha en USB-FTDI-krets i huben om busmastern är en dator, då kan du ju dessutom mellan busmaster och hubb lätt ha åtminstone de fem meter som USB är specat för).
Wedge: din idé med att "vända" genom varje enhet borde funka, fast det kan bli rätt lång kabel. Du får väl fundera på ifall ledningarna bara ska gå genom varje enhet passivt eller om du ska skicka signalen som i en slinga där enheterna normalt repterar signalen från in till ut, men när enheten själv vill sända något så skickar den ut sin egen data på ut.
Du lär ändå behöva fixa-dona med protokoll för att styra upp vem som ska sända vid vilket tillfälle, så du behöver knappast något avancerat för att styra vidareskickning eller egen sändning för enheterna. Jag skulle nog bara lagt in en vanlig grind som lägger ihop signalerna (så att det blir skräpdata ut ifall det både kommer in data på ingången och enheten själv sänder samtidigt).
Det problemet skulle du ändå få även om du kopplar allt passivt med ett datapar och styr sändning av/på på varje interfacekrets.
En annan variant ifall du bara har några decimeter mellan enheterna och bussen är att sätta drivkretsarna precis vid bussen.
Viktigt att veta är att RS485/RS422/RS423 är bara en elektrisk spec, den säger egentligen inget om eventuellt protokoll. Det finns inte mycket till de-facto-standard heller, mer än att man verkar oftast köra seriedata där överföringen har startbit, databitar, eventuell paritetsbit, stoppbit(ar) på samma sätt som vid RS232. Det finns däremot ingen riktig standard för hur man kommer överens om vem som sänder vid halv duplex eller liknande.
Den enda egentliga standardiseringen som använder detta är DMX512. I övrigt verkar det mest vara rätt så tillverkarspecifika grejer om jag fattat rätt.
Jag håller för övrigt med TomasL om att TP-kabel är en bra idé och att det är en bra idé att köra strömförsörjningen över TP-kabeln.
Det är en bra beskrivning på differentiell signalering rent generellt, men RS485/RS422 använder +5V och 0V. Att man ibland ser -5V i beskrivningar beror på att någon angett spänningen på B relativt A (eller vice versa) istället för att ange spänningar relativt jord.TomasL skrev:I differentiell signalering använder du tre trådar A,B och gemensam/Signal-noll.
I förhåkllande till signal-noll:
Etta A=+5V, B=-5V
Nolla A=-5V, B=+5V
Re: RS485: Terminering etc
Jodå det gör det: Modbus till exempel.Det finns däremot ingen riktig standard för hur man kommer överens om vem som sänder vid halv duplex eller liknande.
Re: RS485: Terminering etc
Modbus är väl en standard som i sin tur använder RS-485 ?
Mao ingen standard, utan flera standarder..
Mao ingen standard, utan flera standarder..
Re: RS485: Terminering etc
Nej, Modbus är en kommunikations standard, dvs ett standardiserat protokoll, RS485 är ett av medierna man använder, TCP/IP är ett annat.
Modbus är naturligtvis oberoende av hur och vilken typ av kablar/elektriskt protokoll man använder.
Dock är det så att det digitala protokollet måste kunna hantera det fysiska, annars lär det inte kunna funka.
Modbus är en standard, Ethernet en annan och RS485 ytterligare en., dock är Ethernet och RS485 elektriska standarder och säger ingenting om hur data skall skickas.
Till skillnad från till exempel I2C där standarden både specar det elektriska protokollet såväl som det digitala.
Modbus är naturligtvis oberoende av hur och vilken typ av kablar/elektriskt protokoll man använder.
Dock är det så att det digitala protokollet måste kunna hantera det fysiska, annars lär det inte kunna funka.
Modbus är en standard, Ethernet en annan och RS485 ytterligare en., dock är Ethernet och RS485 elektriska standarder och säger ingenting om hur data skall skickas.
Till skillnad från till exempel I2C där standarden både specar det elektriska protokollet såväl som det digitala.
Re: RS485: Terminering etc
Ethernet såsom t.ex 10BASE-T specifierar både dataformatering och elektrisk signalering.
Re: RS485: Terminering etc
Nja, den specificerar spänningsnivåer och modulering, dock inte hur trafiken ser ut.
Du kan hitta på precis vad du vill med exempelvis ethernet, när det gäller digitala protokoll.
Du kan hitta på precis vad du vill med exempelvis ethernet, när det gäller digitala protokoll.
Re: RS485: Terminering etc
Den specifierar preamble sekvens, byte synkronisering, var MAC skall finnas, CRC beräkning, packetpause osv. Däremot inget om vad som finns i "payload".
Re: RS485: Terminering etc
Förekommer det någon implementering av Ethernet som är inkompatibel med de gängse förekommande? D.v.s. som inte använder mac-adress och en ethertype som inte krockar med vad andra gör?
Re: RS485: Terminering etc
Det beror ju helt på vad man menar med "ethernet".
Ethernet inbegriper ju i princip hela 802.3-familjen, med massa olika understandarder.
Att säga ethernet i det här fallet betyder ju ingenting.
Ethernet inbegriper ju i princip hela 802.3-familjen, med massa olika understandarder.
Att säga ethernet i det här fallet betyder ju ingenting.
