Szerintem férre értettetek nekem olyan megoldásra van szükségem amellyel egész hálózatot tudok működtetni.
A központ minden alegységgel kapcsolatban van ezenkívűl, még egyes alegységek is kapcsolatban vannak egymással. Ez egy kis pókháló lenne.

Na erre alkalmas a RS485. Lehet vele 32 vegpontot felfuzni a buszra.

Már bocsáss meg, de ha egy kérdést nem tudsz feltenni, akkor ne hivatkozzál arra, hogy mi értettünk félre valamit! Két PIC, az KÉT PIC.

Szabvány szerint az RS232 15m. De a kérdés már tárgytalan, mint láthatod...

Hasznalhato nagyobb tavolsagra is, de csak alacsony Baudrate mellett(300 bps). A kerdesre ugyis a RS485 a megoldas. Persze eloszor csak ket PIC-rol beszelt a kollega.

Ez most kinek szól?

Szeretném ismételten megkérdezni,hogy ezzel az égetővel milyen tipusu PIC-eket lehet programozni és,hogy mennyire megbizható!?Előre is köszi a választ

Keresőt próbáltad használni?

Bocsánat ha pontatlanul fogalmaztam a "férre értettek" nem csak azt jelentheti, hogy nálatok van a gond hanem azt is (mint jelen esetben is), hogy a kérdező egyén nem fogalmazott elég pontosan.

Remélem ezzel a képpel már elég egyértelmű lesz. A nyilak a kommunikáció irányát jelölik. A betűk pedig az egyes PIC-eket.

Akkor ez megvalósítható az RS485-ös szabvánnyal?

Szia!
Megvalósítható RS-485 protokollal, de nem tipikusan ilyen kommunikációra való. Ebben az esetben a kommunikációnak master-slave jellegűnek kell lennie. Van egy kitüntetett master pl. "A" egység, mely vezényli az egységek közti kommunikációt. A master egyenként lekérdezi a slave egységeket, hogy van-e küldendő üzenet, ha van akkor a slave elküldi az üzenetet és annak címzettjét, majd ezt az üzenetet a master továbbküldi a címzett slave egységnek. Nagyon fontos, hogy itt mindig kell egy master, aki vezényel, a slavek csak akkor szólhatnak, ha a master megszólítja őket. Ebben az esetben ez a kommunikáció nem túl hatékony, nagy az overhead. Itt pl. a CAN előnyösebb lenne, bár az sokkal bonyolultabb protokoll.

Szia Watt!
Terveztem az programozódnak egy panelt (Mini V4)hamár úgy is maratok.
Kicsit szellősre sikerült Remélem nem szed össze valamilyen zavart? Sima nyomtató kábelt alakítottam át 1,5m hosszú ugye ez sem gond?

Igen, de a lényeg pont az lenne, hogy az A egység kiesése után is tudjanak kommunukálni az egyéb egységek pl F, C-vel. Erre milyen megoldás van?

Előző oldalon olvastam, hogy "felnőtteknek"... Nem lenne jobb odabiggyeszteni a topik címe után, hogy "haladóknak" vagy valami, ha már van "PIC kezdőknek" topik?

Olvastad a cikket?
Van ám égetőkkel foglalkozó topic is!

Maradjon is így! Köszi!

CAN, de már írtam az előző hozzászólásomban is.

Ethernet.
De sajnos ismét azt kell mondjam ez itt off, pontosabban ha nem is off, de van erre jó néhány szakosodott topic!

Arról nem tudtam, hogy már volt...

De az ethernethez is kell egy hub, nem.

Megirtam elkuldtem de aztan letoroltem a valaszom mert ez itt mar tenyleg nagyon erosenn off!

De akkor hol kérdezzem meg?

En probaltam egy egydrotos kommunikaciot csinalni, ami PBUS protokollal mukodott. Kiserleti jelleggel meg csinaltam, de nem nagy tavolsagra. A lenyege az volt, hogy egy kozponti allomason keresztul kuldtem uzeneteket a slavek kozott. Tehat a slave elkuldte a sajat cimet, es a cel slave cimet a masternak, majd a master tovabbkuldte a cimzett slave-nak. A cimzett slavetol kapott valasz alapjan valaszolt a kommunikaciot kezdemenyezonek. Persze lehet direktbe is cimezni barmelyik allomasrol barmelyik allomast. Szerintem mehet nagyobb tavolsagra is, csak kell felhuzo a buszra, es le kell vinni a sebesseget. Egy tobberes kabelon megoldhato a kommunikacio es a tapellatas is. A neten lattam hasonlot a Jakab Peter oldalan.

De ha a master kiesik, akkor megszűnik a kommunikáció.
A másik, hogy ha master van, akkor csak az indíthat kommunikációt, különben káosz lesz.

Egyetlen megoldás van, ha az ethernet mintájára ütközés kezelést programozunk le, ahol bármely forrás indíthat kommunikációt, de meg kell győzödnie, hogy az el is ért a vonal végére. Itt nincs hely és idő, hogy leírjam ez hogyan megy(minimális adathossz, max. kábelhossz, időzítések stb.), de lehet neked nem is kell, mert tudod!

