Igen, erről írtam én is, de majd Attila kiválasztja a számára megfelelő ötletet !

Na, közben rájöttem egy sokkal egyszerűbbre. Marad az eredeti elképzelésem, csak annyit kell tennie a rendszernek, hogy nem veszi figyelembe az üres csomagokat a forgatásnál.
Indulás három egységnél:
1000 2100 3120
Egy kör után:
1230 2310 3120

Valójában nem is kell elküldeni a nullákat sem, a programban dinamikusan kell allokálni a vermeket a kapott csomagszám szerint:
1 21 312
123 213 312 innen már automatikus

Nem kell tudni, hány eszköz van a rendszerben, nem kell véletlen-szám, egy kör után beáll a rend. Ez már elég elegáns?
(Azért más is gondolja át, mert én még nem ittam meg a reggeli kávémat.)

Igazán szép feladatot eszeltél ki. Tehát bolondbiztos, azaz bolond-user-biztos megoldás kell, mert tényleg, ha az emberi tényezőt beleszámítjuk, akkor bármilyen hibával számítani kell.

Ha elég csak az inicializálásnál meghatározni a mérők számát és sorrendjét, utána szabadon összevissza mehetnek a mérések, és a szoftver egyforma kell, hogy legyen, akkor a hardverben kéne változtatásokat alkotni.
Ha szerinted rá lehet venni a "bolond-usert", hogy ahány mérője van, annyiféleképpen helyezzen el egy jumpert, akkor nyert ügyünk van.

Például(1), ahogy az EEPROM-okat címzik, jumperral változtatni a címeket

Például(2) az első mérő a jumper állásából adódóan az egyik kimenetén 1 mVoltot ad ki, a második 2 mVoltot, a harmadik 4 mVoltot, a negyedik 8 mVoltot (és akár stb). Ha összeadjuk a kimeneteket, tudni fogjuk, hány mérőnk van. A mérések során amelyik mérő adásban van, annak azt a bizonyos kimenetét leolvasva, azonosítani tudjuk.

Na, mostanra te is eljutottál oda hogy érted mire gondoltam eredetileg.
Bár mondjuk ezt így konkrétan nem írtam le de természetesen úgy gondoltam az egészet hogy a teljes felálláshoz egy körnek meg kell történnie. Hiszen a legeslegelső csak a sajátját tudja küldeni, az utána lévő a sajátját és az előzőt, a harmadik már még egyet, a negyedik pedig már a sajátját és még hármat. Innentől pedig megvan az első kör, most már mindenki amit kapott abból a legutolsó adatot csak kijelzi (ha ki kell), de tovább már nem küldi.

És így hogy már mindenki érti az ötletemet most már tényleg, kérlek gondoljuk át az esetleges hibalehetőségeket amiket említettem:
Mi van akkor, ha nem szépen sorban történik a mintavétel, hiszen szinte tuti hogy soha nem is fog! Azaz, az áram alá helyezés után mondjuk a "B"-nek sikerül legelőször mintát vennie és ezt tovább küldi a "C"-nek. Igen ám, de nem az lesz a következő történés hogy most pedig a "C" küldi tovább azt amit ő mért plusz az előzőleg a "B"-től kapottat. Hanem mondjuk most (a "B" után) a "D"-nek sikerült mintát vennie. Ő tovább küldi az "A"-nak a sajátját. Aztán jöjjön mondjuk az "A" majd a "C"... Tehát a sorrend: B, D, A, C.
De leírom másképp, talán így érthetőbb:
Áram alá helyezés után egy csomó dolga van a PIC-eknek, úgyhogy mondjuk 3s-nál veszi az első mintát. És legyen a fentebb említett sorrend, a PIC-ek pedig a könnyebb átláthatóság kedvéért 1ms késleltetéssel indulnak el. Akkor ez történik:

3000ms -> "B" elküldi a saját mintáját a "C"-nek.
3001ms -> "D" elküldi a saját mintáját az "A"-nak.
3002ms -> "A" elküldi a saját és a (3001ms-nál) a "D"-től kapott mintát a "B"-nek.
3003ms -> "C" elküldi a saját és a (3000ms-nál) a "B"-től kapott mintát a "D"-nek.

(Ezzel megvan az első kör. Mindenkinél a sajátján felül az egyel mögötte lévő adata van.)

