Pagina's

zaterdag 7 maart 2020

RS 485

5-6-2021

Een leuke uitbreiding op dit onderwerp: soort van bibkiotheek.

Met een bibliotheek voor bepaalde functies in een totaalprogramma, waarbij die functies op een andere plaats staan dan het programma, bereik je dat wijzigingen in die functies gemakkelijker gedaan kunnen worden. Ze staan niet overal her en der in het programma, maar mooi centraal.

Nu ben ik al eens meer bezig geweest om bibliotheken te doorgronden, maar dat is nog een brug te ver voor mij.
Als tussenoplossing maak ik nu gebruik van tabbladen van het IDE ontwikkelplatforn van arduino. Die zijn óf pas ingevoerd met een automatische update, óf ik heb ze nooit gezien. Makkelijk zo'n handleiding, die er niet is.

Die tabbladen gebruiken voor functies heeft het nadeel dat alleen de eigenlijke functies in het tabblad opgenomen kan worden. Initialisaties ed. moeten nog gewoon in het hoofdpragramma.
Maar zeker voor zo iets groots als mijn RS485 protocol werkt dit al heel erg goed. En wat een gemak hierdoor! Bij wijzigingen die ik en elk programma wil doorvoeren, hoef ik nu alleen nog maar dat tabblad te vervangen. En dat kan gewoon in verkenner! (is uitgeprobeerd)

1-2-2021

Er doet zich nu een belangrijke ontwikkeling voor, dat het vermelden de moeite waard is.

Dataconflicten.

Ja, ik kon erop wachten, het zou ooit wel eens kunnen escaleren.

Omdat ik twee systemen door elkaar gebruik, de RS485 en de softwareSerial, is het niet uitgesloten dat het een keer mis zou gaan.

Even een stukje diepzinnigheid:

RS485 is gemaakt om over lange kabels data te kunnen verzenden. Dit is ondergebracht in een klein simpel ic-tje. Bij mij de MAX485. Zie op 11-3-2020.
Dit ic-tje kan op twee manieren gebruikt worden:
  1. half duplex. Dat wil zeggen óf zenden, óf ontvangen. Maar altijd over de twee dezelfde draden in de kabel.
  2. full duplex. Dat wil zeggen met de mogelijkheid van én zenden én ontvangen tegelijkertijd. Maar dit over vier draden.
Ik heb toendertijd gekozen voor half duplex.

Op de arduino zelf maak ik gebruik van softwareSerial. Een software variant van de seriele dataversturing. Dit kan in princiepe op elke pen geconfigureerd worden. Het maakt echter wel gebruik van de eigen vaste seriele buffers. Hoe precies, is me niet duidelijk.

De eigen seriele overdracht op de arduino, heeft de eigenschap dat zowel zenden als ontvangen tegelijkertijd kunnen plaatsvinden. Met de lees en de schrijffuncties kunnen die buffers aangesproken worden.

Maar waarom dan de softwareSerial variant gebruiken?
Om de doodenvoudige reden, dat ik anders mengvormen krijg van de netwerkdata  en de monitor-data. Dan weet je helemaal niet meer waarnaar je moet kijken.

De grote vraag is echter, kan die gelijktijdigheid ook in de softwareSerial plaatsvinden.

Ik heb destijds gekozen om dat maar af te wachten. 
En nu blijkt toch dat ik dataconflicten krijg.
En dat is prima te monitoren.
Ik zie duidelijk dat de ene datastroom wordt onderbroken door een andere, waarbij die andere, in dit geval, overheerst. Hierdoor heb ik een verminkte datastroom, en is daardoor onbruikbaar geworden.