Aki meg nem tudja, ne ilyet akarjon építeni, mert nem fog menni, és itt nincs lehetőség megértetni! És ez tényleg off.

Itt az a lenyeg, hogy mindenki hallgat, es ha neki cimzett uzenetet vesz, akkor valaszol ra. Barki kezdemenyezhet uzenetet barkivel. Viszont ha a cel allomas nem valaszol, akkor valoszinu nincs fennt a halon. Nalam csak egy bizonyos cel erdekeben volt egy master. Nem fontos kijelolt masternek lenni a rendszerben. Mellekesen meg minden uzenet tartalmazott CRC-t, es ha nem volt jo nem valaszolt ra. Ezzel a protokollal ha barmelyik allomas kiesik, meg nem all le a kommunikacio a tobbi allomas kozott. Az ethernet is lehetne megoldas, de sokkal bonyolultabb mint HW, mint SW szinten. Egy riaszto rendszernel peldaul egy lassu atvitel is elegendo, nem szukseges 56 kBaud sebesseg, es ezzel megszunnek a jel terjedesi ido, es jelszint problemak. En pl 1200 Baud sebesseget hasznaltam, es szepen dolgozott a rendszer.

Na de mi van, ha egyszerre 4-nek jut eszébe megszólítani valakit és nem tágítanak, mivel nem kapnak választ folyamatosan elárasztják a vonalat.

Nem konkrétan ethernetet írtam, hanem az ethernet mintájára kialakított kommunikációt. Ez lehet a te egyvonalas megoldásod is, de akár rs422 is, ha a meghajtók elviselik ha több is rádumál a vonalra, vagy I2C szerű, lényeg, hogy fullduplex legyen.

Én itt több kevésbé jó megoldást vélek látni. Az ethernet túl bonyolult, szerintem nem érdemes erre felhasználni. Az RS-485 meg a 422 alapú megoldásokat is sántának vélem, mert igazán master-slave alapon működnek jól, de mi van, ha kiesik a master. Ehhez annyit hozzáfűznék, hogy megoldható más módon, ha minden egység a saját időszeletében beszélhet a vonalra (hasonlóan a FlexRay-hez), így az ütközés elkerülhető, hátrány, hogy szinkronizálni kell az egyes egységeket. Megoldható ugyan, de óraszinkronizációs algoritmus kell, ami tovább bonyolítja a dolgot, valamint ha egy egység hibásan kezd működni, akkor megbolondulhat a rendszer.
Éppen ezért javasoltam a CAN protokollt.
Előnyei:
- üzenetszórásos rendszer, mindenki megkapja a buszra küldött üzeneteket.
- roncsolásmentes ütközésdetektálás: CSMA/CD (mint az Ethernet esetén)
- nagy távolság: 1200 m
- nagy sebesség 1 Mbit/s
- hibavédett, ha egy egység meghibásodik lekapcsolódik a buszról
- Microchipéknek is van CAN vezérlő IC-je
Szóval szerintem ebben az esetben ez a leghasználhatóbb megoldás, bár kétség kívül az UART- nál bonyolultabb.

Lehet csinalni arbitraciot, es mivel mindenki egy deroton log, le tudja olvasni hogy volt e kollicio. Ha volt akkor egy idoosztasos alapon, beosztjuk a buszt. Elso beszel, valaszt var, es ha tudjuk hanyan lehetnek a vonalon, akkor ez nem lehet gond, mert a tobbi akkor fog beszelni, amikor az elozo befejezte a kivancsiskodast. Mikor a vegire ernek, lehet elolrol kezdeni. Lehet generalni szabad vonal uzenetet, es erre be lephet akinek mondanivaloja van. Mint beszeltuk, nem szukseges 10 GB atviteli sebesseg, azert nem egy nagy "was ist das" megirni ugyesen a programot, hogy ne tudjanak osszeveszni az egy szal droton. Egy ilyen rendszernel nem nagyon hataroz az atviteli sebesseg. Persze egy gyors adatfeldolgozo, szabalyzo rendszernel ez mar nagyon lassu lehet a normalis mukodeshez.

Köszönöm a válaszokat!

Nekem eddig ahogy utána olvastam és a hozzászólásaitokat olvasom a CAN protokoll tetszik a legjobban.

Tudna valaki adni egy linket vagy fájlt ahol le van írva (lehetőleg magyarul) hogyan kell csinálni egy CAN hálózatot PIC-ekkel?

Sajnos magyar szakirodalmat eddig nem nagyon láttam (nem is nagyon kerestem ), elvétve lehet találni magáról a szabványról magyar nyelvű anyagot.
A Microchip honlapján érdemes körülnézni, van saját CAN vezérlő IC-jük is, valamint AppNote-ok a használatról.
Microchip/CAN

Nem tudom, nekem egyet sikerült találnom. Csak ez nem kifejezetten PIC-ekről szól.
Azért köszi.