MFC ANwendung reagiert nicht mehr... ( Win XP SP3 )

[Crizz]

Plage mich seit einiger Zeit mit einem Refeine-Plotter herum, der während der Schnittausgabe plötzlich stehenbleibt. Das Gerät wird über RS232 angeklemmt und ist über einen USB-RS232-Konverter mit dem PC verbunden.

Manche Plots klappen, bei anderen bleibt er sporadisch stehen, die Fortschrittanzeige friert ein und irgendwann kommt die Meldung, das die MFC-Anwendung nicht mehr reagiert.

Es wurden schon unterschiedliche RS232-Konverter probiert, unterschiedliche PCs verwendet, aber das Problem ist nicht zu beheben. Die Flusssteuerung wurde nach Herstellerangaben auf "Hardware" gesetzt. Jemand ne Ahnung, wo es klemmen könnte ? Sicherheitssoftware wie Kaspersky oder Norton ist keine installiert. Bei der Software handelt es sich um Artcut2006 in der Version 2009

[ER Corvulus]

Hat Dir sicher MS ein paar Patches drübergebügelt. Schau doch mal, ob die MFC (m.E. MS-Foundation-Classes) bei MS komplett als Runtime bekommst und drüberbügeln. Vorher möglichst ne systemsicherung/Wiederherstellungspunkt manuell setzten.
Oder die Anwendung deinstallieren, neu installieren.

Grüsse Wolfgang

[-andi-]

Sers!

Es ist eine liebe not mit USB zu RS232. Hatte da auch schon seltsame Probleme... Brauchst du das auf einem NB? Wenn nicht, versuche mal eine interne RS232 Karte. Die bekommt man ja für schmales Geld Meiner Erfahrung nach verursachen die weniger Probleme...

Ebenso kannst du mit den Parametern der RS232 spielen. Versuche mal testweise die Flusssteuerung auf Software zu setzten. Sachen wie Stopbit etc. musst du gleich lassen.

des weiteren wurde mit SP3 recht viel geändert - versuch mal SP2. Wir hatten mit SP3 auch einige Probleme, bzw. noch immer SW im einsatz, die für SP3 nicht freigegeben ist...

cu
andi

EDIT: Wenn alle Stricke reisen, kann ich dir testweise ältere HW zukommen lassen, die RS232 onboard hat

[speedy]

Schau doch mal, ob die MFC (m.E. MS-Foundation-Classes) bei MS komplett als Runtime bekommst und drüberbügeln.

Also das wird mit Sicherheit nicht so einfach hinhauen. Denn es gibt verschiedene Versionen der beötigten Dateien - jenachdem, mit welcher Visual Studio Version die Software entwickelt wurde. MS überschreibt die auch nicht so einfach, sondern es wird nachgefragt oder es wird einfach eine zweite Version daneben abgelegt. Jede unterschiedliche Version hat auch die Version im Namen mit drin, so daß wirklich nur gleiche Versionen überschrieben werden könnten - aber das würde ja nichts ausmachen.

Wenn MS da wirklich was drüber gebügelt hat, was ich nicht glaube, dann funktioniert es nur, daß man die Software neu installiert - denn normalerweise werden die benötigten/richtigen DLLs von jedem Programm mitgeliefert. Normalerweise sollten die richtigen DLLs auch nochmal direkt im installierten Verzeichnis liegen - bedeutet auch wiederum, daß da MS garnichts drüber bügeln kann. Denn vom Programm bzw. von Windows wird automatisch erstmal im gleichen Verzeichnis - wo das Programm liegt - nach den benötigten DLLs gesucht und danach erst im System-Verzeichnis, wo die gemeinsamen DLLs liegen.

Und - jene Meldung ist ja auch eher eine allgemeine Meldung. Und nicht, daß in der MFC irgendwas schief gelaufen ist. Das Programm wartet vermutlich auf irgendeine Reaktion von der Schnittstelle oder so, aber es ist kein wirkliches Timeout drinnen oder so.


MFG
speedy

[ER Corvulus]

Normalerweise sollten die richtigen DLLs auch nochmal direkt im installierten Verzeichnis liegen

Nö. Die normalen Installer pfeffern das MS-Zeugs (wenn Du Glück hast) in Gemeinsame*Irgendwas*, wenn Du pech hast ins system32. Bei richtigen "eigenen" DLLs können die im Programmpfad liegen, müssen/sollten aber nicht.

Wenn da mal Updates drüber sind, werden die vom Installer _nicht_ wieder weggeräumt - der räumt nur weg, was er selber installiert hat. Und da gibts noch diesen Internen Zähler, der Dlls (aus system32 oder gemeinsame) erst dann löscht, wenn sie von keiner Anwendung mehr benötigt werden.
Es gibt natürliche mehrere MFC-Versionen - die alle friedlich nebeinander existiren (über den namen), aber die einzelnen Dateienen können durchaus unterschiedliche "Revisionen" haben.
Gibt Tools, mit denen man sich die Liste der verwendeten DLLs angucken kann. Und dann am besten das selbe package komplett neu aufspielen. Die Anwendung neu installieren bringt meist nicht so viel (kost aber auch nix), weil über gepatchte DLLs nicht drüberinstalliert wird, deren Version/Revision(Build) ist ja höher.

