A dolog csak akkor működhet, ha vagy azonosítója van mindegyik panelnek, vagy mindegyik panel tudja, hogy hány db panel van a gyűrűben és annak megfelelően állítja be a működését.

Igen, de programozáskor azt is be kellene égetni ugyan úgy.

Azt lehet, sőt azt be is kell majd menüben állítani hogy hányan vannak a körben. De ezt említettem is az eszmefuttatásomban hogy három panelmérő esetén a harmadikként érkezett adat a panelmérő saját magáé lesz, csak az előzője. Kettő panelmérő esetén pedig az utolsó kettő adat lesz a két panelmérő 'szellemképe'. Ezeket a panelmérők ugyan úgy megkapják, feldolgozzák és kijelzik, a menüben csak a negyedik és a harmadik adat kijelzését kell letiltani. De ha nem tiltják le az sem nagy gond, csak hülyeség is ki lesz jelezve.

Nem feltétlenül kell azt programozáskor.
a) megoldás: amelyiken van gomb+kijelző, azon lehetne azon keresztül is állítgatni
b) megoldás: ha RX/TX vonala van a panelnak, arra lehet kötni egy TTL-RS232 átalakítót, vagy egy USB-TTL átalakítót (pár száz Ft az ebayen), és azon keresztül is lehet őt programozni

A lehető legelegánsabb megoldást szeretném. Ebbe nem fér bele az hogy beégetem a programot PICkit3-mal, aztán előveszek egy másik áramkört amit újra rádugok a laptopra meg a PIC-re aztán külön adok neki egy egyéni azonosítót. Ez bonyolult. Kijelzőn nyomógombokkal állítani nem jó mert akkor át lehet állítani és így már nincs egyedi azonosítója mindnek, így előfordulhat hogy két ugyan olyan azonosítójú beszélget egymással. Ez megint hibalehetőség.

Generálja le a PIC az első bekapcsoláskor a kódot és tárolja le. Mennyi esélye van, hogy két egyforma véletlenül egymás mellé is kerül? A 32bites azonosító elégnek tűnik.

Ez egy nagyon jó ötlet!

Szerintem _vl_ is erre gondolt, ha jól értettem.

Akkor még egyszer próbálkozom, mert látom, hogy valamiért átsiklás történt a megoldásomon.
A legelegánsabb megoldáshoz valóban nem kell se master, se id.
Ha menüben beállítható az eszközök száma, akkor vizsgálni se kell semmi. Indulásnál az eszközök addig csendben vannak, amíg a beállításokat tároló eszköz körbe nem küldi, hogy hány eszköz lesz. Erre minden eszköz beállítja a verem hosszát. Elkezdik egymásnak küldeni az adatokat úgy, hogy balra léptetik a vermet és a legszélsőbe beteszik a saját adataikat. Ahogy körbeért, onnan kezdve mindig ugyanabban a pozícióban lesznek az adatok, ki lehet őket írni. A sorrendet az határozza meg, hogy fizikailag miként vannak a láncon. A forgatás azért kell, mert nincs master, hogy indítson és nincs id, helyette ez viszi be a rendszerbe az azonosítót. Az első körbeforgás után minden eszköznél az többi eszköz fix és változtathatatlan sorrendje áll be az adatcsomagban, ami egyértelmű azonosítást jelent.

Alig hiszem, hogy van ennél simább megoldás. Klasszikus fogaskerék-vezérlés.
(De ha nem érdekes, nem forszírozom.)

Ha a gyűrűs megoldást választod, akkor nem kell mastert választani, nem kell ID-t állítani. Egyedül annyit kell megtenni, hogy a kijelzővel rendelkező példányon be kell állítani, hogy hány slave van (hogy tudja, hányat kell kijelezni, semmi másért). Ezen felül a sorbaköthető maximumot be kell égetni az összes készülékbe, mert ez határozza meg, hogy hány korábbról érkező értéket kell meghagyni a bejövő és továbbküldendő üzenetben. Az nem baj, ha kevesebb van valójában, legfeljebb majd többször lesz bent ugyanaz, a kijelző úgyis csak annyit ír ki, amennyit mondtál neki.
Ha valamilyen osztott közeges, buszos megoldást választasz, akkor kellenek ID-k - erre a legjobb a véletlenszám-generálós, de meg lehet csinálni azt is, hogy lehessen újat generáltatni (mondjuk resetnél az egyik bemenetet egy gombbal lehúzod), sőt, ha fel tudja ismerni az ütközést - ez nem lehetetlen - akár automatikusan is megcsinálhatja. Az RX/TX-vonal PC-re kötésének a "nem megy, nézzünk bele, hogy milyen ID-je van neki" esetnél lehet értelme, nyilván nem mindenki szeretné Pickittel debuggolni ezeket az eseteket.

