Alte .net Apk mag keine USB to RS232 Adapter

Stefan M. schrieb:
> Nun ist die Frage gibt es Adapter die das so senden wie com0com, also
> eher so wie eine "echte" RS232 oder gibt es noch PCIe Karten die das
> können?

Echte PCIe UARTs gibts immer noch. Sind auch gar nicht teuer. Beispiel:

https://www.delock.de/produkt/89555/pdf.html?sprache=de

fchk

Schlaumaier schrieb:
> Dafür gibt es 3 Gründe.
>
> 1. Der Treiber für den Adapter ist Mist.
>
> 2. Der Chip auf den Adapter wird von Windows nicht wirklich unterstützt.
> (In den Zusammenhang mal an die Gefälschten Chips denke)
>
> 3. Der Adapter ist fehlerhaft.
>
>
> Ich hatte eine ähnliches Problem auch schon. Da war es ein Gerät zum
> Auslesen eine Motorrad. Ich habe 6 Treiber ausprobiert bis ich eins auf
> einen auf einer China-Seite gefunden habe der funktioniert.
>
> Besonders Stressig sind einige Adapter die den Prologic.Treiber nutzen.
>
> Mein Rat. Versuch es mit einen anderen Adapter. Am besten ein von einer
> Markenfirma. Oder frag mein EDV-Händler deines Vertrauen mit welcher
> Kombi (Adapter und Treiber) er gute Erfahrungen gemacht hat.

Hi,

Hatte ich auch beides im Verdacht...aber:

1. Treiber habe ich von den Chip Hersteller Seiten
2/3. Beide Adapter sind Markenware.

DerEinzigeBernd schrieb:
> Stefan M. schrieb:
>> habe hier eine .net basierende APK.
>
> Was soll eine "APK" sein?
>
>> ist mir aufgefallen, dass die USB to Serial Konverter Zeichen für Zeichen
>> senden
>
> Kommt drauf an, wie sie konfiguriert sind. Empfangsfifogröße,
> Triggerlevel etc. lassen sich jedenfalls bei FTDI einstellen.

O.K. schaue ich mir mal an.
Wie müssten diese stehen, damit die Daten nicht zerstückelt werden?

Jochen schrieb:
> Das ist ein Problem, mit dem Servicetechniker von älteren
> Industriesteuerungen seit dem Aussterben echter serieller Ports kämpfen.
> USB ist nunmal Paketorientiert.
> Ich konnte mir oft damit helfen, die Software in einer XP-VM laufen zu
> lassen. VMWare hat die Pakete schön zu einem Stream geglättet.

