Ahoj,
chtěl bych si vyvinout modulární systém s MCU (něco jako PLC). Přemýšlím nad základnou, do které bych zasunoval jednotlivé moduly. Přemýšlím nad FULL Duplex 485 nebo SPI. Základna max cca 30cm dlouhá, cca 10 modulů. Jakou by jste zvolili sběrnici s ohledem na rychlost a spolehlivost?
I2c 
ale to sa o rychlosti hovorit neda, i ked podpora 400khz a tueim ze uz aj 1Mhz. Vyhoda ze je priamo adresovana tak ze jednoduchsie raidenie.
RS422 (Duplex 1-10Mb, CAN 1Mb max.) Rozhodně né I2C ani SPI - přenos dat není nijak zabezpečen. CAN není trivka, ale pokud data dorazí, tak jsou zaručeně v pořádku. Na RS485/422 je třeba implementovat vhodný protokol. Taky bys měl vzít v úvahu možnosti použitého MCU - periférie, přerušení, DMA - tak abys ho nezahltil jen komunikací.
Lehce přes 2 roky provozuju vlastní PLC s RS485. Moduly jsou různě umístěný po polích rozvaděčů, délka sběrnice max 2 metry a v klidu to šlape. I s poměrně jednoduchým protokolem to chodí spolehlivě. Používám max 15 adresovaných modulů.
Asi použiji RS485 po dvou drátech. Jednoduchý vlastní protocol, požadavek/odpoveď, kdy budu periodicky obnovovat data ze slave jednotek.
Na slave chci použít nějaké malé ARMy. Na master zvažuji ARM buď s Cortex M0+ na 72MHz nebo Cortex M4 na 168MHz, oba s DMA. Vše asi 5V řada kinetis KE od Freescalu(NXP).
Billy Bob Bean- jakou používáš rychlost?
RS485 je dobrá voľba. Full duplex si neviem zmysluplne predstaviť. Ak by cez jeden kanál mohli teoreticky naraz vysielať do mastra všetky Slave, musel by si ešte robiť špeci arbiter aby si vôbec niečo štatisticky prijal ak by viaceré naraz cheli niečo vysielať.
Výhoda RS485 je vysoká odolnosť a veľmi nízka cena budiča.
Sieť typu Master-Slave je na malú PLC ako stvorená. Arbiter zbernice je dostatočne použiteľný. Token Ring je zas zbytočne komplikovaný.
Zabezpečenie správy s paritou a CRC na konci správy.
Ak nemusíš, nevymýšľaj vlastný protokol. Použi MODBUS. Je dostatočne jednoduchý a nájdeš naň veľa príkladov či aj SCADA systémov, ktoré zväčša MODBUS podporujú. Dokumentácia je zdarma na nete.
Pre zmysluplnú prácu vôbec nie je potrebné implementovať všetko čo norma vyžaduje. Stačia Ti príkazy na zápis čísel a na načítanie čísel. Je Tvoja vec, ako s číslom naložíš. Či si ho v stanici rozložíš na bity alebo ho použiješ ako číslo. Jedinú značnú nevýhodu MODBUSu vidím v použití prenosu čísel ako Big Endian. To značne komplikuje prenos viac bajtových čísel.
Aj prenos správy cez zbernicu I2C alebo SPI samozrejme zabezpečenie môže mať. To závisí od zvoleného protokolu. Nikde nie je napísané, že sa musí cez I2C komunikovať tým pračudensým protokolom pre komunikáciu s EEPROM.
Ak sa na prenos cez I2C alebo SPI posavíš ako k prenosu množiny bajtov, nič Ti nebráni na konci zaradiť CHS alebo CRC a správu mať chránenú.
Ak je na jednej I2C okrem iných procesorov aj nejaká tá EEPROM, FRAM, či RTC, potom stačí v medziprocesorovom protokole použiť na prvom mieste bajt na ktorý bezpečne EEPROM a spol nebudú reagovať a je to vybavené.
I2C má obrovskú výhodu:
-
na komunikáciu stačia dva vodiče
-
protokol má na hw úrovni vyriešenú arbitráž a preto ak je napríklad na doske RTC obvod, môžu cez jedinú zbernicu k nemu pristupovať viaceré procesory.
-
protokol je zároveň synchrónny. To znamená, že nezáleží na presnom časovaní Mastra. I2C sa dá preto s úspechom implementovať softérovo.
Obdobne ako 1-wire.
Díky za vyčerpávající odpověď. Myšlenka RS485 full duplex byla, že kdybych měl slave jednotku, která by měla jeden blok dat pro čtení a druhý blok dat zápis např. 20/20B, tak bych poslal příkaz pro zápis+data a slave by mi rovnou posílal data ke čtení. Tím si myslím, že bych zrychlil dobu přenosu mezi masterem a slave stanicí.
Pokud bych měl jednu jednotku pouze výstupní a druhou pouze vstupní, tak by to nemělo význam.
Plc simatic pouzivali modbus na komunikaciu medzi jednotlivymi plc.
Ako to riesili v nutri neciem ale pinov tam bolo pozehnane.
RS422 (to je duplex z RS485) sa dá použiť len pre dve zariadenia. Tak ako RS232.
Ak cheš použiť na zbernici zariadení viac, treba k tomu vybrať príslušné rozhranie.
Ak má zariadenie posielať do mastra údaje, tak môže:
A) posielať vždy všetky - to ale môže trvať veľmi dlho
B) posielať len to o čo je požiadané.
B) je správne 
Už len preto, že cez sériovú linku môžem chcieť zariadenie preprogramovať a tak podobne a v kontexte práce s ním potrebujem zvyčajne inú odozvu.
Ak potrebujem inú odozvu, potom musím do Slave poslať info, čo od neho chcem. Táto správa musí byť najprv celá prijatá, aby som overil jej správnosť kontrolou CRC. To sa bez načítania celej správy nedá.
Je teda dosť času aby Master prepol RS485 na príjem a vypočul si odpoveď.
Až keď si je Slave istý, čo sa od neho žiada, až potom môže buď zapnút/vypnúť relátko, alebo odoslať odpoveď s požadovanými dátami. Inak odpoveď treba do Mastra poslať vždy. Inak sa Master nemá ako dozvedieť, že správa prišla do Slave v poriadku a netreba ju zopakovať. lebo jedna vec je mať správu chránenú CRC alebo paritou. No táto ochrana slúži iba k tomu, aby sa vedelo, či správa prišla poškodená, alebo je s najväčšou pravdepodobnosťou v poriadku. Ochranné polynomy CRC sú vyberané tak, aby odhaľovali typické chyby pre to ktoré prostredie. Preto sú polynomy používané v priemysle a iné polynomy pre použitie v telekomunikáciách.
Viac o tom je napríklad v:
en.wikipedia.org/wiki/Cyclic_redundancy_check
Lebo logicky, keď prenášam 64B a “chránim” ich 2B, tak musí existovať obrovské množstvo kombinácií, ktoré budú mať rovnaké CRC. Ak sa moja správa vplyvom rušenia “premení” na inú správu, ktorej však prislúcha rovnaké CRC, nemám ako zistiť chybu prenosu.
Ale nemaj z toho obavu. Takéto prípady sa vyskytujú prakticky zanedbateľne a tieto veci fungujú veľmi spoľahlivo. Ak sa bojíš omylom zapnutého relátka, vždy môžeš jeho stav preniesť ako 0x00 alebo 0xff. Ak by nastala nevhodná zmena bitov počas prenostu tak, že by sedelo výsledné CRC, ľahko to vieš zistiť. No nezabudni si ešte potom nejako aj ošetriť adresu zariadenia, aby správu náhodou nedostala iná stanica. Aj preto slušné protokoly majú v odpovedi aj adresu Slave. Aby mal Master istotu, že správa doputovala tam kde mala. A aj preto treba vždy zasielať od Slave odpoveď.
Problém rýchlosti komunikácie sa rieši nasledovne. Nemá zmysle prenášať veľmi rýchlo kvantum dát dokonca s presným časovaním, ako napríklad údaje z prejazdovej váhy, kde je potrebný prístup k AD na úrovni 1ms.
Alebo prenášať stavy binárnych vstupov pre počítanie počtu impulzov z vodomera či elektromera. Rýchle deje je potrbné vždy spracovať na mieste a cez komunikačnú linku treba prenášať len spracované dáta. V prípade snímania vodomera je to aktuálny počet impulzov. Lokálny čísleník úplne stačí 8bitový. Z neho sa iba zistí prírastok impulzov za rozumný čas. Tento prírastok sa potom pripočíta k “veľkému” číselníku v Mastri.
Čo sa rýchlostí týka, celkom bezpečná rýchlosť je 9600Bd. S ňou beží RS485 na sieti v celkovej dĺžke 7km v jednom nemenovanom priemyselnom podniku so spoľahlivosťou komunikácie nad 99.8% v hodine. Počet staníc 48 a topológia pripomína rozvetvený strom. Dávať repeatre do odbočiek sa neosvedčilo. Tvar signálu bol po inštalácii v každom bode meraný osciloskopom a bol všade prakticky učebnicový.
Používali sme tam náš ASCII protokol.
Prechod na MODBUS a rýchlosť 19200Bd by viedlo cca k štvornásobeniu prenosovej kapacity.
Pre Tvoju predstavu o dátovej priepustnosti komunikačnej linky RS485:
19200Bd, 2ms pre pripravenie odpovede na strane Slave a odvysielania odpovede pri balíčkoch (výzva + odpoveď) vo veľkosti:
32B je priepustnosť čistých dát 1,36kB/s (8E2) a 1,58kB/s (8N1)
Pre predstavu, touto priepustnosťou sa dá zrealizovať 42 transakcií a
v každej z nich nastaviť stavy až 138 relé za sekundu.
To znamená, že môžeš meniť stav 138 relé každých 24ms,
alebo za sekundu nastaviť 5796 relé v 42 rôznych zariadeniach za sekundu.
64B je priepustnosť čistých dát 1,47kB/s (8E2) a 1,73kB/s (8N1)
Pri rýchlosti 115200Bd, 2ms
32B 4,62kB/s (8E2) a 5,02kB/s (8N1)
64B 6,23kB/s (8E2) a 6,99kB/s (8N1)
Aj keď je pomer komunikačných rýchlostí 6x, dátová priepustnosť sa zvýši iba 3,4x pre 32B transakcie (jedna správa tam a druhá naspäť, spolu 32B) až po 4,6x pre 64B balíčky a 8E2
pri 8N1 je síce o niečo vyššia priepustnosť, avšak za cenu vzdania sa akeho takeho kontrolného mechanizmu paritného bitu
AK je staníc príliš veľa, tak je dobré použiť nejaký koncentrátor. Napríklad pri 80ks staníc s oneskorením 2ms - ak vôbec stihnú do takéhoto času pripraviť odpoveď - je hluchý čas 80*(2+2) = 320ms, čo je skoro 1/3 sekundy. No tak je lepšie nechať zlučovať dáta koncentrátory.
Jak jsi prosím tě spočítal tu propustnost?
Ľahko, použil som Exel
Napríklad:
32B má správa od Mastra a aj od Slave spolu. Napríklad pre fiktívny jednoduchý, ale účinný bajtovo orientovaný protokol Master pošle správu:
- 1B adresa Slave, (MSB smer vysielania M->S/S->M) a 7b adresa Slave
- 2B subadresa s 1b príkazom WR/RD (2^15 adries z vnútorného priestoru Slave)
- 1B počet bajtov ktoré sa majú preniesť, napríklad 20B
- 2B CRC
Slave mu odpovie napríklad že:
-
1B to som ja, oslovený Slave. Keďže sa jedná o prvý bajt správy, musí tu byť taká hodnota, ktorú iný Slaave nebude považovať za správu pre seba. To že sa jedná o začiatok správy je jasné, lebo sa pred týmto bajtom nejaký čas nič nevysielalo. Napríklad tie 2ms.
-
2B posielam Ti nejaké moje vnútorné status bity, napríklad či som nebol náhodou reštartovaný, alebo či nemám nejaký interný problém z niektorou z periférií, ale kľudne tu môžu byť trvalo aj stavy nejakých vstupov a alarmy. Netreba kvôli nim potom robiť extra komunikácie.
-
1B posielam Ti toľko bajtov kolko si chel, nie že by si nevedel, ale pre veľmi silnú kontrolu a ak by sa náhodou bajty preháňali cez I2C zbernicu, Master musí vedieť koľko bajtov si má načítať.
-
20B požadovaných údajov
-
2B CRC
Koniec správy sa pozná napríklad v MODBUSe tak, že po dobu 3,5 násobku trvania prenosu bajtu sa nič neprijme. To samozrejme nebráni počítať čas od posledného vysielania presne od ukončenia príjmu posledného bajtu.
Pre rýchlosť 19200Bd a 8N1 je čas bezpečne považovaný za ukončenie vysielania daný 3,5 * 10/19200 = 1,82ms.
Alebo bude protokol orientovaný ako ASCII (ale priepustnosť bude menej ako polovičná a dátovo ešte menej) a potom
MASTER:
- 1B úvodný znak, napríklad ‘m’ , akože vysiela Master
- 2 ASCII znaky adresa Slave napríklad “2F”
- 4 ASCII znaky subadresa a príkaz napríklad “2AC7”
- 2 ASCII znaky počet, napríklad “02”
- 4ASCII znaky CRC
- 0x0d ako koncový znak správy
spolu 14 bajtov
SLAVE:
- 1B úvodný znak, napríklad ‘s’ , akože vysiela Slave
- 2 ASCII znaky adresa Slave
- 4 ASCII znaky status bity
- 2 ASCII znaky počet
- 4 ASCII znaky pre požadované dva dátové bajty
- 4ASCII znaky CRC
- 0x0d ako koncový znak
spolu 18 bajtov
Spolu je to v rámci jednej transakcie 32B. Predpoklad je, že medzi dvoma vysielaniami bude ťažko medzera kratšia ako 2ms už len kvôli spracovaniu údajov na strane Slave, alebo pri príprave novej transakcie na strane Mastra. Niekedy to môže byť viac niekedy menej. Ale ako priemer je to dobrý odhad.
Dokonca sa v niektorých systémoch nastavuje koľko času od príjmu posledného bajtu sa nesmie začať vysielanie a čas sa pohybuje okolo 5-100ms. Je to kvôli prepnutiu RS485 ale aj kvôli rôznym RF modemom staršej výroby, ktoré sa môžu na komunikačnej trase vyskytovať a ktoré automaticky transparentne prenášajú dáta a ktoré potrebujú na prepnutie ďaleko viac času ako rýchla RS485-ka.
Takže
1 transakcia, dve vyslané správy.
Čas oneskorenia 2x2ms. nikdy nemôže byť čas spracovania a prípravy správy nulový.
rýchlosť 19200Bd. Jeden bit sa bude vysielať 1/19200.
Pre 8E2 sa bude pre jeden bajt vysielať 12 bitov (start, 8 data, parita 2 stop). To je 625us.
32B* 625us = 20ms
20ms + 2x2ms = 24ms
Do sekundy prenesiem 41,67správy, čo je cca 42 správ.
Pre 8N1 to bude 32*10/19200 + 0,004= 48,39 správy, čo je približne 48 správ.
Ale v každej správe prenášam hore dole 32B.
Takže pre 8E2 to bude cca 42*32=1344B (1,34kB)
a pre 8N1 to bude cca 1536B (1,54kB)
Údaje v mojom predchádzajúcom príspevku sú o niečo väčšie, lebo čas na spracovanie mám nastavený o niečo kratší ako 2ms a nechcelo sa mi to kvôli príspevku všetko prepočítavať, ale rádovo to sedí.
Koľko je z tých prenesených bajtov skutočne užitočných, to už závisí na voľbe protokolu
Tu uvažovaný ASCII protokol je dobre spracovateľný a čitateľný “po ceste”, no z 32B sa preniesú iba 2B užitočných údajov. To je výťažnosť 100*2/32 = 6,25% v tomto konkrétnom prípade.
Pre binárny protokol je to už lepšie, lebo tam je percento užitočných údajov 100 * 20/32 = 62,5% v tomto konkrétnom prípade. Čím bude balík údajov väčší, tým bude efektivita vyššia no dostupnosť údajov z rôznych staníc bude horšia, lebo sa na ne zriedkavejšie dostane.
Takže si to stačí dať pre rôzne rýchlosti, veľkosti správ a prenosové nastavenia jednoducho do Exelu a je to. Nemám čas po sebe všetko kontrolovať, tak snáď som v tom celom nenarobil veľa chýb
Zo všetkého je tiež vidieť, že naháňanie sa za vyššou prenosovou rýchlosťou a´la Ethernet nemá až taký efekt na množstvo skutočne prenesených dát.
Uvažujme reálne pre bežnú prenosovú transakciu tých 32B pre ovládanie domácej či priemyslenej automatizácie. Samozrejme je to iné pri streamovaní hudby či obrazu. Ale bavíme sa o ovládaní relátok, sledovaní stavov, teplôt a tak podobne.
1000ms/4ms = 250prenesených správ za sekundu i keby prenost trval nekonečne krátko. Prakticky viac nie a to je len cca 5,2x viac ako pri rýchlosti 19200Bd 8N1
pre 115200Bd a 8N1 je priepustnosť 32B transakcií
čistý čas jednej transakcie 32*10/115200Bd = 2,78ms
Čas aj so spracovaním údajov je 2,78ms + 2ms+2ms = 6,77ms
To je maximálne 148 správ za sekundu, čo je len 3x viac ako pri 19200Bd
pre 1MBb je to 231 transakcii, čo je len 4,8x viac ale nároky na prenosovú rýchlosť sú 52x vyššie.
To znamená, že ak sa nepracuje s DMA tak prerušenie kvôli prijatiu ďalšieho bajtu je až 52x častejšie. Ak sa náhodou v MCU vykonáva niečo čo musí zakázať prerušenie, ľahko hrozí strata bajtu.
DMA tiež nie je samospasiteľné, lebo tak či tak treba chodiť ten bufer sledovať. Ak sa to robí občas, narastajú prestoje a z 2ms oneskorenia odpovede môže byť ľahko ďaleko dlhší čas, čím zas ďalej degraduje výhoda použitia vysokej prenosovej rýchlosti.
Z hľadiska kompromisu zvyšovanie rýchlosti nad 57600/115200 už nič podstatné neprináša. Skôr hrozí zle prijatá správa pre nie dostatočne rýchle spracovanie prerušenia od UARTU v MCU bez DMA, prípadne pre zákmity na hranách signálu pre odrazy na vedení, či zvýšená citlivosť na rušenie.
V dnešných hw UARTOCH sa stred bitu testuje 3krát (napríklad ATmega1284P) a za prijatú hodnotu sa považuje prevládajúca hodnota.
Čas medzi vzorkami je 1/16 alebo 1/8 času trvania bitu. Pre 19200Bd je to 3,25us alebo 6,5us. Ak rušenie trvá kratšie ako tento čas, automaticky sa vyfiltruje.
Rušivý impulz od prepätia v čase trvania 8/20us (EN 62305, ochrana pred prepätím) zasiahne maximálne pol prenášaného bitu.
Pri rýchlosti 115200Bd je to už však 0,54us či 1,08us. To sú časy, kedy jednak už odrazy na vedení pri nie dostatočneu impedančnému prispôsobeniu môžu svojimi zákmitmi spôsobiť zlé načítanie hodnoty bitu v jeho strede a rušivý impulz 8/20us vie náhodne rozhodiť stavy bitov až vo vyše troch prenášaných bajtoch. Náhoda, že pri rozhodení bude sedieť aj parita je oproti 19200Bd značná. Tam jeden impulz rozhodí maximálne bit. Samozrejme, sú aj iné druhy rušenia, nie iba odrazy na vedení a jednotlivý impulz. No vždy ide o pravdepodobnosť a o to, čo skutočne od prenosu požadujem.
Moc díky za info. Když jsem to počítal, tak jsem zapomněl na mezeru mezi zprávami u modbus RTU.