CPU (4xx) geht in "Stop", nachdem ich 2 DI + 1 DO hinzugefügt habe...

mega_ohm

Level-2
Beiträge
676
Reaktionspunkte
47
Zuviel Werbung?
-> Hier kostenlos registrieren
Sehr geehrte helfende Fachleute,

ich wollte folgende Aufgabe lösen:
- 1 Öffner ( "Stopp" ) ( DI )
- 1 Schließer ( "Start" ) ( DI )
- 1 LED ( Start- Taster beleuchtet ) => Meldung "ist gestartet" ( DO )

_______________________________________________________________
Das ganze Progi bekomme ich nicht zu mir nach Hause... deswegen habe ich mal versucht, das Progi nachzubilden !

Code:
DATA_BLOCK DB 1
TITLE =

  STRUCT        
   M_Stop : BOOL ; //Merker für "Masch_Stopp"
   M_Start : BOOL ; //Merker für "Masch_Start"
  END_STRUCT ;  
BEGIN
   M_Stop := TRUE; 
   M_Start := FALSE; 
END_DATA_BLOCK
FUNCTION FC 192 : VOID
TITLE =
BEGIN
NETWORK
TITLE =Ausgang setzen
      U     DB1.DBX    0.1; 
      U     DB1.DBX    0.0; 
      U(    ; 
      U(    ; 
      O     A      0.6; 
      O     A    108.3; 
      )     ; 
      NOT   ; 
      )     ; 
      S     M      0.0; 
      U(    ; 
      ON    DB1.DBX    0.0; 
      ON    M      0.1; 
      )     ; 
      R     M      0.0; 
      U     M      0.0; 
      =     A      0.6; 
      =     A    108.3; 
END_FUNCTION
FUNCTION_BLOCK FB 10
TITLE =

VAR
  D_0 : DWORD ; //ED 0 sichern
  D_1 : DWORD ; //ED 4 sichern
  D_2 : DWORD ; //ED 8 sichern
  D_3 : DWORD ; //AD 0 sichern
  D_4 : DWORD ; //AD 4 sichern
  D_5 : DWORD ; //AD 8 sichern
END_VAR
BEGIN
NETWORK
TITLE = 
// Eingangs- Peripherie lesen      
      L     PED    0; 
      T     ED     0; 
//      
      L     PED    4; 
      T     ED     4; 
//      
      L     PED    8; 
      T     ED     8; 
//      
//             
//      
// ********************************* PROCEDURE  begin  **************************************************************     
// **       Jetzt kommt natürlich die ganze Mimik, die ein Programm tuen muß, um ein Programm sein zu dürfen       **
// ********************************** PROCEDURE end  ****************************************************************     
//      
//      
// Ausgangs- Peripherie schreiben      
      L     AD     0; 
      T     PAD    0; 
//      
      L     AD     4; 
      T     PAD    4; 
//      
      L     AD     8; 
      T     PAD    8; 
//      
      CALL FC   192 ;
END_FUNCTION_BLOCK
DATA_BLOCK DB 10
TITLE =
 FB 10
BEGIN
   D_0 := DW#16#0; 
   D_1 := DW#16#0; 
   D_2 := DW#16#0; 
   D_3 := DW#16#0; 
   D_4 := DW#16#0; 
   D_5 := DW#16#0; 
END_DATA_BLOCK
ORGANIZATION_BLOCK OB 1
//

VAR_TEMP
  OB1_EV_CLASS : BYTE ; 
  OB1_SCAN_1 : BYTE ; 
  OB1_PRIORITY : BYTE ; 
  OB1_OB_NUMBR : BYTE ; 
  OB1_RESERVED_1 : BYTE ; 
  OB1_RESERVED_2 : BYTE ; 
  OB1_PREV_CYCLE : INT ; 
  OB1_MIN_CYCLE : INT ; 
  OB1_MAX_CYCLE : INT ; 
  OB1_DATE_TIME : DATE_AND_TIME ; 
