Igen, arra gondoltam. Sajna nem talaltam semmi jo megoldast hogyan tudnek code block-ba illeszteni par specko karaktert.

Ez a lekérdezés -1-el ad jó eredményt, nullával nem.

Mert ez a vegerol szamol vissza (Utolso elotti adat)

Ez a Python kód nem igazán működik, legalább is a print sora:
try:
tempdata = thetext.split("\ n")[1].split(" ")[9]
except IndexError as error:
print("Missing data from: {}".format(thetext))
mondjuk nem is értem!
print("Missing data from:",error)
viszont így igen.
Látom a hiba okát, amit eddig is tudtam, csak nem tudtam (tudom) az okát.
Azzel a kód részlettel nem áll le a program. Megszámoltatom a hibákat és naponta 10-15 keletkezik szenzoronként.
Mint előzőleg már írtam régebben hónapokig működött hibagenerálás nélkül.
Ki érti ezt?

Ha még nem tetted volna meg, szerintem írass ki egy jó sort, és írass ki egy hibásat is, hogy szemre össze tudd őket hasonlítani! A hiányzó adat helyéből elvileg már ki lehet találni hogy ki okozza azt, abból meg hogy miért. Én egy naplót íratnék vele, nem csak megszámoltatnám a hibákat.

Vagy jók az adatok vagy ez a hiba "list index out of range"
Egyéb üzenet, vagy rossz adat nincs.
Tulajdonképpen az előzőek szerint működik (ha nem iratom ki akkor észre se lehet venni, folyamatos a működés), csak zavar hogy miért.

Arra gondolok, hogy ha érkezik egy ilyen sor: 1,2,3,4,5 értékekkel, és ezt várod a programban, de helyette 1,2,,4,5 jön, vagy a vessző is elveszik, akkor érthető hogy nincs rendben a tömb, hibázni fog. De ha szemmel látod hogy hiányzik a 3-as, akkor már azt is tudod hol keresd a hibát! Ezért mondom hogy irasd ki.
Azt mondod nincs rossz adat, de a jelenség pont azt mutatja hogy van rossz adat, vagy legalábbis hiányos olykor.
Távgyógyításból többre nem telik, nálad vannak az eszközök!

Én értem mire gondolsz, de vagy jó adat jön, vagy semmi, azaz "list index out of range"

Nekem a raspi szereti megenni a memóriakártyát. A másik ok ha eddig jól csinálta, most a hőmérséklet már csökken, lehet valami számábrázolási hiba.

Azt a stringet irja ki amit feldolgozni probal a split() fuggveny, ami velhetoen nem tartalmaz eleg adatot (lehet hogy teljesen ures)..
Maga a kod biztosan mukodik, max a valtozo tartalma kerdes Ha az 'error' tartalmat iratod ki akkor magat a hibauzenetet kapod de ugye az logikusan kovetkezik a hianyos string-bol.

Üdv.
Soros kommunikáció 2 Raspi közott, 2 byte küldéssel van gondom, 1 byte írás-olvasás működik.
Viszont a 2. byte vétele után értékelhető módon nem tudom szétválasztani az karaktereket.

küldöt adat:17,127
ser.write(str(ertek).encode('utf-8'))

vett adat: b'(17, 127')
ser.reset_input_buffer()
adat = ser.read(1)
sleep(0.02)
data_left = ser.inWaiting()
adat += ser.read(data_left)

miután a byte-k értéke folyamatosan változhat 1-255 között (1-3 karakter között) a visszaadott
karakterek nem tisztán számokat tartalmazhatnak.
Milyen megoldás lehet?l

Szia!

A küldésnél enkódolod az utf8 karaktereket, és azt várod, hogy két bájt érkezzen. Szerintem nem két bájt lesz az encode után, hanem három, vagy több is. Én itt néznék szét a helyedben! Vegyél át mindent ami érkezik, és úgy próbáld meg dekódolni!

