Köszönöm a segítséged. Délután utána járok a dolgoknak.
Normál soros portnál (tankönyv szerint) a számláló törlése a puffert is törli. Ez nekem is furcsa volt.
Előfordult az is hogy a saját programom hibázott. Ilyenkor átáll magától com8-ról com1-re. Most már oda figyelek erre mielőtt bezárom a programot. A programot úgy írtam meg hogy ablak bezárással együtt a comportot is lezárja.

"A VB6 programnak kell bezárnia a COM-ot(MSComm1.PortOpen = False)."
Igen én is ezzel zárom le a port kezelést. Vajon ez a soros puffert is törli? Arra még nem találtam választ hogy a Windows XP az MCP2200-at is normál soros portként kezeli. A soros portra érvényes VB6 utasítások érvényesek az USB-UART átalakítókra is?

"A kommunikáció során legtöbbször tudjuk, milyen hosszú adatsort kapunk. Erre a hosszra kell beállítani az MSComm1.InputLen változót, aminek a hatására csak akkor kerül a lekezelési rutinba a szál, ha beérkezett a csomag. "
Két fajta hosszal dolgozok (32765byte, 6000byte). Ez nem is gond mert a programomban külön is tudom kezelni. A probléma a fix hossz megadással hogy a vártnál mindig kevesebb adat érkezik. Próbálkoztam ezzel a megoldással, de végül az inputlen=1 nél maradtam.

"Az időtúllépéseket Timer modulokkal le lehet kezelni, ha kommunikációs zavar keletkezik."

Erről még nem hallottam. Esetleg tudsz egy linket adni ezzel kapcsolatban.
Az adó oldalon (dsPIC) olyan megoldással kísérletezek hogy minden adatcsomag között 1us várakoztatás van. Volt olyan is hogy 30us-ot állítottam be. Folyton ebbe a "tört" adat kezelésbe ütközök. A Portmon-ban látszik hogy valami gond van az adatfolyammal. Majd délután csatolok egy képet róla.

Szívesen. Talán ez is segít egy kicsit (VB6).

Úgy tudom, hogy szabványos COM portként mutatja magát az MCP.
A hibakezelést timerrel úgy szoktam, hogy az MsComm esemény lekezelésekor engedélyezem a timert, majd a lekezelés végén kikapcsolom. Ha valami közbejön, akkor a timer lejár és ekkor resetálni lehet a COM portot. Úgy tudom a COM port ki-be kapocsolása törli a puffert is, legalább is eseményt nem fog generálni és a mutatót alapra állítja, bármi is volt előtte benne.

Ez nem VB6, ez .NET VB. De megtalálható a VB6-hoz is minden ugyanitt, csak keresni kell.

Itt a VB6 MsComm Object leírása: Bővebben: Link
Innen elérhető példa is...

Igen, valóban elírtam bocs.

"A hibakezelést timerrel úgy szoktam, hogy az MsComm esemény lekezelésekor engedélyezem a timert, majd a lekezelés végén kikapcsolom. Ha valami közbejön, akkor a timer lejár és ekkor resetálni lehet a COM portot."

Köszönöm a tippet, gondolkodok rajta.
Eredetileg egy hibakezelő ciklusba ágyaztam be a soros port kezelését. Hiba esetén visszairányítva a subrutin elejére. Úgy rémlik, néhány napja a hibakezelést is kikapcsoltam. Az a furcsa az egészben hogy főleg a kisebbik (6000byte) adat vételénél jelentkezik a probléma. És már a Portmon-ban is hibás adatok kerülnek. Kimásoltam a log fájlja tartalmát. Betöltöttem Excelbe. Az ábrázolt grafikonon ugyan azt láttam mint a VB6 programomba. Az is elképzelhető hogy a hardverem hibázik. Úgy tűnik ez alapján.

Az RS232 nem az az átviteli technika, ahol 100%-ig meg lehet bízni az átvitt bitekben. Kell valami hibaellenőrzés (checksum, paritás, akármi), különben a hibás adatokat is megeszed.

Abszolút semmi probléma! Az alap irány jó, én is itt szoktam mindent megtalálni, amit a fórumokon nem. Igazából rájöttem, hogy ha itt nem találok megoldást akkor kell fórumozni, és nem fordítva!

A fizikai közeg az USB és nem RS232. Az USB pedig CRC-vel rendelkezik, ha minden igaz. Szóval szerintem kicsi az esély, hogy ott lenne a probléma. Vagy esetleg az MCP2200 és a hardver közötti UART kommunikációra gondolsz? Alacsonyabb sebességeknél, nem túl hosszú jelvezetékeknél, átlagosan zajos környezetben annyira nem gyakori a hibás adatátvitel (persze az is lehet, hogy eddig szerencsém volt a korábbi tapasztalatok alapján).

Az RS232 részére gondoltam. Hiába alacsony a bitsebesség, kicsi a távolság, hiba akkor is lehet. Ha kicsi a hibaszázalék, akkor ritkán fog hibázni - gyengébb védelem is elég. De azt mondani, hogy sosincs hiba, ez nem reális. Ha olyan a protokoll és a felhasználás, hogy ez nem okoz gondot (pl. egy kijelző adatát küldöd, és úgyis küldesz újabb és újabb adatot, ergó legfeljebb egy rövid ideig hülyeség lesz kiírva), akkor mondhatod, hogy "önjavító" a rendszer.

Azt mondtam nem gyakori és nem azt, hogy sosem lehet. Viszont az, hogy 6000 byte adatból feltűnően sok a hibás, azt azért nem hinném, hogy szimplán az UART számlájára lehetne írni (hangsúlyozom normális kialakítás mellett).

