Impulslänge auswerten

chbr

Level-1
Beiträge
3
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

hier gleich mein erster Beitrag ;)

Ist es möglich mit den normalen Digi IOs einer S7, die Impulslänge eines Rechtecksignals auszuwerten? Die Impulse wären recht lang, und zwar z.B. 100ms oder 500ms. Könnte man diese klar unterscheiden? Und wenn ja wie aufwendig und rechenintensiv wäre sowas?

Ein extra Modul zur Frequenzzählung möchte ich mir sparen.

Vielen Dank,
Christian
 
Hallo,
wenn du nur einfach den einen Impuls von dem anderen in der Länge unterscheiden willst, dann ist das kein Problem und läuft stinknormal mit den Standard-Timern.
Falls du jedoch die Impulslänge ziemlich genau messen möchtest, dann wäre dabei die Mess-Toleranz deine CPU-Zykluszeit und du müßtest mit der Systemzeit oder dem OB35 als Taktgeber arbeiten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Taktmerker benutzen

@chbr

am einfachsten dürfte bei der geforderten Genauigkeit sein, das Taktmerkerbyte zu benutzen. Solange der Impuls ansteht, einen Zähler mit einem Taktmerker laufen lassen: Wenn der Impuls fertig hat, zeigt der Zählerstand die Impulslänge. Zähler auslesen, rücksetzen und auf den nächsten Impuls warten.
 
Hallo,

vielen Dank für euere Antworten.

Das ganze klingt für mich ziemlich plausibel. Ich komme eher aus dem Mikrocontroller/Embedded Bereich, von daher meine Fragen.
Dort macht man es eigentlich genau so. Wie schnell kann denn der Timerinterrupt sein, mit dem man die Impulslänge misst?
Bei 25ms (40Hz) würde man ja in etwa eine Impulslängen in 100ms Schritten unterscheiden können (also 100, 200, 300 ms... Länge).

Ist die Verarbeitung einem Controller ähnlich, also einer Interrupt Service Routine?

Grüße,

Christian
 
Hallo,
deine Anahme ist in etwa zutreffend. Der OB35 entspricht einem Timer-Interrupt. Das Aufruf-Intervall ist einstellbar (HW-Konfig der CPU). 10 ms wären dabei ohne weiteres machbar.
In diesem OB35 kannst du dann deinen Code hinterlegen oder von dort aus Funktionen (FC's oder FB's) aufrufen.
 
Das hört sich doch gut an.

Also sollte es auch nicht zu viel Ressourcen der CPU klauen? ;)
Das ganze soll in professionellen SPS Steuerungen laufen (und ich überprüfe nur ob meine Applikation so an eine SPS angebunden werden kann)... ein Profi sollte also bei sowas nicht den Kopf schütteln, weil es zu unnormal ist oder zu weit hergeholt? :ROFLMAO:

Christian
 
Zuletzt bearbeitet:
Hallo Christian,
es gibt, wie du an den einezelnen Beiträgen gesehen hast, mehrere zielführende Möglichkeiten. Je nachdem, was du im Einzelnen genau anstellen willst werden die CPU-Resourcen hierbei in Anspruch genommen. Der OB35-Aufruf wäre hierbei allerdings nicht meine erste Wahl, sondern ich mache es bei vergleichbaren Problemstellungen so ähnlich wie es Zotos schon genannt hat. Deine Ungenauigkeit liegt dabei dann halt "nur" im Bereich der Zykluszeit des Hauptsprogramms.
 
was für eine baugruppe hast du denn?

es gibt baugruppen, die können beim flankenwechsel einen alarm-ob aufrufen.
oder auch die e's der cpu's 31xC sind alarmfähig.
 

Anhänge

  • Zwischenablage02.gif
    Zwischenablage02.gif
    14,7 KB · Aufrufe: 20
...Also sollte es auch nicht zu viel Ressourcen der CPU klauen?...

...Das ganze soll in professionellen SPS Steuerungen laufen ... ein Profi sollte also bei sowas nicht den Kopf schütteln...

Ressorcen sparend ist m.E. Zotos' Methode - ich programmiere das genauso, wie er. Ich halte dies auch für professionell - allerdings gibt es bei der aus heutiger Sicht veralteten CPU318 einen ekelhaften Bug: dort stimmt die OB1-Startinformation der Zykluszeit nicht. Da es sich um ein Derivat der 400er im 300er-Pelz handeln soll, würde ich das ggf. noch für 400er-CPUs separat prüfen (kann ich persönlich keine Aussage machen - habe nur 300er).