Leider nicht machbar... da Hypervisor bei unseren Company Images deaktiv 
ist :-(

Frank K. schrieb:
> Stefan M. schrieb:
>> Nun ist die Frage gibt es Adapter die das so senden wie com0com, also
>> eher so wie eine "echte" RS232 oder gibt es noch PCIe Karten die das
>> können?
>
> Echte PCIe UARTs gibts immer noch. Sind auch gar nicht teuer. Beispiel:
>
> https://www.delock.de/produkt/89555/pdf.html?sprache=de
>
> fchk

Hi Frank,
habe schon vorhin ein Bestellung ausgelöst... allerdings die 89444.
Ich bin mir nur nicht sicher ob, dass über den PCIe sich auch so verhält 
wie eine Echte, oder ob es ähnlich quergeht wie bei USB.

Oh Leude

natürlich meine ich APP und nicht APK.
Wir können es auch gerne altes von XP stammendes Progrämmchen nennen.

Verzeiht mir diesen Fauxpas^^



Gruß
Peff

Schlaumaier schrieb:
> Kleiner Hinweis an den TO.
>
> Vielleicht !!! stimmt die Geschwindigkeit der Ser: Schnittstelle nur
> nicht, und deine Software und der Treiber bekommen das nicht auf die
> Reihe.
>
> Ich würde (nur aus Testzwecken) mal die Einstellungen direkt am Treiber
> machen. Dazu im Gerätemanager, über Eigenschaften des Gerätes die Speed
> + co. einstellen.

Hi,
habe alles schon hin und her getestet... :-(

Schlaumaier schrieb:
> michael_ schrieb:
>> Oft ist eine Ser. auf der Hauptplatine noch vorhanden.
>> In Form von einem Jumper-Block.
>> Schon nachgesehen?
>
> Kann ich bestätigen.
>
> Ich habe schon einige meiner alten "Anschlussbleche mit Kabel dran" an
> Freunde gegeben, weil die, die alte Schnittstelle noch brauchen. Sogar
> LPT-Schnittstellen tauchen da auf. Aber das eher selten.
>
> Es liegt einfach daran das die Mainboards im 1/10 Cent-Bereich
> kalkuliert werden. Und man mit Zubehör viel Geld verdienen kann.
>
> Es gibt kaum ein Rechner in den ich ne Festplatte nachrüste ohne das ich
> ein Strom-Verteiler-Adapter kaufe. Damals konnte ich die übrig
> gebliebenen Anschlüsse als neunschwänzige Peitsche weiterverkaufen.

Hi,
is nen Dell den ich zur Verfügung habe... da is nix drin...

Hmmm schrieb:
> Stefan M. schrieb:
>> dabei ist mir aufgefallen, dass die USB to Serial Konverter Zeichen für
>> Zeichen senden, com0com alle Zeichen in einem Rutsch.
>> Die AKP kommt also nicht mit den "zerstückelten" Daten zurecht.
>
> Das wird kaum der Grund sein. Auf einer echten RS232 kommen die Daten
> auch als einzelne Zeichen an, sofern sie schnell genug gelesen werden.
> Bei 8N1 vergehen zwischen den Zeichen 1/(Baudrate/10) Sekunden.
>
> Ich denke eher, dass die Software ein sehr straffes Timing erwartet.
> Windows hat beim Lesen von COM-Ports konfigurierbare Timeouts (sowohl
> zwischen 2 Zeichen als auch für den gesamten Lesevorgang), und wenn die
> zu knapp gesetzt sind, kann die zusätzliche Latenz des USB-Adapters
> tödlich sein.
>
> com0com ist da ein ungünstiger Vergleich, das schaufelt ja im Grunde nur
> ohne nennenswerte Latenz Daten hin und her.
>
> Schlaumaier schrieb:
>> Besonders Stressig sind einige Adapter die den Prologic.Treiber nutzen.
>
> Das heisst Prolific, und für Prolific-Chips nutzt man halt
> Prolific-Treiber.
>
> Aber Probleme hatte ich damit auch schon, damals war es eine neuere
> PL2303-Version mit gleicher USB-PID, aber anderem Verhalten. Seitdem
> setze ich nur noch FTDI ein.
>
> Schlaumaier schrieb:
>> Von der Definition her, ist eine APK eine Teilgruppe der Gesamtgruppe
>> Programme.
>
> Für Dein sinnloses Gebrabbel gibt es einen Begriff, den ich aus Gründen
> der Höflichkeit nicht nennen möchte.


@Hmmm
Joa...habe nun auch noch mal mit dem FTDI getestet (von Delock).
Da kann ich an den Zeiten spielen wie ich mag, das wird nicht besser.
Allerding kommen bei dem Mal die Daten in einem Rutsch und Mal 
zerstückelt.

Beim Testen ist mir aufgefallen, dass die Waage vor den Werten immer ein 
paar Leerzeichen setzt. Diese sind der Grund für den Absturtz in dem 
Programm.
Wenn ich dem Programm reine Zahlen in "zerstückelter" Form reinpumpe, 
erkennt es immer nur die letzte Zahl. Vielleicht erklärt das irgendwas?

Stefan M. schrieb:
> Frank K. schrieb:
>> Stefan M. schrieb:
>>> Nun ist die Frage gibt es Adapter die das so senden wie com0com, also
>>> eher so wie eine "echte" RS232 oder gibt es noch PCIe Karten die das
>>> können?
>>
>> Echte PCIe UARTs gibts immer noch. Sind auch gar nicht teuer. Beispiel:
>>
>> https://www.delock.de/produkt/89555/pdf.html?sprache=de
>>
>> fchk
>
> Hi Frank,
> habe schon vorhin ein Bestellung ausgelöst... allerdings die 89444.
> Ich bin mir nur nicht sicher ob, dass über den PCIe sich auch so verhält
> wie eine Echte, oder ob es ähnlich quergeht wie bei USB.

Üblicherweise verhalten sich diese Karten wie ein Onboard-UART - die 
Registersätze sind kompatibel, und damit sollte auch das Verhalten 
gleich sein. Gut, von dem Chip auf Deiner Karte habe ich bislang noch 
kein Datenblatt gesehen, daher kann ich das jetzt nicht genau sagen. Bei 
der von mir vorgeschlagenen Karte kenne ich den Chip und das Datenblatt 
zum Chip, und das hat bei mir bislang keine Probleme gemacht.

fchk

Frank K. schrieb:

> Üblicherweise verhalten sich diese Karten wie ein Onboard-UART - die
> Registersätze sind kompatibel, und damit sollte auch das Verhalten
> gleich sein. Gut, von dem Chip auf Deiner Karte habe ich bislang noch
> kein Datenblatt gesehen, daher kann ich das jetzt nicht genau sagen. Bei
> der von mir vorgeschlagenen Karte kenne ich den Chip und das Datenblatt
> zum Chip, und das hat bei mir bislang keine Probleme gemacht.
>
> fchk

O.K. gut zu wissen.
Bin mal gespannt ob's funktioniert

Schlaumaier schrieb:

> Es gibt 0 Grund warum die echte Leerzeichen senden sollte.

Naja... sowas habe ich schon häufiger erlebt. Diverse 
Laborgerätschafften können das auch.
Die Leerzeichen sind auch echte Leerzeichen. Also als HEX ne 20.

Die Waage sendet 6 Zeichen könnte also 999999kg senden...
100kg werden als 20 20 20 31 30 30 30 gesendet.

Hier noch mal ein Bild vom FTDI Adapter.
Bei dem funktioniert es häufig, dass die Daten in einem "Rutsch" 
durchkommen.

Erst 12345
dann 123456
die 12 ist dann Zerstückelt in 1 und 2
dann wieder 9876

Also wirklich Timing?

Hmmm schrieb:
> Auf jeden Fall klingt alles nach miserablem Code.
>
> Wenn Du an dem nichts ändern kannst und der Aufwand eines kompletten
> Nachbaus zu gross ist, könntest Du ein Proxy-Tool schreiben, das auf der
> einen Seite per com0com mit der Originalsoftware redet (und die Daten so
> liefert, wie sie die haben will) und auf der anderen Seite mit der Waage
> kommuniziert.
>
> Aber wenn es mit der bestellten Schnittstellenkarte läuft, hast Du ja
> eine Lösung.

Ja, der Code wird irgendwas zusammen geschustertes sein.
Quellen sind nicht vorhanden und neubau Aufwand zu immens.

An so eine Proxy Lösung hatte ich auch schon gedacht, da fehlen mir aber 
die Kenntnisse.

VM schrieb:
> Das alte OS in einer VM laufen lassen, die COM durchreicht

Geht nicht...
Hypervisor ist bei uns im Company Image deaktiviert...

Herby schrieb:
> c-hater schrieb:
>> ie auch immer: Ich würde empfehlen, das ganze untaugliche USB-Geraffel
>> wegzuwerfen und statt dessen eine COM-Schnittstellenkarte in den PC
>> einzubauen. Sowas kostet als Einzelstück für PCI oder PCIe 'nen schmalen
>> 10er und gut isses. Alle Sorgen weg.
>
> Ich achte beim Rechner-/Motherboard-Kauf immer darauf, dass mindestens
> eine Serielle eingebaut ist, brauche ich ständig (auch ohne Waage).

Leider haben wir in Grosskonzernstrukturen nur einen Warenkorb aus dem 
wir Hardware auswählen können und dort steht nur ein PC drin... ein DELL 
OptiPlex. Da is nix mit wünsch Dir was

c-hater schrieb:

> Dann taugt entweder das Programm nix oder (was ich fast vermuten würde),
> die Kommunikation mit der Waage folgt dem Modbus-RTU-Protokoll. Das wäre
> für Waagen nicht gar so ungewöhnlich.
>
> Also: um welche Waage handelt es sich konkret?
>
> Mit dieser Angabe könnte man nämlich überprüfen, ob die mittels
> Modbus-RTU kommuniziert. Wenn das der Fall ist, ist sehr wahrscheinlich
> nicht das Programm schuld. Es ist dann wohl schlicht und einfach nur
> normgerecht implementiert und berücksichtigt korrekt die timing
> constraints, die Teil des Modbus-RTU-Standards sind.
>
> Was allerdings blöd ist, wenn da noch USB drunter liegt. Darüber sind
> die contraints nämlich praktisch nur mit gezielter Manipulation auf der
> Ebene der Firmware des USB-Serial-Adapters sicher zu stellen. Von den
> verbreiteten Adapter-ICs ist das für den Normalsterblichen nur bei FTDI
> (mit FTDI-Treiber) möglich, zumindest soweit ich weiss.
>
> Die Normalkonfiguration (bei den meisten Wandlern halt die einzige
> verfügbare Konfiguration) ist auf maximalen Durchsatz optimiert, nicht
> auf minimale Latenz. Leider wäre aber genau das, was für Modbus-RTU
> nötig wäre.
>
> Wie auch immer: Ich würde empfehlen, das ganze untaugliche USB-Geraffel
> wegzuwerfen und statt dessen eine COM-Schnittstellenkarte in den PC
> einzubauen. Sowas kostet als Einzelstück für PCI oder PCIe 'nen schmalen
> 10er und gut isses. Alle Sorgen weg.

wie schon geschrieben, dass Prog. wird nicht das Beste sein.
Das genaue Model der Waage habe ich gerade nicht vorliegen, ist war 
italienisches meine ich - bis 20T geht die Wiegezelle.

Beim FTDI habe ich schon alles in Richtung min. Latenz gedreht damit 
läuft es wie im letzten Bildchen zu sehen.

Wenn das Problem mit einer COM-Schittstellenkarten sich erledigt, dann 
ist ja alles gut. Ist schon bestellt als PCIe. Hatte ein wenig bedenken, 
dass es da ggf. auch irgendwie zu Latenzen uns somit zum zerstückeln der 
Daten kommt.
Warten wir's ab, ich werde berichten.

Danke soweit!

Stefan M. schrieb:
> Wir können es auch gerne altes von XP stammendes Progrämmchen nennen.

Das waere eindeutig gewesen. :-)

Stefan M. schrieb:
> in DELL OptiPlex. Da is nix mit wünsch Dir was

Die haben durchaus noch COM-Schnittstellen - aber nicht immer nach 
aussen geführt.

Teilweise gibt es den Adapter noch mit PS2-Anschlüßen zusammmen.

Dirk B. schrieb:
> Stefan M. schrieb:
>> in DELL OptiPlex. Da is nix mit wünsch Dir was
>
> Die haben durchaus noch COM-Schnittstellen - aber nicht immer nach
> aussen geführt.
>
> Teilweise gibt es den Adapter noch mit PS2-Anschlüßen zusammmen.

Habe gestern schon reingeschaut, da ist lediglich noch die Möglichkeit 
nen DP Onboard zu erweitern.

Stell doch mal die Fifo-Größe im USB-Seriell-treiber auf ein vielfaches 
von der Anzahl der versendeten Bytes. Sind es denn immer 6Bytes, die 
gesendet werden? Klang gerade so. Dann stell doch den Buffer mal auf 6 
oder auf 12. Wenn der dann 6 Zeichen hat, schiebt er die auch auf einmal 
raus. Sonst wartet er diese typisch eingestellten 16ms ab uns versendet 
dann erst. Also, wenn man das auf 16ms stehen lässt.
Hat die Waage vielleicht noch diverse Handshake-Signale, die man in die 
Kontrolle der Datenübertragung mit einbeziehen lönnte?

Stefan M. schrieb:
> Leider haben wir in Grosskonzernstrukturen nur einen Warenkorb aus dem
> wir Hardware auswählen können und dort steht nur ein PC drin... ein DELL
> OptiPlex. Da is nix mit wünsch Dir was

Dann darfst du halt keinen Büro-PC kaufen, sondern einen 
Ersatz-Waagen-Bediencomputer, welcher unter Windows läuft, und eine 
RS232-Schnittstelle hat.
Wenn gar nichts hilft, kauf beim Waagenhersteller ein passendes Gerät, 
ansonsten irgend einen (Industrie-)PC bei einem dem Einkauf genehmen (= 
schon in SAP angelegten) Lieferanten.

Wenn der Großkonzern das nicht anders kann, dann kostet das halt extra.

Oliver

Stefan M. schrieb:
> Wenn das Problem mit einer COM-Schittstellenkarten sich erledigt, dann
> ist ja alles gut. Ist schon bestellt als PCIe. Hatte ein wenig bedenken,
> dass es da ggf. auch irgendwie zu Latenzen uns somit zum zerstückeln der
> Daten kommt.
> Warten wir's ab, ich werde berichten.

Und was machst Du wenn es einfach an der Virtualisierung liegt? Sobald 
dein Hypervisor mal nen Schluckauf wegen der anderen VMs bekommt oder 
das Windows selbst mal was einschiebt fliegt Dir wieder alles um dir 
Ohren.

Das Programm ist einfach Schrott. Halbwegs deterministische Abläufe 
(~1ms) auf PCs in der Microsoft Welt sind spätestens mit DOS gegangen. 
Serielle Schnittstelle ist ein Stream wo Daten halt auch mal gestückelt 
werden. So kompliziert und aufwändig kann das Programm ja wohl kaum 
sein. Wenn man die ganzen Arbeitskosten rechnet, die Du jetzt schon 
investiert hast... Sowas passiert halt wenn man bei der Software spart.

123 schrieb:
> Stefan M. schrieb:
>> Waage über RS232
>
>> USB to Serial Konverter
>
>> Ich habe bisher Prolific und FTDI basierte Adapter getestet.
>
> Geben die auch tatsächlich RS232 Pegel aus, oder nur TTL?

Jep, das sind RS232 Adapter ;-)

