Step 7 Analogausgabe Karte defekt?

S7Typ

Level-1
Beiträge
55
Reaktionspunkte
4
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
Ich habe ein seltsames Phänomen an einer Anlage. Diese Anlage regelt einen Schweißbrenner (Gleichstromotor mit Geber) entsprechend der Nahtlage. Mittels Kamera mit einem PC System wird die aktuelle Abweichung an einen analogen Eingang einer S7 300 Steuerung übertragen. Die S7-300 steuert über einen analogen Ausgang von -10V bis +10V eine Motorkarte an. Leider kann ich das PAW nicht beobachten mit Step7. Ein Bediener sagte mir, dass wenn der im Handbetrieb den Schweißbrenner ausrichtet (dafür betätigt er einen Taster) nach loslassen des Tasters der Schweißbrenner in die entgegengesetzte Richtung fährt… ich habe das ganze visuell bestätigen können und habe mit meinem Multimeter am Ausgang der Analogausgabekarte gemessen. Betätigt er den Taster für die Linksfahrt werden konstant -2V ausgegeben. Lässt er den Taster los Messe ich kurz +1V bevor der Ausgang auf 0V geht (das ganze auch wenn an der Karte die Drähte zur Motorkarte abgeklemmt sind). Die Karte zeigt keinen Fehler an. Wir hatten vor einiger Zeit schon die Geberkarte gewechselt (FM350-1) weil die Regelung gar nicht mehr ging und die Steuerung auf die Geberimpulse nicht mehr reagiert hatte. Wie gesagt ich würde gerne das PAW beobachten aber das geht nicht. Ich sehe nur den internen Sollwert der aber nicht das Vorzeichen wechselt wie die Spannung an der Karte. Früher hat es auch immer funktioniert. Die „Regelung“ ist eigentlich keine Regelung es gibt nur einen Toleranzbereich und dann in jede Richtung eine kleine und große Abweichung (mittels Vergleichern). D.h. Im Automatik führt die Analogausgabe nur folgende Spannungswerte: -4V,-2V,0V,+2V,+4V. Wäre auch nebensächlich, da im Handbetrieb wo nur ein Festsollwert ins PAW geschrieben wird der Fehler auch auftritt.
 
Zuletzt bearbeitet:
Leider kann ich das PAW nicht beobachten mit Step7
Welche Adresse hat denn der Analogausgang? Hast du es mit AWxxx mal probiert?

Wäre auch nebensächlich, da im Handbetrieb wo nur ein Festsollwert ins PAW geschrieben wird der Fehler auftritt.
Dann wäre doch der erste Schritt, sich mal den Code anzuschauen. Wenn es im Autobetrieb geht und im Handbetrieb nicht, dann hört es sich für mich nicht nach einem defekten Analogausgang an.
 
Man kann sich das Ganze auch parallel z.B. auf ein Merkerwort schreiben - das läßt sich auf jeden Fall beobachten. Ich tippe aber auch eher auf die Karte ...
 
wenn ich PAW272 per Move oder Lade Transfer Befehl in ein freies MW schreiben will wird das sofort rot und als Fehler in Simatic Manager dargestellt. Das hatte ich heute morgen noch ausprobiert. Eigentlich mag ich die Handhabung von Simatic Manager aber manche Dinge sind einfach so umständlich das kann ich nicht begreifen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
So meinte ich das auch nicht ... an irgendeiner Stelle im Programm wird ja der berechnete Wert in das PAW 272 geschrieben - an der Stelle schiebst du das paralle auch in ein Merkerwort. Ein PAW kannst du natürlich nicht laden - das ginge nur mit einem AW weil dies bis zum Schreiben auf die Hardware auch nicht viel was anderes ist als ein MW ...
 
Ja das Problem ist das ganze geschieht in einem FC welcher 3 mal aufgerufen (1 mal für das PAW für den Motor und 2 mal für das PAW für die Beleuchungseinstellung diese wird beidseitig geregelt) wird. Dem FC wird nur der Sollwert intern übergeben und dann wird überprüft ob der Wert innerhalb von 2 definierten festen Werten/Grenzen liegt welche ebenfalls am Bausteineingang direkt definiert sind. Dann wird das ganze in eine lokale Out Variable geschrieben wo dann das PAW 272 mit verknüpft. Aaaaaber derjenige der den Baustein programmiert hat transferiert den Wert für die lokale Out Variable (PAW 272) vorher in ein MD und dann in ein MW. Hat aber keine Auswirkung, da die anderen beiden FC‘s erst danach bearbeitet werden (hoffe du weißt was ich meine). Dadurch, dass es FCs sind bringt auch das beobachten nichts. Ich kann lediglich schauen, was dem Baustein für ein interner Sollwert übergeben wird und das ist stimmig. Oder ich müsste die HW Konfig ändern und das PAW 272 in einen niedrigeren Bereich legen, um dann auf das AW drauf zuzugreifen.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Leider Nein ... und deine Beschreibung erklärt auch nicht warum du meinen Vorschlag da nicht umsetzen kannst ...
Weil das ganze in einem FC passiert welcher 3 mal aufgerufen wird, für 3 verschiedene analoge Ausgänge.
Wäre das ein FB könnte ich in die Instanz schauen. Wie will ich denn einen FC, welcher 3 mal aufgerufen wird entsprechend beobachten? Das geht gar nicht!
 
