Arduino(MDuino) RS485 bekötés és élesztés.

Gondjaim vannak... Csinált valaki MDuinoval RS485 nulláról?

Van egy csavart érpáras kábelem amin a következő drótok vannak:

1 pár gnd-

1 pár +12 V

1 pár ULA +5 V

... és az AB vezeték.

Nem tudom mit hova az MDuino21+  -on.  Az AB vezetéket föltettem az A és a B pinre (rá van írva a PLC-re). Próbáltam kommunikálni a rákötött cájggal, de tök homály. Szerintem néhány lépést kihagytam. Csinált valaki már ilyet?

Hozzászólások

Mduinot nem ismerem, de Arduino+RS485-ot hasznaltam mar.

Alapesetben 3 pint hasznalsz, TX, RX (ez a 2 lehet software-es is), es egy iranyt, ami megadja, hogy a 485 buszt irja vagy olvassa-e. Gondolom van rajta egy 485 IC, onnan kiderul, hogy a mikrokontrollered melyik labaira van kotve, ha a doksiban nincs.

A strange game. The only winning move is not to play. How about a nice game of chess?

Létezik olyan TTL RS-485 konverter, ami az irányt az adásból találja ki. Pl: https://www.conrad.hu/p/joy-it-joy-it-konverter-modul-fekete-2481412

Ehhez elég táp, GND, TX & RX az Arduino felől. Én ESP32 + ESPHome duóval használok egy ilyet és ESPHome-ban a MODBUS RTU is pofon egyszerű.

$ grep -c egy$ word.list
100

Igen, ezert is irtam, hogy alapesetben 3 lab kell. Ha megnezed a modul kepet, az a 7404, dioda, kondi meg par ellenallas allithatja elo az irany jelet. Ha mikrokontrollered van, egyszerubb abbol kivinni, ha van eleg labad. De amugy PC-n hasznaltam mar olyan USB-s konvertert, ami szinten megoldotta az iranyt maganak.

Az RX+TX-bol is ott a hardware-es, de ha masra mar hasznalod, hasznalhatsz software-eset (softserial lib), vagy irhatsz olyat, ami 1 pinen elintezi a kettot, ha mar ugyis half-duplex kommunikaciorol van szo. Extrem esetben akar az ATMEGA-kban levo analog komparatorral (AIN0 es AIN1 lab) is meg lehet oldani par passziv alkatresszel, de igy nem kapod meg a vedelmet a kulso zajoktol.

A strange game. The only winning move is not to play. How about a nice game of chess?

Melyik eszköz lesz a MASTER? a PLC vagy az MDuino? A kommunikációhoz az A-B vonal kell (elvileg csak, de jobb a GND-t is bekötnöd ha be lehet).
Rövid a távolság? Sebesség? Mert rövid távolságnál és kis sebességnél pl 9600-nál lehet még a lezáró sem fontos egy teszthez. Kell lezáró a busz két végére 120 ohm. 
MODBUS vagy valami szabványos protokollon akarsz kommunikálni, vagy valami egyedin?
Ha nincs oszcilloszkópod akkor köss egy LED-et a vonalra párjuzamosan. (mintha egy másik egység lenne) A LED pedig egy kb 1k ohmos ellenállással legyen ne magában csak a LED. Ha villog akkor megy rajta adat. (egyik bekötési móddal alap esetben sötét a másik esetben alap esetben világítani kell a LED-nek ha a vonal meg van hajtva)
Két oldal sebessége természetesen azonos legyen, meg minden egyéb is. 

A cájg egy gammasugárzás mérő, egy mduino21 plc szólítgatja. 19200-zal megy, egyedi protokoll, 15 méter. Kérdés-válasz.

Nézem az doksikat, úgy látom kell a kommunikációs modulnak 5vdc, ez kijön a cájgból valszeg be kell kötni.

Amatőr kérdés: A-t az A-hoz vagy a B-hez?

Az eddigi törődést köszönöm.

> Sol omnibus lucet.

Ha valamiért az A tegyük fel B akkor sem lesz gond, csak invertált lesz a jel. Tehát fenti LED-es ellenörző villogna, de nem fogná meg a soros port adatkereteket semmi. Ilynekor nem az A-A és B-B kötés kell, hanem meg kell fordítani. De feltételezzük, hogy jól van ráírva.

