Step 7 Pointer

[Manuel123]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen, ich habe bereits schon mal mit Pointer gearbeitet jedoch ist das schon ein bisschen her und fällt mir deshalb im MOment etwas schwer.
Vielleicht kann mir jemand auf die Sprünge helfen.

Wir haben eine Pulveranlage mit 156 Gehänge und zwei Pulverkabinen.
Welches Gehänge in welche Kabine fährt wird über einen Schalter ausgewählt.
Wir haben jeweils zwei Lesestationen, welche die Wagennummer ausliest.
Das Prinzip ist folgendes. Fährt der Wagen ab dem die Weiche für die andere Kabine umgestellt werden soll durch die Lesestation 1 dann wird der Schalter betätigt.
Diese Nummer wird in einem DB geschrieben (DB151.DBW10)
Fährt dieser Wagen durch die zweite Lesestation wird er erkannt und in den DB (DB151.DBW22) geschrieben und die SPS schaltet die Weiche um.

Der Wagen mit der Nr. 12 macht sich jedoch immer selbstständig und fährt meistens in die falsche Kabine.
Ich habe beide Lesestationen überprüft. Alle Wagen werden richtig gelesen.

Ich habe zwei FC´s angehangen. FC 56 für das wegschreiben der Daten (Wagennr. usw) in den DB 115 und
den FC 57 für das Aufrufen des DB 115.

Ich verstehe in diesem Fall nicht warum der weggeschriebene Wagen bei der Lesestation 1 nicht einfach mit den Daten an Lesestation 2 vergleichen werden um dann die Weiche umzustellen.
Hier wurde mit Pointer gearbeitet und ich verstehe leider den Funktion in diesem Fall nicht

Vielen Dank vorab!

 

[Manuel123]

Der FC57 hat noch gefehlt.....

 