Un die Zuordnung des Anlogausgangs erfolgt wie ? Wenn der FC 3 mal aufgerufen wird und dabei unterschiedliche Outs ansteuert dann ist der Out ggf. an der Baustein-Schnittstelle ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
wenn ich PAW272 per Move oder Lade Transfer Befehl in ein freies MW schreiben will wird das sofort rot und als Fehler in Simatic Manager dargestellt.
Peripherieausgänge (z.B. PAW...) kann man nicht lesen und deshalb auch nicht beobachten.
Einfache Lösung: eine Zwischenspeichervariable einfügen, d.h. den Sollwert des Ausgangs auf ein globales Speicherword (z.B. MWx oder DBy.DBWz) schreiben und danach den Wert des Speicherwords in den Peripherieausgang kopieren. Dann kann man den Wert des Speicherwords beobachten. (zum Beobachten mit einer Variablentabelle muss natürlich jede Zwischenspeicherstelle ein anderes MW verwenden)
Code:
+-----+
| FCx |              +--------+
|  OUT|-MW272        |  MOVE  |
|  ENO|--------------|EN      |
+-----+        MW272-|IN   OUT|-PAW272
                     +--------+


Weil das ganze in einem FC passiert welcher 3 mal aufgerufen wird, für 3 verschiedene analoge Ausgänge.
Wäre das ein FB könnte ich in die Instanz schauen. Wie will ich denn einen FC, welcher 3 mal aufgerufen wird entsprechend beobachten? Das geht gar nicht!
Doch das geht. Man kann auch nur bestimmte FC-Aufrufe/Durchläufe beobachten: Stichworte: "Aufrufumgebung", "Beobachten mit Aufrufpfad"
Als Beobachtungsbedingung kann man z.B. festlegen, daß ein bestimmter DB oder IDB (DI) geöffnet sein muß. Dann zeigt der Beobachtungsstatus nur den Status in den Aufrufen, wo der angegebene DB beim Aufruf geöffnet ist.

Beispiel:
- ggf. ein paar (leere) DB erzeugen und in die CPU laden, z.B. DB101, DB102, DB103
- den zu beobachtenden FC öffnen
- Test > Betrieb: Testbetrieb aktivieren
- Test > Aufrufumgebung: als Bedingung [x] Offene Datenbausteine, Instanz-DB Nummer: 101
- im Programmcode vor dem interessierenden FC-Aufruf DB101 als IDB öffnen
Code:
   DI101
---(OPN)

oder in AWL:
Code:
AUF DI 101
CALL MyFC
 OUT:=MW272

L MW272
T PAW272

AUF DI 102
CALL MyFC
 OUT:=MW274

L MW274
T PAW274

Zur Kontrolle kann man bei AWL im Status das "DB-Register 2" einblenden und beobachten.

Harald
 
Zuletzt bearbeitet:
Testweise mal den AO von dem Rest abklemmen und dann noch mal messen.

Wer sagt denn, das die ominöse Spannung nicht von der Leistungsseite irgendwie zurückkommt, könnte ja da auch was kaputt sein.
Masseverbindungen überprüft? Potentialausgleich auf der Maschine mit ausreichend Querschnitt vorhanden und OK?

Gerade beim Schweißen mit höhen DC Strömen hab ich da schon alle möglichen Effekte gesehen.
 
Wäre das ein FB könnte ich in die Instanz schauen. Wie will ich denn einen FC, welcher 3 mal aufgerufen wird entsprechend beobachten? Das geht gar nicht!
Falls das "Beobachten mit Aufrufpfad" zu umständlich erscheint und noch genug Programmspeicher in der SPS frei ist, dann kann man auch
- den zu beobachtenden FC im Projekt kopieren
- unter einer anderen Nummer wieder einfügen
- in die SPS laden
- bei dem FC-Aufruf, den man beobachten will, den Aufruf ändern zur FC-Kopie
- dann wird die FC-Kopie nur einmal aufgerufen und man beobachtet die gewünschte "Instanz"

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Irgendwie habe ich ein ganz bisschen das Gefühl, auch weil Harald auch scheinbar noch in der Spur ist, dass das Ganze, auch wenn es lange funktioniert hat, mit dem FC zu tun hat und einer ggf. grenzwertigen Verwendung von TEMP-Variablen.
 
