TIA Sensoranbindung Variabel

[dweber283]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

wir haben einen neuen Kunden für den ich die erste Anlage programmieren darf.
Dieser hat nun einen Wunsch geäußert, den wir vorher so noch nie umgesetzt haben. Ich hätte schon eine Lösung für die Umsetzung, allerdings wäre diese eher kompliziert. Will diese jetzt hier auch nicht verraten, da ich niemanden bei seinen Gedankengängen beeinträchtigen möchte.

Der Kunde möchte, dass er einen Sensor mal auf Eingang E0.0 und mal auf Eingang E0.1 zum Beispiel anschließen kann. Über dies Visu soll dies dann angegeben werden wo der Sensor angeschlossen ist. Natürlich handelt es sich um mehrere Sensoren und mehrere Eingänge.

Hat einer von euch so etwas schonmal umgesetzt und eine unkomplizierte Lösung für mich?

Eingesetzt wird eine S7-1515 mit TIA V17.

Vielen Dank für euer Hilfe.

Gruß Dennis

 

[Ing_Lupo]

Hallo

Pointer auf PAE zusammenstellen.

Sollte in Tia auch gehen.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

                                   +-----+
"HMI-DB".Settings.Enable_Sensor_1--|  &  |
                                   |     |    +-----+
                            %E0.0--|     |----| >=1 |
                                   +-----+    |     |
                                              |     |
                                   +-----+    |     |
"HMI-DB".Settings.Enable_Sensor_2--|  &  |    |     |  "Sensor_Func_A"
                                   |     |    |     |    +-----+
                            %E0.1--|     |----|     |----|  =  |
                                   +-----+    +-----+    +-----+

Oder im HMI ein Auswahlfeld mit einer symbolischen Liste

"Sensor Func A" ist angeschlossen an: |  --  |v|
                                      | E0.0 |
                                      | E0.1 |
                                      | E1.3 |
                                      | E2.7 |

                                 +----+
"HMI-DB".Settings.Source_Func_A--| == |
                                 |    |       +-----+
                              1--|    |-------|  &  |
                                 +----+       |     |    +-----+
                                       %E0.0--|     |----| >=1 |
                                              +-----+    |     |
                                 +----+                  |     |
"HMI-DB".Settings.Source_Func_A--| == |                  |     |
                                 |    |       +-----+    |     |
                              2--|    |-------|  &  |    |     |
                                 +----+       |     |    |     |
                                       %E0.1--|     |----|     |
                                              +-----+    |     |
                                 +----+                  |     |
"HMI-DB".Settings.Source_Func_A--| == |                  |     |
                                 |    |       +-----+    |     |
                              3--|    |-------|  &  |    |     |
                                 +----+       |     |    |     |
                                       %E1.3--|     |----|     |
                                              +-----+    |     |
                                                ...        ...
                                                         |     |  "Sensor_Func_A"
                                                         |     |    +-----+
                                                         |     |----|  =  |
                                                         +-----+    +-----+

Harald

 

[TP-Inc]

Der Sinn mal dahingestellt… wer wird das den im E-Plan nachziehen? Da sucht sich der nächste beim Fehlersuchen dämlich…

Wenns schon sein muss würd ich einen Baustein machen der alle möglichen Eingänge symbolisch bekommt (irgendwie muss man dass ja eingrenzen) und dann eine Art Tabelle machen, die den Namen, die BMK und die Adresse des Sensors enthält. Name soll ja fix sein nehm ich an. Danach mit den Adressspalten der Tabelle den richtigen Eingang raussuchen und verschalten.

 

[dweber283]

Hi TP-inc,

über die Sinnhaftigkeit sei mal ganz weit nach hinten gestellt.
Natürlich sind die Namen nicht fix. Der Kunde möchte quasi über das HMI neue Sensoren einfügen können. Bitte auch hier die SInnhaftigkeit nicht hinterfragen.

@PN/DP so wie dein ersten Vorschlag hatte ich es mir auch vorgestellt. finde dies eben nur sehr aufwendig für 20 Variablen oder mehr

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