3500ms -> "B" elküldi a mostani mintáját és a (3002ms-nál) az "A"-tól kapott két mintát a "C"-nek.
3501ms -> "D" elküldi a mostani mintáját és a (3003ms-nál) a "C"-től kapott két mintát az "A"-nak.
3502ms -> "A" elküldi a mostani mintáját és a (3501ms-nál) a "D"-től kapott három mintát a "B"-nek.
3503ms -> "C" elküldi a mostani mintáját és a (3500ms-nál) a "B"-től kapott három mintát a "D"-nek.

(Megvan a második kör. "A"-nál és "C"-nél a sajátjukon felül három minta van, "B"-nél és "D"-nél pedig a sajátjukon felül négy.)

4000ms -> "B"-nél négy érkezett minta van, ebből az utolsót eldobja és az első hármat plusz legelöl a mostani sajátját tovább küldi a "C"-nek.
4001ms -> "D"-nél négy érkezett minta van, ebből az utolsót eldobja és az első hármat plusz legelöl a mostani sajátját tovább küldi az "A"-nak.
4003ms -> "A"-nál négy érkezett minta van, ebből az utolsót eldobja és az első hármat plusz legelöl a mostani sajátját tovább küldi a "B"-nek.
4004ms -> "C"-nél négy érkezett minta van, ebből az utolsót eldobja és az első hármat plusz legelöl a mostani sajátját tovább küldi a "D"-nek.

(És innentől ez megy örökké.)

Akkor neked is mondom: Az user egy kártékony hibaforrás, szeretném úgy megoldani a rendszert hogy semmilyen szoftveres (menüből állítható) vagy hardveres dolgot ne kelljen neki variálnia mert akkor bármi történhet. Bár azt nem lehet elkerülni hogy négynél kevesebb panelmérő esetén, háromnál az utolsó, kettőnél pedig az utolsó kettő érkezett minta kijelzését le kelljen tiltani. De ha nem tiltja le, hiba akkor sem történik, csupán hülyeséget fog kijelezni az utolsó, vagy az utolsó kettő helyen a kijelzőn. De a kommunikáció ettől még működik és az első kettő vagy az első három helyen jót is fog kijelezni garantáltan.

Erre gondoltam én is. (LCD kérdéskörre utalok)

Amit én írtam azonosítós és mértékegységes megoldást, abban azt se kell megadni, hány db panelt kötsz össze(kiderítik maguk), csak esetleg a mértékegységet, amit kijeleztetni akarsz, ha fontos, hogy több kijelzőn is azonos sorrendben jelenjenek meg a kijelezendő adatok.
Az is egy elvi megoldás az azonosító létrehozására, ami nemrég hangzott el, azaz a program minden induláskor generál egy kódot. Ebben az a veszély, hogy mi van ha két azonos keletkezik, ezért ezt elvetném. Az egyszer generált azonosító estében sokkal kisebb az esély, hogy az egymás mellé kerülőknél azonos kód keletkezik. Viszont ha ez megtörténik, akkor nehéz detektálni a hibát az usernek.

Akkor is baj van egyébként, ha a user rossz panelszámot üt be... Lehet, hogy rá kéne bízni, hogy 1,2,3,... számokkal jelölje már meg a menüből a paneleket, nem!? Vagy gyárilag beégetni a sorozatszámot, ami téged terhelne...

Most leírtad hosszan, amit én írtam rövidebben.
A tegnapi verziómból még hiányzott a változó számú eszközök jó meghatározása, ma reggel pótoltam.
Lényeg a lényeg, forgatni kell az adatokat mint a fogaskereket, ahogy már tegnap jeleztem. Az első teljes kör után beáll a rend.

Ennek a megoldás egy nagy hátránya van: a képernyőn nem feltétlenül időben közel eső értékek lesznek egyidőben kijelezve. Azaz az egyik tápkimenetnek a friss adatát látod, miközben a másik tápkimenetnek esetleg fél másodperccel korábbi adata lesz mellette. Ha ez nem fél másodperc lenne, hanem az emberi érzékeléshez képest valami sokkal kisebb érték, akkor ez senkit nem érdekelne (igaz, akkor meg a leolvashatóság lenne gázos). A problémának két megoldása lehetne: sokkal gyorsabban küldött (rész)adatok, és a kijelző aggregál, vagy kell egy master, és az adja az ütemet, a többiek pedig ehhez igazítják a saját méréseiket.

