Mehr als 128 Zeiten bei CPU315 ,SFB4 die einzigste Lösung ?

kipphase

Level-1
Beiträge
32
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Für ein größeres Projekt benötige ich mehr als 128 Teimer. Gibt es eine andere Lösung als den SFB4 (T_ON). Beim SFB4 stören mich die vielen DB´s die ich dann erhalte. Vielleicht gibt es aber auch die Möglichkeit einen DB zu verwenden, wenn ich als Instanz z.B DB11.DBW16 angeben könnte. Gibt es hier eine Möglichkeit?
 
Hallo Kipphase,
bau Dir doch selbst Timer mit dem ob35 oder den Taktmerkern und
zähle eine Datenwort hoch oder runter .



HDD
 
ob25 oder Zähler

HDD schrieb:
Hallo Kipphase,
bau Dir doch selbst Timer mit dem ob35 oder den Taktmerkern und
zähle eine Datenwort hoch oder runter .



HDD

Das ginge natürlich, aber ich muss an unsere Inbetriebnehmer vor Ort denken. Die sollen eine Zeit auch als solche erkennen können, und das geht mit T_ON ok.
Danke
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Re: ob25 oder Zähler

Anonymous schrieb:
Das ginge natürlich, aber ich muss an unsere Inbetriebnehmer vor Ort denken. Die sollen eine Zeit auch als solche erkennen können, und das geht mit T_ON ok.
Danke

die von mir sind parametrierbare fc's. da lässt sich eigentlich recht gut erkennen das es eine zeit sein soll.
 
Beide Lösungen (von Volker und HDD) sind ok, und wahrscheinlich muß ich mich für eine entscheiden. Aber gibt es nicht die Möglichkeit einen FB nach folgendem Syntax aufzurufen:

call fc4, P#DB11.dbx0.0 Byte 22

dann brächte ich auch nur einen DB zu verwenden, denn der nächte aufruf könnte lauten

call fc4, P#DB11.dbx22.0 byte 22

Das system nimmt das nicht an, aber villeicht ist ja nur die Syntax falsch.

Ich könnte auch einen Multiinstanzen-FB verwenden, aber der Aufruf mit mehr als 5 Tim,ern wird dann doch recht unübersichtlich.
Aber für die Anregungen schon mal recht herzlichen Dank

Kipphase
 
TON/TOF/TP

Was habt ihr gegen die SFB's? Dafür sind sie doch da. Packt ihr wirklich in einen FB eine alten Timer rein? Das ist ja aus der S5-Steinzeit. Sogar da hat man schon versucht auf Timer zu verzichten (wenn möglich). Alles was begrenzt zur Verfügung steht geht irgenwann mal aus. Egal ob es 128 oder 256 oder 512 Timer sind. Irgendwann sind sie doch alle belegt. In der S7 wurden die Timer nur noch zwecks kompatiblität und für die, die sich vor der Rente nicht mehr umgewöhnen wollen. implementiert.

Mit den SFB's kann mann Zeitfunktionen ohne jede Einschränkung programmieren. Lediglich der Speicherplatz einer CPU gibt da Grenzen auf. Außerdem kann man FB's in denen die Zeiten mittels SFB realisiert wurden problemlos vervielfältigen und in andere Programme einbinden. Mit den alten Timern muß mann immer aufpassen ob die Timer noch frei sind. Warum also eine umständliche Lösung über OB35 und Co (wo mann sorgen haben muß ob das dann einer kapiert), wenn es eine saubere und in der Programmieranleitung beschriebene gibt. Auch in der Hilfe sind die SFB's beschrieben. Habt ihr für eure Timerbausteine eine Onlinehilfe gemacht?

Alos mut zu neuen Techniken. Wer mal damit angefangen hat, hört nicht mehr auf damit. Timer und Zähler verwende ich nur noch während der Inbetriebnahme um schnell irgendwelche Funktionen zum Testen zu Programmieren.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
TON, TOFF, TP

Hallo Gast,
du hast völlig recht, und ich habe nichts gegen T_ON und Co. Wenn ich aber ca. 100 mal Ton aufrufen muß, habe ich 100 DB´s, nur das stört, dafür suche
ich eine Alternative, und die kann nicht heissen "Multiinstanzen.FB", denn dann wird es wirklich unübersichtlich. Kann man nicht für x Timer einen DB nehmen, auch wenn unterschiedliche Zeiten zu programmieren sind. Wenn ich Zeiten vermeiden könnte würde ich das tun, aber in diesem Fall ist das leider nicht möglich.
Gruß
Kipphase
 
Du könntest ja einen FB machen in dem du x mal als Multiinstanz den SFB4 aufrufst, aber nichts anderes.

Dann kannst du ja bei Timer_1 ab DB ?.DBX0.0 = IN des ersten Timers, DB ?.DBX6.0 = OUT des ersten Timers, DB?.DBD2 = Solltime
von jeder x-beliebigen Stelle im Programm darauf zugreifen.

...

Mfg
Manuel
 
also das kann ich so nicht bestätigen.

ok. iec konform sind die s5/s7 zeiten nicht.

aber

