TIA Software UART am Digitalout einer S7-1200 ?

Gleichstromer · 24 Oktober 2016

PN/DP schrieb:
Vielleicht kann man die PWM-Ausgabe auf eine Ausgabefrequenz von knapp 100kHz (10.4µs) programmieren und die Ausgabefrequenz mitzählen oder den PWM-Ausgang auf einen schnellen Zähleingang verbinden und den Zählerstand mit Peripheriezugriffen auslesen

Auf diese Weise - PWM-Rückführung auf Eingang - habe ich den Empfang von RC5/6-Daten (IR-Fernbedienung) mit einer alten 224 umgesetzt, ohne PWM war kein stabiler Empfang möglich bzw. hab ich zumindest nicht hingekriegt.
Die Frequenz ist zwar nur knapp 1kHz, aber wg. der Manchester-Codierung müssen die Daten mittig der zweiten Bit-Hälfte gelesen werden. Mit der Pulsdauer konnte der Abtast-Zeitpunkt sehr genau eingestellt werden, zudem hat Siemens bei der 200er die Ausführungszeiten der Befehle noch angegeben, die insgesamt 70µs für INT0, MOVB, PLS stimmten.

Wenn das Auslesen eines schnellen Zählers in einer Interrupt-Routine möglich ist, sollte die Bitfolgenausgabe prinzipiell machbar sein.
Was bei der 1200er aber noch alles dazwischenfunkt, zumal in V4.X ? In dieser Hinsicht war die Schlichtheit der 200er mal von Vorteil.

Gutes Gelingen !

Hesse · 24 Oktober 2016

PN/DP schrieb:
Hesse will ja auch noch die Adapterbox A232 einsparen.

Ja, weil ich drei Stück bräuchte und noch die RS232 Umschaltung

PN/DP schrieb:
Und falls die Lösung für mehrere Anlagen ist,.........

Ja für mehrere ist angedacht, aber da könnte bzw. werde ich dann gleich Profinet Sensoren einsetzen.
(außer wir finden hier vielleicht doch noch eine Lösung)

PN/DP schrieb:
Desweiteren schadet es sicher nicht für den eigenen Skill, mal etwas tiefer in die SPS-Programmierung reinzuschauen, Lösungen und Grenzen zu finden und auch mal die Dokumentationsaussagen von Siemens unter die Lupe zu nehmen.

Es muss sich nicht immer alles „rechnen“.Es ist auch mall gut einfach was zu machen.
Ich würde mir sehr wünschen, wenn ich bei unsere heutigen Azubis mal nur etwas mehr Ehrgeiz finden würde. Die sie sich wirklich mal dafür interessieren würde, warum was, wie funktioniert.
Aber das ist ein anders Thema und nicht hier auszudiskutieren.

PN/DP schrieb:
Also ich finde das Projekt schon interessant, man kann dabei viel lernen.

Ich auch, dann nennt es halt Hobby mir auch recht.

Auch wenn ich mich schon mehrfach wiederhole:
Bei mir ging es nur darum, das Problem von zuhause aus über die Fernwartung zu lösen!

Ich bekomm keine Hardware durch das Internet.

Hesse · 28 Oktober 2016

Allen ein schönes Wochenende.
Ich habe mal meine Messmöglichkeiten etwas verbessert.

Das ist von der SPS ein „U“ bzw. 85 bei 19200 Baud

Ich bekomme aber auch noch sowas (auch eigentlich eine 85)

Dann war da ja noch die Frage: ob man unbedingt die schnellen Ausgänge Q0.0 bis Q0.3 der SPS verwenden muss.

Die Antwort :
Alle Ausgänge der CPU funktionieren, sie haben keinen Einfluss auf das Timing bei 19200.
Sobald aber ein Ausgang der Erweiterungsmodule ins Spiel kommt ist das Timing absolut dahin,

das war aber auch zu erwarten das der

auf eine Erweiterungsmodul länger dauert.

Jetzt geht es daran einen der Impulsgeneratoren als Baud Generator zu missbrauchen.

Hier zum Vergleich ein „U“ bzw. 85 vom PC gesendet
> Auffällig 1 und 0 sind nicht gleich lang

