Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Ergebnis 1 bis 5 von 5

Thema: WinCC RS232 Kommunikation in C

  1. #1
    Registriert seit
    14.06.2011
    Beiträge
    16
    Danke
    4
    Erhielt 0 Danke für 0 Beiträge

    Standard


    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
    Zitieren Zitieren WinCC RS232 Kommunikation in C  

  2. #2
    Registriert seit
    29.03.2004
    Beiträge
    5.739
    Danke
    143
    Erhielt 1.686 Danke für 1.225 Beiträge

    Standard

    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.

  3. #3
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.222
    Danke
    533
    Erhielt 2.698 Danke für 1.950 Beiträge

    Standard

    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.
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  4. #4
    Registriert seit
    29.03.2004
    Beiträge
    5.739
    Danke
    143
    Erhielt 1.686 Danke für 1.225 Beiträge

    Standard

    Zitat Zitat von Ralle Beitrag anzeigen
    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.

  5. #5
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.222
    Danke
    533
    Erhielt 2.698 Danke für 1.950 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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.
    Geändert von Ralle (03.12.2013 um 22:36 Uhr)
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

Ähnliche Themen

  1. TIA RS232 Kommunikation mit S7-1200
    Von FvO im Forum Simatic
    Antworten: 9
    Letzter Beitrag: 10.11.2014, 10:55
  2. RS232 Kommunikation EM-PC
    Von Rauchegger im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 05.02.2013, 21:57
  3. S7 1200 RS232 Kommunikation
    Von michi204 im Forum Simatic
    Antworten: 0
    Letzter Beitrag: 29.08.2011, 14:36
  4. RS232 Kommunikation
    Von justbql im Forum CODESYS und IEC61131
    Antworten: 2
    Letzter Beitrag: 06.12.2010, 16:48
  5. RS232 Kommunikation
    Von CanCow im Forum Simatic
    Antworten: 0
    Letzter Beitrag: 14.10.2009, 16:14

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •