WinCC RS232 Kommunikation in C

[IoT]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
ich möchte einen RFID Leser über RS232 aus WinCC auslesen. Über HyperTerminal kann ich bereits mit dem Gerät kommunizieren. Für das Nutzen der Windows-Boardmittel (OCX) in WinCC fehlt mir die Design-Lizenz auf der ES. Wer hat schonmal die COM Schnittstelle in WinCC über ein C-Skribt angesprochen? Wenn ich ein Beispiel hätte könnte ich dies für meine Bedürfnisse anpassen. Danke

Gruß Egon

 

[Thomas_v2.1]

Theoretisch solltest du in WinCC ein C-Programm zum Ansprechen der seriellen Schnittstelle direkt eingeben können. Zumindest einen Windows-Socket habe ich schon aus einem WinCC C-Skript verwendet, ich würde darum behaupten mit der seriellen Schnittstelle sollte das prinzipiell auch gehen, habe es aber selber noch nicht umgesetzt.
Beispiele zur seriellen Schnittstelle in C findet man im Internet zu Hauf.

Die Tücke dabei wird sein, dass du in WinCC die Schnittstelle so nur pollend abfragen kannst, da man irgendetwas Event-basiertes dort imho nicht umgesetzt bekommt.
Ich würde zumindest versuchen, das Handle zu der geöffneten Schnittstelle in einer globalen Variable zwischenzuspeichern, ansonsten musst du bei jedem Skriptaufruf auch noch die Schnittstelle auf- und wieder zumachen.
Dann hängt es noch vom Protokoll und den zu übertragenden Blockgrößen ab ob das so funktioniert.
Um das System nicht zu überlasten, würde ich das Skript welches die Schnittstelle pollt z.B. max. alle 0,5 Sekunden (eher sekündlich) aufrufen. In der Zwischenzeit landen die Daten im FIFO der UART, der aber normal nur 14 Bytes groß ist. D.h. wenn zwischen deinen Aufrufen mehr Daten eingetroffen sind, gehen die für deine Auswertung verloren.

Oder du versuchst die ganze Verwendung der seriellen Schnittstelle in Funktionen einer selbstgeschriebene dll auszulagern, und dann diese von WinCC aus aufzurufen.

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich würde auch die DLL vorziehen, wir haben das mal mit Labeldruckern gemacht, die ja auch Signale zurückgeben, ist einfach am Besten.
Allerdings mit Delphi geschrieben und in VBA aufgerufen, aber das ist ja jedem selbst überlassen.

 

[Thomas_v2.1]

Ich würde auch die DLL vorziehen, wir haben das mal mit Labeldruckern gemacht, die ja auch Signale zurückgeben, ist einfach am Besten.
Allerdings mit Delphi geschrieben und in VBA aufgerufen, aber das ist ja jedem selbst überlassen.

Wie hast du das denn da gemacht? Denn rein über auslagern der Funktionen in eine dll bekommt man das Polling-Problem nicht gelöst.

Um das zu beheben, müsste die dll einen eigenen Thread starten der im Hintergrund die serielle Schnittstelle behandelt und empfangene Daten in einen internen Puffer wegschreibt.
WinCC bekommt nach Erstaufruf der dll ein Handle zurück, und kann dann bei den nächsten Aufrufen die Daten aus dem internen Puffer holen.
Wenn es ein festgelegtes Protokoll gibt, könnte man auch schon einen Teil des Protokoll-Handlings in die dll auslagern. Im Falle eines RFID Lesers würde ich es dann so machen, dass über eine Funktion immer ein kompletter Datensatz des RFID zurückgegeben wird. Das müsste man nämlich sonst alles noch in WinCC aus den einzelnen Daten im Puffer zusammensetzen.

 

[Ralle]

Ich hab das nicht selbst gemacht, war nur für WINCC zuständig, die DLL hat ein Kollege geschrieben, wir haben da zusammen eine ganze Zeit rumgetüftelt. Ich habe aus der SPS heraus die zu druckenden Daten in WINCC-Variablen geschrieben, dann einer Startvariable z.Bsp. eine 1 übergeben. Die DLL hat dann den Druckauftrag rausgegeben (TCPIP) und auf das "Fertig" von Drucker gewartet (Dabei war noch das Abzupfen des Labels, als gesonderte Meldung).
Da man die DLL im Script nicht im Wartemodus stehen lassen konnte --> Script in WinCC stoppt und WINCC zeigt nicht mal mehr Fehler an, wurde das Script beendet und ich habe im SPS-Programm immer wieder das Druckergebnis angefragt. Das hat jedes mal die DLL zu einer Antwort gebracht, also Busy, Fehler, Fertig usw.

PS: Die DLL war als ActiveX-Control angelegt.