easy-forum
Deutsch - Software => easySoft => Thema gestartet von: Juergen__R am Juni 26, 2021, 13:28:50 Nachmittag
-
Was besagt die Anzeige Schreibkonflikt (rot)?
Hierzu gibt es keine Hilfetexte.
Schöne Grüße, Jürgen
-
Hallo Jürgen,
wenn man im Programm z.B. den Merker M5 setzt und irgendwo im Programm einen Wert auf das MB1 schreibt, gäbe es einen Schreibkonflikt, da M5 Teil von MB1 ist.
Es hilft bei der Programmierung Fehler zu finden.
Gruß Ralf
-
Hallo Ralf,
danke für die schnelle Info!
Schöne Grüße aus Martfeld, dicht am Mittelpunkt Niedersachsen´s,
Jürgen
-
Kann jemand mir bitte erklären die Frage mit Schreibkonflikt
Ein Musterprogramm, nur für Darstellung
IF M7 THEN
M2 := TRUE;
END_IF;
If NOT M7 THEN
M2 := FALSE;
END_IF;
Ganz einfach. Wenn ich gucke jetzt in Merkerbereichsbelegung, dann sehe ich M2 in Rot (Schreibkonflikt). Obwohl man kann ganz genau sehen, dass M2 wird nicht zweimal geschrieben, sondern nur einmal.
Ich probiere schon mehrmals, aber Ergebnis ist gleich - wenn Merker wird in Programme zweimal oder mehr geschrieben - dann wird unbedingt in Merkerbereichsbelegung Schreibkonflikt gezeigt werden. Obwohl es ist nicht Fehler unbedingt, in Programme kann man in einem Zyklus 2-3 oder mehr in einem Merker schreiben ohne Problem.
Jetzt aber fand ich ein alter Projekt, wo wird ein Merker zweimal geschrieben und gelesen, aber in Merkerbereichsbelegung wird es als gelb (Lesen / Schreiben), aber nicht als rot (Schreibkonflikt) gezeigt. Da gibt es kein JMP oder EXIT, jede Netzwerk wird bearbeitet werden.
Und ich verstehe nicht, wie könnte es sein, kann jemand mir bitte erklären?
Wie kann man Merker zwei oder mehr Mals schreiben und dabei kein Schreibkonflikt in Merkerbereichsbelegung bekommen?
-
Da die Auswertung nicht die Logik sondern nur die Tatsache der der mehrfachen Zuweisung prüft, ist die Meldung korrekt.
Aber schreib doch einfach:
M2 := M7;Ist auch kürzer ;)
-
Na, es war nur Beispiel mit ST. Und die Frage mit Schreibkonflikt bleibt. Und verstehe gar nicht, wie kann man Merker zweimal benutzen und danach kein Schreibkonflikt in Merkerbereichbelegung bekommen.
Update: Ich denke, ich fand die Ursache. Das hängt von Programmversion.
In EasySoft 7.31 - kommt kein Schreibkonflikt.
In EasySoft 8.0 - kommt Schreibkonflikt.
-
Hallo ssyn,
der Compiler reagiert meiner Meinung nach richtig.
Denn dein Beispiel enthält zwei separate IF-Anweisungen. Die könnten im Programm auch weit auseinander platziert sein.
Anweisung 1:
IF M7 THEN
M2 := TRUE;
END_IF;
Anweisung 2:
If NOT M7 THEN
M2 := FALSE;
END_IF;
Hier wird der Merker auch mehrfach zugewiesen, aber in einer Anweisung. Deshalb meckert der Compiler nicht.
IF M7 THEN
M2 := TRUE;
ELSE
M2 := FALSE;
END_IF;
-
Ich habe auch danach gedacht und geprüft, auch mit ..IF ...ELSE und auch mit CASE, aber in neue Versionen kommt IMMER Schreibkonflikt (siehe Bild).
Ich denke die einzige richtige Meldung über Schreibkonflikt wäre es, wenn man versucht gleichzeitig in einen Merker schreiben will (z.B. in einem Netzwerk in FUP oder KOP).
Okay, wahrscheinlich es ist gar nicht wichtig, nur zur Information.
-
Hall Sayn,
bei deinem Beispiel in FUP ist die Meldung aus meiner Sicht vollkommen korrekt.
M1 wird nur gesetzt werden, wenn die Bedingung in Netzwerk 2 erfüllt ist.
Was vorher in Netzwerk 1 passiert hat keinen Einfluss. Es gewinnt immer der letzte
Schreibzugriff auf den Merker.
Gruß Ralf
-
Hier wird der Merker auch mehrfach zugewiesen, aber in einer Anweisung. Deshalb meckert der Compiler nicht.
IF M7 THEN
M2 := TRUE;
ELSE
M2 := FALSE;
END_IF;
Habe ich in easySoft 8.00 getestet; meckert auch ;)
-
Was vorher in Netzwerk 1 passiert hat keinen Einfluss. Es gewinnt immer der letzte
Schreibzugriff auf den Merker.
Ja, ich verstehe es ganz gut und stimme vollständig zu.
Ich mache ähnliche Programm in Codesys und habe keine Fehler bekommen (Bild in Beilage).
Meine Meinung war, dass Schreibkonflikt in Merkerbereichsbelegung in neue EasySoft Versionen falsch reagiert. Drauf möchte ich beweisen und nichts mehr.
-
... aus meiner bescheiden Sicht sollte jedes mehrfach schreiben auf Ausgänge/Merker aufgezeigt werden, egal ob direkt oder über Funktionen da der Compiler (sofern einer dahintersteckt?!?) den tieferen Sinn des Programmes nicht auswerten kann. Stichwort: Bitmanipulation
Eventuell sollte die Meldung nur auf eine "Mehrfachzuweisung" hinweisen und nicht unbedingt "Konflikt" benannt werden ...