cppbert3 schrieb:
> Stefan M. schrieb:
>> wie schon geschrieben, dass Prog. wird nicht das Beste sein.
>> Das genaue Model der Waage habe ich gerade nicht vorliegen, ist war
>> italienisches meine ich - bis 20T geht die Wiegezelle.
>
> Komplizierte, featurereiche Software mit vielen optionen?
>
> Ansonste vielleicht doch nach programmieren, das protokoll scheint ja
> nicht so komplex

ich bin nicht so der Programmierer, fuxe mich gerade erst in Arduino 
also C++ und MicoPyton ein wenig ein.

Helge schrieb:
> 9876..
>
> Hast du ein Oszilloskop zur Verfügung? Es wäre vielleicht möglich, daß
> die Signale verschliffen sind und damit schlecht auswertbar. Hatte die
> alte Kommunikation auf PC-Seite vielleicht bipolare 232/TTL-Wandler?

Nein, da hing nen alter Lenovo PC dran mit noch echter RS232 und XP 
drauf^^

Oliver S. schrieb:

> Dann darfst du halt keinen Büro-PC kaufen, sondern einen
> Ersatz-Waagen-Bediencomputer, welcher unter Windows läuft, und eine
> RS232-Schnittstelle hat.
> Wenn gar nichts hilft, kauf beim Waagenhersteller ein passendes Gerät,
> ansonsten irgend einen (Industrie-)PC bei einem dem Einkauf genehmen (=
> schon in SAP angelegten) Lieferanten.
>
> Wenn der Großkonzern das nicht anders kann, dann kostet das halt extra.
>
> Oliver
Na, da kennt sich wer aus g
Aber den Hersteller der Wiegezelle und dem daraus geführten Messeinheit 
mit RS232 gibbet auch nimmer. Somit keine hardware über die zu beziehen.