1. die normalen timer bieten mir auch zeiten die ich mit t-on t-off erst noch programmieren müsste. (si,sv,ss)
und sind einfach schön schnell ins prog eingebaut

2. klar kann man das auch in multiinstanzen packen. aber das nicht so hyperfitte servicepersonal wird sich bedanken.

das ganze hat mit sicherheit auch nichts damit zu tun das man nichts neues benutzen will. ich bin schon etliche jahre als programmierer tätig.
und wenns was besseres als das alte gibt benutze ich das auch. aber nicht alles was früher gut war ist heute schlecht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Vorschlag von MSB hätte den Vorteil, das unsere Inbetriebnehmer keinen FB ändern müssen, dann nach Anweisungen sollen sie das nicht.

IEC-Konform ist eh Kappes, hat noch nie geklappt ein Programm direkt für eine andere Steuerung zu transformieren.

mfg
Kipphase
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ohne mind. einen Instanz DB geht nichts.

Alle TON's, die innerhalb eines FB's aufgerufen werden, lassen sich auch in dessen Instanz-DB unterbringen- man muss nicht für jeden TON einen DB anlegen.

Es gibt mehrere Möglichkeiten die Instanzen von TON zu erzeugen.

Mann kann z.B. den TON einfach (z.B. in einem FUP-Netzwerk) erzeugen, eine Variante ist:

mit z.B. Alt-F9, dann "TON" eingeben, danach mit der rechten Maustaste in dem FUP-Symbol klicken, im Kontextmenü "Multi-Instanzaufruf" (oder ähnlich lautend) auswählen, einen Symbolnamen eingeben und schon ist eine Instanz davon im statischen Teil der Bausteinvariablendeklaration erzeugt.

An der Aufrufstelle des FB's muss der Instanz-DB, wie üblich bei Änderungen in den Variblendeklarationen neu erzeugt werden.

Ich versuche mal heute Abend einige Screenshots hier rein zu stellen, die das Ganze Schritt für Schritt darstellen.
 
viele Wege führen nach Rom

Die Lösung von HeizDuese (warte noch auf die Sreenshots) scheint mir mindesten genau so interessant wie die von MSB (Manuel). Ich werde beides mal versuchen und dann entscheiden, welche Lösung am besten in unser Konzept passt.
An dieser Stelle mal einen Dank für die wirklich umfangreiche und schnelle Hilfe aller Beteiligten.
Danke.
 
Ich meinte das ganze so:

Es sind AWL-Quellen: FB100, FC100, DB100

FB100:
Code:
FUNCTION_BLOCK FB 100
TITLE =
VERSION : 0.1


VAR
  Timer_1 : SFB 4;    
  Timer_2 : SFB 4;    
  Timer_3 : SFB 4;    
  Timer_4 : SFB 4;    
  Timer_5 : SFB 4;    
  Timer_6 : SFB 4;  
END_VAR
BEGIN
NETWORK
TITLE =

      CALL #Timer_1 ;

NETWORK
TITLE =

      CALL #Timer_2 ;

NETWORK
TITLE =

      CALL #Timer_3 ;

NETWORK
TITLE =

      CALL #Timer_4 ;


NETWORK
TITLE =

      CALL #Timer_5 ;

NETWORK
TITLE =

      CALL #Timer_6 ;

END_FUNCTION_BLOCK

DB100 (Instanz DB)
Code:
DATA_BLOCK DB100
TITLE =
VERSION : 0.1

FB 100
BEGIN
   Timer_1.IN := FALSE; 
   Timer_1.PT := T#0MS; 
   Timer_1.Q := FALSE; 
   Timer_1.ET := T#0MS; 
   Timer_1.STATE := B#16#0; 
   Timer_1.STIME := T#0MS; 
   Timer_1.ATIME := T#0MS; 
   Timer_2.IN := FALSE; 
   Timer_2.PT := T#0MS; 
   Timer_2.Q := FALSE; 
   Timer_2.ET := T#0MS; 
   Timer_2.STATE := B#16#0; 
   Timer_2.STIME := T#0MS; 
   Timer_2.ATIME := T#0MS; 
   Timer_3.IN := FALSE; 
   Timer_3.PT := T#0MS; 
   Timer_3.Q := FALSE; 
   Timer_3.ET := T#0MS; 
   Timer_3.STATE := B#16#0; 
   Timer_3.STIME := T#0MS; 
   Timer_3.ATIME := T#0MS; 
   Timer_4.IN := FALSE; 
   Timer_4.PT := T#0MS; 
   Timer_4.Q := FALSE; 
   Timer_4.ET := T#0MS; 
   Timer_4.STATE := B#16#0; 
   Timer_4.STIME := T#0MS; 
   Timer_4.ATIME := T#0MS; 
   Timer_5.IN := FALSE; 
   Timer_5.PT := T#0MS; 
   Timer_5.Q := FALSE; 
   Timer_5.ET := T#0MS; 
   Timer_5.STATE := B#16#0; 
   Timer_5.STIME := T#0MS; 
   Timer_5.ATIME := T#0MS; 
   Timer_6.IN := FALSE; 
   Timer_6.PT := T#0MS; 
   Timer_6.Q := FALSE; 
   Timer_6.ET := T#0MS; 
   Timer_6.STATE := B#16#0; 
   Timer_6.STIME := T#0MS; 
   Timer_6.ATIME := T#0MS; 
