TIA Negierte Zuweisung in Graph

meikelneit

Level-2
Beiträge
172
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Schönen guten Morgen,

ich versuche grade in einem Graphschritt eine Negierte zuweisung, und bekomme da einen Fehler den ich nicht verstehe.

Ich würde gerne folgendes tun:

N Bit1 := NOT Bit2

aber dann markiert er mir das Bit2 immer rot. Jemand eine Ahnung?

Als Fehlerhinweis kommt: Struct ( erwartet. Aber auch wenn ich Bit2 in Klammern setzte bleibt es rot.

PS: Ich vermute man kann in Graphschritten keine Bools mit := Zuweisen, da wird einfach ein anderer Datentyp erwartet.
 
Zuletzt bearbeitet:
Das habe ich auch schon 1000 Mal gesucht.
Mein Ergebnis: Geht nicht und gibt es nicht.
Vielleicht könnte man einen kleinen Mini-FC bauen der negiert und diesen dann in der Action aufrufen.

PS: wäre ja schön, wenn mich da jemand eines Besseren belehrt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin,

Das habe ich auch schon 1000 Mal gesucht.
Mein Ergebnis: Geht nicht und gibt es nicht.
Vielleicht könnte man einen kleinen Mini-FC bauen der negiert und diesen dann in der Action aufrufen.

Das musste ich leider auch schon feststellen. Ich habe das auch mit einem Bausteinaufruf ("mini-FC" (verbraucht der weniger Speicher? :cool:)) gelöst.

VG

MFreiberger
 
Hallo Ralle,

Erklär mal, wo wird da das Bit negiert? (Hab keine Ahnung von den Interlocks :-) )

Das Bit wird in der Verriegelungsbedingung (Interlock) negiert.

Bei der Aktion sorgt das C in der Spalte Interlock dafür, das die Schrittzeile nur ausgeführt wird, wenn die Verriegelungsbedingung erfüllt ist.

Für meikelneit Problem (5 Unterscheidungen) besteht die Möglichkeit 5 Schritte parallel mit jeweils einer eigenen Verriegelungsbedingung anzulegen. Dann braucht man keinen FC und sieht alle Verriegelungen innerhalb der Schrittkette.

neg_Zuweisung_01.jpgneg_Zuweisung_02.jpg
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Ralle,



Das Bit wird in der Verriegelungsbedingung (Interlock) negiert.

Bei der Aktion sorgt das C in der Spalte Interlock dafür, das die Schrittzeile nur ausgeführt wird, wenn die Verriegelungsbedingung erfüllt ist.

Für meikelneit Problem (5 Unterscheidungen) besteht die Möglichkeit 5 Schritte parallel mit jeweils einer eigenen Verriegelungsbedingung anzulegen. Dann braucht man keinen FC und sieht alle Verriegelungen innerhalb der Schrittkette.

Anhang anzeigen 50252Anhang anzeigen 50253

Ja ok, das ist klar, aber das hat doch nicht wirklich etws mit dem Negieren des Bits in einer Action zu tun.
 
In Graph ist nur eine Operation je Zeile zulässig.

Für alles was nicht Bool ist gilt also EINE Rechenoperation je Zeile!

Für Bool ist die Zusweisung eines anderen Boolwertes bereits eine Operation.

Aber warum so kompliziert... Leg eine zusätzliche Variable an und weise dieser im "OB1" den gewünschten Zustand zu: "my_neg_Input" := not "my_input"
Im Graph dann einfach zuweisen...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja ok, das ist klar, aber das hat doch nicht wirklich etws mit dem Negieren des Bits in einer Action zu tun.

das Ergebnis ist aber das selbe

mal in Textform:

wenn Bit2 = 0 dann wird Bit1 im Schritt gesetzt
wenn Bit2 = 1 dann wird Bit1 im Schritt nicht gesetzt

neg_Zuweisung.jpg

Dann ist die Negierung zwar nicht in einer Aktion, aber in einem Schritt.

Wie schon gesagt, der Sinn ist, dass man alles in einem Baustein (ja sogar in einem Schritt) hat.

Es gibt immer mehrere Wege, die zum Ziel führen - für dieses Thema z.B.
  • Negierung mit Interlock
  • Negierung in den voraus- (nach) geschalteten Anweisungen
  • Negierung in einem anderen Baustein.
 
Ja korrekt: führt alles zum selben Ergebnis!

Nur noch eine kleine Anmerkung:
mal in Textform:

wenn Bit2 = 0 dann wird Bit1 im Schritt gesetzt
wenn Bit2 = 1 dann wird Bit1 im Schritt nicht gesetzt

Ein Bit nicht "setzen" bedeutet eigendlich KEINE Zuweisung zu machen...

Eindeutiger währe hier:

wenn Bit2 = 0 dann wird Bit1 im Schritt 1
wenn Bit2 = 1 dann wird Bit1 im Schritt 0
 
Ja korrekt: führt alles zum selben Ergebnis!

Nur noch eine kleine Anmerkung:


Ein Bit nicht "setzen" bedeutet eigendlich KEINE Zuweisung zu machen...