Van egy harmadik megoldás is: nem egy üzenetcsomagban mennek az adatok, hanem mindegyik adat külön üzenetben, az elejére odabiggyesztve, hogy hanyadik mérőtől jön az adat. Ez persze picit megnöveli az adatmennyiséget.
Amikor a mérő a saját adatait küldi, akkor 0-át tesz oda, amikor kap egy korábbi mérőtől származót, akkor azt már eggyel megnövelve küldi tovább, és nem várakoztatva, hanem azonnal.
Ennek ugye az lesz az eredménye, hogy a kijelzőn az adatok nem egyszerre változnak, cserébe mindegyik adat friss lesz.

Ez így első olvasatra nagyon jól hangzik! Még átgondolom hogy ilyenkor pontosan mi is történik és hogyan...

Ja várjunk, ha egy panelmérő kap adatot és azt azonnal továbbküldi, ha neki épp nincs új mintája akkor ott nullával, akkor az lesz hogy folyamatosan megy körbe az adat, a PIC-ek nem is fognak tudni kiszabadulni a megszakításból! Mert amint kapnak valamit, azonnal tovább küldik, az következő is azonnal tovább küldi, majd az is... aztán négy azonnal elteltével visszajut ugyan oda ahonnan kezdődött na de az ismét azonnal tovább fogja küldeni. Tehát mire befejezte az adást, szinte rögtön már lép is vissza a megszakításba mert újra vétel van. A főprogram nem is fog tudni futni.

A sajátját nem küldi. Csak a megkapott adatot. Tehát nem egy adatcsomag van, benne n db adattal, hanem n db adatcsomag van, benne 1-1 mérés eredménye, plusz egy byte, ami jelzi, hogy ez hanyadik mérőé. És úgy ér véget a kör, hogy ez a jelzőbyte minden továbbküldésnél (minden érintett mérőnél) nő eggyel, a végén pedig amikor eléri a max. mérőszámot, akkor eldobják.

Ezzel egyenértékű, amikor az azonosítókat küldik az adatok mellé, mert azok sorrendje azonosítja a panel elhelyezkedését is. 9600baud mellett simán menne sokkal nagyobb frissítés is és akkor mehet egy üzenetben az egész.

Egyrészt ha jól van szervezve a kommunikációs programrész, akkor a folyamatos adás vétel sem okozhat problémát a többi programrész működésében, mert a soros kommunikáció lassú folyamat, sok idő van két bájt beérkezése-elküldése között, ami mindenre elég kell legyen.

Másrészt olyan nincs, hogy 0-t küldesz, mert a pufferbe mindig a legutóbbi mérés van, tehát legfeljebb ugyanazt elküldöd és kijelezteted, no problem.

Még valamit el kell döntened! Egy dobozon belül akarsz paneleket összekapcsolni, vagy nagyobb távolságokra is ki akarod terjeszteni a kört?
Ha csak dobozon belül, akkor van értelme a leválasztásnak? Nem közös a mérőpanelek testpontja?

Remelem nem leszek megkovezve erte, de szerintem tulbonyolitjuk a dolgot. Az otlet es feladat onmagaban nagyszeru, de nem igazan erzem eletkozelinek, hasznalhatonak. (vagy csak nekem hianyosak az informacioim az egesz projektrol)
Miert is? Kezdjuk ott, hogy mire is kellenek ezek az adatok? Kiindulaskent van egy kettos tapegysegunk, amit hasznalhatnank egymastol fuggetlenul illetve kapcsolatba hozva egymassal es szeretnenk tudni mi tortenik a kimeneten hasznalat kozben egy kozos kijelzorol leolvasva. Velemenyem szerint az esetek tobbsegeben beallitunk egy kimeneti feszultseget, es utana csak a kimeneti aramot figyeljuk, vagyis ebben az esetben van 1 ill 2 statikus es 1 ill 2 dinamikus ertekunk, masszoval csak egy idoszakban mindossze 2 valtozonk van (beallitaskor a feszultsegszint, utana csak az aramerosseg). Viszont hasznalat kozben nagyon zavaro tud lenni ez a fel statikus allapot, vagyis az idoszeletes meres, ami 4 valtozo eseten 1 aktiv es 3 passziv allapotu, masszoval csak 25%-os a hasznos ido. Tobb kimenetet kezelve ez az aktiv idoszelet lecsokken es raadasul a kijelzes rovasara es az eredeti funkciot nem igazan tudjuk hasznositani, mivel "sokminden" tortenhet a passziv ido alatt, amit nem lathatunk, mert eppen egy masik, esetleg nem is ertekes adat kijelzese eppen az aktiv. Ilyen jellegu esetekre jo a triggerelt ertekatadas, de ezt se tartom celszerunek, mert lehetseges egy idoben torteno valtozas is.