END_VAR
BEGIN
NETWORK
TITLE = 
      CALL FB    10 , DB    10 ;
      NOP   0; 
NETWORK
TITLE ="Stopp" setzen
      U     E    108.3; 
      U     E      2.3; 
      =     DB1.DBX    0.0; 
NETWORK
TITLE ="Start" setzen
      O     E    108.2; 
      O     E      2.4; 
      =     DB1.DBX    0.1; 
END_ORGANIZATION_BLOCK

Ich hab' mir extra einen DB1 gebastelt, um eben KEINE Merker- Bereiche zu überschreiben...

DI- bzw. DO- Adresse 0 ... 80 sind auf der 4xx- CPU.
Diese Adressen werden von / auf Peripherie geladen / transferiert.

DI- bzw. DO- Adresse 108 ist auf einer ET200 über Profibus angebunden.

Meine Änderungen ( die der 4xxCPU für die "rote" LED gereicht haben ):
- E2.3 ( Öffner = Taster )
- E2.4 ( Schließer = Taster )
- A0.6 ( LED für die Meldung )

Nachdem ich diese ( ich fand bis vor wenigen Stunden... es wäre eine einfache Aufgabe ! ) Änderung auf die Maschine übertragen hatte, konnte ich die Maschine mit "meinem" <neuen> Taster noch starten... und die Maschine
fing auch an, zu arbeiten !

Theoretisch hätte die LED am A0.6 leuchten müssen... so wie die LED am A108.3 ( die hat definitiv geleuchtet ! ) <<< das funktionierte schon mal nicht, auch der A0.6 wurde nicht gesetzt !
<<< Verdrahtungsfehler kann ich ausschließen ( z.b. + und - an der LED verwechselt, das hatte ich im Voraus schon geprüft )

>>> Danach ( ca. 1/2 min später) [ !!! ]
... die Vormaterial-Maschine führte noch das nächste Vormaterial zu...
, fuhr wieder in die Aufnahme- Position und begann, das nächste Vormaterial zu greifen...

Die Weiterverarbeitungs- Maschine starb mit dem 3. Schritt....

In der Diagnose (CPU) stand:
- "Unerlaubter Aufruf"
- "Fehler in FC 192"
_______________________________________________________________

Meine Fragen:
- welchen Sinn macht es, DI- Word od. DWord AUF ein PEW bzw. PED zu schreiben ???

Mir ist klar, daß diese Aussage heute niemand teilen kann... weil sie in meinem gelieferten Code nicht existiert.
Die Simu "frißt" einen Transfer auf ein PEW nicht.
Ich weiß aber, daß ich genau DAS heute gesehen habe.

Kann mir vielleicht schon jetzt jemand sagen, warum die CPU in "Stop" ging ?
:ROFLMAO: Ich habe nix gemacht... Ich bin nicht schuld !
:confused: oder doch ????

Mfg
 
Hallo,

für mich sieht es aus als hättest du hier einen "Schreibfehler",
ich meine im Ursprung denke ich werden die PEW´s in den DB10 geschoben, und dann anstatt aus der Peripherie mit dem Datenbaustein
weitergearbeitet ( konsistenz ).
Sonst macht das ganze in meinen Augen wirklich keinen Sinn.

gruß Thomas
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

für mich sieht es aus als hättest du hier einen "Schreibfehler",
ich meine im Ursprung denke ich werden die PEW´s in den DB10 geschoben, und dann anstatt aus der Peripherie mit dem Datenbaustein
weitergearbeitet ( konsistenz ).
Sonst macht das ganze in meinen Augen wirklich keinen Sinn.

gruß Thomas
Genauso ist es eben nicht !

Es wird ganz lustig mit den direkten Eingangs- bzw. Ausgangs- Adressen
umher gesprungen... nachdem diese eben, wie angedeutet zyklisch auf PEW (PED) bzw. PAW (PAD) transferiert werden.
Die Funktion des DB10 ( wo dieser Kram reingeschrieben wird) raffe ich gar nicht...