END_DATA_BLOCK

FC100 Aufruf der Timer (Ähnlich den Original Timern)
Code:
FUNCTION FC 100 : VOID
TITLE =
VERSION : 0.1

BEGIN
NETWORK
TITLE =

      L     T#10S; 
      T     DB100.DBD    2; 

      U     E      0.0; 
      =     DB100.DBX    0.0; 

      U     DB100.DBX    6.0; 
      =     A      0.0; 

NETWORK
TITLE =

      L     T#10S; 
      T     DB100.DBD   24; 

      U     E      0.1; 
      =     DB100.DBX   22.0; 

      U     DB100.DBX   28.0; 
      =     A      0.1; 


NETWORK
TITLE =

      L     T#10S; 
      T     DB100.DBD   46; 

      U     E      0.2; 
      =     DB100.DBX   44.0; 

      U     DB100.DBX   50.0; 
      =     A      0.2; 


NETWORK
TITLE =

      L     T#10S; 
      T     DB100.DBD   68; 

      U     E      0.3; 
      =     DB100.DBX   66.0; 

      U     DB100.DBX   72.0; 
      =     A      0.3; 


NETWORK
TITLE =

      L     T#10S; 
      T     DB100.DBD   90; 

      U     E      0.4; 
      =     DB100.DBX   88.0; 

      U     DB100.DBX   94.0; 
      =     A      0.4; 


NETWORK
TITLE =

      L     T#10S; 
      T     DB100.DBD  112; 

      U     E      0.5; 
      =     DB100.DBX  110.0; 

      U     DB100.DBX  116.0; 
      =     A      0.5; 


END_FUNCTION

Was Heizdüse meint ist im Prinzip ähnlich oder genauso.

Nur wäre das dann normalerweise FB bezogen.

Mfg
Manuel
 
ein IEC-Timer gehört doch in den dazu gehörigen FB

Gibt es was einfacheres als einen FB in den alle Funktionen (Timer, Zähler, Merker u.s.w.) in der eigene Instanz (Multiinstanz) verpackt sind? Warum wehrt ihr euch dagegen? Für jeden SFB legt auch wrklich nur der CFC einen eigenen DB an. Allerderdings auch nur bis zu einer schon lang veralteten Version. Danach ist CFC auch schon schlauer geworden.
Ein Inbetriebsetzer soll halt dann die Finger weg lassen von der Programmierung, aber an den Zeitwerten kann er doch jederzeit was ändern. Schlimmstenfalls lege ich die Zeitwerte als IN an den FB an.

Zu einem Problem habt ihr aber noch nichts gesagt: Der Grund für die Diskusion ist doch, das die Standart Timer nicht unendlich sind. Meine Erfahrung zeigt mir, das alles was begrenzt zur Verfügung steht, geht früher oder später auch aus. Wenn ich es vermeiden kann, dann lege ich mir nicht am Anfang eines Projektes schon die Grenzen fest, auf die ich dann mitten drin treffen werde. Grenzen gibt es ja leider genug, wie Speicher, Zykluszeit und Bausteinnummern. Warum selber noch welche dazu bauen?

Zum Thema "Bausteine auf andere Projekte übetragen". Damit habe ich nicht gemeint, von STEP7 auf ABB oder sonst was (das klappt tatsächlich nicht so einfach), sondern von STEP7 auf STEP7. Wenn ich meine FB's programmiere, ohne das ich Merker, Zähler oder Timer darin verwende, dann kann ich den Baustein ohne Probleme in jedes vorhandene Projekt kopieren, ohne das ich vorher prüfen muß, ob die Adressen noch frei sind und ohne das ich vorher die Symbolik anpasse. Ich kopiere den FB ins Projekt, sollte die Bausteinnummer schon vergeben sein, dann werde ich beim Kopieren aufgefordert eine neue Nummer einzugeben und die Sache ist schon fast fertig. Fehlt nur noch ein freier DB für die Instanz.

Weitere Vorteile:
Die Fehlermöglichkeit durch doppelte Verwendung irgendwelcher Merker e.t.c. entfällt komplett.
Dadurch das ich den Instanz-DB online öffnen kann, habe ich einen schnellen Statusüberblick bei der Inbetriebnahme.
Durch die symbolische Programmierung, die dann endlich zwingend und auch einfacher ist, da der Symboleditor nicht gebraucht wird, wird das Programm viel besser lesbar.

Überlegt euch doch mal, ob die Vorteile einer Multinstanz es nicht wert sind, das ihr eure Inbetriebsetzer mal für einen Tag ins Büro holt und ihnen das erklährt. Meistens sind die Leute fitter als ihr denkt.
 
@volker:

Habe das ganze jetzt oben geändert,
funktioniert hat nur der DB nicht, aber ich hatte beim generieren eigentlich
Absolut angegeben, funktioniert das bei DB's nicht?!

Mfg
Manuel
 
Zurück
Oben