Nem tudom, de én biztosan nem építenék kettős, pláne nem négyes tápot, ami galvanikusan fixen össze van drótozva. A független tápokkal egy csomó olyan kapcsolást meg lehet csinálni, amit összekötött tápokkal nem.

Bevallom, nem értem, hogy miről beszélsz. Nincs időszeletes mérés: minden mérő folyamatosan mér, nem pedig az idő 25%-ában. A kijelző pedig képes relatíve gyorsan az egész képernyőt frissíteni.

Ez igaz, de attól még a mérőpanelek lehetnének egy közös testen, ha olyan a mérőkör kialakítása, hogy az független a tápoktól...

Mikrokontroller nélkül? Mennyiért lesz a független a tápoktól?

Akkor most hogyan tortenik a kijelzes? Egy kozos szamkijelzo, vagy valami mas? 1 kijelzo eseten marad az 1 aktiv es 3 pasziv allapot, mivel egy idoben csak egy kijelzett erteket lathatsz.

Nyilván egy LCD kijelzőn elfér több adat is egyidőben, egymás mellett...

Nekem is ez a véleményem csak nem voltam elég bátor beírni, hogy hirtelen nem tudnék felsorolni 3 amatőr szintű alkalmazást, ahol ezt használni lehet legalábbis labortáp témában és nem mérés-adatgyűjtés témában. Biztos vagyok benne, hogy ez egy nagyon jó műszer lesz, de nem tudom érdemes-e beleerőszakolni egy olyan jellegű tudást, amit más felépítéssel sokkal egyszerűbben és talán olcsóbban is meg lehet oldani.

Na igy mindjart mas. Ebben az esetben celszerunek latom az egyedi azonositoval ellatott egysegeket es triggerelt (vagyis megszakitasos) ertekatadast.

Exactly.

Melyik része nem felhasználható? Hogy van több mérő paneled, de csak egyre teszel LCD-t és a többi mérést átadod neki kijelzésre? Szerintem ebben semmi különleges nincs, hacsak az nem, hogy ezt felhasználói hülyeség ellen kell felkészíteni, ha lehet. Számomra ez nem egy megoldhatatlan feladat és nem is felesleges kérdéskör. Attila egyelőre nem tudja melyik megoldást válassza a sok közül, én se tudnám, ha ennyien ennyiféle megoldást öntenének a nyakamba!

... akkor most milyen kijelzorol is van szo? Egy eredeti 3 v 4 digites, vagy valami "komolyabb"? Ha az eredeti, akkor nem igazan tartom hasznalhatonak az elozoekben altalam leirtak szellemeben. Manapsag olyan olcsoak a panelmuszerek, raadasul egy eszkozon belul megvan a feszultseg es arammeres kb 3500 Ft-ert... Ezzel persze nem azt akarom mondani, hogy nincs ertelme foglalkozni ezzel, csak erdemes merlegelni mire megy el az ido. (Esetleg egy mas, komolyabb project elol veszi el)

Teszem azt, egy SPI-s A/D tolná át a biteket és az lenne leválasztott (sokkal könnyebb, mint az USART-ot leválasztani). Igaz akkor külön táp kéne a PIC-nek ami független a labortáptól, de szerintem ez nem egy nagy probléma, mert egy pici trafó igen olcsó. Ekkor bármilyen sebességgel lehetne kommunikálni a paneleknek, nem lenne probléma a kijelzés késleltetése.

Feltűnt-e, hogy ez hobbi?
Nem tudom milyen az eredeti, egy soron nem lehet sokmindent kijelezni, én csak a feladatra koncentráltam, ami szerintem érdekes.

Egy dobozon belül lesznek a panelmérők és muszáj a galvanikus (optós) leválasztás, mert különben nem lehet a labortápok kimeneteit sorba kötni! De ezt írtam is. Nem lehet a mérőpanelek testpontja közös, mert akkor a labortápok kimenetei is közösek lesznek.