Step 7 Fehler beim Laden eines FC Laden (294:6)

[SPS-EK]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo liebe Forengemeinde,

ich bin neu hier und muss mich bei Gelegenheit mal vorstellen. Derzeitig beschäftigt mich das folgende Problem:

Ich kann eine Funktion FC10 nicht in die CPU laden.

Fehlermeldungen: Laden (33:53888) und Laden (294:6)

Anhand von dem Hilfetext habe ich schonmal veruscht ein paar Fehler auszugrenzen, jedoch ohne Erfolg.
Die Speichernutzung hält sich in Grenzen: Lokaldaten: 32 Bytes

MC7: 486 Bytes
​

Ladespeicherbedarf: 706 Bytes
​

Arbeitsspeicherbedarf: 522 Bytes​

Auch ist der Baustein nicht schreibgeschützt und hat keinen Know-How-Schutz.
Ebenso sind nur Standardfunktionen verwendet, wie MOVE und ein paar Timer(T250 und T251).
Die Übergabemerker IN und OUT bzw. deren Werte kopiere ich mit MOVE auf einzelne Tempvariablen die in einer Struktur angelegt sind.
Z.B.: IN_WERT auf HM.WERT
Könnte das das Problem sein?


Die CPU ist eine 314C-2PN/DP mit einer 128kB MMC.
MMC: 128 kB
Version: Hardware 5
Firmware: V3.3.11
Erweiterung: A37.12.12


Ich hoffe mir kann jemand weiterhelfen...

 

[Boxy]

Werden dort ggf. Adressen angesprochen welche deine CPU nicht kennt (z.B. E257.0 o.ä)?

Beim download wird dies erst geprüft ...

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei den Timern geht es schon los.
Wenn du an der CPU angeschlossen bist und einen Baustein markierst drückst du mal "Ctrl D". Dann öffnet sich ein Fenster das ist u.a. ein Reiter der heißt in etwa Leistungsdaten. Dort steht, was die CPU an Merkern Timern etc. zur Verfügung hat. Timer 250 und 251 sind wahrscheinlich zu hoch.

 

[SPS-EK]

Hallo Boxy und Ralle,

danke für die schnellen Antworten.

Nein, Eingangs und Ausgangsadressen werden im Baustein nicht benutzt. Beim Callen weise ich diese den IN und OUT Parametern der FUnktion zu, hier werden aber keine unbekannten Eingänge benutzt. Alles in der Symbolliste angelegt.

@ Ralle: Die Timer habe ich auch schon vermutet, ich meine aber die 314C kann bis 5xx Timer. Ich habe diese aber zum Test nochmal geändert auf T24 und T25. Leider ging es trotzdem nicht.

 

[RONIN]

@ Ralle: Die Timer habe ich auch schon vermutet, ich meine aber die 314C kann bis 5xx Timer. Ich habe diese aber zum Test nochmal geändert auf T24 und T25. Leider ging es trotzdem nicht.

Da "meinst" du leider falsch.

Merker

• max. 256 byte (M255.7)

S7-Zähler

• Anzahl 256

S7-Timer

• Anzahl 256

Die 317 ist die erste die mehr als 256 Timer hat, aber egal...

Der einfachste Weg ist, wenn du eh an der CPU sitzt...
Mach eine Kopie vom FC10 und beginne einfach Netzwerke raus zu löschen. Solange bis du den FC übertagen kannst.
Da solltest du eigentlich schnell raus haben woran es liegt....

 

[SPS-EK]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Ronin,

sagte ja habe testweise ja schon auf Timer 24 und 25 geändert, führte aber auch nicht zum erfolg. Aber gut zuwissen das nur 256 Timer genutzt werden können.

Die Idee mit den einzelnen Netzwerken, werde ich mal ausprobieren. Komme aber leider erst heute Mittag an die Anlage.
Sonst noch jemand eine Idee?


EDIT: Ich glaube ich habe die fehlerhafte Stelle bzw Netzwerk.
Ich habe gerade mein altes Projekt aufgemacht und die AWL-Quelle des Bausteins übersetzt, ein Netzwerk wurde nicht in FUP umgewandelt sondern blieb in AWL stehen.
Hier wird mit den zwei Timern ein Impulssignal erzeugt. Anscheinend stimmt hier was nicht mit den Timern S_VIMP.

 

[RONIN]

Kannst das betroffene Netzwerk (vielleicht sogar besser ohne Symbolik, oder beides) ja mal hier posten....

 

[SPS-EK]

Es lag wohl noch nicht mal an dem Netzwerk. Habe das alte Projekt aufgespielt mit der übersetzten AWl-Quelle und schon ging es.
Leider ein erneutes Problem:
Ich habe ja Hilfsmerker für Wert und Zustand angelegt und wollte so in dem FC diverse Daten einlesen, addieren und wieder ausgeben. Jedoch funktioniert das nicht so recht, ich poste mal ein Netzwerk um es zu verdeutlichen, was ich vorhabe und vllt kann mir jemand eine Hilfestellung geben.

