TIA Bereichslängen Fehler im Hochregallager

[flashgorny]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
habe ein kleines Problem im FB 74(SequenzeParameter) bekomme beim übersetzen kein fehler. Außer wenn sich die SPS im RUN befindet.
Bereichslängenfehler beim Lesen
Global -DB ,Bitzugriff, Zugriffsadresse: 2098
FB-Nummer: 74
Bausteinadresse: 626
Angeforderter OB: Programmierfehler-OB (OB 121)
Prioritätsklasse: 1

Netzwerk Status steps
Quellcode

/ How Many Transitions in this Sequence ("T_CNT" stored at address 'DB length'-31)
L #LengthDB // load length of step sequence DB
L 31 // offset of T_CNT
-I
SLD 3 // to pointer format
T #temp_Adr // address of T_CNT
L DBB [ #temp_Adr]
T #T_CNT // number of transitions

// How Many Steps in this Sequence ("S_CNT" stored at address 'DB length'-28)
L #LengthDB // load length of step sequence DB
L 28 // offset of S_CNT
-I
SLD 3 // to pointer format
T #temp_Adr // address of S_CNT
L DBB [ #temp_Adr]
T #S_CNT // number of steps

// internal number of the initial step ("SINI[1]")
L #LengthDB // load length of step sequence DB
L 36 // offset of ADR_COND
-I
SLD 3 // to pointer format
T #temp_Adr // address of ADR_COND
L DBW [ #temp_Adr]
T #temp_Adr // address offset ADR_LOG_T[0]

L #S_CNT // number of steps
L #T_CNT // number of transitions
+I
L 2
*I
L #temp_Adr // address offset ADR_LOG_T[0]
+I // address offset ADR_T1_CRITFLT
L 7 // additional offset
+I
SLD 3
T #temp_Adr // address offset SINI[1]
L DBB [ #temp_Adr] // SINI[1]
T #SINI

// status interlock error
L #temp_Adr // address offset SINI[1]
SRD 3
L 3 // additional offset
-I
SLD 3
T #temp_Adr // address of ADR_SERRX
L DBW [ #temp_Adr] // ADR_SERRX
T #temp_Adr // address offset SERRX[0]
L #S_CNT // number of steps
L 2
MOD // "1" if number of steps is odd
L #S_CNT // number of steps
+I // round up to the next even number of steps
L 2 // additional offset
+I
L 4 // 4 step fields
*I
L 6 // internal fields
+I
L 4 // MOPEDGE field
+I
L 4 // MOP field
+I
L 12 // TICKS field
+I
L #temp_Adr // address offset SERRX[0]
+I // address offset SQ_FLAGS
SLD 3 // to pointer format
INC 1 // address of .ERROR
T #temp_Adr // address offset SQ_FLAGS.ERROR
A DBX [ #temp_Adr] // SQ_FLAGS.ERROR --------------------> Hier bekomme ich den Fehler
= #InterlockError // Interlock Error present

// Pointer to Step Structure (Step 0; not used)
L #T_CNT // number of transitions
INC 1 // one more
L 16 // length of 1 transition structure
*I
L 10 // start address of first transition
+I
SLD 3 // to pointer format
LAR1 // to address register 1

// Pointer to Initial Step
L #SINI // initial step number
L 32 // lenght of 1 step structure
*I
SLD 3 // to pointer format
+AR1

L DBW [ AR1 , P#2.0 ] // user step number
L %DBW6
==I
= #InitStepActive

Ich weiß leider nicht weiter, könnt ihr mir weiter helfen?

Gruß
Hans

 

[Perfektionist]

TIA...

Hallo mein Lieber,

1. lief das Programm jemals mit Classic?
2. ist es noch immer eine Classic-CPU oder soll das nun von einer 1500er ausgeführt werden?

Problem was dahinter steht: es ist bei TIA mit (z.T. herben) Bugs zu rechnen. Wenn der Code jemals schon irgendwie lief, dann braucht niemand mehr den Code zu durchsuchen.

 

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Schwer zu sagen, vielleicht mal den Baustein beobachten mit AR1 eingeblendet.
Ansonsten ist der Baustein, sagen wir mal "fehleranfällig" programmiert:

// internal number of the initial step ("SINI[1]")
L #LengthDB // load length of step sequence DB
L 36 // offset of ADR_COND
-I
SLD 3 // to pointer format
T #temp_Adr // address of ADR_COND
L DBW [ #temp_Adr] ----------------> L DBD schaut besser aus, der lädet nen 16Bit Adresspointer
T #temp_Adr // address offset ADR_LOG_T[0]


// status interlock error
L #temp_Adr // address offset SINI[1]
SRD 3
L 3 // additional offset
-I
SLD 3
T #temp_Adr // address of ADR_SERRX
L DBW [ #temp_Adr] // ADR_SERRX ----------------> L DBD schaut besser aus, der lädet nen 16Bit Adresspointer
T #temp_Adr // address offset SERRX[0]
L #S_CNT // number of steps
L 2
MOD // "1" if number of steps is odd
L #S_CNT // number of steps
+I // round up to the next even number of steps ----------------> +D schaut besser aus, der addiert nen 16Bit Wert
L 2 // additional offset
+I
L 4 // 4 step fields
*I ----------------> *D schaut besser aus, .....
L 6 // internal fields
+I
L 4 // MOPEDGE field
+I
L 4 // MOP field
+I
L 12 // TICKS field
+I
L #temp_Adr // address offset SERRX[0]
+I // address offset SQ_FLAGS ----------------> +D schaut besser aus, der addiert nen 16Bit Wert
SLD 3 // to pointer format
INC 1 // address of .ERROR
T #temp_Adr // address offset SQ_FLAGS.ERROR


Vielleicht aber absichtlich und durchdacht.....

 

[bike]

L #temp_Adr // address offset SERRX[0]
+I // address offset SQ_FLAGS
SLD 3 // to pointer format
INC 1 // address of .ERROR
T #temp_Adr // address offset SQ_FLAGS.ERROR
A DBX [ #temp_Adr] // SQ_FLAGS.ERROR --------------------> Hier bekomme ich den Fehler
= #InterlockError // Interlock Error present

Wolltest du im Ernst die Bitadresse um 1 erhöhen?
Du erhöhst doch schon vor dem SLD, warum noch das INC?


bike

 

[borromeus]

Das ist der größte Bock, habe ich glatt übersehen.
INC ist überhaupt ein 8 Bit Befehl.

 

[Perfektionist]

Zuviel Werbung?
-> Hier kostenlos registrieren

----------------> L DBD schaut besser aus, der lädet nen 16Bit Adresspointer ----------------> +D schaut besser aus, der addiert nen 16Bit Wert

sorry, hast da nicht was durcheinandergeschmissen?

...und dass INC einen 8-Bit-Wert (Byte) um eins erhöht, konnte der 8088 das überhaupt noch? mein 6510 und 8085: ja.

 

[bike]

sorry, hast da nicht was durcheinandergeschmissen?

...und dass INC einen 8-Bit-Wert (Byte) um eins erhöht, konnte der 8088 das überhaupt noch? mein 6510 und 8085: ja.

Autsch, das war weniger als nix, das war garnix.
Wenn ich Assembler programmieren will, dann hat das absolut nichts mit PLC zu tun.
Jedoch INC funktioniert bei BigS PLC eigentlich richtig und fehlerfrei.


bike

 

[00alex]

sorry, hast da nicht was durcheinandergeschmissen?

...und dass INC einen 8-Bit-Wert (Byte) um eins erhöht, konnte der 8088 das überhaupt noch? mein 6510 und 8085: ja.

Bei S7 nimm lieber den "+i16"("+i32") Befehl ... und inkrementiere mit +1 ( oder +n ) ...dann brauchst dich nicht um die INC Limits sorgen !
( Vorteil = die Rechnung braucht nur ein AKKU )

 

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

sorry, hast da nicht was durcheinandergeschmissen?

...und dass INC einen 8-Bit-Wert (Byte) um eins erhöht, konnte der 8088 das überhaupt noch? mein 6510 und 8085: ja.

Was habe ich durcheinandergeschmissen?
mit: ..... "der addiert nen 16Bit Wert" meinte ich die Originalprogrammzeile (der Befehl da links sollte das heissen)

und die INC Frage versteh ich nicht.... INC geht bis 255, und ist m.E. nicht dazu geeignet eines Adresspointer um ein Bit zu erhöhen.
Aber bitte klär mich auf.

 

[PN/DP]

----------------> L DBD schaut besser aus, der lädet nen 16Bit Adresspointer ----------------> +D schaut besser aus, der addiert nen 16Bit Wert

sorry, hast da nicht was durcheinandergeschmissen?

...und dass INC einen 8-Bit-Wert (Byte) um eins erhöht, konnte der 8088 das überhaupt noch? mein 6510 und 8085: ja.

Was habe ich durcheinandergeschmissen?
mit: ..... "der addiert nen 16Bit Wert" meinte ich die Originalprogrammzeile (der Befehl da links sollte das heissen)

und die INC Frage versteh ich nicht.... INC geht bis 255, und ist m.E. nicht dazu geeignet eines Adresspointer um ein Bit zu erhöhen.
Aber bitte klär mich auf.

Deutsche Sprache - schwere Sprache.
Ich verstehe borromeus' Anmerkungen genauso wie der Perfektionist und würde sie deshalb ebenfalls als falsch qualifizieren. Ich kann aber auch verstehen, wie borromeus es tatsächlich gemeint hat.

So wäre es eindeutig gewesen:
* L DBD schaut besser aus, der "L DBW" lädet nen 16Bit Adresspointer
* +D schaut besser aus, der "+I" addiert nen 16Bit Wert

Wobei "L DBD" statt "L DBW [#temp_Adr]" in dem Programm wahrscheinlich nicht korrekt wäre, weil DBD oder DBW richtet sich danach, auf was für eine Variable #temp_Adr zeigt. Da kann ich mir sehr gut vorstellen, daß diese Variable aus Speicherspar-Gründen eine Word- oder INT-Variable ist. Man muß schon sehr genau hinschauen, wo lediglich 16-Bit-Offsets berechnet werden und wo es tatsächlich Adressberechnungen sind, welche 32-Bit-Operationen erfordern.

Was das INC betrifft - da scheint der Perfekte wohl an einer Wochenend-Amnesie gelitten zu haben borromeus hat natürlich recht mit seiner Anmerkung, daß INC eine 8-Bit-Operation ist.
Allerdings führt das INC wohl nirgends zu einer Fehlberechnung. #T_CNT ist eine BYTE-Variable und "INC 1" direkt nach "SLD 3" funktioniert auch immer korrekt.

Harald

 

[PN/DP]

Wolltest du im Ernst die Bitadresse um 1 erhöhen?
Du erhöhst doch schon vor dem SLD, warum noch das INC?

Wahrscheinlich muß er auf eine Adresse ala DBX123.1 zugreifen. Das SLD 3 erzeugt eine Adresse p#byte.0

Harald

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der Code ist etwas umständlich - doch dafür nachvollziehbar - programmiert. Der Code passt gut zu den vorhandenen Kommentaren. Sehr wahrscheinlich hat der Code unter Beachtung der real vorkommenden Variablen-Werte unter Classic sogar korrekt funktioniert. Ich vermute, daß der oder die ursprüngliche Programmierer dieses Codes die kritisierten Operationen absichtlich so eingesetzt haben.

Möglicherweise will der TE das Programm erweitern und arbeitet nun mit größeren Variablen-Werten (z.B. bei #LengthDB) für die der Code nicht gemacht ist oder TIA erzeugt einen "leicht" unterschiedlichen MC7-Code aus dem AWL. (Welche Ziel-CPU?)

Ich vermute, zu Beginn dieser Codesequenz bzw. beim Aufruf des FB ist nicht der richtige DB geöffnet - eventuell eine "Neuerung" von TIA gegenüber Classic, welche möglicherweise vom "hidden" Code der Parameterversorgung beim Bausteinaufruf resultiert. (Vielleicht erlaubt der geöffnete DB auch keine absolut adressierten Zugriffe? Welche Ziel-CPU?)

Man bräuchte die komplette AWL-Quelle dieses Bausteins, die Quelle des Baustein-Aufrufs, die Quelle des Sequence-DB und eine Aussage zu den real vorkommenden Variablen-Wertebereichen um qualifiziert die Fehlerursache zu benennen.

Eigentlich ist mit dem Beitrag #2 vom Perfektionist bereits alles gesagt bzw. gefragt, was zum jetzigen Zeitpunkt gesagt werden kann. Wir sollten auf eine Antwort vom TE warten.

Harald

 

[borromeus]

Deutsche Sprache - schwere Sprache.
Ich verstehe borromeus' Anmerkungen genauso wie der Perfektionist und würde sie deshalb ebenfalls als falsch qualifizieren. Ich kann aber auch verstehen, wie borromeus es tatsächlich gemeint hat.

So wäre es eindeutig gewesen:
* L DBD schaut besser aus, der "L DBW" lädet nen 16Bit Adresspointer
* +D schaut besser aus, der "+I" addiert nen 16Bit Wert

Wobei "L DBD" statt "L DBW [#temp_Adr]" in dem Programm wahrscheinlich nicht korrekt wäre, weil DBD oder DBW richtet sich danach, auf was für eine Variable #temp_Adr zeigt. Da kann ich mir sehr gut vorstellen, daß diese Variable aus Speicherspar-Gründen eine Word- oder INT-Variable ist. Man muß schon sehr genau hinschauen, wo lediglich 16-Bit-Offsets berechnet werden und wo es tatsächlich Adressberechnungen sind, welche 32-Bit-Operationen erfordern.

Was das INC betrifft - da scheint der Perfekte wohl an einer Wochenend-Amnesie gelitten zu haben borromeus hat natürlich recht mit seiner Anmerkung, daß INC eine 8-Bit-Operation ist.
Allerdings führt das INC wohl nirgends zu einer Fehlberechnung. #T_CNT ist eine BYTE-Variable und "INC 1" direkt nach "SLD 3" funktioniert auch immer korrekt.

Harald

Danke für Deine wie immer sehr präzisen Ausführungen, der Sache mit der unglücklichen Formulierung stimme ich zu.

Aber eines ist doch nicht so glasklar:

zu:
"Da kann ich mir sehr gut vorstellen, daß diese Variable aus Speicherspar-Gründen eine Word- oder INT-Variable ist. Man muß schon sehr genau hinschauen, wo lediglich 16-Bit-Offsets berechnet werden und wo es tatsächlich Adressberechnungen sind, welche 32-Bit-Operationen erfordern."

Auch dann ist es m.E. zumindest nicht konsequent, weil wäre die #temp_Adr aus Speicherspargründen "WORD" wäre

L #LengthDB // load length of step sequence DB
 L 28 // offset of S_CNT
-I
 SLD 3 // to pointer format
 T #temp_Adr // address of S_CNT

das SLD3 auch durch ein SLW3 ersetzbar gewesen.
Wie ich Eingangs schrieb, der Code schaut "fehleranfällig aus".

Dass INC 1 nach SLD3 immer (in diesem Zusammenhang um das .1 bit zu erhalten) funktioniert, korrekt- da war ich wohl zu sehr mit dem 32 Bit Adresspointer "beschäftigt".

 

[PN/DP]

das SLD3 auch durch ein SLW3 ersetzbar gewesen.

Vielleicht hat der/die Programmierer versucht, den Code auf kurzen Programmspeicherplatzbedarf zu "optimieren"? (daher z.B. die INC)
SLW 3 braucht nicht weniger Bytes als SLD 3 --> Optimierung also nicht notwendig, man kann die korrekte Operation stehen lassen.

der Code schaut "fehleranfällig aus".

*ACK*
Der Code hätte in einem Compiler mit Typprüfung keine Chance.

Harald

 

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Viellicht meldet sich der TE ja wieder.