Eingänge => DB1
DB2 => Ausgänge... das kenne ich

Die DI ( z.B. ED 0 ) werden auf PEW 0 transferiert...
Diese Geschichte verstehe ich schon mal nicht.

Grundsätzlich kann ich mir aber noch gar nicht erklären, warum die CPU eigentlich "gestoppt" wurde...
Meine 2 neuen Eingänge ( E2.3 bzw. E2.4 ) und mein einer Ausgang A0.6 ... <<< ich verstehe einfach das Problem nicht !

Mfg
 
Zuletzt bearbeitet:
Die DI ( z.B. ED 0 ) werden auf PEW 0 transferiert...
Diese Geschichte verstehe ich schon mal nicht.


Du kannst ein PEW laden und ein PAW transferieren.
Wenn du im Programm die Eingänge überschreiben willst dann mit t EW.




bike


Edit: Wenn die PLC in Stopp geht, was steht im Puffer?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
kann es sein dass du den DB1 nicht aufs AG geladen hast?
Das ist völlig ausgeschlossen.

1. weiß ich, daß man bei DB- Zugriffen den DB vor den Zuf´griffen laden muß
2. habe ich mir den DB1 online in der Datenansicht ansehen können
3. zig- andere FB's, FC's greifen auf diesen DB zu - ohne Probleme

Mfg
 
Du kannst ein PEW laden und ein PAW transferieren.
Wenn du im Programm die Eingänge überschreiben willst dann mit t EW.




bike


Edit: Wenn die PLC in Stopp geht, was steht im Puffer?
Den kompletten Diagnose- Text habe ich heute gesichert, lade ihn heute nachmittag hoch.
Definitiv steht da der FC 192 als "Problemkind".
Die Aufrufe erfolgen aber auch im FB 10 ( dieser wird vom OB1 aufgerufen), der FB10 macht diese Mimik mit dem Transfer der ED auf PED bzw. AD auf PAD und sichert diese in DB10.
Danach wird vom FB10 der FC19 aufgerufen.
Dort hinein habe ich jetzt meine "Mimik" verfrachtet" ( Man sollte mich bitte nicht fragen, warum... das weiß ich selbst nicht so genau )

Im FB90, FC90, FC91, FC92, FC93 und im FC 191 wird meine "Mimik" korrekt abgearbeitet => ohne Stopp

Sobald ich aber meine Änderungen im FC192 mache... geht die CPU in Stop

Ich raffe das nicht.
Dort sind nur stinknormale AWL- Anweisungen zu finden... keine Pointer- Geschichten, kein Budenzauber...
Mit dem normalen E108.2 ist alles i.O. => funktioniert.
Sobald ich im FC192 mit "Suchen / Ersetzen" anstatt des E108.2 meinen DB1.DBX0.1 ersetze, stoppt die CPU und meckert mir den FC192, Bausteinnummer 5xx an.
Den genauen Diagnose- Text lade ich heute mittag hoch.

