Ik heb een stuk code om van de P2000T data te dumpen naar mijn Mac. Op Mac draai ik in Processing(Java) een tooltje om de zaken binnen te hengelen.
Ik gebruik deze interface:
https://www.onlinekabelshop.nl/usb-a-m-naar-9-pins-sub-d-25-pins-sub-d-m-seriele.html
Stel ik draai heel simpele code als dit:

import processing.serial.*;
Serial SerialUSB;

for (int n=0;n<Serial.list().length;n++){
  println(Serial.list()[n]);
} 

Op mijn mac krijg ik dan in de console
/dev/cu.wchusbserial1440
En dat kun je dan makkelijk kiezen, en ik kan het vervolgens uitlezen.
Als ik dit onder windows doe, krijg ik enkel het ubervage COM4
En vervolgens leest ie ook niks, terwijl die op de Mac gewoon alle binnenkomende bytes herkent. Daarnaast is het heel lastig om je code de goede poort te laten selecteren, het COM nummer is steeds anders.

Iemand een idee hoe je dit kunt oplossen?

Het bleek een driver ding. Ik had een USB RS232 interface van Onlinekabelshop omdat zij 25 pins hadden, maar hun driverlink leidde naar iets dat installeerde maar niet correct werkt. Bij Tinytronics stond wel een correcte driver bij de 9-pins variant.

Tips voor dealen met vage poortnamen blijven overigens welkom. Waarom gaat dit nog steeds op de DOS manier?

[Bericht gewijzigd door blanka op (18%)]

com poort heeft niets met msdos te maken toch, of het nu linux windows, mac of andere besturingssystemen zijn allemaal kennen ze het fenomeen compoort.

Elk besturingssysteem gaat er anders mee om maar de data die er in en uitgaat is gelijk.

De manier waarop een OS de naam toewijst aan de poort verschilt per OS. DOS deed het goed, net als Linux. Windows wil nog wel eens willekeurige nummers toewijzen. Als de poort die je in de driver instelt, niet gewoon op z'n plek blijft, weet ik helaas ook geen oplossing.

Op zaterdag 24 februari 2024 10:05:30 schreef blanka:
Het bleek een driver ding. Ik had een USB RS232 interface van Onlinekabelshop omdat zij 25 pins hadden, maar hun driverlink leidde naar iets dat installeerde maar niet correct werkt. Bij Tinytronics stond wel een correcte driver bij de 9-pins variant.

Tips voor dealen met vage poortnamen blijven overigens welkom. Waarom gaat dit nog steeds op de DOS manier?

Misschien helpt dit? https://sourceforge.net/projects/serial-port-monitor/

RS232 is absoluut niet ouderwets 'DOS-achtig'; het is alleen vermomd als USB, en USB is een LAN die opstart voordat de computer wordt opgestart.

Het USB-gedrag is afhankelijk van de gebruikte Windows-versie, hardware zoals laptop of desktop, en de gebruikers-toegangsrechten.

Het verspringen van de USB-(COM)poort wordt veroorzaakt door USB-multiplexer-chip; deze kan uitgeschakeld worden.

Kortom; wat voor PC-hardware? Welke Windows?

Ik gebruik dit programmaatje altijd daarvoor (detecteert alleen USB serial ports, geen 'echte'...

MSSerial.zip

USB is natuurlijk geen LAN, en of er een 'multiplexer chip' inzit is maar de vraag. Het gedrag dat Harm beschrijft herken ik wel, en je kunt soms inderdaad proberen om vaste toewijzingen te maken als Windows dat niet doet, wat af zal hangen van de Windowsversie en de drivers. Met wat gerommel om het in te stellen heb ik dat bij een klant en in de werkplaats al jaren stabiel draaien. Ik denk dat er op registry-niveau soms ook wat te doen is, maar daar heb ik geen ervaring mee.

[Bericht gewijzigd door maartenbakker op (13%)]

=> ”USB is natuurlijk geen LAN,...”

Dat USB een LAN is, is inderdaad behoorlijk onbekend. Veel mensen hebben geen idee hoe USB precies werkt, maar wellicht dat de bijlage verhelderend is.

=> ”... en of er een 'multiplexer chip' inzit is maar de vraag. ...” Ja, dat is inderdaad de vraag; oudere computers gebruikten deze chips niet, en hebben dus geen last van het verspringen. De bijlage verklaard ook dit gedrag, en op https://www.ti.com/interface/usb/redrivers-multiplexers/overview.html
kun je informatie vinden over dit soort chips.

Op dinsdag 27 februari 2024 10:17:29 schreef Harm J Seef:
Dat USB een LAN is, is inderdaad behoorlijk onbekend. Veel mensen hebben geen idee hoe USB precies werkt, maar wellicht dat de bijlage verhelderend is.

USB is geen LAN, en die bijlage weet niet hoe USB werkt:

USB is
hardwarematig een parallel geschakelde LAN van twee datalijnen (Rx/D+ en
Tx/D-)

De datalijnen van USB worden bijna altijd DP en DM genoemd, en vormen een differential pair. DP bevat dus altijd dezelfde data als DM (alleen dan geinerteerd). Om onderscheid te maken tussen Rx en Tx doet USB aan half duplex.

En er staat nog wel meer onzin in die ik niet allemaal ga herhalen.

Natuurlijk kan een LAN prima met half-duplex verbindingen werken (het oorspronkelijke 10Mbit ethernet over coax kon ook niet anders), maar voor een LAN is het toch wel vereist dat er meerdere autonome apparaten aan kunnen aangesloten worden. Dat is bij USB in feite niet mogelijk, er is altijd maar een Host, de rest is device.

=> ”Als ik dit onder windows doe, krijg ik enkel het ubervage COM4. En vervolgens leest ie ook niks, terwijl die op de Mac gewoon alle binnenkomende bytes herkent. Daarnaast is het heel lastig om je code de goede poort te laten selecteren, het COM nummer is steeds anders.”

Hm, de ervaren Mac-gebruiker merkt nu hoe ongebruikelijk Mac OS eigenlijk is. Hetzelfde probleem ontstaat wanneer een niet Mac-gebruiker onder Mac OS zaken wil regelen.

Wellicht kan de bijgevoegde informatie over binnenharken van logdata je helpen.

=> ”USB is geen LAN”

LAN is een containerbegrip en staat voor Local Area Network; LAN is geen synoniem voor ethernet of welk ander protocol dan ook. USB staat voor Universele Seriele Bus; de kernwoorden zijn ‘serieel’ wat gaat over de wijze van communicatie, en ‘bus’ over de systeemwijze van bedraden.

=> ”En er staat nog wel meer onzin in die ik niet allemaal ga herhalen.”
Ja, dat kan. Als mensaap aap ik de informatie na van https://bretjohnson.us/ . Maar met zijn onzin gebruik ik toch maar mooi USB onder DOS, en heb ik inmiddels heel wat USB/RS232-problemen opgelost.