Da das Ding bei uns in Netz soll kann ich leider nicht auf Ind. PC 
zurückgreifen... Es dürfen nur PCs mit Konzern-OS in Netz.
Und da über SCCM installiert wird geht nur freigegebene Hardware.

Läuft^^

Theoretisch könnte man einen eigenen USB-Seriell-Wandler programmieren 
welcher die seriellen Pakete "genau richtig" in USB-Pakete verpackt, 
aber das wäre schon eine ziemlich verzweifelte Maßnahme um so eine 
Software zu flicken...

Andreas M. schrieb:
> Stefan M. schrieb:
>> Wenn das Problem mit einer COM-Schittstellenkarten sich erledigt, dann
>> ist ja alles gut. Ist schon bestellt als PCIe. Hatte ein wenig bedenken,
>> dass es da ggf. auch irgendwie zu Latenzen uns somit zum zerstückeln der
>> Daten kommt.
>> Warten wir's ab, ich werde berichten.
>
> Und was machst Du wenn es einfach an der Virtualisierung liegt? Sobald
> dein Hypervisor mal nen Schluckauf wegen der anderen VMs bekommt oder
> das Windows selbst mal was einschiebt fliegt Dir wieder alles um dir
> Ohren.
>
> Das Programm ist einfach Schrott. Halbwegs deterministische Abläufe
> (~1ms) auf PCs in der Microsoft Welt sind spätestens mit DOS gegangen.
> Serielle Schnittstelle ist ein Stream wo Daten halt auch mal gestückelt
> werden. So kompliziert und aufwändig kann das Programm ja wohl kaum
> sein. Wenn man die ganzen Arbeitskosten rechnet, die Du jetzt schon
> investiert hast... Sowas passiert halt wenn man bei der Software spart.

Jep, das Prog. is nicht dolle und alt is es auch dazu.
War troztdem teuer ~10K habe hier noch die Rechnung aus dem Jahr 2005.
Hatte versucht darüber den Programmierer ausfindig zu machen, aber die 
Fa. gibt es nicht mehr, warum wohl^^

Das ganze läuft nicht auf einer VM, hier wurde lediglich mehrfach 
vorgeschlagen es auf eine VM zu portieren.

