Ich greife mal ein Thema auf, welches bereits im August 2024 über einen Blog-Leser an mich herangetragen wurde. Es geht um die Verwendung der seriellen RS232-Verbindung unter Windows zu bestimmten Geräten (dort Omron SPS). Nach Windows-Updates (April und Mai 2024) gibt es das Problem, dass Software die zur Kommunikation verwendetet wird (eine *.ocx-Datei), nicht mehr nutzen können. Von Omron gibt es wohl eine Lösung – aber es ist gut möglich, dass das Problem auch andere Software trifft. Daher stelle ich die Information mal im Blog ein.
Anzeige
RS232-Verbindung streikt nach Update
Blog-Leser Axel ist im Umfeld von Labortechnik für die IT zuständig. Nach einem Windows-Update (im Mai 2024) lief man dort in das Problem, dass die serielle RS232-Verbindung zu den vorhandenen Omron SPS nicht mehr funktionierte. Der Hersteller Omron liefert kompakte Steuerungen (SPS) für die Industrie.
Eine ziemlich lange Recherche des Blog-Lesers ergab quasi als Zufallsfund, dass (so seine Vermutung) eine ActiveX-Komponente – der Leser schrieb von mscomctl.ocx, es müsste aber mscomm32.ocx sein, siehe auch nachfolgender Kommentar – nach Installation des Windows-Update nicht mehr verwendet werden konnte. Bei der Komponente handelt es sich um eine ActiveX-Komponente aus Zeiten von Microsoft Visual Basic 6.0, die noch von Altsoftware zur Kommunikation über die serielle RS232-Schnittstelle verwendet werden.
Omron liefert Details
Omron hat ein Supportdokument Connection issue to CS/CJ series PLCs after applying Windows update and version upgrade program veröffentlicht, welches mir vom Leser als PDF-Dokument zuging. In diesem Supportdokument wird bestätigt, dass nach der Installation einiger Windows-Updates vom 9. April, sowie 9. oder 14. Mai 2024 einige der Omron CX-One-Anwendungen, die CX-Server verwenden (z. B. CX-Programmer) nicht mehr in der Lage sind, die Toolbus-Verbindung zu einer SPS der CS/CJ-Serie herzustellen, wenn die Option Baudrate Auto-Detect aktiviert ist.
Fehlerdialog Quelle: Omron
Anzeige
Die Toolbus-Verbindung zu einer SPS der CS/CJ-Serie, die einen Peripherieanschluss oder einen RS-232C-Port verwendet, sei dann bei aktivierter Option Baudrate Auto-Detect nicht verfügbar, heißt es. In den Programmen wird ein Fehlerdialog angezeigt, sobald die Verbindung fehlgeschlagen ist. Betroffen sind folgende Windows-Systeme und Updates:
- Windows 10: KB5036892 (9. April 2024) und KB5037768 (14. Mai 2024)
- Windows 11: KB5036893 (9. April 2024) und KB5037771 (14. Mai 2024)
Omron gibt im Supportdokument weiterhin an, welche Software-Versionen seiner CX-Server betroffen sind und bietet auch eine Lösung für dieses Kommunikationsproblem an. Vielleicht hilft es dem einen oder anderen Betroffenen, falls die Lösung noch nicht bekannt sein sollte.
Anzeige
Keine Probleme bisher auf den Systemen hier, die MSCOMCTL.OCX noch verwenden.
Allerdings gab es in der Vergangenheit da schon Probleme(DLL HELL) mit MSCOMCTL.OCX, COMDLG32.OCX und den anderen VB6 Controls speziell nach Installationen/Updates anderer Software.
Mal ehrlich… das letzte VB6 war mir im VS 1998 unter die Finger gekommen. Wer seit einem viertel Jahrhundert seine Software nicht mehr angepackt hat, braucht sich irgendwo auch nicht zu wundern, dass sein vergammeltes Zeug immer problematischer wird. Von daher sehe da weniger MS in der Pflicht sondern eher jene, die solche Software-Hersteller noch vertreiben oder im Support haben. Und gerade bei COM (der Schnittstelle, nicht dem Component Object Modell) gibt es elegante Möglichkeiten das via TCP/IP zu machen.
das ist nicht nur die Software. Da steckt oft eine Hardware dahinter die 5 bis 6 stellige Kosten verursacht beim Update.
Und VB6 kam erst 1998 auf den Markt. Support von MS bis 2008. Sind also nur 16 Jahre, keine 25
Genau wie der andere Kommentator schon geschrieben hat ist es eben hier nicht nur die alte Software, sondern auch die alten SPS von OMRON, die immer noch im Einsatz sind.
Bei Produktionsautomaten oder Sondermaschinen die man baut ist die Betriebszeit eben oft sehr lange.
Teilweise laufen solche Maschinen 30-50 Jahre und da muss man dann eben auch die Möglichkeit für Reparatur und Service haben.
Im produktiven Industrie-Umfeld muss daher leider oft auch alte/abgekündigte Software zum Einsatz kommen.
Das mit der MSCOMCTL ist ein leidiges Thema. Es funktionieren jeweils nur ganz bestimmt Builds, immer wieder wird ein anderes zusätzlich via den Killbits abgeschossen. Man muss dann oft aus teilweise zweifelhaften Quellen eine andere Build besorgen weil sie MS nicht mehr rausrückt. :(
Für mich hat das ungefähr das gleiche System wie bei den Update-GPO's. Immer ein wenig dran rumbasteln damit die Leute kein Bock mehr haben und ihre Routinen umprogrammieren. Das wäre grundsätzlich möglich mit API's, ist aber ziemlich komplex. Das OCX ist DAU-Sicher und zuverlässig. Auch sind die Software und die Geräte teilweise jahrzehnte alt.
So für die Nörgler, VBA ist übrigens immer noch im Support, in Office und auch in so mancher Software-Erweiterung der Industrie. Das ist faktisch VB6. ;)
Serial via TCP-IP bleibt aus Sicht von Windows immer noch ein COM-Port in der Ansteuerung. Den TCP-Part übernimmt dann einfach ein Treiber. Wenn er wirklich gut ist, macht er das so gut wie ein phyischer Anschluss. Es ist nunmal fakt, dass sehr viele Industrie-Geräte noch mit RS232 automatisiert werden. Auch neue. Waagen, Laborgergäte, hochspezifische Messysteme etc.
Dieser Artikel kommt mir sehr seltsam vor!
Die mscomctl.ocx ist eine Bibliothek für grafische Benutzeroberflächen. Das "com" im Namen stammt von "common controls", nicht von COM-Port (RS-232-Schnittstelle). Mit der Kommunikation über eine RS-232-Schnittstelle hat die mscomctl.ocx meines Wissen nicht das geringste zu tun, dafür ware z. B. mscomm32.ocx eine Bibliothek.
Du hast Recht, muss ich checken, ob in der Nomenklatur ein Fehler von mir rein gekommen ist.
Update: Ich habe den obigen Text korrigiert – Omron gibt keinen Hinweis, welche Komponente durch die Updates betroffen sind – die Info über die .ocx kam vom Leser und ich habe die nicht geprüft. Danke für deine Anmerkung.
Was Daniel sagt ist absolut richtig.
Da ist mir bei der Angabe tatsächlich das MSCOMCTL.OCX und das MSCOMM32.OCX durcheinander gekommen.
Bitte entschuldige das Versehen.