IMHO unbestreitbar professionell sind entweder die IEC-Timer oder die Verwendung des SCF64 TIME_TCK. Ich persönlich verwende den SFC64 bei der CPU318 wegen des genannten Bugs und generiere daraus dann die Entsprechung der Startinformation OB1_PREV_CYCLE. Ich persönlich benutze dann die Dauer des letzen Zyklus als Globalvariable zur Verarbeitung in sämtlichen Prozessen. Bei vollständig gekapselten FB übergebe ich die Zykluszeit an der Schnittstelle. Einen Aufruf des SFC64 innerhalb des Bausteins halte ich für genauso unprofessionell wie eben diese globale Zykluszeit innerhalb des Bausteins zu verwenden. Die Verwendung von IEC-Timern halte ich auch innerhalb von FB für professionell soweit dann ein Multiinstanzaufruf erfolgt, da sie aber m.E. ihrerseits einen SFC64-Aufruf verursachen, sind sie nicht so sehr laufzeiteffizient. Im Übrigen ist die Verwendung von unprofessionellen S5-Timern ist kaum laufzeiteffektiver, als die Zeiten in eine 16- oder 32-Bit-Variable einzuzählen incl. der Überlauf und etc.-Prüfungen.

Ich hoffe, ich habe damit nicht mehr Verwirrung, als Information geschaffen ...;)
 
Also das ist jetzt wieder so ein Punkt,
bei dem ich mir bei Siemens absolut nicht sicher wäre.

Wobei:
Genau genommen steht das ja sogar in meinem FAQ.

Wobei eine Plausibilitätskontrolle aber unabhängig von dem FAQ sicher kein Schaden ist.

Mfg
Manuel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bei SFC64, dann aber unbedingt folgendes FAQ von Siemens beachen:
Beitrags-ID:12033733

Mfg
Manuel

Danke Dir !!! :)
Haben die bei Siemens irgendwas im Griff?:twisted: :confused: :twisted:

also: nimm kein Siemens - das ist von vorneherein unprofessionell !!!

also soviel zu professionell: Siemens selbst verlässt sich z.B. beim Options-Programmpaket Higraph auf den SFC64 (zumindest in einer etwas veralteten Version, die ich nur zwei Mal benutzt habe). Und es würd mich nicht wundern, wenn die IEC-Timer genauso unzuverlässig in den genannten CPUs funktionieren.
 
Danke Dir !!! :)
Haben die bei Siemens irgendwas im Griff?:twisted: :confused: :twisted:

also: nimm kein Siemens - das ist von vorneherein unprofessionell !!!

also soviel zu professionell: Siemens selbst verlässt sich z.B. beim Options-Programmpaket Higraph auf den SFC64 (zumindest in einer etwas veralteten Version, die ich nur zwei Mal benutzt habe). Und es würd mich nicht wundern, wenn die IEC-Timer genauso unzuverlässig in den genannten CPUs funktionieren.

Hallo "Perfektionist",

allem Anschein nach, bist du doch nicht so "Perfekt".

Siemens als unprofessionell zu bezeichnen ist schon lächerlich.

Allerdings kenne ich zwei Ausnahmen: WinCC flexibel,

und den von dir angesprochenenn Schrotthaufen "HiGraph".

Aber wer HiGraph einsetzt ist selber schuld, oder arbeitet für Daimler...


CU

Jürgen.
 
Guten Morgen Jürgen,

ja ja, Perfektionisten streben nach ihr, aber erreichen werden sie sie nie - die Perfektion.

HiGraph haben wir zu Beginn mal mitangeschaft, weil ein Daimlermann imer davon schwärmte - wie gesagt, zwei Projekte. neulich hab ich von dem einen alten Projekt mal so ne Schrittkette in normal umgekodet. WinCC: es gibt halt keine perfekten Kunden.:p

nochwas zur Sache: nachdem ich drüber geschlafen habe, stelle ich fest, dass meine gestrige Meinung zur Verwendung von Time_TCK und ISO-Timern inkonsistent ist. ich versuchs, kurz zu machen: in einem FB, der vollständig gekapselt werden soll (incl know_how_protect), darf m.E. keinerlei globales Element enthalten sein - auch keine Systemfunktion.

Lockerung Stufe 1: Systemfunktionen vorhanden

Lockerung Stufe 2: weitere FB/FC werden als Subroutinen aufgerufen (das lässt sich aber durch eine Rücksprungverwaltung innerhalb des Bausteins vermeiden).

und jetzt Frühstück:cool:


EDIT

... Siemens als unprofessionell zu bezeichnen ist schon lächerlich. ...

war auch gar nicht wirklich ernst gemeint ... aber anhand der Ausnahmen kommt man ja schon ins Zweifeln, ob das nicht jemand im vollen Ernst behaupten würde :ROFLMAO:

Doppeledit: ... aber nachdem Zotos da jetzt ein Danke unter meine Aussage druntergepflanzt hat, muss ich schon zu meiner Aussage stehen:twisted:
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Morgen Jürgen,

ja ja, Perfektionisten streben nach ihr, aber erreichen werden sie sie nie - die Perfektion.

...

Hallo Perfektionist,

die Perfektion ist nie erreichbar.
Aber das Streben nach ihr hilft uns, ihr näher zu kommen.

CU

Jürgen.

P.S.
Zotos hat wahrscheinlich versehentlich auf den Dank - Button geklickt, so früh am Morgen :ROFLMAO:
 
Zurück
Oben