Niklas G. schrieb:
> Theoretisch könnte man einen eigenen USB-Seriell-Wandler programmieren
> welcher die seriellen Pakete "genau richtig" in USB-Pakete verpackt,
> aber das wäre schon eine ziemlich verzweifelte Maßnahme um so eine
> Software zu flicken...

Ich hoffe mal auf PCIe.
Ansonsten komme ich auf einen von Euch zurück^^
Ich kann sowas nicht programmieren.

cppbert3 schrieb:
> und eine .net Applikation lässt sich mit Glück
>
> mit den Tools:
>
> dotPeek: https://www.jetbrains.com/decompiler/
>
> oder
>
> .NET Reflector:
> https://www.red-gate.com/products/dotnet-development/reflector/
>
> dekompilieren (der resultierende Code ist meist wirklich gut zu lesen)
>
> dann sieht man genau wie die Kommunikation funktioniert

Das hört sich interessant an!!!

Stefan M. schrieb:
> Jep, das Prog. is nicht dolle und alt is es auch dazu.
> War troztdem teuer ~10K habe hier noch die Rechnung aus dem Jahr 2005.

Für eine Auftragsentwicklung sind 10k nichts.

Schlaumaier schrieb:

> Aber SO handelt keine Firma. !!!
in Grosskonzernen funktioniert das anders, da ist viel Politik im Spiel.
Wenn die Waage nicht mehr geht, bzw. das Prog. muss die zentrale Lösung 
genommen werden, die "schlechtere" Daten liefert.
Und ich koste eh - also heisst es sieh zu das es läuft

Mucky F. schrieb:
> Schlaumaier schrieb:
>> Mein Chef hat sich schon damals darüber aufgeregt wenn ich an defekten
>> Teilen herum gebastelt habe. Sein Anschiss = "Bestell was neues das ist
>> billiger".
>
> Also ich würde es mit einem COM Server testen.
> 
https://www.moxa.com/en/products/industrial-edge-connectivity/serial-device-servers/terminal-servers/nport-6100-6200-series
>
> Dann entfällt die USB Arie, die Waage hängt irgendwo im Netzt und kann
> von allen PCs abgefragt werden.

Moxa Server habe ich auch an einigen Stellen im Einsatz.
Aber hier muss es direkt sein, da ein bedienterminal mit Touch für den 
user dabei ist...

cppbert3 schrieb:
> Schlaumaier schrieb:
>> Kauf dir eine neue Waage (mit USB) wo der Hersteller eine API mitsamt
>> SDK mitliefert.
>
> Er hat was von 20 Tonnen geschrieben, ich glaube das ist was grösseres

Jep is gross das Ding

Stefan M. schrieb:
> Jep, das Prog. is nicht dolle und alt is es auch dazu.
> War troztdem teuer ~10K habe hier noch die Rechnung aus dem Jahr 2005.
> Hatte versucht darüber den Programmierer ausfindig zu machen, aber die
> Fa. gibt es nicht mehr, warum wohl^^

Wurde denn damals weder der Quelltext mitgeliefert noch ein 
Wartungsvertrag abgeschlossen? Das ist nicht so geschickt...

michael_ schrieb:
> Nicht alles, was unter XP geht, läuft auch unter W7/10.
> Wenn du einen Treiber findest, dann versuch den Adapter mal unter XP zum
> laufen zu bringen.
>
> Stefan M. schrieb:
>> Leider haben wir in Grosskonzernstrukturen nur einen Warenkorb aus dem
>> wir Hardware auswählen können und dort steht nur ein PC drin... ein DELL
>> OptiPlex. Da is nix mit wünsch Dir was
>
> Glaub ich nicht so recht.
> Frag in der IT-Abteilung nach. Die haben sicher einen passenden in der
> Ecke stehen.
>
> DELL-Optiplex gibt es auch mit COM.
>
> 
https://www.ebay.de/itm/234351028203?hash=item369068e7eb:g:jZIAAOSwDbxigiiH&amdata=enc%3AAQAHAAAA4LEljaxpvqkqzvF4RmADHhcRsfOStDFOAAld2JxstYXLkPAIWY36wimUfQ4Y855Omsnwduw8G%2BiX07AdKK7SEXFMfrB2v2uTTiDq1Ras53zfummOs%2BkcqaXih%2FfZBJMhRcqdzWXBgpf42XhDVoU3NLK4EpVmR0%2B6Xpotw%2Fw%2FVenOGHowwmJIK15H%2BUcvwDn8j80Yb%2BNdxjJUqhQFDdQOdguFCXj4bQt9c7C2v2blliWZTbHmBbjFAz3A1dAKVbngrHbTsBgYUcYV8NC0Z6xrdTaycVTzULF0%2FCc%2BGA5D9G0P%7Ctkp%3ABFBM5Iex96Ng

Witzig, ich bin von der IT Abteilung.
Und nein wir haben nur die 3000er Optiplex nur ein Model eine 
Ausstattung.
Aber dafür 1000 Stück davon

DerEinzigeBernd schrieb:
> Mucky F. schrieb:
>> Hab die Teile seit mehr als 15 Jahren im Dauereinsatz
>> (Industrie). Das ist Top of the Art, gab nie Probleme.
>
> Mit USB-Seriell-Bridges gibt es auch im Dauereinsatz (Industrie) keine
> Probleme. Wenn denn die Software etwas taugt, die mit der (virtuellen)
> seriellen Schnittstelle kommuniziert.
>
> Aber genau das ist ja das Problem; die hier genutzte Software ist so
> beschissen, daß sie hochempfindlich darauf reagiert, wenn das
> (willkürliche) Timing beim Empfang nicht eingehalten wird.
>
> Da hilft kein noch so guter Deviceserver, keine noch so gute
> USB-Seriell-Bridge und letztlich auch keine PCIe- oder PCI-Karte; sobald
> deren Treiber sich im Zeitverhalten auch nur einen Hauch unterscheiden
> vom Standard 16550-Treiber der onboard-Schnittstellen, ist's aus.

