Wie funktioniert "forced" in PRG?

ssyn

Level-2
Beiträge
141
Reaktionspunkte
14
Ich habe ganz dumme Frage, aber - wie eigentlich funktioniert forced in SCL/ST/FUP usw.

Ich habe eine Beispiel gemacht (Bild in Beilage)

So,
1. var2 = var1
2. var3 = var2

Wenn var1 = 22, dann var2 = 22 und dann var3 = 22.
Wenn ich force var2 zu 55, dann wird var2 = 55, aber var3 = wird doch 22

3. Und wenn ich var2 + var4 = var5 - dann sehe ich 55 + 5 = 60 (aus Ausgang von Baustein ADD), aber in var5 kommt doch Wert 27 (22 + 5)

Ich verstehe nix, in welche Fälle kann ich überhaupt Forced benutzen. Wenn es niergendo in PRG geschrieben - kann ich einfach schreiben, wenn doch irgendwo es geschreiben, dann bringt "forced" überhaupt nix? Oder ich verstehe es falsch.

Ich möchte manche Werte in einen Projekt forced, damit fehlende Daten und Sensoren ersetzen können.
 

Anhänge

  • forced2.jpg
    47,7 KB · Aufrufe: 26
Variablen zu forcen ist für mich nur ein Notfallhammer.. wenn Variablen gewisse statische Werte benötigen, dann weiße ich diese zu.
 
Und das Programm wird auch wirklich abgearbeitet?

Ja, wirklich. Programm läuft, ich kann andere Werte in var1 oder var4 eingeben und sehe Änderungen. Codesys V3.5.
Z.B. neue Bild
 

Anhänge

  • forced3.jpg
    64,8 KB · Aufrufe: 12
Und das Programm wird auch wirklich abgearbeitet?

Folgendes passt ja auch nicht:
Anhang anzeigen 77227

Was ist das denn für eine Software? CoDeSys?
Das Forcen im Codesys Universum ist schon so eine Sache und da treten die unterschiedlichsten Effekte auf.
Ich habe die genaue Funktionalität samt Einschränkungen auch noch nicht wirklich ergründet.
@HausSPSler: Kannst Du hier Licht ins Dunkel bringen?
 
Variablen zu forcen ist für mich nur ein Notfallhammer.. wenn Variablen gewisse statische Werte benötigen, dann weiße ich diese zu.

Ich hab einen alten Projekt (wurde mehrere Jahre vor von anderem Kollegen erstellt) und möchte schnell nen Fehler finden, möchte nicht die Logik von jede FB verstehen, nur schnell die Ursache finden.
 
OK, es ist nur ein Darstellungsproblem. Im Handbuch steht:
Das bedeutet, bevor dein FUP-CODE abgearbeitet wird, wird VAR2 auf 55 geforced. Dann beginnt die Abarbeitung deines CODE´s und du überschreibst die VAR2 wieder mit DEZ 2.

Dann passt auch das, was (als Ergebnis )angezeigt wird.

Es ist in dem Sinne ein Darstellungsfehler.
Quelle: CoDeSys Forcen und Schreiben
 
Zuletzt bearbeitet:
Hmm, jetzt ist für mich noch sinnloser "force" zu benutzen. Okay, ich kann forced Wert in Netzwerk sehen, aber weiter geht es nicht?
 
Danke @DeltaMikeAir, genau so hätte ich das auch erwartet. Ich glaube, bei Siemens legst Du ja auch fest, wann geforct wird, am Zyklusanfang oder am Ende.
Die Programmierumgebung kann ja nur genau 1x den Wert setzen, und das nicht zufällig irgendwann im Zyklus, sondern i.d.R. sicherlich am Anfang. Wenn dann aber diese Variable im Verlauf überschrieben wird, ist das egal, ob sie geforct wurde.

Wenn Du im gesamten Programm Werte, z.B. der Eingänge, überschreiben möchtest, z.B. zum Simulieren, dann bietet es sich an, dafür einen kleinen FC vorzubereiten, über den Du die Eingänge schleust. Darin kann dann z.B. auch für analoge Eingänge die Skalierung stattfinden.
Dieser Baustein hat dann einen Eingang Test/IBN/Force oder wie immer Du ihn nennen willst. Und diesen kannst Du dann z.B. über eine globale Variable setzen. Dann wird intern statt des Eingangswertes ein Force-Wert oder Simulationswert an den Ausgang übergeben.

Das Forcen funktioniert tatsächlich nur im engen Rahmen in einigen Fällen.
 
Die Darstellungsfehler sind aber auch ordentlich, bei dem unteren ADD werden sogar zwei verschiedene Rechenergebnisse angezeigt.
Ein Ergebnis basiert auf dem Forcewert ( welcher ja nicht mehr vorhanden ist ) + 5, das andere auf dem überschriebenem Forcewert + 5

 
... Wenn dann aber diese Variable im Verlauf überschrieben wird, ist das egal, ob sie geforct wurde. ...
Das sehe ich nicht so. Wenn z.B. das "Überschreiben im Verlauf" so aussieht:
x := x + 1 ;
und das Forcen den ZählerStand vorbesetzt.
Das Forcen funktioniert tatsächlich nur im engen Rahmen in einigen Fällen.
Stimmt. Zaubern kann man damit nicht. Eigentlich siegt immer die Logik.

Hin und wieder kann man beim Programmieren ein evtl. späteres Forcen einplanen/vorbereiten, wenn man z.B. bestimmte Eingriffe für TestZwecke "bereithalten" will.
 
Das sehe ich nicht so. Wenn z.B. das "Überschreiben im Verlauf" so aussieht:
x := x + 1 ;
und das Forcen den ZählerStand vorbesetzt.
Trotzdem sagt "Force" ja von der Begrifflichkeit "Egal was, nimm diese Zahl". Du bestimmst zwar den Anfang vom Zähler, aber am Ende ist nicht mehr der geforcte Wert in der Variablen. Also egal ob über Zuweisung oder Rechenoperation: Der geforcte Wert wird überschrieben.

Hin und wieder kann man beim Programmieren ein evtl. späteres Forcen einplanen/vorbereiten, wenn man z.B. bestimmte Eingriffe für TestZwecke "bereithalten" will.
In dem "gewollten" Falle, würde ich es aber lieber offensichtlich über "IBN"-Variablen (oder Test oder Force oder Simu, je nach Geschmack) auscodieren, so daß auch jeder Nachfolger erkennt, was da getrieben wird. Und dann kann man gleich passend eine Variablentabelle dazu vorbereiten.
 
Ich glaube, bei Siemens legst Du ja auch fest, wann geforct wird, am Zyklusanfang oder am Ende.
Du meinst vermutlich eher den Trigger für Variablen steuern / beobachten.


Forcen läuft bei Siemens (teilweise) etwas anders ab. Hier mal ein Auszug aus der Step7 V5.5 Hilfe:

Achtung, gilt nur für 400ér + CPU318-2:
Unterschiede zwischen Forcen und Steuern von Variablen
  • Beim Forcen besitzt die Variable immer den geforcten Wert. Dieser Wert wird bei jedem Lesezugriff im Anwenderprogramm gelesen. Sämtliche Schreibzugriffe sind unwirksam.

Allerdings unterscheidet sich das Verhalten zwischen 300/400érn CPU´s:

Bei den normalen 300érn sieht es wieder anders aus ( nicht CPU318-2 ):


 
Zuletzt bearbeitet:
Für die Nutzung dieser Website sind Cookies erforderlich. Du musst diese akzeptieren, um die Website weiter nutzen zu können. Erfahre mehr…