Ausgang als Parameter übergeben

IOSam

Level-1
Beiträge
6
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Gibt es mit Awl die Möglichkeit eine Funktion zu schreiben welcher ich einen in einem Datenbaustein definierten Ausgang als Parameter gebe? Ziel ist es aus der Leitebene heraus zu bestimmen welcher Ausgang an/ausgeschaltet wird.

Gesendet von meinem A510 mit Tapatalk 2
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es ist eine S7 300/400 und es sollen digitale Ausgänge an und ausgeschaltet werden, welche sich in unterschiedlichen Modulen bzw. auch auf DZEs befinden. Ich möchte eine FC bzw. einen FB mit dem Ausgang als In-Parameter erstellen was soweit schon funktioniert.

Die besagte Funktion rufe ich in meinem Testprogramm im OB1 auf. Jedoch bekomme ich diesen Aufruf bisher nur mit absoluten Werten hin. Ziel ist es aus der Leitebene die absolute Adresse in einen DB zu schreiben, welcher beim Funktionsaufruf ausgelesen wird.

Die Frage ist wie schreibe ich am die Adresse am besten in den DB und viel wichtiger wie löse ich sie auf damit ich sie an meine Funktion übergeben kann.
 
Ich verstehe Deine Anfrage wie folgt:
Du hast einen FB bzw. FC und willst von außerhalb (Leitsystem/HMI/usw.) bestimmen welchen Ausgang dieser Baustein nun beschreiben soll.

Eine Möglichkeit wäre es im HMI die Informationen eines S7-Pointers zusammenzubauen und an eine dem FC/FB bekannte Stelle in einem DBD bzw. MD zuschreiben. Der FB bzw. FC kann dann mittels indirekter Adressierung das Bit steuern.
 
Ich würde im HMI einen einfachen Integer-Wert mit einer Dezimalstelle anzeigen/eingeben lassen (das entspricht ja der Angabe des Ausganges) und aus diesem Wert den Pointer erzeugen:
Code:
[FONT=courier new]FUNCTION "Ausgang" : BOOL
TITLE =
VERSION : 0.1

VAR_INPUT
  Adresse : INT ;    
  Aktion : BOOL ;    
END_VAR

VAR_TEMP
  Adress_Bit : INT ;    
  Adress_Byte : INT ;    
  Adresspointer : DWORD ;    
  AR1_Temp : DWORD ;    
END_VAR


BEGIN

NETWORK
TITLE =Fehlermeldung rücksetzen
      SET   ; 
      R     #RET_VAL; 

NETWORK
TITLE =Gültigkeit
      L     0; 
      L     #Adresse; 
      <I    ;[/FONT][FONT=courier new]               //Adresse negativ?[/FONT][FONT=courier new] 
      SPBN  _001; 
      L     10; 
      MOD   ; 
      T     #Adress_Bit; 
      L     7; 
      >I    ;[/FONT][FONT=courier new]               //Bitstelle größer als 7?[/FONT][FONT=courier new]
      SPBN  _002; 
_001: S     #RET_VAL; 
      BEA   ; 
_002: NOP   0; 

NETWORK
TITLE =Pointer erzeugen
      L     #Adresse; 
      L     10; 
      /D    ;               //Byte separieren (bit wegrechnen)
      T     #Adress_Byte;   //Byte speichern (falls anderweitig benötigt)
      SLD   3;              //auf Bytestelle im Pointer verschieben
      L     #Adress_Bit; 
      OD    ;               //Byte und Bit zusammenfügen
      T     #Adresspointer; //Pointer speichern