Genau da liegen auch meine bedenken bei der PCIe Variante.
Hoffe PCIe ist einfach schneller als USB.

Und zum siebenhundertdreiundfünfzigsten Mal:
Ja die Software ist beschissen

Mucky F. schrieb:
> DerEinzigeBernd schrieb:
>> Mit USB-Seriell-Bridges gibt es auch im Dauereinsatz (Industrie) keine
>> Probleme. Wenn denn die Software etwas taugt, die mit der (virtuellen)
>> seriellen Schnittstelle kommuniziert.
>
> Da habe ich deutlich andere Erfahrungen, aber darum geht es hier nicht.
> Der TO kann das ja testen, alles andere ist spekulativ.
>
> Es kann auch sein das der neue PC über die serielle-> USB Strecke
> Störungen einfängt (Ausgleichsströme, Einstrahlungen etc.). Standard
> serielle sind dagegen ziemlich immun (V24 Pegel und relativ
> niederohmig). USB Teile machen meist nur +-5V und sind recht hochohmig.
>
> USB ist in der Regel auch nicht galvanisch getrennt, COM Server meist
> ja.
> Wenn das z.B ne LKW Industriewaage ist würde ich auf galvanische
> Trennung eh anraten.

Das Thema Störungen kenne ich. Unser Labor ist direkt neben dem 
Umspannwerk.
Dort musste ich überall galvanisch trennen um die Messgeräte auslesen zu 
können, übrigens mit einem Moxa^^

Niklas G. schrieb:
> Stefan M. schrieb:
>> Jep, das Prog. is nicht dolle und alt is es auch dazu.
>> War troztdem teuer ~10K habe hier noch die Rechnung aus dem Jahr 2005.
>> Hatte versucht darüber den Programmierer ausfindig zu machen, aber die
>> Fa. gibt es nicht mehr, warum wohl^^
>
> Wurde denn damals weder der Quelltext mitgeliefert noch ein
> Wartungsvertrag abgeschlossen? Das ist nicht so geschickt...

Sagte ich schon Grosskonzern?

Da werden Projekte von Leuten durchgezogen, die im nächsten Jahr schon 
nicht mehr da sind, oder in einem anderen Bereich tätig sind und nix 
mehr wissen/wollen.
Da schert sich keiner um so was.
Der Standort der das Ursprünglich mal angeschafft hat existiert noch 
nicht mal mehr

Mucky F. schrieb:
> DerEinzigeBernd schrieb:
>> nd Du glaubst, daß der Devicetreiber davon, der den virtuellen COM-Port
>> zur Verfügung stellt, der nötig ist, damit die grindige Dreckssoftware
>> Daten empfangen kann, sich irgendwie sinnvoller und besser verhält als
>> der Devicetreiber der verwendeten USB-Seriell-Bridges?
>
> Was heißt glauben? Hab die Teile seit mehr als 15 Jahren im Dauereinsatz
> (Industrie). Das ist Top of the Art, gab nie Probleme. Moxa - und
> natürlich auch andere Com Server Hersteller - wissen was Sie machen. Die
> Software heißt nicht umsonst RealPort und läuft von XP bis Win 10 ohne
> Probleme.
>
>
> Kann immer sein das es trotzdem nicht funzt. Reichelt hat ein paar von
> den Dingern, kaufen und wenn es nicht geht das Rückgaberecht nutzen.
>
> Der hier reicht, Software ist überall die gleiche.
> 
https://www.reichelt.de/geraeteserver-1x-rj45-1x-rs-232-db9-moxa-nport-5110a-p273882.html?&trstct=pol_2&nbc=1

Wäre noch eine alternative, habe die Dinger auch von Moxa und W&T im 
Einsatz.
Das einzige was da stirbt sind die Netzteile^^

Aber hier halt nur blöd weil ich's direkt anschließen könnte.
Zudem ist nur ein LAN Port vor Ort, also noch nen Switch dazwischen.
Wieder eine Fehlerquelle mehr.

Ach zurückschicken... geht bei uns nicht.
Gibt das SAP nicht her^^
Bekommen die Inder nicht programmiert

Stefan M. schrieb:
>> Wurde denn damals weder der Quelltext mitgeliefert noch ein
>> Wartungsvertrag abgeschlossen? Das ist nicht so geschickt...
>
> Sagte ich schon Grosskonzern?

Naja, ich habe auch im Konzern gearbeitet und da wurde bei extern 
vergebenen Auftragsarbeiten auch der Quelltext mit ausgeliefert. Sicher 
dass der Quelltext nicht irgendwo rumfliegt?

cppbert3 schrieb:
>> ich bin nicht so der Programmierer, fuxe mich gerade erst in Arduino
>> also C++ und MicoPyton ein wenig ein.
>
> Ist das ein ofizielles Projekt oder nur eine Spielerei?
>
> Wenn es nicht zu Umfrangreich ist könnte ich eine Anbindung als
> Auftragsarbeit machen, oder du lieferst mehr Informationen zu der
> Software, Features usw. Welche Funktionen ihr benötigt und dann
> diskutieren wir weiter über mögliche Lösungen

Hi,