Netzwerk zum laden der Daten über den IN-Übergabeparameter, am Eingang IN liegt ein DB an DBX.DBDX im Dint:

      U     #IN_start
      FP    #DM.HM_edge_pulse_1
      SPBNB _001
      L     #IO_count_result_DB
      T     #HM_count_value
_001: NOP   0

Die Flankenabfrage funktioniert mit den Tempvariablen nicht. Tausche ich diese gegen Merker funktioniert es richtig.

Netzwerk für den Impuls über zwei Timer:

    U(    
      U(    
      U     #IN_start
      FP    #DM.HM_edge_pulse_3
      O(    
      U     T    251
      FN    #DM.HM_edge_pulse_4
      )     
      )     
      L     S5T#10S
      SV    T    250
      U     #IN_stop
      R     T    250
      NOP   0
      NOP   0
      U     T    250
      )     
      FN    #DM.HM_edge_pulse_5
      L     S5T#10S
      SV    T    251
      U     #IN_stop
      R     T    251
      NOP   0
      NOP   0
      NOP   0

Netzwerk zum hochzählen:

      U     T    250
      SPBNB _003
      L     #HM_count_value_pulse_T1
      L     1
      +I    
      T     #HM_count_value_pulse_T1
_003: NOP   0

Hier funktioniert auch das hochzählen nicht, dies wird immer nur einmal ausgeführt obwohl der Impuls mehrmals kommt.


Weiß jemand Rat oder funktioniert das so mit den Tempvariablen nicht und ich muss die Tempvariablen in ein DB auslagern?
Ichhätte ja ein FB genommen aber durch den IDB, kann ja nur die Funktion auf der Werte zugreifen.
Ausserdem müsste der DB die Daten remanent halten.

 

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

      U     #IN_start
      FP    #DM.HM_edge_pulse_1
      SPBNB _001
      L     #IO_count_result_DB
      T     #HM_count_value
_001: NOP   0

Weiß jemand Rat oder funktioniert das so mit den Tempvariablen nicht und ich muss die Tempvariablen in ein DB auslagern?