Ezzel nem teljesül, hogy ne kelljen beállítani semmit és minden PIC-ben ugyanaz a program legyen. Ha van azonosító és meg van határozva a panelek maximális száma, akkor könnyű meghatározni, hogy hány eszköz van a körben, csak egyel nagyobb verem kell, mint a max panelszám. Ha az azonosító is a csomag része és visszaért, akkor az előtte vett eltérő azonosítók számossága elárulja, hogy hány adatot kell kijelezni.

Rengeteg módszer van, amivel meg lehet vizsgálni, hogy hány eszköz van, csak bonyolultabbak, mint egy beállítás a kijelzős pontnál. Ott úgyis be kell állítani, hogy milyen eszközöket fogunk látni (ugyebár különböznek és tetszőlegesek lehetnek).
De hát írtam egy automatizmust is és azóta kitaláltam még hármat. De azt bonyolultabbnak érzem. Különös gond az indulás és az első kör.
De igazad van, valóban megoldható. Én azért javasoltam ezt, mert ezzel elvethettem egy korábbi, automatikus, ám bonyolultabb javaslatomat.

Egyébként minden picben ugyanaz a program lesz így is. Legfeljebb amin nem állítanak be semmit, az nem is foglalkozik se küldéssel, se kijelzéssel.

Dehogy siklottam, csak a tiedre nagyon hosszú választ kezdtem el írni meg egy ábrát rajzolgatni és még nem jutottam a végére.

Na itt már meg is van különböztetve az egyik eszköz a másiktól, szóval már nem jó.

A lényeg és ezt próbálom épp ábrákon megrajzolni hogy ha kevesebb mint négy panelmérő van, akkor sem borul fel a sorrend! Ezt írtam le korábban:

Tehát ha kiesik egy panelmérő, akkor az utolsóként érkezett adat a fogadó panelmérő saját, előző mintája lesz.

Köszönöm, végre valaki megértett hogy mire gondolok!

Pontosan, erre mondtam hogy három panelmérőnél az utolsó adat az adott panelmérő saját, csak előző mintája lesz.

Én azt úgy oldanám meg, hogy amin nincs kijelző, az nem jelez ki(feltételezem, hogy a panelek egyformák, csak van amelyikre nem lesz rátúzve az LCD). A kijelző hiányát a panel tudja detektálni. Ha a csomag tartalmazza a mért érték mértékegységét is, akkor nem kritikus, hogy melyik sorba lesz megjelenítve.
Egy négysoros kijelző esetében négy panel jöhet szóba max. Ha csak három, vagy kettő van, az kiderül azonnal, ahogy körbe ért a saját azonosító, akkor csak három, vagy két sor lesz megjelenítve.
Esetleg ha lenne még egy vizsgálat, hogy melyik mértékegység hol jelenjen meg, akkor mindegyik kijelzős panelen egyfoma lenne a megjelenítési sorrend.
Igaz, a mértékegységet be kéne állítani, de menü úgy tudom van. Az is igaz, ha van menü, akkor sokmindent be lehetne még állítani, akár azonosítót is, de az volt az aggály, hogy a user két azonos értéket állít be, akkor mi van(béna a user). Hát ha ez gond, akkor automatikus azonosító generálás a megoldás...

Nekem csak egy hozzáfűzni valóm lenne: kapcsolóüzemű tápokban akarsz méréseket végezni, ami ugye elég zajos környezet. Nem tudom érdemes-e ennyire szorosan kihegyezett protokollt kitalálni, mert a hibás vételek ismételtetései a gyakorlatban könnyen lehet, hogy széttördelik az egész elméleti adatátvitelt. Biztos vannak páran akik foglalkoztak ilyennel, mondjanak valami tapasztalatot az átviteli hibákra vonatkozóan.
Esetleg az autókban alkalmazott CAN busz?