NETWORK
TITLE =Ausgang setzen/rücksetzen
      TAR1  #AR1_Temp;      //AR1 temporär sichern; Typ: DWORD
      LAR1  #Adresspointer; //Adresspointer ins Adressregister schreiben
      U     #Aktion; 
      =     A [AR1,P#0.0];  //Aktion auf gewünschtes Ausgangsbit übertragen
      LAR1  #AR1_Temp;      //gesichertes Adressregister in AR1 zurückschreiben

END_FUNCTION[/FONT]
Die Gültigkeitsprüfung, die hier enthalten ist, müßtest Du dann evtl. in ähnlicher Weise bei der Eingabe am HMI machen.
 
Hallo IOSam, bei Deinem Vorhaben bekomme ich massiv Bauchschmerzen ...

Ich würde einen Teufel tun, dem PLS zu helfen, direkt die Ausgänge meiner SPS zu schalten (höchstens vielleicht, wenn an der SPS nur Lampen angeschlossen sind). Soll die SPS zu einer dezentralen IO degradiert werden?
Und die dazu nötige indirekte Adressierung von Ausgängen empfinde ich als ein absolutes No-Go!
Ganz davon abgesehen, daß das Ganze höchstens für ein paar ms funktioniert, wenn der Ausgang auch eine zyklische Zuweisung aus dem SPS-Programm erhält.

Viel Spass dann auch bei einer Fehlerdiagnose ... ohne Referenzdaten ... bei jedem Ausgang der sich "seltsam" verhält, wird der Verdacht zuerst auf das PLS fallen ...

Es muß doch auch eine saubere Lösung für Deine Aufgabe geben. Erzähl mal mehr!

Was willst Du bei Dir steuern? Was ist an den Ausgängen angeschlossen? Um wieviele Ausgänge geht das bei Dir? Warum ist es nicht möglich, ganz normal Einschaltbits und Ausschaltbits vom PLS an die SPS zu senden und in der SPS sauber zu verknüpfen? Willst Du Programmierarbeit sparen? Oder "Powertags"? Wie hast Du Dir die Bedienung im PLS gedacht? Soll ein Operator in ein EA-Feld eine x-beliebige Zahl eingeben und dann auf einen Button "ich weiß sicher was ich tue - schalte das jetzt mal ein!" drücken?

Was kann an Deiner Anlage passieren, wenn sich jederzeit beliebige Ausgänge einschalten können? Was passiert, wenn die Verbindung vom PLS unterbrochen wird?


Wenn überhaupt, dann kann ich mir die Lösung Deiner Aufgabe nur so vorstellen, daß es eine begrenzte Anzahl vorher bestimmter (programmierter) Ausgänge gibt, welche Schaltbefehle direkt vom PLS erhalten dürfen. Das PLS sendet dazu eine Index-Zahl für den gewünschten Ausgang und die SPS führt die für diesen Indexwert programmierte Programmsequenz aus - im einfachsten Fall einen Merker setzen. Nicht vereinbarte Indexwerte werden einfach ignoriert/verworfen.

Auf keinen Fall sollte es eine direkte Umrechnung vom Indexwert in die absolute Ausgangsadresse geben - da gehört eine Rangiermöglichkeit und eine Ausgangsverknüpfung dazwischen.

Harald
 
Es handelt sich um eine Dosieranlage. Hierbei gibt ca. 40 Antriebe (Dosierschnecken) welche je nach Dosierauftrag einzeln angeschaltet und beim erreichen des vorgegebenen Sollgewichts abgeschaltet werden sollen. Vom Ablauf her würde die SPS also von der Leitebene ein Sollgewicht und den Ausgang für den jeweiligen Auftrag bekommen. Dies geschieht allerdings nicht vom Anwender direkt sondern über ein Programm. Der Bediener kann demnach die Ausgänge nicht frei wählen sondern er wählt nur ein Dosierrezept aus hinter welchem sich der jeweilige Ausgang verbirgt.

Dein Vorschlag Einschaltbits und Ausschaltbits vom PLS an die SPS zu senden und diese in der SPS sauber zu verknüpfen ist natürlich auch eine Option. Nachteil wäre zwar, dass bei jeder späteren Umadressierung bzw. beim Hinzukommen neuer Dosierantriebe das SPS-Programm neu angepasst werden muss.

Kann ich mir das Verknüpfen so vorstellen, dass ich aus dem PLS in einem Datenbaustein die Antriebsnummer z.B. 7 eintrage. Im FB muss ich nun bedingt abfragen und beim betroffenen Ausgang an/abschalten. Wie genau würdest du das denn aufbauen? Habe ich dann eine Art Tabelle z.B. ein Array wo ich nachsehen kann, welcher Ausgang zur 7 gehört?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Harald: 100% ACK
@IOSam:
Ich würde das so lösen:
Du hast jetzt 40 Schnecken.
Gut, dann bereit HW-mässig mal zB 64 vor, muss ja noch nicht angeschlossen werden.
Dann baut Du Deine 64 FC/FB's bereits im Programm ein.
Im PLS kannst Du mittels (passwortgeschützen) Parameter angeben wieviele Dosierschnecken tatsächlich physikalisch vorhanden sind (auch das ist ein Wert in der SPS).
Das Rezept kann sich der Bediener nun von 1-xx aussuchen und Start drücken.
Dann arbeitet der jeweilige FC/FB mit der dieses Rezept "verbunden" ist dieses Programm ab.

Bedenke: Schnecke hat vermute ich auch Rückmeldung, Störung, das sind 2 weitere Adressen.
Einmal kommt ein FU dazu, dann passt wieder nichts.
Oder man will mal mit 2 Schnecken gleichzeitig fahren... egal was die Zukunft bringt, Du bist dafür mit der trickreichen Version NICHT gerüstet.


Gruß
Karl
 
Ok das mit dem Festbrennen der Ausgängen auf der SPS sehe ich ein, aber ist es wirklich notwendig für jeden Antrieb eine eigene FC oder einen FCB zu basteln? Wie wäre es wenn ich einen FB nehme in dem alle potentiell möglichen Ausgänge bedingt abgefragt werden. Sobald der richtige Ausgang dran ist wird eine globale An/Ausschaltfunktion mit den jeweiligen Aufruf Parameter aufgerufen.


Einen Vorteil sehe hierbei in der Über und dass ich bei Änderungen nicht 64 mal die eigentlich immer gleich aussehende Funktion anpacken muss.
 
Du kannst doch deinen Baustein als einen Funktionsbaustein mit Instanz aufrufen,
das heißt du hast einen Baustein den du bis zu 64 mal mit einen eigenen Instanzdatenbaustein
aufrufst. Vorteile, bei Änderungen brauchst du nur den einen FB in Augenschein nehmen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich kann die Bedenken der Bedenkenträger gut nachvollziehen.

Allerdings ist das Problem der Beeinflussung des Ablaufs durch die HMI auch an einigen anderen Stellen kritisch zu betrachten.
Rezepte können falsche Werte beinhalten ob dies nun ein Ausgang, eine Menge oder eine Position ist.
Welche Folgen dies für die Maschine hat hängt von der Maschine und dem restlichen Programm ab.
Signale aus der HMI können immer hängenbleiben. Schon mehrfach wurde mir berichtet das Leute mit hängengebliebenen
Bits zu kämpfen hatten wenn z.B. eine Taste gleichzeitig ein Bit beeinflusst hat und einen Bildwechsel ausgelöst hat usw.

In dem Konkreten Fall den ich ja nur aus den paar Zeilen im Forum kenne.
Problematisch ist die Sache mit dem Pointern oder übergeben einer Zahl die umgerechnet wird auf jeden Fall dann
wenn der Ausgang TRUE ist und der zu verwendende Pointer bzw. die Zahl sich ändert dann wird ein anderer Ausgang TRUE
aber wer setzt den alten Ausgang zurück? Ein Zuweisung mit "=" würde da nicht helfen da die Adresse eine andere ist.

ich kenne den Aufbau der Maschine oder Anlage ja nicht aber anstatt auf die Ebene der einzelnen Ausgänge zu gehen
könnte man die Dosiereinheit via Leittechnik aktiv bzw. inaktiv schalten. Hier wäre die Sache mit den FBs und den IDBs der leichtere Weg.
 
Du kannst doch deinen Baustein als einen Funktionsbaustein mit Instanz aufrufen,
das heißt du hast einen Baustein den du bis zu 64 mal mit einen eigenen Instanzdatenbaustein
aufrufst. Vorteile, bei Änderungen brauchst du nur den einen FB in Augenschein nehmen.

Danke für den Hinweis, dass hab ich noch nicht gemacht. Wieder was neues :) Bin noch frisch in Step7. Das Ganze ist auch noch in den Kinderschuhen und ich betreibe Grundlagenfoschung. Die Dosierung komplett über die Leitebene zu machen scheidet aus, da wir sonst zu viel Verzögerung beim Abschalten hätten.
Ich hab jedenfalls ein paar neue Ideen und werde am Montag ein wenig testen. In jedem Fall schon einmal ein herzliches Dankeschön an alle bisher Beteiligten, und einen schönen Sonnigen Sonntag!
 
Wie ist den bei dir Antriebstechnik für Dossierungen und die Peripherie aufgebaut.
Für eine Modularen Ausfbau sind Regler mit Profibus Anschluss und das Dezentrale
Peripherie System ET200s gut, weil dann einzelne Teilnehmer und Baugruppen, beim
Systemstart oder auch während der Laufzeit kontrolliert Aktiviert bzw. Deaktiviert
werden können.
 
Zurück
Oben