Én betennék az elejére/végére valami spec karaktert, esetleg chsum-ot is... Aztán kimazsoláznám "kézzel" a stringet...
Nem értem amúgy én 6 karaktert/bájtot látok.
Amúgy ha számokról van szó, akkor miért kell utf8?

Idézet:
„Amúgy ha számokról van szó, akkor miért kell utf8?”

Felteszem az eredeti szöveggel nem ment, aztán kipróbálta számokkal is és azzal se ment. Így aztán copy-paste a legfrissebb nem működő verzióról a kérdésbe.
Ha csak számok lennének, akkor valóban tök felesleges az utf8, és ez meg is oldaná a problémát szerintem

Bocsi ezt nem értem 'chsum-ot'. Egyébként a vesszővel max. 7 karakter lehet, min.3
Az 'utf8' nem kell, csak próbálkoztam. A nélkül is ugyan az a helyzet.
1-3 karakter esetén jó a dekódolás, 5 karater felett az 1-3 értéke is megváltozik.

chsum: a vett adatokból képzett ellenőrző összeg, ebből látod ha hibás a vétel...
Ez mit jelent: vett adat: b'(17, 127') mi az a "b" betű, meg az idézőjel eltévedt?
Az "adat" változód milyen típusú? Nem itt lesz a kutya elásva? karakter/string/int, float?
Ki kéne értékelned a "nem jó" vett érték az hogy jön ki a küldött karakterekből kiindulva...
vagyis miből mi lesz...

Egyébként egy valamire való kommunikációnak van kezdete, meg vége. Ha atom biztos adatkapcsolatot akarsz, két kütyü között, akkor jelzed valami spéci karakterrel hogy kezded az adást(esetleg azt is megmondod hány karakter), aztán jön az adat, chsum, esetleg vége jelzés...
A vevő oldalon mindent elhajigálsz addig, amíg nem jön "kezdet" karakter... ha megjött leveszed az adatfolyamot, ellenőrzöd (chsum), ha rendben van akkor a vett komplett adatcsomagot szépen kimazsolázod akár karakterenként/bájtonként.
Egyébként lehet kiabálni a világba, valaki valamennyit valamikor biztos meghall belőle ))

Köszönöm a segítségeket!
Úgy tünik sikerült megoldani a soros adat küldés-vételt.
Adás oldalon átalakítottam a küldött bájtokat mindig azonos hosszra.
Vétel oldalon ez alapján le tudtam válogatni, még az adat konverziókat kell megoldani és örül.

Tudtok segíteni a Raspik-Python3-Rs422 full duplex programozásában,esetleg példaprogrammal vagy linke-el.
Igazából működik a kommunikáció csak nem folymatos. Úgy értem állandóan küldöm mindkét oldalról az adatokat, mind két oldal vesz, de esetenként leáll a folyamat.
Nem tudom az okát!? Nem szükséges szoftveres szinkronizáció?

A programod pontos ismerete nélkül arra tippelnék, hogy blokkoló API-t használsz a kommunikációhoz. Ez, ha éppen nincsen bejövő adat, akkor várakozik, és amíg a bejövőre vár a program, addig a kimenő puffer kiürül, és akkor ott sem lesz folyamatos adás.

A másik mód, ahogy blokkolni tud, ha a kimenő puffer van tele, arra vár, és akkor meg addig a bejövő oldal van elhanyagolva.

De ez csak tipp. Mi van a soros vonal másik végén, mivel kommunikál a PI?

Ilyesmibe én is futottam már bele. Én akkor és ott FTDI alapú USB-UART modult használtam, ami időnként leállt, hasonlóan mint nálad. Kicseréltem egy másik típusra és azóta minden jól működik. A típusra nem emlékszem de talán CP2102 alapú került bele.

Hátha.

Raspi3 és Raspi4 'beszélgetne.'
Bocsi de ezt a 'blokkoló API-t' nem igazán értem.