Nem lehet probléma az adatok valódiságának ellenőrzése és a hibák száma is kicsi normál esetben, a kapcs táp sem okoz nagyobb gondot megfelelő vezetékelés esetén.

A kijelzés léte nincs hatással a kommunikációra. A PIC a kijelző-vezérlő lábain ugyan úgy kiküldheti a dolgokat, legfeljebb mivel nincs rá kijelző kötve, nem történik semmi.

A panelmérő menüjében ezt kell majd csak beállítani:
Mit jelezzek ki?
- Csak azt amit én mérek!
- Azt amit én mérek plusz ha kaptam valami adatot (azaz nem vagyok egyedül) akkor abból az utolsót (azaz a fizikailag előttem lévő panelmérő adatát)
- Azt amit én mérek plusz ha kaptam valami adatot (azaz nem vagyok egyedül) akkor abból az utolsó két (azaz a fizikailag előttem lévő két panelmérő adatát)
- Azt amit én mérek plusz ha kaptam valami adatot (azaz nem vagyok egyedül) akkor abból az utolsó három (azaz a fizikailag előttem lévő három panelmérő adatát)

Mivel optocsatolós megoldásban kell gondolkodni, ott pedig 5-10 mA nagyságrendű áramok kellenek mindenképpen, továbbá kbps nagyságrendű sebességről beszélünk csak, ezért én nem tartanék itt komoly RF zavaroktól.

Nem 500ms alatt, hanem 500ms-onként. Maga a 30-40 bájt átvitelét úgy gondoltam pár ms alatt megvan.

Pedig lehetne, mert a PIC ellenőrizni tudja, hogy van-e hozzá kötve LCD (pl. BUSY flag ellenőrzéssel, CGRAM olvasással...).

Persze, egyébként ezt a panelmérő III ki is használja de a célból hogy detektálja milyen kijelző van rákötve. Mert ha hétszegmenses LED-kijelző akkor arról nem fogja visszakapni a kiküldött karaktert, az LCD-ről viszont igen. Ez látszik (valamennyire) ezen a kis videómon: Bővebben: Youtube

Igazából mindegy, legfeljebb nyer a PIC egy kis időt amit mintavételezéssel tud tölteni és így még több mintát fog átlagolni. De így is már most 1800-1900 mintapárral (fesz-áram) dolgozik. Bár végülis miért ne, kb három sort kell csak beleírnom pluszban a kódba hogy ha nem észlel kijelzőt akkor ne is próbáljon kijelezni semmit.

Lehet, hulye kerdes, de nem lenne elegendo 1 db PIC az egeszre? Marmint ami elvegzi a mereseket. (multiplexelt belso AD konverter)
Ha ez nem jarhato, akkor pl can busz mint kommunikacios csatorna?

Egy dolog fix, hogy mindenképpen lesz maximális száma az eszközöknek. Ugyebár a véges küldési idő, a kijelző mérete, vagy a pic memóriája ezt meghatározza.
Most még kéne egy eszköz, ami elkezdi a folyamatot, mert enélkül csak körhinta lesz.
Csináljuk úgy, hogy indulásnál generál mindenki egy véletlenszámot. ez lehet akár értékkiolvasás (ugyebár ezek műszerek) utolsó számjegye. Egy AD mindig csinál szemetet az alsó biteken.

Szorozzuk meg a számmal mondjuk egy-két bájt küldési idejét a Tx-en, maximális számú eszköz esetére. Tehát egy jó nagy kört. Közben állítsuk úgy be a rendszert, hogy csak akkor küldjön bármit, ha már fogadott. Indítsunk el egy timert a kiszámolt értékkel. Amelyik elsőnek jár le, körbeküld egy bájtot. Mindegyik fogadja és ad hozzá egyet. Amikor körbeért, már tudjuk hány eszköz van a körön. Közben persze a többiek állítsák le a timert.

