Svenska ElektronikForumet

Det hela blir ju väldigt spekulativt och lite meningslöst när vi inte vet
vad den där leverantören faktiskt menar med "USBporten är för kvick"...
USB är USB, i princip. Eller är det bara en undanflykt från leverantören
för att slippa hjälpa till att fixa det?

Men hur som helst. Det är ju bara att testa med någon av de
PCMCIA eller Express Card som t.ex Dustin har med RS232.
Det är väl inget hemma/hobby projekt?

Om man nu analyserar lite och utgår ifrån att en USB-RS232 är "för snabb".

Då måste detta betyda att den enhet som tar emot från USB-dongeln är för långsam, alltså att det måste vara någon vänttid, t.ex. från fråga till svar och/eller mellan varje byte.

Felet är alltså inte i USB-dongeln men i enheten som ska kommunicera med dongeln.

Jag ser ingen annan förklaring.

Slutresultatet är alltså att givaren är uråldrig eller har ett uselt program - eller en kombination därav. Så istället för att fokusera på dongeln är det kanske dags att fokusera på givaren?

Givaren går för 40kkr och det är klart att tillverkaren inte vill erkänna att både hård och mjukvara inte hängt med.

Det sitter dock redan många, minst hundra stycken, ute i fält, och de ska kalibreras två gånger om året. Att byta ut dessa mot nya givare i samma klass kommer gå på minst fem miljoner.
Vilket betyder att det plötsligt är värt det att ha kvar en hög gamla laptops enbart för att de har RS232port.

Om man tar reda på hur kommunikationen ska se ut så kan man nog programmera en mikrokontroller att agera buffert som skickar vidare datat i rätt hastighet.

Seroster skrev:Tillverkaren av programmet (panaview)
http://www.ge-mcs.com/download/co2-flow/panaview.pdf
Har sagt att USBporten är för kvick, och att vi ska prova med en WinXP dator...
Vad de bygger det på, om något, är mer än jag vet. Det kan lika gärna vara så att de är lika lost som alla andra.

Gamla datorn använder en 9pol Dsub RS232 för att kommunicera med givaren, det går bra.
Nya datorn använder en USB-9pol Dsub RS232 för att kommunicera med givaren, alltså Dator-Dongel-Givare. Det funkar inte alls.

Jag håller just nu på med att göra om program för styrning av industimaskiner via RS232, ett gammalt XP-program skrivits om till dot-NET hade en del buggar som jag skulle fixa. Under arbetets gång upptäckte vi att både det gamla (XP) och nya (.NET) programmet hade väldigt svårt att kommunicera via RS232-USB dongel. I båda fallen berodde det på dålig programmering, dvs. man lät timingen (slumpen) styra hur många bytes som lästes in åt gången. Det fungerade (oftast) med vanlig COM-port, men blev katastrof med USB-RS232-omvandlaren.

Istället för att programmera rätt hade man alltså provat sig fram tills det fungerade, med fördröjningar mm.... som gjorde programmet långsamt och segt trots ganska bra hastighet på RS232 (38400 baud). När jag analyserat kommunikationen ett par dagar skrev jag en helt ny serieportsrutin som inte var beroende av hastighet, timing, pauser etc. och det fungerar dygnet runt utan ett enda fel. Så kontakta gärna GE-sensing, jag går gärna igenom deras programvara för att fixa till serieportsrutinerna (Mot konsultarvode förstås). (Nu kan det hända att deras sensorer använder sig av MODBUS eller liknande tidsbaserat interface, då kan det bli lite svårare att få en PC att göra rätt. Men även det ska gå bra om man gör rätt.)

Det behöver inte vara snabbheten det hänger på även om det uttrycks så. Äldre program för serieportskommunikation, i synnerhet om det hade utvecklats redan på DOS-tiden, det var inte ovanligt att dessa skrev helt eller delvis direkt till port-registerna.
Det gjordes bl.a. för att aktivera utökad buffert, vilket somlig hårdvara erbjöd upp till 16 resp 32 tecken har jag för mej var rätt vanligt, men som kanske inte direkt stöddes i BIOS, eller helt enkelt för att man som en första koll, verifierade att det finns en konkret hårdvara på en av de 4 kända port adresserna. Det är rätt vanligt att sådana program sedan vägrar köra om de tilldelas port-nummer över COM4.
Ett exempel på sådan mjukvara. och där man beskriver lösning vad gäller port-numreringen.
Att direkt komma åt portarna fungerade oftast utan på problem upp till Win98 och Win2k för DOS-program som givits Windows-kostym. För XP gick det skapa hårdvaruaccess utan allt för stort krångel men nyare Windows versioner är rätt kinkiga med program som försöker direkt accessa portar eller annat än eget allokerat minne. Det går alltid gå runt begränsningar men kräver med visst krångel.
Enklaste jag kan tänka mej är att installera en virtuell XP som erbjuder åtkomst till virtuella hårdvaruportar. Det ska gå bra i t.ex. VMware.

