Datenbaustein mit Tri-State Ausgang

[FPH]

Hallo Forum,
da ich mehr als 32 Datenbausteine benötige, habe ich mir einen Anwenderbaustein erstellt. Leider blockiert der Ausgang mein Merkerwort, obwohl die Bausteine nicht aktiviert sind (EN).
Mit den Datenbausteinen kann ich das Merkerwort in der Tabelle händisch überschreiben, voraus gesetzt die Datenbausteine sind nicht aktiviert (EN).
Dieses Merkerwort soll auch via Modbus bzw. Touch Panel überschrieben werden.
Wie kann ich den Ausgang vom Anwenderbaustein erstellen, ohne das der Ausgang bei deaktivierten EN das Merkerwort überschreibt?

[Eulhofer]

Hallo FPH,

ich weiß nicht, ob ich hilfreich sein kann, da ich die Fragestellung schon nicht ganz nachvollziehen kann.

Also du hast alle 32 Datenbausteine im Programm eingesetzt und die werden aber nur bei Bedarf durch ihren jeweiligen EN aktiviert?
Zusätzlich hast du identisch arbeitende UFs geschrieben/im Einsatz?

Leider blockiert der Ausgang mein Merkerwort, obwohl die Bausteine nicht aktiviert sind (EN

Wessen Ausgang?
Wessen/welches Merkerwort?
Welche Bausteine sind nicht aktiv?

Und überschreiben jetzt ALLE DBs und auch Dein UF ein und dasselbe MW?

Mit den Datenbausteinen kann ich das Merkerwort in der Tabelle händisch überschreiben

Also mit den Hersteller-DBs?
Welches Merkerwort?
In welcher Tabelle?

voraus gesetzt die Datenbausteine sind nicht aktiviert (EN)

Auch hier sprichst du von den Hersteller-DBs?

[Juergen]

Hallo,
ich habe es selber mit einem UF Baustein versucht.
Ich komme auf das gleiche Ergebnis, das es mit einem DB im UF  so nicht geht.
Das verhalten ist anders als, wenn der DB im Hauptprogramm ist.

Noch nicht mit Hardware geprüft

[FPH]

Vielen Dank für die schnelle Antworten. Ich habe noch mal nach gedacht, und festgestellt, das ich einen UF mit Tri-State-Ausgang benötige. Der Datenbaustein (DB01 ... DB32) hat ja einen Tri-State-Ausgang und beschreibt somit bei deaktivierten DB (EN = low) nicht das Merkerwort.

[FPH]

Nachtrag
Als Notlösung plane ich einen UF mit 3 DB´s und werde diese auf einen originalen DB an den Eingang legen. So kann ich 3 verschiedene Analogsignale mit Auswahl des EN in ein Merkerwort schreiben.

[CiesleRa]

Hallo FPH,

die DB's sind so programmiert, das sie nur für einen Zyklus aktiv sind. Nämlich dann, wenn der Triggereingang aktiv ist. Das gilt aber nicht für einen Anwenderfunktionsbaustein (AFB) im Hauptprogramm. Somit ist der Wert am Ausgang des AFB's sozusagen festgeschrieben.

Abhilfe für dein Problem ist, wenn ich es denn richtig verstanden habe, dass der AFB nach erfolgter Triggerung übersprungen wird.
Ich habe mal zwei Bilder angehängt, die zeigen sollen wie ich das meine. Kannst Du ja mal ausprobieren um zu sehen, ob es die Funktion ist, die Du haben möchtest.
Ansonsten könnte ich mir vorstellen, dass auch der MX-Datenmultiplexer dein Problem lösen könnte.

Gruß Ralf       

[FPH]

Hallo CiesleRa,

danke für Deine Antwort, aber leider benötige ich einen Tri-State-Ausgang, um nicht das MW zu überschreiben. Der Trick mit dem nachfolgenden DB (siehe Anhang) funktioniert. Sobald ich die Funktion nicht mehr benötige, wird das MW13 nicht mehr beschrieben, und kann mit dem TouchPanel via ModBus beschrieben werden. Die Funktion beziehungsweise Funktionen sind leider dazu gekommen, sonnst hätte ich von Anfang an alles anders gemacht.

[CiesleRa]

Hallo FPH,

ich glaube nicht, dass Du auf dem richtige Weg bist, aber das mag auch daran liegen, dass ich nicht genau verstehe, was Du da machst.
Der "EN" Eingang ist eigentlich im Normalfall nicht dazu da, den Wert von I1 auf das Merkerwort zu schreiben. Dazu dient eigentlich der Triggereingang "T_".
Wenn Du den Triggereingang mit einem Triggersignal (steigende Flanke), beschaltest und damit den Wert von I1 auf das MW13 schreibst, kannst Du danach das MW13 auch über Modbus neu beschreiben. 

Gruß Ralf

[Juergen]

 Hallo Ralf,

ich habe es versucht Online die Werte zu ändern.
Das geht mit einem Datenbaustein im Hauptprogramm. Mit einem Datenbaustein im UF nicht mehr

[CiesleRa]

Hallo Jürgen,

im UF selber, verhält sich der DB genauso wie im Hauptprogramm. Nur ist es im
Hauptprogramm nicht der DB, der auf das Merkerwort schreibt, sondern der UF. Und der
verhält sich anders. Daher muss man nach dem Triggern den UF überspringen um die
gleiche Funktionalität wie ein DB zu bekommen. Wenn Du mein kleines Beispiel nach programmierst, wirst Du sehen, dass es dann wieder möglich ist das MW an anderer Stelle neu zu beschreiben.

Gruß Ralf

[Juergen]

Hallo Ralf,
hatte deine Bilder beim Lesen übersehen. War dabei wohl nicht Angemeldet.
Es sollte so gehen.
Leider hatte ich eine Lösung mit mehreren DBs in einem UF. Da geht es dann nicht mehr oder nur umständlich.
Der von dir Vorgeschlagene MX-Datenmultiplexer könnte eine elegante Lösung sein.

[Eulhofer]

 

aber das mag auch daran liegen, dass ich nicht genau verstehe, was Du da machst.
Der "EN" Eingang ist eigentlich im Normalfall nicht dazu da, den Wert von I1 auf das Merkerwort zu schreiben. Dazu dient eigentlich der Triggereingang "T_".
Wenn Du den Triggereingang mit einem Triggersignal (steigende Flanke), beschaltest und damit den Wert von I1 auf das MW13 schreibst, kannst Du danach das MW13 auch über Modbus neu beschreiben.

Da bin ich ja froh, dass ich nicht ganz alleine damit war/bin.

Zumindest hat mir das Ändern des Themas auf "Tri-State-Ausgang" bzw. der Hinweis darauf geholfen, worum es prinzipiell geht.

Beim Herumprobieren ist mir aufgefallen, dass der DBxx-Baustein als Parameter auch das Abschalten der Flankenauswertung an T_ bietet (vielleicht erst seit letztem Update?) und damit auch bei Aktivierung/Deaktivierung mittels EN wie erwartet arbeitet (ich habe es nicht geschafft in der Simulation eine Flanke an T_ zu erreichen).

Das ganze Thema hat mir nun geholfen die Funktionsweise besser zu verstehen/untersuchen.

Ich hatte vor einiger Zeit schon einmal gefragt, wie ich eine Wertzuweisung in Abhängigkeit von einem boolschen True-Ergebnis realisieren kann, ohne dass der bestehende Wert bei "False" verändert wird.  Da bin ich jetzt schlauer - und brauche meinen selbstgeschriebenen UF dafür gar nicht mehr...