Vannak eszközök amin kapcsolható a lezáró ellenállás, vagy fixen benne van. Erre az oldalra akkor nem is kell 120 ohm. 
https://www.planetanalog.com/wp-content/uploads/images-common-planetana…
kb. ilyen egy RS-485-s busz. Ha az első vagy utolsó egység tartalmaz lezárót akkor oda már nem kell.

Az jön le nekem a tanácsokból, hogy tápot kell neki adni ( van rá pin vdc+5) és pöcögtetni kell az adairány kaput. Na majd meglátjuk. Manana...

Köszönöm az eddigieket mindenkinek.

> Sol omnibus lucet.

RS485 half-duplex, a MASTER küld kérdést, vagy parancsot, arra jön válasz egy kis késleltetéssel, hogy legyen időd átváltani vételre az irányt. A transciver IC másik oldalán ilyenkor Rx lábon jön amit a SLAVE küld éppen... majd a SLAVE lesz újra vevő és a MASTER adó a Tx lábbal. Ez egy alap felállás szokott lenni általában. 

A LED-es tesztert csináld meg, lásd, hogy egyáltalán jön-e ki jel. Ha ugyanígy küldesz adatot és vételre teszed akkor pedig nem kell villognia a LED-nek. Célszerűbb a villogós tesztet alacsony sebességen végezni, pl 1200 bps-en (biztos van olyan itt aki még meg is mondja a villogásból mit küldesz éppen :) )
Esetleg oscilloszkóp (tárolós) vagy logikai analizátor, pl egy olcsó USB-s nincs a közeledben? Valahogy a kimenetet adás és vételről tesztelned kellene a MASTER oldalon. 

Ha már okoskodunk a végére akkor tegyük is tisztába. Half-duplex amikor egy adatutvonalon keresztül megy az oda és vissza adatforgalom is felváltva. Nem is működhetne másképpen, hiszen az adat sérülne. Mindig csak egy irány mehet egy időben.
Amire te gondolsz az az RS-422, amit még életemben nem láttam csak rajzon és talán régi Mac gépeken van ilyen. Itt lehetséges Full-duplex jelátvitel, mivel két adatutvonala van. Viszont itt is a MASTER - SLAVE felállás van, mivel az egyik vonalon van egy darab adó (M) és sok vevő (S), a másik vonalon pedig egy vevő és sok adó.

A MASTER-SLAVE felállás nem csak MODBUS sajátosság. Az egyedi protokollja is így működik, és minden ami ilyen vonalakon kommunikál. Sőtt nagyon sok RS-232-es eszköz is, ahol pl. egy PC kezdeményez kéréseket és az eszköz csak válaszolgat, végrehajt. Pl. nem tud szólni, ha történik valami, hanem lekérdezni kell azt időszakosan.

Hírtelen 1 dolog jut eszembe ami megkavarhatja az embert, az a BiDi-s optikai konverter, de ott is két adatútvonal van, igaz 1 szál optikai kábelben. Két különböző hullámhosszon megy az adat, így nem akad össze.

Ha másképpen látod, tudod, kérlek fejtsd ki, hadd tanuljak róla még. 

A szabvany tartalmaz full-duplex konfiguraciot is, igy leteznek full-duplex transceiverek is.

Half-duplex amikor egy adatutvonalon keresztül megy az oda és vissza adatforgalom is felváltva.

Nem. Half-duplex ha egy adott pillanatban csak egyiranyu lehet a kommunikacio. Klasszik ethernet is 2 erparon/adatutvonalon tudott csak full-duplex kommunikaciot elerni.

En magam fejlesztettem multi-master protocolt RS-485 felett es  valahogy mukodott :). Rengeteg collision detection/avoidance modszer van amit lehet itt is alkalmazni.

CD / CA nem full duplex lesz, hanem észreveszi hogy más akar beszélni és akkor valamilyen megoldással ezt összehozzák. De egy időben csak egy beszélhet egy irányba egy azon közegen.

A multimaster RS-485 is ugyanúgy half duplex.
Igen úgy pontos ahogy írtad, mert lehet más adatútvonalon is a vissza irány viszont időben csakis egy irányban megy az adat. Pl. RS-232 half duplex esetben ilyen. Addig nem adhatsz amíg a másik adása nem fejeződött be, tehát adatot veszel. Az RS-485 mivel egy azon közegen beszélget mindenki az más nem is lehet, csakis half-duplex.
A full duplex-hez nem csak a közegnek kell megfelelőnek lenni, hogy ne keveredjen a két irányú adat, hanem az adatot fogadó egységeknek egy időben képesnek kell lennie küldeni és fogadni adatot.