Den DB1 habe ich definitiv geladen, ich kann mir online ( Datenansicht) die Änderungen ansehen ( solange ich eben diesen versch***en FC192 mit meinen Änderungen noch nicht auf's AG übertragen habe ).


Ich habe mal eine ganz "fiese" Frage....
Wenn ich mit meinen 2 Eingängen ( E2.3 bzw. E2.4) im FB10 nach dem Transfer der ED auf PED einfach die Eingänge E108.2 bzw. E108.3 setze ?

Code:
U E2.3 // neuer Stopp- Taster
= E108.2 // bestehender Stopp- Taster ( alt )
 
U E2.4 // neuer Start- Taster
= E108.3 // bestehender Start- Taster ( alt )


Dann müßte doch zumindest für einen Zyklus die ganze Geschichte vom AG bearbeitet werden.
Das sieht nicht schön aus, ich selbst habe mich schon darüber aufgeregt.... [ "Wer macht denn sowas ? ] , aber funktionieren muß die Maschine nach dem Willen desjenigen, der am PG sitzt.
______________________________________________________________

Der derzeitige IST- Stand ist:
Ich habe im FC192 den "! alten" Eingang belassen... den Rest geändert.
Es funktioniert.... bis eben auf die Funktionen, die im FC192 programmiert sind.
Die "kann" mein neuer Taster nicht !
Diese wären aber eigentlich zu 20% entscheidend für die Rechtfertigung der Nachrüstung.

Mfg
 
Zuletzt bearbeitet:
Bei meiner Suche nach dem Fehler fand ich im OB1 Folgendes:
Code:
NW1 // Lampentest
UN M0.0 // welche Merker es nun konkret sind, ist ja unerheblich
UN M0.1
UN M0.2
SPB M003
L 1
T AW 0
T AW 2
 // etc.    eben alle Ausgänge, wo LED's  "hängen"
BEA // DAS heißt doch, der OB1 ist in diesem Fall nur noch mit dem "Lampentest" beschäftigt ??  mit sonst nix mehr ?
M003: NOP 0
 
NW2 // Mache dies
 
NW3 // Mache das
Ich interpretiere diesen Code so:
- wenn Lampentest, dann geht nichts anderes mehr

Oder habe ich da was Wichtiges übersehen ?

Mfg
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Kann mir eigentlich mal jemand erklären, warum man überhaupt
Code:
L ED 0
T PED 0
( mit den Ausgängen steht die gleiche Frage )
macht ?

Das man die Ein- bzw. Ausgänge auf DB's schreibt und dann im Programm nur noch die jeweiligen DB's verwendet... das sehe ich ein.

Warum schreibt man aber z.B. einen Eingang auf einen Peripherie- Eingang ?
Wo ist da der Vorteil ?

Die s7- Hilfe hat mir nicht geholfen.
Da stand was von "Verstecken" etc...
Wenn ich Programmteile "verstecken" will, nehme ich "einfach nur" Pointer und einen FB.
Diese Maßnahme ist sehr effizient.
Daran scheitern viele.

Mfg
 
Kann mir eigentlich mal jemand erklären, warum man überhaupt
Code:
L ED 0
T PED 0
( mit den Ausgängen steht die gleiche Frage )
macht ?

Das man die Ein- bzw. Ausgänge auf DB's schreibt und dann im Programm nur noch die jeweiligen DB's verwendet... das sehe ich ein.

Warum schreibt man aber z.B. einen Eingang auf einen Peripherie- Eingang ?
Wo ist da der Vorteil ?

Die s7- Hilfe hat mir nicht geholfen.
Da stand was von "Verstecken" etc...
Wenn ich Programmteile "verstecken" will, nehme ich "einfach nur" Pointer und einen FB.
Diese Maßnahme ist sehr effizient.
Daran scheitern viele.

Mfg
In dem ersten Posting steht L PED 0 T ED 0.
Daher schreibt er nicht auf PED sondern läd zur Laufzeit exakt an dieser Position das PED. Kann sein, dass er sich sicher sein will / muss, dass die Eingänge aktuell sind.

Du kannst schon deine Eingänge überschreiben.
Doch warum dies tun?

Schön wäre der Stack und auch der ungekürzte Programmteil, dann kann man suchen.
Denn einmal schreibst du PED beschreiben, dann PEW usw.
So erschließt sich mir dein Problem nicht.


bike
 
In dem ersten Posting steht L PED 0 T ED 0.
Daher schreibt er nicht auf PED sondern läd zur Laufzeit exakt an dieser Position das PED. Kann sein, dass er sich sicher sein will / muss, dass die Eingänge aktuell sind.

bike
Bei meinem letzten Posting zum Thema PED / PAD ging es mir erstmal um das grundsätzliche Verständnis, warum man sowas macht.

Die Diagnose- Textdatei habe ich mal angehangen.
 

Anhänge

  • Diagnose.txt
    4,6 KB · Aufrufe: 21
Zuviel Werbung?
-> Hier kostenlos registrieren
Kann mir vielleicht schon jetzt jemand sagen, warum die CPU in "Stop" ging ?
Ich könnte mir vorstellen, dass in dem FB10 Datenwort abfragen sind ohne dass der DB geöffnet wird, sprich ein "Nichtqualifizierter Zugriff".
Ich hab' mir extra einen DB1 gebastelt, um eben KEINE Merker- Bereiche zu überschreiben...
Und jetzt wird der DB1 geöffnet, was eventuell nicht an dieser Stelle passt.
 
Ich könnte mir vorstellen, dass in dem FB10 Datenwort abfragen sind ohne dass der DB geöffnet wird, sprich ein "Nichtqualifizierter Zugriff".

Und jetzt wird der DB1 geöffnet, was eventuell nicht an dieser Stelle passt.

Da hast du wohl wahr :)

Warum ein neuer zusätzlicher DB?
Wenn du einen DB aufschlägst, dann musst du dir vorher! Gedanken machen welchen Einfluss dies auf das Programm hat.


Ich würde einen OB121 reinkopieren, dann an meine Änderung zur Laufzeit gehen und schauen was vorher und nachher in den Akku steht.

Programmcode würde uns und dir echt helfen.


bike
 
Ich könnte mir vorstellen, dass in dem FB10 Datenwort abfragen sind ohne dass der DB geöffnet wird, sprich ein "Nichtqualifizierter Zugriff".

Und jetzt wird der DB1 geöffnet, was eventuell nicht an dieser Stelle passt.
Du ahnst gar nicht, wie recht Du hast. :)