[TP-Inc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi. Kannst du mal das ganze Projekt hochladen. Da wird einem ja richtig übel wenn man das sieht... Gibts die Pfuscherfirma noch ?

 

[PN/DP]

Bis auf 2 sinnlose Anweisungen sieht der Code doch gar nicht so übel aus... so sieht halt indirekte Adressierung in AWL aus. Pfusch wüde ich das nicht nennen, das könnte sogar ein "Firmen-Standard-Baustein" sein.
Also ich sehe in dem FC56 und FC57 keinen Fehler, der mit Deinem Problem mit dem Wagen Nr 12 zu tun haben könnte. Ich vermute, daß der Fehler außerhalb der FC56 und FC57 liegt: einspeichern oder auslesen zum falschen Zeitpunkt, oder Variablen-Überlappung, oder woanders schreibt ein wilder Pointer, ...

Harald

 

[TP-Inc]

Man kann doch nicht eine Variable im Pointerformat mut der Vagonnummer multiplizieren oder ? Da müsste doch vorher SRD3, dann du multiplikation und dann wieder SLD3 rein oder. Es sein denn Vagonnummer ist in irgendeinem Spezialformat. Oder steh ich voll am Schlauch. Und die Rechtschreibfehler und sinnlosen Anweisungen find ich doch sehr pfuschig...

 

[chrigu]

Zuviel Werbung?
-> Hier kostenlos registrieren

Man kann doch nicht eine Variable im Pointerformat mut der Vagonnummer multiplizieren oder ? Da müsste doch vorher SRD3, dann du multiplikation und dann wieder SLD3 rein oder. Es sein denn Vagonnummer ist in irgendeinem Spezialformat. Oder steh ich voll am Schlauch. Und die Rechtschreibfehler und sinnlosen Anweisungen find ich doch sehr pfuschig...

Schön, dass du nie einen Rechtschreibfehler machst...

 

[PN/DP]

FC56: Der Kerncode des indirekten Speicherns in die Tabelle (INT-Array "verdi" in DB115) ist folgendes (und das funktioniert auch korrekt so):

L   #DB_number         //115
T   #in_db_number      //TEMP-Zwischenvariable für indirektes "AUF DB"
AUF DB [#in_db_number] //= AUF DB115

L   P#2.0              //Größe eines Array-Eintrags im Pointerformat (P#2.0 = 16 dez, INT = 2 Bytes)
L   #Vagonnumber       //Wagennummer 0..157 = Index in das Array
*I                     //(normalerweise sollte "*D", doch "*I" reicht hier)
T   #pointerr          //ergibt höchstens P#314.0 (2512 dezimal)

L   #Kodevalue         //den übergebenen Codewert
T   DBW [#pointerr]    //an die berechnete Stelle im Int-Array verdi[#Vagonnumber] speichern

Der FC57 zum Auslesen funktioniert analog.

Zu der eigenartigen Schreibweise von Variablennamen würde ich sagen, daß Englisch und Deutsch bestimmt nicht die Muttersprache des Programmierers war, er sich aber bemüht hat, verständliche kurze Begriffe zu benutzen.

Harald

 

[PN/DP]

Man kann doch nicht eine Variable im Pointerformat mut der Vagonnummer multiplizieren oder ?

Doch, kann man, wenn der Pointer wie hier keine Bereichskennung enthält: P#2.0
Die Bereichs-Angabe kommt erst beim indirekten Lesen bzw Schreiben dazu: "L/T DBW [#pointerr]"

Harald

 

[Manuel123]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi. Kannst du mal das ganze Projekt hochladen. Da wird einem ja richtig übel wenn man das sieht... Gibts die Pfuscherfirma noch ?

Nein die gibt es nicht mehr

 

[Manuel123]

Erstmal danke!

Ich frage mich nur warum der Pointer überhaupt mit der Wagennummer multipliziert wird. Was hat das für einen Sinn?
Die Weiche wird über die Variable #Destination gesteuert (FB40). Aber wo wird diese auf true oder false gesetzt?
Ich finde auch nichts wo der P#0.0 un P#2.0 beschrieben werden. Kann ich irgendwie danach suchen?

Danke vorab!

 

[PN/DP]

Ich frage mich nur warum der Pointer überhaupt mit der Wagennummer multipliziert wird. Was hat das für einen Sinn?

Um die Speicheradresse im INT-Array zu berechnen. Weil ein INT 2 Bytes belegt liegt das Element verdi[12] an der Adresse DBW24 (entspricht P#DBX24.0)

Die Weiche wird über die Variable #Destination gesteuert (FB40). Aber wo wird diese auf true oder false gesetzt?

Gar nicht - weil #Destination ein INT ist.
Im FC57 wird anhand der Wagennummer die Adresse des Tabellen-Eintrags (Array-Elements) berechnet und dann dieser Eintrag (INT) gelesen und an den OUT #Destination ausgegeben. In der Tabelle/Array liegen die INT-Werte 0 und 1

L DBW [#pegepind]
T #Destination

Ich finde auch nichts wo der P#0.0 un P#2.0 beschrieben werden.

P#0.0 und P#2.0 kann man nicht beschreiben, das sind Konstanten (Zahlen) im Pointerformat, die in den AKKU geladen werden um mit der Wagennummer multipliziert zu werden.

Harald

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Programm funktioniert mit 155 Nrn richtig und nur mit 1 nicht? Das kann ja wohl nicht wahr sein, dass ihr deswegen hinter spoardischem, wenn auch ziemlich reproduzierbarem Fehlverhalten der Pointerei hersucht?
Ich kann nicht erkennen, warum ausgerechnet die Nr 12 Probleme machen sollte. Welche Nrn sind überhaupt belegt? Lückenlos von 1 bis 156? Sprecht ihr von dezimal 12 oder hexadezimal 12 = dezimal 18? Könnte es nicht doch am Einlesen der Nr dieses einen Wagens hapern? Oder daran, dass der Speicherplatz für nur den Wagen 12 von irgendwo anders her kaputtgeschrieben wird? Was passiert denn, wenn man dem Wagen 12 eine andere, z.Z. nicht benutzte Nr verpasst? Hat das Array dafür keinen ReservePlatz mehr frei?
Wer jetzt sagt "guck' doch selber mal in die Software", liegt absolut richtig - hab' ich (noch) nicht getan. Aber vielleicht solltet ihr euch auch zuerst oder wenigstens zwischendurch mal zurücklehnen und ein Bisschen überlegen, ehe ihr jedes Bit einzeln inspiziert. Vielleicht habt ihr dann auch eine Idee, wonach ihr überhaupt suchen solltet!?
Gruss, Heinileini
PS: Kommt die 12 wirklich richtig in der PLC an? Wenn nicht, auf welchem Wege kommt sie dahin? Gerät ein ParityBit in die Quere oder ein CRC-Fehler? Bei Zahlen, wie 10 oder 12 oder 13 denke ich an LF (LineFeed), New Page alias Clear Screen oder an CR (CarriageReturn) ...

 

[Manuel123]

Sorry ich bin krankheitsbedingt ausgefallen und konnte mich deshalb nicht melden.
Das Programm funktioniert mit 156 Nrn. Alle Nummer sind belegt. Es funktioniert bis vor kurzen alle Nummern. Jetzt gibt es Probleme mit der der Nummer 12.
Es kommt auch mal vor das eine andere Nummer nicht funktioniert. Das ist aber sehr selten.
Die Nummern werden richtig gelesen und kommen auch richtig in der PLC an. Auch die Nummer 12.
Bei den Nummern reden wir vom Dezimalformat.

Wie soll ich dem Wagen 12 eine andere Nummer geben?
Die Wagen werden über ein Lochmuster und 9 Sensoren gelesen. Somit hat jeder Wagen eine feste Nummer.

 

[Heinileini]

Moin Manuel123!
Aus "dezimal" und 9 Bit schliesse ich, dass die Zahl als BCD-Zahl dargestellt wird. Je 4 Bit für die Einer- und Zehner-Stelle und das 9. für die Hunderter.
Also z.B. ...
X 0X0X 0XX0 für 156,
0 X00X X00X für 99 und
0 000X 00X0 für 12 ?
Oder ist das 9. Bit ein ParityBit?
Also z.B. ...
G X00X XX00 für 156,
U 0XX0 00XX für 99 und
U 0000 XX00 für 12?
Wobei bei gerader Parität G=X und U=0 bzw. bei ungerader Parität G=0 und U=x wäre?
Oder ist das 9. Bit bei allen Zahlen vorhanden und gibt lediglich an , dass die anderen 8 gelesen werden sollen?

Du schreibst "Es funktioniert bis vor kurzen alle Nummern". Hat das Problem nach einer SoftwareÄnderung/-Erweiterung angefangen?

Ist die Codierung beim Wagen 12 irgendwie störanfälliger als bei den anderen? JustageProblem? Löcher kleiner oder nicht sauber oder irgendwie "schief" angeordnet?

Gruss, Heinileini

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

.. Die Wagen werden über ein Lochmuster und 9 Sensoren gelesen...

Wie wird denn das Lesen getriggert? Wie ist die Peripherie aufgebaut, eventuell über Profibus? Gibt es Diagnoseeinträge? Welche OBs sind im Programm enthalten? Ich denke in Richtung verlängerter Zykluszeiten, zum Beispiel aufgrund von Instabilitäten am Bus. Vielleicht auch Inkonsistenzen beim Einlesen der Sensoren. Ein verdreckter Initiator, der besonders beim Gehänge Nr. 12 etwas stärker gedämpft wird? Es muss irgend etwas sein, was durch Alterung zustande kommt.

 

[PN/DP]

Ich vermute, daß der Fehler außerhalb der FC56 und FC57 liegt: einspeichern oder auslesen zum falschen Zeitpunkt, oder Variablen-Überlappung, oder woanders schreibt ein wilder Pointer, ...

Hast Du mal überprüft, ob DB151.DBW10 oder DB151.DBW22 woanders (manchmal) überschrieben werden? (da wo die Wagennummer in DB151.DBW10 und DB151.DBW22 geschrieben wird schreibe zusätzlich in eine Variable in einen anderen ganz neuen DB und vergleiche mit DB151.DBW10 und DB151.DBW22 direkt vor Aufruf der FC56 und FC57)

Hast Du mal im Programm mitgeloggt, ob die Wagennummer 12 immer korrekt erkannt wird? (Beispielcode Logbuch) Vielleicht ist ein Loch des Wagen 12 verdreckt/zu groß/zu klein oder einer der 9 Sensoren ein kleines bißchen ungenau auf den Lochmittelpunkt montiert und sieht manchmal den Lochrand? Oder schaukelt der Wagen 12 mehr als andere oder schwankt der Triggerzeitpunkt?

Harald

 

[Eraser]

*Gelöscht*
War jemand schneller als ich.

 

[Zombie]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kanns nicht sein, dass für den Wagen 12 einfach das falsche Ziel in der Datenbank steht?
Wenn Wagen 12 immer nach links fährt obwohl er rechts soll, könnte einfach das Ziel falsch sein?