Aki először indított, már tudja, mi a létszám. El is küldi a többieknek, akik szépen beállítják erre a verem méretét és onnan kezdve kapcsolhatnak élesre. (Kis szünet után, hogy a többiek is kapjanak időt a beállásra. Eztán jöhet a körforgó verem. Úgy egy másodperc alatt lefuthat az egész.

Esetleg ez működhet.
Ha olyan pechünk van, hogy kettő indul egyszerre (Murphy+), akkor legfeljebb kikapcs-bekapcs és restart.

Mivel most is a munkammal kapcsolatban keresgelek, jott egy esetleges kommunikacios megoldas: 1 vezetekes soros kapcsolat Bővebben: Link
Nekem igazabol 52 "azonos" eszkoz kommunikaciojat kellene megoldanom a kulvilaggal a leheto legegyszerubben, kis meretben, minel kevesebb kapcsolodasi ponttal (pl can busz-szal ami 2 vezetekes)

1db PIC nem jó. Attól eltekintve hogy nincs is már több lába (ne mondjátok hogy nagyobb lábszámú PIC-el csináljam mert rengeteg okból kifolyólag nem akarom és nem is tehetem meg), ha egy PIC mérne mindent akkor a tápegységek nem lehetnének galvanikusan függetlenek egymástól ami nagyon komoly kompromisszum lenne egy labortápegységnél. Nem lehetne sorba kötni a kimeneteiket "pluszminusz" feszültség előállításához. Az analóg galvanikus jel-leválasztás megoldható lenne és tudok is rá nagyon jó megoldást csak az méregdrága és nehezen beszerezhető. A legegyszerűbb, legtisztább ha külön-külön van egy panelmérő és ezek elmondják egymásnak hogy mit méricskélnek. A digitális jelet pedig nagyon egyszerű galvanikusan leválasztani.

A CAN-buszt nem ismerem (az UART-al is csak most ismerkedek!) de igyekszem minél egyszerűbben megoldani. Ráadásul mint említettem a panelon lévő ICSP csatira kivezetett két programozói láb (PGD, PGC) pont az UART modul RX és TX lábai is, így mindenképp UART-tal szeretném megvalósítani a kommunikációt. Azért is vitatom meg veletek (uC kommunikációban nálam egészen biztos hogy jóval jártasabb emberekkel) az egészet mert ezt ha leprogramozom és hiba van benne (biztos lesz, ismerem magam...)akkor azt borzasztó nehéz lesz debuggolni, mivel a panelmérők közti kommunikációt megvalósító lábak a PICkit3-ra csatlakoznak. Ha meg a panelmérőket kötöm össze akkor nincs PICkit3, azaz nincs debuggolás. Ráadásul nincs 4db PICkit3-am hogy mind a négy panelmérőt debuggoljam. Persze ötleteim vannak erre is, ilyen tekintetben szerencsére elég kreatív szoktam lenni (gyújts LED-eket, írasd ki LCD-re, mentsd el EEPROM-ba stb...).

Serial Analyzer-el szerintem elemezheted, én építettem ilyet, ha gondolod felrakom a rajzokat.

Hát én valami hasonlót vázoltam fel korábban

Visszatérve az egyedi azonosításra: Nem nagy kunszt programozáskor két sort odabiggyeszteni (Notepad editor) a beégetendő HEX fájl végére, s akkor egyedileg beírható a 8 bájtos User ID. Például:

:020000040020DA
:08000000B1CC07041D455002BC

A fenti példában egyébként a PICCOLO HID 4550 (ver) 02 azonosító szöveg van "elrejtve", az alábbi megfeleltetésekkel B=P, 1=I 4=H. A sorvégi BC pedig a checksum.

Némi kézügyességgel a kívánt automatikus léptetés is megoldható egy kis Perl vagy Python scriptelés fejében...

Persze, mert ott is lesz a megoldás. Csak nem kell kiejteni a "master" szót.
Az egyforma programok valójában csak indulásnál okoznak gondot. Hajlamos a rendszer körhintává válni. Itt mindenképpen ki kell zökkenteni őket egy pillanatra. Erre nagyon más mód nincs is, mint valami véletlen-szám generálás alapú egyedi késleltetés. Később már nincs is rá szükség. Nem is kell különböző program, csak az a lényeg, hogy valamelyik eszköz elsőnek kapja el a lapát nyelét.