[XP] Comport problemen onder XP, 2k/9x/ME/NT werken wel

[Fludizz]

Ok, dit is een beetje een vreemd probleem... heb er ook lang op lopen zoeken, maar kan niets vinden, behalve één hit. Maar die oplossing was al geprobeerd zonder succes.

Het gaat om een stukje DOS-software dat van een barcode scanner data uitleest via de COM poort. Dit werkte allemaal perfect onder alle windows versies. Maar... sinds kort zijn er een aantal klanten van het bedrijf waar ik stage loop die zijn overgestapt naar WinXP. Om een of andere reden schijnt onder Windows XP de compoort niet goed uitgelezen te worden. De eene klant kan niets uitlezen vanaf de COMpoort, de andere klant kan wel wat uitlezen, echter gaat het bagger traag en komt er op een gegeven moment een buffer overflow.

De scanner zelf werkt op 2400 baud, de compoort onder XP is ingesteld op 2400 baud, verder met de identieke instellingen als bij andere windows-versies. Het programma draaien onder Windows 95 of 98 compatible mode zou het probleem moeten oplossen volgens een hit over een soortgelijk probleem, maar dat doet het echter niet. Het probleem blijft bestaan.

In de Microsoft KB kan ik niets vinden over bekende problemen met Windows XP en COM port uitlezen. Google gaf enkel de hit over een soortgelijk probleem, en verder nutteloze hits.

Hier op GoT kon ik ook niets vinden erover...

Can someone please help me out? ik kom er zelf ook niet meer uit...

[sebastius]

Gewoon een nieuwe barcode scanner die op de keyboard interface werkt pakken? Is dat misschien een heel dom idee, maar die doen het namelijk ALTIJD.

[Fludizz]

Het is goedkoper om dan terug te gaan naar windows 2000 gezien de hoeveelheid klanten die dit stukje software met bijbehorende scanner gebruikt

[Abbadon]

Move A61 -> WOS

[elevator]

Fludizz schreef op woensdag 22 december 2004 @ 11:53:
Het is goedkoper om dan terug te gaan naar windows 2000 gezien de hoeveelheid klanten die dit stukje software met bijbehorende scanner gebruikt

Controleer eens met 'mode com1' in een command prompt of je comport écht wel op 2400 bps staat

[Fludizz]

@elevator: Het lijkt mij stug dat ie niet op 2400bps staat, aangezien er wel degelijk een connectie is waar data over komt, echter onder windwos 2000 gaat alles perfect, uitlezen van de data en alles op de goede snelheid. Echter op dezelfde machine, die nu windows XP draait, gaat het data lezen extreem langzaam (voor zover 2400bps al snel is )

XP leegt schijnbaar de COM-port buffer niet snel genoeg, waardoor van de 20 gescande artikelen maar 2 tot 5 doorkomen, en bij de rest een buffer overflow ontstaat. Wat is er zoveel verandert in de COM-poort afhandeling tussen 2k en XP dat het in XP niet goed gaat, en in 2k of lager wel goed gaat?

offtopic:
@Abbadon, dank

[ Voor 3% gewijzigd door Fludizz op 22-12-2004 12:26 ]

[djexplo]

Die buffer groote kon je vroeger al tijd zelf instellen in ms-dos of in een ms-dos programma. Dit commando om de buffer groote, groot te zetten en baud rate goed, kan je in je autoexec.nt en config.nt zetten.

Zie ook deze informatie over win3.11 (waarschijnlijk werkt het in winxp op ongeveer de zelfde manier):

If you've got WfW 3.11, then you should modify the following entries in system.ini, [386enh] (n is the number of the COM port referred to):
COMnFIFO=1* ; enables the RX-FIFO
COMnBuffer=128* ; buffer size, here the standard size has been chosen, enlarge the buffer size if apps "lose" characters while sending/receiving from a COM port (my notebook needs 2048 bytes or more, current setting: 32767 bytes)
COMnTxFIFO=1 ; the transmit FIFO isn't enable by default, so you should enable this option! (16550A)
COMnRxTrigger=4 ; After so and so many bytes of data an interrupt is generated - 8 is quite a good value (cybercom.drv's default), but 4 is even better (16550A)
COMBoostTime=20* ; that's the time a VM has to process a COM interrupt; the default is 2; should only affect DOS terminal programs in windows

Verder moet je ook kijken naar instellingen als CTS/DSR handshaking kan bufferoverflow voorkomen. En naar DSR sensitivity moet waarschijnlijk aanstaan. Timeout is mischien ook handig om in te stellen, en je aantal data/stop bits en parity soort moeten natuurlijk overeenkomen met de scanner. (Deze gegevens kan je idd. zie reactie van Elevator bekijken en wijziggen met "mode com1")

[ Voor 114% gewijzigd door djexplo op 22-12-2004 12:44 . Reden: aanvulling ]

[Fludizz]

@ djexplo

We hebben helaas momenteel niet de mogelijkheid om het te testen, aangezien er op dit moment geen klant aan de lijn hangt met het beschreven probleem.
Verder kan je de buffer wel vergroten, maar dat is probleem-verplaatsing. Daarmee is het nog steeds niet duidelijk waarom XP de com-poort buffer zo langzaam leeghaalt.

[ Voor 5% gewijzigd door Fludizz op 22-12-2004 12:54 ]

[elevator]

De buffer leeghalen is geen verantwoordelijkheid van het OS maar van de applicatie (je hebt niet toevallig toegang tot die appl?).

Ik zou je nogmaals aanraden die speed te controleren. Een 'mismatched' BPS rate tussen twee comporten kan zeker wel voor 'vreemde' problemen zorgen.

[Fludizz]

Dan blijf ik mij afvragen waarom het wel perfect werkt onder windows 2000 en oudere versies, maar zodra ze windows XP erop zetten niet goed meer met dezelfde instellingen... Hoor trouwens net dat het niet bij alle Windows XP machines het geval is.

Zou trouwens een handshake onderling niet dat snelheidsverschil moeten afvangen?

[nextware]

Staat de optie "Fifo-buffers gebruiken" van je Com poort wel aan ?

Ik heb zelf ook onder Windows XP wel eens zo'n probleem meegemaakt. Onder alle windows versie werkte het compoort apparaat ( tripkey reader ) als een trein. Onder Windows XP echter niet.

Toen ik deze functie had aangezet, werkte de reader wel goed.

hoe in te stellen ? =>

Ga naar apparaatbeheer ( hoe je hier naar toe komt wel je ongetwijfeld wel ), Klik dan op het plus-tekentje naast poorten -> rechtermuisknop je op je Com1 -> Ga naar tabblad Poortinstellingen -> klik daar op Geavanceerd

Nu zou het bovenste vakje aangevinkt moeten worden...

[Fludizz]

Ja die staan aangevinkt. Dat is het eerste wat gecontrolleerd werd, of de instellingen van de com-poort correct waren. Daarom is het zo vreemd dat het niet goed werkt.