Kann zwar sein, würde mich aber trotzdem wundern, wenn Sendefehler via irgendwas in den MS-Runtimes nicht sauber abgefangen werden. Habe mich mit dem Kram lange genug rumgeärgert.

Oft sind es "nur" Anwendungs-Software-Fehler, die dann irgendwelche RückgabeCodes/Fehler/Trigger/Events (je nach dem) nicht sauber auswerten.

Grüsse Wolfgang

[speedy]

Nö. Die normalen Installer pfeffern das MS-Zeugs (wenn Du Glück hast) in Gemeinsame*Irgendwas*, wenn Du pech hast ins system32. Bei richtigen "eigenen" DLLs können die im Programmpfad liegen, müssen/sollten aber nicht.

Ähm - was der Installer macht, das bestimmt der Entwickler, der den Installer konfiguriert hat. Und - eigene DLLs sollten auf jedenfall im Programmverzeichnis liegen - woanders haben die nichts zu suchen.

Gibt Tools, mit denen man sich die Liste der verwendeten DLLs angucken kann.

Yep, aber das ist nichts für Otto-Normal-User.

weil über gepatchte DLLs nicht drüberinstalliert wird, deren Version/Revision(Build) ist ja höher.

Hmm, ja - na zumindestens wird nachgefragt (zumindestens kommen bei mir ab und zu solch Fragen), ob drübergebügelt werden soll oder nicht - aber wird man ja dann oft nicht machen.

Aber wenn nur ein niedrigerer Build ordentlich funktionieren sollte, dann kann man den trotzdem noch ins Programmverzeichnis kopieren, wenn er da wirklich nicht sein sollte. Die Suchreihenfolge nach der DLL ist halt so, daß erst im Programmverzeichnis gesucht wird.


MFG
speedy

[ER Corvulus]

zumindestens wird nachgefragt (zumindestens kommen bei mir ab und zu solch Fragen)

Die "üblichen" Installer fragen m.W. nur nach, wenn eine höhere Version/Revision/Build (oder andere Sprachversion/gleicher Build) auf dem Zielverzeichnis existiert - niedrige werden überbügelt.

eigene DLLs sollten auf jedenfall im Programmverzeichnis liegen

die MFC ist aber nicht "eigen".

Aber das ist hier nun wirklich Erbsen und hilft Crizz sicher nicht so viel weiter.

@crizz: Hast mal beim Hersteller-Support gefragt?

[yacco]

Gibt Tools, mit denen man sich die Liste der verwendeten DLLs angucken kann.

Dafür ist der Dependency Walker ganz gut: http://dependencywalker.com/ (der muß nicht mal installiert werden).

Da sich der Fehler scheinbar nicht exakt reproduzieren läßt, würde ich ein Versions-Problem mit den MFC-Libraries aber auch ausschliessen. Kann man die Ausgabe evt. in eine Datei umleiten und die dann aus einem anderen Programm heraus an den Plotter schicken?

[Crizz]

Ich könnte es zwar in ne PLT-Datei umleiten, aber dann fehlen mir Steuerfunktionen wie Offsetkorrektur für das Schneidmesser und Überschneiden für geschlossene Objekte. Gibt für die Kiste zwar auch nen Treiber um aus Corel zu plotten, aber da ist das gleiche Problem, weil am Gerät diese Parameter ( Offset, Close ) nicht justiert werden können sondern von der SW kommen müssen. Von daher bringt mich das leider nicht wirklich weiter.

Ich werd am WE mal schaun, ob es mit nem Rechner mit SP2 läuft, normalerweise soll es von einem Nettop aus gesteuert werden, deshalb auch der RS232-USB-Konverter. Werde dann aber mal die Möglichkeit haben, direkt einen Hardware-COM-Port zu verwenden, mal schaun ob das was ändert. Alternativ werd ich die FIFO-Puffer mal abschalten, vielleicht haut auch da irgendwo was ins Leere.

[FPK]

Ich würde mal beim Hersteller nachfragen, welche USB-RS232-Konverter mit dem Gerät funktionieren, um diese doch recht wahrscheinliche Fehlerquelle auszuschliessen.

[Crizz]

Prolific läuft eigentlich am problemlosesten, werden am meisten eingesetzt. Mir ist eben aufgefallen, das auf dem System noch jeweils ein anderer USB-Ser.-Treiber installiert wurde - wahrscheinlich Altbestand von nem anderen Gerät / Adapter. Hab die eben erstmal allesamt komplett entfernt, Software runter, Treiber für den aktuellen Adapter installiert und dann nochmal die SW neu drauf. Heut abend wird dann getestet. Kann mir vorstellen das dort schon die Quelle zu suchen war.

[Crizz]

Update :

Problem gefixed ! Nachdem ich obige Schritte ausgeführt hatte laufen nunmehr beide Systeme sauber, Plots klappen hervorragend in jeder Dateigröße und Schnittgeschwindigkeit. Manchmal hilft schon die Korrespondenz mit anderen, neue Gedanken zu öffnen - dafür meinen Dank an euch !