ist ein echtes Projekt.
XP muss raus, somit die alte Hardware mit Real RS232.
Auftragsarbeit wird leider nix, da Du nicht bei uns als Lieferant 
gelistet bist :-(
Denn ich vermute Du möchtest da gern etwas für haben.

Niklas G. schrieb:
> Stefan M. schrieb:
>>> Wurde denn damals weder der Quelltext mitgeliefert noch ein
>>> Wartungsvertrag abgeschlossen? Das ist nicht so geschickt...
>>
>> Sagte ich schon Grosskonzern?
>
> Naja, ich habe auch im Konzern gearbeitet und da wurde bei extern
> vergebenen Auftragsarbeiten auch der Quelltext mit ausgeliefert. Sicher
> dass der Quelltext nicht irgendwo rumfliegt?

ich habe alles abgegrast, alles was ich noch gefunden habe ist eine 
Kopie der Installation und der Auftrag/Rechnung selbst.
Habe sogar den ehemaligen Chef der beauftragen Fa. ausfindig gemacht.
Die Fa. existiert ja mittlerweile nicht mehr wie schon geschrieben
Der wollte aber nix rausrücken...meinte das muss neu geschrieben werden, 
da der Zugriff auf RS232 unter XP anders läuft als unter W10.

Wie wir ja sehen liegt es aber einfach nur am Timing, bzw. an der 
Zerstückelung in Pakete.

Wenn das mit der PCIe nicht klappt werde ich es mit einem W&T COM Server 
testen.
Wenn das nicht klappt brauche ich eine Art Proxy der die Daten von der 
Waage annimmt und sie dann über sowas wie com0com an die Software weiter 
gibt.

Denn mit com0com ist jeder Schuss ein Treffer.
Habe es mal ne Nacht laufen lassen und über 7500 Datensätze erfolgreich 
damit reingeschoben.

Stefan M. schrieb:
> Der wollte aber nix rausrücken...meinte das muss neu geschrieben werden,
> da der Zugriff auf RS232 unter XP anders läuft als unter W10.

Das glaube ich nicht, das ist selbst mit dem WinApi unverändert, und 
selbst wenn muss man ja nicht alles neu schreiben, nur die Paar Zeilen 
des Auslesens. Naja nicht sehr nett von ihm das geheim zu halte, seiner 
Logik nach bringt der Code ja eh nichts... Aber rechtlich wird man da 
wohl nichts machen können

Mucky F. schrieb:
> Stefan M. schrieb:
>> Zudem ist nur ein LAN Port vor Ort, also noch nen Switch dazwischen.
>> Wieder eine Fehlerquelle mehr.
>
> Naja wenn da nicht gerade Gigabit Ethernet läuft bekommt man 2 Ports
> über eine CAT5 Dose.

...ich fange jetzt nicht an die Ports aufzusplitten.

so, PCIe ist nun da verbaut.

und...

das Ding sendet in 4er Päckchen.
Also --> Funzt net

Oh nein... Kannst du mal mit einem Oszilloskop oder Logic Analyzer die 
Datenpakete von der Waage aufzeichnen und zeigen? Dann könnte man 
schauen wie lang die Lücken zwischen den Bytes sind. Eventuell sendet 
die Waage längere Lücken, sodass die diversen PC-Seriell-Ports 
zwischendurch an den PC senden. Eventuell könnte man tatsächlich etwas 
mit einer eigenen USB-Seriell-Firmware machen die ein längeres Timeout 
bei der Paketerkennung verwendet...

PS: Werden eigentlich die Flusskontrollleitungen verwendet? Vielleicht 
stimmt da was beim Timing nicht.

Hi,

die 4er Pakete habe ich nicht mit der Waage festgestellt, ich teste z.Z. 
mit einem alten PC mit echter RS232.
Die Pakete sende / empfachen ich mit einem Terminalprogramm CoolTerm und 
die Analyse mache ich mit Serial Port Monitor von eltima.

Hier mal eine Übersicht:
Was die Waage sendet
Was der USB to RS232 daraus macht
Was die PCIe daraus macht

Die Software erwartet zumindest einen durchgänigen Datenstrom alles 
andere führt zu Problemen

Stefan M. schrieb:
> die 4er Pakete habe ich nicht mit der Waage festgestellt, ich teste z.Z.
> mit einem alten PC mit echter RS232

Das hilft leider gar nicht, weil das Timing beliebig anders sein kann. 
Der alte PC macht eventuell auch Lücken.

Stefan M. schrieb:
> Die Software erwartet zumindest einen durchgänigen Datenstrom

Offenbar erwartet sie dass bestimmte Bytefolgen als Paket ankommen und 
mit einem read()-Aufruf ausgelesen werden. Wäre ein Datenstrom, d.h. 
beliebig angeordnete Folge von Bytes möglich, hättest du das Problem 
nicht. Es sei denn die Software erwartet tatsächlich 
millisekundengenaues Ankommen bestimmter Bytes, aber das kann ich mir 
kaum vorstellen - erstere Möglichkeit ist deutlich wahrscheinlicher weil 
sie durch schlampige Programmierung schnell zustande kommt.

Niklas G. schrieb:
> Stefan M. schrieb:
>> die 4er Pakete habe ich nicht mit der Waage festgestellt, ich teste z.Z.
>> mit einem alten PC mit echter RS232
>
> Das hilft leider gar nicht, weil das Timing beliebig anders sein kann.
> Der alte PC macht eventuell auch Lücken.
>
> Stefan M. schrieb:
>> Die Software erwartet zumindest einen durchgänigen Datenstrom
>
> Offenbar erwartet sie dass bestimmte Bytefolgen als Paket ankommen und
> mit einem read()-Aufruf ausgelesen werden. Wäre ein Datenstrom, d.h.
> beliebig angeordnete Folge von Bytes möglich, hättest du das Problem
> nicht. Es sei denn die Software erwartet tatsächlich
> millisekundengenaues Ankommen bestimmter Bytes, aber das kann ich mir
> kaum vorstellen - erstere Möglichkeit ist deutlich wahrscheinlicher weil
> sie durch schlampige Programmierung schnell zustande kommt.

Ich bin mir mitterweile auch sehr sicher, dass es ersteres ist.
Habe mit den Einstellungen der PCIe ein wenig "rumgespielt" und FiFo 
aktiviert.
Im Gegensatz zu den USB Dingern kann man hiermit wirklich die 
Datenstromlänge exakt beeinflussen.
Wenn das Stabil klappt, wäre das meine Lösung!!!

Da die Waage nur alle Ewigkeiten mal sendet wäre mit die Zeitverzögerung 
die ja hierdurch entsteht egal

DerEinzigeBernd schrieb:
> In "was die Waage sendet" kann man klar erkennen, daß sie mit CR
> abgeschlossene Telegramme sendet.
>
> Die tolle "Analyse" von Eltima zeigt das nicht an. Das Ding ist also
> eher untauglich.
>
> Mit diesem Wissen sollte es jetzt möglich sein, das Problem mit reiner
> Software zu lösen:
>
> Ein von jemandem, der es kann, zu schreibendes Programm empfängt via
> USB-Seriell-Adapter den Datenstrom der Waage.
>
> Dieses Programm kommuniziert via com0com mit der Dreckssoftware.
>
> Es empfängt einzelne Bytes und kombiniert die zu einem Telegramm, das in
> einem Rutsch via com0com gesendet wird, sobald ein CR empfangen wurde.

die Schnipsel, von Eltima zeigen nicht die Daten der Waage...
Sondern irgendetwas was ich aus die Schnittstelle gesendet habe.

Der Dreckssoftware ist es völlig Hupe womit der Datensatz endet oder 
auch anfängt. Habe ich alles schon probiert. Die nimmt lediglich 
zusammenhängende Zahlen aus dem Datensatz.
Und dieser Datensatz muss zwingend in einem Rutsch ankommen und nicht in 
einzelnen Päckchen.

Wie schon geschrieben scheint bei der PCIe die FiFo Buffer zu greifen.
Somit werden immer Päckchen in Grösse des Buffers in die Software 
gepumpt.
Was das Problem löst wenn der Treiber das stabil umsetzt.

Mal eine blöde OT-Frage:

Stefan M. schrieb:
> Es dürfen nur PCs mit Konzern-OS in Netz.
> Und da über SCCM installiert wird geht nur freigegebene Hardware.

Wie bekommst du da com0com installiert?

Oliver

Oliver S. schrieb:
> Mal eine blöde OT-Frage:
>
> Stefan M. schrieb:
>> Es dürfen nur PCs mit Konzern-OS in Netz.
>> Und da über SCCM installiert wird geht nur freigegebene Hardware.
>
> Wie bekommst du da com0com installiert?
>
> Oliver

Naja... wir als offizielle System-Administratoren haben "noch" 
Adminrechte^^
Auch wenn man und die nach nun nach beschneidet

Falls du ein STM32F103RB-Board mit USB herumfliegen hast (z.B. ein 
STM32-Bluepill-Board oder STM32-Olimexino), flashe mal diese Software 
drauf. Dies ist eine modifizierte USB-Seriell-Wandler-Firmware 
(USB-CDC-ACM), welche 3 COM-Ports zur Verfügung stellt.

Die Pin-Belegung ist (in den Klammern stehen die Zuordnungen für das 
Olimexino-STM32):
 * Port 0: TX=PA9(D7), RX=PA10(D8), DTR=PA1(D3), RTS=PA5(D13)
 * Port 1: TX=PA2(D1), RX=PA3(D0), DTR=PA6(D12), RTS=PA7(D11)
 * Port 2: TX=PB10(D29), RX=PB11(D30), DTR=PC0(D15), RTS=PC1(D16)

An diese 3 Seriell-Ports kannst du 3 Waagen anschließen. Die Software 
sendet immer ganze USB-Pakete, wenn die Waage ein 0x0D sendet. Der 
Windows-Treiber sendet diese hoffentlich am Stück an die Anwendung. 
Damit könnte es dann funktionieren, ist natürlich ein ziemlicher Hack. 
Die erreichbare Datenrate dürfte relativ gering sein, aber das spielt 
hier wohl keine Rolle. Funktioniert nur solange die Pakete unter 2KiB 
groß sind.

DerEinzigeBernd schrieb:
> Stefan M. schrieb:
>> die Schnipsel, von Eltima zeigen nicht die Daten der Waage...
>> Sondern irgendetwas was ich aus die Schnittstelle gesendet habe.
>
> Ach wie toll. Das ist ja super, damit hast Du ja denen, die den Fehler
> begangen, Dir helfen zu wollen, echt total bei der Fehlersuche geholfen.

naja, es sollte einfach nur verseutlichen, dass die Pakete zerstückelt 
werden. Denn darum geht es ja hier.
Das die Waage sauber sendet und das Problem an der Software liegt ist ja 
nun schon vielfach beschrieben worden.

Was ähnliches wie Du auf der ARM Basis gebaut hast, hatte ich hier auch 
schon  mit dem ESP32 zusammen gebastelt. Halte ich alles mal inder 
Hinterhand.

Seit nun 2 Std. laufen die Daten über die PCIe mit dem AX99100 Chip und 
dem aktivierten FiFo Buffer stabil :-)

Danke an alle bisher die sich beteiligt haben!

Wollte nur vermelden, Maschine läuft stabil :-)

Stefan M. schrieb:
> Wollte nur vermelden, Maschine läuft stabil :-)

UNd? was hast du letztendlich dafür getan?

Oliver