Im FC 192 wurde auf verschiedene DBW zugegriffen.
( es ist nur als Beispiel zu sehen, es ist kein Auszug aus dem realen Programm ! )
Code:
L DBW 80
...
T DBW 90
Im FB90 stand irgendwann einmal (z.B. ! )
Code:
AUF DB10
Im FB90 hatte ich zwar auch "rumgekramt" mit meinem DB1.DBX0.1,
aber in diesem FB erfolgte kein Zugriff auf einen anderen DB.
Im FB90 wurde aber der FC192 aufgerufen...
:sm11: Das hatte ich nicht beachtet.

Übrigens funktioniert auch nicht ( es funktioniert nur nicht, die CPU "lebt" aber... geht nicht in "Stop" ),
wenn man ( z.B. !)
Code:
u E 0.0
= E 108.2
schreibt, wenn zwischendurch mal das PEW oder PED gelesen wird. :ROFLMAO:
Ich weiß das jetzt sicher.

Ich danke Dir für Deinen Tipp. Durch diesen konnte ich wenigstens erfassen, wo das Problem lag. ( einen irdischen Grund mußte es haben, daß war mir von Beginn an klar ).

Mfg
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Übrigens funktioniert auch nicht ( es funktioniert nur nicht, die CPU "lebt" aber... geht nicht in "Stop" ),
wenn man ( z.B. !)
Code:
u E 0.0
= E 108.2
schreibt, wenn zwischendurch mal das PEW oder PED gelesen wird. :ROFLMAO:
Ich weiß das jetzt sicher.
Was funktioniert daran nicht? :confused:

Die CPU geht bei dieser legitimen Operation selbstverständlich nicht in Stop (wenn die Größe des PAE > E108.2 ist). Vielleicht entspricht das Ergebnis nur nicht den Erwartungen des Programmierers?
Will man in einem OB1-Zyklus die Einganszustände auffrischen und dann mit den aktuelleren Zuständen weiterarbeiten, dann braucht man nur schreiben:
Code:
L PEW0
T EW0

Harald
 