@PN/DP so wie dein ersten Vorschlag hatte ich es mir auch vorgestellt. finde dies eben nur sehr aufwendig für 20 Variablen oder mehr

Tja, das ist halt unser Job, sowas leicht verständlich/nachvollziehbar auszuprogrammieren. Gerade Zugriffe auf E/A müssen auch für andere Programmierer leicht nachvollziehbar sein. Bei vielen größeren Kunden sind indirekte Zugriffe auf E/A auch explizit verboten, weil schlecht nachvollziehbar und gaaanz schlecht umverdrahtbar. Bei einem Defekt einzelner E/A soll es oft ohne SPS-Baugruppentausch und ohne CPU-STOP schnell möglich sein, auf einen anderen freien E/A umzuverdrahten.

Ich habe solche Umverdrahtungen per HMI öfters bei pneumatischen Multiventilinseln an Feldbus (z.B. Profibus). Da kann man bei Defekt einer Ventilscheibe oft nicht einfach den Prozess anhalten, um die defekte Ventilscheibe auszutauschen oder einen Programmierer holen der das Umverdrahten im Programm macht. Da sind dann in jeder Ventilinsel z.B. 2 Ventilscheiben jeder Art als Reserve schon eingebaut, und im HMI kann man per symbolischer Eingabefelder für jedes Reserve-Ventil einzeln auswählen, welche Ventilfunktion der anderen Ventile der Ventilinsel es übernehmen soll. Oder im Extremfall für jede Ventilscheibe auswählen, welche Funktion sie übernehmen soll, oder für jede Funktion festlegen, an welcher Ventilscheibe sie angeschlossen ist. Dann braucht man im Defektfall nur die ein/zwei Luftschläuche umstecken und im HMI die Funktion einstellen und weiter geht es. Die Ventilinsel reparieren oder austauschen kann man dann später.

Harald

 

[TP-Inc]

Hi TP-inc,

über die Sinnhaftigkeit sei mal ganz weit nach hinten gestellt.
Natürlich sind die Namen nicht fix. Der Kunde möchte quasi über das HMI neue Sensoren einfügen können. Bitte auch hier die SInnhaftigkeit nicht hinterfragen.

@PN/DP so wie dein ersten Vorschlag hatte ich es mir auch vorgestellt. finde dies eben nur sehr aufwendig für 20 Variablen oder mehr

Und was sollen die neuen Sensoren im Programm tun? Der soll einfach einen PC mit TIA zur Anlage stellen…

 

[TP-Inc]

Tja, das ist halt unser Job, sowas leicht verständlich/nachvollziehbar auszuprogrammieren. Gerade Zugriffe auf E/A müssen auch für andere Programmierer leicht nachvollziehbar sein. Bei vielen größeren Kunden sind indirekte Zugriffe auf E/A auch explizit verboten, weil schlecht nachvollziehbar und gaaanz schlecht umverdrahtbar. Bei einem Defekt einzelner E/A soll es oft ohne SPS-Baugruppentausch und ohne CPU-STOP schnell möglich sein, auf einen anderen freien E/A umzuverdrahten.

Ich habe solche Umverdrahtungen per HMI öfters bei pneumatischen Multiventilinseln an Feldbus (z.B. Profibus). Da kann man bei Defekt einer Ventilscheibe oft nicht einfach den Prozess anhalten, um die defekte Ventilscheibe auszutauschen oder einen Programmierer holen der das Umverdrahten im Programm macht. Da sind dann in jeder Ventilinsel z.B. 2 Ventilscheiben jeder Art als Reserve schon eingebaut, und im HMI kann man per symbolischer Eingabefelder für jedes Reserve-Ventil einzeln auswählen, welche Ventilfunktion der anderen Ventile der Ventilinsel es übernehmen soll. Oder im Extremfall für jede Ventilscheibe auswählen, welche Funktion sie übernehmen soll, oder für jede Funktion festlegen, an welcher Ventilscheibe sie angeschlossen ist. Dann braucht man im Defektfall nur die ein/zwei Luftschläuche umstecken und im HMI die Funktion einstellen und weiter geht es. Die Ventilinsel reparieren oder austauschen kann man dann später.