Ich sehe nur den internen Sollwert der aber nicht das Vorzeichen wechselt wie die Spannung an der Karte.
:unsure: Was ist der "interne Sollwert"?
Wenn das der Wert ist, der an das (korrektte) PAW ausgegeben wird, dann gibt es eigentlich keinen Grund, warum sich die AusgangsSpannung mit dem "internen Sollwert" ändert, aber das Vorzeichen der Spannung nicht dem Vorzeichen des "internen Sollwertes" folgt.
Ein Missverständnis des irritierenden Begriffs "VorzeichenBit" kann doch wohl nicht das Problem sein?
Ist der AnalogAusgang evtl. so parametriert, dass am Ausgang nur positive Spannungen ausgegeben werden sollen, so dass evtl die Ausgabe auf den unteren Wert von -1 V begrenzt wird? Aber -1 V ist doch negativ ... wie ist das mit der Aussage vereinbar, dass das Vorzeichen nicht wechselt?
:unsure: Oder meinst Du, dass es zwischen dem "internen Sollwert" und dem Schreiben auf PAW eine Skalierung des Wertes gibt, die Du nicht beobachten kannst?
Nein. Der FC hat 3 Inputs:
Interner Sollwert
Obergrenze
Untergrenze
1 Output:
Ausgabe
:unsure: Oder versteckt sich die Skalierung in dem FC und seine Eingangswerte 'Obergrenze' und ' Untergrenze' haben einen Einfluss auf die Skalierung?
:unsure: Der Wert, den der FC ausgibt, ist der Wert, der direkt(?) auf dem PAW ausgegeben wird? Warum sollte sich der vom FC berechnete Wert nicht so abspeichern lassen, dass je FC-Aufruf ein anderes SpeicherZiel angegeben wird???
D.h. Im Automatik führt die Analogausgabe nur folgende Spannungswerte: -4V,-2V,0V,+2V,+4V.
:unsure: Wenn das so ist, was gibt es dann am Verhalten der Karte auszusetzen? Du beschreibst doch hier das, was die Karte tun soll (inklusive des angeblichen nicht funktionierenden VorzeichenWechsels) ... oder was habe ich falsch verstanden?

Wer sagt denn, das die ominöse Spannung nicht von der Leistungsseite irgendwie zurückkommt, könnte ja da auch was kaputt sein.
Ich dachte, S7Typ hätte das irgendwo gesagt/erwähnt. Aber leider finde ich die Stelle nicht wieder ...

Ich kann lediglich schauen, was dem Baustein für ein interner Sollwert übergeben wird und das ist stimmig.
:unsure: Und Du kannst nicht schauen, was der FC jeweils für einen AusgangsWert aus den beobachtbaren EingangsWerten macht?
Und Du kannst nicht ggfs das Programm so umschreiben, dass die verschiedenen Ergebnisse beobachtbar werden?
Aaaaaber derjenige der den Baustein programmiert hat transferiert den Wert für die lokale Out Variable (PAW 272) vorher in ein MD und dann in ein MW.
:unsure: Er speichert den berechneten Wert zuerst in ein MD und dann erst in ein MW?
Also in das MD mit der Nr 'MD-Nr' und in das MW mit der 'MW-Nr'?
Also löscht er (so nebenbei) das MW mit der Nr 'MD-Nr' und beschreibt das MW mit der Nr 'MD-Nr' + 2 und das MW mit der Nr 'MW-Nr' mit dem berechneten Wert?
Sind 'MD-Nr' und 'MW-Nr' identisch?
Gibt es zwischen dem Abspeichern in ein MD und dem Abspeichern in ein MW zufällig noch eine Umwandlung von GleitPunktZahl in FestPunktZahl? Für die AnalogKarte dürfte ein INT-Wert (= 16 Bit FestPunktZahl) relevant sein.
 
... auch wenn es lange funktioniert hat ...
Da gebe ich Dir Recht, Ralf. "Hat jahrelang so funktioniert" besagt in der Praxis oft gar nix.
Ob etwas funktioniert oder nicht, das hängt meistens auch von den Daten ab und nicht nur von dem Programm.
Falls es "stillschweigende" Absprachen gibt, welche Daten auftreten können und welche nicht, dann verzichtet das Programm wahscheinlich(?) darauf, zu prüfen, ob nicht doch Daten angeliefert werden, die nicht auftreten dürfen.
 
Zurück
Oben