Vannak csavartérpáros kommunikációk akár full-duplexre ahol valahogy különválasztható az két egység kommunikációja. RS-485-n ugyanúgy van az adás és vétel oldal kommunikációs paramétere, tehát ha valaki beszél akkor az másik beszélőt is zavarná. 

Szerk.: Amúgy biztos tudunk a végtelenségig találni megoldásokat amik kacifántosabbá teszik az eszmefuttatást. :) 
Az 1 érpáras fullduplex ethernet érdekelne. Valami ipari megoldásban talán láttam ilyet, gondolom könnyebb kábelezhetőség miatt. Normál esetben úgy tudom az is half duplex lehet csak. A kettő érpáras ami 1,2,3,6 zöld és narancs érpárakat használja, az általában 100Mbit és full duplex.
Érdekel az információ, mert sosem tudni, hogy mikor jön jól egy megvalósításkor.

Ezeket a dolgokat probalom ervekkel cafolni amiket leirtal:

"RS485 half-duplex, a MASTER küld kérdést"

Nem kizarolag. Az EIA/TIA-485 szabvany-ban nincs MASTER se SLAVE, ez ahogy irtam egy atviteli szabvany. Amire te gondolhattal az valoszinuleg a MODBUS RS-485-on (RTU/ASCII/Plus).

"A MASTER-SLAVE felállás nem csak MODBUS sajátosság. Az egyedi protokollja is így működik, és minden ami ilyen vonalakon kommunikál."

Valoban nem, azert irtam, hogy valoszinuleg arra gondolsz. Mi az egyedi protokoll itt, mire gondolsz? Once again az RS-485 az egy atviteli szabvany. "RS-485 only specifies the electrical characteristics of the generator and the receiver: the physical layer. It does not specify or recommend any communications protocol" 

Azaz amikor azt mondod RS-485 akkor ezen a szinten nem lehet szo kommunikacios protokollrol. Ennek az a feladata, hogy jelet (a nap vegen biteket) vigyen at A-bol B-be ahogy a szabvanyban le van irva.

"CD / CA nem full duplex lesz, hanem észreveszi hogy más akar beszélni és akkor valamilyen megoldással ezt összehozzák. De egy időben csak egy beszélhet egy irányba egy azon közegen."

Nem is irtam, hogy az lesz. Ugy lesz full-duplex, hogy mondjuk olyan drivert hasznalsz es akkor bar meg mindig megeshet, hogy nem lesz collision-free a kommunikacio de attol meg full-duplex marad. Azert mert adott pillanatban lehet ketiranyu a kommunikacio, hisz ket csatorna van. Kacifantos.

Az 1 érpáras fullduplex ethernet érdekelne.

Tobbek kozott automotive ipar hasznalja a 100BASE-T1-et, erdekes megoldas es jo. De mostmar van multi-drop Ethernet is ami szerintem izgalmasabb :) 10BASE-T1S. Nezd meg pl ezt a PHY-t.

A protokollt mint olyat te képzelted oda még a "pro" szó sincs benne az előző bejegyzésemben.

Hidd el tisztában vagyok hogy az RS-485 az adat reprezentációja átviteli közegen. Jelen esetben feszültségszintek az A és B vonalon, ezt fogadja egy komparátor a másik oldalon ami érzékeli, hogy melyik polaritással jön éppen a jel, ebből lesz 1 vagy 0. Ha fordítva kötöd be, ezért lesz invertált. 
Az amit linkeltél meghajtó nem lesz full duplex RS-485-n hiszen egy időben nem mehet két jel. Viszont RS-422-n full-duplex is tud lenni.
Amugy. hogy beszélgetünk, találtam olyat amikor ilyesmi meghajtóval és talán 6db ellenállással trükköztek és full duplex lett 1 érpáron, de az meg már nem RS-485, mert ahogy írtad az RS-485 nem a protokollt definiálja (amugy ilyet nem mondtam hogy azt), hanem az adatátvitel módját 1 csavart érpáron.