Harald

Das ist ja unnötig hoher Aufwand für eine Situation die vielleicht nie eintritt und mit einem PG sofort behoben ist.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist ja unnötig hoher Aufwand für eine Situation die vielleicht nie eintritt und mit einem PG sofort behoben ist.

Tja, wenn die Produkion steht und pro Stunde einen vier- bis fünfstelligen Betrag kostet und das Produkt vielleicht verdirbt, und auf einen Programmierer gewartet werden muß, der vielleicht erst noch das Programm analysieren muß, dann relativiert sich das "unnötig hoher Aufwand" sehr schnell.
Bei uns passiert so ein Ausfall einer Ventilscheibe oder der Elektronik des Kanals etwa einmal in 2 Jahren.

Harald

 

[PN/DP]

Und was sollen die neuen Sensoren im Programm tun? Der soll einfach einen PC mit TIA zur Anlage stellen…

Es könnte z.B. eine Lichtschranke, Endschalter oder Produktzähler oder ähnliches sein an einem Transportsystem in einer Halle, wo die Transportbänder zum Füllen der Halle verschieden zusammengestellt werden (z.B. erst lang bis in die hinterste Ecke und dann immer kürzer), und in der Halle sind mehrere dezentrale IO-Stationen verteilt, wo der Sensor mal hier und mal da angesteckt wird, und trotzdem immer die selbe Funktion hat. Oder manche Teilbänder sind mit Lichtschranke am Ende und manche ohne. Warum sollte man da jedesmal die Anlage umprogrammieren?

Harald

 

[Onkel Dagobert]

Man kann doch unmöglich gegen jeden Ausfall eines Bauteils derartige Maßnahmen konstruieren? In absoluten Ausnahmefällen, wo fortlaufend ein spezielles Teil ausfällt, welches auch nicht durch ein langlebigeres ersetzt werden kann, würde ich es vielleicht gelten lassen. Aber eine Lichtschranke, ein Endschalter oder ein Produktzähler? Was veranstaltet man dann mit dem Rest der Anlage, wie Zahnriemen, Antriebe, Zylinder etc?

Aber um die Sinnhaftigkeit geht es ja ausdrücklich nicht, ist aber dennoch interessant.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Man kann doch unmöglich gegen jeden Ausfall eines Bauteils derartige Maßnahmen konstruieren? (...)
Aber eine Lichtschranke, ein Endschalter oder ein Produktzähler?

In meinem Beispiel fallen die Teile nicht aus, sondern wenn alles gut geht, wird alle Stunde die Anlage umgebaut (die Transportbänder umgestellt).

Harald

 

[AndSor]

Zurück zur eigentlichen Frage, ich habe sowas schonmal gebaut (potentialfreier Kontaktaustausch zu anderen Anlagen).
Alle Eingänge in einen DB (am besten in ein Array) schreiben und mit einer "Übersetzungstabelle" (individuell am HMI konfigurierbar) in einen zweiten DB übergeben. Von dort können die Variablen im Programm verwendet werden.
ABER wie Harald schon schrieb ist das alles andere als "verständlich/nachvollziehbar".

 

[Holzmichl]

Ich würde es eher so machen, einen FC als Multiplexer zu erstellen.
Als Input die 20 Eingänge und einen Integer als Verweis. Der Output des FC ist dann dein variables Signal. Der Integer die Eingabe vom HMI. Für den Integer eine eigene Textliste erstellen und per Auswahlliste zuweisen.
Den Baustein dann 20x kopieren in jeweils eigene Netzwerke.
Dann bleibt das auch schon übersichtlich und nachvollziehbar. Und die Querverweisliste kann ein späterer Programmierer auch (sinnvoll) nutzen.
Aber so wenig Logik wie möglich in den Baustein.