Was funktioniert daran nicht? :confused:
Der FB10 macht die Mimik mit den PEW/ PED bzw. PAW / PAD ( dieser wird vom OB1 aufgerufen). Gesichert werden die Ergebnisse in DB10.
Danach wird vom FB10 der FC19 aufgerufen.

Ich hatte meinen Code
Code:
U E 0.0
= E 108.2
im FB10 vor dem Lesen der EW / ED bzw. im FC19 ( also eigentlich, nachdem die Peripherie in den DB geschrieben wurde ).
In beiden Fällen konnte ich mir in dem entsprechenden Baustein das Ganze online ansehen und es tat so, als würde es funktionieren.
Beim Setzen /Beobachten der Variablen wurde zwar der E0.0 ( neuer Taster ) gesetzt...
aber mit dem E108.2 ( ursprünglicher Taster) passierte gar nichts.
Es passierte auch nichts mehr, wenn ich den Taster (E108.2) betätigte.

Will man in einem OB1-Zyklus die Einganszustände auffrischen und dann mit den aktuelleren Zuständen weiterarbeiten, dann braucht man nur schreiben:
Harald
Es werden doch
1. die Eingänge gelesen
2. die Verknüpfungen aktualisiert
3. die Ausgänge gesetzt :confused: = 1 Zyklus

Wenn ich also vor dem Durchlauf eines kompletten Zyklus die Eingänge nochmal "genau" wissen will... muß ich das ( z.B. ) PEW nochmal lesen ?

Mir ist klar, daß Lade / Transfer VKE- unabhängig ist. Bedeutet das denn auch das es zyklus- unabhängig ist ?

Wo oder wie soll ich denn meinen E0.0 (den neuen Taster) ins Programm tun, damit es funktioniert ?

Mfg
 
warum das machst habe ich noch nicht verstanden

Code:
U  E 0.0
=  E 108.2

kann mann das wegen der übersichtlichkeit und üblichen Programmierlokig
nicht besser so lösen.

Code:
O  E 0.0
O  E 108.2
S  #irgendwas

Warum muss mann es bei einfachsten Bitverknüpfungen schon so
kompleziert machen?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
warum das machst habe ich noch nicht verstanden

Code:
U  E 0.0
=  E 108.2

kann mann das wegen der übersichtlichkeit und üblichen Programmierlokig
nicht besser so lösen.

Code:
O  E 0.0
O  E 108.2
S  #irgendwas

Warum muss mann es bei einfachsten Bitverknüpfungen schon so
kompleziert machen?
:ROFLMAO: meinst Du, daß...
Code:
U  E 0.0
=  E 108.2
komplizierter ist, als...
Code:
O  E 0.0
O  E 108.2
S  #irgendwas

:confused:

Zumindest ist eine Zeile weniger zu schreiben.

Aber mal im Ernst:
S wie "Setzen" mag ich nicht so gern, weil man sich dann auch um das R (Rücksetzen ) kümmern muß.

Ich gebe zu, daß mein "Plan A" war, einfach eine Leitung auf die schon bestehenden Taster zu "ziehen".
Auf Grund der Entfernung ( das wäre ja noch fast egal... es gibt Tage, an denen man nicht gewinnen kann und Tage, an denen man verliert) und hauptsächlich auf Grund der verbauten oder zugestellten bisherigen unterirdischen Kabeltrassen war "Plan A" nicht durchführbar.
>> "Eine überirdische Leitungsführung ist zu vermeiden, um eine maschinelle Reinigung der Hallen sicherzustellen"
(Das ist eine Vorgabe der Firma )

Der "Plan B" (Software- Änderung) stand erst nach Begehung und Feststellung der Nicht- Realisierbarkeit von "Plan A" an.
- Danach habe ich, weil ich zu faul war, mir 2 freie Merker zu suchen, einen eigenen DB kreiert.
Ich ging davon aus, das "AUF DB" in nur s5 vorkommt... in s7 gab es m.M. nach keinen Grund mehr für "nichtquali. DB-Zugriffe".
Dieser Irrtum (meinerseits) wurde mit einem "CPU- Stop" belohnt.