Hab jetzt nur mal das erste Codeschnipsel raus genommen um es zu verdeutlichen.
Flankenmerker (in deinem Fall #DM.HM_edge_pulse_1 - x) funktionieren in dem Sie sich den letzten Zustand des zu prüfenden Bits über einen SPS-Zyklus hinweg merken. Beim nächsten Durchlauf erfolgt dann:

Zu Prüfendes Bit = 1 und Flankenmerker = 0 -> Es ist eine positive Flanke
Zu Prüfendes Bit = 0 und Flankenmerker = 1 -> Es ist eine negative Flanke
Flankenmerker = Zu Prüfendes Bit -> Rücksicherung für nächste Prüfung in nächsten Zykus
​

Oder in "FP" AWL nachprogrammiert...

U  Prüfbit        //Funktion für positive Flanke
UN Flankenmerker
=  PositiveFlanke

U  Prüfbit        //Rückspeichern für nächsten Zyklus
=  PositiveFlanke        //Remanent für min einen Zyklus

Zentral ist nunmal das Sichern des Zustandes über einen Zyklus hinweg. Temporäre Variablen sind hier schlecht, da diese, wie der Name schon sagt,
nur temporär sind und die Information am Ende des Bausteins verloren geht.
Am Anfang des Bausteins haben temporärer Werte bei der 300/400 sogar meist einen "zufälligen" Wert.

Du musst also irgendwas Remanentes nehmen. Versorgung über IN/OUT, DB, Merker, FB mit IDB

Ich hätte ja ein FB genommen aber durch den IDB, kann ja nur die Funktion auf der Werte zugreifen.
Ausserdem müsste der DB die Daten remanent halten.

Ein IDB ist auf der 300/400 immer remanent, wäre also eine Möglichkeit.
Gerade wenn der Baustein wiederverwendbar sein soll, du ihn also mehrfach aufrufen willst, wäre das die beste Lösung
Das Funktioniert im Moment aber auch schon wegen der fix verwendeten Timer nicht.

Das mit dem "aber durch den IDB, kann ja nur die Funktion auf der Werte zugreifen." versteht ich nicht ganz.
Der FB-IDB in nix anderes (nicht ganz) als ein FC mit Zusatzspeicher (IDB). Der kann auch alles was der FC kann.

Sag uns mal genauer was es werden soll, ob du lieber einen FC hättest und inwiefern das Ding wiederverwendet (mehr als 1x im selben Projekt) werden soll.
Wenn es nur ein One-Off-Baustein ist dann brauchst du wahrscheinlich nicht mehr zu tun als dich um die Flanken zu kümmern.

 

[SPS-EK]

Im Grunde habe ich vor einen fortlaufenden Zähler zu programmieren, der nicht beschränkt ist wie die aus der Bibliothek. Durch Dint könnte man dann ja bis 2147483648 zählen.
Das Ergebnis übertrage ich durch MOVE dann in ein remanenten DB so der Plan.
Es kann gut sein, dass der Zähler mehrmals im Projekt auftauchen kann momentan ist aber nur einer vorgesehen, daher der erste Ansatz mit festen Timern. Nur erstmal soll er zählen.
Die Timer hierbei sollten für den Zählwert pro Stunde zb sein.
Am Ende sind es also zwei Zählwerte, ein kontinuierlich fortgeführter und einer pro Stunde. der kontinuierliche muss logischerweise erhalten bleiben auch wenn dei Anlage aus ist.

Ist es bei einem IDB nicht so das nur der Funktionsbaustein auf die Werte im IDB zugreifen kann? Denn eine andere Funktion müsste auch auf diese Werte zugreifen können.

 

[RONIN]

Ist es bei einem IDB nicht so das nur der Funktionsbaustein auf die Werte im IDB zugreifen kann?
Denn eine andere Funktion müsste auch auf diese Werte zugreifen können.

Jein, grundsätzlich ist ein IDB von außerhalb des zugeörigen FBs gesehen nix anderes als ein normaler DB.
Wenn du einen IDB in Step7 öffnest und bei der Abfrage "Nein" drückst dann geht er auch im ganz normalen DB-Editor auf.
Man kann im Programm auch normal mit L DB[IDB-DbNr].DBD123 darauf zugreifen, es ist wie gesagt von außen ein normaler DB.
Der einzige Unterschied ist eben das er einem FB zugeordnet ist der darauf arbeitet. Oft gibt es auch Bausteine wo Parameter/Flags
im IDB abgelegt werden wo man diese Einstellungen von außen setzt.

Sollte man von außen auf einen IDB zugreifen (müssen)? Eigentlich nicht, vor allem nicht bei sowas was du vorhast.

Im Grunde habe ich vor einen fortlaufenden Zähler zu programmieren, der nicht beschränkt ist wie die aus der Bibliothek. Durch Dint könnte man dann ja bis 2147483648 zählen. Es kann gut sein, dass der Zähler mehrmals im Projekt auftauchen kann...
Am Ende sind es also zwei Zählwerte, ein kontinuierlich fortgeführter und einer pro Stunde.

Das ist ein Paradebeispiel für einen komplett abgekapselten FC/FB.
Du möchtest schließlich einen Zähler bauen der als abgekapselter Block für sich zählt und die Ergebnisse dann abliefert. Der Baustein sollte einen Eingangs- und einen Ausgangsbereich haben. Am Eingangsbereich bekommt er Start,Impuls, Reset, am Ausgangsbereich liefert er die Zählerwerte. Das was dazu dazwischen benötigt wird (Flanken, Timer, Zwischenergebnisse) dass willst du außen gar nicht sehen, die soll der Zähler schön in seinem IDB ablegen. Oder besser als Multiinstanz im IDB des FBs der den Zähler-FB beinhaltet.

Des weiteren ist es auch unschön wenn man einen abschlossen Block an einem Ende des Programms hat und am anderen Ende wühlt irgendjemand in dessen Daten rum und ändert Werte. Da wird die Fehlersuche lustig, am besten noch so dass man keine Querverweise hat.

Ich hab dir mal ein Beispiel dafür gemacht. Sonst wir die Erklärung ewig lang. Da siehst du auch gleich wie FBs als Multiinstanzen verwendet werden könnten bzw. was ich mit abgekapselter Funktion meine.
Anhang anzeigen BSP_SimpleCount.zip

 

[SPS-EK]

Zuviel Werbung?
-> Hier kostenlos registrieren

@ Ronin: Danke für die erklärung, den Denkanstoß und das Beispiel.
Genau wie du beschrieben hast, habe ich vor den Zählbaustein zu nutzen.
Meine Funktion sah von der Programmierung sehr ähnlich aus wie die aus dem Beispiel, nur halt nicht mit dem DB. Habe mein FC in ein FB gewandelt und entsprechend angepasst.

Ein paar kleinere Änderungen habe ich dabei aber vorgenommen:
Ich habe zwei TP Zeitbausteine benutzt, die jeweils ein Impuls erzeugen. Das hat bei mir den Hintergrund, dass mir das mit dem Stundenwert auf 0 setzen nach einer Stunde nicht gefällt. Den nach einer Stunde ist der Verbrauch ja nicht 0. Durch die zwei miteinander verknüpften Impulsglieder die jeweils eine Minute laufen, erzeuge ich ein Impulssignal das eine Minute 1 ist und eine Minute 0. Durch zwei weitere Zähler des generierten Impulssignales erfasse ich dann ob der TP1 60 Impulse ausgegeben hat und der TP2 30 Impulse.
Ist das der Fall und der neue Wert ist größer dem alten, folgt eine Berechnung: WerproStunde= Wertnach2Stunden - WerproStunde.
So wird der Zählwert pro Stunde nur beim Start oder reset 0 sein und ich müsste immer den aktuellen Wert haben. Man hätte das zwar auch per Mittelwertbildung machen können, aber diese Angabe ist ja nicht genau. Durch die Berechnung, sollte immer der wirkliche Stundenwert passen.
Desweiteren übertrage ich am Ende die Zählwerte gesamt und pro Stunde nochmal an zwei Ausgangsparameter. Ich denke gerade für die Nutzung zur Anzeige in der Visu ist das nicht verkehrt.

Nun bleibt mir noch folgende Frage: Ist es denn arg schlimm zwei TPs zu benutzen wenn man den FB als Multiinstanz nutzt? So benötige ich eben auch keine Taktmerker der CPU.

 

[PN/DP]

Man kann durchaus so viele Timer benutzen wie man will - falls die Timer aber irgendwie zusammengehören (z.B. Impulsfolgen generieren sollen), dann könnte man vielleicht auch Zeiten per Zähler von nur 1 Timer ableiten. Bei nicht exakter Programmierung wird es passieren, daß mehrere TP auseinanderlaufen und nach mehreren Zyklen deutlich sichtbar nicht mehr synchron schalten.


Wie oft soll sich Dein "WertProStunde" aktualisieren?

Nach meinem Verständnis Deiner Aufgabe gilt:

Wert_pro_Stunde := Zählerstand_jetzt - Zählerstand_1Stunde_vorher ;

Wenn Dir z.B. alle 10 Minuten eine Aktualisierung des StundenWertes reicht, dann könntest Du alle 10 Minuten den Zählerstand auf 6 Variablen (z.B. Array) speichern und die Differenz zum Wert vor 1 Stunde in die Anzeige nehmen (überlappende Meßintervalle). Bei einem Neustart müssten die 6 Variablen mit dem Zählerstand_jetzt initialisiert werden. Man könnte auch während der ersten Stunde (bis zum Vorliegen des ersten exakten Zählergebnis) "Hochrechnungen" präsentieren.
Wenn die Aktualisierung sehr viel häufiger als das Meßfenster erfolgen soll, dann ist ein ungenauerer gleitender Mittelwert mit weniger Aufwand realisierbar. Oder man berechnet wie bei einem km/h-Tacho eine voraussichtliche Hochrechnung aus der Zählerstandsänderung im Aktualisierungsintervall. Die wird aber ungenau und schwankend, weil die prinzipiellen Messfehler und Auflösungsfehler mit multipliziert werden.

Harald

 

[SPS-EK]

Hallo PN/DP,

danke für deine Beteiligung.

Wie meinst du das mit Zeiten per Zähler von nur einem Timer ableiten? Soll ich dann nur ein Timer laufen lassen? Das Problem ist dann ja, dass ich diesen Impuls von 1 Minute 1, 1 Minute 0 nicht erhalte. Daher hab ich ja zwei Timer genutzt.
In dem FB bzw IDB sind meine zwei Timer als TP1 und TP2 drin. Könnte es da passieren das die sich überscheiden wenn ich den FB mehrmals nutze?

Mein WertProStunde kann von mir aus während jedem Zyklus an die Ausgangsparameter übertragen werden. Da sehe ich keine Probleme.
Die Formel hast du richtig erkannt. So decke ich da immer die erste Stunde ab und eine zweite ebenso, wobei die Berechnung erst erfolgt wenn die 2. Stunde abläuft und der 2. Wert größer dem ersten ist.
Die Berechnung reicht mir so. Mir hat nur nicht gefallen, dass der Wert nach einer Stunde auf 0 gesetzt wird und ebenso gefällt mir auch die Mittelwertbildung nicht. Eine MIttelwertbildung kann hier zu ungenau werden. Durch die Subtraktion der Werte von einer Stunde und von 2 Stunden müsste dies eigentlich genau aufgehen und unnütze Wertspeicherung wie bei Mittelwertbildung entfällt somit auch.

Ich habe aber noch eine Frage: Wie kann ich eine AWL-Quelle erstellen wobei auch die SFB's mit und die Einträge in der Symbolliste automatisch geschehen?

Hatte nämlich gerade probiert, meinen FB als AWL-Quelle in ein andere Projekt zu inkludieren nur dabei kamen Fehler raus, weil der FB nicht in der Symbolliste angelegt ist und der SFB 3(TP) muss ja dann in das neue Projekt auch inkludiert werden.