Eindeutiger währe hier:

wenn Bit2 = 0 dann wird Bit1 im Schritt 1
wenn Bit2 = 1 dann wird Bit1 im Schritt 0


da hast du natürlich recht

Gruß aus Mondorf nach Köln
 
Aber ds sind alles Krücken für eine einfache Geschichte.

kleines konstruiertes Beispiel:

Man hat eine Prüfung, die besagt, das Teil ist IO mit True. In den Teiledaten hat man 2 Bit IO und NIO. Der Kunde will das getrennt.
Nun möchte man nach Prüfende die Prüfung auswerten und in der Auswertung die beiden Bits setzen bzw. rücksetzen.

Also in der Action des Schrittes bei Transaktion Prüfende, bei Verlassen des Schrittes einfach:

TeilX_IO := Prüfung.IO;
TeilX_NIO := NOT TeilX_IO;

Sowas geht nur mit irgendwelchen um den Hintern herumhantierten Konstrukten.
Vor- und Nachgelagerte Anweisungsteile, OB1, alles ok, aber in 5 Jahren suche ich oder ein Kollege uns einen Wolf, wo das 2. Bit denn umgedreht wird, das ist unschön gelöst.
Dann lieber ein FC.

In meinem Bsipiel kann man auch 2 Schritte als Alternativverzwigung programmieren:

wenn IO --> Transaktion in Schritt X IO-Bit setzen
Wen nicht IO --> Transaktion in Schritt X1 --> NIO-Bit setzen, IO-Bit Rücksitzen

Ich glaube in Codesys geht das ganz locker in einer Action, Siemens kanns wieder mal nicht. Ein einfaches NOT wäre durchaus machbar, aber dann müßte man mit seinem eigenen Mülll auch mal selbst etwas programmieren und zum Laufen bringen.

PS: zum OB1
@NBerger

Dann hast du bei Maschinen mit 20+ Stationen irgendwo eine Latte von solchen negierten Bits, das ist nicht wirklich schön.
 
Dann hast du bei Maschinen mit 20+ Stationen irgendwo eine Latte von solchen negierten Bits, das ist nicht wirklich schön.

Ich persönlich würde sowas auch garnicht erst anfangen. Negative Logik gehört ebensowenig in die Industrieautomatisierung wie NPN-Sensoren.

Ein Teilestatus gehört absolut nicht in eine Schrittkette, das gehört zentral in einen FC/FB und zwar betriebarten unabhängig!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich persönlich würde sowas auch garnicht erst anfangen. Negative Logik gehört ebensowenig in die Industrieautomatisierung wie NPN-Sensoren.

Ein Teilestatus gehört absolut nicht in eine Schrittkette, das gehört zentral in einen FC/FB und zwar betriebarten unabhängig!
Nachdem Du mich mit #11 so schön auf's Gleis gesetzt hast, fühle ich mich jetzt wieder "abgehängt".

- Keine "negative Logik" in der Industrieautomatisierung"? Wenn der Name einer BOOL-Variablen zu ihrer Bedeutung passt (und nicht hier ein Verdreher der Logik versteckt ist), wie kommen wir denn hier auf das Thema "negative Logik"?

- "Ein Teilestatus gehört nicht in eine Schrittkette"? Ich kann mir sehr gut vorstellen, dass ein Teilestatus in einer Schrittkette abgefragt wird und auch, dass ein erfolgter Schrittwechsel einen Teilestatus ändern soll bzw. muss. Ob nun an Ort und Stelle in der Schrittkette selbst oder durch Umschaufeln der entsprechenden Information an eine "zentrale Verwaltung", das würde ich nicht so kategorisch ablehnen oder befürworten wollen. Wahrscheinlich habe ich zu oft mit Schrittketten zu tun gehabt, die keine Betriebsart kannten, weil sie keine Mechanik bewegt haben, sondern nur Abfolgen von DatenVerwurstungen organisieren mussten.

- War das Thema nicht, wie man in Graph ein Bit negieren kann? Ganz unabhängig von seiner Bedeutung? Das Beispiel mit IO und NIO hat wohl irgendwie die Assoziation mit einem Teilestatus in den Vordergrund gerückt?
 
Ich persönlich würde sowas auch garnicht erst anfangen. Negative Logik gehört ebensowenig in die Industrieautomatisierung wie NPN-Sensoren.

Ein Teilestatus gehört absolut nicht in eine Schrittkette, das gehört zentral in einen FC/FB und zwar betriebarten unabhängig!


Aha, na da lerne ich gerne mal was.
Wer spricht von negativer Logik, die hattest das vorgeschlagen.
Der extra FC ist wozu genau unabdingbar?
Warum eigentich betriebsartenabhängig, was hat der Teilestatus mit der Betriebsart zu schaffen? Bei mit jedenfalls gar nichts und die Anlagen laufen korrekt. Das mach ich sicher was falsch.

PS: Der Teilestatus war nur ein schnelles Beispiel, mit dem sicher einige zu tun haben.
 
Zurück
Oben