Da ich nicht das halbe Programm umschreiben wollte, dachte ich mir...
eine direkte Zuweisung eines E (E0.0) auf einen anderen (E108.2) ist zwar brutal ( ich mag's eigentlich gar nicht ), aber geht schnell und relativ "schmerzfrei".

Der Programmierer, der das ursprüngliche Masch.-Progi geschrieben hat, hat aber sehr gut für sich vorgesorgt.
Er hat erstmal alle DI und DO, die im Haupt- Schaltschrank existieren, mittels PEW / PED bzw. PAW / PAD irgendwie geladen / transferiert.
Egal, ob sie wirklich belegt sind... oder nicht.
(Sollte Interesse bestehen, würde ich nächste Woche "XRef" hochladen )

______________________________________________________________

Was habe ich gelernt ?
- Nicht alles, was auf den 1. Blick einfach lösbar schein, ist es auch.

Die Schwierigkeiten, um 2 zusätzliche Tasten einzufügen, hatte ich nicht so groß erwartet.

Das sämtliche EW und AW, die im Schaltschrank auf die s7-4xx verdrahtet, teils aber ab der Zwischenklemme drahtfrei (not connect) sind, im Programm manipuliert werden...
- komplette Merker- DWord wurden, ohne auch nur 1 Bit dieser DWord überhaupt im Progi zu verarbeiten, mit Laden / Transfer im FB10 manipuliert.
______________________________________________________________

Die Geschichte hat ein gutes Ende... es funktioniert.
Ich habe mir tatsächlich die Mühe gemacht, 1 freien - nicht über WORD oder DWORD- Zugriff im Progi abgearbeiteten Merker zu finden.

Für meinen "Stopp"- Taster habe ich die Verknüpfung über den DB1 beibehalten.

UND... ich habe gelernt. ( Das ist, glaube ich, das Wichtigste )
Ich habe gelernt, wenn ich mit "Suchen / Ersetzen" meine Ideen in ein bestehendes Progi einbringe, das bestehende Programm noch genauer zu analysieren...

Es war eine Prozedur... "Lernen durch Schmerz"... (es hat mich richtig geärgert, daß meine anfänglichen Änderungen nicht "laufen" )

Ich hatte über die unqualifizierten Zugriffe von DB's in s7 einfach überhaupt nicht nachgedacht, weil ich glaubte ( Glauben ist der Gegensatz von "Wissen" ) => das macht doch in s7 keiner mehr.

Heute bin ich, auch Dank Eurer Hilfe schlauer und vor allen Dingen vorsichtiger...

Mfg
 
Zuletzt bearbeitet:
eigentlich meinte ich nicht das setzen eines "irgendwas", sondern
das Rangieren von einen Eingang auf einen Anderen. Das finde ich
mehr als Unglücklich. Eingänge als Variabel zu mißbrauchen ist unüblich,
dafür gibt es andere Variabeln, wie Merker, Temponäre Variabeln oder
Variabeln in Datenbausteine. Das es funktioniert ist schön macht aber
in diesen Fall überhaubt keinen Sinn, nur um bei einer so Leistungsfähigen
Steuerung eine AWL Zeile zu spraren. Das hört sich an wie, ich nehme
jetzt mein Feuerzeug aus den Handschuhfach, bei einen Auto mit 350PS,
damit es schneller fährt.
 
S wie "Setzen" mag ich nicht so gern, weil man sich dann auch um das R (Rücksetzen ) kümmern muß.

Ist das dein Ernst :confused: alles immer nur mit "=".

Ich stelle mir gerade vor es gäbe kein S und kein R.
Meine Programme hätten viel mehr Zwischenmerker
und wären viel länger und unübersichlicher.

Nimm es mir nicht übel, aber ich bin über diese Zeile
mehr als verwundert.

Frank
 
Zurück
Oben