Nagyon könnyű CRC16-ot leprogramozni, nem érdemes rizikózni és a léleknek is jót tesz!
Ha érdekel vannak rutinjaim asm, C, VB-re.

Amit korábban írtam arról hogy a VB6-ban látható eredmény és a Portmon-ban látható vett adatok egyeznének az újabb vizsgálódásaim szerint mégsem így van. Úgy tűnik a VB6-os programomat is felül kell vizsgálnom. A Portmon szerint 2530byte adat érkezett be a kb.6000byte helyett. Leginkább ez zavar jelenleg.
A Portmon monitorozása szerint időnként megjelenik 1000-1200 sor IOCTL_SERIAL_SET_WAIT_MASK. Ilyenkor adatra vár?

A WEB oldaladon megtaláltam a CRC-s anyagot. Pihentetésképpen ismerkedek vele.

Adatra vár. Azt érdemes megnézned, hogy milyen eseményre (event) reagáljon a progid. A monitorozás szerint be van állítva egy csomó ilyen esemény.
RXCHAR (beérlezett karakter), TXEMPTY (Tx puffer üres) stb. Szerintem válaszd ki a számodra szükséges eseményt ami kell, és azt detektáltasd. Például RXCHAR vagy RXFLAG. Utána pedig a programoddal vizsgáltasd meg, hogy ez következett-e be, ha nem akkor várjon rá. Ez pedig szerintem egy jó oldal a crc számításokhoz.

Még egy gondolat. Ha az Rx puffered kicsi, és nincs kiürítve, akkor nem tud több adat beérkezni. "Setupcomm" funkcióval be lehet állítani 8192-re a te esetedben, ami elég 6000 byte fogadásához.

A VB6-ban a soros komponens tulajdonságainál 32750-re van beállítva a bemeneti puffer mérete. Az eszköz kezelőben is teljesen maxra van állítva a vételi és átviteli puffer méret.

Az bőven elég Nem okoskodó akarok lenni. Csak segíteni szeretnék. Személy szerint , ha ilyesmit fejlesztek mindig csinálok egy log rész a programomban és mindent oda kiíratok, hogy tudjam hol tart és mit csinál.Én Delphiben fejlesztek Pl.: egy külön memo-ban kiiratom "port nyitás sikerült" vagy "adatra várás" majd "adat megérkezett" stb. A pc oldal felőli részt pedig úgy tesztelem, hogy Rx-Tx összeköt és önmagamnak küldök adatokat a te estedben 6000 byte-ot , ha ez megjön Pc oldalon valószínűleg minden ok-> jöhet a hardver vizsgálat.

A Portmon adatra várását nem értem. A dsPIC-nek folyamatosan kellene küldenie a mérési adatokat. A hardvernél lesz a probléma. Eleinte nem is jelentkezett ez a fajta hiba. Ahogy egyre nagyobb lett a PIC programja hirtelen előjött. Persze a programot Pascal-ban írom. Előfordulhat hogy a fejlesztő proginak van valami kehéje.
Délután megpróbálkozok azzal hogy kiiktatom a VB6 programomat. A PIC csak egy számértéket vár. Jelen esetben Hex 0A, és már küldi is a mérési értékeket. Ezt bármilyen más sorosport kezelő programmal el tudom küldeni neki.

Kicsit kezdenek összekutyulódni a dolgok! A PC programodnak le kell tudnia kezelni, ha nem érkezik meg az összes adat időben, vagy ha CRC hibás a csomag.
Addig is az adatfolyamot érdemes leellenőrizni egy logolni tudó terminállal, pl. Brayterminal(képes időzített Makrók elküldésére is). Ez előre is sokmindent megmond, bár CRC-t nem ellenőriz.
Ha lesz időm összeszedem a CRC-s rutinjaimat és felteszem...

Szia! Ez a példa C18-ban íródott, de bármilyen nyelvre könnyen átültethető.

Köszönöm a CRC-s anyagot. Belátom használnom kell.

Próbálgattam a hardverem a HTERM nevű programmal.
Bárcsak a VB6 programommal is ilyen szépen menne az adatok vétele. A Portmon-ban sem látok semmi várakozást , csak az adat folyik be és karakterszámra is megvan mind.
A soros puffer nem törlődik. Ha mintavételezési sebességet váltok akkor egy ideig még az előző mintavétel adatai jönnek.

Nem törlődik? Azt olvastam az MSDN-n, hogy a "MSComm1.Input" kiolvassa és törli a puffert.
"Input -Returns and removes characters from the receive buffer."

Két órát vacakoltam az adatokkal. Lehet túlságosan bele bonyolódtam. Utána gondolkodtam a puffernek törlődnie kellett.
Egy a lényeg, a VB6-ban írt programom hibás. Remélem rájövök mi volt a probléma és nem magától javul meg.

Sok sikert.

Nem tudjátok, az MCP2200 OSC2 lábát tovább lehet vinni mikrokontrollerre? Konfigurációs szoftverében és az adatlapon nem látok semmilyen beállítási lehetőséget.

Igen, lehet, bár sok értelmét nem látom.

Pl. az az értelme hogy az AVR-nek lenne egy stabil, 12MHz-es kvarckristályos órajele, külön kristály nélkül!
Nem kell +1 kvarcot venni, és a panel mérete is kisebb lehet!
Egyedül az a kérdés hogy az MCP2200 erősített jelet használ-e vagy sem. Oszcilloszkóppal meg kell nézni!