Nu ben ik op zoek gegaan naar de eigenlijke RS485 programma's.
Ik heb er twee onder de loep genomen:
  1. Het eigen protocol van arduino.
    Deze is heel vreemd. Het 485-ic heeft een RX en een TX, en nog twee schakellijnen.
    Arduino gebruikt de RX niet, maar schakelt in plaats daarvan de schakellijnen van het ic.
    Je zou dit kunnen vergelijken met een kamer met een lamp. Ik kan de lamp aan en uitschakelen met de schakelaar op de kamer, maar ook met de hoofdschakelaan in de meterkast. Ja, de lamp gaat inderdaad hiermee ook aan en uit, maar ik vind dit niet fraai. Bovendien kreeg ik het destijd niet werkend.
  2. Een protocol van iemand anders.
    Op zich vind ik dit een heel goede, als je erop voorbereid bent, of toch nog start met een nieuw project. Dan kun je er rekening mee houden.
    Want wat doet het?
    Er zijn vele mogelijkheden, die ik eerlijk gezegd niet helemaal goed heb bekeken. Allemaal onder het mom van conflictvermijding van data. Het safe maken van de data.
    Zo is er een echo-functie (teruggeven van dezelde data), waarop eventueel de data opnieuw wordt verzonden.
    Ook foutdetectie, waardoor de data opnieuw word verstuurd.
    En ook nog meer mogelijkheden.
    Of deze mogelijkheden door mij aan of uit gezet kunnen worden, heb ik nog niet bekeken.
    Maar voor dit moment vind ik dit nog te ingewikkeld.
    Bovendien wordt het oorspronkelijke serialprotocol van arduino om zeep geholpen ten behoeve van zijn 485 protocol. Hier weet ik dus niet wat dit voor concequenties heeft voor andere dataoverdracht, bijvoorbeeld de USB, en dus het monitoren van het programma.
Al met al heb ik besloten om mijn huidige methode uit te breiden met een bezet-lijn.
Dit houdt in, dat deze geschakeld moet wordn als er iemand wilt zenden. Alle andere stations kunnen daarop testen. Hiermee hoop ik gelijktijdige verzending te voorkomen, of zéker tot een minimum te beperken. Ik schat zelf in dat die gelijktijdigheid met een factor van enkele duizenden wordt beperkt.

In het beginstadium van de opbouw van het netwerk, ben ik al bezig geweest met de mogelijkheid van stuur-lijnen. Dat heb ik toen niet toegepast, eerst maar eens kijken hoe het zou gaan.

Momenteel heb ik een datastroom van een stuk of tien datatreintjes per minuut. Eén datatrein kan bestaan uit iets minder dan 10 bytes tot enkele tientallen bytes. Maar ondanks de grote pauzes tussen de treinen, die zeer willekeurig plaatsvinden, komen toch dataconflicten voor.
De snelheid van de data is bij mij 4800 bytes per seconde.

Praktijk:

Dit houdt in dat ik één draad extra in de kabel moet gebruiken voor de bezet-lijn. Ik had er 4 van de 8 in gebruik, dus kan prima zo.
En ik moet een I/O poort op de arduino over hebben voor de bezet-lijn. Helaas zal dit nu steeds een andere pin moeten worden, of ik moet meer wijzigen.
Al met al moeten alle staions onder het mes, zowel softwarematig als hardwarematig.


12-4-2020

Nu ik wat meer ga uitbreiden, en dus de bus RS485 ga uitbreden, bedenk ik me toch over de afsluitweerstanden van 120ꭥ, die "noodzakelijk" zijn voor een goede werking over lange leidingen. In het huidige netwerk heb ik ze weggelaten. Over die korte leiding werk dit prima.

Nu herinner ik me een situatie waarbij ik problemen had met de maximale capaciteit van de 5V van het NANO-bordje. Die was voor een bepaalde situatie niet genoeg. Na aansluiting op de losse spanningesregelaar functioneerde het ineens wél goed.

Het zou zomaar eens kunnen zijn dat de RS485 met hetzelfde probleem zit.
Als je 2x 120ꭥ op 5 volt zet, moet er zomaar ineens 80mA geleverd worden. Het maximum is 200mA.

Dus, als ik de communicatie over de extra regelaar wil laten lopen, moet ik daar wel vanaf nu mee beginnen, én het huidige aanpassen. Op een veel later tijdstip alles aanpassen is ondoenlijk, dus nu maar gelijk doen.

Ik heb net weer een testopstelling gemaakt met een netwerkje. Zowel met interne als met externe spanning van 5V gewerkt. In beide gevallen blokkeert de weerstand van 120ꭥ de communicatie.
Ik ga er dan maar vanuit dat het niet nodig is. Ik hoop dat dit in de toekomst geen problemen gaat geven.

______________________________________________________
16-3-2020.
Inmiddels heb ik de RS485 echt operationeel. De ventilatieklep in de keuken kommuniceert met de basis in mijn werkkamer. En dat is kicken!
En in twee richtingen! Stoer hoor.
______________________________________________________
11-3-2020.