Köszi a tippet. A Raspi3 oldalon én is FTDI alapu USB-RS422 modult, a Raspi4-nél CV8285M RS422-RS232 és RS232-USB kombinációt használok.
Jelenleg már stabilabb a működés, folyamatos az adás-vétel. Küldött adat változás esetén fordul elő esetenként leállás. A timeout és a read utáni időket csökkentettem.

Elsőre úgy értettem, hogy a saját UART-juk van összekötve. Az nem nagyon tud hibázni, az hardveres UART ugyanabban a csipben, olyasmi mint egy mikrovezérlőben.

Így hogy egy USB-s kütyüről van szó, más a helyzet, így lehet USB szintű probléma is. Van esetleg más is ugyanazon az USB hubon?

A blokkoló API-t úgy értettem, hogy egy serial.write() vagy egy serial.read() hívás addig várakozik, ameddig nincs hely a kimeneti pufferben/adat a bejövőben. Ha egymás után vannak az írások és olvasások (egy szálon), akkor előfordulhat, hogy az egyik nem történik meg, akkor a másikat is blokkolja.

A két oldal órája nem teljesen egyforma, nem ugyanannyi adatot küldenek adott idő alatt, ha arra épít a program, hogy ugyanannyi lesz az adat, hosszú távon ebből is lehet hiba.

A python nyelv tudtommal Garbage Collection alapon működik, a programban amikor lefut a "szemétgyűjtés", akkor hosszabb szünet is lehetséges. Pár tizedmásodpercet is el tudok képzelni, bár konkrét ismereteim a Pythonnal nincsenek, csak hasonló GC memóriakezelésű nyelvekkel.

Számtalan oka lehet a hibának, kód nélkül csak találgatni lehet.

Miután nagyobb távolságon kell a kommunikáció, ezért az RS422-t választottam.
Próbálkoztam UART-n MAX3232-vel két Raspi között működött is. Viszont az RS422 miatt az USB portok voltak egyszerűbbek és olcsőbbak, miután ahhoz csak 1 USB/RS422-t kellett vennem a többi kütyü meg volt. Az USB hubon nincs több eszköz.
'Szemétgyűjtés' a Python-ba vagy az írás-olvasás 1 szálon történő futtatása bizonyára a hiba forrása. Megpróbálom több szálon futtatni a programot, valamikor már csináltam ilyet.
Köszönöm a hasznos tanácsokat.

Sziasztok!
Van egy 7" IPS kijelző (1024x600), amit rpi4-hez használnék, de nem tudom beállítani.
A képeken látszik, hogy a gyári beállításokat alkalmaztam, de a screen resolution-nál látszik, hogy nagyobbat kínál fel.
Lehet, hogy akkorára állítódik be valamiért?
Hol rontottam el, vagy hol kell/lehet még állítani, hogy ne rajzoljon túl a kijelzőn kívülre?

Ha a /boot/config.txt fájlt szerkeszted, akkor az ott beállított értékeket tudod felülírni a konfigurátorral (negyedik kép). Ilyen esetben a "Default" értékek azok lesznek, amelyeket a config.txt-ben megadsz.

Ezek a kijelzők elégge buta kijelzők, nincs bennük scaler. Ha nem megfelelő felbontású jelet kapnak, akkor vagy nem adnak képet vagy szétesik az egész. A kép alapján nagy valószínűséggel jól van beállítva.

Köszi. Elvileg 1024x600 van beállítva.
A bolt szerint működnie kell, meghát, ha nem lenne jó, visszajelzések alapján, tudnának róla, hogy rossz. Beszéltem a bolttal, még nem reagáltak. Gondoltam, hátha találkozott már ilyennel valaki.

Mi a konkrét hibajelenség? Honnan tudod, hogy a kijelzőn kívülre is rajzol?

A harmadik képen látszik, hogy hiányzik felül a jobbfelső sarokban a wifi ikon, stb. , tehát odébb rajzolja. Ezért gondolom, hogy 1366x768-ra méretezi a képet.
A koppintás jó helyen van, mert érintéskor, kb 1-2 centit balrább kell érinteni, hogy eltaláljam az ikont.