Dann war da ja noch die Frage: ob man unbedingt die schnellen Ausgänge Q0.0 bis Q0.3 der SPS verwenden muss.
Die Antwort :
Alle Ausgänge der CPU funktionieren, sie haben keinen Einfluss auf das Timing bei 19200.
Sobald ein Ausgang eines Erweiterungsmodule ins Spiel kommt ist das Timing absolut dahin,
das war aber auch zu erwarten das der

auf eine Erweiterungsmodul länger dauert.

Jetzt geht es daran einen der Impulsgeneratoren als Baud Generator zu missbrauchen.

Thomas_v2.1 · 28 Oktober 2016

Was hast du am PC denn für eine serielle Schnittstelle, onboard oder USB?
Wenn onboard, dann kommt meistens ein 16550 zum Einsatz, da ist dieses Zeitverhalten zwischen Hi und Lo im Datenblatt so festgelegt (75/100 Hi/Lo).

Hesse · 31 Oktober 2016

PN/DP schrieb:
Wenn Du die Ausgangsfrequenz auf eine Periodendauer von 208µs programmierst, dann brauchst Du nicht den Zählerstand selber sondern nur den Zeitpunkt, wenn sich der Zählerstand ändert - Bit .0 auswerten reicht. Vielleicht kannst Du auch direkt den Peripherieeingang abfragen?
Harald

Genau so habe ich es schon gemacht. Damit habe ich pro 100 Byte nur noch 3 - 8 Fehler . Aber halt noch nicht 100% Fehlerfrei . Bekomm den Zähler jetzt auch auf Null.
Bin weiter dran .... Ich habe noch Hoffnung ,nur nicht soviel Hobbyzeit

gesendet vom Lumia 930

Hesse · 1 November 2016

Ich kann machen was ich will. Es wird nicht 100% fehlerfrei.
Da die CPU immer ca. alle 1ms einfach was anderes tut.

Siehe dieser mini Programm (das die PWM am 100khz Eingang einliest und wieder am Q0.3 ausgibt)
und das Ergebnis dazu ….

Code:

    (**********************************************************
    Weckalarm (z.B. OB30) alle 4sec
    ***********************************************************)
 
       #nAIRT := DIS_AIRT(); //höherpriore Alarm- und Fehler-OB verzögern
  //Zyklusüberwachung auf 3sec
        REPEAT
            "out":P  := "In_Takt":P;
        UNTIL 1 = 2
        END_REPEAT;
        
      #nAIRT := EN_AIRT(); //Alarm- und Fehler-OB wieder freigeben

Da einzige was noch klappen könnte wäre genau zwischen den „Unterbrechungen“ zu senden
Also:
1. Warten bis Unterbrechung
2. Senden Byte mit 19200
3. Vor der nächsten Unterbrechung fertig sein

Thomas_v2.1 · 1 November 2016

Probier doch mal den Zustand Ausgang maximal schnell zwischen 1 und 0 zu wechseln, also ohne irgendwelche weiteren Bedingungen. Dann kann man sehen wie lange das Betriebssystem zwischendurch unterbricht, und dann kann man auch abschätzen welche Baudrate dann noch maximal möglich ist.
Das dürfte immer noch schneller sein als meine Variante aus dem anderen Thread bei der in jedem OB Aufruf nur ein Bit übermittelt wird (dafür aber dann zuverlässig).

Interessant ist dieses Wissen beispielsweise fürLaufzeitmessungen von Programmteilen mittels Runtime, denn hier ist eine einmalige Messung demnach unbrauchbar. Da muss immer über mehrere Messungen gemittelt werden um ein verwendbares Ergebnis zu erhalten.

Hesse · 1 November 2016

Thomas_v2.1 schrieb:
Probier doch mal den Zustand Ausgang maximal schnell zwischen 1 und 0 zu wechseln, also ohne irgendwelche weiteren Bedingungen.

Ohne Bedingung geht nicht. da erkennt das schlaue TIA den „Todescode“
Bild:

Code:

    (**********************************************************
    Weckalarm (z.B. OB30) alle 4sec
    ***********************************************************)
 
       #nAIRT := DIS_AIRT(); //höherpriore Alarm- und Fehler-OB verzögern
        
    
        //Zyklusüberwachung auf 3sec    
    
        REPEAT
            "out":P  := 1;
            "out":P  := 0;
        UNTIL 1 = 2 END_REPEAT;
        
 
      #nAIRT := EN_AIRT(); //Alarm- und Fehler-OB wieder freigeben

