Hallo Zusammen, habe hier eine .net basierende APK. Habe keine genauen Infos dazu und auch der Programmierer ist nicht mehr erreichbar. Die APK nimmt Daten von einer Waage über RS232 an um diese zu verarbeiten. Ich versuche nun die APK auf einen neuen PC umzuziehen. Da wir keine PC mehr mit RS232 im "Warenkorb" haben, habe ich auf einen USB to Serial Konverter gesetzt. Nun habe ich das Problem, dass die APK beim Empfang der Daten von der Waage crashed. Daraufhin habe ich das Ganze mit com0com getestet, damit lief es. Zur Analyse habe ich mir die Daten der RS232 angeschaut, 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. Auswertung der RS232 im Anhang. COM9 --> com0com Schnittstelle. COM5 --> USB to RS232. 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? Ich habe bisher Prolific und FTDI basierte Adapter getestet. Prolific "zerstückelt" immer. FTDI "funktioniert" teilweise. Bin für jeden Tip dankbar, da z.Z. mit meinem Latein am Ende
Angehängte Dateien:
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.
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.
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.
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.
Stefan M. schrieb: > Wie müssten diese stehen, damit die Daten nicht zerstückelt werden? Na, größere Werte sorgen für größere Pakete. Und was ist eine "APK"? Ein TLA?
DerEinzigeBernd schrieb: > Und was ist eine "APK"? Der TO ist zu modern. Und auch sein Handy fixiert. ;) Eine APK ist eine APpliKation. Leute wie ich die schon was älter sind schreiben PRG. für Programm. Von der Definition her, ist eine APK eine Teilgruppe der Gesamtgruppe Programme. Weil Programme sind alles, deren Definition ist :"Nacheinander Ausführbare Befehle für einen Datenverarbeitungsrechner". APK = Eindeutschung der Definition für "Anwenderprogramme" Ich hoffe ich habe deine Frage gut beantwortet kischer
Schlaumaier schrieb: > Eine APK ist eine APpliKation. APK heißt "Android PacKage". Mich würde aber auch interessieren, was er damit meint. Meine Vermutung ist eine Verwechslung mit APP.
Deckenleuchte schrieb: > Meine Vermutung ist eine Verwechslung mit APP. Wäre möglich. Aber auch apI wäre eine Idee. Was so ein kleiner Buchstabe zu verwirrung führen kann ;)
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
Stefan M. schrieb: > Hi Frank, > habe schon vorhin ein Bestellung ausgelöst... allerdings die 89444. Oft ist eine Ser. auf der Hauptplatine noch vorhanden. In Form von einem Jumper-Block. Schon nachgesehen?
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.
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.
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.
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...
Stefan M. schrieb: > is nen Dell den ich zur Verfügung habe... da is nix drin... Bää , du armer Kerl. Meine ich ernst. Der Laden ist Luxus-Schrott pur.
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?
Ich würde das Programm neu schreiben, denn ganz offensichtlich ist es sehr fehlerhaft.
Stefan M. schrieb: > Beim Testen ist mir aufgefallen, dass die Waage vor den Werten immer ein > paar Leerzeichen setzt. Bist du sicher das es echte Leerzeichen (chr/ascii 32) sind. Da viele Zeichen VOR Ascii-32 nur als Leerzeichen dargestellt werden. Im URALTEN MS-Dos Zeichensatz waren da die süssen Gesichter drin. https://de.wikipedia.org/wiki/American_Standard_Code_for_Information_Interchange#Zusammensetzung Zitat: Die ersten 32 ASCII-Zeichencodes (von 00hex bis 1Fhex) sind für Steuerzeichen (control character) reserviert; siehe dort für die Erklärung der Abkürzungen in der rechts (oder oben) stehenden Tabelle. Ich empfehle dringend diese Zeichen zu "paar Leerzeichen" zu Analysieren. Es gibt 0 Grund warum die echte Leerzeichen senden sollte.
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
Stefan M. schrieb: > 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? 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.
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.
Angehängte Dateien:
-
FTDI.png
96 KB
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.
Das alte OS in einer VM laufen lassen, die COM durchreicht
VM schrieb: > Das alte OS in einer VM laufen lassen, die COM durchreicht Geht nicht... Hypervisor ist bei uns im Company Image deaktiviert...
Stefan M. schrieb: > habe hier eine .net basierende APK. Naja, zwischenzeitlich hat sich ja herausgestellt, dass du schlicht ein Programm meinst... > Ich versuche nun die APK auf einen neuen PC umzuziehen. Da wir keine PC > mehr mit RS232 im "Warenkorb" haben, habe ich auf einen USB to Serial > Konverter gesetzt. > > Nun habe ich das Problem, dass die APK beim Empfang der Daten von der > Waage crashed. > > Daraufhin habe ich das Ganze mit com0com getestet, damit lief es. 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.
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).
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.
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?
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
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
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?
Schlaumaier schrieb: > Besonders Stressig sind einige Adapter die den Prologic.Treiber nutzen. Ein typischer Schlaumaier-Post. Was soll das für ein Treiber sein - noch nie gehört.
c-hater schrieb: > Mit dieser Angabe könnte man nämlich überprüfen, ob die mittels > Modbus-RTU kommuniziert. Der Dump hier Beitrag "Re: Alte .net Apk mag keine USB to RS232 Adapter" eindeutig, daß das kein Modbus ist. Modbus-Geräte senden nicht unaufgefordert, Modbus-Geräte senden keinen ASCII-Text (insbesondere RTU nicht). Stefan M. schrieb: > Beim FTDI habe ich schon alles in Richtung min. Latenz gedreht damit > läuft es wie im letzten Bildchen zu sehen. Nicht verringern. Erhöhen.
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
:
Bearbeitet durch User
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?
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!!!
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 Man kann es auch preiswerter machen. I.d.R. kennen die TOP-Hersteller ihre Produkte und verkaufen als "Kundenservice" überteuerte Dongle o.ä. damit der Kunde seine lieb gewonnene Waage o.ä. behalten kann. Also einfach anrufen. Mit der Technik verbinden lassen und die wissen ob es so was gibt. Bei unser Post-Kontrollwaage die an die Frankiermaschine angeschlossen war damals, hat uns der Hersteller auch ein Adapterkabel und ein Eprom geliefert damit die alte Waage und die neue Frankiermaschine sich wieder lieb hatten. ;)
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.
Andreas M. 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. > > Für eine Auftragsentwicklung sind 10k nichts. Genau. Kauf dir eine neue Waage (mit USB) wo der Hersteller eine API mitsamt SDK mitliefert. GUTE Hersteller machen das. Bei mein Etikettendrucker von Brother z.b. gibt es ein SDK-Paket (nur download) was in hm 5 Sprache inkl. VB + C Beispiele für die Ansteuerung zeigt. Ich habe auch schon Waagen gesehen wo der Hersteller auf so SDK verwiesen hat.
Schlaumaier schrieb: > Kauf dir eine neue Waage (mit USB) wo der Hersteller eine API mitsamt > SDK mitliefert. Vielleicht sollte erst mal geklärt werden, was die Waage tatsächlich liefert. Das einzige Informationsschnipselchen ist der Mitschrieb hier Beitrag "Re: Alte .net Apk mag keine USB to RS232 Adapter" Der aber gibt offensichtlich nicht das wieder, was die Waage sendet, sondern nur das, was das kaputte Programm empfängt, vor allem fummelt es zwischen den Empfangsversuchen auch irgendwie an der Schnittstelle herum. Also: Waage an einfachst-Analysatorprogramm à la "hammer hterm" hängen und damit einen Mitschrieb anfertigen.
DerEinzigeBernd schrieb: > Also: Waage an einfachst-Analysatorprogramm à la "hammer hterm" hängen > und damit einen Mitschrieb anfertigen. Klor. Wenn man viel Zeit hat kann man das ganze dann "Hacken". Protokoll + Datenstrom analysieren. Zwischen-Progamm schreiben, was dann die Daten an die gewünschte Software weitergibt. Würde ich zu Hause auch alles machen. Aber bei einen Mindestlohn von k.a. 12 Euro + 50 % Arbeitgeberzulage = ca. 18-20 Euro /Std. kostet mich der Mitarbeiter als Chef 160 Euro ca. am Tag. 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". Resultat : Ich hab das kaputte Teil gemütlich zu Hause repariert und so eine sehr gute Ausstattung für fast Lau bekommen". ICH würde das Teil mit einer Wahrscheinlichkeit von 95% wieder sauber ans Laufen bekommen. Die Frage ist halt nur wie viele Wochenenden ist mir das wert. Und wie ehrgeizig + kämpferisch bin ich, es zu schaffen. Ich habe schon einige Tage an Geräten gefummelt die ich danach nie wieder wirklich angeschaut habe. ;) Aber SO handelt keine Firma. !!!
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.
Mucky F. schrieb: > Also ich würde es mit einem COM Server testen. Sorry falscher link. Die hier nutze ich selber: https://www.moxa.com/en/products/industrial-edge-connectivity/serial-device-servers/general-device-servers/nport-5200-series/nport-5210
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
Mucky F. schrieb: > Also ich würde es mit einem COM Server testen. Und 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? Halte ich für sehr optimistisch. Sehr.
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
> 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
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
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.
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.
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
:
Bearbeitet durch User
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: > Witzig, ich bin von der IT Abteilung. Stefan M. schrieb: > ich bin nicht so der Programmierer, fuxe mich gerade erst in Arduino > also C++ und MicoPyton ein wenig ein. Darum handeln manche IT-Abteilungen manchmal etwas seltsam... 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, Ich auch, PCIe Karten waren dann jedoch meist die Lösung. Niklas G. schrieb: > Sicher dass der Quelltext nicht irgendwo rumfliegt? @TO, ist die Person, die die Waage und Software angeschafft hat bekannt und noch erreichbar, evtl. Im Ruhestand?
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
:
Bearbeitet durch User
Stefan M. schrieb: > 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. für ganz umsonst wäre mir meine Zeit dann doch zu knapp :) keinen Weg über einen Lieferanten einen Sub-Auftrag zu starten? btw: wenn der Code so altbacken ist (und die Firma schon wieder Geschichte ist) kann ich mir nicht vorstellen das die Entwickler damals irgendwas zum Software-Schutz gemacht haben d.h. der .Net-Reflector könnte den Source-Code wieder vollständig herstellen bis hin zur sauberen Re-Kompilierbarkeit - ich hab damit vor Jahren eine nicht ganz kleine Software (deren Source-Code man verschlampt hatte) wieder neues Leben eingehaucht
cppbert3 schrieb: > btw: wenn der Code so altbacken ist (und die Firma schon wieder > Geschichte ist) kann ich mir nicht vorstellen das die Entwickler damals > irgendwas zum Software-Schutz gemacht haben > > d.h. der .Net-Reflector könnte den Source-Code wieder vollständig > herstellen bis hin zur sauberen Re-Kompilierbarkeit Ja, das geht. Relativ kleine Verluste gibt es nur bezüglich der Menschenlesbarkeit, für den Compiler reicht es auf jeden Fall. Blöd nur, wenn sich z.B. rausstellt, dass der UART-Code nicht aus dem SerialPort des .net-Frameworks besteht, sondern aus einem importierten mscomm32.ocx. Das findet man recht häufig in nach VB.Net "hochkonvertierten" VB6-Programmen. Ist aber auch ohne Programmänderungen lösbar. Allerdings ist trotzdem der logistische Aufwand nicht zu unterschätzen, bis dann das Ergebnis irgendwann endlich auf dem Zielrechner läuft. Inbesondere, wenn man erst lernen muss, was man da alles tun muss. Neu schreiben könnte u.U. billiger werden.
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.
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.
:
Bearbeitet durch User
Angehängte Dateien:
-
usb_rs232.jpg
250 KB -
AX99100_PCIe_rs232.png
37 KB -
was_die_Waage_sendet.jpg
83 KB
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
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
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.
Stefan M. schrieb: > 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. Ach ja, und wie man das machen kann, hatte ich Dir auch gerade beschrieben.
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!
Stefan M. schrieb: > Wollte nur vermelden, Maschine läuft stabil :-) UNd? was hast du letztendlich dafür getan? Oliver
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.