A M-S felállás sok esetben megvan, más kommunikációs megoldásokban is, mert általában egyszerűbb mint egy multi-master vagy nevezzük egyenrangú megoldásnál. Igen a MODBUS is ilyen, de M-Bus, 1-wire, DMX és sok egyedi protokoll is, ahol a MASTER a kommunikáció kezdeményező, a SLAVE pedig a válaszoló vagy hallgató. Változhat a kommunikáció közben az is hogy éppen adó vagy vevő. DMX pl egy irányú, de DMX-RDM már két irányú, ott változik menet közben az adatirány, amikor a SLAVE válaszol. 
Ahogy leírta neki kellett üzenetet küldeni a sugárzásmérőre amire választ kellett várnia. De mindenféle vacak, napelemes inverterek, BMS, stb... ugyanígy működik.

Pont ezt a drivert néztem, de annó úgy döntöttem, hogy kihagyom. Eléggé egyedi ahhoz, hogy nehéz legyen megjavítani, hibát keresni. Külön kellene még eszköz stb... Így lett normál ethernet meghajtó a uC-n.
Majd lehet egy labor teszten kipróbálom.

A protokollt mint olyat te képzelted oda még a "pro" szó sincs benne az előző bejegyzésemben.

Probaltam osszegezni amit ebben athreadben irtal, ezert ideztem, igy semmit nem kepzelek oda ezt mind te irtad. Az lehet, hogy felreertelmezem amit irsz, de olvasd vissza. Gyakorolj onkritikat es csinalj amit szeretnel a vegeredmennyel :) De amugy megvan, hogy mi az amit szerintem nem jol ertelmezel:

Az amit linkeltél meghajtó nem lesz full duplex RS-485-n hiszen egy időben nem mehet két jel.

Az amit linkeltem az egy "Full-Duplex RS-485 Transceiver". Es most nem a gyarto hazudik, tenyleg az. Nem attol lesz valami full-duplex, hogy egy idoben egy csatornan mehet "ket jel", hanem hogy lehet-e egyszerre ket iranyban kommunikalni. Az, hogy van olyan eset, hogy van utokozes az egy masik dolog, attol meg full-duplex-es.

"A full-duplex (FDX) system allows communication in both directions, allows this to happen simultaneously."

Rákerestem már, de azon kívül, hogy tisztáztam, hogy a protokoll egyedi-e vagy MODBUS esetleg, amire jött is válasz 20 perc múlva. Nem volt semmi protokoll kérdés. Ott tisztázott lett, hogy egyedi protokollon van.

Viszont eddig úgy voltam vele hogy RS-485 1 érpár, amin osztozik az adás és vétel, ha így tetszik. Az RS-422 pedig 2 érpár, aminek külön vonala van adásra és vételre. 
Pedig, RS-485-ből is van 2 érpáras, ez a full duplex megoldás. Annyi a különbség az RS-422-höz képest, hogy RS-422 csak 1 kijelölt MASTER lehet, a RS-485 full duplexnél pedig lehet multi master, azt, hogy hogy lesz éppen valaki a M azt az adott protokoll dönti majd el, nem pedig az RS-485. 

Én még 4 vezetékes RS-485-t nem láttam. Valahogy a két vezetékes (1 érpáras) megoldás ugrik elsőre be. Jelen esetben is 2 vezetékes RS-485-ről volt szó, mivel A és B csatlakozásról beszélgettünk. Amit feltüntettek ugyan mindkét készüléken, de az egyiken hibásan. Erre is volt egy tippem, ha már nagyon nem akar menni, mi lehet a gond típusu hibakeresésnél.

Mindig tanul az ember. Tehát van 2 érpáras, 4 vezetékes RS-485 full-duplex megoldás.
Nem RS-422, mert nem 1 MASTER lehet, hanem változhat, hogy ki a MASTER. Ez esetben RS-485.

Nem a szabványról beszélek - bevallom, meg sem néztem -, hanem a megvalósíthatóságról. Ha holnap bemennék a munkahelyemre, s azzal fogadnának, meg kell csinálni full duplex soros átvitel egyetlen szimmetrikus érpáron, vagy egy adatvezetéken és egy GND-n, akkor megcsinálnám. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az RS-485 mivel egy azon közegen beszélget mindenki az más nem is lehet, csakis half-duplex.