Ich werde jetzt den Byte Versand auf diese Unterbrechung Synchronisieren …..

PN/DP · 1 November 2016

Hallo Hesse,

vielen Dank für Deine Tests und die Bilder und Deine Ausdauer. Die Erkenntnisse sind sehr interessant.

Ich würde noch untersuchen:
- DIS_AIRT() + EN_AIRT() mal weglassen, es ist ja eingestellt, daß der OB nicht von anderen OB unterbrochen werden kann
- Unterbricht das BS direkt den OB oder verzögert es nur die Rückkehr in den OB beim Peripherie-Lesen oder beim Peripherie-Schreiben? Auf das Peripherie-Schreiben kann man ja nicht verzichten, doch das Peripherie-Lesen oder RUNTIME()-Lesen kann man testweise durch eine feste "Friss-Zeit"-Schleife oder -Anweisungsfolge ersetzen.

Wie man an den ca. 5µs-kurzen Pulsen in den Bildern sehen kann, wäre die S7-1200 grundsätzlich schnell genug für den Soft-UART, sogar schnell genug für 19200. Auch der Versatz und Jitter zwischen PWM-Ausgang und Peripherieeingang lesen ist schön klein. Doch wie kann man diese Einmischung durch das BS abstellen? Da fällt mir leider nichts weiter ein.

Hesse schrieb:
Ich werde jetzt den Byte Versand auf diese Unterbrechung Synchronisieren …..

Da bin ich jetzt gespannt, wie Du die Unterbrechung erkennst, da brauchst Du wohl einen Zeitvergleich, z.B. über unnormal lange RUNTIME()-Aufruf-Ausführungszeiten oder Du fragst den schnellen Zähler ab, wenn der Zählerstand sich um mehr als 1 ändert, dann war gerade die Unterbrechung.

Zum Testen von schnellstmöglichen Vorgängen muß der Programmcode nicht eine elegante Schleife sein, ich würde mich nicht scheuen, auch mal 100 einzelne Peripherieausgaben hintereinanderweg hinzuschreiben (Copy+Paste).

Harald

PN/DP · 1 November 2016

Hesse schrieb:
Anhang anzeigen 34573

Interessant zu sehen, daß die 1- und 0-Ausgaben ziemlich gleich lang sind, daß offenbar die ca. 5 µs fast nur vom Aufruf des Peripherieschreibens kommen und der Schleifen-Rücksprungcode sogut wie keinen Einfluß (<< 1 µs) auf die Programmlaufzeit hat.

Harald

Thomas_v2.1 · 1 November 2016

So wie es aussieht erfolgen die Unterbrechungen alle 1ms. Da müsste man sich nur einmalig den Zeitpunkt der Unterbrechung merken, und wüsste dann wann die nächste Unterbrechung kommt und kann dann die Übertragung entsprechend zeitlich abstimmen.

Nur wie bekommt man das gemessen? Evtl. den Ausgang rückführen auf einen schnellen Zähleingang, und dann in einer Schleife 100ms lang Takte (Softwaremäßig) ausgeben, und später den Zählerstand auswerten. Kommen zu wenig, dann weiß man dass man sich hier im Unterbrechungszeitraum befunden hat.
Wenn die Unterbrechungen langzeitstabil sind, muss dieser Messzyklus nur einmalig nach Neustart durchgeführt werden.

PN/DP · 2 November 2016

Unterbrechung alle 1 ms - könnte es sein, daß die S7-1200 als PROFINET-Controller konfiguriert ist mit einem Sendetakt von 1 ms? Kann man den Takt ändern oder abschalten? Oder gibt es weitere Einstellungen, welche irgendwas mit 1 ms Intervall ausführen?

Harald

rostiger Nagel · 2 November 2016

PN/DP schrieb:
Unterbrechung alle 1 ms - könnte es sein, daß die S7-1200 als PROFINET-Controller konfiguriert ist mit einem Sendetakt von 1 ms? Kann man den Takt ändern oder abschalten? Oder gibt es weitere Einstellungen, welche irgendwas mit 1 ms Intervall ausführen?

Harald

Da gibt es unter Profinet-Schnittstellen->Erweiterte Optionen->IO-Kommunikation einen Reiter mit Sendetakt dieser steht laut Werkseinstelung auf 1.oooms vielleicht rotzt dieser da rein.
Ich weiß aber nicht wie man diesen abschalten kann, man kann andere Zeiten einstellen.