Det finns ett annat problem som är relaterat till USB-stacken, där timing-variabler ändrades av Microsoft efter WinXp så att somliga FTDI-chip inte längre blev identifierade som serieport. Det handlade om att tidigare USB-stacken hade vidare timing-fönster än vad USB-standarden anger för initial handskakning. När man korrigerade detta fick somliga FTDI-chip problem. Det hade inget att göra med senare tiders problem med Kina-FTDI-kloner som evt ratas av nyare FTDI-drivers.
Avhjälpte detta timing-problem i ett fall där jag kopierade XP USB-stacken till en Win2008 med lyckat resultat. Först vägrade Win2008 att ta emot filerna och kopierade på egen hand nya filer. Fick radera alla backup-källor och stänga av internet, sedan svalde den filerna och protesterade inte vid efterföljande omstarter. Den har rullat så nu i ett par år utan problem.

Man kan justera överförd blockstorlek och latens, vilket kan ha betydelse för stabilitet i överföringen. Typiskt identifieras porten korrekt i Windows men kan t.ex. till synes utan anledning sporadiskt sluta hämta data. Här är ett exempel på hur man kan justera dessa parametrar för bättre funktion vid långsam serieports-överföring.

Om det nu inte skulle vara ett FTDI-chip som emulerar serieport så får TS glömma ovan text.
Skulle det t.ex. vara en SiLab-krets så kan en enkel lösning vara att gå över till FTDI, eller tvärs om.
Likaså var detta bara exempel på vad som kan hända och förslag på åtgärd vid olika felsymtom.
Hyperterminal som finns installerat på de flesta Windatorer bör ge en första snabb koll hur felet yttrar sej och därmed möjliga åtgärder,
dvs är hårdvaru-kommunikation över serieporten död, går det inte nå mjukvaruporten eller om det är applikations-mjukvaran som fallerar.
Det kanske kommer beskrivning av felsymtom? Vi är ju bara på sidan 4 än.

Felsymptomen är väl "programvaran får ingen kontant med givaren". Och som flera varit inne på, det är mest troligt att det beror på dåligt skriven mjukvara.

Seroster skrev:Givaren går för 40kkr och det är klart att tillverkaren inte vill erkänna att både hård och mjukvara inte hängt med.

Det sitter dock redan många, minst hundra stycken, ute i fält, och de ska kalibreras två gånger om året. Att byta ut dessa mot nya givare i samma klass kommer gå på minst fem miljoner.
Vilket betyder att det plötsligt är värt det att ha kvar en hög gamla laptops enbart för att de har RS232port.

Alltså, när det är en sån stor apparat vi pratar om, varför ens forska och dona och hålla på med gamla laptops?
https://www.dustin.se/product/5010786420/probook-650
Första bästa på dustin, 5500kr för en ny dator med inbyggd RS232-port.

Är operativet ett problem så kör VMWare med en XP-installation eller liknande.

Felmeddelande vid användning av RS232 dongel.

Detta är inget jag normalt pysslar med om dagarna.

FormerMazda skrev: Första bästa på dustin, 5500kr för en ny dator med inbyggd RS232-port.

Problemet är väl att den där seriporten internt är ansluten via USB, d.v.s. den är förknippad med exakt samma problem som en extern omvandlare.

Min gissning är att programmet är så dåligt skrivet att det räknar med en viss fördröjning innan svaret kommer, men eftersom porten är för snabb så hinner svaret komma innan programmet har börjat läsa.

Men programmet måste ju då vara skitdåligt skrivet som inte klarar av att hantera att en port buffrar datat?

Det är ju en timeout på 3,5 sekund?!

Om den nu är så ansluten och att det är problem med externt ansluten RS232?

Har en HP ProBook själv på jobbet, och den ser "äkta" ut när man kollar i enhetshanteraren. Med detta menar jag att den inte syns bland USB-pryttlarna och den har IRQ och I/O-resurser. Men jag rättas gärna om jag har fel där.

Seroster skrev:Detta är inget jag normalt pysslar med om dagarna.

Är du säker på att din USB-dongel tilldelas com-port 1?

Det som sannolikt händer är inte för långsamt svar, det är däremot nog datorn som är för snabb för att givaren inte har hunnit göra klar för att ta emot data.

Så det är inte heller USB-RS232 som är för snabb, det är givaren som är för trög.

Den verkar ju köra med "challenge - response" så datorn frågar om den finns, givaren svarar och det svar reagerar datorn på "för snabbt". Enda svar som kvarstår för mig är att givaren är usel!

Och går man lite längre känns de osannolikt att mjukvaran köra direkt till serieportens register som i de gamla DOS-dagar (t.o.m Win98) - så återigen pekar det på att givaren är usel i programvaran.

Min gissning är att givaren är en kassako för säljaren, den blev utvecklat för en del år sedan och utveckling har mest varit att debugga felen men inte uppgradera hårdvaran. Och om den t.ex. är baserat på en 8031 och har haft en dålig programmör kan jag förstå om det finns problem. Jag skulle tro att serieporten är pollad, detta skulle enkelt kunde förklara det hela.

Men utan något koll på om det rent faktisk sker någon kommunikation mellan enheterna är det omöjligt att definiera vad som går fel! Det skulle ju vara mycket enkelt att ta ett par DSUB9 (eller vad som används) och göra en avgrening. E fullkopplat hane till hona och sedan en hona mer som är kopplat direkt till pin 5 (GND) och har en omkopplare som kan växla mellan pin 2 och 3 på det fullkopplade paret och har COMM kopplat till pin 2 på den extra hona.

Då kan man sniffa på kommunikationen och se om det finns någon kommunikation alls. En sådan koppling använder jag en hel del.