Ezt nem látom be, miért kellene így lennie. Nem feszültséggenerátorosan kell hajtani a vonalat, hanem áramgenerátorosan, ekkor annak feszültségét meg tudod változtatni, és ez a jel szuperponálódik arra a jelre, amely más adó által keletkezett. Utána már csak annyi a dolgod, hogy a vevőben megjelenő A+B jelből kivonod a saját adásod, amelyet nyilván ismersz minden időpillanatban, így lesz (A+B)-A = B, ami éppen a másik oldal adása. Tehát lehet ugyanazon a vezetéken full duplex kommunikációt folytatni. Olyannyira, hogy a régi analóg telefonokon is full duplex volt az analóg hangátvitel ugyanezen az elven azzal a különbséggel, hogy a saját hangból egy keveset belecsatoltak a hallgatóba azért, hogy ne tűnjön süketnek a telefon, ha beszélsz.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ahogy fentebb írtam láttam ilyen megoldást, full-duplex 1 érpáron és pár darab ellenállással elérték. Viszont az már nem RS-485 mert nem teljesíti annak a követelményeit. 

Ha a kábel két végére teszek 1-1 egyforma transciver-t amit akár egyszerre használhatok adásra és vételre is, akkor ugyanugy fognak beszélni. Ha ezek egyszerre beszélnek akkor abból hibás adatátvitel lesz. Varázslatokkal, meg hogy éppen az adat egy részét egy vívőre tenném, eltolnám a feszültség szinteket, vagy egymásból kivonnám stb... ahhoz már olyan dolgok kellenek ami miatt nem lesz RS-485 a vonal.
Vagy mégis az lesz? Tehát dobhatok rá még egy pár vevőt és adót? A 3. eszköz vevője honnan tudja éppen melyik jelnek kell a DO-ra mennie?

Elgondolkodtattó a dolog. Viszont iparban a biztosra megy az ember, nem pedig a varázslatra és a lehet jó lesz megoldásra. Maradok a 2 vezetékes szigoruan half-duplex RS-485-nél. :)

Az RS–485 vagy TIA/EIA-485-A (európai elnevezése pedig ISO/IEC 8482) egy elektronikai szabvány, amely meghatározza a használandó adó- és vevőegységek jellemzőit digitális buszrendszerek számára.

Digitális, tehát van 0 és 1 - bármit is nevezzünk annak.

A fentiek miatt nem analóg.

Definició szerint nem duplex, csak haf duplex.

A specifiikáción kívül eső entitásokat nem hívjuk RS485-nek. A telefonvonalat sem.

És ami a legfontosabb: Nem protokoll, csak layer. (amely meghatározza a használandó adó- és vevőegységek jellemzőit digitális buszrendszerek számára.)

Persze emberi jogod bárminek is ellentmondani, csak nem biztos, hogy van értelme. ;)

Másik szálban kifejtette, hogy elméleti síkon mondta. Ha mondjuk kellene ilyet csinálni, hogy egy érpáron full duplex kommunikáció. 
Ami amugy létezik is. Hasonlóan mint 1 RF kábelen a DOCSIS vagy a BiDi vagy xPON optikai szálon. Fizikai közeg azonos, de valami miatt mégis elválaszott az adott közegben az egyes kommunikáció.

Húúú... ez ilyen sörözős berugós megvitatós téma. :D

Szerkesztve: 2022. 10. 05., sze – 21:10

AR/Mduinoval nem, de bare metal AVR-rel (beleertve ATmega328P-t is) mar szamtalanszor ;) Tehat:

 - az altalanos sztenderd labkiosztasu RS485 transciever ic (pl: MAX485) 1-es labat az MCU RX-ere kotod, a 4-es labat az MCU TX-ere, a 2-es meg 3-as labat (/RE, DE) pedig osszekotod es egy valamelyik GPIO-ra rakotod.  Legyen a pelda kedveert ez most a PD2. 

 - ugyanez a masik oldalon is, es az A-A, ill B-B vezetekeket kotod ossze sodrott erparral - es ahogy fentebb is irjak, hasznalj lezaro ellenallast ha par meternel hosszabb a drotod. 

 - Beallitod az UART-ot es a PD2-t lehuzod foldre (PORTD &= ~(1<<2)).

 - Venni ugy tudsz mint barmilyen UART-on (RXNE bit csekkolasa)

 - Adatot kuldeni pedig: eloszor PD2-t felhuzod (PORTD |= (1<<2)), kuldesz adatot a szokasos modon, majd megvarod mig a "transmit complete" bit ujra 1 lesz. Ezutan elengeded/lehuzod a PD2-t. 

A "szuk keresztmetszet" az az lehet, ami a szokasos UART-ozashoz kepest kulonbozo hogy adatot kuldeni akkor tudsz mikor az UDRE bit az 1, viszont nem akkor kell lezarnod az RS485 vonalat (azaz lehuzni a PD2-t) mikor az UDRE bit az 1 lesz, hanem amikor a TXC bit lesz 1. Ha nem igy teszel, akkor az utolso byte az lemarad :)

Én azt várom, hogy egy ipari cuccon (MDUINO plc) ne kelljen rátaknyolnom egy lezáróellenállást. Bekötöm a vezetékeket és kész. Amúgy a sugárzásmérőn és a PLC-n eltérő az AB polaritás: a minuszt kötöttem a minuszház és a pluszt a pluszhoz és nem a beűkódot néztem.

A PLC-t half-duplexbe kapcsoltam (DIP), ez elég egyértelmű, nem lehet elrontani.

Az RS485 könyvtárban az RS485 objectum meghívásával a normál Serial-on kommunikál gyakorlatilag a soros portjaim száma megduplázódik, de mindkettő ugyanazon a vezetéken (standard usb-n, amin felprogramozni is kell) kommunikál.

Itt tartok most. A cájg még mindig süket.

> Sol omnibus lucet.

Én azt várom, hogy egy ipari cuccon (MDUINO plc) ne kelljen rátaknyolnom egy lezáróellenállást

Nem rossz a gondolat, de az RS485 az egy busz es nem egy pont-pont osszekottetes. Szoval a gyarto nem fetetelez(het)i hogy a cuccod az RS485-os vonal ket vege valamelyiken vagy kozepen valahol foglal helyet... persze lehet hogy olyan megoldas is hogy egy jumperrel v. kis kapcsoloval tudod ki-be kapcsolgatni a lezaro ellenallast, attol fuggoen hogy a drotozasban ugye hova teszed. Ez kulturaltabb megoldas mint egy sima "rataknyolas", nyilvan :] 

Attól, hogy kisebb a bitráta, még ugyanúgy marha meredekek az élek. Persze értem, hogy messzebb van a bitközép, és addig lecseng az őrület, de azért na. Sávkorlátozni volna jó, alacsony du/dt volna kívánatos. Meg a hullámimpedanciával történő lezárás. Sőt, ha még precízebb vagyok, talán annak komplex konjugáltjával, de nem nagyon szokott képzetes rész lenni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A valóság elég komplex, bár nem konjugált. ;)

A "marha meredek élek" előállítását egy-egy tranzisztor végzi. Létezik nagysebességű driver, de készítenek slew rate határolt kivitelt is - pontosan a meredekség csökkentése miatt.

Láttam olyan drivert is, ami nem ilyen egyszerű volt, mert 10 MHz és néhány km távolsághoz már nem elegendő. Általánosságban a hullámimpedancia helyettesítése rezisztív lezárással kis hibát okoz.

Viszont sokszor kimarad az a tény, hogy a használt vezeték impedanciája nem 120 Ω. A valódi RS485/MODBUS stb. ipari kábelek elég drágák. Helyette megfelel pl. az UTP vagy ipari ethenet kábel, de annak csak 100 Ω az impedanciája. Így aztán az RS485 lezárása != 120 Ω.

LED-es teszter vagy valami van? Látod, hogy jönne ki adat az RS-485-n valahogy? 

Első körben mindenféle egyéb dolog nélkül ennyit kellene elérni, hogy villogjon a LED teszter, vagy lásd oszcilloszkópon vagy bármi más megoldással, hogy van adat küldés.
A leírás sem teljesen egyértelmű nekem, hogy mi mit csinálhat. Ki kell próbálni. Akár egy közvetlen IO portokat birizgáló kicsi kóddal. A leírásban benne van, hogy az RS-485 hová csatlakozik.

Először is köszönöm minden kinek a segítséget. Megoldódott a probléma, egyesettanulmányt megér:

 

1. PC --> Mduino21+ -> BNS-98S doziméter kommunikáció RS485-ön :: ez volt a feladat.

2. Süket volt, mint a nagyágyú, se kép, se hang.

---

Élesztés:

 

1. Kiiktattam egy lehetséges hibaforrást: az Mduinot. Vettem egy USB/RS486 konvertert (DIGITUS) és ezen keresztül a dozimétert közvetlenül a PC-re kötöttem. Megírtam a doksi szerinti protokollt, csekkeltem a kimenő adatokat (kiírtam a vincseszterre is), minden bit a helyén volt. A doziméter továbbra is süket maradt.

2. Szkóppal rámértünk, a kimenő forgalom rendben volt. Végigmértük a lábakat, a kábelt mindent. Minden jónak látszott. Telefonos segítség a gyártótól: 50 mA áramfelvételt kell mérni itt-meg-itt és kaptunk egy szervízparancs szekvenciát. Persze közben próbáltuk csereberélni a jelszinteket (invertálás),  és a bitsorrendet is. Az egyik kombinációra a szervízparancsra jött egy értelmes válasz. (Ja, a 130 ohmot, azt odaadtuk neki.)

3. Ezzel a fizikai beállítással kiküldtem az üzemi lekérdező parancsot: csönd... Néztem ki a fejemből.

4. A lekérdező parancs egyik bájtját elkezdtem pörgetni. Az egyik értékre értelmes válasz jött. Rossz volt a doksi! Szívás^3! Már csak a float típusú adat konvertálása volt hátra, fordított volt a bájtsorrend, mint a PC-n.

5. Következett az Mduino élesztése. Csináltam egy rövid kábelt és direktbe összekötöttem a PCbe dugott RS485 konverterrel (plusz a pluszhoz, minusz a minuszhoz, föld a földhöz). Itt jegyzem meg hogy a doziméter és az Mduino A/B jelőlése nem egyforma. Írtam egy rövid programocskát, ami az Mduinoból az RS485-ön keresztül kilök egy hosszabb 0xff sorozatot. Ez voltmérővel is detektálható. A huncutság abban van, hogy melyik pinen kell adni/venni és ehhez hanyas számú Serial objectumot kell használni. Az eredeti Arduino RS485 könyvtár nem volt jó, az objectumot nem a DEFAULT-ra, hanem a Serial3-ra kell definiálni (RS485.cpp)!

6. Volt még némi szinkronitási probléma az adás-vételt illetően, de ez már favágás volt csak.

Tehát él az összes eszköz, mostmár csak össze kell őket drótozni, biztos vagyok benne, hogy menni fog. A kulcsmomentum a szervízparancs ismerete, a szkópos háttér és a Serial3 definíció volt. Köszönet: régi harcostársamnak, Szalay Róbertnek (szkópos felderítés), Petrányi Jánosnak (Gamma Zrt.) és a linuxos közösségnek.

 

Üdv mindenkinek: meditor

 

Ps: A Dunakanyarban, a Börzsöny lábánál 200 nSievert/h háttérsugárzást mértem (épületen belül), ez az országos átlagnál magasabb, itthon (Köcsk, Vas megye) 100 nS/h-át. A figyelemztetési szint 250 nS/h, a riasztási szint 500 nS/h.

> Sol omnibus lucet.

Mert meg akartad úszni az elektronikával való foglalkozást, nem akartad bemocskolni a kezed oszcilloszkóp mérőfejjel, meg effélék. :P Nem lehet mindent csak software-ből, firmware-ből megoldani.

Jó, hogy leírtad, bemutatja, hogy milyen a hardware- és firmware-fejlesztők hányattatott sorsa, amikor több hiba rakódik egymásra.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szabadtéri az eszköz, de egyelőre csak laborkörülmények között használom (== tesztelem). Megy majd ki egy Comet meteorológiai szonda, egy szélmérő és egy kamera (felhőkép) kíséretében.

A project itt: https://hup.hu/node/177239

A hikvision kamra rész itt: https://hup.hu/node/168074

> Sol omnibus lucet.

A mi műszereinkben is van ilyen cím, amelyre mindenképp hallgat az eszköz, mert mi van, ha valaki elfelejti, milyen címre lett programozva, vagy éppen fel kell programozni az új címet. Jó, nálunk csak 5 bites cím van, végig lehetne scannelni, de szebb, gyorsabb, ha van broadcast.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

OKÉ, megy a cájg MDuinoval is. Azért volt egy-két érdekesség még, de megbocsájtottam az Arduino 1.8.19-nek. Ja, az usb-táplálás nem elég az RS485-höz, kéri a rendes 24 voltot (csakúgy, mint az ethernet!)

> Sol omnibus lucet.