Hesse · 2 November 2016

rostiger Nagel schrieb:
Da gibt es unter Profinet-Schnittstellen->Erweiterte Optionen->IO-Kommunikation einen Reiter mit Sendetakt dieser steht laut Werkseinstelung auf 1.oooms vielleicht rotzt dieser da rein..

Profinet kann ich nicht abschalten, das brauch ich schon noch….
Zum Test wollte ich aber die Sendezeit ändern, geht da bei euch was anderes einzustellen als 1ms?
Bei mir kommt bei allem andern Einstellungen :

TIA schrieb:
Der Sendetakt des IO Controllers ist ungültig

Thomas_v2.1 · 2 November 2016

Hast du schon Profinet Devices an dem Controller projektiert? Evtl. unterstützt ein Device nur bestimmte Zyklen.

Hesse · 2 November 2016

Thomas_v2.1 schrieb:
Hast du schon Profinet Devices an dem Controller projektiert? Evtl. unterstützt ein Device nur bestimmte Zyklen.

Nein , in diesem „RS232 Testprojekt" kein Profinet Teilnehmer

Hesse · 24 Dezember 2016

Hallo ,
möchte meinen Abschlussbericht nicht schuldig bleiben.
Ich habe es nicht hingekommen unter eine Fehlerrate von
vier bis fünf Byte pro hundert Byte zu kommen und das auch nur bei 19200 .

Für meine Anwendung hätte das sogar ausgereicht.
Da ich dann, aus einem anderen Grund sowieso einen vor Ort Termin hatte habe ich das Problem anderweitig gelöst.

Wenn man vielleicht noch wirklich viel Zeit rein investieren würde ging vielleicht noch etwas mehr. Man hätte aber keine Sicherheit dass es nach irgendeinem Update von Siemens dann auch wieder noch funktionierten wurde.
Danke allen Helfern
gelernt habe ich bei der Aktion auf jeden fall wieder etwas ….

Heinileini · 24 November 2018

Hesse schrieb:
gelernt habe ich bei der Aktion auf jeden fall wieder etwas ….

Ich auch: es gibt hier im Forum etliche, die ihr Hobby zum Beruf gemacht haben und den nötigen Biss haben, nicht so schnell aufzugeben.

Hätte diesen Thread gerne 2 Jahre früher entdeckt.
Vor ca. 30 Jahren habe ich mich via S5 AWL, PLC 150 irgendwas (A oder K, definitiv nicht S) und NC 8M auch mit diesem Thema beschäftigt.
Es waren 300 Baud angesagt und der Anschluss eines PT80 bzw. PT88 und … es hat problemlos funktioniert, jedenfalls an der standalone Test-PLC.
Sobald aber die 8M mit im Spiel war, kamen Unterbrechungen, gegen die die InterruptSperren der PLC wirkungslos waren. Und auch Siemens konnte (oder wollte?) nicht aus der Patsche helfen. Somit war das Projekt abrupt wieder gestorben.
Hatte den Weg beschritten pro OB1-Zyklus ein Zeichen per PAW in einer ProgrammSchleife auszugeben. Musste aber nicht gegen optimierende Compiler kämpfen.
PWM-Ausgänge kannte ich nicht, vermutlich gab's die auch noch nicht?
War interessant, hier den Thread zu verfolgen!

Gruss, Heinileini

TIA Software UART am Digitalout einer S7-1200 ?

Gleichstromer

Level-2

Hesse

Level-3

Hesse

Level-3

Thomas_v2.1

Level-3

Hesse

Level-3

Hesse

Level-3

Thomas_v2.1

Level-3

Hesse

Level-3

PN/DP

User des Jahres 2011-2013;2015-2017;2020-2022;2024

PN/DP

User des Jahres 2011-2013;2015-2017;2020-2022;2024

Thomas_v2.1

Level-3

PN/DP

User des Jahres 2011-2013;2015-2017;2020-2022;2024

rostiger Nagel

Forums-Knochenbrecher

Hesse

Level-3

Thomas_v2.1

Level-3

Hesse

Level-3

Hesse

Level-3

Heinileini

Level-3

Similar threads

Wir schützen deine Privatsphäre