De echt eerste RS485 verbinding had heel wat voeten in aarde.
Ik wilde de ventilatie-klep separaat uitvoeren en RS485 gebruiken voor comando's om de klep in te stellen. In het bestaande gedeelte heb ik de RS485 bibliotheek moeten installeren.
Ik kreeg het spul maar niet werkend. Bovendien ontdekte ik dat de hardware, de ontwikkelbordjes, niet 100% betrouwbaar zijn. En dat is een tegenvaller. Want op die breadboards test je eerst alles uit.
Na een aantal dagen zonder bevredigend resultaat, heb ik maar eens 2 programma's naast erkaar gelegd, een werkend programma naast het programma, waarin de RS485 ingepast moest worden. Hierin ontdekte ik dat ik de noodzakelijke setup was vergeten van de bilbiotheek. (:

En nu werkt het dus wel, hoewel nog met korte draadjes.
Straks ga ik er een lange kabel tussen hangen. Ben benieuwd.




De configuratie van de RJ45 stekerverbindingen heb ik inmiddels ook moeten maken. Hiervoor is niks specifiek vastgelegd.
Deze opstelling wordt uiteraard overal in dit systeem toegepast.

De A en B is de communicatielijn.
De signalen zijn altijd tegengesteld aan elkaar. Dit is dé eigenschap van het RS485 protocol. Hiermee kan je lange leidingen van maximaal 1200mtr halen.
Verder heb ik de 12v meegenomen in de kabel. Hiermee voedt ik alle submodules.
In elke module bevindt zich een 12 naar 5 volt omvormer. Zolang de 12 volt niet onder de 7 volt uitkomt, ben ik gewaarborgt over mijn 5 volt, hetgeen de voeding is voor al mijn modules / onderstations.

Als kabel gebruik ik (reeds gebruikte) CAT5 kabel, unshielded. De twisted pair zorgt voor de imuniteit voor andere signalen, ook de pairs onderling.

Het MAX485 ic vormt het hart van de RS485 communicatie. Deze zet de Rx Tx seriele communicatie om in de harde A en B lijn.
Met de R/W lijn kies ik of ik wil zenden of ontvangen. Standaard staat die lijn altijd op ontvangen. Data wordt daardoor niet gemist.
______________________________________________________
7-3-2020.

Afgelopen tijd ben ik druk geweest met het behandelen van het netwerk RS485 protocol. Maar de praktische uitvoering had heel wat werk in petto.

Arduino kent een bibliotheek voor een origineel RS485 netwerk.
Eigenlijk alle fora gebruiken echter software serial als basis, maar met een RS485 ic.
Door het gebruik van het ic bereik je wel de voordelen van de hardware, namelijk gebruik van lange leidingen.
Maar zoals ik al zei, de diverse fora gebruiken niet het originele RS485 bibliotheek. Deze bilbliotheek kent een groot manco, namelijk de pin-bezetting. Nu kan deze aangepast worden, maar is niet volledig.
Ik heb van allles uitgeprobeerd, maar het lukt me echt niet.

Dus moet ik ook mijn toevlucht nemen tot het software serial bibliotheek.
Deze ondersteunt Rx en Tx protocol op andere dan de standaard penbezetting.
Nu ben ik ook door schade en schande wijs geworden, en ontdekt dat niet alle pennen van de arduino geschikt zijn voor seriele overdracht. Wat heeft me dat tijd gekost om dáár achter te komen. Maar eenmaal onderkend, loopt het ineens heel erg soepel.

In een proefprogramma heb ik het volledige netwerk onder de knie gekregen. Deze kan ik nu in het ventilatieproject inpassen, eerst nog in het huidige "thuis" programma, later in het geheel.

Weerstanden.
Diverse websites laten schema's zien met diverse weerstanden in de hardware rondom de rs485 ic.
Er zijn echter ook complete boards beschikbaar, maar die vind ik veel te groot. en te duur.
Ik heb dus een aantal ic's gekocht voor een paar duppies per stuk. En dan zie ik wel wat nog daaromheen gebouwd moet worden.

Websites laten zien dat in ieder geval de A-B lijn afgesloten moeten worden met weerstanden van 120ꭥ. Ook een voortrekken met 560ꭥ naar +5v en gnd wordt aangeraden.
Nou, in elk van die gevallen slaat de ic dicht. maw: doet dan niks meer.
Maar die weerstanden zijn wel essensieel, zeggen diverse websites.
Maar eens uitproberen.
Een kort draadje van 10 cm werkt prima in de testopstelling.
Een hussel kabel, ik denk 50 meter, werkt een twisted pair prima, zonder weerstanden.
Ook ontdekte ik dat de (noodzakelijke???) gnd, die meegestuurd zou moeten worden, geen effect had.

In de toekomst zie ik wel verder, wat het uiteindelijk moet worden.



Geen opmerkingen:

Een reactie posten